Artikel

NoESB, een alternatief voor een ESB

Menig applicatielandschap is gebaseerd op Service Oriented Architecture (SOA) en bevat een Enterprise Service Bus (ESB) als een centraal component waar al het verkeer doorheen zou moeten gaan. De realiteit is echter dat de voordelen van een ESB discutabel zijn en juist als een complexe bottleneck wordt ervaren. Maar wat is dan het alternatief?

Inleiding

In veel IT architecturen is een ESB geïntroduceerd als een essentieel component van een Service Georiënteerde Architectuur. Na grote opstartkosten komt er van het beloofde integratiegemak weinig terecht. Dit met name wegens nieuwe technische en organisatorische complexiteit. Je vraagt je af of er alternatieve oplossingen zijn. Je bent huiverig voor een ESB van een andere leverancier. Toch wil je applicaties snel, eenvoudig en goed kunnen integreren.

In dit artikel lichten we een aantal Enterprise Service Bus problemen toe en stellen wij een lichtgewicht oplossing voor die dezelfde behoefte vervult als een ESB. Deze oplossing is gebaseerd op een HTTP proxy en decentralisatie van integratiefuncties.

Een gedistribueerde architectuur

Een klassieke gedistribueerde architectuur bevat de volgende componenten: services, clients, servers, een gemeenschappelijke messaging infrastructuur en een vorm van naming en directory service.

Figuur 1: Een gedistribueerde architectuur

De clients roepen de services. De servers implementeren de services. De services hebben een logische naam. De aanroepen vinden plaats over een gemeenschappelijke messaging infrastructuur: zowel clients en servers kennen het transport protocol en het berichtformaat waarmee de services kunnen worden aangeboden en worden aangeroepen.

De belangrijkste component van de gedistribueerde architectuur is de naming en directory service: hier worden de logische service namen vertaald naar een fysiek adres van een server die de service implementeert. De naming en directory service zorgt voor location transparency. Location transparency is essentieel voor het ondersteunen van schaalbaarheid en hoge beschikbaarheid. Het stelt de client in staat om bij elke aanroep een server op te zoeken die beschikbaar is om de service uit te voeren. Producten die een dergelijke architectuur implementeren zijn onder andere TUXEDO, DCE en JINI.

WebServices architectuur

In een WebServices architectuur zijn alle componenten van een gedistribueerde architectuur terug te vinden. Een gemeenschappelijke messaging infrastructuur, welgedefinieerde interfaces en een communicatieprotocol tussen clients en servers voor het aanroepen van services. Als naming en directory services is ooit UDDI gedefinieerd. In het artikel ‘Integrating WCF Services into UDDI based enterprise SOA’ [1] wordt nog een poging gedaan om deze architectuur te realiseren in een Microsoft omgeving. Helaas is de adoptie van UDDI niet van de grond gekomen en is de ondersteuning door vendors inmiddels ter ziele (zie referentie 2 en 3).

Door het ontbreken van een naming en directory service in een WebService architectuur, bevatten de webservices clients harde referenties naar fysieke adressen van de logische services. Het gebruik van fysieke adressen leidt tot een moeilijk te wijzigen, point-to-point integratie architectuur.

Figuur 2: Point-to-point architectuur

Om toch enige ontkoppeling tussen de clients en de servers te verkrijgen, wordt vaak gekozen voor de inzet van een ESB. Hierbij communiceren alle clients en servers via de ESB. De point-to-point architectuur is nu omgezet in een hub-and-spoke architectuur. Het nadeel van een hub-and-spoke model, is dat de point-to-point koppelingen niet verdwijnen: ze worden alleen gecentraliseerd in de ESB. Het centrale karakter van de ESB maakt dat het een potentiële bottleneck wordt. Een bottleneck voor de beschikbaarheid, een bottleneck voor de performance en een bottleneck voor wijzigingen.

Figuur 3: Hub-and-spoke architectuur

Een bottleneck voor beschikbaarheid en performance is evident: al het verkeer tussen clients en servers moet via de ESB verlopen. De load van al dit verkeer kan leiden tot performance en schaalbaarheidsproblemen. De ESB is een ‘single point of failure’, ondanks het feit dat leveranciers clustering technologie gebruiken om dit risico te minimaliseren.

De ESB kan ook een bottleneck vormen voor wijzigingen. Omdat al het verkeer tussen client en server over de ESB moet lopen, betekent dit dat voor elke koppeling wijzigingen moeten worden aangebracht in de ESB. Deze wijzigingen bestaan meestal uit het configureren van berichtenstroom in een vendor specifieke programmeertaal. Dit is een specialisme in een niche, waar minder IT professionals van zijn die daar kennis en ervaring mee hebben. Zij zijn wel bij alle projecten nodig.

Tot slot zorgt het toevoegen van een ESB voor een extra systeem in de keten tussen client en server. Dit vergroot de kans op fouten en een verminderde beschikbaarheid. De ESB vergroot de complexiteit van het landschap.

Het alternatief

Het alternatief bestaat uit een HTTP Reverse Proxy en gedistribueerde adapters ten behoeve van bericht- en protocoltransformatie. De HTTP Reverse Proxy is prima in staat om in combinatie met internetstandaarden zoals URL Load Balancing en failover functionaliteit de benodigde functionaliteit te leveren voor webservice gebaseerde applicatie architecturen. De Reverse Proxy is volledig transparant, bewezen technologie, en standaard internet infrastructuur en levert location transparency voor webservice clients. Daarnaast past dit alternatief naadloos bij de REST architectuurstijl.

Figuur 4: HTTP Reverse Proxy

Location Transparency

De HTTP Reverse Proxy server zorgt voor location transparency voor de clients, waardoor hoge beschikbaarheid en schaalbaarheid kan worden gerealiseerd.

Clients kunnen een URL als logische naam voor de service beschouwen. Zoals in iedere browser wordt door middel van DNS een URL naar een fysiek adres van de service vertaald. DNS alleen is echter onvoldoende: DNS implementeert een gedistribueerde cache, waardoor wijzigingen in de DNS records vertraging kunnen oplopen.

Door een DNS record te laten verwijzen naar een Reverse Proxy, kan deze op basis van de hostnaam in de URL het verzoek doorsturen naar de eigenlijke server(s). De meeste Reverse Proxies ondersteunen standaard load-balancing en failover configuraties.

Bewezen technologie

HTTP Reverse Proxies zijn bewezen technologie. Op het internet zijn honderdduizenden sites die gebruik maken van Reverse Proxies voor het ontsluiten van websites. Van Squid, Apache tot HAProxy. De Reverse Proxies zijn betrouwbare, hoog performante en schaalbare systemen, die in staat zijn om duizenden verzoeken per seconde af te handelen (zie referentie 4 en 5).

Standaard functionaliteit

HTTP Reverse Proxies leveren standaard functionaliteit voor load balancing, caching, beveiliging en performance verbeteringen rondom het HTTP protocol. Vaak is een HTTP Reverse Proxy geconfigureerd als een device in de infrastructuur. Dit zorgt ervoor dat een proxy eenvoudig is te vervangen door een andere proxy implementatie.

Volledig transparant

Voor zowel de client als de server is het gebruik van een Reverse Proxy volledig transparant. Zelfs zonder proxy zal het systeem in staat zijn om de gewenste functionaliteit te leveren.

Wat kan een Reverse Proxy niet?

Een Reverse Proxy bevat geen functionaliteit uit het applicatie integratie domein. Je kunt er geen berichttransformaties mee uitvoeren. Ook is het niet mogelijk om protocol conversies uit te voeren: bijvoorbeeld van HTTP naar SFTP.

De essentie van dit alternatief ten opzichte van een oplossing met een ESB is decentralisatie van integratiefuncties zoals bericht- en transporttransformaties. Het centraliseren van deze functionaliteit kan zelfs gezien worden als een verkeerde plaatsing van verantwoordelijkheden en verlies van cohesie in het systeem: een transformatie van een bericht hoort gezien de benodigde kennis bij de service of de afnemer zelf. Ook een protocolconversie hoort in dezelfde categorie. Een adapter als deze is in vele vormen en in verschillende technologieën te verkrijgen. Dit sluit ook aan bij de belangrijkste boodschap van Stefan Tiklov [6] in zijn presentatie over pragmatisch SOA: “don’t put it in the middle”.

Conclusie

Voor de belangrijkste functionaliteit van een ESB, het ontkoppelen van systemen, is het gebruik van DNS in combinatie met een HTTP Reverse Proxy afdoende. Het is volledig transparant voor de afnemers en leveranciers van de services, het is standaard internet infrastructuur en bewezen technologie. Het vermindert het aantal componenten en afhankelijkheden in de architectuur en reduceert daarmee de complexiteit. In de keynote van “Does my Bus look big in this” van Martin Fowler [7] wordt dezelfde visie uitgedragen.

Categorie:   
Auteur(s)
afbeelding van viktorgrgic
Viktor Grgic
LeanArch b.v. - Eigenaar

Viktor Grgic is een zelfstandige Agile/Lean IT architect die in zijn werk als software architect Agile principes hanteert. Viktor heeft in zijn loopbaan als architect vele software projecten geleid. Onder andere leiding gegeven aan architectuurteam van Nieuw Handelsregister bij Kamer van Koophandel, lead SOA / integratie architectrol vervult bij ProRail en vele architecten gecoacht in hun werk. Viktor's werk kenmerkt zich door sterke focus op de mensen, eenvoud in alles, risico's onderkennen en realisme in wat met software mogelijk is. Viktor's expertise is met name service-orientatie / SOA, EAI, domein modellering, ontwikkelstraten, ontwikkelmethodieken en systeemontwikkeling van met name JEE systemen.

afbeelding van markvanholsteijn
Mark van Holsteijn
Xebia - senior consultant

Mark van Holsteijn is senior consultant bij Xebia.

 
Reacties
Eric Jan Malotaux op donderdag 16 december 2010 13:08

Spot on!

Andrej op donderdag 16 december 2010 13:29

Dit is precies wat we doen op mijn huidige project. We gebruiken nog wel een esb (servicemix), maar dan als applicatieserver voor integraties services die gebruik verantwoordelijk zijn voor transformatie en service compositie.

De meeste webservers zoals apache kunnen naast reverse proxy functionaliteit ook caching bieden, zodat je REST services kun cachen.

Roberto Viana op vrijdag 17 december 2010 10:20

Zonder meer een interessant artikel maar helaas gaan de auterus heel snel kort door de bocht bij het ontkrachten van de toegevoegde waarde van de ESB.

Een ESB levert meer dan alleen "het ontkoppelen van systemen" zoals hierboven wordt gesuggereerd. In essentie wat je met een ESB wilt realiseren is een gecentraliseerde platform waarbij applicaties op een gestandaardiseerde manier met alkaar kunnen interacteren en samenwerken zonder dat de mate van afhankelijkheid te groot wordt.

Met andere woorden als ik systeem A en systeem B via een ESB koppel, kan ik later een derde of een vierde systeem toevoegen die ook geinterseerd is in de input of output van systeem A of B. Daarnaast kan ik volledig toezicht (functioneel en technisch) houden over de hele E2E keten zodat ik te allen tijde op veranderingen(fouten, fluctuaties, enz..) in het process adequaat kan reageren.

Kortom de oplossing gepresenteerd in dit artikel vormt een alternatief maar het is ongetwijfeld geen vervanger van de ESB. Wellicht dat de keuze afhankelijk is van een aantal factoren zoals de grootte van de organisatie en de complexiteit in het integratielandschap.

Marcel op donderdag 23 december 2010 10:29

Zoals Roberto al aangaf denk ik dat de keuze van een reverse proxy afhankelijk is van het soort integratieprobleem dat men wil proberen op te lossen.

Wanneer men de reverse proxy oplossing gaat gebruiken, denk ik dat het belang van een goede organisatorische basis (geoptimaliseerde processen/gegevensstromen, verminderen gegevens redundancy e.d.)van groot belang is.

Veel organisatorische problemen kan men nu nog opvangen door de functionaliteit die een ESB bevat. Hierdoor ontstaat overige er wel een onwenselijke situatie. Echter, wanneer dit niet beschikbaar is, dient dit dus vooraf aangepakt te worden. De praktijk leert helaas dat niet iedere organisatie/project zich hier evengoed voor laat lenen...

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.