I can't stand. After the first few days of Indigo hype, we are back to business.
Now that Indigo is here (well, at least in the shape of code snippets in blog posts) people start to wonder about 'best practices' - funny, isn't it? One of the main concerns a lot of bright people are currently musing about is the contractstory. And this absoutely does not just count for Indigo, that's for sure. And Indigo is still far away, especially for the most part of our customers. Alas, here is my 2 cents on it.
It is all about being explicit.
The current discussions are revolving around whether to write your 'contract' in native .NET through writing down interfaces - or by starting with something different, like XSD and WSDL. Well, nothing new so far ;)
No. The world is not black or white. We all know this. So nobody might recommend just only one approach, or the way. We should be frank and admit that there are actually good reasons for starting with a non-CLS representaion (i.e. C#, VB, or whatever) - at least just for sake of explicitness. Sometimes it is actually better to turn around and see the world through different eyes. Therefore we need 'this other approach'. We do not want to solely rely on XmlSerializer (or any other evolved magic ser./deser. instance, for that matter... XmlFormatter).
What really annoys me is that nearly everybody seems to ignore the interoperability aspect of services (and Web Services...) nowadays. If you (try to) do serious interop in your daily work, you won't even bother starting with C# or VB or Java... and yes: I know that you might want to see C# interfaces and some square-bracketed attributes as one valid way to write down your service's interface description. But then, I want to cite Steve Vinovski who hits the nail:
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.
... and Indigo won't heal those wounds. Sorry.
Let me throw in another aspect. This point supports my vision of being explicit.
With every new day I think about those contracts more and more in a way of DSLs (domain specific languages). Just as the Windows Forms designer in VS.NET is kind of a graphical DSL for our GUI in Windows Forms applications, we could have a (graphical or not) notation of service contracts. The user controls on our forms are the interface into our client side GUI. I surely do not want to start designing my GUIs by hacking up .NET code, no. And I surely do not want to hack up XAML code one day, no.
Obviously, I do not want to design my service interface by typing .NET code annotated with attributes - neither do I want to hack up angle bracketed XML/XSD and WSDL, no. So we need an abstraction on top of it - a DSL which models our service interface contract and which is also executable. Or for the more XML-infected guys out there: it is about the WS-I BP 1.xWSDL InfoSet (a term which does not exist, AFAIK). And the best means to write it in a hardcore fashion would be to write down XSD and WSDL, but nobody wants to do this. Then you better have a DSL and tool support to help you out.
As Tim mentions, there is a small tool which tries to abstract away all the nitty-gritty details of WSDL and people seem to love this approach. Once you have your service contract in place (as WSDL which you do not need to understand, but you have the one valid and interoperable serialization format of the WSDL InfoSet), you can generate code from it - and one day even for Indigo, it's just another stack or platform. This tool is in a very basic sense DSL-ish, although there is a long road to go.
BTW: maybe we want to compare the last part of this discussion with the religiouswarrevolvingBinary XML... just pops up in my brain...
Previous Topic
