PK is mainly a scheduler application. For those who know the Unix World it
could be thought as a crond daemon implementation. But, as I will show you,
many important differences exist between them.
PK back-end
We can take the crond software package as a start-point to explain PK
characteristics so we need to spend some time to describe this BSD-utility.
Crond needs two sets of parameters that ask two different questions:
The first parameter-group concerns the command or file that the scheduler will
execute. This instance is called "job".
The second group concerns the time-starting-coordinates of the job. Trought these
it will be possible to create a preferred time-frequency like daily, weekly, monthly and so on.
All these parameters are given to crond by a front-end called "crontab".
It is important to understand that those data identify a set of precise points in time, so if
at the fixed moment the resource is busy or the system is off for any kind of problems, the
process will not start.
Going back to Unix World we know that exists a crond implementation whose name is
"anacrond". This daemon accepts two time-parameters, creating a sort of
slot, inside which the scheduler will keep on trying to start the job.
Then all daemon's parameters answer to the following questions:
- what?
- when?
- For how much time I must try to relive the process?
Let's examine PK peculiarities
Version: 1.x - local scheduler
This version of PK answers to the previous questions, but it also allows the user to
define new parameters in order to be able to check the resources status and to define actions that
have to start when the process terminates. The actions are associated with the error code that the
process gives back before ending.
- Which are the resources that I must find available?
- Which action is to be taken if the job fails, and which if the job successes, and so on...
- Where do I have to send the job's logs?
The parameters that answer the first question define the minimum resources
that the system, who hosts the scheduled process, must have in order to execute
the job.
With the second question the scheduler sets the action that has to be executed because associated to the job
exit-status.
The answer to the third question indicates to the scheduler where the log will be
stored. In the Unix environment this is solved with input output channel
redirection. This is not an appropriate way for a wide enterprise environment.
Instead of this, PK provides the structures to define a set of virtual-devices that can manage
the job-logs.
Version 2.x: The conditioner.
This version will answer to a further question:
In this version the user can make a dependencies relationship among the jobs.
For example a job execution could be conditioned to the result of another job.
Version 3.x: The network
This version will answer to another question:
It will permit to choose in which system or set of systems the job will be executed.
Further PK features:
The PK's engine is developed with Perl using Object Oriented Program. This makes PK's
codes executable on many different platforms.
The PK's front-end
PK is a sotware application born for wide enterprise environments where the
scheduling-philosophy is strongly used. In this type of work-environment the
scheduler management (as job-monitoring) is often assigned to simple operators with
good factory-procedures know-how, but with a minimal IT knowledge. For this reason
producing an easy and intuitive interface is very important.
In order to obtain a total platform independent software we have developed the
Graphical User Interface (GUI) with PHP.
In the version 1.x: of the PK's GUI, it will be possible:
- making calendars
- creating new objects used by jobs (eg. Actions, logs...)
- creating jobs
- creating tasks
- monitoring the scheduled jobs
In the version 2.x the GUIs will be fundamentally the same except for the addition
of a new one used for the conditioning of the jobs. Moreover, it will be
developed the drag & drop method to configure the scheduler functions. This new
code will be made with Java Script.
In the 3.x version will be added the interfaces needed to:
- define the scheduled-jobs host system
- define a set of scheduled jobs host systems
Moreover we plan to have available a 3D interface for jobs monitoring.
by Silvano Catinella
catinella@yahoo.com
revision by Simona Bugada
simona_bugada@yahoo.it