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 ;-)
Stefan,
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…
-Mike.
[1] http://martinfowler.com/articles/consumerDrivenContracts.html