OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [ebxml-msg] 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?

   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.

   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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC