Introducing .NET My Services

The Global XML Web Services Architecture (GXA)

Today, Web services are built on a set of baseline specifications, which include SOAP, Web Services Description Language (WSDL), and Universal Description, Discovery, and Integration (UDDI). Together, these specifications allow you to write Web services, which are not constrained by programming languages or platforms. The true value of Web services lies in their ability to operate in these heterogeneous environments, but these environments also pose challenges that Web services do not currently address.

• Security Web services must operate within the context of an end-to-end security architecture that allows for authentication and authorization across a heterogeneous, distributed environment.

• Routable Messages In some cases, a message might need to be routed through multiple intermediaries across multiple transports. In these cases, you need the ability to define the route a message must take to reach its intended recipient.

• Referral Service Often the route to an intended recipient must be dynamically configured. For example, many computers, especially those owned by corporations, are located behind a network address translation (NAT) server. A computer located behind a NAT server can open a connection to another server. However, the first computer is not addressable by computers located on the opposite side of the NAT server. In this case, the message needs to be dynamically routed to its intended recipient.

• Browsable Discovery Sometimes it is necessary to advertise your Web service so that it can be discovered using a browse paradigm. For example, a developer might want to browse a peer's server to determine which Web services are exposed.

Unfortunately, the current Web services architecture does not provide specifications that define how these types of operations can occur. This means that an organization implementing Web services today will choose either to ignore these issues or to develop its own proprietary solutions to these problems.

For example, an organization that wants to ensure message integrity might implement a technique based on a proprietary security mechanism. Anyone who interacts with this organization must adhere to this technique. Obviously, this approach requires that the consumer and the producer of the Web service agree on how this solution is implemented. However, the Web service consumer might discover that another Web service producer she deals with implements a different solution, and thus the consumer must modify her applications to interact using another proprietary solution. As you can see, this breaks the fundamental ethos of Web services—that of interoperability.

To respond to the need for universal specifications that ensure interoperability, routable messages, referral service, and browsable discovery support, Microsoft and its partners are defining a set of new specifications. Once these specifications mature, Microsoft will propose them to the appropriate entities for consideration as universal standards, in much the same way that it did with SOAP. Together, these specifications will form the GXA.

So far, the GXA consists of the following five specifications:

• Web Services Inspection Language (WS-Inspection)

• Web Services Security Language (WS-Security)

• Web Services License Language (WS-License)

• Web Services Routing Protocol (WS-Routing)

• Web Services Referral Protocol (WS-Referral)

These specifications leverage the extensible nature of SOAP to provide SOAP modules that build on the baseline specifications of today's Web services. The modular nature of the architecture allows you to select which of the modules you want to use. For example, if you have an application for which security is of no concern, you will not need to use the modules pertaining to security (WS-Security and WS-License). In addition, each module is expressed in the same terms regardless of whether it is used individually or with other modules. Finally, modules are independent of the platforms or programming languages at the message endpoints, thus allowing Web services to use the architecture in heterogeneous environments.

WS-Inspection

Recall that in Chapter 9 I explained two methods of locating a Web service, UDDI and DISCO. UDDI provides a centralized directory that can be searched to locate published Web services. UDDI does provide the ability to browse for the Web services exposed by a particular business entity. However, it does not provide a means of discovering the Web services exposed by a particular server.

Today this role is filled by DISCO. DISCO provides a browse paradigm similar to hypertext links in HTML documents. However, DISCO has its drawbacks. DISCO is not an industry standard, is not extensible, and is currently supported only by the .NET platform.

WS-Inspection is intended to offer an industry-standard mechanism for discovering Web services via a browse paradigm while overcoming the known issues with DISCO. Similar to DISCO, a WS-Inspection document can contain a list of pointers to WSDL documents as well as to other WS-Inspection documents. Unlike DISCO, WS-Inspection is extensible and allows you to reference any number of resources, including UDDI directory entries.

WS-Inspection Document Syntax

The grammar of a WS-Inspection document is quite simple, as the following example shows:

<wsil:inspection>   <wsil:abstract xml:lang=""? ... /> *    <wsil:service> *     <wsil:abstract xml:lang=""? ... /> *     <wsil:name xml:lang=""? ... /> *     <wsil:description referencedNamespace="uri" location="uri"?> *       <wsil:abstract xml:lang=""? ... /> *        <-- extensibility element --> ?     </wsil:description>   </wsil:service>   <wsil:link referencedNamespace="uri" location="uri"?/>  *     <wsil:abstract xml:lang=""? ... /> *      <-- extensibility element --> ?   </wsil:link> </wsil:inspection>

Each WS-Inspection document has an inspection root element. This element must contain at least one service element or link element. The service element must have one or more description elements, which act as pointers to other service description documents. The description element's referencedNamespace attribute identifies the namespace that the referenced document belongs to, and the location attribute references the actual service description document.

For example, the following XML fragment shows a reference to a WDSL document accessible via HTTP:

<description referencedNamespace=http://schemas.xmlsoap.org/wsdl/ location=http://example.com/weatherreport.wsdl/>

The service element has two other child elements: abstract and name. The abstract element allows you to add a text description within the element. This description is intended for human eyes rather than for consumption by an application. Likewise, the name element allows you to associate a human-readable name with a service.

In contrast to the service element, the link element references another aggregation of service documents, such as another WS-Inspection document. Similar to the service element's attributes, the link element's referencedNamespace points to the namespace of the linked aggregation, and you can use the link element's location attribute to provide a link to the actual linked aggregation source.

For example, the following XML links a WS-Inspection document to two other WS-Inspection documents, which other directories on a Web server contain:

<inspection xmlns=   "http://schemas.xmlsoap.org/ws/2001/10/inspection/">   <link referencedNamespace=   "http://schemas.xmlsoap.org/ws/2001/10/inspection/"   location="http://example.com/weather/inspection.wsil"/>   <link referencedNamespace=   "http://schemas.xmlsoap.org/ws/2001/10/inspection/"   location="http://example.com/events/inspection.wsil"/> </inspection>

Notice that the actual WS-Inspection document and the two links all reference the schema because they all belong to the same namespace. When a user accesses this document, she can obtain the aggregated list of services that the two linked documents advertise. As you can see, this type of chaining allows multiple common entry points to a site to advertise the services on offer throughout the site without having to repeat lists of references.

Publishing WS-Inspection Documents

To allow users to look up the services referenced by a WS-Inspection document, you must place the document where users can locate and access it. WS-Inspection provides two methods for doing this. The first, Fixed Name, requires you to place WS-Inspection documents at the common entry points to your Web site or application. You should save the WS-Inspection document with the name inspection.wsil so that users know to request a document with a standard name. If you provide services from more than one location on your server, you must provide a separate WS-Inspection document at each of these locations. Of course, you can chain these documents—as shown previously—to avoid duplicating service information.

The second method, Linked, allows you to advertise services through other types of content. For example, you can link to multiple WS-Inspection documents through an ordinary HTML Web page. To do this, you simply reference the WS-Inspection documents from the content attribute of the HTML META tag, as shown here:

<HTML>     <HEAD>         <META name="serviceInspection"                content="http://example.com/weather/inspection.wsil">         <META name="serviceInspection"                content="http://example.com/events/inspection.wsil">     </HEAD>     <BODY>         <!-- Other HTML tags -->     </BODY> </HTML>

As you can see, the HTML links to the two WS-Inspection documents that I previously defined. Note that when you link to documents in HTML, you must link only to WS-Inspection documents and not to other HTML documents.

WS-Security and WS-License

One challenge that developers of Web services face is securing messages to and from Web services. In Chapter 10, we looked at how developers can address those issues today. Specifically, you learned about ways to provide authentication, authorization, data integrity, and nonrepudiation for data exchanged between a client and a Web service. The solutions I examined relied on technologies outside of the actual SOAP messages themselves, such as the following:

• IIS authentication mechanisms such as Basic authentication and Digest authentication

• SSL/TLS or IPSpec for securing transport channels

• Cryptography algorithms for encrypting and signing data

The problem with leveraging these technologies is that they are not integrated with SOAP. For example, the IIS authentication mechanisms are tightly coupled to the HTTP protocol and provide no benefit if the message is sent over another transport protocol. SSL/TLS and IPSec are connection-oriented protocols and do not provide an end-to-end solution if the message needs to be routed through multiple intermediaries. If the message is signed or encrypted using a standard cryptography algorithm, there is no standard way of presenting the recipient with the information to validate the signature or decrypt the message. What is needed is a solution that is SOAP-oriented, one that is standards based and transport-protocol agnostic.

The GXA defines WS-Security and WS-License, which together define a standard way to build secure solutions for SOAP messages. These specifications provide support for the following:

• Multiple security authentication credentials

• Multiple trust domains

• Multiple encryption technologies

Because the specifications do not dictate a particular implementation, they allow you to securely exchange SOAP messages in a platform-independent and technology-independent way. As long as a client application can build and understand SOAP messages and has access to appropriate libraries—for example, a Kerberos library—it can interact securely with a Web service.

Specifically, the modules provide support for multiple security authentication credentials, multiple trust domains, and multiple encryption technologies through the following three main mechanisms:

• Credential passing

• Message integrity

• Message confidentiality

The modular nature of the architecture allows you to use these mechanisms together for an integrated security solution or to use them individually to address specific scenarios. For example, if you run a weather report Web service in which authentication is the only requirement, you can simply use credential passing as a means of authenticating users. If you run a Web service that supplies sensitive sales data to remote offices, requires you to authenticate and authorize users, and requires you to ensure the integrity and privacy of the data exchanged between the client and the server, your security solution will require using all three security mechanisms.

Let's explore each of these mechanisms in more detail.

Credential Passing

When two parties want to communicate securely or one party wants to authenticate the identity of another party, they typically exchange security credentials. The WS-Security specification allows parties to exchange a wide variety of credentials regardless of the underlying transport protocol or delivery mechanism. It does this by inserting an additional header into a SOAP message known as the credentials header. The credentials header contains credential and license information that parties can use to authenticate each other.

In terms of WS-Security, credentials refer to licenses and supporting information together. The specification is independent of any specific license or credential format, but it does provide explicit support for X.509 certificates and Kerberos tickets. The WS-License specification defines the XML elements that describe these licenses. Thus, to pass credentials, you use WS-Security and WS-License together. Specifically, WS-License defines the following four subtypes of the WS-Security credentials type:

• abstractLicense The abstract class for all licenses, from which all WS-License licenses derive. You can extend the specification by creating your own subtype of this type.

• binaryLicense Represents an instance of a license that is binary encoded. The two possible values for this type are X.509 certificate and Kerberos ticket.

• abstractCredential The abstract class for all credentials, from which all WS-License credentials derive. You can extend the specification by creating your own subtype of this type.

• binaryCredentials Used to pass a security credential, which is not a license but is binary encoded. The specification does not define specific values for this type; instead, it accepts user-defined values.

The following example shows a SOAP message that contains an X.509 certificate. It also shows the relationship between the WS-Security and WS-License specifications.

<?xml version="1.0" encoding="utf-8"?> <S:Envelope xmlns:S=http://schemas.xmlsoap.org/soap/envelope/  xmlns:xsd=http://www.w3.org/2001/XMLSchema  xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance> <S:Header>   <m:path xmlns:m="http://schemas.xmlsoap.org/rp">     <m:action>http://tickers-r-us.org/getQuote</m:action>     <m:to>soap://tickers-r-us.org/stocks</m:to>     <m:from>mailto:[e-mail]</m:from>     <m:id>uuid:84b9f5d0-33fb-4a81-b02b-5b760641c1d6</m:id>   </m:path>   <wssec:credentials xsi:type="wslic:CREDENTIALS"    xmlns:wssec=http://schemas.xmlsoap.org/ws/2001/10/security    xmlns:wslic="http://schemas.xmlsoap.org/ws/2001/10/license">     <wslic:binaryLicense wslic:valueType="wslic:x509v3"      xsi:type="xsd:base64Binary">       MIIEZzCCA9CgAwIBAgIQEmtJZc0rqrKh5i...RnSNBe8DQve       qD6a3gUACyZ6XVe3u     </wslic:binaryLicense>   </wssec:credentials> </S:Header> ... <!-- Body here--> ... </Envelope>

As you see, the message contains a credentials element (as defined by the WS-Security specification). This element has a child element of binaryLicense (as defined by the WS-License specification), which contains the X.509 certificate. If you want to pass an alternative form of license or alternative credentials, you can replace binaryLicense with the appropriate option from those previously listed.

Message Integrity

In Chapter 10, you learned that you must have control of both the client and the Web service in order to ensure the integrity of data, and that no current SOAP standard provides for integrity. This situation will change because the integrity mechanism of the WS-Security specification provides privacy through the use of signatures that are compliant with the XML-Signature specification. You insert these signatures into an integrity SOAP header.

Signatures provide two benefits: integrity (the message has not been altered in transit) and nonrepudiation (you must have sent it because you signed it). The specification allows you to include one signature for an entire message or multiple signatures, each relating to a different portion of the message. For example, this is particularly useful when a message is forwarded from one department to another and each department adds to the message; the signatures can provide a history of integrity for the document.

Another important issue that the specification addresses is that of SOAP headers, which are volatile and often in flux. For example, the WS-Routing specification (more on this a little later) allows SOAP headers to change legitimately; thus, a message receiver might not be able to verify a signature based on the entire SOAP envelope, including these headers, even though the message body has not changed. The use of multiple signatures can negate these effects, but the specification recommends the use of a Routing Signature transform. A Routing Signature transform bases its signature digest computation on the SOAP envelope but excludes the WS-Routing headers, which are liable to change legitimately. A message recipient can thus verify the signature even though some of the WS-Routing SOAP headers might have changed. In addition to the Routing Signature transform, the specification supports all the algorithms and transforms defined by the XML-Signature specification.

The following example shows a SOAP message that contains a single XML-Signature. The integrity node set, which contains all the signature information, is shown in bold.

<?xml version="1.0" encoding="utf-8"?> <S:Envelope xmlns:S=http://schemas.xmlsoap.org/soap/envelope/  xmlns:xsd=http://www.w3.org/2001/XMLSchema  xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance> <S:Header>   <m:path xmlns:m="http://schemas.xmlsoap.org/rp">     ...         <!-- Standard path headers here -->     ...     </m:path>   <wssec:credentials    xmlns:wssec="http://schemas.xmlsoap.org/ws/2001/10/security">     <wslic:binaryLicense      xmlns:wslic=http://schemas.xmlsoap.org/ws/2001/10/licenses      wslic:valueType="wslic:x509v3" xsi:type="xsd:base64Binary"      >       ...       <!-- The very long encrypted certificate here -->       ...     </wslic:binaryLicense>   </wssec:credentials>   <wssec:integrity    xmlns:wssec="http://schemas.xmlsoap.org/ws/2001/10/security">     <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">       <ds:SignedInfo>       <ds:CanonicalizationMethod        Algorithm="http://www.w3.org/Signature/Drafts/xml-exc-c14n"/>       <ds:SignatureMethod        Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>       <ds:Reference>         <ds:Transforms>           <ds:Transform Algorithm=           "http://schemas.xmlsoap.org/2001/10/security           #RoutingSignatureTransform"/>           <ds:Transform Algorithm=           "http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>         </ds:Transforms>         <ds:DigestMethod          Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>         <ds:DigestValue>           EULddytSo1zHgUljA3lHABwSv7A=         </ds:DigestValue>       </ds:Reference>       </ds:SignedInfo>       <ds:SignatureValue> BL8jdfToEb1l/vXcMZNNjPOVt8Wqc72Ht7GEHtpJj3n33WjNEYpU5ZYv/5aXeU5eFSJP3UM 0suDTORH8s8PsnS218aoyRvA3jJYnxEkPKVTDAXq7LK3zZ28iWpOhN98nwSnZ4L4Hqe3G40 gUv3jOhLZRkx6czpJuxlcDlhibbmY=       </ds:SignatureValue>       <ds:KeyInfo>         <wssec:licenseLocation="#X509License"/>       </ds:KeyInfo>     </ds:Signature>   </wssec:integrity> </S:Header> ... <!-- Body here--> ... </S:Envelope>

The integrity element can contain multiple Signature elements, but in this instance it contains just one. The Signature element has three children. The first is the SignedInfo element, which you use to pass information about the encryption algorithms used to create the signature and the digest on which it is based, as well as the URI of any transforms you have applied. The second element is the SignatureValue element, which contains the actual XML signature. The final child element is the optional KeyInfo element, which references a license with which the user can determine the trust level of the signed data. In this example, the license is an X.509 certificate, which is also included within the SOAP header.

Message Confidentiality

You have seen how WS-Security can help you ensure the integrity of data, but in some instances simply checking whether a malicious party has modified data in transit is not enough—you need to ensure that the data remains confidential so that even if someone gains access to it, it is of no use to them. For example, when users pass credit card details to a Web service, it is imperative that no one be able to see the credit card numbers while the data is in transit. In these instances, you must encrypt the data—that is, the SOAP envelope's actual payload. The WS-Security confidentiality mechanism provides a way to do this using XML Encryption.

In terms of algorithms, the specification has the same requirements as the XML Encryption specification and, unlike the integrity mechanism, it does not recommend any additional algorithms. To send a message whose body or a portion of whose body is encrypted, you encode the SOAP message based on the XML Encryption specification. However, if you want to send encrypted attachments, you do not use the functionality XML Encryption offers but instead use the WS-Security confidentiality SOAP header. This header acts as a container for references to encrypted parts and attachments, each of which you reference using an EncryptedData element.

The following example shows the use of the confidentiality header to reference an encrypted attachment:

<?xml version="1.0" encoding="utf-8"?> <S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/" xmlns:"xsd=http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">   <S:Header>     <m:path xmlns:m="http://schemas.xmlsoap.org/rp">       <m:action>http://tickers-r-us.org/getQuote</m:action>       <m:to>soap://tickers-r-us.org/stocks</m:to>       <m:from>mailto:[e-mail]</m:from>       <m:id>uuid:84b9f5d0-33fb-4a81-b02b-5b760641c1d6</m:id>     </m:path>     <wssec:confidentiality      xmlns:wssec="http://schemas.xmlsoap.org/ws/2001/12/security">       <enc:EncryptedData xmlns:enc="'http://www.w3.org/2001/04/xmlenc#">         <enc:EncryptionMethod          Algorithm="http://www.w3.org/2001/04/xmlenc#3des-cbc"/>         <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">           <enc:EncryptedKey>             <enc:EncryptionMethod              Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>             <enc:CipherData>               <enc:CipherValue>                 AQIAAANmAAAApAAAX2mbWyA...                 1Y0TwnDRoTIc0Bke5jPEKszdWwV66DGxjmCjQHo=               </enc:CipherValue>             </enc:CipherData>           </enc:EncryptedKey>         </ds:KeyInfo>         <enc:CipherData>           <enc:CipherReference URI="cid:122326"/>         </enc:CipherData>       </enc:EncryptedData>     </wssec:confidentiality>   </S:Header>   <S:Body>     <tru:AttachedList xmlns:tru="http://tickers-r-us.org/payloads"/>   </S:Body> </S:Envelope>

WS-Routing

Developers currently face the challenge of having to figure out how to configure routing of messages that must pass through intermediaries before they reach their final destinations. Even though SOAP allows you to specify multiple intermediaries that a message must pass through en route to its final destination, it does not provide a mechanism for specifying the order in which the message passes through those intermediaries.

WS-Routing provides a solution to this problem by allowing you to specify message routes—that is, it allows you to specify the order that a message travels through intermediaries on the way to its final recipient. WS-Routing also allows you to define return, or reverse, paths for messages so that you can create applications that use various messaging paradigms, such as one-way messaging, two-way messaging, and long-running dialogs. As with the other components of the GXA, WS-Routing is independent of underlying protocols—it can operate over a wide array of transport protocols, including TCP, UDP, DIME, SMTP, HTTP, and TLS.

When you use WS-Routing, a path SOAP header contains the routing information for the message. This header contains child elements that specify the message path. For example, the following SOAP message demonstrates the use of the path header:

<S:Envelope xmlns:S="http://www.w3.org/2001/06/soap-envelope"> <S:Header>   <w:path xmlns:w="http://schemas.xmlsoap.org/rp/">     <w:action>http://www.microsoft.com/weather</w:action>     <w:to>soap://D.com/some/destination</w:to>     <w:fwd>       <w:via>soap://B.com</w:via>       <w:via>soap://C.com</w:via>     </w:fwd>     <w:from>soap://A.com/some/origin</w:from>     <w:id>uuid:82e9a994-d345-ace1-b2ba-09a2c5d466</w:id>   </w:path> </S:Header> <S:Body>   ...   <!-- Message body here -->   ... </S:Body> </S:Envelope>

The code provides a message path that originates from a sender (A) who sends to an intermediary (B), who forwards the message to C, who forwards the message to D, the message recipient. The code references these four parties through child elements of the path header, namely these:

• from The message sender (A)

• fwd The intermediaries (B and C), each of which is declared in a via element

• to The message recipient (D)

In addition to these elements, the path header contains an action element and an id element. The action element contains a URI identifying the action the message points toward—that is, its intent. The id element contains an ID for the message. When you specify this ID, be sure it is unique—for example, by using a hash of the message's content.

WS-Routing also allows you to specify a reverse path for a message. This can be useful in a number of situations, such as peer-to-peer messaging or returning error messages. To set a reverse path, you use the path header's child element, rev. Note that only the message sender can insert a rev element into a message; intermediaries cannot. If you do not stipulate a reverse path, one will be built dynamically as the message moves along the forward path. However, you can specify a reverse path if you want, by using via child elements in the same way that I did for the forward path in the previous example.

When you define reverse paths, you might want to associate one message with another. For example, in a peer-to-peer message exchange, it is important to know which message response relates to which original message. Likewise, it is important to identify which message an error message relates to. WS-Routing allows you to perform this form of correlation using the relatesTo element. This element simply takes a value, which is the ID of the message to which it must correlate.

The following example shows a simple SOAP message that uses the rev element and the relatesTo element:

<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> <S:Header>   <w:path xmlns:w="http://schemas.xmlsoap.org/rp/">     <w:action>http://www.microsoft.com/weather</w:action>     <w:to>soap://D.com/some/destination</w:to>     <w:fwd>       <w:via>soap://B.com</w:via>       <w:via>mailto:[e-mail]</w:via>     </w:fwd>     <w:rev>       <w:via/>     </w:rev>     <w:from>soap://A.com/some/origin</w:from>     <w:id>uuid:82e9a994-d345-ace1-b2ba-09a2c5d466</w:id>     <w:relatesTo>       uuid:dd089c-c569-987a-bc23-6532c24da2     </w:relatesTo>   </w:path> </S:Header> <S:Body> ... <!-- Message body here --> ... </S:Body> </S:Envelope>

The example highlights two further points of interest. First, it specifies the reverse path as an empty via element. This indicates that the underlying transport protocol handles the reverse path. For example, TCP can handle the reverse path, but UDP cannot because it does not operate on a request-response model. The second point of interest is that intermediary B acts as a transport protocol bridge because the example references C through the mailto scheme.

WS-Referral

As you have seen, WS-Routing allows you to stipulate both forward and backward message routes. What it does not do is dynamically alter these routes—more specifically, it does not allow one WS-Routing node (a SOAP router) to dynamically insert, delete, or query routing information in another SOAP router. For example, A might want to pass a message to B, but if B now requires the message to pass through an additional intermediary, C, WS-Routing is not appropriate because it does not provide a mechanism for B to inform A of this change of policy. Fortunately, WS-Referral does provide a mechanism to allow B to pass a message to A that indicates that all future messages must pass through C.

Specifically, WS-Referral provides the following four mechanisms that allow you to insert, delete, and query routing entries in a SOAP router:

• WS-Referral statement Describes referral information (such as that just described)

• WS-Referral query message exchange Allows a SOAP router to request referral statements from another SOAP router

• WS-Referral registration message exchange Allows a SOAP router to request that another SOAP router explicitly accept or reject a referral statement

• WS-Referral header Allows a SOAP router to send referral statements to another SOAP router without using WS-Referral query message exchange or WS-Referral registration message exchange

As this list shows, all operations involving WS-Referral revolve around WS-Referral statements.

The following example shows a statement that asks A to route all messages through C if the referral takes less than 21,600,000 milliseconds (6 hours):

<r:ref xmlns:r="http://schemas.xmlsoap.org/ws/2001/10/referral">   <r:for>     <r:exact>soap://A.com/weather</r:exact>   </r:for>   <r:if>     <r:ttl>21600000</r:ttl>   </r:if>   <r:go>     <r:via>soap://C.com</r:via>   </r:go>   <r:refId>uuid:82e9a994-d345-ace1-b2ba-09a2c5d466</r:refId>   <r:desc>     <r:refAddr>       http://B.com/referralDocs/09a2c5d466.xml     </r:refAddr>   </r:desc> </r:ref>

The main part of the WS-Referral statement that the example shows is the for-if-go construct. The for element contains a list of targets, which the statement is intended for. You list each potential recipient using either the exact element (as shown in the example) or the prefix element, which matches any URI that starts with the value defined within the element. The if element places a condition on the statement. If the if condition returns true, the contents of the go element are acted on. In this instance, the go element provides the redirect URI.

In addition to the for-if-go construct, the example shows the refId element, which allows the SOAP router to uniquely identify the statement, and the desc element. The desc element allows you to provide a description of the statement, which in this case is a URI that points to the physical location of a document containing the statement. The desc element is optional.

WS-Referral Query Message Exchange

The WS-Referral query message exchange provides a mechanism by which one SOAP router can request WS-Referral statements from another SOAP router. For example, a SOAP router might want to obtain an update for a WS-Referral statement that has exceeded its time to live. To send a query message exchange, you simply construct a SOAP message that contains a query element within its body. The query element contains a list of intended recipients of the statement.

The following example shows a query in which A requests a WS-Referral statement from B. B responds with a WS-Referral response, which is a simple SOAP message that contains a list of WS-Referral statements within its body.

<S:Envelope xmlns:S="http://www.w3.org/2001/09/soap-envelope"> <S:Header>   <rp:path xmlns:rp="http://schemas.xmlsoap.org/rp/">     <rp:action>       http://schemas.xmlsoap.org/ws/2001/10/referral#query     </rp:action>     <rp:to>soap://B.com</rp:to>     <rp:rev>       <rp:via/>     </rp:rev>     <rp:id>uuid:82e9a994-d345-ace1-b2ba-09a2c5d466</rp:id>   </rp:path> </S:Header> <S:Body>   <r:query xmlns:r="http://schemas.xmlsoap.org/ws/2001/10/referral">     <r:for>       <r:exact>soap://A.com</r:exact>     </r:for>   </r:query> </S:Body> </S:Envelope>

WS-Referral Registration Message Exchange

WS-Referral registration message exchange is a mechanism that allows a SOAP router to explicitly request that another SOAP router accepts or rejects a WS-Referral statement. For example, B might want to route all requests to itself to SOAP router C, perhaps because B wants to reduce the load on itself. B can send A a WS-Referral registration message that asks A to reroute all messages to C. A can then choose to accept or reject the request and send a WS-Referral registration response confirming its intent.

To issue a WS-Referral registration message, you must construct a SOAP message whose body contains a register element, which contains a ref element, which in turn contains the WS-Referral statement to accept or reject. Here is a registration message in which B sends a request to A:

<S:Envelope xmlns:S="http://www.w3.org/2001/09/soap-envelope"> <S:Header>   <rp:path xmlns:rp="http://schemas.xmlsoap.org/rp/">     <rp:action>       http://schemas.xmlsoap.org/ws/2001/10/referral#register     </rp:action>     <rp:to>soap://A.com</rp:to>     <rp:rev>       <rp:via/>     </rp:rev>     <rp:id>uuid:82e9a994-d345-ace1-b2ba-09a2c5d466</rp:id>   </rp:path> </S:Header> <S:Body>   <r:register    xmlns:r="http://schemas.xmlsoap.org/ws/2001/10/referral">     <r:ref>       <!-- WS-Referral statement here -->     </r:ref>   </r:register> </S:Body> </S:Envelope>

WS-Referral Header

The two previous mechanisms allow a SOAP router to either request a WS-Referral statement or issue a statement, which the receiver must accept or reject. However, in some instances, you might simply want to forward referral statements to a SOAP router, which can then do with them what it wants. The WS-Referral header provides a mechanism that allows you to do this. The header is simply a SOAP header that contains a referrals element, which contains the statements to forward.

Here is an example of a SOAP header that contains a WS-Referral header:

<S:Envelope xmlns:S="http://www.w3.org/2001/09/soap-envelope"> <S:Header>   <r:referrals    xmlns:r="http://schemas.xmlsoap.org/ws/2001/10/referral">     <r:ref>       <!-- WS-Referral statement here -->     </r:ref>     <r:ref>       <!-- WS-Referral statement here -->     </r:ref>   </r:referrals> </S:Header> </S:Envelope>

Dynamic Application Topologies

One of the technologies the GXA is enabling is dynamic application topologies. Even though the Internet facilitates ubiquitous communication between the client and the server, the locality of a Web service and its client play a factor in the overall performance. The same problem exists today with HTML-based applications. Companies such as Akamai and Inktomi are providing solutions by caching static Web page content on servers geographically distributed around the world.

Content is hosted on what are termed edge servers. Edge servers are often strategically placed inside ISP networks in effort to reduce the latency of requests made by the ISP's customers. Client requests for the content are then dynamically routed to an edge server that is deemed to provide the lowest network latency for the client.

In addition to performance, another advantage of this infrastructure is that it has the potential to offer excellent availability and scalability. If an edge server becomes unavailable or heavily burdened with requests, the delivery service is responsible for routing the client's request to another server that is better capable of handling the request.

One of the efforts underway is to take these same concepts and apply them to Web services. A variety of companies, including Microsoft, are developing infrastructures that will allow you to host stateless Web services on edge servers.

At the time of this writing, very little information has been publicly released regarding Microsoft's plans to support dynamic application topologies. However, one of the goals that have been announced is the ability to allow developers to decorate which portions of their Web applications can be fanned out geographically. Since the application is self-describing, the supporting infrastructure can make intelligent decisions such as distributing certain portions of the application to a new datacenter recently brought on line.

One of the issues with creating an infrastructure to support dynamic application topologies is abstracting the physical location of a requested resource. Resources such as Web services are often identified by a URL. The URL contains either an IP address or a domain name. An IP address is very tightly coupled with the physical location of the resource. The default behavior of DNS is to associate a particular domain name with a particular IP address, making it tightly coupled to the resource as well.

Services such as Akamai leverage the fact that a domain name provides a level of abstraction from the IP address. These services ensure that their own DNS servers handle name resolution to a particular domain. This allows the service's DNS server to apply an algorithm for determining which IP address will be returned to the client.

There are a few potential issues with this technique. First, you cannot rely on the federated nature of DNS. All name resolutions need to be performed by the service's DNS infrastructure. Second, the URL for a particular resource is often scoped to the domain name of the service provider. If you switch service providers, you need to ensure that all your clients reference the new URL. Finally, the resource is often an obscure series of characters embedded in the URL, further tying you to your service provider. In the future, you will see the evolution of a virtual topology that is more capable of abstracting the physical structure of the Internet.