Entity Services - Pattern or Anti-pattern?

Arnon:

thanks for this post, this is very informative. An entity service is merely the interface between business processes and the CRUD APIs (I don't want to call them services).

In other words, if you look at any business entity, there is an inherent, enterprise wide state machine that controls the lifecycle of entity instances (a policy for instance goes through the states of quoted, issued, renewed, canceled, suspended...) That logic is independent of the business process in which the entity participate. If you ever hope to enforce this kind of business logic at the enterprise level and give your business analysts the freedom to design business processes, you have to enforce this logic behind the entity service interface not above !

So yes, Entity Services are, IMHO, the keystone of a successful enterprise wide SOA. If you are looking at building your enterprise services at the CRUD level only, you are almost garanteed to do a lot of work for hardly any benefit.

This article characterizes Entity services as "CRUD", and non-CRUD services as not Entity services. Is that a correct interpretation?

I think both REST (where Resources are Entities that can be POST'ed to) and Pat Helland's conception of Entities (distributed message processing agents) are more general than just CRUD.

See Pat Helland's excellent paper referenced from his blog:
Life Beyond Distributed Transaction

John,
The point is that both Thomas Erl (which is a noted SOA author) and Shy Cohen (who was a technical program manager for WCF in MS) and others do seem to define Entity Services in the light of CRUD operations.
I would agree that there is a place for a more coarse grained services which are not defined in terms of CRUD (and maybe occasionally support these operations)- I defined such services in several projects I designed.

However, considering there's enough problem with term overloading, we should probably name these something else :)

Arnon

Arnon,

I agree that more clear definitions would help. Both Thomas Erl and Shy Cohen refer to "business entities" in the quoted sections above.

My interpretation of "business entity" is broader than "data(base) entity", and the the reason that I posted my comment.

Perhaps too much current SOA thinking is driven by a false belief that services can't both be Entity based and have rich behavior.

My understanding of REST with uniform URI identification leads easily to endpoints being entities (resources) at whatever granularity is appropriate.

Thanks,
John

Jean-Jacques:

I totally agree with you.

I think there is a semantic mismatch between the pro & anti entity services guys.

If by "CRUD/Entity services", someone means straight database insert/select/update/delete with just a "service" exposing an SQL/API statement, the anti Entity Services are right.
But if the "CRUD Entity services" is CRUD with business rules validations/business object lifecycle management, this a reusable asset for the whole IT architecture, and in fact, it is the only way to achieve a successful SOA approach.
To exclude the old database meaning of "CRUD", I think it will be better to call this a "Business CRUD" to imply the BO lifecycle.
By reusable Business CRUD, I'm thinking about services like "create order","update customer address", etc... These kind of service are CRUD but in a Business Object meaning, not a database meaning.

This kind of "Business CRUD" is perfect to be managed by what we call MDM systems. (Master Data Management).

Best Regards,
Vincent Poncet
udsi.wordpress.com/

Most people I find talking about SAO have the technological aspects in mind. Very few use terms like BO not only in the sense of coars grained objects but really in the sense of business.

My experience is, that the small but very important difference between business and non-business is easily overseen and as CRUD has a long technological background in real life, "Business CRUD" might easily become the excuse to expose data-object via services. I already here programmers saying "but in our database we have the customers ..." without realizing that the underlying IMS-DB is badly structured and only one of a lot of concurrent partner systems in a complex company. And these programmers convince their project leads project managers. An the project managers - as the talk about "Business ..." have no problems with SOA-evangelist in the ivory towers.

Thus "Business CRUD" seems to me like an wide and open door to let techies expose their datastructures. It's better to try to keep this door closed.

Best regards

Martin Prischmann

Vincent:

merci... some more ideas:

a) I found this very old link (1999) from a group of visionaries who taught me a lot, www.jeffsutherland.org/papers/boa_pap.html

In the mid 90s the OMG had developed the BOCA (Business Object Component Architecture) which, to me, equates

b) I also wish that Praxeme (www.praxeme.fr) be translated in English because it would certainly shed some light in this debate. Do you know if this is in the works?

c) At the end of the day, nobody nobody should be talking about a "service" if the consumer needs to know and implements business rules related to the entity itself. It would be like sending a letter using the post office but having to reserve the trucks, the planes, the boats, the mailman,... to effectively mail the letter. A letter has a very simple state machine, created, mailed, received, lost. The interactions with the "sending service" should be reflecting that particular state machine not the machinery behind the process of sending a letter. This is exactly the same for any business object.

JJ-

Jean-Jacques :

a) Interesting to see that the idea of an Enterprise IT build upon Business Objects is not new. On this subject, the best I read are the Chris Partridge's research. Have a look on www.boroprogram.org and his book www.amazon.co.uk/exec/obidos/ASIN/0955060303

b) I'm not aware of an English translation of praxeme methodology.

c) I think that the word "service" has no meaning in itself. If all SOA stuff is based on this empty concept, we will build a new kind of spagghetti-like IT systems, sure we will not have any silo'ed applications, but we will have silo'ed "services". What a mess...
If we would like to build sustainable IT systems, we have to build it upon Business concepts (Business Process, Business Object) and not upon IT technical concepts (service, component, ...)

Vincent.

Vincent:

I entirely agree with your point c). However, one must create a development platform based on a strong formalism that support these business concepts. Over the last 10 years, I have seen pretty much anyone but the platform vendor create their own formalism and associated runtime engine to be able to work at the business level. This may be coming (slowly) but what a waste in the mean time. Even a framework like Spring which is targeting at simplifying J2EE development remains far and away from introducing business concepts in the framework.

See this post on the topic - mine.

blogs.ittoolbox.com/eai/business/archives/soa-d...