RE: Proposed text on reliability in the web services architecture

Wearing my "wrote one to many choreography specs" hat, I would say there are
two distinct problems here.

First, how you define a multi-party interaction so everybody understand that
it involves n>2 participants. Let the choreography people deal with that.

Second, how do you allow an operation to involve multiple consumers. Let's
assume that instead of sending a message to one service you can send that
message to a group of services and do that in a single operation.

If we are still discussing reliability of message delivery (not of
application), then RM should have to say something about that. Specifically,
how it gets the message to more than one consumer, determines how many acks
it has seen, and does message ordering within that group.

From there on everything is the responsible of the coordination protocol
(which can deal with n>2 participants) and the choreography, and indeed
let's not try to solve the same problem in two different places.

arkin


> Very interesting.  I think that we are in harmony here, as long as the
> various objectives are clearly defined.
>
> Parenthetically, it seems to me that there might be some risk of getting
> into murky IP waters, a la the procedural aspects of choreography, when
> one starts looking at the n>2 interactions between components in the
> context you suggest.
>
> -----Original Message-----
> From: Assaf Arkin [mailto:arkin@intalio.com]
> Sent: Tuesday, January 21, 2003 11:54 AM
> To: Cutler, Roger (RogerCutler); Peter Furniss; Miles Sabin;
> www-ws-arch@w3.org
> Subject: 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: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
> > 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: 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
> > 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:  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 13:26:32 UTC