You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 16 Next »

Overview

The introduction of the JobScheduler Operating Center (JOC) Cockpit with the release of Version 1.11 brings a significant change in the JobScheduler architecture:

  • The JOC Cockpit has a client - server web service architecture and is installed separately from a JobScheduler Master.
  • The Cockpit client runs in a standard Internet browser and the server provides the JobScheduler Web Services.
  • The JobScheduler Web Services provide the necessary information for the Cockpit GUI as well as handling the communication with JobScheduler Masters.

The Web Services can be addressed by any number of Cockpit GUIs and by external programs such as ERP applications.

 

The diagram below provides a schematic view of a typical JobScheduler environment using the JOC Cockpit.

Additional features of this new architecture are:

  • Authentication and Authorization: The Web Services use an LDAP Directory for authentication, authorization is carried out against role-based group permissions data held on the WebServices server. This means that user access to particular resources can be restricted and that resources .
  • Multiple GUIs: The JobScheduler Web Services can be accessed by more than one Cockpit, so that, for example, an operator situated in a remote site can carry routine tasks at the same time as an administrator in the server room is configuring maintenance procedures.
  • 3rd party applications: External applications such as ERP systems can also access the Web Services and, for example, start jobs when they provide the correct authentication and authorization.
  • Multi-Client Capability: Any number of JobScheduler Masters can be controlled in a network via the Web Services as long as they are in the same network.
  • Job Status and History: JobScheduler Masters record operational information in a database - this information can be called up from the JOC Cockpit via the Web Services.

Note also the following:

  • The JOC Cockpit can display workplan and job history information and therefore functionally replaces JID - the JobScheduler Information Dashboard, which will not be delivered with the JobScheduler from version 1.11 onwards.
  • JobScheduler Universal Agents or Universal Agent Clusters cannot be directly controlled via the Web Services - this must take place via a JobScheduler Master.

Technical Details

The diagram below shows the JobScheduler JOC Cockpit Architecture at a more technical level. 

HTTP is used for communication between the RESTful Web Services and the JOC Cockpit - or other application - clients.

The Web Services use XML commands and responses to communicate with the JobScheduler Master(s). [Protokol??] In addition events are communicated [Protokol??] between the Web Services and the JobSchedulers.

Communication between the JobScheduler Masters and Agents takes place using HTTP/HTTPS RESTful web service .

Communication between the REST Web Services and the JobScheduler database takes place using XML [Genauer??] .

Authentication and authorization is carried out by an Apache Shiro framework integrated into the Cockpit:

  • authentication is carried out against an LDAP directory (not shown in the technical diagram above but in the) and
  • authorization is carried out against a role-based group permissions file.

 

  • No labels