Re: multiparty (was) Fwd: Re: message routing

[Martin W Sachs <mwsachs@us.ibm.com>]

My replies embedded below.

Regards,
Marty

*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



James Bryce Clark <jamie.clark@mmiec.com> on 07/25/2001 10:08:17 PM

To:   ebxml-cppa@lists.oasis-open.org
cc:   ebxml-bp@lists.ebxml.org
Subject:  multiparty (was) Fwd: Re: message routing




>Date: Wed, 25 Jul 2001 17:19:13 -0400
>From: christopher ferris <chris.ferris@east.sun.com>
>Subject: Re: message routing
>
>My turn;-)    Please see my comments below.    Cheers,    Chris
>
>Martin W Sachs wrote:
> > Dale,   First, I would like to separate routing from multiparty.
> > ROUTING

      [J] On this topic, I agree with earlier posters that it would be nice
to have a messaging-level artifact that identifies single messages as
"belonging" to a specific conversation.
MWS:  We already have it.  It's the conversation ID.

MWS:  I was trying to separate routing at the destination from multiparty
matters.
Whether in a two- or multi-party conversation, a message sender sends a
message
to one other party and has to include the routing information appropriate
to
the recipient.  That information comes from the BPSS instance document.

However, as a professional
pessimist, a first question is, how could a self-declarative parameter be
misused?
      In an ongoing multi-party transaction, the parties depend in part on
reliable boundary setting.  A message that is allowed to declare itself as
part of the Foo series is a different, and more difficult, proposition than
a message whose payload gives externally-verifable proof that it is a
Foo.   (E.g., its author, its time attributes, its conforming contribution
to the management of jointly-declared state machines, its conformance to
pre-existing conditions that anticipate it.)   As a participant in that
automated marketplace, I may want to rely on the transactional rules
implicit in its boundaries, and know that I'm not dealing with a Wolf in
Foo's clothing.
MWS:  I think you are telling me that multiparty collaborations are hard.
I thought I was trying to tell you that.  :-)

]
>[snip] * * *
> > MULTILATERAL CPAs
> > In IBM Research, we deferred multilateral tpaML when we realized that
there
> > were major matters whose solutions would delay the basics. Problems we
ran
> > into included:
> >    Multiparty choreography (BPSS may have taken care of this one)
>
>Possibly, but I don't believe that they gave it all the attention
>that it really needs. What they did IMHO amounts to a placeholder
>for dealing with multiparty choreographies in the next round.
>Karsten, please correct me if I have mis-characterized this.

       [J]  Karsten can give his own view.  Mine is that you're right.   To
be fair, a number of smart BP team people also have their own views, and
may not agree with either of us.  It is unfortunate that cross-standard
coordination in 1.0 was such a secondary goal.  BP and TPA did pretty well,
for a sporadic bootleg effort, but I hope we improve it this time.

> >    Conversation state tracking across parties:  * * *   A has to know
> about the
> >    messages between B and C to understand the current state. * * *  Are
> there     >    things going on between B and C that A isn't supposed to
know
> >    about even though there is a CPA among the three of them?

      [J]  I think so.  From a legal point of view, although the
abstraction of these practices is a rather new and arcane art, we generally
are forced to build up our analysis of inter-party contract obligations
from binary pairs.   To do or undo deals, or assess risks, we need to know
separately what A and B owe each other, and B-C, and A-C.   Even in a
multi-party marketplace.   If anyone wants to look further into that
hypothesis, let's talk about it off-line.

> >    Are there
> >    things in the CPA that relate to matters between B and C that A
> >    shouldn't even see in the CPA?
> >

      [J]  Let me try to construct an example.  (Be gentle;  I'm winging it
here.)  I may be an information broker who resells an intangible service to
you, by harvesting data from a difficult, cranky source in one-off
automated transactions which were a nuisance to implement, and reshuffling
the info to you on a user-friendly, low-hassle retail sort of
platform.  There may be aspects of the way I get the data from Cranky
Source -- e.g., protocol, periodicity, messaging channel or security level
-- that I don't want you as Complacent Retail Buyer (or potential entrant)
to know.  Perhaps, for reasons of source identifiability, or pricing, or
second-guessing the service level I am offering or my value-added
operations, versus what I could conceivably offer.  Maybe some of those
matters could be reverse-engineered from the CPA contents.
MWS:  Again, that's why in both tpaML and CPP-CPA, the perpetrators decided
to crawl (2-party) before walking (multi-party). In this case, we figured
that if there were things that A wasn't supposed to know about B and C,
let's just use three binary collaborations with separate CPAs and attack
the broader question of multiparty later.

> >      Are there new security issues with more than two parties?
> > We didn't give up on these problems.  It was more of a case of crawling
> > before walking before running. So yes, at least in my mind, leaving
> > multiparty CPAs out of scope for version 1 was a matter of not having
> > enough time to work the problem than because of any principle.  We have
> > seen the result of Core Components perhaps being too ambitious.
>
>Agreed! ;-)

      [J]  Amen.   My working guess is that we may yet learn that at some
level of certainly and stability, it may always be necessary to build up
multi-party transactions from binary pairs.  But it's early in the game.
      The question often at the back of my mind is what I would say if a
client asked if it's safe, from a legal and process point of view, to "hook
up my EAI to this XML thing."    Are the risks to the enterprise (of
suffering unanticipated enforceable legal commitments based on some process
flaw, nonreplicable transformation, failure of isomorphism between the code
and the user's understanding of it, etc etc) materially greater than the
usual risks associated with paper contracts and human negotiation?   Now
all we have to do is refine and specify the legitimate business
requirements associated with that question ... I'm not promising to ship
next week on that one.

      Best regards    Jamie

> >
> > Regards,
> > Marty
> >


------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-cppa-request@lists.oasis-open.org