SOA in de wolken

Een soa stelt u in staat te werken met diensten en modules aangeboden door derden: zogenaamde partner-soa's. Het kostenplaatje is bij dergelijke systemen erg interessant. Er is echter ook een schaduwkant: stabiliteit en betrouwbaarheid van de dienst. Als uw eigen internetverbinding wegvalt of als de systemen van uw soa-partner plat gaan, dan liggen uw applicaties plat en verliest u dus geld.

In een bedrijf tellen uiteraard de zakelijke activiteiten. Alles wat met ict te maken heeft, hoort die zakelijke activiteiten te ondersteunen. Dat is logisch. Desondanks heeft ict jaren als een min of meer onafhankelijke entiteit binnen bedrijven gefunctioneerd. De zakelijke processen functioneerden dan nogal eens ondanks en niet dankzij de aanwezige ict. Service Oriented Architecture of soa integreert de ict-diensten in de ondersteuning van de bedrijfsprocessen. De hele ict-architectuur hoort daaraan aangepast te zijn. Dat vereist een heel ander denkkader bij ict'ers.

In het verleden hebben bedrijven wel vaker geëxperimenteerd met 'distributed computing'. Niet alleen op het gebied van ict, maar ook bij het ontwerpen van de software. Het pijnpunt van veel bedrijfssoftware is dat die slecht of helemaal niet onderling communiceert. Bij soa is die onderlinge communicatie van cruciaal belang. Het is immers de bedoeling dat een bedrijf de beschikbare ict-diensten op het netwerk bundelt en gebruikt zodat ze overeenstemmen met bedrijfsprocessen. Zo krijgen we niet alleen gedistribueerde diensten, maar kunnen we de diverse diensten ook als modules gebruiken om tot een totaaloplossing te komen. Een soa is dus zowel gedistribueerd als modulair.

Standaarden

Er was en is dus een nood aan standaarden. De ict-diensten moeten werkelijk interoperabel zijn, zodat ze onderling kunnen communiceren. Om gebruik te kunnen maken van die ict-diensten, willen we geen specifieke applicatiesoftware draaien. Dat vergroot weer de kans dat bepaalde communicaties niet mogelijk blijken. Moderne soa-ontwikkelingen gaan dan ook steevast in de richting van open standaarden. Web 2.0 hoort daarbij, maar ook uitwisselbare dataformaten zoals XML en bij uitbreiding ODF. In verband hiermee promoot Microsoft uiteraard ook OOXML.

Applicaties en diensten wisselen XML-data uit via standaardprotocollen zoals SOAP (Simple Object Access Protocol). Ook Java-gebaseerde soa-oplossingen zoals IBM's WebSphere werken op basis van XML en SOAP. Dat begon natuurlijk met HTML en Java Service Pages (JSP's). XML en Ajax (Asynchronous JavaScript and XML) en Web 2.0 liggen in het verlengde daarvan. Zelfs Microsoft, dat traditioneel sterk aan zijn bedrijfseigen protocollen vasthoudt, kan er niet langer omheen en biedt oplossingen aan op basis van XML/SOAP. Veel bedrijven zijn druk bezig met ict-diensten en soa's op basis van Ajax. Zo zal Web 2.0 veel gestandaardiseerder, maar tegelijk meer open zijn.

Metadata

Een belangrijk aspect van soa is het gebruik van metadata. Letterlijk is dat immers 'data over data'. Dat helpt het structureren en het naderhand doorzoeken van data. Metadata beschrijft overigens niet alleen karakteristieken van data, maar ook van de diensten zelf. Ook hier komt XML om de hoek kijken, omdat  dat een erg gestructureerde manier is om data op te slaan en voor te stellen. Men noemt dit 'talen'. WSDL (Web Services Decription Language) kan worden gebruikt om diensten mee te beschrijven. Het eerder aangehaalde SOAP beschrijft de communicatieprotocollen tussen de diensten.

Uiteraard evolueert dit nog allemaal. Er zijn echter twee basisvereisten waaraan de implementatie van metadata binnen een soa moet voldoen. Eerst en vooral moet software in staat zijn deze data dynamisch te configureren via ontdekking en insluiting van gedefinieerde diensten. Tegelijk dient software de coherentie en integriteit te waarborgen. Ten tweede moeten systeemontwerpers in staat zijn de metadata met een minimum aan kosten en inspanning te begrijpen en te beheren. Idealiter zult u applicaties die gebruik maken van de soa tot stand kunnen brengen via orchestratie. Dat is de bundeling en het modulair gebruik van diensten. Nieuwe code ontwerpen zal dan minder nodig zijn, wat het dus erg kostenefficiënt maakt.

Modulariteit en prestaties

De bedoeling van een soa is om functionaliteit te bieden via een aantal diensten. U bouwt dan applicaties op basis van deze diensten, door ze naar uw wens samen te voegen en te gebruiken vanuit uw eigen software. Hoe meer van die diensten u gebruikt, hoe minder interfaces u moet gebruiken om bepaalde functionaliteit te implementeren. Een te grote bundeling van diensten of te grote dienstenmodules vermindert uiteraard wel de modulariteit. Dat kan het moeilijk maken deze functionaliteit dan elders te hergebruiken. Een te grote modulariteit zorgt echter voor een groter aantal interfaces. Dat vermindert de prestaties van het geheel. Het is dus kwestie van uw applicaties te ontwerpen met een evenwicht tussen modulair en prestatiegericht gebruik van de soa.

Motorkap

De functiemodules die u samenstelt voor hergebruik in uw applicaties moeten zelfstandig kunnen werken. Er mogen geen interacties zijn tussen de gedefinieerde modules of tussen deeldiensten van een module. Zoiets heet een stelsel van ongeassocieerde evenkniediensten. Het is de bedoeling zelf de interactie van al die diensten te definiëren en zo een applicatie samen te stellen. U kunt het vergelijken met de manier van definiëren van subroutines en functies in klassieke programmeertalen. Maar dit staat natuurlijk op een veel hoger niveau. De diensten zelf zijn natuurlijk nog wel ontworpen door programmeurs met behulp van de traditionele middelen en programmeersystemen. De soa zelf is een abstractie daarvan. Als applicatieontwikkelend gebruiker van die soa ziet u alleen de diensten en daar werkt u mee. Alles wat onder de motorkap zit blijft verborgen.

Losse schakels

In klassieke programmeertalen worden de verschillende geprogrammeerde modules vast samengebonden met behulp van een linker naar de uiteindelijke applicatie. Een soa werkt ook op basis van het integreren van functies of diensten binnen modules en het gebruiken van deze modules binnen een applicatie. De koppeling is hier echter los in plaats van vast. Daardoor krijgt u een veel dynamischer opgebouwd stelsel van diensten en dienstmodules binnen applicaties. Het stelt u ook in staat te werken met diensten en modules aangeboden door derden: zogenaamde partner-soa's. We zien dit in toenemende mate gebeuren: allerlei firma's bieden open source diensten en dienstenmodules aan die u kunt gebruiken binnen uw soa. Binnen Microsoft-centrische omgevingen gebeurt dit allemaal binnen .NET. Ook Microsoft biedt zelf al een aantal herbruikbare diensten en dienstenmodules aan. Een dergelijk aanbod van diensten kan gratis of betalend zijn.

In meer algemene omgevingen steunt alles gewoonlijk op Java. Dat zijn dan in feite vertrouwde subomgevingen waarbinnen u uw soa-diensten gebruikt. Het staat u natuurlijk vrij die extra wikkels af te bouwen en rechtstreeks met de diensten te werken. Ook dat zien we meer en meer. Daardoor zouden ondernemingen een soa in gebruik kunnen hebben die werkt met binnenshuis ontwikkelde diensten en modules, maar ook met buitenshuis ontwikkelde en zelfs draaiende diensten. Een soa met buitenshuis draaiende diensten heet tegenwoordig een 'cloud', al slaat dat woord meestal op puur webgebaseerde diensten. Webbasering kan echter prima in een soa: uw applicatie is dan een bundeling van webdiensten waar uw gebruikers met behulp van hun webbrowser gebruik van maken. Dat is een ontwikkeling waar al jaren erg veel interesse voor bestaat, omdat het clientplatform dan 'dun' (thin clients) kan zijn. Het vereenvoudigt ook de ondersteuning en het onderhoud. Het is verder goedkoper om aan de clientzijde alleen maar met een webbrowser te werken.

Vereisten

Een soa is door zijn dynamiek bijna 'levend'. De diensten en dienstenmodules die in zo'n soa zitten kenmerken zich dan ook door herbruikbaarheid, modulariteit, samenstelbaarheid, componenteerbaarheid en interoperabiliteit. De belangrijkste hoofdvereiste vloeit daaruit voort: standaardisatie en naleving van normen en standaarden. Ook een hoofdvereiste is het identificeren en categoriseren, provisioneren, leveren, bewaken en opvolgen van diensten. Een soa en alle onderdelen daarvan moet dus met andere woorden behoorlijk beheerd worden. Omdat diensten vrijwel overal gebruikt kunnen worden, geldt dat natuurlijk ook voor heel veel data. Het is dus logisch om te voorzien in een bronnenfederatie: een gefedereerd datawarenhuis (data warehouse). Dat zorgt ervoor dat data en diensten altijd bereikbaar en bruikbaar zijn.

Omdat u niet kunt voorspellen welke nieuwe functionaliteit in de toekomst ontwikkeld zal worden op basis van beschikbare diensten en data, spreekt het ook vanzelf dat elke data-element in een gemeenschappelijk bedrijfsformaat opgeslagen en opgevraagd moet worden. Omdat diensten per definitie platformonafhankelijk zijn (Microsoft niet te na gesproken), komt hier ook weer de noodzaak aan open standaarden tot uiting. Voor documenten hebben we XML en het daarop gebaseerde ODF. Er bestaan ook volledig open formaten voor afbeeldingen (PNG) en multimedia zoals audio en video (Ogg-Vorbis en dergelijke). Een keuze voor die formaten betekent dat u ze altijd en overal kunt afspelen en dat u nooit voor onaangename verrassingen inzake patenten of licenties komt te staan.

Partner-soa’s

Een voorbeeld van partner-soa's zijn de diensten die zowel Amazon als Google aanbieden. In het geval van Amazon kunt u er eigen webwinkels mee uitbouwen. In het geval van Google krijgt u zoekfunctionaliteit en kantoorapplicatiefunctionaliteit. Het systeem van Amazon is gebaseerd op hun eigen webwinkelsoftware die natuurlijk al jaren gedebugd is. Ook Ebay is bezig met soa-diensten uit te bouwen, dan uiteraard voor hun specialiteit: webveilingen.

Het kostenplaatje is bij dergelijke systemen erg interessant. Er is echter ook een schaduwkant: stabiliteit en betrouwbaarheid van de dienst. Als uw eigen internetverbinding wegvalt of als de systemen van Amazon of Google of uw andere soa-partner plat gaan, dan liggen uw applicaties plat en verliest u dus geld. Zowel Amazon als Google zijn onlangs in het nieuws gekomen omdat hun servers urenlang platlagen. Maar ook voor diensten die u binnenshuis draait, stelt zich de vraag hoe u stabiliteit en betrouwbaarheid kunt verzekeren.