Web service interoperability (WS-I)

Web service interoperability (WS-I) 96

Web service interoperability organization (WS-I) Founded 2.6.2002 See: www.ws-i.org Assists in creating and deploying interoperable Web services Interoperability problems with Web services multiple resources to support implementations of Web services vendor platforms many specifications and their many versions specifications can and are extended and interpreted for various purposes no single interpretation of the term Web service 97 WS-I organisaatio on lyhyessä ajassa saanut paljon jäseniä ja yhteistyökumppaneita. WS-I perustettiin 2002, mutta suurimmat Web-palvelujen toteuttamista tukevien työkalujen ja standardien tarjoajat ovat jo nyt mukana. Web-palvelujen toteuttamiseen käytettäviä standardeja kehitetään samanaikaisesti eri organisaatioissa, kuten W3C, OASIS, OAG (Open Applications Group) jne. WS-I pyrkii toimimaan näiden standardien integroijana ja antamaan ohjeistusta standardien käytöstä. Web-palveluiden käytössä esiintyy yhteentoimivuuusongelmia monista eri syistä. Yksi perussyy on se, että Web-palvelustandardit sisältävät paljon optionaalisia elementtejä ja ne ovat osin laajennettavia. Tämä mahdollistaa näiden standardien tulkinnan eri tavoin. Näin on tehtykin eri Webpalvelutyökaluissa. Ongelma on hieman vastaavanlainen mutta ei kuitenkaan yhtä huomattava kuin XMI:n kohdalla. Toisaalta myös termin Web-palvelu erilaiset tulkinnat aiheuttavat luonnollisesti ongelmia.

WS-I goals Encourage adaption provide a forum for end users to communicate requirements raise awareness of the standards Accelerate deployment and achieve/improve interoperability integrate specifications provide guidelines and recommendations for using the standards e.g., Basic Profile 1.0 (August 2003), Basic Profile 1.1 (August 2004) and Basic Profile 1.2 (Working Group Approval Draft, October March 2007) deliver testing tools and sample applications provide a collaboration forum for developers 98 WS-I:n tavoite on tarjota tukea sekä työkalujen että Web-palvelujen tuottajille: työkalujen tuottajat saavat tietoa asiakkaiden (Web-palvelujen tuottajat) yhteentoimivuusvaatimuksista ja ongelmista, ja palvelujen tuottajille taas tarjotaan työkaluja ja ohjeistusta (esim. best practices ) palvelujen toteuttamiseksi. Lisäksi WS-I pyrkii kannustamaan ja rohkaisemaan Web-palvelukonseptin ja standardien käyttöönottoa. Ohjeistuksen lisäksi WS-I tarjoaa työkaluja ja esimerkkisovelluksia.

Profiles A profile for Web services is a set of (certain versions of) specifications with guidelines and conventions for using them together Basic Profile 1.0 is for SOAP 1.1, WSDL 1.1, UDDI 2.0, XML 1.0, and XML Schema Basic Profile 1.1 is derived from Basic Profile 1.0 by incorporating to-date errata and moving those requirements related to message serializations to the Simple SOAP Binding Profile A testing tool to check profile conformance The specifications will evolve, which challenges the work and means that the profiles need to evolve as well 99 WS-I:n ehkä tunnetuin kontribuutio on Basic Profile, joka määrittelee miten Web-palvelustandareja (WSDL, UDDI, SOAP) ja erityisesti niiden tiettyjä versioita - tulisi käyttää, jotta yhteentoimivuusongelmat tulisi minimoitua. Basic Profile pyrkii siis tavallaan tilkkimään niitä aukkoja, jotka spesifikaatiot jättävät avoimiksi. Basic Profile suosituksesta on julkaistu versiot 1.0 ja 1.1. Versio 1.0 määrittelee sääntöjä SOAP 1.1, WSDL 1.1, UDDI 2.0, XML 1.0 ja XML Schema standardien käyttämiseksi ja yhteensovittamiseksi. Versio 1.1 on version 1.0 laajennos siten, että tunnetut version 1.0 virheet on korjattu ja joitain SOAP-viestejä koskevia sarjallistamisvaatimuksia on siirretty erilliseen Simple SOAP Binding Profile suositukseen. Maaliskuussa on julkaistu myös Basic Profile 1.2 draft, mutta sitä ei ole vielä hyväksytty viralliseksi profiiliksi. Sen vuoksi versiota 1.2. ei käsitellä tarkemmin. WS-I tarjoaa myös työkalusetin WS-I Testing Tools, jonka avulla voidaan tarkastaa ovatko esimerkiksi käytetyt SOAP-viestit tai WSDL-kuvaukset Basic Profile suosituksen mukaisia. Useimmat suurimmista Web-palvelutyökalujen tuottajista tarjoavat jo uusimmissa työkaluversioissaan tukea WS-I profiilille. Tämä tuki saattaa olla esimerkiksi erillinen optio, joka tarvittaessa ottaa huomioon Basic Profile suosituksen (esimerkiksi työkalu generoi Basic Profile suosituksen mukaisen WSDLdokumentin toteutetun palvelun rajapinnan perusteella). Basic Profile, kuten myös WS-I:n tarjoamat työkalut, ovat kaikille vapaasti saatavilla. Kuitenkin ainoastaan WS-I:n jäsenet voivat tarjota näitä työkaluja sekä muuta materiaalia WS-I:lle jaettaviksi. Jäsenet lisäksi voivat osallistua näiden suositusten suunnitteluun ja kehittämiseen. Basic Profile suosituksesta tullee uusia versioita, koska itse spesifikaatioiden kehitys jatkuu edelleen.

In EEWES research group at TUT, a tool has been developed that transforms WSDL document into a UML model (class diagram) and checks the conformance of that UML model against WS-I Basic Profile 1.0 and 1.1 rules represented as a UML profile 100 Tampereen teknillisen yliopiston ohjelmistotekniikan laitoksella EEWES (2004-2007) ja MoDES (2007-2010) -projekteissa on tutkittu mm. UML:n roolia Web-palveluiden suunnittelussa. Projektissa on kehitetty esimerkiksi työkalu, jonka avulla WSDL-dokumentit voidaan kuvata UMLluokkakaavioina. Työkalu muodostaa dokumentista sekä matalan tason instanssikaavion sekä abstrahoidun version, joka kuvaa dokumentin loogista rakennetta. Instassikaaviossa jokaista WSDLdokumentin elementtiä (esim. porttype) vastaa luokka luokkakaaviossa (oikeampi kaaviotyyppi olisi oliokaavio, mutta käytännön käytettyyn CASE-työkaluun liittyvistä ongelmista johtuen ko. instanssikaavio kuvataan luokkakaaviona). Kyseisen elementin attribuutit annetaan vastaavasti luokan attribuutteina. Abstrahoidussa luokkakaaviossa kutakin elementtityyppiä vastaa luokka (esim. aina vain yksi porttype luokka) ja niiden esiintymiskerrat kuvataan assosiaatioiden kertautumismääreinä. Lisäksi projektissa on kuvattu WS-I Basic Profile 1.0 suosituksen mukaiset WSDL:ää ja SOAP-sidontaa koskevat säännöt UML-profiileina OCL:ää hyödyntäen. UML-profiili kuvataan luokkakaaviona ja se määrää tiettyjä sääntöjä, jotka kunkin profiilin mukaisen mallin tulee ottaa huomioon (UML-spesifikaatiosta löytyy tarkempaa informaatiota UML-profiileista). Projektissa (hyödyntäen aiempien tutkimusprojektien tuloksia) on lisäksi toteutettu työkalu, jonka avulla annettu WSDL-dokumenttia kuvaava luokkakaavio voidaan validoida ko. profiilia vasten. Ts., työkalu etsii WSDL-kuvauksesta mahdollisia profiilin vastaisia kohtia. Löydetyt virheet listataan erillisessä editorissa (Error Browser), josta voidaan myös navigoida virheen sisältämiin kohtiin luokkakaaviossa.

Kuvassa on esitetty esimerkkiajo, jossa annettu WSDL-dokumentti on ensin muutettu luokkakaavion muotoon. Osa tästä Rational Rose CASE-työkaluun importoidusta luokkakaaviosta näkyy taustalla. Kuvan etualalla näkyy Error Browser selain, jossa on listattu kaikki havaitut virheet. Virhekoodeina (WSI2114 ja WSI2123) käytetään Basic Profile suosituksen mukaisia koodeja. Samoja koodeja käytetään myös WS-I Testing Tools työkalusetissä. Näin ollen näiden kahden työkalusetin antamia tuloksia voidaan helposti verrata keskenään. Käyttäjä on valinnut yhden virheistä, jolloin virheen sisältämä elementti (esitetty luokkana) tulee automaattisesti valituksi mallista. Toteutettu työkalusetti eroaa WS-I Testing Tools työkalusetistä mm. siinä, että WS-I Testing Tools ei tarjoa vastaavia navigointi- ja visualisointimahdollisuuksia.

Designing and realizing SOA 101

Developing SOA-based systems Top-down approach 1) Design of services and processes Ideally without considering the existing code base i.e. what would be needed 2) Implementation of the required services Match with existing code base Modify/use existing services and use wrapping techniques Build new services A business driven approach 102 Edellä esitetty tapa toteuttaa palvelupohjaisia järjestelmiä edustaa nk. top-down lähestymistapaa. Oleellisesti siinä siis edetään systemaattisesti abstrakteimmalta tasolla tarkentaen yhä yksityiskohtaisemmalle ja tarkemmalle tasolle päätyen lopulta itse toteutukseen. Kuten edellä mainittiin, ideaalisessa tapauksessa suunnittelu alkaa liiketoiminnan tasolta eikä liiketoimintaprosesseja eikä teknisiä realiteetteja vielä edes huomioida tuossa vaiheeessa. Kun liiketoimintaprosessit on määritelty, tulee niiden toteuttaminen suunnitella teknisinä prosesseina. Nämä tekniset prosessit voidaan sitten toteuttaa osin hyödyntäen olemassa olevia järjestelmiä ja toisaalta toteuttamalla uusia palveluita tarvittaessa. Tätä lähestymistapaa kutsutaan myös liiketoimintaorientoituneeksi lähestymistavaksi.

Developing SOA-based systems Bottom-up approach 1) Identification of services and processes from existing code 2) Using e.g. wrapping techniques to implement proper service interfaces Goals to extend the functionality of a legacy system to migrate a legacy system for a new environment For software integration and/or interoperability reasons Etc. An IT driven approach Some experiences from practical cases indicate that the combination of the two (bottom-up and top-down), i.e. meet in the middle, would be a most applicable approach. 103 Edelliselle top-down lähestymistavalle vastakkainen vaihtoehto on nk. bottom-up lähestymistapa. Siinä lähdetään nimenomaan olemassa olevista teknisistä valmiuksista. Aluksi pyritään identifioimaan tarvittavat palvelut ja prosessit koodista. Hyödyntämällä erilaisia käärimistekniikoita ja takaisinmallinnustekniikoita (reverse engineering techniques), olemassa oleva koodi muunnetaan palvelupohjaiseksi. Tätä toiselta nimeltään IT-lähtöistä lähestymistapaa käytetään paljon. Se on selkeästi enemmän käytetty kuin top-down lähestymistapa. Sitä hyödynnetään mm. kun halutaan laajentaa legacyjärjestelmien toiminnallisuutta, integroida ne muiden järjestelmien kanssa, käyttää niitä uudessa ympäristössä jne. Toisaalta tässä lähestymistavassa on myös selkeät heikkoutensa. Suurin niistä lienee se, että muodostettu palvelujoukko on harvoin ideaalinen ja aidosti SOA-hengen mukainen.

G. Coticchia, Seven Steps to a Successful SOA Implementation. Business Integration Journal,10, 5, 2006, http://www.bijonline.com/, pp. 10-13. : Business services cannot be developed bottomup, ad hoc, in other words driven by immediate project needs and implementation details instead of long-time business needs. But one-step top-down approach is not either the only way to go, as it tends to ignore the details and make false assumptions on the cost and scheduling of implementations. Instead, collaborative, iterative top-down mechanism should be used. 104 Käytäntö on osoittanut, että ehkä paras edetä olisi yhdistää top-down ja bottom-up lähestymistapoja. Bottom-up lähestymistapa saattaa johtaa joustamattomaan palvelujoukkoon eikä huomioi liiketoimintatarpeita. Top-down lähestymistapa puolestaan saattaa johtaa siihen, ettei teknisiä realiteetteja oteta oikealla tavalla huomioon. Esimerkkeinä voivat olla väärät oletukset toteutuksen kompleksisuudesta, toteutukseen tarvittavasta ajasta jne. Coticchia (2006) on todennut tutkittuaan useaa käytännön projektia, että nk. meet-in-the-middle olisi tässäkin tapauksessa paras vaihtoehto. Hän toteaa, että suunnittelun tulisi alkaa aidosti liiketoiminnan näkökulmasta, mutta tekniset realiteetit tulisi huomioida jo melko aikaisessa vaiheessa. Tämä lisäisi myös kommunikaatiota liiketoiminta- ja ITvastuullisten kesken.

Developing SOA-based systems Harry Sneed, Migrating to Web Services A Reseach Framework, CSMR conf., SOAM workshop, 2007 Developing web services is a long term investment [1]. It will take at least two years before enough services of sufficient quality can be made available to the user business processes. It is questionable if the users are willing to wait so long. The benefits of using selfdeveloped web services will only become visible after some years. In the meantime, the IT department must sustain the continuity of the existing systems [1] J. Bishop and N. Horspool, Cross-Platform Development Software that lasts, IEEE Computer, Oct. 2006, p. 26 105 Toisaalta bottom-up lähestymistalle löytyy myös puollustajia, kuten esim. Harry Sneed on esittänyt useissa artikkeleissaan. Kyse lienee kuitenkin lopulta siitä mitä palvelupohjaiselta järjestelmältä halutaan ja mitä tarkoitusta varten se on toteutettu.

Enterprise Service Bus (ESB) 106

What is ESB? ESB is a software infrastructure that facilitates application integration. There are different definions Architectural style? EI pattern? Architecture? Standard? Framework? An Enterprise Service Bus (ESB) is a new architecture that exploits Web services, messaging middleware, intelligent routing, and transformations. ESBs act as a lightweight, ubiquitous integration backbone through which software services and application components flow. [Gartner] Many ESB implementations (products) exist 107 ESB:n määritteleminen on itse asiassa hieman hankalaa. Siitä on käytetty termejä arkkitehtuurityyli, integraatiomalli, arkkitehtuuri, standardi, kehys jne. Käytännössä sen voisi sanoa olevan sovellusintegraatiota tukeva infrastruktuuriratkaisu, jolle on olemassa erilaisia toteutuksia eri työkaluvalmistajien tarjoamina.

Software integration and ESB ESB is a software infrastructure that facilitates application integration. It suits well and is widely used as a middle ware for SOA implementations, since it supports Exchange of messages, Provides a communication channel for XML-based (e.g. SOAP) message exchanges, often asynchronously Execution of transactions, Orchestration of services, Use of open standards, An infrastructure based on open standards allows use of WS-* standards and thus support for Secure messaging Intelligent routing Data transforming QoS features Building loosly coupled system integrations However, ESB SOA ESB provides means, not business value ESB does not guarantee a SOA solution 108 SOA-pohjaiset ratkaisut usein käyttävät palveluväylää toteutusteknologiana, mutta se ei tietenkään ole välttämätöntä. On esitetty myös kriittisiä mielipiteitä siitä miten ESB itse asiassa sotii tiettyjä SOAn periaatteita vastaan. Sen sopivuus on kuitenkin helposti perusteltavissa, koska se tukee XML-pohjaista (kuten SOAP) viestinvälitystä, usein asykronisesti Transaktioita Palveluiden yhdistämistä (esim. orkestraatiot) Avointen standardien käyttöä WS-* -standardien käyttö Turvallinen viestinvälitys Reititys Datamuunnokset QoS-ominaisuudet Löyhien integraatioratkaisujen toteuttamista Jne.

Toisaalta on hyvä muistaa, että ESB tarjoaa ainoastaan keinot SOA-ratkaisun toteuttamiseksi, se ei takaa SOA-ratkaisua. Analogiana voisi ajatella, että ESB on tavallaan tie, jolla pääsee tiettyyn päämäärään, mutta se ei ole tai määritä itse päämäärä; ESB ilman SOAa on kuin tie, jonka lähtöpiste on paikka ilman asukkaita ja päätepiste on paikka, jonne kukaan ei ole menossa. Kriittistä keskustelua ESB:n ja SOAn roolista löytyy esimerkiksi osoitteesta http://www.ibm.com/developerworks/webservices/library/ws-soa-esbarch.

What is ESB? Web services Service orchestrations Existing applications Messaging Web portals Enterprise Service Bus (Routing, transformation services) Adapters Data services, databases File, ftp Email J2EE,.NET, 109 Kalvon kuvassa on laajennettuna havainnollistettu edellisellä kalvolla esitettynä ESB-väylän ominaisuuksia.

Service-Oriented Modeling and Architecture (SOMA) A method to model and design SOA, proposed by IBM Implements IBM s other method, service-oriented analysis and design (SOAD), through identification, specification and realization of the three main elements of SOA: services, components that realize those services (a.k.a. "service components"), and flowsthatcanbeusedto composeservices More information A. Arsanjani, Service-Oriented Modeling and Architecture: How to Identify, Specify and Realize Services for your SOA, IBM developerworks, 2004. N. Bierberstein, S. Bose, M. Fiammante, K. Jones, and R. Shah, Service- Oriented Architecture (SOA) Compass: Business Value, Planning, and Enterprise Roadmap, IBM Press, ISBN-13: 978-0-13-187002-4, Oct 2005. A. Asanajani, L.-J. Zhang, M Ellis, A. Allam, and K. Channabasavaiah, S3: A Serivce-Oriented Reference Architecture, IT Professional, IEEE Computer Society, May/June 2007. 110 IBM:n SOMA on menetelmä, jonka tarkoituksena on tukea SOA-pohjaisten järjestelmien suunnittelua, mallintamista ja toteuttamista. Koska se on yksi ensimmäisistä ja ehkä myös laajimmin tunnetuista suunnittelumenetelmistä ja koska tällaisten menetelmien tarve (ja niiden puute) on laajalti havaittu, käsitellään SOMAa seuraavaksi esimerkinomaisesti. On kuitenkin syytä korostaa, että SOMAa ei menetelmänä voida missään nimessä kutsua (edes de facto) standardiksi. SOMA toteuttaa IBM:n toisen menetelmän SOAD, joka on kehitetty palveluorientoituneiden järjestelmien analyysi- ja suunnittelumenetelmäksi. Tämä menetelmä pohjautuu perinteisiin olio- ja komponenttipohjaisten järjestelmien analyysi- ja suunnittelumenetelmiin ja laajentaa niitä SOAn kannalta oleellisilla näkökulmilla. SOMA koostuu kolmesta päävaiheesta: SOAn peruselementtien tunnistaminen, spesifiointi ja realisointi. Nämä peruselementit ovat palvelut, palvelut realisoivat palvelukomponentit (service components) sekä palveluiden yhdistämiseen käytettävät vuot.

SOMA - Designing SOA systems The design strategy for a SOA does not start from the bottom-up" as is often the case with a Web services-based approach. You must remember that SOA is more strategic and business-aligned. (Ali Arsanjani, Service-oriented modeling and architecture, IBM developerworks, 2004). Activities of a service consumer (i.e. a user of a service, which can be a client or a service): Service identification, service categorization, choreography or composition, quality of service (QoS) Activities of a service provider: Component identification, component specification, service realization, service management, standards implementation, service allocations to components, layering the SOA, technical prototyping, product selection, architectural decisions (state, flow, dependencies) 111 A. Arsanjani korostaa artikkelissaan Service-oriented modeling and architecture, IBM developerworks, 2004, että suunniteltaessa SOA-pohjaisia järjestelmiä tulisi välttää bottom-up tyyppistä lähestymistapaa, jossa siis lähdetään yksityiskohdista (esim. olemassa olevasta koodista) ja valitaan/identifioidaan palvelut näiden yksityiskohtien perusteella tai johdattamana. Tällainen lähestymistapa harvoin johtaa parhaaseen mahdolliseen lopputulokseen. Arsanjani tähdentää, että sen sijaan tulisi muistaa, että SOAlla on strategista merkitystä ja sen tulisi huomioida myös liiketoimintaorientoitunut näkökulma. Tällöin siis top-down tai mahdollisesti näiden kahden lähestymistavan (top-down ja bottom-up) yhdistelmä olisi parempi. Arsanjani sanoo edelleen, että bottom-up lähestymistapaa käytetään paljon Web-palvelujärjestelmiä toteutettaessa. Kuten Arsanjani edelleen toteaa, bottom-up lähestymistapaa käytetään paljon Web-palvelujärjestelmiä toteutettaessa (service mining, software migration). Se ei silti liene se oikea tai paras lähestymistapa myöskään Web-palvelujärjestelmiä jotka myös ovat SOA-pohjaisia toteutettaessa. Kalvolla on listattu SOA-pohjaisen järjestelmän suunnittelussa huomioitavat palvelun käyttäjän (consumer) ja palvelun tarjoajan (provider) tehtävät ja roolit. Tässä palvelun käyttäjä (consumer) on erotettu termistä asiakas (client). Käyttäjä on palvelua käyttävä taho ja se voi olla joko asiakas tai palvelu. Huomaa, että palvelun käyttäjän aktiviteetit muodostavat alijoukon palvelun tarjoajan aktiviteeteista. Palvelun tarjoaja esimerkiksi myös tunnistaa, kategorisoi jne. palveluita. Palvelun

käyttäjä spesifioi ensin ne palvelut, joita se tarvitsee (tyypillisesti etsimällä niitä tietyin kriteerein) ja varmistuttuaan sen jälkeen siitä, että etsittyjen palvelujen (kriteerit) ja toisaalta tarjotun/löydetyn palvelun spesifikaatiot vastaavat toisiaan (vaaditulla tavalla), se ottaa yhteyttä ko. palveluun. Palvelun tarjoajan puolestaan tulee julkaista tarjoamansa palvelut, sekä toiminnallisuuden että laatuattribuuttien (QoS) osalta. Tämä implisiittinen sopimus palvelun tarjoajan ja käyttäjän välillä voi mahdollisesti kypsyä eksplisiittiseksi SLA-sopimukseksi, joka on neuvoteltavissa joko elektronisesti (esim. ebxml, jota käsitellään myöhemmin) tai muutoin.

The layers of a SOA (A. Asanajani, L.-J. Zhang, M Ellis, A. Allam, and K. Channabasavaiah, S3: A Serivce- Oriented Reference Architecture, IT Professional, IEEE Computer Society, May/June 2007. Service consumer Service provider Consumer Business process composition choreography business state machines Services Atomic Composite Service components Operational systems Packaged application Channel Business to business Custom application OO application Integration (enterprise service bus) Quality of service (security, management, and monitoring infrastructure services) Information architecture (metamedia and business intelligence) 112 Governance and policies Kalvon SOAn kerroksia havainnollista kuva on piirretty mukaellen kuvaa, joka on esitetty artikkelissa A. Asanajani, L.-J. Zhang, M Ellis, A. Allam, and K. Channabasavaiah, S3: A Serivce-Oriented Reference Architecture, IT Professional, IEEE Computer Society, May/June 2007. Kirjoittajat toteavat, että kuvan yhdeksän kerrosta ovat suhteellisen itsenäisiä, minkä vuoksi organisaatio voi valita palvelun tarjoajan ja käyttäjän integraation asteen. Esimerkiksi liiketointaprosessikerros ei välttämättä esiinny SOA-ratkaisussa. Tällöin palvelun käyttäjä ja tarjoaja voivat kommunikoida suoraan. Operatiivisten järjestelmien kerros (Operational systems) sisältää kaikki ne käytettävät sovellukset ja/tai niiden osat, jotka tukevat liiketoiminta-aktiviteetteja. Näihin sovelluksiin kuuluvat esimerkiksi legacy-järjestelmät, tietokannat ja vaikkapa pakatut sovellukset ja ratkaisut kuten ERP- tai CRMratkaisut. Palvelukerros (Services) puolestaan sisältää kaikki SOAan kuuluvat palvelut: sekä sellaiset palvelut, jotka palvelun tarjoaja tarjoaa, että käytettävät palvelut. Jokaisesta palvelusta tulee olla tieto tarjottavista operaatioista, kontaktipisteestä, kutsuprotokollan yksityiskohdista sekä palvelun semantiikasta (esim. liiketoimintakonteksti). Web-palvelujen tapauksessa kolme ensimmäistä saadaan WSDL-dokumentista. Seuraavassa liiketoimintaprosessikerroksessa (Business process) organisaatio koostaa palvelukerroksen palveluista prosesseja. Lopuksi kuluttajakerroksessa (Consumer) hoidetaan interaktiot käyttäjän tai muiden SOA-ekosysteemiin kuuluvien ohjelmien kanssa. Tämän kerroksen kautta organisaatio voi toisaalta välittää dataa sovelluksille ja käyttäjille tiettyjen preferenssien mukaan

ja toisaalta se voi nopeasti luoda liiketoimintaprosesseille ja sovelluksille front-end-liitännän, jonka avulla se voi mukautua erilaisiin ulkopuolisiin muutoksiin. Edellä mainittujen kerrosten lisäksi Asanajari et al. määrittävät neljä muuta edellisiä kerroksia hallinnoivia ja niihin vaikuttavia kerroksia. Integraatiokerros (Integration) integroi käytännössä kerrokset 2-4 (Service components, Services, Business processes). Integrointi voidaan toteuttaa vaikkapa ESB-ratkaisuna. Tämän kerroksen avulla organisaatio voi reitittää, välittää ja kuljettaa palvelukutsuja palvelun pyytäjältä konkreettiselle palvelulle. Laatuattribuuttikerros (Quality of service, QoS) huolehtii ei-funktionaalisista vaatimuksista liittyen luotettavuuteen, saavutettavuuteen, hallittavuuteen, skaalautuvuuteen ja turvallisuuteen. Informaatioarkkitehtuurikerros (Information architecture) voi esimerkiksi sisältää tietoa ja/tai referenssejä koskien teollisuuden alalle spesifejä tai teollisuusalojen välisiä tietorakakenteita ja XML-pohjaisia metadata-arkkitehtuureja (XML Schema). Tämä kerros sisältää SOA-ekosysteemissä tarvittavan metadatan. Viimeisenä kerroksena Asanajani et al. esittävät hallintakerroksen (Governance and policies). Tämä kerros on vastuussa SOA-ekosysteemin hallinnoinnista koko liiketoimintaoperaatioiden elinkaaren ajan. Tämä kerros määrittää myös periaatteet ja säännöt SLA-sopimuksille (esim. kapasiteetti, tehokkuus, turvallisuus). Hallinnoinnin merkitys SOA-pohjaisille ratkaisuille onkin viime aikoina saanut paljon huomiota. Kuten kaikille järjestelmille, se on tärkeää myös SOA-pohjaisille ratkaisuille.

Designing and implementing Web services 113

Designing Web services Designing Web service capabilities for an application and designing the business logic of it are two different things Business logic design and implementation does not depend on Web service technologies e.g. an existing legacy system To design Web service capabilities, one needs to decide on what kind of interface with which service operations the Web service should have? how to receive and process requests? how to delegate the requests to the business logic? how to formulate and send responses? how to manage error situations and how to report about them? 114 Web-palvelu voidaan ajatella jaettavaksi kahteen erilliseen kokonaisuuteen: itse palvelun toiminnallisuuden toteuttava osa ja osa, joka mahdollistaa ko. toiminnallisuuden hyödyntämisen Webpalveluna. Tämä jako on oleellinen myös Web-palveluita suunniteltaessa. Itse palvelun toiminnallisuuden (puhutaan yleisesti myös liiketoimintalogiikasta) suunnittelun ei tarvitse riippua siitä onko se tarkoitettu käytettäväksi Web-palveluna eikä näin ollen myöskään riipu Webpalveluteknologioista. Se voi esimerkiksi olla olemassa oleva ohjelmisto, jota haluttaisiin hyödyntää Web-palveluna. Osaa, joka mahdollistaa ko. sovelluksen hyödyntämisen Web-palveluna, suunniteltaessa tulee päättää millainen on asiakassovelluksille näkyvä rajapinta (operaatiot), millaista interaktioita halutaan tukea, miten tämä interaktio muutetaan interaktioksi toiminnallisuuden toteuttavan osan kanssa, miten virhetilanteet raportoidaan asiakassovellukselle jne. Joissain tapauksissa tässä sovelluslogiikan päälle ajateltavassa ja asiakkaalle näkyvässä kerroksessa halutaan myös esikäsitellä viestejä ennen kuin ne välitetään itse sovelluslogiikan toteuttavalle osalle. Lisäksi palvelun käytön analysointi (esim. viestien monitorointi) voidaan toteuttaa tässä kerroksessa.

Service implementation Service client Service interaction layer Service processing layer A layered view of a Web service (from Designing Web Services with the J2EE(TM) 1.4 Platform : JAX-RPC, SOAP, and XML Technologies by Inderjeet Singh, Sean Brydon, Greg Murray, Vijay Ramachandran, Thierry Violleau, and Beth Stearns, Sun Microsystems, 2004.) 115 Palvelun interaktiokerros (interaction layer) koostuu asiakkaille näkyvästä ja niiden käyttämästä palvelun kontaktirajapinnasta (endpoint interface), viestien ja vastausten (SOAP) tulkinnan ja käsittelyn toteuttavasta logiikasta sekä integraatiosta sovelluslogiikan toteuttavan kerroksen kanssa. Vaikka kuvassa palvelun interaktiokerros ja varsinainen sovelluslogiikka on kuvattu yhtenä kokonaisuutena (Web-palvelu), saattavat ne käytännössä olla joko toteutettu tiiviisti integroituina tai selkeästi toisistaan erotettuina kokonaisuuksina, jotka on tavalla tai toisella integroitu toisiinsa. Interaktiokerroksen tehtävänä on tulkita ja käsitellä (SOAP-)kutsut, delegoida kutsut sovelluslogiikkakerrokselle, muokata vastaukset tarvittavaan muotoon (SOAP) ja lähettää vastaukset asiakassovellukselle. Palvelun sovelluslogiikan toteuttavan kerroksen tehtävänä on toteuttaa varsinainen palvelun toiminnallisuus.

Developing Web service interfaces 1) Java (or some other language) -> WSDL generating WSDL documents from an existing set of Java interfaces for the Web service + An easy approach + One need not to be aware of WSDL details - The developer looses some control over WSDL file creation - Comes with the cost of less flexibility - may be hard to evolve the service interface without forcing a change in the corresponding WSDL document, -> changing the WSDL might require rewriting the service s clients 2) WSDL -> Java - requires more from the designer, including more knowledge of WSDL and WS-I requirements 116 Web-palveluiden toteuttamiseen käytetään yleisesti kahta tapaa: (1) generoidaan WSDL-kuvaukset automaattisesti olemassa olevasta rajapintamäärittelystä ( Java->WSDL ) tai (2) generoidaan suunnitellusta WSDL-kuvauksesta palvelun rajapinnan toteuttavaa koodia ( WSDL->Java ). Java->WSDL tapa on näistä kahdesta helpompi ja yksinkertaisempi. Lisäksi sitä käytettäessä toteuttajan ei tarvitse välttämättä tuntea WSDL-kieltä. Toisaalta se tarkoittaa myös sitä, että Webpalvelua ajatellaan käytettävän RPC-tyyppiseen kommunikointiin: generoitu WSDL heijastelee suoraan valittua rajapintakoodia. Web-palvelukonseptia tulisi voida käyttää RPC-tyyppisen kommunikoinnin lisäksi dokumenttipohjaiseen kommunikointiin. Lisäksi RPC:n toteuttamiseen on olemassa useita tekniikoita eikä se vastaa Web-palvelukonseptin perustarkoitusta. Java->WSDL menetelmän huono puoli on myös joustamattomuus ja huono ylläpidettävyys: mikäli palvelun rajapintaan tehdään muutoksia, tulee WSDL generoida uudelleen, mikä puolestaan saattaa aiheuttaa muutoksia asiakaspäähän. Koska palvelulla on potentiaalisesti useita asiakkaista, ovat kaikki muutokset, jotka edellyttävät muutoksia myös asiakaspäähän ei-toivottuja. Versionhallinta ja ylläpidettävyys onkin yksi suurista haasteista Web-palveluille tällä hetkellä. Toinen tapa toteuttaa Web-palveluita, WSDL->Java vaatii taas enemmän palvelun toteuttajalta ja suunnittelijalta. Se vaatii esimerkiksi WSDL-kielen sekä WS-I suositusten tuntemista. Toisaalta huolellinen suunnittelu voi johtaa parempaan lopputulokseen.

Designing Web service clients Various kinds of clients may use Web services, e.g. heavy and rich client applications or light-weight clients such as wireless devices The client application should support the communication method (e.g. SOAP/HTTP) chosen locate the service(s) generate messages (e.g. SOAP) from native calls parse respond messages and transform them to native calls and/or map the data to its object model 117 Asiakasohjelman näkökulmasta Web-palvelu toimii mustana laatikkona: asiakasohjelma on kiinnostunut vain palvelun rajapinnasta, ei siitä miten se on toteutettu. Asiakasohjelmat voivat olla hyvin erilaisia kevyistä (esim. mobiililaitteet) aina monimutkaisempiin asiakassovelluksiin. Asiakassovelluksen tulee luonnollisesti tukea palvelun tukemaa kommunikointimenetelmää. Näistä yleisin on SOAP/HTTP. Asiakassovelluksen tulee myös tarvittaessa pystyä paikallistamaan palvelu. Ratkaisuissa, joissa tiedetään mitä palveluita käytetään, ei palveluja luonnollisesti tarvitse erikseen etsiä. Lisäksi asiakassovellus toteuttaa SOAPia käytettäessä SOAP-arkkitehtuurin asiakaspään. Tämä tarkoittaa käytännössä ns. proxyn toteuttamista, jonka avulla asiakassovellus kommunikoi palvelun kanssa. Sen tulee esimerkiksi generoida SOAP-viestejä natiivikutsuista tai WSDL-kuvauksista ja toisaalta tulkita palvelun lähettämät SOAP-muotoiset vastaukset natiivikutsuiksi.

Designing Web service clients There are three methods for communication with a Web service, each of them relying on a kind of a client-side proxy that represents a Web service and is used for accessing the service s functionality: static stubs (static proxies) dynamic proxies dynamic invocation interface (DII) this is the only approach that does not rely on a (full) WSDL description at development time, but supports locating it at run-time from a service registry 118 Asiakasohjelmaa suunniteltaessa ja toteutettaessa ensimmäinen tehtävä on selvittää käytettävän Webpalvelun kuvauksen (WSDL) sijainti ja valita osin sen perusteella kommunikoinnin toteutustapa. Näitä tapoja on kolme. Kaikki niistä nojaavat tavalla tai toisella jonkinlaisen asiakaspään proxyn käyttöön. Proxy edustaa Web-palvelua ja sitä käytetään haluttaessa käyttää itse palvelua. Näistä tavoista ensimmäinen, ns. staattinen tapa, tarkoittaa sitä, että proxyn koodi tulee kääntää toteutusvaiheessa ja jopa ennen asiakassovelluksen kääntämistä. Tällä tyylillä toteutetut asiakasohjelmat saattavat mennä helpostikin toimintakyvyttömiksi mikäli palvelussa, johon ne ovat yhteydessä, tapahtuu muutoksia. Staattinen tapa on kuitenkin eri tavoista yksinkertaisin ja helpoin. Sekä staattinen että dynaaminen tapa edellyttää, että palvelun kuvaus (WSDL) on olemassa, sillä proxyn (dynaaminen tai staattinen) generointi tapahtuu WSDL-dokumentin tietojen perusteella. Dynaaminen tapa on kuitenkin joustavampi kuin staattinen tapa. Se tarjoaa periaatteessa saman toiminnallisuuden, mutta tekee sen dynaamisesti. Kolmas tapa, ns. dynaaminen kutsurajapinta, on näistä tavoista ainoa, joka sallii puhtaan SOA:n mukaisen kommunikoinnin, ts. WSDL-dokumentin etsimisen ajonaikana esimerkiksi etsimällä sitä palvelurekisteristä. Seuraavaksi tutustumme näihin tapoihin hieman tarkemmin. Nämä asiakastyypit voivat esiintyä myös muilla nimillä, riippuen esim. työkalutuesta.

Communicating using static stubs Static stub classes that enable the service and the client to communicate are generated during development time The platform-specific stub class is generated for a WSDL description prior to the client s deployment and compilation represents the service endpoint interface converts requests to (e.g.) SOAP messages and sends them to the service converts SOAP responses back to a form understandable by the client software -> stub acts as a proxy for the service endpoint 119 Staattisessa tavassa siis myös proxyn koodi kirjoitetaan ja käännetään staattisesti ennen ajamista. Tämä koodi tyypillisesti generoidaan olemassa olevasta WSDL-kuvauksesta. Yleisimmin käytetyt työkalusetit tarjoavat siihen valmiit työkalut. Tässä on huomioitavaa siis se, että käytettävän palvelun WSDL-kuvaus tulee olla tiedossa jo asiakaspäätä toteutettaessa. Staattinen proxy edustaa asiakaspäälle palvelun rajapintaa. Kuten edellä mainittiin, sen tulee generoida SOAP-viestit ja toisaalta sen tulee purkaa SOAP-muotoiset vastaukset asiakassovelluksen ymmärtämään muotoon. Näin ollen se toimii proxyna Web-palvelulle.

Communicating using static stubs Worth using when services and especially their WSDL documents are unlikely to change over time + Easy to use (working with generated classes) - Creates dependencies between the client and the service -> problems, if the service changes - Requires that the stub classes are generated prior to the compilation of the client application 120 Staattista tapaa kannattaa käyttää silloin kun WSDL-kuvaukset on tiedossa ja niihin ei odoteta tulevan muutoksia. Tässä tapauksessa on siis erityisen hankalaa kaikki palvelun evoluutiosta aiheutuvat ja sen kutsurajapintaan heijastuvat muutokset. Tämä tapa on myös suhteellinen helppo toteuttajan kannalta, koska suuri osa koodista voidaan generoida automaattisesti. Toisaalta tämä tapa aiheuttaa riippuvuuksia asiakkaan ja palvelun välille. Web-palvelun perusidea on tehdä asiakas- ja palvelusovellukset mahdollisimman riippumattomiksi ja siten olla todellinen edistysaskel verrattaessa olemassa oleviin hajautusteknologioihin. Tällaiset riippuvuudet ovat aina hankalia palvelua muutettaessa. Lisäksi tämä tapa edellyttää, että proxy luokat generoidaan ennen asiakassovelluksen kääntämistä.

Communicating using dynamic proxies Corresponding to the static stub approach, but things are carried out dynamically: instead of requiring early compilation of the stub class (prior to the compilation of the client application), an equivalent dynamic proxy is generated at runtime Client-side developers need a (client-side) interface that matches the service endpoint -> clients program to that interface Like in the static approach, a WSDL description is needed for proxy generation + Portable, vendor-independent code can be written Java classes to serve as value types might also be needed Useful approach if portability is desired and if services are exptected to change only occationally - There might be a performance overhead 121 Dynaaminen tapa vastaa hyvin pitkälle staattista tapaa, mutta proxyn luominen tehdään dynaamisesti ajonaikana. Tämä menetelmä edellyttää palvelun rajapintaa vastaavan asiakaspään rajapinnan olemassaoloa. Dynaaminen proxy generoidaan sitä hyödyntäen. Lisäksi saatetaan tarvita Java-luokkia, jotka edustavat käytettäviä tyyppejä. Näillä luokilla tulee olla kentille (tyypeille) omat set- ja getmetodit. Dynaaminen tapa tuottaa luonnollisesti staattista tapaa siirrettävämpiä toteutuksia. Koska myös tämä tapa edellyttää WSDL-kuvauksen olemassaolon (ja palvelun rajapintaa vastaavan asiakaspään rajapinnan olemassaolon), saattavat palvelun muutokset tuottaa ongelmia. Ongelmat ovat kuitenkin oletettavasti pienempiä kuin staattista tapaa käytettäessä. Dynaaminen tapa tosin voi aiheuttaa hitautta ajonaikana juuri sen dynaamisuudesta johtuen.

Communicating using DIIs A client can call a service without knowing the exact service name (operations) and address at compile time More difficult for a developer to use, since a more complex interface (compared to static stubs and dynamic proxy approaches) needs to be used This interface is more prone to class cast errors - Performance overhead + Useful when a complete WSDL document is not available, esp. when ports are not specified + Useful when the service is expected to be changed frequently 122 Viimeinen asiakaspään toteutustapa, dynaaminen kutsurajapinta, on näistä kolmesta eri tavoista joustavin mutta myös haastavin ja monimutkaisin. Käytettävä rajapinta on huomattavasti monimutkaisempi verrattaessa staattiseen ja dynaamiseen tapaan. Lisäksi ko. rajapinta on käytännössä alttiimpi tyyppimuunnoksista aiheutuville ongelmille. Dynaaminen kutsurajapinta on ainoa tapa, joka toteuttaa SOA:n puhtaasti: se on tavoista ainoa, joka sallii palvelun kutsumisen ilman, että sen rajapinta (tarjotut operaatiot) ja osoite on tiedossa käännösaikana. Näin ollen se sallii esimerkiksi palvelun etsimisen ajonaikana palvelurekisteristä. Dynaaminen kutsurajapinta on puhtaasti dynaaminen tapa: se ei edellytä lainkaan käytettävään palveluun liittyvän koodin luomista asiakasohjelmaa luotaessa. Tässäkin tapauksessa tai erityisesti tässä tapauksessa tehokkuusongelmia saattaa ilmetä varsinaisia palvelukutsuja tehtäessä. Tämä tapa on erityisen hyödyllinen silloin, kun palvelun rajapinnan oletetaan muuttuvan usein. Lisäksi tämä on ainoa tapa, joka ei edellytä täydellisen WSDL-kuvauksen olemassaoloa.

Legacy systems as Web services 123

Legacy systems Old, valuable systems that are often designed and implemented using methods and programming languages that are no longer in use legacy means something valuable and something inherited There is a growing need to access legacy systems in current net-centric applications and Web services 124 Legacy-järjestelmällä tarkoitetaan (mahdollisesti) vanhaa, olemassa olevaa ja käyttökelpoista ohjelmistoa, joka on toteutettu käyttäen vanhoja menetelmiä ja/tai ohjelmointikieliä, joiden tuntemus yrityksessä saattaa olla puutteellista. Sana legacy itsessään tarkoittaa jotain perittyä ja arvokasta. Nämä ominaisuudet pätevät myös legacy-järjestelmiin. Legacy-järjestelmien modifiointi on usein erittäin vaikeaa eikä useinkaan kannattavaa. Syitä tähän on monia: järjestelmät on toteutettu vanhoilla ohjelmointikielillä suurella todennäköisyydellä ko. järjestelmien arkkitehtejä, suunnittelijoita ja koodaajia on vaikea tavoittaa (sikäli kun käytettyjen ohjelmointikielten osaajia ylipäätään on mahdollista löytää) mikäli modifiointeja tarvitaan, niin ne (erityisesti arkkitehtuuritason muutokset) käytännössä vaativat niin paljon työtä, että usein voi olla helpompaa rakentaa uusi järjestelmä usein legacy-järjestelmän statuksen saavuttaneet järjestelmät toimivat kohtuullisesti (koska niiden elinikä on osoittautunut odotettua pidemmäksi) eikä suuret rakenteelliset tai toiminnalliset muutokset ole aina välttämättömiä. esimerkiksi proseduraalisten ohjelmien konvertoiminen oliopohjaisiksi on osoittautunut usein huonoksi ideaksi: vaikka uusi oliopohjainen ratkaisu toimisikin, (a) se saattaa olla hitaampi tai (b) ohjelmoijat yksinkertaisesti hylkäävät uuden ratkaisun, koska se ei vastaa heidän ymmärrystään algoritmien rakenteesta tai ohjelman arkkitehtuurista.

Legacy systems It has proven to be often too costly, too risky, and too time consuming to reimplement the legacy systems from scratch. Wrapping the legacy system is often the best solution for enabling its reuse, e.g. transforming it to a Web service minimal changes to the source enables the reuse of current functions in new applications isolates the particular implementation from the user of the function/feature 125 Edellä mainituista syistä legacy-järjestelmien korvaaminen uusilla tai muilla olemassa olevilla järjestelmillä on usein varsin riskialtista. Lisäksi erityisesti uuden järjestelmän rakentaminen on usein hyvin aikaa vievää ja näin ollen kallista. Tämän vuoksi se ei aina ole edes realistinen vaihtoehto. Vanhoja legacy-järjestelmiä ei näin ollen käytännössä haluta useinkaan heittää pois vaan ne halutaan tavalla tai toisella käytettäväksi uudessa muuttuneessa ympäristössä. Usein paras tapa on kääriä (wrap) ne. Kääriminen edellyttää vain hyvin suhteellisen pieniä muutoksia ko. ohjelmaan, sallii olemassa olevan toiminnallisuuden ja toteutuksen käytön ja erottaa toteutetut ominaisuudet niiden käyttäjistä. Käärimistekniikoita käsitellään tarkemmin kurssilla Ohjelmien ylläpito ja evoluutio.

Requirements and expectations for wrapping Legacy systems/applications must include functions with high business value and good technical quality (e.g. robustness) The systems and their functionalities must be bounded, and they should have manageable APIs The system to be wrapped should have (enough) expected value in the future Wrapping should be worth the effort, compared to re-engineering the system building a new system from the scratch replacing the system with another alternative 126 Jotta kääriminen olisi varteenotettava vaihtoehto, edellytetään myös käärittävältä ohjelmalta tiettyjä ominaisuuksia. Käärittävän ohjelman tulee ensinnäkin olla käärimisen arvoinen. Sillä tulee toisin sanoen olla tarpeeksi arvokkaita (esimerkiksi luotettavuuden tai tehokkuuden näkökulmasta) ominaisuuksia, joita halutaan käyttää jatkossakin. Käärittävän ohjelmalla tulee myös olla riittävän hyvä ja käytettävä API ja käytettävät ominaisuudet tulee olla selkeästi identifioitavissa ja kutsuttavissa ko. APIa käyttäen. Näiden lisäksi verrattaessa vaihtoehtoisiin ratkaisuihin, kuten ohjelman uudelleen kirjoittaminen tai sen korvaaminen toisella ohjelmalla, käärimisen tulee paras ratkaisu arvioitaessa työmäärää ja hyötyä sekä niiden suhdetta (cost-benefit).

Wrapping considerations There might be a need for not corresponding wrapper and application interfaces e.g. when data structures that client uses are not isomorfic with the data structures legacy system uses e.g. when providing a higher level wrapper interface a wrapper s operation might be decomposed to several application calls XML wrapping might cause some overhead but is flexible Use design patterns, e.g., Wrapper, Adapter, Facade, Bridge 127 Käärimisen ei välttämättä aina haluta tarjoavan täsmälleen vastaavaa rajapintaa kuin alkuperäinen ohjelma, erona vain käytettävä kieli (esim. SOAP-rajapinta C++ -ohjelmalle). Voidaan esimerkiksi haluta, että uuden rajapinnan kutsuttava operaatio käyttää legacy-ohjelman useampaa operaatiota. Tällöin rajapinnassa tai tarkemmin ottaen interaktiokerroksessa voidaan käyttää ns. mukauttajia tai välittäjiä, jotka tekevät tarvittavat muutoksen. Mukauttajien käyttöä edellyttää myös tilanteet, joissa asiakasohjelman käyttämät tietorakenteet voivat erota legacy-ohjelman käyttämistä tietorakenteista. Kääreen erottaminen legacy-ohjelmasta - tai yleisemmin interaktiokerroksen erottaminen liiketoimintalogiikasta kannattaa suunnitella joustavaksi ratkaisuksi. Tähän tarkoitukseen voi käyttää esimerkiksi Façade, Wrapper, Adapter ja Bridge suunnittelumalleja. Suunnittelumalleja käsitellään tarkemmin Ohjelmistoarkkitehtuurit kurssilla ja käärimisen yksityiskohtiin puolestaan perehdytään Ohjelmistojen ylläpito ja evoluutio kurssilla. XML-kääre aiheuttaa käytännössä hitautta, koska se esimerkiksi edellyttää aina myös XML-jäsentäjän käyttöä. Toisaalta XML-kääreellä on etunsakin. Käärittäessä ohjelma esimerkiksi Internetiä hyödyntäväksi Web-palveluksi, voidaan sitä käyttää laajalti muista ohjelmista käsin.