How To Kill A SOA Project - Or What Questions To Ask First Your Client

SOA focusses on business and customer needs - what is a good thing. However it becomes often too expensive, or hard to estimate. The problem is seldom the technology - and always business, organizational issues and politics. Things, which cannot be fixed with any technology. There are some technical challenges, which can be derived from the distribution, reuse and orchestration. The following facts have impact not only to the technology, but especially for business - and can make your customer no more so excited about the SOA approach:

  1. A once deployed service (e.g. WSDL, Java interface, WADL, IIOP etc.) cannot be changed any more. Every change breaks all clients (potentially from other departments). In some protocols - even minor interface changes can break the contract. So, what is the strategy for the release management?
  2. Because a service cannot be changed - new copies (versions) of slightly changed service have to be deployed. So, how many versions of one service your department like to maintain?
  3. Monolithic services are orchestrated inside one process in a local transaction - now they are distributed - and distributed (XA, 2PC) transactions are needed. Does it really work?
  4. The robustness of the whole systems becomes as good, as the weakest service. Can your customer live with that?
  5. You have to live with partial failure - this problem was unknown so far in monolithic silos. How to deal with it from the business perspective?
  6. It is hard to find a semantically valuable service, which is interesting enough to different departments. Business Domain Objects like "Customer", "Invoice", or even "Address" are different concepts for each department. So will the service be actually reused at the end?
  7. The abstractions and distributions and TX coordinations do cost performance - synchronous transactions becomes asynchronous, or have to be split to many fine transactions coordinated by the end-user. Is your client ready to change the already existing process to adapt SOA?

Funny thing - at the beginning of the most SOA projects - no one want to hear such questions - it is much easier to concentrate on the technology, and forget about business :-). In case the customer already invested in tools and infrastructure - he want to be successful and just start to implement. Inconvenient questions are always problematic :-). I forgot some points for sure (this post was very spontaneous) - what's your experience with SOA? In my opinion, most of successfull projects are "just" EAI integration of existing, legacy stuff - so only few of this points have to be considered in such a case...

[See also Persistent Domain Object, page 90+ and Pragmatic Java EE Architecture, Page 253+ in the book "Real World Java EE Patterns"]


Adam, Your remarks on SOA are very true.

However some problems can be solved by the usage of a mediation and routing platform.

Gregor Hohpe gives some nice receipes on how to achieve this in his Book on Enterprise Integration patterns.
In practice the patterns can be realized with an Enterprise Service Bus (ESBs).

Regarding Your points:

1.& 2. Usage of message translations allows several facades fullfilling different contracts in front of one common service implementation.

This appears to be more manageable than parallel deployment of versions (which is essentially code Duplication).
In this case You still modify production Software (the single Service Implementation) on a regular base - so You will be lost without a Test Driven Approach.

3.Distributed transactions are as bad for SOA architectures as using Remote Interfaces without need is for EJB architectures.
Instead of this Compensation actions have to be defined from a business perspective.

4. Service invocations should be asynchronous, robust with guranteed delivery. At his point Your caller service is uncoupled from the called service's availability.

In my experience customers think that expensive vendor stacks have solved any technical problems.
And buying licences solves their problems.
This illusion leads to unfulfillable expectations to the project members.

It is sad truth, that there a mostly EAI projects.
Sucessful SOA projects should have much more value to the customer.

Posted by Ralf Sigmund on May 29, 2008 at 02:03 PM CEST #

Hi Ralf,

it seems like you had similar experiences in the past :-). You are right about the patterns. The problems is: compensative transactions actually do not work - the undo refers only to one level - nested transactions cannot be rolled back. The customer has to define compensative transactions *in addition* to non-SOA approach. In general he is not really happy about his fact...
Thank you for your comment!,


Posted by Adam Bien on May 30, 2008 at 02:06 AM CEST #

WS-BusinessActivity spec basically defines a version of the "open nested" transaction protocol, in which nested transactions can commit without the parent committing. If the parent rolls back, the committed subtransactions invoke a compensation action. The user defines the compensation action but WS-BA provides the hook to invoke it on rollback of the parent.

This is also intended to complement BPEL. Sure WebSphere 6.1 supports WS-BA but I agree with these concerns.

So what do you think about this? My advice: use the Atomikos TCC (Try-Confirm/Cancel) paradigm if you want really reliable and compensation-based web services. It is faster, better and leads to real business-level consistency across service invocations.

Posted by Delivante on June 11, 2008 at 04:22 AM CEST #


What is the best practice you would take with this additional programmatic work of defining compensative transactions while creating separate boundries of concern regarding the non-SOA approach? BPEL directly supports compensation, yes. I agree that knowing what you are getting into under the hood with XA 2PC is critical but worth the cost. What about the fact that XA JDBC drivers are typically inefficient compared to non-XA JDBC drivers and BEA WebLogic LRO (Last Resource Option) at

What do you think about Response to Gregor on transactions at (bottom)

Posted by Delivante on June 11, 2008 at 04:23 AM CEST #

The short-lived atomic transaction protocol in SOA does not need to concern with resource management at the web service level. Instead, it should be
modeled as an extension to the existing platform-specific two-phase commit transaction support infrastructure, in particular to the Resource Managers that already exist within Java EE, .NET, and CORBA environments, to name a few
examples. Perhaps web service transaction management components should not require changes to fundamental transaction processing system artifacts, but that they do require the underlying system to expose a minimal Resource Manager interface, in order to operate the two-phase commit protocol. Too bad "WS-BusinessActivity protocol will be available in the near future."

Posted by Delivante on June 11, 2008 at 04:39 AM CEST #

Hi Adam,

Very good points indeed. Just a question: what do you mean by 'undo refers only to one level'?

I can't speak for other systems, but ours (Atomikos ExtremeTransactions) does provide compensation of the whole nested subtransaction tree...

It would be interesting to exchange views some time. Feel free to email me.


Posted by Guy Pardon on February 12, 2009 at 09:24 AM CET #

Hi all,

interesting aspects. I'm just new to SOA, but already facing some very important questions. Distributed transactions (XA) are fine if the timeframe between the service calls is very short, but in real live it can be days or weeks. What happens if somebody else changed the data which must be "rolled back" from a compensation service. Though, the compensation service maybe must be aware of quit a lot constellations ...
can be very complex ...


Posted by ChristofMueller on March 25, 2009 at 02:12 PM CET #

Post a Comment:
  • HTML Syntax: NOT allowed
...the last 150 posts
...the last 10 comments