An SOA pattern for performance

In my days as a consultant in London, I used to work for a French consultant company based in the center of London, just off Oxford Street. One of my assignments was to train recent computer science college graduates on how to become consultants. This resulted in an intensive one week boot camp that focused on UML, OOAD, and patterns in a model driven development environment. One of the pattern that I liked was the decorator or wrapper pattern.


As a pattern it could not be simpler and yet it has a subtlety that made it a great pattern to teach and to learn. It clearly shows the cherished object orientated principles of object encapsulation and polymorphism working in harmony, yet at the same time the pattern could be applied to any interface to enhance, extend or decorate its existing implementation. Now five years later, on an engagement in Texas the buss words were field based development of SOA patterns. SOA provides a whole new set of challenges in terms of performance and business flexibility and as such a new set of patterns and best practices to deal with these. One of these challenges is that the bottom up enablement of existing legacy applications as services often poses problems as the non functional requirements for these services in an SOA environment change considerably from the requirements when the application was originally created. In the case of the Texas engagement we had a well defined service and a legacy implementation that did not perform. Use the decorator/wrapper pattern I hear your shout and you would be right. This was the start of what was to become know as the requester side caching pattern. The requester side caching pattern can decorate an interface or service on the requester side with caching capabilities to significantly improve performance.


The requester side caching pattern was applied to the client of the underperforming service, and the non function requirements were satisfied. In my last blog entry I talked about a pattern specification and a pattern implementation. Here is the pattern specification for the requester side caching pattern. An implementation of this pattern using the Rational Software Architect pattern engine will be made available as a Reusable Asset Specification (RAS) asset on the developerWorks RAS repository and a supporting developerWorks article showing how to use this pattern will be also be published within the next couple of weeks. This developerWorks article will be part of the series on Building SOA Applications with reusable assets The requester side caching pattern is testament to the vision of the original Gang of Four Design Patterns. These patterns come up repeatedly in different contexts to help us understand and formulate new best practices for an ever changing IT landscape.