MHonArc v2.5.2 -->
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
Title: 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.
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.
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.
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?
David