Introduction

• The implementation architecture describes:
  • the components used,
  • embedding of components and
  • component communication.
• Clustering is described as:
  
  • JS7 - Agent Cluster
  • JS7 - Controller Cluster
  • JS7 - JOC Cockpit Cluster

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 the 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 by 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 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.
• 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.
• 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