The Ancient Art of Programming

Two short updates on WS-DuckTyping.

• I will be doing a talk on WS-DuckTyping at SpringOne 2007. As a little joke, I used the word Anatidaeic in the abstract. Until two weeks ago this word had 0 hits on Google. Currently, it has one hit, therefore making it a true GoogleWhack. Of course, writing this post will make an end to that soon.
• I wrote a post on XPath support in Spring Web Services over on the Interface21 team blog. Check it out!

One of the most popular features of languages such as Smalltalk, ObjectiveC, and Ruby is Duck typing. To quote Wikipedia:

[…] duck typing is a form of dynamic typing in which a variable’s value itself implicitly determines what the variable can do. This implies that an object is interchangeable with any other object that implements the same interface, regardless of whether the objects have a related inheritance hierarchy.[…]

The term is a reference to the duck test — “If it walks like a duck and quacks like a duck, it must be a duck”.

So what does this have to do with Web services? Well, duck typing is a great way to create graceful and interoperable Web services. Web services are about exchanging information, and as long as the information walks like a duck…

Here are my three tips to implement WS-Duck Typing:

Don’t validate incoming messages!

Not only is XSD-based validation slow, it also requires strict schema conformation from the other party, thus creating a strictly typed service. Such a service breaks Postel’s Law: be conservative in what you do; be liberal in what you accept from others.

If you really want to do validation, do it on server-side outgoing messages only. After all, you should adhere to your own schema. Also, Schematron is the exception to the rule, since it not based on grammars, but on finding tree patterns in the parsed document. Which brings us to:

Use XPath!

XPath is an excellent way to extract information from an XML document. Code written with XML API like DOM, SAX, or StAX is typically quite fragile when it comes to element ordering, nesting, or unexpected elements. And XML marshalling isn’t much better: some of these API’s throw exceptions in these cases.

Not with XPath. When using XPath, you don’t care whether the <lastName> element is the first or the second child of <person>; the /person/lastname expression grabs it anyway. And if if you really don’t know where to find the last name, you can always resort to //lastname, which finds it anywhere in the document.

In the past, XPath has dismissed as being too slow. With modern XPath libraries which support XPath pre-compilation, this is less of an issue.

Don’t create stubs or skeletons!

This is perhaps the most controversial tip. If you create client-side stubs or server-side skeletons in a strongly-typed language like Java, you throw away any option of being liberal about the XML messages. Instead, you have create a strongly-typed API that is strongly-coupled to the contract, and that passes or expects parameters of a certain kind. If they are of any other kind, or if they are simply not there, your code will never be invoked. Even if you didn’t need the parameter in the first place.

If you treat Web services like XML messaging, rather than RPC, you could have handled the message gracefully: let’s see if I can find the first name under the person element, and if it’s not there, I’ll try and find in anywhere in the document. Still not there? Perhaps it’s an older message: I’ll just apply this stylesheet, and see if I can find the first name then. Et cetera, et cetera.

Hopefully, these tips will help you create flexible, interoperable Web services that gracefully handle XML messages.

Quack!

Whenever somebody says that XML, XSD, SOAP, or WSDL sucks, I am always remember of my high school days.

Here, in the Netherlands, it is not uncommon that pupils learn a third learn a third language, next to Dutch and English. Typically, one chooses either French or German. Most pupils choose French, since German is considered an “ugly” and uncool language. I used to think the same way, until I spent six months in Germany during university, and learned to appreciate the language more.

Learning beautiful words like “feuerzeug” (lit. fire-thing, i.e. lighter), and reading Goethe and Kant in their native language changed my mind, however. German is a beautiful language, and can be much more subtle than French or English.

After all, it’s not about the language, but about the thoughts that you express in it.

Some Web service stacks offer an option to send any server-side stack trace over to the client, as part of a <faultDetail/> block. Axis 1 does it, and it seems like the JAX-WS reference also offers this feature. Presumably, this makes it easier to debug the service from the client side.

Let me explain why I think that there is a big difference between a SOAP Fault and an exception, and why I don’t offer this feature in Spring-WS:

Let’s say I call a public Web service to get a stock quote. Instead of the result, I might get a SOAP Fault as a reponse, which means something went wrong. In SOAP 1.1, a Fault contains four elements, the first two of which are required:

1. a code (a qualified name)
2. a string
3. an actor, and
4. a detail (which can contain any number of xml elements)

A Java or .NET Exception, on the other hand, has just two elements:

1. a string message, and
2. a stack trace

Notice the difference between the two? Of course, you can use the exception message as the fault string, and you can create some kind mapping between the exception class and the code, but that’s your mapping. There is no standard, interoperable way to write stack traces in faults, mostly because stack traces can only be found in Java, but not in C, for instance. And Web services are all about interoperability.

Back to the stock quote: imagine the Web service is not written in Java, but in C, which means we cannot send any stack trace as part of the fault. So what do we send in order to facilitate debugging on the client side? Do we attach the core dump ?

There’s a simple lesson here: it only makes sense to use Web service technology where the client isn’t interested to the language of the server. If you really want to see the stack trace on the client-side, use Java RMI. If you want to invoke a method on a class written in another language, use CORBA or Hessian. If you want to do XML messaging, use SOAP.

Compare the following quote from the EJB 1.1 specification:

The Application Assembler is a domain expert who composes applications that use enterprise Beans.

to this quote I found describing BPEL:

After the developer does the prep work, a domain expert pulls the services from a palette and connects them with lines that represent workflow.

Now, I’ve made quite a few EJB’s in my day, but I’ve never met an Application Assembler in my life. Somebody who took (existing) components and created new applications using them. Somehow, it all came down to us developers.

My burning question is: what has changed? Why would the domain expert want to compose services with BPEL/WS/SOA, when he didn’t want to with EJB?