References:
1. http://haacked.com/archive/2006/08/09/ASP.NETSupervisingControllerModelViewPresenterFromSchematicToUnitTestsToCode.aspx
2.
http://www.jpboodhoo.com/blog/AnswersToSomeGoodQuestions.aspx
3. http://blog.vuscode.com/malovicn/archive/2007/02/04/tdd-rhino-mocks-part-1-introduction.aspx
4. Rhino Mock Documentation
Sunday, November 25, 2007
Thursday, November 22, 2007
SOA and CRUD
SOA and CRUD
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
http://www-128.ibm.com/developerworks/blogs/page/johnston?entry=crud_vs_business_operations_events
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)
http://blogs.msdn.com/maarten_mullender/archive/2004/07/23/193524.aspx
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.
http://msdn2.microsoft.com/en-us/library/ms954596.aspx
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.
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
http://www-128.ibm.com/developerworks/blogs/page/johnston?entry=crud_vs_business_operations_events
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)
http://blogs.msdn.com/maarten_mullender/archive/2004/07/23/193524.aspx
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.
http://msdn2.microsoft.com/en-us/library/ms954596.aspx
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.
Subscribe to:
Posts (Atom)