ebxml-msg — archive

[System]

David, In this case, where the MSH doesn't support ebXML RM protocol, you cannot send a message with OnceAndOnlyOnce semantics. It MUST send back an error "Not Supported". My point is that the RM protocol is hop-to-hop and the end-to-end semantics are achieved by having each hop be reliable (whether using ebXML RM or something else). Think of it this way: (routing app) | | A[eb] <-> [eb]B B[MQ] <-> [MQ]C In this case, the B intermediary is reliable and supports both ebXML RM *and* MQ series. Whether these are separate instances or the same instance with multiple capabilities is irrelevant. It may be distributed for that matter. The routing app needs to be reliable as well (just as any other app) because it should ONLY mark the message as having been processed if it has successfully processed it. We can be more explicit regarding what responsibilities are at an intermediary node here, but IMHO, there really is no difference here between a routing "application" and an endpoint business "application" in that the MSH has a responsibility to ensure that the "application" processes the message. The B node above could all be a single piece of software, operating as a routing intermediary (which would certainly make it more robust), but we have nothing to say on the matter as far as our specification is concerned. I don't think that we need to address the situation where two adjacent nodes don't support the same RM protocol. That would be (IMHO) no different that an SMTP node trying to foist the SMTP protocol on an HTTP server. They speak different protocols and can never interact directly without some manner of gateway. Cheers, Chris David Fischer wrote: > > Chris, > > What do you mean by unreliable? I will agree there is no unreliable IM but > there can be an IM which does not support ebXML RM (e.g. uses MQSeries instead). > This is the whole point of the reliableMessageMethod parameter. > > David Fischer > Drummond Group. > >