Challenges of Web Service Development

In a recent article, Gregor Hohpe asks "Is SOA Like Drunk Driving?" In our attempts to address the shortcomings of component-based development have we "swung too far" and introduced new problems? One recent experience suggests to me that we may well be at risk of this.

I was recently asked to look at possible development of an application which would use Microsoft SharePoint Services as its back end. Now call me old-fashioned, but I'd like to be able to do this using the tools I know and trust (in this case Microsoft Visual Studio), on my own PC. There are good reasons - it's an environment I can control without troubling the corporate server police, and I've got used to MS development tools with "Intellisense", helping me to navigate complex object models and providing continuous design-time type checking and so on.

According to the "SDK" (just a help file, really) SharePoint has an object interface, so with my preferences this was an obvious starting point. But it becomes rapidly apparent that the object model is only designed for use on the server. There's no recognised "client install", and some of the documentation suggests that it won't work even if I can get the right components onto the client. I wrote to Microsoft, who replied that their recommended approach is to install Visual Studio on the server and develop directly on it. The corporate server police are really going to go for that. Sure!

On the basis that I don't take "no" for an answer I'm part-way through a set of experiments based on snaffling various DLLs and XML files from the server onto my PC, but so far it's not working. I'll update this article if I eventually succeed, but it doesn't look hopeful.

Which that leaves the Web Service interfaces. Each SharePoint library exports a set of SOAP interfaces, allowing you to navigate the structure and perform basic document operations. It wasn't difficult to set up a "web reference" to the target area on the test server, and invoke web services to get a list of lists, and then a list of documents in a chosen list. In fact, I was pleasantly surprised by how easy this was in Visual Studio, even though I was using VB.NET and all the examples were in C#. 

And that's where the fun begins. Because the web services return a lump of XML. No schema. No objects you can "rehydrate" from it. As far as I can establish, no formal definition of structure - the SDK merely publishes a few examples, with no indication of which elements are optional or repeatable, for example. So I'm reduced to copying the lump of XML into an editor, rummaging through it to infer the structure, and hard-coding XML parsing logic to get the information I want. No early binding, no Intellisense, no protection against errors. Wonderful!

How have Microsoft, who have always served developers so well in the past, got it so abysmally wrong? This was my first experience of trying to develop against "somebody else's" Web Service, and I'm very disappointed. Maybe Gregor is right, and we need to stop the "services with everything" bandwagon veering too far.