Modellering van SOA: een noodzaak

Ontwikkeling van services vindt nu veelal plaats vanuit softwareontwikkelingsperspectief. Men maakt ontwerpen, waarna programmatuur wordt ontwikkeld, volgens welke methode dan ook. Tijdens programmatuurontwikkeling bieden ontwikkelomgevingen de mogelijkheid om webservices te publiceren. Alle noodzakelijke open standaarden worden gepubliceerd en zijn extern benaderbaar.

Voor veel 'kleine' componenten werkt dit. Als ik bijvoorbeeld de temperatuur wil weten, dan kan ik hiervoor een component met een sensor en zijn daarbij horende service inrichten. Voor complexere bedrijfssystemen wordt dit lastiger. Daar moet ik weten welke functionaliteit ik als afnemer kan gebruiken om die in mijn dienstverlening te passen. Wanneer mag ik een order annuleren, wat doe ik bij te late leveringen en wat als bij een levering foute artikelen worden geleverd? Dit gedrag moet bekend zijn en is onderdeel van een service van een leverancier.

De ontwikkelwijze om vanuit componenten services te genereren, geheel volgens de soa-benadering, resulteert in gedrag van een systeem dat pas echt bekend is als de webservices gepubliceerd zijn. En dan nog is het gedrag afhankelijk van de technische inrichting van de achterliggende software. In feite volgen we hier nog steeds de component based-benadering, waar componenten met hun gedrag worden ontwikkeld.

Soa moet uitgaan van een ander perspectief. Allereerst moet ik als ontwikkelaar het gedrag van een systeem specificeren. Welke services biedt ik aan, wat zijn de functionele en niet-functionele aspecten die ik bij deze services wil leveren? Bij functionele aspecten horen niet alleen de datastructuren weergegeven als xml-schema, maar ook de samenhang tussen deze interacties. Ook moet ik aangeven als ontwikkelaar hoe de zogenaamde applicatieservices de bedrijfsvoering ondersteunen. Hoe kan ik een order plaatsen, welke webservice moet ik daarvoor gebruiken en wat kan ik terugverwachten?

Niet alleen een gestructureerde benadering om extern gedrag te bepalen is nodig, maar ook architecturele principes met een scheiding tussen bedrijfsmatige dienstverlening en ondersteunende ict-applicatieservices moeten gevolgd worden. Een overgang naar standaarden als WSMO/WSML lijkt dan eenvoudig: vanuit mijn product/dienstcatalogus specificeer ik de applicatieservices en kan een ander die vinden.

Een groot aantal leveranciers ontwikkelt al onderdelen van service engineering workbenches. De grote vraag hierbij is en blijft: welke concepten hanteren ze en hoe zijn die concepten gerelateerd aan technische, open standaarden. Zolang dit niet vaststaat, krijgen we hopelijk nog steeds service engineering workbenches die los van technische standaarden en softwarecomponenten ons in staat stellen deze services te specificeren en te onderhouden.