W3C home > Mailing lists > Public > www-ws-arch@w3.org > January 2003

RE: Proposed text on reliability in the web services architecture

From: Cutler, Roger (RogerCutler) <RogerCutler@chevrontexaco.com>
Date: Tue, 21 Jan 2003 11:40:43 -0600
Message-ID: <7FCB5A9F010AAE419A79A54B44F3718E01624906@bocnte2k3.boc.chevrontexaco.net>
To: "Assaf Arkin" <arkin@intalio.com>, "Peter Furniss" <peter.furniss@choreology.com>, "Miles Sabin" <miles@milessabin.com>, www-ws-arch@w3.org

I suppose so, but as Peter points out, there is certainly a lot of value
in the n=2 case.  Most of the usage cases of which I am aware are built
on this, even those with many players since they usually just interact
pairwise.  Most of the business interactions which I am aware of
providing current value seem to be stay in the n=2 case.

-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com] 
Sent: Tuesday, January 21, 2003 11:32 AM
To: Peter Furniss; Miles Sabin; www-ws-arch@w3.org
Subject: RE: Proposed text on reliability in the web services

Byzantine generals does not require a pre-defined population beyond the
scope of an interaction. In fact this class of problems is used to solve
the "population unknown" problem. Where some of these algorithsm say "a
bounded set" they refer to a non-finite set and typically within the
context of a given interaction (e.g. a round).

A one-on-one interaction is a specific case of group communication where
the group consists of two nodes. An n=2 problem.

But wouldn't it be great if we could use WS both for one-on-one
interactions and for groups?


> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Peter Furniss
> Sent: Tuesday, January 21, 2003 9:22 AM
> To: Miles Sabin; www-ws-arch@w3.org
> Subject: RE: Proposed text on reliability in the web services 
> architecture
> Byzantine discussions may be fun, but contrary to Miles, I doubt if it

> coping with the full scale glories of malicious nodes is very relevant

> in the web-services world.
> Part of a service model (and an aspect of the general
> loose-coupledness) is
> that any one
> service generally doesn't know which other services are involved in 
> the client's operations, nor does a client know whether a service it 
> invokes is making use of other services behind it.
> There isn't, as with the Byzantine generals, a pre-defined population
> which a consensus is sought.  It's just a collection of two-party
> relationships, with the knowledge of how those relationships interact
> localised to each party that is involved in more than one relationship
> (commonly, as client to one or more and service to one or none).  For
> two-party relationship there is some (implicit or explicit) contract
> determines what the other party is expected/required/promises to
> do and what
> is implied by the sending of particular protocol messages.
> In that structure, there are requirements for assurance by one side of

> a two-party relationship that a message has been delivered / parsed / 
> accepted / acted on (keeping off that side of the matter for now). A 
> party that is involved in several of those may choose - or 
> *effectivel* be constrained by
> its contract(s) - to link these (so it chooses not to promise to
> deliver the
> goods until the credit card company has promised the payment will
> be made).
> But that's a question for its internals.
> In the particular case of a malicious intermediary, it becomes 
> important to work out who the contract is with. If the intermediary 
> determines when to send the acknowledgement, the contract is with the 
> intermediary, but the content of the contract is (or should have been)

> "ensure this is processed",
> and the intermediary has fallen down on that contract.
> The cure, as Miles says, is to get the assurance of processing from 
> the processor, not from the intermediary.
> Peter
> ------------------------------------------
> Peter Furniss
> Chief Scientist, Choreology Ltd
>    Cohesions 1.0 (TM)
>    Business transaction management software for application 
> coordination
> web: http://www.choreology.com
> email:  peter.furniss@choreology.com
> phone:  +44 20 7670 1679
> direct: +44 20 7670 1783
> mobile: +44 7951 536168
> 13 Austin Friars, London EC2N 2JX
> > -----Original Message-----
> > From: www-ws-arch-request@w3.org 
> > [mailto:www-ws-arch-request@w3.org]On
> > Behalf Of Miles Sabin
> > Sent: 21 January 2003 11:33
> > To: www-ws-arch@w3.org
> > Subject: Re: Proposed text on reliability in the web services
> > architecture
> >
> >
> >
> > Assaf Arkin wrote,
> > > 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
> > > in the proper manner.
> >
> > Not exactly. Byzantine failures are where nodes/links don't simply 
> > fail, they malfunction in a way which violates the protocol. The 
> > connection with trust issues is that an untrustworthy or malicious 
> > node is pretty much indistinguishable from a malfunctioning one.
> >
> > I think byzantine failures are definitely worth consideration here, 
> > especially in connection with intermediaries and gateways ... eg. a 
> > gateway might accept a SOAP message for forwarding to an internal 
> > system, forward it to the internal system which fails silently, then

> > ack at the SOAP level to the sender.
> >
> > This is yet another example of why RM is an end to end 
> > characteristic of a communication mechanism. Gateways are an 
> > endpoint wrt WS messaging, but aren't endpoints wrt the application,

> > which also includes the systems gateway'd to.
> >
> > Cheers,
> >
> >
> > Miles
> >
Received on Tuesday, 21 January 2003 12:42:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:02 UTC