I think you pose excellent questions. Being quite a newbie on Camel (but
already hooked), I've looked at a lot of examples as a recipe to solve my
tasks. However, I really lack a more thorough description of how the
Exchange (and the in and out messages) are handled when walking through a
route. Is the In message passed to the next processor or is it the out
message and when should I change what?
I would really recommend to add a chapter (or a few paragraphs) to Camel in
Action explaining how the messages change when the pass from processor to
processor in a route. The description needs to address the supported MEP's
and provide guidelines for developing processors and type converters.
It would be nice to gain a little more theoretical understanding in this
subject instead of only practical solutions to problems at hand. Maybe this
is documented somewhere already? A link would then be much appreciated.
/Bengt
2010/9/11 Christian Müller <christian.muel...@gmail.com>
> Hello list!
>
> I read Claus, Jonathan and Hadrians book Camel in Action and I studied the
> Camel site [1]. I also hat a short conversation with Ade from Progress
> about
> the exchange pattern, but still I have the feeling I doesn't understand all
> aspects. May be you can help me to understand it correct. Here are my
> questions:
> - In the book and the Camel site only the exchange patterns InOut and
> InOnly
> are mentioned but org.apache.camel.ExchangePattern defines the following
> exchange patterns: InOnly, RobustInOnly, InOut, InOptionalOut, OutOnly,
> RobustOutOnly, OutIn, OutOptionalIn. Should we only use InOut and InOnly?
> - If I understood Ade correct, after each processing on a
> component/processor the message goes throught the pipieline before it
> receives the next component/processor. In the case of an InOut exchange,
> the
> pipeline will copy the out message body, headers and attachments into the
> in
> message. So that in the next component/processor can access these data from
> the in message again. If I use the InOnly exchange pattern, the
> component/processor will write the response into the in message and the
> pipeline has nothing to copy. From the end user perspective it looks like
> it
> doesn't matter, whether to use the InOnly or InOut exchange pattern.
> - The only one component I know which handle InOnly and InOut "really"
> defferently is the jms-component. It will only send a reply message if the
> exchange pattern InOut is used.
> - If I use a InOnly exchange for the following routes, I takes also more
> than 5 seconds until my templeate.send() method returns. I would expect
> that
> the call returns after the exchange was placed into the next sub route
> (after a few milliseconds). My key point here is not to improve the
> performance. Only to understand the exchange pattern correct, how the work
> and how they are used in the right way...
>
> from("direct:start")
>
> .to("direct:sub");
>
>
>
> from("direct:sub")
>
> .process(*new* Processor() {
>
> @Override
>
> *public* *void* process(Exchange exchange) *
> throws* Exception {
>
> Thread.*sleep*(5000);
>
> }
>
> })
> .to("mock:result");
>
>
> - Do you have recommendations when to use InOnly and InOut?
> - If we write our own processor which modifies the in message, should they
> write the modified body into the out message, if the exchnage is out
> capable
> (and also copy all header and attachments we need for further processing)?
> Or should we always modify the in message because it requires less action?
> - The same question for our own type converters. I know the type converter
> is implemented in this way, that it will return the new (converted) object.
> But our type converters also have to modify the message header. Should they
> also check whether the exchange is out capable and than modify the out (if
> out capable) or in (if not out capable) message? Is this the way camel
> handels the converted object from the type converter?
>
> [1] http://camel.apache.org/exchange-pattern.html
>
> Thanks in advance for your help and taking time for my questions,
> Christian
>
