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

RE: Proposed text on reliability in the web services architecture

From: Peter Furniss <peter.furniss@choreology.com>
Date: Tue, 21 Jan 2003 17:22:16 -0000
To: "Miles Sabin" <miles@milessabin.com>, <www-ws-arch@w3.org>
Message-ID: <LLEBILBKKFJFAFMCFCHJMEHJDMAA.peter.furniss@choreology.com>

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 from
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 each
two-party relationship there is some (implicit or explicit) contract that
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 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 you
> > 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:22:18 UTC

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