Dit artikel is geschreven door Edwin van Asch
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.
Bron: Computable
Filed under: Service oriënted architecture (soa) | getagged: Ketentest, Ketentesten, Service oriented architecture, soa testen
