Wat zijn ESB en SOA eigenlijk

Een uitmuntende beschrijving van het systeem achter systeemdenken
Nick Coghlan, Core Python Developer

Also available in Català, Deutsch, English, Français, italiano, Português, ру́сский, Türkçe and 中文.

De afkorting ESB en de eraan verwante term - SOA - kunnen erg verwarrend zijn. ESB staat voor “Enterprise Service Bus”, een soort communicatiekanaal voor “diensten”. De term SOA staat voor “Service Oriented Architecture”, een architectuur op basis van “diensten”

Dat verklaart natuurlijk nog steeds niet veel vandaar dat we hieronder een beschrijving laten volgen in normale taal, dus zonder al te veel marketing gebabbel.

De hele waarheid

Bedenk wat er gebeurt als je inlogt bij de webapplicatie van de bank:

  1. Je naam wordt weergegeven
  2. Je saldo is te zien
  3. Je pasjes zijn te zien
  4. Je lijst met beleggingsfondsen kunnen getoond worden
  5. Er zullen vooraf berekende aanbiedingen staan voor leningen waar je in geïnteresseerd kan zijn

Het is erg waarschijnlijk dat deze stukjes informatie in verschillende systemen en applicaties zijn opgeborgen. Elk van deze laat het stukje data van jou zien via een soort interface (HTTP, JSON, AMQP, XML, SOAP, FTP, CSV, maakt eigenlijk niet echt uit):

  1. is van een CRM lopend op Linux en Oracle
  2. is van een COBOL systeem op een z/OS mainframe
  3. is van een zogenaamd mainframe maar ze willen er niet echt wat over kwijt, alleen maar dat ze liever CSV hebben in plaats van iets anders.
  4. is van een mix van PHP en Ruby lopend op Windows
  5. is van PostgreSQL, Python en Java lopend op Linux en Solaris

De grote vraag is nu hoe je deze voorkant laat communiceren met 1-5? Nou, dat doe je dus niet.

Dit is namelijk een van de basisregels om er zeker van te zijn dat je kunt schalen voorbij een handvol systemen. Je staat niet toe dat ze direct met elkaar communiceren In de diagram hieronder is elke aanroep van een service weergegeven met een andere lijndikte of stijl:

Let wel: we hebben hier de complexere verbindingen weggelaten (App 1 roept App 2 aan en App 3 of App 5 afhankelijk van het succes van een eerdere antwoord van App 6 zo dat App 4 op een later moment data kan grijpen die geproduceerd was door App 2 maar alleen als App 1 dit niet verbiedt. Enzovoort.)

Let op dat we hier niet over servers praten - elk systeem kan op 10 fysieke servers draaien zodat we tenminste 60 fysieke componenten hebben die met elkaar aan het communiceren zijn.

Nu komen een aantal vragen naar boven.

Hoe kun je interfaces scheiden ? Hoe kun je uitrollen plannen ? Hoe kun je de updates of geplande downtime coördineren als elke applicatie onderhouden wordt door een verschillend team, andere leveranciers of een andere afdeling terwijl de helft van de oorspronkelijke ontwikkelaars al weg zijn ?

Als je denkt dat je 6 applicaties te kunnen beheren, wat als het er 30 worden ?

Kun je 400 aan ? Of 2000? Elke applicatie zal een unieke omgeving zijn die 10 servers of andere apparaten nodig heeft om te lopen. Hetgeen leidt tot 20k bewegende delen die verdeeld zijn over continenten, allerlei culturele en technische grenzen waarbij alle onderdelen constant en onophoudelijk berichten met elkaar willen uitwisselen en met elkaar willen babbelen zonder enige onderbreking ooit. (We zullen je niet lastig vallen met een diagram)

Er is een goede naam voor deze situatie. Het heet een puinhoop.

Hoe kan je de puinhoop opruimen?

Als eerste zul je eerlijk moeten bekennen dat de situatie uit de hand gelopen is. Dit staat je toe om naar een oplossing te zoeken zonder al te veel schuldgevoelens. OK, het is gebeurd, je wist niet beter, maar er nu is een kans om het op te schonen.

Dit kan betekenen dat je als organisatie anders tegen IT moet aankijken maar een andere realisatie is dat de systemen en applicaties niet alleen maar gemaakt zijn om data rond te pompen. Ze zijn bedoeld om zakelijke processen te ondersteunen, onafhankelijk van welke zakelijke processen je verricht. (bankieren, audio opnames, radiolocatie apparatuur, wat dan ook).

Als je deze twee duidelijk hebt dan kun je gaan denken over het bouwen of herontwerpen van je systemen naar diensten. Een dienst is iets interessants, herbruikbaars en atomairs dat aangeboden wordt door een systeem aan een applicatie die er gebruik van wil maken. Maar nooit direct in een een-op-een relatie. Dit is de kortst mogelijke zinvolle definitie. Als een functionaliteit van een systeem aan deze 3 eisen voldoet, te weten:

  • I nteressant
  • H erbruikbaar
  • A tomair

Dan is er een goede kans dat het als een service aan andere systemen getoond kan worden en dat dit eigenlijk ook zou moeten. Maar dit alles dus nooit direct.

Laten we de IHA benadering eens bekijken door een aantal voorbeelden.

Variabele Notities
Omgeving Het CRM van een elektriciteitsbedrijf
Functionaliteit Een lijst van gebruikers die actief waren in de self-service portaal in kwartaal 3 2012
Is het interessant? Ja hoor, vrij interessant. Het kan gebruikt worden om allerlei nuttige rapporten en statistieken mee te maken
Is het herbruikbaar? Nee, niet echt. Hoewel het wel als basis te gebruiken is voor een een rapport op hoger niveau, zoals statistieken voor een heel jaar. Het is duidelijk dat het waarschijnlijk niet echt nuttig meer gaat zijn in 2018
Is het atomair? Waarschijnlijk wel, ja. Zeker als er vergelijkbare diensten zijn voor andere kwartalen. Het geeft mogelijk inzicht op jaar niveau.
Hoe maken we het IHA?
  • Zorg er voor dat de start- en de stopdatum te kiezen is in plaats van de beperking tot 1 kwartaal.
  • Zorg er voor dat willekeurige applicaties toegang kunnen krijgen in plaats van alleen maar het portaal. Laat de betreffende applicatie een invoer parameter zijn in plaats van een hard gecodeerde verwijzing naar het portaal.
Variabele Notities
Omgeving e-commerce omgeving
Functionaliteit Elk stukje informatie van een selecteerde gebruiker teruggeven wat ooit verzameld is
Is het interessant? Nou, ehm, ja. Als je toegang hebt tot alles kun je altijd selecteren wat je werkelijk nodig hebt.
Is het herbruikbaar? Grappig genoeg niet echt. Er zullen weinig toepassingen zijn die geïnteresseerd zijn in elk stukje informatie.
Is het atomair? Zeer zeker niet. Deze monster functionaliteit is waarschijnlijk logisch samengesteld uit meerdere kleinere onderdelen.
Hoe maken we het IHA?
  • Splits het in kleinere stukken. Denk over wat een klant goed beschrijft - ze hebben een adres, telefoon, favoriete producten, favoriete contact methodes en zo verder - elke hiervan zou een aparte onafhankelijke service moeten zijn.
  • Gebruik de ESB (Enterprise Service Bus) om samengestelde diensten te maken op basis van de atomaire stukken
Variabele Notities
Omgeving Een willekeurig CRM ergens.
Functionaliteit Bijwerken van kolom CUST_AR_ZN in tabel C_NAZ_AJ als iemand een account creëert
Is het interessant? Helemaal niet. Dit is interne functionaliteit van het CRM. Niemand die goed bij zijn verstand is wil te maken hebben met dit soort gedetailleerde informatie.
Is het herbruikbaar? Ja, waarschijnlijk. Een account kan via meerdere kanalen aangemaakt worden dus dit lijkt herbruikbaar.
Is het atomair? Het lijkt er op, ja. Het is het bijwerken van een kolom in een tabel.
Hoe maken we het IHA? Geen moeite doen om dit tot een dienst of service om te zetten. Het is niet interessant Niemand wil denken aan kolommen en tabellen in een bepaald systeem. Het is een onderdeel van de opbouw van het CRM systeem. Maak er geen dienst of service van omdat het toevallig herbruikbaar en atomair is. Het is de verantwoordelijkheid van het CRM systeem om data op te slaan in tabellen en kolommen, daar moet verder niemand anders mee lastig gevallen worden.
Variabele Notities
Omgeving Een mobiele telefonie aanbieder
Functionaliteit Opladen van een prepaid kaart in een administratie systeem
Is het interessant? Ja, extreem. Iedereen wil het gaan gebruiken, via tekst berichten, telefonische keuze menus, instant messaging, portalen, cadeaubonnen, etc
Is het herbruikbaar? Zeer herbruikbaar, het kan onderdeel zijn van allerlei andere processen op hoger niveau.
Is het atomair? Ja, vanuit het gezichtspunt van de aanroepende applicatie kan het zijn om de kaart op te laden of niet. Dat het administratiesysteem deze functionaliteit implementeert als proces in een aantal stappen is niet relevant. Vanuit het zakelijke perspectief is het atomair, een ondeelbare dienst geleverd door het administratie systeem.
Hoe maken we het IHA? Het is al IHA.

Als je in de laatste 50 jaar wat geprogrammeerd hebt, dan is het duidelijk dat het beschikbaar maken van een dienst hetzelfde is als het beschikbaar maken van een api van een deel code voor een andere. Het enige verschil is dat het hier niet handelt om submodules van een enkel systeem. Het gaat hier om een totale omgeving met ongelijksoortige systemen.

Beschikbaar stellen dienst op een ESB in een SOA

Nu dat je snapt dat de systemen niet direct informatie uitwisselen en je begrijpt wat een dienst is, kunnen we gebruik gaan maken van de ESB.

Het is de taak van de ESB om de diensten te tonen en uit te voeren van de gekoppelde systemen. Op die manier is, in de meeste gevallen, maar een koppel-methode en interface nodig tussen elk systeem en de ESB.

Dus als je 8 systemen hebt zoals getoond in de diagram hierboven dan heb je 16 interfaces (een in elke richting) te maken, te onderhouden, te beheren en rekening mee te houden.

Zonder een ESB zouden er 56 interfaces uitgedacht en beheerd moeten worden (er vanuit gaande dat alle systemen met elkaar communiceren).

De besparing van 40 interfaces betekent minder tijd verspild en meer geld bespaard. Dit is een van de redenen waarom je vrijdagen minder stressvol zullen zijn.

Alleen al hierom zou je gemotiveerd moeten zijn om met een ESB aan de gang te gaan.

Als een systeem herschreven wordt, van eigenaar verandert of opgesplitst moet worden over afdelingen of leveranciers, dan is het de taak van de ESB personen om de de noodzakelijke aanpassingen toe doen. Geen van de andere systemen zullen dit merken omdat hun interface naar de ESB intact blijft.

Als je start met het ademen van IHA diensten op een dagelijkse basis dan kun je ook gaan denken aan samengestelde diensten.

Herinner je de “Geef-me-alles-wat-je-kan-van-deze-klant” dienst van hierboven ?

Het was geen goed idee om dit te maken maar soms heb je te maken met een vragende applicatie die samengestelde en gesommeerde informatie nodig heeft. Het zijn de ESB personen die verantwoordelijk zijn voor het kiezen van de beste atomaire diensten om deze samengestelde voor het specifieke vragende systeem te maken die deze specifieke set van samengestelde data vraagt.

Na verloop van tijd zal de hele organisatie beginnen te begrijpen dat het niet meer draait om database tabellen, bestanden, batches, functies, routines of records. Dit is ook het moment dat de architectuur gaat draaien om interessante, herbruikbare en atomaire diensten die door applicaties aangeboden worden.

Mensen zullen niet langer denken dat applicaties en systemen informatie naar elkaar zenden. Ze zullen de ESB zien als een universele toegangspoort naar interessante diensten waar hun eigen systeem gebruik van kan maken. En ze zullen niet de moeite doen om te controleren wie precies wat levert, hun systemen koppelen alleen met de ESB.

Dit kost tijd, geduld en gecoördineerde inspanning maar het is uitvoerbaar.

Maar pas op voor...

De beste manier om het hele concept van de SOA te ruïneren is om een ESB uit te rollen en te verwachten dat zaken zichzelf oplossen. Ondanks dat het een fantastisch idee is, gewoon een EBS installeren zal helaas niet zo veel resultaten opleveren.

In het beste geval, het onder het tapijt vegen, zoals in het diagram hieronder, zal niets opleveren.

Je IT personen zullen het systeem haten en het management zal het ESB eerst tolereren als het laatste nieuwe speeltje maar later wordt het het lachertje. “Wat een nieuwe perfecte oplossing ? Hahahaha”.

Dit soort gevolgen zijn niet te voorkomen als een ESB niet een onderdeel is van een groter verbeterplan.

Een ESB is er dus alleen voor banken en daaraan vergelijkbaar, toch?

Helemaal niet, nee. Het is een goede keuze in iedere situatie die meerdere databronnen en meerdere toegangsmethodes nodig hebben die samenwerken om een interessant resultaat te verkrijgen.

Bijvoorbeeld, het verkrijgen van de laatste metingen van een thermometer en deze publiceren op meerdere kanalen, zoals e-mail waarschuwingen en een iPhone toepassing klinken als een passende kandidaat voor een integratie platform.

Periodiek controleren en meten of alle onderdelen van een kritische applicatie werken en als er een faalt, het uitvoeren van een voorgedefinieerd script en ondertussen een bericht sturen naar de beheerders klinkt ook goed.

Alles wat een integratie in een duidelijke, goed gedefinieerde omgeving nodig heeft is mogelijk een kandidaat voor een ESB dienst maar als altijd, besluiten of iets werkelijk een perfecte kandidaat is, is afhankelijk van je eigen ervaring. Natuurlijk kunnen de makers van Zato hierin ondersteunen <https://zato.io/support.html>`_.

Maar ik hoorde dat SOA eigenlijk gaat over XML, SOAP en webdiensten

Ja, dat is wat mensen graag willen dat je gelooft.

Als mensen of leveranciers waar je mee gewerkt hebt dingen deden als het BASE-64 coderen van een CSV bestand en deze naar je toesturen via een SAML2-beveiligd SOAP bericht dan is het erg begrijpelijk dat je deze indruk verkregen hebt.

XML, SOAP en webdiensten hebben hun nut, net als alles, maar ze kunnen misbruikt worden.

SOA gaat over een heldere onderhoudbare architectuur. Dat een bepaalde dienst mogelijk SOAP gebruikt of niet is eigenlijk niet relevant. Als een architectuur benadering zal SOA deugdelijk zijn, zelfs als geen enkele SOAP dienst gebruikt wordt.

Als een architect een mooi gebouw ontwerpt dan kan hij weinig doen aan de kleur verf die mensen kiezen voor hun eigen interieur.

Dus nee, SOA gaat niet over XML, SOAP en webdiensten. Ze kunnen ook gebruikt worden maar het is niet het complete verhaal.

We willen je hierbij aanmoedigen om je afgedwaalde collega’s vriendelijk naar dit artikel te leiden om hen te laten begrijpen waar SOA echt om draait.

Maar er is nog meer

Dit hoofdstuk behandelt alleen maar het eerste begin maar het dient om je een goed begrip te geven hoe ESB en SOA er uit moeten zien en wat noodzakelijk is om het tot een succes te maken.

Een greep uit de andere, hier niet behandelde onderwerpen:

  • Hoe steun te krijgen van het management voor een ESB
  • Hoe krijg ik de SOA architecten en de analyse groepen bij elkaar
  • De introductie van een Canonical Data Model (CDM) in een organisatie
  • Key Performance Indicatoren (KPI) - nu er een gemeenschappelijke en eenduidige methode is voor het verlenen van diensten over de systemen, moet je beginnen met meten en evalueren van wat werkelijk geleverd wordt.
  • Business Process Management (BPM) - hoe en wanneer te kiezen voor een BPM platform om de dienste te dirigeren (antwoord: niet te vroeg, raak eerste vertrouwd met de manier om mooie en aantrekkelijke diensten te bouwen)
  • Wat te doen met systemen die geen API’s hebben ? Bijvoorbeeld: moet een ESB direct hun database benaderen ? (antwoord: Hangt er vanaf, er is geen absolute regel voor)

Dus wat is Zato nu eigenlijk?

Zato is een ESB en applicatie server geschreven in Python. Het kan gebruikt worden om middleware en backend systemen mee te bouwen. Het is open-source software en de ondersteuning is beschikbaar door de gemeenschap maar ook commercieel te verkrijgen. En Python is a programmeertaal beroemd om zijn gebruiksgemak en productiviteit.

Python en Zato gebruiken betekent dat je productiever zult zijn en minder tijd nodig zult hebben voor lastige zaken.

Zato is geschreven door pragmatici voor pragmatici Het is niet weer een ander systeem snel in elkaar gezet door een leverancier die mee wil doen met de ESB/SOA hype.

Eigenlijk is het geboren uit de praktische ervaring bij het blussen van branden veroorzaakt door dit soort systemen. Inderdaad, de Zato scheppers hebben zoveel tijd doorgebracht met het omgaan met zulke verschrikkelijke omgevingen dat ze virtueel immuun geworden zijn voor elke brand.

Dit is de smederij waaruit Zato ontstaan is en waarom het productiviteit en gebruiksgemak kan bieden ongeëvenaard door schijnbaar soortgelijke oplossingen.

Tot dan!