Predicts 2004: Enterprise Service Buses Are Taking Off

Transcription

1 Strategic Planning, R. Schulte Research Note 16 December 2003 Predicts 2004: Enterprise Service Buses Are Taking Off Today, enterprise service buses are used only in leadingedge applications. They quickly will evolve; major vendors will offer them in ESBs will supersede traditional communication middleware in new applications by Core Topic Application Integration and Middleware: Application Integration Key Issue Which trends, features, industry standards and packaging strategies will shape the future of integration middleware? Strategic Planning Assumptions More than 90 percent of ESBs will support multiple styles of communication and multiple protocols by 2H05 (0.8 probability). IBM will ship its new ESB product in 2H04 (0.7 probability). Microsoft will ship Indigo in the Longhorn operating system by 2006 (0.4 probability) or by YE07 (0.8 probability). All major integration suites will have an ESB core by YE06 (0.7 probability). Modern applications are inherently distributed that is, programs interact with other programs across the network. To make this work, enterprises need a middleware infrastructure that supports program-to-program communication, such as object request brokers (ORBs), message-oriented middleware (MOM), remote procedure call (RPC) services and Web services platforms. Sometimes the middleware is unbundled and sold as a separate product. In other cases, it is bundled into a larger product. For example, Java application servers include an ORB (Remote Method Invocation), MOM based on the Java Message Service (JMS) standard and a Web services platform. Similarly, the Windows operating system includes the.net Framework, which encompasses MOM (Microsoft Message Queue [MSMQ]), an ORB (.NET Remoting) an RPC service (MS-RPC) and a Web services platform. A large enterprise will typically use a combination of unbundled and bundled middleware facilities, each of which specializes in a single communication style. Enterprise service buses (ESBs) are a new kind of middleware that combines features from several previous types of middleware into one package. ESBs support Web services by implementing Simple Object Access Protocol (SOAP) and leveraging Web Services Description Language (WSDL) and Universal Description, Discovery and Integration (UDDI). Many ESBs also support other communication styles that involve guaranteed delivery and publish-and-subscribe; those that don't soon will. All ESBs provide some value-added services beyond those found in basic communication middleware, such as message validation, transformation, content-based routing, security, service discovery for a service-oriented architecture (SOA), load balancing, failover and logging. Some services are built into the ESB core, while others run in "plug in" modules. ESBs have a distributed architecture wherein some services are executed near the application programs, rather than in a central Gartner Reproduction of this publication in any form without prior written permission is forbidden. The information contained herein has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information. Gartner shall have no liability for errors, omissions or inadequacies in the information contained herein or for interpretations thereof. The reader assumes sole responsibility for the selection of these materials to achieve its intended results. The opinions expressed herein are subject to change without notice.

2 hub. ESBs support Extensible Markup Language (XML) and often also support other message formats. Prediction Pure SOAP/HTTP-only ESBs will converge with multiprotocol ESBs by the end of There are two types of ESBs: ESBs based solely on SOAP Multiprotocol ESBs that support Web services and other communication mechanisms SOAP/HTTP ESBs: ESBs called "Web services brokers" or "fabrics" originally were created to work specifically with SOAP/HTTP messages. They still use SOAP, but some also support alternatives to HTTP as a transport now. It was clear from the early days of SOAP that the value-added services used with Common Object Request Broker Architecture (CORBA), Distributed Computing Environment (DCE) and MOM also would be needed for Web services. For many applications, it is not enough to simply convey a SOAP message from a client directly to a server. Plain, unbundled Web services platforms, such as Apache's Axis or Systinet's Web Applications and Services Platform, or similar platforms that are bundled into Microsoft's SOAP Toolkit or a Java application server, are sufficient only for simple applications. ESBs turn Web services into a distributed computing environment by intercepting messages within the local SOAP runtime or in an intermediate proxy server to provide value-added services. Many ESB vendors also supply Web services development tools and some management capabilities. Most of these value-added services and tools are not specified by a Web services standard and never will be. Examples of such ESBs include: Blue Titan's Network Director Cape Clear's 4 Server Digital Evolution's DE Management Server Hewlett-Packard's Talking Blocks Service Oriented Architecture Primordial's Web Services Network Systinet's Web Services Bus webmethods' Fabric Some SOAP-centric ESBs occasionally are called Web services management (WSM) products. We consider a product to be an ESB if its primary value proposition is communication (for 16 December

3 example, guaranteed delivery or publish-and-subscribe) or simple brokering (for example, validation, transformation or content-based routing). In our view, the real WSM products are those whose primary mission is management (for example, performance monitoring, provisioning, availability or security). WSM vendors include Actional, AmberPoint, Computer Associates, Confluent Software, Flamenco Networks, Infravio, Service Integrity and Westbridge Technology. There is an overlap between WSM products and ESBs because WSM products usually embed basic ESBs, and ESBs usually embed some monitoring and security features. Nevertheless, there is a discernible difference in their respective emphases. Multiprotocol ESBs: Multiprotocol ESBs support SOAP/HTTP and additional protocols. They implement communication patterns, such as guaranteed delivery and publish-andsubscribe, often following the JMS standard because there are no Web services standards for those patterns. These products also provide various value-added services. Examples of such ESBs include: Fiorano Software's ESB IBM's Services Integration Bus (a future product) IONA Technologies' Artix Kenamea's Web Messaging Platform KnowNow's Event Routing Platform Microsoft's Indigo (a future product) PolarLake's JIntegrator Software AG's EntireX Sonic Software's ESB SpiritSoft's Spiritwave WebV2's Process Coupler Convergence: The two kinds of ESBs largely will converge by year-end The Web services standards have become more open to alternative protocols beyond SOAP and HTTP. Standard SOAP documents can be sent over private protocols when HTTP is not scalable, reliable or efficient enough. Furthermore, WSDL can be used to describe an official Web service, even if SOAP is not used. This enables "pure" SOAP ESB vendors to implement other protocols without violating their principle of standards compliance, and it lends credibility to multiprotocol ESB vendors' strategies. 16 December

4 Most SOAP/HTTP ESBs will become multiprotocol ESBs or will fade away. Rather than coding their own additional protocols and communication styles, some HTTP-only ESBs will merge with multiprotocol ESBs or MOM. Some vendors will merge a pure HTTP ESB with a multiprotocol ESB, even if the multiprotocol ESB already has some basic SOAP and HTTP features, because SOAP/HTTP ESBs generally have better support for Web services standards and development tools. This makes the SOAP/HTTP ESB vendors attractive acquisition targets. For example, in 2H03, Hewlett-Packard acquired Talking Blocks and webmethods bought The Mind Electric. This acquisition trend likely will continue in 2004 and beyond. Whether through acquisition or internal development, most multiprotocol ESBs will augment their support for Web services during 2004 and By 2H05, ESB vendors will compete mostly on the strength of their value-added services and performance, rather than on standards compliance. The better ESBs will offer developers a choice of programming models, communication patterns and application programming interfaces in a combined, SOA-capable infrastructure. In some cases, the ESBs also will merge with endpoint Web services platforms. ESB vendors increasingly will shield application developers from having to know what protocol is being used (including shared memory in some cases). Some advanced ESBs will select a protocol dynamically, or will transparently route across multiple protocols. Strategic Planning Assumption: More than 90 percent of ESBs will support multiple styles of communication and multiple protocols by 2H05 (0.8 probability). Action Recommendation for 2004 Select an ESB that has a firm road map to support multiple protocols, a comprehensive set of Web services standards, and good management and brokering services. Prediction IBM and Microsoft eventually will dominate the ESB market, but not during 2004 or Leading-edge development projects are succeeding with ESB products from small vendors. ESB use will explode when ESBs from larger venders are delivered. In August 2003, IBM announced its intent to offer a Services Integration Bus, which will be backward-compatible with its MQSeries MOM. If this ESB is as open as MQSeries which supports all major operating systems, programming languages and application servers the IBM ESB could become popular in heterogeneous networks. 16 December

5 In October 2003, Microsoft described its future Indigo "servicebased infrastructure." Indigo will supersede previous Microsoft communication middleware, including DCOM, MS-RPC, MSMQ,.NET Remoting and the Microsoft Web services platform. Microsoft intends for Indigo to have substantial backward compatibility with all of those facilities to reduce coexistence and migration problems. Indigo's architecture appears to be very advanced and complete. It is designed to be fully distributed, scalable and extensible. It reportedly will support multiple protocols, multiple qualities of service and all major Web services standards. Because Indigo will be built into the Longhorn version of the Windows server operating system, and will also be available for Windows XP and Windows Server 2003, most enterprises will run it. Indigo probably will become the de facto standard in Microsoft-centric networks. Strategic Planning Assumptions: IBM will ship its new ESB product in 2H04 (0.7 probability). Microsoft will ship Indigo in the Longhorn operating system by 2006 (0.4 probability) or by YE07 (0.8 probability). Action Recommendation for 2004 Leading-edge enterprises that are implementing a SOA-capable enterprise nervous system in 2004 should consider ESB vendors that are smaller than IBM and Microsoft, or create ESB-like infrastructure by using separate MOM and Web services products, integrating them through custom code. Prediction The core of integration suites will evolve from MOM to ESBs by Comprehensive integration suites, such as IBM's WebSphere Business Integrator, SeeBeyond's ICAN, TIBCO Software's BusinessWorks, webmethods' Integration Platform and Vitria Technology's BusinessWare, originally were built on MOM backbones because Web services did not exist. These products have added XML support, SOAP/HTTP stacks and varying facilities for WSDL, UDDI and other Web services. However, the integration suites implement Web services in a way that is not fully integrated with their native MOM. We expect this to change. Just as these vendors had to re-architect to build ever-closer ties into Java 2 Platform, Enterprise Edition (J2EE) and.net, they also are gradually implementing native ties into Web services. webmethods was the first of the traditional integration vendors to make a major move in this direction by acquiring The Mind Electric and its Fabric technology. Fabric is a pure SOAP/HTTP ESB. However, we expect that Web services technology from Fabric will be injected into webmethods' Integration Platform, and technology from the Integration Platform will find its way into 16 December

6 Fabric. The result will be a comprehensive integration suite based on a multiprotocol ESB core by the end of 2005, although it will take several iterations to get there. Other integration vendors likely will follow suit via acquisition or development. ESB vendors are coming from a different origin than the application integration vendors, but they are going to the same destination. During the past year, some pioneering multiprotocol ESB vendors, such as Fiorano and Sonic, announced comprehensive integration suites as a layer built on top of their base ESBs. Fiorano's Business Integration Suite and Sonic's Business Integration Suite are roughly comparable to the traditional MOM-based integration suites, although they use an ESB core that can be bought separately. Customers can start with the ESB and add options, such as adapters, business process management (BPM) and message warehousing. These suites are priced lower than the traditional integration suites and are newer. However, they are less proven and the vendors are smaller. Other ESB vendors, such as Cape Clear, Systinet and WebV2, also are moving toward offering full integration suites. Acronym Key BPM business process management CORBA Common Object Request Broker Architecture DCE Distributed Computing Environment ESB enterprise service bus J2EE Java 2 Platform, Enterprise Edition JMS Java Messaging Service MOM message-oriented middleware MSMQ Microsoft Message Queuing Services ORB object request broker RPC remote procedure call SOA service-oriented architecture SOAP Simple Object Access Protocol UDDI Universal Description, Discovery and Integration WSDL Web Services Description Language WSM Web services management XML Extensible Markup Language Some vendors refer to the low-price versions of their traditional integration tools as "ESBs." This terminology is misleading and should be dropped, but the problem is understandable. ESBs are extensible and supply various levels of value-added features. They often provide basic transformation and content-based routing, which traditionally are found in integration suites but not in plain MOM. However, ESBs are not full integration suites because they do not include BPM, adapters, trading-partner management and other integration functions in the core product (although these may be added as options to make the ESB into an integration suite). At a minimum, ESBs include communication middleware (including SOAP/HTTP) and some value-added services. Microsoft's BizTalk is not an ESB because it includes BPM. It is also not an ESB because it does not embed communication middleware. It is a hub that plugs into separately implemented communication middleware, such as the.net Framework and MQSeries. Strategic Planning Assumption: All major integration suites will have an ESB core by YE06 (0.7 probability). Action Recommendation for 2004 Select an integration suite based on a comprehensive view of its technical and business characteristics (see "Integration Broker Selection: Technical Criteria" and "Integration Broker Selection: Vendor-Related Criteria"). Whether the core communication mechanism is an ESB or a MOM is a minor consideration in some cases. 16 December

7 Bottom Line: Leading-edge developers should use an enterprise service bus in 2004 for service-oriented architecture projects. Mainstream enterprises should add ESBs to their IT strategies during 2004 and begin selectively implementing ESBs in Conservative projects should avoid ESBs until 2006, by which time ESBs will be more proven and mature. 16 December