Java EE ja Enterprise JavaBeans 3.0 Harri Valkonen 30.4.2007 HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
i Sisällys 1 Johdanto... 1 2 EJB ja muut Java EE -teknologiat... 1 3 Enterprise JavaBeans 3.0... 4 3.1 Pysyvyys... 5 3.2 Transaktiot... 6 3.3 Turvallisuus... 7 3.4 Ajastin-palvelu... 8 3.5 Message Oriented Middleware... 9 3.6 Java EE Connector architecture...11 3.7 Klusterointi...12 4 Yhteenveto...15 Lähteet 15
1 1 Johdanto Java EE, Java platform Enterprise Edition, on laajalle levinnyt ja pitkälle kehittynyt kokoelma korkeantason käsitteitä, ohjelmointistandardeja ja innovaatioita. Ne mahdollistavat suurien, skaalautuvien ja robustien ohjelmien tekemisen. Tässä tekstissä tutustutaan Java EE:hen kuuluvaan Enterprise JavaBeans 3.0 -komponenttiin (EJB) ja sen tarjoamiin väliohjelmisto-tason palveluihin EJB yksinkertaistaa vaikeiden ja laajojen ohjelmistojen tekemistä määrittelemällä joukon komponentteja rajapintoineen ja määrittelemällä palveluorientoituneen ohjelmistoalustan (Application Server). Näin ohjelmistoyhtiö voi keskittyä sovelluslogiikan tekemiseen jättäen palvelut ohjelmistoalustan hoidettavaksi. Koska kaikki on standardoitu, voi ohjelmistoyhtiö vertailla eri valmistajien ohjelmistoalustoja ja valita itselleen parhaimman vaihtoehdon. Käyttämällä Enterprise JavaBeans -teknologiaa ohjelmistoyhtiön ei tarvitse huolehtia muun muassa transaktioista, datan pysyvyydestä (persistent), turvallisuudesta (security), tilan hallinnasta, komponentin elinkaaresta tai säikeistämisestä (threading). Tässä tekstissä kappale kaksi esittelee EJB teknologian tekniset periaatteet yleisellä tasolla ja miten EJB käyttää hyväkseen muita Java EE:n määrittelemiä teknologioita. Kappaleessa kolme esitellään tarkemmin Enterprise JavaBean -teknologiaa keskittyen sen tarjoamiin väliohjelmisto tason palveluihin. Kappale neljä sisältää yhteenvedon. 2 EJB ja muut Java EE -teknologiat Java EE tunnettiin aiemmin J2EE:n nimellä, mutta versiosta 5.0 alkaen Sun Microsystems nimesi uudelleen teknologian Java EE:ksi. Samassa yhteydessä myös J2SE uudelleen nimettiin versiosta 6.0 alkaen Java SE:ksi. Java EE on kokoelma väliohjelmisto tason palveluita, jotka on suunniteltu nopeuttamaan laajojen ja vikasietoisten palvelin -tason ohjelmistojen tekemistä. Uusi Java EE -versio keskittyi pääasiassa yksinkertaistamaan olemassa olevia määrityksiä, mutta esittelee myös EJB 3.0 standardin, JavaServer Faces -määritykseen ja uudistuksia WebServices palveluun. Tässä kappaleessa esitellään lyhyesti osa eri Java EE -teknologioista, joita EJB teknologia käyttää suoraan hyväkseen. Näiden lisäksi Java EE pitää sisällään paljon
2 muita teknologioita, joita ei tässä tekstissä käsitellä. Tällaisia teknologioita ovat muun muassa Java Server Pages, JavaMail ja JavaServer Faces [Jav07]. Ensimmäiseksi muista Java standardeista EJB pavun asiakasohjelman tekijä kohtaa Java Naming and Directory Inteface (JNDI) määrityksen, jota käyttämällä asiakasohjelma hankkii EJB pavun etärajapinnan. JNDI palvelun sijainti kerrotaan asiakkaalle esimerkiksi asetustiedoston avulla. Sijainnin selvittämisen jälkeen asiakas voi hankkia palvelusta EJB -pavun etärajapinnan pavun nimen perusteella. Saatuaan etärajapinnan asiakasohjelma voi alkaa kutsumaan sen metodeja. Etärajapinta, joka on muista hajautetuista teknologioista tutun tynkäluokan vastine, ohjaa kutsun sovelluspalvelimessa suoritettavalle papusäiliölle (bean container), joka kutsuu itse EJB papua. Seuraava kuva havainnollistaa edellä kuvattua toimintaa etärajapinnan hankkimisen jälkeen: AppServer Client Remote Interface EJB Container LAN Kuva 1. EJB ohjelma. EJB käyttää etämetodien toteutuksessa hyväkseen Remote Method Invocation (RMI) määritystä. RMI on Java standardi, joka luotiin alun perin Java maailmaan toteuttamaan hajautettujen olioiden etäkutsu mekanismi. Ensimmäisissä versioissa RMI oli rajoittunut pelkästään Javaan eli keskustelevien ohjelmien piti olla kirjoitettu Javalla [Sri06, 65]. Myöhemmissä versioissa Java Remote Method Protocol protokolla korvattiin CORBA (Common Object Request Broker Architecture) teknologian
3 käyttämällä protokollalla nimeltä IIOP. Lisäksi määritettiin sovitin palvelu, jolla RMI kutsut pystytään kuljettamaan IIOP:n päällä. Liitos tunnetaan nimellä RMI-IIOP protokolla, joka mahdollistaa esimerkiksi EJB 3.0 pavun kutsumisen C++ -kielellä tehdystä ohjelmasta tai päinvastoin [Sri06, 65]. Sovelluspalvelin tarjoaa useita erilaisia palveluita, joita EJB pavut ja niitä hallinnoivat papusäiliöt voivat käyttää hyväkseen. Palveluvalikoimasta löytyy esimerkiksi etäkutsu-, tietokanta-, nimen selvitys-, transaktio- ja viestintä-palvelut. Seuraavassa kuvassa edellä mainittuja palveluita vastaavat seuraavat Java standardien lyhenteet: RMI, JDBC, JNDI, JTA ja JMS: AppServer Container EJB R M I J D B C J N D I J T A J M S OS Kernel LAN Kuva 2. Sovelluspalvelimen tarjoamia palveluita.
4 3 Enterprise JavaBeans 3.0 EJB:n on palvelin päässä toimiva ohjelmistokomponentti, joka voidaan asentaa (deploy) hajautettuun monikerros ympäristöön. Yksi Enterprise bean (papu) voi muodostua yhdestä tai useammasta Java-oliosta, koska komponentti on yleensä isompi kuin vain yksi olio. Huolimatta siitä, miten papu on toteutettu, asiakkaat keskustelevat pavun kanssa käyttäen vain yhtä rajapintaa. Tämän rajapinnan, kuten myös itse pavun, pitää noudattaa Java EE:n määrityksiä. Java EE:n määrittää muutamia metodeita, jotka mahdollistavat papusäiliön hallinnoida papujen elinkaarta ja kontrolloida osaltaan niiden toimintaa. EJB ei ota mitään kantaa itse asiakas-ohjelmaan. Se voi olla mitä vain, esimerkiksi servletti (servlet) tai appletti (applet) tai jopa toinen papu. Koska papua voi kutsua toinen papu, voidaan monimutkainen ongelma osittaa hallittavammiksi osiksi ja ketjuttaa kutsut sopivalla tavalla palvelun toteuttamiseksi. Tämä on erittäin käyttökelpoinen ja voimakas väline EJB teknologiassa. Seuraavassa kuvassa esitellään joitain vaihtoehtoja erilaisista EJB papujen asiakasohjelmista [Sri06, 63]: Kuva 3. Erilaisia EJB järjestelmiä.
5 Erilaisia papu-tyyppejä on EJB 3.0 standardissa kolme erilaista: tilaton- (stateless), tilallinen- (statefull) ja viestintä- (message driven) papu. Aikaisemmissa standardeissa mukana ollut entiteetti-papu on korvattu kokonaan uudella teknologialla nimeltään entiteetti (entity), mutta EJB 3.0 tukee myös vanhemmissa standardeissa ollut entiteettipapua. Tilaton -papu on paputyyppi, jolla ei nimensä mukaisesti voi olla mitään tilatietoa. Tilaton papu ei siis tiedä asiakkaasta tai aikaisemmista kutsukerroista mitään. Tilaton - papu on sovelluspalvelimen ja esimerkiksi jäljessä esiteltävän klusteroinnin kannalta paras vaihtoehto. Koska ketä tahansa asiakasta voi palvella mikä tahansa tilaton papu, voi sovelluspalvelin hallinnoida tilattomia papuja hyvin vapaasti. Tilallinen papu on paputyyppi, jota käytetään silloin, kun sovelluksen täytyy muistaa keskustelun tila asiakkaan kanssa. Tilallisella pavulla on siis tilatietoa ja samaa asiakasta palvelee yleensä aina sama papu. Poikkeustapaus on, jos joudutaan vaihtamaan varmistavaan palvelimeen, jolloin palveleva papu on ensisijaisen palvelijan kopio. Klusterointiin ja varmennukseen palataan myöhemmin. Esimerkiksi pankkisovelluksissa pavun täytyy muistaa asiakkaan aikaisemmista toiminnot, joihin tilallinen -papu on oikea vaihtoehto. Tilallinen papu on hallinnoinnin ja klusteroinnin kannalta huomattavasti tilatonta papua vaikeampi tapaus. Viestintä papu on muista poikkeava papu siinä mielessä, ettei sillä ole etärajapintaa ja asiakas ei voi sitä suoraan kutsua. Papusäiliö kutsuu viestintä papua saadessaan viestejä asiakasohjelmilta. Uuden entiteetit eivät siis ole EJB papuja, vaan Java SE versiossa määritettyjä Java luokkia toteuttaen Java Persistence rajapinnan. Lisää entiteeistä ja vanhemmista entiteetti -pavuista seuraavassa kappaleessa. Lukuun ottamatta muutamia poikkeustapauksia kaikki edellä mainitut papu-tyypit voivat yleensä käyttää jäljessä esiteltyjä palveluita. 3.1 Pysyvyys EJB 3.0 standardin edeltäjissä pysyvyys (persistence) -palvelu hoidettiin Entiteettipavuilla (Entity Bean). Papusäiliö hallinnoi entiteetti-papuja samaan tapaan kuin muitakin papuja. Entiteetti-pavut saivat kuitenkin osakseen paljon kritiikkiä huonosta suorituskyvystään [Guo05] ja niinpä EJB 3.0:n myötä entiteetti-pavut korvattiin uudella ja tehokkaammalla tekniikalla nimeltään entiteetit (entities). EJB 3.0 on yhteensopiva
6 aiempien määritysten kanssa, joten vanhemmissa standardeissa käytettyjä entiteettipapuja voi käyttää myös EJB 3.0 versiossa. Uuden pysyvyys rajapinnan nimi on Java Persistence, joka on osa Java SE -versiota ja sisältyy siten myös Java EE -versioon. Uusi, molemmille versioille yhteinen rajapinta yhdenmukaistaa ja helpottaa pysyvyys-palveluita tarvitsevien ohjelmistojen tekoa. Java Persistence on normaaleihin Java-olioihin (POJO, Plain Old Java Object) tukeutuva ohjelmointi-rajapinta (API). Määritys sisältää täydellisen olio/relaatio yhteyden (mapping) määrityksen käyttäen Java metadata -merkintöjä (annotation) tai XML kuvaajia (descriptor) kuvaamaan Java olion ja relaatio-tietokannan suhteita [JaP07]. Lisäksi määritys pitää sisällään ilmaisuvoimaisen, SQL-kielen tapaisen kysely-kielen niin staattisille kuin dynaamisille kyselyille. Määritys mahdollistaa myös pysyvyys palveluiden tarjoajan vaihtamisen eli talletuskohde ja muoto voidaan vaihtaa ohjelmallisesti. Mikä tahansa papu tyyppi voi käyttää pysyvyys palveluita. 3.2 Transaktiot Transaktiot yksinkertaistavat ohjelmien tekoa vapauttamalla ohjelmoijan monista vaikeista ohjelmointi-haasteista, kuten virheistä toipumisesta ja monesta yhtä aikaisesta käyttäjästä johtuvista haasteista. Transaktioita käytettäessä ohjelman suorittama työ jakaantuu yksiköihin, joita kutsutaan transaktioiksi. Transaktio järjestelmä takaa, että työyksikkö suoritetaan kokonaisuudessaan loppuun tai virheen sattuessa ohjelman tila palautetaan transaktiota edeltävään tilaan (roll-back). Yleisesti transaktiot määritetään neljän ominaisuuden perusteella: atominen (Atomic), konsistentti (Consistent), eristetty (Isolated) ja pysyvä (Durable). Edellä mainituista englannin kielisistä nimistä saadaan yleisesti tunnettu transaktioita kuvaava lyhenne: ACID [TaS07, 21]. Transaktioita ei esitellä tässä tekstissä tämän syvällisemmin. Niihin voi tutustua tarkemmin esimerkiksi edellä mainitun viitteen kautta. Transaktio-tuki on olennainen osa EJB arkkitehtuuria. EJB pavun tai asiakas-ohjelman tekijän ei tarvitse huolehtia transaktioiden hallinnasta, vaan voivat keskittyä varsinaiseen ohjelmalogiikkaan. EJB pavun ohjelmoija voi valita ohjelmoiko itse transaktio järjestelmän API:a käyttämällä transaktioiden rajat vai käyttääkö ns. julistuksellista lähestymistapaa. Lisäksi yksi mahdollinen tapa on antaa EJB pavun asiakkaan merkitä papu-kutsut transaktioon kuuluviksi (client-controlled transaction).
7 Julistuksellisessa lähestymistavassa ohjelmoija ilmoittaa sovelluspalvelimelle mitkä EJB pavun metodeista kuuluvat transaktioon ja EJB papusäiliö hoitaa automaattisesti transaktioiden hallinnan [JSR06, 316]. Näin ohjelmakoodi pysyy siistinä, koska ylimääräistä transaktioihin liittyvää koodia ei tarvitse kirjoittaa. EJB 3.0 standardi tukee pelkästään ns. matalia (flat) transaktioita, joten transaktiot eivät voi olla sisäkkäisiä (nested) [JSR06, 316]. EJB 3.0 hyödyntää transaktioissa muita Java standardin määrittelemiä ohjelmointirajapintoja. Java Transaction API (JTA) määrittelee rajapinnan transaktio managerin ja muiden hajautettuun transaktioon osallistuvien tahojen kesken, jotka ovat itse ohjelma, resurssi-managerit (esim. tietokanta) ja sovelluspalvelin. Java Transaction Service (JTS) puolestaan määrittelee sidoksen CORBA:n Object Transaction Service:n (OTS) tarjoamaan rajapintaan. CORBA on pitkään olemassa ollut standardi hajautettujen järjestelmien tekoon. CORBA on täysin laite, käyttöjärjestelmä, ohjelmointikieli tai toimittaja riippumaton standardi, joka on monella tapaa ollut EJB:n esikuva [Rom99, 303-304]. JTS tarjoaa transaktioiden yhteensopivuuden CORBA arkkitehtuurissa käytetyn mekanismin kanssa. JTA voi käyttää hyväkseen JTS:n tarjoamia palveluita, mutta itse EJB pavun ohjelmoija käyttää vain JTA rajapintaa. Koska EJB 3.0 standardi vain suosittelee JTS -rajapinnan käyttöä, voi eri sovelluspalvelimen transaktiot olla toteutettu epäyhteensopivalla tavalla, jolloin hajautettua transaktiota ei voida hajauttaa eri valmistajien sovelluspalvelimille [Sri06, 286]. 3.3 Turvallisuus Laajat väliohjelmistot käyttävät tyypillisesti jotain tärkeää liiketoiminta-resurssia. On luonnollista, että näitä tärkeitä resursseja pitää suojella luvattomalta käytöltä. Turvallisten järjestelmien rakentaminen on aina tasapainoilua lisääntyvän kompleksisuuden, vähentyvän suorituskyvyn, ylläpidettävyyden ja toiminnallisuuden kanssa. Siksi on tärkeää, että osataan tunnistaa kyseisen järjestelmän turvallisuus-riskit ja valita oikea suojautumistaso. Tyypillisesti turvallisuus käsite jakautuu seuraaviin alikäsitteisiin: vastapuolen tunnistaminen (authentication), suoritus-oikeudet (authorization), datan koskemattomuuden turvaaminen ja datan luottamuksellisuuden säilyttäminen.
8 Autentikointi tapahtuu tyypillisesti käyttäjätunnuksen ja salasanan avulla tai perustuu julkiseen digitaaliseen allekirjoitukseen. Kun tunnistettu käyttäjä käyttää järjestelmää, vaaditaan järjestelmältä yleensä suoritus-oikeuksien tarkistaminen, eli vain tietyt käyttäjät tai käyttäjäryhmät voivat suorittaa tiettyjä operaatioita. Datan koskemattomuudella tarkoitetaan sitä, ettei kolmas osapuoli voi muokata tai vääristää dataa, kun dataa siirretään verkon yli. Datan luottamuksellisuus pyritään tyypillisesti säilyttämään soveltamalla erilaisia kryptaus algoritmejä datalle, jottei kolmas osapuoli pysty lukemaan viestiä, vaikka onnistuisikin sen kaappaamaan. Java Authentication ja Authorization Service (JAAS) määrittelee rajapinnat, joita käyttämällä Java ohjelmat, mukaan lukien EJB-pavut, voivat tunnistaa käyttäjän ja tarkistaa heidän oikeutensa. EJB käyttää jo olemassa olevia turvallisuus standardeja datan suojaamiseen siirron aikana, kuten Secure Socket Layer (SSL / TSL) määritystä [AlB03]. JAAS mahdollistaa sovelluspalvelimen automaattisesti vahvistaa annetut kirjautumistiedot riippumatta turvallisuuspolitiikan toteuttavasta järjestelmästä. Sovelluspalvelin voi vahvistaa tiedot esimerkiksi tietokannasta, asetustiedostoista tai tarkoitukseen suunnitellusta kolmannen osapuolen tarjoamasta järjestelmästä. Riippumatta toteutustavasta vahvistaminen voidaan toteuttaa implisiittisesti sovelluspalvelimen toimesta [Sri06, 329]. Käyttäjän tunnistamisen jälkeen sovelluspalvelin tarkastaa käyttöoikeudet ennen pavun metodeiden kutsumista. Jokaisella turvallisella pavulla on olemassa oma turvallisuuspolitiikka (security policy), jonka pavun ohjelmoija määrittelee joko ohjelmoimalla turvallisuustarkistukset itse pavun koodiin tai julistamalla turvallisuus-politiikan, jolloin papusäiliö toteuttaa julistetun politiikan. EJB tukee myös turvallisuus-rooleja, jolloin uusia käyttäjiä ja rooleja voidaan lisätä tai poistaa koskematta itse papujen koodiin [Sri06, 329]. 3.4 Ajastin-palvelu Ajastustoiminnot ovat tyypillinen enterprise tason ohjelmistojen vaatimus väliohjelmistoille. Esimerkiksi enterprise sovellus voi olla pankkijärjestelmä, joka on ruuhkautunut päivisin, mutta yöllä on huomattavasti hiljaisempaa. On viisasta ajastaa huolto- ja siivous -toimenpiteet suoritettavaksi hiljaisempaan aikaan.
9 EJB 2.1 versio toi mukanaan EJB ajastin-palvelun (Timer Service). Palvelu määrittää useita rajapintoja, joita käyttämällä sovelluspalvelin voi kutsua takaisin (call-back) papuja, kun asetettu aikaraja umpeutuu. Call-back -metodeissa voidaan suorittaa mitä tahansa tiettyyn aikaan haluttua ohjelmakoodia. Vanhemman määrityksen mukaiset Entiteetti-pavut, sekä stateless- ja message-driven pavut voivat rekisteröityä ajastinpalveluun, mutta statefull pavut tai uuden määrityksen mukaiset Java Persistence entiteetit eivät voi [Sri06, 368]. Tulevissa EJB:n versiot todennäköisesti tukevat ajastinpalvelua myös edellä mainituille käsitteille. Ajastin-palvelua käytettäessä on hyvä huomata, ettei se sovellu reaali-aika laskentaan eli määritys ei takaa, että palvelu kutsuu aina tarkasti oikeaan aikaan rekisteröitynyttä papua. Sen sijaan takaisin-kutsu tapahtuu suunnilleen annettuun aikaan. Java standardi ei määrittele tarkasti säikeiden ajastamis-käytäntöä, joten se vaihtelee eri Java virtuaali koneiden (JVM) välillä. Lisäksi roskienkeruu algoritmin suorittaminen aiheuttaa epädetermistisyyttä. 3.5 Message Oriented Middleware Etäkutsut, kuten RMI- tai CORBA tekniikkaan pohjautuvat, tai suoraan TCP/IP protokolla-pinon kuljetuskerroksen päälle tehdyt hajautetut sovellukset eivät välttämättä aina ole tarkoitukseen soveltuvia ja ohjelman vaatimukset täyttäviä. Edellä mainittujen ratkaisuiden huono puoli on, että molempien keskustelevien osapuolten on oltava suorituksessa, jotta kommunikointi voi onnistua. Tämän ongelman ratkaisemiseen on kehitetty viesti-orientoituneita väliohjelmistoja (Message-Oriented Middleware, MOM). Perusidea MOM pohjaisessa järjestelmässä on, että lähettäjän ja vastaanottajan ei tarvitse olla koko kommunikoinnin ajan suorituksessa. Lähettäjä voi lähettää viestin ja jatkaa suoritustaan (asynkrooninen viestintä), vaikka viestin käsittelevä asiakas-ohjelma olisi kaatunut. MOM ottaa viestin vastaan ja toimittaa sen asiakkaalle, kun asiakasohjelma ottaa uudelleen yhteyttä MOM ohjelmistoon. Lisäksi MOM tarjoaa yleensä toimitus-takuun säilömällä viestit esimerkiksi kiintolevylle laitevikojen tai vakavien ohjelmistovirheiden varalta. Viestillä voi olla monta asiakasohjelmaa eli MOM voi monistaa viestin usealle eri asiakkaalle. Eri viestintä -tyypeistä käytetään termejä point-to-point, jossa jokaisella viestillä on vain ja ainoastaan yksi kuluttuja, mutta eri viesteillä voi olla eri kuluttajat (ja tuottajat). Toinen viestintä tyyppi on ns. publish / subscribe malli, jossa yksi tai useampi tuottaja tuottaa
10 viestejä yhteen tai useampaan ns. topic :iin. Kuluttajat rekisteröityvät kiinnostavaan topic:iin ja MOM välittää viestit jokaiselle topic:iin rekisteröityneelle kuluttajalle. MOM pohjaiset järjestelmät ovat hyvä ratkaisu, jos viestinnän ei tarvitse olla lähes reaaliaikaista, johon etäkutsut ja TCP/IP ovat parempi vaihtoehto [TaS07, 145]. Java EE tukee MOM ajattelutapaa tarjoamalla Java Message Service (JMS) - määrityksen. Ennen JMS -standardia monet valmistajat tarjosivat omia MOM paradigman mukaisia tuotteita, joka johti kaaokseen tuotteiden yhteensopimattomuuden takia. Nykyään JMS standardi on laajasti tuettu eri valmistajien toimesta mahdollistaen eri valmistajien tuotteiden yhteensopivuuden. JMS määrittää kaksi rajapintaa: viestien lähetykseen ja vastaanottamiseen tarkoitetun rajapinnan, sekä palveluntarjoaja rajapinnan, joka abstrahoi palveluntarjoajan itse palvelusta. JMS toteuttaa molemmat edellä mainitut MOM ajattelutavan mukaiset viestintä tyypit [Sri06, 161]. EJB 1.3 standardin myötä esiteltiin uusi paputyyppi nimeltään Message Driven Bean (MDB) [JaM07]. MDB tarjoaa EJB maailmassa MOM ajattelutavan mukaiset palvelut, jotka perustuvat JMS määritykseen. MDB:a ei voi kutsuta suoraan, vaan papusäiliö kutsuu papua saadessaan viestin asiakas-ohjelmalta, joka JMS standardin ansiosta voi olla mikä tahansa JMS määrityksen toteuttava ohjelma. Seuraava kuva havainnollistaa MDB:n ja sovelluspalvelimen toimintaa JMS viestinnässä [Sri06, 170]:
11 Kuva 4. JMS:n ja EJB:n yhteistoiminta. MOM pohjautuville sovelluksille on monta hyvää käyttökohdetta, kuten esimerkiksi sähköposti- ja ryhmäohjelmistot (groupware), sekä taustaprosessien välinen kommunikointi. Lisäksi erinomainen käyttökohde ovat hajautetut tietojärjestelmät ja hajautetut tietokannat. Esimerkiksi tietokanta-kysely, joka tarvitsee tietoa useasta tietokannasta, voidaan pilkkoa pienempiin kyselyihin ja ohjata oikeaan tietokantaan MDB:n avulla [TaS07, 152]. 3.6 Java EE Connector architecture Java EE Connector Architecture käsitteestä käytetään tässä tekstissä JCA akronyymiä, jota ei pidä sekoittaa Java Cryptography Architecture:een. JCA on standardoitu sovelluskehys, joka on suunniteltu enterprise tason ohjelmistojen sulauttamiseen. Käyttämällä JCA:ta ohjelmoija voi käyttää hyväkseen yrityksellä jo olemassa olevia perintö-järjestelmiä (legacy systems). Lisäksi yritysfuusioiden synnyttämät tarpeet eri yhtiöiden järjestelmien yhteensovittamiseksi voidaan helposti hoitaa JCA tekniikan avulla.
12 JCA standardoi tavan kuinka sovelluspalvelin ja perinne-järjestelmän välinen yhteistyö hoidetaan. Aikaisemmin ilman standardia tapahtuneet integroinnit johtivat yksilöllisiin ratkaisuihin, joita oli vaikea ymmärtää ja ylläpitää. JCA määrittää lisäksi useita palveluita, jotka vapauttavat ohjelmoijan monesta järjestelmätason ohjelmointiongelmasta, kuten säikeistyksestä, transaktioista, turvallisuudesta ja yhteydenhallinnasta. Järjestelmätason ohjelmointi on erityistaitoja vaativa laji ja lisäksi se lisää huomattavasti kehitys-, testaus- ja asennusaikaa. JCA:n avulla sovelluspalvelin voi hoitaa edellä mainitut asiat ohjelmoijan puolesta perinne-järjestelmiä integroitaessa. Perinne-järjestelmän ja sovelluspalvelimen väliin kehitetään ns. resurssi-sovitin (Resource Adapter). Sovelluspalvelin kutsuu sovitinta sovelluksen suorituksen eri vaiheissa ja sovittimen tehtävä on hoitaa kommunikointi perinne-järjestelmän kanssa. Sovitin voi implementoi erilaisia sopimuksia sovelluspalvelimen kanssa, kuten esimerkiksi yhteyden-hallintasopimus, joka mahdollistaa ns. yhteys-varaston (pool) perustamisen tai turvallisuus-sopimus, joka mahdollistaa turvallisen yhteyden perinnejärjestelmään [Sri06, 440]. Muita sopimuksia ovat transaktioiden hallintasopimus, jossa mahdollistaa perinnejärjestelmän osallistumisen transaktioon tai elinkaaren hallintasopimus, jota käyttämällä sovelluspalvelin hallinnoi sovitinta [Sri06, 441]. Työn hallintasopimuksella sovitin voi delegoida työtä sovelluspalvelimelle, joka suorittaa työn omassa säikeessään [Sri06, 441]. Lisäksi JCA:sta löytyy sisään tulevan transaktion (transaction inflow) sopimus, jolla perinne-järjestelmä voi sisällyttää kutsun sovelluspalvelimeen osaksi omaa transaktiotaan tai sisään tulevan viestin (inflow message) sopimus, jolla sovitin voi asynkroonisesti toimittaa viestin sovelluspalvelimelle [Sri06, 441]. JCA kehystä käyttämällä EJB papu voi esimerkiksi ottaa yhteyttä Java Native Interface:a käyttämällä C++ -kielellä tehtyyn ohjelmaan. 3.7 Klusterointi Java EE standardi ei määrittele klusterointi palvelua, mutta jokainen tyypillisesti EJB:n toteuttava sovelluspalvelin tukee jollain tapaa klusterointia [Sri06, 508]. Standardin puutteesta johtuen klusterointi on sovelluspalvelin kohtaista, mutta pääperiaatteiltaan kaikki noudattavat jotain jäljessä esitellyistä tavoista. Seuraavaksi tarkastelemme hieman tarkemmin klusterointia, vaikka EJB 3.0 standardi ei sitä määritäkään. Asia on kuitenkin niin tärkeä laajoille ohjelmistoille, että tulevaisuuden EJB -standardeissa asiaan otetaan todennäköisesti kantaa.
13 Tyypillisesti korkealaatuisilta enterprise -ohjelmistoilta vaaditaan suurta luotettavuutta ja saatavuutta. Luotettavuudella tarkoitetaan, että järjestelmä toimii määrityksensä mukaisesti oikein kaiken aikaa. Saatavuudella taas tarkoitetaan aikaa, jolloin järjestelmä on palvelemassa asiakkaitaan eli saatavuutta pienentää esimerkiksi huoltotauot tai järjestelmän täydellinen kaatuminen. Lisäksi odotetaan, että järjestelmä pystyy palvelemaan paljon asiakkaita ja asiakkaiden määrän kasvaessa järjestelmä voidaan mukauttaa kasvaneeseen asiakasmäärään. Vaatimuslistaan kuuluu myös hyvä suorituskyky eli kaikki asiakkaat saavat palvelua riittävän nopeasti. Järjestelmän hallittavuus nousee myös tärkeäksi, koska laajaa järjestelmää valvoo ja huoltaa tyypillisesti useampi henkilö. Enterprise järjestelmän perusvaatimukset voidaankin tiivistää seuraavasti: luotettavuus (reliability), saatavuus (availability), hallittavuus (servicebility) ja skaalautuvuus (scalability) [Sri06, 506-507]. Näihin haasteisiin vastataan EJB maailmassa yleisesti klusteroinnilla. Klusteroinnin perusperiaatteena on käytettävissä olevien resurssien monistaminen, jolla saavutetaan vikasietoisuutta ja enemmän laskentatehoa. Klusteri on ryhmä samanlaisia palvelin-tason koneita, joista jokainen tarjoaa täysin samanlaisen palvelun. Asiakas ottaa yhteyttä ns. julkisivu koneeseen tai tarkoitusta varten suunniteltuun sulautettuun järjestelmään, joka vain uudelleenohjaa palvelupyynnön jollekin klusterin palvelimista. Näin klusteri näyttää asiakkaalle vain yhdeltä koneelta. Klusteri voi toteuttaa kuorman tasausta (load balancing) reitittämällä asiakkaan palvelupyynnön vähiten kuormitetulle palvelimelle klusterissa. Seuraava kuva havainnollistaa kuormantasaus -klusteria käytännössä [Sri06, 510] : Kuva 5: Kuormantasaus -klusteri.
14 Klusteroinnilla voidaan parantaa myös järjestelmän vikasietoisuutta, koska järjestelmästä voidaan poistaa ns. kriittinen palvelin (single-point of failure), joka kaatuessaan pimentää koko järjestelmän. Vikasietoisuuden parantaminen on huomattavasti kuormantasausta haasteellisempi tehtävä, koska ohjelman tila täytyy toisintaa usealle koneelle (replication). Lisäksi liikennettä ohjaavan koneen tai sulautetun järjestelmän täytyy osata reitittää liikenne ensisijaisen palvelimen kaatuessa varmentavalle palvelimelle. Seuraava kuva havainnollistaa toisintamista [Sri06, 511] : Kuva 6. Toisinnettu järjestelmä. Käytännössä klusterin julkisivua hoitava ohjelmisto osaa hoitaa yhtä aikaa niin kuormantasauksen kuin toisintamisenkin, mutta on hyvä huomata näiden asioiden olevan erillisiä toimintoja. Lisäksi klusteria rakennettaessa kannattaa tarkoin harkita kuin paljon toisintamista asiakkaat todella tarvitsevat, koska toisinnetun tiedon ylläpitäminen vaatii paljon prosessointia ja tietoliikenne-kapasiteettia. EJB valmistajat hoitavat klusteroinnin pääsääntöisesti kolmella eri tavalla: JNDI tasolla, papusäiliö tasolla tai käyttämällä älykkäitä etärajapintoja (tynkäluokkia, smart stub). JNDI tavassa JNDI konteksti sitoo useita ekvivalentteja olioita yhteen nimeen ja voi siten hajauttaa liikennettä eri palvelimille. Papusäiliö tavassa papua hallinnoiva säiliö voi toisintaa tiedon suoritetuista toimenpiteistä toisella palvelimella pyörivällä papusäiliölle tai pyytää toista säiliötä suorittamaan osan omien papujensa laskennasta ja uudelleen ohjata kutsut toiselle palvelimelle [Sri06, 517]. Älykäs tynkäluokka lähestymistavassa tynkäluokka voi tuntea useita eri palvelimia ja voi siten hajauttaa kutsut useammalle palvelimelle. Nykyään tynkäluokka lähestymistapa on suosituin tapa toteuttaa klusterointi, mutta tapa sitoo samalla käyttäjänsä tiettyyn valmistajaan, koska lähestymistapaa käytettäessä on käytettävä valmistajan tarjoamia kääntämis-työkaluja,
15 jotta klusterointi logiikan rakentaminen automaattisesti on ylipäätään mahdollista [Sri06, 517]. Nykypäivänä klusterit voivat olla todella laajoja, esimerkiksi suositut palvelut Hotmail ja Google ovat hajautettu tuhansille eri palvelimille [Che02]. Enterprise tason järjestelmän tekemisen vaikeutta kuvaa hyvin se tosiasia, että näinkin suuresta hajautuksesta huolimatta järjestelmän saatavuus nousee harvoin 99,9% tasoon, joka esiintyy yleisesti korkealaatuisten enterprise tason järjestelmien vaatimuksissa [Che02]. 4 Yhteenveto Nykyajan verkottuneessa maailmassa ohjelmistoilla voi olla todella paljon käyttäjiä. Lisäksi ohjelmistojen vaatimukset ja monimutkaisuus ovat kasvaneet todella hurjaa tahtia viime vuosina. Kasvaviin haasteisiin on vastattu mm. monikerros arkkitehtuureilla. Monikerros arkkitehtuureissa merkittävin kerrosten ero on alue, jolla kerros toimii. Esityskerroksen (front-end) tarpeet poikkeavat hyvin paljon palvelin-puolen (back-end) tarpeista. EJB teknologia on suunniteltu vaativien palvelin-puolen operaatioiden tekemiseen, kuten vaativaan transaktioiden hallintaan tai korkean tason viesti-pohjaisen kommunikaation tekemiseen. Lisäksi EJB teknologia mahdollistaa sovellusten korkean saatavuuden turvatussa, vikasietoisessa ympäristössä. Java EE ja sen mukana EJB standardi ovat koeteltuja ja hyväksi havaittuja standardeja rakentaa nykyajan vaatimukset täyttävä laaja ohjelmisto. Lähteet AlB03 Allen, P.,Bambara, J., Sun Certified Enterprise Architect for J2EE Study Guide. McGraw-Hill/Osborne, 2003, kappale 10. Che02 Chen, M., et al., Pinpoint: problem determination in large, dynamic Internet services. IEEE, Proceedings International Conference on Dependable Systems and Networks, 2002, sivut 595-604. Gio00 Giotta, P. et al, Professional JMS programming. Wrox press, 2000, sivut 11-12. Guo05 Guo, C., et al., The research on the software architecture of negotiatory synthetical forecasting GDSS based on J2EE. Proceedings of the Ninth
16 International Conference on Computer Supported Cooperative Work in Design, Coventry University, UK, toukokuu 2005, sivut 27-32. JaP07 Java Persistence API FAQ. Sun Microsystems, 2007, http://java.sun.com/javaee/overview/faq/persistence.jsp. [17.4.2007] JaM07 Java Message Service API FAQ. Sun Microsystems, 2007, http://java.sun.com/products/jms/faq.html#relship_ejbs [27.4.2007] Jav07 Java EE Technologies at a Glance. Sun Microsystems, 2007, http://java.sun.com/javaee/technologies/. [17.4.2007] Jee07 Java EE 5. Sun Microsystems, 2007, http://java.sun.com/javaee/technologies/javaee5.jsp. [17.4.2007] JSR06 Java Specification Request 220: Enterprise JavaBeansTM,Version 3.0, EJB Core Contracts and Requirements. Sun Microsystems, 2006. Rom99 Mastering Enterprise JavaBeans and the Java 2 Platform, Enterprise Edition. Wiley, 1999. Sri06 Sriganesh R., Brose G., Silverman H., Mastering Enterprise JavaBeans 3.0. Wiley, 2006. TaS07 Tanenbaum, A., Steen, M., Distributed Systems, Principles and Paradigms. Prentice Hall, 2007.