Soa Testing Simplified Series 2

Soa Testing Simplified Series 2

In the last article ‘Series-I’ we got familiar with SOA architecture, and its some components. We saw how a web service ‘wsdl’ file looks like and learnt how we decipher the complex information present in the file, so that we understand the web service better. In this series we will dig deeper into SOA architecture and try to figure out how exactly the various components of SOA architecture communicate with each other to solve the complex business need.

Let us get back to our ‘MoneyConverter’ web service. I typed in the url on the browser http://localhost/MoneyConverter/Converter.asmx and this is what I got:



[Fig: 1a]

Now click on any of the method to find out the request and response format for them:



[Fig: 1b]

We will now test the web service method; the screen shot for the same is attached below:


[Fig: 2a]



[Fig: 2b]

Till now we saw what to expect if we open the web service in the browser. It displays the information about the various methods present in the service. The request and response format of each method of the service. And if the service is hosted locally on the system then you may invoke it and test its methods.


So far so good, but is it all to the complex web service architecture. Well no, what we just saw was the front end of the SOA architecture. Lets get to the back end of the architecture and understand how exactly the various components of the architecture communicate with each other to provide us with the result. Let’s take a good look at the diagram below before we move further:


[Fig: 2c]

As clear from the diagram we can see three components of the SOA architecture: Service Provider, Directory and Service Consumer. They communicate with each other in form of xml packets over the SOAP protocol. We will take each part of the figure and understand its role:


  1. Service Provider: A service provider is the one who has actually built the web service to fulfill a business requirement. The web service will be hosted at the service provider location and the service consumer has to communicate with the provider to get its work done.
  2. Directory: A directory is where the Service Provider publishes the ‘WSDL’ file related to the web service. Directory could be a local directory or UDDI. UDDI stands for Universal Description, Discovery, and Integration; it is defined as a directory of services. A service consumer first queries the directory for the wsdl file of the web service.
  3. Service Consumer: A service consumer is the one who requires the web service to meet its business requirement. It has to first query the directory to get hold of the wsdl file of the web service. This is also known as discovering the web service. It then constructs its request to be queried directly against the service provider for the response.


The communication among the components is as follows:


  1. The Service consumers, first queries the directory of services for the web service. This is also known as ‘Discovery’.
  2. The Directory responses back using the WSDL file to the Service Consumer.
  3. The Service Consumer now using the WSDL file generates the SOAP request which is sent to the Service Provider which in return responds back with the SOAP response based on the WSDL file.


Enlightened with the functioning of a web service architecture we come to the end of this series of the blog. In the next series we will start exploring how do we go about testing a web service and what all tools both open source and commercial are available for it.







No comments

Leave a reply

Your email is never published nor shared. Required fields are marked *