12.3 Adopting the WS-* Specifications in an ESB An ESB implementation does not have to support all of the WS-* specifications in order to be an effective integration platform. If you recall from most of the discussion in this book, the majority of applications today are built upon neither J2EE nor .NET, and they won't all just switch over to web services interfaces in a day. ESBs will generally support these specifications as they become more mature and are adopted in the industry. When they do implement these specifications, interoperability and integration through an ESB will become an even easier task. Using the full WS-* stack of technology as an alternate protocol between services, ESBs will provide better interoperability across services and provide endpoint connectivity without necessarily requiring the use of special adapters. Table 12-1 lists the functionality in the ESB and existing standards that are reasonably mature and that have implementations that an ESB can utilize to provide interoperability among applications and services. It also gives an indication of which of the evolving WS-* specifications should be used in an ESB implementation as the specifications mature and are adopted by multiple vendors and platforms. Table 12-1. ESB and the evolving WS-* specifications| ESB capability | Existing ESB technology | Evolving WS-* specifications | Notes |
|---|
| Secure communication channels | SSL, HTTPS | WS-Security, WS-SecureConversation | WS-Security not really useful without WS-SecureConversation and WS-Trust. | | Authentication | PKI digital certificates | WS-Trust, SAML, WS-Federation | | | Message payload encryption | Standard cypher suites | WS-Encryption | | | Access control lists | LDAP, JMX, proprietary | XACML | | | Publish and subscribe | JMS, proprietary | WS-Notification, WS-Eventing | | | Service endpoint description | WSDL, proprietary, LDAP, JNDI | WSDL, WS-Policy, SOAP 1.2 F&P | | | Reliable messaging | JMS, proprietary MOM | WS-ReliableMessaging, WS-Reliability | | | Itinerary-based routing | WSDL, proprietary | WSDL, WS-Addressing | | | Business process orchestration | Proprietary | WS-BPEL, WS-Choreography, proprietary | BizTalk 4.0 imports and exports. Other implementations use extensions to do anything concrete. | | Transactions | JTA, JCA, XA, proprietary, compensating | WS-Coordination, WS-Transaction, WS-AtomicTransactions, WS-BusinessActivity, WS-CAF | |
12.3.1 WS-* Does Not Imply Enterprise Capabilities There are and will continue to be a number of implementations of web services stacks that are not sophisticated enough or scalable enough to support an enterprise-wide integration backbone. Simply supporting WS-Rel*, for example, requires only that two endpoints know how to perform a message exchange pattern that satisfies the send/acknowledge semantics that the specification defines. An open source effort, such as the Apache Web Services project, may eventually support the whole family of specifications, but that does not mean that you should use it alone to deploy an enterprise-wide integration backbone. Implementing this family of specifications does not require or imply that the implementation supports, for example, a scalable implementation of clustered fault-tolerant message brokers that can act as a single virtual unit, and that are capable of intelligently routing messages across sophisticated deployment topologies. 12.3.2 WS-* Does Not Imply ESB If a web services toolkit provides support for the WS-* specifications, it does not automatically imply that the toolkit is an ESB. A question I am often asked is, "When web services become more mature, will I still need an ESB?" or "What's the difference between an ESB and a bunch of web services linked together with a BPEL engine?" Of course, at this point in the book, the answer should be apparent. But I'll summarize the key points. An implementation of a set of WS-* specs does not imply an ESB. The ESB concept is well suited for adopting the WS-* family of specifications as they mature and are adopted by more vendors. As the ad hoc collaboration of vendors implements more of these specifications in their respective platforms, their products will be able to interoperate with each other. This will not obsolete the use of an ESB, however; in fact, it will make the ESB concept more relevant, in that applications built upon those platforms will be easier to integrate into the common integration environment that is the ESB. Support for the WS-* family of specifications does not imply anything about the underlying implementation. Recall the accidental architecture discussion from Chapter 2. Web services alone, without a proper architecture for a distributed integration network, does not buy you much except for a new set of protocols and interfaces to deal with. Simply applying web services interfaces and protocols to existing applications can quickly lead to a "standards-based accidental architecture." A common misconception of an ESB is that it is just a MOM with SOAP and WSDL bindings. Providing an environment where the gap can be bridged between a proprietary MOM and a Web Services Reliable SOAP protocol is a step in the right direction, but it is only one part of what makes an ESB. It is analogous to having an Ethernet plug on the back of your computer that alone does not make your computer automatically able to talk to every other computer. An entire network of switches and routers makes that part possible. Part of what makes an ESB is an underlying message bus, which provides a network of collaborating message servers that can transparently route application data as messages across a variety of protocols. However, even a message bus by itself does not fully qualify as an ESB. An ESB provides an SOA across that message bus, and the highly distributed integration functions in a hosted lightweight container environment, which can operate independently of one another, without the need to install the entire stack of functionality in every place an individual integration component is required. This includes the capabilities of XML data transformation, content-based routing, orchestration and process flow, and application adapter interfaces. Looking forward, the best possible outcome of the "coming of age" of the WS-* family of specifications is that, when combined with an ESB architecture, IT functions will have even more ways of integrating and interoperating with application endpoints. Adoption of the WS-* family of specifications by the major application platform vendors will continue to make the model of message-driven application interfaces a reality. As more application endpoints provide support for these protocols, it will become easier to integrate them through an ESB integration fabric. |
