Note that there are some explanatory texts on larger screens.

plurals
  1. POSOA: Reasons why emulating an ESB behaviour in code, for sure, is the worse option
    text
    copied!<p>We have an SOA based project which has been built from the ground up as a webservice layer to a well established application. </p> <pre> ClientA --> ClientB --> ESB --> Atomic Services --> Established App (DB/NAS etc) ClientC --> </pre> <p>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:</p> <pre class="lang-py prettyprint-override"> 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 </pre> <p>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:</p> <ul> <li>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.</li> <li>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.</li> <li>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.</li> </ul> <p>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. </p> <p>I guess this would look like this:</p> <pre> ClientA --> ComposingServiceA --> ClientB --> ComposingServiceB --> Atomic Services --> App ClientC --> ComposingServiceC --> </pre> <p>However, reading on here I found an unreferenced statement as follows:</p> <blockquote> emulating an ESB behaviour in code, for sure, is the worse option </blockquote> <p>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?</p> <p>Why is emulating an ESB behaviour in code, for sure, the worst option?</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload