MHonArc v2.5.0b2 -->
ebxml-msg message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [ebxml-msg] an assessment of the reliability of pulled messag es
Title: Re: [ebxml-msg] an assessment of the reliability of pulled messag es
Sorry
I missed the last call (Wed 14) , but Jeff told me there was more discussion on
why make the Pull message reliable .
Could
someone post notes about this?
Here
is my opinion on why we need to make the Pull itself reliable (in addition to
the pulled message)
In case we do NOT use guaranteed delivery for the Pull ebMS
signal, we have the following issue. Let
me first unwind the scenario that we are talking about, I
believe:
-------------- Step
#1:
-Sender MSH: Send
Pull(PartyId) in non-reliable way.
-Sending RMP: send Pull(PartyId)
(non-reliable)
|
v
-Receiving RMP: get the
Pull
-Receiver MSH: get the Pull, pass to
App
-------------- Step #2:
-Receiver MSH: get the pulled message
(response) from its queue, pass to RMP.
-Receiving RMP: send reliably the
pulled message over synch MEP (SOAP Response to the previous Pull, as this
was
a synchronous Pull) and persist this
message (for possible resend)
|
*
failure
-Sending RMP: does not get the
reeliable response, does not send an Ack
-Sender MSH: does not get a pulled
message.
-------------- Step #3:
-Sender MSH: re-send Pull(PartyId) in
non-reliable way after a while, for pulling the same message.
-Sending RMP: send the new
Pull(PartyId) (non-reliable) with a new [WS-Reliability] message
ID.
|
v
-Receiving RMP: get the second Pull,
but never got an Ack for the [reliable] pulled message it sent as
response
to the previous Pull. The RMP however
CANNOT resend the persisted pulled message because it needs to do
so
only as a SOAP response of a Pull
message with same [reliable] message ID as the initial Pull.
(indeed, the RMP is unable to know
that the second Pull is for pulling the same message).
Consequently, will
persist uselessly the initial pulled
message until some time out and notify of delivery failure
the receiver MSH later
on.
-Receiver MSH: get the second
Pull, look at its queue. But will pull a different message unless (1) there is a
flag on
the Pull saying that this is for the
previously pulled message, and (2) the MSH queue remembers the
previously
pulled message. (need to enforce
idempotency)
--------------
We don't have all these issues if we
send Pulls reliably.
Clearly in all cases, the MSH will
also have to resend Pulls in case a first pull was unsuccessful at getting
the
pulled message,
but I believe that should
only have to deal with the MSH
failures
(e.g. when there was nothing yet in the MSH queue to
be pulled)
Relying exclusively on the MSH Pull
resending mechanism for handling all cases of failure does not get
us any mileage in terms of
design simplicity and implementation effort.
Note that we need to define more
precisely the behavior of RMP for a reliable synchronous pulled message (as a SOAP
response):
I assume that the resending
mechanism can only resend a pulled message as a
SOAP response of a SOAP request that
is itself a duplicate (in the RMP sense) of the initial SOAP
request.
Meaning the initial Pull has to be
resent by the RMP - not the MSH - and so be treated itself asa a reliable
message.
Does
that address the questioning on using reliability for Pull?
Jacques
On 12/17/04 12:08 AM, "Jacques Durand"
<JDurand@us.fujitsu.com> wrote:
Jeff:
Currently traveling, sorry for missing the call - yes I
can work on updating the Pull section.
Regarding the "multiple" Pull, I
am still questioning teh requirements for this...
Regards,
Jacques