Other GXA Specifications

We’ve looked at the five GXA specifications that are implemented in WSE and are currently most relevant to us. As you’ll recall from Table 12-1, the GXA portfolio has six other specifications, as well as a second addendum to the WS-Security specification.

It doesn’t make sense to spend a great deal of time looking at these specifications because they have no implementation yet. (Some people would argue that even with an implementation, we still wouldn’t really need to understand them.) We’ll look at them briefly, and you can go to http://msdn.microsoft.com /webservices/understanding/gxa/ default.aspx to see the complete specifications.

WS-Addressing

All of the Web services we’ve built so far have an address that belongs to the HTTP transport protocol (as in http://host:port/file). As the use of Web services becomes more prevalent, you’re likely to want to use protocols that don’t fit into the protocol://host:port/ file paradigm. For example, what if you want to send a request to a Web service to a message queue?

The WS-Addressing specification solves this problem by defining two constructs that take the messaging information from the underlying transport protocol and represent it in a transport-neutral way.

The first construct we’ll look at is the endpoint reference. An endpoint is any object that you can target with a request for a Web service, and the endpoint reference conveys all of the information required to access that endpoint.

The second construct that the WS-Addressing specification defines, the message information header, is used in messages to and from Web services. It allows the addressing of the message using an endpoint reference construct and also provide details of the message characteristics for the source and destination. It can also be used to provide a unique identity for a message.

WS-Addressing was in the most recent batch of specifications along with WS-ReliableMessaging and WS-ReliableMessaging is the only specification that makes use of it. As the other specifications are updated, they will likely use the WS-Addressing specification to provide standardized addressing across all the available transport protocols.

Note

The WS-Addressing specification was released as a public specification by BEA Systems, IBM, and Microsoft on March 13, 2003. This version of the specification is in the http://schemas.xmlsoap.org/ws/2003/03/addressing namespace and usually takes the wsa prefix.

WS-Coordination

The WS-Coordination specification provides a framework for distributed applications to coordinate their efforts. What it doesn’t do is specify the coordination between the distributed applications—that is left to other specifications, such as WS-Transaction.

WS-Coordination defines a context for all of the details required to specify the coordination. You specify how long the coordination request will be valid, the coordination type, and the address details for the registration service that the remote applications will connect to in order to receive the details of the coordination.

The coordination type is a reference to the specifics of the coordination effort, which are defined in other specifications. The WS-Transaction specification, which we’ll look at shortly, defines two coordination types; other specifications are free to define their own coordination types as required.

When the registration service receives a request, it returns the address details of the Web service to connect to as well as the specifics of the coordination effort. The WS- Coordination specification defines only the process of setting up the coordination— other specifications control what the coordination effort actually does.

Note

WS-Coordination is still a draft specification; the latest version was released by BEA Systems, IBM, and Microsoft on August 9, 2002. This version of the specification is in the http://schemas.xmlsoap.org/ws/2002/08/wscoor namespace and usually takes the wscoor prefix.

WS-Inspection

The WS-Inspection specification is a replacement for the Microsoft Discovery (DISCO) specification, which we looked at in Chapter 4.

You can think of the WS-Inspection specification as DISCO on steroids. Like DISCO, WS-Inspection lets you create documents that detail the Web services available at a particular location—although it does not specify the method used to describe the Web services. And as with DISCO, if you don’t know the address of the Web service you’re requesting, you still need to look at using some other mechanism, such as UDDI, to discover the Web service.

The WS-Inspection specification defines an inspection document that contains the details of the Web services that are available.

You saw in Chapter 4 why DISCO has fallen by the wayside and why we’ve moved to the use of UDDI to discover Web services. With WS-Inspection being almost a direct replacement for DISCO, it is hard to see where WS-Inspection really fits into the overall scheme of things. We still need UDDI to discover Web services when we know nothing about the Web service. A WS-Inspection document will probably end up as the document that is referenced from UDDI—you’ll interrogate the WS-Inspection document to retrieve the WSDL definition of the Web service. This offers the best of both worlds— you’ll have a reference to your Web service within the UDDI Directory, and you’ll also have a local document that you can reference directly that contains the details of your Web service.

Note

The WS-Inspection specification was released as a public specification by IBM and Microsoft on November 1, 2001. This version of the specification is in the http://schemas.xmlsoap.org/ws/2001/10/inspection namespace and usually takes the wsil prefix.

WS-Policy

Although the GXA specifications we’ve discussed so far will allow you to develop complex Web services once they have a concrete implementation, they don’t give you a way to inform users of your Web services that you are using the GXA specifications or to tell them your requirements. For example, a Web service might require all messages to be signed with an X509 certificate, but you need a way to communicate this requirement to users. This is where WS-Policy comes in.

WS-Policy allows you to define policy statements for Web services. A policy statement contains a series of policy assertions that detail what the Web service expects. The specification is open enough that you can define any assertions you want—from assertions that define what the Web service requires of the messages it receives all the way to assertions that deal with privacy policy and quality-of-service guarantees.

Although WS-Policy defines the framework for adding policy assertions to Web services, it does not define any assertions—that’s up to the individual specifications. You’ll see this when we look at WS-ReliableMessaging and the new version of WS-Security, which were released after the WS-Policy specification and define policy assertions that can be applied to Web services that implement those specifications.

Note

The WS-Policy framework was released as a public specification by BEA Systems, IBM, Microsoft, and SAP AG on December 18, 2002. This version of the specification is in the http://schemas.xmlsoap.org/ws/2002/12/policy namespace and usually takes the wsp prefix. In addition to the base WS-Policy specification, the complementary specifications WS-PolicyAssertions and WS-PolicyAttachment also use this namespace.

WS-PolicyAssertions

As we mentioned, the WS-Policy specification doesn’t specify any assertions, but the complementary WS-PolicyAssertions specification defines four common assertions that you can use:

• Language assertion Lets you specify that the messages you receive must be in a given language (such as English or French) and specify whether you’ll accept requests in a variety of languages.

• MessagePredicate assertion Lets you specify that all messages you receive must match some precondition that the sender should check before sending the message.

• SpecVersion assertion Lets you specify which version of a particular specification you’re using. Different versions of a specification might handle certain elements differently, and this assertion lets you specify which version messages must be using.

• TextEncoding assertion Lets you specify that any messages sent must be encoded using a specific text format (such as ISO-8859-1 or UTF8).

WS-PolicyAttachment

Released at the same time as WS-Policy and WS-PolicyAssertions, the WS-PolicyAttachment specification defines a way to add assertions to WSDL and UDDI descriptions. It allows you to add your policy assertions at a higher level than the Web service so users can determine whether your Web service is suitable without having to interrogate the Web service directly to retrieve the policy assertions.

WS-ReliableMessaging

One problem with Web services is that they offer no reliable means of message delivery—if the delivery of a message fails, no mechanism is in place to automatically retry delivery. The WS-ReliableMessaging specification fills that gap.

WS-ReliableMessaging defines a mechanism for transferring messages reliably between a source and a destination and for an acknowledgement to be returned indicating that the message was delivered successfully.

A message transmitted from a source to a destination has an embedded sequence number (an incrementing integer). The sequence numbers control the overall process— the last message in the exchange is flagged as the last message, and the destination informs the source if any of the messages in the sequence were missed. The sender then retransmits any missed messages, and the destination acknowledges that the messages were received.

This specification was released after the WS-Policy specification and uses that framework to define its own policy assertions. The assertions defined by WS-Reliable detail your requirements—how many times a message send can be retried, how long a sequence is valid, the maximum gap between messages, and so on.

Note

The WS-ReliableMessaging specification was released by BEA Systems, IBM, Microsoft, and TIBCO Software on March 13, 2003. This version of the specification is in the http://schemas.xmlsoap.org /ws/2003/03/rm namespace and usually takes the wsrm prefix.

WS-Security

Two days after the release of the WS-Security specification, the “Security in a Web Services World” roadmap (available at http://msdn.microsoft.com/library /en-us/dnwssecur/ html/securitywhitepaper.asp) was published. It details the way forward for security and provides an overview of six additional specifications built on top of the WS-Security specification that provide a more secure and flexible security framework.

Those six specifications include the WS-Policy specification, which we just looked at, and which the roadmap describes as a fundamental requirement for the future of security. Since the roadmap was released, the status of WS-Policy has been upgraded beyond being just a child of the WS-Security specification. The other five specifications still belong to the WS-Security fold.

In December 2002, simultaneous with the release of WS-Policy, a new version of the WS-Security specification was released. It consists of WS-SecurityPolicy, an addendum to WS-Security that defines various policy assertions, and WS-SecureConversation and WS-Trust, two of the five specifications in the roadmap released eight months earlier.

Note

WS-SecurityPolicy was released as a public specification by IBM, Microsoft, RSA Security, and VeriSign on December 18, 2002. This is an addendum to WS-Security and has the same prefix, wsse, as previous versions, but has a new namespace, http://schemas.xmlsoap.org/ws/2002/12/secext. WS-SecureConversation and WS-Trust also share this namespace and prefix.

In the next sections, we’ll look at the released specifications in some detail. First, however, let’s look at a brief description of the three as-yet unreleased specifications.

• WS-Authorization Describes how authorization policies for a Web service are specified and managed.

• WS-Federation Builds on the facilities provided by WS-Security, WS-Policy, WS-Trust, and WS-SecureConversation to provide federation between different security token issuers.

• WS-Privacy Uses a combination of WS-Security, WS-Policy, and WS- Trust to allow you to define privacy policies for Web services and use the WS-Trust specification to validate the privacy claims made by Web services and users.

WS-SecureConversation

Although the security mechanisms defined in the WS-Security specification (and its two addendums) allow you to provide authentication, signing, and encryption services, they are not ideal in terms of conducting conversations between two endpoints. WS-Security is susceptible to various security attacks—the longer the conversation between two endpoints, the greater the likelihood of the security of the conversation being compromised.

The WS-SecureConversation specification addresses several of these security issues by defining a mechanism for establishing and sharing security contexts and for deriving session keys from these contexts.

Before a conversation starts, a security context is created (by a security token service, by one of the endpoints, or by negotiation), and this context is used to generate session keys that are used to sign and encrypt the messages that form the conversation. These keys are created from details shared between the two endpoints and can be changed on an ad hoc basis; if the two endpoints use the same security context, the derived keys will be valid for both endpoints.

WS-SecurityPolicy

WS-SecurityPolicy is not really a specification; it is actually a second addendum to the WS-Security specification. WS-Security was released before WS-Policy, so this addendum details the policy assertions that apply to WS-Security.

Six policy assertions are defined in the addendum:

• Confidentiality assertion Specifies that certain parts of the message must be encrypted and specifies the required encryption method.

• Integrity assertion Specifies that certain parts of the message must be signed and specifies which type of signing is acceptable.

• MessageAge assertion Specifies the maximum elapsed time between a message being transmitted and being received.

• SecurityHeader assertion The <wsse:Security> SOAP header can contain a lot of different information, and this assertion allows you to specify the parts of the header that are required.

• SecurityToken assertion Specifies that the sender must attach a SecurityToken to the message. You can specify the type or types of SecurityToken that are acceptable.

• Visibility assertion Specifies that parts of the message must be unencrypted.

WS-Trust

We now have a fairly complete and usable security model for Web services, but we still have no means of requesting and issuing security tokens. So far we have had to acquire the security tokens by “offline” means—outside of the Web services processing model. WS-Trust addresses this by defining a mechanism for requesting and issuing security tokens.

WS-Transaction

When we looked at the WS-Coordination specification, we said that without other specifications you can’t actually do an awful lot. The WS-Transaction specification is one of these other specifications.

WS-Transaction defines two new coordination types that allow you to perform transactions: the atomic transaction (AT) and business activity (BA) types.

Using the AT coordination type, you can specify that the coordination effort you’re engaged in be a transaction and that all parts of the transaction must be successful before the results of the transaction are finalized. When you use atomic transactions, you’re usually involved in a short interchange that requires little time and few resources.

In contrast, the BA coordination type allows you to define a far more complex transaction that involves multiple atomic transactions in what, for want of a better term, is a business process.

The distinction between an atomic transaction and a business process can be quite loose, but a business process, although atomic, doesn’t really fit the abort-retry mechanism of atomic transactions. With a business process, you’re more likely to want the overall process to continue even if one part of the process, an atomic transaction, fails.

Note

WS-Transaction is still a draft specification. The latest version was released by BEA Systems, IBM, and Microsoft on August 9, 2002. This version of the specification has two namespaces, http: //schemas.xmlsoap.org/ws/2002/08/wsba and http://schemas.xmlsoap.org/ws/2002/08/wstx, and these take the wsba and wstx prefixes, respectively.