OK, I Admit: I Stare at Angle Brackets; I Gotta do it; I Do Not Enjoy doing it BUT it Helps by doing it

Tim and Dare had some great exchanges here where they discussed on the importance and significance of staring at angle brackets and service reach.

Tim hit on a sweet spot which I can definitely identify with when he wrote this:

"Is it an issue in companies doing lots of legacy integration work?"

I guess we all come from and work in different IT surrounding environments. I work in a fairly large Systems Integrator where loads of our work revolves around integration and maintainence of legacy systems in vertical Line-Of-Businesses. Since it is also a free business environment, we also have to integrate with work done by other SIs, systems and technology vendors as well. This is a fairly tough proposition and if we are not involved in sitting around tables discussing how to integrate data formats and semantics, we are usually thrown a stack of documents describing the data schemas of other companies and people doing previous work with other technology systems.

Now, XML-Schema is usually (Thank God for that) the agreed-upon format for describing these data formats and that is all we have. Nothing more. Most of the time, we are just given documents with table formats and we have to markup those table formats in XSD ourselves.

So, the XSD-Editor in Visual Studio is definitely a God-sent (Geek-speak, of course) to generate the schema. I was left to my own barehands and notepad to create the _WSDL_.

No, other WSDL toolkits were not an option, cost-wise. Thinktecture's WSCF definitely gave us a huge productivity boost in terms of generation of those WSDL files. By that time, our brains are so well-tuned to angle brackets that we could just hand-author the resultant WSDL to produce the exact result we want. Examples include having multiple service elements and soap:location address attributes for the same SOAP Binding, importing of re-usable data schemas and the separation of abstact and concrete defintions in the WSDL File. By doing all that, we built extensibility, versioing and interoperability as well...and we went in there with our eyes wide open. Troubleshooting is relatively a breeze now, one look at the SOAP Request and the WSDL; we know where and how the SOAP Fault happens.

Is that a problem with primitive tooling that can be solved down the road ? Maybe and I truly hope so. In this instance, I hope that tool utility developer companies can strive for that goal. I am, however, sceptical that a holy grail can be achieved so soon.

I still think, with all things status quo, that developers need to know explicity what goes onto the wire. This has got nothing to do with what is the "native" or real contract or the the canonical forms used to describe the messages. The problem is that when someone gives us these contracts or schemas described in canonical forms, it is the only thing we have that we best understood what is to be sent on the wire so that the other end of the pipe can intepret, understand and process these messages.

...Therefore, I have no choice to not just stare at angle brackets BUT understand what it is trying to convey as well.

p/s: One of my favourite article that exhorts the virtues of the Contract-First Approach