WS-Specifications

The WS-Specifications build a composable architecture to form an environment for complex Web Service applications. Different vendors, such as BEA, IBM, Microsoft, RSA Security and SAP, have joined forces to lay the foundation of secure and reliable Web Service applications, that support different technologies and multiple participants. This article describes the family of the WS-Specifications.

Most of the specifications are still in the draft phase and subject to change but some products already exist that support certain features. WS-* specifications are designed to be used with the SOAP versions 1.1 and 1.2.

WS-Addressing
The Web Service Addressing specification is essential for the other WS-Specifications. A reference to a Web Service endpoint can be expressed and passed using WS-Addressing. WS-ReliableMessaging and WS-Coordination are using descriptions of Web Service endpoints. Besides the construct of endpoint references, the specification provides message information headers.

WS-Policy
WS-Policy can express requirements, capabilities and assertions. For example, a policy can indicate that a Web Service only accepts requests containing a valid signature or a certain message size should not be exceeded. How a policy can be obtained is out of the scope of this specification. WS-MetadataExcange and WS-PolicyAttachment specify how policies are accessible through SOAP messages or associated with XML and WSDL documents.

WS-PolicyAttachment
The description of requirements or capabilities of a Web Service, expressed in WS-Policy, has to be associated with the Web Service in order to consider the policy before invoking the service. Web Services Policy Attachment specifies how policies can be associated with XML and WSDL or registered in UDDI registries.

WS-MetadataExchange
Metadata in WSDL documents, XML Schemas and WS-Policies is useful to invoke a Web Service successfully. How to retrieve this information about service endpoints is the subject of the Web Service Metadata Exchange specification.

WS-Resource Framework (WSRF)
The previous Web Services standards treated state like a stepchild or omitted it completely. A different approach to Web Services the "representational state transfer" architecture managed server-side data as resources. The WS-Resource Framework introduces state, in the form of resources, to SOAP-based Web Services. WSRF introduces a design pattern that describes how to access resources with Web Services. The WS-Resource Framework constitutes a refactoring of the Grid Forum's Open Grid Services Infrastructure (OGSI). WSRF is broken down into a family of composable specifications. Applications of the Resource Framework are Grid Computing and Systems Management.

WS-Notification
WS-Notification specifies how to use Publish-Subscribe messaging with Web Services. It exploits the WS-Resource Framework and Web Services.

WS-Inspection
Web Services that are offered by a website can be published using a WS-Inspection document. A WS-Inspection document provides references to service descriptions like UDDI entries or WSDL service descriptions. WS-Inspection does not compete with UDDI. On the contrary, it is a form of description at the point-of-offering which works in conjunction with UDDI.

WS-Security or Web Services Security (WSS)
Security is a requirement for adopting Web Services in critical applications. The integrity and confidentiality of messages must be guaranteed. Furthermore, the identity of the participating parties shout be proofed. The Web Services Security Language, or WS-Security for short, is a base for the implementation of a wide range of security solutions. In April 2004, the Organization for the Advancement of Structured Information Standards (OASIS) ratified WS-Security as a standard under the name OASIS Web Services Security (WSS).

Signing and encryption of SOAP messages as well as the propagation of security tokens is supported by WS-Security. WS-Security leverages the XML Signature and XML Encryption standards by the W3C. Almost all WS-Specifications can be used in conjunction with WS-Security. For example, a

wsp:Policy

element inside a SOAP header should be signed to prevent tampering. WS-SecureConversations and WS-Trust are layered on top of WS-Security.

WS-SecureConversation
If more than two messages are exchanged, a security context might be more suitable than using WS-Security. Mechanisms for establishing and sharing security contexts as well as deriving session keys from securtiy contexts are the subject of Web Service Secure Conversation. To derive a new key a shared secret, a label and a seed are necessary.

WS-Trust
WS-Trust is an extension of the WS-Security specification. The extension allows to request , issue and exchange security tokens between Web Services and Security Token Services.

WS-ReliableMessaging
A sequence of messages can be reliably delivered using WS-ReliableMessaging. The receiver acknowledges received messages and asks for redelivery of lost messages.

WS-Reliability
This specification is the counterpart to WS-ReliableMessaging. WS-Reliability was created by Sun Microsystems, Oracle, Sonic Software and others. Its goals- guaranteed delivery, duplicate message elimination and message ordering- are identical to those of WS-ReliableMessaging. WS-Reliability was submitted to the OASIS standard body as an open standard. Both standards should converge into one because only one specification for reliable messaging is needed.

WS-Coordination
WS-Coordination is an extensible framework for the establishment of coordination between Web Services and coordinators. Different kinds of coordination types can be defined. Each coordination type can have multiple coordination protocols. Contexts used for transactions or security can be created and associated with messages. A context contains a reference to a registration service. WS-Transaction leverages the WS-Coordination specification.

WS-Transaction
The WS-Transaction specification is obsolated by the WS-AtomicTransaction and the WS-BuisnessActivity specification.

WS-AtomicTransaction
The Web Service Atomic Transaction specification describes transactions that have all or nothing semantics. Because the resources involved in the transaction are locked during the transaction, the transaction should span a short time. If more than two resources take part in a transaction, the two phase commit protocol (2PC) comes into play to coordinate the participants.

The protocols of proprietary transaction monitors can be wrapped in order to operate in a Web Services enviroment.

WS-BuisnessActivity
Long running transactions are different from short-time transactions such as database transactions. In a Web Service environment, a transaction can span several days so locking the resources is not recommended. Actions are excuted immediatedly and changes concerning data are made permanent. In the case of an error, actions are taken to compensate the already commited modificaitons.

The Web Service Buisness Activity specification covering long running transactions will replace Part II of the obsolete WS-Transaction specification. At this time, the WS-BuisnessActivity specification does not yet exist.

WS-Routing
The path of a SOAP message from the initial sender to the ultimate receiver via a set of optional intermediaries can be expressed in the SOAP header using the Web Services Routing Protocol. The reverse path can be expressed in this way as well. The specification enables several message exchange patterns like request/response, message acknowledgement and peer-to-peer conversation.

WS-Federation
Sophisticated Web Service scenarios can span over several Web Services located in different security domains. It´s annoying for an user or a Web Service application to prove and validate its identity against every service. A federation virtually enables the seamless access over Web Services in different domains. WS-Federation not only provides the transparent propagation of identities, but provides the propagation of arbitrary attributes too.

WS-Eventing
An infrastructure for asynchronous messages exchange is a building block for complex distributed applications. WS-Eventing enables the use of the Observer Design Pattern for Web Services. The Web Services Eventing Protocol defines messages to subscribe with an event source, to end a subscription, and to send notifications about events.

Summary
There is still a large gap between the rich features of CORBA and SOAP based Web Services. The WS-* specifications will help fill the gap. However, most of the WS-* specifications are still in early stages. The essential WS-Security specification is the building block for most applications and is quite mature for using today. A very promising specification is WS-Addressing because it is needed to pass an endpoint reference from one service to another.

The major companies in the Web Services business are behind the specifications so there is high probability of a big market share.