Job Queue Introduction   -   Job Queue Architecture   -   IndyJUG Home

Indianapolis Java Users Group Open Source Project

Job Queue Open Source Project Definition

 

Business Purpose: 

 

The eBiz Shop is donating existing source code for the current version of the Java-based Job Queue to kickstart the first IndyJUG open source project.  While there are many, many projects that could be tackled by the group, it was determined that having at least a beginning and some basis to start from would be a good idea and there is some definition and a working model which should make for easier progress.  It was also felt that this product could be used by many of the members to their benefit. The intention of this project is to not only produce a useful product, but also to teach the java language to those that want to participate at various levels.  The project will be reviewed at the users group on an appropriate basis as a learning tool.

 

The Job Queue project was initially created by The eBiz Shop to solve the following computing issues:

 

1)      Report programs/long running programs being submitted causing a general system slowdown of the database machine and application machine.

2)      Allow end users to manage the queue without the need for administrative rights.

3)      Run jobs in a sequential order due to dependencies of prior job results within a scheduled order.

4)      Provide the ability to run jobs after regular business hours to spread out the use of the available computing power across a 24 hour period, thereby eliminating the need for special reporting servers and/or special database reporting servers.

5)      Maintain a status of the submitted job completions.

6)      Provide a notification method on failed jobs via email.

7)      Job Queue application needs to be cross-platform capable, particularly targeted at Intel processor based systems like Windows and Intel-UNIX hardware although any java supported platform could be used.

8)      The queue needs to be able to stop submitting jobs at an appointed time to give back the computing power at a pre-determined time interval.

9)      Browser-based interface is mandatory.

10)  Utilize open source tools to create the job queue.

 

As the hours of operation for many businesses continue to extend beyond the 8:00AM to 5:00PM standard, it is becoming difficult to “kick off” a job prior to leaving work.  As well, it is becoming increasingly important that IT staff push as many tasks out to their user community that they can and a job queue with a browser interface could allow the users to submit reports and long running jobs without machine administrative rights.  On the other hand, IT administrators don’t want so many jobs submitted and running at one-time to the point that machine can’t perform for interactive jobs.  A job queue that can stack up requests and then release them at an appointed time, and also stop submitting jobs at a certain time period could be quite valuable to fully utilize available computing power. 

 

 

Marketplace Analysis

 

There are many job scheduling/job queue products on the marketplace that do some very sophisticated job manipulations but most are fairly expensive, complicated to setup and haven’t been available with browser-based user interfaces.  The free job schedulers/job queue management software available has tended to be command –line driven and require pretty advanced knowledge to setup and use.  While there are probably products emerging all of the time and something could come out into the marketplace before we complete even the first phase, current research suggests there is a need for this product.

 

Current Technical Environment

 

The donated starting point consists of the following components:

 

A) A java applet using Swing 1.2 components to provide a table interface.

B) Three SQL tables used to store the job queue data currently defined for SQL Server

C) A library of java classes used to create the applet

 

State of Existing Code

 

This has been a side project for one developer at this time so only basic functionality has been placed into service to merely run the jobs.  Scheduled start and stop times for the jobs as well as the queue have not been implemented.  Features too numerous to mention at this point are missing but a few high priority issues are needed.

 

Priority Feature Deficiencies

 

1)      HTML admin management interface

2)      HTML user management interface

3)      Setting of release time per job.

4)      Setting of stop/start time for the job queue in general.

5)      Scheme to setup and define additional job queues.

 

Immediately Known Technical Deficiencies

 

1)      Utilizes swing 1.2 only as a user interface, which requires the java plug-in.

2)      Utilizes SQL Server rather than the open source database mySql.

3)      Runs as a service within the Windows OS.

4)      Not been ported to another OS yet.

5)      Utilizes some specific ebiz java classes, which aren’t necessary for the product.

 

 

Intended Technical Environment

 

The ideal product would have two interfaces; an advanced user interface that would be a java applet and a simple interface that would be a java servlet/HTML type interface.  Both interfaces could be used to access and manipulate the job queue data.  One of the first tasks is to define a Servlet approach to this project.  The Swing 1.2 interface was primarily used so that the original developer could learn Swing so it is possible that we  ignore the swing side of the equation and concentrate on the servlet side.  It will make the building and testing go faster.

 

MySQL should be used to store the queue data, although we could use an even simpler file system to manage the queue, but this might take away the use of currently coded SQL statements.

 

Must be able to use this product on Linux and Windows/NT.  The servlet model will be built on Linux as a demonstration of the product due to the donation of the test machine from The eBiz Shop.

 

Intended Feature Direction

 

There are a ton of features that could be incorporated into this product, but I think the participants and the users should have some input here.  After everyone gets their feet wet then we will discuss a priority list of features.