Business Transaction Management

Als we de al wat gedateerde televisiereclame van Microsoft moeten geloven, is het integreren van bestaande systemen een fluitje van een cent. In de commercial vertelt een al wat oudere heer met enige trots welke systemen hij al sinds zijn indiensttreding geïntegreerd heeft. En dat is een imposante rij. Als de aandachtig luisterende jonge dame vervolgens vraagt hoelang hij dan al bij dat bedrijf werkt, antwoordt hij drie maanden. En haar mond, en uiteraard ook die van de kijkers, valt open van verbazing. Maar hij had het uiteraard niet kunnen doen zonder de hulp van Microsofts software. En kijkers die zelf kampen met integratieproblemen krabben zich verbaasd op het hoofd en vragen zich af wat zij dan verkeerd doen.

Laten we eerlijk zijn, geen enkel integratieproject, waarbij applicaties gekoppeld moeten worden die initieel niet voorbestemd waren om samen te werken, is een klusje van drie maanden. Als integratie betekent dat applicaties onderling gegevens kunnen uitwisselen, dan is dat misschien nog wel te doen. Maar als er transacties in het spel komen, wordt het lastig.

Stel dat er in een organisatie vier applicaties geïntegreerd moeten worden. Bijvoorbeeld, als er een nieuwe klant in applicatie A wordt ingevoerd die zelfde gegevens ook in de andere drie applicaties opgevoerd moeten worden. Het gaat hier dus om vier operaties. Hierbij geldt dan tevens de alles-of-niets garantie. De nieuwe klant wordt opgevoerd in alle applicaties of in geen van alle. In dit geval moet er met transacties gewerkt worden.

Als de gegevens direct in de onderliggende databases van de applicaties ingevoerd kunnen worden, dan is dit redelijk eenvoudig. Alle bekende databaseservers ondersteunen two-phase commit protocollen, en daarmee bieden zij de alles-of-niets garantie. Maar stel dat het ongewenst of zelfs geheel onmogelijk is om direct de databases te benaderen. Dan zit er niets anders op dan de gegevens van die applicaties op te voeren. En dat maakt het ineens lastig. Het impliceert dat een transactiemanager het two-phase commit protocol over applicaties gaat uitvoeren. Bekende EAI-tools van SeeBeyond, Tibco, Vitria en WebMethods, zijn hier toe in staat en ook nieuwe producten als Choreology.

In de praktijk komen er ook nog complexere constructies voor dan het alles-of-niets principe. Bijvoorbeeld, van een reeks van vier operaties zijn er drie verplicht en is één optioneel. Of twee operaties zijn verplicht en maximaal één van de andere twee moet uitgevoerd worden. 

Als de transacties complexer van aard worden en als gegevens via applicaties (eventueel externe applicaties) opgevoerd moeten worden, dan praten we niet meer over 'gewone' transacties, maar over business transacties (en uiteraard is er maar een vage scheidingslijn tussen deze twee). Een zogenaamde business transaction manager (BTM) wordt dan verantwoordelijk voor het afhandelen van de business transacties.

Echter, een dergelijke BTM dient dan wel speciale ingangen in de applicatie te hebben. De BTM moet de applicatie kunnen vragen gegevens tijdelijk te blokkeren, eventueel zaken te ‘cancellen’ of te ‘committten’. Uiteraard hebben de meeste applicaties, zeker als ze al meer dan twintig jaar oud zijn, die ingangen niet. Ze zijn nooit ontwikkeld om als een marionettenpop door een BTM bestuurd te worden. Dus zal er met de hand code aan de oude applicatie toegevoegd moeten worden. En dit is waar business transaction management tegen een enorme hindernis aanloopt. We praten dan nog niet eens over aangekochte applicaties waarvan we niet eens de ontwikkelaar zijn. Gaat de leverancier ze dan aanpassen?

Tegenwoordig is de technologie beschikbaar om de meest complexe business transacties te draaien, maar zijn de applicaties wel gereed? Business transaction management is knap, is krachtig en gewenst, maar stelt hoge eisen aan de onderliggende applicaties. En dat zou wel eens het struikelblok kunnen worden.