L'idea che culminerà nel progetto Perikronos ha preso vita una sera del maggio 2003, a margine di un corso presso una imponente società francese, il cui business è quasi esclusivamente la vendita, l'assistenza e il training del loro prodotto per la schedulazione centralizzata multi-piattaforma in ambito enterprise.
La filosofia alla base dello sviluppo di PeriKronos nasce da un attenta analisi critica dell'autore ai prodotti attualmente reperibili in commercio. Questi presentano i seguenti difetti:

Il primo punto: dimensioni del codice.

I pacchetti commerciali a cui faccio riferimento occupano diverse decine di megabyte, alcuni qualche centinaio. Questo aspetto rende particolarmente "fragile" il prodotto stesso. Infatti, all'aumentare delle dimensioni aumentano le probabilità di errori e diviene sempre più critica la loro ricerca e relativa correzione. Alcuni applicativi, fra quelli a cui mi riferisco, hanno conservato una struttura modulare, questo ha concesso loro di ovviare a questi limiti, altri sono stati sviluppati in modo non lineare e oggi sono blocchi di codice obsoleti cui vengono aggiunte modifiche più per risolvere i sintomi che per curare le patologie.

Il punto 2: richieste di risorse.

Un altro difetto, direttamente collegato al precedente, è l'ingiustificato utilizzo di risorse.
E' un fatto ormai acquisito che le società che sviluppano software non si preoccupino di ottimizzare il codice, limitandosi a richiedere supporti fisici sempre più potenti e capienti. E' importante sottolineare che questa mancanza aumenta con il crescere dell'entropia nel codice stesso. Quindi la difficoltà di sviluppare un programma in modo lineare, funzionale e ordinato è spesso proporzionale alla sua dimensione.

Il punto 3: architettura obsoleta

I pacchetti software verso i quali si muovono le mie critiche sono nati in momenti storici in cui le problematiche, le richieste e le priorità erano completamente differenti rispetto ai giorni nostri.
Queste differenze, in gran parte irrisolte, hanno dato origine a segmenti di codice che male si integrano nei rispettivi programmi a causa dell'inadeguatezza delle strutture e della poca flessibilità che caratterizzava i software vecchi. Tutto questo ha incrementato la loro entropia.
Un esempio classico di quanto detto sono le specifiche di sicurezza: quanti schedulatori di fascia enterprise distribuiscono le direttive di schedulazione criptando il loro contenuto? E quanti verificano l'identità del chiamato e del chiamante?

Il punto 4: lo sviluppo di piccoli moduli per i propri usi

Generalmente l'utente è portato ad apprezzare i prodotti "chiavi in mano" per la loro immediatezza. Infatti qualsiasi oggetto necessario è stato incluso nel pacchetto software dei suoi sogni. Purtroppo la realtà è molto diversa: se per il piccolo utilizzatore può essere vantaggioso un programma che, non richieda un autonomo sviluppo, ma sia molto completo (anche troppo) e soprattutto facile e immediato da utilizzare, per un esigenza dinamica e complessa quale quella di un ambiente enterprise questo è un compromesso limitante. Facciamo un esempio pratico: per un utente medio, che volesse scrivere un documento, un pacchetto quale "swriter" (modulo di OpenOffice) conterrà sicuramente molte più opzioni di quante ne userà, in tal senso il software utilizzato sarà sovrabbondante, mentre per uno scrittore di documentazione lo stesso prodotto risulterà inadeguato poiché poco adattabile ai suoi scopi. Egli utilizzerà, probabilmente, LaTex, molto più ostico (inizialmente), ma molto più dinamico e adattabile alle proprie esigenze.
Il concetto è poche funzioni molto espandibili contro molte funzioni non modificabili. Quale scegliere?

Il punto 5: Poca flessibilità

Un ambiente enterprise presenta continui nuovi problemi che, sebbene raramente sconvolgano l'intera architettura, quasi sempre rendono necessarie continui adattamenti e continue rifiniture delle componenti più periferiche del sistema. Un applicativo come lo schedulatore certo non fa eccezione. Per tale motivo la domanda del punto precedente ha una risposta scontata: poche funzioni (quelle veramente necessarie) e la possibilità di generarne di più specifiche in modo lineare, ordinato e granulare, in altre parole, in gergo informatico "in modo elegante". Perikronos si pone questo come uno dei suoi scopi principali.

I Punti fondamentali di Perikronos


Il primo punto: Leggerezza

Perikronos sarà composto fondamentalmente di due parti: il motore e l'interfaccia. Queste saranno completamente disgiunte. In tal modo, dove non sarà necessaria l'interfaccia, si potrà installare esclusivamente il motore e creare la lista di oggetti da schedulare in un ambiente differente.
Al contrario dei suoi mastodontici corrispondenti in ambito commerciale, questo software avrà una dimensione inferiore ai due Mega-bytes. Questo permetterà di utilizzare come schedulatori anche apparecchi moto modesti, quali ad esempio vecchi 386 per controllare luci, sistemi linux-embedded.... e in generale tutto ciò su cui è implementato l'interprete Perl.
Inoltre le sue caratteristiche gli permetteranno di adattarsi perfettamente a strutture di granfi dimensioni quali cluster, mainframe, server di varie nature.... sfruttandone le peculiarità.
Come è possibile tuto ciò?
La risposta è in più semplice di quanto possa sembrare: la leggerezza è dovuta all'utilizzo di tecniche moderne per la produzione del software, la flessibilità è invece una conseguenza della sua architettura primaria. Perikronos è in realtà un framework, ovvero uno scheletro su cui si possono montare gli oggetti più consoni a seconda delle necessità.
Devo ammettere che esiste in commercio un prodotto avente una struttura simile, ed è, a mio avviso, il più valido disponibile. Ma la parte concernente i moduli (e oggetti) è molto complessa, pesante e proprietaria, quindi impossibile da comprendere da parte dell'utente, nel caso in cui quest'ultimo non sia un programmatore C con significative competenze in UDP/IP, SNMP, e in un object-request-broker ovviamente proprietario.

Il secondo punto: Robustezza

Il cuore di Perikronos è un motore Perl. Quest'ultimo è un linguaggio spesso sottovalutato, avente un elevato grado di stabilità e di maturità. Il modello Open Source (OS) garantisce uno sviluppo lineare poiché direzionato dal "mantainer" e caratterizzato da apporti eterogenei. In tal modo il risultato è una selezione di un vasto numero di idee fortemente differenziate da cui selezionare la più idonea, performante ed "elegante". Inoltre il software appartenente a tale gruppo è soggetto ad un testing superiore, se non altro perché chiunque lo può provare, ed il Perl è molto usato.
Non intendo dilungarmi più del dovuto nella descrizione dei vantaggi che hanno portato il modello OS a realizzare i prodotti più usati e di qualità più elevata disponibili oggi (samba, apache, gcc...).
Il Perl rende disponibili paradigmi di programmazione molto potenti, come ad esempio l' Object Oriented Program, l'overload degli operatori (non disponibile nemmeno in Java), Il table-driven (classico del C), e altri. Questo permette di sviluppare codice molto compatto e di ridotte dimensioni, dove è più facile trovare e correggere possibili problemi.

Il quarto punto: Indipendenza dalla piattaforma hardware e software

Acorn AIX Amiga Apple Atari
AtheOS BeOS BSD BSD/OS Coherent
Compaq Concurrent Cygwin DG/UX Digital
DEC OSF/1Digital UNIXDYNIX/ptx EMC Embedix
EPOC FreeBSD Fujitsu-SiemensGuardian HP
HP-UX IBM IRIX Japanese JPerl
Linux LynxOS Macintosh Mac OS Mac OS X
MachTen Minix MinGW MiNT MPE/iX
MS-DOS MVS NetBSD NetWare NEWS-OS
NextStep Novell NonStop NonStop-UX OpenBSD
ODT OpenVMS Open UNIX OS/2 OS/390
OS/400 OSF/1 OSR Plan 9 Pocket PC
PowerMAX Psion QNX Reliant UNIX RISCOS
SCO Sequent SGI Sharp Siemens
SINIX Solaris SONY Sun Symbian
Stratus Tandem Tru64 Ultrix UNIX
U/WIN Unixware VMS VOS Win32
WinCE Windows 3.1 Win. 95/98/Me Win. NT/2K/XPz/OS]

Queste sono le piattaforme su cui è disponibile Perl, potete trovare questi dati all'indirizzo: http://www.cpan.org/ports/index.html Non penso siano necessari altri commenti.

Il quinto punto: Sviluppo autonomo

Perikronos, come detto, è un framework. Gli oggetti che vengono inclusi in esso si possono rappresentare secondo un diagramma a piramide: un oggetto è collegato ad altri oggetti più periferici, i quali sono connessi ad altri... e cosi via. Questa caratteristica permette di strutturare le proprie conoscenze, o quelle del gruppo che lo gestisce, in base alle proprie necessità di flessibilità. In altre parole, ipotizzando un caso pratico, una società avrà degli operatori con conoscenze informatiche di base che utilizzeranno le interfacce grafiche per creare i jobs da schedulare. Un gruppo di persone con modeste conoscenze di programmazione Perl che svilupperanno "agenti" in grado di recuperare dati con i quali condizionare l'esecuzione dei jobs stessi. Nel caso si desideri la possibilità di adattare lo scheduler a ogni possibile situazione, sarà necessaria, da parte di un ristretto gruppo, la competenza in OOP in Perl, in tal caso essi potranno interagire con il gruppo di sviluppo del progetto "PeriKronos" ospitato da sourceforge, con mia felicità :-)

Qualcuno disse "comprereste mai un auto con il cofano sigillato??" Non vi è maggiore certezza e sicurezza nell'uso di un software che essere in grado di controllarlo nelle sue intime componenti, "let's turn to Open Source World".

Anche questo documento è soggetto a licenza GPL, quindi, ogni critica o aggiunta sarà ben accetta.

Silvano Catinella
catinella@yahoo.com
mantiner del progetto PeriKronos
perikronos.sourceforge.net


Simona Bugada
simona_bugada@yahoo.it
revisione e traduzione contenuti