SOA presents a particular difficulty for determining ownership of data. A service must be able to not only manage but to truly own the data that it represents, or chaos will ensue. But an enterprise will frequently define services that must share common data such as customers, products, and so forth. How can this be managed?
As you define your architecture, differentiate between services that own objects, and services that reference objects owned by other services. Depending on the context, you may need to use caching techniques or subscription patterns to handle updates to the data.
Every service must be self-sufficient and must be defined as being totally in control of its own data. It is clearly preferable to never use data across business domains, as doing so can destroy the loose coupling SOA attempts to achieve. In the real world, however, our business domains sometimes do not match our data definitions as purely as we might like, especially when we’re dealing with large companies with lots of opportunities for legacy modernization. You must make sure that a service only references data from other domains so that only one single domain is ever in control of a given business object.
In your SOA, you have a
CustomerDataService. This service represents the data for a fundamental aspect of your enterprise, and it can participate in many business processes or composite services. It will be used in a variety ...