Background And Principles

What's it all about.

• In the beginning
• Principles

In the beginning

Once upon a time a developer came to a place where there was a bespoke scheduling system. The system was running over two thousand batch jobs doing sql extracts and ftps and emails and sometimes doing them and sometimes not. The development team started writing their more complicated jobs in Java and using Ant to build them and then they realised that they could use ant to do most of what their batch files were doing and so started replacing several batch files with one Ant script and this worked very well.

The old scheduling system was still not without problems and there began a project to look at a replacement and the developer being a big fan of open source looked for an open source solution and found:

• Quartz which provided scheduling but lacked retry schedules, job chaining or job dependencies.
• Ant which provided loads of tasks and runtime configuration, but is not a scheduler.
• Avalon which introduced Inversion of Control and Frameworks
• Soon after there was Spring, which showed the way ahead was non intrusive frameworks and POJO dependency injection but had ugly configuration files and no runtime configuration.
• Struts and BeanUtils demonstrated a really neat way of linking job properties.
• Finally JMX promised it can provide remote control and monitoring (but not without some effort).

Unfortunately our developer didn't find a distributed open source scheduling system with web and desktop control providing the required flexible scheduling options and an out of the box set of jobs for doing every day tasks. Surely there must be such a beast out there but he had Googled in vain.

The Company chose a commercial solution and the developer moved on into the world of the 'free lance' where survival is all about keeping your lance sharp. The developer realised he needed a pet project to help him do this - he remembered the beast that had thwarted him before and the quest was on.

So he took the ingredients he had gathered on his previous travels and began mixing them, and mixing metaphors, and - well to cut a long story short Oddjob was born.

Principles

In creating Oddjob a few guiding best practice principles have helped light the way in times of architectural indecision. Hopefully explaining them will help you better understand how to develop with and for Oddjob.

1. A non intrusive framework

   Writing a job, wherever possible, should not involve knowing anything about Oddjob.

   A job in Oddjob does not need to implement any Oddjob interface or extend any Oddjob class.

   (Unlike Ant's Task class or Quartz's Job interface)

2. Development with standard types

   A job's properties should be standard types. The framework should provide conversions to standard types without the job knowing anything about it.

   (Unlike Ant tasks which require fileset objects, an Oddjob job can be written with just a File[] property.)

3. Support for user defined types

   Support for user defined types should also be non intrusive. The framework should configure a type and inject it into the job without the job needing to do anything.

   (Unlike Ant references and the, dependency on Project to resolve them.)

4. Visually Configurable Components

   Oddjob should support GUI configuration.

   Although Oddjobs current GUI configuration doesn't really make Oddjob available to the masses - It does make configuration easy.

   (Easier than XML only configuration.)

5. Rapid Application Development and Deployment

   Writing jobs must be quick and easy. Lifecycle and deployment options should be kept a minimum.

   (Not like EJB!)