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

That's very fine with me.


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


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