Tim and
Clemens have been going back and forth over the importance of XSD/WSDL/Policy and its role in SO systems. This debate was spawned by Clemens posting some Indigo code containing a [ServiceContract] definition and arguing that you should "break the bad habit of angle brackets." Here's a recap:
Clemens: [Indigo code] is a perfectly reasonable way to share contract between server and client… Staring at WSDL is about as interesting as looking at the output of "midl /Oicf".
Tim: XML is not just an implementation detail, it is the implementation detail that actually makes this Web services thing work… Remember that WSDL/XSD/Policy is the contract, period. Any other view of your contract is just an illusion.
Clemens: WSDL and XSD and Policy are interoperable metadata exchange formats. That’s just about it... But WSDL/XSD/Policy isn’t the contract.
Tim: I think that writing some code in your tool and having it generate the logical part of your contract is a bad idea if you don't know and care about exactly how it works.
Clemens believes that it's perfectly reasonable to express a service contract in a C# interface definition a la Indigo, while letting the runtime produce the XSD/WDSL/Policy definitions as an byproduct, and as a result, you should never have to look at angle brackets again. Tim, on the other hand, believes that the official service contract is the collective XSD/WSDL/Policy definition and therefore special attention must be paid to what they say.
If you live in the real world, Tim is right, and Clemens is clearly wrong.
You only have to reach for your
nearest Webster's to learn the meaning of the word "contract":
1 a : a binding agreement between two or more persons or parties;
Obviously an agreement between two parties implies that both sides understand what's being said. A contract communicates the rules we agree to play by in a language we understand. I would never sign a business contract authored in German since I'd have no clue what I'd be agreeing to. Likewise, there's no way a Java client is going to have anything to do with a contract authored in Indigo C# definitions. You can translate the Indigo C# definition into an XSD/WSDL/Policy definition, which the Java client would be abel to understand. That clearly makes the XSD/WSDL/Policy the official contract.
If your entire SO system is only using Indigo, you can get away with sharing C# contract definitions with consumers since both sides understand them, and the XSD/WSDL/Policy translations should never get in your way since it's the same runtime on both sides. From his posts, it seems that this is the only world Clemens knows. Realistic SO systems are a built from a melting pot of languages, frameworks, and platforms. In that reality, the only contract definition language that all parties understand is XSD/WSDL/Policy. And history has proven that runtime translations between the native programming language and XSD/WSDL/Policy can easily get in the way and hurt interoperability if you don't understand what's going on.
You can obviously choose to ignore this fact, but that does not change the reality that the XSD/WSDL/Policy is the official contract - it must be since it's what defines the agreement between parties. If I want to consume a service offered by Acme, Acme presents me with their service contract (the XSD/WSDL/Policy definition) and I'm obligated to conform to it if I want to use the service. I have no idea what the contract looks like in Acme's implementation environment (a la Indigo), but I know what the implementation is supposed to do, and what I'm required to do, according to the contract definition (XSD/WSDL/Policy).
What was the contract definition language in COM? It was clearly IDL, not VB or C++ class definitions, because IDL was the contract language all parties understood. If you believe that IDL defined the contract in COM, I don't see how you could argue that XSD/WSDL/Policy doesn't play the same role in WS. Nevertheless, multitudes of VB developers ignored IDL and just wrote class definitions, and as long as they were connecting with other VB components everything was cool. However, once they tried to hook up with a C++ component, careful analysis and modifications to the IDL contract were almost always necessary.
Ignoring this reality will inevitably impact your reach as
Tim stated, as you're bound to generate service contracts (XSD/WSDL/Policy) via your framework that are difficult for others to consume. What's most discouraging is that a large class of developers are likely to share Clemen's perspective and do what's easiest now. I believe that if we had better tools we could steer the ship in a different direction. Tools like WSCF are a good start, but vendors like Microsoft must commit to a true contract-first development environment that shields some of the angle-bracket-pain while helping you focus on the true service contract.
Posted
Feb 10 2005, 12:00 PM
by
Aaron Skonnard