Last week I blogged about Arjen’s WS-Duck Typing and how Spring-WS enables “duck typed” web services.

Andres Aguiar points out an enormous change to the behavior of data access in tiered architectures that…

My opinion on validation comes from experience. The B2B system that I worked on tried to take this many messages, one transformation process. It ended up being a huge unmaintainable mess where pretty much every change resulted in problems processing stable clients’ messages. The approach that did work was having a canonical form and transforming everything into that form to pass on to a core processing module. This is actually more flexible because you can still use the approaches you are advocating when it makes sense. It also let us process messages using completely different and incompatible standards with the same core functionality.

This approach takes more work than what you are advocating but for industrial strength b2b services it’s a best practice. Really, it supercedes that approach. It may be overkill for some situations but we had 100s of consumers and producers to support.

I can understand your POV on validation, but I don’t agree with it. Which I think is OK, and does not imply that either you or Arjen practised “FUD” — just that we have different experiences.

Glad to see the discussion focusing on technical aspects now.

You write:

“So instead, in might be useful to create one course-grained type, and use that in all operations, which eventually results in sending more information than is strictly required. The question is whether you want to validate this non-required information.”

This may seem like a good idea but when you have hundreds of different producers all with their own idiosyncrasies, it’s going to turn into spaghetti code. How is this any different than the monolithic procedural approaches of the past? I prefer an object-oriented-like approach where each message has it’s own type.

I think calling this approach duck-typing is a little misleading. In duck-typing, a given object is treating as being a certain type if it has the required operations. That’s part of the technique you are describing. But the other part is not similar to duck-typing. It’s more like pattern matching but I predict that in most cases it will degenerate into something more like the following (sometimes necessary) anti-pattern:

if type(input) == str: // do this elif type (input) == dict: // do that else: // do the default

That’s reasonable. I suppose a lot of this depends on the context. In my B2B experience, messages were effectively contracts often worth hundreds of thousands of dollars a pop. It’s not sensible to be loose and fast with this kind of thing. Accepting a bad message would even violate our service agreements. But now I am using XPath to glean info from exported ‘code’ from a gui and I couldn’t care less about the schema. I’m /*//ing without a care in the world.

But to imply validation is an ineffective technique is not correct. It may not be appropriate in all contexts but it’s definitely very useful and important in many others. The problems with different messages still arise but the solution is different when you need strict validation.

In my post, I said that code written with SAX is “typically quite fragile”. This doesn’t mean that all SAX code is fragile. It just means that, as you stated yourself, a lot of people don’t get functional APIs, and tend to write fragile SAX code. This isn’t about what I do, nor is it about you do, nor is it what I recommend, but it’s about what I’ve seen happen in the field. The same thing applies to StAX or DOM code, by the way: the code in the link that Stefan posted can be made less fragile by not assuming the first element is the only interesting element. It can be done in a better way, but it’s not typical. XPath just conveniently bypasses these issues.

Also, grabbing an element from somewhere else can be perfectly acceptable in some cases. If a small document only contains one phone number, then who cares where it is located? If it contains multiple phone numbers (like in the address example you describe), then grabbing it from anywhere is probably a bad idea. It all depends on the context.

@Contract Nazi I don’t agree. The question is not whether the message conforms to the schema; but whether it contains the information required to process the request. These two might be the same (i.e. the schema only contains the necessary information), but that might mean that you will end up with a lot of similar types in the schema (i.e. one type per operation). So instead, in might be useful to create one course-grained type, and use that in all operations, which eventually results in sending more information than is strictly required. The question is whether you want to validate this non-required information.

“If you send me a message constructed within these constraints I’ll guarantee to respond in this predicatble way.”

The inference being, that if the service consumer does not abide by the published constraints, that is the contract, then all bets are off. The service provider doesn’t need to validate the request in order to meet his side of the contract.