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:Implement real transactions with WS-Atomic Transaction or suchImplement compensation-based solution which compensates call to A with cancelA() or somesuch if call to B failsBoth of these seem very problematic / close to unusable to me:WS-Atomic Transactiona lot of complexity, most advice that I found just warns pain in the ass, dont do itsupport is limited, for example if you take open source ESBs, main alternatives ServiceMix, Mule or WSO2 do not support itcompensationsimplementing 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? 
Does SOA service composition actually work in practice?
web services;soa;transaction
The short answer is Yes!I have seen this done at several large financial organisations, and, it has worked well.The transaction issues are complex but usually handled by (expensive) middleware such as Oracles WebLogic EAI or IBMs Websphere ESB. 