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 pulledmessages
Title: Re: [ebxml-msg] an assessment of the reliability of pulled messages
Here are the two proposals as I see them for a “reliable” pull transaction:
I. Non-reliable Pull Request
---------- Step#1:
-Sender MSH: pass Pull(PartyId) to RMP.
-Sending RMP: send Pull(PartyId) (non-reliable)
|
|
-Receiving RMP: get the Pull (non-reliable)
-Receiver MSH: get the Pull, pass to App
---------- Step #2:
-Receiver MSH: gets the pull request and gets a waiting 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)
a. failure
-Sending RMP: does not get the reliable response, does not send an Ack
-Sender MSH: does not get a pulled message.
-Sender MSH: schedules the next pull request
|
|
-Receiver RMP: RMP does not get the Ack for the reliable message (response), makes message eligible for
“resend” (makes message available for next pull request)
b. success
-Sender RMP: gets reliable response, sends (callback) RMP Ack, passes “pulled” message to MSH
-Sender MSH: Processes “pulled” message
|
|
- Receiver RMP: Receives Ack and notifies MSH of Delivery
II. Reliable Pull Request
---------- Step#1:
-Sender MSH: pass Pull(PartyId) to RMP.
-Sending RMP: send Pull(PartyId) (reliable)
|
|
-Receiving RMP: get the Pull reliable request, pass to MSH
-Receiver MSH: get the Pull, pass to App
---------- Step #2:
-Receiver MSH: get the waiting message (response) from its queue, pass to RMP.
-Receiving RMP: send reliably the pulled message over synch MEP with bundled Ack
(SOAP Response to the previous Pull, as this was a synchronous Pull) and persist this message (for possible resend)
a. failure
-Sending RMP: does not get the Ack, makes request eligible for resend
-Sender MSH: does not get a pulled message.
-Sender RMP: resends the same (duplicate RM message ID) pull request
|
|
-Receiver RMP: RMP does not get the Ack for the reliable message (response), makes message eligible for
“resend” (makes message available for next duplicate pull request)
-Receiver RMP: Receives duplicate pull request (duplicate RM message ID) and responds with the cached reliable
pull message (response)
b. success
-Sender RMP: gets reliable response/Ack, sends (callback) RMP Ack, passes “pulled” message to MSH
-Sender MSH: Processes “pulled” message
|
|
- Receiver RMP: Receives Ack and notifies MSH of Delivery
On 12/22/04 12:07 PM, "Jacques Durand" <JDurand@us.fujitsu.com> wrote:
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