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+s465427n566932...@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.
