Introduction
- The implementation architecture explains:
- the components used,
- embedding of components and
- component communication.
- Clustering is explained with
Implementation Architecture
- Download: JS7_JobScheduler_Implementation_Architecture.pptx
- Download: JS7_JobScheduler_Implementation_Architecture.pdf
- Download the slides from the links above if the document below does not display in your browser:
Workflows and Orders
- Workflow configurations are deployed from JOC Cockpit to a Controller that forwards them to the connected Agents:
- Agents execute instructions and jobs from a workflow.
- Agents report back execution results and the job log output by returning events.
- Orders are managed by the JOC Cockpit and are submitted to Controllers that forward them to the connected Agents:
- Agents start workflows based on the order's scheduled start time.
- User interventions include canceling, suspending and resuming orders. Such operations are sent by JOC Cockpit to the Controller that forwards them to connected Agents.
Controller and Agent Implementation Architecture
- A Controller Cluster provides automated fail-over between Active and Standby Controller instances.
- Controllers hold a journal for restart capabilities that includes workflow configurations and order state events:
- The JOC Cockpit History Service subscribes to such events to maintain the History and to forward events to the GUI.
- Events are released from a Controller and the journal shrinks once the History has been persistently stored in the database.
- Controllers and Agents store messages in their journal and pass them asynchronously. This mechanism recovers communication in case of longer outages lasting hours or days.
JOC Cockpit Implementation Architecture
- JOC Cockpit can be operated in the following modes:
- single instance,
- active-passive clustered instances with one active instance and any number of standby instances.
- Cluster Service
- manages a number of Background Services:
- Monitor Service: checks execution history for events that users should be notified about.
- Restart Service: reruns pending deployments and performs synchronization with a Controller.
- Cleanup Service: purges the database, e.g. to limit the size of the history.
- History Service: retrieves execution results and logs from a Controller instance.
- Daily Plan Service: creates and submits orders to connected Controllers.
- guarantees service execution:
- checks the cluster health status of any connected JOC Cockpit instances,
- performs a fail-over operation in case that the Active JOC Cockpit instance fails.
- manages a number of Background Services:
- Event Bus Service
- An event bus manages communication between JOC Cockpit services:
- events are published in a producer/consumer (publish/subscribe) model,
- events are asynchronous, i.e. a service does not rely on immediate responses,
- events are not persistent, i.e. they are removed after being consumed or after some timeout,
- events are considered informational for the user interface that displays current data.
- An event bus manages communication between JOC Cockpit services:
- Proxy Service
- On start-up the Proxy will retrieve a snapshot of the Controller's journal and will subsequently receive any events fired by a Controller.
- The Proxy implements an event queue that can be subscribed to by a number of consumers, e.g. by Background Services and by the GUI.
Further Resources
Pages
Navigation
Overview
Content Tools