Thought Leader: Sean McGrath

Sean McGrath opines on Transactions and SOA. In his post, he offers a guideline for scoping services that ties in to some of the earlier posts that I have been writing, and affords me a chance to go off a bit more. He says:

Systems that have ACID semantics make perfectly good services to expose on an SOA. Like any paradigm, one of the skills of service decomposition is knowing when to stop. A temporal coupling boundary (such as a classic ACID) is a good place to stop.

FWIW, This advice works well not just for web services but also for rpc and distributed objects.

I have seen several systems that on the surface appear to be doing the RightThang (tm), in that they are developing with the latest and greatest technologies and platfoms, e.g. J2EE or .NET, they are following iterative and incremental development processes, and all of their application interfaces are exposed via web services.

The problem is that they didn't know when to say when, and that led to basically a massive collection of CRUD-oriented interfaces on top of entity/domain class concepts, i.e. there ends up being a service per entity, say, for example, Employee, and the operations are basically CreateEmployee, SaveEmployee, FindEmployee, DeleteEmployee. The service should be defined at a business semantic that expresses a sense of acheiving a user/business goal. For the Employee example, for example, business operations might be Hire, Terminate, Promote, etc. The Hire operation, in addition to saving the employee information in the HR database, could provision a new laptop, establish the user's domain account and assign them the appropriate role based on their position, and send out a welcome email.

It is very typical that most of the aforementioned problems are systemic in the development process, in that the use cases are too fine grained and do not address goals as much as functions. This is the appropriate point to once again reference Cockburn's Structuring Use Cases with Goals.