The purpose of this article is to introduce the function test method and performance test method of the Enterprise Service Bus. The testing method is summarized based on the real customer project, and is proved as a successful testing method.

Yu Hong Song, Test Lead, IBM  

Yu Hong SongYu Hong Song is a test lead in IBM China. She joined IBM as a software engineer with master degree in 2007. She is part of Global Business Solution Center (GBSC) of GBS. Currently she is working on ITS solution testing.



Tao (Jerry) Liu, Advisory I/T Architect, IBM  

Tao (Jerry) LiuTao (Jerry) Liu is an accredited IT Architect in IBM China. He joined IBM as a research engineer with master degree in 2003. He is part of Global Business Solution Center (GBSC) of GBS. Currently he is working on ESB asset of common technology enabler initiative.



Jingfeng Zhang , Software Engineer, IBM  

Jingfeng Zhang Jingfeng Zhang is a Software Engineer in IBM China. He has more than 7 years of software development experience and joined IBM in 2007. He mainly focuses on the J2EE, MQ, WMB, SOA, ESB, EAI. He is a member of Global Business Solution Center (GBSC).



30 November 2009

Also available in Japanese Spanish

ESB functional test method

As Figure 1 shows, within a service oriented architecture, service requesters and service providers communicate with each other through an ESB. The major capabilities of ESB are message transformation, protocol conversion and service routing. Based on the ESB middleware, integration routines are developed to mediate the service requesters and providers. To test those integration routines, we summarized the different types of ESB functional verification test methods as below. In this article, we take WebSphere Message Broker as the ESB middleware example to describe our testing guideline.

Figure 1. Example message and network protocols in SOA
Example message and network protocols in SOA

Message flow for JMS to web service

Figure 2 displays the message flow about correlation between JMS (consumer) and the web service (provider) within the ESB. The service requester sends the request to the ESB and converts the request to the SOAP message and transfers to invoke the web service (provider). The provider sends out the SOAP response message to the ESB and transforms the message to XML and sends the message back to the requester’s response queue.

Figure 2. Message Flow 1
Message Flow 1

To test the function of the message flow, the test branches for the message flow need to be identified firstly. There are two valid branches in the Figure 2. One branch is sending the message to the requester’s request queue, and getting the response message from the requester’s response queue. The other branch is sending the message to the requester’s request queue, and getting the fault message from the requester’s response queue.

Secondly, different kinds of input messages for different branches should be designed. For example, for the first branch, kinds of input XML messages would be designed to be converted to the different kinds of SOAP message to get the different response from the service. The input boundary and the classification need to be considered when design the test input. For the second branch, invalid input XML messages would be converted to the invalid SOAP message for the service.

Test cases are designed to verify the function of the message flows. First of all, clear the requester’s request queue, and send the input message to the queue. Get the converted SOAP request message at the check point 1 of the Figure 2 and verify the SOAP message is converted to the expected Message. In the check point 2 of Figure 2, the test client gets the Response/Fault message from the request’s response queue and then checks if the message is expected.

Message flow for web service to JMS

The Correlation Message flow with a web service to JMS is showed at Figure 3. A web service (consumer) sends the SOAP request message to the ESB and converts the SOAP message to an XML message and sends the message to the Provider’s Request Queue. Service provider gets the request the message and response message to the ESB. ESB transforms the response message to SOAP message as the SOAP reply of the web service. To test the kind of flow automate, a provider simulator is implemented to send back the response message of the provider.

Figure 3. Message Flow 2
Message Flow 2

The message flow of Figure 3 could be identified as two test branches. One is SOAP request message is invalid, ESB handles the exception and sends out the Fault Result as the response. The other is web service sends out the valid SOAP request message and gets the valid SOAP response message through the ESB.

The input messages for exception branch need to be designed to cover the exception situations. And for the valid branch, the input boundary and the classification need to be considered when design the input SOAP message for the coverage.

There are two check points in the test cases for the valid flow as the Figure 3 shows. When the SOAP request is converted to the XML message, test client gets the message to verify the XML is converted successfully and the content satisfies the requirement of the service provider. And the other check point to verify the converted SOAP response message is correct. For the invalid branch, the check point 2 needs to be verified. Test client need to verify the Fault response result is generated correctly.

Message flow from MQ/JMS to MQ/JMS

The message can also be transferred from one queue to others (Local/Remote) by ESB. Figure 4 shows the one way message flow. Input message would be designed to verify the message is transferred successfully. Input message is sent to the consumer’s request queue and test client gets the message from the provider’s request queue to verify the format and the content of the message is transformed and transferred successfully.

Figure 4. Message Flow 3
Message Flow 3

As shown in figure 5 the correlation message flow in the ESB. Service consumer sends the service request by JMS and the request message transferred and transformed by ESB. Service provider gets the request message from the provider’s request queue and sent back the response message to provider’s response queue. ESB transfer the response message to the service consumer. The test case is designed to cover the flow.

Input message is designed by the contract schema. Test client verifies if the provider receives the right messages in the check point1. Test client create a simulator to send back the response message. The consumer's response message is need to be verified if the format and content is expected in the check point 2.

Figure 5. Message Flow 4
Message Flow 4

Message flow from FTP to FTP

Files can be transferred by FTP from the consumer to the provider through ESB as Figrue 6. Test client would upload the files from the dedicated source folder. ESB transfer the file to the expected destination. Test client get the files from the destination and check files are the same as the input files by byte compare. Three types of input files are designed: 0 size file, normal file, large size file to verify the transformation function.

Figure 6. Message Flow 5
Message Flow 5

Message flow from FTP to JMS

The Figure 7 shows a conversion of FTP to JMS. The ESB receives the files by FTP and converts the file to the message and sends to the provider’s queues. Test client needs to design different kinds of files (zero size, normal size, large size) to be the input. And then get the converted message from the two queues to verify the files are converted and transferred successfully.

Figure 7. Message Flow 6
Message Flow 6

ESB performance test method

Concurrent workload control

In this performance test, we will test the in-scope message flows in an extreme strict situation that all the request of the message flows will be sent to message broker just at the beginning of the test without think time. For example, message flow IRS_CRM_AccountCreationRequest has 1000 requests in the peak hour. Then all of the 1000 request messages would be sent to the input queue of the message flow without stop when the testing is started. At the same time, the request messages of other 20 plus message flows are sent to the specified destination too. So the stress of the message flows at the beginning of the test would be very high.

One-way message flow

The one way message flow usually contains one MQ input node and one MQ output node as shown in figure 8 below.

Figure 8. One-Way Message Flow
One-Way Message Flow

In the test script, we will record the timestamp as t0 when we start to send one request message to the request queue. We will record the timestamp as t1 when we retrieved the response message from the response queue. And the other request messages are also recorded as described. We calculate the sum of the entire message flows’ response time as ∑ (t1-t0). Suppose we send totally m messages for this flow. Then the average response time (ast) would be calculated as ast= ∑ (t1-t0)/m.

Correlation message flow

The correlation message flow usually contains 2 MQ input nodes and 2 MQ output nodes as below.

Figure 9. Correlation message flow
Correlation message flow

We have one simulator illustrated at the right side to construct a reply message with the given request message. The simulator just simply set the correlation ID of the reply message with the request message ID and then put the reply message into Provider’s Response Queue. Similarly, we will record the timestamp of t0 and t1 as 3.2 described. Moreover, we will record the total time used in the simulator to construct and reply the message as ds. Suppose we send totally m messages for this flow. Then the average response time (ast) would be calculated as ast= (∑ (t1-t0)-ds) /m.

Web service provider message flow

The web service provider message flow usually sends the SOAP request message to SOAP Input node and get the SOAP response message from SOAP Reply node like below. The MQ input node and MQ output node are used to send the transformed messages to the service consumer and get the response message from the consumer.

Figure 10. Web service provider message flow
Web service provider message flow

The simulator acts as the service consumer to construct a reply messages as 3.3. The timestamp t0 is used to record when the SOAP Request message is sent out. And t1 is the timestamp we get the response time from SOAP Reply. We will record the total time used in the simulator to construct and reply the message as ds. Suppose we send totally m messages for this flow. Then the average response time (ast) would be calculated as ast= (∑ (t1-t0)-ds) /m.

Web service consumer message flow

The web service consumer message flow usually contains one MQ input node and one MQ output node as followed. The web service node consumes the MQ request messages and sends the response message to the MQ output node.

Figure 11. Web service consumer message flow
Web service consumer message flow

Similarly, we will record the timestamp of t0 and t1 as 3.2 described. We will record the total time used in the web services simulator to construct and reply the message as ws. Suppose we send totally m messages for this flow. Then the average response time (ast) would be calculated as ast= (∑ (t1-t0)-ws) /m.


Summary

The function test and performance test method are described in this document. The testing method could be implemented by JUnit and executed automatically. The ESB system has been deployed in the customer’s Road User Charging project and performs an import role in the project.

Resources

Learn

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into SOA and web services on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=SOA and web services
ArticleID=441951
ArticleTitle=ESB Testing Best Practice
publish-date=11302009