Encyclopedie
Begrippenlijst

Integratie aan de achterkant middels een servicebus

Uit Triple A Encyclopedie
Ga naar: navigatie, zoeken


Een servicebus is een infrastructurele voorziening die ervoor zorgt dat diensten (services) kunnen worden gevonden en aangeroepen. Al het berichtenverkeer van en naar diensten loopt via de servicebus.

Omdat al het berichtenverkeer langs deze servicebus loopt, kan de servicebus een aantal aanvullende taken vervullen, zoals:

  • Het routeren van een request naar de juiste service door gebruik te maken van een register of repository van services
  • Het monitoren van een tijdige response op een request
  • Het overbruggen van technische verschillen tussen de vragende en de leverende service door het technische formaat van het bericht of de wijze van aanroepen aan te passen
  • Het overbruggen van functionele verschillen tussen de vragende en de leverende service door het bericht inhoudelijk te vertalen, anders in te delen of aan te vullen
  • Het beveiligen van berichtuitwisseling door autorisatiecontroles uit te voeren
  • Het tijdelijk vasthouden van berichten als de leverende service tijdelijk niet beschikbaar is

Een servicebus wordt ook vaak aangeduid met de term Enterprise Service Bus (ESB) om te benadrukken dat het een organisatiebrede voorziening is die diensten uit de hele organisatie met elkaar verbindt. De hierboven genoemde faciliteiten hebben ook vooral een toegevoegde waarde in de integratie tussen domeinen vanwege de technische en functionele verschillen die er kunnen zijn.

Onder een applicatie wordt hier een verzameling diensten verstaan die in samenhang is ontwikkeld (of aangeschaft). Alle services in die ene applicatie zijn gebaseerd op hetzelfde technische platform en gebruiken dezelfde gegevensdefinities.

Binnen één applicatie is het zelfs niet nodig om een servicebus te gebruiken. Binnen één technisch platformeen verzameling technische basisvoorzieningen op basis waarvan softwareontwikkeling kan plaatsvinden bijvoorbeeld het J2EE platform of het .NET platform. is er doorgaans een eenvoudigere voorziening beschikbaar die ervoor zorgt dat services elkaar kunnen aanroepen: de applicatieserver.

Een servicebus voorziet op hoofdlijnen in de volgende typen communicatie:

Gebeurtenissen (events)

Dit betreft het uitwisselen van berichten naar één of meerdere afnemers met de bedoeling een bepaalde gebeurtenis (bijvoorbeeld een statuswijziging of mutatie) te melden. Belangrijke kenmerken van dit type communicatie zijn:

  • Het is asynchroon: de verzender wacht niet op antwoord
  • Het mechanisme is ‘publish and subscribe’: de verzender publiceert het bericht maar kent de afnemer(s) die zich op het bericht ‘abonneren’ in principe niet.
  • Er geldt het principe van ‘fire and forget’: de verzender gaat uit van gegarandeerd transport door de servicebus en hoeft niet van de ontvangst door de afnemer te worden geïnformeerd
  • Technisch gezien is dit veelal een XML-bericht, maar het kan ook een EDI-bericht of tekstbestand zijn.

Diensten (services)

Dit betreft de aanroep van een dienst (service), veelal beschikbaar gesteld door een andere applicatie. Belangrijke kenmerken van dit type communicatie zijn:

  • Het kan synchroon (de verzender wacht op antwoord) of asynchroon zijn (de verzender wacht niet op antwoord of het antwoord wordt later als aparte service teruggeleverd)
  • De verzender is afhankelijk van de beschikbaarheid van de service. Bij synchrone verzending is dat het meest direct, maar bij asynchrone verwerking kan er ook een afhankelijkheid zijndie later in de tijd optreedt
  • Technisch gezien is dit veelal een web service, maar het kan ook een ander type applicatiecomponent zijn

Enkele instellingen hebben al een servicebus geïmplementeerd en andere overwegen dat te doen. Voor de toekomst wordt voorzien dat steeds meer instellingen deze stap zullen zetten, om zo de complexiteit van koppelingen tussen applicaties te reduceren en een betere integratie van applicaties te realiseren. Er wordt bijna altijd gestreefd naar één generieke voorziening waarop alle applicaties zijn aangesloten. Het is echter niet onwaarschijnlijk dat na verloop van jaren (modernere) additionele servicebussen in gebruik worden genomen. Het is dan wenselijk dat die samen zo veel mogelijk als één geheel kunnen werken. Bovendien moet er vaak gekoppeld kunnen worden met de servicebussen van andere organisaties.

Richtlijnen:

  1. De servicebus wordt zo veel mogelijk generiek ingericht, zodat deze bruikbaar en toegankelijk is voor zo veel mogelijk applicaties die binnen de instelling gebruikt worden.
  2. Een servicebus is specifiek per instelling; het is niet nodig op dit punt in de sector te standaardiseren.
  3. De servicebus ondersteunt in ieder geval de volgende typen communicatie tussen applicaties
    • Diensten (services) (asynchroon of synchroon)
    • Gebeurtenissen (events), (asynchroon)
  4. Bulkuitwisseling middels bestanden wordt zo veel mogelijk beperkt.
  5. Functionaliteit voor transport, technische conversie, berichttransformatie, routering, monitoring en logging worden ondersteund door de servicebus. Eventuele functionaliteit daarvoor binnen individuele applicaties wordt niet gebruikt.
  6. Wanneer er meerdere servicebussen in gebruik zijn, moet er overkoepelend over deze servicebussen gemonitord kunnen worden (‘meta-monitoring’).
  7. De ‘repository’ wordt onafhankelijk van de andere infrastructuur gerealiseerd en bij voorkeur op basis van open standaarden. Ze wordt dus ook onafhankelijk opgezet van het register (registry) waarin de technische ‘deployment’ details van de onstloten softwarefuctionaliteiten worden geregistreerd.
  8. Uitwisseling van gegevens wordt gebaseerd op een beperkte set fundamentele gegevenstypen die ten behoeve van gegevensuitwisseling organisatiebreed worden gestandaardiseerd.