Title: Re: [ebxml-msg] an assessment of the reliability of pulled messages
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
