I have been a very interested observer in the recent debate between Tim and Clemens on their definition of the contract in the context of XSD/WSDL/Policy. Aaron has this to share as well which I read with great interest.
I have done a fair amount of work in preparing to give some prezzos and talks about XSD/WSDL/Policy this year. This is the feedback I had gathered over past few months when developers questioned the reach of interoperability of XML SOAP Services...and most of the time, they have no idea what is going on with the XMLSerializer and the WSDL Generator.
Although I am on Clemen's side when he states that:
"Staring at WSDL is about as interesting as looking at the output of “midl /Oicf”."
I do stand on different ground as him when I believe that developers still need to know what is going on in the deeper plumbings of things. Semantics discovery is still a distance away. While the RAD approach of VS.NET and Indigo is great in churning out developer and business productivity, the real world of the enterprise is rather different. Working in a fairly large SI give me an in-depth look at how disparate systems MUST BE made to integrate and work with each other. Introducing newer, better systems such as Indigo is not even an option at this point in time.
WSDL-generating tools are still very primtive today. There is no easy way to really extend or version my XML SOAP Services without mucking around with the brackets of WSDL today. If you implement some kind of a proxy-middleware layer approach as a messaging layer (known as the Enterprise Service or Message Bus to some), it is highly likely that it is doing things to your XSD or WSDL to attain its advertised benefits. The point is --- You cannot run away from having to muck around with it and we are not even talking about interoperability yet.
Clemens, however, did state his point is only valid "if you’ll be sticking to Indigo". Unfortunately, I dont have that luxury to work in an environment with a single homogeneous platform and I really doubt that will change in the real world for many years to come. So besides having to know what the wire-format looks like, it is equally important to agree to that format first and this is where XSD/WSDL/Policy comes in.
I think Aaron hit the point in his post when he did a comparison of roles between IDL and XSD/WSDL/Policy plays in the definition of a contract. However, I would read WSDL than IDL anytime of the day.
I believe that the WSDL generated by default (*.asmx?WSDL) from VS.NET is difficult to read and understand before it is not in-line with proper practices. Modularity, Re-usability and Separation of concerns are not being diligently practiced. That is fine, and like what Clemens say, as it is not meant to be read by many humans...but by not treating it as an official contract is totally different thing altogether.
I think WSDL is the indispensable API and is poised to be the universal contract design view. I am a great fan of the contract-first approach and Thinktecture's WSCF, currently in the 4th rendition, is a huge step in the right direction to realize that design implementation. It does a great job in separating the data types from the message types. I cannot wait for it to go one step further in version 5 where it will generate interfaces to host the service implementation regardless of where the implementation may be, amongst other things. Thanks Christian for listening to my pleas.
And if you are not debating the fact that WSDL is the contract but it is the readability you are having an issue with, there are a couple of ways to make a WSDL easier to read. If you are having trouble with the brackets, then why not try the {curly} ones instead. I used CapeClear's Simplified WSDL Stylesheet to bend the angles into curls.
And of course, some people from the other camp do share the same views as well.
Barring any further whopping from Rich Salz on WSDL 2.0, I think some of the recommendations of WSDL 2.0 does make it slightly flatter and therefore easier on the eyes. Examples include:
- Removal of Message Constructs -- It is more or less redundant now with Doc/Literal in wide acceptance now and is rightfully placed in the section.
- Renaming of PortTypes to Interfaces and Port to Endpoint can give a Software / XML SOAP Service geek orgasms.
- Introducing XML Schema model XSD-type enhancements such as wsdl:import and wsdl:include does bring about certain principles of modularity, re-usability and separation of concerns.
- ...