Some responses below.
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
*************************************************************************************
Christopher Ferris <> on 09/14/2001 03:00:01 PM
To:
David Fischer <>
cc:
Martin W Sachs/Watson/IBM@IBMUS, Dan Weinreb <>,
Subject: Re: T2 Retry with Delivery Receipt
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".
MWS: Which MSH do you refer to here? The first IM or the destination
endpoint? Clearly if either the first IM or the destination doesn't support
RM but does support ebXML-MS, it must send back "not supported". If the
node that receives the message doesn't understand ebXML at all, it can't
send anything back and isn't an MSH at all. This may be obvious but that
isn't clear from some of the postings.
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).
MWS: Yes, but the ebXML or ebXML-RM protocol terminates at the last point
at which there is an ebXML MSH (should be obvious also).
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.
MWS: In this case, the ebXML-MS protocol terminates at the left side of B
and B's left side is the From MSH by definition. From an ebXML viewpoint,
B and everything to the right of it are part of the system above the B MSH.
The B-C link is no more part of the ebXML protocol than is an SMTP
intermediate node.
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.
MWS: I agree with this but we must state explicitly at a minimum that
intermediate nodes must store and forward reliably.
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.
MWS: Indeed. We also have nothing to say about C or the link between B
and C.
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.
MWS: True. That situation is basically impossible.
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.
>
>
