Architectural Fundamentals

OpenJCS relies on master scheduler daemons (openjcsd), a client daemon on each host participating in the scheduling domain (jcsjobd) which also doubles as the job controller/dispatcher for that host, and one or more service listeners for the services provided by OpenJCS. The services and daemons used by OpenJCS are as follows:

JCS Master (openjcsd) – The master controller for an OpenJCS domain. This daemon handles domain membership, region administration, service map distribution and permission lists. Every host will have an openjcsd running on it, and communication to the other OpenJCS daemons pass through openjcsd to get to the target daemons. There can only be one active master openjcsd for the domain, but others in the domain will be defined as standby masters, and will also serve as pass-through systems to the current master when not active.

JCS Execution (jcsjobd) – This daemon is responsible for every process that is dispatched from OpenJCS to execute on the host.

JCS Heartbeat (jcshbd) – This process sends a UDP heartbeat request to openjcsd and each of the service masters periodically, and if its heartbeat fails to the current master, but not to one of the candidate failover masters, it calls for a master election. This process is a child process to jcscomd.

JCS Scheduling (jcssched) – Provides the repository for schedule checking, and dispatches events to target clients.

JCS Variables (jcsvard) – Maintains all JCS variables across the domain.

JCS Resources (jcsresd) – Maintains all JCS resources, and controls allocation of same.

JCS Replies (jcsaskd) – Maintains list of pending replies, as well as all automated replies.

JCS Virtual Hosts (jcsvirtd) – Maintains Virtual Host lists, rules and tokens, and allocates Virtual Host workloads.

JCS Calendars (jcscald) – Maintains all information regarding OpenJCS calendars.

JCS File Transfer (jcscpd) – Performs file transfers between hosts in OpenJCS.

The listeners communicate via SOAP calls. The call is first routed to the jcsjobd for the current host, which then uses its service map to decide where to route the request.

The location and quantity of listeners defined for a domain is contained in the openjcs.conf file. The default is one listener per service on each host in the domain, with daemons for virtual hosts and regions being kept on the current master.

System Level Components

In order for OpenJCS to perform its job properly, certain system level components must be in place. Some of these components are:

v DBMS – As of this writing, the only DBMS that OpenJCS will use to maintain its job execution history and component values is PostgreSQL. Other databases may be supported in the future if there is sufficient demand to warrant the development effort involved.

v Apache Web Server – This is required if the Web GUI for OpenJCS is used (highly recommended).

v C++ – Used to implement the performance-critical aspects of OpenJCS (memory caches, for example).

v Python and Zope – Used to implement the less performance-critical aspects of the OpenJCS system.

v Java Virtual Machine – Another requirement if the Web GUI is used. It is also required on the client machine if the client GUI is used.

v PHP – Used in the Reporting GUI.

v ssh – Used to secure the communications between clients and services.