<<The relationship between service and data is one of those design-points addressed early on in SOA projects, usually as part of the initial analysis phases. Services are conduits for data but also establish boundaries that represent bodies of related information. How these boundaries are defined can communicate an abstracted view of the data to consumers, but this view is usually not representative of how the data is actually structured on the back-end.
When we drill down into service architectures, we will usually find that the layer of data abstraction provided by services is underpinned by another layer of data abstraction established by a separate schema architecture. And below that layer is the actual physical implementation of (often proprietary) data models. What's often overlooked among these layers are the schemas. Many service designers allow schemas to become skewed in support of the service layer, but there is a real opportunity to build a data architecture that is fully capable of facilitating individual services (usually through shared schemas) but can also be used outside of the service layer by other parts of the enterprise that can benefit from its usually uniform, abstracted view of enterprise-wide data.>> You can read this at: http://www.soamag.com/ Gervas
