RE: FW: T2, Proposed solution for ... Re: SyncReply andReliableMessagingMethod in QualityOfServiceInfo

[David Fischer <david@drummondgroup.com>]

Thanks Chris, very good points.

<df>comments in-line</df>

Regards,

David Fischer
Drummond Group.

-----Original Message-----
From: Chris.Ferris@Sun.COM [mailto:Chris.Ferris@Sun.COM]
Sent: Thursday, September 20, 2001 11:50 AM
To: ebXML Msg
Subject: Re: FW: T2, Proposed solution for ... Re: SyncReply and
ReliableMessagingMethod in QualityOfServiceInfo


David Fischer wrote:
>
> As Chris pointed out, we need to carefully consider this.  So, I am sending
this
> out again (slightly modified -- retryCount goes in Via).  Does anyone see any
> problems with this or does anyone have an alternative proposal?
>
> Regards,
>
> David Fischer
> Drummond Group.
> ===============
> Proposal:
> A retryCount attribute on Via.  This parameter can only be set by the From
Party
> MSH and MUST start at zero.  The first retry, retryCount is set to one, etc.

How does this work if the sending MSH knows nothing of intermediaries?
Are you suggesting that the Via element is now REQUIRED on all messages?

<df>Yes, this is a problem, not only for retryCount but for all parameters in
Via.  I have asked this same question before, is Via always required?  If we are
doing RM at all, then Via is required in order to pass the ackRequested and
reliableMessagingMethod parameters.  I guess Via is REQUIRED for all RM
messages -- regardless of retryCount.
</df>

>
> Discussion:
> Duplicate detection, as always, is detected by the To Party and From Party
based
> upon MessageId.  Duplicate detection by the Intermediary is based upon
MessageId
> plus retryCount.

How does an intermediary distinguish itself as such? This seems to preclude
an MSH "module" that can be used anywhere as there is now a distinction between
how an intermediary MSH node treats idempotency checking versus how an endpoint
does so.

<df>The IM must know that it is an IM in order to forward rather than process
the payload.  If the IM is not the From Party or the To Party then it must be an
IM.  This is not quite true for a mailroom situation (need to work on this --
something like MTA routing tables?  or MX records?).
</df>

>
> For example (see attached flow chart):
>
> Let's say there are three intermediaries (nodes B, C, D).  A is the From and E
> is the To.  A sends a message with MessageId of 1 and retryCount of 0 (let's
> call this ID 1.0).  We will assume two failures occur during send -- the
message
> makes it to D but has problems sending to E.  The Ack from C also fails going
> back to B.  Since A did not get a DR within retryInterval, it decides* to
retry

retryInterval applies to the RM retry. You are now stating that the DR is the RM
artifact, not the Acknowledgment. What happens when no DR is requested/required?
Does the sending MSH wait for the response message?

<df>Chris, you are right, almost.  There is a CPA to the first IM and a CPA with
the end.  There is a retryInterval in each which corresponds to that interval.
However, what if the From Party does not know about any IMs?  I think it would
be wise for ends to always make retryInterval long and IMs to make retryInterval
short.  This is the kind of problem that will always exist with transparent IMs.
This would be part of the initial system tuning process -- implementation
detail.

	retryInterval(end) > sum(retryInterval(IM)*retries)

I am not saying DR is an RM artifact.  You objected previously so I am no longer
saying DR is part of RM.  I changed the automatic retry to "decides*" to
indicate that this happens by some unspecified means, not RM (read note at
bottom) and not necessarily by retryInterval -- implementation decision.
</df>

> using ID 1.1.  B will not see this as a duplicate and will pass it on.  B will
> also retry to C using ID 1.0.  C will see ID 1.0 as a duplicate so it will not
> send on but C will send an Ack back to B (who gets it).  C will also receive
ID
> 1.1 and send it on since it is not a duplicate.  Meanwhile D has finally made
> the send to E and the DR and Ack have come back from E.  D then receives ID
1.1
> from C and sends it on since it is not a duplicate.  E receives ID 1.1 but
since
> E is the end, it sees ID 1.0 and ID 1.1 as duplicates (it only uses
MessageId).
> E sends an Ack to D for ID 1.1.  E sees ID 1.1 as a duplicate so it does not
> pass on to its application but it does send another DR back to A.  A finally
> receives two DRs, one for ID 1.0 and another for ID 1.1.

So now A has to wait for the total possible number of DRs from E before it can
stop worrying about the message. Why is A allowed to retry before it has
any indication that there is a problem? The same retryInterval as might be
used between A and B doesn't seem realistic to be reused between A and E
as there may be a wide discrepancy between the expected response from B
and the expected response from E. E may be only intermittently connected
for any variety of reasons.

<df>A will stop worrying about the message when it gets a DR (if requested).
Why someone would retry is an implementation/user decision and probably not
automated.  We are leaving this decision criteria unspecified.
</df>

Thus, a separate parameter is needed to specify how long to wait for
a DR (which is still optional as far as I'm concerned) or possibly the
expected business response. As I understand, these are attributes that
are presently expressed in the BPSS (timeToAcknowledgeReceipt
and timeToPerform).

<df>Chris, we are leaving DR as optional and not part of RM -- at your request.
There probably does not need to be a separate parameter because this may not
be/probably won't be automated -- again at your request.   Would you prefer an
automated solution?
</df>

>
> *The retry on lack of DR may be either manual or automatic -- implementation
> dependant.
>
>   ----------------------------------------------------------------------------
------------------------
>               Name: RM9.jpg
>    RM9.jpg    Type: JPEG Image (image/jpeg)
>           Encoding: BASE64

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>