The business value of services IS reach

Kevin commented on my last post, observing that in a many of these discussions there is not enough focus on the intended audience of these tools, i.e., “Joe Average corporate IT developer” not “the EBay's of the world” and “XML wonks like you” (guilty as charged ;-). He observed that “those people [IT developers] are focused on providing business value, not maximizing reach...“. I don't think there is any difference.

Companies are embracing services because it lets the split apart silo applications into reusable pieces that can be leveraged to create new applications more easily. The business value of those services is directly related to how easily consumable they are. The harder they are to consume, the harder they are to leverage in other places. If the average IT developer approaches service development from the perspective of a single toolkit and not caring about reach, then he or she is using Web services gratuitously where a lot of existing, more mature distribution technologies could be used instead.

I grant you that Indigo is kind of a special case. Unlike most Java vendors who are adding WS functionality to their existing distribute platform, Microsoft is recreating it's distributed platform completely. That means that Indigo is heir to .NET remoting and Enterprise Services as well as ASMX and WSE. So there are probably going to be ways to use Indigo to address problems other than reach, where Web services are not required at all. Having Indigo address both needs makes a ton of sense to me and I don't have any issue with that. What bothers me, though, is the idea that you can ignore the essential core of Web services - the contract - and still build a service that is easy to consume from toolkits other than your own.

Think about the experience of the developers who built ASP.NET Web services that use Datasets as parameters. They left the creation of their real contract to the tools and it generated something that is perfectly legal, but not very easy to consume. In fact, they're hard to consume from any toolkit other than ASMX! Does that mean that you ought never to use DataSets with ASMX? No. But it does mean that you are making a trade-off - the convenience of DataSets at the price of less reach - and you need to make it deliberately. If you made that decision deliberately, okay. But if you didn't made that decision inadvertantly and just used a Dataset assuming everything would work - because everyone tells you that Web services are interoperable - then you're out of luck. You convinced your boss that this was the right approach, you had to rebuild things, but then other people would be able to use them, and it turned out not to be true. Lot's of time and money is wasted this way.

Now, none of that means that I'm not sympathetic to Joe Average corporate developer and his desire for tools that hide these details. I think we could go a long way with tools for creating schemas and WSDLs. I've been pretty happy with VS's built-in XSD editor and Thinktecture's WSCF add-in (I'd like to see some tweaks and Christian is very open to feedback). Both hide the angle brackets without hiding the conceptual model of messages and portTypes. Once I create those, I generate code and let it fill in the endpoint and policy info (I'm still debating about binding - ASMX treats portTypes and bindings as one thing, but I'm not convinced I want to think of the world that way). It can all be done without ever looking at angle brackets!

So I guess it isn't that I think staring at angle brackets is a good idea. I think explicitly designing the logical part of your contract is a good idea. 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. I have no problem with generating service code from a logical WSDL/XSD definition and then plugging in the endpoint and policy info there, again with a solid understanding of exactly how it works. Whether you do the entire service in code or the interface in WSDL and the rest in code, what you write is putting requirements on your client. You need to know what those requirements are so that you ensure that your service is as hard or as easy to consume as you expect it to be.