The first thing that comes to mind on Mule Cache scope is how to implement this cache mechanism with a webservice. Mule has a wonderful mechanism of caching with its cache scope, available in Anypoint Studio with Mule ESB Enterprise, and there are examples available on internet on how to extend the Mule caching mechanism with EHCache. Check out Mule caching with EHCache if you are still looking for an example.
In this post, I will demonstrate a simple example of how to use this powerful caching mechanism (with EHCache) on a webservice.
To implement a SOAP webservice with Cache you need to have a flow divided into two as the following:
In the first flow ServiceFlow, the payload after HTTP inbound endpoint is getting converted into String and getting into the Mule Cache block. In the Cache block, the payload is dispatched to the next flow using VM outbound connector.
In the second flow ServiceFlow2, the payload is accepted by the VM inbound endpoint which is then passed to the CXF component containing the webservice interface and then followed by a Java component which is responsible for implementing the interface.
Now, the reason I’ve used an Object to String before the Cache block is to convert the payload into a String to make it a consumable payload (The HTTP inbound endpoint produces a streaming payload, so it is not cachable. The to string transformer deserializes this stream to a non-consumable payload, thus the cache scope works) since the Cache will only accept consumable values in it to store.
Here is the following code for this implementation:
Now, what we’ll do is run and test the webservice. This webservice retrieves a row from the database and will show the row value in the SOAP response.
Here’s how we’ll test the webservice:
You can see that we have used SoapUI to test the webservice. Now when we hit the service, you can see in the SOAP request, it takes id as input and then fetches all the data from the database for that id.
Now, what we will do is manually deleting the entire row from the database. In my case, I have used sql server and deleted the row from the table using a SQL query:
With this in place, if we again hit the service, we will get the same response as we got earlier:
You can see that, though the entire row is deleted from the database table, it’s still showing the response, which means it is fetching the response from cache and not hitting the actual database.
If we now look into our XML configuration, we will find the following bit of XML:
The documentation for these properties states:
timeToIdleSeconds is the maximum number of seconds an element can exist in the cache without being accessed.
timeToLiveSeconds is the maximum number of seconds an element can exist in the cache regardless of use. The element expires at this limit and will no longer be returned from the cache.
So, now if we hit service again after the time defined in timeToLiveSeconds , we will find the following result:
As you can see, it clearly shows no records are there in the database, which means the cache has expired and the service is actually hitting the database.
I’ve hopefully been clear enough in displaying the implementation of Mule cache (extending EHCache) with a webservice in a simplest way.
Now it’s your turn to experiment with the Cache scope. Please share your comments and experiences below in the comments section!
