ebxml-tp message

OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

Subject: RE: CPA composition from multi-role CPPs


	I think that the composition, being from multi-role or not, would require
two steps as, I think, you highlighted in your mail:

	1.	A mechanical "matching step"
		This step would distill the only combinations that are possible
		according to the constraints that are defined by the TP specifications.

		This step may be implemented by a software program or by a human but
		needs to follow rigorously the "matching criteria" that are
		highlighted in the spec.

		(i.e. compatible transports, different roles in the same BP etc)

	2.	A subjective "selection step"
		The output of the previous step may be more than a single result
		or may well be a single result that does not make sense or may
		well be a single result which would need further parametrization
		(as implied in a message some days ago)

		At this point, a human will have to take a decision or to fill
		some blanks.

Does this make sense ?


 -----Original Message-----
 From: Moberg, Dale [mailto:Dale_Moberg@stercomm.com]
 Sent: 19 January 2001 15:37
 To: 'christopher ferris'; ebxml-tp@lists.ebxml.org
 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
 >then some further intervention may be needed to determine which
 >Role(s) Party B should play in the context of the CPA being

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC