Hoe test ik mijn SOA

Voor een presentatie die ik moest houden was ik op Google aan het zoeken met de zoekwoorden “SOA” en “testen”. Voor IT’ers een normale combinatie, voor de rest van Nederland een onderwerp waar ze eigenlijk het liefst helemaal niets mee te maken willen hebben. Helaas is semantiek nog niet iets waar Google mee overweg kan.

Het onderwerp waar ik naar op zoek was, was" "hoe test ik mijn Service Oriented Architecture (SOA)". Bij het uitrollen van een op SOA principesgebaseerde architectuur komen steeds meer organisaties er achter dattraditionele testmethodes en gereedschappen niet meer voldoende zijn om decomplexe gelaagde wereld van een SOA grondig te testen.

Het testen van de individuele componenten, de webservices bijvoorbeeld, dat gaat nog wel. De interface is immers goed gedefinieerd in devorm van een WSDL. De gebruikersinterface testen wordt al wat moeilijker, moderne webapplicaties maken steeds meer gebruik van AJAX  (ga daar maar eens op zoekenmet Google) en daar kunnen sommige testtools niet zo goed mee omgaan. Het testen van een complete SOA infrastructuur is een heel ander verhaal. Eendergelijke complexe infrastructuur bevat bijvoorbeeld een BPM product, een ESB, messaging middleware , Enterprise Java Beans en een database. Allemaal met elkaar verbonden en van elkaar afhankelijk. Loosely coupled dat wel, maar hoe je het ook bekijkt een SOA zit vol afhankelijkheden.

En daar gaat het fout, los kun je al die onderdelen best wel op de een of andere manier testen, maar toch kan het dan fout gaan als je allesaan met elkaar gaat verbinden. Vanaf de buitenkant lijkt alles goed te gaan, detransactie wordt netjes bevestigd op het scherm, maar is de transactie ookwerkelijk in alle uithoeken van je infrastructuur op een correcte manieraangekomen en nergens blijven steken of verkeerd vertaald?

Het testen in een SOA omgeving vraagt om controle door de gehele keten, op elk niveau en bij elk protocol. Van de userinterface via de BPM laag, de ESB laag,de applicatie server, de message queue tot en met de database. De transactie moet door de hele keten worden gevolgd en op elke plek geverifieerd.

Als er iets niet werkt zoals het zou moeten is het in eenSOA niet eenvoudig om de vinger op de zere plek te leggen. Gaat het fout in deop Web 2.0 gebaseerde interface, de XSLT vertaling in de ESB, de Java code inde Java bean of de vertaling naar de database. Wie het weet aan de hand van eencryptische foutmelding in de user interface mag het zeggen. Het gevolg hiervan is dat veel kostbare tijd verloren gaat bij het zoeken naar de plek waar hetfout gaat. Door te testen en te verifiëren door de hele keten heen kun jedirect controleren waar een eventuele fout zit en dus welk team het probleemmoet gaan repareren.

Een gedegen SOA testomgeving die zich niet alleen richt op specifieke SOAcomponenten zoals webservices maar eigenlijk de gehele applicatieinfrastructuur tot zijn werkgebied rekent kan het verschil maken tussen eensuccesvolle of mislukte SOA implementatie.

Systemation