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

-----Original Message-----
From: Stefano POGLIANI [mailto:stefano.pogliani@sun.com]
	I think that the composition, being from multi-role or not, would
two steps as, I think, you highlighted in your mail:

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

		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

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

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

Does this make sense ?

Yes it makes sense to me! My only thought currently (unlike at the NY f2f)
I would not insist on always doing the "mechanical matching step" as a
"step". I would rather say that there are two computational tasks: 1,
finding out
what collaborations can be done interoperably and, 2, proposing specific
ways to do (some
or all ) of them. These tasks can be merged into procedures in a great
of ways, and it is entirely implementationally open just how the tasks are
into specific "algorithms"/procedures.


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