muSOAing for 9/8/09

Now let us tackle the Simulator. In my previous post, I did articulate a few important reasons why a Simulator is needed. So here are some important points you need to consider when you want to implement one.

– How many services am I looking at which have the potential for Simulation
– How much flexibility do I need in my Simulator
– Do I need a blackbox simulator with very simple responses
– What level of customization is required, how complex are my services

Take it from me, any shop that is implementing services however big or small will need some level of simulation and there are several reasons for this. First of all, if you are designing a some complex business processes that involve the composing of one or more services, you will need to stub out or simulate a few that are still unavailable so the entire process can be tested and run end to end.

This is also important in an offline environment like a demo at a client location where you will need a simulator that can return the SOAP results that are required for the demo to run.

Guess, I have added a few more reasons for the need of a Simulator. Now let us talk about Simulator features itself. The first question that will be asked is Build or Buy. How do you answer this question. It really depends on what level of sophistication you require of your Simulator. If you want your Simulator to function like a black box. One that does not inspect the incoming request but blindly sends out a response based on configuration then there are several open source and commercial products available that let you do this.

If you need a more sophisticated one that does some intricate content based routing then you might not find a product that suits your needs. Whatever be the case, it is really not too difficult to build your own flexible simulator as I did for my previous engagement. I have found this to be very useful and have used it since in several other ones and others have been able to avail of this as well.

You can build a fairly sophisticated simulator by implementing a SAAJ Servlet that can receive a SOAP message and for the processing of content you can implement an Interface driven framework similar to a services invocation framework. The only difference is, each implementing class will implement a simulation instead of a service. In each class you can have total control over your incoming payload, inspect it and tailor your responses accordingly. As for the responses, you can either have a file driven approach or do something more sophisticated such as cache your responses in memory from a DB and then read off of memory for better performance.

Since these canonicals can be quite intricate and complex or in the case where you cannot leverage Canonicals but are waiting for schemas to be fleshed out (which can happen in a few cases), you will need tools to build out your responses. Ever tried handcrafting response files? Just Kidding!!!!!

For more detailed information of the simulator please feel free to contact me In my next post, I will talk about these tools, mainly the ones I built for my previous efforts.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: