The Trouble With Orchestration
Good luck with the fish.
The "SOA" concept has been around since I started working in the trade 24 years back. The principle stumbling block I have observed is that if you make the Data and Business Services reusable, then they must be non-contextual and low function. This has several knock-on effects. First the intelligence of the transaction is driven to the Orchestration layer, which is the only level that knows the context of the transaction and the meaning of events within the transaction. All transaction logic, relational edits and data locks must be maintained at the Orchestration layer. This produces performance problems, deadly embrace and data corruption, as the Orchestration layer has to make multiple calls to multiple services and hold data locks over an extended period of time. Concurrency issues are crippling. These are the issues at the heart of why SOA is of questionable utility.
Also consider that re-use is the primary cost justification for SOA. Surveys reporting the most optimistic levels of re-use (and organizations that just made massive investment in a concept will always rate the results of that investment as positively as possible) claim 10% to 40% re-use. That's not much return on investment, now is it?
Third, like all Objet D'art styles, one generally ends up breaking out business functions into atomic services. This process is often difficult, and has to be re-visited constantly, as the granularity of the service doesn't map to the business definition of a transaction. The first change order affecting a widely used service can pull down the entire edifice.
Fourth, the internal and external security issues of SOA are very disturbing. Function re-use too often leads to people having access to data they don't need and should not see.
It's all very well to say that internal reviews will catch these issues, but in reality it is too easy for say, Hospital Housekeeping staff, tapped into the ADT system for room cleaning purposes, to end up viewing confidential patient records. The lack of context at the Service and Data levels also makes it easier for external hacks to take advantage of those data services once past the walls.
Last, let us speak again of dismal performance. The additional overhead inherent in the multiple messaging required to pull the various bits of the transaction together, and the addition of a text-based parser in the SOAP/XML scheme cannot help but add to that.
This is not to say that there are no applications that would benefit from the SOA version of orchestration; rather that we cannot assume that this is any more of a magic wand solution than CORBA, TUXEDO or DAF were.
Biting the hand that feeds IT
