Web Service Testing Using iTKO LISA

1. Introduction

Middleware is a software that works between multiple processes running on different machines and allows them to interact with each other.

It provides messaging services for these multiple applications across heterogeneous computing platforms to communicate with each other.

Examples of Middleware program:

1.    Remote procedure call (RPC): It is used by an application for executing a subroutine or procedure which could be located on another machine on the shared network.

2.    Object Request Broker (ORB): It is used by an application to make program calls from one machine to another through a network.

Web Services are created by companies to present their business logic in the form of services which are used by various applications. Sometimes even companies offer their web services to other firms.

                               

iTKO LISA tool can be effectively used for middleware and web services testing.

ITKO is the leading provider of virtualization and validation solutions. ITKO’s first product LISA 1.0 was launched in 1999 for high-volume Load Testing.
First commercial release was LISA 2.0 in 2002, since then iTKO has tried to roll out different kinds of testing components with better features.

The different products of a LISA Suite are: -

·         LISA VIRTUALIZE

·         LISA TEST

·         LISA VALIDATE

·         LISA PATHFINDER

On 26^th Jan 2010 5.0 version was announced with new visual modeling user interface. Here the flow of execution within the application’s components or amongst different services can be seen.

2.    Some Definitions

Queues: It is used for exchanging messages between programs which are independent of each other, at different locations and without having any logical connection between them.

Topic: It is similar to a queue; however in a topic every subscriber listening on that topic will receive a copy of the message.

WSDL: Web Services Description Language (WSDL) is an XML based language used for web services description.

TIBCO: TIBCO Software Inc founded by Vivek Ranadive in 1997, is a provider of infrastructure software to other companies which can be further used for cloud computing environments.

3. Using LISA for middleware testing

The TIBCO EMS Messaging step allows sending messages to, and receiving messages from queues and topics. It also allows receiving, modifying and forwarding an existing message.

JAR FILES: Necessary jar files depending on the chosen configuration and Connection should be placed in the HOTDEPLOY folder in the LISA installation folder.

The jar files can be found in the lib directory of the TIBCO installation:

·         tibjms.jar

·         tibjmsadmin.jar

·         tibjmsapps.jar

·         tibrvjms.jar

TIBCO EMS messaging step is available in TIBCO step

The messaging step editor for TIBCO EMS Messaging is shown below

There are four tabs available at the bottom of the editor.

·         The Base: For specifying connection and messaging parameters.

·         The Selector Query: For specifying a selector query to be run when listening for a message on a queue.

·         The Send Message Data: For giving the message content to be published to the queue or topic.

·         The Response Message: For receiving the response messages subscribed to the queue.

                                                             

BASE INFO:

1.    Server Connection Info:

·         JNDI Factory Class: LISA pre-populates this field with default values

·         JNDI Server URL: LISA pre-populates this field with default values

·         JMS Connection Factory: You can use the magnifying glass, , to browse available resources on the server. Select or type in a Connection Factory per the JMS specification to use for this Step execution.

·         User

·         Password

2.    Publisher Info:

·         Name: The name of the topic or queue to which the message is to be published.

·         Type: To select whether using a topic or queue.

·         Message: To select the type of messages to be published. Different type of messages that can be published are: Empty, Text, Object, Bytes, Message, and Mapped (Extended).

3.    Subscriber Info:

·         Name: The name of the topic or queue to which the message is to be published.

·         Type: To select whether using a topic or queue.

·         Timeout (secs): To select the period to wait before LISA interrupts waiting for a message (this field can be left blank for no timeout).

·         Async Key: This is only needed in asynchronous mode. To enter the value needed to identify asynchronous messages.

·         Durable Session key: It allows to receive messages from topic even if user logs off and then logs on again.

SELECTOR QUERY TAB:

JMS selector query can be entered in this editor. The syntax is similar to SQL.

A JMS selector query can be specified when listening for a message on a queue that is a response to a published message.

The Selector Query tab view is shown below:

SEND MESSAGE DATA:

     

The message to be published to the Queue or topic is given in this tab.

The message can be directly written here or can be read from a file using “Read Message From File” tab or it can be given by storing it in a LISA property.

The Send Message Data tab view is shown below for a XML message:

RESPONSE MESSAGE:

If the TIBCO step is configured to subscribe, response is displayed in this tab.

The object is loaded into LISA’s complex object editor where it can be manipulated like any other Java object.

  

The Response Message tab is shown below:

  Web Services Execution using LISA

iTKO’s LISA offers testing (unit/regression or functional testing) of Web Services. For executing a web service, there is some mandatory things/information required which are as follows: -

 Input and Output XML

For every Application there is different workflow between the methods or services. These different methods or services communicate/transfer information amongst in the form of XMLs. The Input XML hits the web service and an Output XML is generated as response. This O/P message has to be validated as a well formed XML Schema (i.e. with proper structure and data of the messages).

The Input XML is passed as string while execution.

 End Point URL i.e. Environment

The End point URL works as the environment over which the testing of that particular web service is to be done.

The Web Service URL is of the form < http:// {{Server}}:{{Port}}/….. >

This URL consists of the server name and the port over which the service is present.

WSDL – It contains all the methods which are present in the Web Service. Apart from that it mainly describes about binding i.e. how the end point communicates. A WSDL document defines the following objects in a web service execution: -

4.1         Types– It describes the data and XML Schema is used to verify that.

4.2         Message– It depicts the information needed for execution of operation.

4.3         Operation– the operation supported by the Web service or methods.

4.4         Port Type– defines a web service.

4.5         Binding– It defines the interface, binding style and transport used for communication (HTTP etc.)

4.6         Port– Defines connection point to a web service.

4.7         Service- Set of endpoints.

TEST DATA – While using an Input XML, we need to parameterize its tag values so as to cover different scenarios for the various tags. Now after parameterize, we have to create a test data with different set of test values for the tags.

This Test data can be of different forms, but usually it is created in Excel format as the values can be assigned/modified easily as per the change in Test Scenarios. Else the values can be picked from database, or we can create a data set in the Lisa itself.