The big software vendors use the term – Service Registry synonymously with SOA Governance. In the process they inadvertently confuse a reader into thinking that setting up a Service Registry can ensure SOA Governance. I wrote an article on this subject that got published here :


Mention SOA or Services and most of your audience would immediately relate it to web-services – yes, the often un-intented misuse of XML over Http that gives the technology and anything related to it a bad name in the world of high-performance J2EE applications.

Two of the biggest culprits in loss of Performance are I/O and Transformation overheads. Web services has both these drawbacks – increased data transfer i.e higher I/O associated with markup overhead of well-formed XML and the CPU utilization overhead when converting XML to Java and back aka. Marshalling.

Web-services and its implementation of XML over Http is good when it is genuinely needed. For e.g. exposing services for consumption with partner organizations where consuming technologies are not known or for integration between disparate systems.  However often this need for integration unfortunately leads people to stereotype services as web-services in a SOA. 

The question then is : can we reap the benefits of SOA and not suffer the drawbacks of the overheads inherent in web-services? I believe, we can.

Quite a while back, I read this excellent IBM Redbook : Implementing SOA using ESB where the author recommends deploying a B2B Gateway external to the ESB. I must admit it didnot make much sense to me then. I have come to appreciate it much better these days. A B2B Gateway enables consumption of services by “third-party” . This “third-party” may be a client from a different technology platform or from an altogether different organization.

A separate B2B gateway introduces the possibility of:

  • Making the web-service channel independent of the service implementation and therefore a matter of choice to use (and therefore suffer) the XML over Http interface
  • Introducing the much required security standards(and implementations) for securing services and data managed by the services
  • Using third party implementations that specialize in implementing WS-* policies
  • Using hardware to augment the processing capability provided by software frameworks – e.g. XML appliances

The SOA runtime therefore must enable services to be written independently of XML and the WS-* specifications/constraints.  The Web-service interface  is then an optional channel , via a B2B Gateway, to invoke the services. 

We, at MindTree, have taken this design further in our implementation of Momentum – an SOA based delivery Platform. Interfaces like JMS and web-services are optional channels provided by the Framework to invoke any deployed service. A schematic that explains this approach is shown below:


Request flow to a Service from different channels

The web-service interface is therefore an optional means to invoke your service when you separate the service container and the ESB(optional) from the B2B Gateway and deploy the latter as a separate infrastructure.  You can then benefit from the good of web-services without compromising on your service’s QoS.

Myth of the ESB?

September 14, 2007

Many in the industry consider SOA as hype and ESB as another, both related, nonetheless. Is it a hype or a matter of failure of understanding? Agreed the hype is fostered by promises of either(or both) being a panacea for all your systems woes.

Lets get to simple descriptions of the two entities : SOA is an architectural approach and a methodology while the ESB is a pattern/logical group of capabilities that are employed to realize the SOA. This means that you are unlikely to find the ultimate SOA/ESB product that addresses all your architectural concerns, no matter what the product vendor says. I am sure all of us have seen the SOA triad of provider, client and broker depicted like below:

SOA - triad of provider, consumer and broker

Also you would have seen the ESB “silver bullet” depicted as below :


Before I go further, let me clarify that I am a great fan of SOA and the ESB. I have employed both and seen clients benefit from it.

The title of this post was suggested by a client project manager, who along with his organization – a large airline, was entirely sold out on SOA and a commercial ESB offering. It took a 3 month consulting assignment to establish the Why and How of SOA and determine what an ESB could provide.

I will first list a few busted myths about SOA and ESB, in no particular order:

  • Writing a few web services does not mean you have embraced SOA
  • SOA is not an IT initiative alone and involves Business and Operations just as much.
  • Neither SOA or ESB are silver bullets for your organization and not everything can/must be a service.
  • Service reuse does not always translate to using the service in a hosted mode.
  • Web services are not the only way to implement services in a SOA.
  • There is a big difference between Process Orchestration(BPM through BPEL) and Service Orchestration aka Composite Services(an invocation like Service A –> Service B –> Service C within a shared context say transaction or process).
  • ESB provides certain infrastructure for your SOA. On a case-by-case basis you would still need the following: Service Container, Service Registry, Service Repository, Service Orchestration.

Do all of the above erode away the promise of SOA and an ESB? The answer is “no”. The key is to clearly establish your SOA adoption (see my post Methodology for SOA Adoption ) and use a capability model(see IBM redbook on “Implementing an SOA using an ESB”) to evaluate the need and features of an ESB. You will then see that pictures like the ones above are not myths but reality.