Aaron, thanks for your input! Comments inline.
Cheers,
Hadrian
On Jan 30, 2008, at 10:55 AM, Aaron Crickenberger wrote:
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,
I don't think it's a major effort either. For the most part Camel
*does* things right.
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
