RE: [ebxml-msg] an assessment of the reliability of pulled messages

[Jacques Durand <JDurand@us.fujitsu.com>]

Title: Re: [ebxml-msg] an assessment of the reliability of pulled messages

Jeff:

 

Your Scenario #1  (Non-reliable Pull Request)

is not realistic as you draft it, because you assume an RMP behavior that is quite "new" w/r to WS-Reliability spec:

namely, that the RMP will be able to resend the cached pulled message as a sync response of an entirely new Pull request.

That would assume that  the RMP has some knowledge of the Pull semantics, and knows somehow that all "Pulls" for this party ID  are equivalent, so that it can do the resending as a response of any of them.

 

The other radical alternative for Non-reliable Pull Request that could be taken (but which has many problems)  can be summarized as:

 

"Because it is a Pull signal, we can redo it (MSH level) as many times as we want, when we fail to get

a pulled message. So no need to involve any RMP-level reliability."

 

Problems are:

 

- that only works if the Pull is idempotent, e.g. you need a flag saying "I want to re-pull the same message as previous pull"

that complicates things.

- some caching is assumed on MSH side so that pulled messages are still available for resending until they are acknowledged somehow. That seems to require a new persistence mechansim at MSH level that would not be necessary if we rely just on RMP presistence.

- that needs be governed by an MSH-level Ack (which we precisely wanted to avoid lately).

Trying to use the "next" Pull as an Ack is very tricky: that assumes a complete serialization of Pull+response pairs, which I think is very restrictive. We should allow for implementations sending batches of Pull without waiting for the response between each.  That is quite possible when using concurrently several HTTP connections, and even over a single HTTP connection (pipelining).

- unless we try to avoid situations where the same ebMS message can be successfully pulled twice (whcih seems hard to guarantee) we'll need to do duplicate elimination at MSH level (based on ebMS ID).

 

 

Jacques

 

-----Original Message-----
From: Jeff Turpin [mailto:jturpin@cyclonecommerce.com]
Sent: Wednesday, January 05, 2005 1:41 PM
To: Jacques Durand; 'ebxml-msg@lists.oasis-open.org'
Subject: Re: [ebxml-msg] an assessment of the reliability of pulled messages

Here are the two proposals as I see them for a "reliable" pull transaction:

I. Non-reliable Pull Request
    ---------- Step#1:

    -Sender MSH: pass Pull(PartyId) to RMP.
   -Sending RMP: send Pull(PartyId) (non-reliable)
            |
           |
   -Receiving RMP: get the Pull (non-reliable)
   -Receiver MSH: get the Pull, pass to App   

    ---------- Step #2:

    -Receiver MSH: gets the pull request and gets a waiting 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)        
        a. failure

   -Sending RMP: does not get the reliable response, does not send an Ack
   -Sender MSH: does not get a pulled message.
    -Sender MSH: schedules the next pull request
        |
        |
    -Receiver RMP: RMP does not get the Ack for the reliable message (response), makes message eligible for
        "resend" (makes message available for next pull request)

b. success
    -Sender RMP: gets reliable response, sends (callback) RMP Ack, passes "pulled" message to MSH
    -Sender MSH: Processes "pulled" message
        |
        |
    - Receiver RMP: Receives Ack and notifies MSH of Delivery

II. Reliable Pull Request
    ---------- Step#1:

    -Sender MSH: pass Pull(PartyId) to RMP.
   -Sending RMP: send Pull(PartyId) (reliable)
            |
           |
   -Receiving RMP: get the Pull reliable request, pass to MSH
   -Receiver MSH: get the Pull, pass to App   

    ---------- Step #2:

    -Receiver MSH: get the waiting message (response) from its queue, pass to RMP.
   -Receiving RMP: send reliably the pulled message over synch MEP with bundled Ack
            (SOAP Response to the previous Pull, as this was a synchronous Pull) and persist this message (for possible resend)
                    
        a. failure

   -Sending RMP: does not get the Ack, makes request eligible for resend
   -Sender MSH: does not get a pulled message.
    -Sender RMP: resends the same (duplicate RM message ID) pull request
        |
        |
    -Receiver RMP: RMP does not get the Ack for the reliable message (response), makes message eligible for
        "resend" (makes message available for next duplicate pull request)
    -Receiver RMP: Receives duplicate pull request (duplicate RM message ID) and responds with the cached reliable
        pull message (response)

b. success
    -Sender RMP: gets reliable response/Ack, sends (callback) RMP Ack, passes "pulled" message to MSH

           -Sender MSH: Processes "pulled" message
                |
                |
            - Receiver RMP: Receives Ack and notifies MSH of Delivery