2008/1/30, Hadrian Zbarcea <[EMAIL PROTECTED]>:
> Hi Roman,
>
> Interesting points. From what I gather there are two questions you
> raise:
> 1. Is the distinction between in/out/fault/exception necessary
> 2. Is the DSL clear or at least intuitive enough
>
> On the second point, I think there are a few places that require a bit
> of a revisit.
That is definitely true now and I believe further discussion here is
not really necessary ;)
What I'm trying to point out is, that lot of those problem disappear
if we remove this distinction between in/out/fault.
> On the first point, my personal take is that the distinction is
> important and should be there. There are influences from the WSDL
> spec(s) and I think there is a reason for that.
This is exactly my impression - that we have this distinction because
it is present in specs like WSDL or JBI. Let me try to stick with WSDL
as I believe JBI suffers from the same issue that Camel does (I
think).
WSDL describes formats of in/out/fault messages, because they are
different (formats). In Camel, our payload is Object. Moreover when
you send lets say SOAP, you have 1 message at a time. This out/fault
distinction works like a flag (what I propose) that specifies which
format should be consulted. We cannot receive out AND fault AND have
an access to in message at the same time (we can store in message in a
variable, but it is not the protocol).
> Inputs are sort of read-only from the point of view of the next
> processor in the pipeline.
That is not definitely true, as in majority of cases we agree to
modify in message, and propagate it. BTW it is very handy as if you
want your headers to be propagated you simply cannot fill out message
in DSL.
> Outputs provide a response after
> successful processing. Faults are responses that indicate to the
> client that the expected goal was not achieved, and they usually
> provide a reason. Faults are messages that tell a client that the
> server did receive the request and successfully processed it, but not
> in the way intended and the client may need to take further action.
> Exceptions on the other hand indicate that the message was not
> processed successfully, and the client should not make any
> assumptions. The way the semantics of the result (output/fault/
> exception) is sent back to the client is dependent on the component.
This is what WebServices world does. But what bothers me here is that
we don't have the server always. This distinction you describe is not
really clear and could be confusing.
Lets look at http component. When we receive status code == 500 it
should be fault according to your description. It is not - it is out
message and we have http.responseCode set (I already found it very
handy BTW).
In validation component when validation fails we should have fault -
validation performed and the outcome is that the payload was bad. Now
it is exception.
Another problem is that we don't have any way in camel to handle
faults. My proposal is to have some sensible way of marking faults
(via header maybe), and maybe some way of defining what is fault for
you. This way you can interrupt your flow.
I can imagine something like this:
//this could be the default fault/exception definition
faultIs(or(isInstanceOf(Exception.class), header("isFault").isNotNull()));
//construct similar to exception(), but handles all different faults
fault(isInstanceOf(Exception.class)).to("jms:exceptionOccured");
fault().xpath("/myBody/error").to("jms:someErrorOccured");
This way it is YOU who define when you want your flow to be
interrupted. I can imagine that we can treat like a fault the fact
that your mail endpoint received a mail with 'no such address' string.
This goes even further - to merge faults and exceptions together. But
what is wrong with sending an exception as a body? In RPC SOAP fault
IS java exception anyway.
By belief is that such approach is simpler and more universal than
what we currently have. It is also how I can imagine some fault
handling in camel (that simply doesn't exist so far).
Roman
