RE: Asynchronous Web Services

>JMS is an API. Other than the DOM (which is an API for
>client-side use) the W3C really doesn't have much to do with APIs. I
>think the effort should be spent on open standards protocols built on
>top of other open standards protocols.

I think the reference to JMS really aims at the concept of running SOAP on
top of various MOM transports (which JMS provides an API for).

There are already a few implementations of this available today (from BEA,
IBM, CapeClear, and probably more, and I think .NET has equivalent
capabilities). In addition to that, the Java community is actively working
on providing this type of support in coming versions of EJB and J2EE. I
don't think that excluding all these efforts from the architectural scope of
WSA would be a wise move, particularly given the fact that these efforts are
highly likely to play a central role in real world WS-based business
implementations.

Ugo

-----Original Message-----
From: Paul Prescod [mailto:paulp@ActiveState.com]
Sent: Monday, July 22, 2002 9:16 AM
To: www-ws-arch@w3.org
Cc: 'Paul Prescod'
Subject: Re: Asynchronous Web Services






Edwin Khodabakchian wrote:
> 
>...
> 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.

First, let's talk about SMTP servers. Much of what SMTP servers do is
duplicated in Web servers. SMTP servers have aliasing features, so do
Web servers. SMTP servers of course have all kinds of networking code,
much of it duplicated with Web servers. Many (not all) of the 
security issues are the same: privilege separation etc. Many of the
extensibility features overlap. 

SMTP servers also have lots and lots of historic stuff that you do not
need for web services. 

So if you were going to start from scratch, building an SMTP-like
infrastructure for Web Services, I posit it would take a tiny fraction
of the effort (and code) it took to build the existing SMTP
implementations...and it could be much more sophisticated.

On the other hand, even if I am wrong, one could wrap SMTP
implementations in HTTP interfaces and then the internal use of SMTP is
a matter outside of the scope of this group.

Second, JMS. JMS is an API. Other than the DOM (which is an API for
client-side use) the W3C really doesn't have much to do with APIs. I
think the effort should be spent on open standards protocols built on
top of other open standards protocols.
 
> 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.

I would expect the intermediary to be bidirectional, like an integrated
SMTP server/POP server. Also, if you really do want the client to
generate the correlation "ID", it could still be a full resource because
the intermediary could host it.

If there is a trusted intermediary that has persistent state (as it must
to retry delivery) then I'd say that it could host the conversation URI.

> 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.

I didn't mean to say that messaging systems are evil. I meant to say
that they should be adapted to web architecture (either through new
versions or gateways) rather than the web architecture being expanded to
include them. I believe that the original Web succeeded because it did
not try to grandfather in a host of incompatible and/or proprietary
technologies. Rather, it provided a clean mechanism for *encapsulating*
those technologies in standardized interfaces.
-- 
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 Monday, 22 July 2002 14:03:47 UTC