Posts Tagged ‘testing’

This is just an extension to my previous post (SOA Testing). Most of the java developers look to automate web service testing. If you are using SOAPUI, this is possible by writing junit test cases and then invoking SOAPUi projects from junit for a particular test case. It might be the case that you do not want to rely on any tool while testing and end up creating test cases that creates and invokes request for you. With the same intention, I was looking for a free tool and found this one – SOAMOA.

Still in its infancy stage, this tool may not be used for all your testing needs but some features look promising. The GUI is not too great. It doesn’t offer you to set preferences and does not support web services standards. For all this, you already have a free tool SOAPUI (not the pro version). The only striking feature is the ability to generate junit test cases and groovy script based upon your request. You just need to import your WSDL and create SOAP Request as you generally do in SOAPUI.

Here is a list of the leading testing tools available in the market to test the SOA components. I believe that no tool can completely fulfill the testing requirements of an SOA but you can accomplish a lot. The tools should be intelligent enough to carry out:

It is not easy to test components of a service oriented architecture. Many people use the terms SOA and Web Services interchangeably and think that SOA cannot be implemented without web services. However, this is not true. Web Service is just a way to implement SOA. There are projects which do not use web services but still inherit merits of a SOA. Grid Computing is one such example. So if you have a project where you have used an ESB to choreograph web services to achieve a desired functionality, then testing these web services (using a tool like SOAPUI etc) is not enough. One many not be interested only in testing the business functionality but also in testing the integration logic that resides within an ESB. This may not sound feasible as in most of the cases there are more than one webservice and each will accept input in a different format. So you cannot simulate all web services. But you definitely create a wrapper service that can accept request in any format and helps you gauge whether your ESB has performed its job before invoking the service. Now what does a wrapper service do in this case:

1. No changes required in the ESB. Just a small configuration so that when you perform a dynamic lookup of end-point, the request is always directed to the wrapper service.

2. The wrapper service does not require implementing operations for each request. One operation that takes an Object as an input can serve the purpose.

3. A SOAP Handler that validates the SOAP Header and a function call from handleRequest method of SOAP Handler to validate the SOAP Body or message payload can be implemented.