Subject: RE: CPA composition from multi-role CPPs
That's very fine with me. /Stefano » -----Original Message----- » From: Moberg, Dale [mailto:Dale_Moberg@stercomm.com] » Sent: 19 January 2001 17:40 » To: 'Stefano POGLIANI'; 'christopher ferris'; ebxml-tp@lists.ebxml.org » 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. » » » » » » »
Powered by
eList eXpress LLC