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 pulled messag es

Title: Re: [ebxml-msg] an assessment of the reliability of pulled messag es
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 !
-----Original Message-----
From: Jeff Turpin [mailto:jturpin@cyclonecommerce.com]
Sent: Monday, December 27, 2004 1:43 PM
To: Jacques Durand; 'ebxml-msg@lists.oasis-open.org'
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" <JDurand@us.fujitsu.com> 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)
-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.
-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?


On 12/17/04 12:08 AM, "Jacques Durand"  <JDurand@us.fujitsu.com> wrote:

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...



-----Original Message-----
From: Jeff Turpin   [mailto:jturpin@cyclonecommerce.com]
Sent:  Tuesday, December 14,  2004 8:05 PM
To: Jacques Durand;   ebxml-msg@lists.oasis-open.org
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" <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]