camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hadrian Zbarcea <hzbar...@gmail.com>
Subject Re: Camel Exchange Patters
Date Fri, 24 Sep 2010 13:09:48 GMT
Let me try to clarify this a bit, because there are 2 or 3 things mixed up in this thread.

Because "Working on IN is just much easier to explain and use for end users" doesn't necessarily
mean that that is what you should do. And the "use" part is debatable anyway.
Every node on the route is a Processor. A route is nothing else but a chain (when executed,
tree when constructed) of specialized Processors. An Exchange, that contains an in, out and
exception moves along the Processor chain and sends the out of the previous Processor (if
any) as in for the next Processor. If the previous Processor did not produce an out, than
the previous in is used.

The MEP refers to 2 things, depending on the context. From outside the route, the question
is should the camel route return a response or not? Which means: is the MEP in or in-out?
Depending on the component the answer to this question is pretty clear, rarely we have to
setExchangePattern explicitly. Now from the Processor perspective, should a Processor return
a response or not? Or, in translation, is the Processor in or in-out. That's totally up to
the developer of the processor, she knows what the MEP should be for the processor. There
is almost no correlation between the route mep and processor mep, in the sense that you can
have in-only processors in an in-out route and vice-versa.

As an example, you can have your jms endpoint set up as a consumer (in the from() that starts
the route) and that could be in-only or in-out btw, but on the route you could use a log processor,
that does not create an out, just logs the in, leaving it unchanged, or you can call on a
choice processor, that again does not alter the in, just evaluates expression to make decisions
down the road, or you can call on a web-service (via camel-cxf) that may produce an out, that
will replace the in on the Exchange when moving to the next processor.

I think this should clarify things, but I can take it further if needed.

Cheers,
Hadrian

On Sep 24, 2010, at 8:46 AM, Claus Ibsen wrote:

> On Fri, Sep 24, 2010 at 2:44 PM,  <patrice.godard@orange-ftgroup.com> wrote:
>> Hello,
>> I'm not sure I understand why I shouldn't be using getOut().
>> Here is what I do at the end of my processor (that is transforming the message Body):
>> 
>> // propagate headers
>> ex.getOut().setHeaders(ex.getIn().getHeaders());
>> 
>> Am I wrong?
> 
> No not really because you take matter in your own hand and propagate
> the headers.
> But the Camel routing engine will automatic handle using IN if there
> is no OUT message.
> 
> Working on IN is just much easier to explain and use for end users.
> And there is less message creation, copying headers, and whatnot if
> you dont use OUT messages.
> 
> 
>> 
>> I saw a couple of Processor samples that were only dealing with getIn() but I don't
quite understand how and when the "in" message becomes an "out" message and I noticed that
if I was propagating my headers by copying them from the "in" message to the "out" one I was
no longer losing them.
>> 
>> I'm looking forward to the latest MEAP version of Camel In Action since it seems
I got it wrong somewhere.
>> 
>>> -----Message d'origine-----
>>> De : bengt.rodehav@gmail.com [mailto:bengt.rodehav@gmail.com] De la
>>> part de Bengt Rodehav
>>> Envoyé : vendredi 24 septembre 2010 12:47
>>> À : users@camel.apache.org
>>> Objet : Re: Camel Exchange Patters
>>> 
>>> Perfect!
>>> 
>>> /Bengt
>>> 
>>> 2010/9/24 Claus Ibsen <claus.ibsen@gmail.com>
>>> 
>>>> On Fri, Sep 24, 2010 at 10:27 AM, Claus Ibsen <claus.ibsen@gmail.com>
>>>> wrote:
>>>>> On Tue, Sep 14, 2010 at 2:29 PM, Bengt Rodehav <bengt@rodehav.com>
>>>> wrote:
>>>>>> Yeah I remember reading about the problems with losing message
>>> headers
>>>>>> somewhere on this list...
>>>>>> 
>>>>>> To be perfectly honest I think that the number of mails on this
>>> thread
>>>>>> indicates the importance of documenting these rules and how things
>>> work.
>>>>>> Claus, you are most definitely the man to do it. I've got your
>>> book
>>>> (haven't
>>>>>> read the last updates though) and it certainly warrants a place
>>> there.
>>>>>> Perhaps it should also be on the wiki somewhere.
>>>>>> 
>>>>> 
>>>>> We have added information about this in Camel in action,
>>>>> chapter 3 when we drill down and work the Processor which exposes
>>> the
>>>>> Exchange API.
>>>>> 
>>>> 
>>>> I also added a couple of FAQs as well, such as
>>>> 
>>>> 
>>> https://cwiki.apache.org/confluence/display/CAMEL/Using+getIn+or+getOut
>>> +methods+on+Exchange
>>>> 
>>>>> 
>>>>>> /Bengt
>>>>>> 
>>>>>> 2010/9/14 Claus Ibsen <claus.ibsen@gmail.com>
>>>>>> 
>>>>>>> On Tue, Sep 14, 2010 at 2:16 PM, Bengt Rodehav <bengt@rodehav.com>
>>>> wrote:
>>>>>>>> I think that was very useful information. I hadn't thought
of a
>>>> Processor
>>>>>>> as
>>>>>>>> very low level - it's definitely a level that a lot of us
will
>>> use.
>>>> Then
>>>>>>> I
>>>>>>>> guess that in some circumstances (like when coding a custom
>>>> processor)
>>>>>>> you
>>>>>>>> need to set the out messsage if the MEP is "out capable"
>>> otherwise
>>>> you
>>>>>>> just
>>>>>>>> set the in message. Are there more situations where this
is
>>> needed?
>>>>>>>> 
>>>>>>> 
>>>>>>> If the MEP is out capable you can still just change the IN
>>> message.
>>>>>>> If the OUT is null, then Camel will re-use the IN (which you
just
>>>>>>> changed) and thus still route whatever you have changed.
>>>>>>> 
>>>>>>> You only need to use OUT if you want to create a totally 100%
new
>>>>>>> message which is not related to the IN message at all.
>>>>>>> And this is only needed in special cases.
>>>>>>> 
>>>>>>> Otherwise you get the problem with: Why do I lose my message
>>> headers
>>>> etc.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> I think that this subject is definitely complicated enough
to
>>> warrant
>>>> a
>>>>>>> good
>>>>>>>> documentation somewhere. I think it's really important for
>>> developers
>>>> to
>>>>>>>> understand core concepts instead of just using boilerplate
>>> samples
>>>>>>> (although
>>>>>>>> they are very useful).
>>>>>>>> 
>>>>>>>> /Bengt
>>>>>>>> 
>>>>>>>> 2010/9/14 Claus Ibsen <claus.ibsen@gmail.com>
>>>>>>>> 
>>>>>>>>> On Tue, Sep 14, 2010 at 10:23 AM, Christian Müller
>>>>>>>>> <christian.mueller@gmail.com> wrote:
>>>>>>>>>> Hello Claus!
>>>>>>>>>> 
>>>>>>>>>> That's not (in my opinion) how it works currently.
At
>>> present I
>>>> work
>>>>>>> on a
>>>>>>>>>> route which looks like this:
>>>>>>>>>> 
>>>>>>>>>> errorHandler(
>>>>>>>>>>  defaultErrorHandler()
>>>>>>>>>>    .retryAttemptedLogLevel(LoggingLevel.DEBUG)
>>>>>>>>>>    .retriesExhaustedLogLevel(LoggingLevel.INFO));
>>>>>>>>>> 
>>>>>>>>>> onException(IllegalArgumentException.class)
>>>>>>>>>>  .handled(true)
>>>>>>>>>>  .maximumRedeliveries(0)
>>>>>>>>>>  .beanRef("myResultProvider", "failureResponse");
>>>>>>>>>> 
>>>>>>>>>> from("cxf:bean:MyCoolService")
>>>>>>>>>>  .processRef("myValidator") // validates conditional
rules
>>>>>>>>>>  .inOut("direct:mySubroute")
>>>>>>>>>>  .beanRef("myResultProvider", "successResponse")
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> If my validator throws a IllegalArgumentException
and the
>>> result
>>>>>>> provider
>>>>>>>>>> writes the response into the in message, the web
service
>>> will
>>>> return
>>>>>>>>> null.
>>>>>>>>>> But if I write the response into the out message,
the web
>>> service
>>>> will
>>>>>>>>>> return it. So, I changes my bean to the following
"pattern":
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Well that could CXF Bean component having a bug.
>>>>>>>>> 
>>>>>>>>> If you decide to use a Processor and work on Exchange
then you
>>> use
>>>> the
>>>>>>>>> low level Camel API and then you have to handle the IN/OUT
>>> stuff
>>>>>>>>> yourself.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> if (exchange.getPattern().isOutCapable()) {
>>>>>>>>>>  exchange.getOut().setBody(response);
>>>>>>>>>> } else {
>>>>>>>>>>  exchange.getIn().setBody(response);
>>>>>>>>>> }
>>>>>>>>>> 
>>>>>>>>>> And that's the same how the
>>>>>>>>> org.apache.camel.processor.ConvertBodyProcessor
>>>>>>>>>> works (I know you know this, but for the other guys..
:o) )
>>>>>>>>>> 
>>>>>>>>>> public class ConvertBodyProcessor implements Processor
{
>>>>>>>>>> ...
>>>>>>>>>>    public void process(Exchange exchange) throws
Exception {
>>>>>>>>>>        Message in = exchange.getIn();
>>>>>>>>>>        if (charset != null) {
>>>>>>>>>>            exchange.setProperty(Exchange.CHARSET_NAME,
>>> charset);
>>>>>>>>>>        }
>>>>>>>>>>        Object value = in.getMandatoryBody(type);
>>>>>>>>>> 
>>>>>>>>>>        if (exchange.getPattern().isOutCapable())
{
>>>>>>>>>>            Message out = exchange.getOut();
>>>>>>>>>>            out.copyFrom(in);
>>>>>>>>>>            out.setBody(value);
>>>>>>>>>>        } else {
>>>>>>>>>>            in.setBody(value);
>>>>>>>>>>        }
>>>>>>>>>>    }
>>>>>>>>>> ...
>>>>>>>>>> }
>>>>>>>>>> 
>>>>>>>>>> Should our custom processors/beans/.. not work in
the same
>>> way?
>>>>>>>>>> 
>>>>>>>>>> Cheers,
>>>>>>>>>> Christian
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> Claus Ibsen
>>>>>>>>> Apache Camel Committer
>>>>>>>>> 
>>>>>>>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>>>>>>>> Open Source Integration: http://fusesource.com
>>>>>>>>> Blog: http://davsclaus.blogspot.com/
>>>>>>>>> Twitter: http://twitter.com/davsclaus
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> Claus Ibsen
>>>>>>> Apache Camel Committer
>>>>>>> 
>>>>>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>>>>>> Open Source Integration: http://fusesource.com
>>>>>>> Blog: http://davsclaus.blogspot.com/
>>>>>>> Twitter: http://twitter.com/davsclaus
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Claus Ibsen
>>>>> Apache Camel Committer
>>>>> 
>>>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>>>> Open Source Integration: http://fusesource.com
>>>>> Blog: http://davsclaus.blogspot.com/
>>>>> Twitter: http://twitter.com/davsclaus
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Claus Ibsen
>>>> Apache Camel Committer
>>>> 
>>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>>> Open Source Integration: http://fusesource.com
>>>> Blog: http://davsclaus.blogspot.com/
>>>> Twitter: http://twitter.com/davsclaus
>>>> 
>> 
>> *********************************
>> This message and any attachments (the "message") are confidential and intended solely
for the addressees.
>> Any unauthorised use or dissemination is prohibited.
>> Messages are susceptible to alteration.
>> France Telecom Group shall not be liable for the message if altered, changed or falsified.
>> If you are not the intended addressee of this message, please cancel it immediately
and inform the sender.
>> ********************************
>> 
>> 
> 
> 
> 
> -- 
> Claus Ibsen
> Apache Camel Committer
> 
> Author of Camel in Action: http://www.manning.com/ibsen/
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus


Mime
View raw message