Your message has been sent.
This article has been saved to your account.
Go to my account
This article has been emailed to your Kindle.
Send this article
Quality is a key to success of service-oriented projects. Utilization of proper tools is important to the outcome of web service testing methodology. Being the leading open source web services testing tool, soapUI helps to build robust and flexible automated tests in a productive manner.
In this article by Charitha Kankanamge, author of Web Services Testing with soapUI, we will cover:
- Overview of some of the key characteristics of web services
- The role of web services in SOA
- Approaches of testing web services
- Web services testing challenges
- Introduction to soapUI
- Installing soapUI
Web services are one of the key building blocks of service-oriented solutions. Because of their usage and importance in the enterprise applications, the project teams are expected to be knowledgeable and familiar with the technologies which are associated with web services and service-oriented architecture(SOA).
(For more resources related to this topic, see here.)
SOA and 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.
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.
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
- 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
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. 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:
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
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.
Simple Object Access Protocol
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:
SOAP is a lightweight protocol for exchange of information in a decentralized, distributed environment. It is an XML based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined datatypes, and a convention for representing remote procedure calls and responses.
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:
- Message processing instructions
- Security policy metadata
- Addressing information
- Message correlation data
- Reliable messaging metadata
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.
When working with SOAP messages, identification of the version of SOAP message is one of the important requirements. At first glance, you can determine the version of the specification used in the SOAP message through the namespace identifier of the <Envelope> element. If the message conforms to SOAP 1.1 specification, it would be http://schemas.xmlsoap.org/soap/envelope/, otherwise http://www.w3.org/2003/05/soap-envelope is the name space identifier of SOAP 1.2 messages.
Alternatives to SOAP
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 WSReliableMessaging 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.
eBook Price: €23.99
Book Price: €38.99
Due to the complexities accompanied with the SOAP model, Representational State Transfer (REST) architecture has emerged as a result. RESTful web services can be considered as a lightweight alternative to the bulky and complex SOAP based web service standards. In RESTful web services, the emphasis is on point-to-point communication over HTTP, primarily using plain old XML (POX) messages.
Java Script Object Notation
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.
Web Services Description Language
According to the WSDL 1.1 specification, WSDL is defined as:
WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services)
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:
- The <types> element is used to define the data types used by the web service usually through a XML schema. The schema can be defined inline as a child element of <types> or can be imported from an external URL.
- The <message> element defines an abstract representation of all the messages used by the web service. A message consists of logical parts, each of which is associated with a definition within some type in the XML schema of the web service. The following image is an example of a message:
The <portType> element is an abstract representation of the operations and message exchange patterns used in the web service. Operations represent a specific action performed by a web service and which can be related to the public methods used by a program. Operations have input and output parameters and those are represented as messages. Hence, an operation consists of sets of input and output messages. This is evident from the following image:
In the preceding example, the SampleServicePortType element includes a single child element, <wsdl:operation name="echoString">, which itself includes two child elements to define the input and output messages processed by the echoString operation.
- The <binding> element connects the abstract web service interface defined by <portType> and <message> elements into a physical transport protocol. A binding represents a particular transport technology that the service uses to communicate. For example, SOAP v1.1 is one such commonly used binding.
Message exchanging patterns
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:
- Fire and forget
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.
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.
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:
- faultcode: The faultcode element is used to define the type of the fault. For example, if the problem of message transmission is due to the server, the associated faultcode is Server. Similarly, we can use VersionMismatch, MustUnderstand and Client error codes as appropriate.
- faultstring: The faultstring element is intended to provide a human readable explanation about the fault.
- faultactor: The faultactor element provides an indication about the responsible party who caused the fault to occur in the message path.
- detail: The detail element is used to carry application specific error information related to the body element. For example, if the payload of the SOAP request is unable cannot be processed by web service, the associated response should include the detail element inside the SOAP Fault.
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.
Approaches of testing web services
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:
- Unit testing
- Functional testing of web services
- Integration testing of web services
- Performance testing
Let's discuss each of these approaches in detail.
Unit testing of web services
A web service is a unit of business logic and it consists of one or more operations. These operations must be tested individually in order to make sure the intended business problems are addressed by web service operations. Therefore, similar to how individual methods in a computer program are tested as units, web service operations must also be unit tested. Unit tests can be developed using the unit test framework associated with the programming language which is used to implement the web services. For example, if web services are written in Java, JUnit framework can be used as the unit testing framework. Generally, it is the responsibility of the author of the web service to write a sufficient number of unit tests to cover the logic of the web service operations.
Once a web service is deployed in a service container, it is subjected to a comprehensive functional verification. The purpose of functional testing of a web service is to ensure that the expected business functionality is given by the web service. There are many approaches to perform functional testing as explained below.
Tool assisted testing
The primary objective of using tools for web service testing is to support the automatic generation and submission of web service requests. As the web service interface is a machine readable XML document, it is not an easy task to read the WSDL and derive tests manually. Therefore, tools can be used to point to the WSDL and generate the corresponding requests automatically, so that the testers can send them to the service with or without alterations. soapUI is a good example of such a testing tool, which can be used in functional testing of web services.
Using client APIs provided by service container middleware
The life for a web service is given by the service container middleware where the service is hosted. Usually, the middleware providers ship the associated client API libraries which can be used to invoke web services programmatically without using any third party tool.
Integration testing of web services
Web services do not essentially run alone. Instead they are integrated with multiple components such as brokers or service coordinators. Once a service is integrated or joined with another component, we should carry out tests to make sure that such integrations do not break the system. For example, in a service-oriented solution, if a service consumer application sends a message to a web service but the message does not conform to the advertised schema of the web service. In this case, the web service usually responds with a SOAP fault. However, if we want to take such a request and transform the request SOAP message such that it is valid according to the schema, then we do not want to ask the consumers of our web service to change the client applications as the service schema is modified. This type of message transformation is achieved by using a broker component, in other words, enterprise service bus (ESB) middleware. According to the transformation rules defined in the enterprise service bus, the request is converted into the correct format and forwarded to the web service. This is a typical example of web service integration. In order to test this type of integration, the request message should be forwarded to the ESB component instead of directly sending it to the web service. Tools such as soapUI can easily be used to send the messages to desired target locations appropriately.
Performance testing of web services
Once we are satisfied with the functional aspects of the web service, it should be tested thoroughly for performance. This includes load and stress testing the web service as well as measuring the performance under various conditions. We can use various open source or commercial tools in web services performance testing. Apache JMeter (found at http://jmeter.apache.org/) is a good example of an open source testing tool which can be used to test web services. The functional tests which we create on soapUI can easily be extended to test the performance of web services.
The common challenges of Web services testing
When compared to traditional testing approaches, there are some unique challenges associated with web services testing.
Use of external web services
The autonomous and loosely coupled nature of web services introduces a greater level of scalability and extensibility to the system. All services included in a system are not necessarily built in-house. Some web services can be developed and hosted by third parties. These services can be dynamically discovered and used according to the business requirements. Though this accelerates the delivery of solutions, testing such a system becomes complex because the quality assurance and availability of the third party services are out of your control.
Implications of using complex standards and protocols
Web services, especially SOAP-based services can use various WS-* specifications. When testing web services which adhere to specifications such as WS-Security, the tester should possess a fair amount of knowledge about the standards and concepts to carry out testing effectively. This introduces a higher learning curve for testers to get started with the testing of web services.
Web services can also be exposed over multiple transport protocols. Thus, testing is not limited to one particular transport such as HTTP. The same web service can be made accessible over transports such as JMS or VFS which requires changes in the testing setup as well as a different set of test scenarios.
Headless nature of web services
In traditional web application testing, test scenarios can be identified quite easily by studying the GUI of the components.The operations of web services are exposed to the outside world via machine-readable service contracts (such as WSDLs). Thus, during the early stages of web services development, testers need to use WSDLs as the reference for the derivation of test scenarios which can be difficult as compared to exploring a GUI.
eBook Price: €23.99
Book Price: €38.99
What is soapUI?
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.
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.
Capabilities of soapUI
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 :
- Complete coverage of functional aspects of web services and web applications: soapUI supports most of the standards used in web applications, such as message transmission through HTTP, HTTPS transport as well as JMS. It also supports testing SOAP and RESTful web services. specifically, soapUI supports most of the web service specifications such as WS-Security, WS-Addressing, among others.
- Service mocking: Using soapUI mock services, you can simulate the web services before they are actually implemented. This gives you the ability to test the web service consumer applications without waiting until the web service providers are implemented.
- Functional testing: : soapUI lets you do functional verifications against web services, web applications, and JDBC data sources. You can validate responses of your tests using various in-built and custom assertions. It also allows you to add conditional test steps to control the test execution flow.
- Performance testing: With just a few clicks, you can generate performance and load tests quickly using soapUI.
- Test automation: soapUI can be integrated into automated test frameworks such as JUnit, and the tests can also be launched through Apache Maven and Apache Ant build frameworks. It can also be integrated into continuous integration tools such as Hudson or Bamboo.
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.
To be able to run soapUI, you should have Java Development Kit (JDK) v1.6 running in your system. As soapUI is implemented in Java, it runs on many operating systems including Windows XP, Windows Vista, Windows 7, Windows Server 2003, Windows Server 2008, various Linux fl avors such as Ubuntu, Red Hat, Fedora, SuSE, and CentOS, and Mac OS X v10.4 or higher.
We can summarize the system requirements to install and run soapUI as follows:
1 GHz or
200 MB hard disk space
1 GHz or
240 MB hard disk space
Mac OS X
1 GHz or
140 MB hard disk space
Let's discuss the installation procedure of soapUI in each of the preceding operating systems in detail.
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:
- Download the Linux binary zip version (for example soapui-4.0.1-linuxbin. zip) of the latest soapUI release from http://www.soapui.org.
- Extract the downloaded binary distribution into a directory in your local file system, for example /home/user/soapui.
We will refer to the extracted directory as SOAPUI_HOME
- Go to SOAPUI_HOME/bin and run the soapui.sh startup script as follows: ./soapui.sh. This will launch the soapUI graphical user interface.
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:
- Download a soapUI Linux installer (for examplesoapUI-x32-4_0_1.sh) from http://www.soapui.org.
- After the file is downloaded, give executable permissions by running the command,chmod 755 soapUI-x32-4_0_1.sh.
- Run the installer as follows: ./soapUI-x32-4_0_1.sh.
- 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 installation on Windows
Similar to the preceding installation procedure on Linux, soapUI can be installed on a Windows operating system either using Windows installer or Windows binary archive.
Let's look at the installation steps of Windows binary archive. They are as follows:
- Download the Windows binary zip version (for examplesoapui-4.0.1-windows-bin.zip) of the latest soapUI release from http://www.soapui.org.
- Extract the downloaded binary distribution into a directory in your local filesystem, for example C:/soapui.
We will refer to the extracted directory as SOAPUI_HOME. This will launch the soapUI GUI.
- Go toSOAPUI_HOME/bin and run the soapui.bat startup script by executing the command: soapui.bat.
The steps for soapUI installation using the Windows installer are almost the same as the steps given in the Linux installer. You just need to double-click on the installer (soapUI-x32-4_0_1.exe) and it will launch the soapUI installation wizard.
Installing soapUI on MacOS
soapUI installation on Mac OS is straightforward and similar to the preceding steps which we described for Linux and Windows installers.
A glance at soapUI user interface
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:
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.
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.
Resources for Article :
- Starting with Gradle [Article]
- Securing a BPEL process [Article]
- ADempiere 3.6: Building and Configuring Web Services [Article]
About the Author :
Charitha Kankanamge is Manager, Quality Assurance and Senior Technical Lead at WSO2 with more than 9 years of experience in Software Quality Assurance. Charitha is specialized in SOA and middleware testing. He lead the WSO2 QA team since 2007. He is also a committer of the Apache Software Foundation contributing to Apache web services project. Charitha is interested in researching new technologies in software-testing space as well as new trends in agile and exploratory testing processes.
Prior to joining WSO2, Charitha has worked at Virtusa inc. for 3 years where he was involved in multiple on-site and off-shore project assignments. In his rare offline moments, he enjoys playing guitar and watching movies.
Charitha has been involved in reviewing two books, Apache Jmeter, Emilly H. Halili and Quick Start Apache Axis2, Deepal Jayasinghe both being published by Packt Publishing.
Charitha can be reached through his blog: http://charithaka.blogspot.com