multiparty (was) Fwd: Re: message routing

[James Bryce Clark <jamie.clark@mmiec.com>]

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

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