Sign In/My Account | View Cart  
advertisement


Listen Print

WSDL Tales From The Trenches, Part 2
by Johan Peeters | Pages: 1, 2

Error handling

Perhaps the single most important difference between a demo and a production-quality service is the quality of the error handling. Yet the literature pays little attention to this topic.

Defining separate messages in order to distinguish between error conditions can be convenient; the structure of such messages may vary according to the error condition that occurred. This listing specifies a web services that will raise the hackles of any system administrator: it runs a binary supplied by the caller. I apologize to readers that are looking for examples of good use of namespaces and modularization, as this will not do. The example focuses on error handling. Two errors have been foreseen in the design: first, there may not be enough memory, in which case the allocated heap space and the amount of memory in use is returned; second, the program may attempt to dereference a null pointer, in which case a stack trace is returned.

The fault message types are derivations of an abstract type. The motivation for the abstract type comes from mapping the faults to an inheritance hierarchy in one or more programming language. So this revised listing is a more compact WSD. The differences between the sets of (fault) messages that are valid according to the respective documents are minute.

The intent, however, is a lot clearer with the former document; client implementors working with the latter document will likely surmise that an OutOfMemoryException may be returned. But it is not clear from the specification that this is the intention. Neither can client implementors feel confident that their code covers all fault conditions since the abstract tException type may have been extended by types other than the ones listed in the latter document.

I have seen hybrid approaches, ones where the supertype is not declared abstract. In this universe, fault messages may be specified in the WSD to be of a derived type, sometimes the supertype is specified. This creates even greater uncertainty regarding the exact format that will be received by the client; hence, I do not recommend it.

document/literal versus rpc/encoded

The accepted wisdom is to use literal wire format with document invocation style and encoded with RPC invocations. There are no fundamental reasons for this restriction; it is rather a historical coincidence that tools tend to support (one of) these combinations.

The trade off is between the complexity of the programming model and the complexity of message marshalling. RPC offers a comfortable programming model. It is not without its dangers, as I pointed out in the previous article. However, it is also important to be aware of the obligations that the wire formats used with RPC impose on marshalers: the distinction between literal and encoded is between writer and reader makes right, respectively. This means that the latter wire format may have many different representations for semantically equivalent messages.

The classic example is SOAP's encoding support for both independent and embedded elements. It is up to the receiver to understand all representations. I already indicated the importance of nailing down the format of the messages as much as possible in the previous section. The reason for this is that reader-makes-right comes at a cost. This may not matter in environments where sophisticated tools are available to generate client stubs, but working with heterogeneous platforms, this is by no means always the case.

The shape of things to come

As mentioned previously, WSDL 1.1 does not carry the weight of a standard. Yet the specification has been widely used, often frustrating hopes for interoperability. Thus the motivation for WS-I entering the fray; not to take ownership of the WSDL standard, but to define profiles "consisting of a set of non-proprietary Web services specifications, along with clarifications and amendments to those specifications which promote interoperability".

I cannot help feeling irritated at having to keep yet another organization dealing with standards on the radar. Despite its declared aim, I fear that initiatives such as WS-I will lead to the balkanization of standards. Nonetheless, I would recommend reading section 5 of the Basic Profile Approval Draft, which does a pretty good job of clarifying some of the darker recesses of WSDL 1.1. And yet I do not like the fact that they focus all their attention on SOAP.

In the previous installment I also briefly discussed the OASIS WSS TC, which seems to be taking the lead in the definition of web services security standards. Yet another body bringing a much-needed piece of the puzzle. But are the pieces going to fit, and who is going to be putting them all together?

Ownership of future versions of WSDL seems to firmly rest with the W3C where a Web Service Description Working Group has WSDL 1.2 in the making. According to its charter, the release for the new specification is planned for May 2003. That target is clearly going to be missed. Nevertheless, the shape of things to come is emerging in the drafts they occasionally publish. So what is likely to happen to the anomalies we covered above?

The draft available at the time of writing seems to confirm the interpretation of what ends up in the target namespace of a WSD. It says that the "targetNamespace attribute information item defines the namespace affiliation of top-level components defined in this definitions element information item. Messages, port types, bindings and services are top level components." Whether WSDL 1.2 will support implementing several interfaces in a single service is hotly debated right now. The WSDL 1.2 draft states explicitly that the same rules against sharing namespaces with imported documents apply as in XML Schema. On the other hand, an alternative mechanism for modularizing descriptions is provided via an include element modeled on XML Schema's include element that does allow sharing of namespaces.

Acknowledgments

XML Spy is a registered trademark of Altova GmbH. To Caroline Greenman, thanks for comments, as always.

Resources

Here are some resources that give good advice on writing WSDL:

For the diehards, it is of course essential to read the W3C WSDL 1.1 Note. I would recommend section 5 of Basic Profile Approval Draft too as it clarifies many points in WSDL 1.1. The Web Service Description Working Group are in the process of writing the WSDL 1.2 specification. From time to time a draft is published.