This chapter is from the book
This chapter is from the book
This chapter is from the book
3.6 Quality of Service
Specifications in this domain are related to the quality of the experience associated with interaction with a Web service. The services in this layer specify the requirements that are associated with the overall reliability of Web services. The specific issues involving this layer include security, reliability of message delivery, and support for transactions (guaranteeing and agreeing on the outcome of a business application).
3.6.1 WS-Security
Security is of fundamental concern in enterprise computing. WS-Security is the basic building block for secure Web services. Today, most distributed Web services rely on transport-level support for security functions (for example, HTTPS and BASIC-Auth authentication). These approaches to security provide a basic minimum for secure communication, and the level of function they provide is significantly less than that provided by existing middleware and distributed environments. WS-Security uses existing security models (such as Kerberos and X509). The specifications concretely define how to use the existing models in an interoperable way. Multihop, multiparty Web service computations cannot be secure without WS-Security.
Security relies on predefined trust relationships. Kerberos works because participants trust the Kerberos Key Distribution Center. Public Key Infrastructure (PKI) works because participants trust the root certificate authorities. WS-Trust defines an extensible model for setting up and verifying trust relationships. The key concept in WS-Trust is a Security Token Service (STS). An STS is a distinguished Web service that issues, exchanges, and validates security tokens. WS-Trust allows Web services to set up and agree on which security servers they trust, and to rely on these servers.
Some Web service scenarios involve a short sporadic exchange of a few messages. WS-Security readily supports this model. Other scenarios involve long, multimessage conversations between the Web services. WS-Security also supports this model, but the solution is not optimal.
Protocols such as HTTP/S use public keys to perform a simple negotiation that defines conversation-specific keys. This key exchange allows more efficient security implementations and decreases the amount of information encrypted with a specific set of keys. WS-SecureConversation provides similar support for WS-Security. Participants often use WS-Security with public keys to start a conversation or session, and they use WS-SecureConversation to agree on session specific keys for signing and encrypting information.
WS-Federation allows a set of organizations to establish a single, virtual security domain. For example, a travel agent, an airline, and a hotel chain might set up such a federation. An end user who logs into any member of the federation has effectively logged into all of the members. WS-Federation defines several models for providing federated security through protocols between WS-Trust and WS-SecureConversation topologies. In addition, customers often have "properties" when they deal with an enterprise, and WS-Federation allows the setting up of a federated property space. This allows each participant to have secure controlled access to each member’s property information about the end users.
The WS-Security family of specifications is discussed in detail in Chapters 12, "Security," and 13, "Advanced Security."
3.6.2 Reliable Messaging
In the Internet world, communication channels are typically unreliable. Connections break, messages fail to be delivered or are delivered more than once, and perhaps in a different sequence to that in which they were sent. Communication can become even more of an issue when the exchange of messages spans multiple transport layer connections. Although techniques for ensuring reliable delivery of messages are reasonably well understood and available in some messaging middleware products today (such as IBM WebsphereMQ), messaging reliability is still a problem. If messaging reliability is addressed by Web service developers who are incorporating techniques to deal with this directly into the services they develop, there is no guarantee that developers of different Web services will make the consistent choices about the approach to adopt. The outcome might not guarantee end-to-end reliable interoperable messaging. Even in cases in which the application developers defer dealing with the reliable messaging to messaging middleware, different middleware products from different suppliers do not necessarily offer a consistent approach to dealing with the problem. Again, this might preclude reliable message exchange between applications that are using different message-oriented middleware.
WS-ReliableMessaging addresses these issues and defines protocols that enable Web services to ensure reliable, interoperable exchange of messages with specified delivery assurances. The specification defines three basic assurances:
In-order delivery—The messages are delivered in the same order in which they were sent.
At least once delivery—Each message that is sent is delivered at least one time.
At most once delivery—No duplicate messages are delivered.
You can combine these assurances to give additional ones. For example, combining at least once and at most once gives exactly one delivery of a message. The protocol enables messaging middleware vendors to ease application development and deployment for Web services by providing services that implement these protocols, possibly layered over their existing proprietary message exchange protocols. WS-Reliable Messaging protocols allow different operating and middleware systems to reliably exchange messages, thereby bridging different infrastructures into a single, logically complete, end-to-end model for Web services reliable messaging.
WS-ReliableMessaging is discussed in detail in Chapter 10, "Reliable Messaging."
3.6.3 Transactions
Dealing with many of today’s business scenarios necessitates the development of applications that consist of multiple Web services exchanging many messages. An example might be a group of financial institutions setting up a financial offering that involves insurance policies, annuities, checking accounts, and brokerage accounts. Such applications can be complex, executing across heterogeneous, loosely coupled distributed systems that are prone to failure, and introducing significant reliability problems. For such applications, you must deal with the failure of any component Web service of the application within the context of the whole application. A coordinated orchestration of the outcome of the participating services that make up the business application is essential so that a coherent outcome of the whole business application can be agreed upon and guaranteed. Therefore, it is important that the Web services involved are able to do the following:
Start new tasks, the execution and disposition of which are coordinated with other tasks.
Agree on the outcome of the computation. For example, does everyone agree that the financial packages were set up?
WS-Coordination, WS-AtomicTransaction, and WS-BusinessActivity define protocols that are designed specifically to address these requirements.
WS-Coordination is a general mechanism for initiating and agreeing on the outcome of multiparty, multimessage Web service tasks. WS-Coordination has three key elements:
A coordination context—This is a message element that is associated with exchanges during the interaction of Web services. This coordination context contains the WS-Addressing endpoint reference of a coordination service, in addition to the information that identifies the specific task being coordinated.
A coordinator service—This provides a service to start a coordinated task, terminate a coordinated task, allow participants to register in a task, and produce a coordination context that is part of all messages exchanged within a group of participants.
An interface—Participating services can use the interface to inform them of an outcome that all of the participants have agreed upon.
Although WS-Coordination is a general framework and capability, WS-AtomicTransaction and WS-BusinessActivity are two particular protocols that compose with and extend the WS-Coordination protocol to define specific ways to reach overall outcome agreement. They extend this framework to allow the participants in the distributed computation to determine outcome robustly .
WS-AtomicTransaction defines a specific set of protocols that plug into WS-Coordination to implement the traditional two-phase atomic ACID transaction protocols. However, traditional atomic transactions and the WS-AtomicTransaction protocol are not always suitable. For example, this protocol is generally not appropriate for use with many types of business transactions. Transaction protocols for business transactions have to deal with long-lived activities. These differ from atomic transactions in that such activities can take much longer to complete. Therefore, to minimize latency of access by other potential users of the resources being used by Web services participating in the activity, you need to make the results of interim operations visible to others before the overall activity has completed. In light of this, you can introduce mechanisms for fault and compensation handling to reverse the effects of tasks that were completed previously within a business activity (such as compensation or reconciliation). WS-BusinessActivity defines a specific set of protocols that plug into the WS-Coordination model to provide such long-running, compensation-based transaction protocols. For example, although WS-BPEL defines a transaction model for business processes, it is WS-BusinessActivity that specifies the corresponding protocol rendering. This, again, is an example for the composeability of the Web services specifications.
WS-Coordination and Transaction specifications are covered in detail in Chapter 11, "Transactions."