The idea that originated the PK project borne a night on May 2003, on critics of an important French Company's product. The business of that company is the commercialisation, support, and training of its main product for enterprise centralised environment multy-platform scheduling.

Analisys of the Enterprise Scheduling Environment and its players

The philosophy behind PK's development starts from a deep analysis on the available commercial softwares. These products are affected by the following problems:

First problem: code size.

The size of the softwares I have analysed exceed ten megabyte sometime some hundreds. This aspect increase the unstability of the code. An increase of the code-lines number brings to the growth of error probability and time needed to find every error-bug.
Some commercial applications have kept a modular structure, this way they limit these kind of problems. On the other side, many other programs are developed in a non linear way and today they are monolithic rocks of old code always needing patch.

Second point: required resources .

Another limit directly connected to the previous one is the overkilling use of hardware resources.
We all know that software houses have not interst in optimizing their products code, requiring more and more powerful hardware and bigger storage devices. It is important to understand that this characteristic makes the system's entropic-level grow and, as consequence, also the difficulty to write ordered linear and logical code grow. Then the difficulty to write "elegant" code depends on the code size, too.

Third point: old architecture

The software-products I refer to are borne in the past when they had to solve very different requirements.
These differences have produced many code-segments that have not possibility to integrate themselves in their owned software-applications because their old structures are inadequate in the new dynamic situations. This way of developing has increased the entropic-level. An example about what I said is provided by the new security requirements: how many enterprise schedulers deliver the scheduling directives trought encrypted channels? And how many of them check the identity of the system?

Fourth point: the user development of small modules.

The user generally appreciates the all-inclusive static products for their fast access. So every feature is included in his "dream" software package. But reality is very different: if small users take advantage of using an easy and not much customized program, for the management of an enterprise dynamic environment this is a not acceptable mediation. For example, for a normal home-user who writes a document, Open Office Swrite offers certainly more options then he will use, so he doesn't need to develop other modules. But if we consider a professional document editor he will probably use LaTex. The usage of this package is more difficult and the exploitation requires a longer training, moreover LaTex has few built-in functions but a wider possibility to customize them. This characteristic allows the professional-user to obtain in few steps every solution he needs.

Fifth point: not enough flexibility

An Enterprise Environment has frequently small new problems that require many little tunings of the most external components. The scheduler application is not an exception. For this reason, with reference to the previous point, in order to obtain job-management in a logical and "elegant" way, the right approach is to have few main functions, extremely flexible and customizable.

PK's characteristics and advantages


Light weight.

PK is composed by two distinct parts: engine and interface. These parts have not interaction between them except for read/write operations on files and for the read operation on memory tables. Thanks to the described characteristic it is possible to install just the software neded and nothing more, this way no hardware resources are wasted: the code really needed by the system, where the jobs are scheduled, is less then two mega-bytes. This way PK can be used for many small tasks, like turning on or off the lights in a building, on old and less-powerful platforms as Intel-386 - as well as for scheduling heavy and critical jobs on Enterprise Servers, Clusters, Mainframe, etc. How can it be possible? The answer is easyer then it looks like: the light-weight is obtained with modern tecnologies used for software development, the flexibility is a consequence of PK's main structure: PK is a light-weighted framework on which mounting the objects (or modules) more adequate to the necessities. There is one commercial product with a framework structure, and in my honest opinion, this is the best you can find in the traditional market. But its object interaction and management are very complicated, heavy weighted, and which code is closed by license. These elements make impossible for a user who has no knowledge of C-language, UDP/IP SNMP Network, and Object Request Broker, to understand how to program it. Solid PK's core is developed in Perl, a computer-language very stable and mature, often undervalued.