JS7 JobScheduler

Space shortcuts

Page tree

Versions Compared

Old Version 2

changes.mady.by.user Andreas Püschel

Saved on

compared with

New Version 3

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 from scratch of the JobScheduler components. The motivation for the JS7 is not to improve the existing branch 1.x (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. This makes three reasons to rewrite JS7:
    • A code base needs a redesign from time to time, you cannot indefinitely continue to add bells and whistles: for example, if the code was not designed for more elaborate security requirements that were not known or evident at the time of writing. The JS7 is designed to meet up-to-date requirements for performance, resilience and security.
    • The C++ code base requires a number of software packages that have to be installed in the operating system. In addition, it does not allow perfect platform independence. The JS7 makes use of Java exclusively 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 for a product with future development of a product in mind for a foreseeable time only, maybe for some two to three four years, but you cannot design such a model that is stable for a product life cycle of e.g. eight years. For the JS7 Controller and Agent SOS switched to the Scala programming language using a functional design for most parts. 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 JobScheduler find preliminary migration tools that are improved in the course of JS7 releases, See JS7 - Migration of JobScheduler 1.x job configuration.

...

  • The JS1 requires use of a run-time database by the Master to store job results and logs immediately after execution of a job.
  • This database is dropped as the JS7 - History Service performs this task asynchronously.

...

  • The JS1 Reporting Database exists in a similar way for JS7.
  • However, the JS7 - Database stores inventory information and deployment information for job-related configuration. This database is not required at run-time but at design-time and at deploy-time only. Therefore high availability requirements to this database can be are considered in a being more relaxed way by a number of users.

Controller / Agent

...

  • In JS1 an Agent can be accessed by a number of Master instances.
  • For JS1 With JS7 Agents are dedicated to their a Controller and cannot be shared between Controllers.

...

  • 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 configuration 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 of 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.
  • The JS7 follows a role based access model only that excludes users with technical permissions such as a root account. Instead, digital signatures are used to prove to a Controller and Agent that a specific user is entitled to deploy certain workflows and jobs. This adds non-repudiability to job-related deployments deployment that is not based on trust relationships of JS7 components but on use of certificates only, e.g. an Agent does not trust a Controller or JOC Cockpit, it trusts available certificates only.
  • For lovers of the straightforward option available from JS1 to push/pull job-related configuration files to/from a version control system, the good news is: the JS7 includes direct support for Git based repositories, see JS7 - Roadmap. Support for additional version control products will become becomes available from file based exports of the JS7 inventory.

...

  • Due to the limited capabilities of the JS1 for backward dependencies users might have implemented dependencies individually, e.g. by scripting. the Product Knowledge Base includes a number of such examples.
  • The JS7 implements a larger number of workflow patterns as stated with the previous chapter. SOS does not consider it desirable to bury the logic of job dependencies in scripts. Instead such scripts should be migrated to use of use JS7 - Workflow Instructions and should be part of the configuration. This is manual work and is not supported by migration tools.

...

Support for Scripting Languages migrated to GraalVM

  • JS1 includes support for a number of scripting languages.:
    • Shell Jobs implemented with any scripting languages language are supported provided that the script interpreter, e.g. Python, Ruby etc., is available from the machine on which the job is executed.
    • API Jobs are supported for a number of scripting languages to which the JobScheduler Job API is exposed:
      • JavaScript (RhinoNashorn)
      • 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 scripting languages JScript and VBScript are supported by the JVM on 32bit systems only, see 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
    With JS7
    • the option to run Shell Jobs for any scripting language for which the interpreter is available remains unchanged.
    • API Jobs are supported for scripting languages available with the GraalVM such as
      • JavaScript (Node.js)
      • Perl
      • Python
      • Ruby
    • At the same time JS7 API Jobs do not provide the same capabilities as for JS1. JS7 API Jobs are limited to receive arguments and to return a result. Actions on inventory objects such as adding orders, stopping jobs etc. are available from the RÉST JS7 REST Web Service API (see below).

Job API migrated to REST Web service

  • 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 to modify objects of the current job , such as the current task or order.
    • The JS7 REST Web Service API allows modification of any objects, but requires to identify objects such as jobs.
    • A number of operations of the JS1 Job API are not available, for example to modify the job configuration on-the-fly, e.g. by adding/dropping a setback configuration on-the-fly.
  • A REST Client has to be used by jobs that access the JS7 REST Web Service API.