RE: Proposed text on reliability in the web services architecture

> If you're serious about this, I'd suggest starting with defining a
> comms model (ie, sender, senderBuffer, channel, receiver,
> receiverBuffer) rather than working from usecases (they can come
> later). With that model agreed upon, it can be determined 1) what
> level of reliability is acheivable - for example if the model is
> pure client/server, that affects what claims you can make for RM and
> 2) what is out of scope - for example you'll probably want to have
> something to say about Byzantine/arbitrary failure cases.

Bill,

Interesting that you mention this.

From what I recall Byzantine failure (and the larger space of problems
around it) describes a trust problem in group communication. Namely: how do
I trust that you will process the message I sent you in the proper manner.

Security is an issue, but security can be addressed by signing the message,
and is orthogonal to RM (of course, IMO RM must be able to support signature
of the ack, otherwise you introduce a potential security hole).

Silence is another issue. The fact that you never send back a reply: does it
mean you agree or disagree with the message? Group communication defines
various protocols to deal with it, which fall into the scope of
choreography. (Did I say before that RM is not the only thing you need?)

Ordering is another issue. If you send back a response saying yes, does that
mean you agree to the last message, or maybe you refer to the previous
message?

There are several ways to address this and it depends on whether you are
doing point-to-point (I assume that is what you mean by client/server) or
pub/sub (group communication). In the first case correlation is relatively
easy. In the second case you need to order messages within the group.

I would definitely like to see the RM support group communication. There are
many cases where you want to exchange messages between a group of services,
not just 101. I think Amy could give you some good examples for that.

arkin

Received on Tuesday, 21 January 2003 06:01:01 UTC