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
Manage a database of job definitions.
Generate events, based on dependencies, schedules, and holiday calendars, to start
Respond to Client-based events signaling the completion and success/failure of jobs.
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.
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
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.
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.
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.
†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.