Data or entity Services

One of the biggest problems I have with designing SOA systems is the area of data services or entity services as Microsoft calls them. The snag is that in many cases the data has to used by multiple services and so you really want to share the data between services which breaks autonomy.

Thinking about this I realized that data is used in services in two different ways: The first one is where it is just used by that service and so autonomy is not broken. The second is where the data is used by multiple services and so becomes a service entity where autonomy is broken.

In this case you need to think of the entity as more than just data but data and some associated logic such as validation and consistency checking for multiple services.

The way I think of this is the difference between a straight database and a database with stored procs. A straight database is used by a service, a database with stored procs is a data entity. Today the SP’s do data checking and validation for the data layer of a three tier architecture; in a entity service the code does entity checking and validation for the SOA.

Quite what the details of this entity checking and validation look like I am not sure but it will definitely include entity state validation and service rules checking…

Now autonomy is broken within the entity but not at the entity service level and so all is well with our services model once again. IMHO we must not break autonomy at the services level; this is a recipe for disaster. It is just architectural laziness.