Re: CPA composition from multi-role CPPs

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

Regarding the last paragraph, I absolutely agree.  Our Requirements
Specification states that the negotiation and composition processes are
outside the TP team's scope at this time but we have to assure that it can
be done.  The more non-normative advice we can provide, the more we will
understand the problem and the more potential implementers will understand
the problem.  I have had in mind a non-normative appendix on this subject.


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



"Moberg, Dale" <Dale_Moberg@stercomm.com> on 01/19/2001 09:36:45 AM

To:   "'christopher ferris'" <chris.ferris@east.sun.com>,
      ebxml-tp@lists.ebxml.org
cc:
Subject:  CPA composition from multi-role CPPs



[whew, lot of mail today. starting from the bottom up]

ChrisFerris>Of course, if the CP has more than 2 Roles (as in the case I
described)
>then some further intervention may be needed to determine which
>corresponding
>Role(s) Party B should play in the context of the CPA being
>"negotiated".

MartySachs>>
>>    1. Admit that this case requires negotation after composition.

>I say cry Uncle. I see no way around this;-) Of course, "negotiation"
>may not be completely accurate a term. More like "intervention" or
>"user input".


During the NY f2f (way back), this issue came up when we realized that
if we were only given two CPPS, the CPA that could be automatically
formed would be "maximal," for the given matching procedures that were
employed. This maximal match would need to be "filtered" to reflect such
things as:

1. preference on transport, when more than one possible, and only one to be
agreed to.
2. preference on docexch, when more that one possible, and only one to be
used for simplicity.
3. security preferences (key strength, trust anchors, CRL check intervals,
etc etc)
4. to (n-1)

and most importantly,

n. the actual BPs the parties needed/wanted to do together,
and the roles of interest to them!

The negotiation after composition might/would be
needed to trim/filter the desired collaboration
from the technically interoperable combinations
found. Of course, if software were
given as an input to the composition procedure, more
information than simply the two CPPs, then the filtering
and the composition steps can be merged with matching
in a given software product's implementation...

(It is possible, of course, that two parties each can play buyer/seller
roles in the PO BP _and_ that for business reasons, the CPA needs both
permutations! That was Hammermill and IBM: IBM buying green bar, and
Hammermill buying mainframes...)

I believe this fact, along with several others we have discovered,
shows that we only want to provide
informational remarks about the merge and composition
process, because we don't know
that exact information inputs into the composition
procedure for a given software
environment.