On Jan 30, 2008, at 5:21 AM, Roman Kalukiewicz wrote:
WSDL describes formats of in/out/fault messages, because they are
different (formats).
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.
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.
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).
Allow me to comment as a bit of an outsider here, as I haven't been
too involved with the parts of Camel that actually use the out/fault
messages, nor the exception handling capabilities.
As I understand it the whole reason Exchange exists is to model the
correlation between the in/out/fault messages, not their format.
Maybe the abstraction is too leaky to hide, but I thought that's what
Camel was trying to do. If you remove the distinction from Camel's
API, it then becomes the responsibility of the players involved in the
to keep track of the correlation. That, to me anyway, sounds like it
makes life more difficult for users of Camel, or at the least, anyone
implementing a Camel component.
As Hadrian said, I think a number of your concerns can be address by
revisiting Pipeline and a few of the core routing mechanisms. The in/
out/fault distinction may not be clear or consistent throughout Camel,
and rmaking it so is not a simple task, but I think to get rid of it
entirely is throwing out the baby with the bathwater, so to speak.
For example, as you point out, the in/out distinction is clunky to
processors that only want to modify a message or pass it along. The
convention or shortcut that's come about for these cases is merely
modifying/using the In message, and having Pipeline forward it along.
Perhaps some benefit could come from further utilizing
ExchangePattern, or generating better default wrappers from the DSL.
- aaron
