Java Reference
In-Depth Information
As a distributed cache, EHCache maintains stores on disk and in memory and can replicate
data to listeners, as well as invalidate stale data. It has a number of extensions that allow it to
support advanced performance improvement facilities such as ZIP compression and caching
of JSPs and servlets. EHCache allows you to programmatically create a cache manager object
that is responsible for conducting the CRUD business of the cache and for coordinating work
among its constituent caches.
In its upcoming version, EHCache supports both SOAP and RESTful web services, as well
as SOAP security specifications and the WS-I Basic Profile. Under the hood, the EHCache
server edition uses Glassfish.
When you push updates to the cache, interested services (such as Invoice) can reference the
distributed cache. There are a couple of trade-offs though. First, you will need to have a lot
of storage capacity, and you could waste processing cycles and consume network resources
pushing updates that may never be read.
You might also use a timer (such as the EJB
TimedObject
interface) to perform a cache update
in the middle of the night. The update could be pushed from the service of record (in this ex-
ample, the Customer service) out to a distributed cache that referring services use. Or, if each
referring service maintains its own cache, it can pull the data into its local database or cache
structure. The advantage to this approach is that it's simple. The disadvantages are many, and
include the inability to get updates outside the pre-set schedule. It might work for some brick-
and-mortar retailers, but it is not effective for global organizations operating 24/7.
It's important to keep in mind that the cached copy is nothing more than that, and that the real
service of record must always remain the true manager of its data. Perhaps more importantly,
you must not undermine the authority of the service of record by going in any back doors.
This issue is a reality in modern organizations. A developer who knows the location of the
“real” data (and has been accessing it that way for years) may be reluctant to go through the
front door of your web service interface and incur the attendant overhead. This is dangerous,
and you must take steps to lock down your data store or record set to ensure that your service
of record is the only custodian of that data.
NOTE
As a general architectural principle, you can also consider data partitioning within your caches to
improve speed. Partition data across date ranges, alphabetic keys, by function, group, or whatever
makes sense for your dataset.
