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] Selective pulling and failed syncronous transfers


In your "Two distinct situations" cases, the second one is really the one we want to address:
The responding MSH deciding sometimes to send response over backchannel of request, sometimes not.
Normally the 1st case is covered by RM.

It looks like this the feature would affect:

1- Pmode definition (add a "fallback" option to an MEP)

2- possible definition of a new error ("MessageNoAvailable" to send back on the second leg of the 2-way/sync when the response is not ready. Unless we reuse EBMS:0006)

3- behavior of the responding MSH.

more responses inline <JD>


-----Original Message-----
From: Pim van der Eijk [
Sent: Monday, May 17, 2010 9:09 AM
To: ebxml-msg@lists.oasis-open.org
Subject: [ebxml-msg] Selective pulling and failed syncronous transfers


Could we define functionality to use "selective pulling"
based on eb3:RefToMessageId to support retrieving failed
responses in "sync" bindings?   The response MPC is
specified in the Pmode and the eb3:MessageId of the request is specified in the request message, so all information needed to pull the selected response message is present in a Core v3.0 compliant request user message and Pmode.

This functionality requires the Responding MSH to store such a response and make it available for pulling. Whether the responding MSH does this could be configurable as an option (e.g. pmode parameter). The configuration expresses that a particular Two Way exchange is associated with BOTH a Sync binding AND a fallback Push-and-Pull binding.  The response message, when pulled, would be identical to the sync replied response (including any reliable message sequence numbers, message ids, security).

The implementation of a regular ebMS3 MSH would need to be modified to do the Pull when no synchronous response is received (when initiating, triggered by some error
condition) and to store the synchronous response so that it can be pulled if needed (when responding).

Two distinct situations:
-  The responding MSH successfully contructs a response user message and attempts to send it on the backchannel, but somehow it is lost on its way to the requesting MSH.
-  The responding MSH detects it cannot construct a synchronous response (e.g. because the backend app that needs to produce this response is not responding within some interval). Would we need a special error type, a special signal, or just send a eb3:Messaging structure without eb3:UserMessage?

-  When the initiating finds out it needs to pull, how long does it wait before pulling?  If the back-end is late, it should not pull too soon.

<JD> like any pulling, it’s a matter of implementation configuration - there will be possibly several "useless" pulls. It is an implementation issue. For now we don't have a Pmode parameter for controlling timing of pull.

-  What if there is no response on the pull, does the MSH retry the pull, or is this an ebMS error?  If it retries, how often does it retry and when does it give up?

<JD> this would just be handled like selective pulling: you get a warning error if no answer, then you retry. How many times is a configuration issue.

-  How long does the responding MSH keep the message in the fallback pull queue?  Messages are only pulled from it in exceptional cases.  If the response messages are sent using reliable messaging, sequence acknowledgments could be used to clear any unnecessary (successfully delivered using sync) messages.

<JD> It is an implementation issue.

-  v3.0 core pull with reliable messaging uses reliable pull signals, for multihop we added non-reliable pull signals.
Which one do we need for the fallback messages?

<JD> It is an implementation issue. Non-reliable is fine if we are not concerned the response could be lost on its way back.

-  ...


To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:

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