Enterprise Service Bus: Web Services Meet Message-Oriented Middleware
Posted on: Sunday, 23 April 2006, 03:02 CDT
By Kobielus, James
ESB is the hot new term in middleware. Network managers need to prepare for how it will affect traffic flows and integration efforts.
Enterprise service bus (ESB) is a new term for an old ideal. Generally, ESB refers to a universal middleware environment that supports simple, speedy, standards-based integration across heterogeneous network application environments. Some say the ESB ideal is well within our reach, due to the widespread adoption of Web services standards. Others say it's a pipe dream, and that it glosses over the stubbornly complex challenges of real-world integration.
ESB is an architectural concept, but it's more than just a middleware field of dreams. It also refers to a growing segment of the integration software market that addresses the intersection of message-oriented middleware (MOM) and Web services. ESB vendors include both middleware providers-such as Fiorano Software, Iona, PolarLake, Sonic Software, Tibco Software and webMethods-and platform vendors such as IBM, BEA, Oracle and Sun.
In addition, Microsoft will provide ESB capabilities in the Windows Communications Foundation functionality of its forthcoming Windows Vista and "Longhorn" operating environments, though Microsoft distances itself publicly from the term "ESB" (see "Microsoft WCF: Eooks, Walks And Quacks Like An ESB").
We're also seeing the rise of ESB open-source projects, including Apache Synapse, Celtix and ServiceMix, all of which leverage an emerging standard: Java Business Integration (JBI, aka JSR 208-see "Open Source Commoditizing ESB," p.32).
ESB: Why Network Managers Should Care
From a network manager's point of view, ESB products will grow in importance, as platforms for shaping and controlling traffic flows at the application layer become more important. ESB environments provide more content-aware trafficrouting flexibility than traditional hub-and-spoke middleware environments. But the flip side of that benefit is the potential for more unpredictable, peer-to- peer traffic flows among ESB-enabled application servers and other endpoints.
In spite of this potential for greater complexity of traffic flows, ESB's core value proposition, visa-vis traditional middleware approaches, is the simplification, through additional abstraction, of enterprise software and application integration. ESB products provide an abstraction layer that mediates among old and new computing platforms and middleware environments. An ESB environment offers simplification along several dimensions:
* Unified integration paradigm: ESB products wrap, virtualize and integrate the legacy integration paradigms-such as MOMs, object request brokers (ORBs) and remote procedure calls (RPCs)-within the new paradigms of Web services and service-oriented architecture (SOA- also see this issue, pp. 10-11). Web services refers to a middleware environment-but not the only one-that may integrate across an ESB. SOA refers to a development paradigm that encourages maximum reuse and sharing of functionality across networked platforms, such as through Web services protocols over an ESB.
* Modular integration layers: ESB products allow implementation of as few or as many robust integration services-such as reliable messaging, event notification, publish-and-subscribe, content transformation and orchestration-as appropriate to a particular integration scenario. ESB architectures are modular at all layers, and vendors often package ESB functionality as separate software components that may be deployed in various combinations to address the diverse integration requirements of enterprises and service providers.
* Flexible integration patterns: As noted above, ESB products support flexible messaging patterns, including hub-and-spoke, routed and peerto-peer message flows, within the same integration environment. They support the requestresponse conversational flows associated with SOA, the publish/subscribe flows associated with event-driven architecture, and the method-invocation flows associated with object-invocation environments. And they allow integration architects to implement communication alternatives such as static vs. dynamic object binding; synchronous vs. asynchronous connections; stateless vs. stateful conversations; transacted vs. non-transacted sessions, and reliable vs. best-effort messaging.
* Ubiquitous integration-logic deployment: ESB products usually allow integration components to be deployed at many points in a distributed environment, including endpoints (such as application servers), distributed intermediary nodes (such as content-based routers. WSM agents, message brokers, queue managers, proxy servers) and centrali/cd integration hubs (such as integration brokers and protocol gateways). Often, ESB vendors build their components to be scaled, clustered and failed over, and to provide the ability to monitor and manage integration components remotely from a central console.
* Visual integration models: ESB products provide a visual, intuitive, model-driven interface for development, integration, orchestration, monitoring and management of complex environments.
Core ESB Architecture, Functionality And Standards
But when delving into ESB offerings, let the buyer beware. "ESB" is a trendy marketing buzz phrase that every middleware vendor interprets to its own advantage (see "ESB: A Few Quick Definitions of a Sprawling Abstraction," p. 33).
Increasingly, we're seeing "ESB" used in the brand names of vendors' integration products, such as BEA AquaLogic Service Bus, CapeClear ESB for WebSphere, Fiorano ESB 2006, IBM WebSphere Enterprise Service Bus, Oracle Enterprise Service Bus. Sonic ESB and Sun Java ESB Suite. These and other middleware vendors are also using the term as a catch-all for the re-branding of their entire product portfolios, spanning both legacy and future offerings. Vendors often label older middleware approaches-such as MOM, enterprise application integration (EAI), business process management (BPM). object request brokers (ORBs). remote procedure calls (RPCs) and integration brokers-as components or facets of ESB.
Against this spin-intensive backdrop, it can be difficult to compare and contrast different vendors' ESB offerings on a teature- by-feature basis. Nevertheless, some architectural and functional commonalities pervade the ESB market. Most ESB products support reliable messaging, event notification and publish-and-subscribe (the traditional MOM features). ESB products leverage Web services standards and interface with established reliable-messaging MOM protocols such as IBM WebSphere MQ. Tibco Rendezvous and Sonic Software's SonicMQ.
Common features of ESB products include the ability to bridge heterogeneous MOMs, wrap MOM protocols with Web Services Description Language (WSDL) interfaces, and tunnel Simple Object Access Protocol (SOAP) traffic over MOM transports. Many ESB products also support Web Services Reliable Messaging (WS-RM) and WSNotification, which are widely-adopted industry specifications that enable MOM-like features over native SOAP and HyperText Transfer Protocol (HTTP) transports.
But ESB is much more than "super-MOM." Many ESB solutions also support such critical integration functions as ACID (atomic, consistent, independent, durable) transactions, data transformation, content-based routing, policy-based orchestration, business process management (BPM). business activity monitoring (BAM) and Web Services management (WSM). (For a discussion of WSM. see "New Tools for Web Services Management" in the April 2004 issue of BCR.)
Architecturally, one of the hallmarks of most ESB solutions is messaging-centric integration, which embraces and interfaces older, proprietary MOMs with the emerging world of SOAP-based Web services. In addition, ESB environments are often distinguished from legacy middleware approaches by their superior architectural flexibility, supporting diverse multipoint messaging Hows such as hub-and-spoke. decentralized and peer-topeer with equal agility. By contrast, legacy MOMs primarily support peer-to-peer messaging patterns, while traditional integration brokers-such as Microsoft BizTalk Server- focus on hub-andspoke integration.
Figure 1, p. 34 shows an ESB application-messaging environment's support for flexible messaging patterns, including hub-and-spoke. routed and peer-to-peer (as well as for complex interactions among those patterns).
ESB Vendors Converge From Different Competitive Backgrounds
Vendors are converging on ESB from different middleware market niches. Differentiation and positioning strategies follow several tracks.
Traditional MOM vendors are positioning their message brokering/ queueing offerings as ESB in order to defend their market positions. In particular. IBM. Tibco and Sonic have strong, diversified ESB product portfolios and development road maps. Over the long term, smaller ESB/MOM vendors-such as Fiorano-will find it increasingly difficult to position themselves as viable alternatives to these entrenched competitors. Just supporting WS-* and peer-to-peer messaging may not be enough to distinguish smaller MOM vendors in the ESB market, no matter how stable or reliable their products might be.
Integration broker vendors recognize tha\t ESB's superior messaging flexibility will erode their considerable share of the middleware market. Some integration broker vendors-such as Cape Clear and webMethods-have added flexible ESB messaging patterns to products that have traditionally supported hub-and-spoke integration. However, other integration-broker vendors-such as Fuego, Intalio, Lombardi Software, Savvion, Seagull Software and Ultimus-haven't indicated when or whether they'll integrate decentralized or peer-to-peer messaging into their product architectures.
Traditional ORB vendors have largely migrated toward the ESB model. Iona-one of the bestknown ORB vendors-has made this transition effectively. With its Artix ESB product architecture. Iona is migrating customers' peer-topeer ORB environments (Iona's Orbix technology) toward native support for WS-* and reliable messaging. At the same time, lona's ESB container technology, deployable only on application endpoints, retains backward compatibility with the vendor's Common Object Request Broker (CORBAyinternet Inter-ORB Protocol (HOP) ORBs.
FIGURE 1 ESB Application Messaging Environment
Some SOA application platform vendors (namely IBM, BEA, Oracle and Microsoft) see an opportunity to dominate the middleware market by embedding ESB functionality into their "application endpoints," thereby crowding out thirdparty middleware products (such as message brokers and integration brokers) that operate from intermediary nodes in the network. However, it's not clear when or how other SOA platform vendors-such as SAP and Novell-will add support for ESB message-exchange patterns.
Standards Reducing ESB Vendor Lock-in
ESB functionality-across Windows, Java, Linux and other platforms- leverages the universal interoperability stack: WS-* set of industry standards and specifications.
In recent years, SOA platform vendor support for the MOM- enabling WS-* standards has continued to grow, even though some of the relevant specifications have yet to achieve ratification from OASIS or other standards groups. Increasingly, all platform vendors will need to implement WS-RM in their architectures in order to enable reliable, guaranteed, once-only delivery of SOAP messages over Web services environments. WS-Notification will become the lingua franca of eventdriven middleware architectures. And WS- Transactions will support ACID and long-running transactions over a growing volume of SOAP traffic.
It will take 1-2 years before WS-RM, WSNotification, and WS- Transactions jump several key hurdles, including widespread vendor implementation, published profiling by the Web Services Interoperability (WS-I) Organization, and conformance-group testing for multi-vendor interoperability. Until WS-RM and other ESB protocols are widely adopted, enterprises will continue to rely on traditional MOMs and other established middleware approaches to provide the end-to-end reliable messaging that the WS-* stack (in its current incomplete state) can't yet support.
One consequence of this trend will be continuing reductions in vendor opportunities to lock customers in through proprietary specifications. Vendor-proprietary MOM application programming interfaces (APIs) have already taken a back seat to the common Java API-Java Message Service (JMS). In addition, all ESB vendors provide crossplatform APIs through the ability to wrap proprietary MOMs as Web services via WSDL and SOAP.
Major Platform And Middleware Vendors Will Dominate ESB Market
It's not clear which ESB vendors and platforms will survive the industry's current shakeout. Currently, the ESB market is experiencing a round of mergers and consolidations. The shakeout will continue for the foreseeable future, due both to overcrowding in the market and to the leveling forces of standardization and commoditi/.ation.
One of the most significant recent mergers, in January 2006, involved a pioneering ESB vendor-Sonic Software (an operating unit of Progress Software)-and one of the pioneering WSM vendors: Actional. Sonic clearly saw that WSM tools are critical for end-to- end management of ESBs. WSM provides application-layer tools for planning, optimizing, monitoring and managing ESB traffic flows and quality of service (QOS) throughout enteiprise intranets, B2B supply chains and other integration environments.
However, the merged Sonic/Actional won't be able to compete for long against the SOA platform vendors-especially IBM, BEA. Oracle and Microsoft-who are adding ESB and WSM functionality to their suites at a rapid clip. When the ESB market matures by the end of this decade, ESB pure-play vendors will find their value proposition usurped by platform vendors that have embedded ESB functionality into their offerings.
SOA application platform vendors-such as Microsoft, Oracle, IBM and BEA-are going to dominate the ESB space by the end of this decade. Many SOA platform vendors are embedding ESB functionality more deeply into their environments. They do so in order to address a broader range of integration scenarios, to support their own integration software products and to position their platforms as alternatives to third-party integration software. Clearly. Microsoft's WCF is a bold attempt to push ESB functionality more deeply into current and future versions of Windows.
In the next 2-3 years, the ESB wave may give some platform vendors an advantage over their direct competitors. When Microsoft delivers commercial WCF-and Windows Workflow Foundation (WWF) functionality-in Vista and "Longhorn," the company will be able to position its server and client platforms as ESB-enabled out of the box. Microsoft has also committed to running WCF on pre-"Longhorn" Windows platformsWindows XP and Windows Server 2003-which will further strengthen its ESB and SOA story.
Over the next several years, platform vendors who fail to address ESB functionality in their road maps will marginalize themselves out of the SOA market. Minor platform vendors won't be able to survive in a market that will eventually be dominated by SOA platforms. In order for SOA platform vendors-large and small-to distinguish their commoditized ESB features, they'll have to keep evolving up the functionality stack, adding WSM. dynamic content-based routing, distributed transactions, appliance form factors and other advanced features.
As ESB functionality becomes ubiquitous in application platforms, pure-play ESB middleware vendors will struggle for survival. Today's ESB middleware market segment will fade away, absorbed into the SOA platforms that will dominate all distributed environments. ESB- enabled SOA platforms will dominate, and also accelerate the decline of today's separate ESB middleware market. The rest of this decade will see ongoing acquisitions, mergers and consolidations among platform and middleware vendors. In particular, Sonic, Tibco, Cape Clear, PolarLake and Fiorano. though currently positioned well in the ESB space, won't survive long unless they partner or merge with SOA platform vendors.
As regards WSM functionality, there's little of that in today's ESB market-that's why the merger of Sonic (the ESB pioneer) and Actional (one of the WSM pioneers) is so significant. BEA is also a pioneer in merging ESB and WSM functionality, which it has been doing in its AquaLogic product family since 2005. Increasingly, ESB vendors will layer WSM functionality on their product architectures. It's very likely that other WSM pioneers, such as AmberPoint, will find suitors in the ESB space.
Another likely development is that network appliance vendors- such as Cast Iron Systems, Cisco Systems, F5 Networks and Solace Systems-may reposition their products as high-performance ESB message processing nodes. It remains to be seen whether IBM will integrate appliance technology from DataPower-a WSM vendor that it recently acquired-into its WebSphere ESB product.
Another wild card is networking powerhouse Cisco, which has set its sights on the contentaware network appliance market under its Application-Oriented Networking (AON) strategy. For further information on appliances, see "Exploring Content-Aware Network Appliances" in the December 2005 issue of BCR (also BCR, July 2005. pp. 40-44).
ESB Will Deliver Its Own Blend Of Simplicity And Complexity
ESB is the paradigm tin jour in the middleware arena, promising the simplicity that comes from a unified, modular, flexible, visually-oriented integration environment.
The ESB market is in danger of succumbing to the inflated expectations that grow out of incessant hype. Integration architects suffer from acronym fatigue, and many have tossed these three new letters onto the stack that includes SOA, BPM, EAI, MOM and other bright shiny marketing banners of yore.
They don't need more acronyms. What they need are integration products that are easy to install, configure, administer and manage. They need middleware that supports robust, standardsbased, any-to- any integration. And they need to address new integration requirements cheaply and quickly, rather than in multi-year, high- risk, budget-busting mega-projects.
Of course, today's ESB products can't deliver all of those benefits all the time. The problem is not so much with ESB solutions themselves as with myriad legacy middleware products, protocols and approaches in most organizations. Companies have invested far too much money on middleware, and on integrating applications via legacy middleware, to throw it all out overnight and start anew. Most real- world integration environments feature middleware products from several vendors, many of these implemented in the context of particular tactical projects, not as part of enterprise-wide architecture.
ESB is a not a silver-bullet solution to the middleware mess. No single ESB product can provide a comprehensive solution to the dizzying range of real-world integration requirements that confronts enterprises and service providers of any size and complexity.
M\ost integration architects will choose to integrate diverse vendors' ESB components-both commercial and open source-rather than standardize on a single provider for this mission-critical backplane
Companies Mentioned In This Article
BEA (www.bea.com)
Cape Clear Software (www.capeclear.com)
Fiorano Software (www.fiorano.com)
IBM (www.ibm.com)
Intalio (www.intalio.com)
Iona (www.iona.com)
EogicBlaze (www.logicblaze.com)
Eombardi Software (www.lombardisoftware.com)
Microsoft (www.microsoft.com)
Oracle (www.oracle.com)
PolarLake (www.polarlake.com)
Savvion (www.savvion.com)
Seagull Software (www.seagullsoftware.com)
Sonic Software (www.sonicsoftware.com)
Sun Microsystems (www.sun.com)
Tibco Software (www.tibco.com)
Ultimus (www.ultimus.com)
webMethods (www.webmethods.com)
Microsoft WCF: Looks, Walks And Quacks Like An ESB
Among SOA platform vendors. Microsoft distances itself furthest from the term "ESB." However. Microsoft's Windows Communications Foundation (WCF) has all the architectural hallmarks of ESB: unified integration paradigm, modular integration layers, flexible integration patterns, ubiquitous integration-logic deployment and visual integration models.
Microsoft WCF defines a messagingoriented environment for both loosely coupled Web services interactions and tightly coupled object- invocation interactions among application components. It will support both local (intra-machine) application integration and remote (cross-domain) application integration. It will specify SOAP/ XML as the mandatory in-memory data format, though it allows in- memory format to be seriali/.ed to almost any text or binary encoding for transmission. And WCF will support both intermediated and non-intermediated message flows for reliable messaging, ACID transactions, streaming unidirectional traffic and other flows.
The framework will encompass the WS-* standards and protocols to which Microsoft has committed, including SOAP, WSDL, WS-RM, WS- security. WS-SecureConversation, WS-Trust. WS-Coordination and Universal Description. Discovery and Integration (UDDI). WCF will also support varying degrees of interoperability and/or co- existence with Microsoft's legacy proprietary middleware protocols. WCF will use MSMQ as its native message queuing infrastructure. WCF won't talk native Distributed Component Object Model (DCOM) on the wire, but Microsoft will retrofit COM+ to communicate directly with WCF. There will be no wire-level interoperability between .NET Remoting and WCF, though .NET Remoting and WCF applications will be able to coexist on Windows machines.
All Windows-based application and infrastructure components- including Microsoft's BizTalk Server integration broker-will have access to WCF features embedded in Windows. WCF will be built into the Vista and "Longhorn" operating systems, and into Visual Studio and Microsoft's other development tools. Some older Windows versions (Windows Server 2003 and Windows XP) will support WCF through a downloadable, redistributable API pack. Programmatic access to WCF features will be through the vendor's new WinFX programming model, which is the successor to .NET
Vendors are using "ESB" as a catch-all in product names
Open Source Commoditizing ESB
Both standardization and commoditization are leveling the ESB playing field, preventing even the largest platform and middleware vendors from exerting excessive customer lock-in.
The trend toward ESB commoditization is best illustrated by the recent inauguration of several open-source ESB projects in the Java community, including Celtix, Petals, ServiceMix and Synapse. Most of these efforts were inaugurated in 2005, and these fresh ESB codebases are too new to have found their way yet into commercial ESB products or actual enterprise production ESB environments.
Collaboration-not competition-among these diverse open-source communities is the rule. All these initiatives leverage the Java Community Process' (JCP) JSR208 specification, also known as JBI version 1.0. Among established ESB vendors, Sonic Software has taken a lead in developing JBI, and has announced plans to integrate the specification into the next major release of its ESB product. However, some other ESB vendors-most notably, IBM and BEA-declined to ratify JBI when it came up for a vote in the JCP in summer 2005.
JBI defines a standards-oriented interoperability framework, J2EE- or J2SE-based runtime container, and set of service provider interfaces for plugging in ESB integration logic. JBI allows ESB software components from multiple vendors to be integrated in a common platform, enabling transformation, routing, protocol mediation, orchestration and other middleware functions. All JBI- based ESB services are described with WSDL 2.0, and they support loosely coupled, message-oriented, multi-platform, multiprotocol interoperability. At the heart of each JBI-based platform is a "normalized message service" that converts all messages in transit between plug-in components on that platform to XML, thereby enabling more efficient message content processing. Externally, the platform's "binding components" convert messages to and from the protocol-specific formats and encodings of their native transports.
The Celtix project is an initiative of Iona, an established ESB and ORB vendor, and ObjectWeb, a France-based open-source software community. Announced in June 2005, Celtix is defining a JBI-based ESB open-source codebase and set of extensibility APIs. The project is developing a J2EE 1.5-based runtime container; plug-in components for protocol mediation, transformation, routing and orchestration; protocol bindings to HTTP 1.1, SOAP 1.1, JMS, WS-RM, Web Services Business Process Execution Language (WSBPEL) and File Transfer Protocol (FTP); language bindings to Java, JavaScript and Perl; and tools for converting Java classes to WSDL definitions and vice versa. In February 2006, Celtix announced delivery of the fourth milestone code-release (of six milestones) in its ambitious development plan.
The Petals project is co-sponsored by ObjectWeb, Fossil E- Commerce, and EBM WebSourcing. The Petals project, announced in October 2005, is developing a JBI-based open-source container for distributed deployment throughout business-to-business integration environments, by means of a JMSbased transport layer. The project is using the ObjectWeb Fractal component model and the Celtix platform as its ESB runtime container and transport layer. Petals will be provided as a standalone ESB platform or bundled with Jonas, which is an open source implementation of J2EE.
The ServiceMix project is an initiative of LogicBlaze, Inc., which is a provider of opensource integration technology and services. Like Celtix and Petals, ServiceMix is based on JBI. The ServiceMix codebase is currently in version 3.0, and is available under the Apache 2.0 open source license. The project's functional differentiators include the ability to run either in an intermediary node or application endpoint (server or client); support for the LogicBlaze-developed ActiveMQ MOM protocol; and implementation of WS- Notification.
The Synapse project, inaugurated in August 2005, addresses the need for open-source ESB integration components on the Apache Axis2 second-generation SOAP stack. Synapse integration components would be installed on nodes deployed as intermediaries in ESB environments. Code for Synapse has been contributed by Sonic Software, Iona, Blue Titan, Infravio and WS02. Project participants are building protocol mediation, message brokering, content transformation and routing components for Axis2. Synapse, like all ESB open-source projects, will support a full range of industry- consensus WS-* standards, including Web Services Distributed Management (WSDM) for end-to-end ESB monitoring and management
ESB: A Few Quick Definitions Of A Sprawling Abstraction
ESB is a new term-only a few years old-and has many definitions in use throughout the IT world. Nevertheless, at heurt, most observers define ESB as follows:
* Universal middleware environment that supports simple, speedy, standards-bused integration across heterogeneous network application environments.
* Growing segment of the integration software market that addresses the intersection of message-oriented middleware (MOM) and Web Services.
* Integration environmeni that supports flexible messaging- centric interaction patterns, enabling hub-and-spoke. decentralized and peer-to-peer patterns with equal agility.
* Abstraction layer that mediates among old and new computing platforms and middleware environments.
* Catch-all term for re-branding of middleware vendors' entire product portfolios, spanning both legacy and future offerings.
ESB isn't synonymous with SOA. ESB provides the ubiquitous integration fabric that allows organizations to realize the SOA promise of maximum functionality reuse, sharing and interoperability across networks.
ESB isn't synonymous with Web services. ESB provides an integration environment that supports Web services natively, but also bridges among Web services and other middleware protocols and approaches
ESB is much more than "super-MOM"
Another wild card is how Cisco will mesh ESB with its AON initiative
ESB is not a silver bullet
Jim Kobielus is a senior technical systems analyst with Exostar LLC in Herndon, VA. He can be reached at 703/340-8134 or James_kobielus@hotmail.com. The opinions expressed are his own. Tune into his blog at http:// jkobielus.blogspot.com.
Copyright Business Communications Review Apr 2006
(c) 2006 Business Communications Review. Provided by ProQuest Information and Learning. All rights Reserved.
Source: Business Communications Review
 |
 |
User Comments (0)
RSS Feeds