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 <codeintheo...@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 <claus.ib...@gmail.com>
> wrote:
>
> > On Wed, Aug 15, 2012 at 3:32 PM, Joe San <codeintheo...@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 <claus.ib...@gmail.com>
> > wrote:
> > >
> > >> On Wed, Aug 15, 2012 at 2:53 PM, Joe San <codeintheo...@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: cib...@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: cib...@fusesource.com
> > Web: http://fusesource.com
> > Twitter: davsclaus, fusenews
> > Blog: http://davsclaus.com
> > Author of Camel in Action: http://www.manning.com/ibsen
> >
>
