David,
Some replies below, "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
*************************************************************************************
"Burdett, David" <david.burdett@commerceone.com> on 11/12/2001 04:49:42 PM
To: Martin W Sachs/Watson/IBM@IBMUS, "Burdett, David"
<david.burdett@commerceone.com>
cc: "Burdett, David" <david.burdett@commerceone.com>, "'Miller, Robert
(GXS)'" <Robert.Miller@gxs.ge.com>, "'ebXML Messaging (E-mail)'"
<ebxml-msg@lists.oasis-open.org>
Subject: RE: [ebxml-msg] RE: The Return Path Problem
Marty
You said ...
>>>In summary, it's the endpoint URL that gets the message through the
network to the mailroom and to the correct place on the enterprises's
internal network (final destination MSH).� The routing elements in the
messageheader then get it to the software entry point associated with the
destination MSH.<<<
I think you are implying that you **must not** use the Service and Action
to work out the URL of the endpoint. This means that an intermediary, such
as the mailroom MSH, cannot do any logical routing and that the original
sender of a message must know the physical address (aka URL) of the final
application that is to receive a message they want to send.
MWS: That's absolutely correct. The sender gets the physical address from
the CPA.
In turn this means that whenever you change the internal URL for an
application you have to inform everyone who might send you a message which
is a huge (and my view unnecessary) overhead.
MWS: That's no different from anything else in the CPA. It does
discourage people from unnecessarily reconfiguring their networks. Aside
from that a mailroom function could certainly include a "mail forwarding"
function in which if it receives a message directed to a URL that has been
changed, it substitutes the new URL before forwarding the message. This is
no different than the forwarding services that the post office and phone
companies already provide and have provided forever.
If this is what you suggest then I don't think intermediaries can provide
any value add at all from a routing perspective with the standard version
of the spec.
MWS: That's why some people argue that if it is worth having an
intermediary, it must have something to do beyond being a passive
forwarder.
MWS: But the mailroom intermediary can provide the address forwarding
function that I described above.
I think that you should be able to (but not have to) do routing of messages
based on the "PartyId, Service and Action" and map these, either using a
CPA or by table/database look-up to the URL to which the message should be
sent. Is there a problem with this that I don't see?
MWS: There are two problems that you are not seeing. One is that PartyId,
service, and action are not network functions; they only identify the
software to process the message. The URL provides the routing across the
network (inter- and intranet). The second problem that you are not seeing
is that in a large enterprise with many systems scattered, perhaps, all
over the globe, uniqueness of service and action names across the whole
enterprise is something not even to be dreamed of.
David