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] New section 2.6.6


Pim:
 
inline <JD>


From: Pim van der Eijk [mailto:pvde@sonnenglanz.net]
Sent: Wednesday, November 04, 2009 12:11 AM
To: ebxml-msg@lists.oasis-open.org
Subject: [ebxml-msg] New section 2.6.6

 
Here is a proposed re-write of section 2.6.6, generalized to cover all errors at intermediaries:  the (new) routing error, connection error and a (new) MessagePullIntervalExpired error.

2.6.6 Handling of Errors at Intermediaries

ebMS Errors (eb3:Error) generated by endpoints are subject to the same reporting options as errors in point-to-point communication. At least a couple of routing patterns for eb3:Error must be supported: (a) the error destination URL is known (e.g. obtained from the PMode) and does not require any multi-hop routing, or (b) the eb3:Error signal is routed using the same routing functions as those used for other ebMS signal messages. 

<JD>  I would not impose that "At least a couple of routing patterns for eb3:Error must be supported" because some intermediaries may be designed to only support the "configured [error] reporting" below. Can we say instead: "Two routing patterns may be used...".

An ebMS Error can be generated by Intermediaries when a message cannot be routed by the Intermediary because the message does not match any rule in the routing function. This new type of error MUST be supported by intermediaries:

Note that finding a match for a message in the routing function is separate from applying the rule. For instance, the intermediary may not immediately forward the message but store it first.

The reporting of an error generated by an intermediary MUST follow one of these three patterns:

(a) Configured reporting: 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 another MSH may pull from. In all cases this is subject to a QoS agreement between I-Cloud providers and end-users.

(b) Message-determined reporting: if there is no provision for solution (a), the error is sent to the destination based on data contained in the faulty message. This may in turn fall into a couple of cases:

(c) Default reporting: if there is no provision for either (a) or (b), the default reporting option for an error related to the routing of a message sent over an HTTP request, is to send back an error message over the HTTP response. The default reporting mode is usually sufficient for Hub-and-spoke configurations.

To prevent looping of error message intermediaries MUST NOT sent Error messages for messages that themselves transmit routing errors. Note that this not prevent an intermediary from generating and reporting of such errors as long as they are not sent out as Error messages.  

<JD>  To be more precise: if an error unit is piggibacked over a regular User Message unit, then it is still possible to fault the User Message unit and send the related error.

A non-normative example of a routing error signal is provided in appendix D.5 .

Apart from RoutingError, intermediaries may also generate other errors:



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