[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg] New section 2.6.6
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:
error ID: EBMS:0020,
short description: RoutingFailure
severity: failure
description: whenever an Intermediary is unable to route an ebMS message, it must generate such an error and stop processing the message.
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:
Either the WS-Addressing header wsa:FaultTo or wsa:ReplyTo is present in the message in error and its value indicates an URL that can be directly resolved. The Error message MUST be sent directly to this location;
One of these WS-Addressing headers is present and contains an ebint:RoutingInput reference parameter. The intermediary MUST then add this EPR to the error message (as described in 2.7.3 - the ebMS Error message being considered as a response message). The error message MUST then be sent to its destination using the I-Cloud;
None of these WS-Addressing headers is present in the message in errorbut a RoutingInput header can be inferred (section 2.7.3 , case 4) from other headers available in the message in error. The intermediary MUST add the inferred RoutingInput header to the Error message and sent it using the I-Cloud.
(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:
The intermediary may not be able to push a message to the next hop due to connection error. The ebMS v3.0 Core Specification specifies the EBMS0005, ConnectionFailure error for this situation.
If the routing rule of the intermediary specifies that another MSH (either the final destination or the next intermediary) will pull the message based on its message partition channel identifier, the intermediary MUST store the message and wait for it to be pulled. However, the intermediary MAY impose a limit on the time it will wait for the message to be pulled, and discard messages that have not been pulled after the limit is reached. The intermediary MAY report this as a new kind of error, with error code EBMS0021, MessagePullIntervalExpired.
<JD> does that cover the case where forwarding = put in a pull MPC, and the MPC is "full" or exceeding capacity for some reason (nobody pulls from it, etc.), i.e. there may be a discarding of message not just for timeout but also for lack of capacity.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]