Today it would not raise many eye-brows if I said that an application server need not necessarily be a physical standalone entity or process and can actually be “assembled” from a set of available frameworks. Thanks to frameworks like Spring and standards like OSGi (and containers supporting it), this can be realized and not remain just on paper.

How about an ESB? The picture that most of us have seen (and reproduced in this post : Myth of the ESB ) appear to imply this big central infrastructure that acts as a conduit for all integration and message based interactions within an enterprise.

How easy or difficult is it to realize such a deployment in an organization? I have worked on SOA for a few years and more recently on deploying ESB as an infrastructure component in a SOA. Not once in these cases have we done such a deployment. Why? The answer is simple – most organizations take an incremental approach to SOA adoption and not all existing applications are amenable for migrating their business logic as services and thereafter accessed via an ESB.

Does this mean an ESB is only a promise? No, if you care to see it a little differently. I’ll go back to my earlier example of an application server. In the world of light-weight containers, components and dynamically loaded modules, the application server can be seen as a set of capabilities realized through an integrated set of components,frameworks,libraries and a runtime. The advantage here is that one can use as much of the application server as is needed.

If I were to apply the same analogy to an ESB, the first question that comes to my mind is – what are the capabilities of an ESB (or) what can an ESB provide to an application? IBM puts it nicely (and using a nice term) by defining a “Capability Model” in their Redbook on “Implementing an SOA using an ESB”. This capability model, for me, also serves as a good yard stick to measure an ESB offering – sort of a self compliance check.

A gist of the capability model is listed below:

  • Communication : Routing, Addressing, Response / request, Publish / subscribe, Sync/Async e.t.c
  • Service Interaction: Service interface definition(WSDL), Substitution of service
    implementation, Service directory and discovery
  • Integration : Database, Legacy and application adapters, Service mapping, Protocol transformation
  • Quality of Service : Transactions, assured delivery
  • Security : Authentication, Authorization, Security standards
  • Service Level : Performance, Throughput, Availability
  • Message Processing : Content-based logic, Message and data
    transformations, Validation
  • Management and Autonomic : Administration capability, Logging, Metering, Monitoring
  • Modeling : Object modeling, Common business object models
  • Infrastructure Intelligence : Business rules, Policy driven behavior

Now thats a huge list of capabilities and you may not need all of them – again like in an application server, you may not need JNDI, JTA, JMS and an EJB container all at once. However you can integrate these capabilities when needed. Can you do the same for an ESB? Yes, you can. Its a different post altogether how one can do that. One might ask this question : but why take the trouble?

The answers come from the cost of deployment, the set of features truly available in the fancy ESBs and the flexibility of actually using an ESB’s features but within your own runtime process. There are quite a few light-weight ESBs that help you do this. If you carefully look at the features in these ESBs, you’ll notice that they fall short of the Capability Model in more ways than one. This is true for the commercial ESBs as well. The lack of standards adds to the disconnect. In the meanwhile, considering an ESB as a logical set of capabilities and using it that way puts many things into perspective – including the value of an ESB in a SOA.