What is the recommended approach to transactions given a SOA edge app?
For example, my usual approach to updating Items in a list would end up calling the dataportal update call on each item to be updated. In my SOA scenario this would result in discreet calls to the updateItem service. To date I've always been accessing a database, not a service, from the dataportal and it's been simple to wrap the entire set of updates in a transaction. What has been people's approach to this in a SOA edge world?
This ties into one of my favorite stories (includes a little poetic license).
Around 1999 I was in an advisory meeting with Microsoft, along with around 50 other external people. They asked if we'd be interested in a technology that allowed us to make object/method calls over port 80 - unlike DCOM that required hundreds of open firewall ports. But this technology wouldn't offer the security/transactional features of DCOM.
48 of 50 people raised their hands enthusiastically. The other 2 people looked grumpy, because they needed the security/transactional features of DCOM.
Of course the question was in relation to what became SOAP.
Those 2 grumpy people represented a small, but influential set of Microsoft customers. They wanted SOAP, but needed it to do all the DCOM stuff too. So they lobbied to create the WS-* specifications.
The result is that SOAP isn't simple or accessible anymore, because it has all the horrific complexity of DCOM - just with XML.
So the 48 people have been giving up on SOAP and moving to REST. Although REST has inferior tooling and is generally harder to use than the original SOAP, it is infinitely easier to use than the post-WS-* SOAP.
If I may, without intending offense, you must be one of the 2 people that helped ruin SOAP :)
Thanks for the reply and the amusing back story. I guess this makes me a 4%-er...
After further discussions with the team we are evaluating whether or not we actually need transactions, there is a consensus building that we may not. Especially since we are developing both the service and the edge app.
The real answer is that in a true SOA world you use something called "compensating transactions".
Traditional transactions are extremely tightly coupled. SOA is all about being loosely coupled. Therefore the two concepts are like oil and water, and they don't (and shouldn't) mix.
Compensating transactions are loosely coupled, and thus fit into the SOA world very naturally. Unfortunately, they usually also tie into business processes, and are therefore more complex than the simple yes/no of a low-level ACID transaction.
Copyright (c) Marimer LLC