During the last couple of years I have been reading that CRUD (Create, Read, Update, Delete) interfaces is bad design for services in SOA. For example have Ron Jacobs published it as an anti-pattern in his article "Principles of Service Design: Service Patterns and Anti-Patterns".

Yesterday Pablo (aka Cibrax) wrote a post about the subject, "CRUD Interface for a Service - Is a bad practice?", where he disagree about CRUD being a bad practice. Of course he, as I and I believe all that has comment so far, agree on Ron's anti-pattern since it is an example of extremely bad design, not only for services, but for all cross application domain interfaces.

The focus when designing service interfaces that is part of a SOA must be to support the business processes. The business process, has activities and it this activities that our service interface must support. If we have an activity that is called "Modify Customer", than I will have a ModifyCustomer in my service interface. In the activity there are requirements for what information that is required and that will demand my message(s) structure. Of course this is somehow simplified, but my main point here is that the business processes and activities must be supported by the service interfaces. I might even go so far that, if you do not have modeled the processes you can't create services that will be part of a SOA. Of course you can use services for any system as a way of doing out-of-process communication, but that is not the same as having services in a SOA.