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 <> on 10/28/2001 12:40:22 AM
Please respond to "Dan Weinreb" <>
To: Martin W Sachs/Watson/IBM@IBMUS
cc: , ,
,
Subject: Re: [ebxml-cppa] Proposed schema changes, plus illustrative
examp le
Date: Sat, 27 Oct 2001 21:00:09 -0400
From: "Martin W Sachs" <>
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.
