In the last few days, I've been reading a series of articles and commentary about Web services that seem to radically miss the point. The first was an email news letter and talk from Ecademy. This seems to equate "Web Services" with MS Hailstorm. The second was a piece by Clay Shirky (http://www.xml.com/pub/a/2001/10/03/webservices.html) on the trivial implementations so far, the more general problem of business semantics and the hype being generated by some ill considered press releases from UDDI (http://www.uddi.org). Then of course, there was Dave Winer's reaction to Clay's piece. (http://scriptingnews.userland.com/backissues/2001/10/03).

As a slight aside, I was also at a conference given by Spiked (http://www.spiked-online.com) last week called "Don't Blow IT". I lost count of the number of people who began sentences with the phrase "The Internet is..." when what they really meant was "I've noticed this subset of the internet where it appears that ..." I think the commentators and practitioners in the web services space are in danger of promoting the same sort of muddy thinking. We're setting up a straw man by focussing on one aspect of the problem in order to provide an excuse to pull down the whole edifice. This reminds me of the parable of the three blind men trying to describe an elephant. One held it's trunk and said "It's a snake", Another held a leg and said "It's the pillars of a building". The third held it's tail and said "It's a dog". Equally, by focussing on one aspect we're missing others as if we were doing research on the brain neurons of an ant to try and understand how ant hills develop.

So having wandered well off the point, let's try and shed some light on different aspects of web services. First, a broad definition (that you're welcome to disagree with). Web Services are systems that enable application to application communication across the internet, in the same way that the early internet protocols focussed on application to user communication across the internet. Now this is a bit broad and the term is generally used only for A2A comms involving remote procedure calls or RPC. But RPC or internet RPC is a bit narrow as RPC has a specific meaning as well. As we begin to build systems that do asynchronous integration or use messaging such as Jabber or email for the transport, Web Services look to be a bit more than rigid RPC.

Now Clay argues that "It's turtles all the way up" as a dismissive comment on one problem of web services that I will come back to. but this is actually a strength. Layering protocols has proven to be a highly effective way to build systems. Then he argues that the trivial nature of current implementations don't provide any proof of concept of web services solving real world problems. Well that may be true, but perhaps it shows a certain lack of imagination and it ignores the real business work being done by people like BEA.

To promote a better understanding of web services, I'd like to recap some of the layers.

First we have to get the function call or message from one application to another across the net and then return the result. While the majority of Web Services so far have been written to use http, this is not the only possibility. Experiments are already underway to use email, Jabber and several other transports.

One thing that we do seem to be agreed on is that we should be using XML as an alphabet for describing the calls and the results. At least then we can write general purpose parsers that can turn the bit stream into application variables. But again we have to remember that XML is a standard for writing standards. It says nothing about the content or semantics of the messages, only the alphabet they are written in.

Now we have to provide a standard way to pass call names, functional parameters and result structures back and forth. There have been numerous attempts to do this over the years such as Java RMI, DCOM and even CGI. As a note, CGI provides almost all we need to write remote function calls except that it says nothing about the format of the returned data and it is tied to HTTP. The current focus is on two XML standards SOAP and XML-RPC. These share a lot of similarities and to some extent SOAP is simply a more robust, wider reaching and heavy duty version of XML-RPC. So now we have standards for making the call and receiving the data. Note that we haven't yet said anything about the nature of the call or results except to say that it will be written in XML. This in itslf has attracted the interest of enough programmers that there are now toolkits in all the major languages to support these and even support built directly into some operating systems such as Mac OSX.

Now we begin to get into the application arena. As an application programmer that wants to connect my application with somebody elses, I now need to either read their documentation and/or write my own and get them to read it. Writing documentation in English gets the job done but it's also hard to find, may not make any sense and may involve me in a long communication session with the other programmer as we try and make sense of what each other are writing. In business, this is great for the consultancies but not so good for getting the job done! WSDL attempts to deal with this by coming up with a formal definition language (in XML, of course). Now I may not know what a function call named GetStockQuote() actually does, but by reading the WSDL at least I have a description of how to call it, where it is, and what parameters it expects. WSDL is complete enough that it is just about feasible to write code that can figure out what data to assemble, call the function, and disassemble the results. If there is a valid WSDL file and SOAP interface, I can realistically put together the application to application integration in hours rather than months.

So now the problem becomes a familiar one with standards. "How do I promote my services so people can find it" and "How do I find other people's services". This is where UDDI comes in. It provides a searchable index with pointers to WSDL service descriptions. Inevitably the search, registration, update functions are available as SOAP services so it can be driven from code as well from a user interface. Even the standards for replicating the database between UDDI servers have been written as SOAP services. Just as with WSDL, I could just use Google to search the web for the documentation, but UDDI provides a more formal way of achieving this. And one that can be automated and scripted.

Finally (finally!) we reach the crux of the problem. "What do we do with all this". And this is really what Clay was dealing with. My system has a service Foo that your system Bar should integrate with. But neither of us know what the other is up to and we don't even have a common language to describe it. To make this real instead of just Foo and Bar, think about the huge number of formats there are for things we think we understand like a Purchase Order or a Product Code. Unfortunately organizations like UDDI and some of the press talking about Web Services have suggested that we should be able to do on the fly integration between arbitrary systems using web services and that XML will somehow leap the conceptual gap between my understanding of a purchase order and yours. But XML is 4 paragraphs back down the stack from this problem!

We've got about 3 or 4 possible approaches to this. The first is to take an industry and define all the possible interactions between businesses in that industry. And then to get widespread use of these definitions. This is the approach of Rosettanet for the electronics industry. Most industries have an initiative to try and achieve this along with the UN with OASIS on a global scale. But almost all of them are mired in corporate in-fighting and are not making much headway. The next approach is to come up with a set of maps between competing standards and convert from one to the next automatically. Microsoft is attempting this with Biztalk. But of course this depends on the competing standards being more or less stable and complete which is only really true of Rosettanet at the moment. The third approach is to get widespread de-facto use of a set of business semantics. At the low end, Microsoft with Commerce server and Great Plains has a real chance of achieving this. And of course, with .Net they hope to also achieve this with personal interactions with web services. At the high end it's rather harder. Applications like SAP should be able to leverage their installed base, but in fact the software is typically so configurable that no two implementations are the same.

One issue that has been raised repeatedly in relation to Web Services is the one of authentication and security. Unfortunately, this has not been addressed directly in the main protocol standards and has been left at the application level. Fortunately, we already know how to conduct secure communications across the internet with technologies such as SSL. We also know how to do authentication with digital certificates and Kerberos. So the way is open for toolkit vendors to roll these technologies into their web services toolkits.

So what we have is enormous potential to do fast, easy and cheap integration between applications that can connect across the internet. As long as we recognise the hype and don't get carried away with it then all these initiatives can help us build tighter integration between organizations (and individuals). They open up huge possibilities for new applications. But they are just another set of tools in the system integrator's armoury and not some magical cure all that will automate all our problems with one press of a button. And Web Services does not equal .Net or Hailstorm. Rather .Net and Hailstorm are platforms and sets of applications that use web services and may or may not succeed in their own right.
[ << Don't blow IT - Part I ] [ More on UDDI and WSDL >> ]
[ 0 comments ] [ G ] [ # ]