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

[Todd Boyle <tboyle@rosehill.net>]

In my very brief squint at the multiparty facility in BPSS I got
the impression that it only supported all-or-none success, i.e.
lets say five guys agreed to go out and do something 
(very common) and then one of the guys didn't show
up with one component then the whole job ends. 

I imagine today's workflow majors enable the planner to set
conditions and failover for every conceivable case, if they
have the stamina and endurance (ugh)

What we need is a nice visual palette where we can drag 
the little condition boxes, just like todays flowchart software
and type the code for the conditions into the boxes just
like the IDE for any visual programming language.
It would be cool if then, the particpants could be provided
a visual graphical display of where the job is at....

Sorry for the long post, I agree, though, it seems most likely
to me, that the multiparty BP capabilities of ebXML must be
quite limited compared to the requirements of real world
workflow planning.  

The BPSS is the greatest thing out there, keep up the great work,

Keep thinking of economic event recognitino into the GL, 
we need it.  BTW there are some significant stirrings in the 
open source community around a Java business platform 
for SMEs.  That would be such an ideal way for the ebXML 
community to connect with SMEs.   I'm trying to get them to
maintain GL data right, 

Todd



At 07:08 PM 7/25/2001 -0700, James Bryce Clark wrote:
>
>>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
>> >
>
>
>------------------------------------------------------------------
>To unsubscribe from this elist send a message with the single word
>"unsubscribe" in the body to: ebxml-bp-request@lists.ebxml.org
>