Understanding GXA

Don Box
Microsoft Corporation

July 2002

Applies to:
   SOAP 1.1/1.2 Specifications
   WS-Referral Specification
   WS-Routing Specification
   WS-Security Specification
   XML Information Sets (Infosets)

Summary: Describes the basic design principles of Microsoft GXA and includes a roadmap for understanding how the individual GXA-infrastructure protocols are composed to provide a cohesive platform for Web services and applications. (8 printed pages)

Contents

Abstract
1. Introduction
2. GXA Design Principles
3. GXA Functionality (Today)
4. GXA Futures
5. Conclusion

Abstract

The Microsoft® Global XML Architecture (GXA) is a protocol framework designed to provide a consistent model for building infrastructure-level protocols for Web services and applications. In addition to this underlying protocol framework, GXA defines a family of pluggable infrastructure protocols that provide applications with commonly needed services such as security, reliability, and multi-party agreement. This document describes the basic design principles of GXA and provides a roadmap for understanding how the individual GXA infrastructure-protocols are composed to provide a cohesive platform for Web services and applications.

1. Introduction

The underlying premise of GXA is that application developers do not want to rebuild an entire platform for each application. This premise has dominated the single-machine development model in which 95% of programmers in the world write applications that utilize a platform built by the remaining 5%. The traditional single-machine world of software development has had decades to formalize modularization techniques, which makes the separation between application and platform clean and easily understood.

The world of communication protocols also coined its share of modularization techniques, of which the most well-known is the concept of protocol layering, exemplified by the OSI seven-layer protocol stack. Other modularization techniques have existed within the research community for some time; however, few, if any, are known to the average application programmer. The primary design goal of GXA is to (a) provide a more formal model for protocol modularity and (b) provide a family of platform-level protocols for application developers to utilize in their Web services and applications. Just as an operating system provides commonly used facilities such as thread scheduling, access checks, and memory management, GXA provides a set of common facilities that are needed by a wide number of Web services and applications.

The GXA architecture builds on ideas such as traditional protocol layering and encapsulation. A key characteristic of GXA is that protocol features that cross-cut a broad range of applications are factored independently from application-specific protocols. This strict factoring allows individual infrastructure protocols to be reused in a variety of contexts. In addition to defining a family of infrastructure protocols, GXA also lays out a policy-based framework for establishing which of these protocols will be used for a particular set of message exchanges.

Because GXA is ultimately a family of wire-level protocols, the conceptual model behind GXA does not need to be shared by applications that interact with GXA-based Web services. Because GXA is built on the foundation of XML and SOAP, any Perl hacker can cobble up the necessary messages to interact with a GXA-enabled Web service; therefore, GXA acts as a fundamental pillar for the next generation of Microsoft XML Web services tools, frameworks, and applications.

1.1 Infrastructure vs. Application Protocols

GXA distinguishes between application protocols and infrastructure protocols. Application protocols are specific to a particular application domain. Application protocols have very specific semantics that are expressed as a series of domain-specific message exchanges. Though there has been some success in the past at defining application protocols that span a vertical market segment (e.g., supply-chain management or health care), most application protocols tend to be ad hoc and are defined by one or at most two parties for communicating with very specific applications.

Infrastructure protocols tend to transcend specific application domains and focus on adding value to a broad range of application protocols. Because infrastructure protocols are not tied to a specific application domain, infrastructure protocols tend to be useless by themselves. Rather, infrastructure protocols are designed to be composed with an application protocol, typically by augmenting the message exchanges that are already in place.

GXA provides a framework for composing infrastructure protocols with application protocols. This framework is agnostic to the underlying transport, framing, and marshaling protocol. That stated, GXA is specified in terms of SOAP, which is the dominant protocol for Web services. That does not prohibit the use of GXA protocols in other contexts; rather, defining non-SOAP-based binding for GXA protocols is outside the scope of GXA proper.

1.2 Support for Infrastructure Protocols in SOAP

From its earliest incarnations dating back to 1998, SOAP has focused on providing mechanisms for mixing application and infrastructure protocols. Moreover, the W3C SOAP 1.2 specification explicitly separates these mechanisms from other aspects of the protocol, such as data encoding and HTTP bindings. Part I of the SOAP 1.2 specification provides a message-processing model that is the kernel of the GXA architecture.

SOAP messages are XML documents that adhere to a predefined schema. This schema defines a framing convention in which the primary payload of the message (called the body) may be augmented by zero or more auxiliary pieces of XML called headers. Consider the following SOAP 1.1 message:

<soap:Envelope 
  xmlns:soap="https://schemas.xmlsoap.org/soap/envelope/"
  xmlns:ns1="http://platforms-r-us.org/profiles"
  xmlns:ns2="http://the-platform-co.com/qos/priority"
  xmlns:ns3="urn:schemas-acme-com:pvr.v1"
>
  <soap:Header>
    <ns1:preferences>
       <genre>Noir</genre>
       <format>WMV</format>
    </ns1:preferences>
    <ns2:priority>
      <level>low</level>
    </ns2:priority>
  </soap:Header>
  <soap:Body>
    <ns3:Record>
      <channel>11</channel>
      <start>2003-01-11T08:00:00-8:00</start>
      <duration>P30M</duration>
    </ns3:Record>
  </soap:Body>
</soap:Envelope>

In this example, the Record element is the body of the message. The preferences and priority elements are each distinct message headers. In the parlance of GXA, the SOAP body conveys information specific to an application protocol; the header elements convey information that is part of an infrastructure protocol.

SOAP headers are strongly typed and each header's role is determined by its namespace-qualified element name. To allow new header types to be introduced over time, SOAP provides explicit support for marking headers as either optional or mandatory via the soap:mustUnderstand attribute. Headers are marked as mandatory to indicate that the message as a whole cannot be properly (or safely) interpreted without also processing the mandatory header. SOAP provides a well-known fault code to indicate that an unrecognized header was encountered. In contrast, optional headers may be safely ignored by software that doesn't recognize the header's element type.

Optional headers often convey advisory information about the message. Mandatory headers often convey critical aspects of the message, such as digital signatures, transaction identifiers, etc. The following SOAP message carries two headers: one optional header and one mandatory header.

<soap:Envelope 
  xmlns:soap="https://schemas.xmlsoap.org/soap/envelope/"
  xmlns:ns1="http://platforms-r-us.org/profiles"
  xmlns:ns2="http://the-platform-co.com/qos/priority"
  xmlns:ns3="urn:schemas-acme-com:pvr.v1"
>
  <soap:Header>
    <ns1:preferences soap:mustUnderstand='1'>
       <genre>Noir</genre>
       <format>WMV</format>
    </ns1:preferences>
    <ns2:priority>
      <level>low</level>
    </ns2:priority>
  </soap:Header>
  <soap:Body>
    <ns3:Record>
      <channel>11</channel>
      <start>2003-01-11T08:00:00-8:00</start>
      <duration>P30M</duration>
    </ns3:Record>
  </soap:Body>
</soap:Envelope>

In this example, the preferences header is a mandatory header, as it carries a soap:mustUnderstand attribute with a value of "1." The recipient of this message is required to recognize this header and properly process it according to the corresponding header-specific protocol. If the header cannot be processed because the receiver has no a priori knowledge of the header, then a SOAP fault message must be returned indicating as much.

For many SOAP headers, the namespace-qualified element name is sufficient to convey the intention of the sender. In some circumstances, an additional identifier is needed to identify exactly which piece of software is expected to process the message. Rather than push this identifier into each header type that needs this functionality, SOAP formalizes the idea via its soap:role attribute (called soap:actor in SOAP/1.1). SOAP header elements may carry a soap:role attribute whose value is simply an opaque URI. How that URI is processed is dependent on the node that is processing the message.

2. GXA Design Principles

The GXA family of protocols builds on a set of shared design principles. These principles act as guidelines for all GXA protocols and influence both their design and application. These principles include:

Decentralization and Federation: A fundamental theme throughout Web service development is the concept of constrained agreement. The fact that two parties have to agree only on the syntax and semantics of messages is what makes XML Web services so attractive. The two parties are free to vehemently disagree on programming language, operating system, virtual machines, and databases provided they can come to an agreement on what messages will be exchanged.

GXA protocols are designed with constrained agreement in mind. Specifically, core pieces of the GXA infrastructure (routing, security) assume that introducing a centralized authority is impractical. Instead, the presence of a centralized authority is considered the exception rather than the rule—decentralization is the assumed default. To allow this decentralized approach to work without chaos ensuing, GXA builds upon the hierarchical nature of the URI mechanism to act as a "federator" of disparate, autonomous organizations. This approach leverages the existing namespace that today's Internet and XML are based on, and can be seen in the GXA routing architecture and its policy framework.

Modularity: A key to the success of SOAP was its modularity. Rather than attempt to specify an entire protocol stack, SOAP carved out a small but important niche (XML message processing). This modularity was implicit in the design of SOAP, and was made explicit in SOAP/1.1. The modularity of SOAP has allowed it to adapt to arbitrary transport protocols (e.g., TCP, HTTP, SMTP), some of which did not exist during the SOAP design phase (e.g., BEEP, Jabber).

GXA builds on the extensibility model of SOAP. To that end, GXA takes full advantage of the SOAP message-processing model, including support for multi-actor messages and SOAP intermediaries. Rather than trying to "boil the ocean", individual GXA specifications tend to be short and concise, providing a focused concrete solution to a bounded problem space.

The focused nature of GXA protocols allows them to be used as protocol building blocks. This composability allows one to combine orthogonal GXA protocols (e.g., WS-Security, WS-Routing) into a single message. Unlike large, monolithic protocols, GXA can be adopted piecemeal or en masse. If your application doesn't need a particular GXA protocol, it is reasonable to not use it while still using other parts of the architecture.

The inherent modularity and composability of GXA can be made manageable through the use of extended metadata formats that express the capabilities and requirements of a given Web service. Collectively, these capabilities and requirements are referred to as policy. The WS-Policy specification mentioned in Security in a Web Services World: A Proposed Architecture and Roadmap the IBM/Microsoft Web services security roadmap, is one example of policy-oriented metadata. By allowing various aspects of message transfer to be specified using policy, applications are able to "late-bind" against a Web service. This loose coupling is achieved using policy intersection, in which the requirements and capabilities of each party are used to find a common ground that all sides can live with.

An "existence proof" of the composability of GXA protocols is that various GXA protocols compose with themselves. For example, when a WS-Referral routing policy update is received, how does the receiver know whether the policy statement can be trusted? Rather than invent a routing-specific security mechanism, WS-Referral simply defers message-level security to an external protocol, most likely WS-Security.

XML-based Data Model: Because GXA is SOAP-based, GXA protocols are specified in terms of the data model for XML. This data model (called the XML Information Set or Infoset) has the advantage of broad industry support in terms of both platform and tool support.

By defining GXA in terms of XML Infosets, a GXA protocol has an obvious and natural representation in XML 1.0, the default transfer syntax for XML-based information. Building on Infosets also allows GXA to function in high-performance XML-based architectures that do not depend on transferring XML 1.0, such as XML processing pipelines, XML-based programming environments, and databases that support XML as "native."

Transport neutrality: GXA is specified entirely at the level of SOAP message exchanges. While HTTP has proven to be an extremely useful transport protocol for building XML Web services, GXA does not rely upon either the syntax or semantics of HTTP. To this end, GXA protocols (like SOAP itself) are designed to function at the message level independent of underlying transport.

Another aspect to the transport neutrality of GXA is that it does not assume RPC-style request/reply message patterns. GXA protocols are designed to allow out-of-band control information (e.g., security handshakes, policy exchange) to be carried either as part of the application-level message exchange or via independent channels established by infrastructure components (e.g., authentication servers, directories).

Application domain neutrality: Perhaps the most important design principle of GXA is that GXA protocols tend to be general-purpose solutions to broad problems that span application domains. Because reaching agreement is difficult, agreeing on a single broad solution for all application domains is more manageable than having one security standard for supply-chain applications, another for scheduling applications, etc. Agreeing upon a common general purpose standard does not imply that specific application domains do not have their own specific requirements. This is why all GXA protocols and schemas provide a consistent and well-defined extensibility mechanism. This allows a GXA protocol to be used as a "baseline" that provides the majority of what is needed while still allowing domain-specific specialization.

3. GXA Functionality (Today)

GXA provides a protocol platform for building Web service-based applications. The core functionality of that platform includes:

Application-aware Virtual Network: The fundamental value of GXA is that it provides a virtual network over arbitrary network transports and protocols. The GXA protocol that provides this "Web service dialtone" is WS-Routing. WS-Routing abstracts away protocol-specific addressing and routing behind a uniform, URI-based addressing scheme. WS-Routing leverages the concept of "SOAP intermediary" as defined by SOAP/1.2 by allowing messages to flow through one or more routing nodes prior to reaching the ultimate receiver of the message. Because WS-Routing works over arbitrary transports, each hop may use a different underlying transport, which allows two endpoints to communicate even when no common transport protocol is available.

Because messages that use WS-Routing may be sent over multiple hop-to-hop transports, WS-Routing by itself can only guarantee datagram-level functionality when an intermediary is present. To achieve end-to-end reliable transmission in all cases, Microsoft is currently defining a reliable messaging protocol to provide reliable, in-order delivery of messages over arbitrary transports. This protocol builds on the lessons learned from TCP, and is suited to both transient message delivery as well as durable, store and forward scenarios.

It is tempting to look at the GXA network virtualization and ask, "Why not simply use TCP/IP?" The primary reason is that it is extremely difficult to implement application-aware optimizations into most commercial TCP/IP stacks. By expressing the network protocol in terms of XML, it becomes easier to build application-aware infrastructure (e.g., routers, gateways, bridges) that leverage the existing XML-based tools and technologies. Additionally, because implementing new routing algorithms or retransmission heuristics can be implemented in user-mode code using very accessible tools, protocol innovation no longer requires low-level kernel hackery.

Message-oriented security: Once SOAP formalized the notion of an intermediary, the ability to rely upon transport-level security was no longer reasonable. Because an intermediary may need to process a message prior to forwarding it to the next intermediary (or ultimate receiver), Web service security needs to be explicitly aware of the underlying "SOAP-ness" of the message. This awareness is provided by WS-Security, the baseline security protocol of GXA.

WS-Security provides a SOAP-aware mechanism for signing and sealing portions of a SOAP message. Specifically, WS-Security defines a SOAP header that conveys the security token of the sender. This token represents one or more claims that the sender is asserting to be true. The message receiver uses these claims to determine whether the message can be processed. If the sender lacked the required claims, then the message will be rejected with a well-known fault code. Otherwise, the message will be processed as expected.

WS-Security does not mandate a specific format for the security token. Rather, specific formats are supported via an extensibility element in the security header. WS-Security predefines the element format for several protocols (e.g., X509, Kerberos) that are in widespread use.

The security token that appears in a WS-Security header is used for (at least) two purposes: signing and sealing. WS-Security supports signing and sealing portions of a SOAP message. Signing a message ensures (a) that the sender is in fact the possessor of the security token and (b) that the signed portions of the message have not been tampered with. Sealing a message encrypts the contents of a message using a key that only the sender and receiver understand. WS-Security simply provides a framework for signing and sealing and defers to externally defined protocols such as XML Signature and XML Encryption for the actual algorithms. This allows WS-Security to adapt to new algorithms as they are developed.

4. GXA Futures

Rich support for federated security: WS-Security is a baseline specification and represents the minimum functionality needed to send a secure message. Security in a Web Services World: A Proposed Architecture and Roadmap outlines a suite of forthcoming security-related protocols that complete the picture. WS-Trust will define protocols for issuing security tokens and managing trust relationships. WS-Privacy will provide a framework for making statements about information privacy requirements and preferences. WS-Authorization will provide mechanisms for discovering the claim/privilege requirements of a service. WS-Federation will define the protocols necessary to broker trust relationships between autonomous organizations and authentication technologies. WS-SecureConversation will provide the protocol for establishing a secure communications context, including establishing a secure session key suitable for sealing message content. Finally, WS-Policy will provide a framework for discovering the capabilities and requirements of a service in a general-purpose way.

Distributed agreement: From the earliest days of SOAP, users have wondered what role transactions will play in the world of Web services. To address the needs of a broad range of applications, Microsoft is defining a framework for building GXA-based distributed agreement protocols. This framework does not mandate a specific agreement protocol (e.g., two-phase-commit); rather, it simply defines a common framework for various parties to establish mutual interest in order to facilitate coordinated work.

Pervasive metadata and discovery: GXA assumes a world in which metadata is high fidelity and ubiquitous. To this end, Microsoft is currently developing an XML-based metadata framework that allows arbitrary statements to be made about the various entities that comprise a Web service application. This framework is used to express capabilities, preferences, and requirements for endpoints and messages. WS-Referral is the first application of this framework, and forthcoming specifications will generalize the role of metadata to other domains.

5. Conclusion

GXA is a family of infrastructure-level protocols that add richness to today's Web services and applications. Individual protocols in GXA solve specific, focused problems and may be composed to provide a more cohesive platform. The initial wave of GXA protocols (WS-Routing, WS-Security) provides an application-aware network layer that can be secured independent of underlying transport. Subsequent GXA protocols will enhance this network to support reliable message delivery, transaction coordination, and ubiquitous metadata and discovery.