DeCare Systems Ireland Blog

We have been working with Redwood Software’s CronacleBeans technology for about the last year now and I would like to try and start spreading the good word about this most useful piece of technology.

CronacleBeans comes as part of the Cronacle Enterprise Scheduler suite of software and allows full integration between the Java world and the enterprise scheduling world. What made CronacleBeans interesting for us was the fact that our development teams could develop Java based services (POJOs, EJBs, whatever) and then, via a simple API (the heart of Cronacle is built on PL/SQL but Redwood provide a Java API which maps directly to the PL/SQL API), make them enterprise scheduler executable jobs.

Any decent enterprise scheduler must provide a core set of functionality, for example:

• Schedule jobs (doh!)
• Manage job dependencies
• Manage queueing
• Manage job prioritization
• Manage job status
• React to changes in job status e.g. errors, completions, unknowns etc.
• Start, stop, restart
• Concurrent job processing
• Notification

Its not impossible to construct your own Java scheduler, but to be honest, while you’re spending your time bringing together a set of libraries to do any of the above, or develop and test a home grown solution, your customers core business requirements are not being satisfied. When you use Cronacle and CronacleBeans you get all of the above out of the box. You do not have to concern yourselves with the mechanics of scheduling and how to implement some of its concepts in the Java world. You get to concentrate on what you were hired to do in the first place: solve some business problem for your customer.

Relatively simple schedulers like Cron can do a fine job of scheduling ‘kick-offs’ for command line driven applications, but we know that you get greater performance from long running java processes that have natively compiled all the hotspots in your application. Generally, processes like this would be started with the -server option enabled in your Java options and would process work over a long period of time.

CronacleBeans can be ran in two different modes:

• In-container: running inside a J2EE container
• Standalone

We happen to have a number CronacleBeans instances running inside a number of Oracle OC4J 10g instances (for ease of configuration) but it could just as easily be running as a standalone Java process. The CronacleBeans instance listens to the Network Agent for any work that may be assigned to it, and when a a job is invoked, either in an ad-hoc, scheduled or event driven manner, the agent will stream the necessary Java job definitions in the CronacleBeans instance.

A Java job definition is, at its most basic, a Java class, that implements a Redwood Executable interface and has some XML embedded in the source that can be picked up and read by the Redwood ANT tasks that convert the Java class into a Cronacle readable set of files. Redwood provide a number of ANT tasks that are necessary for script generation, compilation and eventual deployment to the script repository. The development approach required is quite easily setup in a JDeveloper or Eclipse IDE. The ability to create custom job adapters is also available if for some reason you require the ability to override the default classloading strategy or need to do something specific to your needs. All this code, as I said before, can be written in a standard text editor or IDE so it can be integrated into whatever source code repository you happen to be using. This makes the deployment of, and movement of, different job versions around the Redwood environment much easier as you are dealing with versioned code.

We have implemented the custom job adapters to some degree and if anyone out there would like to discuss this I would be more then happy to chat with them about it.

To date, we have implemented two different batch type applications in two different manners. The major difference between the two is in the threading implementation approach.

One application was a report generation type process, using XSL FO and FOP, whose threading was controlled via Cronacle: 1 report request = 1 unit of work. In some cases we had upwards of 3,500 units of work. All requests would be fed into a Cronacle managed queue, on which there was a maximum concurrently running job parameter which is configurable during runtime (1 running job = 1 Cronacle controlled thread). This workload would then be consumed by any attached Cronacle Beans schedulers. A running job instance in CronacleBeans is essentially the creation and control of a thread by CronacleBeans. This would allow CronacleBeans to ensure that, whatever the max concurrent running jobs parameter was, that this number of threads would be running in your target CronacleBeans environment. As this number could be changed at runtime, you could decrease or increase this number on the fly, therefore, resources allowing, increasing or decreasing throughput. The full life cycle of these threads are maintained via CronacleBeans, so aswell as being created, they could also be sent a ‘kill’ signal if required.

The other application is an electronic enrolment type application for the insurance sector. External customers would send in enrolment files with additions, updates or terminations of existing enrolment data. The arrival of each of these files resulted in event being fired off in Cronacle. The file then started to go through a number of steps controlled via a job chain: Mercator mapping, PL/SQL jobs, Java jobs, report generation etc. The Java portion of work for this application was originally developed in a standalone, out-of-container manner, the threading of which was implemented using Doug Lea’s util.concurrent library. Using the Redwood Java API, it was quite easy to integrate this application into the CronacleBeans/OC4J environment. At the moment, Cronacle is managing the arrival of approx. 150 files a week, processing approx. 3.4 million lives and we know, based on our benchmarks, that we can push this even further.

We are currently working on some case studies to highlight our work with Redwood Cronacle and CronacleBeans. These case studies will be posted on the Decare Systems Ireland web site, but if anyone would like to contact me to discuss anything that I have mentioned here, please feel free to do so.

Please bear in mind that Redwood Cronacle and CronacleBeans are commercial products and are not freely available. We (DeCare Systems Ireland) are not software resellers, so if you require information on Redwood pricing please contact them directly.

- Jay

PS - Follow this link to see Redwood’s case study on DSI’s use of Redwood CronacleBeans.