Enterprise service bus

Een Enterprise service bus (ESB) is een architecturele softwareconstructie (pattern) waarmee de communicatie tussen de afnemers van diensten (“service”) en aanbieders hiervan, vereenvoudigd wordt.

De ESB biedt hiertoe aan de kant van de aanvrager een met de aanvrager afgesproken interface aan, dit kan een webservice zijn, maar bijvoorbeeld ook een SMTP (e-mail) interface en tal van andere mogelijkheden. Aan de kant van de aanbieder zal de ESB via de interface die met de aanbieder is afgesproken communiceren. Zo kan het dus zijn dat een aanvrager van een dienst op een compleet andere wijze met de ESB communiceert dan de ESB met de aanbieder. Onderstaande figuur geeft dit schematisch weer.

De customer-services kunnen allemaal op dezelfde manier communiceren met de ESB. De ESB vertaalt het bericht naar het juiste berichttype en stuurt het door naar de juiste producer-service

Door de toevoeging van het ESB component binnen een software-architectuur kan de wijze waarop service-aanvragers communiceren met service-aanbieders gestandaardiseerd worden, immers er is alleen een afspraak tussen de ESB en de aanvrager of aanvragers die van dezelfde service gebruikmaken.

Het is de taak van de ESB om de informatie die binnenkomt bij een aanvraag en daarbij behorende informatie op de juiste wijze te vertalen (transformeren) naar het formaat dat door de service aanbieder verwacht wordt.

De ESB component is verantwoordelijk voor het op de juiste plaats afleveren van een aanvraag, dus bij de juiste aanbieder of wellicht aanbieders van services. Binnen de afhandeling van deze aanvragen zorgt de ESB verder voor de afhandeling van fouten en het eventueel prioriseren van de aanvragen met andere woorden, welke aanvraag dient eerst te worden afgehandeld, etc. Dit geheel van aanvraag afhandelen en de controles die hierbij komen kijken wordt aangeduid als orchestratie van service aanvragen.

Een volgend aspect van een ESB component is de beveiliging van aanvragen en de gegevens die hiermee gemoeid zijn. Hierbij gaat het dus naast het beveiligen van het communicatie kanaal (bv. een beveiligde webservice via HTTPS) ook om wie (welke gebruiker of rol) mag een service aanvragen.

Een laatste veel voorkomende taak van een ESB component is het monitoren van de aanvragen die gedaan worden en hiervan statistische gegevens bijhouden. Bijvoorbeeld, hoe vaak wordt een service aangeroepen, hoe vaak gaat dit fout of juist goed en hoe lang duurt een aanvraag. Op basis hiervan kan later gerapporteerd worden, maar kan ook direct gereageerd worden indien bijvoorbeeld binnen de orchestratie van een aanvraag een service aangeroepen wordt die een foutafhandeling uitvoert. Binnen monitoring valt ook het controleren op vooraf gestelde SLA’s voor een service, die in de ESB gedefinieerd zijn, met acties indien een SLA niet gehaald wordt. In het kort de kenmerken op een rij:

• Een ESB “bemiddelt” tussen service aanvragers en service aanbieders
• Een ESB zorgt voor standaardisatie van de communicatie met service aanvragers
• Een ESB handelt de transformatie van gegevens tussen aanvrager en aanbieder af
• Een ESB orkestreert de afhandeling van aanvragen en het doorsturen naar aanbieders
• Een ESB monitoort de service aanvragen en rapporteert over het gebruik van aanvragen
• Een ESB zorgt voor beveiliging van het transport.

Waarom een ESB?

Hier volgt een beknopte opsomming van de redenen waarom een ESB gebruikt zou kunnen worden en de voordelen die het oplevert.

1. Compleet loskoppelen of gedeeltelijk ontkoppelen (loosely coupled) van service aanbieders en service aanvragers. → Aanvragers communiceren met de ESB en niet direct met de aanbieder.
2. Versimpelen en standaardiseren van interfaces tussen aanbieders en aanvragers → één generieke manier van communiceren met de ESB, de ESB zorgt voor communicatie met de onderliggende systemen.
3. Het stimuleren van hergebruik → doordat services beschikbaar zijn op een centraal niveau (binnen de ESB) en gemakkelijk toegankelijk, kunnen ze sneller worden toegepast in andere systemen.
4. Centrale en generieke manier van service monitoring → binnen de ESB kunnen services gemonitored worden en gecontroleerd op afgesproken SLA’s op een generieke manier, de monitoring hoeft niet meer bij iedere service aanbieder te worden ingericht, maar gebeurt centraal in de ESB.
5. Reduceren van “time-to-market” door hergebruik en minder implementatie tijd → hierdoor kan uw organisatie (business) sneller inspringen op veranderingen in de organisatie of omgeving.

Bovenstaande figuur verduidelijkt nog eens de punten 1 en 2 van de lijst hierboven, nl: zonder gebruik te maken van een ESB hebben aanvragers en aanbieders zogenaamde “Point-to-Point” verbindingen en lopen deze kris-kras door de organisatie. Door de toepassing van een ESB hebben aanvragers één gestandaardiseerde interface met de ESB en zullen aanvragen via de ESB afgehandeld worden.

Concluderend kan worden gezegd dat een ESB onmisbaar is als “enabler” in een organisatie waar een Service Oriented Architecture ontwikkeld wordt. De ESB zorgt voor de juiste infrastructuur waarop op hoger niveau, vanuit de functionele gedachte (business) naar processen wordt gekeken en hoe deze te verbeteren zijn binnen een organisatie.