Future Directions for Web Services

< BACK  NEXT >

[oR]

The technologies of Web services are certainly usable today, but they're also not fully mature. Many useful features could be added, and it's a safe bet that, one way or another, these features will find their way into the W3C specifications. As mentioned earlier, for example, SOAP allows adding arbitrary headers. Yet effective, full-featured interoperability among different vendors' SOAP implementations requires agreement on how at least some of these headers should look. Toward this end, Microsoft in late 2001 announced a Global XML Web Services Architecture (GXA). Although initially a Microsoft-only proposal, the company's stated intent is to submit this work to the W3C, then to conform to the standards that ultimately emerge from that organization.

Microsoft's GXA defines additions to SOAP

The GXA specification defines a set of SOAP headers for addressing common problems. These headers, and thus the services they provide, can be combined as needed for a specific application. The initial GXA specs define headers in four areas:

• WS-Security: Provides a way to pass security credentials, such as the identity of the client, and to indicate what options (if any) are being used to provide integrity and confidentiality for a SOAP message. An integrity service allows the message's receiver to be certain that the message wasn't modified in transit, while a confidentiality service typically encrypts a message so it can't be read in transit.

• WS-License: Provides a standard way to identify common kinds of credentials, which are referred to in the specification as licenses. Among the supported options are Kerberos tickets and X.509 certificates, each of which relies on strong cryptographic techniques to allow the receiver to verify a client's identity. WS-License is typically used together with WS-Security, as the example shown later in this section illustrates.

• WS-Routing: Defines header information that can be used to route messages across intermediate SOAP nodes. Note that this routing happens at the application level, and so is distinct from the service that network routers provide.

• WS-Referral: Defines header information that allows configuring SOAP implementations to route SOAP messages correctly. Unlike WS-Routing, which is used to specify what path a particular SOAP message should take, WS-Referral allows configuring the SOAP systems themselves to route messages correctly.

GXA addresses security and routing of SOAP messages

To give some sense of how these are used, here's an example of how the simple SOAP message shown earlier might look if it used some of the headers defined by WS-Security and WS-License:

 <soap:Envelope    xmlns:soap=       "http://schemas.xmlsoap.org/soap/envelope/"    xmlns:xsd=       "http://www.w3.org/2001/XMLSchema"    xmlns:xsi=       "http://www.w3.org/2001/XMLSchema-instance">    <soap:Header>      <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:kerberos"            xsi:type="xsd:base64Binary">               eMrrI4GIEBAgIiIOgay52ZXJpc2lnbi5j ...         </wslic:binaryLicense>      </wssec:credentials>   </soap:Header>   <soap:Body>       <GetBalance          xmlns="http://www.qwickbank.com/bank">          <Account>729-1269-4785</Account>       </GetBalance>    </soap:Body> </soap:Envelope> 

Like the earlier example, this message contains a Body element wrapped in an Envelope element. While the message body is just the same as before, the envelope defines some extra namespaces and also contains a Header element. Inside this element is a credentials element, complete with an attribute defining a namespace. Inside the credentials element is a binaryLicense element, which also includes an attribute identifying an appropriate namespace. This binaryLicense element contains other attributes as well, indicating that the license supplied is a Kerberos ticket and specifying how the ticket is encoded. The ticket itself follows, although only part of its binary value is shown here.

Defining standard headers for common functions is important. There are other enhancements that can also make Web services technology more effective, however. One of these is a mapping of SOAP directly to TCP, an option known as Direct Internet Message Encapsulation (DIME). Doing this makes getting through firewalls a bit more challenging, but it also allows better performance than sending SOAP messages over HTTP. Other likely enhancements include a standard way to identify transactions in SOAP messages and a way to guarantee reliable delivery of those messages. More additions are sure to come, as Web services continue to work their way into the fabric of modern computing.

DIME allows mapping SOAP messages directly to TCP

< BACK  NEXT >