Wat is service oriented architecture?

Service oriented architecture (soa) komt voort uit het aloude ontwerppara-digma, waarbij aanvraag en reactie zowel onder synchrone als asynchrone toepassingen plaatsvindt. De functies van een toepassing worden in modules opgedeeld en als services voor consument/client-toepassingen gepresenteerd. Het

Wat is service oriented architecture?

Service oriented architecture (soa) komt voort uit het aloude ontwerppara-digma, waarbij aanvraag en reactie zowel onder synchrone als asynchrone toepassingen plaatsvindt. De functies van een toepassing worden in modules opgedeeld en als services voor consument/client-toepassingen gepresenteerd. Het belangrijkste element van deze services is dat hun interface onafhankelijk is van de installatie.

Toepassingsontwikkelaars of systeemintegrators kunnen toepassingen bouwen door een of meer services samen te stellen zonder de onderliggende installaties van de services te kennen. Een service kan bijvoorbeeld zijn geïnstalleerd in .Net of J2EE, en de toepassing die de service consumeert, kan in een ander platform of in een andere taal zijn.

Service oriented architecturen hebben de volgende hoofdkenmerken:

- Soa-services hebben zelfbeschrijvende interfaces in platformonafhankelijke xml-documenten. Web services description language (wsdl) is de standaard die wordt gebruikt om de services te beschrijven.

- Soa-services communiceren met berichten die formeel zijn gedefinieerd via xml Schema (ook wel xsd genoemd). Communicatie onder consumenten en providers of services vindt normaal gesproken plaats in heterogene omgevingen, waarin weinig of geen kennis over de provider aanwezig is. Berichten tussen services kunnen worden beschouwd als belangrijke bedrijfsdocumenten die in een onderneming worden verwerkt.

- Soa-services worden in de onderneming onderhouden door een register die werkt als een verzamellijst. Toepassingen kunnen de services in het register opzoeken en de service aanroepen. Universal description, definition and integration (uddi) is de standaard die voor serviceregisters wordt gebruikt.

Aan elke soa-service is een quality of service (qos) gekoppeld. Sommige belangrijke qos-elementen zijn beveiligingsvereisten, zoals verificatie en autorisatie, betrouwbaar berichtenverkeer en beleid over wie welke services kan aanroepen.

Waarom soa?

De realiteit in it-ondernemingen is dat er een heterogene infrastructuur is qua besturingssystemen, toepassingen, systeemsoftware en toepassingsinfrastructuur. Voor de uitvoering van lopende bedrijfsprocessen worden meestal bestaande toepassingen gebruikt, zodat het van de grond af opbouwen van een nieuwe infrastructuur geen optie is. Bedrijven moeten alert en snel reageren op veranderingen, gebruikmaken van bestaande investeringen in toepassingen en toepassingsinfrastructuur voor nieuwe toepassingen en vereisten, nieuwe kanalen van interactie met klanten, partners en leveranciers ondersteunen en een architectuur hebben die organische bedrijfsvoering ondersteunt. Dankzij de enigszins losse structuur van soa kunnen ondernemingen stukje bij beetje nieuwe services toevoegen of bestaande services upgraden, is het mogelijk die services via verschillende kanalen aan te bieden en kunnen de bestaande enterprise-toepassingen als services worden aangeboden, wat de al gedane investeringen in it-infrastructuur beschermt.

Een onderneming die soa gebruikt, kan een samengestelde supply chain-toepassing maken met behulp van een aantal bestaande toepassingen waarmee de functionaliteit via standaardinterfaces aan de buitenwereld wordt getoond.

Servicearchitectuur

Verschillende consumenten van services kunnen deze services aanroepen door berichten te sturen. Deze berichten worden normaal gesproken door een servicebus omgezet en doorgestuurd naar een geschikte service-implementatie. Deze servicearchitectuur kan een systeem voor bedrijfsregels leveren die in een service of in meerdere services moet worden ingebouwd. De servicearchitectuur levert ook een infrastructuur voor het beheer van services en activiteiten als controle, facturering en registratie. Verder geeft de architectuur ondernemingen de flexibiliteit van alerte bedrijfsprocessen, wordt regelgeving als Sarbanes Oxley (sox) beter nageleefd en kunnen afzonderlijke services worden gewijzigd zonder dat andere services daar last van ondervinden.

Soa-infrastructuur

Ondernemingen hebben voor het uitvoeren en beheren van soa-toepassingen een soa-infrastructuur nodig die deel uitmaakt van het soa-platform. Een soa-infrastructuur moet alle relevante standaarden en vereiste runtime-containers ondersteunen. In de volgende gedeelten worden de afzonderlijke onderdelen van de infrastructuur beschreven.

Soap, wsdl, uddi

Wsdl, uddi en soap vormen de bouwstenen van de soa-infrastructuur. Wsdl wordt gebruikt om de service te beschrijven, uddi om de services te registreren en op te zoeken en soap is de transportlaag waarmee berichten worden uitgewisseld tussen de consument van de service en de provider van de service. Soap is het standaardmechanisme voor webservices, maar voor andere soorten bindingen voor een service worden andere technologieën ingezet. Een consument kan een service opzoeken in het uddi-register, de wsdl voor de service met de beschrijving ophalen en de service aanroepen met soap.

WS-I Basic Profile

WS-I Basic Profile is afkomstig van de Web services Interoperability Organization. Serviceproviders kunnen de Basic Profile-pakketten gebruiken om de compatibiliteit van een service in verschillende platformen en technologieën te testen.

J2EE en .Net

Hoewel J2EE en .Net de dominerende ontwikkelplatforms zijn voor soa-toepassingen, is soa zeker niet beperkt tot deze platforms. Platforms als J2EE bieden ontwikkelaars niet alleen het kader om op een natuurlijke wijze deel te nemen aan de soa, maar bieden door hun aard ook een volwassen en bewezen infrastructuur voor schaalbaarheid, betrouwbaarheid, beschikbaarheid en prestaties. Nieuwere specificaties als Java API voor xml binding (jaxb), voor het verbinden van xml-documenten aan Java-klassen, Java api voor xml registry (jaxr), voor de standaardinteractie met de uddi-registers, en Java api voor xml-based remote procedure call (xml-rpc), voor het aanroepen van externe services in J2EE 1.4, maken de ontwikkeling en implementatie van webservices mogelijk die op alle standaard-J2EE-containers kunnen worden gebruikt, en kunnen tegelijkertijd samenwerken met services op andere platforms als .Net.

Quality of services (qos)

Bestaande bedrijfskritische systemen in ondernemingen worden ingezet voor geavanceerde vereisten op het gebied van beveiliging, betrouwbaarheid en transacties. Naarmate bedrijven steeds vaker servicearchitectuur gaan gebruiken als medium voor het ontwikkelen en implementeren van toepassingen, zullen de basiswebservices als wsdl, soap en uddi niet meer voldoen. Zoals gezegd, zijn deze vereisten ook wel bekend als quality of services (qos). Er worden veel specificaties uitgewerkt die betrekking hebben op qos. Dit wordt gedaan door standaardenorganisaties als het World Wide Web Consortium (W3C) en de Organization for the Advancement of Structured Information Standards (OASIS). Hieronder worden enkele qos-artefacten en verwante standaarden beschreven.

Beveiliging

De beveiligingsspecificatie voor webservices betreft berichtenbeveiliging. Deze specificatie is gericht op de uitwisseling van persoonsgegevens, de integriteit van berichten en de vertrouwelijkheid van berichten. Het aantrekkelijke van deze specificatie is dat deze het gebruik van bestaande standaarden, zoals security assertion markup language (saml), mogelijk maakt voor de beveiliging van webserviceberichten. Webservicebeveiliging is een van de onderdelen waarvoor OASIS zich blijvend inzet.

Betrouwbaarheid

In een standaard-soa-omgeving worden verschillende documenten tussen consumenten en providers van services uitgewisseld. In bedrijfskritische systemen die gebruikmaken van servicearchitectuur is de aflevering van berichten met kenmerken als uitsluitend-eenmalige-aflevering, maximaal-eenmalige-aflevering, verwijdering van dubbele berichten, afleveringsgarantie en bevestiging heel belangrijk. WS-Reliability en WS-ReliableMessaging zijn standaarden die zich bezighouden met betrouwbaar berichtenverkeer. Deze beide standaarden maken nu deel uit van OASIS.

Beleid

Serviceproviders vragen soms van serviceconsumenten om een zeker beleid te volgen in hun communicatie. Een serviceprovider vraagt bijvoorbeeld om een Kerberos-beveiligingstoken om toegang tot de service te verkrijgen. Dergelijke vereisten worden vastgelegd in beleidsverklaringen. Beleid kan uit meerdere verklaringen bestaan. WS-Policy standaardiseert hoe beleid moet worden gecommuniceerd tussen serviceconsumenten en serviceproviders.

Integratie

In een servicearchitectuur kunnen services worden gebruikt voor de integratie van datasilo's, toepassingen en systeemonderdelen. Het integreren van toepassingen betekent dat de procesvereisten, zoals asynchrone communicatie, parallelle verwerking, datatransformatie en compensatie, gestandaardiseerd moeten worden. Bpel4ws of wsbpel (web services business process execution language) is een OASIS-specificatie voor service-integratie, waarin bedrijfsprocessen uit een set discrete services bestaan. Wsbpel maakt nu deel uit van OASIS.

Beheer

Door de groei van het aantal services en bedrijfsprocessen die als services worden gebruikt in de onderneming, wordt het belangrijk een beheerinfrastructuur in het leven te roepen waarmee de systeembeheerders de services in een heterogene omgeving kunnen beheren. Web services for distributed management (wsdm) geeft aan dat elke service die volgens wsdm is geïmplementeerd, door een wsdm-beheersoplossing kan worden beheerd.

Andere qos-kenmerken als coördinatie tussen partners en transacties met meerdere services worden geregeld in de specificaties WS-Coordination en WS-Transaction, ook van OASIS.

Soa is niet gelijk aan webservices

Er lijkt algehele verwarring te heersen over de relatie tussen soa en webservices. In een rapport van marktonderzoeksbureau Gartner van april 2003 maakt Yefim V. Natis het onderscheid als volgt duidelijk: "Webservices gaan over technologiespecificaties en soa is een softwareontwerpprincipe. Met name wsdl van webservices is een voor soa geschikte interfacedefinitiestandaard: dit is het punt waar webservices en soa fundamenteel met elkaar in contact treden." Eigenlijk is soa een architectuurpatroon, terwijl webservices services zijn die worden geïmplementeerd aan de hand van een aantal standaarden; webservices vormen een van de manieren waarop je soa kunt implementeren. Het voordeel van de implementatie van soa met webservices is dat je een platformonafhankelijke benadering krijgt van de toegang tot services en een betere compatibiliteit bereikt naarmate meer leveranciers meer webservice-specificaties ondersteunen.

Voordelen van soa

Het soa-concept is eigenlijk niet nieuw, maar soa onderscheidt zich van bestaande gedistribueerde technologieën doordat de meeste leveranciers soa accepteren en met een toepassings- of platformpakket werken dat geschikt is voor soa. Soa, dat een universele set standaarden heeft, maakt gebruik van bestaande bezittingen of investeringen in het bedrijf en maakt het mogelijk om op bestaande toepassingen nieuwe toepassingen te bouwen. Met soa kunnen veranderingen in toepassingen worden aangebracht zonder dat clients of serviceconsumenten daar iets van hoeven te merken. Met soa is het upgraden van afzonderlijke services of serviceconsumenten mogelijk; toepassingen hoeven niet compleet te worden herschreven en bestaande systemen - die niet meer geschikt zijn voor de nieuwe bedrijfseisen - hoeven niet te blijven bestaan. Tot slot krijgen ondernemingen met soa meer flexibiliteit bij het bouwen van toepassingen en bedrijfsprocessen en kunnen zij alerter reageren op veranderingen in de markt.