Sean McGrath points out that some folks (himself included) are making
predictions
for Web services in 2003. It’s surely an oversight that I wasn’t
asked for my predictions 8-), so here they are;
- Web services will continue to struggle on the Internet.
XMethods will list only 400 available-over-the-Internet
services by the end of the year.
- The WSA WG will have their
architecture document reviewed by the
TAG and the
Director. One or both of the
two will reject it as being incompatible with
Web architecture. Much nastiness will ensue.
Sean McGrath
calls for
a “workable definition” of a Web service in order to bring integration complexity down to O(n)
from O(N^2).
While a definition would be a good start, more importantly we need a common abstraction.
This drives integration complexity down because once you’ve integrated with one service,
you’ve (ideally, and not that uncommonly) integrated with them all.
Take for example, a blog aggregator. If everybody had their own interface to their
blog, aggregation would be an O(N^2) task. But luckily they don’t, they all make their
RSS available over HTTP GET, a very useful common abstraction. That, plus that RSS (all
four versions 8-) is a common format, provides for O(N) integration complexity.
The Web provides one common abstraction that I talk about a lot; the uniform interface.
There are others (though none so general,
I believe), but Web services, via WSDL, are all about providing custom interfaces. As
long as use of WSDL in this manner continues, Web services will, like Sean says, amount
to “one big damp squib” (which doesn’t sound like a good thing 8-).
I’ve written a draft note
on how I see REST’s hypermedia application model relating to
workflow/process-execution/choreography/orchestration/etc..
My conclusion; we don’t need these specs, because we should just be
following URIs.
Congratulations to the XML Protocol WG.
The end is near! 8-)
Phil Wolff critiques
my resumé, and apparently likes what he sees.
Thanks, Phil. How nice is that? Of course, I promptly patched it in response to
the two very valid nits he had.
The job hunt is going well, actually. It started slowly, but is picking up steam.
Just received an offer out of the blue from a local company, and it could be
really good (Semantic Web, “Web services” (cough), collaboration, etc..), but I want
to do some due diligence on them first, as I don’t know a lot about them as a going
concern. Amazon has an
evangelist
position that sounds like it would be a blast, but I’ve got to check that the
travel wouldn’t be too brutal. Been there, done that, got the miles.
Jon Udell asks three questions
about the spontaneous integration observed in his LibraryLookup project. I’ll take a stab at answering them.
Why was this unexpected?. Because it wasn’t planned. 8-)
In what environment would it be taken for granted?. I’d
say that any environment in which it was both possible and simple.
How do we create that environment?. Eschew data hiding.
Make all data available with a simple mechanism.
I’ve got to agree with Sam
and CNet.
I just can’t get too excited about Office 11 and its XML support.
XML is syntax, a context free grammar. Standardized syntaxes are
wonderful, but heck, it’s just syntax. And while a published
schema would describe some data semantics, it would still leave loads of wiggle
room for the format to remain proprietary.
I think it is useful, as it does open up the format to XML tools
like XSLT. But any use of tools with the Office XML format (such as
XSLT style sheets written to manipulate it) will be locked-in to the
Office 11 format, the same way that software written to the Win32 API
is locked-in. That’s not an inherrently bad thing, of course, but
let’s call a spade a spade.
Sam thinks good thoughts
about how to use RESTful SOAP as a Blogger API. Nice. But there’s an important issue with
SOAP and PUT. Unlike POST, PUT means “store”, and as such its processing model doesn’t
provide a hook into which an additional processing model (i.e. SOAP) can be introduced.
An intermediary or message processor seeing a PUT request with a SOAP body, would be correct
to treat the body as opaque data, and wouldn’t be required to follow the SOAP processing model.
This is why I’ve talked about
the need for a new HTTP method I’m currently calling “SET”, whose semantics will be
“process and store”, and will therefore allow for an additional processing model to be
inserted.
Apparently for today he is. Let’s check back tomorrow. 8-)
Eugene Kim of the Web services Devchannel
interviewed me about REST and Web services.