JS7 JobScheduler

Space shortcuts

Page tree

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

Compare with Current View Page History

« Previous Version 2 Next »

Introduction

  • 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 endlessly continue 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 developed with up-to-date requirements for performance and security in mind.
    • 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 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 was not a perfect match for ongoing development of the product. You can design an object oriented model for a product with future development in mind for a foreseeable time only, maybe some two to three years, but you cannot design such a model for a product life cycle of e.g. eight years. For the JS7 Controller and Agent we switched to the Scala programming language using for most parts a functional design. 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 not focused on 

Major Changes

Job-related Configuration

XML format migrated to JSON

  • The JS1 stores job-related configuration in XML files. The problem with XML is that parsers are inherently insecure due to the many capabilities of XML. One more problem is the fact that a number of XML parser projects are not actively maintained. This results in an increasing number of XML vulnerabilities and inacceptable delays for security fixes.
  • The JS7 makes use of JSON as the storage format for job-related configuration. In fact JSON capabilities are by fare more poor than what is available with XML, e.g. when it comes to validation. At the same time JSON is more focused and offers less attack surface.

File based Configuration migrated to the Database

  • 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 allowed to modify 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 an Agent that a specific user is entitled to deploy certain workflows and jobs. This adds non-repudiability to job-related deployments 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 will include with direct support for Git based repositories. Support for other version control products will become available from file based exports of the JS7 inventory.

Job Dependencies

Job dependencies migrated to workflow patterns

  • The JS1 preferably implements forward dependencies and a few options for backward dependencies by additional JITL jobs and JITL based monitors. For example a split/join operation is available from JITL job templates that have to be added to a job chain in addition to business related jobs and that are parameterized in a somewhat sophisticated way.
  • The JS7 implements a larger number of workflow patterns, see JS7 - Workflow Patterns that are available from JS7 - Workflow Instructions. For example, the JS7 includes a native JS7 - Fork / Join Instruction that does not require use of additional JITL jobs and that works without parameterization.

Individual Implementation of dependencies moved to workflow patterns

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

Pre-Post Processing

Support for Scripting Languages migrated to GraalVM

  • JS1 includes support for a number of scripting languages.
    • Shell Jobs implemented with any scripting languages 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 Job API is exposed:
      • JavaScript (Rhino)
      • JScript (Microsoft)
      • Perl (PerlScript)
      • PowerShell (Microsoft)
      • VBScript (Microsoft)
    • JavaScript, JScript and VBScript are available from the Java Virtual Machine (JVM) implementation provided by Rhino.
      • Newer versions of the JVM no longer support the JavaScript implementation provided by Rhino.
      • The Scripting languages JScript and VBScript are no longer supported by the JVM.
  • 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 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 Web Service only (see below).

Job API migrated to REST Web service

Migration Tools

The JS7 provides





  • No labels