[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