Naakte SOA - Via Nova Architectura - Digital, Enterprise, IT Architecture

Een naakte SOA is een “back to basics” architectuur. De gedachte is even sympathiek als simpel. Het web is de beste architectuur die het vakgebied tot nu toe heeft voortgebracht. Sir Tim Berners-Lee heeft als geestelijk vader van het web een voorbeeldige prestatie verricht. Het web is schier oneindig schaalbaar, en het biedt een platform voor applicaties die in de verste verte niet te voorzien waren. Waarom zouden we het dan nu moeilijk maken met een ESB?

Het web is van nature één en al middleware. En de grote kracht van het web is dat het zo dom is. Berners-Lee heeft heel bewust voor gekozen voor een oersimpele architectuur. Hij wilde bijvoorbeeld het probleem van de “broken links” niet door het netwerk op te laten lossen. Dat kunnen de gebruikers van het netwerk veel beter zelf doen. In Europa zouden ze zoiets het subsidiariteitsbeginsel noemen – probeer de verantwoordelijkheid voor het oplossen van een probleem zo dicht mogelijk bij de bron te leggen. En applicatieontwikkelaars met een integratieprobleem hebben een meer dan begrijpelijke weerzin tegen het oplossen van zo'n probleem op enterprise niveau (waarschijnlijk nog meer dan met enterprise technologie).

Het web als middleware is goed, het is bewezen, dus wie nog betere middleware aan de man wil brengen moet van goede huize komen. En als “betere middleware” alleen zou betekenen dat er intelligentie in het netwerk wordt gesmokkeld die innovaties tegengaat en die dus de oerkracht van het web ondermijnt, dan zou het inderdaad tijd worden om de stormbal te hijsen.

Toch zijn er ook geluiden dat leveranciers niet zelden al te gemakkelijk als zondebok voor jammerlijk mislukte SOA-projecten worden gebruikt. Het is nou eenmaal verleidelijk om de schuld van zulke mislukkingen buiten de eigen organisatie te zoeken. Ik heb zelf nog geen enkel SOA-project gezien dat is mislukt puur vanwege falende technologie. Ik ken wel projecten die zijn mislukt omdat er overspannen verwachtingen waren van de magische vermogens van technologie om architectuurproblemen te verhelpen. Typische voorbeelden van het “Same Old Architecture” probleem. Iedere keer als dezelfde architecten die een bestaand architectuurprobleem niet hebben kunnen voorkomen geacht worden om het op te lossen, dan is de kans niet denkbeeldig dat ze opnieuw in dezelfde valkuilen vallen.

Het is de verdienste van David Linthicum [5] om al zeker 10 jaar onvermoeibaar te hameren op het gevaar van “vendor driven architecture” [3], [6-9]. Hij laat ook geen gelegenheid onbenut om erop te hameren dat een succesvolle transformatie naar een SOA geen tactische operatie is die in een projectvorm tot een goed einde kan worden gebracht, maar dat het een strategische keuze moet zijn die een verandering van lifestyle vereist. In die zin is het domweg opbergen van de bestaande inter-application spaghetti in een blackbox met het label ESB inderdaad een recept voor ellende. Maar is dat nou de schuld van de leveranciers?

De naakte waarheid

Hoe zat het ook al weer. David Chappel – de auteur die het begrip ESB groot heeft gemaakt – stelt het zo: “The ESB provides a highly distributed, event-driven Service Oriented Architecture (SOA) that combines Message Oriented Middleware (MOM), web services, intelligent routing based on content and XML data transformations” [10]. Afgezien van het gebruik van het woord “architectuur” als synoniem voor “infrastructuur” beschrijft dit de kern van de ESB-propositie. De ESB als glueware, met een rijkdom aan functionaliteit om componenten en services losjes (“loosely”) te koppelen.

Oracle beschrijft een ESB als “the underlying infrastructure for delivering a service-oriented architecture (SOA) and event-driven architecture (EDA)” [11]. IBM houdt het op een “infrastructure service that provides robust communication, intelligent routing, and sophisticated translation and transformation of services” [12].

ESB is dus geen oplossing voor een architectuurprobleem. Het is een tool om makkelijk bestaande applicaties van een service-interface te kunnen voorzien, om makkelijk composiete services samen te kunnen stellen en om bepaalde governancetaken te centraliseren. In een ideale wereld zou je waarschijnlijk geen proprietary ESB willen gebruiken. Vendor-lock-in's zijn nooit aan te bevelen. Misschien kun je zelfs wel stellen dat het niet wenselijk is om in een green-field situatie een ESB als concept te gebruiken. Complexiteit voorkomen is altijd beter dan complexiteit beheersen, niet waar?

Een ESB kan naar mijn mening wel degelijk helpen om bijvoorbeeld een legacyprobleem op te lossen. Zie het maar als een stap in een migratiestrategie. Als een truc om gedurende de vlucht de lekke band van een vliegtuig te plakken. Noem het van mij part een “One-night stand”. Weggooiarchitectuur desnoods. Een noodzakelijk kwaad. Maar zie een ESB als een nuttig instrument om problemen die in de loop van de jaren zijn gegroeid te tackelen. Een ESB is niet de bron van de organisatorische en architecturele problemen. Dan is het toch raar om leveranciers te verwijten dat hun EBS die niet kan oplossen?

Een paradigmaverandering gaat altijd gepaard met vallen en opstaan. Het was zo bij de invoering van relationele databases, het was zo met de adoptie van het web en het is zo bij de transformatie naar enterprise architectuur. Succesverhalen en mislukkingen wisselen elkaar af, maar uiteindelijk vinden we met z'n allen een balans die de industrie een hoger plan brengt. Daarbij hebben technologische innovaties altijd een rol gespeeld en er is geen enkele reden om te denken dat zoiets dit keer niet zal gebeuren. De “peak of inflated expectations” [13] ligt inmiddels achter ons, zo veel maakt dit debat wel duidelijk. We zullen de “trough of disillusionment” nog doormoeten om te ontdekken welk potentieel ESB's op termijn zullen bieden, dan wel hoeveel of hoe weinig kleren een effectieve SOA infrastructuur nodig heeft.

Een ding is zeker. Een typische eilandorganisatie met een bijbehorende archipelarchitectuur zal heel wat weerstand moeten overwinnen voordat het zich een cultuur van bruggenbouwen en samenwerken eigen heeft gemaakt. Op termijn is het opsplitsen van zulke organisaties het enige alternatief voor synergetische samenwerking. Wat dat betreft is de markt ongenadig.

In deze kwestie wordt een actueel thema op een scherpe manier geanalyseerd. Het is de 10^de in een reeks.Deze is op 29 juli 2008 gepubliceerd op ArchITectuur Bedrijven.

[6] David S. Linthicum: “Enterprise Application Integration”; Addison-Wesley, 1998.

[7] David S. Linthicum: “B2B Application Integration: e-Business-Enable Your Enterprise”; Addison-Wesley, 2000.

[8] David S. Linthicum: “Next Generation Application Integration”; Addison-Wesley, 2003.

[11] Vimmika Dinesh et al: “Oracle® Enterprise Service Bus Quick Start Guide 10g”; Oracle website, sept 2006.

[12] Naveen Balani: “Model and build ESB SOA frameworks”; IBM website, mrt 2005.

	Written by This e-mail address is being protected from spam bots, you need JavaScript enabled to view it on 29-07-2008 21:00
	Hoi Hans, Heel herkenbaar. Ik hoor te vaak bij klanten de suggestie dat "de ESB" wel zal leiden tot een service georiënteerde architectuur. Ook zie ik "de ESB" te vaak in architecturen terugkomen als de oplossing voor integratieproblemen. Het maakt blijkbaar niet meer uit hoe we systemen koppelen; zolang het maar via "de ESB" loopt. Het lijkt een excuus te worden om niet meer te hoeven nadenken over applicatie-integratie. Het gaat zelfs verder; ik heb religieuze discussies met architecten die menen dat er altijd "een ESB" moet worden gebruikt bij het integreren van applicaties. Een belangrijk argument lijkt te zijn dat "de ESB" kan loggen. Mijn antwoord; als "de ESB" er niet is hoef je ook niet te loggen, want hij kan ook niet falen. Als je wilt weten of een bericht is verzonden of ontvangen dan is dat een verantwoordelijkheid van de applicaties zelf en niet van "de ESB". Mijn advies is tegenwoordig; definieer gewoon WS-I Basic Profile Web Services met een goed gedefinieerde interface dan ben je al een heel eind. Denk natuurlijk wel na over herbruikbaarheid van de service interface, maak gebruik van een canonical data model en publiceer je service wel in een service directory. Integratie-middleware zoals "de ESB" is vooral goed in het koppelen van systemen die zich niet aan standaarden houden. Als je dus wel uitgaat van standaarden dan heb je "de ESB" ook niet nodig. Mvgr, Danny Report

	Written by Jan Miedema on 30-07-2008 14:09
	Hoi Hans en Danny In de eerste plaats lijkt het me goed om te onderkennen dat (los van de marketing) er wel een "message bus" maar geen "service bus" bestaat. Elke relatie tussen de bus en een SOA moet dus gevonden worden doordat er kennelijk zaken om de bus heen georganiseerd zijn. Hetzij in de infrastructuur, protocols, applicaties hetzij organisatorisch/procedureel of een combinatie daarvan. Of "het web" ons dan helpt bij SOA weet ik eerlijk gezegd niet, in elk geval is dat voor intra-bedrijf communicatie niet heel handig, waarschijnlijk wel voor inter-bedrijf communicatie. Ik hanteer al lange tijd "standardize on protocols, not on tools". En vanuit dat perspectief kan ik Danny's keuze goed volgen. Maar soms moet je ook praktisch/opportunistische keuzes maken. En voor intra-bedrijf communicatie kan een ESB dan goed bruikbaar zijn. En anders maar een andere vorm van SOA middleware. Wat wezenlijk is voor een SOA is hoe je rond de beschikbare infrastructuur je SOA georganiseerd hebt. Hoe definieer je de services, welke governance is daarvoor nodig, en hoe vertaal je de services naar de beschikbare applicaties en infrastructuur. Het bijzondere daarvan is dat we zoveel mogelijk naar loosely-coupling streven en dat betekent o.a. dat weliswaar het protocol op enig moment vastligt maar dat wat elke partij voor en achter dat protocol doet los van elkaar staat. Dus ook bij het bedenken van services kan de één dat heel anders doen dan de ander. En dat maakt dat waar velen proberen eenduidigheid rond SOA te creëren, de essentie van SOA juist is dat die eenduidigheid beperkt is tot het gedefinieerde protocol. Kortom SOA middleware is weliswaar nodig en hoe breder de scope van het gebruik van je services hoe meer standaard de protocollen van de middleware zullen moeten zijn, maar veel belangrijker voor SOA is het hele concept bovenop de techniek om partijen via loosely-coupled services met elkaar te laten interageren. mvg, Jan Report

	Written by This e-mail address is being protected from spam bots, you need JavaScript enabled to view it on 06-08-2008 16:16
	Ik blijf toch met een brandende vraag zitten. Als je alle sentiment tegen leveranciers en al te machtige en toch jammerlijk onwetende service managers uit de discussie probeert te filteren - de verdeling van verantwoordelijkheden is tenslotte een ander onderwerp; dan houd je maar betrekkelijk weinig bezwaren tegen het gebruik van een ESB over. Ik zie helemaal geen voorbeelden van integratie-oplossingen die zonder ESB wel mogelijk zijn, maar met een ESB niet zouden kunnen. Waar zijn de onderbouwde cases dat de performance via de ESB 40% lager ligt dan rechtstreeks? Wie toont eens onomstotelijk aan dat ESB's de innovatie werkelijk remmen? Het enige argument dat steeds terugkomt is dat van een lock-in bij een leverancier. Nou kun je er verschillend over denken hoe zwaar dit moet wegen, en of dit ook geldt als je een open source ESB zou gebruiken, maar het kan toch niet zo zijn dat dit het enige valide argument tegen het inzetten van een ESB zou zijn? Report

Het debat

De naakte waarheid