Web Services Testing with soapUI: Starting with an overview of SOA and web services testing, this guide take you through a number of hands-on exercises and projects to get you familiar with soapUI. A sure way to raise the quality of your web services.

SOA is a distinct approach for separating concerns and building business solutions utilizing loosely coupled and reusable components. SOA is no longer a nice-to-have feature for most of the enterprises and it is widely used in organizations to achieve a lot of strategic advantages. By adopting SOA, organizations can enable their business applications to quickly and efficiently respond to business, process, and integration changes which usually occur in any enterprise environment.

Service-oriented solutions

If a software system is built by following the principles associated with SOA, it can be considered as a service-oriented solution. Organizations generally tend to build service-oriented solutions in order to leverage flexibility in their businesses, merge or acquire new businesses, and achieve competitive advantages. To understand the use and purpose of SOA and service-oriented solutions, let's have a look at a simplified case study.

Case study

Smith and Co. is a large motor insurance policy provider located in North America. The company uses a software system to perform all their operations which are associated with insurance claim processing. The system consists of various modules including the following:

• Customer enrollment and registration

• Insurance policy processing

• Insurance claim processing

• Customer management

• Accounting

• Service providers management

With the enormous success and client satisfaction of the insurance claims processed by the company during the recent past, Smith and Co. has acquired InsurePlus Inc., one of its competing insurance providers, a few months back.

InsurePlus has also provided some of the insurance motor claim policies which are similar to those that Smith and Co. provides to their clients. Therefore, the company management has decided to integrate the insurance claim processing systems used by both companies and deliver one solution to their clients.

Smith and Co. uses a lot of Microsoft(TM) technologies and all of their software applications, including the overall insurance policy management system, are built on .NET framework. On the other hand, InsurePlus uses J2EE heavily, and their insurance processing applications are all based on Java technologies. To worsen the problem of integration, InsurePlus consists of a legacy customer management application component as well, which runs on an AS-400 system.

The IT departments of both companies faced numerous difficulties when they tried to integrate the software applications in Smith and Co. and InsurePlus Inc. They had to write a lot of adapter modules so that both applications would communicate with each other and do the protocol conversions as needed.

In order to overcome these and future integration issues, the IT management of Smith and Co. decided to adopt SOA into their business application development methodology and convert the insurance processing system into a service-oriented solution.

As the first step, a lot of wrapper services (web services which encapsulate the logic of different insurance processing modules) were built, exposing them as web services. Therefore the individual modules were able to communicate with each other with minimum integration concerns. By adopting SOA, their applications used a common language, XML, in message transmission and hence a heterogeneous systems such as the .NET based insurance policy handling system in Smith and Co. was able to communicate with the Java based applications running on InsurePlus Inc.

By implementing a service-oriented solution, the system at Smith and Co. was able to merge with a lot of other legacy systems with minimum integration overhead.

Building blocks of SOA

When studying typical service-oriented solutions, we can identify three major building blocks as follows:

• Web services

• Mediation

• Composition

Web services

Web services are the individual units of business logic in SOA. Web services communicate with each other and other programs or applications by sending messages. Web services consist of a public interface definition which is a central piece of information that assigns the service an identity and enables its invocation.

The service container is the SOA middleware component where the web service is hosted for the consuming applications to interact with it. It allows developers to build, deploy, and manage web services and it also represents the server-side processor role in web service frameworks. A list of commonly used web service frameworks can be found at http://en.wikipedia.org/wiki/List_of_web_service_frameworks; here you can find some popular web service middleware such as Windows Communication Foundation (WCF), Apache CXF, Apache Axis2, and so on. We will use Apache Axis2 as the service container for sample projects within the context of this book. Apache Axis2 can be found at http://axis.apache.org/.

The service container contains the business logic, which interacts with the service consumer via a service interface. This is shown in the following diagram:

Mediation

Usually, the message transmission between nodes in a service-oriented solution does not just occur via the typical point-to-point channels. Instead, once a message is received, it can be flowed through multiple intermediaries and subjected to various transformation and conversions as necessary. This behavior is commonly referred to as message mediation and is another important building block in service-oriented solutions. Similar to how the service container is used as the hosting platform for web services, a broker is the corresponding SOA middleware component for message mediation. Usually, enterprise service bus (ESB) acts as a broker in service-oriented solutions.

Composition

In service-oriented solutions, we cannot expect individual web services running alone to provide the desired business functionality. Instead, multiple web services work together and participate in various service compositions. Usually, the web services are pulled together dynamically at the runtime based on the rules specified in business process definitions. The management or coordination of these business processes are governed by the process coordinator, which is the SOA middleware component associated with web service compositions.

We looked into the primary building blocks of service-oriented solutions and the corresponding SOA middleware components. Next, we are going to discuss some of the distinguished elements associated specifically with web services. These are SOAP messaging, Web Services Description Language (WSDL), message exchanging patterns, and RESTful services.

Simple Object Access Protocol (SOAP) can be considered as the foremost messaging standard for use with web services. It is defined by the World Wide Web Consortium (W3C) at http://www.w3.org/TR/2000/NOTE-SOAP-20000508/ as follows:

The SOAP specification has been universally accepted as the standard transport protocol for messages processed by web services. There are two different versions of SOAP specification and both of them are widely used in service-oriented solutions. These two versions are SOAP v1.1 and SOAP v1.2.

Regardless of the SOAP specification version, the message format of a SOAP message still remains intact. A SOAP message is an XML document that consists of a mandatory SOAP envelope, an optional SOAP header, and a mandatory SOAP body.

The structure of a SOAP message is shown in the following diagram:

The SOAP Envelope is the wrapper element which holds all child nodes inside a SOAP message.

The SOAP Header element is an optional block where the meta information is stored. Using the headers, SOAP messages are capable of containing different types of supplemental information related to the delivery and processing of messages. This indirectly provides the statelessness for web services as by maintaining SOAP headers, services do not necessarily need to store message-specific logic. Typically, SOAP headers can include the following:

The SOAP body is the element where the actual message contents are hosted. These contents of the body are usually referred to as the message payload.

Let's have a look at a sample SOAP message and relate the preceding concepts through the following diagram:

In this example SOAP message, we can clearly identify the three elements; envelope, body, and header. The header element includes a set of child elements such as <wsa:To>, <wsa:ReplyTo>, <wsa:Address>, <wsa:MessageID>, and <wsa:Action>. These header blocks are part of the WS-Addressing specification. Similarly, any header element associated with WS-* specifications can be included inside the SOAP header element.

The <s:Body> element carries the actual message payload. In this example, it is the <p:echoString> element with a one child element.

Though SOAP is considered as the standard protocol for web services communication, it is not the only possible transport protocol which is used. SOAP was designed to be extensible so that the other standards could be integrated into it. The WS-* extensions such as WS-Security, WS-Addressing, and WS-ReliableMessaging are associated with SOAP messaging due to this extensible nature. In addition to the platform and language agnosticism, SOAP messages can be transmitted over various transports such as HTTP, HTTPS, JMS, and SMTP among others. However, there are a few drawbacks associated with SOAP messaging. The performance degradations due to heavy XML processing and the complexities associated with the usage of various WS-* specifications are two of the most common disadvantages of the SOAP messaging model. Because of these concerns, we can identify some alternative approaches to SOAP.

Java Script Object Notation

Java Script Object Notation (JSON) is a lightweight data exchange format similar to XML. It is based on a subset of JavaScript language. JSON uses key value pairs to represent data which are carried inside the message. The following example shows how the XML payload of a SOAP message can be represented in JSON:

The corresponding JSON format of the preceding XML payload is represented by:

You may refer to http://www.json.org for more details about JSON.

According to the WSDL 1.1 specification, WSDL is defined as:

In simple terms, WSDL provides a formal definition of the web service through abstract and concrete definitions of the interface. The following diagram shows the main structure of a WSDL document:

WSDL is an XML document with a <definitions> element at the root and the child elements, <types>, <message>, <portType>, and <binding>. These can be explained as follows:

We will discuss about the WSDL in detail in Chapter 2, The Sample Project, using the one that is used in the sample project.

As we have already discussed, the web services communicate with each other and the other programs by sending messages. If we consider two SOAP processing nodes, the communication pattern between the two entities can be defined as a message exchanging pattern (MEP). The primary message exchanging patterns are:

In a request-response pattern, when a source entity (service requester) transmits a message to a destination (service provider), the provider should respond to the requester. This is the most commonly used message exchanging pattern and we will use this in most of the examples in this book.

In the following diagram, a service requester sends a SOAP request message to a service provider:

Upon receiving the SOAP request message, the service provider responds with a SOAP response as shown in the following diagram:

When a response to a request message is not expected from a web service (or service provider), it is known as a fire and forget message exchange pattern. For example, if we send a ping request to a web service, we do not expect a response message back.

Before concluding our discussion on web services and the associated concepts, we should look at the fault handling mechanism of web services. Faults can be returned by web services due to various reasons. For example, if the request message does not conform to the XML schema of web service, the service responds back with a SOAP Fault. The SOAP Fault element is used to carry such faults occurred during web service communication. This element must be included inside body of a SOAP message. A typical SOAP 1.1 Fault message consists of the following child elements:

In the case of SOAP v1.2 messaging, faultcode is renamed to Code and faultstring is renamed to Reason. In addition to that, a SOAP v1.2 Fault message can include the optional child elements, Node, Role, and Detail. A detailed explanation of SOAP 1.1 Faults can be found at http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383507. SOAP 1.2 Faults are explained in detail at http://www.w3.org/TR/soap12-part1/#soapfault.

We discussed a set of concepts most associated with web services. Now, it is time to look in to the testing aspects of web services. As we noticed, web services are loosely coupled and autonomous components which are individual units of business logic in SOA. This facilitates a distinguished approach for testing web services. Because of the loosely coupled nature, the services do not maintain tight, cross-service dependencies with each other. Therefore, once a particular web service is implemented, it can be tested independent from others.

This gives the ability to testers to follow a component level testing methodology. Before moving into various integrations, a web service can be tested to verify both functional and non-functional requirements. Once the service is enhanced with different attributes such as security policies, then such a service can also be tested individually to ensure that it functions properly before taking the integration scenarios into account. This gives great flexibility for testers and provides agility to testing processes.

We can identify a set of common approaches for testing web services as follows:

Let's discuss each of these approaches in detail.

The primary objective of designing testing tools is to assist people in testing software by reducing the time taken by test execution. There are different types of tools which can be used for functional and non-functional testing. Some of the tools are designed to automate user interface based interactions and some are used to derive various types of requests messages automatically and transmit them to applications with or without modifications. Some tools support both of these aspects.

soapUI is a tool which can be used for both functional and non-functional testing. It is not limited to web services, though it is the de-facto tool used in web services testing. In web services testing, soapUI is capable of performing the role of both client and service. It enables users to create functional and non-functional tests quickly and in an efficient manner by using a single environment.

The first release of soapUI (v1.0) was in October 2005. Ole Lensmer, while working in a project related to SOA, felt the need for a testing tool to support agile development. Therefore, he started to develop soapUI in his spare time. Eventually, the project was open sourced and the community grew. Ever since, a number of versions have been released with various new features and enhancements and the newest version of soapUI is 4.0.1 at the time of writing this book.

The originator of soapUI, Ole Lensmer was managing the project releases through a company called Eviware for the past few years. In July 2011, Eviware was acquired by SmartBear Software (http://smartbear.com/) and now soapUI is part of SmartBear Software.

soapUI is a free and open source utility, which means you can utilize the various features provided by the tool freely as well as you are allowed to make modifications to the source code of soapUI and suit it according to your requirements. soapUI is licensed under the terms of the GNU Lesser General Public License (LGPL). It has been implemented purely using Java platform hence it runs on most operating systems out of the box.

It should be noted that soapUI is also distributed as a non-free commercial version known as soapUI Pro, which basically provides users with custom utilities and enhanced production level testing capabilities. All our discussions and examples are based on the free version of soapUI for your convenience.

The primary goal of the authors of soapUI is to provide users with a simple and user-friendly utility which can be used to create and run functional as well as non-functional tests through a single test environment. Based on that objective, soapUI has become the world's leading SOA and web service testing tool. soapUI can be installed with no configuration overhead in most of the common operating systems which allow users to start using the tool without spending time on configuring various installation prerequisites.

By using the easy-to-use Java Swing-based GUI, you can start creating functional tests with zero coding. Eventually, the same functional tests can be used for load and performance testing through the same test environment. This gives users a great flexibility since all functional and non-functional tests can be managed through a single point of access.

Let's look at some of the important features of soapUI which we are planning to discuss in the following chapters.

In addition to the preceding features, the proprietary version of soapUI, soapUI Pro, provides users with data-driven testing capabilities, HTTP recording, and test reporting facilities which are not in scope of this book.

We looked at the major features provided by soapUI and discussed the tool in general. It is time to explore the easy and straightforward soapUI installation on some of the popular operating systems.

Installing soapUI on Linux

soapUI is distributed as two different installers for your convenience. You could either download the binary archive (ZIP) of the installer or the installer script.

First, we will look at the installation procedure of the binary archive. Perform the following steps:

1. Download the Linux binary zip version (for example soapui-4.0.1-linux-bin.zip) of the latest soapUI release from http://www.soapui.org.

2. Extract the downloaded binary distribution into a directory in your local file system, for example /home/user/soapui.

   Note

   We will refer to the extracted directory as SOAPUI_HOME.

3. Go to SOAPUI_HOME/bin and run the soapui.sh startup script as follows:./soapui.sh. This will launch the soapUI graphical user interface.

Tip

If you encounter a Permission denied error when running the soapui.sh script, make sure to change the file permission mode by granting executable privileges to the user by executing the chmod command as chmod 755 soapui.sh.

You can also install soapUI using the Linux installer by performing the following steps:

1. Download a soapUI Linux installer (for example soapUI-x32-4_0_1.sh) from http://www.soapui.org.

2. After the file is downloaded, give executable permissions by running the command, chmod 755 soapUI-x32-4_0_1.sh.

3. Run the installer as follows: ./soapUI-x32-4_0_1.sh.

4. This will launch the installer UI as shown in the following screenshot:

   

Now, you can proceed through the installation wizard. You will be asked to accept the license agreement at the next step of the wizard. Simply click on I accept the agreement option and click on Next. You will be required to specify a destination directory for soapUI to be installed.

At the next step of the installation wizard, you can select which components you need to include in soapUI, such as; Hermes JMS, soapUI source files, and tutorials. Simply accept all options and click on Next. You will be prompted with the license agreement for Hermes components at the next step. Accept the license agreement and click on Next to proceed through the wizard. Then, you will be asked to specify a directory for soapUI tutorials. Enter a location which is in your filesystem and click on Next. You will be asked for a directory where soapUI symlinks are created for executables such as the soapui.sh file. Enter a directory and click on Next. You can check the Create a desktop icon checkbox to create an icon on the desktop so can you can easily launch soapUI. Finally, click on the Next button to start the installation.

The soapUI installation screen will look like the following screenshot:

soapUI is a self-explanatory testing tool. The easy-to-use user interface makes it simple to work with soapUI for any type of user. With a few clicks, you can start testing a web service or a web application with minimum effort. This highly usable and flexible user interface helped soapUI to become the most user-friendly and easier SOA and web service testing tool among the testing community.

Once soapUI is launched, you will be shown the starter user interface as shown in the following screenshot:

In soapUI, all tests are organized under a central element, known as Projects. Just by right-clicking on the Projects node in the left-hand side pane in soapUI GUI, a new soapUI project can be created as shown in the following screenshot:

I will leave it to you to navigate through the rest of the UI elements on your own before starting with sample projects. You will find a lot of materials on the soapUI official website related to these features. We will explore through the soapUI user interface as we proceed through the demonstrations and samples in the rest of the chapters.

Web services are the individual units of business logic in SOA. In order to test web services, we must possess a good understanding about SOA and web services as well as the associated technological components. This chapter has been dedicated to build that foundation.

We started to look into soapUI, the world's leading and most complete SOA and web services testing tool. We discussed the primary goals and objectives of using soapUI in web services testing. We looked at a bit of history of soapUI and its distribution models. Finally, the steps of installing soapUI on Linux, Windows, and Mac OS were explained.

Now, we have soapUI running on our systems. Let's get our hands dirty with a sample project in the next chapter.