Tuesday, October 27, 2009

SoapUI for Data Setup - Use Case

With Soap UI having very useful features, I find this tool helpful for more and more purpose than just testing and coverage. In one of the product implementation, we were trying to setup the initial necessary data (basic and test data) in easy and best way. We needed the initial setup of few organization profiles and users to proceed further in the product implementation. We had three options - 1. Create manually through UI (painful), 2. Create through web service, 3. Write stored procedures (complicated). As second option seemed easy and clean we built the web service requests and ran each of them to setup data. However we felt there was still some more scope for improvement on this. And then flashed the test suite functionality of SoapUI!!

Once I had the idea it was very easy to setup the project on SoapUI with one test case under a test suite. That's it. I created one test step (web service request) for each profile to be created. However user creation required some of the profile information. Property Transfer came in handy to transfer the required values from the response of a specific profile creation request to the user creation request. (I tried many ways to do this with Property Expansion, however couldn't find a way to do this).


The snapshot of the setup is as shown in the figure. As you can see there are multiple SOAP requests, one each for profile/user creation. The property transfer worked fine, however I observed one weird behavior. Though the response xml did not contain any namespace prefix, In Property Transfer I still had to declare the namespace and mention the xpath elements with this namespace prefix. I still need to find a reason for this behavior.

Another notable thing to mention here is to turn on the option to close http connection after every request. Normally SoapUI will open a http connection and sends the web service requests one by one. However due to few unknown problems on data size limit I encountered, the test case was failing at some point midway through the test steps. However after turning on the option to close http connection after every request the data setup ran very smoothly. This option can be accessed under File -> Preferences -> Http Settings.

Tuesday, February 10, 2009

SoapUI - Property Expansion

While profiling one of my web services I was looking for an effective tool for load testing my web service. Initially thought of JMeter, but due to my happy experience with SoapUI in the past I decided to use SoapUI.

My request xml had multiple fields however couple of fields I had to send the same data. This wouldn't have been a problem during unit testing, but while load testing this service the value of these fields should be unique per test request. So my problem was say If I am sending 50 requests then in each request the value of these fields though common should be unique. Example request would be as below...
<soapenv:Envelope xmlns:soapenv = "http://schemas.xmlsoap.org/soap/envelope/" xmlns:web = "http://www.xyz.com/webservices/">
<soapenv:Header/>
<soapenv:Body>
<web:MigrateOrdersRequest>
<web:Header>...</web:Header>
<web:Credentials>...<web:Credentials>
<web:Order>
...
<web:OrderNumber>PO10001</web:OrderNumber>
...
<web:OrderLines>
<web:OrderLine>
...
<web:SerialNumber>PO10001</web:SerialNumber>
...
</web:orderLine>
<web:OrderLine>...</web:OrderLine>
</web:OrderLines>
</web:Order>
<web:MigrateOrdersRequest>
</soapenv:Body>
</soapenv:Envelope>

Here I have to pass both PO number and Serial Number unique and same. I initially looked for groovy script, but didn't work out for me. The other feature which really impressed me was Property Expansion which really did it. The property expansion will evaluate the property for you in the soap request may be it is from implicit objects, properties or any random math expression.

The solution initially looked tough was very very simple in the end. I just created a new TestCase in my soapUI testSuite with just one test step which was the soap request. And I created a load test step in the same test case (visibly load test will have only one test step). I used simple strategy with limit as 5 seconds and Test Delay of 5000 milliseconds and giving as many threads as required to mimic the scenario where 'n' (say 50) test requests hit the server. With other strategies where Test Delay was lesser than limit, the counter was not actually unique as the same thread after Test Delay was creating a new request. The modified request is as below.
<soapenv:Envelope xmlns:soapenv = "http://schemas.xmlsoap.org/soap/envelope/" xmlns:web = "http://www.xyz.com/webservices/">
<soapenv:Header/>
<soapenv:Body>
<web:MigrateOrdersRequest>
<web:Header>...</web:Header>
<web:Credentials>...<web:Credentials>
<web:Order>
...
<web:OrderNumber>PO1000${=context.getProperty("ThreadIndex")}${=context.getProperty("RunCount")}</web:OrderNumber>
...
<web:OrderLines>
<web:OrderLine>
...
<web:SerialNumber>PO1000${=context.getProperty("ThreadIndex")}${=context.getProperty("RunCount")}</web:SerialNumber>
...
</web:orderLine>
<web:OrderLine>...</web:OrderLine>
</web:OrderLines>
</web:Order>
<web:MigrateOrdersRequest>
</soapenv:Body>
</soapenv:Envelope>

Here after every load test the PO1000 needs to be modified to give next set of unique numbers. The catch here is that ${=<expression>}was actually evaluating to a value by soapUI at runtime. This expression can be any expression with the objects available in the context like properties, implicits etc.

Friday, February 6, 2009

Design - Singleton Pattern

JVM is a virtual machine where you find threads, objects, classes, classloaders, garbage collector etc having their own living space in the machine. Of all these it is the threads which keeps the metabolism going. When all the threads are dead the virtual machine dies. During its lifetime these threads create, edit or act upon multiple objects. Objects hold data and defines the behavior. In certain instances we need specialized objects holding data which needs to be shared across the virtual machine. This requires us to maintain only one instance of the object which is shared across multiple threads in the jvm. This is defined by Singleton pattern. Below are my thoughts and understandings of this pattern.

The basic definition of this pattern is as below.
1. Make the object constructor private. This allows the control on object creation.
2. Define the static object reference to self to hold the instance of this object.
3. Define the static getter method to get a reference to the object.
There are many flavors of pattern implementation, which are as below.

A. A very simple way of implementing Singleton is as below. This works in both the situations of single and multi-threaded environment.
public class Singleton{
private static final Singleton instance = new Singleton();
//Other data attributes go here...
private Singleton(){}
public static Singleton getInstance(){
return instance;
}
//Other methods go here...
}

The above method is simple and very effective, but this may not be desirable in few design situations. The above method does early initialization of the object while the below methods talk about the lazy initializations.

B. When more control is needed, like handling the situations when the initialization in the constructor throwing exception. Though exception may be handled in the constructor or a new exception can be thrown from constructor, we may want to return null value to the to the calling method rather than return this partially initialized instance.
//CASE: Single threaded environment:
public class Singleton{
private static Singleton instance = null;
//Other data attributes go here...
private Singleton(){}
public static Singleton getInstance(){
if(instance = null) instance = new Singleton();
return instance;
}
//Other methods go here...
}
//CASE: Multi threaded environment
public class Singleton{
private static Singleton instance = null;
//Other data attributes go here...
private Singleton(){}
private static synchronized Singleton createInstance(){
if(instance == null){
//Exception handling can be done here.
instance = new Singleton();
}
return instance;
}
public static Singleton getInstance(){
Singleton singleton = instance;
if(singleton = null){
singleton = createInstance();
}
return singleton;
}
//Other methods go here...
}

C. There is also the other reason why we may not do the early initialization. If we wish to extend from the Singleton class. Below style talks of this in the multi threaded environment.
//CASE: Parent:
public class Singleton{
protected static Singleton instance = null;
//Other data attributes go here...
protected Singleton(){}
private static synchronized Singleton createInstance(){
if(instance == null){
instance = new Singleton();
}
return instance;
}
public static Singleton getInstance(){
Singleton singleton = instance;
if(singleton = null){
singleton = createInstance();
}
return singleton;
}
//Other methods go here...
}
//CASE: Child
public class ChildSingleton extends Singleton{
//Other data attributes go here...
protected ChildSingleton(){}
private static synchronized Singleton createInstance(){
//Overriding the createInstance behaviour
if(instance == null){
instance = new ChildSingleton();
}
return instance;
}
//Other methods go here...
}

However be careful in the above method as the protected access specifier indicates that it can be accessed by the other classes in the same package as well, which gives a leak to create multiple instances.

D.One of the good approaches I have come across. This works well in all situations and is lazy initialization as well.
public class Singleton{
//Other data attributes go here...
private Singleton(){}

public static Singleton getInstance(){
return SingletonHolder.INSTANCE;
}
//Other methods go here...

//Inner class
private static class SingletonHolder{
private static final Singleton INSTANCE = new Singleton();
}
}

But beware that Singleton may not really be a single instance and there can be many leaks. There are some more good articles on this topic. Few of them are mentioned below.
http://en.wikipedia.org/wiki/Singleton_pattern
http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns.html

Thursday, January 29, 2009

J2EE Remote debugging

To enable remote debugging both server and client needs to be configured. The server should be enabled to listen to debug connections and client should open a connection and interact with server for debug information.

On the Server:
Below are the jvm parameters which have to be passed to any server to enable debugging.
-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=7010
Below are the meaning of each parameter
Xdebug- Enables debugging (start the jvm and listen to debug connections)
Xnoagent- Disables VM support for old jdb. Basically it disables the old way of communicating with the debugee. It is optional.
Xrunjdwp-Makes use of transport and the JDWP protocol to communicate with a separate debugger application. The sub-options specify the details required like
transport=dt_socket specifies to use socket connection on the port specified by the address.
transport=dt_shmem uses available shared memory transport address.

On the Client: (Here it is eclipse)
Follow the steps below:
1. Open java perspective
2. Open the java class where you want to place breakpoint
3. Add breakpoint
4. Now Go to menu bar Run->Debug Configurations (In older versions I think it is Run->Open Debug Dialog).
5. Right click on the 'Remote Java Application' in the left section of popup window. select New.
6. The class and package would be automatically selected for you as you had opened the java file just before you opened debug configurations.
7. Give proper host and port as mentioned in the server above, Apply and click debug.
8. Once you click debug eclipse will try to connect to server on the port.
Now run the application and you will see that the the program control would stop at the breakpoint you just added when your breakpoint is reached in the program flow.

Learning programming

    Programming is an interesting world where you apply your skills to build a software program that comes into life when it is run on a com...