David,
>The key point is that I think we should allow any or all of these to be
used
and not dictate to an implementation what is required. The consequence of
this is, IMO, that we need to keep these elements separate in the header so
that you can easily choose which ones to use.
I agree, and...
Sounds like a SOAP Bubble to me ! Exactly the same concept.
Scott Hinkelman, Senior Software Engineer
XML Industry Enablement
IBM e-business Standards Strategy
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074
"Burdett, David" <david.burdett@commerceone.com> on 07/19/2001 12:30:21 PM
To: Martin W Sachs/Watson/IBM@IBMUS, Scott Hinkelman/Austin/IBM@IBMUS
cc: Arvola Chan <arvola@tibco.com>, David Fischer
<david@drummondgroup.com>, ebXML Msg
<ebxml-msg@lists.oasis-open.org>, Pete Wenzel
<Pete.Wenzel@RosettaNet.org>, ebxml-cppa@lists.oasis-open.org
Subject: RE: PIP IDs
Marty
You make good points, I can see how any combination of the following could
**potentially** be used for routing purposes:
* From Party
* To Party
* Service
* Action
* CPAId (header)
* RefToMessageId
* CPAId (Via)
... and probably more.
For example at its simplest you could base your routing just on "To Party",
e.g. everything for IBM goes to the same URL. At the other extreme, you
might have to look into the payload to work out where to send the message,
although I don't think this is a good idea.
The key point is that I think we should allow any or all of these to be
used
and not dictate to an implementation what is required. The consequence of
this is, IMO, that we need to keep these elements separate in the header so
that you can easily choose which ones to use.
For example you could combine To Party, Service and Action into a single
URI
for the "to" such as
urn:party:xyzco:service:supplierordermgmt:action:neworder but then you are
forcing single end-point based routing.
Thoughts?
David