RE: "Reliable" web services for Next Big Thing? (was RE: Agenda for 5 December WSA telcon)

Hi Mark,

Actually, I was not trying to get involved in the protocol vs. application aspect of the debate.  I was more trying to support Dave O's proposal to start with agreement on a simple ack.  The simple ack I'm thinking of (and which I am assuming Dave is thinking of, please correct me if I'm wrong) could indeed look like your example:

  <mark:messageid>http://foofoo.org/mid/232394820480234</mark:messageid>
  <mark:qos>http://ackack.org/qos/ack</mark:qos>

But I'd simplify it further to just send a plain "ack" for a message with a given unique ID. In that context the rest of the "qos" namespace URI would not really be needed but I agree with your idea or assumption that whatever we do should be extensible and flexible.  But actually a simple ack is what I'd like us to focus on for the initial proposal, so perhaps an even simpler example would be better:

  <mark:ack>http://ackack.org/ack</mark:ack>

Or like that.

Regarding the RPC comment, I just like to emphasize the idea that Web services are not really suitable for RPCs, in fact they are one-way asynchronous messages (and yes one could correlate them into something like an RPC) and we should focus on defining an ack for an asynchronous message style of interaction, not for the RPC style.

Thanks,

Eric

-----Original Message-----
From: Baker, Mark 
Sent: Friday, December 06, 2002 10:37 PM
To: Newcomer, Eric
Cc: David Orchard; www-ws-arch@w3.org
Subject: Re: "Reliable" web services for Next Big Thing? (was RE: Agenda
for 5 December WSA telcon)


Hi Eric,

On Fri, Dec 06, 2002 at 03:36:09PM -0500, Newcomer, Eric wrote:
> I believe what Dave is referring to (an ack) would allow application level reliability protocols to be built, and I support his proposal to start with it.

I responded to Anne that I felt that some SOAP headers could be defined
to aid in reliability, but I wouldn't call any of them protocols.

Are we in synch, or do you believe that they would be protocols?

Do you have an example of what you mean?  My headers might look like;

<envelope>
 <header>
  <mark:messageid>http://foofoo.org/mid/232394820480234</mark:messageid>
  <mark:qos mustUnderstand="true">http://ackack.org/qos/once-and-only-once</mark:qos>
 </header>
 ...
</envelope>
 
What I would consider a protocol would be something like;

<envelope>
 <header>
  <foo:ack>
   <messageid>http://foo.org/mid/239482398423948</messageid>
  </foo:ack>
 </header>
 ...
</envelope>

where that message id is some previous message that was sent, that is
being acked with this message.  That's a possibility, but one with some
complex interactions with the SOAP processing model and MEPs because
you're muxing.  As you know, muxing complicates implementations
enormoursly and may make many existing libraries useless because of its
concurrency assumptions which muxing messes with.

Anyhow, I don't expect to completely synch up on this, because my view
remains that reliability is a *coordination* problem, and when you're
working in the context of existing coordination semantics (supplied by
application protocols), you can't ignore those semantics (as Web
services typically do), you can only extend them.  But we can hopefully
agree on at least the need for message-ids and qos specifications.

> As a sort of aside, a lot of the Web services discussions remind me both of the early days of integration (when everything was a file get, put, update, or delete, and the application was expected to interpret all the data in the file) and of issues related to asynchronous message queueing.  In this latter category the simple ack is very valuable, and I hope we're not getting sidetracked thinking about reliable messaging for RPCs ;-)

I don't really understand what you mean there.  I think a lot of
people are going to try and do reliable RPCs with this (keeping in
mind that my definition of SOAP RPC is any SOAP message bound to an
application protocol that has a method name in it).

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis

Received on Monday, 9 December 2002 00:37:06 UTC