Open standaarden voor systeemintegratie

Juni 2008 - Voor systeemintegratie zijn twee specificaties ontwikkeld die erom strijden de standaard te worden: JBI en SCA. Wat betekenen deze standaarden? Wat zijn de verschillen? Welke van de twee zal uitgroeien tot de feitelijke standaard? Op deze vragen geef ik een antwoord in dit artikel.

Inleiding

Stel, u hebt te maken met veel verschillende software systemen: bijvoorbeeld financiële administratie, voorraadbeheer en klantenbeheer. Om dienstgericht te opereren wilt u deze systemen op een flexibele manier aan elkaar koppelen. Op de markt zijn er verschillende producten verkrijgbaar die dit kunnen, bijvoorbeeld Tibco BusinessWorks, BEA AquaLogic, Sonic ESB en Cape Clear ESB. Het vervelende is dat ieder product dit op zijn eigen manier doet. De toegepaste mechanismen lijken wel veel op elkaar, maar zijn ze niet uitwisselbaar. Hierdoor word je met de keuze voor een bepaald pakket afhankelijk van de leverancier. Om te kunnen werken met een bepaald pakket moet je mensen in dienst hebben die kennis hebben van dit specifiek product.

Standaardisering kan aan deze ongewenste situatie verandering brengen. Open standaarden zijn publiek beschikbare specificaties om een bepaalde taak te volbrengen. Doordat iedereen de standaard mag gebruiken, neemt de uitwisselbaarheid tussen de verschillende soorten hardware- en softwareonderdelen toe. Standaarden kunnen de aanpasbaarheid vergroten doordat ze algemeen geaccepteerd zijn en gebruikt worden door vele partijen in de industrie. Hierdoor zal het makkelijker worden om mensen met de juiste kennis te werven. Ook kan het makkelijker worden om systemen te vervangen. Verschillende software systemen die werken volgens open standaarden kunnen goed onderling samenwerken. Hierdoor ben je niet meer afhankelijk van één leverancier voor de gehele automatisering. Het zal dus eenvoudiger worden om producten van verschillende leveranciers met elkaar te laten communiceren.

In tegenstelling tot wat vaak wordt gedacht zijn SOA en ESB geen standaarden. SOA (Service-Oriented Architecture) is geen standaard, maar een denkrichting om integratie binnen een bedrijf te bewerkstelligen. Het idee is dat een organisatie zich opdeelt in eenheden die met elkaar samenwerken op basis van diensten, meestal uitgevoerd met behulp van ICT. ESB (Enterprise Service Bus) is ook geen standaard, maar een technisch concept. Centraal staat  een aparte laag waarin afzonderlijke systemen kunnen samenwerken. In deze laag kan gegevensuitwisseling plaatsvinden en worden dingen geregeld als beveiliging, registratie en orkestratie. ESBs ondersteunen langlopende processen waarin de status van een bericht kan veranderen.

Java Business Integration (JBI)

JBI is een initiatief van de Java gemeenschap en is bedoeld als een uitbreiding op de programmeertaal Java. JBI beschrijft hoe communicatiemogelijkheden en bedrijfslogica losgekoppeld kunnen worden. De invalshoek van JBI is zeer technisch van aard en eigenlijk bedoeld voor leveranciers van middleware software.

JBI beschrijft een uitbreidbare technische infrastructuur. In de specificatie wordt onderscheid gemaakt tussen componenten die het transport regelen (binding components) en componenten die bepaalde bedrijfslogica uitvoeren (service engines). Maar eigenlijk doet dat er niet toe, het onderscheid is puur logisch. Technisch gezien zijn de componenten identiek; zowel service engines als binding components kunnen diensten leveren of  afnemen. De infrastructuur is zodanig modulair opgezet dat nieuwe componenten op eenvoudige wijze kunnen worden toegevoegd. De specificatie schrijft niet voor welke componenten in een implementatie aanwezig moeten zijn. Dit mag een leverancier zelf bepalen. Het is mogelijk om eigen componenten te maken en toe te voegen aan de infrastructuur.

Figuur 1: Plug-in architectuur van JBI

Componenten praten niet rechtstreeks met elkaar maar via een routeringmechanisme. Een bericht dat binnenkomt op een binding component wordt vertaald naar een genormaliseerd XML bericht. Hieraan wordt vervolgens metadata toegevoegd m.b.t. de service die uitgevoerd dient te worden. De Normalized Message Router zorgt ervoor dat  het bericht terecht komt bij de betreffende service engine. 

Figuur 2: Routeringsmechanisme van JBI

Hoe de componenten met elkaar samenwerken wordt geconfigureerd in een XML bestand (jbi.xml). Hierin wordt beschreven welke componenten diensten afnemen of leveren. Elke service wordt weer op een aparte manier geconfigureerd. Een JBI service wordt verpakt in een service unit. Een of meerdere service units worden gecombineerd tot een service assembly. Zo’n bundeling van services kan in principe op elke willekeurige JBI implementatie draaien. Dit klinkt ingewikkeld maar gelukkig valt het gebruik in de praktijk mee. Verschillende producten bieden een grafische manier om componenten te configureren. Hierdoor is het niet nodig om de interne werking van de JBI infrastructuur te begrijpen.

Service Component Architecture (SCA)

De SCA specificatie is voortgekomen uit een consortium van software leveranciers. Daar waar JBI zich richt zich op leveranciers, ziet SCA vooral de applicatie programmeur als doelgroep. Er is getracht om een model te introduceren dat eenvoudig te begrijpen is en integratie vraagstukken op kan lossen. Over hoe de onderliggende infrastructuur werkt is niets vastgelegd.

Componenten zijn de bouwstenen van SCA. Een component kan een Java programma zijn maar ook een BPEL proces. Ook is mogelijk om Spring, C++, Cobol en PHP te gebruiken. Eén of meerdere componenten kunnen worden gecombineerd om een bepaald stuk functionaliteit te realiseren. Zo’n combinatie wordt in SCA een composiet genoemd. Een composiet kan op zijn beurt gebruikt worden als component in een composiet.

Figuur 3: SCA composiet

Een composiet wordt beschreven in een XML bestand (Service Component Definition Language) die aangeeft welke componenten in de compositie zitten en hoe deze componenten met elkaar samenwerken. Alle leveranciers zullen echter een grafische ontwikkelomgeving aanbieden zodat dit bestand niet handmatig gemaakt moet worden.

Het koppelvlak van een component wordt in SCA een service genoemd. Hoe je met het component communiceert is onafhankelijk van het koppelvlak. Per service is aan te geven welke wijze van communicatie deze moet ondersteunen; het is bijvoorbeeld mogelijk om een component als web service en/of als Java interface aan te bieden. Voor externe afhankelijkheden kun je gebruik maken van referenties. Het concept van de referentie lijkt op het mechanisme zoals dit door o.a. het Spring raamwerk wordt toegepast: dependency injection.

Figuur 4: Situatie waarin drie SCA composieten van elkaars functionaliteit gebruik maken

Anders dan bij JBI is het in SCA niet mogelijk om zelf een nieuwe technologie of communicatie protocol toe te voegen. Alle mogelijke technologieën en protocollen zijn vastgelegd in de standaard.

Afhankelijkheid van de leveranciers

De manier waarop SCA en JBI garanderen niet afhankelijk te zijn van één leverancier is verschillend. JBI zegt dat je geen gebruik hoeft te maken van één leverancier maar dat je componenten van verschillende leveranciers kunt combineren in één oplossing. Dit is een mooi streven maar in praktijk blijkt dit niet altijd zo eenvoudig. Bovendien wordt JBI niet door alle leveranciers ondersteund. Zo zullen IBM en BEA geen producten op de markt brengen die aan deze standaard voldoen.

Bij SCA is onafhankelijkheid van de leverancier gewaarborgd doordat zowel de kennis van het programmeermodel als de broncode overdraagbaar is naar andere systemen. De vraag die je zou kunnen stellen hoe een leverancier zich bij SCA kan onderscheiden? Een leverancier kan zich alleen onderscheiden door om meer functionaliteit in zijn product te stoppen, waardoor de compatibiliteit met de standaard in gevaar komt. Dat SCA niet alleen Java ondersteunt maar ook talen als PHP en Cobol zal niet echt meerwaarde bieden ten opzichte van JBI. Vanwege de grote beschikbaarheid van Java programmeurs en de uitgebreide features van Java zal in de meeste gevallen gekozen worden voor de Java implementatie.

En de winnaar is...

SCA. Het ontwikkelen van toepassingen is met SCA veel eenvoudiger. De bedenkers ervan hebben begrepen dat het draait om gebruiksgemak en toepassingsmogelijkheden. Als programmeur ben je niet geïnteresseerd in de interne werking maar in het realiseren van de gewenste functionaliteit. Dat dit programmeermodel wordt toegepast door verschillende leveranciers maakt het voor ontwikkelaars heel eenvoudig om over te stappen van de ene leverancier naar de andere. Het simpele programmeermodel stelt een programmeur in staat om complexe problemen op te lossen. Doordat componenten ook uit Java en Spring programma’s kunnen bestaan, zijn de mogelijkheden legio. Behalve programmeurs kunnen ook eindgebruikers, zij het op een beperktere schaal, effectief gebruik maken van SCA.

JBI is een heel technisch en complex verhaal. Dit zal veel bedrijven afschrikken. Een groot manco is het ontbreken van een eenduidig programmeermodel. Als je bijvoorbeeld Apache ServiceMix met Sun OpenESB vergelijkt valt op dat de manier van programmeren totaal verschillend is. Hierdoor zullen programmeurs inwerktijd nodig hebben als ze willen overstappen. En dat is iets dat je juist wil voorkomen.

Het is jammer dat de leveranciers van systeemintegratie software in twee kampen verdeeld zijn. Het zou beter zijn als er een gezamenlijk initiatief was voor het tot stand komen van een standaard. Maar concurrentie heeft ook voordelen. Er zal een kruisbestuiving plaatsvinden die er voor zorgt dat goede ideeën in beide specificaties worden opgenomen. Standaardisering heeft er in elk geval voor gezorgd dat systeemintegratie niet langer het exclusieve domein is van grote spelers als Tibco en IBM. Tegenwoordig zijn er open source alternatieven beschikbaar. En dat was enkele jaren geleden nog ondenkbaar.

Referenties

• JBI specificatie:
  http://jcp.org/en/jsr/detail?id=208
• SCA specificatie:
  http://www.osoa.org/display/Main/Service+Component+Architecture+Specifications
• ServiceMix, een open source JBI implementatie:
  http://servicemix.apache.org/
• Tuscany, een open source SCA implementatie:
  http://tuscany.apache.org/

Over de auteur
Jos Nieuwenhuis is een Java / SOA consultant. Hij combineert ruime ervaring op het gebied van enterprise Java met uitgebreide kennis van integratie en SOA architecturen en oplossingen.