RE: [ebxml-msg] Selective pulling and failed syncronous transfers

Pim:

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>

Jacques

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

Hello,

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?

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

-  
...

Pim

---------------------------------------------------------------------
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:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php