This is a single archived entry from Stefan Tilkov’s blog. For more up-to-date content, check out my author page at INNOQ, which has more information about me and also contains a list of published talks, podcasts, and articles. Or you can check out the full archive.

Runtime Interface Dependency

Stefan Tilkov,

Don Box disagrees with my opinion that stubs and skeletons are evil:

Ultimately folks who use languages with dots (e.g., Ruby, C#, Javascript) or with slashes (XPath, XSLT, XQuery) often make assumptions about the “shape“ of the messages they process. At MS, we’ve built “dot-based“ programming models over XML that are liberal in what they allow, but ultimately if a user depends on access to an element named “foobar“ that element needs to be in the XML whether the user is using dots or slashes. Yes, people can program around missing/optional data (thank God for null), but again, most programs that consume XML make some commitment to element and attribute names that wind up being an intrinsic part of the definition of the program (even when those parts of the program are stored out of band from the code stream (e.g., attributes)).

I agree with this — my code will depend on some elements and attributes in the document. The problem, though, is that even if my application only accesses 20% of the elements and attributes in the XML it consumes, the (un)marshaling/(de)serialization code will require a perfect match between the XML and the schema that was current when the code was generated. In other words: while my application code may be tolerant to at least some changes, the generated infrastructure code isn’t (at least not in the general case — BOCTAOE, possibly the MS tooling being one).

I much prefer what Spring WS creator Arjen Poutsma calls the anatidaeic approach ;-)

On May 30, 2007 4:22 PM, Mike Glendinning said:


The truth here, of course is that the contract between service provider and consumer is [usually] unique for each consumer. In your example, by needing and using only 20% of the information returned, you’re effectively defining a new contract for yourself as consumer, incorporating just that 20%.

Currently, many people, as well as the available tools, assume that there is a single contract defined by the provider and that this applies to all consumers, which is obviously insufficient.

With a mechanism for realising such unique contracts (and here, like you, I would prefer a Schematron-like approach) there seems no reason why tools could not generate stub code as flexible as anything crafted by hand.

Remember also that if the goal is loosely-coupled and autonomous services, you should not make any assumptions or enforce restrictions about how a consumer or provider is implemented. Whether it is Java, C# or Ruby should be irrelevant to you. Likewise whether it is automatically generated code or hand-crafted by an expert!

The Robinson/Fowler paper on “Consumer-Driven Contracts” [1] was an interesting start to understanding and developing this area, but I feel that much more is still needed…



On May 30, 2007 4:50 PM, Sergey Beryozkin said:


What about the XML versioning techniques ? Things like ignore unrecognized elements. May not always be possible to ignore but if the generated code is generated with the ignorability in mind then it might work

Cheers, Sergey

On June 6, 2007 7:25 AM, Stefan Tilkov said:

Sergey, sorry, only just noticed your comment … I’m not aware of any WS toolkit that generates change-resistant code. Are you?

On September 8, 2007 6:24 PM, Oliver Newell said:

Hi Stefan -

I have had some success w/respect to change-resistant code using Spring-WS in conjunction with Apache XMLBeans. XMLBeans provides some hooks which can be used to allow a message consumer to successfully read incoming messages based on new ‘minor releases’ of a schema, where minor releases are by definition backwards-compatible. Basically, all the new elements/namespaces/whatever in the incoming message get ignored by message consumers based on older versions of the schema.

See the post at:

On September 8, 2007 6:44 PM, Oliver Newell said:

For whatever reason, the double-dash ‘—’ before the ‘tf4362130.html’ in the link I posted above is getting converted to the string ‘%E2%80%94’ when clicked on (and it’s not working in my browser). It does work if that escape string is hand-edited to replace the escape string with the original ‘—’ …


On September 9, 2007 4:48 PM, Stefan Tilkov said:

Thanks Oliver. The reason for the conversion is “Smartypants” which does some smart things on special sequences that turn out not to be so smart in this case. Enclosing the URL in backticks (“`”) fixes the problem.