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



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
separate
"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
variety
of ways, and it is entirely implementationally open just how the tasks are
translated
into specific "algorithms"/procedures.


/Stefano

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


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

Powered by eList eXpress LLC