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:
- their code is oversized
- the resources they require are bigger than needed
- Many problems are caused by their old architectures
- The user has no possibility to enhance the program's code for his proper use.
- The program has few possibilities to adapt itself to a dynamic-problem environment
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
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
- Platform independent
- Wide possibility to be developed
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.
PK's core is developed in Perl, a computer-language very stable and mature, often undervalued.