Subject: RE: CPA composition from multi-role CPPs
Dale, 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 ? /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. » » »
Powered by
eList eXpress LLC