Entity Services - Pattern or Anti-pattern?

| by Arnon Rotem-Gal-Oz Follow 1 Followers on Jun 11, 2007. Estimated reading time: 3 minutes |
Entity Services or  business-centric entities are considered by some to be a corner stone of Service Oriented Architecture - however not everyone agrees with this view. So are Entity Services a pattern or an anti-pattern for SOA? Last month, Shy Cohen, in an article called "Ontology and Taxonomy of Services in a Service Oriented Architecture" Defined Entity Services as follows:
"Entity Services unlock and surface the business entities in the system. They can be thought of as the data-centric components ("nouns") of the business process: employee, customer, sales order, and so on. Examples of Entity Services include a customers service that manages the customers' information, or an orders service that manages the orders that customers placed."
Shy Also wrote that:
"It is very common for Entity Services to support a create, read, update and delete (CRUD) interface at the entity level, and add additional domain-specific operations needed to address the problem-domain and support the application's features and use cases. An example of a domain-specific operation is a customers service that exposes a method called FindCustomerByLocation that can locate a customer's ID given the customer's address."
Thomas Erl (author of the upcoming "SOA: Principles of Service Design" and a few other SOA books) defined Entity Services in a similar fashion:
In just about every enterprise, there will be business model documents that define the organization’s relevant business entities. Examples of business entities include customer, employee, invoice, and claim. The entity service model represents a business-centric service that bases its functional boundary and context on one or more related business entities. It is considered a highly reusable service because it is agnostic to most parent business processes. As a result, a single entity service can be leveraged to automate multiple parent business processes. Entity services are also known as entity-centric business services or business entity services. The figure on the right shows an example of an entity service. Several of its capabilities are reminiscent of traditional CRUD (create, read, update, delete) methods.
It seems however that not everyone agrees with this view. John Evdemon, who like Shy, is also from Microsoft defined CRUD interfaces as an Anti-pattern for SOA :
"CRUD operations are the wrong level of factoring for a Web service. CRUD operations may be implemented within or across services, but should not be exposed to consumers in such a fashion. This is an example of a service that allowed internal (private) capabilities to bleed into the service's public interface."
Also Steve Jones (Author of "Entrprise SOA Adoption strategies", published here in InfoQ) put it rather bluntly when he talked about CRUD in general and concluded that "CRUD is CRAP" Recently,  Nick Malik, Jack Van Hoof  and Udi Dahan also debated the issue of Entity Services and they came to the conclusion that (from Udi's blog):

"Entity Services are in the Application Architecture domain. They are not a member of the Services which are the primary unit of decomposition of SOA.

An SOA Service may be implemented using Entity Services, or not. If so, those Entity Services are not allowed to be accessed outside that SOA Service’s boundary. As such, they are an implementation detail of SOA. In which case we can have very interesting discussions about the relative value of Entity Services over things like the Domain Model Pattern.

Or as Nick Malik summed it:
"So, is an Entity service an antipattern?  From the enterprise perspective, yes.  From the application perspective, no.  (these are not in conflict).  I guess it depends on where you stand."
Nevertheless, there's also the point of service granularity -  even in the application level. Services which are too fine grained would violate few of the "8 fallacies of distributed computing" and as Peter Deutsch said when he defined them:
[when you make the false assumptions] "All prove to be false in the long run and all cause big trouble and painful learning experiences."
What do you think?

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

An Entity Service is not at the CRUD level by Jean-Jacques Dubray


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.

Thoughts and link to Pat Helland's blog by John Heintz

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

Re: Thoughts and link to Pat Helland's blog by Arnon Rotem-Gal-Oz

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 :)


Re: Thoughts and link to Pat Helland's blog by John Heintz


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.


Re: An Entity Service is not at the CRUD level by vincent poncet


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

Re: Business CRUD excuse to service-enable Data-Object? by Martin Prischmann

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

Re: An Entity Service is not at the CRUD level by Jean-Jacques Dubray


merci... some more ideas:

a) I found this very old link (1999) from a group of visionaries who taught me a lot,

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

b) I also wish that Praxeme ( 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.


Re: An Entity Service is not at the CRUD level by vincent poncet

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 and his book

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, ...)


Re: An Entity Service is not at the CRUD level by Jean-Jacques Dubray


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.

Re: An Entity Service is not at the CRUD level by Eric Roch

See this post on the topic - mine.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

10 Discuss