Service Orienteret Arkitektur - løfter, forventninger og argumenter. 4 ugers projekt

Transkript

1 Service Orienteret Arkitektur - løfter, forventninger og argumenter 4 ugers projekt Martin Høgedal og Flemming Mertz IT-Universitetet, sommeren 2005 Vejleder: Carsten Butz 24. august 2005

2 Abstract Målet for denne rapport har været at kigge nærmere på de positive egenskaber, der stilles i udsigt ved at benytte en Service Orienteret Arkitektur. Udgangspunktet er følgende problemformulering: Der omtales i litteraturen væsentlige fordele ved Service Orienterede Arkitekturer baseret på Web Services. Hvad er disse fordele, hvilke argumenter baserer forfatterne disse løfter om fordele på, og er der nogen problemer med denne argumentation? Problemstillingen er løst ved hjælp af et litteraturstudie, som primært omfatter en beskrivelse af de tilgængelige teknologier, som SOA baserer sig på, samt de løfter der i litteraturen knytter sig til disse teknologiers egenskaber. Herefter analyseres og diskuteres de fremkomne egenskaber ved en Service Orienteret Arkitektur, i forhold til de argumenter som tilknyttes i litteraturen, og egne erfaringer fra projektet. Det konkluderes at SOA i forbindelse med Web Services har en stor mængde teknisk velfunderet potentiale til rådighed blandt andet i forbindelse med det simple, platformuafhængige interface til applikationsfunktionalitet. Et generelt problem er dog manglen på offentlige cases og artikler der detaljeret dokumenteret forløbet omkring implementering og ibrugtagelse af SOA på en større skala. Heriblandt den påvirkning SOA vil have på et enterprise Systems ydeevne. Dette samt manglen på en fælles standard med hensyn til de støtteteknologier der er behov for, for at sikre transaktioner, adgangskontrol og pålidelighed, er hovedårsagen til fortsat at være skeptisk overfor at SOA med Web Services kan løftes op i enterprise-klassen. 1

3 Forord Denne rapport er resultatet af en måneds arbejde med Service Orienteret Arkitektur, med det formål at gøre os klogere på en arkitektur der har været meget i fokus i det sidste stykke tid. Samtidig med mange løfter om potentielle fordele ved SOA har der også været en del kritik, blandt andet gående på at der ikke er noget væsentligt nyt i denne arkitektur, og at det således er kongens nye klæder. Dette fandt vi spændende, og da et projekt der så nærmere på dette område passede fint ind i modellen for et 4-ugers semesterprojekt, var valget oplagt. Vi håber at vi via denne rapport kan videregive noget af den viden om SOA, som vi føler vi har fået oparbejdet gennem dette projekt. Tilbage er der blot at håbe, at læseren også vil få tilført lidt ny viden gennem læsningen af denne rapport, og at det på trods af det lidt tekniske emne ikke bliver alt for tung og kedelig læsning. I forbindelse med arbejdet har vi fået god og konstruktiv kritik fra vores vejleder, ligesom han har været behjælpelig med forslag til litteratur, ideer og nye tankerækker. Vi vil derfor gerne her takke Carsten Butz for hans støtte gennem projektet. God læselyst! 2

4 Indhold 1 Indledning Motivation Problemformulering Afgrænsning Metodevalg Læsevejledning Indføring i problemområde 7 3 SOA s løfter Åbne standarder og platformuafhængighed Simple Object Access Protocol Service-baseret design Løs kobling Universal Distribution Discovery and Interoperability Hurtigere udvikling Fleksibilitet Genbrugelighed Integration Diskussion 22 5 Konklusion 28 6 Perspektivering 29 7 Projektforløb 31 3

5 Kapitel 1 Indledning 1.1 Motivation Service Orienteret Arkitektur har gennem den seneste tid været et meget udbredt samtaleemne indenfor softwarebranchen. Næsten alle former for arkitekturer kunne drage nytte af Service Orienteret Arkitektur, hvis man skulle tro artiklerne i fagbladene, mens der næsten lige så hurtigt dukkede artikler op om at SOA ikke var andet end konges nye klæder. Genbrug af eksisterende applikationer og hurtigere udvikling af nye, større IT fleksibilitet, lettere integration og besparelser på hardware er bare nogen af de løfter som SOA krediteres for i litteraturen. Men er disse fordele så ligetil, og er teknologien så ny og revolutionerende som lovet? Disse løfter og tilhørende spørgsmål, er nogen af de elementer der pirrede nysgerrigheden, og som leder frem til følgende problemformulering. 1.2 Problemformulering Formålet med denne rapport er at undersøge de potentialer og uenigheder der, som nævnt ovenfor, gør sig gældende omkring SOA. Helt konkret ønsker vi altså at undersøge hvad der ifølge den, på nuværende tidspunkt, tilgængelige litteratur tilbydes i en Serviceorienteret arkitektur samt om arkitekturen kan leve op til disse løfter. Det vil i den forbindelse ligeledes være aktuelt at undersøge selve argumentationsbaggrunden i litteraturen. Dette har ledt os frem til følgende problemformulering: Der omtales i litteraturen væsentlige fordele ved Service Orienterede Arkitekturer baseret på Web Services. Hvad er disse fordele, hvilke argumenter baserer forfatterne disse løfter om fordele på, og er der nogen problemer med denne argumentation? 4

6 1.3 Afgrænsning En Service Orienteret Arkitektur (SOA) er ud fra den følgende definitionen implementeret af et antal services, og der er ikke noget i vejen for at de eksempelvis implementeres ved hjælp af CORBA eller i en ren Java verden eventuelt gennem servlets eller RMI. At undersøge SOA i forbindelse med alle disse teknologier ligger dog udenfor rammerne af dette projekt, hvorfor indeværende rapports fokus hovedsageligt beskæftiger sig med SOA i forbindelse med Web Services. Derfor dækker betegnelser SOA og Service Orienteret Arkitektur, i denne rapport, over en Service Orienteret Arkitektur baseret på Web services medmindre andet er eksplicit nævnt. Det ligger uden for dette projekts område at undersøge implementeringen af SOA i praksis. Det er alene en identifikation og vurdering af de løfter SOA stilles i udsigt i litteraturen, hovedsageligt med fokus på de tekniske egenskaber. Der findes en del løfter gående på mere forretningsorienterede områder, men disse har vi ikke ønsket at vurdere eller efterprøve i dette projekt. 1.4 Metodevalg Dette afsnit omhandler, hvordan vi vil gribe problemstillingen an set fra en praktisk synsvinkel. Overordnet set vil vi besvare problemformuleringen ved hjælp af et litteraturstudie. Dette studie vil primært omfatte en beskrivelse af de tilgængelige teknologier, som SOA baserer sig på, og der vil i den forbindelse blive fokuseret på SOA og web services, for at danne et teoretisk grundlag for læseren. Herefter vil vi analysere og diskutere de fremkomne egenskaber ved en Service Orienteret Arkitektur, i forhold til de argumenter som tilknyttes i litteraturen, og egne erfaringer fra projektet. 1.5 Læsevejledning For at øge rapportens overskuelighed gives her en beskrivelse af, hvad de enkelte kapitler indeholder: Kapitel 1, Dette kapitel har til formål at introducere læseren til opgaven samt problemstillingen. Ligeledes består kapitlet af en indledning og denne læsevejledning. Kapitel 2, Derefter introduceres til problemområdet, hvor den benyttede litteratur gennemgås, og de definitioner der arbejdes med i rapporten fastlægges. 5

7 Kapitel 3, Dette kapitel omhandler de løfter om forbedringer af IT udnyttelsen, som findes i litteraturen om SOA, og som er den væsentlige del af projektet. Kapitlet er inddelt i tre afsnit som henholdsvis omhandler: De standarder, der indgår i opbygningen af Web Service teknologien, og som derfor er basis for den type SOA der studeres i dette projekt. Skiftet til at designe og udvikle Service baseret herunder løfter omkring løs kobling, hurtigere udvikling, fleksibilitet og genbrugelighed. Web Services, og en fuld SOA, som integrationsteknologi. Der gennemgås løfter inden for både intern og ekstern integration. Kapitel 4, I diskussionen vurderer og analyser vi de fremkomne løfter, baseret på de argumenter som forfatterne benytter. Desuden ser vi på de områder af SOA s egenskaber som, vi mener, kan være kritiske. Kapitel 5, Konklusionen holder diskussionen op mod problemformuleringen, og samler op på de resultater som er fremkommet under projektet. Kapitel 6, Formålet med dette kapitel er at anskue projektet fra en mere reflekterende synsvinkel, og det indeholder derfor en opsummering af problemstillinger, der kunne være interessante at arbejde videre med, men som har ligget uden for dette projekts problemformulering. Da der forekommer en del tekniske termer, vil tekniske ord der benyttes, men ikke direkte forklares i teksten, være at finde i ordforklaringen i appendix. 6

8 Kapitel 2 Indføring i problemområde Problemformuleringen ovenfor definerer rapporten som fokuserende på de løfter der i litteraturen stilles til udsigt, ved at benytte en Service Orienteret Arkitektur. Vi vil hovedsageligt fokusere på de tekniske egenskaber, der skaber fordelene, men inden vi kan gå dybere ind i dette, er vi nødt til at definere hvad vi mener med litteraturen, samt definitioner på hvad vi forstår ved nogle af de hovedbegreber, der kommer til at gå igen i rapporten. Den litteratur der ligger til grund for litteraturstudiet i denne rapport, er hovedsageligt teknisk orienterede bøger om SOA eller Web Services. Disse bøger kan ses i litteraturlisten, men derudover har vi forsøgt at finde mere forskningspræget litteratur, i blandt andet Ebrary og DADS. Vi har imidlertid ikke kunne finde noget der egentligt understøtter de fordele der nævnes i de tekniske bøger, og som der vil blive kigget nærmere på i denne rapport. Det har heller ikke været muligt for os at frembringe detaljerede case beskrivelser af implementeringer af SOA, hvor det beskrives hvad der er implementeret, graden af succes og de fordele, eller ulemper, der måtte være blevet afdækket. Når der skrives litteraturen i denne rapport, er det altså stort set begrænset til de tekniske og programmeringsorienterede bøger, der findes i litteraturlisten. Dertil skal der lægges mindre artikler i fagblade inden for eksempelvis Java, som har været meningsdannede for blandt andet os. Der vil gennem rapporten blive gjort udpræget brug af ord som SOA, service, Web Service og lignende. Da en del af disse begreber ikke er en fast defineret størrelse, er det væsentligt for den fælles konsensus på området at definere disse begreber. Denne definition er ikke nødvendigvis den korrekte set med andres øjne, men det er den der arbejdes ud fra i denne tekst. Et helt grundlæggende begreb når man benytter en Service Orienteret Arkitektur, er begrebet en service. En service er et vidtstrakt begreb, men helt basalt set dækker ordet over en tjenesteydelse, som leveres af en part, 7

9 og efterspørges af en anden. Denne definition ligger faktisk også ret tæt op af det vi mener, når vi skriver service i denne rapport. Men inden for software er rollerne som udbyder og forbruger af en service lidt mere diffuse, end ved udbud af service mellem personer. I software kan disse roller spilles af andre dele af et program, af andre programmer eller af personer. Men basalt set er definitionen den samme. Der udbydes noget (algoritmisk), som forbruges af andre. Berry definerer også en service som værende: A service is a function that is well-defined, self-contained, and does not depend on the context or state of other services. Over time, the industry will standardize on the capabilities of various services. [32] Den type Service Orienterede Arkitekturer der behandles i denne rapport, benytter Web Services til at implementere service begrebet. Med en service defineret, er det ret let at udlede en definition på web services. Det er en service der er tilgængelig over web, altså et netværk baseret på almindelige Internet protokoller. Men Web Services er også et mere fast begreb, som er defineret af de teknologier der indgår i opbygningen af en web service. W3C som har stået for at udvikle og definere de basale standarder som Web Services bygger på, definerer en Web Service således: A service that is accessible by means of messages sent using standard web protocols, notations and naming conventions, including XML Protocol (or until XML protocol is standardized, SOAP). Web service may also imply the use of ancillary mechanisms, such as WSDL and UDDI for defining Web services interfaces. En Service Orienteret Arkitektur (SOA) er som navnet antyder en arkitektur hvor fokus er på opbygning og samspil mellem services. I stedet for større delsystemer, opbygges systemet af mange små, selvstændige services. Den type SOA som er emnet for dette projekt, er den som er mest udbredt i øjeblikket, og som benytter Web Services til at implementere service begrebet. Så når der i dette projekt skrives Service Orienteret Arkitektur eller SOA, menes der som nævnt tidligere, en Service Orienteret Arkitektur, med Web Services. Som det fremgår af dette afsnit er begrebet SOA noget sværere at definere præcist. Men følgende definition fra Wikipedia dækker ganske godt den synsvinkel der er taget i dette projekt: In computing, the term service-oriented architecture (SOA) expresses a software architectural concept that defines the use of services to support the requirements of software users. In an SOA environment, nodes on a network make resources available to other participants in the network as independent services that the participants access in a standardized way. Most definitions of SOA identify the use of web services (using SOAP and WSDL) in its 8

10 implementation, however one can implement SOA using any service-based technology. Ved gennemgangen af litteraturen fremkom en mængde egenskaber, som gik igen flere steder, og som må anses som de væsentligste løfter ved brugen af SOA. Disse løfter beskæftiger sig med forskellige områder af teknologierne der indgår i en SOA, og de passer derfor logisk sammen i nogle større grupper. Disse løfter beskrives samlet, da grundlaget for flere af disse løfter bunder i de samme teknologiske argumenter. 9

11 Kapitel 3 SOA s løfter 3.1 Åbne standarder og platformuafhængighed En af de egenskaber der går igen i alle bøgerne, om end ofte mellem linierne, er det fordele de åbne Web Service standarder giver i fordel til tidligere teknologier, inden for samme domæne. Dette afsnit handler derfor om de teknologier som Web Services er bygget op af, og som benyttes som nogle af argumenterne for de fordele, som en SOA skulle kunne levere. Den helt centrale teknologi i Web Services er Extensible Markup Language (XML). Siden den første W3C Recommendation for XML kom i 1998 [20], er tilslutningen og udbredelsen af XML som dataformat steget voldsomt, og XML benyttes i dag i stort omfang inden for alle områder af IT. Mange virksomheder har taget XML til sig som enten datalagrings, integration eller udvekslingsformat [25], hvilket gør Web Services lettere at integrere i de allerede eksisterende systemer. XML i sig selv vil ikke blive beskrevet her, da det ligger uden for projektets problemformulering. Men brugen af XML i web services ligger til grund for nogen af de argumenter for SOA s fordele, og XML s placering i web services vil derfor kort blive gennemgået. Som illustreret på figur 3.1 tilbyder Web Services en standardiseret måde for alle former for klienter at tilgå backend systemer såsom J2EE, Database eller.net servere. Det foregår ved at Web Servicen modtager et XML dokument fra en klient sendt over netværket, som omsættes til det format der benyttes af det aktuelle system som skal udføre den ønskede funktionalitet. Såfremt en besvarelse er nødvendig sender backend systemet svar tilbage til web servicen, som endnu engang sørger for at besvarelsen omformes til et XML og sender dette til klienten. Introduktionen af XML er et vigtigt skridt i simplificeringen af vedligeholdelsen af eksternt data, idet XML gør udviklere i stand til at separere indholdet af data, fra dets præsentation. Formålet med udviklingen af XML var at overvinde HTML s begrænsninger, hovedsageligt med hensyn til bedre 10

12 Figur 3.1: Web Service (kilde: [1]) at understøtte et dynamisk indhold. XML indeholder ligesom HTML elementer, attributter og værdier, men hvor HTML indeholder et definitivt antal af elementer og attributter, er det i XML muligt at definere et uendeligt antal elementer og attributter. Disse bruges til at give data en betydning, men samtidig ligger der ikke nogen præsentationslogik i disse tags. Faktisk ligger der ikke nogen specifik mening i hovedparten af tags ne, og det er så op til dem der parser XML filen at give de enkelte tags mening. Dette er en af de store styrker ved XML, i forhold til anvendelsen i Web Services. Som nævnt ovenfor er XML allerede benyttet på mange andre områder, så ved at introducere Web Services i et system introducerer man ikke samtidig nødvendigvis et nyt dataformat. Set i forhold til for eksempel CORBA giver dette et væsentligt mere enkelt applikationsbillede, hvor data repræsentationen er uafhængigt af implementeringen af Web Services. Vælger man CORBA, vælger man samtidig IDL som dataformat og ORB en som protokol. Derudover er det forfatternes egne erfaringer at der også kunne være forskelligheder inden for forskellige CORBA implementeringer, og sågar inden for forskellige versioner af samme implementering, der kunne give problemer med kompatibilitet. I Web Services styres udviklingen af dataformatet ikke af de samme som udvikler de sprog hvor implementeringen af Web Services skal foretages, hvilket giver en større grad af sikkerhed for kompatibilitet. I forhold til ovennævnte portabilitetsproblem har XML også en fordel over IDL i CORBA s tilfælde. Når man skal benytte CORBA kompileres der IDL stubbe og skeletons, som henholdsvis klient og server benytter til 11

13 udgangspunkt for den fælles kommunikation. Efter kompileringen er der ingen måde at ændre formatet for et metodekald, og både klient og server skal nøje overholde denne kontrakt. XML har indbygget en fleksibilitet overfor ændringer i data, da det er muligt at understøtte flere versioner af samme Web Service fra samme interface. Der er ikke noget i vejen for at sende mere data end nødvendigt, og lade det være op til en Web Service at nivellere sit svar, baseret på hvor meget data en klient sender. Denne fleksibilitet baserer sig i den træstruktur som et XML dokument modellerer, hvor et element kan findes på samme plads, selv om det har child elementer, som en service ikke forventer. Denne søgning i XML, og valideringen af data, udføres ved hjælp af flere støtte teknologier, som ikke er en del af dette projekt. Men det er værd at bemærke, at også disse støtteteknologier (XSLT, XPath, XML Schema m.fl.) vedligeholdes af W3C og således ligeledes er frit tilgængelige, og uden for et enkelt firmas kontrol. En af grundene til at Web Services er så udbredte som de er, er at de baserer sig på disse åbne standarder. W3C har ingen kommercielle interesser i udnyttelsen af de standarder de definerer, og der er derfor ingen risiko for at de pludselig ønsker at gå i en anden retning end tidligere. Det at der ikke er en fast ejer af en teknologi, gør det mere attraktivt at implementere den, enten som separate produkter, eller i eksisterende programmeringssprog [30]. Der findes da også understøttelse for Web Services i alle større programmeringssprog. Med denne understøttelse på plads giver XML en platformsuafhængig måde at repræsentere og udveksle data, og Web Services er det interface der gør udvekslingen ensartet og let. [21] Samlet set har man altså et meget simpelt setup, hvor et anerkendt dataformat benyttes til udvekslingen af data, og almindeligt udbredte protokoller sørger for kommunikationen. En af de ting man lægger mærke til ved Web Services, er da også den udprægede enkelhed der præger de grundlæggende specifikationer. Det virker som om intentionen har været at skære helt ind til benet, og gøre det så simpelt som muligt. Et af de steder der er tydeligt, er i valget af protokol. Til at overføre ovenstående XML benyttes SOAP, som i sig selv er XML baseret. Funktionaliteten i SOAP er meget begrænset, og beskæftiger sig slet ikke med selve netværkskommunikationen. Til denne del er der allerede et verdensomspændende Internet, og ved at lade SOAP operere over de gængse internetprotokoller sikrer man sig et omfattende, vedligeholdelsesfrit kommunikationsgrundlag [31] Simple Object Access Protocol Simple Object Access Protocol (SOAP) er i princippet en simpel mekanisme til at håndtere de strukturerede informationer i et XML dokument mellem distribuerede systemer via Internettet og dermed HTTP protokollen, hvilket gør SOAP til en ideel måde at transportere data på når det drejer sig om Web Services. En af fordelene ved SOAP er netop at det er uafhængigt af 12

14 underliggende transportlag og kan implementeres til at understøtte forskellige protokoller. Det er blot HTTP protokollen som pr. standard skal være implementeret. Man kan generelt opdele en SOAP besked i 4 dele: SOAP envelope SOAP header SOAP body SOAP fault En SOAP besked sammenlignes ofte med en almindelig kuvert 3.2, og hvor en almindelig kuvert indeholder et brev, indeholder SOAP beskeden et XML dokument med data. Modtageren på brevet svarer til SOAP beskedens header og selve kuverten svarer til envelope delen (deraf også navnet). Fault delen af en SOAP besked falder lidt udenfor analogien, men det er nødvendigt at have en plads til eventuelle strukturelle fejl. Figur 3.2: Strukturen i en SOAP besked Envelopen er en obligatorisk del af SOAP beskeden og indeholder forskellige overordnede indstillinger såsom hvilken type indkodning der skal benyttes. 13

15 Det er ligeledes Envelope delen der fortæller hvornår beskeden starter og s- lutter. Man kan derfor anskue Envelope delen som en slags indpakningsmekanisme [2]. Header delen er frivillig at medtage i en SOAP besked, og kan i nogle tilfælde eksistere flere steder på en gang. Derudover kan Headeren tilføre yderligere funktionalitet til SOAP som på nuværende tidspunkt ikke eksisterer, det værende transaktioner, sikkerhed, QoS m.m. Det kræver dog at disse bliver udviklet og standardiseret, og indtil det sker, har Header delen ikke den store relevans i forhold til Web services. Body-delen er som Envelope en påkrævet del af en SOAP-besked, og skal komme umiddelbart efter Headeren såfremt denne eksisterer. Det er ikke uden grund at denne del er påkrævet idet at det er her de data der skal overføres fra et system til et andet er placeret i form af XML. Derudover indeholder body-delen samtidig XML-skemaet til at analysere betydningen af XML-dokumentet [3]. Ved hjælp af SOAP har man altså opbygget et framework som fastlægger en række regler for opbygningen af XML-dokumenter der skal transmitteres over netværket, og på trods af at SOAP i sin oprindelse blev udviklet til at indkapsle RPC-kald, er transportprotokollen, netop i kraft af sin uafhængighed af operativsystem samt programmeringssprog, ved at blive en de facto standard indenfor Web Services. For at summere op, så er de egenskaber som XML og de andre åbne standarder bidrager med til listen over SOA s løfter, følgende: Platformuafhængighed Et fast, simpelt interface Et fleksibelt data format En simpel og problemfri protokol Disse egenskaber er dog ikke nødvendigvis fordele i sig selv. Fordelene er det der kan afledes af disse egenskaber, hvor man for eksempel i platformuafhængighedens tilfælde opnår en større grad af frihed i forhold til valg af hardware, styresystemer og programmeringssprog [30]. Dette kan både omsættes til økonomiske fordele, og til tidsmæssige besparelser i udviklingshastighed og time to marked. Men der er ikke nogle direkte sammenhæng mellem disse tekniske egenskaber, og så de fordele som tilknyttes SOA i litteraturen. Det virker som om at det ligger implicit i disse tekniske egenskaber, at de fordele der efterfølgende nævnes, kan argumenteres som eksisterende. Men der gøres generelt ikke noget forsøg på at gøre dette eksplicit. 14

16 3.2 Service-baseret design Løs kobling Som nævnt tidligere har vi valgt at fokusere på SOA som implementeres ved hjælp af Web Services. Konceptet omkring det at have services i applikationer er som sådan ikke noget nyt idet at disse, som komponenter, kan anskues som en række byggeklodser der samlet set udgår den fulde applikation. Web Services er, til forskel fra komponenter, selvstyrende. Det betyder at hver Web Service har ansvar for sit eget domæne og at en Web Services omfang er begrænset til at dække en specifik forretningsproces. En Web Service-baseret SOA vil derfor bestå af en række isolerede komponenter ofte kun bundet sammen af en standard (Internet)-kommunikationsprotokol, hvilket åbner muligheden for at implementere et løst koblet system [5]. Løs kobling er ikke noget nyt koncept, og har lige siden Objektorienteret udviklings begyndelse spillet en væsentlig rolle i veldesignet softwareudvikling [4], og der er derfor allerede etableret en bred enighed om at det er hensigtsmæssigt at stræbe efter en løs kobling Universal Distribution Discovery and Interoperability Rent teknologisk er der flere årsager til at det er muligt at opnå denne løse kobling i en SOA. Krafzig et al. [6] argumenterer for at den løse kobling opnås gennem brugen af Web services ved hjælp af den dynamiske måde som UDDI kan opdage og binde andre Web services på. Løs kobling er i sig selv ikke nogen fordel. Der opstår derimod en række fordele i kølevandet på den løse kobling som arkitekturen kan benytte sig af og det er disse fordele som der fokuseres på i dette afsnit. For at opnå denne løse kobling er det dog nødvendigt at finde de Web Services som man ønsker at benytte. Der er med andre ord brug for en måde at offentliggøre sine Web Services, således at andre kan finde og bruge dem. Denne offentliggør-forespørg-forbind kombination er en vigtig del af den serviceorienterede arkitektur og er illustreret på figur 3.3. Bindeledet mellem service-leverandøren og service forbrugeren kaldes Service registeret og et eksempel på dette er det såkaldte UDDI. For at forstå hvorledes UDDI fungere kan man sammenligne det med De gule sider i en telefonbog, som indeholder en omfangsrig liste af virksomheder samt en række oplysninger som gør det muligt at tage kontakt til disse. På samme måde indeholder UDDI en liste af virksomheder samt adresser på de Web Services som de stiller til rådighed for andre virksomheder at benytte. Dette foregår ved at en service udbyder registrerer sin Web Services WSDL-dokument i UDDI en. Herefter har service forbrugere mulighed for at forespørge UDDI en om en konkret Web Service. UDDI en returnerer en adresse til service udbyderens WSDL-dokument. På baggrund af WSDL 15

17 Figur 3.3: Offentliggørelse af Web Services dokumentet har service forbrugeren nu mulighed for at initialisere kontakten til Web Servicen og data-udvekslingen kan foregå. Idet at UDDI i sig selv kan implementeres som en Web Service kan denne tilgås fra et hvilken som helst stykke software arbejde sammen med UDDI, og selve UDDI ens WSDL-dokument er det eneste som det kræves er kendt på forhånd. Dens største offentlige UDDI service findes på og opretholdes af en række af de største IT-virksomheder såsom HP, IBM, SAP og Microsoft hvor alle virksomheder frit kan registrere sine Web Services. Derudover findes der ligeledes et dansk UDDI register [7] som indeholder Web Services for godt 100 danske virksomheder heriblandt Danske Statsbaner, Erhvervs og Selskabsstyrelsen og KMD A/S. Et sådan offentligt serviceregister er ikke en nødvendighed, men benyttes ofte når man har behov for en Web Service hvor man ikke kender til en specifik virksomhed som tilbyder denne. Har man derimod en samarbejdspartner som på baggrund af en indbyrdes aftale tilbyder en række Web Services er der ikke behov for et sådan offentligt register, men i stedet nogle lokale virksomheds-registrer. Der findes forskellige måder dette kan være implementeret på og et eksempel kunne være gennem et såkaldt Partnerkatalog- UDDI. Et sådant UDDI er som oftest placeret så den kun kan tilgås internt i virksomheden. Virksomhedens applikationer benytter tidligere nævnte service WSDL-definitioner til at benytte de enkelte Web Services. Derudover 16

18 indeholder UDDI en som oftest kun på forhånd godkendte samarbejdspartnere, hvilket giver væsentlig større sikkerhedsniveau for brugen af Web Services. UDDI er utroligt vigtigt for udviklingen af Web Services, idet det er igennem netop UDDI at disse kategoriseres og indekseres. Man kan sammenligne UDDI med de velkendte søgemaskiner som findes på Internettet. Før disse kom til var det utroligt svært at finde den information man skulle bruge medmindre man havde specifikke websites, hvor man vidste at informationen kunne findes. Ligeledes vil Web Services uden brug af UDDI være spredt udover det hele og med mindre virksomheden ved hvor de skal lede efter specifikke Web Services vil det være en utrolig kompleks affære at finde de Web Services der tilfredsstiller deres krav Hurtigere udvikling Et af de løfter som SOA tilhængere krediterer arkitekturen for, er øget udviklingshastighed. Dette løfte er et produkt af den førnævnte løse kobling [8], hvilket blandt andet skyldes at de enkelte services kan designes og udvikles sideløbende, uden indgående kendskab til andre services. Et væsentligt kriterium ved begrebet en service, er jo netop at den ikke bør have kendskab til, eller være afhængig af, hvorledes andre services opfører sig. Opnår man dette kriterium er det ifølge Newcomer muligt at lade den udvikler, som bedst kender til den ønskede funktionalitet, udvikle den pågældende service, uden kendskab til de andre services. Det samme gør sig gældende for brugen af allerede udviklede Web services. Fordi Web Services er udviklet som komponenter kan disse, ifølge Newcomer, benyttes uden kendskab til implementeringsdetaljer, men blot semantikken. Den løse kobling gør det ligeledes lettere at udvikle og afprøve prototyper. Ved ikke direkte at have kompileret et givent interface ind i sit program eller web service, er det let at udskifte en service med en anden, for at teste ny funktionalitet. Det samme gør sig gældende ved opdateringer og fejlrettelser, der så længe servicen udfører det samme arbejde som klienten forventer, ikke behøver blive kommunikeret til andre end driften. Dette giver virksomheden mulighed for at være mere innovativ på et hurtigere og mindre omkostningsfuldt plan og åbner samtidig muligheden for nye markedsandele [11]. Det at man forsøger at samle fælles funktionalitet i en service, i stedet for at det optræder i mange forskellige delsystemer, har også den fordel at det er lettere at fejlrette kode. Fordi klienten ikke behøver at blive påvirket af nye versioner af en service, og kode kun skal rettes et sted, er det langt hurtigere at idriftsætte en fejlretning end hvis koden findes mange steder, og klienten måske endda er kompileret direkte op mod den binære servers funktionalitet. Et af de argumenter som gennemsyrer det meste af litteraturen omkring SOA, er den synergieffekt der opnås, desto mere man satser på services. 17

19 Desto flere man udvikler, og derved baserer væsentlige dele af ens kodebase på services, desto hurtigere bliver det at udvikle efterfølgende services, fordi de kan genbruge eller basere sig på de allerede udviklede dele. Ideen er meget relateret til software moduler, JavaBeans og lignende initiativer, men fordi web services er platformuafhængige, er de brugbare på tværs af alt kode både internt i virksomheden, og for partnere og kunder. Man er altså her i den modsatte situation med hensyn til investering i IT end man plejer, hvor ledelsen ofte er nervøs for om man får valuta for en given investering. I dette tilfælde er det næsten omvendt, hvor desto mere man udvikler, desto større værdi får den nye funktionalitet, plus det allerede eksisterende bliver mere værd Fleksibilitet Udover hurtigere udvikling bliver man i litteraturen ofte lovet en øget fleksibilitet når man vælger at skifte til en service-orienteret arkitektur. Den øgede fleksibilitet skyldes ifølge flere forfattere herunder Barry [12] blandt andet at Web Services er mere udbredt i software produkter og udviklingssprog end tidligere. Men også den konstante forandring som ikke kun præger IT branchen, men stort set også alle andre former for forretnings-områder, gør det utrolig vigtigt for ethvert firma at kunne tilpasse sig disse forandringer. Ifølge Newcomer gør SOA det betydeligt lettere at og mindre omkostningsfuldt at rekonfigurere og tilpasse, i dette tilfælde Web Services, til at imødegå nye og uventede krav. Dette opnås på baggrund af blandt andet 3 efterhånden velkendte elementer: Løs kobling, åbne standarder samt simple interfaces [16]. At løs kobling skulle gøre arkitekturen mere fleksibel begrundes med at der med løs kobling generelt opnås et mindre kompleks system med færre afhængigheder. Med færre afhængigheder bliver systemet ligeledes lettere at vedligeholde hvilket igen er med til at gøre systemet mere fleksibelt [13]. Løftet omkring fleksibilitet med hensyn til åbne standarder opretholdes hovedsageligt på baggrund af brugen af XML, hvilket er omtalt tidligere i dette kapitel. XML s fleksibilitet gør samtidig teknologien til en af de bedste standarder til at løse de problemer der opstår i forbindelse med applikationers diversitet. XML s fleksibilitet er dog muligvis også teknologiens største problem netop fordi at effektiv integration og data-management kræver højniveau datastrukturer og formater. Det bevirkede at der eksisterer en større mængde højniveau-standarder som forsøger at adressere disse problemer, hvilket betød at det tog lang tid at standardisere endda kerneelementer til specifikationen af XML-baserede datatyper, såsom DTD s og Schema s [14]. Sidst men ikke mindst kan der opnås stor fleksibilitet ved at sørge for at holde interfaces på de enkelte delkomponenter, i dette tilfælde Web Services, simple. Lokale ændringer i en enkelt Web Service må ikke tillades at have 18

20 OO-arkitektur Opbygning af objekter er let Udvikling af genbrugelige objekter af høj kvalitet er kompliceret Genbrug af samlinger af objekter og objekt-frameworks er moderat kompliceret SO-arkitektur Opbygningen af services er let Udvikling af genbrugelige services af høj kvalitet er kompliceret Genbrug af services er simpelt Tabel 3.1: Objektorienteret vs. Service-orienteret arkitektur [18] påvirkninger på resten af systemet. Det betyder at så længe ændringerne i enkelte Web Services ikke har nogen indvirkning på selve den funktionalitet som komponenten udfører, må dette ikke påvirke processer eller andre Web Services udenfor denne. Udviklingen af interfaces til Web Services skal derfor være generisk. [15] Krafzig et. al. gør dog samtidig særligt opmærksom på at det, på trods af den øgede fleksibilitet som SOA automatisk tilbyder, kræver utrolig dygtige udviklere at opnå dette Genbrugelighed Et andet løfte som man uomtvisteligt vil støde på i en gennemgang af SOA litteraturen er løftet om et højt niveau af genbrugelighed. Dette løfte har sit udspring, ligesom løftet omkring hurtigere udvikling, i den løse kobling. Ifølge Newcomer vil en løs kobling gøre det muligt ikke blot at genbruge Web Services i forskellige applikationer, men ligeledes på tværs af platforme. Man er altså ikke bundet til at udvikle sin applikation på den samme platform som de Web Services man benytter, men kan benytte den platform som udviklerne har det største kendskab til eller som passer bedst ind i resten af en eksisterende applikations-portefølge. Et sidste argument angående genbrugelighed er Newcomer s påstand om at genbrugelighed i en SOA er lettere at håndtere og bruge end genbrugelighed i en objekt-orienteret arkitektur. Argumenterne for dette er oversat i tabel 3.1. Som det ses adskiller den serviceorienterede arkitektur sig ifølge Newcomer fra den objektorienterede, ved at det er svært at benytte de komponenter som der er udviklet ud fra sidstnævnte arkitektur. Dette skyldes ifølge Newcomer at det kræver en dybdegående viden omkring arv, polymorfi, templates m.m. at genbruge komponenter baseret på den objektorienterede arkitektur hvorimod services er væsentlig lettere at genbruge i kraft af Business Process Management (BPM) og Web Service-Business Process Execution Language(WS-BPEL), samt at der ikke stilles krav til den tekniske platform. BPM er nøjagtigt hvad det lyde til. Et værktøj til at identificere, modellere samt udvikle forretningsprocesser i en virksomhed både med hensyn til menneskelig interaktion og IT-systemer. BPM er ikke noget nyt som er opstået i forbindelse med Web Services men har, ligesom størst- 19