Re: [ebxml-cppa] Proposed schema changes, plus illustrative examp le

[Martin W Sachs <mwsachs@us.ibm.com>]

Some rejoinders below tagged MWS:.

Regards,
Marty

*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



Dan Weinreb <dlw@exceloncorp.com> on 10/28/2001 12:40:22 AM

Please respond to "Dan Weinreb" <dlw@exceloncorp.com>

To:    Martin W Sachs/Watson/IBM@IBMUS
cc:    Jzheng@vitria.com, dmoberg@cyclonecommerce.com,
       ebxml-cppa@lists.oasis-open.org, ebxml-msg@lists.oasis-open.org
Subject:    Re: [ebxml-cppa] Proposed schema changes, plus illustrative
       examp      le



   Date: Sat, 27 Oct 2001 21:00:09 -0400
   From: "Martin W Sachs" <mwsachs@us.ibm.com>

   The purpose of the ebXML MS protocol is to get a message from the From
   Party to the To Party. So, in your terms, the MS protocol sends the
   message
   from an instance of X, a "party", to an instance of X, a "party".

OK, that's fine with me, as long as we make it very clear to our
readership that a PartyId, *despite its name*, does not uniquely
identify a "party".  Is that right?

MWS:  Let's try this:  An enterprise may own one or more PartyIds.  A given
PartyId belongs to only one enterprise.  In that sense, it is unique.

   At the ebXML messaging layer, the message is sent to an endpoint address
   which is typically a URL that represents the To party.  It is the
   endpoint
   address given in the delivery channel  that is associated in the CPA (or
   equivalent) with the desired service and action.

OK, then the endpoint addresses serve to name parties.  They aren't
unique names -- that is, many endpoint addresses might denote the same
party, and there's no way (no well-defined or easy way, anyhow) to
determine whether two endpoint addresses denote the same party -- but
that's OK, we don't have any pressing need for unique names.

MWS:  OK by me.

   The X's are NOT instances of MSHs.  The message goes to a (persistent)
   store above the upper boundary of the MSH and then is routed to the
   desired
   application software entry point.

Very well, I shall refrain from using the term "MSH" where I really
mean "party".  Thanks for clearing this up.

   >From what I recall, we have never attempted to formally define an
   instance
   of an MSH. As I said in my previous posting, I don't believe any of the
   existing identifiers is suitable unless you want to consider
   PartyId.CPAId.

   As far as I can see, the only use for defining an instance of a MSH
   would
   relate to error handling.  However it is not clear to me that this is
   the
   business of the MS specification.  Error handling is much more likely
   the
   business of system configuration and management software inside each
   node.

One thing I had in mind was the Message Status Request message.  There
is clearly an abstract entity that is associated with a persistent
store that contains information including a set of assertions of the
form "a message with MessageId XXXX was received at time TTTT".  In
order to use Message Status Request, you must make sure to send it to
the same entity that you were trying to send the original message to.
So that entity should be referred to as a "party", not as an "MSH".
OK.

MWS:  Sounds good.