Web Services Security and More: The Global XML Web Services Architecture (GXA)

Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

Introduction

In April 2001, the W3C conducted a Web Services Workshop whose aim was to explore the direction the W3C should take to standardize the emerging Web services architecture. This was a pivotal event in the Web services world, as one of its outcomes was a set of specifications in October 2001 that presented an architecture for the next generation of XML Web Services. This architecture is known as the Global XML Web Services Architecture, (GXA).

For quite some time, there has been a growing need for consistent support of more secure Web services—especially at the levels of inter-enterprise trust and business policy agreement. GXA, as an application-level protocol framework that is built on the foundation of XML and SOAP, helps satisfy this need by providing a consistent model for building infrastructure-level protocols for Web services and applications. By doing so, GXA “fills the gap” in the current Web services stack. Because GXA is built on top of SOAP, it is also “transport-neutral”—that is, it does not rely on any application-level transport protocol such as HTTP or SMTP to carry out its specified functionality.

GXA specifications are authored by Microsoft, IBM, Verisign, BEA Systems, RSA Security, and SAP (in various combinations, with Microsoft as an author on all specifications). One of the most valuable aspects of the GXA specifications is that they are designed to be “protocol building blocks” that can be adopted piecemeal or en masse. The GXA specifications also leverage existing specifications such as ITU-T X.509, W3C XML Signature, and W3C XML Encryption for providing required functionality.

Since the initial set of specifications in October 2001, 12 additional GXA specifications have been released—six in December 2002, and two in March 2003. Several more also have been announced as forthcoming. This is indicated in the figure below, which indicates various milestones of GXA:

This article provides highlights from the majority of those specifications that were released up to (and including) December 2002, while those released in March 2003 (WS-ReliableMessaging and WS-Addressing) will be covered in a later article. XML examples that illustrate the main concepts are provided for each covered specification. For brevity, some of these examples denote fragments rather than entire SOAP envelopes.

A Snapshot of the GXA Specifications

The GXA specifications can be grouped in seven main “concentrations.” Each concentration is listed below, along with its specifications and a brief description of each specification. Those specifications that have been announced but have not yet been released are marked accordingly.

The Cornerstone of GXA: WS-Security

Many Web service interactions today utilize Secure Socket Layer/Transport Layer Security (SSL/TLS) for their transmission security requirements. While this technique works well in point-to-point scenarios, there is a need to maintain secure contexts over multi-point message paths where trust domains need to be crossed (such as between organizations)—that is, to support end-to-end message-level security, not just transport-level security. This need is addressed by the WS-Security specification, which was originally released in October by 2001 by Microsoft, IBM, and Verisign.

Secure Message Exchanges

WS-Security defines a standard set of SOAP extensions that implement message-level integrity and confidentiality for secure message exchanges. WS-Security forms the basis for many other GXA specifications, and thus is considered “The Cornerstone of GXA.” This is indicated in the figure below, which shows GXA’s placement in the “Web Services Stack:”

The figure below demonstrates how WS-Security enables the maintenance of a secure context over a multi-point message path. It denotes three Web participants—a “sender” Web service, an “intermediary” Web service, and a “receiver” Web service. Rather than carrying a separate security context from one participant to another (as would be necessary using SSL/TLS), WS-Security allows for the security context to be carried over the entire interaction as a “security umbrella:”

WS-Security is designed to support a wide variety of security models—i.e. it is designed to support multiple security token formats, multiple trust domains, multiple signature formats, and multiple encryption technologies. This includes existing security models, as well as security models that may be released in the future. Examples of “security tokens” are: a username/password, an X.509 certificate, a Kerberos ticket, or a Security Assertion Markup Language (SAML) assertion.

XML Example: Username/Password

WS-Security defines a <Security> header block within a SOAP message that contains all security-related information. For example, the following <Security> header is used to define direct trust using a username and password (all namespace declarations in this article are omitted for brevity):

<?xml version="1.0" encoding="utf-8"?>
<S:Envelope
  <S:Header>
    <wsse:Security>
    <wsse:UsernameToken wsu_Id="MyID">
      <wsse:Username>Zoe</wsse:Username>
      <wsse:Password>MyPassword</wsse:Password>
      <wsse:Nonce>FKJh...</wsse:Nonce>
      <wsu:Created>2001-10-13T09:00:00Z</wsu:Created>
    </wsse:UsernameToken>  .....  </wsse:Security>
  </S:Header>
    <S:Body wsu_Id="MsgBody">  .....  </S:Body>
</S:Envelope>

In the above example, the username and password are supplied along with a nonce and timestamp. A nonce is a parameter that varies with time, intended to limit or prevent the unauthorized replay or reproduction of a file (this includes what is common referred to as a “replay attack”). Because the password is clear text, it should be sent on a secured channel; otherwise, it should be obscured by creating a password digest as described in the WS-Security specification—by creating a SHA1 digest using the nonce, timestamp and password).

XML Example: W3C XML Signature

The following example illustrates the use of W3C XML Signature by WS-Security to specify message-level integrity:

<?xml version="1.0" encoding="utf-8"?>
<S:Envelope
  <S:Header>
   <wsse:Security>
      <wsse:BinarySecurityToken
            ValueType="wsse:X509v3"
            EncodingType="wsse:Base64Binary"
            wsu_Id="X509Token">
            MIIEZzCCA9CgAwIBAgIQEmtJZc0rqrKh5i...
     </wsse:BinarySecurityToken>
      <ds:Signature>
                   .....
      <ds:SignatureValue>BL8jdfToEb1l/vXcMZNNjPOV...
      </ds:SignatureValue>  .....  </ds:Signature>
    </wsse:Security>
  </S:Header>
  <S:Body wsu_Id="MsgBody">  .....  </S:Body>
</S:Envelope>

In the above example, the <wsse:BinarySecurityToken> element is used to describe a binary authentication token (such as an X.509 certificate or Kerberos ticket). The “ValueType” attribute above indicates an X.509 certificate, while the “EncodingType” attributes indicates that the encoding format of the certificate is XML Schema base64 encoding. We assume here that the X.509 certificate contains the key that is used to create the digital signature—that is, it is “cryptographically bound” to the signature. In addition to specifying the digital signature, the W3C XML Signature <ds:Signature> element includes several items that are not listed in this example such as canonicalization method, signature method, and digest method.

WS-Security also specifies additional capabilities, such as use of the W3C XML Encryption specification for message confidentiality and message timestamps to indicate the “freshness” of a message.

Specification Location

The WS-Security specification is currently being developed under OASIS, and can be found at http://www.oasis-open.org/committees/wss.

Policy-Related Extensions to WS-Security: WS-SecurityPolicy

In message exchange, it would be very advantageous if the “sender” Web service knew what the “receiver” Web service required or expected regarding items such as token types, or what portions of a message must be signed or encrypted. This is addressed by the WS-SecurityPolicy specification, released in December by 2002 by Microsoft, IBM, Verisign, and RSA Security.

Policy Assertions

WS-SecurityPolicy builds on WS-Security by defining how to describe policies related to various features defined in the WS-Security specification, and is therefore considered an “addendum” to the WS-Security specification. It defines several types of policy assertions that represent an individual preference, requirement, capability, or other property of a Web service. The following are examples of the types of policy assertions that are specified by WS-SecurityPolicy:

• SecurityToken Assertion: Specifies security token types required/accepted by a Web service.
• Integrity Assertion: Specifies that specific portions of a message must be signed, and specific algorithms/keys to be used (for example, the SHA-1 algorithm and the RSA key).
• Message Age Assertion: Specifies the acceptable time period before messages are declared “stale” and discarded.

XML Example: SecurityToken Assertion

The following example illustrates a “SecurityToken” assertion that specifies that the Web service accepts X.509 certificates for authentication (the “Preference” attribute will be described later in this article):

<wsse:SecurityToken TokenType="wsse:X509v3"
                    wsp_Usage="wsp:Required" wsp_Preference="50"/>

Specification Location

The WS-SecurityPolicy specification can be found at http://msdn.microsoft.com/ws/2002/12/ws-security-policy.

Expressing Enterprise Security Policies: WS-Policy

Policy assertions by themselves cannot be acted upon. Rather, they need to be aggregated into units called policy expressions, which are then used as a framework for the creation of policies. This is the focus of the WS-Policy specification, released in December by 2002 by Microsoft, IBM, BEA Systems, and SAP.

Policy Hierarchy

WS-Policy describes a policy hierarchy whose base is a policy assertion, and which contains the following components:

• Policy Statement: A group of policy assertions.
• Policy: A set of domain-specific policy statements.
• Policy Expression: An XML serialization that represents one or more policy statements.

The figure below represents the above concepts in a graphical form:

XML Example: Policy Expression

The following example illustrates a policy expression that uses “SecurityToken” assertions:

<wsp:Policy>
  <wsp:ExactlyOne>
    <wsse:SecurityToken TokenType="wsse:X509v3"
          wsp_Usage="wsp:Required" wsp_Preference="50"/>
    <wsse:SecurityToken TokenType="wsse:Kerberosv5TGT"
          wsp_Usage="wsp:Required" wsp_Preference="10"/>
  </wsp:ExactlyOne>
</wsp:Policy>

In the above example, the <wsp:ExactlyOne> element (known as a “policy operator”) indicates that a valid policy that is constructed from this policy expression can contain any (but not more than one) of the assertions listed in the policy expression. That is, a Web service that uses the above policy expression to construct a policy can accept either X.509 certificates or Kerberos tickets for authentication. Additionally, the “preference” of this policy is that an X.509 certificate is used for authentication, due to its higher “Preference” value of 50.

In addition to the “ExactlyOne” policy operator, values of “All” (all child elements must be satisfied) or “OneOrMore” (at least one of the child elements must be satisfied) may be used.

Specification Location

The WS-Policy specification can be found at http://msdn.microsoft.com/ws/2002/12/Policy.

Message-Related Assertions: WS-PolicyAssertions

There are additional types of assertions specified within GXA that are not directly related to security, but rather to aspects such as character encoding, natural (spoken) language, and specification versions. These types of assertions are described in the WS-PolicyAssertions specification, released in December by 2002 by Microsoft, IBM, BEA Systems, and SAP.

Policy Assertions

WS-PolicyAssertions specifies policy assertions such as the following:

• TextEncoding Assertion: Indicates which character encodings (for example, ISO-8859-1, UTF-8, and UTF-16) are supported by a Web service.
• Language Assertion: Specifies supported (spoken) natural languages.
• SpecVersion Assertion: Indicates which versions of a specification a Web service supports.
• MessagePredicate Assertion: Expresses predicates (pre-conditions) to which a message must conform.

XML Example: TextEncoding Assertion

The following example illustrates a “TextEncoding” assertion that specifies that the Web service supports the ISO-8859-5 character set:

<wsp:TextEncoding wsp_Usage="wsp:Required" Encoding="iso-8859-5"/>

XML Example: MessagePredicate Assertion

The following example illustrates the use of the “MessagePredicate” assertion to express that messages to which this assertion applies must contain exactly one WS-Security <Security> header element:

<wsp:MessagePredicate wsp_Usage="wsp:Required">
     count(wsp:GetHeader(.)/wsse:Security) = 1
</wsp:MessagePredicate>

In the above example, the “wsp:GetHeader (node)” function is one of several normative functions for use with XPath defined in the WS-PolicyAssertions specification. It returns the SOAP envelope <Header> element from the specified Envelope element. The following are some of the other functions that are specified:

• wsp:IsInHeader (node): Returns true if the specified node is in the SOAP envelope <Header> element from the specified Envelope element.
• wsp:IsMandatoryHeaderBlock (node): Returns true if the specified node is in the SOAP envelope <Body> element from the specified Envelope element.
• wsp:IsRoleURIForUltimateReceiver (node, string): Returns true/false depending on whether or not the specified role maps to the predefined “ultimate receiver” for the version of SOAP used by the supplied message.

XML Example: Policy Expression

Finally, the following example illustrates a policy expression that includes the two assertions shown above:

<wsp:Policy>
  <wsp:All>
    <wsp:TextEncoding wsp_Usage="wsp:Required"
         Encoding="iso-8859-5"/>
    <wsp:MessagePredicate wsp_Usage="wsp:Required">
         count(wsp:GetHeader(.)/wsse:Security) = 1
    </wsp:MessagePredicate>
  </wsp:All>
</wsp:Policy>

Specification Location

The WS-PolicyAssertions specification can be found at http://msdn.microsoft.com/ws/2002/12/PolicyAssertions.

Policies Applied: WS-PolicyAttachment

Now we begin to answer the question: How can all of the policy concepts presented above be associated with Web service definitions such as those described by WSDL and UDDI? This is the focus of the WS-PolicyAttachment specification, released in December by 2002 by Microsoft, IBM, BEA Systems, and SAP.

Attachment Mechanisms

WS-PolicyAttachment describes three specific “attachment mechanisms” for using policy expressions with existing XML Web service technologies:

• How to reference policies from WSDL definitions
• How to associate policies with specific instances of WSDL services
• How to associate policies with UDDI entities

XML Example: WSDL Endpoint

WS-PolicyAttachment defines a <wsp:PolicyAttachment> element to associate a policy expression with a resource, independently of the definition and/or representation of that resource. In the following example, a policy expression is associated with a WSDL endpoint.

<wsp:PolicyAttachment>
   <wsp:AppliesTo>
       <wsp:EndpointReference>
          <wsp:ServiceName Name="InventoryService"/>
          <wsp:PortType Name="InventoryPortType"/>
          <wsp:Address URI="http://www.xyz.com/acct"/>
       </wsp:EndpointReference>
   </wsp:AppliesTo>
   <wsp:PolicyReference Ref="http://www.xyz.com/acct-policy.xml"/>
</wsp:PolicyAttachment>

In the above example, the policy expression referred to in the <wsp:PolicyReference> element will apply to all output resources of a service that implements the “InventoryPortType” portType on the “InventoryService” service located at address http://www.xyz.com/acct.

Additionally, policy expressions can be associated with wsdl:message and wsdl:part elements, for more “granular” policy attachment.

XML Example: UDDI tModel and businessService

Policy expressions also can be represented as tModels within a UDDI registry, and then be associated with entities in the registry. The following example shows the creation of a UDDI tModel to represent a policy expression (the reader is referred to the UDDI specifications for more information on the UDDI structures):

<tModel tModelKey="uuid:bd3966a8-faa5-416e-9772-128554343571">
   <name>http://schemas.xmlsoap.org/ws/2002/07/policytmodel</name>
   <description>WS-PolicyAttachment policy expression</description>
</tModel>

Once this is done, the policy expression can be associated with entities in the UDDI registry through the mechanisms provided by UDDI. In the following example, the policy expression is associated with a businessService using the service’s categoryBag:

<businessService>
  <name>MyService</name>
  <description>...</description>
  <bindingTemplates>...</bindingTemplates>
  <categoryBag>
    <keyedReference
       tModelKey="uuid:bd3966a8-faa5-416e-9772-128554343571"
       keyName="http://schemas.xmlsoap.org/ws/2002/07/policytmodel"
       keyValue="http://www.example.com/myservice/policy"/>
  </categoryBag>
</tModel>

In the above example, the “tModelKey” and “keyName” attribute values below match the “tModelKey” and “name” attribute values (respectively) of the tModel shown in the previous example. This signifies that the categoryBag involves a WS-PolicyAttachment policy expression. The “keyValue” attribute value is the URI of the actual policy expression that is being associated with the businessService.

A policy expression can also be associated with a UDDI bindingTemplate, which represents an individual Web service and provides the information necessary for applications to bind to and interact with the Web service being described.

Specification Location

The WS-PolicyAttachment specification can be found at http://msdn.microsoft.com/ws/2002/12/PolicyAttachment.

Managing Trust Relationships: WS-Trust

All of the concepts discussed to this point are highly important, but they cannot be useful unless there is a trust relationship between two parties. This is the focus of WS-Trust specification, released in December by 2002 by Microsoft, IBM, Verisign, and RSA Security.

Trust Engine/Security Token Service

WS-Trust introduces the notion of a trust engine, a conceptual component of a Web service that evaluates the security-related aspects of a message. A trust engine verifies that:

• The claims in a security token are sufficient to comply with the policy and that the message conforms to the policy.
• The attributes of the claimant are proven by the signatures.
• The issuers of the security tokens are trusted to issue the claims they have made.

For example, if a policy stated that only Kerberos tickets were accepted as a security token, the trust engine of a Web service would enforce this requirement for all incoming messages. The WS-Trust specification also introduces the notion of a security token service that issues security tokens based on trust, similar to a certificate authority (CA).

The figure below depicts a “sender” and “receiver” Web service, each with its own trust engine. A security token service is also depicted, from which the sender Web service will request a security token to be used for its interaction with the receiver Web service. The sender Web service can request a security token based on the receiver Web service’s policies, using the mechanisms described earlier in this article. The sender Web service will use its trust engine to authenticate the security token service, while the receiver Web service will use its trust engine to authenticate the sender Web service.

XML Example: Security Token Request/Response

The following example demonstrates a request for a security token (X.509 certificate), and the response with the certificate. The <wsse:BinarySecurityToken> was seen earlier in the description of the WS-Security specification.

<wsse:RequestSecurityToken>
  <wsse:TokenType>wsse:X509v3</wsse:TokenType>
  <wsse:RequestType>wsse:ReqIssue</wsse:RequestType>
</wsse:RequestSecurityToken>

<wsse:RequestSecurityTokenResponse>
  <wsse:RequestedSecurityToken>
    <BinarySecurityToken ValueType="wsse:X509v3"
                         EncodingType="wsse:Base64Binary">
                         MIIEZzCCA9CgAwIBAgIQEmtJZc0...
    </BinarySecurityToken>
  </wsse:RequestedSecurityToken>
</wsse:RequestSecurityTokenResponse>

In the above example, the <wsse:RequestType> element value of “ReqIssue” denotes the issuance of a security token. Other valid values are “ReqValidate” (validate security token) and “ReqExchange” (exchange security token).

Challenges

In some cases, a security token service may choose to challenge the requestor of a security token. For example, this may occur if the security token service does not trust the nonce and timestamp (for example, the freshness) in the message. Or, the security token service may challenge the signature within the message. Challenge requests and responses are issued by specifying challenge and response elements within a <wsse:RequestSecurityTokenResponse> element, in a negotiation-type scenario.

XML Example: Signature Challenge

Signature challenges are processed using the <wsse:SignChallenge> element, as shown in the following example:

<wsse:SignChallenge>
  <wsse:Challenge>Describes the message parts to be
                  signed...</wsse:Challenge>
  <wsse:SecurityTokenReference>...</wsse:SecurityTokenReference>
</wsse:SignChallenge>

The <wsse:Challenge> element in the above example uses one of two possible mechanisms to describe the message parts to be signed: either an XPath expression, or one of several “message part selection functions” that are defined in the WS-PolicyAssertions specification. The <wsse:SecurityTokenReference> element is used to reference security tokens that are passed as part of the negotiation process. Once the sender receives this challenge, they would normally create a new signature that includes the specified message parts and return the new signature in a <wsse:SignChallengeResponse> element.

Specification Location

The WS-Trust specification can be found at http://msdn.microsoft.com/ws/2002/12/ws-trust.

Application-Level Routing: WS-Routing

SOAP by itself does not define an actual message path along which a SOAP message is to travel; rather, it relies on its underlying application layer protocols (such as HTTP or SMTP) to do so. However, these protocols each have their own mechanisms for defining message paths. That is, given four SOAP nodes—A, B, C, and D—a SOAP message generated by node A can indicate which parts of the message are meant for nodes B, C, and D, but not that that the message is to be sent from A to D via B and C as intermediaries. As GXA is transport-neutral, it cannot rely on SOAP’s underlying application layer protocols for specifying message paths.

The WS-Routing specification leverages the concept of a “SOAP intermediary” as defined in SOAP 1.2, therefore “raising up” the capability to define a message path to the SOAP layer and making it transport-neutral. It is a simple, stateless, SOAP-based protocol for routing SOAP messages in an asynchronous manner over a variety of transports. The WS-Routing specification was released in October 2001 by Microsoft.

SOAP Routers

WS-Routing (and the WS-Referral specification, discussed next) defines the concept of a SOAP router, which is a SOAP node that exposes SOAP message relaying as a Web service either as a standalone service or in combination with other services. WS-Routing also defines a new SOAP header named <path> that contains the following elements:

• from: Denotes the message originator
• from: Denotes the ultimate receiver
• fwd: Contains the forward message path
• rev: Contains the reverse message path, enabling two-way message exchange

The <wsrp:fwd> and <wsrp:rev> elements also contain <wsrp:via> elements to denote intermediaries.

XML Example: “path” SOAP Header

The following example demonstrates a “path” SOAP header:

<SOAP-ENV:Header>
  <wsrp:path>
    <wsrp:to>soap://D.com</wsrp:to>
    <wsrp:fwd>
      <wsrp:via>soap://B.com</wsrp:via>
      <wsrp:via>soap://C.com</wsrp:via>
    </wsrp:fwd>
    <wsrp:from>soap://A.com</wsrp:from>
    <wsrp:id>uuid:84b9f5d0-33fb-4a81-b02b-5b760641c1d6</wsrp:id>
  </wsrp:path>
</SOAP-ENV:Header>

In the above example, the message is to travel from soap://A.com to soap://D.com, passing through (“via”) intermediaries soap://B.com and soap://C.com. This may be done for purposes such as load balancing, if a Web service’s network address has changed, or for dynamic message path optimization (a “better” path suddenly exists).

XML Example: Reverse Paths

As the above message travels through each of the above nodes, each node may alter the “path” SOAP header to include its destination address in a <wsrp:rev> element, in case the message path needs to be reversed (for example, due to an error). In the following example, the message has just passed through node soap://A.com, and this node has entered its destination address in a <wsrp:rev> element:

<SOAP-ENV:Header>
  <wsrp:path>
    <wsrp:to>soap://D.com</wsrp:to>
    <wsrp:fwd>
      <wsrp:via>soap://B.com</wsrp:via>
      <wsrp:via>soap://C.com</wsrp:via>
     </wsrp:fwd>
     <wsrp:rev>
       <wsrp:via>soap://A.com</wsrp:via>
     </wsrp:rev>
    <wsrp:id>uuid:84b9f5d0-33fb-4a81-b02b-5b760641c1d6</wsrp:id>
  </wsrp:path>
</SOAP-ENV:Header>

Each successive node could also do so, adding its destination address to the <wsrp:rev> element to build a complete reverse path.

Specification Location

The WS-Routing specification can be found at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/ws-routing.asp.

Referral Statements: WS-Referral

The WS-Referral specification defines the mechanisms by which the message paths specified in WS-Routing can be dynamically discovered. More specifically, it defines mechanisms by which a Web service can insert, delete, and query routing entries in a SOAP router. The WS-Referral specification was released in October 2001 by Microsoft.

Referral Statements

The basic unit of WS-Referral is a referral statement, which is an XML-based structure for describing a routing entry along with a set of conditions under which the statement is satisfied. A referral statement contains five parts—among them are:

• A set of SOAP actors for which a statement is intended
• A set of conditions that have to be met for a statement to be satisfied
• A set of SOAP routers that a statement is referring to as part of the delegation

WS-Referral defines a referral statement using a “for-if-go” grammar; that is, “for” the following set of actors, “if” the following conditions are satisfied, then “go” to these SOAP routers.

XML Example: Referral Statement

An example of a referral statement is as follows:

<r:ref>
  <r:for>
    <r:prefix>soap://a.org</r:prefix>
  </r:for>
  <r:i>
    <r:ttl>43200000</r:ttl>
  </r:if>
  <r:go>
    <r:via>soap://b.org</r:via>
  </r:go>
  <r:refId>uuid:09233523-345b-4351-b623-5dsf35sgs5d6</r:refId>
</r:ref>

In the above example, the <r:prefix> element means that any SOAP node beginning with the contained URI is considered to be a match for the referral. The <r:ttl> element denotes “time to live”—that is, it sets a “time to live” limit on the availability of a referral. The value of this element above (43200000) is the number of milliseconds, which equates to 12 hours. Therefore, the entire statement would be read as follows: “for all SOAP nodes that begin with the URI soap://a.org, if this referral is less than 12 hours old, then go to soap://b.org“.

This referral could be used on future messages to include a <r:fwd> element in the SOAP header (as described in the WS-Routing specification), such as the following:

<wsrp:fwd>
  <wsrp:via>soap://b.org</wsrp:via>
</wsrp:fwd>

WS-Referral Queries

A SOAP router can explicitly request one or more WS-Referral statements from another SOAP router by sending it a WS-Referral query. This may be done to request new information, or perhaps update inadequate routing information in order to reach a given SOAP router in a message path.

XML Example: WS-Referral Query

The following is an example of a WS-Referral query that requests referral information for all SOAP nodes that begin with the URI soap://a.org:

<r:query>
  <r:for>
    <r:prefix>soap://a.org</r:prefix>
  </r:for>
</r:query>

A referral statement would then be sent in the response.

Specification Location

The WS-Referral specification can be found at http://msdn.microsoft.com/webservices/understanding/gxa/default.aspx?pull=/library/en-us/dnglobspec/html/ws-referral.asp.

Transactional Properties: WS-Transaction

If you’ve ever made a stock trade online, you know how disconcerting it could be if you’re presented with an error in the middle of your trade execution. However, if the online trade is designed with transactional properties in mind (which it should be!), it will be ensured that the trade was either carried through fully, or not at all. Transactional properties of Web services are the focus of the WS-Transaction specification. The WS-Transaction specification was released in August 2002 by Microsoft, IBM, and BEA Systems.

Coordination Types

WS-Transaction defines two coordination types that essentially characterize transactions as either “fine-grained” or “course-grained” transactions. Atomic transactions are transactions that are used to coordinate activities having a short duration and executed within limited trust domains; they are more “fine-grained” in nature. Such transactions are called “atomic” because they have an “all or nothing” property (in other words, the transaction must either be completely executed, or not executed at all, as in our stock trade scenario above). In contrast, business activities are used to coordinate activities that are long in duration and that may apply business logic to handle business exceptions; they are more “coarse-grained” in nature. Because of the long duration of business activities, data resources cannot be locked as with atomic transactions—rather, actions are applied immediately and are permanent. A Web services application can include both atomic transactions and business activities, and developers can use either or both of these coordination types when building applications that require consistent agreement on the outcome of distributed activities.

Each activity in a transaction is coordinated by a Web service that is aptly called a coordinator or coordination service. As we will see shortly, each participant in an activity registers with the coordinator of that activity through what is known as a registration service.

Coordination Protocols

Each coordination type discussed above can have multiple coordination protocols, each of which is intended to coordinate a different role that a Web service plays in the activity. Each participant in an activity registers for the coordination protocol that is most appropriate for its particular role in the activity. Some examples of atomic transaction coordination protocols are:

• Completion: One participant (generally the application that created the transaction) registers for the completion protocol, so it can tell the coordinator either to try to commit the transaction or force a rollback.
• 2PC (2 Phase Commit): A participant such as a resource manager (ex: database) registers for this, so that the coordinator can manage a commit-abort decision across all the resource managers (2-phase commit).
• Phase Zero: The coordinator notifies a participant just before a 2PC protocol begins; this would allow an application that caches data (for example) to write outstanding updates to a database prior to the execution of the 2PC protocol.

Coordination Contexts

In order to link the various activities participating in a transaction, messages between parties carry a coordination context. Once a coordination context is acquired by an application, it is sent by whatever appropriate means to another application.

XML Example: Coordination Context

The following is an example of a coordination context supporting a transaction service:

<S:Header>
       . . .
  <wscoor:CoordinationContext>
    <wsu:Identifier>http://abc.com</wsu:Identifier>
    <wsu:Expires>2002-08-31T13:20:00-05:00</wsu:Expires>
    <wscoor:CoordinationType>
      http://schemas.xmlsoap.org/ws/2002/08/wstx
    </wscoor:CoordinationType>
    <wscoor:RegistrationService>
      <wsu:Address>
        http://xyzregistrationservice.com
      </wsu:Address>
    </wscoor:RegistrationService>
  </wscoor:CoordinationContext>
       . . .
</S:Header>

In the above example, the element value is the value defined by WS-Transaction to signify an atomic transaction (http://schemas.xmlsoap.org/ws/2002/08/wstx). Additionally, the <wscoor:RegistrationService> element gives the URI of the registration service with which all Web services wishing to participate in the transaction register.

Transaction Coordinator

The coordinator of a transaction aggregates the following services:

• Activation Service: Allows a coordination context to be created, through a CreateCoordinationContext operation.
• Registration Service: Allows a Web service to register to participate in a coordination protocol, through a Register operation.
• Coordination Protocol Services: A set of coordination protocol services for each coordination type supported by the coordinator.

Abbreviated Example

The following is an abbreviated example of WS-Transaction in action—it contains only the highlights of a transaction process, and does not include some “standard” of the back-and-forth negotiation processes that take between the participants (such as acknowledgments). It will involve three applications:

• App1: A “user-facing” application; will initiate the transaction
• App2: An application that caches data
• App3: A resource manager

The process is as follows:

• App1 sends a CreateCoordinationContext message to its local activation service, to create an atomic transaction
• App1 receives from its local activation service a coordination context containing the following items (along with other information):
• A transaction identifier that uniquely identifies the transaction
• A coordinator port reference for the activity coordinator
• App1 registers with the coordinator for the Completion protocol
• App1 sends a message to App2 containing the coordination context
• Because App2 is an application that caches data, it registers with the coordinator for the Phase Zero protocol
• App2 sends a message to App3 containing the coordination context
• Because App3 is a resource manager, it registers with the coordinator for the 2PC protocol

At this point, the coordinator knows all of the transaction participants and what coordination protocols they expect to use. From this point on, the actions of each of the participating applications will be coordinated by the coordinator based on interactions between the coordinator and the various participants.

Remaining Specifications

The following is a list of the remaining specifications that currently comprise GXA:

Conclusion

In this article, we have discussed the Global XML Web Services Architecture (GXA). GXA is poised to play a major role in advancing the adoption of Web services through its robust specification of mechanisms for Web services such as security, policy, coordination, federation, and routing. More specifications will be forthcoming for areas such as privacy, federation, and authorization.

About the Author

Joseph Chiusano is a Senior Consultant with Booz Allen Hamilton. His technology background includes such diverse areas as systems architecture, relational database applications design and development, operating system development, and XML consulting. Mr. Chiusano possesses in-depth knowledge in many aspects of XML and XML-related technologies, including Web services, XML schemas, digital security, XML registries, and XML vocabularies.