← 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
Jeff:
I can help
updating the ReliableMessaging section.
I guess I can
draft up to the points that are still being discussed.
Please let me
know what is the latest version of the spec if you have something more
recent?
Also I'll
probably work on OpenOffice or even simple txt, so you'll do the final imports
into OpenBook?
Hope all this
left you enough time to enjoy your Holidays !
Regards,
Jacques
-----Original Message-----
From: Jeff Turpin
[mailto:]
Sent: Monday, December 27, 2004
1:43 PM
To: Jacques Durand;
''
Subject: Re: [ebxml-msg] an
assessment of the reliability of pulled messag es
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
← Prev in month
← Prev in thread