Question 2: Is an ESB an Architecture or a Product?

A big question in the ESB space is, “Is an ESB an architecture or a product?” On the surface, this question seems a little strange, because we would contend that all products, especially ones as critical as application infrastructure, should be designed and implemented from an architectural blueprint. So, at a first pass, we say “both.” But the underlying point here is that some large vendors (IBM for one) that have integration and application infrastructure solutions (but not distinct enterprise service bus solutions) are saying that the ESB is an architecture, or design pattern, from which an end user can assemble an ESB, using his current application infrastructure and integration products. While this is true an end user can roll his own, the question then becomes, “Does that make sense?” Only the individual organization can answer that, considering its current investments, initiatives, skills, and risk tolerances. For the majority of organizations, the answer will be “no,” especially if production-quality ESB solutions are readily available.

So, as a general statement, we say that an ESB is a product, which evolves from an architecture.

Question 3: What Are the ESB Features and Functions?

There seems to be general agreement on what an ESB should do. In Table A, we list the basic and optional features and functions of an ESB. As you can see, the features and functions have a strong correlation to the backbone services of the networked integration environment, which is why we believe the ESB is a good candidate to realize the NIE.

What there isn’t strong agreement on is how an ESB should provide these features/functions. We’ll look at this in Question 4.

Question 4: What Does the ESB Look Like?

INSIDE THE BOX OF AN ESB. Assuming an ESB is a product, based on an ESB architecture, when you “open the box” of an ESB, you would find integration tooling, a management console, service containers (ESB peer), and integration services.

There are however, variations in what else you might find in your ESB. The variations relate to messaging infrastructure implementation, protocol support, adapters, and exposure of ESB services, as follows:

• Messaging Infrastructure. An ESB may be tied to its own messaging infrastructure (MOM), or it may provide adapters (JMS or WS-Rel*) to run any of the more popular messaging infrastructures (WebSphere MQ, MSMQ, Tibco Rendezvous).
• Protocol Support. An ESB may be single protocol or multiprotocol. This refers to “how you get on the bus.” For example, most single-protocol ESBs require a WS-SOAP interface, but if you send a “plain” XML message using JMS, an adapter translates the incoming message to SOAP to participate on the bus. In a multiprotocol ESB, varieties of protocols (WS-SOAP, JMS, JCA, etc.) natively interact with the bus, without employing an adapter.
• Adapters. As with any integration solution, the collection of adapters (protocol bridges) supplied by the ESB vendor varies. The adapters will also depend on the protocol support, as mentioned above.
• Exposure of ESB Services. Some ESBs expose their underlying services, for integration or management, as services for consumption outside of the ESB solution set. This facilitates remote management and reuse of integration services.