RE: [ebxml-msg] Routing Errors

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

How about:

Either one of the following:

(a) errors are handled and reported in an implementation-specific
manner: either logged locally or sent to a fixed, pre-configured
destination, or yet assigned to a specific MPC that one may pull from.

(b) if there is no provision for (a), the error is sent to the
destination identified by wsa:ReplyTo or wsa:FaulTo, which may involve
I-Cloud routing as described in 2.7.3 (the ebms Error message being
considered as a response message).

(c) if there is no provision for (a) and no wsa header supporting (b),
the error related to the routing of a messages sent over an HTTP request
should be sent over the HTTP response. 

Jacques

-----Original Message-----
From: Pim van der Eijk [mailto:pvde@sonnenglanz.net] 
Sent: Wednesday, April 29, 2009 12:12 PM
To: ebxml-msg@lists.oasis-open.org
Subject: [ebxml-msg] Routing Errors

 

Section 2.6.6 of the current version of the spec describes three options
for routing errors at intermediaries:
(a) error is logged only
(b) error is sent to a fixed, pre-configured destination
(c) error is sent to destination identified by wsa:ReplyTo or wsa:FaulTo

I would like to propose some variants:

(d) error is sent on the HTTP response (anonymous EPR).  

(e) the error is sent to the icloud URI asynchronously.

In both cases (d) and (e) an error message generated using option (4)
from section 2.7.3 SHOULD be added. I.e. a routing parameter is added
based on UserMessage header elements. Attached are a UserMessage and a
sample Error message that an intermediary might generate. This allows
routing errors to
be routed back to the senders.   

Option (d) is especially relevant for the first intermediary: endpoints
sending messages to an intermediary will get all routing errors
immediately, without having to be HTTP addressable or to pull from an
MPC on some intermediary.  To be able to generate the routing error, the
intermediary only needs to verify that it has a matching routing rule.
It would not have to actually wait until the message is routed, so the
intermediary can still be fully asynchronous (pull-on-push, or
store-and-forward push-on-push). The is-routable(message)->boolean
function adds a minimal processing burden on intermediaries so is quite
acceptable even in high performance, high volume
environments.   Assuming typical multihop deployments will have vastly
more
endpoints for any intermediary, I think (d) could be the default. At the
least, I would prefer it to options (a) and (b).

In scenario (e) the routing function of the intermediary would define
how to route the error message back through the icloud, using the
regular options for response messages.

Scenarios (d) and (e) MUST NOT be applied to messages that themselves
carry routing errors. 

Pim