Title: Re: [ebxml-msg] an assessment of the reliability of pulled
messag es
Jacque's message below seems to make a good case for making PullRequest
reliable, although I personally do not feel strongly about it either
way.
-Matt
Jeff Turpin wrote:
Sorry
for the delay in getting back to you Jacques. I guess I can see both
sides of this argument (Reliable PullRequest vs. Unreliable
PullRequest). However, after reading your most recent email, it may be
necessary to make the PullRequest reliable. I would like to close this
issue as soon as possible so we can finish the Reliable Messaging
section. If anyone on the list has a strong opinion either way, please
post your thoughts as soon as possible. Also Jacques, do you think you
might have time to update the ReliableMessaging section to take into
account whatever our final decision is on this issue? I am very busy
trying to get the security section completed. If you can, that would be
great, but I understand if you don’t have the time. Cheers and Happy
Holidays!
Jeff Turpin
Cyclone Commerce, Inc.
On 12/22/04 12:07 PM, "Jacques Durand" <>
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" <>
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
-----Original Message-----
From: Jeff Turpin [mailto:]
Sent: Tuesday, December 14, 2004 8:05 PM
To: Jacques Durand;
Subject: Re: [ebxml-msg] an assessment of the
reliability of pulled messages
This is good.
So I think that in general we are in agreement on the semantics of a
reliable Pull transaction. I guess at this point we can discuss
support of "Pulling" multiple messages and if it is necessary.
Jacques, do you have the time to update or complete the Pull section
of the spec? Don't worry about formatting, if you can just get me
some content, I can get into the DocBook document. We can discuss
this on the call tomorrow if you like. Cheers!
Jeff Turpin
From: "Jacques
Durand" <>
Date: Fri, 10 Dec 2004 13:20:09 -0700
To: "Jeff Turpin"
<>, "Jacques Durand"
<>,
<>
Subject: RE: [ebxml-msg] an assessment of the
reliability of pulled messages
Correct.
I believe that works well (except for the fact that this case would
deserve more exposure in WS-Reliability )
Inline comments:
-----Original Message-----
From: Jeff Turpin [mailto:]
Sent: Friday, December 10, 2004 9:01 AM
To: Jacques Durand;
''
Subject: Re: [ebxml-msg] an assessment of the
reliability of pulled messages
So basically the exchange would look like this:
ebMSH A
ebMSH
B
PullRequest -------------------> (SOAP Request -
"Request/Response MEP") -------->
(w/ WSRM Request)
[Jacques Durand] reliable
Pull with response reply pattern.
<----------------------------------(SOAP Response -
"Request/Response MEP")------Queued ebXML Message (Pull Response)
(w/
WSRM Response & WSRM Request)
[Jacques Durand] reliable
SOAP response (callback pattern only) bundled with an Ack (this is
not precluded by WS-Reliability, but not much advertized either)
WSRM Response (Callback)
------------------------------------------------------------->
Is this correct? I apologize for my crude diagram, I hope it comes
through ok.
[Jacques Durand]
Important note: the Pull message should also require
NoDuplicateDelivery, so that the behavior specified in WS-R 3.2.2
applies: if the sending RMP does not get the expected pulled message
for whatever reason (note: an "empty" ebMS response message due to
no message available to pull is a valid response for the sending
RMP, so is excluded from the case I describe here)
then the sending RMP
will resend the Pull. In case the failure occurred during the
transmission of the pulled message (receiving RMP had actually
received the initial Pull and passed it to ebMS MSH and gotten the
pulled message ) then we expect the receiving RMP to resend a copy
of the initial pulled message that it had cached, for each Pull
resent. So we should not need the "idempotency" assumption for Pull
messages.
Jacques
Jeff
On 12/8/04 8:06 PM, "Jacques Durand" <>
wrote:
About relying (after all) on WS-Reliability for
ensuring the guaranteed delivery of pulled messages (ebMS Pull
responses):
-------------------------------------------------------------------------------------------------------------
One of the reasons we did
not consider this was the fact that this reliability case falls
under the more general
reliability of [synchronous] response messages (speaking in terms
of SOAP MEPs)
and we knew that this is
something WS-Reliability will very likely have to address, but in
the next release.
Having now a second look at
this, and at how much interpretation leeway WS-Reliability 1.1 would
allow for this:
First, summarizing the best
we can hope for:
- ensure guaranteed
delivery of pulled messages in the same way as for any other
message,
but with a resending mechanism that includes the Pull signal (since
we can't just resend the response).
- in case of delivery
failure, the pulled party will know and notify its Producer party
the same way
as for pushed messages that
fail.
- we get all this without
introducing new ebMS signals (e.g. an Ack for pulled messages)
And then looking at how
well WS-Reliability 1.1 can handle this:
- It is clear that the
resending behavior can't be same for pulled messages as for pushed
messages.
WS-R 1.1 states (3.2.1)
that "a resending technique MUST be used ... [ for messages under
GuaranteedDelivery agreement)"
but is not more
specific. So it can be interpreted as resending of the Pull ebMS
signal (which would cause
resending of the cached
pulled message). More on this later.
- the Reply Patterns as
defined in 2.4 do not preclude "reliable" responses (of a SOAP
request-response MEP) that
have themselves
wsrm:Request headers (of course, a "response" reply pattern would
not make sense here)
- Which RMP operation is
used for submitting a "reliable" pulled message is TBD. DO not see
major issue here though
would need be clarified
by implementors. Both Respond and Submit seem open (yet reliability
of Respond unspecified.)
Conclusion: Reliability of
pulled messages is certainly underspecified in WS-Reliability 1.1
meaning it is not precluded, but 1.1 is mute about associated
restriction(s)
(e.g. about usable reply patterns, related faults)
Certainly WS-Reliability
implementors would have to be aware that these features are needed
in addition to what 1.1 requires, for use in ebMS.
One more word about the
resending mechanism for the Pull:
- It has been suggested
in the meeting this afternoon that a Pull resending could be handled
at ebMS MSH level.
I would advise against
that for several reasons.
First, nothing prevents a pulled message to have both wsrm:Request
header and wsrm:Response header for acking of the Pull.
So I would just rely on
guaranteed delivery of the Pull message itself and associated
resending at RMP level.
Then, the Pull is not
really idempotent (ebMS queue management).
Also: the pulled party is
waiting for an Ack that targets the pulled message that was
initially submitted to RMP.
The receiving RMP can associate successive resends of a Pull request
with this same (cached) pulled response,
but only if the resending
is done by sending RMP (if done by MSH, would look as different
requests for receiving RMP,
mandating different
responses - at least looking different from RMP viewpoint - each of
these asking for a different Ack).
Correct interpretation of a
Callback Ack for these copies, and correct delivery failure
notification to the pulled party depends on this.
-Jacques
