Page History
| SEO Metadata | ||
|---|---|---|
| ||
JS7 implements a resilient architecture for scalable use and flexible clustering of products |
| Table of Contents |
|---|
...
Introduction
- The implementation architecture explainsdescribes:
- components the products used,
- embedding of components and
- component communication.
- Clustering is described as:
Implementation Architecture
- Download: JS7_JobScheduler_Implementation_Architecture.pptx
- Download: JS7_JobScheduler_Implementation_Architecture.pdf
- Download Use the slides from above links should display of the below document not work for 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 the JOC Cockpit to the Controller which then 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 which 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 instance with a primary instance and backup instance,active passive clustered instance with a primary instances with one active instance and any number of backup standby instances.
- The JOC Cluster Service
- manages a number of backend servicesBackground Services:
- Job Streams Service: manage job starts, monitor tasks and calculate events for dependency management.
- History Service: retrieve the job execution and log output of jobs executed with Agents.
- Daily Plan Service: submit orders for the daily plan to JobScheduler Controller.
- Monitor Service: check execution history for events that users should be notified about.
- operates backend services for active or passive mode:
- in active mode any of the services will perform active tasks, e.g. the Job Streams Service will start tasks,
- in passive mode any of the services will report status information about the result of active tasks.
- guarantees service execution
- for the Active JOC Cockpit instance in service active mode,
- for any Passive JOC Cockpit instance in service passive mode.
- forwards service execution requests originating from a Passive JOC Cockpit instance to the Active JOC Cockpit instance.
- JS7 - Monitor Service: checks execution history for events that users receive JS7 - Notifications for.
- JS7 - Cleanup Service: purges the JS7 - Database to limit for example the size of the history.
- JS7 - History Service: receives execution results and logs from a Controller instance.
- JS7 - Daily Plan Service: creates and submits orders to Controllers on a daily basis.
- guarantees service execution:
- checks the cluster health status of any connected JOC Cockpit instances,
- performs a fail-over operation in case the active JOC Cockpit instance fails.
- manages a number of backend servicesBackground Services:
- Event Bus ServiceJOC Event Bus
- 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 a timeout,
- events are considered informational for the user interface that displays current data,
- events are not intended for historical retrieval.
- is updated in near real-time.
- An event bus manages communication between JOC Cockpit services:
- Proxy Service
- On
- The Controller Proxy 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 Controller Proxy implements an event queue that can be is subscribed to by a number of consumers.
Controller/Agent Implementation Architecture
...
- , for example by Background Services and by the GUI.
Resources
Overview
Content Tools