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.

Comments

• Anonymous
  March 05, 2005
  The comment has been removed
• Anonymous
  March 05, 2005
  Hey Michael,
  
  I probably don't need to tell you this but just in case...
  
  Have you read Pat Helland's views on a similar topic? MSDN article "Data on the outside vs Data on the Inside"?
  
  http://msdn.microsoft.com/architecture/overview/default.aspx?pull=/library/en-us/dnbda/html/dataoutsideinside.asp
  
  .savas.
• Anonymous
  March 06, 2005
  If I understand what you're saying, I must disagree most vehemently. You say that sharing data between services violates the principle of service autonomy. I'm not sure if you mean sharing instances of business entities, sharing a common information architecture or having multiple services depend on a single entity service, but none of those necessarily violate service autonomy (indeed, I would argue that the first two are almost required for an SOA).
  
  Autonomy is not sovereignty, or, to paraphrase John Donne, no service is an island, entire of itself; every service is a piece of the continent, a part of the main. The connection a service has to the larger system is embodied primarily in the business entities that it accepts as input or produces as output. Despite the limitations of our current toolsets (especially WSDL), the service doesn't own its messages the way an RPC method owns its parameters or an object owns its members. As often as not, these business entities will be processed by other services in the system. Without a common understanding of those entities, there is no system. Now, this is not to say that there is necessarily some overarching enterprise information model that completely defines all the entities within the system, merely that a service and its clients (which often include other services) must have a shared understanding of the business entities. It would be odd indeed if this shared understanding didn't frequently span multiple services. The enforcement of this shared understanding will vary from architecture to architecture based on the actual needs of the business, not slavish acceptance of a set of SOA rules.
  
  SOA is not some academic theory or abstract conceptual framework for building distributed systems. Rather it's a set of patterns that grew out of solving real problems. The true power of service orientation is that it models both the way businesses work and the way distributed systems work at the same time. If you see "many cases" which seem to violate your mental model of how service orientation works, you need to consider whether your mental model has it right. While I agree that an entity is more than just data, I think it is a serious mistake to think that what is added is logic. It is more helpful to think of your business entities as documents (an idea that's only hard to explain to geeks, normal folks don't have any trouble thinking of a purchase order or a customer record as a document). Business logic, constraints, validation and consistency checking is the domain of a service, not an entity. This is not a recipe for disaster; rather it is a recipe for success with 4000+ year track record.
  
• Anonymous
  March 07, 2005
  Couple of comments.
  Re Pats paper, yes I have read it and it covers a part of my second paragraph (data inside). I dindt bother with talkign about data on the outside which is mainly about transmission of data in messages and how 2pc accross services is a bad idea because I thought that was pretty obvious. The case I was talking about is where data is used by mutiple services not as a message.
  
  Re sharing data, I agree that all three cases you talk about are part of SOA and do not violate autonomy. It all depends where you are defining autonomy, at a service level things are autonomous above that level they are not. I agree with what you are saying about how you should view and use SOA. I am talking about a level lower than SOA but higher than a service.. a sort of SO level, where you do need to share data. I dont say you should add logic, in fact I dont think you should any more than I think you should have business logic in a SP. I do think there is some "entity" infromation required which is similar to your document analogy, a document contains both data and information about how to use that data.
  As I said I am not sure what that entity checking and validation look like I am not sure, I agree it is not busienss logic or validation (that is the domain of a service) or data logic and validation (that is the domain of the database). Its something in between.
• Anonymous
  March 07, 2005
  Not sure what exactly you mean by "entity services" but I assume that these are the lowest level services available to access a persistent data store. The scope of such a service should match some "logical unit of work" i.e. an operation that leaves the data in a consistent state. This (probably) would involve more than one data entity in order to maintain referential integrity. Sitting above these services are higher level services that represent business procedures e.g. "Establish new customer account" which may update multiple data stores. And sitting above that are business processes e.g. "Acquire new customer" with defined flows, exceptions and escalations.
  
  The important thing about LUW services is that they must all respect the semantic integrity of the data. This is the prerequisite for data sharing of any kind. What they are not is simple CRUD instructions e.g. Create Customer. That is why I think the term "entity service" may be misleading.
• Anonymous
  March 07, 2005
  Yes, yes yes!! I dont like entity service as a term, it's a Microsoft one and I think misleading however I dont really have another name for what is being described.
  I really like the old LUW thinking / terminology rather than CRUD because it matches much better the granularity of services.
  You have given a great example of exactly what I was thinking and saved me having to pummell the old brain cells. It's really great to be able to tie it back to a old principle like LUW too. Thanks!
• Anonymous
  March 17, 2005
  The comment has been removed