The Standards

Work continues apace on the core Web standards we’ve covered in this book (and plenty more) in an effort to give the Web services platform a richer function set to work with. Appropriately enough, the best overview of the standards work going on is in one of the standards being written at the moment: the working draft for a reference Web Services Architecture (WSA), which can be found at http://www.w3.org/TR/ws-arch/. The goal of the WSA is to describe a standard generic model for a Web services framework and the functionality it should provide. Like the Open Systems Interconnection (OSI) 802.1 network layer model, it’s being written to show how the pieces of the framework should work and be linked together but doesn’t prescribe any particular standard technology to implement them. (It does use SOAP, XML, and WSDL as examples, however.)

If you’re wondering why the WSA is only in working draft form, consider that there isn’t yet a unified view of what Web services should do or how they should work. That understanding is slowly coming together, however, and the World Wide Web Consortium (W3C) now feels confident that it can write a reference specification that won’t need tearing up and rewriting six months down the line. Now that the plumbing is quite stable, it might not change shape again for quite a while.

The draft document describes the WSA in terms of a basic architecture—the plumbing that we know and love—and an extended architecture, which Microsoft, IBM, and several other companies are starting to work on. We’ll look at the work being done on each of them in turn.

The Basic Architecture

The core part of the WSA (often referred to as “the plumbing” in this book) is currently implemented by the standards we investigated in Chapters 2, 3, 4, and 6. That is, the basic architecture includes the following technologies:

• The wire stack, where client and server can exchange messages

• The description stack, where a Web service can be described to the client

• The discovery agencies stack, where servers can publish Web services and clients can discover them

If you believe the word on the street, the plumbing has pretty much come together and is quite mature. However, of the six technologies shown in Figure 16-1 that make up the plumbing, only SOAP is not still being directly altered.

Figure 16-1: The basic plumbing of the WSA and the standards that currently implement it

The other technologies are being worked on either directly or by extension to increase their usefulness. Even the W3C states that it will continue to work on this basic architecture until the end of 2004. By then, either all the issues raised by the six technologies will have been addressed or something else will have taken their place. It’s valid to argue that standards should be “frozen” before they become obsolete, but that’s an argument for a different time. We need to stay in the present and consider the three tasks that the basic architecture defines: message exchange, service description, and publishing and discovery.

Message Exchange

Of the three tasks, message exchange, as executed in the wire stack, is in the best shape. XML has always been the choice for carrying messages, and with SOAP we have a simple yet flexible and extensible format for phrasing those messages. HTTP 1.1 will remain the transport protocol that SOAP binds to as a template in its specification, but work continues apace to produce standard bindings to other protocols as well, as you can see in Figure 16-2.

Figure 16-2: The wire stack and the technologies involved in each layer

XML and Unicode

The W3C will release version 1.1 of the XML and Namespaces in XML specifications in 2003 to make use of Unicode 3.0. XML 1.0 disagrees with Unicode 2.0 slightly and the new version corrects that problem, but it is backward incompatible as a result.

From a Web services point of view, the inclusion of Unicode 3.0 in the XML space is welcome, but some issues (especially internationalization issues) still haven’t been resolved. For example, a URI in an XML document can be written in any character set as long as that character set is identified in the processing instruction at the top of the document, but by specification (in RFC 2396 to be exact), URIs must be written in 7-bit ASCII. This is fine if you generally use the ASCII set of characters in daily life, but what if, for example, a Vietnamese developer wants to use a Namespace URI (corresponding to his schema) in his own character set? Converting his UTF 16–encoded URI for display in a browser down to ASCII would probably involve the browser changing at least every other character in the URI into an escape sequence that the browser could display. The readability and ease of use of a URI depends on the character set it originated in. When asked to write the URL for his services’ schema on the back of his business card, should the Vietnamese developer write it in his native language or the escaped URL that the browser will understand?

You can find the XML 1.1 specification at http://www.w3.org/TR/xml11/ and Namespaces in XML 1.1 at http://www.w3.org/TR/xml-names11/. A complete list of issues identified so far between Unicode and XML can be found at http://www.w3.org/ TR/unicode-xml.

HTTP

HTTP 1.1 has been the de facto standard for transferring messages and data across networks for six years. However, groups are working to add extensions to (or even replace) HTTP to help those who are trying to implement the extended architecture (which we’ll look at shortly). The following projects aim to improve on or replace HTTP:

• The HTTP Extension Framework (http://www.w3.org/Protocols/HTTP/ietf-http-ext/)

• A purely XML-based protocol called XMLP (http://www.w3.org/2000/xp/Group/)

• A robust version of HTTP called Reliable HTTP (http://www-106.ibm.com/ developerworks/library/ws-phtt)

IBM is working on Reliable HTTP, which provides the reliability of robust messaging systems such as its own MQSeries. Developers whose Web services run over Reliable HTTP will be able to determine the quality of their service—an issue that is preeminent in the Extended WSA, as you’ll see shortly.

Interestingly enough, these projects intersect neatly with others that affect or will affect the SOAP envelope. For example, if you send SOAP messages over Reliable HTTP to monitor the quality of Web service response, that functionality will be restricted to servers that can work with Reliable HTTP. If we can incorporate what Reliable HTTP does into a SOAP header with a little programming, we can have that quality of service across every protocol. Indeed, work on the HTTP Extension Framework at the W3C has been suspended, and using SOAP headers is one of the suggested alternatives.

SOAP

The W3C’s involvement in the creation of SOAP 1.2 is the first time the organization has had access to this standard, and it has tried to remove as much of the ambiguity from the specification as possible. For example, SOAP 1.2 uses the XML Infoset (http://www.w3.org/TR/xml-infoset/) to describe the contents of a SOAP message rather than the XML specification itself, in accordance with the WSA draft.

This effort has the desired effect of making it a lot harder for Web service toolkit developers to misinterpret what each piece of SOAP 1.2 should do—but at the cost of readability and, some would say, uniformity. (See http://www.xml.com/pub/a/2002/11/20/ends.html for the full argument.) SOAP 1.1 is simple to understand, while SOAP 1.2 has twice as many specification documents, which are themselves twice as long and twice as dense as those in SOAP 1.1. S now stands for “strict but still extensible” rather than “simple,” it would seem.

You can find a full list of differences between SOAP 1.1 and 1.2 in the SOAP 1.2 Primer document (http://www.w3.org/TR/2002/CR-soap12-part0-20021219/#L4697). In brief, SOAP 1.2 does the following:

• Changes the SOAP media type to application/soap+xml, in line with RFC 3023, and it removes the SOAPAction HTTP header

• More strictly defines the use of the SOAP <fault> element and its child elements and clarifies which HTTP status code to use when

• Defines new syntax for use when sending SOAP messages via one or several intermediaries

• Includes the W3C Schema 1.0 Recommendation

• Tries to make the serialization of messages using SOAP encoding less complex

• Doesn’t currently comply with the WSA draft because QNames might be used to identify certain items in a SOAP envelope rather than URIs

This last point isn’t a specific feature of SOAP 1.2, but rather of the WSA draft. Indeed, the W3C XML Protocol Working Group, which looks after the SOAP standard, is working closely with the Web Services Architecture Working Group to marry the two. As you’ll see in a minute, the latter group has also been quite busy trying to extend the reach of SOAP, with several adjoining specs for SOAP 1.2 addressing issues such as attaching items to SOAP messages and using SOAP headers to enable various security efforts.

Service Description

Compared to the wire stack, the description stack (shown in Figure 16-3) is almost in disarray. Developers are still learning what it should do. In the meantime, a lot of work remains to be done by the W3C before this part of the WSA is comprehensive. The XML Schema specification is very stable, but WSDL still needs some fairly major work. The top layer of the stack, collaboration description, will deal with describing how one Web service should interact with another, but little has been done about this yet. (More on this later.)

Figure 16-3: The WSA description stack

WSDL

Like SOAP 1.2, WSDL 1.2 will be the first version of the standard written by the W3C. Unlike SOAP 1.1, however, WSDL 1.1 isn’t almost complete. Indeed, it could be described as the spaghetti stuck to the wall after the contents of the brainstorm bowl have been thrown at it. No one knew exactly what WSDL should do when it was designed, so it was built to cover everything it should do and some things it shouldn’t. Only since it has been tried out has it become clear what exactly it should do. One could argue, for instance, that WSDL’s <service> and <binding> elements would be more at home in UDDI. The Web Services Description Working Group, which looks after the development of WSDL, therefore has four tasks ahead of it:

• Streamlining WSDL to do only what it must

• Making WSDL less ambiguous by describing the contents of a WSDL document in terms of the XML Infoset

• Adding binding support for SOAP 1.2 to WSDL

• Collaborating with the W3C Semantic Web Activity to develop a more meaningful description of a Web service (http://www.w3.org/TR/2002/WD-owl-guide-20021104/)

The last point is particularly interesting not only because it marks the first good, solid application of the semantic Web activity onto another area of the W3C but because it also represents cooperation rather than a clash between WSDL and UDDI. The taxonomy (classification) of the Web service described in UDDI will form part of the service’s ontology (semantics) in WSDL. Exactly how this will be achieved is best left to the experts, but a WSDL document will eventually describe the context in which a Web service should be used as well as the interface it exposes—and that’s a powerful thing.

Schemas

As the W3C’s only XML-based interface definition language, Schemas appear to have a secure role in the WSA that will remain so for quite a while. The first working draft of WSDL 1.2 provides for the use of RELAX NG documents and document type definitions (DTDs) in addition to Schemas, but more for convenience than anything else.

More interesting perhaps are the extensions to the Schema specification beyond the updates to match the latest version of XML. Schematron (http://xml.ascc.net/xml/resource/schematron/schematron.html), for example, allows you to put comparison constraints on the elements of a SOAP message in addition to the structure and strong typing that Schemas allow. You saw in Chapter 10 that you can accommodate that kind of constraint as a SOAP extension, but it would be far more powerful as a mandatory part of the WSA. An adjunct standard, perhaps?

Publishing and Discovery

The discovery agencies stack (shown in Figure 16-4) is in a completely different situation from the wire and discovery stacks in that no single component of the stack is yet accommodated by an actual standard.

Figure 16-4: The current implementation of the discovery agencies stack is almost completely dependent on UDDI.

UDDI

UDDI 3.0 was released in July 2002 by the UDDI Project (http://www.uddi.org) and subsequently handed over to OASIS (http://www.oasis-open.org) for standardization. Its adoption has been a little slow, even though compared to earlier versions UDDI 3.0 offers better integration with other standards and provides for private UDDI registries. Version 3.0 has grown a great deal compared with version 2.0 (11 APIs instead of 3), but most of the growth is related to interdirectory communication and handling the distribution of the registry between the three root directories. Version 3.0 does provide explicitly for private UDDI servers, but small local servers such as the new UDDI Server in Windows 2003 Server don’t need the complexity of UDDI 3.0, which is why Windows 2003 Server supports only versions 1.0 and 2.0 of the UDDI API. You might not be surprised to learn that OASIS is working to make version 2.0 a standard first rather than version 3.0.

Discovery technologies can only ever be reactive to technologies in the description stack because their main purpose is to direct a user to the location of a service’s description. A lot can be done to improve the publishing mechanism, security, and directory services of UDDI registries, but the standard itself will always need to be in line with the latest version of WSDL, WS-Data, or whatever the description is at the time. The W3C itself might be finished by 2004, but OASIS will probably work with UDDI for quite some time after. Just as the W3C is starting to look at the addition of semantic syntax to WSDL, so too will OASIS need to acknowledge that sooner or later users will want to scope out the intention of a service from a UDDI registry as well as its concrete details.

WS-Inspection

WS-Inspection has been around since November 2001, but even though Microsoft created it with IBM, it hasn’t paid much attention to WS-Inspection until recently, preferring to stick with the DISCO mechanism to browse for service descriptions on a network. IBM, meanwhile, handed over its Java implementation of WS- Inspection, WSIL4J, to the Apache group; it is now part of Apache Axis.

Essentially the next generation of DISCO, WS-Inspection sits on top of a network and draws into one predetermined place entries for the various services and their descriptions resident on a server or network. Microsoft will include WS-Inspection as part of its Web Services Enhancements (WSE) for Microsoft .NET download at some point to mirror its inclusion in the WS-* Interop group of specifications.

You can find out more about WS-Inspection at http://msdn.microsoft.com/library/en- us/dnglobspec/html/wsinspecspecindex.asp .

Users on the discovery stack

It seems a bit inconsistent that the technology in the discovery stack is more advanced than that in the description stack if one relies on the other. How can the developers of WSDL just be figuring out what WSDL should do exactly while the UDDI Project already has a clear idea? If the aim of UDDI is to present a way to publicize and locate services’ WSDL documents, why isn’t it doing so? Ignoring the many hundred entries for “Hello World” services, the four root UDDI servers contain many times more entries for services than they do the WSDL documents for those services. Why? Because although the UDDI Project might know where it’s going, service developers are more at ease with WSDL than they are with publishing information on a UDDI server. It would seem that the developers of UDDI need to talk more with the WSDL team, figure out which technology needs to do what, and then figure out how to get the service developers to do what they should—publish their WSDL documents on the UDDI server as part of the service’s entry in the UDDI directory.

The Extended Architecture

As its name would suggest, the Extended Web Services Architecture strives to provide the functionality that developers expect from a mature distributed architecture framework. Implementing the basic architecture just gets the system up and running across the wire, but it’s the pieces that bolt on top of it that make for a great system that people want to use. (See Figure 16-5.)

Figure 16-5: The Extended Web Services Architecture

The present WSA draft gives a partial list of the features that should be incorporated into Web services operations. These and several other features can be divided into two groups. The first group includes features that can be implemented within the operation stacks of the basic architecture:

• Asynchronous messaging

• Adding attachments to your messages

• Caching

• Binding to different protocols

• Sending messages via intermediaries

• Making Web services stateful within their parent application

• Cooperation between (the orchestration of) Web services

The second group consists of features that apply to every layer of the WSA:

• Security

• Transactions

• Quality of service

Web service developers with access to the .NET Framework and the Web Service Enhancements add-on pack for .NET already have access to some of these features, to one degree or another (as covered in Chapters 12 and 13).

Of course, Microsoft isn’t the only one looking at the concepts and tasks to implement in the extended architecture. IBM/OASIS, Sun, and Hewlett-Packard have their own equivalents of the WS-* Interop initiative, but to keep confusion to a minimum, we’ll concentrate solely on the W3C and Microsoft. If you’re curious what the others are doing, check out http://www.zapthink.com/reports/poster.html or http://webservices.xml.com/pub/a/ws/2002/01/09/soap.html for a round-up and http://www.xml.com/2003/02/12/deviant.html for an overall view.

Wire Stack Extensions

SOAP was designed to be simple and extensible, and almost all the stack-specific extensions to the WSA shown earlier in Figure 16-5 are based on either the bindings of SOAP to protocols other than HTTP or the definitions of new features to be added in the SOAP <header> element.

HTTP remains the protocol of choice for communication over the Web, but in version 1.2 the SOAP standard for the first time explicitly states that it is independent of any transport mechanism. Systems have of course already used SOAP messages across other protocols, but there’s now an opportunity to lay out standards for binding SOAP across a variety of transports. The W3C is already working on a standard binding for SOAP over e-mail (http://www.w3.org/TR/soap12-email), giving us true asynchronous messaging in addition to the ability to use HTTP messaging asynchronously. It wouldn’t be a surprise to see it bound formally to a P2P protocol, such as Jabber or Groove; several proprietary messaging systems such as Microsoft Message Queuing (MSMQ) or the MQSeries; or even multicast protocols such as User Datagram Protocol (UDP) in the future (especially if you could present some use cases for the existence of those bindings).

On the SOAP <header> front, meanwhile, the WS-* Interop initiative is already looking to accommodate the rest of the wire stack extensions (attachments, routing, referral, and sessions). Indeed, in Chapter 13, you saw how the WSE pack implements these extensions using SOAP header elements to store the necessary information to carry out the relevant tasks. The W3C is also developing a standard for adding attachments to messages (http://www.w3.org/TR/SOAP-attachments) that complements Direct Internet Message Encapsulation (DIME).

Combining Web Services

As we noted earlier, the basic WSA defines a third row of the discovery stack that covers the collaboration, or orchestration, of Web services—that is, the combination of two or more Web services at run time in a business process that’s invisible to the user. Because the implementation of a Web service is regarded as a software module or component, it would seem natural to create more complex services by adding together simple ones.

A combination of Web services could play one of several roles. Intraenterprise Web services might collaborate to present a single Web service interface to the public. Optionally, Web services from different enterprises might collaborate to perform machine-to-machine or business-to-business transactions. Alternatively, a workflow manager might call each Web service in turn to participate in a business process.

Microsoft’s Biztalk Server takes this latter approach using the XLang (http://www.gotdotnet.com/team/xml_wsspecs/xlang-c/default.htm) language to orchestrate interchanges between services. On the broader front, the W3C has begun to tackle this issue quite late in the day. With several orchestration languages in the works—Web Services Flow Language, Business Process Modeling Language, and XLang—the standards body’s new Web Services Choreography Group will have a tough time reconciling the ideas of each effort into a cohesive standard to sit next to WSDL. Indeed, it might have a worse time trying to resolve the many intellectual property issues that it is sure to face for having appeared so late at the party. You can read more on the problems facing Web services orchestration at http://www.infoworld.com/article/02/07/05/020708plweborch_1.html .

Universal Issues

On all three stacks the WSA must address three important concerns at all levels—security, transactions, and quality of service. To be sure, these will not be the only overarching concerns, but they are currently the most evident. The key will be to make sure that each stack addresses these issues and that they can be integrated quickly and safely with any new concern or technology that is introduced to the WSA as a whole.

Security

As with any other interchange that occurs across a wire, one of the primary concerns with using Web services is how secure you can make them. Can a SOAP message be kept confidential, its sender be authenticated, its security level be expressed, and its integrity be checked at the end of its journey? We’ve already spent a chapter looking at the various APIs and specs in the WS-* Interop group that deal with security, so here we’ll just note two more points:

• No single security solution currently covers every aspect of the basic Web Services Architecture. For example, WS-Security covers how to send keys and encrypt with them but doesn’t cover key exchange or maintenance. It is possible to implement the W3C’s own XML Key Management System in ASP.NET, however (http://msdn.microsoft.com/library/en-us/dnaspp/html/implementingxkms.asp).

• Every new feature introduced in the extended architecture will likely require new security measures. For example, if you get two Web services to collaborate, how do you ensure that the request message and the response message remain secure as they’re passed between the two? You would have to either make sure the collaboration language agrees with the security language or rewrite the security mechanism to account for the collaboration.

Transactions

You’ve learned in the course of this book that in .NET, Web services can take part in a transaction only as the root of a new transaction. If one transactional Web method calls another, each takes part in its own transaction. That’s the current situation. The feature set for the extended WSA includes both session support and Web service collaboration, so transactions can potentially extend across Web services and perhaps even across applications. How to accommodate such long-running transactions—in particular, how to store the extended and distributed rollback information—is yet to be established. WS-* Interop includes WS-Transaction (which sits in the WS-Coordination framework), which starts to address this, but WS-Transaction and WS-Coordination haven’t been implemented as part of WSE. Both are still in early development.

Quality of Service

Quality of service at a messaging level refers to the ability to send a message exactly as given and to send it only once to the given recipient and send an error back if this is not possible. Current efforts in this field include:

• Using Reliable HTTP as the underlying transport protocol (as discussed earlier) to provide for some measurement of the message’s arrival and the communication of that measurement in the request/response headers

• IBM’s Web Service Endpoint Language, which aims to provide an XML format for handling endpoint management, including quality of service, usage, and security characteristics to include in SOAP headers

Quality of service also implies that a server and its services guarantee a certain level of service. Web services must be able to specify dispute resolution authorities, provide references, perhaps even employ distributed reputation systems, and specify legally binding guarantees of service. The OASIS Web Services Reliable Messaging technical committee will be working on this (http://www.oasis-open.org/committees/wsrm/).