SOA: Reasons why emulating an ESB behaviour in code, for sure, is the worse option

Question

We have an SOA based project which has been built from the ground up as a webservice layer to a well established application.

ClientA -->                       
ClientB -->    ESB   -->   Atomic Services  -->   Established App (DB/NAS etc)
ClientC -->    

We have several scenarios where a service provided by the ESB is composed of multiple atomic calls called in sequence with interactions, such that logically they do something like this:

def composing_service(xmlrequest):
    output_of_decision_service = decision_service(xmlrequest)
    if (output_of_decision_service.matches("foo")):
        xmlresult = foo_service(xmlrequest)
    if (output_of_decision_service.matches("bar")):
        xmlresult = bar_service(xmlrequest)
    return xmlresult    

In fact this logic has been implemented using XSLT transforms and XPath queries build into the ESB implementation we have bought. This seems problematic to me for a few reasons:

• Developers can't test the composing services (simple functionality from business perspective) locally as the ESB implmentation is too "heavy" to be deployed locally. Overall testing is an integration activity.
• The XSLT syntax used to form these and similar control blocks are not as readable or accessible as code in a general programming language. (if ... then, else finally etc.) The XSLT has got very long and intimidating.
• In certain complex scenarios more fine grained control would be beneficial, i.e. compensating for failed calls by calling a compensating atomic service to roll back an earlier action.

I guess after a year working on the project I feel as if the notion of decomposing the application functionality into atomic services is a good one. However I often feel as if I'd prefer to implement the composing webservices in a plain old programming language like Java.

I guess this would look like this:

ClientA -->    ComposingServiceA     -->                   
ClientB -->    ComposingServiceB     -->   Atomic Services  -->   App
ClientC -->    ComposingServiceC     -->

However, reading on here I found an unreferenced statement as follows:

emulating an ESB behaviour in code, for sure, is the worse option

Sadly this was left as a blind statement of fact (opinion) with no supporting reasons. However it got me rattled. Why could the above be true? I was ready to draft an email to our architect voicing all the concerns above, but this comment makes me wonder if I should?

Why is emulating an ESB behaviour in code, for sure, the worst option?

Answer 1

Not knowing the full context of the statement makes it difficult to comment, however if they meant trying to implement your own ESB from scratch, then yes I would have to agree. ESBs are sufficiently complex that you don't want try try to roll your own.

In terms of the architecture, your are right to want to decompose into "Composing" services. This is called service layering and typically results in three layers. Your atomic services correspond to entity layer services or utility later services, which are business process agnostic and generally quite reusable. Your composing services normally correspond to task layer services, which compose other services, are related to a specific business process and are generally not as re-usable.