Marty,
You hit a very important point that is missing from David's paper and the
subsequent discussion:
Content-based routing requires function that understands the content.
That's usually viewed as application function, not message routing.
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.
The ebXML-MSH specification touches on the return path or repeating an
outbound path in a few ways:
1) Message Status query: If an ebXML-MSH has a name, it's the URL as you
have described earlier. Whether or not that name gets you to a particular
software stack is immaterial as long as it appears to operate in that
fashion. To Dan's earlier questions about the Message Status query,
internal routing based on service, action or any other parameters besides
the PartyId and given URL MUST NOT prevent the Message Status query from
operating. OK, Message Status is somewhat optional so the internal routing
can be as haphazard as you please...
2) Errors, Acknowledgements, et cetera: Must go back to the originating MSH.
This is identified in the CPA though you've mentioned some problems with the
current CPA specification with respect to having different error paths for
different requests (really, multiple return paths per request).
We've also identified the service and action that must be used when sending
errors or acknowledgements alone.
3) Business responses: This is the big one described in David's first use
case. It's completely up to the designers of the integration between
companies to decide the services and actions used to identify each part of
their exchange. The information necessary to create a business response
must be in the CPA. Besides that, it's up to the application levels at the
responder (To party of the original message) to craft the entire response,
including making a choice about the service and action.
David,
I'd probably build an MSH that recognises message identifiers in the
RefToMessageId and associates them with internal systems (the originating
MSH) were I to build a mailroom as complicated as outlined in the proposal.
It's a single value and this implementation doesn't require any external
description. I don't buy the argument that this requires storage of every
MessageId ever sent -- if you send something unreliably, you don't care
(that much) about errors. I also don't buy arguments that involve different
outbound and return paths that aren't identified in the CPA beforehand. ABC
Co. isn't likely to tell eHubsRUs much about it's internal routing and will
implement a mailroom if its situation is as complicated as you describe.
The main point is that these are fringe use cases and the specification
provides MSH implementations and applications with ways to address them.
later,
doug