SOA Service Composition – Does it Work in Practice?

One of the main SOA service design principles is Service Composability principle
(https://en.wikipedia.org/wiki/Service_composability_principle).

The idea is that by composing new services using existing ones as building blocks, one
can rapidly develop new services. Kind of analogously to how you call exising methods
of objects when you implement new methods. This is where much of productivity boost from SOA is supposed to come from.

Does someone really do this in practice? I have seen this repeated endlessly in written
text, but have not experienced working real world implementations myself. Most of the
text also omits any mention of transaction handling, which seems to me to be the
biggest obstacle in realizing composable services.

First, you really do need to tackle the transactions problem before you can compose any
non-trivial services. Sure, if the example has services "findCurrentTime()" and
"writeLogMessage()" its easy to not worry about transactions, but not when having real
world examples such as "depositMoney()" and "withdrawMoney()".

I know of two options:

1. Implement real transactions with WS-Atomic Transaction or such
2. Implement compensation-based solution which compensates call to A with "cancelA()"
   or somesuch if call to B fails

Both of these seem very problematic / close to unusable to me:

• WS-Atomic Transaction
  • a lot of complexity, most advice that I found just warns "pain in the ass, dont
    do it"
  • support is limited, for example if you take open source ESBs, main alternatives
    ServiceMix, Mule or WSO2 do not support it
• compensations
  • implementing the handling of compensations seems very complex to me. What do we do if service A
    succeeds and we never get an answer from service B and do not know if it failed or
    succeeded? Handling such logic manually (as implementor of compositing services) makes
    me want to slit my wrists – this is the kind of work some tool should do for me!.
  • I also dont see how you can have compensation methods in non-trivial services. Say
    your service A is "depositMoney()" and that succeeds, some other action quickly
    transfers the money elsewhere, and then we receive "compensateDepositMoney()", what do
    we do now? Seems like a big can of worms.

To me it seems that service composition is such a fundamental SOA principle that you
really do not get the benefits of SOA if you cannot (conveniently) compose services.
What's the reality? 90% of SOA users use "criplled SOA" without real service
componsition? Or most users do in fact use service composition and I am exaggerating
the difficulty of it?