You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Joe San <co...@gmail.com> on 2012/08/15 14:53:18 UTC

enrich and pollEnrich

Camel Riders,

I fail to fathom the fact that enrich works with a Producer EndPoint and
pollEnrich works with a Consumer EndPoint. Is there a design consideration
behind this mechanism? Can anyone please clarify why a pollEnrich should be
used with a Consumer EndPoint and not with a Producer EndPoint? Has it got
something to do with the Message type (request only or request / response)?

Regards,
Jothi

Re: enrich and pollEnrich

Posted by Joe San <co...@gmail.com>.
Claus. I plead that you listen to this. Camel in Action is an awesome
resource. I would request you to make it even more awesome by detailing a
bit more on the core concepts.

Regards,
Jothi

On Wed, Aug 15, 2012 at 4:49 PM, Vincent Nonnenmacher <
vincent.nonnenmacher@gmail.com> wrote:

> I concur to this, the notions aren't very clear at the beginning on an
> otherwise very well written book.
>
> A phrase like this "The TO .. is "always" a producer.." along with very
> clear schemas could help a lot,
> because somehow its counter intuitive, until the light come up latter by
> practicing.
>
> It could then be easier to introduce the EIP pattern along that.
>
>
>
> On Wed, Aug 15, 2012 at 4:08 PM, Joe San <co...@gmail.com> wrote:
>
> > Yes. Your statement....
> >
> > "The TO in the Camel routes is *always* a producer, eg you produce a
> > message to an endpoint.
> > In the http endpoint you would then do a request/reply to the http
> > service. So the message after the TO will
> > contain the response from the http service, and whatever the message
> > was before would be discarded."
> >
> > ....made sense. You don't need a stronger Coffee. You might probably need
> > to consider expanding your Chapter 1 in "Camel in Action" book with such
> > explanations.
> >
> > Regards,
> > Jothi
> >
> >
> >
> > On Wed, Aug 15, 2012 at 4:02 PM, Claus Ibsen <cl...@gmail.com>
> > wrote:
> >
> > > On Wed, Aug 15, 2012 at 3:32 PM, Joe San <co...@gmail.com>
> > wrote:
> > > > Thanks for the explanation.
> > > >
> > > > From your example in the Camel in Action book in Chapter 3:
> > > >
> > > > from("quartz://report?cron=0+0+6+*+*+?")
> > > > .to("http://riders.com/orders/cmd=received&date=yesterday")
> > > > .process(new OrderToCsvProcessor())
> > > > .to("file://riders/orders?fileName=report-${header.Date}.csv");
> > > >
> > > > Your statement "Where as a http component may only support the
> > > producer". I
> > > > would understand the above route as follows
> > > >
> > > > From the quartz Producer to http Consumer, process and send to file
> > > > Consumer. Is it interpreted this way? or the role of a component
> > > (Producer
> > > > or Consumer) depends on the component type?
> > > >
> > >
> > > The TO in the Camel routes is *always* a producer, eg you produce a
> > > message to an endpoint.
> > > In the http endpoint you would then do a request/reply to the http
> > > service. So the message after the TO will
> > > contain the response from the http service, and whatever the message
> > > was before would be discarded.
> > >
> > > eg the TO follows the pipes and filters pattern (aka pipeline in Camel)
> > > http://camel.apache.org/pipes-and-filters.html
> > >
> > >
> > > If you use the content enricher then you can "enrich" instead, so you
> > > have the before and after message.
> > > And then use the AggregationStrategy to do your logic how to
> > > enrich/merge the messages together, whatever you want.
> > > http://camel.apache.org/content-enricher.html
> > >
> > >
> > > Now the example you refer to from the book, we dont use the content
> > > enricher EIP per see, as we dont really need to enrich the message. As
> > > the message from the quartz endpoint will be an empty message. So we
> > > can just use the pipes and filters EIP.
> > >
> > >
> > > Does my rambling make a bit of sense?
> > > Maybe I need a stronger coffee to explain it better.
> > >
> > >
> > > > Regards,
> > > > Jothi
> > > >
> > > > On Wed, Aug 15, 2012 at 3:00 PM, Claus Ibsen <cl...@gmail.com>
> > > wrote:
> > > >
> > > >> On Wed, Aug 15, 2012 at 2:53 PM, Joe San <co...@gmail.com>
> > > wrote:
> > > >> > Camel Riders,
> > > >> >
> > > >> > I fail to fathom the fact that enrich works with a Producer
> EndPoint
> > > and
> > > >> > pollEnrich works with a Consumer EndPoint. Is there a design
> > > >> consideration
> > > >> > behind this mechanism? Can anyone please clarify why a pollEnrich
> > > should
> > > >> be
> > > >> > used with a Consumer EndPoint and not with a Producer EndPoint?
> Has
> > it
> > > >> got
> > > >> > something to do with the Message type (request only or request /
> > > >> response)?
> > > >> >
> > > >>
> > > >> Yes some components support both producers and consumers, and behave
> > > >> differently.
> > > >> For example file/ftp components. The producer will write a file, and
> > > >> the consumer read a file.
> > > >>
> > > >> Where as a http component may only support the producer, etc.
> > > >>
> > > >>
> > > >>
> > > >> > Regards,
> > > >> > Jothi
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Claus Ibsen
> > > >> -----------------
> > > >> FuseSource
> > > >> Email: cibsen@fusesource.com
> > > >> Web: http://fusesource.com
> > > >> Twitter: davsclaus, fusenews
> > > >> Blog: http://davsclaus.com
> > > >> Author of Camel in Action: http://www.manning.com/ibsen
> > > >>
> > >
> > >
> > >
> > > --
> > > Claus Ibsen
> > > -----------------
> > > FuseSource
> > > Email: cibsen@fusesource.com
> > > Web: http://fusesource.com
> > > Twitter: davsclaus, fusenews
> > > Blog: http://davsclaus.com
> > > Author of Camel in Action: http://www.manning.com/ibsen
> > >
> >
>

Re: enrich and pollEnrich

Posted by Vincent Nonnenmacher <vi...@gmail.com>.
I concur to this, the notions aren't very clear at the beginning on an
otherwise very well written book.

A phrase like this "The TO .. is "always" a producer.." along with very
clear schemas could help a lot,
because somehow its counter intuitive, until the light come up latter by
practicing.

It could then be easier to introduce the EIP pattern along that.



On Wed, Aug 15, 2012 at 4:08 PM, Joe San <co...@gmail.com> wrote:

> Yes. Your statement....
>
> "The TO in the Camel routes is *always* a producer, eg you produce a
> message to an endpoint.
> In the http endpoint you would then do a request/reply to the http
> service. So the message after the TO will
> contain the response from the http service, and whatever the message
> was before would be discarded."
>
> ....made sense. You don't need a stronger Coffee. You might probably need
> to consider expanding your Chapter 1 in "Camel in Action" book with such
> explanations.
>
> Regards,
> Jothi
>
>
>
> On Wed, Aug 15, 2012 at 4:02 PM, Claus Ibsen <cl...@gmail.com>
> wrote:
>
> > On Wed, Aug 15, 2012 at 3:32 PM, Joe San <co...@gmail.com>
> wrote:
> > > Thanks for the explanation.
> > >
> > > From your example in the Camel in Action book in Chapter 3:
> > >
> > > from("quartz://report?cron=0+0+6+*+*+?")
> > > .to("http://riders.com/orders/cmd=received&date=yesterday")
> > > .process(new OrderToCsvProcessor())
> > > .to("file://riders/orders?fileName=report-${header.Date}.csv");
> > >
> > > Your statement "Where as a http component may only support the
> > producer". I
> > > would understand the above route as follows
> > >
> > > From the quartz Producer to http Consumer, process and send to file
> > > Consumer. Is it interpreted this way? or the role of a component
> > (Producer
> > > or Consumer) depends on the component type?
> > >
> >
> > The TO in the Camel routes is *always* a producer, eg you produce a
> > message to an endpoint.
> > In the http endpoint you would then do a request/reply to the http
> > service. So the message after the TO will
> > contain the response from the http service, and whatever the message
> > was before would be discarded.
> >
> > eg the TO follows the pipes and filters pattern (aka pipeline in Camel)
> > http://camel.apache.org/pipes-and-filters.html
> >
> >
> > If you use the content enricher then you can "enrich" instead, so you
> > have the before and after message.
> > And then use the AggregationStrategy to do your logic how to
> > enrich/merge the messages together, whatever you want.
> > http://camel.apache.org/content-enricher.html
> >
> >
> > Now the example you refer to from the book, we dont use the content
> > enricher EIP per see, as we dont really need to enrich the message. As
> > the message from the quartz endpoint will be an empty message. So we
> > can just use the pipes and filters EIP.
> >
> >
> > Does my rambling make a bit of sense?
> > Maybe I need a stronger coffee to explain it better.
> >
> >
> > > Regards,
> > > Jothi
> > >
> > > On Wed, Aug 15, 2012 at 3:00 PM, Claus Ibsen <cl...@gmail.com>
> > wrote:
> > >
> > >> On Wed, Aug 15, 2012 at 2:53 PM, Joe San <co...@gmail.com>
> > wrote:
> > >> > Camel Riders,
> > >> >
> > >> > I fail to fathom the fact that enrich works with a Producer EndPoint
> > and
> > >> > pollEnrich works with a Consumer EndPoint. Is there a design
> > >> consideration
> > >> > behind this mechanism? Can anyone please clarify why a pollEnrich
> > should
> > >> be
> > >> > used with a Consumer EndPoint and not with a Producer EndPoint? Has
> it
> > >> got
> > >> > something to do with the Message type (request only or request /
> > >> response)?
> > >> >
> > >>
> > >> Yes some components support both producers and consumers, and behave
> > >> differently.
> > >> For example file/ftp components. The producer will write a file, and
> > >> the consumer read a file.
> > >>
> > >> Where as a http component may only support the producer, etc.
> > >>
> > >>
> > >>
> > >> > Regards,
> > >> > Jothi
> > >>
> > >>
> > >>
> > >> --
> > >> Claus Ibsen
> > >> -----------------
> > >> FuseSource
> > >> Email: cibsen@fusesource.com
> > >> Web: http://fusesource.com
> > >> Twitter: davsclaus, fusenews
> > >> Blog: http://davsclaus.com
> > >> Author of Camel in Action: http://www.manning.com/ibsen
> > >>
> >
> >
> >
> > --
> > Claus Ibsen
> > -----------------
> > FuseSource
> > Email: cibsen@fusesource.com
> > Web: http://fusesource.com
> > Twitter: davsclaus, fusenews
> > Blog: http://davsclaus.com
> > Author of Camel in Action: http://www.manning.com/ibsen
> >
>

Re: enrich and pollEnrich

Posted by Joe San <co...@gmail.com>.
Yes. Your statement....

"The TO in the Camel routes is *always* a producer, eg you produce a
message to an endpoint.
In the http endpoint you would then do a request/reply to the http
service. So the message after the TO will
contain the response from the http service, and whatever the message
was before would be discarded."

....made sense. You don't need a stronger Coffee. You might probably need
to consider expanding your Chapter 1 in "Camel in Action" book with such
explanations.

Regards,
Jothi



On Wed, Aug 15, 2012 at 4:02 PM, Claus Ibsen <cl...@gmail.com> wrote:

> On Wed, Aug 15, 2012 at 3:32 PM, Joe San <co...@gmail.com> wrote:
> > Thanks for the explanation.
> >
> > From your example in the Camel in Action book in Chapter 3:
> >
> > from("quartz://report?cron=0+0+6+*+*+?")
> > .to("http://riders.com/orders/cmd=received&date=yesterday")
> > .process(new OrderToCsvProcessor())
> > .to("file://riders/orders?fileName=report-${header.Date}.csv");
> >
> > Your statement "Where as a http component may only support the
> producer". I
> > would understand the above route as follows
> >
> > From the quartz Producer to http Consumer, process and send to file
> > Consumer. Is it interpreted this way? or the role of a component
> (Producer
> > or Consumer) depends on the component type?
> >
>
> The TO in the Camel routes is *always* a producer, eg you produce a
> message to an endpoint.
> In the http endpoint you would then do a request/reply to the http
> service. So the message after the TO will
> contain the response from the http service, and whatever the message
> was before would be discarded.
>
> eg the TO follows the pipes and filters pattern (aka pipeline in Camel)
> http://camel.apache.org/pipes-and-filters.html
>
>
> If you use the content enricher then you can "enrich" instead, so you
> have the before and after message.
> And then use the AggregationStrategy to do your logic how to
> enrich/merge the messages together, whatever you want.
> http://camel.apache.org/content-enricher.html
>
>
> Now the example you refer to from the book, we dont use the content
> enricher EIP per see, as we dont really need to enrich the message. As
> the message from the quartz endpoint will be an empty message. So we
> can just use the pipes and filters EIP.
>
>
> Does my rambling make a bit of sense?
> Maybe I need a stronger coffee to explain it better.
>
>
> > Regards,
> > Jothi
> >
> > On Wed, Aug 15, 2012 at 3:00 PM, Claus Ibsen <cl...@gmail.com>
> wrote:
> >
> >> On Wed, Aug 15, 2012 at 2:53 PM, Joe San <co...@gmail.com>
> wrote:
> >> > Camel Riders,
> >> >
> >> > I fail to fathom the fact that enrich works with a Producer EndPoint
> and
> >> > pollEnrich works with a Consumer EndPoint. Is there a design
> >> consideration
> >> > behind this mechanism? Can anyone please clarify why a pollEnrich
> should
> >> be
> >> > used with a Consumer EndPoint and not with a Producer EndPoint? Has it
> >> got
> >> > something to do with the Message type (request only or request /
> >> response)?
> >> >
> >>
> >> Yes some components support both producers and consumers, and behave
> >> differently.
> >> For example file/ftp components. The producer will write a file, and
> >> the consumer read a file.
> >>
> >> Where as a http component may only support the producer, etc.
> >>
> >>
> >>
> >> > Regards,
> >> > Jothi
> >>
> >>
> >>
> >> --
> >> Claus Ibsen
> >> -----------------
> >> FuseSource
> >> Email: cibsen@fusesource.com
> >> Web: http://fusesource.com
> >> Twitter: davsclaus, fusenews
> >> Blog: http://davsclaus.com
> >> Author of Camel in Action: http://www.manning.com/ibsen
> >>
>
>
>
> --
> Claus Ibsen
> -----------------
> FuseSource
> Email: cibsen@fusesource.com
> Web: http://fusesource.com
> Twitter: davsclaus, fusenews
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
>

Re: enrich and pollEnrich

Posted by Claus Ibsen <cl...@gmail.com>.
On Wed, Aug 15, 2012 at 3:32 PM, Joe San <co...@gmail.com> wrote:
> Thanks for the explanation.
>
> From your example in the Camel in Action book in Chapter 3:
>
> from("quartz://report?cron=0+0+6+*+*+?")
> .to("http://riders.com/orders/cmd=received&date=yesterday")
> .process(new OrderToCsvProcessor())
> .to("file://riders/orders?fileName=report-${header.Date}.csv");
>
> Your statement "Where as a http component may only support the producer". I
> would understand the above route as follows
>
> From the quartz Producer to http Consumer, process and send to file
> Consumer. Is it interpreted this way? or the role of a component (Producer
> or Consumer) depends on the component type?
>

The TO in the Camel routes is *always* a producer, eg you produce a
message to an endpoint.
In the http endpoint you would then do a request/reply to the http
service. So the message after the TO will
contain the response from the http service, and whatever the message
was before would be discarded.

eg the TO follows the pipes and filters pattern (aka pipeline in Camel)
http://camel.apache.org/pipes-and-filters.html


If you use the content enricher then you can "enrich" instead, so you
have the before and after message.
And then use the AggregationStrategy to do your logic how to
enrich/merge the messages together, whatever you want.
http://camel.apache.org/content-enricher.html


Now the example you refer to from the book, we dont use the content
enricher EIP per see, as we dont really need to enrich the message. As
the message from the quartz endpoint will be an empty message. So we
can just use the pipes and filters EIP.


Does my rambling make a bit of sense?
Maybe I need a stronger coffee to explain it better.


> Regards,
> Jothi
>
> On Wed, Aug 15, 2012 at 3:00 PM, Claus Ibsen <cl...@gmail.com> wrote:
>
>> On Wed, Aug 15, 2012 at 2:53 PM, Joe San <co...@gmail.com> wrote:
>> > Camel Riders,
>> >
>> > I fail to fathom the fact that enrich works with a Producer EndPoint and
>> > pollEnrich works with a Consumer EndPoint. Is there a design
>> consideration
>> > behind this mechanism? Can anyone please clarify why a pollEnrich should
>> be
>> > used with a Consumer EndPoint and not with a Producer EndPoint? Has it
>> got
>> > something to do with the Message type (request only or request /
>> response)?
>> >
>>
>> Yes some components support both producers and consumers, and behave
>> differently.
>> For example file/ftp components. The producer will write a file, and
>> the consumer read a file.
>>
>> Where as a http component may only support the producer, etc.
>>
>>
>>
>> > Regards,
>> > Jothi
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> FuseSource
>> Email: cibsen@fusesource.com
>> Web: http://fusesource.com
>> Twitter: davsclaus, fusenews
>> Blog: http://davsclaus.com
>> Author of Camel in Action: http://www.manning.com/ibsen
>>



-- 
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen

Re: enrich and pollEnrich

Posted by Joe San <co...@gmail.com>.
Thanks for the explanation.

>From your example in the Camel in Action book in Chapter 3:

from("quartz://report?cron=0+0+6+*+*+?")
.to("http://riders.com/orders/cmd=received&date=yesterday")
.process(new OrderToCsvProcessor())
.to("file://riders/orders?fileName=report-${header.Date}.csv");

Your statement "Where as a http component may only support the producer". I
would understand the above route as follows

>From the quartz Producer to http Consumer, process and send to file
Consumer. Is it interpreted this way? or the role of a component (Producer
or Consumer) depends on the component type?

Regards,
Jothi

On Wed, Aug 15, 2012 at 3:00 PM, Claus Ibsen <cl...@gmail.com> wrote:

> On Wed, Aug 15, 2012 at 2:53 PM, Joe San <co...@gmail.com> wrote:
> > Camel Riders,
> >
> > I fail to fathom the fact that enrich works with a Producer EndPoint and
> > pollEnrich works with a Consumer EndPoint. Is there a design
> consideration
> > behind this mechanism? Can anyone please clarify why a pollEnrich should
> be
> > used with a Consumer EndPoint and not with a Producer EndPoint? Has it
> got
> > something to do with the Message type (request only or request /
> response)?
> >
>
> Yes some components support both producers and consumers, and behave
> differently.
> For example file/ftp components. The producer will write a file, and
> the consumer read a file.
>
> Where as a http component may only support the producer, etc.
>
>
>
> > Regards,
> > Jothi
>
>
>
> --
> Claus Ibsen
> -----------------
> FuseSource
> Email: cibsen@fusesource.com
> Web: http://fusesource.com
> Twitter: davsclaus, fusenews
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
>

Re: enrich and pollEnrich

Posted by Claus Ibsen <cl...@gmail.com>.
On Wed, Aug 15, 2012 at 2:53 PM, Joe San <co...@gmail.com> wrote:
> Camel Riders,
>
> I fail to fathom the fact that enrich works with a Producer EndPoint and
> pollEnrich works with a Consumer EndPoint. Is there a design consideration
> behind this mechanism? Can anyone please clarify why a pollEnrich should be
> used with a Consumer EndPoint and not with a Producer EndPoint? Has it got
> something to do with the Message type (request only or request / response)?
>

Yes some components support both producers and consumers, and behave
differently.
For example file/ftp components. The producer will write a file, and
the consumer read a file.

Where as a http component may only support the producer, etc.



> Regards,
> Jothi



-- 
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen