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: RE: [ebxml-msg] RE: The Return Path Problem


I agree with your definition of a "Party", and yes I assume that there is
only one MSH within a party that implements a Service and Action. I also
agree that we need to be more explicit about what is (or is not) a Party and

However I don't think that limiting a Party to one MSH Service and Action is
necessarily a problem as:
1. A Party can represent a division of a company (as in DUNS+4)
2. If you need more than one MSH for a Service and Action within a company,
then you do content based routing where some other data (perhaps in the
payload) is ued to do the second level routing.

I also think that a CPA should be between businesses and not between
applications as the maintenance level required by the keeping CPAs between
individual applications is too high. What I think Marty's suggestion implies
would mean you would have to update your CPA with a business if you wanted
to do a query for a new reason.

I also agree that Service and Action are "what" type information and that we
need the "how". It's just that I think you should be able to dervice the
"how" dynamically from the "what" rather than just ignore the "what" for
routing purposes.



-----Original Message-----
From: Dan Weinreb [mailto:dlw@exceloncorp.com]
Sent: Monday, November 12, 2001 1:41 PM
To: david.burdett@commerceone.com
Cc: ebxml-msg@lists.oasis-open.org
Subject: Re: [ebxml-msg] RE: The Return Path Problem

In my mind, the topic of your paper is closely related to the
questions I've been asking about "how do you name an MSH" or "how do
you name a party".  I think there has been some confusion about what
we mean by a "party": is "ABC Co" is a party, or is "Order Management
MSH" a party?  Marty seemed to be suggesting the latter, to which I
replied that then a "partyId" would not be an identifier of a "party".

It looks to me like you're assuming:
  -- ABC Co. is one "party".  Order Management MSH is not a "party".
  -- A "party" is identified by a "partyId" (i.e. each partyId denotes
	one specific "party".
  -- There is one CPA, between the "parties", so there isn't a separate
	CPA for the different paths shown in your figure 1-1.

In your paper, you suggest using the Service and Action fields in
order to figure out how to route the message.  It seems to me that
there is a tacit assumption behind this suggestion, which I think
needs to be made explicit.  It assumes that you never have two
distinct MSH's within one "party" that both implement the same

Is this really a safe assumption?  If a "party" might be a large
corporation, the corporation could have many divisions, each of which
provides the service "Purchasing" with the action "Submit PO".

It seems to me that Service & Action are an assertion about *what* to
do, not *who* is doing it.  For routing, we want to use "who-like"

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

Powered by eList eXpress LLC