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.
Edwin van Asch
Ik onderschrijf het verhaal van Edwin volledig: om SOA-applicaties goed te kunnen testen, moeten er keten testen, of beter gezegd end-to-end testen uitgevoerd worden. Voor een ontwikkel/test-omgeving is dit afdoende. Hiermee wordt de functionaliteit vanuit gebruikersperspectief bezien in combinatie met de user-experience (binnen de kaders van de ontwikkel/test-omgeving. Echter in SOA-omgevingen zijn naast Functionaliteit en User-experience, ook Beschikbaarheid, Performance, Veiligheid en Schaalbaarheid van doorslaggevend belang. In hoeverre hieraan voldaan kan worden, zodat sprake is van een succesvol opererende SOA-omgeving, wordt in toenemende mate bepaald door de onderliggende communicatie-infrastructuur. Deze is bijvoorbeeld cruciaal voor de werking van een ESB van een wereldwijd verspreidde SOA-implementatie. Ook dit zal getest moeten worden. Hiervoor zijn aanvullende testen nodig in andersoortige testomgevingen. Doordat allerhande services elkaar autonoom kunnen triggeren, achtereenvolgens en gelijktijdig, genereert dit een diversiteit in de applicatie- en trafficflows. Diversiteit in soorten verkeer en in de karakteristieken van het verkeer. De voorkomende combinaties hebben impact op Performance. Hiervoor dienen meerdere soorten volume-, performance en stresstesten uitgevoerd te worden, zowel op applicatieniveau als onderliggende communicatie-infrastructuur-niveauVoor beschikbaarheid dienen redundantie-oplossingen en fail-over machanismen getest te worden binnen de service-keten en over de service-ketens heen. Security kent zo ook zijn eigen specifieke testen en schaalbaarheid laat zich ook goed testen middels simulaties. Dus het volledig uittesten van een SOA-implementaties vraagt om een framework van specifieke testen, die apart en in combinatie met elkaar pas tot een weloverwogen oordeel kunnen leiden.Wat mij vaak opvalt, ook in het verhaal van Edwin, dat er vanuit SOA gekeken wordt naar Applicaties en de Applicatieinfrastructuur in ontwikkel/testomgevingen, maar dat communicatie-infrastructuren niet meegenomen worden, en juist deze worden meer en meer cruciaal. Een optimale SOA-implementatie kan niet zonder bestaande netwerken te evolueren naar Service Oriented Infrastructuren en ook die moeten meegetest worden om zinvolle uitspraken te kunnen doen over het werkend succes van een SOA-omgeving. Oscar RoelofsBusiness Unit Manager, ion-ip
Oscar,Je hebt helemaal gelijk. Naast de applicatie infrastructuur moet ook de communicatie infrastructuur getest worden. De mooie analogie van SaaS met stroom uit het stopcontact is nog ver weg. De infrastructuur zou de vanzelfsprekendheid en beschikbaarheid moeten hebben van het elektriciteitsnetwerk in een land zonder Apache helikopters. Tot die tijd, testen, testen en nogmaals testen. Is het reeel om te veronderstellen dat je een dergelijke infrastructuur 100% kan nabootsen in een testomgeving om daar te kunnen testen of is de productie omgeving de enige plek waar dit mogelijk is (gegeven een complexe infrastructuur).
Beste Edwin,100% produktielike bestaat alleen in produktie. Echter met inzet van slimme oplossingen kun je een aardig eind in de buurt komen. Binnen systeemontwikkeling is de afgelopen jaren veel resultaat geboekt met Functionele, Performance en Volumetesten. Ook voor SOA-omgevingen zijn de eerste testsuites op de markt. Binnen communicatie-infrastructuren zijn er ook voldoende mogelijkheden om te testen op Performance en Throughput. Denk aan dedicated testapparatuur waar op basis van diversiteit van gebruikersprofielen een netwerk gesimuleerd kan worden, waarbij daadwerkelijk load (IP-sessies) gegeneneerd worden om de applicatieomgeving te beproeven alsof die in produktiestaat.Daarnaast komen er steeds meer integrale testmogelijkheden om zogenaamde end-to-end testen uit te voeren, al dan niet m.b.v. agents, om zo de user-experience te testen en/of te monitoren. Voor de volledigheid: op het gebied van security zijn er vervolgens nog een scala aan testen en testtools beschikbaar op zowel applicatieniveau als communicatie-infrastuctuur level.Al met al kunnen we een heel eind komen, ook voor SOA-omgevingenOscar Roelofsion-ip