Veel Service Oriented Architectures worden opgebouwd met behulp van een Enterprise Service Bus (ESB). Het hart van een ESB wordt gevormd door modules die in staat zijn berichten tussen applicaties en services heen en weer te sturen en er voor zorgen dat ze snel en veilig verstuurd worden en gegarandeerd aankomen.
Conceptueel gaan we ervan uit dat dit berichtenverkeer over een bus loopt. Een bus die qua architectuur wat weg heeft van de bus die we in computers aantreffen. Deze bus koppelt alle hardwarecomponenten aan elkaar en verzorgt al het onderlinge verkeer.
In PowerPoint-presentaties wordt de ESB ook altijd als een bus afgebeeld. Centraal in de tekening staat dan een lange streep, of als de tekenaar tijd over had, een holle, driedimensionale buis. Aan de bus zitten dan alle applicaties en services gekoppeld. Soms worden ook expliciet de adapters en/of connectors getekend. Dit zijn als het ware de op- en afritten voor de berichten om van de bus naar de applicatie te komen of andersom. Een ESB ziet er dan altijd simpel uit.
Maar heeft elke ESB echt een dergelijke busgeoriënteerde architectuur? Het antwoord is: nee. Sommige producten die we als bus betitelen zijn eerder brokers. Het zijn vooral de ESB’en die rond Java Applicatie Servers gebouwd zijn die als brokers betiteld moeten worden.
Maakt het eigenlijk uit: een bus of een broker? Het grote theoretische voordeel van een bus is dat er minder afhankelijkheid is van één centrale component. Bij een bus hoort elke verbonden partij met een willekeurige andere partij te kunnen communiceren zonder dat een centrale component geraadpleegd wordt. Nogmaals, theoretisch, niemand zit elkaar dan in de weg en dat moet de snelheid van communiceren ten goede komen.
Bij een broker moet alles langs een centrale component lopen: de broker. Als deze de werkdruk niet meer aankan, zal elke betrokken partij dat voelen. Bij een broker kunnen eerder lange wachtrijen ontstaan. Het is altijd de potentiële bottleneck van de architectuur.
Conclusie: een ESB moet een bus-architectuur hebben. Alhoewel, is dat nu wel zo? Ik rij in een Chrysler Voyager met een 3,5 liter motor. Je zou denken, zo’n auto heeft heel wat in zijn mars. Dat klopt maar gedeeltelijk. Als ik bij de stoplichten naast een klein autootje sta met maar een 1,8 liter motor, word ik er bij het optrekken soms wel ‘uitgereden’. Het feit dat een product een bepaalde technologie inzet, wil nog niet zeggen dat de technologie ook garant staat voor prestaties. Uiteindelijk is het allemaal afhankelijk van de slimheid en efficiëntie van de gekozen algoritmes.
Waar ik maar even voor het gemak aan voorbij ga is dat als een leverancier een prachtige technologie bedenkt, het nog steeds aan ons ligt of we de kracht die er potentieel in zit, er ook uit weten te halen. We kennen allemaal voorbeelden waarbij door een slecht ontwerp of door een slechte implementatie een product geheel om zeep geholpen wordt. We halen er dan niet uit wat er in zit.
Waar we in de wereld van de ESB dringend behoefte aan hebben is een neutrale benchmark. Een benchmark waarmee we de snelheid en betrouwbaarheid van een ESB objectief kunnen meten. We hebben dit soort benchmarks voor databaseservers, zoals die van de Transaction Processing Council, we hebben ze voor pc’s en voor grote mainframes. Het wordt tijd dat we er één voor ESB’en bedenken. Alleen dan kunnen we zien of een bus inderdaad meer kracht heeft dan een broker.
Maar het kan nog lang duren, voordat deze benchmark er is. We zullen ons dus nog lang afvragen wat nu beter is: bus of broker. Misschien moeten we daarom de afkorting ESB maar veranderen in ESB2 wat staat voor Enterprise Service Bus/Broker.
Rick van der Lans
