You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by ext2 <xu...@tongtech.com> on 2010/10/14 07:54:19 UTC
Re: TransformerProcessor doesn't deal with MEP( Why we need InOnly?)
Thanks a lot;
Yes, you are right ;if output is present , it always means result, no matter
what the MEP is;
But this confused my understanding about the exchange pattern;Why we need
the InOnly pattern? Only for performance reason?
If we has no such many patterns, event we didn't define the MEP for camel,
And we just determine the result by the out message exist or not. Things
will be more simply for the end-user;
If the performance is the only reason to introduce the InOnly pattern? If
so, it's not worth.
==========================================================================
Hadrian Zbarcea wrote:
>Then there's something wrong with the aggregator, I'd say.
>The result of processing is always: out if present, otherwise in. Makes
sense?
>I hope this helps,
>Hadrian
>On Oct 14, 2010, at 12:43 AM, ext2 wrote:
> I still feel it's a bug; let's give a sample as following:
>
> <from uri="direct:start">
> <multicast ref="some-aggregate">
> <transform A/>
> <bean B/>
> <bean C/>
> <multicast>
>
> While writing the aggregator, how does I know where the result stored, in
or
> out message? I can only determine it by exchange pattern;
> If the route is using InOnly pattern(which is default), the aggregator
will
> aggregate In message of Exchange. But the transform will always return out
> message as result, so the aggregate result isn't correct;
>
> ==============================================================
> Does this [1] explain it?
> Hadrian
>
> [1] http://camelbot.blogspot.com/2010/10/should-you-getin-or-getout.html
>
>
> On Oct 13, 2010, at 11:51 PM, ext2 wrote:
>
>> The Transformer Processor always set Out Message as result and doesn't
>> care what MEP being;(At least until version camel 2.4.0, it being so,
> 2.5.0
>> I haven't checked)
>>
>> It seems doesn't confirm to the rules of camel's MEP, why?
>>
>>
>
>
>
Re: TransformerProcessor doesn't deal with MEP( Why we need InOnly?)
Posted by Hadrian Zbarcea <hz...@gmail.com>.
The MEP is very important from outside camel. It tells camel if the producer (client) who send the request is waiting for a response or not. Thus it allows consumers to know what to do, but it is (almost) not relevant on the route itself. It looks like I should have clarified this better.
Cheers,
Hadrian
On Oct 14, 2010, at 1:54 AM, ext2 wrote:
> Thanks a lot;
> Yes, you are right ;if output is present , it always means result, no matter
> what the MEP is;
> But this confused my understanding about the exchange pattern;Why we need
> the InOnly pattern? Only for performance reason?
>
> If we has no such many patterns, event we didn't define the MEP for camel,
> And we just determine the result by the out message exist or not. Things
> will be more simply for the end-user;
>
> If the performance is the only reason to introduce the InOnly pattern? If
> so, it's not worth.
>
> ==========================================================================
> Hadrian Zbarcea wrote:
>> Then there's something wrong with the aggregator, I'd say.
>> The result of processing is always: out if present, otherwise in. Makes
> sense?
>
>> I hope this helps,
>> Hadrian
>
>
>> On Oct 14, 2010, at 12:43 AM, ext2 wrote:
>
>> I still feel it's a bug; let's give a sample as following:
>>
>> <from uri="direct:start">
>> <multicast ref="some-aggregate">
>> <transform A/>
>> <bean B/>
>> <bean C/>
>> <multicast>
>>
>> While writing the aggregator, how does I know where the result stored, in
> or
>> out message? I can only determine it by exchange pattern;
>> If the route is using InOnly pattern(which is default), the aggregator
> will
>> aggregate In message of Exchange. But the transform will always return out
>> message as result, so the aggregate result isn't correct;
>>
>> ==============================================================
>> Does this [1] explain it?
>> Hadrian
>>
>> [1] http://camelbot.blogspot.com/2010/10/should-you-getin-or-getout.html
>>
>>
>> On Oct 13, 2010, at 11:51 PM, ext2 wrote:
>>
>>> The Transformer Processor always set Out Message as result and doesn't
>>> care what MEP being;(At least until version camel 2.4.0, it being so,
>> 2.5.0
>>> I haven't checked)
>>>
>>> It seems doesn't confirm to the rules of camel's MEP, why?
>>>
>>>
>>
>>
>>
>
>
>
Re: TransformerProcessor doesn't deal with MEP( Why we need InOnly?)
Posted by Willem Jiang <wi...@gmail.com>.
Hi,
Please see my comments in the mail.
On 10/14/10 1:54 PM, ext2 wrote:
> Thanks a lot;
> Yes, you are right ;if output is present , it always means result, no matter
> what the MEP is;
> But this confused my understanding about the exchange pattern;Why we need
> the InOnly pattern? Only for performance reason?
No, it's related to the component or the transport we use.
Normally, for the Http transport it always has a request/response
message, for the JMS we could use fire and forget InOnly MEP by default.
>
> If we has no such many patterns, event we didn't define the MEP for camel,
> And we just determine the result by the out message exist or not. Things
> will be more simply for the end-user;
Camel just want to be more smart to get the message, but if you know
this principle you will feel easy to understand.
>
> If the performance is the only reason to introduce the InOnly pattern? If
> so, it's not worth.
I don't think so.
The MEP is based on the WSLD model which is used heavenly on ServiceMix.
If you take a look at the ExchangePattern[1], you will see them.
In most case, we just use InOnly and InOut these two patterns.
>
> ==========================================================================
> Hadrian Zbarcea wrote:
>> Then there's something wrong with the aggregator, I'd say.
>> The result of processing is always: out if present, otherwise in. Makes
> sense?
>
>> I hope this helps,
>> Hadrian
>
>
>> On Oct 14, 2010, at 12:43 AM, ext2 wrote:
>
>> I still feel it's a bug; let's give a sample as following:
>>
>> <from uri="direct:start">
>> <multicast ref="some-aggregate">
>> <transform A/>
>> <bean B/>
>> <bean C/>
>> <multicast>
>>
>> While writing the aggregator, how does I know where the result stored, in
> or
>> out message? I can only determine it by exchange pattern;
>> If the route is using InOnly pattern(which is default), the aggregator
> will
>> aggregate In message of Exchange. But the transform will always return out
>> message as result, so the aggregate result isn't correct;
>>
>> ==============================================================
>> Does this [1] explain it?
>> Hadrian
>>
>> [1] http://camelbot.blogspot.com/2010/10/should-you-getin-or-getout.html
>>
>>
>> On Oct 13, 2010, at 11:51 PM, ext2 wrote:
>>
>>> The Transformer Processor always set Out Message as result and doesn't
>>> care what MEP being;(At least until version camel 2.4.0, it being so,
>> 2.5.0
>>> I haven't checked)
>>>
>>> It seems doesn't confirm to the rules of camel's MEP, why?
>>>
>>>
>>
>>
>>
>
>
>
>
--
Willem
----------------------------------
Open Source Integration: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: http://twitter.com/willemjiang