Petals Distribution

Better management of errors versus faults in JBI exchanges

Details

  • Type: Task Task
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 4.2.4
  • Fix Version/s: None
  • Component/s: Components
  • Security Level: Public
  • Description:
    Hide

    The JBI specs talks of patterns that optionally have faults in them, but it also talk of errors and of error status.
    There is not much explanation about the role of errors, error status and when they can be set on an exchange.

    This ticket clarifies that, and describe what need to be done to improve the code of petals.

    Faults are messages (implementing NormalizedMessage and Fault interfaces).
    FAULT messages are defined in WSDL file in the same ways as OUT or IN messages: they respect an xml schema and that's all.
    When a fault is set on an exchange, the exchange has the status active.

    Errors are java exceptions: they are not defined in the WSDL as they are NOT business related, but technical errors!
    When an error is set on an exchange, the pattern does not continue, the exchange has the status error.

    To clarify, JBI can be partially considered as a WSDL extension: when comparing JBI with SOAP (another WSDL extension), the corresponding concept to JBI Errors are SOAPFault.
    Important: SOAPFault are not ALWAYS WSDL Fault, SOAPFault can represent technical errors (See overview of http://docs.oracle.com/cd/E24329_01/web.1211/e24965/faults.htm for details).
    As a side note, in that context, in the BC SOAP errors must be transformed to SOAPFault (potentially by hiding the stacktrace to hide implementation details!).

    Based on that, the following should be done/respected:

    Show
    The JBI specs talks of patterns that optionally have faults in them, but it also talk of errors and of error status. There is not much explanation about the role of errors, error status and when they can be set on an exchange. This ticket clarifies that, and describe what need to be done to improve the code of petals. Faults are messages (implementing NormalizedMessage and Fault interfaces). FAULT messages are defined in WSDL file in the same ways as OUT or IN messages: they respect an xml schema and that's all. When a fault is set on an exchange, the exchange has the status active. Errors are java exceptions: they are not defined in the WSDL as they are NOT business related, but technical errors! When an error is set on an exchange, the pattern does not continue, the exchange has the status error. To clarify, JBI can be partially considered as a WSDL extension: when comparing JBI with SOAP (another WSDL extension), the corresponding concept to JBI Errors are SOAPFault. Important: SOAPFault are not ALWAYS WSDL Fault, SOAPFault can represent technical errors (See overview of http://docs.oracle.com/cd/E24329_01/web.1211/e24965/faults.htm for details). As a side note, in that context, in the BC SOAP errors must be transformed to SOAPFault (potentially by hiding the stacktrace to hide implementation details!). Based on that, the following should be done/respected:
  • Environment:
    -

Issue Links

Depends
 

Activity

Ascending order - Click to sort in descending order
Victor NOËL made changes - Fri, 24 Apr 2015 - 15:04:04 +0200
Field Original Value New Value
Priority Blocker [ 1 ]
Description The JBI specs talks of patterns that optionally have faults in them, but it also talk of errors and of error status.
There is not much explanation about the role of errors, error status and when they can be set on an exchange.

This ticket clarifies that, and describe what need to be done to improve the code of petals.

Faults are messages (implementing NormalizedMessage and Fault interfaces).
FAULT messages are defined in WSDL file in the same ways as OUT or IN messages: they respect an xml schema and that's all.
When a fault is set on an exchange, the exchange has the status active.

Errors are java exceptions: they are not defined in the WSDL as they are NOT business related, but technical errors!
When an error is set on an exchange, the pattern does not continue, the exchange has the status error.

To clarify, JBI can be partially considered as a WSDL extension: when comparing JBI with SOAP (another WSDL extension), the corresponding concept to JBI Errors are SOAPFault.
Important: SOAPFault are not ALWAYS WSDL Fault, SOAPFault can represent technical errors (See overview of http://docs.oracle.com/cd/E24329_01/web.1211/e24965/faults.htm for details).
As a side note, in that context, in the BC SOAP errors must be transformed to SOAPFault (potentially by hiding the stacktrace to hide implementation details!).

Based on that, the following should be done/respected:
* Fault can only be set by components or SU since they are defined in WSDL and only those are implementing services respecting a WSDL (in the same way that only them can create IN or OUT messages!)
* Error can happen everywhere (container, CDK, component, SU) and must be set on the message (some care should be taken to put exception that are classloader-ok, see https://doc.petalslink.com/display/petalscomponents/Advanced+topics+and+guidelines#Advancedtopicsandguidelines-JBIlisteners%2CtheCDKandExceptionhandling .
* The SOAP BC should transform Errors to SOAPFaults: see PETALSBCSOAP-145.
* The CDK: See ticket to be created. 		The JBI specs talks of patterns that optionally have faults in them, but it also talk of errors and of error status.
There is not much explanation about the role of errors, error status and when they can be set on an exchange.

This ticket clarifies that, and describe what need to be done to improve the code of petals.

Faults are messages (implementing NormalizedMessage and Fault interfaces).
FAULT messages are defined in WSDL file in the same ways as OUT or IN messages: they respect an xml schema and that's all.
When a fault is set on an exchange, the exchange has the status active.

Errors are java exceptions: they are not defined in the WSDL as they are NOT business related, but technical errors!
When an error is set on an exchange, the pattern does not continue, the exchange has the status error.

To clarify, JBI can be partially considered as a WSDL extension: when comparing JBI with SOAP (another WSDL extension), the corresponding concept to JBI Errors are SOAPFault.
Important: SOAPFault are not ALWAYS WSDL Fault, SOAPFault can represent technical errors (See overview of http://docs.oracle.com/cd/E24329_01/web.1211/e24965/faults.htm for details).
As a side note, in that context, in the BC SOAP errors must be transformed to SOAPFault (potentially by hiding the stacktrace to hide implementation details!).

Based on that, the following should be done/respected:
* Fault can only be set by components or SU since they are defined in WSDL and only those are implementing services respecting a WSDL (in the same way that only them can create IN or OUT messages!)
* Error can happen everywhere (container, CDK, component, SU) and must be set on the message (some care should be taken to put exception that are classloader-ok, see https://doc.petalslink.com/display/petalscomponents/Advanced+topics+and+guidelines#Advancedtopicsandguidelines-JBIlisteners%2CtheCDKandExceptionhandling .
* The SOAP BC should transform Errors to SOAPFaults: see PETALSBCSOAP-145.
* The CDK should not transform errors to fault: See PETALSCDK-130.
Victor NOËL made changes - Fri, 24 Apr 2015 - 15:04:14 +0200
Assignee Christophe DENEUX [ cdeneux ] Victor NOËL [ vnoel ]
Victor NOËL made changes - Fri, 24 Apr 2015 - 15:04:43 +0200
Link This issue depends on PETALSCDK-130 [ PETALSCDK-130 ]
Victor NOËL made changes - Fri, 24 Apr 2015 - 15:04:56 +0200
Link This issue depends on PETALSBCSOAP-145 [ PETALSBCSOAP-145 ]
Hide
Permalink
Christophe DENEUX added a comment - Mon, 27 Apr 2015 - 19:37:05 +0200

I agree with you, with the following adds:

  • a business error is a JBI fault,
  • a technical error is a JBI error,
  • a JBI fault is not a SOAP fault, so a dedicated JIRA issue should be created to change the JBI fault format (from SOAPFault to simple XML payload compliant with the WSDL)
  • a chapter should be added into the Petals documentation about the error management and explain the error vs faults,
  • each MEP should be documented, in a business view, into Petals documentation to defined explicitly where a business fault can occur, and where a technical error can occur in MEP. For example, no business error could be occur with MEP InOnly,
  • each component should be review to manage correctly error/fault, mainly binding-components against their external side, so one JIRA issue by component should be added if needed
Show
Christophe DENEUX added a comment - Mon, 27 Apr 2015 - 19:37:05 +0200 I agree with you, with the following adds:
  • a business error is a JBI fault,
  • a technical error is a JBI error,
  • a JBI fault is not a SOAP fault, so a dedicated JIRA issue should be created to change the JBI fault format (from SOAPFault to simple XML payload compliant with the WSDL)
  • a chapter should be added into the Petals documentation about the error management and explain the error vs faults,
  • each MEP should be documented, in a business view, into Petals documentation to defined explicitly where a business fault can occur, and where a technical error can occur in MEP. For example, no business error could be occur with MEP InOnly,
  • each component should be review to manage correctly error/fault, mainly binding-components against their external side, so one JIRA issue by component should be added if needed
Hide
Permalink
Victor NOËL added a comment - Tue, 28 Apr 2015 - 09:23:33 +0200

a business error is a JBI fault,

And a business error is a fault declared in a wsdl.

a technical error is a JBI error,

a JBI fault is not a SOAP fault, so a dedicated JIRA issue should be created to change the JBI fault format (from SOAPFault to simple XML payload compliant with the WSDL)

A JBI Fault is a SOAPFault, in SOAP, see http://docs.oracle.com/cd/E24329_01/web.1211/e24965/faults.htm
A ticket is already open for the CDK PETALSCDK-130 (and for the BC SOAP so that SOAPFault are created as needed: PETALSBCSOAP-145).

a chapter should be added into the Petals documentation about the error management and explain the error vs faults,

each MEP should be documented, in a business view, into Petals documentation to defined explicitly where a business fault can occur, and where a technical error can occur in MEP. For example, no business error could be occur with MEP InOnly,

That seems obvious to me, isn't that already defined in all the norms, standard and recommendation of the W3C on the meaning of the different patterns?
Faults can happen when Faults appear in the definition in the pattern…

each component should be review to manage correctly error/fault, mainly binding-components against their external side, so one JIRA issue by component should be added if needed

Show
Victor NOËL added a comment - Tue, 28 Apr 2015 - 09:23:33 +0200
a business error is a JBI fault,
And a business error is a fault declared in a wsdl.
a technical error is a JBI error,
a JBI fault is not a SOAP fault, so a dedicated JIRA issue should be created to change the JBI fault format (from SOAPFault to simple XML payload compliant with the WSDL)
A JBI Fault is a SOAPFault, in SOAP, see http://docs.oracle.com/cd/E24329_01/web.1211/e24965/faults.htm A ticket is already open for the CDK PETALSCDK-130 (and for the BC SOAP so that SOAPFault are created as needed: PETALSBCSOAP-145).
a chapter should be added into the Petals documentation about the error management and explain the error vs faults,
each MEP should be documented, in a business view, into Petals documentation to defined explicitly where a business fault can occur, and where a technical error can occur in MEP. For example, no business error could be occur with MEP InOnly,
That seems obvious to me, isn't that already defined in all the norms, standard and recommendation of the W3C on the meaning of the different patterns? Faults can happen when Faults appear in the definition in the pattern…
each component should be review to manage correctly error/fault, mainly binding-components against their external side, so one JIRA issue by component should be added if needed
Victor NOËL made changes - Tue, 28 Apr 2015 - 12:38:23 +0200
Link This issue depends on PETALSSEJSR-28 [ PETALSSEJSR-28 ]
Victor NOËL made changes - Tue, 28 Apr 2015 - 12:46:16 +0200
Status New [ 10000 ] Open [ 10002 ]
Hide
Permalink
Christophe DENEUX added a comment - Tue, 28 Apr 2015 - 14:27:06 +0200

a business error is a JBI fault,

And a business error is a fault declared in a wsdl.

Yes

a technical error is a JBI error,

a JBI fault is not a SOAP fault, so a dedicated JIRA issue should be created to change the JBI fault format (from SOAPFault to simple XML payload compliant with the WSDL)

A JBI Fault is a SOAPFault, in SOAP, see http://docs.oracle.com/cd/E24329_01/web.1211/e24965/faults.htm

No, a JBI fault is transformed in a SOAPFault by the consumer side of the Petals BC SOAP, and a SOAPFault is transformed in a JBI fault by the provider side of the Petals BC SOAP.

A ticket is already open for the CDK PETALSCDK-130 (and for the BC SOAP so that SOAPFault are created as needed: PETALSBCSOAP-145).

The main goal of PETALSCDK-130 is about technical errors that should not be transformed in fault, but kept as error. We should create another issue to change the content format of JBI fault, from SOAP Fault to a simple XML payload.

a chapter should be added into the Petals documentation about the error management and explain the error vs faults,

each MEP should be documented, in a business view, into Petals documentation to defined explicitly where a business fault can occur, and where a technical error can occur in MEP. For example, no business error could be occur with MEP InOnly,

That seems obvious to me, isn't that already defined in all the norms, standard and recommendation of the W3C on the meaning of the different patterns?

Sure, but our users are not expert in each technology involved in Petals ESB. So we should explain these concepts in the user documentation.

Faults can happen when Faults appear in the definition in the pattern…

Sure.

each component should be review to manage correctly error/fault, mainly binding-components against their external side, so one JIRA issue by component should be added if needed

Show
Christophe DENEUX added a comment - Tue, 28 Apr 2015 - 14:27:06 +0200
a business error is a JBI fault,
And a business error is a fault declared in a wsdl.
Yes
a technical error is a JBI error,
a JBI fault is not a SOAP fault, so a dedicated JIRA issue should be created to change the JBI fault format (from SOAPFault to simple XML payload compliant with the WSDL)
A JBI Fault is a SOAPFault, in SOAP, see http://docs.oracle.com/cd/E24329_01/web.1211/e24965/faults.htm
No, a JBI fault is transformed in a SOAPFault by the consumer side of the Petals BC SOAP, and a SOAPFault is transformed in a JBI fault by the provider side of the Petals BC SOAP.
A ticket is already open for the CDK PETALSCDK-130 (and for the BC SOAP so that SOAPFault are created as needed: PETALSBCSOAP-145).
The main goal of PETALSCDK-130 is about technical errors that should not be transformed in fault, but kept as error. We should create another issue to change the content format of JBI fault, from SOAP Fault to a simple XML payload.
a chapter should be added into the Petals documentation about the error management and explain the error vs faults,
each MEP should be documented, in a business view, into Petals documentation to defined explicitly where a business fault can occur, and where a technical error can occur in MEP. For example, no business error could be occur with MEP InOnly,
That seems obvious to me, isn't that already defined in all the norms, standard and recommendation of the W3C on the meaning of the different patterns?
Sure, but our users are not expert in each technology involved in Petals ESB. So we should explain these concepts in the user documentation.
Faults can happen when Faults appear in the definition in the pattern…
Sure.
each component should be review to manage correctly error/fault, mainly binding-components against their external side, so one JIRA issue by component should be added if needed
Hide
Permalink
Victor NOËL added a comment - Tue, 28 Apr 2015 - 14:39:41 +0200

The main goal of PETALSCDK-130 is about technical errors that should not be transformed in fault, but kept as error. We should create another issue to change the content format of JBI fault, from SOAP Fault to a simple XML payload.

Ok, but we have nothing to do in practice, there is no ticket to create to do any actions: FAULTS are like IN or OUT message, they have to be set on the message by the component or the SU using any mean desired as long as the component or the SU respects the WSDL it is meant to implement!

In the implementation of the MessageExchange, a Fault is simply implemented with a NormalizedMessage (more precisely with the class Fault that extends NormalizedMessage).

There is nothing specific to SOAP in this implementation, only the CDK creates such artificiality, and this should be removed as explained in PETALSCDK-130 (i.e. everything related to SOAPFault and FaultException will just disappear from the CDK and any specific treatment of the errors will too).

Show
Victor NOËL added a comment - Tue, 28 Apr 2015 - 14:39:41 +0200
The main goal of PETALSCDK-130 is about technical errors that should not be transformed in fault, but kept as error. We should create another issue to change the content format of JBI fault, from SOAP Fault to a simple XML payload.
Ok, but we have nothing to do in practice, there is no ticket to create to do any actions: FAULTS are like IN or OUT message, they have to be set on the message by the component or the SU using any mean desired as long as the component or the SU respects the WSDL it is meant to implement! In the implementation of the MessageExchange, a Fault is simply implemented with a NormalizedMessage (more precisely with the class Fault that extends NormalizedMessage). There is nothing specific to SOAP in this implementation, only the CDK creates such artificiality, and this should be removed as explained in PETALSCDK-130 (i.e. everything related to SOAPFault and FaultException will just disappear from the CDK and any specific treatment of the errors will too).
Hide
Permalink
Christophe DENEUX added a comment - Tue, 28 Apr 2015 - 19:01:59 +0200

You're right, faults are like IN or OUT message and they have to be set on the message by the component. But, are you sure that we have nothing to do ? I'm not.
At least, we should remove some source code as SourceUtil.createSoapFaultDocument(..) that is used to set an exception as a Fault in the message exchange. Perhaps, few other changes can occur.

Show
Christophe DENEUX added a comment - Tue, 28 Apr 2015 - 19:01:59 +0200 You're right, faults are like IN or OUT message and they have to be set on the message by the component. But, are you sure that we have nothing to do ? I'm not. At least, we should remove some source code as SourceUtil.createSoapFaultDocument(..) that is used to set an exception as a Fault in the message exchange. Perhaps, few other changes can occur.
Hide
Permalink
Victor NOËL added a comment - Wed, 29 Apr 2015 - 10:16:11 +0200

If you have examples of what specific should be done, I'm curious.

The only specific thing I can see is that depending on the MEP, faults can or cannot be set, but it has always been like that.

Again, the changes you are talking about (such as those in SourceUtil) have to occurs in the CDK and can be discussed in PETALSCDK-130, I don't see how they relate to something else than "removing any Fault/SOAPFault related useless code", which is just a subtask of "not transforming errors to fault".
If you want to create a specific ticket for removing code that will become useless once we stop transforming errors to fault, then feel free to do so

Show
Victor NOËL added a comment - Wed, 29 Apr 2015 - 10:16:11 +0200 If you have examples of what specific should be done, I'm curious. The only specific thing I can see is that depending on the MEP, faults can or cannot be set, but it has always been like that. Again, the changes you are talking about (such as those in SourceUtil) have to occurs in the CDK and can be discussed in PETALSCDK-130, I don't see how they relate to something else than "removing any Fault/SOAPFault related useless code", which is just a subtask of "not transforming errors to fault". If you want to create a specific ticket for removing code that will become useless once we stop transforming errors to fault, then feel free to do so
Christophe DENEUX made changes - Fri, 1 May 2015 - 10:34:07 +0200
Link This issue depends on PETALSCDK-133 [ PETALSCDK-133 ]
Christophe DENEUX made changes - Fri, 1 May 2015 - 10:37:57 +0200
Fix Version/s 5.0.0 [ 10412 ]
Priority Blocker [ 1 ] Major [ 3 ]
Victor NOËL made changes - Thu, 21 May 2015 - 16:47:05 +0200
Status Open [ 10002 ] In Progress [ 10003 ]
Victor NOËL made changes - Thu, 21 May 2015 - 17:13:46 +0200
Link This issue depends on PETALSCDK-134 [ PETALSCDK-134 ]
Victor NOËL made changes - Fri, 22 May 2015 - 13:06:08 +0200
Link This issue depends on PETALSSEACTIVITI-3 [ PETALSSEACTIVITI-3 ]
Victor NOËL made changes - Fri, 22 May 2015 - 16:53:01 +0200
Link This issue depends on PETALSSEPOJO-22 [ PETALSSEPOJO-22 ]
Victor NOËL made changes - Fri, 22 May 2015 - 16:53:14 +0200
Link This issue depends on PETALSSEPOJO-22 [ PETALSSEPOJO-22 ]
Victor NOËL made changes - Fri, 22 May 2015 - 16:53:22 +0200
Link This issue depends on PETALSSEACTIVITI-3 [ PETALSSEACTIVITI-3 ]
Victor NOËL made changes - Fri, 22 May 2015 - 16:53:32 +0200
Link This issue depends on PETALSSEJSR-28 [ PETALSSEJSR-28 ]
Victor NOËL made changes - Fri, 22 May 2015 - 16:53:46 +0200
Link This issue depends on PETALSBCSOAP-145 [ PETALSBCSOAP-145 ]
Victor NOËL made changes - Wed, 15 Jul 2015 - 13:48:02 +0200
Link This issue depends on PETALSBCREST-2 [ PETALSBCREST-2 ]
Victor NOËL made changes - Wed, 15 Jul 2015 - 13:48:14 +0200
Link This issue depends on PETALSSEJSR-30 [ PETALSSEJSR-30 ]
Victor NOËL made changes - Wed, 15 Jul 2015 - 13:48:50 +0200
Link This issue depends on PETALSBCSOAP-145 [ PETALSBCSOAP-145 ]
Christophe DENEUX made changes - Thu, 16 Jul 2015 - 14:38:47 +0200
Link This issue depends on PETALSSEACTIVITI-3 [ PETALSSEACTIVITI-3 ]
Hide
Permalink
Victor NOËL added a comment - Fri, 2 Oct 2015 - 09:13:37 +0200

This is mostly resolved in 5.0.0-M1, there still some fixup to do.

Show
Victor NOËL added a comment - Fri, 2 Oct 2015 - 09:13:37 +0200 This is mostly resolved in 5.0.0-M1, there still some fixup to do.
Victor NOËL made changes - Fri, 2 Oct 2015 - 09:13:37 +0200
Status In Progress [ 10003 ] Resolved [ 10004 ]
Resolution Fixed [ 1 ]
Hide
Permalink
Victor NOËL added a comment - Fri, 2 Oct 2015 - 09:14:00 +0200

Reopen for issues still open in components.

Show
Victor NOËL added a comment - Fri, 2 Oct 2015 - 09:14:00 +0200 Reopen for issues still open in components.
Victor NOËL made changes - Fri, 2 Oct 2015 - 09:14:00 +0200
Status Resolved [ 10004 ] Open [ 10002 ]
Resolution Fixed [ 1 ]
Component/s Components [ 10270 ]
Victor NOËL made changes - Tue, 9 Feb 2016 - 11:56:29 +0100
Link This issue depends on PETALSBCSOAP-164 [ PETALSBCSOAP-164 ]
Victor NOËL made changes - Wed, 14 Sep 2016 - 10:22:23 +0200
Fix Version/s 5.0.0-M1 [ 10412 ]
Christophe DENEUX made changes - Wed, 28 Dec 2016 - 10:08:14 +0100
Link This issue depends on PETALSBCREST-6 [ PETALSBCREST-6 ]
Transition Status Change Time Execution Times Last Executer Last Execution Date
New New Open Open
3d 21h 44m
1
Victor NOËL
Tue, 28 Apr 2015 - 12:46:16 +0200
Open Open In Progress In Progress
23d 4h
1
Victor NOËL
Thu, 21 May 2015 - 16:47:05 +0200
In Progress In Progress Resolved Resolved
133d 16h 26m
1
Victor NOËL
Fri, 2 Oct 2015 - 09:13:37 +0200
Resolved Resolved Open Open
23s
1
Victor NOËL
Fri, 2 Oct 2015 - 09:14:00 +0200

People

Dates

  • Created:
    Fri, 24 Apr 2015 - 15:02:00 +0200
    Updated:
    Wed, 28 Dec 2016 - 10:08:14 +0100
Atlassian JIRA (v4.1.2#531) | Report a problem | Request a feature | Contact administrators
Powered by a free Atlassian JIRA open source license for Petals ESB. Try JIRA - bug tracking software for your team.