By Pallavi Sharma

In this blog post we will understand how we use Rational SOA Tester tool to test our web services.

Pre Requisites:

1.    Rational Performance Tester to be installed on the system.
2.    Rational SOA Tester plug-in to be installed on it.
3.    The WSDL files of the web services you wish to test.

Once you have all these inputs in place you can start testing your web service right away. First of all you will create a Performance Test Project in RPT. We create a performance test project as RPT uses the same framework to test web service as it uses for performance testing. Once we are done with that we need to import our WSDL file from the file system to the project folder.

After we have imported the WSDL file, we will create our very first test for this web service. To do so, we need to start the Recorder, and chose Web Service Recording using the Web Services Explorer.

You will see your web service in the Web Service Explorer mode. The web service explorer mode will list down the methods and clicking on any method will ask you to input the method arguments, once done that click next and it will show you the output, meanwhile the recorder is recording all the request – responses and once done when you click on stop recording the test is generated.

Now you have in your hands a recorded web service test. In the next series we will see how do, we go about editing the web service test. Use datapool to parameterize the test, use verification points to validate the test etc.

References:

1. Soa Tester Tutorials: IBM.

(Copyrighted by CresTech Software Systems Pvt. Ltd.)

By Pallavi Sharma

In the last series we saw what are the various challenges which a tool should overcome to test a SOA based application. We saw a list of commercial and open source tools which can assist us in testing our web services.

From this series we will take each tool one by one and understand what all it has to offer us. The first solution to web service testing we will consider is the one provided by Rational. Rational offers the following solutions:

a. Rational Tester for SOA Quality
b. Rational Performance Tester Extension for SOA Quality.

Following are the list of features which they offer:

• Both built on Rational Performance Tester technology
• Support for Web Services standards UDDI, WSDL, SOAP, HTTP, HTTPS, WS-Security
• Integrated with Rational Test Management tools (Test Manager with ClearQuest)
• Monitoring tools (Tivoli) can be easily integrated with it.

The best part of this tool is for both functional and performance testing of the web service we can use the same interface of Rational Performance Tester. As shown in the figure below:

[Fig- 1a]

Following are the various advantages of Rational SOA Tester:

• Simplify testing of GUI-less service
o Automated generation of web service test client
o No programming knowledge necessary to create, comprehend, modify, and execute a functional or performance test
o Automated data correlation and data driven testing through a code-free test environment
• Simplify service integration testing
o Automated test creation from Web Sphere Business Process Execution Language resources
• Create, comprehend, modify, and execute a functional or performance test
o Graphical test editor enables both high-level and deeper detail views
o Support Web services standards (e.g. SOAP,HTTP(S), WS-Security, UDDI)

How to Get Rational SOA Tester:

You need to have Rational Performance Tester 7.01 installed on your system. Once you have that you can download the SOA Tester as an extension over RPT. The link for the same is as follows: http://www.ibm.com/developerworks/downloads/r/tsq/learn.html?S_TACT=105AGX15&S_CMP=ART

A simple tutorial explaining how you use the SOA tester will be the topic of our next blog series. Till then hopefully you have acquired the tool.
References:
1.http://www.ibm.com/developerworks/downloads/r/tsq/learn.html?S_TACT=105AGX15&S_CMP=ART

(Copyrighted by CresTech Software Systems Pvt. Ltd.)

By Pallavi Sharma

So far, we have undertaken the difficult voyage of web services, SOA-Architecture and have come out of it empowered with the knowledge of what this new buzz SOA is all about. In this series of blog we will delve deeper into SOA and understand how do, we go about testing SOA. We will also see what all tools both open source and commercial are available in the market to help us achieve it. We will also take each tool one by one and understand how to best utilize it to test SOA.

Let’s first understand what all issues needs to be considered when we test any web service: [Ref 1]
• Web Services are intrinsically distributed and are platform and language agnostic.
• Web Services can be chained with dependencies on other 3rd party Web Services that can change without notice.
• Web Services ownership is shared across various stakeholders.
• Web Services client developers typically only have access to interfaces (WSDLs) and lack access to code.
• High level of reuse of web services.

As we know web services are based upon loosely coupled architecture. They are platform and language independent which increases the complexity of testing them. A web service usually calls another web service which might be a third party service. Oftenly 3rd party web service changes without prior information resulting in your web service failure. Also, if you are using a 3rd party web service all you have access to is a WSDL document of the web service and no code is available. A 3rd party web service can be used by a large number of users raising performance and security concerns which needs to be taken care of also.

Keeping all this in mind we need to also judge a test tool which takes the following issues into consideration:

• No User Interface to easily play a test
• High level of reuse of the services
• Testing at the service and end-to-end levels
• Interoperability, conformance, security penetration…
• Support of SOA standards and specific implementations WSDL, SOAP, UDDI, HTTP, WS-Security, …

A test tool to test any web service should support the various SOA standards like WSDL, SOAP, XML. Usually there is no UI available to test a web service. So the test tool should provide a user friendly interface to test the GUI less service. It should also assist in testing the interoperability, conformance issues which do arises in web service testing.

The commercial tools which are available in the market to test web services are:

1. IBM : Rational SOA Tester
2. HP: LR and QTP
3. Crosschecknet
4. Parasoft

The open source tools for SOA testing are as follows: [Ref 2]

1. Eviware SoapUI 1.6
2. PushToTest TestMaker
3. WebInject

In the coming series we will take each tool one by one and understand how do, we test the web service using it.

References:

1. http://www.crosschecknet.com/soa_testing_black_white_gray_box.php
2. http://www.infoworld.com/article/07/05/11/19TCwebservicetest_1.html

(Copyrighted by CresTech Software Systems Pvt. Ltd.)

By Pallavi Sharma

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]
Response:

[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.
References:

1. http://www.service-architecture.com/web-services/articles/web_services_explained.html

(Copyrighted by CresTech Software Systems Pvt. Ltd.)

By Pallavi Sharma

If you have reached this blog, then may be you have heard about SOA and testing SOA applications, or may be you understand testing and would like to know what SOA testing is all about or maybe you want to know what SOA and testing is all about…  Well however complicated your case may be… I would explain SOA and testing SOA applications in an uncomplicated way to you in a series of blogs and this is the very first blog on it.

SOA stands for Service Oriented Architecture. It describes IT infrastructure which allows different applications to exchange data with one another as they participate in business processes. The aim is a loose coupling of services with operating systems, programming languages and other technologies which underlie applications. [1].

These services inter-operate based on a formal definition (or contract, e.g., WSDL) that is independent of the underlying platform and programming language. Services written in C# running on .NET platforms and services written in Java running on Java EE platforms, for example, can both be consumed by a common composite application (or client). Applications running on either platform can also consume services running on the other as Web services, which facilitates reuse.

Let’s understand the term ‘Web Service’. A Web Service in simplistic terms is a web enabled API, that can be accessed over the network. In the SOA architecture it is one component which takes care of a specified business need. Each web service has its own contract file which is required to communicate with it. This contract file is termed as WSDL, which is defined as, ‘Web Service Description Language’. As clear from the name, it provides information about what a web service is all about. The kinds of information you can fetch from the WSDL file are:
1. Where the web service is hosted.
2. What functionality the web service provides.
3. What all methods a web service consist of.
4. What arguments the web service takes and what response it returns.
Let’s take an example web service and its wsdl file and try to make sense out of it. The example web service is ‘MoneyConverter’; this service converts a currency value provided in Indian Rupees, to Dollars and vice versa. It solves a business requirement and will consist of two methods, you guessed them right:

a. RupeesToDollars
b. DollarsToRupees

Let’s take a look at the WSDL file for this service, which is an xml file describing this web service. [File attached]

To decipher the WSDL document, let’s begin from the end. The last xml node of the wsdl file provides information where the service is hosted.

“<wsdl:service name=”Converter”>
<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>A web service for converting currencies</wsdl:documentation>
<wsdl:port name=”ConverterSoap” binding=”tns:ConverterSoap”>
<soap:address location=”http://localhost/Converter/Converter.asmx” />
</wsdl:port>”

Moving up, we find information about what all methods are present and what arguments they take and the return value.

wsdl:portType name=”ConverterSoap”>
<wsdl:operation name=”RupeesToDollar”>
<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Convert from Rupees to Dollars</wsdl:documentation>
<wsdl:input message=”tns:RupeesToDollarSoapIn” />
<wsdl:output message=”tns:RupeesToDollarSoapOut” />
</wsdl:operation>
<wsdl:operation name=”DollarToRupees”>
<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Convert from Dollars to Rupees</wsdl:documentation>
<wsdl:input message=”tns:DollarToRupeesSoapIn” />
<wsdl:output message=”tns:DollarToRupeesSoapOut” />
</wsdl:operation>
</wsdl:portType>

Now we would like to know what does the input message looks like, and the output, for this lets move a bit up the document. The “wsdl type” xml node defines all the data types which are passed as arguments or returned as response after the method invocation. Let’s take one node and explain it further:

<s:element name=”RupeesToDollar”>
<s:complexType>
<s:sequence>
<s:element minOccurs=”1″ maxOccurs=”1″ name=”amount” type=”s:decimal” />
</s:sequence>
</s:complexType>
</s:element>
It states that the element is of type ‘decimal’, name of the element is ‘amount’, and it is a mandatory argument for the method, which can be understood by the minoccurs and maxoccurs attributes of the s:element node.

So, from the above information provided by the WSDL document of the MoneyConverter, we now know the following;

1. The port where the web service is hosted.
2. The methods which are present in the web service.
3. The arguments and the return value of each method of the web service.

Empowered with all this information, in the next blog series we will understand how we exactly use this web service, so that we are more enlightened to test it.
References:

1. Newcomer, Eric; Lomow, Greg (2005). Understanding SOA with Web Services. Addison Wesley. ISBN 0-321-18086-0.

(Copyrighted by CresTech Software Systems Pvt. Ltd.)