Cache mediation pattern specification: an overview

Cache mediation resides between the service provider and the service consumer, and therefore can benefit multiple service providers and service consumers in one solution. This article proposes a cache mediation pattern as a reusable solution to accelerate service response in a Service-Oriented Architecture (SOA) environment where messaging middleware is employed as the communication channel.

Yan Fang Rao (raofy@cn.ibm.com), Staff Research and Developement Engineer, IBM, Software Group

Fang Yan Rao is a staff research and development engineer in the IBM China Research Lab. She received an M.S. degree in computer science from Xi'an Jiaotong University in 2000. Ms. Rao currently focuses on SOA research.



Ru Fang (fangru@cn.ibm.com), Research and Development Engineer, IBM, Software Group

Ru Fang is a research and development engineer in the IBM China Research Lab. She received an M.S. degree in computer science from Xi'an Jiaotong University in 2005. Since joining IBM, Ms. Fang has worked in the area of SOA research.



Dr. Zhong Tian (tianz@cn.ibm.com), Senior Architect, IBM, Software Group

Zhong Tian is a senior architect at Lab Based Services at the IBM China Development Lab. He received a Ph.D. in computer science from FuDan University in 1995. Much of his customer experience is with large manufacturing, banking and transportation industry solution design and development. He has worked in the area of SOA, business process modeling and integration and e-commerce. Dr. Tian is leading architect for solution development at China Development Lab.



Eoin Lane, Senior Solution Engineer, IBM, Software Group

Dr. Eoin Lane is a senior solution engineer in IBM's Enterprise Integration Group. He serves as a lead for the SOA Pattern effort within that group.



Harini Srinivasan (harini@us.ibm.com), Software Engineer, IBM, Software Group

Harini Srinivasan is a member of the SOA Design Requirements team in IBM's Enterprise Integration Group. Her interests are in Web and SOA application performance analysis, model-driven development approach for building SOA solutions, the design and optimization of applications and runtimes. Before joining the EIS team in IBM Software Group she served as a Research Staff Member in the Software Technology department at the IBM T.J Watson Research Center.



Timothy Banks (tim_banks@uk.ibm.com), Software Engineer, IBM, Software Group

Tim Banks is a software engineer in IBM Software Group. Much of his experience with customers and large systems was gained on the communications facilities of the CICS transaction processing system, and more recently he has been working on Web services standards for large systems (including Grids) and patterns for integration of services in large scale systems, which is sometimes known as ESB technology.



He Lei (heleihl@cn.ibm.com), Staff Software Engineer, IBM, Software Group

He Lei (Joyce) is a staff software engineer with IBM's Enterprise Integration Design Center in Beijing, China. She received an M.S. degree in computer science from BeiHang University in 2003. Since joining IBM, Ms. He has worked on China Grid project for the Grid Computing Group of CSDL and has worked on customer projects for EIS design center. She is currently working on IBM SOA supporting tools.



30 May 2006

Also available in Chinese

Introduction

Performance is a major concern in the Service-Oriented Architecture (SOA) environment. Reducing the response time of costly remote service invocations in such environments is a critical challenge in many real life cases. Caching, widely used to improve performance, has been used successfully in many solutions to address the performance issue. This article discusses a cache mediation pattern as a reusable solution to accelerate service response in a SOA environment where messaging middleware is employed as the communication channel. The cache in this pattern is resides on the messaging middleware between the service providers and the service consumers. Unlike traditional design patterns, this pattern is more at the infrastructure level and leverages existing capabilities provided by the messaging middleware.


Context

In an SOA environment, service providers and requesters are loosely coupled and distributed across the network, either within an organization or across organizational boundaries. Performance is a key factor In such a distributed environment. For example, XML is a widely used message format for service providers and consumers in SOA. XML message packaging and parsing brings extra overhead to both ends. Therefore Web service invocation costs more in terms of response time than some other kinds of remote procedure invocation. Reducing the response time of costly remote service invocations in such environments is a critical challenge in many real life cases. Asynchronous messaging is widely recognized as an effective communication channel in an SOA environment where the service provider and the consumer may be separated across the Internet. Compared with other communication channels like direct SOAP over HTTP, messaging middleware provides controlled and mediated message delivery between service providers and consumers. The mediation capabilities like message transformation, logging, routing, etc, are provided by the mediations in the message middleware. The performance of such mediated service invocation is further decreased by the intervening message mediations.

Messaging middleware supports multiple messaging paradigms: request-response, publish-subscribe, and one-way. This article focuses on the request-response messaging paradigm between service providers and consumers.


The problem

One key quality of service within an SOA environment is performance, given the verbose XML message payload and extra overhead of packaging and parsing XML. While using messaging middleware as the communication channel between service providers and consumers, performance is further decreased by the intervening message mediations.

Providing reasonable performance is a critical challenge for most production environments. Accelerating service response time, when messaging middleware is the communication channel, is a basic problem in an SOA environment.


Forces at work in an SOA environment

Typically the forces at work in a situation like this include:

  • Performance: The response time of services in an SOA environment plays a key role in most production environments. The response time of the service provider decreases as the size or frequency of requests increase. The intervening mediations in messaging middleware further aggravate the problem.
  • Accelerating multiple service providers and consumers: Messaging middleware resides between service providers and service consumers. And the pattern user wants to accelerate response of multiple service providers and requests from multiple service consumers in one solution. The intervening mediations in messaging middleware further aggravates the problem.
  • Leveraging existing cache solutions rather than build a cache from scratch.

The solution

The solution is to reduce the service response time by caching the service response messages in messaging middleware. When an identical request message is issued, the message system retrieves the corresponding response message from the cache and returns it directly to the service consumer instead of forwarding the request message to the service provider. This can eliminate costly remote service invocation and improve the service response time. In messaging middleware that is connected to an SOA environment, multiple service providers and consumers can be attached to the messaging middleware. Unlike the cache on the server side or client side, the mediation cache resides in the communication channel in the middle. Therefore providing a cache solution in messaging middleware can accelerate service requests from multiple service consumers residing on different locations, and also benefit multiple service providers.

This solution is based on the ESB cache pattern scenario proposed in the article, Enterprise Service Bus : Making SOA real (IBM Systems Journal,Volume 44, Number 4, 2005), which describes how to accelerate service response time in the ESB context (See Figure 1). The Enterprise Service Bus (ESB) is the key element of the messaging middleware. In this caching scenario, when the cache mediation finds a response to a service request in the cache, it will return the cached response directly to the message requester. If it does not find such items within the cache, it will forward the request to the service provider which will, in turn, return a response that is routed back to the message requester. Meanwhile, the response messages will be cached by the cache mediation.

Figure 1. ESB cache pattern
ESB Cache Pattern

Figure 1 is adapted from Enterprise Service Bus: Making SOA real.

Under closer investigation, there are two detailed design challenges the Cache Mediation pattern needs to solve:

Challenge 1: Identify the request and corresponding response in asynchronous messaging environment

A cache can be viewed as simply a collection of cache items (key, data). Data is identified by its key in the cache. A cache class can has one basic method "Object hitCache(Object key)" which returns the corresponding data according to a key, and places fresh data into the cache if it is missed according to a specific cache refreshing policy.

The cache needs to identify the request and corresponding response to accelerate service responsiveness. The request data is used to generate the cache key, and the response data is stored in the cache as cache data in the cache item. So when the same request is issued to the service provider, the response data can be retrieved from cache directly. Both server side cache and client side cache have the convenience that it can identify a request and its response easily from one invocation. For example, the hitCache method can look like this:

Listing 1. hitCache method
	public Object hitCache(Object request) {
   Object key = generateKey(request); 
   Object response = this.cache.get(key); //cache is missed, invoke the service and get response data 
   if (response == null){ 
      response = this.service.invoke(request); 
      this.cache.add(key, response); 
   } 
   return response; 
   }

In a messaging environment, the invocation is different. The request message and response message are delivered independently. Figure 2 depicts this behavior. In this environment, message mediations work independently and asynchronously. Request messages and response messages trigger request message mediation and response message mediation respectively. For example, in the Service Integration Bus (SIBus) implementation of ESB in IBM® WebSphere® Application Server, the message mediation handlers are implemented as Enterprise Java™ Beans (EJBs). Neither the request mediation nor the response mediation can identify the request message and its corresponding response message in the same invocation of the hitCache method, as illustrated above. Request mediation and response mediation work independently,that is, when response mediation is triggered by a response message, the request mediation may become inactive. The Mediation Cache pattern requires a special design to handle this problem.

Figure 2. Behavior of mediations in messaging middleware
Behavior of mediations in messaging middleware

Challenge 2: Leverage existing caching mechanism

Another problem the pattern design needs to consider is how to leverage existing cache solutions as underpinnings for the caching mechanism. Caching is a widely used technology to improve application performance. Various caches have been designed and implemented to improve application responsiveness in various software products, like JbossCache, SpiritCache, the Dynamic Cache Service of Websphere Application Server. The cache mediation pattern’s design needs to enable you to accommodate different underlying caching solutions rather than build a cache from scratch.

The detailed solution is described in following sections.

Structure: Two cache mediations coupled by one cache

Figure 3 depicts the structure of the cache mediation pattern. The structure can be characterized as two cache mediations coupled by one cache instance. As mentioned earlier, mediation refers to the message processor in a messaging system. It performs tasks like logging, routing, message format transformation and other tasks which need to be performed on messages. By using two cache mediations coupled by a single cache instance, as well as collaboration between the two cache mediations, the correlated request and response message identification problem can be solved.

Figure 3. Cache mediation pattern structure
Cache mediation pattern structure

Class diagram

The class diagram, illustrated in Figure 4, shows the detailed structure of the cache mediations involved in the pattern.

In the class diagram, the ServiceClient interface generates requests. The Service interface produces responses according to the request from the ServiceClient. The two interfaces are connected with the Mediation class, which is the communication channel between the Service and the ServiceClient. This is a typical invocation style in an SOA environment with messaging middleware.

The Mediation class is composed of the RequestCacheMediation class and theResponseCacheMediaton class, which implements the Cache Mediation Handler interface. As introduced earlier, a cache is typically composed of a group of cache entries. A cache entry is organized as a duplicate of key, and data where the key is utilized to identify the data. The Cache Mediation Handler interface generates key and data from the request and response messages, then supports caching capability by invoking hitCache(), insert() and remove() operations provided by Cacheinterface. The Cache interface is implemented by the CacheImpl class. Here the hitCache() operation can determine if there has already existed a cache entry given a specific key, the insert() operation inserts a new cache entry into the cache and the remove() operation is used to remove a cache entry according to a given cache key.

Figure 4. Cache mediation pattern class diagram
Cache mediation pattern class diagram

Sequence diagram

Collaboration among the pattern participants is described in Figure 5. The interaction between the service provider, cache mediations, and service consumer is as follows:

  • First, a service consumer sends a request message to a service provider. The messaging middleware routes the message to the destination of the service provider.
  • When the message arrives at the destination, the cache request mediation attached to the destination can access the message content and perform some actions on the message. The cache request mediation generates a cache key based on the request message, and searches for a response in the cache.
  • If a matching response is found, the cache request mediation returns the response message to the service consumer immediately. Otherwise, the request message will be sent to the service provider and a new cache entry, with the cache key generated, will be inserted into the cache.
  • When the service provider returns the response message and the messaging middleware routes the response to the service consumer, the cache response mediation is invoked.
  • The cache response mediationcompletes the cache entry created by the cache request mediation by identifying the correlated request message’s cache key in the cache, and updating the cache item with the response message.
Figure 5. Behavior of participants in Cache Mediation pattern
Behavior of participants in Cache Mediation pattern

Applicability

  • Communication channel: The communication channel between the service provider and the consumer needs to be messaging middleware if we want to apply the pattern.
  • Cache location: The cache is associated with the cache mediation that resides in the messaging middleware. Caches on the service provider side or the service requester side are not applicable for this pattern.
  • Invocation style: To apply the pattern, the invocation style should be request and response, where one response message is generated according to one request. Other invocation styles like publish/subscribe are not applicable to this pattern.
  • Service provider side tolerance: The cache pattern requires that the service be accelerated so it can tolerate identical requests not being delivered to it and responses can be cached by the messaging middleware. This has several notable characteristics: the service is not transactional; data change frequency is not high, or the data expiration time is not short; the data auditing policy allows request data that is not arriving at the service provider side; and the data privacy policy allows data to be cached in a communication channel.

Consequences

  • Behavior: The behavior of the messaging middleware is changed. It actively changes the routing path of the request message and sends cached response messages back to the service consumer. The service provider will not receive every request message.
  • Data: With the cache in messaging middleware, response messages may not be up to date. The data staleness introduced by the cache needs to be understood by cache users, and can be alleviated by a cache data refresh policy.
  • Performance: The cache increases the responsiveness of the service by caching request and corresponding response messages. However, caching has its costs. Message mediations need extra cost to access the payload of messages and store cached messages.

Considerations in using caching

  • Message correlation: Messaging middleware needs to provide a message correlation mechanism to correlate request and corresponding response messages. Correlation can be either automatically done by messaging middleware, or by the service provider with correlation APIs provided by messaging middleware.
  • Message identification: Message middleware can provide faster message identification options so that pattern users can choose appropriate message identification for cache item identification key generation and comparison.
  • Underlying cache: The Cache Mediation pattern is not a design pattern for general purpose cache design, rather it leverages an existing basic cache capability provided in messaging middleware or other cache systems. In our reference implementation, we are using the Dynamic Cache Service of Websphere Application Server as the underlying cache for this pattern.

Related patterns

Requester Side Cache Pattern: The Cache Mediation pattern is originally inspired by the investigation of how, and whether, the requester side cache pattern can be used in the messaging middleware context. It also attempts to solve similar problems and uses different cache design, with the cache residing on the requester side.


Known uses

This pattern can be used in the Service Integration Bus (SIBus), which is one implementation of the ESB. The SIBus is implemented on IBM WebSphere Application Server Version 6, which can leverage the dynamic cache provided by IBM WebSphere Application Server Version 6 to cache the pairs of request and response messages. In this use case, the caching policies, such as data validation policy, are supported by IBM WebSphere Application Server Version 6, which means the caching policy is configured in some deployment files in IBM WebSphere Application Server Version 6.


Conclusion

A pattern is a solution at a certain level of abstraction that is intended to solve recurring problems in different contexts. This article proposes the Cache Mediation pattern as a new pattern in an SOA environment, following the outline of patterns as specified in the book titled "Design Patterns: Elements of Reusable Object-Oriented Software" by Gamma et al. Unlike the server side and the client side cache, cache mediation resides between the service provider and the service consumer, and therefore can benefit multiple service providers and service consumers in one solution.

Resources

Learn

Get products and technologies

Discuss

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=125298
ArticleTitle=Cache mediation pattern specification: an overview
publish-date=05302006