1.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.

2.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.

PURE-PLAY ESB. Before we drop into the ESB implementation model, it is important to differentiate the pure-play ESB from an ESB built on top of EAI solutions or application servers. ESBs built from the ground up have inherent flexibility and cost benefits over the second group.

A pure-play ESB is a lightweight solution with selectively deployable components, configurable into an ESB peer network. (See Illustration 2.) Because you can tailor the deployment of integration services only to the ESB peers that will use them, the ESB has a small footprint (lightweight). Application servers and EAI solutions have fixed and heavy deployment stacks, requiring a good deal of CPU and memory to achieve service levels.
Because of the ESB’s peer network, you can isolate heavy processing (such as XSLT transformation) with a peer on a powerful machine, while keeping light tasks (such as routing and service invocation) on machines with less power or less available capacity. Not only does this optimize capacity, it also prevents a particular integration task from adversely impacting the performance of all integration scenarios. In a hub solution, such as EAI, the entire infrastructure needs to be sized to handle the largest task, even if that task runs infrequently. In addition, the hub model, if not sized and configured properly, can cause bottlenecks when a heavy processing task is underway.

ESB IMPLEMENTATION MODEL. The following discussion refers to Illustration 2. As you can see, the ESB is a network of ESB peers, with a unified management console. All ESB components (peers and management) connect using a messaging backbone. The messaging backbone is the messaging infrastructure that came with the ESB or, better yet, your own existing enterprise message backbone. To avoid having a single point, each ESB peer has a local cache for service, peer, and interaction metadata. For ease, the metadata are administered centrally and then deployed to the local cache at the peers. While the ESB components do offer quality of service for failover, performance, and scale, you also need to configure the messaging backbone to avoid bottlenecks and a single point of failure.

Looking at the peers, on ESB Peer 1, there is an integrated resource—a packaged or legacy application—using an adapter. On ESB Peer 2, there are two integrated resources—a database using an adapter and a J2EE application component using a standard protocol. On ESB Peer 3, there aren’t any integrated resources; this peer is in place to perform a heavy integration service such as XSLT transformation (as mentioned above). An integration scenario could be completely fulfilled on one peer or could flow across all three peers, starting as a request from the application attached to Peer 1, routing to Peer 3 for data translation, and lastly routing to Peer 2 to both invoke the java component (a message-driven bean) and insert a record in a database.
The peer network configuration and service deployment will vary based on your implementation environment and the customer scenarios you are trying to fulfill. These integration design decisions are critical, and we recommend using skilled integrators that understand your business and your portfolios (application, service, information, infrastructure, and architecture) to ensure the integration does not adversely affect your production environment.

3.Is the ESB Here to Stay?

Since nothing in IT but basic computing principles and architectures*1 are truly here to stay, the question is really “Is ESB a flash in the pan?” Does ESB solve a temporary problem? Or are the basic principles and architecture of the ESB sustainable, therefore making an ESB an important (and wise) investment? The considerations here pertain to Web Services: How pervasive will Web Services be? And if Web Services are the future, how far out are we talking? And what (if anything) should we do in the interim to bridge the current and future?

4.DOES WS-* OBVIATE INTEGRATION SOLUTIONS

There is a group of WS-*2 purists who say that, when the full complement of Web Services specifications are mature and the supporting technology is incorporated in all technology platforms and applications, the need for an intermediary integration infrastructure will be obviated. Every platform, application, and software component will have native integration support via Web Service technology.

OK, we can almost buy that—except for three points: First, we can’t help but think this fully baked-in Web Service enablement is at least five years out. That’s a long time to sit on the sidelines and wait.
Second, our legacies tend to stay around forever. The majority of enterprises are running applications and infrastructures that are at least a decade old; most enterprises have systems that are two decades old. So, while in theory all new assets will be fully integrated and integrate-able, there will still be some other “stuff” in the enterprise mix.
Third, even assuming WS-* clears up the technical issues (security, management, orchestration, interoperability, etc.) and all new platforms are fully Web Service enabled, there is still a huge integration problem to be solved—that of semantics. We still need to define and agree upon the naming, meaning, and classification/taxonomies of the resources (services, application, information) and businesses we are trying to bring together. Until semantics are resolved, there will always be the need for intermediaries to do interpretation, translation, and transformation. So WS-* only as the integration answer is at least five years out for companies without legacy systems and semantic incompatibles; it’s longer still for mere mortals.

5.IS SOA FABRIC THE ANSWER?

SOA fabric is a new name for the combination of a Web Services platform and a Web Services management environment. In 2002 and 2003, Susan Aldrich covered this space extensively for the Patricia Seybold Group under the then-moniker, “Web Services backplane.”*3

Essentially, in an SOA fabric, intermediary (agent) services are employed to perform the routing, transformation, security, and management tasks required for effective implementation of an enterprise-scale SOA. The intermediaries intercept requests (messages) as they traverse between client (consumer) and service (producer). The SOA fabric consists of intermediaries, registry, and policy components. The intermediaries are deployed in the Web Service execution environment, in the J2EE or .Net container. The underlying assumption in SOA fabric is that all services participating in the SOA are Web Services.

SOA fabric is best suited to composite application development—the first SOA style, which has primarily synchronous interactions. While some SOA fabric vendors are starting to implement asynchronous support to comply with the WS-Rel* specs,*4 many more are advertising their ability to integrate with ESBs to support integration and the second SOA style: event-driven/process-driven SOA.

6.ESB IS HERE TO STAY, BUT IT WILL EVOLVE?

While there are overlapping functions between ESB and SOA fabric, we believe these technologies are more complements than competitors. Many organizations will use SOA fabric as the backbone for composite application development while connecting to an ESB as the backbone for integration and event-driven/process-driven SOA.
Over the next three to five years, we expect to see coalescing of some of the technology components supporting fabric and ESB. This will be great, because how many messaging infrastructures, registries, repositories, and management tools does an organization really need? Since both technologies have service-oriented underpinnings with standards-based interfaces, any changes to the underlying implementations (if done correctly) should be non-invasive to the consumers.

7.CHOOSE WISELY—CHOOSE FOR YOUR BUSINESS?

So our recommendation is to support your business now, solving the particular infrastructure problem(s) you have on hand in the most standards-based manner possible. If your first priority is integration or event-driven/process-driven SOA, start with an ESB. If your first priority is composite application development, investigate portals for the user interaction layer and, depending on your architectural preference (HTTP, messaging) and service catalog (Web Services or non-Web Services), either SOA fabrics or ESB for service interaction.

In the long run, you may end up with all three product sets—ESB, SOA fabric, and portals—all of which have their place in your enterprise architecture and our networked integration environment. The most important thing is that you pick what is right for your business, based on your initiatives, current environment, architectural principles, skills, and risk tolerance. As always, you should pick standards over proprietary, pick sustainable vendors, and keep an eye on the industry, because change is constant—which, we suppose, is another way of saying, “Integration is inevitable!”

8.SUMMARY AND NEXT STEPS?

Given the architecture and functions of the ESB, we believe that there is a strong match to provide the backbone services of the networked integration environment. The ESB supports both enterprise integration and the “integration inside” that is present in today’s (and tomorrow’s) event-driven, process-based, service-oriented business solutions. Of course, ESB is relatively new, and there is a lot of activity in the integration and SOA space, so we recommend a thoughtful consideration of solutions. This includes research, hands-on evaluation, and a finalist proof-of-concept run-off.
With the major ESB questions answered and the solid match to the networked integration environment backbone, our next step is to assist in your evaluation process. We will start by evaluating the pure-play ESB offerings. In addition to the ESB evaluations, we will continue to provide related research and insights into the other ten points of the IT integration strategy for customer experience.
Finally, as part of our SOA and Web Services research, we will be watching the activities in the SOA fabric, Web Services platform, and Web Services management spaces for the implications to both enterprise integration and service-oriented architecture.

• For example, SOA and Web Services are just the latest incarnation of RPC technology in a loosely coupled architecture.
• WS-* (pronounced “splat”) is the shorthand moniker for the collection of standards/protocols that fall under the Web Services umbrella. These standards include (but are not limited to): WS-I (SOAP, UDDI, WSDL), WS-Addressing, WS-Security, WS-Rel*, WS-Notification, WS-Policy, WSDM, etc.
• To review Sue Aldrich’s Web Services backplane research, please go to our SOA and Web Services Landing page (http://www.psgroup.com/research_webserv.aspx). For an introduction to the backplane, see “Web Services Backplane: Infrastructure for Web Services,” by Susan E. Aldrich, January 2, 2003, http://dx.doi.org/ 10.1571/LA1-2-03CC.
• WS-ReliableMessaging and WS-Reliability are two (overlapping) Web Services specifications that describe how to use SOAP over a reliable, asynchronous transport, such as message-oriented middleware (MOM).

9.?

10.?

11.?

12.?

13.?

14.?

15.?

16.?

17.?

18.?

19.?

20.?