I was recently invited to be a guest speaker at the eBay Developers Conference, where I was part of a panel whose topic was "Delivering the Promise of Web Services." I found it particularly interesting, if slightly worrisome. What struck me most was the differentiation between Web services consumers and Web services authors.

The audience at this presentation asked a large number of questions that helped me understand that consumers and producers are not the same groups of people. eBay developers are particularly interested in consuming Web services (such as the eBay and PayPal APIs that are exposed as Web services), but in general they were not interested in developing and publishing their own Web services. This shaped the discussion in a way that was enlightening for me because it highlighted some of the things that the end users of the services we discuss so much are coping with.

In particular, these consumers were looking for better Web services consumer mechanisms in their languages of choice, which were not the compiled or near-compiled languages of the developers, who chose to develop services in languages such as Java or C#. Instead, these developers were concerned with the quality of the Web services toolkits in languages such as PHP, Perl, and Python.Once you understand that their primary interest is using the API on their sites, without having to use the eBay interface, you can easily grasp why these open source, thin client-oriented languages occupied a large part of the conversation.

It also tended to underscore a concern I've been feeling for some time now regarding Web services. We, the industry and specification leaders, are ignoring the last mile.The initial set of standards - UDDI, XML, WSDL, and SOAP - are now well entrenched and providing meaningful interoperability between software platforms. The second generation of standards, which includes things such as WS-Transaction, WS-Security, WS-Reliable Messaging, are starting to result in even greater functionality that can be provided with Web services. But by and large, these standards are clearly aimed at the Web services developer community, and in the end have only so much impact on the Web services consumers.

Now, we can say that Web services is about services themselves, and not user interfaces, and we'd largely be right, but not fully. In the end, a service needs to be used, and even though Web services technologies make it easier to do computer-to-computer conversations, the reality of business computing is that the overwhelming majority of services will be consumed by people. And those people need some sort of visual interface with which to interact (yes, except for IVR).

Now, obviously it is harder to divorce the UI layer from proprietary technology and languages, and this makes it harder to actually come up with a uniform standard for the interface. It's also true that the service is distinct from the interface and for maximum flexibility should be neutral to interface requirements. In fact, trying to come up with a description language for the interface is probably not worthwhile (even if you ignore the fact that HTML is already such a language). Instead, we need to make the intermediate manipulation languages, such as ASP, JSP, PHP, Python, and Perl easier and bulletproof. We also need to give some consideration to common UI tasks such as set iteration. There's nothing in the Web services specifications towards that end, but certainly applications that use Web services will have to make use of a variety of common presentation concepts where an intermediate presentation service language could shape and mold the generic XML message returned from a service invocation into a screen or page layout. Ideally this is again generic, so that varying presentation services can be utilized.

I learned one other thing from eBay - bid with your head, not over it. Now what do I do with a black, chrome-covered parade saddle? Sometimes I amaze myself.