The basic question which turning around is whether ESB suppose to be a PROTOCOL independent?
Considering webMethods Servicenet, it will accept only Webservice otherwise; it needs some other Mediation Layer such as EAI to receive or send the request / response.
When we say ESB as an router or a delegator between �Consumer Service� and �Provider Service�, if any mainframe system (or some other legacy system which will not support Webservice) would like to act as a Consumer Service (considering that we will not use any Neon RTE in between), then it cannot talk to ESB so called Servicenet. On these grounds, can we say that an ESB layer suppose to be a PROTOCOL independent where it will accept all the requests iresspective of protocol and process?
At this point of time I do not want to talk / discuss about Transformation / Translation in ESB as I feel it is not the piece of cake of ESB.
I don’t think ESB’s are designed to be protocol independent. Most I have seen rely on SOAP over HTTP, SOAP over JMS and some REST style. Legacy integration is still the realm of EAI vendors when you need protocol specific adapters that are not consider standard in the new Web Services world.
ESB’s specialize in intelligent routing, some transformation and protocol conversion but usually limited to the aforementioned protocols. They have strong service’s slant as opposed to an Integration viewpoint.
The concept of an ESB was born out of the SOA push. The dominant protocols in the SOA world are SOAP over HTTP and SOAP over JMS. Most EAI vendors have layered their existing products with the additional functionality provided by an ESB. I believe the intent by these vendors, webMethods in particular, is to use their core Integration Suite along with Infravio now (Servicenet is bye bye) to achieve the promise of an ESB.
The latest versions of CICS support Web Services, don’t know if you have look at that yet. Check IBM’s web site for more details.
One could argue that wM already had an ESB–Integration Server.
One could also argue (and I think wM has) that Broker and its adapters comprise a so-called “ESB.”
The definition of ESB seems to vary, depending on whom is doing the defining. Here’s one that claims ESB is “an extension of EAI” that adds transformation, “portability” (which they say is the ability to “share data between different computer systems an operating environments”), load balancing/clustering, and failover. I have to ask, how were those “extensions” not a part of “earlier form of middleware” called “EAI”?
This article quotes the Gartner definition of ESB, which in my mind describes many of the products that have been on the market for years. The Gartner definition allows for an ESB to be protocol independent–“Many ESBs also support other communication styles [in addition to web services] that involve guaranteed delivery and publish-and-subscribe; those that don’t soon will.” So, generically, an ESB can be protocol independent–a specific product might not be protocol independent but would still be considered to be an “ESB.”
If we forget about the hype and hooey of all the TLA’s, including EAI, B2B, ESB, SOA, LOL, etc. and the nonsense of whether or not something is a “true” this or that, then we can focus on an integration layer that supports various protocols, formats and such, probably using multiple toolsets and technologies.
Focus on creating an integration architecture and infrastructure that supports what your enterprise needs, using the best-fit tools out there. If one focuses solely on whether or not a tool is an “ESB”, there is a risk of making erroneous assumptions about whether or not the tool has specific functionality that may be needed.