RE: Proposed text on reliability in the web services architecture

> 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.

I definitely agree. I do see more n=2 cases than n>2 cases, and most
business interactions do involve n=2 interactions or do multi-party
interactions in a way that forces n=2 interactions. This might be a best
practice or maybe a limitation of tools to properly address n>2
interactions.

Regardless, we have to determine whether WS is intended solely for the
purpose of addressing business interactions or whether it provides a
framework for interacting services. Many business applications that do n=2
business interactions also do n>2 interactions between their components.
That would be a place where WS could replace legacy and proprietary
protocols, and I believe would be of interest to the W3C.

arkin

>
> -----Original Message-----
> From: Assaf Arkin [mailto:[email protected]]
> Sent: Tuesday, January 21, 2003 11:32 AM
> To: Peter Furniss; Miles Sabin; [email protected]
> Subject: RE: Proposed text on reliability in the web services
> architecture
>
>
>
> 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?
>
> arkin
>
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]]On
> > Behalf Of Peter Furniss
> > Sent: Tuesday, January 21, 2003 9:22 AM
> > To: Miles Sabin; [email protected]
> > 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
> 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
> >
> > ------------------------------------------
> > Peter Furniss
> > Chief Scientist, Choreology Ltd
> >
> >    Cohesions 1.0 (TM)
> >    Business transaction management software for application
> > coordination
> >
> > web: http://www.choreology.com
> > email:  [email protected]
> > phone:  +44 20 7670 1679
> > direct: +44 20 7670 1783
> > mobile: +44 7951 536168
> > 13 Austin Friars, London EC2N 2JX
> >
> > > -----Original Message-----
> > > From: [email protected]
> > > [mailto:[email protected]]On
> > > Behalf Of Miles Sabin
> > > Sent: 21 January 2003 11:33
> > > To: [email protected]
> > > 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
> > >
>
>