You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Reynald <re...@weiner.com.br> on 2012/04/25 17:11:33 UTC
Newbie question: Topology for Camel: Servlet -> Quartz -> JMS
Hi all,
I'm reading through all the documentation of Camel. I'm really excited but
due to the extent of the docs and my lack of experience on it, I'd
appreciate if somebody give some guidelines on the following scenario. I
want to keep things as simple as possible :)
- I have to have a decoupled server running Camel;
- systems will access the Camel server through Webservices - I cannot have
Camel clients or use RMI;
- I think on creating webservices to handle the demand as in the
camel-example-servlet-tomcat
- have routes that based on the servlet "from" will schedule a calendar Job
on Quartz (these are dynamic jobs - which are scheduled and unscheduled
several times, per client - we need to pass specific JobDataMap as well)
- Quartz will trigger a JMS call when its time
- systems will consume the messages and start the jobs
Any thoughts and guidance where should I focus on my learning ?
How can I chain the message from servlet -> quartz -> activemq ? (any
samples)
tks
PS. We could do this without Camel of course. But Quartz is only the tip of
the iceberg and our first integration...
--
View this message in context: http://camel.465427.n5.nabble.com/Newbie-question-Topology-for-Camel-Servlet-Quartz-JMS-tp5665134p5665134.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Newbie question: Topology for Camel: Servlet -> Quartz -> JMS
Posted by Claus Ibsen <cl...@gmail.com>.
On Fri, Apr 27, 2012 at 3:32 PM, Reynald <re...@weiner.com.br> wrote:
> Hi Claus,
>
> Thanks for the promptness!
>
>> So you decouple a servlet request by submitting a job to a quartz
>> scheduler. The scheduler will trigger the job
>> sometime in the future, and the job is to send a message to a queue?
>> Why do you want to do that?
>
> We want to integrate our calendar/processes with external jobs. It means
> that events are created dynamically by systems so they are not
> pre-defined in Quartz. Events can have calendar complex rules like "First
> monday of every 2 months". Ex: on our supply chain some product have
> different purchase rules that we want to automate. These purchase can be
> made using these calendar rules.
>
> The idea is to have Camel as the "middleware" managing the dynamical
> scheduled tasks and dispatching the jobs.
>
> Since we have several different jobs (in different languages besides Java)
> we cannot execute all them in this "middleware" server/cluster.
> One idea is to put the job request in a queue for some service to consume
> it (we could use a webservice call but we are analysing yet).
>
>> And what should the client calling the servlet do in the mean time?
>> Should the servlet just send back a OK message after
>> it has submitted a job to the scheduler?
>
> This client is a legacy/process system and the creation of the scheduler is
> part of a larger workflow. Since these recurrent tasks
> will be executed in the future, an "OK" returned from the servlet is
> acceptable. Errors in the job execution will be treated separately.
>
>> And what happens after the message has been send to the jms queue?
>
> After the message goes to its queue, there are polling services that will
> consume them and execute the task (or as I said we might use a webservice
> call).
>
> We are still designing the new architecture which involves legacy systems
> and systems developed in other languages than Java. There are several
> points we are analyzing but the basic idea for the scheduled part is what I
> described.
>
> tks
>
> PS. We run a test and Quartz is not a "to: " endpoint for a route. If we
> have to programatically include the schedules in Quartz, does it make sense
> to still think about using Camel ?
>
Not as much no. You need to store a persistent quartz job with some
details from the message,
and when it should trigger etc.
Then when the quartz job is triggered, you can send a message to JMS
using the Camel ProducerTemplate API.
That said, we have a JIRA ticket about an idea to send a message to a
quartz endpoint. That would
then schedule a job for the future with the current message to be
routed. But its not implemented AFAIR.
> On Fri, Apr 27, 2012 at 3:07 AM, Claus Ibsen-2 [via Camel] <
> ml-node+s465427n5669326h1@n5.nabble.com> wrote:
>
>> Hi
>>
>>
>> On Wed, Apr 25, 2012 at 5:11 PM, Reynald <[hidden email]<http://user/SendEmail.jtp?type=node&node=5669326&i=0>>
>> wrote:
>>
>> > Hi all,
>> >
>> > I'm reading through all the documentation of Camel. I'm really excited
>> but
>> > due to the extent of the docs and my lack of experience on it, I'd
>> > appreciate if somebody give some guidelines on the following scenario. I
>> > want to keep things as simple as possible :)
>> >
>> > - I have to have a decoupled server running Camel;
>> > - systems will access the Camel server through Webservices - I cannot
>> have
>> > Camel clients or use RMI;
>> > - I think on creating webservices to handle the demand as in the
>> > camel-example-servlet-tomcat
>> > - have routes that based on the servlet "from" will schedule a calendar
>> Job
>> > on Quartz (these are dynamic jobs - which are scheduled and unscheduled
>> > several times, per client - we need to pass specific JobDataMap as well)
>> > - Quartz will trigger a JMS call when its time
>> > - systems will consume the messages and start the jobs
>> >
>> > Any thoughts and guidance where should I focus on my learning ?
>> >
>> > How can I chain the message from servlet -> quartz -> activemq ? (any
>> > samples)
>> >
>>
>> So you decouple a servlet request by submitting a job to a quartz
>> scheduler. The scheduler will trigger the job
>> sometime in the future, and the job is to send a message to a queue?
>> Why do you want to do that?
>> And what should the client calling the servlet do in the mean time?
>> Should the servlet just send back a OK message after
>> it has submitted a job to the scheduler?
>>
>> And what happens after the message has been send to the jms queue?
>>
>>
>> > tks
>> >
>> > PS. We could do this without Camel of course. But Quartz is only the tip
>> of
>> > the iceberg and our first integration...
>> >
>> > --
>> > View this message in context:
>> http://camel.465427.n5.nabble.com/Newbie-question-Topology-for-Camel-Servlet-Quartz-JMS-tp5665134p5665134.html
>> > Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com
>> FuseSource
>> Email: [hidden email]<http://user/SendEmail.jtp?type=node&node=5669326&i=1>
>> Web: http://fusesource.com
>> Twitter: davsclaus, fusenews
>> Blog: http://davsclaus.blogspot.com/
>> Author of Camel in Action: http://www.manning.com/ibsen/
>>
>>
>> ------------------------------
>> If you reply to this email, your message will be added to the discussion
>> below:
>>
>> http://camel.465427.n5.nabble.com/Newbie-question-Topology-for-Camel-Servlet-Quartz-JMS-tp5665134p5669326.html
>> To unsubscribe from Newbie question: Topology for Camel: Servlet ->
>> Quartz -> JMS, click here<http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5665134&code=cmVuYXRvQHdlaW5lci5jb20uYnJ8NTY2NTEzNHwyOTAwMzk0MDg=>
>> .
>> NAML<http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Newbie-question-Topology-for-Camel-Servlet-Quartz-JMS-tp5665134p5670302.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
--
Claus Ibsen
-----------------
CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: Newbie question: Topology for Camel: Servlet -> Quartz -> JMS
Posted by Reynald <re...@weiner.com.br>.
Hi Claus,
Thanks for the promptness!
> So you decouple a servlet request by submitting a job to a quartz
> scheduler. The scheduler will trigger the job
> sometime in the future, and the job is to send a message to a queue?
> Why do you want to do that?
We want to integrate our calendar/processes with external jobs. It means
that events are created dynamically by systems so they are not
pre-defined in Quartz. Events can have calendar complex rules like "First
monday of every 2 months". Ex: on our supply chain some product have
different purchase rules that we want to automate. These purchase can be
made using these calendar rules.
The idea is to have Camel as the "middleware" managing the dynamical
scheduled tasks and dispatching the jobs.
Since we have several different jobs (in different languages besides Java)
we cannot execute all them in this "middleware" server/cluster.
One idea is to put the job request in a queue for some service to consume
it (we could use a webservice call but we are analysing yet).
> And what should the client calling the servlet do in the mean time?
> Should the servlet just send back a OK message after
> it has submitted a job to the scheduler?
This client is a legacy/process system and the creation of the scheduler is
part of a larger workflow. Since these recurrent tasks
will be executed in the future, an "OK" returned from the servlet is
acceptable. Errors in the job execution will be treated separately.
> And what happens after the message has been send to the jms queue?
After the message goes to its queue, there are polling services that will
consume them and execute the task (or as I said we might use a webservice
call).
We are still designing the new architecture which involves legacy systems
and systems developed in other languages than Java. There are several
points we are analyzing but the basic idea for the scheduled part is what I
described.
tks
PS. We run a test and Quartz is not a "to: " endpoint for a route. If we
have to programatically include the schedules in Quartz, does it make sense
to still think about using Camel ?
On Fri, Apr 27, 2012 at 3:07 AM, Claus Ibsen-2 [via Camel] <
ml-node+s465427n5669326h1@n5.nabble.com> wrote:
> Hi
>
>
> On Wed, Apr 25, 2012 at 5:11 PM, Reynald <[hidden email]<http://user/SendEmail.jtp?type=node&node=5669326&i=0>>
> wrote:
>
> > Hi all,
> >
> > I'm reading through all the documentation of Camel. I'm really excited
> but
> > due to the extent of the docs and my lack of experience on it, I'd
> > appreciate if somebody give some guidelines on the following scenario. I
> > want to keep things as simple as possible :)
> >
> > - I have to have a decoupled server running Camel;
> > - systems will access the Camel server through Webservices - I cannot
> have
> > Camel clients or use RMI;
> > - I think on creating webservices to handle the demand as in the
> > camel-example-servlet-tomcat
> > - have routes that based on the servlet "from" will schedule a calendar
> Job
> > on Quartz (these are dynamic jobs - which are scheduled and unscheduled
> > several times, per client - we need to pass specific JobDataMap as well)
> > - Quartz will trigger a JMS call when its time
> > - systems will consume the messages and start the jobs
> >
> > Any thoughts and guidance where should I focus on my learning ?
> >
> > How can I chain the message from servlet -> quartz -> activemq ? (any
> > samples)
> >
>
> So you decouple a servlet request by submitting a job to a quartz
> scheduler. The scheduler will trigger the job
> sometime in the future, and the job is to send a message to a queue?
> Why do you want to do that?
> And what should the client calling the servlet do in the mean time?
> Should the servlet just send back a OK message after
> it has submitted a job to the scheduler?
>
> And what happens after the message has been send to the jms queue?
>
>
> > tks
> >
> > PS. We could do this without Camel of course. But Quartz is only the tip
> of
> > the iceberg and our first integration...
> >
> > --
> > View this message in context:
> http://camel.465427.n5.nabble.com/Newbie-question-Topology-for-Camel-Servlet-Quartz-JMS-tp5665134p5665134.html
> > Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
>
> --
> Claus Ibsen
> -----------------
> CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com
> FuseSource
> Email: [hidden email]<http://user/SendEmail.jtp?type=node&node=5669326&i=1>
> Web: http://fusesource.com
> Twitter: davsclaus, fusenews
> Blog: http://davsclaus.blogspot.com/
> Author of Camel in Action: http://www.manning.com/ibsen/
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://camel.465427.n5.nabble.com/Newbie-question-Topology-for-Camel-Servlet-Quartz-JMS-tp5665134p5669326.html
> To unsubscribe from Newbie question: Topology for Camel: Servlet ->
> Quartz -> JMS, click here<http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5665134&code=cmVuYXRvQHdlaW5lci5jb20uYnJ8NTY2NTEzNHwyOTAwMzk0MDg=>
> .
> NAML<http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
--
View this message in context: http://camel.465427.n5.nabble.com/Newbie-question-Topology-for-Camel-Servlet-Quartz-JMS-tp5665134p5670302.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Newbie question: Topology for Camel: Servlet -> Quartz -> JMS
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
On Wed, Apr 25, 2012 at 5:11 PM, Reynald <re...@weiner.com.br> wrote:
> Hi all,
>
> I'm reading through all the documentation of Camel. I'm really excited but
> due to the extent of the docs and my lack of experience on it, I'd
> appreciate if somebody give some guidelines on the following scenario. I
> want to keep things as simple as possible :)
>
> - I have to have a decoupled server running Camel;
> - systems will access the Camel server through Webservices - I cannot have
> Camel clients or use RMI;
> - I think on creating webservices to handle the demand as in the
> camel-example-servlet-tomcat
> - have routes that based on the servlet "from" will schedule a calendar Job
> on Quartz (these are dynamic jobs - which are scheduled and unscheduled
> several times, per client - we need to pass specific JobDataMap as well)
> - Quartz will trigger a JMS call when its time
> - systems will consume the messages and start the jobs
>
> Any thoughts and guidance where should I focus on my learning ?
>
> How can I chain the message from servlet -> quartz -> activemq ? (any
> samples)
>
So you decouple a servlet request by submitting a job to a quartz
scheduler. The scheduler will trigger the job
sometime in the future, and the job is to send a message to a queue?
Why do you want to do that?
And what should the client calling the servlet do in the mean time?
Should the servlet just send back a OK message after
it has submitted a job to the scheduler?
And what happens after the message has been send to the jms queue?
> tks
>
> PS. We could do this without Camel of course. But Quartz is only the tip of
> the iceberg and our first integration...
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Newbie-question-Topology-for-Camel-Servlet-Quartz-JMS-tp5665134p5665134.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
--
Claus Ibsen
-----------------
CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/