If any company wants to coordinate the assignment of action and service
names to applications and design its mail room to understand all of that,
nothing in ebXML can stop them. If you know anyone who has ever done that
over a really large company with physical locations all over the globe, ask
them their experience. Or just ask a large company that has tried to
deploy Lotus Notes company wide, what their experience has been.
The URL gets you through the network to the destination MSH. It is a
simple and well understood technique and does not require coordinating
service and action names across the entire company.
For asynchronous messaging, ebXML does not stand in the way of using
different paths for requests and responses. You just sent up the two
parties' delivery channels accordingly. We are already talking about
specifying separate delivery channels for signals and for MSH to MSH
messages, so there again, there is nothing to prevent configuring different
paths for the two directions.
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
*************************************************************************************
"Burdett, David" <david.burdett@commerceone.com> on 11/12/2001 09:35:58 PM
To: "'Doug Bunting'" <dougb62@yahoo.com>, ebxml-msg@lists.oasis-open.org
cc:
Subject: RE: [ebxml-msg] RE: The Return Path Problem
Doug.
>>>In the MS specification, we're designing a message routing
infrastructure
and have explicitly avoided defining particular routing paradigms.� David
is
proposing one routing paradigm, others are free to choose something
different.� However, going further with David's proposal locks us into a
single method.<<<
I think with the current spec we are already locked into a single method
and that is that error messages, delivery messages, etc *have* to be sent
back using the same path as the original method was sent. With the current
spec Use Case 3 just does not work ! If it can be made to work can someone
please explain to me how?
I am also not trying to lock us into a particular proposal. I am only
suggesting that we include information from the sending service in a
message that is sent that is included in the message that is returned so
that it **may** be used for routing purposes when sending a response. I am
not suggesting that this information *must* be used for routing.
On the other hand I beleive that Marty is suggesting that *all* routing
*has* to be done using the URL and nothing but the URL which, as far as I
can see is a single method.
A few more comments below.
David