De (on)zin van SOA 2.0
Er is een tijdje geleden nogal opschudding ontstaan over de term SOA 2.0. Deze term is een tijdje geleden gelanceerd door Oracle en Gartner. Volgens Oracle en Gartner zou SOA 1.0 gaan over client-server stijl interacties, terwijl de nieuwe SOA een combinatie is van Event Driven Architecture (EDA) en SOA.
Maar op basis waarvan concluderen de ‘bedenkers’ van SOA 2.0 dat SOA 1.0 alleen client-server interactie betreft? Als er gekeken wordt naar de manier waarop services communiceren is er inderdaad een zendende partij (client) en ontvangende partij (server). Maar deze rollen kunnen zomaar omwisselen, bijvoorbeeld in het geval van een callback door een asynchrone service. Hierdoor lijkt de term client-server voor SOA 1.0 dan ook nogal arbitrair.
SOA, de naam zegt het al, gaat over architectuur. Het is vreemd om versienummers toe te kennen aan architecturele concepten en/of patterns. Zeker gezien het feit dat SOA een gehypte marketing term is voor een architectureel principe dat al jaren bestaat. SOA gaat immers over het zo onafhankelijk mogelijk koppelen (loosely coupling) van software componenten, met als doel deze componenten te herbruiken. Iets waar bijvoorbeeld de Object Management Group (OMG) in 1989 al mee bezig was, alleen heette het toen CORBA. Alleen in plaats van componenten praten we tegenwoordig over services. Was CORBA dan SOA 0.1?
SOA 2.0 is eigenlijk niets anders dan een andere insteek voor service georiënteerde architectuur. De toevoeging 2.0 doet aan als een slechte poging om mee te liften op de Web 2.0 hype. Het is een slimme marketing truuk om mensen te verwarren door SOA als een technologie in plaats van architectuur te positioneren.
Of we het nu eens zijn over de naam of niet, zowel EDA, SOA als een combinatie van beide bestaan al een langere tijd. Maar waarom komen Oracle en Gartner dan nu ineens met het concept van SOA 2.0?
Misschien kan het verklaard worden door de verschillende opvattingen van ICT professionals die veel te maken hebben met SOA. Aan de ene kant hebben we de opvatting dat SOA op zichzelf vanzelfsprekend al een EDA is. In deze opvatting is een gebeurtenis (event) synoniem aan een bericht (message). Op het moment dat een een service wordt aangeroepen door middel van een bericht, reageert de service in feite op een event. Volgens deze redenering is een SOA vrijwel automatisch een EDA.
Aan de andere kant bestaat de opvatting dat een EDA een architectuur principe is waarbij events worden gegenereerd puur op basis van wijzigingen in de toestand (state) van de applicatie en/of onderliggende data. Door deze events te publiceren via bijvoorbeeld een queue of, intelligenter, een enterprise service bus (ESB), kunnen ze afgehandeld worden door onafhankelijke op zichzelf staande services. Deze services kunnen op hun beurt ook van invloed zijn op de toestand van de applicatie door ook events te publiceren.
Tot op zekere hoogte zijn beide opvattingen correct, afhankelijk van hoe je een EDA definieert. De nuance zit hem in het verschil hoe services worden geconsumeerd. In een ‘echte’ EDA SOA opzet, is er namelijk eigenlijk helemaal geen sprake van het consumeren van een service. Volgens het event driven principe is het enige wat de applicatie doet een event publiceren. Alle in dit event geïnteresseerde bedrijfslogica of externe applicaties pakken de informatie zelf op en gebruiken dit om hun taak uit te voeren. De gepubliceerde events kunnen zowel asynchroon als synchroon zijn. Events die als gevolg de validatie en/of persistentie van data tot gevolg zouden moeten hebben zullen vaak synchroon zijn, waarbij events die een (langlopend) bedrijfsproces tot gevolg zullen hebben asynchroon kunnen worden geïmplementeerd.
De resultaten van het event kunnen optioneel door de verwerkende processen worden teruggeplaatst op de service bus. Zo ontstaat er min of meer een canonisch communicatiemodel zoals dit bijvoorbeeld al eerder gebruikt werd in Oracle InterConnect. In dit canonische model staat de service bus centraal.
In de figuur is simplistisch de interactie tussen verschillende componenten weergegeven. Herkenbaar is het hub and spoke model, met ESB als centrale berichtverwerkende eenheid (messaging middleware). Iedere component communiceert in de basis alleen met ESB, via events. De ESB dient als doorgeefluik en/of tolk tussen de diverse componenten. Om afhankelijkheden met betrekking tot de fysieke locatie van de ESB en de diverse componenten te voorkomen, wordt een service registry (UDDI) ingezet.
Waarom is dit vanuit architectuur perspectief een mooie oplossing die Oracle en Gartner zelfs willen lanceren als een nieuwe marketinghype? De reden is dat er, alhoewel SOA al een hele goede stap is in de richting van loosely coupling is, in de praktijk toch afhankelijkheden blijven bestaan. Applicaties hebben toch vaak kennis van de services die ze aanroepen. Dit kan gedeeltelijk worden opgelost door gebruik van een UDDI server zoals Oracle Service Registry. Echter de interface tussen applicatie en service is dan toch op één of andere manier vastgelegd in de applicatie.
Om dit te voorkomen worder vervolgens bedrijfsprocessen in BPEL gemodelleerd. Dit voorkomt in ieder geval dat de applicatie kennis heeft van alle services, en in welke volgorde deze moeten worden aangeroepen (orchestratie). Met het uitbesteden van de orchestratie van bedrijfsprocessen aan een BPEL engine stopt het tot nu toe vaak.
Door het inzetten van een service bus, kan zelfs de afhankelijkheid tussen de applicatie en BPEL worden geminimaliseerd. De applicatie kan namelijk events plaatsen op de bus, die worden gerouteerd naar het BPEL proces. Een bijkomend voordeel is dat, naast het starten van een BPEL proces, ook signalen of informatie kan worden verstuurd naar andere (legacy) applicaties. Een ander voordeel is dat de applicatie alleen gegevens publiceert, onafhankelijk van de interfaces van de systemen die op basis van deze events reageren. Het enige contract dat de applicaties hoeven te kennen is die van het event.
In een later artikel zullen we praktijkvoorbeeld van een EDA SOA oplossing bespreken.
Tags: architectuur, BPEL, EDA, ESB, events, SOA, SOA 2.0, UDDI