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: 
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 :
"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.
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):
Or as Nick Malik summed it:"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.
"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?