SOAP over JMS - Performance Testing the Middleware

(JMS Performance Testing Case studies using Loadrunner and JMETER)

Authors:

Name: Yashi Saxena

Email ID:

ABSTRACT

SOA architecture makes use of Web Services to assist other application components in their transactions by communicating with them over a network. SOAP based applications requiring high reliability cannot simply make use of HTTP protocols for SOAP request – response transportation. Hence, it’s imperative to incorporate a robust and trusted system to facilitate this association between services and different components of a multi – tier application.Since middle ware application plays a significant role in providing support to the application servers hence it is mandatory to make performance checks to ensure that the middle ware engine is able to process the messages (e.g. xmls, flat files, MQ) with a given pace.What is expected in this is that the JMS middleware is definitive and fast in its functioning. To validate the listed properties, JMETER and Loadrunner are the most widely used performance testing tools. The paper focuses on performance testing SOAP over JMS transfer of services. How sound and rapid the entire amalgamation of the system is.

Table of Contents

  1. Introduction4
  2. Case Study6
  1. Testing Approach6
  2. Pre - requisites6
  3. Techniques, Enhancements, Analysis7
  1. JMETER7
  • Issues11
  • Resolution11
  • Analysis11
  1. Loadrunner12
  • Issues15
  • Resolution15
  • Analysis15
  1. Conclusion17
  2. References17
  1. INTRODUCTION

SOA Architecture:

Service Oriented Architecture acts a vendor and technology independent principle which is a discrete functionality enclosed in a black box catering different application components requirements. The interchange of these services is done using server channels. The servers facilitating the interchange of these functionalities are called middleware. They help in establishing connection between the services and application parts.

Technology based implementation of SOA architecture:

  1. SOAP
  2. REST
  3. Messaging
  4. OPC – UA
  5. WCF
  6. Apache Thrift
  7. SORCER

SOAP:
Simple Object Access Protocol, works on XML – messaging services. A WSDL, is a compilation of endpoints and messages. The message contains the details of the services that are catered by the web service xml and the end points determine the destination where the service response needs to be delivered. The request which is the message body is generated from the HTML servers on the client end. These requests are processes by the web service and sent to the final point where the processing response of the service is used. This transfer between the different components and services is facilitated by the intermediate middleware which acts a conveyance channel.

Parts of a SOAP request:

  1. Header
  2. Body
  3. Envelope element
  4. End – points
  5. Fault element

SOAP over JMS:

SOAP services are heavy, difficult to create but highly efficient and reliable to use. They have a reputation of being used in banking domain, majorly because of this reliability trait. They are like sealed envelopes of functioning delivering responses to the destination. The challenge of using HTTP as a method of delivery is that they fail to guarantee 100% efficient, swift and concealed delivery. For this reason the developers resort to a more firm and exhaustive channel of communication which aids in a faster and better transfer. This is aided by JMS. Hence, sending SOAP messages over JMS help overcome several business problems and performance issues of the overall system.

It is not important that the entire application does not use HTTP at all. The current architecture schema can be that the client facing end where the GUI should be simple and which does not require much scrutiny can be built using HTML / HTTP. The internal passages can be constructed using JMS.

JMS:

Java Messaging Service or JMS provides a critical message oriented middleware framework that creates client to client connectivity, thus providing a medium of interoperability for the overall system. JMS standard makes use of message broker which means that an intermediate component is involved in the message delivery. This implies that the message sender need not have any knowledge about the message recipient / recipients. There are two models of message transmission in JMS:

  1. Point to Point model: As the name suggests this model send message from a specific point to the other. Here, the message sent in the queue can be consumed by a specific consumer only. The message stays in the queue till it is consumed by the specific consumer for which it was sent else it gets expired.
  2. Publisher / Subscriber model: In this model a message gets published from the sender’s end and can be consumed by multiple receivers or consumers. It can be treated as a newsletter which is published from one end and can be read by multiple.

Properties of JMS Message:

  1. Message Header: Defines properties helpful in identification of message characteristics by the client.
  2. Message Property: Pre – defined values which help in making the message usable by multiple applications making the message more compatible and usable.
  3. Message Body: Contains actual data which is required to be processed like information, parameters etc.

Choice of Tools:

In the current paper the tools of choice to test the transfer of request – responses using SOAP over JMS in terms of performance are JMETER and Load Runner. The main reason being that they can be used for testing applications based on multiple technologies. They can be configured as a JMS client and can be used to generate high load on the queue and test its performance under the same. The case studies taken below are conducted using these two tools. The simplicity of the GUI and the ease of setting up of the tools and the system which will be used to get connected via them makes them a convenient choice.

  1. CASE STUDY
  1. Testing Approach:

First we need to identify based on the compatibility and the availability of the budget which tool need to be used. The next step now is to determine approach for performing various performance tests. Approach can be decided based on the Business strategy document.

Let us consider an example where the middle ware application accepts the input from the web application in the form of xml, hence we have to simulate the environment where we can publish n number of messages to the JMS topic/queues where the messages will be listened and processed.

Therefore the middleware has to recognize the messages that are being sent from one point (one queue), recognize and process it and direct to the relevant target queue.

  1. Pre – requisites for testing:

The information about the entire system needs to be acquired before the scripting is started. Other than the system details following pre – requisites need to be set on the system where the testing will be performed:

  1. 1. Queues Information:
    The queue details rely mainly on the kind of infrastructure and server used. This information is mainly for accessing queue hence the queue names and credentials used for accessing, the connection factory are basic essentials for this. Depending on the queues that need to be used and the architecture used one can get the information about the queue from the application developer. The following are the queue details that are needed:
  • HostName
  • Channel
  • Port
  • Queue Manager
  • Input Queue
  • Output Queue
  • Queue Connection Factory
  • Username and password
  1. JNDI Context Factory:
    The details about JNDI context factory like the context factory name, credentials and the provider URL are needed for setting up the test plans and scripts.
  2. Jar Files:
    According to the web server under test the JAR files should be downloaded and saved so that they can be accessed during runtime.
    In the following case studies WebSphere MQ is being using as middleware hence it should be installed on the client where the performance testing tool (Loadrunner / JMETER) installation has been done along with all the necessary JAR files pertaining to the publishing and receiving queue application points. In absence of Jars ClassNotFound exception is seen. The following JARS are needed to setup queues.

  1. WebSphere MQ Binding File:
    The file is created using WebSphere MQ Client application on local machine using the JNDI context factory. The Binding file is an .xml file and as the name suggests this file helps in binding multiple physical endpoints and in application / data transfer from one part to another. Following is a sample for SOAP JNDI Binding file. This file also contains properties for JMS. The properties that are specified in this file will be accessed and used by all the ports that are using this file.
  1. Techniques, Enhancements, Issues and Analysis
  1. JMETER
  • The common step in creation of test plan for JMS services for both the types is the creation of thread group. The thread group in case of Publisher and Subscriber model will be made twice, each having the number of users and other relevant user properties for Subscriber and Publisher. In case of point to point model, the thread group will be made once for the single sampler. The thread group is indicative of settings during the run – time of the test plan. It gives the number of users, the kind and time of ramp and also the duration and situation in which the loop has to run and till when the scenario should continue.
  • For point to point scenario the following sampler will be created post creation of thread group. The details needed in this will include the name of Factory for queue creation. It will have details about the sending or the request queue and receiving or the target queue. Also, in the JNDI Properties one can mention other relevant properties for queues like the credentials. There are two communication styles in JMETER point to point sampler. The request only mode is meant to generate large load on the system. There is another mode for Request – Response which is meant for monitoring the response from the destination queue.

  • For Publisher / Subscriber scenario, we need to create two thread groups under each sampler for publisher and subscriber respectively. One has to provide details like credentials, message topic, connection factory details, destination queue details etc. This has to be done for both JMS Publisher and JMS Subscriber samplers. This can be noted here that the messages are sent and received on the basis of message topic property. This means a one publisher having many subscribers for a message topic. Another difference between Publisher and Subscriber sampler is that the Publisher sampler will have an additional field called text where one can put in customized message that can be sent by the publisher.
    The below screen is for Publisher sampler: JMS Publisher will publish messages to a given destination (topic/queue) using the JNDI properties.

The message selection can be done in the following manner. If message source selected is from file, it will take the specific filename mentioned in the respective column. In case of random file selection it will take up any random file from the folder name given in the Random folder containing files field. In case of text message selection the message in the Text message field will be selected.

The subscriber sampler will look as follows:

For dynamic data values one can create an API in the JMETER where there can be a code to access values which can be read from a .csv file and incorporated with the .jmx test plan. Hence, adding a CSV dataset configuration element to the test plan makes the script readable and easily executable.
Common Issues Observed:

One major issue that is seen in JMETER scripting is that the screen freezes during the test execution. There are a couple of errors that are displayed when this happens:

  1. 100% CPU utilization
  2. Out of memory exception
  3. jMeter.Sampler.BatchSampleSender: sample occurred java.rms.ConnectionException: Connection refused by host
  4. jMeter.threads.jMeterThread: java.lang.OutOfMemoryError

One major reason for this is the test execution being done in GUI mode. Another being that there are a lot of graphical listeners added to your test. Also, there can be way more threads in the test run as compared to what the JMETER or the system can support.

Resolution: It is suggested that the GUI mode should be used only during the scripting and the load should be less. Also, heavy graphical listeners like tree, graphs should not be used for load test. These should be restricted to scripting only. One can run JMETER in non – GUI mode using the command: jmeter –n –t test.jmx –l test.jtl. JMETER should be used in headless and non – functional mode.

Analysis:

One can add listeners in JMETER which act as monitors. These listeners will capture run time values and help in performance engineering of the middleware component. These listener graphs can be directly stored to any file destination on the machine and complete data for entire run can be recorded. Image below is an aggregate graph which depicts the response times for the JMS queues being hit. Each bar represents the specific targeted functionality / message. The red ones are the average response time bars and the green ones are the 92%le response time graph.

  1. Loadrunner

Load Runner has several protocols to choose from and work upon. The application under test in this paper requires transfer of messages from one set of web service to another specific web service using SOAP as the protocol of choice. The following steps are followed to create a test plan for doing this type of testing:

  • Protocol Selection: On clicking the option for creation of a new script the following window will come up. The recording mode used for the application should be Web Services.
  • Action API: The standard JMS Action block would contain a lot of elements that can be seen in the below image. These elements are necessary in providing all the information to the Load Runner and relevant messaging queues.
  • Providing the right transaction names: The lr_start_transaction function will help in determine the start of the transaction which contains the message. This will contain the jms_send_receive_queue function which enables us to put the message to be delivered along with the queue details. The end of the transaction is marked by lr_end _transaction containing the same transaction name as in the start section. Once the transaction is complete one can put the checks for success verification
  • Setting Properties: The JMS function jms_set_message_property is used to set any property associated with header or property section. This may include characteristics like source of the message, target service for the message queue, Binding file version, message expiry time, credentials, correlations, etc. For example: Once a middleware framework is received, there are several properties associated with the queues. All these properties that the queue has have to be set in LR. This can be done in the following way:
  • Inserting message: The jms_send_and_receive_message_queue function contains the entire SOAP message that has to be transported. It also tells about the generating point and target service. This can be mentioned in the send and receive queue fields. The message for SOAP over JMS comes in .xml format. The xml message has to be imported in the action which will hit the queues. This message has to be imported in the action block where it will be implemented. The following image can be referred as an example as to how the message is placed in load runner.

The message with the operation name is received as xml file. The first is the step name followed by the SOAP message envelope.

  • Parameterizing a given Id: Parameterization in JMS is done on the fields that are present in the SOAP message. The values in the tags that are unique for all iterations are parameterized. For example: If there is a field <Account>12345</Account>, the account number value in the field should be different in each message. Then this field can be parameterized by creating a parameter file for the same in LR Vuser. Hence, all the parameterization will take place in the jms_send_receive_queue function.
  • Verification: The success of the JMS queue is ensured when the message that is sent from the initiating point reaches its destination as it is required to. To check the accuracy, one can refer to the text check result. If the message is successfully transmitted, the text check will pass else will result in failure. Hence, the query in the text check should be from the message body which is placed inside the jms_send_and_receive_message_queue, so that the comparison can be made. The text checks used in JMS messaging are similar to normal web services scripting. The lr_xml_find function helps in putting text checks for the message being transported. This function will extract the value from the brackets whose boundary has been specified and then match or check with the value present in the query parameter. Unlike HTML mode of scripting this function is placed at the end of the transaction. Once the transaction has ended this function will extract the query parameter from the response.
  • Run – time Settings: Once the message is created the run time settings need to be described so that the message associated properties are set in the action. The following settings are required to be done when you start scripting for JMS:
  1. Classpath: specifies the path for all the Websphere MQ JAR files for the particular JMS project saved in the client machine. Each file path is separated by a semi colon. For example: If the JAR files are in C drive in a folder named JMS. So, in the classpath field one can give values like: C:\JMS\jms.jar;C:\JMS\jndi.jar
  2. JNDI initial Context factory: Java Naming and Directory Interface is the name for the JMS class provider. This helps in creating the initial connection for the transportation. For a WebSphere MQ queue type, the JNDI initial context factory name is com.sun.jndi.fscontext.RefFSContextFaxtory.
  3. JNDI Provider URL: Path of the Websphere MQ Binding file. For example: If the file are in C drive in a folder named JMS. So, in the JNDI Provider URL field will have values like: C:\JMS\SOAPJNDIbindings
  4. JMS Connection Factory: JNDI name of JMS connection factory or the QCF name. For a queue for an application it can be something like UPS.APPNAME.QCF (QCF stands for queue connection factory).
  5. Username/ Credentials: A queue cannot be accessed without these if it is password protected. The JMS security principals is the username and JMS security credentials is the password.