So do angle brackets really matter?

Dare continues our conversation with this comment to my last post, my comments are inlined:

It seems to me your are conflating a lot of concepts. I tend to agree with your statements about 3 web service stacks as evidenced by my most recent blog post. On the other hand, I also believe that knowing nitty gritty details about transport protocols is simply not important for a large number of developers building distributed applications. I've built applications that use HTTPS/SSL and I don't know any details of the protocol.

I hadn't read your post yet, but I have now and I think we're on the same page about reach. I do think that a lot of developers know a lot about HTTP details - what headers they need to send to achieve desired affects. I agree that they don't know much about how HTTPS/SSL work - certainly I wouldn't claim great expertise. But they do know the overall degree of integrity/privacy they get and what the authentication options are (I hope!).

The fact that XML now makes it easy to study the wire formats with ease doesn't mean developers should have to or need to be doing sol. In certain cases it is important and in others it isn't. I'd posit that in a vast majority of cases it isn't.

I think there are tons of cases where developers can work at the object level and live happily ever after. I also think there are cases where exposure to XML is warranted: you are dealing with complex documents (possibly from an industry vertical schema) that is too cumbersome to reasonably map to an object model, you want to transform or validate a message before deserializing it, or you want to process the message as a stream.

I certainly would be hard pressed to come up with a convincing argument for the added expense of having our developers hand code WSDLs, XSDs, proxies, etc (although they do this in certain cases) especially if they are already following guidelines within the toolkits to ensure interoperability.

I think this is the part where I'm not making my point clear. I am arguing that you need to be deliberate in your contract design. Christian has a great post about why, that references this quote from Steve Vinoski:

When you start with the code rather than the contract, you are almost certainly going to slip up and allow style or notions or idioms particular to that programming language into your service contract. You might not notice it, or you might notice it but not care. However, the guy on the other side trying to consume your service from a different implementation language for which your style or notions or idioms don't work so well will care.

Can you be deliberate if you work solely in code? In theory, yes, if you are really really careful. But as Steve notes, things have a way of slipping in. My favorite example is elements of type string marked minOccurs=”0” because a string could be null. Of course the service checks for null and throws a SOAP fault containing an invalid argument exception if it gets a null string.

It's much better to be deliberate by creating XSD and WSDL. However, this doesn't mean that you have to type angle brackets by hand. VS.NET has a built in graphical XSD editor that is reasonable and there are other tools that do the same thing. Christian is building WSCF, an addin that makes mapping elements from an XSD into a WSDL trivial. In short, the overhead of developers working this way is minimal and does not require angle brackets at all. Is there some extra cost to this approach? Yes. But I think the design benefit of focusing on messages and contracts as key concepts in the Web services world is worth the cost, even when reach is not a primary concern.