Introduzione
Contesto
Il presente documento rappresenta un’analisi dell’attuale situazione del contesto tecnologico informatico aziendale nel cosiddetto middle tier, a partire dalla quale si giunge ad alcune previsioni sulla base:
- dei trend evolutivi in termini di infrastruttura, player dominanti, linguaggio/architettura
- di alcune considerazioni sulla situazione di mercato;
- di altre considerazioni di natura tecnologica.
Il periodo preso in considerazione è quello a partire dagli anni ’80 sino al medio-lungo termine, inteso quest’ultimo nell’ambito della rapida evoluzione del mondo informatico/Internet.
Obiettivo
L’obiettivo del documento è quello di delineare le decisioni per le quali è stata disegnata, progettata e implementata la iConnect Architecture (in breve: iConnect), oltre ad una giustificazione di alcune decisioni di fondo quale la scelta del linguaggio di riferimento, sulla base di un’analisi del contesto tecnologico che ha portato ad una serie di predizioni.
Evoluzione del contesto tecnologico
Evoluzione infrastrutturale
A partire dagli anni ’80 ad oggi, si sono avuti alcuni grossi cambiamenti a livello di infrastruttura tecnologica aziendale: dai grossi mainframe dell’epoca si è arrivati sino all’attuale struttura di Internet, passando per i Mini Computer e in seguito per i sistemi Client / Server.
L’evoluzione infrastrutturale evidenziata nel grafico seguente mostra il susseguirsi delle diverse tipologie infrastrutturali in termini di predominanza di modello.
La natura sempre più distribuita delle applicazioni, in un contesto di carico crescente (entrambe, queste, caratteristiche proprie di Internet), porta ad una complessità man mano crescente in termini sia di infrastruttura tecnologica che di architettura applicativa.
La crescita di carico deve essere intesa come la continua crescita di Internet in termini di traffico, host, domini, richieste per sito.
Come mostra il grafico seguente, negli ultimi anni si è avuto un grandissimo incremento nel numero di hostname Internet, anche in termini di hostname per server.
Nella situazione delineata, i requisiti non funzionali osservabili quali la scalabilità, l’affidabilità, la performance e altre, in un’ottica di Quality of Service e di Service Level Agreement, rappresentano grandi sfide che si cerca di controllare e governare con l’adozione di apposite infrastrutture ed architetture.
Tutto ciò comporta l’adozione di hardware sempre più potente in grado di sostenere la crescita di Internet nei parametri suindicati, esigenza questa che viene presa in carico dai grandi fornitori di hardware (tipicamente gli stessi che producono/supportano alcuni linguaggi mainstream, quale Java) tramite grossi e costosi sistemi SMP, dotati di sistemi operativi proprietari.
Ciò ha portato ad una situazione di vendor lock-in che le aziende contrastano ricorrendo sempre più a griglie di macchine mono/bi-processore x86, piuttosto che a cluster di macchine SMP (che l’architettura J2EE incoraggia/richiede).
Il mercato del front tier Web è già dominato da questa configurazione infrastrutturale, e ciò sta avvenendo anche nel back-end, portando così ad un’evoluzione in tal senso del contesto middle-tier.
Evoluzione dei player dominanti
In ciascuna delle transizioni che hanno portato a nuovi modelli di infrastruttura, si è avuto anche un cambiamento relativamente ai player dominanti.
Le griglie di server x86 indicate nel paragrafo precedente sono di norma equipaggiate di distribuzioni GNU basate sul sistema operativo Linux. In seguito allo shift infrastrutturale già menzionato, è quindi lecito aspettarsi che Linux possa così diventare il player di riferimento in quanto a sistema operativo in ambito server.
È altrettanto prevedibile che, nonostante iniziative come il Sun Java Desktop e l’effort della comunità open source nel produrre distribuzioni pronte per il desktop, in tale ambito il predominio di MS Windows rimanga tale parecchio a lungo.
La necessità sarà pertanto quella di continuare a garantire la possibilità di sviluppare su Windows e di effettuare il deployment su Linux; in tale senso, l’ambigua accoppiata Windows-Linux può risultare vincente.
È inoltre interessante notare le quote di mercato dei vari web server, come da figura seguente, dal quale risulta che Apache, prevalentemente utilizzato su piattaforme Linux, risulti essere di gran lunga il più usato.
Tutte queste considerazioni portano quindi a prevedere che Linux occuperà una grande, se non predominante, quota di mercato nel middle tier diventando così il player di riferimento.
Evoluzione dei linguaggi
Analogamente al cambio di player dominante in ciascuna transizione infrastrutturale, si è avuto un cambio in quelli che erano i maggiori linguaggi di riferimento.
L’attuale situazione vede Java e .NET come architetture di riferimento in contesti Enterprise. Nonostante questa percezione del mercato, e un’immagine di più affidabilità e professionalità di J2EE, il PHP è tre volte più popolare di JSP in termini di numero di URL (Fonte: Google).
È inoltre interessante notare la costante crescita del PHP in numero di domini, anche a fronte di un numero abbastanza statico di server/IP, che porta ad un totale di quasi 17.000.000 di siti sviluppati con il PHP.
La figura seguente mostra come il trend di lungo termine nella percezione dei vari linguaggi in quanto a presenza di figure professionali, corsi di formazione e certificazioni veda un erodersi in termini percentuali della quota del Java, in grosso favore del PHP (e anche di Python) che vede una notevole crescita avvicinandosi alla percentuale del Java.
È da notare invece come la situazione del C# di Microsoft sia abbastanza statica; tuttavia, alcune considerazioni sulla forza commerciale ed il sostanziale controllo di alcuni settori di mercato di Microsoft inducono a prevedere che nel medio termine il linguaggio C#, e di conseguenza l’architettura .NET (sebbene quest’ultima non sia limitata al solo C#), registrino significativi aumenti in percentuale di mercato.
Bisogna inoltre considerare la specularità nei macro vantaggi di Java e .NET: il primo è pensato come linguaggio robusto in grado di essere eseguito su ogni piattaforma per la quale esista una Java Virtual Machine (architettura multipiattaforma), il secondo è invece pensato come architettura destinata ad un determinato sistema operativo forte nel mercato, in grado tuttavia di eseguire più linguaggi (architettura in multilinguaggio).
È ipotizzabile che le grandi aziende adottino una miscela di entrambe le tecnologie, al fine di beneficiare di entrambi i macro vantaggi e comunque diminuendo ulteriori vendor lock-in.
In tal senso, il PHP ha il grosso vantaggio di eliminare alla base il concetto di vendor lock-in, data la sua natura open source basata su un’ampia comunità di sviluppatori ed utenti che possono influenza il processo di sviluppo del linguaggio.
Inoltre, poiché con l’utilizzo di piattaforme x86 e di Linux le aziende si sentono protette dal vendor lock-in anche in termini di infrastruttura, la portabilità delle applicazioni, tipica di Java, non è più un requisito.
Come poi si vede dalla successiva tabella comparativa, il PHP 5 è infine pressoché indistinguibile da Java, in termini di strutture di linguaggio e anche di stile, sintassi e parole chiave.
| Caratteristiche | PHP 5 | Java |
|---|---|---|
| OOP (programmazione orientata agli oggetti): un’applicazione consiste di una collezione di oggetti interagenti, ognuno dei quali comprende una struttura dati e un’insieme di operazioni che possono esserle applicate. Gli oggetti aiutano il programmatore a gestire la complessità dei sistemi software, migliorandone la comprensibilità, la riutilizzabilità e la robustezza. | sì | sì |
| Identità: Ogni oggetto è unico, perciò due oggetti sono distinti anche se i loro attributi sono identici | sì | sì |
| Classificazione: Ogni oggetto è istanza di una “classe”, che rappresenta un insieme di oggetti aventi le stesse proprietà. | sì | sì |
| Ereditarietà | si, ereditarietà singola | si, ereditarietà singola |
| Polimorfismo e “dynamic binding” | sì | sì |
| Incapsulamento | sì | sì |
| Neutralità e Portabilità | il PHP è un linguaggio interpretato e come tale viene eseguito dall’interprete specifico per la macchina su cui sta avvenendo l’esecuzione | Il codice viene compilato in bytecode, che viene interpretato ed eseguito dal sistema runtime di Java su un qualsiasi calcolatore |
| aritmetica dei puntatori | no (solo riferimenti) | no (solo riferimenti) |
| typing delle variabili | loosely typed | strongly typed |
| gestione delle eccezioni | si (meccanismo try+catch) | si (meccanismo try+catch) |
| strutture di controllo (if…else, while, for, …) | si, tutte | si, tutte |
| reflection | sì | sì |
| allocazione degli oggetti | dinamica | dinamica |
| distruzione oggetti/garbage collection | distruzione automatica degli oggetti | garbage collection |
| possibilità di utilizzo di variabili globali | si | no |
| tipi di dato | boolean, integer, float, string, array, object | boolean, char, byte, short, int, long, float, double, String, Array, Object |
| Variable variable names (variabili che contengono nomi di altre variabili) |
sì | no |
| dichiarazione di costanti | sì | sì |
| method overloading | no | sì |
| funzioni con numero variabile di argomenti | sì | no |
| object serialization | sì | sì |
| interfacce | sì | sì |
| oggetti astratti | sì | sì |
| Scope delle variabili | public, private, protected | public, private, protected |
| programmazione concorrente | no | sì, tramite threads |
| open source | sì | no |
| strutture necessarie all’esecuzione | interprete PHP | Java virtual machine |
| costruzione di eseguibili stand-alone | sì | sì |
Tale somiglianza fa in gran parte decadere la tipica obiezione del mondo Java verso quello PHP, che porta al motto “fai la cosa nel modo giusto” di Java, in contrapposizione a quello del PHP “fai effettivamente la cosa e in tempo” (questo poiché i progetti Java hanno un tasso di insuccesso molto più alto di quelli PHP). La notevole somiglianza del linguaggio PHP nella sua ultima major version 5 al Java, consente infatti di avvicinarsi maggiormente ad una sintesi dei due motti: “fai la cosa nel modo giusto ed in tempo”.
Il PHP 5 infatti non forza lo sviluppatore ad eccessivi formalismi rispetto alle dimensioni dell’applicativo da realizzare, così come invece consente di utilizzare costrutti e caratteristiche più robusti tipici del mondo Java.
Ciò che tuttavia manca al PHP 5 è la definizione di un’architettura sovrastante che definisca una metodologia ed un insieme di specifiche per sviluppare applicazioni che soddisfino quei requisiti elencati nell’introduzione che derivano da un contesto di natura distribuita con un carico crescente.
Nel mondo PHP prevale infatti il concetto che “ci sono molti modi per ottenere il risultato”; ciò porta grossi vantaggi in termini di tentativi di studiare nuove forme di organizzare e disegnare l’architettura del codice, ma più spesso significa anche che non viene adottata nessuna architettura; né, in ogni caso, vi sono già architetture, ad eccezione della iConnect Architecture, che è stata studiata, progettata ed implementata proprio in questa ottica.
La maggior parte dei framework esistenti in PHP infatti si limitano ad essere orientati ad un dominio di problematiche legate a prodotti CMS, senza invece affrontare le questioni inerenti i requisiti non funzionali.
Sebbene vi sia questo divario in termini di architettura che si cerca di colmare con la iConnect Architecture, a sua volta il Java soffre di un eccesso di architettura, anche in termini di formalismi: si ha infatti spesso la sensazione che molti sviluppatori J2EE vivano in una sorta di “torre d’avorio” isolata dalla concretezza dei problemi aziendali.
Il contesto J2EE è infatti sempre più costituito da un ammasso di API spesso incoerenti e incomprensibili, che rendono sempre più difficoltosa la realizzazione di quel tipo di applicazioni che si limitano a fare da front end HTML ad un database relazionale e che costituiscono l’80% delle applicazioni J2EE realizzate (fonte Gartner).
Analizzando poi ciò che essenzialmente fa la maggior parte delle applicazioni, si nota che, di base, esse producano più che altro del semplice testo (es.: HTML, XML, …). Ciò, combinato alla sempre maggior diffusione dei Web Services, porta alla conseguenza che anche il back-end produca essenzialmente documenti XML piuttosto che formati binari.
Sintetizzando quindi i vari elementi fin qui portati, si delinea la seguente situazione in quanto a requisiti per le odierne applicazioni aziendali:
- gestire XML efficientemente;
- processare velocemente i testi all’interno ed all’esterno degli oggetti;
- la maggior parte delle applicazioni hanno una logica limitata consistente principalmente nel controllare i flussi;
- non vi è necessità di portabilità oltre a Linux/x86 e Windows x/86;
- profilate per piattaforme x86 mono/bi-processore.
A fronte di questi requisiti e vincoli, Java dimostra di non essere la miglior scelta:
- i documenti XML sono evidentemente non tipizzati e devono essere scalciati dentro e fuori di Java, che è un linguaggio strong typed;
- Java è molto scarso nel processare testi in quanto non può manipolare le stringhe direttamente;
- mentre Java è ben adatto per applicazioni complicate, non è particolarmente indicato per il controllo di flusso;
- Java è ottimale nella portabilità tra piattaforme, ma questo non è più un requisito oltre a Windows e Linux;
- poiché non c’è più il requisito di portabilità, gli sviluppatori richiedono un overhead minimale, mentre invece Java porta con sé una pesante virtual machine tra l’applicazione ed il sistema operativo: molte implementazioni J2EE richiedono macchine SMP con 4-16 processori.
Si profila quindi la necessità di disporre di un linguaggio loosely typed, al fine di incapsulare agevolmente documenti XML, e che sia in grando di processare molto efficientemente del testo; inoltre, il linguaggio deve essere sufficientemente versatile nel controllo di flusso e deve fornire uno strato leggero al di sopra del sistema operativo.
Dei vari linguaggi che secondo il trend di cui all’illustrazione 9 sono più vitali, il PHP risulta essere il candidato migliore, perché è il più diffuso e risponde a queste caratteristiche:
- linguaggio idoneo a gestire strutture dati lasche come quelle dei documenti XML;
- presenza di un sistema per accedere molto facilmente alla struttura di documenti XML;
- altamente specializzato nel processare testi;
- molto versatile nel controllo di flusso;
- molto sviluppato e testato su piattaforme Linux/x86 e Windows/x86;
- molto vicino al “metallo”, data la sua origine come linguaggio di scripting;
- ottimizzato per macchine x86 mono/bi-processore.
Infine, il linguaggio PHP è facile da imparare ed utilizzare, oltre ad essere open source.
Conclusioni
La previsione d’insieme è che il trend tecnologico, in luce delle considerazioni di cui nel capitolo precedente, porti a:
- una configurazione infrastrutturale a griglia;
- un player dominante identificato in Linux;
- un linguaggio prevalente identificato nel PHP, supportato da un’architettura.
Tutto ciò giustifica la creazione e l’adozione di un’architettura quale la iConnect Architecture, in quanto ben si adatta alla situazione appena delineata.
Revisione del 2008: la iConnect Architecture è ora parte integrante di Innomatic., la piattaforma open source per realizzare applicazioni web multi-tenant.
