API-Question: MessageContext.isFaultResponse()

["Hubert, Eric" <er...@jamba.net>]

Hi all,

before asking a question regarding the existing API, I'd like to mention the targeted use case (requirement):
Detect/count application level faults passed from the service over Synapse to the client independent of the application level protocol (e.g. SOAP/Hessian) used on top of the transport protocol.

While looking for a solution I stumbled over MessageContext.isFaultResponse()
The name was promising... ;-)
From looking at the Java-Doc I honestly was not sure about the purpose of this operation. So I had a very quick look at the current usage.

The corresponding setter is called within the FaultMediator (but there only within makePOXFault(); not within makeSOAPFault()). Is this intended? Anyway it looks like this message context flag is only used if Synapse has created its own fault - not if the application passes back a fault. Is this observation correct? I'm fine with this - I just would like to better understand the existing logic.

Internal faults within Synapse (exceptions) are stored within a generic property map within each message context. E.g. using the keys SynapseConstants.ERROR_CODE, SynapseConstants.ERROR_MESSAGE, SynapseConstants.ERROR_DETAIL, SynapseConstants.ERROR_EXCEPTION I'm able to get details about those internal faults.

So far as I can see there is currently no convenient way to detect application faults as they are not centrally stored. In fact they depend on the application level protocol used and one has to analyze the message to find this out.
So for a SOAP message I have to write code like this:

final SOAPFault fault = axis2MessageCtx.getEnvelope().getBody().getFault();
SOAPFaultCode faultcode = fault.getCode();
SOAPFaultReason faultmessage = fault.getReason();
//...

In order to detect errors for other protocols, like the binary Hessian protocol, things get even more complicated. At mediation time, I'm rather late to detect those, as I would need access to the binary stream. 

How to best tackle/support such cases? I guess I'm looking for a mechanism to intercept the message building process. 
If each application protocol specific (or actually depending on some magic Axis2 logic rather content type specific) message builder were able to detect a fault message and set a custom property in the message context, later at mediation time it would be possible to always ask for the same property (independent of the protocol). Problem: How to do this without rewriting each Builder and registering own MessageBuilders? 

Any other (better) ideas? Totally wrong approach? Please just don't blame the requirement! ;-) I know that it sounds strange to count faults send from the applications in an infrastructure component... 

Further it is a requirement to differentiate between faults coming from the service and self generated faults (e.g. we don't find a matching destination and create a fault from the default case of a switch mediator). The custom mediator analyzing the message send out does not know whether it came from the client or was generated using the FaultMediator or can I check this? 


Regards,
   Eric

RE: API-Question: MessageContext.isFaultResponse()

["Hubert, Eric" <er...@jamba.net>]

Hi Asankha,

thanks for your detailed and very helpful reply. Please find my comments
inline!

> MessageContext.isFaultResponse()
> This seems like a left over and unused/unwanted API method that we
need
> to clean up.. I would consider a cleanup along with the move of the
core
> API's into a separate package as proposed by you, so that users will
> only use the "public" API. This would also help us maintain backwards
> compatibility at least in future, over methods in the public API.
With "separate package" I suppose technically you are associating a
separate Maven artefact (JAR-File), right?
Yes, this way we can encourage people extending Synapse to only use the
public API and save them from "unknown" compatibility issues. If the
users decide to use any internal API then this at least gets obvious to
them and they recognize that they are on a (wrong/dangerous) road and
should ask on the dev list about changing their approach or letting
change the public API. ;-)

> > In order to detect errors for other protocols, like the binary
Hessian
> protocol, things get even more complicated. At mediation time, I'm
rather
> late to detect those, as I would need access to the binary stream.
> For example SOAP 1.1/1.2 and REST over http/s should use HTTP 500 for
> error responses. I guess Hessian should too, and most other protocols
Your guess regarding the Hessian protocol is unfortunately wrong.
Hessian does not differentiate between "normal" and "erroneous"
responses via an HTTP status code. Faults are also send as HTTP 200 and
Synapse currently violates the Hessian protocol spec in this regard.

> Hessian - this would not be possible with the current implementation,
> although we could surely write a "smart" hessian builder, that can
just
> read the first few bytes of the binary message and detect this :-) !
Yes, this was exactly what I wanted to do. But I don't want to end up
with our own version of an "improved" Hessian message builder/formatter
pair. So I would suggest we implement those needed changes and submit a
patch. I will also take a look at the HTTP response code handling as
this is currently not correct for Hessian faults (also for the self
generated ones via the makeFault-mediator).

> I think your idea and approach is correct and good..
Ok, with this statement it makes sense for me to proceed. I just did not
want to "run" in the wrong direction.

Regards,
   Eric

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org

Re: API-Question: MessageContext.isFaultResponse()

["Asankha C. Perera" <as...@wso2.com>]

Hi Eric
> before asking a question regarding the existing API, I'd like to mention the targeted use case (requirement):
> Detect/count application level faults passed from the service over Synapse to the client independent of the application level protocol (e.g. SOAP/Hessian) used on top of the transport protocol.
>   
This is a valid requirement indeed, and an important one.
> While looking for a solution I stumbled over MessageContext.isFaultResponse()
> The name was promising... ;-)
> From looking at the Java-Doc I honestly was not sure about the purpose of this operation. So I had a very quick look at the current usage.
>
> The corresponding setter is called within the FaultMediator (but there only within makePOXFault(); not within makeSOAPFault()). Is this intended? Anyway it looks like this message context flag is only used if Synapse has created its own fault - not if the application passes back a fault. Is this observation correct? I'm fine with this - I just would like to better understand the existing logic.
>   
This seems like a left over and unused/unwanted API method that we need 
to clean up.. I would consider a cleanup along with the move of the core 
API's into a separate package as proposed by you, so that users will 
only use the "public" API. This would also help us maintain backwards 
compatibility at least in future, over methods in the public API.
> Internal faults within Synapse (exceptions) are stored within a generic property map within each message context. E.g. using the keys SynapseConstants.ERROR_CODE, SynapseConstants.ERROR_MESSAGE, SynapseConstants.ERROR_DETAIL, SynapseConstants.ERROR_EXCEPTION I'm able to get details about those internal faults.
>
> So far as I can see there is currently no convenient way to detect application faults as they are not centrally stored. In fact they depend on the application level protocol used and one has to analyze the message to find this out.
> So for a SOAP message I have to write code like this:
>
> final SOAPFault fault = axis2MessageCtx.getEnvelope().getBody().getFault();
> SOAPFaultCode faultcode = fault.getCode();
> SOAPFaultReason faultmessage = fault.getReason();
> //...
>
> In order to detect errors for other protocols, like the binary Hessian protocol, things get even more complicated. At mediation time, I'm rather late to detect those, as I would need access to the binary stream.
For example SOAP 1.1/1.2 and REST over http/s should use HTTP 500 for 
error responses. I guess Hessian should too, and most other protocosls 
over http/s - but maybe not all. So at the transport level, we could set 
a "hint" property to a request or response received, if the transport 
suspects the message is a fault request/response. This could be valid 
for some other transports like some messaging systems, FIX, AMQP etc (I 
am guessing wildly!), where the brokers mark messages as faults..

However, even with SOAP there could be say asynchronous responses when 
WS-Addressing is used etc, where a fault response could come as a 
request - without any hints at the transport level. So in this case, the 
message builders could come in, and state what they think.. However, for 
Hessian - this would not be possible with the current implementation, 
although we could surely write a "smart" hessian builder, that can just 
read the first few bytes of the binary message and detect this :-) !
> How to best tackle/support such cases? I guess I'm looking for a mechanism to intercept the message building process. 
> If each application protocol specific (or actually depending on some magic Axis2 logic rather content type specific) message builder were able to detect a fault message and set a custom property in the message context, later at mediation time it would be possible to always ask for the same property (independent of the protocol). Problem: How to do this without rewriting each Builder and registering own MessageBuilders? 
>
> Any other (better) ideas? Totally wrong approach? Please just don't blame the requirement! ;-) I know that it sounds strange to count faults send from the applications in an infrastructure component...
I think your idea and approach is correct and good..
> Further it is a requirement to differentiate between faults coming from the service and self generated faults (e.g. we don't find a matching destination and create a fault from the default case of a switch mediator). The custom mediator analyzing the message send out does not know whether it came from the client or was generated using the FaultMediator or can I check this?
Again, the message builder could have placed the hint that the original 
incoming message was a fault, and thus you should be able to use that to 
properly determine what next steps to take

asankha

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org