Caching web services to improve the performance of business solutions in WebSphere Process Server

Web services play a key role in SOA business solutions but web service SOAP calls can be expensive to influence the performance. If the data of web services does not change frequently, properly caching could boost the performance. This article shows you how to use dynamic cache in a declarative way to cache the results of web service calls in WebSphere Process Server.

Share:

Jun Xue (xuejun@cn.ibm.com), Software Engineer, IBM

Jun Xue is a Software Engineer at the IBM China Development Lab, Shanghai. He has 3 years of experience on SOA-solution design and development across DB2, WebSphere Process Server, and WebSphere Portal Server.



29 October 2010

Also available in

Prerequisites

In this article, you will use WebSphere Integration Developer 7.0 to build the sample SCA application. We assume that you have experience with SCA and Java programming, web services, WSDL interfaces and SOAP/HTTP requests. Also, we assume you have basic administration skills for WebSphere Process Server.


Introduction

Web services are widely used interfaces for different types of clients to invoke SCA applications. But web services SOAP calls can be expensive that the server will receive a heavy load and response time will increase a lot. So how to improve the performance of SOA business solutions? Our answer is to cache the results of web services invocations so that we can reduce the amount of processing actually done within your SCA applications.

One of the ways that Process Server provides the caching capability is through a service called dynamic cache. Dynamic cache or dynacache as it is often called, provides the capability to cache the output of different objects within your application.

In this article, you will learn how to caching the existing web services without any additional lines of code. You can manage your web services caching behavior by the cache configuration file. The article will cover the basic principles you need to know while using cache configuration file to cache the results of web service calls, how to define the cache configuration file and how to use it for your application module. In addition, you will learn how to validate and monitor the caching results.

The following picture illustrates the basic principles for SOAP request to call caching web services using dynamic cache:

Figure 1. Principles for calling caching web services
Principles for calling caching web services

Prepare the sample SCA application

In this section we will describe our sample SCA application using the WSDL port type interface and Java implementation. Our sample was developed and tested using WebSphere Integration Developer v7.0, to import the sample project:

  1. Download CacheWebServiceSample.zip (found at the end of the document) to a temporary directory.
  2. In Integration Developer, select menu File > Import to open the Import wizard, on the Select dialog, expand Other and select Project Exchange, click Next.
  3. The import projects page will display. Click Browse to select the zip file.
  4. Browse to the temporary directory and select the zip file you just downloaded in step 1. (Figure 2)
Figure 2. Import Project Interchange Contents Wizard
Import Project Interchange Contents Wizard
  1. Click Select All.
  2. Click Finish.

Review business objects and the service interface

There are two simple business objects named Product and Products as shown in Figure 3.

Figure 3. Business objects
Business objects

There is one service interface named ProjectService with three service operations around the two business objects, as shown in Figure 4:

Figure 4. Service interface
Service interface

The meanings of the three operations in above service are:

  1. addProduct: for users to add new products
  2. getProductsByCategory: find all products for the specific category name
  3. getAllProducts: find all existing products

Review the service implementation

In the sample service implementation, we make sure that, each function's execution time requires at least one second and it will print out some message while being executed.

List 1 shows the sample implementation of getProductsByCategory, it firstly prints out a message to indicate the function is executed, and then in the mocked implementation of productDAO, it finds out the products for the category and waits one second to return the result.

Listing 1. Sample implementation of getProductsByCategory
/**
 * Method generated to support implementation of operation 
 * "getProductsByCategory" defined for WSDL port type
 * named "ProductService".
 *
 * The presence of commonj.sdo.DataObject as the return type and/or as a parameter
 * type conveys that it is a complex type. Please refer to the 
 * WSDL Definition for more information
 * on the type of input, output and fault(s).
 */
public DataObject getProductsByCategory(String categoryName) {
    System.out.println("Enter into the body of getProductsByCategory, by category name 
                                            ["+categoryName+"]");
    return productDAO.getProductsByCategoryName(categoryName);
}

/**
 * Gets the products by the category name
 * @param name, the categroy name
 * @return the products data object
 */
public DataObject getProductsByCategoryName(String name){
        List<DataObject> resultProducts = new ArrayList<DataObject>(2);
        for(DataObject p : this.allProducts){
                String categroyName = p.getString("category");
                if(name.equalsIgnoreCase(categroyName)){
                        resultProducts.add(p);
                }
        }
        DataObject result = this.newProducts();
        result.setList("product", resultProducts);
        waitOneMinute();
        return result;
}
</DataObject>

Test the sample application using Integration Test Client

To test the sample application:

  1. In Business Integration perspective of Integration Developer, right click the project, select Test > Test Module from the popup menu.
  2. The Integration Test Client page will display. On the right panel, expand Details Properties; select the component, service interface and corresponding operation you want to do testing. Here we select ProductComponent, ProductService and getProductByCategory for testing as an example (Figure 5)
  3. If the operation requires some input message, you need to input it in the right bottom panel with title Initial request parameters. (Figure 5)
Figure 5. Integration Test Client for the sample application
Integration Test Client for the sample application
  1. When the service configuration and parameters are ready, click the Invoke icon on the left side of the tool bar to start running. (Figure 5)
  2. The Deployment Location dialog will display, select the Process Server runtime and click Finish.
  3. The Process Server will launch and the module will be deployed.
  4. Minutes later, you can check the result in Integration Test Client opened in step 2. (Figure 6)
Figure 6. Review testing results
Review testing result

Enable dynamic cache service in process server

To enable dynamic cache service for web services, you should enable the servlet caching on the server startup:

  1. Open the Process Server's administrative console in your browser.
  2. Navigate to Servers > WebSphere application servers > server_name > Web Container Settings > Web container, you can see the configuration page similar to Figure 7:
Figure 7. Servlet caching configuration page
Servlet caching configuration page
  1. Make sure the Enable servlet caching option is selected.
  2. Click Ok.
  3. Save the changes and restart the server.

Process Server provides one application named Dynamic Cache Monitor for users to view and manage the cache entries; by default, this application hasn’t been installed, follow steps below to install and use it.

  1. In the administrative console, navigate to Applications > New Application, click New Enterprise Application.
  2. Click Browse to locate the application ear file on the server’s installable applications path, that is <WPS_HOME>/ installableApps/ CacheMonitor.ear
  3. Follow the wizard to install it properly.
  4. Once installed, you can view the application by navigating to Applications < WebSphere enterprise applications, where you can start it.
  5. To authorize the application's access to everyone, navigate to Applications > WebSphere enterprise applications > Dynamic Cache Monitor > Security role to user/group mapping; on this page, select the checkbox of role administrator, and select Everyone from Map Special Subjects menu. (Figure 8)
Figure 8. Security role to user/group mapping
Security role to user/group mapping
  1. Click Ok.
  2. Start Dynamic Cache Monitor application. (Figure 9)
Figure 9. Start dynamic cache monitor application
Start dynamic cache monitor application
  1. In your browser, you can open the web page of dynamic cache monitor similar to Figure 10:
Figure 10. Web page of dynamic cache monitor
Web page of dynamic cache monitor

Once the dynamic cache service is enabled and the dynamic cache monitor application is installed, it is ready to use with your application.


Two methods to use the cache configuration file

Cache specification and invalidation policies are provided through the cachespec.xml file. This file is very powerful that it can define caches for a few types of dynamic content, like servlet/JSP fragment, web services, etc. In this article we will demo how to use it to cache web services. This type of cache will hold the result of web service SOAP calls.

You can either save a global cachespec.xml in the application server’s properties directory, or place the cache configuration file with the deployment module.

Listing 2. Sample global cachespec.xml file for web service call
<?xml version="1.0" ?>
<cache>
  <cache-entry>
      <class>webservice</class>
      <name>/CacheWebServiceSampleWeb/sca/ProductServiceExport2</name>
      <sharing-policy>not-shared</sharing-policy>
      <cache-id>
    		<component id="21" type="serviceOperation">
    	<value>http://CacheWebServiceSample/ProductService:getProductsByCategory</value>
    		</component>
    		<component id="Hash" type="SOAPEnvelope"/>
    	    <timeout>180</timeout>
    	    <priority>1</priority>
      </cache-id>   	    	    				        
      <cache-id>
            <component id="23" type="serviceOperation">
                 <value>http://CacheWebServiceSample/
                        ProductService:getAllProducts</value>
            </component>
            <component id="Hash" type="SOAPEnvelope"/>
            <timeout>180</timeout>
            <priority>1</priority>
      </cache-id>
  </cache-entry>  
</cache>

Listing 2 shows a sample global cachespec.xml file with a single cache entry for the web service call. The class element indicates the type of entry is web service call; the value of name element is the URI path of the web service; element cache-id defines the identifier for the cache entry, here the value of the id is the combination of service operation and a hash value of SOAP envelop; and timeout element shows the cache entry will be kept for 180 seconds.

You can find the value of name element from the web service binding file as shown in Figure 11:

Figure 11. URI path of the web service
URI path of the web service

For the value of the service operation component, it is a combination of the service interface namespace and the operation name, as shown in Figure 12:

Figure 12. Service operation
Service operation
Listing 3. Sample global cachespec.xml file for web service call
<?xml version="1.0" ?<
<cache>
  <cache-entry>
      <class>webservice</class>
      <name>/sca/ProductServiceExport2</name>
      <sharing-policy>not-shared</sharing-policy>
      <cache-id>
    		<component id="21" type="serviceOperation">
    	<value>http://CacheWebServiceSample/ProductService:getProductsByCategory</value>
    		</component>
    		<component id="Hash" type="SOAPEnvelope"/>
    	    <timeout>180</timeout>
    	    <priority>1</priority>
      </cache-id>   	    	    				        
      <cache-id>
            <component id="23" type="serviceOperation">
                 <value>http://CacheWebServiceSample/ProductService:getAllProducts</value>
            </component>
            <component id="Hash" type="SOAPEnvelope"/>
            <timeout>180</timeout>
            <priority>1</priority>
      </cache-id>
  </cache-entry>
</cache>

Listing 3 shows a sample module level cachespec.xml file with a single cache entry for the web service call. Compare with the previous sample configuration file in Listing 2, the only difference between the two is the value of the name element: If the configuration file will be deployed with the module, the URI path of the web service should be relative path instead of full path.

For example, the full URI path of product service is "/CacheWebServiceSampleWeb/sca/ProductServiceExport2", and the relative path will be "/sca/ProductServiceExport2".

To enable the cache configuration file for the web service call using the global method:

  1. Navigate to your Process Servers properties folder, normally it will be like <WPS_ROOT>/profiles/<profile_name>/properties/.
  2. Copy the sample global cache configuration file (Listing 2), make sure the file name should be cachespec.xml
  3. Restart the Process Server.

To deploy the cachespec.xml file together with the application module:

  1. In Integration Developer, switch to Business Integration perspective, select menu Project > Business Integration Projects > Update Deploy Code.
  2. Switch to Java EE perspective, Integration Developer will auto generate a web module for the business integration application and the name of the web module will add the appendix "Web", here it will be CacheWebServiceSampleWeb (Figure 13)
Figure 13. Web module for business integration application
Web module for business integration application
  1. Copy the sample module level cache configuration file (Listing 3) to the folder <Web_module>/WebContent/WEB-INF. (Figure 13)
  2. Redeploy the business integration application CacheWebServiceSample to Process Server.

You can enable the caching policy for your business integration application by either of above methods. The recommended method is to define the cache specification per application module, and then you can redeploy the application with the latest cachespec.xml file to bring it into effect instead of restarting the Process Server.


Test the caching web services using SoapUI

We assume that you have deployed the cachespec.xml file with the sample application to Process Server. In the section, you will verify the web service cache behavior as expected.

SoapUI is an easy-to-use tool for testing web service; you can download and use it from the SoapUI website.

To test the sample caching web service, follow the steps:

  1. Download and install the SoapUI tool following the instructions on SoapUI website.
  2. Start the SoapUI, and select menu File > New soapUI Project, the wizard will launch, input CacheSample as the project name and click Browse to locate the WSDL, in this article, the file is: CacheWebServiceSample/CacheWebServiceSample_ProductServiceExport2.wsdl, (Figure 14).
Figure 14. New soapUI project
New soapUI project
  1. Click OK, the tool will create sample request for each service operations.
  2. Expand getProductsByCategory in the left panel and double click Request 1, you can see the pre-constructed SOAP request that can be sent as a test. (Figure 15)
  3. Enter the text book in <categoryName> node of the request envelope.
  4. Click the green arrow button in the toolbar just above the SOAP request text, it sends the request to the service and display the resulting SOAP response in the right-hand panel. (Figure 15)
Figure 15. First time invocation – response from the service
First time invocation – response from the service
  1. In the bottom of the pane, you can see the response time is nearly 2368 milliseconds. And in the Console view of Integration Developer, you can see a message printed out by the service execution. (Figure 16)
Figure 16. Server log after first time service invocation
Server log after first time service invocation
  1. Repeat step 6 to invoke the service for a second time, you can find that the response time reduces quite a lot (only 16 milliseconds) and you can not see any messages printed out in the Console view of Integration Developer. It means the result of this time SOAP request is from the cache. (Figure 17)
Figure 17. Second time invocation – response from the cache
Second time invocation – response from the cache

Enter the text pen in <categoryName> node of the request envelop and send the request for a third time, but with different category name. In the Console view of Integration Developer, there is a another message printed out that indicates the service is executed as shown in Figure 18, and Figure 19 shows the SoapUI request result panel after this time SOAP call.

Figure 18. Server log after third time service invocation
Server log after third time service invocation
Figure 19. Third time invocation – response from the service
Third time invocation – response from the service

This section describes how to test the caching web services by SoapUI tool; similarly, you can test all service operations to verify it.


Monitoring the web services result cache

In previous section Enable dynamic cache service in process server you have installed the Dynamic Cache Monitor application shipped together with the Process Server installation.

To use it follow the steps:

  1. Open the monitor page from your browser, the URL will be similar to http://locahost:9080/cachemonitor/, by default the Cache Statistics page displays (Figure 20), there is a Clear Cache button on the top, which can be used to clear the cache manually.
Figure 20. Cache statistics page
Cache statistics page
  1. To check whether or not there is any cache policy files, click Cache Policies link in the left navigation, you can see, there is one policy template with web service type (Figure 21)
Figure 21. Cache policies page
Cache policies page
  1. To view the cached content, click Cache Contents link in the left navigation, from this page, you can see there are currently two cached items and the cache it for each item (Figure 22)
Figure 22. Cache contents page
Cache contents page

Conclusion

Web services are widely used in SOA business solutions, but the web service SOAP calls can be very expensive. This article starts from a sample SCA application with web service export, talks how to define a set of cache policies and how to use it with the web service application. Accordingly to our testing results using SoapUI, it is obvious that the performance of web service call will be improved. In addition, this article introduces how to monitor the cache entries.


Download

DescriptionNameSize
Sample files for this articleCacheWebServiceSample.zip178KB

Resources

Learn

Get products and technologies

  • Evaluate IBM products in the way that suits you best: Download a product trial, try a product online, use a product in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement Service Oriented Architecture efficiently.

Discuss

  • Get involved in the My developerWorks community. Connect with other developerWorks users while exploring the developer-driven blogs, forums, groups, and wikis.

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into SOA and web services on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=SOA and web services
ArticleID=551845
ArticleTitle=Caching web services to improve the performance of business solutions in WebSphere Process Server
publish-date=10292010