XSLT niet toereikend voor applicatie-integratie

Overal wordt aan applicatie-integratie gedaan. Het is dan ook niet verwonderlijk dat de markt van EAI-tools (Enterprise Application Integration) groeiende is. Al deze producten hebben hun eigen, zelfverzonnen taal om aan te geven hoe gegevens tussen applicaties uitgewisseld moeten worden. Helaas ontbreekt een gestandaardiseerde taal voor deze categorie tools. Er wordt wel eens gesuggereerd dat XSLT (eXtensible Stylesheet Language Transformations) die rol van standaardtaal voor applicatie-integratie zou kunnen vervullen. XSLT is weliswaar een mooie en krachtige taal, maar is voor applicatie-integratie niet toereikend.

In een notendop, een EAI-tool is verantwoordelijk voor het uitwisselen van gegevensstromen tussen applicaties. Dit zijn bijna altijd applicaties die oorspronkelijk niet ontworpen zijn om met elkaar te communiceren. Veranderingen binnen het bedrijf of in de markt vereisen dat dit later toch moet gebeuren. Bijvoorbeeld, in een factureringsysteem worden dagelijks nieuwe klanten opgevoerd. Vanaf nu willen we dat die klantgegevens direct beschikbaar zijn in het CRM-systeem. Het eerste systeem is jaren geleden zelf ontwikkeld, terwijl het CRM-systeem zeer recentelijk aangeschaft is. Een EAI-tool kan ingezet worden om de gegevens van de nieuwe klanten op te pakken en zal er voor zorgen dat ze in het CRM-systeem opgevoerd worden.

EAI-tools werken dus met gegevensstromen. Uit het ene systeem wordt een gegevensstroom gehaald en bij de ander opgevoerd. In de meeste gevallen zal de inkomende gegevensstroom wel eerst getransformeerd moeten worden voordat ze als uitgaande stroom aan het andere systeem aangeboden kan worden. In een EAI-tool dienen we daarom de mogelijkheid te hebben transformaties van gegevensstromen te specificeren. Hiervoor bieden de meeste producten nu leverancierafhankelijke talen. Dit is geen ideale situatie, ik hoef u niet uit te leggen waarom.

Omdat gegevensstromen zeer verschillend van formaat kunnen zijn (de ene kan een EDI- of Swift-bericht zijn, de andere een SQL INSERT-instructie en de derde een aanroep via de SAP R/3 BAPI), proberen de meeste tools elk binnenkomend en uitgaand bericht eerst te vertalen naar een neutrale taal. Sommige gebruiken hiervoor XML. XML is namelijk qua bouwstenen rijk genoeg om de meeste gegevensstromen te modelleren.

Als XML gebruikt wordt, dan is de suggestie om XSLT te gebruiken voor het specificeren van transformaties begrijpelijk. Nogmaals, XSLT is een mooie gestructureerde, declaratieve taal, die hier uitermate geschikt voor is. Bovendien is ze gestandaardiseerd. Natuurlijk zijn er ook enkele nadelen, zoals de tegenvallende performance van XSLT-processors. Maar dat is typerend voor een jonge, declaratieve taal. Geef de ontwikkelaars van deze XSLT-processors enkele jaren de tijd en dit probleem zal voor een groot deel verholpen zijn. 

Maar naast transformaties moet een EAI-tool nog meer faciliteiten bieden: een EAI-tools moet onder andere met complexe transacties kunnen omgaan, het moet kunnen ingrijpen als het ontvangende systeem de gegevens niet accepteert, en het moet weten wat te doen als tijdens het transport van een bericht het netwerk uitvalt. Dit zijn alle faciliteiten die we nu niet met XSLT kunnen beschrijven. De verwachting is ook niet dat ze in de nabije toekomst toegevoegd zullen worden. Om de woorden van een lid van de XSLT-werkgroep te citeren: "De bedoeling is niet dat XSLT een volledige programmeertaal wordt, het zal geen concurrent worden van Java en VisualBasic".

In de wereld van applicatie-integratie ontbreekt dus nog een standaardtaal voor het volledig beschrijven van berichtenstromen. Indien die taal er komt, dan hoop ik wel dat voor het transformatiedeel XSLT gekozen is. Het zou vervelend zijn als hier een andere transformatietaal voor ontworpen zou worden. XSLT is taaltechnisch een prima taal voor transformaties van gegevensstromen, het is alleen niet toereikend genoeg voor alle wensen uit de wereld van applicatie-integratie.