OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

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
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" <JDurand@us.fujitsu.com>
Date: Fri, 10 Dec 2004 13:20:09 -0700
To: "Jeff Turpin" <jturpin@cyclonecommerce.com>, "Jacques Durand" <JDurand@us.fujitsu.com>, <ebxml-msg@lists.oasis-open.org>
Subject: RE: [ebxml-msg] an assessment of the reliability of pulled messages

 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:jturpin@cyclonecommerce.com]
Sent: Friday, December 10, 2004  9:01 AM
To: Jacques Durand;  'ebxml-msg@lists.oasis-open.org'
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.



On 12/8/04 8:06 PM,  "Jacques Durand" <JDurand@us.fujitsu.com>  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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]