Modellering van SOA: een noodzaak
Senior innovator
Expert van Computable voor de topics: SOA, Overheid en ICT-branche
MeerOntwikkeling 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.
10-02 Het einde van het begin van cloud en virtualisatie
10-02 De windwakken van de cloud-sector
09-02 Citoto
09-02 Lang leve de hackers!
09-02 Modder gooien in ICT-land
08-02 Reseller verliest slag om het groene huishouden
08-02 Hadoop lijkt een alleskunner
07-02 Hou zicht op de informatie bij HNW
07-02 Eigen werknemer kan ook een vijand zijn
06-02 Krachtenbundeling NGI en TestNet is goede zaak
05-12 Traxion introduceert IAM4Cloud
02-12 Progress breidt RPM-suite verder uit
26-10 Infor presenteert Twitter-ERP
03-10 Macaw zet nieuw servicecentrum op
22-09 SOA en agile kunnen best door één deur
07-07 Compuware neemt Dynatrace Software over
22-06 IBM Rational levert nieuwe ontwikkelingstools
19-04 ROC Aventus: datakoppelingen en zeggenschap
13-04 HP wilde Tibco Software overnemen
31-03 'Ivent heeft te weinig kennis van SOA'
|
|
11-12-08 Modelleringstaal voor SOA begin 2009 klaar
02-12-08 Webdiensten vormen betere middleware
De gecombineerde kracht van JD Edwards en Salesforce.com
De integratie van JD Edwards en Salesforce.com drijft organisaties vaak tot wanhoop. Deze whitepaper beschrijft hoe......


