Door Dik Bijl, Enterprise Architect, Microsoft Nederland
In dit derde artikel over SOA ga ik dieper in op de beginselen en principes van SOA. De beschrijving geldt nog steeds zowel voor de wereld van de IT als voor de reële wereld om ons heen.
Het is mijn bedoeling om daarbij aan te tonen dat de IT-wereld met SOA niet veel meer doet dan het navolgen van de reële wereld. En dat is een zeer krachtig argument in de stelling dat SOA niet zomaar een van de vele IT-hypes is en dat met SOA in de IT-wereld de business optimaal ondersteund kan worden. Het geeft ook aan dat, mits men de juiste ‘taal' hanteert, SOA prima moet kunnen worden uitgelegd aan stakeholders in de business.
De vier basisprincipes van SOA
De werkdefinitie van SOA uit deel 1 is misschien wat complex geformuleerd, maar de kern er van is vrij simpel: het gaat om onafhankelijke eenheden (‘services') met hun eigen gedrag en capaciteiten (‘capabilities') die op de een of andere wijze met elkaar gekoppeld worden om samen een stuk werk te verrichten (‘cooperative work').
Dat koppelen gebeurt door het met elkaar uitwisselen van berichten (en in de reële wereld ook: goederen, diensten en geld). Een bericht wordt geproduceerd binnen een service en vervolgens gestuurd naar een andere service. Vaak zal zo'n bericht de vorm hebben van een verzoek of opdracht (‘request') of een antwoord op een verzoek (‘reply), maar er zijn ook andere berichttypen mogelijk.
1. De grens van de service is duidelijk
Je weet heel goed wanneer je binnen een service bent en wanneer je er buiten staat. De enige manier om een service van buiten af aan te spreken is door het sturen van een bericht en de enige manier waarop een service een (re)actie van binnenuit op de buitenwereld kan ondernemen is door het sturen van een bericht.
Een bericht, laten we zeggen van het type ‘verzoek', komt van buitenaf de service binnen. Het verzoek wordt binnen de service in behandeling genomen - mits het verzoek voldoet aan bepaalde randvoorwaarden; zie verderop - en leidt tot een bepaalde (trans)actie binnen in de service.
Het resultaat van die (trans)actie kan zijn dat er een nieuw bericht (een antwoord) binnen die service wordt geproduceerd en vervolgens naar buiten worden gestuurd en geadresseerd aan de service van wie het verzoek afkomstig was. Daarbij is steeds duidelijk waar de grens van de service ligt en wanneer het bericht zich buiten of binnen de service bevindt.
2. Services zijn autonoom
Services werken samen met andere services, daar ontlenen ze hun bestaansrecht aan. Maar iedere service is op zich autonoom. Waar de service gelokaliseerd is, hoe zij ingericht en beheerd wordt, met welke technologie ze is vervaardigd; dat alles wordt in principe autonoom bepaald. Ook hoe de service zich verder ontwikkelt staat los van de andere services.
Als de service succesvol is, dan zal zij waarschijnlijk uitbreiden, een hogere beschikbaarheid, betere kwaliteit en misschien een lagere prijs bieden. Als ze niet succesvol is, dan zal ze pogingen in het werk stellen de propositie te verbeteren en in het slechtste geval afsterven, maar daarbij sleept ze in theorie niemand in haar val mee.
3. Services delen alleen schema en contract
Om services met elkaar te laten samenwerken hoeven ze niet alle ‘ins' en ‘outs' van elkaar te weten; liever niet eigenlijk. De interne organisatie van de service is niet relevant voor de buitenwereld.
Wel relevant is de ‘taal' die ze spreekt en de ‘manier' waarop je met de service kunt communiceren. Het schema beschrijft de vorm van de individuele berichten waarmee de service aangesproken kan worden. Je kunt daarbij denken aan een invulformulier om een verzoek of opdracht bij de service te plaatsen.
Het contract definieert de toegestane dialoog of de volgorde van individuele berichten die je met een service kunt uitwisselen. Denk aan de volgorde: invullen en opsturen kooporder, bevestigen order en geven van leveringstermijn, versturen van order (met pakbon), factureren van order en betalen van order. Die twee zaken moet je weten van de service om ermee te kunnen werken en staat helemaal los van de interne organisatie van die service of wel hoe die service met de opdrachten omgaat.
4. De samenwerking tussen services is gebaseerd op ‘policies'
Je bent dan misschien niet geïnteresseerd hoe de service intern met jouw opdrachten omgaat, je wil wel het een ander weten van het kwaliteitsniveau van de service en de algemene voorwaarden van de service. Onder welke voorwaarden zal de service een verzoek of opdracht in behandeling nemen en hoe lang duurt het voor er een antwoord komt. Dit soort zaken bepaalt mede of de buitenwereld met de service ‘zaken' wil doen. Het heeft niet te maken met de inhoud van de service, maar meer de zaken er omheen.
Figuur 1 geeft de basisprincipes van de service weer. Een service is een duidelijk definieerbare entiteit waarmee men communiceert via berichten die moeten voldoen aan het door de service opgestelde schema en contract en die bestuurd worden door policies zoals algemene voorwaarden en kwaliteitsniveaus.
Figuur 1: Basisprincipe service
Als voorbeeld van een service in de reële wereld kun je denken een postorderbedrijf. Een postorderbedrijf werkt asynchroon. Hoewel het asynchroon werken geen noodzakelijke voorwaarde is voor een service, is het wel een ‘best practice'.
Werk, in dit geval een orderformulier, komt het bedrijf binnen via de traditionele post of via het internet (duidelijke grens). Het orderformulier moet voldoen aan de standaard die het postorderbedrijf heeft opgesteld en de juiste gegevens bevatten (schema & contract). In de algemene voorwaarden staat misschien opgenomen dat producten binnen 30 dagen geretourneerd kunnen worden, mits in originele verpakking en het postorderbedrijf belooft dat orders binnen 5 werkdagen worden uitgeleverd (policies).
Als het postorderbedrijf succesvol is, dan zal zij verder uitbreiden en misschien wel meerdere vestigingen opzetten. Misschien dat daarbij de interne organisatie compleet anders wordt ingericht. Voor de consument maakt dat niet uit, zolang het maar vanuit de luie stoel op min of meer dezelfde wijze zijn producten kan bestellen, ontvangen, betalen en bij ontevredenheid: terugsturen (autonomie).
Coördinatie en orkestratie
Het postorderbedrijf wisselt niet alleen berichten uit met de klanten, maar ook producten. Hoe dat postorderbedrijf aan die producten komt is ‘verborgen' voor de klant en vanuit zijn perspectief niet interessant.
Voor het postorderbedrijf is het dat natuurlijk wel en daarin moet het postorderbedrijf een flinke hoeveelheid werk verzetten en coördineren. Het postorderbedrijf moet een goed en aantrekkelijk assortiment samenstellen dat tegen een zeer concurrerende prijs aanbieden. Het moet de markt onderzoeken om te zien wat wel en wat niet in de mode is, het moet bepaalde leveranciers uitzoeken en er contact mee leggen en weer andere van zich afhouden. Het moet prijsonderhandelingen voeren, afspraken maken over levertijden en de nazorg van producten en zorgen dat de producten op tijd bezorgd worden. De voorraad moet voldoende zijn, maar ook niet te groot, etcetera.
Veel werk zal uitbesteed worden zoals de logistiek en wellicht het marktonderzoek. Af en toe zal het eenmalige partijen opkopen via tussenhandelaren en die tegen afbraakprijzen aanbieden. Ook met zijn toeleveranciers communiceert het postorderbedrijf via berichten.
Met andere woorden om te zorgen dat de consument vanuit zijn luie stoel de producten geleverd krijgt, moet het postorderbedrijf veel werk verzetten en ook uitzetten/uitbesteden. Daarvoor is coördinatie en orkestratie van de totale bedrijfsvoering nodig en moet het postorderbedrijf als retailer goed inzicht hebben in en zijn invloed aanwenden op de hele keten van de consumentenproducten uit het assortiment.
Figuur 2: orkestratie van services
Figuur 2 geeft de hier beschreven situatie in abstracte termen weer: de orkestratie van services. De bovenste samengestelde service is in dit geval het postorderbedrijf. Naar zijn klanten toe is dat een enkelvoudige service, maar in werkelijkheid is het een samengestelde service die diverse andere enkelvoudige en samengestelde services orkestreert tot een goed werkend geheel. Elk van de enkelvoudige services specialiseert zichzelf waarin het goed is en moet daarbij concurreren met andere services die eenzelfde soort service bieden.
SOA in de IT-wereld
Aan het slot van dit artikel maak ik een sprong naar de IT-wereld. Figuur 3 geeft de hier besproken SOA-principes weer voor IT-applicaties. Ik zal beschrijven hoe de figuur gelezen moet worden.
Figuur 3: SOA-principes voor IT-applicaties
Een applicatie (midden boven: het startpunt) bestaat uit meerdere services die (rechts af onder) met elkaar communiceren door het uitwisselen van berichten en die (links af) geregeerd worden door beleidsregels (Policies) en gebonden zijn door contracten. Elk van de services beheert de status van de gegevens/database die relevant zijn voor die service (rechts af boven) en die in principe afgesloten zijn voor de buitenwereld.
De policies hebben betrekking op de operationele eisen zoals veiligheid, beschikbaarheid, randvoorwaarden voor deelname; kortom alles wat met het serviceniveau (SLA) en de algemene voorwaarden van de service te maken heeft. Zo kan de service opleggen dat het alleen berichten in behandeling neemt die ‘encrypted' zijn en waarvan de zender is geauthenticeerd.
Het contract bevat alle berichten die met de service uitgewisseld kunnen worden en in welke volgorde dat moet (‘Message Exchange Pattern') en het contract bevat de gegevenstypen van elk van die berichten (‘Schema'). Elk bericht tenslotte moet voldoen aan het schema en passen binnen het message exchange pattern.
Vanaf het volgende artikel spreken we alleen nog maar over services binnen de IT-wereld. De link met de reële wereld is afdoende aangetoond, lijkt me. Het vierde artikel bespreekt de webservicesarchitectuur. Webservices zijn een manier om een SOA binnen de IT-wereld vorm te geven. Het is zeker niet de enige manier, maar het is wel een zeer goede - eigenlijk de enige - kandidaat om de standaard te worden bij het inrichten van het applicatielandschap op SOA-basis. | 
