Re: Asynchronous Web Services

Edwin Khodabakchian wrote:
> 
> Paul,
> 
> This is a very good explanation.
> 
> How would you address the case where the client initiates the long-lived
> transaction through a one-way protocol like SMTP or JMS. It seems to me
> that it that case, the client needs to specify the correlationId.

Edwin: I think that this is a core disagreement between the REST and
SOAP communities. When you have to start dumbing down your archicture to
preserve compatibility with hundreds of different protocols, the cost of
compatibility with those protocols is way too high. I will be speaking
on this theme at a few conferences and in some upcoming papers.

If you want wire-level interoeperability then the participants in
communication must choose a particular wire protocol. The software
vendors and enterprises who dominate the Web Services world naturally
have a tendency to want to preserve their investment in non-Web
protocols (including SMTP). What I believe that they do not understand
is that the money saved in the short-term in that preservation is vastly
overwhelmed in the money they will spend again three years from now
solving the interoperability problems they solve today by continuing to
use non-Web protocols.

Of course, saying "non-Web protocols" is just a politically correct way
of saying non-HTTP protocols because HTTP is the only protocol so far
developed (if we exclude the HTTP variants WebDAV and SOAP+HTTP)
specifically to integrate with the Web architecture and with a deep
understanding of the central concepts of that architcture (in particular
URIs). Even SOAP 1.2 does not require messages to always be addressed to
a URI (though the HTTP binding requires that of course).

So anyhow, you will never see me compromise a design "in case" it needs
to run over JMS or SMTP. Note that I am not deprecating the importance
of either reliability or asynchrony. Reliable systems are important.
Reliable messages are not. They are only a means to an end in some
architectures. Similarly, asynchronous systems are important.
Asyncronous messages are not. Note that SMTP is not an asynchronous
protocol in the same sense that UDP is. SMTP is a synchronous protocol
weaved into an asycnchronous system. I propose that this widely adopted,
successful model is also appropriate for web services.

If and when someone invents a reliable or asynchronous protocol that is
truly a web protocol in its understanding of the role of URIs as
addresses and URIs embedded in documents ("hypermedia") as an
abstraction, I would adopt that alongside HTTP happily. Until that
happens, it is easy enough to build reliable and asynchronous systems in
HTTP as it is today that I do not feel that I am asking anyone to
sacrifice anything.

> As to whether the correlationId should be a URI, some clients (like a VB
> app) cannot host URIs: those clients interact with the long-lived
> transaction through polling (passing in the correlationId as part of
> each request).

I presumed that typically the server would host the conversation
resource. That's why I said that the server should invent the name
(URI), not the client.

> It seems to me that a correlationId is not a resource but rather a key
> used as part of an asynchronous interactions.

Why shouldn't a key be a resource? I've outlined the benefits of doing
it. The only complaint yet proferred about the model is: "it doesn't
work with non-Web protocols." But this is the W3C and we are building
the Web, not building life support for non-Web systems. Once again let
me say that I am not deprecating legacy systems especially legacy
business logic. The Web deals with legacy systems through gateways. When
I order a ticket from Expedia I do so through HTTP even though I presume
that my message at some point travels over the proprietary Sabre
information network. The Web is precisely the *standardized glue*
between these legacy systems. 

If those legacy systems start to migrate from the edge of the network
into the very architecture then we are just rebuilding the mess that
already exists. I'd rather build a new system that is clean and clear
and can be the common conversation point for those legacy systems.

An attempt to build a union of existing systems will collapse under its
own weight. Let me make the necessarily inflamatory suggestion that if
vendors had tried to build the Web they would exactly have attempted to
grandfather in every hypertext language and transport protocol and
messaging protocol: Lotus Notes+Microsoft Help+CICS+.... This would have
made the migration from existing systems to the Web cheap for their
customers but interoperability would have been terrible. Instead, the
Web was invented by idealists who said: "map all of your old crap into
our model. It will be very expensive but interoperability will be
great." It was very expensive: expensive enough to build entirely new
companies like BEA, Allaire and Vignette. But it was cheaper than
limping along with half-way compatible systems.

Sorry for the long note but I wanted to explain why I do not see
arguments about protocol independence to be persuasive.
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/

Received on Saturday, 20 July 2002 20:12:38 UTC