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 Friday, 6 December 2002 22:32:34 UTC