Question

Our client follows SOA principles and have design web services that are very fine grained like createCustomer, deleteCustomer, etc.

I am not sure if fine grained services are desirable as they create transactional related issues. for e.g. if a business requirement is every Customer must have a Address when it’s created. So in this case, the presentation component will invoke createCustomer first and then createAddress. The services internally use simple JDBC to update the respective tables in db. As a service is invoked by external component, it has not way of fulfilling transactional requirement here i.e. if createAddress fails, createCustomer operation must be rolledback.

I guess, one of the approach to deal with this is to either design course grained services (that creates a Customer and associated Address in one single JDBC transaction) or
perhaps simple create a reversing service (deleteCustomer) that simply reverses the action of createCustomer.

any suggestions. thanks

Answer 1

The short answer: services should be designed for the convenience of the service client. If the client is told “call this, then cdon’t forget to call that” you’re making their lives too difficult. There should be a coarse-grained service.

A long answer: Can a Customer reasonably be entered with no Address? So we call

createCustomer( stuff but no address)

and the result is a valid (if maybe not ideal) state for a customer. Later we call

changeCustomerAddress ( customerId, Address)

and now the persisted customer is more useful.

In this scenario the API is just fine. The key point is that the system’s integrity does not depend upon the client code “remembering” to do something, in this case to add the address. However, more likely we don’t want a customer in the system without an address in which case I see it as the service’s responsibility to ensure that this happens, and to give the caller the fewest possibilities of getting it wrong.

I would see a coarse-grained createCompleteCustomer() method as by far the best way to go – this allows the service provider to solve the problem once rather then require every client programmer to implement the logic.

Alternatives:

a). There are web Services specs for Atomic Transactions and major vendors do support these specs. In principle you could actually implement using fine-grained methods and true transactions. Practically, I think you enter a world of complexity when you go down this route.

b). A stateful interface (work, work, commit) as mentioned by @mtreit. Generally speaking statefulness either adds complexity or obstructs scalability. Where does the service hold the intermediate state? If in memeory, then we require affinity to a particular service instance and hence introduce scaling and reliability problems. If in some State or Work-in-progress database then we have significant additional implementation complexity.