Java Reference
In-Depth Information
If the Invoice service maintains a copy of the customer data, it must duplicate the update ef-
forts of the Customer service, effectively undermining the point of your SOA.
So you cannot have the customer data stored in 2 or 3 or 17 places, as the Customer service
would lose its credibility as the owner of that data. It cannot manage what it does not have a
view into. Moreover, inventing a clever way to have the Customer service reach into each of
the local data stores of the referencing services to manage the customer data they have “bor-
rowed” is brittle, unmaintainable, and clearly does not support the agility concerns that SOA
aims to address.
The naive solution would appear to be this: simply have the Invoice service go out to the Cus-
tomer service every time it needs any information regarding customers. The Invoice service
stores only an identifier, and not a full copy, reducing the record management problem. In this
case, you don't have two competing services that both own the customer record; instead, you
have the Invoice service only referencing the data that the Customer service owns. This is a
common solution in a number of environments, but it does not cleanly and wholly address the
problem at hand within a SOA. For example, what happens to the Invoice pointer if a custom-
er is deleted? This creates instability and invalidates the Invoice service without anyone being
aware of it.
Moreover, this introduces an altogether different kind of problem: accumulated network
latency. Having a variety of composite services reference such core services as Customer In-
formation can create undue or unanticipated load. This can have a ripple effect that slows
down services across domains.
So the crux of the problem is this: the Invoice service (which does not own but only references
the data managed by the Customer service) must be able to use customer data flexibly and
must have up-to-date information, but not be allowed to sink beneath the weight of the con-
siderable latency involved in constantly invoking the Customer service every time it needs a
small slice of information.
Happily, there are some reasonable ways of dealing with this issue.
Timed caches and distributed caches
An obvious but perfectly reasonable solution to this problem is to have the referencing service
obtain a copy of the data from the owned service and treat the records as it would any other
cached data. So the data is not a first-class citizen within the referencing application.
One way to handle this is to use a distributed caching mechanism. In Java, you can try
EHCache, which is available from
http://ehcache.sourceforge.net
under an Apache license.
The current version as of this writing is 1.5.0.
