← Prev in month
← Prev in thread
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"
<> 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
← Prev in month
← Prev in thread