RE: Asynchronous Web Services

Paul,

I am sold on identifying long-lived transaction with URIs and having
useful GETs associated with them. I am also sold on trying to clean up
and simplify when ever possible.

But it seems to me that messaging systems such as SMTP servers and JMS
servers are useful pieces of infrastructure and that we should try to
leverage them if possible unless we can provide alternatives that are
radically simpler.

How do you envision providing reliability without a persistent
intermediary?

It seems to me that even if you only allow HTTP, the only way to offload
the client from having to implement reliability through scheduled
retries, would be to have an "always on" intermediary that the client
contacts through HTTP passing the request and asking the intermediary to
manage the delivery of the request to the server. In that case the
intermediary does not know the URI of the transaction that the final
server will be initiating. Therefore the client has to be the one to
provide the key and we end up in the same situation as the one I was
describing in my previous email.

Personally, I do not believe that messaging systems are evil. Specially
if they can be enriched to support XMLSchema-typed messages, open
protocols and URI identifiable queues and topics. I am not sure why they
are considered unRESTful and why they should be associated with the
failure of OMA.

Am I missing something?

Thanks!
Edwin

 

> -----Original Message-----
> From: www-ws-arch-request@w3.org 
> [mailto:www-ws-arch-request@w3.org] On Behalf Of Paul Prescod
> Sent: Saturday, July 20, 2002 4:12 PM
> To: Edwin Khodabakchian; www-ws-arch@w3.org
> Subject: 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 21:08:05 UTC