Service Patterns and Data

I was alerted to this interesting article titled "Incorporating Enterprise Data into SOA" by a colleague and wanted to pass it along.

What I find interesting is that in our services implementation here we've built a mix of the first two patterns he discusses.

Aligning Enterprise Data Support with the Business Services. Here, our business services (meaning service operations) define and implement the rules for data validation and encapsulate the storing and retrieving particular sets of data albeit with the help of a set of "manager" classes that we use to decouple the data access logic from our EDAF implementation. This is most clearly evidenced in our service contracts by the fact that our "select" request schemas include the concept of "zones". Essentially, the long term data architecture at Compassion calls for data to be distributed in a series of zones ranging from OLTP to data warehouse cubes with the appropriate aging and flattening of the data as it flows through the zones.

To support this we created a schema that is a simple enumeration of zones and that can be included as an optional attribute in the envelope for service request schemas like so:


<xs:attribute ref="ds:DataStore" use="optional" />


Service consumers then set the zone accordingly and it is up to the service operation both to interpret the zone and retrieve the data from the appropriate location (perhaps even using different data access mechanisms). Clearly, here is a case where our business services know alot about our enterprise data.

Enterprise Data Access as a business service. Here some of the service operations we've built can be thought of as CRUD operations albeit with higher granularity thereby not falling into the "anti-pattern" category he mentions. For example, service operations such as LocateNeed which selects available children for sponsoring based on a set of rules and criteria, and QueryPaymentRelationshipSummary which summarizes and returns sets of monetary relationships between Compassion and our constituents are clearly well-aligned with business functionality.

That said, the tension between these two is what has led the schemas we developed to be in some cases too tightly bound to the existing enterprise data model. In a perfect world it would have been nice to work with a re-designed enterprise data model and to build a pure data services layer (enterprise data bus) on top of that which incorporates the concept of zones, validation, and entity aggregation that the more business oriented services would interact with.