Udi On SOA (Part 2)
Udi, continuing the SOA discussion, suggests a solution to the transaction issue:
The client would generate an instance of the appropriate message class as the user finishes each sub-task, saving them up. When the user would click “confirm”, the client would send all these message objects to the server in one go with this API,
void IBus.Send(params IMessage[] messages);
Like so:
myBus.Send(addOrderLineMsg, delOrderLineMsg);
The bus would take all these objects and wrap them in a single SOAP envelope, and send them to the server, probably on a transactional channel, but that’s a configuration issue. At the server side, the bus would activate the transaction (because of the transactional channel) and start dispatching each of the specific messages to its message handler, one at a time, in the same thread.
So as you can see, there is no “transactional conversation”, and therefore we’re not locking tables in between calls, because we’ve gotten rid of “in between”. It’s just like the generic update in terms of transaction time and network hops, just with specific, simple business logic. [1]
While this sounds good in theory, this approach itself doesn't really solve any special problems. In fact, without a proper service oriented architecture and messages that are constructed based on tasks instead of CRUD operations, you will end up in the same boat as if you hadn't implemented this approach. For example, take the situation where your app needs to preform a read and modify it's data based on the results of that read (say, for instance, discounts on a shopping cart). If you continued to code your methods the same old way, you might have a call to get the discounts, then apply those discounts and save the order. Of course, if you had architected your messages properly, you would have been sending a distinct PlaceOrder message and letting the server do all the discount calculations as those are part of one discreet task. So, while Udi's proposal is an interesting one and solves some transaction issues, it isn't a silver bullet that lets you make the same calls you've always been making and still be SOA. Contrary to popular belief, simply passing your data in a message doesn't make your application service oriented.
[1] http://udidahan.weblogs.us/2007/03/31/tasks-messages-transactions-%e2%80%93-the-holy-trinity/