Thursday, November 22, 2007



There is complete census that CRUD is Anti-SOA pattern

Simon thinks that one can think of CRUD as business events rather than service operations

Maarten Mullender’s says to take the best of both worlds. Use CRUD interfaces for service when concurrent updates can be avoided because
1. Updates are seldom, or
2. Updates have only one source (person or system)

Ramkumar Kothandaraman writes
If one of the services fails to handle the CRUD request, then the EA service should be able to handle this business exception. One of the mechanisms to handle a business exception involves executing a flow that compensates for prior activities.
A Business Analyst usually determines Compensation Logic. Compensation Logic can be either automated or manual. For example, a compensation action may involve alerting the monitoring facility when one of the services returns a business exception, leading to a manual resolution.

My thoughts
There are going to be CRUD operation even for a SOA scoped Application. Best way of writing optimum CRUD operations is to visualizing a client talking to a service rather than a traditional RPC application.
Service APIs will be designed or dictated by client application and it is responsibilty of client to submit bulk CRUD operation with concise payload. It is responsibility of client to make sure that it has correct state.

1 comment:

Anonymous said...

There are two levels of CRUD. One is database level, one is REST level. Facade or higher layer should expose coarse grained APIS (I still use "API", I do not really care RPC or not, the real thing is granularity, not what name we give to them); however, I also believe that you never know when you need to expose a few fine grained API, so be prepared to wrap it anytime!

REST level CRUD is that a web service is always about a "resource", so, CRUD is it the CRUD of that "resource" (not a database record). I feel it is a very good concept, and if we accept REST, the "official" SOA must be modified :-)