OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: End-to-end RM


Please see below.



Martin W Sachs wrote:

> IMO, an MSH, unless it is embued with an intellegence of its own,
> cannot be directly responsible for addressing a delivery failure
> along a message path for a message for which it has already received
> an acknowledgment. It should only be responsible for notifying
> the sending party (the application or its administrator, etc.)
> of the details of the delivery failure.
> MWS:  The MSH which is responsible for notifying the From Party
> of delivery failure is the From
> Party's MSH.  The evidence of delivery failure is exhausting the permitted
> number of retries without receiving an acknowledgment.  So, there is no
> issue about a delivery failure along a message path for which it has
> already
> received an acknowledgment.  IF the acknowledgment came, the message was
> delivered to the destination persistent store.  Of course, I have the
> end to end protocol in mind when I say this. A protcol which permits and
> intermediary to acknowlege the message and further, permits the message
> to be lost farther down the path is not reliable messaging.

Actually, there are three cases as I see it coming from my perspective
where reliability is achieved by a reliable hand-off between two adjacent
MSH nodes along a message path consisting of nodes ALL of which support
the RM protocol or an equivalent (or superior) transport-specific reliable
messaging mechanism.

The first case is one where the originating MSH node (the From Party's
initial MSH) cannot deliver a message to the next MSH node in the
message path following the specified number of retries each separated by
the retry interval. In this case, that MSH needs to communicate (somehow
through some unspecified interface) the delivery failure. This could be
as trivial as a logging of the failure in an error log or it could be
achieved through some call-back to the sending application or its
proxy. Regardless, the mechanism can't be specified as there are simply
too many equally valid possibilities from which to choose.

The second case is one which involves an MSH node that is NOT the
initial From Party MSH. In this case, as defined in section 10.4,
an Error message is generated and sent to the From Party with
an errorCode of DeliveryFailure and a Severity of Error in the event that
the message cannot be delivered to the next MSH node in the message
path. The initial From Party MSH node that receives such an error MUST 
(somehow, probably using the same mechanism as described above) notify 
the From Party of the delivery failure.

The third case is defined as the case where the ultimate destination
MSH of the To Party cannot, for some reason, forward the message to
the To Party (the "application"). This case is equivalent IMO to the
second use case above. The fact that the message is persisted on
disk by the ultimate MSH in the message path is irrelevant from the
perspective of the From Party if the message cannot be processed. It is
no different in my mind than if the message was "lost" at some point
along the way.

The question becomes then, should the DeliveryFailure message be delivered
reliably. I think that if it were, that it closes the loop except in
extreem cases where the DeliveryFailure message results in a delivery failure
of its own, in which case some external mechanism is in play (pick up
the phone and figure out what the problem is, you have bigger problems
than can be addressed with this or any other protocol one could define
such that an implementation were affordable by any but the Fortune 500!).

Any manner of positive acknowledgment should, IMO be optional and should IMO
be a function of the receiving application/party notifying the sending
party/application of the receipt. By this I don't necessarily mean that
the "application" necessarily support such a function directly. This could be
handled by a proxy of the "application" (e.g. a B2BI server [which possibly has as
a component of itself an MSH]).


Because under many circumstances, an application-level response received
within a reasonable, possibly agreed-upon, timeframe can serve as an equally effective
positive acknowledgment without adding the overhead of an unnecessary extra message 
between the parties. 

In RosettaNet, business signals such as the ReceiptAcknowledgment, etc.
can serve the purpose of providing the sending party with an effective
positive acknowledgment that the message has reached its ultimate
destination. Adding in a MSH-specific end-to-end acknowledgment would be
redundant and possibly meaningless in certain use cases such as non-repudiation.

I do not think that we can require that the MSH be provided with the
authorized private keys required to sign a non-repudiation receipt which
in the case of non-repudiation is what determines whether the message
was indeed received from the perspective of the From Party.

RosettaNet, as well as ebXML BPSS provide for a business transaction
time-to-live, after which, in the absence of the response business
message, the transaction, and possibly the whole conversation/exchange,
are considered null-and-void.

> I don't ever recall in any context that we ever said that RM can be
> achieved
> over unreliable links. Possibly you mean unreliable transports, such as
> HTTP, which is what the RM protocol has been designed to address.
> I believe that if a sending party/application says that a message is
> to be delivered with a deliverySemantics of OnceAndOnlyOnce that this
> quality of service MUST be supported (whether by the ebXML RM protocol
> or by "transport" specific means, such as in the case of MQSeries)
> by all MSH nodes in a message path. Maybe the spec doesn't say that
> explicitly, in which case we should address this to make it crystal
> clear in the errata. Something along the lines of:
>      An MSH receiving a message with a deliverySemantics="OnceAndOnlyOnce"
>      that does not support that level of QOS MUST send
>      an Error message to the To Party with an errorCode of NotSupported
>      and a Severity of Error.
> MWS:  This is back into the discussion of end to end vs. hop by hop.  As
> long as the RM protocol is end to end, it doesn't matter whiat quality of
> service is supported in between.  Of course a lousy link in the middle will
> cause more RM retries but it won't violate the committments that RM makes
> to
> the endpoint parties.

Please see above.

> Yes, this would mean that this particular message path would be permanently
> blocked until such time as the offending node is either removed from the
> message path or it is enabled with the RM capability. I don't see this as a
> problem that we need to solve, nor do I ever recall it as being a
> requirement.
> Possibly you are referring to the requirement that RM be achievable over
> unreliable transports such as HTTP and SMTP. That is a very different
> requirement
> than that RM be achievable through intermediary MSH nodes that don't
> support
> that level of QOS.
> Cheers,
> Chris
> [1] http://lists.oasis-open.org/archives/ebxml-msg/200107/msg00026.html
> David Fischer wrote:
> >
> > Chris,
> >
> > I think we have established on the list the need for end-to-end RM.
> However, on
> > the call, you asserted the reverse.
> >
> > Many times we have made the statement in the various F2F meetings that
> "reliable
> > messaging can be achieved over unreliable links."  Yet on the call you
> said that
> > if RM is requested by DeliverySemantics=1&o1, then if a link cannot do RM
> it
> > must return an error?  This could actually be a permanently block any RM
> flagged
> > message!  These two ideas are not compatible.  The only way to provide RM
> over
> > unreliable links is to "close the loop" with an end-to-end Ack.
> >
> > I must continue to maintain that an end-to-end MSH level Ack is required.
> This
> > is already in the spec and it is called DeliveryReceipt.  The only change
> I am
> > asking for is that DeliveryReceipt be appropriately added to section 10.
> >
> > Regards,
> >
> > David Fischer
> > Drummond Group.
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC