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:pvde@sonnenglanz.net]
Sent:
Monday, May 17, 2010 9:09 AM
To: ebxml-msg@lists.oasis-open.org
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