| This chapter provides an overview of the evolving web services specifications, and an explanation of how web services and ESBs will move forward together. There is an evolving set of specifications being branded as the "Web Services Specifications," commonly referred to in this book as the WS-* family of specifications. Some of the WS-* specifications originated from standards organizations such as the W3C and OASIS, but a large majority are a result of an ad hoc collaborvation of vendors that usually includes Microsoft, IBM, and BEA. Other vendors and organizations, such as Global Grid Forum, RSA, SAP, Sonic, and TIBCO, also collaborate based on their particular area of expertise. For example, the WS-Notification Specification authors include Akamai Technologies, Computer Associates International, Fujitsu Laboratories of Europe, The Globus Alliance, Hewlett-Packard, IBM, SAP AG, Sonic Software, and TIBCO Software; the October 2003 WS-ReliableMessaging Interoperability workshops included BEA, IBM, Blue Titan, Microsoft, NEC, Sonic, TIBCO, and Systinet. The goal of these ad hoc vendor collaborations is to eventually bring the specifications before a standards body, after a considerable amount of public feedback sessions and interoperability workshops have occurred. For some specifications, such as WS-Security, WS-BPEL, and WS-Notification, this has already happened. The reason behind this approach is that these companies feel that defining standards by committee is too slow and arduous, and that it is best to define the standards offline until they are "almost baked" before finally bringing them to a standards body for "ratification" with a broader community. That being said, these standards are not being developed in a vacuum. In the case of WS-ReliableMessaging, WS-Security, WS-Policy, WS-Notification, and others, the sponsoring companies have been hosting specification feedback meetings and providing open invitations to interoperability workshops. Some specifications that do originate from standards bodies have overlapping objectives with the specifications from the ad hoc vendor collaborations. Some examples of this include: The WS-Reliability specification, an output of the OASIS Web Services Reliable Messaging (WSRM) Technical Committee (TC), overlaps with WS-ReliableMessaging of the WS-* family of specifications. The WS-Policy specification, from the WS-* family of specifications, overlaps with a W3C SOAP 1.2 capability known as "Features and Properties" (F&P). WS-Eventing and WS-BaseNotification, both from the WS-* family of specifications, are almost identical in scope. WS-Addressing from the WS-* family of specifications, and WS-MessageDelivery, which is a W3C "member submission."
This overlap can sometimes even exist in multiple standards bodies. For example, the Web Services Choreography Working Group (WS-Choreography) was established in the W3C. Shortly thereafter, the Business Process Execution Language for Web Services (BPEL4WS) specification was brought to OASIS to form the WSBPEL TC. The two groups eventually decided to create official liaisons between them, and now have a fair amount of cross-membership. An ESB should be capable of accommodating these specifications going forward, even if it means supporting multiple overlapping versions. To an ESB, these become more standardized ways to integrate with applications. When Microsoft supports WS-ReliableMessaging in its Indigo platform, for example, an ESB should be able to support that protocol if it wishes to provide integration hooks into applications based on Indigo. However, an ESB implementation may also need to support WS-Reliability in order to integrate with applications from vendors who back that specification, such as Oracle, Sun, and SAP. |