Advanced Web Service specifications

Several important issues are not addressed by the basic protocol stack, such as service composition, security, reliable messaging, transactions, etc. To fill this gap, many so-called WS-* specifications have been proposed on top of the basic Web Service specifications. The WS-* specifications provide mechanisms for quality of service (e.g., WS-Security [136] and WS-ReliableMessaging [43]) and for service composition (e.g., BPEL [59]).

WS-* specifications are composable: whilst each of them addresses a specific concern and has a value on its own, it can work seamlessly in conjunction with other WS-* specifications. For example, a SOAP message that is secured according to WS-Security can also carry reliable messaging headers as defined by WS-ReliableMessaging. In the following, the WS-* specifications that are relevant to this thesis will be presented shortly.

Web Service Security

SOAP messages are exposed to several security threats when exchanged between clients and Web Services. The receiver needs to be sure that the message was really sent by the claimed sender, that is was not read or tampered with during transmission, etc.

WS-Security [136] is an OASIS standard, which defines SOAP extensions to implement message integrity, message confidentiality, and single message au- thentication. WS-Security defines a security header to convey security-related data such as signatures, keys, time stamps, etc. WS-Security supports two kinds of authentication tokens: a UsernameToken can be used to carry a username

and password pair and a BinaryToken can be used to carry other tokens such as X.509 certificates and Kerberos tickets.

There are other security specifications that build on top of WS-Security and address advanced security issues such as trust [4], secure conversations [88], federation [3], etc.

WS-Trust [4] provide methods for issuing and exchanging security tokens, and for managing and establishing trust relationships. In the trust model of WS-Trust, a client that wants to interact with a given Web Service has to interact with the Security Token Service (STS) of that Web Service. The STS may require its own set of claims in order to subsequently issue a token that the client uses to interact with the Web Service.

WS-SecureConversation [88] builds upon WS-Security and WS-Trust to sup- port the establishment of mutually authenticated security contexts, which can be used to exchange several messages. In WS-Security, each individual message should contain information about the artifacts that were used to secure it. WS- SecureConversation eliminates the overhead of carrying and validating all these security artifacts in each SOAP message.

Web Service Reliable Messaging

Several delivery errors could occur when unreliable communication channels are used, such as message loss, message duplication, and message reordering (i.e., messages that are sent in a certain order are received in a different order).

There are two competing specifications that address reliable messaging in Web Services: WS-ReliableMessaging [43] is a specification by IBM, BEA, Mi- crosoft, and Tibco and WS-Reliability [135] is an OASIS standard.

Both specifications provide similar delivery assurances (exactly-once, at- least-once, at-most-once, and ordered delivery). To enforce these assurances, both specifications define protocols for reliable message delivery and use well- known mechanisms from computer networks such as message acknowledgment and message numbers. A detailed comparison of both specifications can be found in [46, 139].

Web Service Transactions

In several business scenarios, it is important to coordinate multi-party message exchanges between distributed participants, which can be Web Services and their clients. When these message exchanges should achieve a common objective coordination becomes important.

WS-Coordination [63] provides a generic framework for coordinating dis- tributed activities. WS-Coordination is extensible, i.e., new coordination pro- tocols (e.g., for short-running atomic transactions) can be plugged into the framework. WS-Coordination defines three main elements:

• The coordination context is a shared context that represents the coordi- nation. It includes a context identifier and the address of the registration service.

• The activation service is used by the initiator of the coordination to create a coordination context, which will be propagated to the participants as part of the application messages.

• The registration service is used by participants to register for a specific coordination protocol of a given coordination type, e.g., for the completion protocol of atomic transactions [137].

There are two WS-* specifications that leverage WS-Coordination: WS- AtomicTransaction [137], which supports short-running atomic transactions and WS-BusinessActivity [138], which supports long-running compensation-based transactions.

The atomic transaction coordination type comprises three protocols for sup- porting atomic distributed transactions with the traditional ACID properties: a completion protocol to initiate the commitment of a transaction and two 2-Phase-Commit protocols (volatile and durable) to decide whether the trans- action should be committed or aborted.

The business activity coordination type supports long-running distributed transactions. Unlike atomic transactions, business activities, which model cross- organizational transactions, do not lock resources until the completion of the transaction. These transactions are characterized by relaxed isolation, i.e., in- termediary results can be seen by other transactions. If a business activity has to be rolled back, the already completed parts of the transaction must be reversed using appropriate compensation logic.

WS-BusinessActivity defines two coordination types: AtomicOutcome, in which the transaction coordinator directs all participants uniformly to either close or compensate their work, and MixedOutcome, in which the coordinator can direct some participants to close and some others to compensate.

In addition, WS-BusinessActivity defines two coordination protocols. In the BusinessAgreementWithParticipantCompletion protocol, a participant informs the coordinator when it completes his/her part of the transaction. Then, the coordinator tells the participant to close or compensate. In BusinessAgreemen- tWithCoordinationCompletion, the participant waits until the coordinator tells him/her to complete.

Web Service Policy

Web Services need a means to publish their QoS requirements, capabilities, and preferences to potential clients. For example, a Web Service may need to tell clients that it supports reliable messaging and requires confidentiality through message encryption.

Such policies cannot be expressed in WSDL, which covers only the func- tional interface of a Web Service. WS-Policy [113] provides a generic model and an extensible XML syntax for describing the policies of a Web Service in a declarative way.

In WS-Policy, a policy expression is a collection of one or more policy asser- tions that can be combined using policy operators. A policy assertion represents a domain-specific capability, requirement, or preference. Assertion languages such as WS-SecurityPolicy [44] define domain-specific assertions, e.g., for secu- rity, reliable messaging, transactions, etc.

The WS-PolicyAttachment [45] specification defines mechanisms for associ- ating policies with subjects such as WSDL documents, UDDI entries, or any other resource. In internal attachment, policy annotations are used in an XML

document to directly attach policies to subjects that are defined in that docu- ment. In external attachment, policies are attached to subjects using an external binding from outside the documents where the subjects are defined.