AXIS2-WEBPALVELUKEHYS

Transkriptio

1 AXIS2-WEBPALVELUKEHYS Aki Heikkinen Joensuun yliopisto Tietojenkäsittelytiede Kandidaatintutkielma

2 TIIVISTELMÄ Webpalveluiden suosio liikeyritystasolla on ollut viime vuosina suuressa kasvussa, jonka johdosta nykypäivän webpalveluilta odotetaan paljon. Apache Software Foundationin julkaisema Axis2-webpalvelukehys tarjoaa joustavan ja modulaarisen tavan toteuttaa nopeasti vakaita ja tehokkaita webpalveluita. Sen vahvuudet ovat käyttäjäystävällisyys, monipuolisuus ja myöskin kustannustehokkuus, sillä se on ilmainen webpalvelukehys. Tutkielmassa tarkastellaan yleisellä tasolla webpalveluja, World Wide Web Consortium:n (W3C) julkaisemia webpalvelustandardeja ja Axis2- webpalvelukehyksen arkkitehtuuria, käyttöönottoa sekä sen palveluiden, moduulien ja asiakaspuolen toteuttamista Java ohjelmointikielellä. ACM-luokat (ACM Computing Classification System, 1998 version): D.2.2, D.2.3, D.2.11 Avainsanat: W3C, webpalvelu, Apache, Axis2, Java SISÄLLYSLUETTELO 1 JOHDANTO WEBPALVELUT Webpalvelumalli Webpalvelujen standardit ARKKITEHTUURI Moduulit Axis-oliomalli Toteutusketju Käsittelijä Vaihe Informaatiomalli Staattinen data Kontekstidata WEBPALVELUKEHYKSEN KÄYTTÖÖNOTTO Axis2-palvelimen asentaminen Axis2 web-arkistosovelluksena Axis2 itsenäisenä sovelluksena Palveluiden käyttöönotto J2EE-tapainen palveluiden käyttöönotto Joustavat päivitysmahdollisuudet Palveluiden sijoitusvarasto Palveluiden kirjoittaminen... 15

3 4.3.1 Palvelujen kuvaustiedostot Palvelun arkistotiedoston luominen Palvelun käyttäminen Moduulien kirjoittaminen Käsittelijäluokan toteuttaminen Moduulien kuvaustiedostot Moduulin arkistotiedoston luominen ja käyttöönotto Moduulin toteutusluokka Asiakas-ohjelmointirajapinnan käyttö Odottava ja ei-odottava kutsu Asiakaspuolen toteuttaminen Esimerkkejä ServiceClient-toteutuksesta YHTEENVETO VIITTEET LIITE 1: Esimerkki WSDL-tiedostosta LIITE 2: Esimerkki globaalista konfiguraatiotiedostosta: axis2.xml LIITE 3: Esimerkkikoodi palvelusta: HelloWorld.java LIITE 4: Esimerkki HelloWorld luokan kuvaustiedostosta: services.xml LIITE 5: Esimerkkikoodi moduulista: IncomingCounterHandler.java LIITE 6: Esimerkkikoodi moduulista: OutgoingCounterHandler.java LIITE 7: Esimerkki moduulitoteutuksien kuvaustiedostosta: module.xml LIITE 8: Axis2:n rajapinta: CounterConstants.java LIITE 9: Esimerkkikoodi moduulin toteutusluokasta: CounterModule.java LIITE 10: Esimerkkikoodi synkronisesta asiakkaasta: SyncWSClient.java LIITE 11: Esimerkkikoodi asynkronisesta asiakkaasta: AsyncWSClient.java

4 1 1 JOHDANTO Webpalvelut ovat pohjimmiltaan palvelukeskeisen arkkitehtuurin (Service Oriented Architecture, SOA) toteutuksia [2]. Niissä toiminnallisuus ja tarjotut palvelut ovat itsenäisiä sovelluksia, jotka on yhdistetty toisiinsa standardisoitujen ja hyvin määriteltyjen rajapintojen avulla. Tällainen arkkitehtuuri on helposti laajennettava, jonka johdosta viime vuosien aikana siitä on tullut hyvin suosittu toteutus liikeyritystasolla. Webpalveluiden vahvuus muiden www-kommunikaatiokehyksien rinnalla on se, että se hoitaa kommunikoinnin modulaarisesti kahden järjestelmän välillä käyttäen webin standardeja protokollia datan kuljettamiseen sekä XML-pohjaista representaatiota informaation esittämiseen [2]. Täten tarjotuihin palveluihin voidaan päästä käsiksi käyttäen lähes jokaisen järjestelmän mahdollistamaa webiä, joka lisää kommunikaatiomahdollisuuksia erilaisten järjestelmän kesken. Tässä kandidaatintutkielmassa tutustutaan yleisellä tasolla Apache Software Foundationin julkaisemaan Java Axis2-webpalvelukehykseen ja sen käyttöönottoon [1]. Tämän tutkielman luettua lukija ymmärtää mikä on Axis2-webpalvelukehys ja mitkä ovat sen vahvuudet erityisesti joustavuuden ja modulaarisuuden puolella. Luvussa 2 tutustuaan yleisellä tasolla webpalveuihin ja niiden toimintaan käytettävien standardien kautta. Luvussa 3 tarkastellaan Axis2-webpalvelukehyksen arkkitehtuuria, käsitteitä ja toimintatapaa. Luvussa 4 perehdytään käytännöntasolla Axis2- webpalveluiden ja asiakastilaajan kirjoittamiseen ja käyttöönottoon. Luvussa 5 on yhteenveto, jossa on esitetty tutkielman oleellisimmaan seikat. Tutkielman lopussa on useita ohjelmakoodiliitteitä, joihin viitataan eri luvuissa. Ohjelmakoodiliitteet ovat ladattavissa osoitteesta 2 WEBPALVELUT Webpalvelut kuvataan WSDL-tiedostona, joiden mukaan järjestelmät tietävät muun muassa, mitä kukin palvelu tekee, missä se sijaitsee ja miten palvelua voidaan kutsua

5 2 [2]. Webpalvelun kanssa kommunikoivat sovellukset kirjoittavat SOAP-viestejä, jotka välitetään yleensä avulla mutta välityksessä voidaan käyttää apuna myös muita web-standardeja ja XML-sarjallistuvuutta. 2.1 Webpalvelumalli Webpalvelumalli sisältää kolmenlaisia toimijoita [2]: palveluntarjoajia, välittäjiä ja tilaaja. Nämä kolme toimijaa voivat suorittaa erilaisia toimintoja, kuten kuvassa 1 on esitetty. Palveluntarjoaja on yleensä jokin organisaatio, joka tarjoaa palveluja. Toisin sanoen palveluntarjoajalla on hallussa palveluiden kooditason toteutukset. Palveluntarjoajan tehtäviä ovat muun muassa palveluiden luominen, julkaiseminen, ylläpitäminen ja poistaminen tarpeen tullen. Palvelunvälittäjä ylläpitää palveluntarjoajan julkaisemia palvelukuvauksia (WSDL tiedostoina). Palveluiden tilaajat selaavat välittäjän ylläpitämiä kuvauksia hakiessa haluamaansa palvelua. Onnistuneen haun jälkeen tilaaja saa välittäjältä palveluiden sidontainformaation, jonka avulla tilaaja voi kutsua ja käyttää palveluja. Palvelunvälittäjä voi olla avoin, jolloin sen välittämiä palveluja voi käyttää kuka tahansa tai vaihtoehtoisesti välittäjä voi olla suljettu, jolloin vain tietty joukko tilaajia voivat käyttää sen tarjoamia palveluita. Palveluntilaaja on asiakas, joka hakee ja käyttää palveluntarjoajan palveluja. Tilaaja voi olla joko järjestelmän käyttäjä tai sovelluksen aliohjelma. Kun tilaaja haluaa käyttää palveluntarjoajan palveluita, se hakee palvelunvälittäjän ja lukee välittäjän tarjoaman WSDL-tiedoston. WSDL-tiedostosta tilaaja voi määrittää, mitkä toiminnallisuudet on saatavilla sekä millä tavalla tilaaja voi suorittaa sidonnon palveluntarjoajaan, jonka jälkeen se voi kutsua haluttua palvelua. Julkaise, poista julkaisu, päivitä Palvelun välittäjä Palvelun tarjoaja Löydä Kutsu, sido Palvelun tilaaja Kuva 1. Webpalvelumalli [2]

6 3 2.2 Webpalvelujen standardit Webpalveluiden standardit ovat nopeassa kehityksessä sen kasvavan suosion johdosta. WS-* standardit määrittävät webpalveluiden protokollapinon [2], kuten kuvassa 2 on esitetty. Alla on esitelty muutama oleellinen standardi tarkemmin käsiteltynä. Kuva 2. Webpalveluiden standardit [2] XML-RPC: XML-RPC tarkoittaa etäproseduurikutsua (Remote Procedure Call, RPC), joka koodataan XML-tietona ja kuljetetaan kautta [2]. Lähetetty viesti sisältää tiedon siitä, mikä proseduuri palvelimella tulee suorittaa, jonka jälkeen proseduurin palauttama arvo koodataan XML-muotoon ja lähetetään takaisin proseduurin kutsujalle. Proseduurikutsun parametrit voivat olla skalaareja, numeroita, merkkijonoa, päivämääriä tai kompeksisia tietueita tai listarakenteita. XML-RPC on hyvin yksinkertainen, minimaalinen ja helppokäyttöinen viestintästandardi. SOAP: SOAP (Simple Object Access Protocol) on XML-RPC:stä seuraavan askeleen kevyt viestintäprotokolla, joka on tarkoitettu rakenteisten tietojen vaihtoon hajautetussa ympäristössä [3]. SOAP käyttää XML-teknologiaa määritääkseen laajennettavan viestintäkehyksen, joka kattaa viestirakenteet. Viestintäkehyksen viestirakenteet voivat muuttua eri protokollan kerroksissa. SOAP-kehys on suunniteltu irralliseksi ohjelmointimalleista ja toteutusriippuvaisesta semantiikasta. SOAP-kehyksen perusperiaate on olla tilaton, yksisuuntainen viestinvaihtoparadigma [2]. Kuitenkin sovellukset voivat luoda SOAP:ia käyttäen myös kompleksisempia

7 4 vuorovaikutusmalleja, kuten tilaa-vastaa tai tilaa-julkaise. SOAP-kehys tarjoaa myös tavan, jossa sovellusriippuvaiset tiedot voidaan välittää laajennettavalla tavalla. WS-Addressing: WS-Addressing (Web Service Addressing) mahdollistaa kehittäjille standardimallin toteuttaa luotettavia ja yhteentoimivia viestientunnistuksia ja välityksiä useampien eri päätepisteen välillä käyttäen webpalvelusovelluksia [5]. Tämä standardi tarjoaa itsenäisen kuljetustason mekanismin määrittää viestin osoitetietoja ja tunnistaa webpalveluiden päätepisteitä XML-elementtien avulla. WSDL: WSDL (Web Services Description Language) on XML-pohjainen kieli ja sen tarkoitus on kuvata webpalveluiden informaatio [4]. WSDL-tiedosto sisältää tiedon webpalvelun tarjoamista toiminnallisuuksista, niiden sijainneista ja palveluntarjoajan sidontatiedoista. Näiden lisäksi esimerkiksi palveluiden tarjoamat erikoiset tietotyypit on upotettu WSDL-tiedostoihin XML-skeeman muodossa. Liitteessä 1 on esimerkki WSDL-tiedostosta. 3 ARKKITEHTUURI Axis2 on rakennettu modulaarista arkkitehtuuria käyttäen ja se koostuu ydinmoduuleista, jotka ovat välttämättömiä toiminnallisuuden kannalta [2]. Ydinmoduulien lisäksi Axis2 sisältää myös lisämoduuleja, joiden avulla toiminnallisuutta voidaan joustavasti laajentaa tarpeen mukaan. Ydinmoduulien toteuttama perustoiminnallisuus edellyttää, että jokainen Axis2-järjestelmään saapuva viesti on muunnettava SOAP-viestiksi, ennenkuin se voidaan antaa käsiteltäväksi. Sisääntulevat viestit voivat kuitenkin olla muita kuin SOAP-viestejä, mutta kuljetustasolla kaikki viestit tullaan muuttamaan SOAP-viesteiksi. Kuva 3 esittää kaikki Axis2-arkkitehtuurin avainkomponentit.

8 5 Koodin generointimalli Tiedon sidontamalli Informaation käsittelymalli Ydinmoduulit XML-käsittelymalli SOAP-käsittelymalli Kehitys- ja käyttöönottomalli Kuljetusmalli Asiakas-ohjelmointirajapintamalli Kuva 3. Axis2-arkkitehtuurin avainkomponentit [2] 3.1 Moduulit Tässä kohdassa esitellään Axis2:n tarjoamat ydin- ja lisämoduulit. Koska Axis2:n tarkoitus on olla mahdollisiman joustava ja modulaarinen, se koostuu vain muutamasta ydinmoduulista, jotka ovat oleellisia sen toiminnalle. Nämä moduulit ovat [2]: XML-käsittelymalli: XML-käsittelymoduuli koostuu AXIS-oliomallista (AXIOM) ja sen toteutuksesta, joka kattaa perusteet SOAP-viestien tiedonesitykseen ja sen käsittelyyn. SOAP-käsittelymalli: SOAP-viestien lähetys ja vastaanotto ovat kaksi tärkeintä toiminnallisuutta webpalveluissa. Näitä varten Axis2 tarjoaa kaksi putkea ( Flows ), joista toinen viestien lähetystä varten ( OutFlow ) ja toinen viestien vastaanottoa varten ( InFlow ). Näiden kahden putken toteuttamiseksi Axis2:ssa on määritetty kaksi metodia: send() ja receive(). Kahden pääputken lisäksi Axis2:ssa on vielä kaksi muuta putkea, jotka on tarkoitettu virheviestien lähetystä ja vastaanottoa varten. Putkien idea on se, että jokainen järjestelmään saapuva tai lähtevä viesti kulkee putken läpi, joka voi sisältää erilaisia viestinkäsittelijöitä (handlers), jotka muokkaavat ja tarkastavat viestiä tarpeentullen. Informaatiomalli: Axis2:n informaatiomalli koostuu kahdesta oliohierarkiasta: kuvauksesta ja kontekstista. Kuvaushierarkia sisältää staattista dataa, joka tulevat konfiguraatiotiedostoista kuten axis2.xml, services.xml ja modules.xml. Kontekstihierarkia sisältää ajonaikaisen datan ja sen tila yleensä muuttuu aina, kun se saa viestejä. Informaatiomallia tarkastellaan tarkemmin kohdassa 3.4.

9 6 Kehitys- ja käyttöönottomalli: Tämä moduuli tarjoaa muun muassa Axis2- webpalveluilla J2EE-tapaisen levitysmekanismiin, jossa palveluiden kehittäjät voivat koota kaikki yhden palvelun tarvittavat resurssit yhteen ja samaan arkistotiedostoon. Koottu arkistotiedosto voidaan tämän jälkeen siirtää palvelukoneelle käytettäväksi. Tämän lisäksi kehitys- ja käyttöönottomoduuli tarjoaa kaksi uutta ominaisuutta, jotka helpottavat palveluiden käyttöönottoa ja päivittämistä: Hot Deployment ja Hot Update. Asiakas-ohjelmointirajapinta: Asiakas-ohjelmointirajapintamoduulia käytetään ottamaan yhteyttä ja viestittämään palveluntilaajalta palveluntarjoajaan. Moduuli tarjoaa kaksi luokka, joiden avulla viestintä voidaan toteuttaa eri tarpeen tasolla: ServiceClient ja OperationClient. Näistä ServiceClient luokka tarjoaa yksinkertaisen tavan toteuttaa XML-pohjaisten viestien lähettäminen, kun taas OperationClient luokka tarjoaa joustavamman, mutta enemmän valmisteluja vaativan tavan toteuttaa monipuolisia tehtäviä. ServiceClient luokan toteutuksella järjetelmällä on pääsy vain SOAP viestien rukoon, kun taas OperationClient luokan toteutuksella järjestelmä voi vaikuttaa myös SOAP-viestien otsikkotietoihin. Asiakas-ohjelmointirajapintaa tarkastellaan tarkemmin kohdassa 4.5. Kuljetus: Kuljetusmoduuli tarjoaa laajan tuen erilaisille kuljetusprotokollille, joihin kuuluvat: HTTP/HTTPS, TCP, SMTP, JMS ja XMPP. Käytettävät kuljetusprotokollat voidaan määrittää Axis2:n globaalissa konfiguraatiotiedostossa erikseen sekä lähtevälle että vastaanotettavalle viestille. Ydinmoduulien lisäksi Axis2:ssa on mahdollista ottaa käyttöön lisämoduuleja toiminnallisuuden laajentamiseksi. Lisämoduulien tavoite on muun muassa toteuttaa erilaisia WS-standardeja [2]. Apache Axis2-kotisivulta löytyy erikseen ladattavana muun muassa seuraavat lisämoduulit [1]: Sandesha2: Toteuttaa WS-RM spesifikaation. Rampart: Toteuttaa WS-Securityn ja WS-SecureConversation. Näiden lisäksi Axis2:n mukana tulee kaksi lisämoduulia [2]:

10 7 Koodingenerointi: Koodingenerointimoduuli on työkalu, jonka avulla voi generoida palvelinpuolen luurangon, asiakaspuolen tyngät sekä WSDL-kuvaustiedostot ja mahdolliset testitapaukset. Lisättävät tietosidonnat: Tämä moduuli laajentaa asiakas-ohjelmointirajapinnan tarjoamaa SOAP-käsittelyä kapseloimalla XML-infosetkerroksen ja tarjoamalla ohjelmointikieli-spesifisen rajapinnan. Axis2:n tukemat tiedonsidontakehykset ovat Axis2:n oma ADB, XMLBeans, JaxMe ja JibX. 3.2 Axis-oliomalli Axis-oliomalli on Apache Software Foundationin julkaisema ja Axis2:n käyttämä tehokas vaihtoehto jäsentää XML-informaatiota muiden XML-jäsentäjien (esimerkiksi DOM, JDOM ja SAX) ohella. Axis-oliomalli tunnetaan myös nimellä AXIOM (AXIs Object Model) [2] ja vaikka se onkin Axis2:n käyttämä, on se täysin irallinen julkaisu Axis2:sta. AXIOM perustuu JSR-173 standardin mukaan toteutettuun StAX-pyyntöjäsennin (Pull Parsing) ohjelmointirajapintaan ja sen vahvuudet muihin XMLjäsentimiin nähden on sen kevyt rakenne sekä pyyntö-jäsennysparadigma. Pyyntöjäsennysparadigma tarkoittaa vaihtoehtoista tapaa toteuttaa jäsennyksien käsittely. Yleisemmässä tarjontajäsennysparadigmassa (Push Parsing), jota käytetään muun muassa DOM- ja SAX-jäsentimissä, jäsennyksenhallinta on täysin jäsentimellä itsellään, jolloin yleensä koko XML-dokumentti tulee jäsentää, sillä jäsennin ei tiedä, mitkä XML-dokumenttin osat ovat oleellisia ja mitkä eivät. Pyyntöjäsennysparadigmassa jäsennyksenhallinta on jäsentäjän käyttäjälle, esimerkiksi toisella aliohjelmalla. Tällöin jäsentäjän käyttäjä voi itse valita, mitkä osat XML-dokumentista tarvitsee jäsentää. Pyyntöjäsennys on täten tehokaampi ja muistia säästävä ratkaisumalli, mikäli jäsennettävä XML-dokumentti on valtavan kokoinen ja se sisältää paljon informaatiota, joka ei ole oleellista jatkotoiminnan kannalta. 3.3 Toteutusketju Kaikki viestit, jotka vastaanotetaan tai lähetetään Axis2:ssa, kulkevat määrätyn putken läpi, jolloin ne kohtaavat monia peräkkäisiä prosesseja, jotka niiden tulee läpäistä [2]. Näitä yksittäisiä prosesseja kutsutaan kokoojiksi (interceptor) tai käsittelijöiksi

11 8 (handler) ja niistä muodostunutta peräkkäistä käsittelijäjoukkoa kutsutaan toteutusketjuksi. Toteutusketjun tarkoitus on mahdollistaa muun muassa viestien luotettavuus ja turvallisuus sekä laajentaa viestejä tarpeen mukaan Käsittelijä Käsittelijät ovat tilattomia ajureita, jotka suorittavat sille omistetun tehtävän viestiä varten, kun viesti saapuu toteutusketjua pitkin kyseiselle käsittelijälle [2]. Yleensä kukin käsittelijä tarkastelee SOAP-viestin otsikkotietoja, jolloin se joko lukee, lisää tai poistaa otsikkotietoja. Käsittelijät pystyvät myös vaikuttamaan SOAP-viestin runkoon. Poikkeukkeustilanteiden sattuessa käsittelijä heittää poikkeuksen, jonka seuraava toteutusketjussa oleva käsittelijä ottaa kiinni ja toteuttaa tarvittavat toimenpiteet. Kukin käsittelijä pystyy myös tarvittaessa keskeyttämään tai tilapäisesti pysäyttämään toteutusketjun. Toteutusketjun keskeyttäminen johtuu yleensä siitä, että viesti on virheellinen tai se ei sisällä tarvittavia parametreja esimerkiksi salaukseen liittyen. Toteutusketjun tilapäinen pysäyttäminen voi tapahtua moniosaisten viestien osalla, kun viestien viimeinen osa saadaan käsiteltäväksi ennen ensimmäsistä osaa. Tässä tapauksessa käsittely tulee keskeyttää siksi aikaa, kunnes ensimmäinen osa viestistä saadaan käsiteltyä Vaihe Vaiheilla tarkoitetaan dynaamista käsittelijöiden järjestystä toteutusketjussa [2]. Toteutusketju on siis järjestetty vaiheiden joukko, jotka on esitelty globaalissa axis2.xml konfiguraatiotiedostossa. Liitteessä 3 on esimerkki globaalista konfiguraatiotiedostosta. Kun vaihetta kutsutaan, se kutsuu peräkkäin vaiheen kattamia käsittelijöitä. Vaiheilla on myös kaksi tärkeää metodia, joiden avulla voidaan suorittaa esi- ja jälkiehtojen tarkastukset kussakin vaiheessa. Vaiheet voivat olla joko globaaleja tai operatiiviisa. Globaaleja vaiheita kutsutaan aina, kun viesti tulee järjestelmään, kun taas operatiivisia vaiheita kutsutaan vain erikoistapauksissa, kun niitä tarvitaan. Kullakin vaiheella tulee olla määritetty ensimmäinen (phasefirst) ja viimeinen (phaselast) käsittelijä, jotka määräävät mistä vaiheen käsittelijät alkavat ja mihin ne päättyvät. Vaiheilla voi olla myös muita attribuutteja, jotka määräävät käsittelijöiden järjestyksen, kuten before ja after. Näitä attribuutteja kutsutaan vaihesäännöiksi. Before vaihesääntö tarkoittaa, että kyseinen käsittelijä tulee suorittaa ennen before attribuutissa annettua käsittelijää,

12 9 ja after vaihesääntö tarkoittaa, että kyseinen käsittelijä tulee suorittaa after attribuutissa annetun käsittelijän jälkeen. Before ja after attribuutit voidaan myös yhdistää, jolloin kyseinen käsittelijä suoritetaan attribuuteissa annettujen käsittelijöiden välissä. Vaihesäännöillä on myös muutama periaate, jotka tulee toteuttaa tai vaihe on epäkelvollinen. Periaatteet ovat [2]: (1) Vaiheella voi olla vain yksi phasefirst attribuutti. (2) Vaiheella voi olla vain yksi phaselast attribuutti. (3) phasefirst tai phaselast attribuutin omaavalla käsittelijällä ei voi olla muita vaihesääntöjä. (4) Jos samalla käsittelijällä on phasefirst ja phaselast attribuutit, vaiheella ei voi olla muita käsittelijöitä. (5) Before attribuutti ei voi viitata phasefirst käsittelijään. (6) After attribuutti ei voi viitata phaselast käsittelijään. 3.4 Informaatiomalli Axis2:n joustavuus ja laajennettavuus pohjautuu sen informaatiomalliin, jossa sen logiikka ja data pidetään erillisinä toisistaan jaettuna kahteen oliohierarkiaan [2]: staattiseen (logiikka) ja dynaamiseen (ajonaikainen kontekstidata). Axis2:n staattinen data eli logiikka on persistoituja konfiguraatio-optioita, jotka tulevat kolmesta eri lähteestä: globaali-tason konfiguraatiotiedostosta axis2.xml, palvelutason konfiguraatiotiedostosta services.xml ja moduuli- tai palvelulaajennusten konfiguraatiotiedostosta module.xml. Dynaaminen eli konstekstidata muuttuu aina, kun järjestelmä saa viestin käsiteltäväksi. Kuvassa 4 on esitetty staattisen ja ajonaikaisen datan suhteet toisiinsa eri tasoilla Staattinen data Staattisen datan hierarkia koostuu viidestä tasosta, jotka kukin voivat sisältää omat optiomääritykset [2]. Tilanteen mukaan eri optiomääritykset voidaan ylikirjoittaa, jos ne muuttuvat alemmilla hierarkian tasolla. Ylikirjoituksen mahdollisuus voidaan

13 10 kuitenkin estää määrittämällä optio lukituksi. Staattisen hierarkian tasot ylimmästä alimpaan ovat: AxisConfiguration, AxisServiceGroup, AxisService, AxisOperation ja AxisMessage. AxisConfiguration taso on staattisen hierarkian ylin taso ja sen sisältö koostuu kaikkien kolmen konfiguraatiotiedoston sisältämistä optiomäärityksistä, joihin kuuluvat: käyttöönottokonfiguraatiodatan määritykset, kuljetuksen lähettäjien ja vastaanottajien määritykset, toteutusketjun ja vaiheiden määritykset, viestien muotoilijoiden ja rakentajien määritykset sekä muut parametrimääritykset. Korkeimman tason hierarkian alemmat tasot tunnetaan myös palveluiden kuvaushierarkioina ja ne on määritetty services.xml ja module.xml konfiguraatiotiedostoissa. Kukin hierarkian taso voi määrittää optioita, jotka kuuluvat sen ylemmän tason hierarkiaan, joiden lisäksi kullakin tasolla on omia optiomahdollisuuksia. AxisServiceGroup tasolla voidaan määrittää optioita, jotka pätevät kaikiin palveluihin, kun taas AxisService on palvelukohtainen taso, jossa voidaan määrittää optioita yksittäisille palveluille. AxisOperation tasolla voidaan määrittää palvelut ja niiden sisältämät operaatiot. AxisMessage taso on vaihtoehtoinen ja sillä voidaan määrittää kullekin palvelulle omat viestinvälitykset yksityiskohtaisesti Kontekstidata Kontekstidatan hierarkia tarkoittaa ajonaikaista dataa, joka on käytössä vain, kun viesti vastaanotetaan ja käsitellään. Kontekstihierarkian tasot ylimmästä alimpaan ovat [2]: ConfigurationContext, ServiceGroupContext, ServiceContext, OperationContext ja MessageContext. Kontekstidataa käytetään jakamaan samaa dataa monien eri invokaatioiden ja käsittelijöiden kesken ja se tallennetaan valitulle kontekstihierarkian tasolle käyttäen nimi-arvo pareja. Tällöin kukin hierarkian alempi taso voi käyttää tai ylikirjoittaa valitun datan omalla tasollaan. ConfigurationContext on kontekstihierarkian ylin taso ja se eroaa merkittävästi alemmista hierarkian tasoista siinä, että se on aina olemassa ja käytössä järjestelmän ollessa käynnissä. Täten myös tälle tasolle tallennetut arvot ovat aina olemassa ja käytettävissä järjestelmän ollessa päällä. Alemmat hierarkian tasot luodaan ja

14 11 tallennetaan tarvittaessa, kun viestejä vastaanotetaan järjestelmään, ja niiden eliniät vaihtelevat käytön mukaan. Jokaisella kontekstihierarkian tasolla voi olla yksi tai useampi alemman hierarkiatason ilmentymä ja kukin kontekstihierarkian taso on luonnollisesti myös riippuvainen sitä ylempien tasojen hierarkioiden olemassaolosta sekä yhdestä staattisen hierarkian tasosta, kuten kuvassa 4 on esitetty. Kuva 4. Hierarkioiden suhteet. [2] 4 WEBPALVELUKEHYKSEN KÄYTTÖÖNOTTO Jayasinghen [2] mukaan käyttäjäystävällisyys on ollut yksi tärkeimmistä prioriteeteista Axis2:n suunnittelussa. Tämän johdosta Axis2:n käyttöönotto ja päivittäminen on tehty mahdollisimman helpoksi ja vaivattomaksi jopa tavallisille käyttäjille. Merkittävämpiä uudistuksia aikaisempaan Axis webpalvelukehykseen on muun muassa J2EE-tapainen palveluiden käyttöönottomekanismi sekä joustavat päivitysmahdollisuudet. Yleisellä tasolla Java-luokkien toteuttaminen Axis2-järjestelmää varten vaatii Java-virtuaalikoneen version 1.4 tai uudemman [1]. Tässä luvussa tutustutaan Axis2:n käyttöönottoon sekä sen palveluiden, moduulien ja palveluntilaajan toteuttamiseen käytännön tasolla.

15 Axis2-palvelimen asentaminen Axis2-palvelun voidaan asentaa käyttökuntoon useilla eri tavoilla [1]. Tässä tutkielmassa tutustutaan kuitenkin vain kahteen tapaan, jossa ensimmäisessä Axis2 palveluja käytetään toisen sovelluspalvelimen sisällä web-arkistosovelluksena (.war) ja toisessa tavassa Axis2- webpalveluita käytetään itsenäisesti (Standalone). Ensimmäisessä tavassa käytettävä sovelluspalvelu on Apache Software Foundationin julkaisema Apache Tomcat (versio ) oletusasetuksilla. Käytettävä Axis2:n versio on 1.4.1, jonka voi ladata Apache Software Foundationin Axis2-kotisivuilta Axis2 web-arkistosovelluksena Kun Axis2:a haluaa käyttää toisen sovelluspalvelimen sisällä tulee siitä ladata binääriversio, jonka pohjalta tulee muodostaa web-arkistosovellustiedosto (.war) [1]. Vaihtoehtoisesti Axis2-kotisivuilta voi ladata valmiin Axis2 web-arkistosovellusversion (axis2.war) [1]. Axis2:n web-arkistosovellustiedosto tulee siirtää Apache Tomcatin kotihakemiston /webapps kansioon ja Tomcat-palvelin tulee käynnistää uudelleen [2]. Tämän jälkeen Axis2:n toimivuus voidaan testata kirjoittamalla web-selaimeen osoite [2]. Sivun avautuminen onnistuneesti tarkoittaa sitä, että Axis2-palvelin on asennettu onnistuneesti toimimaan Tomcat-soveluspalvelimen sisällä [2]. Kun tutkielmassa jatkossa mainitaan Axis2:n kotihakemisto, sillä tarkoitetaan Apache Tomcat hakemistossa sijaitsevaa osoitetta: /webapps/axis2/web-inf/ Axis2 itsenäisenä sovelluksena Kun Axis2:a haluaa käyttää itsenäisenä palvelimena tulee siitä ladata binääriversio ja käyttöjärjestelmässä tulee olla asennettuna Java-virtuaalikone (versio 1.4 tai uudempi) [1]. Ladattu paketti tulee purkaa haluttuun sijaintiin, jonka jälkeen Axis2:n käyttämää sisääntuloporttia voi muuttaa muokkaamalla Axis2:n globaaliakonfiguraatiotiedostoa axis2.xml, joka sijaitsee puretussa hakemistossa /conf kansiossa. Sisääntuloportti voidaan määritettää <parameter name="port"> tagissa yhden <transportreceiver> tagin sisällä. Oletusarvoisesti Axis2.xml sisältää alla esitetyn sisääntulokonfiguraation porttiin 8080 [2]:

16 13 <transportreceiver name="http" class="org.apache.axis2.transport.http.simplehttpserver"> <parameter name="port">8080</parameter> </transportreceiver> Kun haluttu sisääntuloportti on määritetty, voidaan Axis2-palvelin käynnistää ajamalla Axis2- hakemiston /bin kansiossa oleva axis2server.bat tiedosto, jos käytetään Windowskäyttöjärjestelmää [1]. Vaihtoehtoisesti Linux- tai Unix-pohjaisessa käyttöjärjestelmässä tulee ajaa axis2server.sh tiedosto [1]. Tämän jälkeen Axis2:n toimivuus voidaan testata kirjoittamalla web-selaimeen osoite jossa portin 8080 sijaan tulee kirjoittaa käytettävä porttinumero. Sivun avautuminen onnistuneesti tarkoittaa sitä, että Axis2-palvelin on onnistuneesti käynnissä itsenäisesti [1]. Itsenäisesti ajettuna Axis2:n kotihakemisto on hakemisto, jonne ladattu Axis2-paketti purettiin. Ainut eroavaisuus on se, että /services ja /modules kansiot sijaitsevat kotihakemiston /repository kansion sisällä. 4.2 Palveluiden käyttöönotto Axis2 tarjoaa useita eri menetelmiä webpalveluiden käyttöönottamiseksi [2]. Tässä kohdassa tarkastellaan kuitenkin vain yhtä menetelmää, joka on ollut Axis2:n alkuperäinen tapa suorittaa käyttöönotot, niin kutsuttu arkisto-pohjainen menetelmä J2EE-tapainen palveluiden käyttöönotto Axis2:ssa jokainen palvelu ja moduuli on yksinkertainen paketti, joka sisältää kaiken tarvittavan toiminnallisuuden kannalta. Kukin paketti sisältää yhden palvelun tai moduulin kaikki resurssit sekä konfiguraatio- että binääritiedostot, jolloin se on helposti siirrettävissä ja käyttöönotettavissa. Paketit ovat kuin arkistotiedostoja joiden loppupääte on.aar palveluilla ja.mar moduuleilla. Kukin.aar tai.mar paketti tulee sisältää vähintään META-INF kansio, jonka sisällä on sen kuvaustiedosto joko services.xml (jos kyseessä on palvelu) tai module.xml (jos kyseessä on moduuli). Kyseiset palvelu- tai moduulipaketit voidaan luoda helposti käärimällä kaikki sen sisältämät tiedostot ja resurssit Javan arkistopaketiksi (.jar) ja muuttamalla arkistotiedoston loppu.aar tai.mar päätteiseksi. Kuvassa 5 on esimerkki sekä palvelu- että moduulipaketin sisällöstä. [2]

17 14 Palveluesimerkki.aar lib lib1.jar lib2.jar META-INF services.xml java esimpalveluluokka palvelu.class Moduuliesimerkki.mar lib lib3.jar lib4.jar META-INF module.xml java esimmoduuliluokka moduuli.class Kuva 5. Esimerkkipakettien sisältö Joustavat päivitysmahdollisuudet Palveluiden saatavuus on merkittävä asia liikeyritystason sovelluksissa, jonka johdosta palvelimien ja palveluiden päivittäminen tulisi tapahtua häiritsemättä niiden käyttäjiä. Tämä tarkoittaa sitä, että päivitykset tulee pystyä tekemään järjestelmään sen ollessa päällä. Axis2:ssa tämä on mahdollista sen Hot Deployment ja Hot Update ominaisuuksien johdosta. Hot Deployment tarkoittaa ominaisuutta, jonka avulla uusia palveluita voidaan lisätä järjestelmään käytettäväksi järjestelmän ollessa käynnissä. Hot Update tarkoittaa ominaisuutta, jonka avulla käynnissäolevaan webpalveluun voidaan tehdä muutoksia. Hot Update on kuitenkin ominaisuus, jota tulisi käyttää vain järjestelmän kehitys- ja testausympäristössä, sillä se voi viedä järjestelmän epävakaaseen tilaan. Tarvittaessa joustavat päivitysmahdollisuudet voidaan ottaa pois käytöstä, jos niitä ei tarvita järjetelmässä. Tämä tapahtuu muokkaamalla globaaliin konfiguraatiotiedostoon (axis2.xml) seuraavat rivit vastaavanlaisiksi [2]: <parameter name= hotdeployment >false</parameter> <parameter name= hotupdate >false</parameter> Vastaavasti, jos joustavat päivitysmahdollisuudet halutaan ottaa käyttöön, niiden arvoiksi tulee asettaa true. Oletuksena Hot Deployment on true ja Hot Update false Palveluiden sijoitusvarasto Axis2:ssa palveluiden sijoitusvarasto on tavallinen tiedostohakemisto, joka sijaitsee Axis2:n kotihakemistossa ja jolla on ennalta määrätty rakenne, kuten kuvassa 6 on esitetty. Tämän tyyppinen ratkaisu webpalvelun toiminnallisuuksien sijoitusvarastolle on joustava, sillä siihen

18 15 pääsee käsiksi joko paikalliselta koneelta tai etäkäytön kautta. Hakemistossa on /modules ja /services kansiot, joihin palveluiden ja moduulien arkistopaketit tulee sijoittaa. Hakemiston ylimpänä olevaan /lib kansioon voidaan sijoittaa kolmannen osapuolen tarjoamat kirjastot jar-paketeissa, jolloin ne jaetaan käytettäväksi kaikille palveluille ja moduuleille. Tämän lisäksi /modules ja /services kansiot sisältävät omat /lib kansiot, joiden tarkoitus on jakaa kolmannenosapuolen tarjoamat kirjatot käytettäviksi vain palveluille tai moduuleille. Axis2 web-arkistosovelluksena lib lib1.jar lib22.jar Axis2 itsenäisesti ajettuna lib lib1.jar lib2.jar modules lib modlib1.jar modlib2.jar module1.mar module2.mar services lib servlib1.jar servlib2.jar palvelu1.aar palvelu2.aar Kuva 6. Palveluiden hakemistorakenne repository modules lib modlib1.jar modlib2.jar module1.mar module2.mar services lib servlib1.jar servlib2.jar palvelu1.aar palvelu2.aar 4.3 Palveluiden kirjoittaminen Axis2:ssa palvelut ovat tavallisia Java-luokkia, joita pystytään kutsumaan ja käyttämään verkon ylitse [2]. Liitteesä 3 on esimerkki hyvin yksinkertaisesta Java-luokasta, joka tässä kohdassa muutetaan webpalvelun tarjoavaksi palveluksi Palvelujen kuvaustiedostot Tärkeä osa palvelun perustamista on kirjoittaa palvelulle kuvaustiedosto, jonka nimeksi tulee antaa services.xml [2]. Kuvaustiedostojen tarkoitus on kuvata palvelut ja niiden vaatimat konfiguraatiot, kuten muun muassa viestinvälitysmenetelmät. Liitteessä 4 on esimerkki kuvaustiedostota liitteen 3 luokaa varten. Liitteen 4 kuvaustiedostossa palvelu nimetään nimellä HelloService ja sille annetaan kuvaus <Description> tagissa. Pavelussa käytettävä Java-luokan toteutus voidaan määritellä <parameter name= ServiceClass > tagissa

19 16 antamalla arvoksi Java-luokan nimi. Jos luokalla olisi pakettinimi, se tulisi kirjoittaa kokonaisuudessaan luokan nimen mukaan. Palvelun sisältämät metodit ja niiden käyttämät viestinvälitysmenetelmä voidaan määrittää <operation> tageissa, ja kunkin <operation> tagin nimeksi tulee antaa määritettävän metodin nimi. Viestinvälitysmenetelmä voidaan määritellä <operation> tagin sisään tulevassa <messagereceiver> tagissa, jolle tulee antaa class attribuutti, jonka arvo on toteutetun viestinvälitysmenetelmäluokan nimi. Liiteen 4 esimerkissä käytettävä viestinvälitys on RPC-menetelmä, joka on toteutettu Axis2:n mukana tulleessa luokassa org.apache.axis2.rpc.receivers.rpcmessagereceiver Palvelun arkistotiedoston luominen Kun luokka ja kuvaustiedosto on toteutettu, tulee niistä luoda halutun niminen arkistopaketti, jonka loppupääte on.aar [2]. Tämä onnistuu esimerkiksi tekemällä luokasta ja kuvaustiedostosta tavallisen.jar arkistotiedoston ja korjaamalla sen loppupäätteen.aar loppupäätteellä. Palvelun arkistotiedosto tulee sisältää tietty hakemistorakenne, josta on esimerkki kuvassa 5. Tässä esimerkkitapauksessa arkistotiedosto on nimetty nimellä HelloWorld.aar ja sen hakemistorakenne on seuraavanlainen kuvan 7 mukainen. HelloWorld.aar META-INF services.xml src HelloWorld.class Kuva 7. Esimerkkipalvelun hakemistorakenne Kun arkistotiedosto on luotu, se voidaan siirtää Axis2-kotihakemistossa sijaitsevaan kansioon /services. Jos Axis2:n Hot Deployment ominaisuus on päällä, niin uusi palvelu on heti käyttövalmis ja se ilmestyy palvelulistaan, jonka voi nähdä kirjoittamalla selaimeen osoitteen Muussa tapauksessa uusi palvelu on käytettävissä vasta, kun webpalvelu on käynnistetty uudelleen Palvelun käyttäminen Kun uusi palvelu on käyttökunnossa, voidaan sen toimivuus testata selaimella kirjoittamalla palvelun osoite [2]. Vastauksena selain näyttää palvelun takaisinlähettämän SOAP-viestin [2]. Esimerkissä palvelun toimivuus voidaan testata kirjoittamalla seuraava osoite:

20 17 jossa palvelun saama parametri name voidaan määrittää kohdassa?name= ja sen arvoksi voi asettaa halutun merkkijonon. Ylläolevalla testillä saamme selaimeen näkyviin seuraavan SOAP-vastausviestin: <ns:sayhelloresponse> <ns:return>hello Akseli</ns:return> </ns:sayhelloresponse> 4.4 Moduulien kirjoittaminen Moduulien tarkoitus on mahdollistaa Axis2-webpalveluiden laajennettavuus ja tehostaa palveluiden laatua. Kohdassa 3.3 esiteltiin Axis2:n toteutusketju ja sen toiminta käsittelijöiden kautta. Moduulit ovat toteutukseltaan irrallisia käsittelijöitä, jotka voidaan liittää toteusketjuun. Täten moduulit voivat olla webpalveluspesifikaation määrittelemien lisäominaisuuksien toteutuksia ja niiden kautta voidaan mahdollistaa esimerkiksi viestinnän transaktiotoiminnallisuus tai lisätä viestinnän turvallisuutta ja luotettavuuden [2]. Tässä luvussa perehdytään moduulien toteutukseen käytännön tasolla. Esimerkkimoduulina on toteutettu toiminnallisuus, joka laskee lähtevien ja tulevien viestien lukumäärän käytettävässä webpalvelussa Käsittelijäluokan toteuttaminen Kukin käsittelijä tulee toteuttaa omana luokkanaan. Käsittelijäluokan tulee joko laajentaa Axis2:n tarjoama org.apache.axis2.handlers.abstracthandler abstraktiluokka tai toteuttaa Axis2:n sisältämä rajapinta org.apache.axis2.engine.handler [2]. Liitteissä 5 ja 6 on toteutettu esimerkkikäsittelijäluokat, jotka laskevat kulkevien viestien lukumäärää. IncomingCounterHandler luokka laskee vastaanotettujen viestien lukumäärää, kun taas OutgoingCounterHandler luokka laskee lähtettyjen viestien lukumäärää. Molemmat esimerkkiluokat laajentavat AbstractHandler abstraktiluokkaa, jolloin ainut metodi, joka tarvitsee pakollisesti toteuttaa, on invoke(). Molemmat luokat toteuttavat myös Axis2:n CounterConstants rajapinnan, joka sisältää ainoastaan merkkijonovakiot kuvaamaan tarpeellisia laskurinimikeitä ja etuliitteitä. CounterConstants rajapinta on esitetty liitteessä 9. Liitteiden 5 ja 6 luokkien invoke() metodi saa paramerina MessageContext olion, joka

21 18 sisältää palvelun tilatietoja. Kyseistä MessageContext oliota käyttäen järjestelmä voi saada palvelun konfiguraatiotiedot ja ominaisuudet. Esimerkkiluokissa saaduista konfiguraatiotiedoista haetaan sen nykyinen viestien lukumäärä, käyttäen CounterConstants rajapinnan vakiomuuttjia, joko lähetetyistä (OUTGOING_MESSAGE_COUNT_KEY) tai vastaanotetuista (INCOMING_MESSAGE_COUNT_KEY) viesteistä. Saatu arvo kasvatetaan yhdellä ja se asetetaan joko lähtevien tai vastaanotettujen viestien lukumääräksi palvelun konfiguraatiotietoihin. Käsittelijäluokan invoke()metodin tulee myös ratkaista onko vastaanotettu viesti kelvollinen ja voidaanko se antaa eteenpäin seuraavalle toteutusketjun jäsenelle. Ratkaisu voidaan antaa eteenpäin InvocationResponse palautusarvona, jonka arvo voi olla joko InvocationResponse.CONTINUE, jos toteutusketju voi jatkaa normaalisti, InvocationResponse.SUSPEND, jos toteutusketju tulee pysäyttää tilapäisesti ja odottaa kunnes jokin tilanne muuttuu, tai InvocationResponse.ABORT, jos toteutusketju tulee keskeyttää kokonaan. Koska esimerkkikäsittelijät laskevat kaikkien mahdollisen viestien lukumäärää, eikä niiden logiikassa voi tulle virheellisiä viestejä, ne palauttavat aina InvocationResponse.CONTINUE arvon Moduulien kuvaustiedostot Kuten jokaisella palvelulla, myös jokaisella moduulilla tulee olla kuvaustiedosto. Moduulin kuvaustiedoston nimeksi tulee antaa module.xml ja sen tarkoitus on kuvata moduulin sisäänja ulostuloskäsittelijät sekä niiden sijainti toteutusketjussa vaihesääntöjä käyttäen [2]. Liitteessä 7 on esimerkkikuvaustiedosto liitteiden 5 ja 6 käsittelijäluokkia varten. Liitteen 7 kuvaustiedossa moduuli nimetään nimellä countermodule ja sille annetaan kuvaus <Description> tagissa. Esimerkkikuvaustiedostossa on määritetty vain InFlow ja OutFlow putket sisään- ja ulostuloja varten, joissa kummassakin on oma käsittelijä määritetty <handler> tagin sisällä. Käsittelijätagille voidaan antaa attribuuteiksi name ja class, joista class:in arvoksi tulee asettaa käytettävän käsittelijäluokan nimi pakettinimen kanssa. Käsittelijätagin sisällä voidaan myös määrittää käsittelijän sijainti toteutusketjussa <order> tagin sisään antamalla sille attribuutti phase, jonka arvoksi tulee antaa haluttu vaihe toteutusketjussa. Attribuutin phase lisäksi <order> tagi voi sisältää vaihesäännöt attribuutteina after ja before.

22 Moduulin arkistotiedoston luominen ja käyttöönotto Toteutetuista käsittelijäluokista ja kuvaustiedostosta tulee luoda halutun niminen arkistopaketti, jonka loppupääte on.mar [2]. Tämä onnistuu samalla tavalla kuin palveluiden arkistotiedostojen luominen. Moduulin arkistotiedosto tulee sisältää samankaltainen hakemistorakenne, kuten palveluilla, josta on esimerkki kuvassa 5. Esimerkkitapauksessa arkistotiedosto on nimetty nimellä CounterModule.mar ja sen hakemistorakenne olisi seuraavanlainen kuvan 8 mukainen. CounterModule.mar META-INF module.xml org apache axis2 sample module request CounterConstants.class IncomingCounterHandler.class OutgoingCounterHandler.class Kuva 8. Esimerkkimoduulin hakemistorakenne Kun moduulin arkistotiedosto on luotu, se voidaan siirtää Axis2-kotihakemistossa sijaitsevaan /modules kansioon. Jos Axis2:n Hot Update-ominaisuus on poissa päältä, moduuli on saatavilla vasta, kun palvelu on käynnistetty uudelleen. Kun moduuli on saatavilla, voidaan se liittää mukaan haluttuihin webpalvelun osiin kirjoittamalla selaimeen seuraava osoite: ja kirjautua järjestelmänvastaavana sisään. Oletusasetuksina Axis2:n järjestelmänvastaavan käyttäjänimi on admin ja salasana on axis2. Available Modules-linkin kautta voi katsoa, onko moduuli saatavilla, jolloin ilmestyvässä listassa tulisi näkyä esimerkkitapauksen moduuli kuvauksineen. Moduulin voi liittää webpalveluun valitsemalla jonkin Engage Module-otsikon alla olevista linkeistä ja painamalla engage-painiketta halutun moduulin kohdalla. Kun esimerkkitapauksen moduuli on liitetty webpalveluun sen toimivuus voidaan testata kutsumalla jotain olemassaolevaa palvelua, jolloin palvelinkonsoliin ilmestyy moduulin sisältämä tuloste, jossa on lähtettyjen ja vastaanotettujen viestien lukumäärät.

23 Moduulin toteutusluokka Tavallisesti käsittelijäluokan toteutukset ovat yksinkertaisia palveluja, jossa ei tarvitse välittää ulkopuolisista alkuasetuksista, kuten tietokantayhteyden muodostamisesta, asetustiedoston lukemisesta tai säikeiden perustamisesta. Liikeyritystason webpalveluilla nämä toimenpiteet ovat kuitenkin yleisiä, jolloin ne tulee pystyä toteuttamaan webpalvelun käynnistymisen aikana ja sulkemaan webpalvelun sulkeuduttua. Tätä varten ohjelmoija voi toteuttaa moduulin toteutusluokan [2]. Moduulin toteutusluokka on vaihtoehtoinen ja se kannattaa toteuttaa vain, jos webpalvelun tarvitsee suorittaa jonkinoloinen toimenpide palvelun käynnistyessä ja sulkeutuessa. Moduulin toteutusluokka on tavallinen Java-luokka, jonka tulee toteuttaa Axis2:n Module rajapinta. Module rajapinnan toteutettavat metodit ovat init(), shutdown() ja engagenotify(), joista init() metodia kutsutaan, kun webpalvelu käynnistyy, metodia shutdown() kutsutaan webpalvelun sulkeuduttua ja engagenotify() metodia kutsutaan, kun kyseessä oleva moduuli liitetään järjestelmään. Liitteessä 9 on esimerkki moduulin toteutusluokasta, joka on liitteiden 5 ja 6 moduuleja varten. Kun moduulin toteutusluokka otetaan käyttöön, tulee moduulin kuvaustiedoston <module> tagiin liittää class attribuutti, jonka arvoksi tulee antaa käytettävä moduulin toteutusluokka pakettinimen kanssa, ja moduulin toteutusluokan käännetty.class tiedosto tulee liittää mukaan moduulin arkistotiedostoon. Liitteen 9 esimerkkitapauksessa liitteen 7 moduulin kuvaustiedoston ensimmäinen rivi tulee korvata seuraavalla rivillä: <module name="countermodule" class="org.apache.axis2.sample.module.request.countermodule"> 4.5 Asiakas-ohjelmointirajapinnan käyttö Axis2-webpalvelukehys ei sisällä erillisiä toteutuksia palvelu- ja asiakastarpeisiin, vaan webpalvelukehystä ja sen toteutusketjua voidaan käyttää palveluiden käyttöönoton lisäksi myös palveluiden kutsumiseen asiakaan puolelta. Tämän toiminnallisuuden toteuttaa asiakasohjelmointirajapintamoduuli, jota voidaan käyttää kutsumaan palveluita joko synkronisesti tai asykronisesti. [2]

24 Odottava ja ei-odottava kutsu Webpalvelut käyttävät kahta eri menetelmää viestinnässä, joista toinen on odottava eli synkroninen malli ja toinen on ei-odottava eli asykroninen malli. Synkronisessa mallissa asiakaspuoli kutsuu palvelua ja jää odottamaan vastausta estäen kaiken muun liikenteen ja toiminnallisuuden, kunnes saa vastauksen palvelulta. Asynkronisessa mallissa asiakaspuoli voi tehdä useamman palvelukutsun eikä se estä käyttäjää jatkamasta työskentelyä tai tekemästä uusia palvelupyyntöjä. [2] Asiakaspuolen toteuttaminen Axis2 tarjoaa kaksi tapaa toteuttaa asiakaspuoli, joista yksinkertaisempi tapa on käyttää ServiceClient luokkaa, joka mahdollistaa yksinkertaisten SOAP-viestinnän [2]. Toinen tapa toteuttaa asiakaspuoli on käyttää OperationClient luokkaa, joka mahdollistaa monipuolisemman SOAP-viestinnän tarjoamalla pääsyn viestien otsikkotietoihin. Tämä malli on erityisesti liikeyritystason webpalvelutoteutuksia varten ja sen toteuttaminen vaatii yksinkertaisempaan malliin verrattuna moninkertaisen työmäärän eikä sen toteutusta tulla esittämään tässä tutkielmassa. ServiceClient ilmentymä tarkoittaa samaa asiaa kuin webpalvelun asiakasilmentymä ja se voidaan luoda kolmella eri tavalla [2]: oletusarvoisesti, kustomoidusti tai dynaamisesti. Oletusarvoisesti asiakasilmentymä luodaan käyttäen ServiceClient luokan konstruktoria, joka ei saa lainkaan parametreja, jolloin asiakasilmentymä luodaan käyttäen Axis2:n oletuskonfiguraatioita: ServiceClient serviceclient = new ServiceClient(); Asiakasilmentymän luominen kustomoidusti vaatii, että käytettävissä on oma kustomoitu konfiguraatiodata. Konstruktorille annettavat parametrit sisältävät kyseiset konfiguraatiotiedot, joiden mukaan asiakasilmentymä pystytään rakentamaan. Parametrit voidaan jättä tarvittaessa tyhjiksi (null), jolloin ne määritellään käyttäen oletusasetuksia: ServiceClient serviceclient = new ServiceClient( configcontext, axisservice);

25 22 Asiakasilmentymä voidaan luoda myös dynaamisesti eli lennossa. Tällöin asiakasilmentymä konfiguroidaan käyttäen ajonaikaista WSDL:ää. Dynaamisesti luodun asiakasilmentymän parametreista configcontext voidaan jättää tyhjäksi (null), jolloin se määritellään kuin kustomoidussa mallissa. Parametria wsdlurl ei saa jättä tyhjäksi ja sen arvoksi tulee asettaa URL-osoite WSDL:ään. Parametrina wsdlservicename voidaan antaa tietty palveluelementti sen QNamen perusteella. Jos parametri jätetään tyhjäksi (null), niin se käyttää oletusarvoisesti palveluelementtilistan ensimmäistä jäsentä. Parametria portname voidaan käyttää määrittämään tietty käytettävä webpalvelun portti. Jos parametri jätetään tyhjäksi, niin sen arvoksi tulee palvelun porttilistan ensimmäinen jäsen: ServiceClient dynamicclient = new ServiceClient( configcontext, wsdlurl, wsdlservicename, portname); Esimerkkejä ServiceClient-toteutuksesta Seuraavaksi on esitetty kaksi ServiceClient toteutusta, joista ensimmäinen on synkroninen (SyncWSClient.java) ja toinen asynkroninen (AsyncWSClient.java) toteutus. Esimerkkikoodit ovat liitteissä 10 ja 11. Kutsuttava palvelu on kohdassa 4.3 toteuttettu esimerkkipalvelu HelloService. Molemmat toteutukset sisältävät samanlaisen metodin createpayload(), joka luo lähetettävän SOAP-viestin käyttäen AXIOM-oliomallia [2]. Koska molemmissa toteutuksissa ServiceClient ilmentymä luodaan käyttäen oletuskonstruktoria, tulee sitä varten luoda metadataolio käyttäen Options luokkaa kuten allaolevassa esimerkissä on esitetty. Metadataolio sisältää tiedon muun muassa webpalvelun päätepisteestä, jonne asiakasilmentymä ottaa yhteyden, sekä käytettävän palvelun kutsun [2]. ServiceClient sc = new ServiceClient(); Options opts = new Options(); opts.setto(new EndpointReference( " opts.setaction("urn:sayhello"); sc.setoptions(opts); Synkronisessa toteutuksessa SOAP-viestin lähetys tapahtuu kutsumalla sendreceive() metodia, kuten alla on esitetty. Kun vieti on lähetetty, jää järjestelmä odottamaan vastausta estäen muun toiminnan, kunnes se saa vastauksen. sc.sendreceive(createpayload())

26 23 Asynkronisessa toteutuksessa ennen viestinlähetystä ohjelmoijan on tullut toteuttaa joko takaisinkutsu (callback) tai yhdistämismenetelmä (pooling) mahdollistaakseen asynkronisen viestintämallin [2]. Esimerkikoodissa on toteutettu AxisCallback, jonka luotu olio annetaan parametreina viestinvälitysmetodiin. Asynkronisessa toteuteuksessa SOAP-viesti lähetetään kutsumalla sendreceivenonblocking() metodia. Esimerkkikoodi sisältää myös aikakatkaisutoteutuksen, jolla voidaan rajoittaa viestinkuuntelun kestoa. Kun aikakatkaisu tapahtuu, heitetään AxisFault poikkeus. sc.sendreceivenonblocking(createpayload(), callback); Kun ajamme kumman tahansa asiakastoteutuksista saamme pienen odotuksen jälkeen alla esitetyn SOAP-viestin vastauksena. Tällöin asiakaspääty on onnistuneesti saanut yhteyden webpalveluun ja webpalvelu on onnistuneesti lähettänyt vastauksen palveluntilaajalle. <ns:sayhelloresponsexmlns:ns=" <ns:return>hello Matti Mainio</ns:return> </ns:sayhelloresponse> 5 YHTEENVETO Axis2 tarjoaa joustavan ja modulaarisen webpalvelukehyksen, joka on sekä aloittelijaystävällinen että soveltuva myös liikeyritystason webpalveluiden toteuttamiseen. Axis2:n vahvuudet perustuvat sen käyttäjäystävällisyyteen sekä monipuolisten toteutustapojen mahdollistamiseen. Kaiken lisäksi Axis2-webpalvelukehys on ilmainen, jonka johdosta siihen on helppo tutustua. Kuitenkin laadukaan liikeyritystason webpalvelun perustaminen käyttäen Axis2:ta vaatii todella paljon työtä ja ymmärtämistä. Toinen heikkous on se, ettei Apache Software Foundation ole vielä toteuttanut kaikkia mahdollisia ilmestyneitä WS-* standardeja Axis2-webpalveluiden käytettäväksi, jolloin osa webpalveluiden laatujärjestelmästä jää webpalvelun perustajien toteutettavaksi. Parhaiten Axis2 soveltuu käytännön opetusmateriaaliksi johdattamaan aloittelevat webohjelmoijat webpalveluiden maailmaan tai ensimmäiseksi pienen aloittelevan yrityksen kaupalliseksi tai ei-kaupalliseksi webpalvelutoteutukseksi. Kokonaisuudessaan Axis2- webpalvelukehys on kuitenkin laadukas ohjelmointikehys ja siitä on tullut merkittävä

27 24 webpalveluiden ohjelmointikehys maailmanlaajuisesti, mutta sen ilmainen jakelu on myös sen heikkous suurempien ohjelmistoyrityksien horisontissa. VIITTEET [1] Apache Software Foundation (2008) Apache Axis2: Next Generation Web Services. WWW sivusto, ( ) [2] Jayasinghe, D. (2008) Quickstart Apache Axis2: A practical guide to creating quality web services. Packt Publishing Ltd, Birmingham. [3] The World Wide Web Consortium (2007) SOAP version 1.2 Part 1: Messasing Framework (Second Edition). WWW sivusto, ( ) [4] The World Wide Web Consortium (2001) Web Service Description Language (WSDL) 1.0. WWW sivusto, ( ) [5] The World Wide Web Consortium (2006) Web Service Addressing 1.0 Core. WWW sivusto, ( )

28 25 LIITE 1: Esimerkki WSDL-tiedostosta. <wsdl:definitions targetnamespace=" <wsdl:documentation>helloservice</wsdl:documentation> <wsdl:types> <xs:schema attributeformdefault="qualified" elementformdefault="qualified" targetnamespace=" <xs:element name="sayhello"> <xs:complextype> <xs:sequence> <xs:element minoccurs="0" name="name" nillable="true" type="xs:string" /> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="sayhelloresponse"> <xs:complextype> <xs:sequence> <xs:element minoccurs="0" name="return" nillable="true" type="xs:string" /> </xs:sequence> </xs:complextype> </xs:element> </xs:schema> </wsdl:types> <wsdl:message name="sayhellorequest"> <wsdl:part name="parameters" element="ns:sayhello" /> </wsdl:message> <wsdl:message name="sayhelloresponse"> <wsdl:part name="parameters" element="ns:sayhelloresponse" /> </wsdl:message> <wsdl:porttype name="helloserviceporttype"> <wsdl:operation name="sayhello"> <wsdl:input message="ns:sayhellorequest" wsaw:action="urn:sayhello" /> <wsdl:output message="ns:sayhelloresponse" wsaw:action="urn:sayhelloresponse" /> </wsdl:operation> </wsdl:porttype> <wsdl:binding name="helloservicesoap11binding" type="ns:helloserviceporttype"> <soap:binding transport=" style="document" /> <wsdl:operation name="sayhello"> <soap:operation soapaction="urn:sayhello" style="document" /> <wsdl:input> <soap:body use="literal" /> </wsdl:input> <wsdl:output> <soap:body use="literal" /> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:binding name="helloservicesoap12binding" type="ns:helloserviceporttype"> <soap12:binding transport=" style="document" /> <wsdl:operation name="sayhello"> <soap12:operation soapaction="urn:sayhello" style="document" /> <wsdl:input> <soap12:body use="literal" /> </wsdl:input> <wsdl:output> <soap12:body use="literal" /> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:binding name="helloservicehttpbinding" type="ns:helloserviceporttype"> < verb="post" /> <wsdl:operation name="sayhello"> < location="helloservice/sayhello" /> <wsdl:input> <mime:content type="text/xml" part="sayhello" />