Re: [Springframework-developer] Scheduler update #2

[<jue...@we...>]

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