(still rough)
Few would dispute that hyperlinks and URIs are at the heart of the Web as we know it. Nevertheless, the first generation of Web Services have mostly ignored what we have learned in building the world's largest information system, the Web. My previous articles have mentioned this fact and given examples of these weakness. But somehow the centrality of the issue has consistently flown over many readers' heads.This article will deal with that issue alone.
The central idea is that the decision to use URIs or not is fundamentally equivalent to the choice between using an established standard and doing something in a proprietary way. Take a concrete example, the canonical stock quote example. One way of handling this is to think of the stock service as an "endpoint". You could use a "method" or "message" to retrieve data from the endpoint. The message would specify what stock quote to retrieve. Let's call this the message-centric view.
In order to get the stock quote you first connect to the service and then send the message. It maps the parameter name into some kind of internal address, finds the result and returns it in another message. I can't really represent this as a declarative expression so I'll use some code:
foo = new ServiceProxy("http://www.xmlstocks.org/myservice.asp")
foo.getStockQuote("MSFT")
An alternative way of thinking about it is the Web way. In this view, the stock quote is a resource.
http://www.xmlstocks.org/myservice.asp/MSFT#xquote
It has a current value that can be retrieved through a representation. This address is in a standardized syntax. Anywhere on the Web where there is a slot that expects a floating point number, I can plug in this expression and have it resolve to the right value.
Let me emphasize this point. Presume that the "Web Services" enabled version of Excel had a feature that allowed URL-fetching and interpretation. It could easily work with this value without knowing that it is a stock quote at all. The SOAP version would be accessible only through a script that explicitely knew what methods to invoke to work with the data.
Consider this from a security point of view. In one case I can give you an Excel spreadsheet with a URI embedded in it. It is no more "dangerous" than a standard web page. In the other case the only way I can transmit the location of the information is as code. This is obviously a trivial example but it captures some important principles:
It is very important to understand that the problem only arises when we try to use the data in a way that was not explicitly designed into the service in advance. This is why simple web services will not run into the problem at first. The problem is not a usability issue: it is an integration issue.
Let's discuss the assertion that information representations are easier to standardize than messaging interfaces. At one level this is trivially obvious: after all, messages must themselves have representations. Therefore standardizing a messaging interface requires standardizing both the message syntax and the method names.
We can also demonstrate this by analogy. There is only one XML syntax but dozens of differently optimized APIs for working with it. Some are streaming, some push, some pull, some tree-based. Similarly there are many different APIs for parsed HTML. The issue is that ....
In the world of business integration the problem is even more severe. It is extremely difficult to integrate business APIs because doing so is inevitably tied up with issues of business process.
Back to our stock quote example. Let's say that you wanted to make an application that integrates various stock quotes from different servers.
XSLT, XPointer, XPath, XQuery, TransQuery,
Concrete examples:
Beyond the standards designed specificially to work with hyperlinks there are the ones that merely use hyperlinks internally: XML Schema, XSLT, XHTML, ..., ...
Consider a service that generates XHTML at runtime. How will these XHTML pages link to each other? You might say: "serving XHTML is the job of the old-fashioned Web." That means that in order to integrate an HTML user interface into your Web Service, you must switch to a completely different stack of tools. How is the divergence between "The Web" and "Web Services" productive?
Concrete examples:
Like a database without foreign keys.
Like CORBA without object IDs
Like COM without interface pointers
Like the Web without hyperlinks!
Analogy to Google -- what if Google had to learn a billion APIs? (is there a difference in scale between learning a billion vocabularies? I think yes, because the same data type can be used much more widely than a particular API -- especially in the SOAP model where there are no references)
I do not know whether the Semantic Web will ever be a reality, but I know for certain what will cause it to fail. It cannot succeed if all of the information it is intended to annotate is hidden behind proprietary addressing schems.
Due to missing features in the SOAP and WSDL specifications,
In my previous articles, I have tried to emphasize that one of the most