Discipline & Punish SOA

On the "Disciple and Punish" blog, I ran into an interesting entry: Revisiting the Battle of Abstractions". For starters, I really like the rising acceptance I see of messaging in SOA. Not only at the transport level, messaging as a top-level communication paradigm is (finally) getting traction.

[Originally posted here]

What interests me, though, is that REpresentational State Transfer keeps getting compared to SOA. It's like comparing apples and types of pies. Yes, there maybe an type of pie which is an apple pie, which cannot be made without apples, but I don't think that that warrants talking about apples at the same level as pies.

Things like DDD which I see jiving very well with SOA don't do so well with REST. In REST terms, an Order may be a resource. In which case, a Customer would be a different resource. How then would business rules like cancelling an order line, causing a decrease in overall order cost, causing a decrease in customer orders for the quarter, causing the customer to lose the "preferred" status, be handled? How would this change be propogated to the caller of the original resource without some notification mechanism? Seeing as REST is (by its most vocal proponents) an HTTP only deal, who is in charge of handling reliable messaging - application-level code?

I'm willing to accept that REST is a valid choice for certain types of applications, however I think that a lot of difficult questions need to be answered before REST can be used in mission-critical systems.

Posted by Udi Dahan at 05:45 PM  Permalink