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.
Question 5: 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?
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.
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.
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.
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!”
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.
*1 For example, SOA and Web Services are just the latest incarnation of RPC technology in a loosely coupled architecture.
*2 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.
*3 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/
*4 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).
About the Author
Brenda Michelson is an IT strategist, hands-on practitioner, and the voice of business-driven architecture. Brenda’s day job is principal consultant for Elemental Links. Brenda also contributes architecturally to the Patricia Seybold Group. Brenda spent 19 years in corporate IT, most recently as Chief Enterprise Architect for L.L. Bean. At L.L. Bean, Brenda was responsible for the articulation and execution of the enterprise architecture strategy (J2EE transformation, enterprise integration, SOA and EDA), strategic planning, portfolio management and talent development. Previous to L.L. Bean, over the span of 10 years, Brenda provided development services for Insurance, Banking, a Chip Manufacturer and a world leader in Aircraft Engine Design & Manufacturing. Email Brenda.More by Brenda M. Michelson
About Elemental Links
Elemental Links is an IT consulting and advisory practice specializing in strategy, architecture, and portfolio planning for business-driven IT.