JS7 JobScheduler

Space shortcuts

Page tree

Versions Compared

Old Version 16

changes.mady.by.user Alan Amos

Saved on

compared with

New Version Current

changes.mady.by.user Andreas Püschel

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • JS7 is a rewrite of the JobScheduler components products from scratch. The motivation for developing JS7 was not to improve the existing 1.x branch (JS1) but to create something better.
  •  The code base of JS1 partly dates back some 12 years, major parts had been written in C++ for an object oriented design. There are three reasons for rewriting JS7:
    • A code base needs a redesign from time to time: you cannot indefinitely continue to add bells and whistles when. for example, the code was not designed to meet more elaborate security requirements which were not known or evident at the time of writing. JS7 is designed to meet up-to-date requirements for performance, resilience and security.
    • The C++ code base means that a number of software packages have to be installed in the operating system. In addition, it does not allow perfect platform independence. JS7 makes use of Java for the purpose of guaranteed platform independence and minimum installation requirements.
    • The object oriented design of JS1 is not a perfect match for ongoing development of the product. You can design an object oriented model with future development of a product in mind for a foreseeable time only, maybe for some two to four years, but you cannot design a model that is stable for a product life cycle of eight years. SOS switched to the Scala programming language using a functional design for most parts of the JS7 Controller and Agent. This is due to the fact that functional programming is free from side effects, whereas an object oriented approach tends to add more and more relationships to objects that makes ongoing product development increasingly complex.
  • The first release of JS7 is focused on new users of the product. Existing users of the JobScheduler will find migration tools that are being improved in the course of JS7 releases, See the JS7 - Migration of JobScheduler 1.x Job Configuration article for more information.

...

Inventory/Reporting Database

  • JS7 and JS1 both require similar Reporting Databases.a Reporting Database for similar purposes. However, this is not the same database: initial installation of JS7 has to start from a new database or schema, see JS7 - Database.
    • Users who want to access the job history and logs of JS1 are recommended to continue use of JS1 JOC Cockpit and its database with the JS1 Master being deactivated.
  • The However, the JS7 - Database stores inventory information and deployment information for job-information about inventory, deployment and execution history of jobs, workflows and related configuration. This
    • Inventory and deployment: The database is not required at run-time but at design-time and at deploy-time only.
    Therefore
    • In this respect high availability requirements for
    this
    • the database
    are
    • can be considered to be more relaxed
    by a number of users
    • .
    • Execution history: If the database is not available then the execution history and logs cannot be made available in near-real time with JOC Cockpit. This does not affect execution of jobs and workflows. The execution history is not lost but will be streamed from the Controller to JOC Cockpit at a later point in time when the database becomes available.
    • API Service: The database is required for use of the JS7 - REST Web Service API. Users who run jobs with access to the API might prefer to use a highly available database.

Controller / Agent

Agent Assignment

...

  • The file based configuration of JS1 is not perfectly cloud usable. This is why branch 1.13 dropped the JOE job editor and introduced browser based management of job-related configurations stored with the database. However, JS1 allows modifications of job-related configuration by files for users with access to the operating system. From a security perspective this is not a perfect design as technical permissions which allow a system administrator to modify files at operating system level are not related to role based permissions that determine who should be entitled to modify and to deploy jobs.
  • JS7 follows a role based access model that excludes OS users such as a root account with technical permissions for file systems. Instead, digital signatures are used to prove to a Controller and Agent that a specific user is entitled to deploy certain workflows and jobs - see JS7 - Secure Deployment of Scheduling Objects for more information. This adds non-repudiability to job-related deployment that is not based on trust relationships for JS7 components products but purely on the use of certificates. For example, an Agent does not trust a Controller or JOC Cockpit, it only trusts the available certificates.
  • For lovers of the straightforward option available with JS1 to push/pull job-related configuration files to/from a version control system, the good news is: JS7 includes the JS7 - Git Repository Interface. Support for additional version control products is available from file based exports of the JS7 - Inventory Export and Import.

...

  • JS1 includes support for a number of scripting languages:
    • Shell Jobs implemented with any scripting language are supported, provided that the script interpreter, e.g. Python, Ruby etc., is available on the machine which the job is executed on.
    • API Jobs are supported for a number of scripting languages to which the JobScheduler Job API is exposed:
      • JavaScript (Nashorn)
      • JScript (Microsoft)
      • Perl (PerlScript)
      • PowerShell (Microsoft)
      • VBScript (Microsoft)
    • JavaScript is available from the Java Virtual Machine (JVM) implementation provided by the Nashorn JavaScript Engine.
    • The JScript and VBScript scripting languages are only supported by the Windows JVM on 32bit systems as described in VBScript Jobs. The ScriptControl:VBScript job type introduced with JobScheduler release 1.10 acts as a replacement for VBScript jobs.
  • JS7 includes support for the following scripting languages:
    • The option of running Shell Jobs for any scripting language for which the interpreter is available remains unchanged.
    • For Java and JavaScript Jobs the JS7 - Job API is offered.
    • JS7 - JavaScript Jobs are supported based on use of the Oracle® GraalVM with JS7 Agents starting from Release 2.5.4 and Release 2.6.1.
      Later JS7 releases will include support for API Jobs for scripting languages available with the GraalVM such as
      • JavaScript (Node.js)
      • Perl
      • Python
      • Ruby
    • At the same time JS7 JVM Java/JavaScript Jobs do not provide the same capabilities as API Jobs for JS1. JS7 JVM Jobs are limited by design to receiving arguments and returning result objects. Actions on inventory objects such as adding orders, stopping jobs etc.  are are available through the the JS7 - REST Web Service API (see below).

...

  • The functionality of the JobScheduler Job API has been migrated to the JS7 - REST Web Service API.
  • However, a number of differences have to be considered:
    • The JS1 Job API allows modification of objects of the current job such as the current task or order.
    • The JS7 REST Web Service API allows modification of any objects at configuration level that includes deploying modified objects.
    • A number of operations of the JS1 Job API are not available with JS7, for example modifying the job configuration on-the-fly by, for example, adding/dropping a setback configuration. This is not considered good practice as such changes to the configuration are deeply buried in script code and are not evident from configuration.
  • A REST Client has to be used by jobs that access the JS7 REST Web Service API. JS7 ships with a REST Client for Java/JavaScript jobs.

Object Changes

Consider changes described in the JS7 - Terminology article.

...

  • JS1 knows Jobs and Job Chains that implement a sequence of jobs.
    • A job is an object that can be modified individually and which can be re-used with a number of job chains.
    • A job is defined to be operated standalone or as a node in a job chain.
    • Any changes to jobs and job chains are implemented immediately.
  • JS7 is not limited to a sequence of JS7 - Jobs but introduces a number of JS7 - Workflow Patterns which is why the term workflow replaces job chain.
    • A job is only available within a workflow. A job is not an independent object and it cannot be re-used.
      • While users might consider this a limitation, in fact it guarantees a self-contained and consistent workflow configuration. Consider the fact that a JS1 job could be modified or removed at run-time leaving the job chain in a critical status. The JobScheduler Master had to check for updated versions of a job XML file and had to apply any modifications in good time. If modifications are not consistent, e.g. if the job parameterization was changed, then would breaks a currently running order as any changes to jobs are applied immediately.
      • Modifications to a JS7 job force a workflow to be deployed once again.
      • The JS7 - Inventory Bulk Operations for Jobs allow modification of a single job and the application of changes to a number of jobs across workflows.
    • There are no JS1 standalone jobs in JS7, instead such jobs are considered to be workflows with a single job.
      • The JS7 - Job Templates replace the JS1 standalone jobs as they allow to centrally update jobs in a number of workflows.
    • Changes to workflows take effect for newly added JS7 - Orders only. The JS7 Controller keeps track of workflow versions as long as an order is assigned the workflow.
      • At the point of time of submission an order is associated with the current version of a workflow.
      • If the workflow changes later on then this has no impact on submitted orders, but will only affect new orders that are submitted after this change.
      • This feature can be used to target changes to a workflow to a future date. Existing orders can be cancelled and re-submitted to be assigned the current version of a workflow from the Daily Plan view.

...

  • JS1
    • The license model includes running any number of parallel jobs with Masters and Agents if used with the commercial license.
    • Users of the open source license can run any number of parallel jobs with Masters and are limited to running one task at a time with Agents.
  • JS7
    • JS7 introduces a new license model: for details see the JS7 - License article.
    • Users of the open source license can run any number of parallel jobs with JS7 Agents.
    • The same source code and therefore the same feature functionality is available with both license models. The one exception is the operational feature of clustering JS7 components products for high availability which is a commercially available feature for license holders.
  • JS1 + JS7
    • The SOS is committed to open source which is about free software, in the sense of freely available source code.
    • Customers with commercial licenses benefit from additional Support Options and Services.

...