Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

enter image description here

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?

share|improve this question

1 Answer 1

up vote 0 down vote accepted

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.

share|improve this answer
    
Not much discussion so I think I am selecting your answer. I guess service composition works if you put needed amount of effort into it and use proper tools. –  Janne Mattila May 30 '13 at 11:15
    
As a follow-up question I am curious what percentage of SOA implementations do it "properly" and use real service composition? My hunch would be pretty low, like 10%... Am I mistaken? –  Janne Mattila May 30 '13 at 11:17

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.