Featured White Papers

• Java Web Hosting | DailyRazor.com - Over 10yrs Of Java Web Hosting Exp!

Sponsored Links

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Cache SOAP services on the client side

Design patterns let you cache SOAP services and improve performance

By Ozakil Azim and Araf Karsh Hamid, JavaWorld.com, 03/08/02

The Web services revolution has started. New standards and technologies enable and integrate distributed Web services. SOAP (Simple Object Access Protocol), an XML RPC (remote procedure call)/messaging protocol, underlies it all. Simple by name, simple by definition, and simple to use, SOAP lets you request a service using simple XML and receive a simple XML response.

SOAP is proving its mettle in the enterprise application space. Developers employ the protocol to integrate disparate enterprise applications, and to develop new distributed and scalable enterprise applications that use XML for cross-component messaging.

SOAP's creators, in their desire for simplicity, deliberately did not build a complex distributed object model; they left that difficult task to the application developer. However, SOAP's simplicity means a simple SOAP implementation in an enterprise application will be stateless and could fall prey to performance issues. Indeed, repeated SOAP-client calls to access server state can choke a network.

In response, we describe transparent client-side caching for SOAP services using the Business Delegate and Cache Management design patterns, and offer an implementation that completely hides from the client application the lookup, invocation, and caching of Web services. Moreover, we introduce a mechanism for automatic client-cache synchronization with the SOAP service provider.

We assume you have familiarity with SOAP installation and service deployment. We do not detail how SOAP works or how to make it work. See Resources for references to Websites where you can find more information.

Note: You can download this article's complete source code in Resources.

The problem: Web services in an application world

When developing rich Java clients with SOAP-based servers as data providers, you must address three main issues: performance, performance, and performance.

If your client application accesses the same information repeatedly from the server, you'll quickly realize the server's performance, and consequently your application's response time, is not fast enough. Further, when hundreds of client applications hit the server simultaneously, the performance degrades even faster. That's when you remember the lesson from client/server databases development: thou shalt always cache locally! Invoking a SOAP call produces costs similar to running an SQL statement in a relational database; maybe even more so. Indeed, a database likely gets accessed whenever a SOAP call is made. So a SOAP call's cost includes network latency, CPU cycles at the SOAP server, and SQL latency at the database server.

A problem, however, with caching locally: the cache might become inconsistent with the original data source; changes made to the SOAP server after the cache loads go unreflected in the cache (read inconsistency), and changes made to the cache go unreflected at SOAP server (write inconsistency).

The problem domain: stock transactions

Because the problem proves a little complex, we offer an example that highlights the need for fast response without requiring you to learn a new problem domain.