The set of WS-* specifications is still evolving. The following are brief descriptions of some of the important ones that have relevance to an ESB:
- WS-Eventing
-
Supports a publish-and-subscribe event model using web services. WS-Eventing provides a simple subscription model using WSDL interfaces, but has no notion of message brokering and does not attempt to describe how topic namespaces are managed.
- WS-Notification
-
Provides a family of specifications that includes WS-BaseNotification, WS-BrokeredNotification, and WS-Topics. WS-BaseNotification defines a subscription-based event model using web services, very much like WS-Eventing. WS-BrokeredNotification defines a model for how publish-and-subscribe messaging can be managed by message brokers, and how message brokers themselves can act as conduits for dispatching messages to their intended destinations. WS-Topics defines how a hierarchical namespace of publish-and-subscribe messaging topics can be managed and accessed. Subscriptions are treated as manageable resources with a lifecycle that is defined according to the rules specified by the WS-ResourceFramework family of specifications.
Both WS-Eventing and WS-Notification are intended to work with WS-Policy and WS-ReliableMessaging. WS-Notification has been brought to OASIS to form a Technical Committee (TC). TC members may introduce other possibilities such as "composability" between WS-Eventing and WS-BrokeredNotification.
- WS-ReliableMessaging
-
Published by MS/IBM et al., WS-ReliableMessaging provides a SOAP-based reliable protocol that describes SOAP header elements and behavioral semantics for message acknowledgments, message retries, and fault handling for coping with undeliverable messages. The specification definition and input process have been broadened to include several feedback and interoperability workshops that have been open to the public. WS-ReliableMessaging has a high degree of overlap with OASIS WS-Reliability in terms of capabilities and functionality.
- WS-Reliability
-
A product of the OASIS Reliable Messaging TC, WS-Reliability provides a SOAP-based reliable protocol that describes SOAP header elements and behavioral semantics for message acknowledgments, message retries, and fault handling for coping with undeliverable messages. Several test implementations have been provided by the TC members for the purposes of interoperability testing. WS-Reliability has a high degree of overlap with WS-ReliableMessaging in terms of capabilities and functionality.
- WS-Security (WSS)
-
An OASIS TC that specifies QoP, privacy, and message integrity through encryption and signing of XML documents, in part or in their entirety, WSS also includes mechanisms for associating security tokens, such as X.509 certificates and Kerberos tickets, with XML documents.
- WS-Trust
-
WS-Trust is a companion specification to WS-Security that describes how to establish security tokens and derive and share security keys.
- WS-SecureConversation
-
WS-SecureConversation establishes a shared security context and shared session keys based on security context. Shared security context exists for the lifetime of the conversation.
WS-Security will not be fully baked until WS-Trust and WS-SecureConversation are fully worked out and adopted by the security vendors and the major platform vendors.
- WS-Federation
-
The goal of WS-Federation is to provide security, including authentication and authorization across federated security realms, using a single authentication mechanism.
- WS-Addressing
-
WS-Addressing defines a set of constructs for endpoint references that represent From, To, RelatesTo (RefTo), FaultTo, and ReplyTo (and Reply Forward) addresses. WS-Addressing maps very well for use as a base for the metadata describing a message itinerary in an ESB.
- WS-Policy
-
WS-Policy is a composable set of specifications (WS-Policy, WS-PolicyAssertions, WS-PolicyAttachments) that, collectively, are similar to SOAP 1.2 F&P. WS-Policy defines a means for expressing assertions about the capabilities of an endpoint, or the underlying capabilities of the service behind the endpoint. A web service client that wishes to communicate with the service endpoint should first query its properties to determine whether it is capable of supporting that endpoint's asserted "features." WS-Policy allows a service endpoint to specify preferences using a weighting system, indicating to a potential client multiple options of capabilities that can be used to carry out a conversation. For example, a service endpoint might expose a policy indicating that it supports both WS-ReliableMessaging and WS-Reliability as communication protocols, but that it prefers the client to use WS-ReliableMessaging if there is a choice. In addition, these policy preferences are packaged up in the SOAP envelope header to indicate to the receiving service endpoint which policy preferences the sender has chosen to use. This is not a negotiation protocol per se; it is a one-way exchange of information where the service endpoint asserts to a potential client sender that it supports certain capabilities, designated as required or optional. The sender must support the required capabilities or it will not be allowed to send a message to the endpoint (i.e., the endpoint will generate a SOAP fault).
- SOAP 1.2 Features and Properties (F&P)
-
A product of the SOAP 1.2 Transport Binding Task Force (http://www.w3.org/2000/xp/Group/tbtf) and an alternative approach to WS-Policy, SOAP 1.2 F&P makes use of the SOAP 1.2 extensibility model (http://www.w3.org/TR/2003/REC-soap12-part1-20030624/#extensibility), which allows two parties having a conversation over SOAP to mutually agree on capabilities of the endpoints. For example, they both may agree that they support WS-Encryption and that they can exchange encryption keys using an out-of-band means that is known to both sides of the conversation. Choosing a WS-Rel* protocol, as described in the WS-Policy explanation, can work here equally as well.
- WS-BPEL
-
WS-BPEL is an OASIS TC that is defining the ongoing work of the Business Process Execution Language for Web Services (BPEL4WS) specification. BPEL4WS extends and subsumes its roots, which come from a combination of Microsoft's XLANG specification and IBM's Web Services Flow Language (WSFL) specification. BPEL4WS defines an XML grammar for describing an abstract business process and the constraints of a message exchange of business-level messages in an executable process flow. The first rendition of the specification focuses on peer-to-peer interactions between web services endpoints that are described using WSDL.
BPEL4WS can also be described as providing a schema for an instance of a business process from the point of view of a particular participant (service). The language defines business process sequences (flows) by describing links between participants and the interactions between those links.
The language supports constructs such as variable definitions, looping, and throw and catch blocks that can be transactionally scoped using compensating transactions. Activities define the interactions between links. Examples include the invoke, reply, compensate, and receive statements. Correlation sets are defined for linking "request" messages with "response" messages, and fault handlers are provided for handling the cases when good messages go bad. Parallel execution paths of business processes and conditional joins are supported in the language.
It should be noted that BPEL4WS is sufficient enough to describe an abstract definition of a business process, or the interaction steps between two partners. An actual implementation requires that vendor extensions be provided, or that an import/export facility be implemented. Biztalk 4.0 provides an import/export facility. An ESB could support either approach as well.
