Figure 1

         Server

The Server process is a multi-threaded, command line process that runs continuously.† The Server is the central process of the system.  It is event-based and has the following responsibilities:

1. Manage a database of job definitions.
2. Generate events, based on dependencies, schedules, and holiday calendars, to start jobs.
3. Respond to Client-based events signaling the completion and success/failure of jobs.
4. Respond to GUI-based events to create, modify, and control jobs.

All events processed by the Server are processed in a queue to ensure correct ordering.

Architecture

Job2Do is combination of 3 lightweight processes, each implemented as a stand-alone Java application that may be independently started and stopped (inter-process re-connections will happen automatically). Each of the 3 processes may run on any TCP/IP-networked machine on your LAN or WAN.  2 or more processes may run on the same machine. For example, if all your batch jobs execute on a single machine, you may run all 3 processes on that machine.

The 3 processes are called the Server, Client, and GUI, where both the Client and GUI processes are actually “clients” of the Server process. These 3 processes are summarized below.

        Client

The Client process(es) also runs continuously.†  In other job scheduling systems this process is sometimes referred to as an “agent.” The Client receives commands from the Server that tell it which jobs’ commands to start or kill.  The Client is responsible for executing commands on its local machine and returning the results to the Server.

One Client process should run on each physical or virtual machine on your network on which you wish to execute jobs.

         GUI

The GUI (graphical user interface) process(es) is used to define, edit, control, and monitor jobs.  A GUI may be started up and shut down as necessary.  All actions taken by the GUI are sent as events to the central Server process (GUIs never interact directly with Client processes).

One GUI should be installed on each machine from which a batch administrator wishes to control or monitor jobs.  

        Deployment

Because the 3 Job2Do processes are free to run on any machine on your network, endless deployment configurations are possible, and it is easy to modify your deployment as your batch matures and grows across your network.

In the most basic deployment, all 3 processes are installed and run on the same machine.  This deployment is depicted in figure 1 below, where the gray rectangle represents a machine (physical or virtual) and the colored letters represent the 3 processes.

If your jobs run on a specialized application server, you might deploy as in figure 2 below, where the Client is separately installed on the application server.

And if you have a large, business-critical batch, you will probably want to install the Server on a robust, stable, and secure server machine, which leads to the basic fully-distributed deployment in figure 3.

The logical extension of the above leads to the following type of deployment, where GUIs and Clients are free to intermingle on the same machines when the machines are used both for job execution as well as for job monitoring/control.

Figure 2

Figure 3

Figure 4

†On UNIX variants the process may be configured to run as a daemon.  On Windows it may be run either as a “system tray” application or as a normal command line (CMD shell) process.  See the FAQ for information about installing as a service.

1

2

3