A mock web service―The easy way (Part 1)

This article is written addressing a real situation that you might already have experienced―or are about to. WSO2 ESB is a very lightweight Enterprise Service Bus product that can be used to handle this situation at a level of perfection―especially, without taking more than a few minutes.

Let us think about a situation, where you hold the responsibility of developing and/or testing a software component, which depends on a few external web services. The software component needs to invoke each of those services proving some inputs, and then do some processing with responses given by those services. We may call this application component as “application Δ” hereafter, for the ease of reference.

If these services then are available to be used and are free of bugs; you will feel very comfortable with the developments of your end.

But—how would you think to deal with it, if those web services are not available to be used by the time you start developments/testing? How would you think to proceed with developments/testing related to the software component that you are responsible of?

Here comes the word “mock web services”: and that is one of the easiest ways of handling this type of a situation, without waiting until the “real web services” become available. With this approach, we would be developing a few (temporary) applications that would accept some inputs, and would dispatch a fake (hard-coded) response which follows the format of the response that the real service suppose to dispatch.

Let us consider a situation where you have to invoke a SOAP based web service, through your application. For example, we may assume that you are suppose to send a payload to the subjected web service like,

<t:account xmlns:t="http://www.teachingbad.com">
    <t:customerId>303101842</t:customerId>
    <t:accountNumber>100153451092</t:accountNumber>
    <t:accountType>Savings</t:accountType>
    <t:accountCurrency>LKR</t:accountCurrency>
    <t:accountBalance>250356.46</t:accountBalance>
</t:account>

If you also think that a mock service would do the trick, the next questions for you would be,

1. How to develop the mock service
2. Which technology to be used
3. What are the tools―such as IDE—to be used

A typical developer would select a language (technology) and an IDE and start coding a simple web service, if he/she is familiar with the relevant technologies and tools. If that person is not that familiar with those stuff, he/she will start to type on google “how to create a web service with visual studio” or “how to create a JAX-WS web service with eclipse”.

However, for a developer with some experience, it will take some time to write the code, compile, start an application server and deploy the application on it; while the other developer also has to take time to perform all the previously mentioned actions—and some additional time to read/learn what he/she just googled. Even after the mock web service application was developed, the developer will have to test it, fix bugs, compile and deploy it again and again.

The mock service applications will ultimately be dumped, when the real service becomes available to be used; and then perhaps, your application will need to be modified so that it would communicate with the real services, instead of communicating with the mock services.

Then, what is the easy way of developing the Mock Services?

In this article, I would be suggesting the easier way of doing this, and you need to download and install a few tools, in order to try what is described here.

1. JDK ( version 6 or higher )
2. SOAP UI ( for trying out )
3. WSO2 ESB ( in this case, to create and expose mock services )

WSO2 ESB allows you to create “Proxy Services”, which can be used to perform so many actions. But in this particular case, we will only be using it for providing some fake service endpoints, so that application Δ would identify those as real service endpoints; allowing itself to be developed/tested using those.

A proxy service can be defined using XML, and this does not require any code compilation or any wizard based deployment. Making modifications on an XML file will work just fine, when you need any modification to be made on this proxy service configuration code. However, when it comes to large scale enterprise-wide development and deployment, WSO2 provides IDE and tooling support with “WSO2 Developer Studio”, which facilitates the developer with the ability of developing and packaging all the configurations/artifacts within a single archive file, which may involve some wizard based deployments.

For the time being, I will stick to the WSO2 ESB Admin console based(or XML file based) development method, in order to make it easier to understand the basics.

Unlike a mock service application that you would create using java or asp.net, you do not have to dump this mock service once the real service becomes available―instead, you can use this proxy service as a layer of abstraction, allowing the requests/responses to be routed through the proxy service.

Once you do that, the proxy will accept the requests from the “application Δ” and direct it to the relevant web service endpoint, and receive the response from the web service and direct it to “application Δ”. This would take it to another level, having empowered you with the capabilities of “Message Mediation”.

However, I believe that you would prefer to play and get some hands on experience with WSO2 ESB, before understanding more conceptual stuff related to that. Leaving such subjects for future posts, I will simply be describing how to set-up and try the above mentioned case, with the use of WSO2 ESB, in the part 2 of this article. In that article, I will describe each and every step in detail, so that everybody could try it very easily; even a person who loves to copy, paste, execute and run.

The ESB takes care of all the enterprise related
connectivity, transformation, negotiation,
routing and such matters on behalf of you.

When you keep studying the matters related to the WSO2 ESB, you would realize what you could do with it, and how easily those could be done―with a very little learning. With it’s capabilities and performance, WSO2 ESB can truly become the soul of your Enterprise Middleware set-up, enriching the same with flexibility, connectivity & inter-operability, scalability, stability and high-availability. Being 100% free and open source, it allows you to download it and use for developments, testing and even on production.