...

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

Architecture Changes

Database

Run-time Database dropped

• The JS1 requires use of a run-time database 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.

Inventory/Reporting Database

• 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 deploy-time only. Therefore high availability requirements to this database can be considered in a more relaxed way by a number of users.

Controller / Agent

Agent Assignment

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

Agent Cluster Configuration

• For JS1 any number of Agent Clusters can be configured that reference the same Agent as they represent a logical layer on top of the installation.
• With JS7 there is a unique registration of an Agent during JS7 - Initial Operation.

Configuration Changes

Job-related Configuration

...

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

Migration Tools

...

• .

...