Menu
▾
▴
springframework-developer
|
From: Kopylenko, D. <dko...@ac...> - 2003-11-03 14:10:16
|
+1 for a light-weight solution
Regards,
Dmitriy.
-----Original Message-----
From: Trevor Cook [mailto:pr...@se...]
Sent: Monday, November 03, 2003 9:05 AM
To: spr...@li...
Subject: RE: [Springframework-developer] Scheduler update #2
Thanks Ivan. I've taken a quick look at the manual, and it looks pretty
good. I think Rod covered all the things necessary for Spring, so assuming
those are met, I'd vote to have the simple scheduler (yours) inside Spring
("out-of-the-box"), with a Quartz wrapper available.
I'll dig a little deeper today and compare it to what might be needed for
Quartz (since that's what I use, and what everyone seems to be asking for).
However, a really light-weight option like yours is definately good for
Spring.
Trevor
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf Of
Ivan Ristic
Sent: November 3, 2003 6:59 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Scheduler update #2
> I don't think Spring should attempt to include a full-featured
> scheduler.
I agree with that, except that I wouldn't consider this scheduler to
be full-featured :) Chronos is an attempt at a small library to
satisfy the needs of most people so that they don't have to go out
and learn more complex libraries.
If you don't think that it should be a part of Spring I have no
problem with that.
> However, there is an argument for including a convenient, readily
available,
> implementation of a scheduler abstraction. This gives the user the
benefits
> of pluggability in good Spring fashion.
We'll see whether someone will come forward. Or, we may attempt to
contact the Quartz people and seek their help/opinion.
--
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program. Does
SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program. Does
SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: <jue...@we...> - 2003-11-03 19:58:50
|
Ivan,=20 I'm delighted to see the progress of your scheduler. A nice coincidence = is that I'm currently working on a J2EE integration project for a major = existing job scheduler myself (as I've already announced in September). = We should try to align our efforts, I guess -- particularly in terms of = the job programming model. With the scheduler that I'm addressing, the actual scheduling happens on = a central server. The server notifies executors on all kinds of = platforms for individual job execution requests, collecting execution = reports afterwards. This concept aims at central control of all kinds of = enterprise systems with unified means. I'm involved in the design of an = executor for J2EE platforms. This is obviously different to the programmatic job scheduling that = Chronos, Quartz, and Flux are targeted at: The latter is ideal for = embedding into applications, using the scheduler as library. This is of = course a very valid approach; basically a sophisticated replacement of = java.util.Timer. In my view, the ideal job programming model should be reusable across = both kinds of schedulers. This shouldn't be too hard to do, but the = requirements are different in certain respects. For example, embedded = schedulers hardly need to collect execution reports in a central manner = but rather rely on the job implementations to perform proper logging. -----=20 A further major difference is that embedded schedulers run within their = parent application and just need to execute jobs in that process. OTOH, = a J2EE executor for a central job scheduler needs to be able to dispatch = job execution requests to multiple J2EE applications within a server or = even cluster. My current design idea involves a central executor in the J2EE server, = implemented as JCA 1.5 resource adapter that starts up with the server = and listens for job execution requests coming in via a network port. = This connector then dispatches messages to JMS queues, using one such = queue per application, and listens for execution reports coming in via a = response queue, again one per app. Each scheduler-aware J2EE application needs to have a JMS listener = attachted to its queue, being able to parse and execute incoming job = execution requests. Ideally, that listener should not be specific per = scheduling system but rather a generic component that interprets a = generic message format for job execution requests. I haven't been able to come up with a non-intrusive mechanism to execute = jobs in a specific J2EE application. After all, the application needs to = have some kind of "door" that the executor can use to dispatch job = execution requests to it. Using JMS queues per application seems to be = the most natural approach; including a generic JMS listener is probably = as non-intrusive as it gets. Such a JMS queue can also provide for automatic distribution of job = execution requests across a cluster, via distributed destinations. = Execution reports would come back via corresponding response queues. = That should work reliably in a cluster, shouldn't it? Has anyone = experience with such load balancing via JMS, particularly if execution = reports are required? An alternative approach would be to expose a special executor web = service in each application, sending job execution requests to it and = periodically polling it for execution reports. Remote EJBs don't seem to = be a good fit, as the C-based central scheduling server would have to = use IIOP to talk to them. -----=20 Finally, regarding job scheduling abstraction in Spring. The problem = that I see is that job models differ widely between current schedulers: - At the core, Chronos schedules Runnables, while Quartz requires jobs = to implement its Job interface with an execute(JobExecutionContext) = method. Alternatively, Chronos offers ExecWrapper to specify an = execution method to invoke plus arguments. - Chronos schedules job instances, or alternatively job commands with a = new instance per execution via the ExecWrapper. Quartz always creates = new instances for each execution, following the command pattern. - Chronos expects its jobs to be either preconfigured instances or to = not need any configuration besides the arguments of the method to = invoke. Quartz jobs have access to a Map of configuration parameters via = the JobExecutionContext's JobDataMap. I tend to prefer the command pattern, with bean-style parameters instead = of a JobDataMap, and an execute method without parameters. All this = metadata can easily be applied dynamically, not requiring a job to = implement any specific interface. Such a bean-style task definition can = easily be implemented as a Runnable itself, similar to the current = ExecWrapper but more powerful in terms of parametrization. So I envisage a job model like the following:=20 - The most basic job is a Runnable instance.=20 - A CommandTaskDefinition (implements Runnable) takes a class name, bean = property values, and an execute method (plus optional arguments). On = run, it would simply instantiate the class, populate the bean = properties, and invoke the execute method. - An EjbTaskDefinition (implements Runnable) takes a JNDI name and = method name plus arguments. Other such convenience classes can be added, = of course.=20 - A SpringBeanTaskDefinition (implements Runnable) takes a BeanFactory = reference and a bean name, delegating to the specified prototype or = singleton from the given Spring bean factory on run. - A SpringEventTaskDefinition (implements Runnable) takes an = ApplicationContext reference and a class name (referring to a class of = type ApplicationEvent). Such jobs can easily be run by Chronos as they are all Runnables. For = Quartz, we'd need a generic Quartz Job implementation that receives a = Runnable in its JobDataMap and invokes run in its execute method. Then = we could seamlessly execute any of the above kinds of job with either = scheduler - the most important goal of abstraction, I guess. Juergen=20 -----Original Message-----=20 From: spr...@li...=20 [mailto:spr...@li...]On Behalf=20 Of Rod Johnson=20 Sent: Monday, November 03, 2003 10:09 AM=20 To: spr...@li...=20 Subject: [[W3-SPAM]] - Re: [Springframework-developer] Scheduler update=20 #2 - Email found in subject=20 Ivan,=20 Thanks for the update.=20 > Will the scheduler be accepted as a part of Spring?=20 We should probably take a vote on this.=20 I would probably make it a separate project and download within Spring,=20 spring-scheduler, dependent on the main codebase. Other crucial things = are:=20 - Code review.=20 - Volume of code. If there's lots of code, it's a stronger argument for=20 putting it outside the main codebase.=20 - Any dependencies it introduces.=20 - Unit test coverage. As our target is to go above 80% for 1.0 RC1, new = code=20 must have this kind of level of test coverage, verified via Clover.=20 - Your commitment to maintaining it, providing forum/list support etc.=20 > I am all for having pluggable scheduler, so people can choose the one=20 > they like. Is anyone willing to contribute a Quartz wrapper? Now would = > be a very good time to get the abstraction interfaces right.=20 +1=20 I think abstraction interfaces are very important, and consistent with=20 Spring's approach in general.=20 Providing a default scheduler implementation as standard might flow from = that.=20 Regards,=20 Rod=20 -------------------------------------------------------=20 This SF.net email is sponsored by: SF.net Giveback Program.=20 Does SourceForge.net help you be more productive? Does it=20 help you create better code? SHARE THE LOVE, and help us help=20 YOU! Click Here: http://sourceforge.net/donate/=20 _______________________________________________=20 Springframework-developer mailing list=20 Spr...@li...=20 https://lists.sourceforge.net/lists/listinfo/springframework-developer=20 |
|
From: Ivan R. <iv...@we...> - 2003-11-03 23:38:41
|
jürgen höller [werk3AT] wrote: Jürgen, I admire your ability to write long and interesting emails. Thank you for informing us about the interesting work that you're doing :) > - A CommandTaskDefinition (implements Runnable) takes a class name, > bean property values, and an execute method (plus optional > arguments). On run, it would simply instantiate the class, populate > the bean properties, and invoke the execute method. This sounds appealing but we effectively already have it with the combination of bean definition and SpringBeanTask definition. Personally, I don't mind having to do it in two steps. It also gives you the flexibility to reference the bean you are scheduling, and to schedule beans more than once if required. > - An EjbTaskDefinition (implements Runnable) takes a JNDI name and > method name plus arguments. Other such convenience classes can be > added, of course. And many other come to mind: native exec, HTTP, BeanShell, etc. We could group these in a separate package because they would apply to all scheduler implementations through the power of abstraction. -- ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ] |
|
From: Alef A. \(JTeam\) <al...@jt...> - 2003-11-04 00:47:07
|
<off-topic> Juergen, Interesting stuff you have there. I'd love to participate in such projects :)... > That should work reliably in a > cluster, shouldn't it? Has anyone experience with such load > balancing via JMS, particularly if execution reports are required? Well, I think it should work. One of our projects runs with distributed JMS right now, Not really two-way like you mentioned, but it works perfectly. We did it with JBoss (3.2) and had To go through quite some hassle before we got it running, but it works like a charm now... We've in fact got distributed XA transactions with Jboss/Oracle running there as well, pretty cool... </off-topic> |
|
From: Kopylenko, D. <dko...@ac...> - 2003-11-03 20:36:53
|
Juergen,
>Remote EJBs don't seem to be a good fit, as the C-based central scheduling
server would have to use IIOP to talk to them.
Can a remote EJB expose a Web service API("end point") ?
Dmitriy.
|
