Qualche mese fa abbiamo iniziato un incredibile viaggio nel mondo di Java attraverso un’avvincente retrospettiva scritta in collaborazione con Danilo Ventura, Senior Software Engineer di Bitrock. Possiamo andare avanti nella nostra narrazione descrivendo ciò che è accaduto nei primi anni 2000.
Da Java Server Pages alle Architetture SOAP
Come abbiamo visto nel precedente articolo, le servlet Java consentivano un maggior grado di interattività e dinamicità nel design delle applicazioni Web. Tuttavia, esisteva ancora una limitazione significativa. I server potevano produrre solo pagine HTML statiche, senza elementi variabili. All’interno di una Servlet si doveva scrivere tutto il codice di ogni pagina html mettendo insieme dati variabili (ad esempio provenienti da un DB) e dati statici.
Per semplificare il processo, nel 1999 Sun Microsystems rilasciò la prima versione di una nuova tecnologia rivoluzionaria: Java Server Pages (JSP). Con le pagine JSP era possibile inserire in una pagina HTML parti di scripting in linguaggio Java, creando una “pagina JSP”. Le JSP venivano tradotte in Servlet e quindi compilate. Con le Java Server Pages e le Servlet nacquero le pagine lato server. Questo significa che le pagine non erano più statiche (ferme e immutabili come le pensavano i creatori di siti web): al contrario, venivano generate dinamicamente sul lato server, utilizzando le JSP come modello con contenuti dinamici all’interno.
Siamo arrivati ai primi anni 2000: in questi anni emergono i primi framework Java per la scrittura di applicazioni web. I più rilevanti sono Velocity (un motore di template, più che un framework), Struts e poi Struts2. Tool come questi sono stati i primi tentativi di applicare il pattern M.V.C. allo sviluppo di applicazioni web. Struts e Struts2 si basavano su XML (“eXtensible markup language”), progettato per essere un linguaggio di markup leggibile dall’uomo e dalla macchina per gestire il trasporto dei dati. XML è nato come formato di scambio di dati, ma è stato anche (ab)usato come linguaggio di configurazione.
Gli Enterprise Java Beans e l’Era del Web 1.0
Un’altra tecnologia java, Enterprise Java Beans (EJB), diede un forte contributo alla diffusione e allo sviluppo delle applicazioni distribuite. Possiamo descrivere EJB come una tecnologia per la creazione di componenti server modulari, scritti nel linguaggio di programmazione Java, che vengono impacchettati e distribuiti seguendo rigidi standard, ideali per la distribuzione in ambienti enterprise.
EJB è una tecnologia molto potente e complessa, ancora oggi utilizzata nella versione di specifica 3.0,. Gli Enterprise Java Beans sono basati su application server: non si tratta più di semplici web server o servlet engine. Per eseguire gli EJB, gli sviluppatori necessitano di application server che mettano a disposizione un intero substrato (chiamato EJB Container) grazie al quale, ogni volta che l’applicazione viene distribuita, viengano generati una vasta gamma di componenti runtime, creando un vero e proprio ecosistema che permetta all’applicazione di interagire con le risorse del server. Molte software house, all’epoca, avevano un proprio prodotto di EJB Application Server: WebSphere di IBM, Weblogic di BEA Systems (poi acquisita da Oracle) e, naturalmente, erano presenti anche prodotti open source come JBoss, Apache TomEE e GlassFish.
Lo sviluppo di applicazioni per questa tecnologia era piuttosto complicato, dal momento che i professionisti dovevano occuparsi non solo di operazioni di scrittura del codice, ma anche di azioni ripetitive: lanciare i programmi, impacchettare l’applicazione in un certo modo, avere le corrette dipendenze di libreria per i progetti e così via. Tutti questi compiti venivano svolti manualmente: come si può immaginare, la possibilità di errore era particolarmente elevata. Inoltre, per gli sviluppatori generare tutti questi pacchetti da distribuire sui server delle applicazioni rappresentava un’enorme perdita di tempo (che poteva essere dedicato allo sviluppo).
Ciò ha portato alla necessità di creazione di nuovi strumenti in grado di risolvere queste esigenze. Il primo strumento di build nell’ecosistema java a comparire fu Ant. Ant era uno strumento molto innovativo in quanto, sempre tramite XML, era possibile scrivere procedure da eseguire all’interno del mondo Java. Attraverso uno script Ant in XML, si poteva eseguire una sequenza di operazioni, come copiare e archiviare file, spostare alcune parti in una specifica cartella, creare un archivio Java da quella cartella e spostarlo altrove. In questo modo era possibile automatizzare una serie di operazioni. Inoltre era possibile scrivere in java task personalizzati che potevano essere adoperati all’interno del file xml di build.
Ant è arrivato nel 2002, seguito da Maven nel 2004 (ancora oggi utilizzato). Infine, Gradle è apparso intorno al 2012. Maven, oggi, permette ad uno sviluppatore Java di gestire tutte le dipendenze e il ciclo di vita della sua applicazione in modo standard. Tutti questi strumenti, risolvendo una serie di problemi, sono stati essenziali per garantire la sopravvivenza di Java, che altrimenti si sarebbe estinto.
Nei primi anni 2000 – l’era del Web 1.0 – esistevano alcune alternative a Java. Alcuni esempi? PHP, C# e Microsoft .NET (la tecnologia Microsoft per la costruzione di applicazioni Web in ambienti Windows).
Questo è stato anche il periodo di gloria di altre tecnologie che si presumeva avrebbero avuto un successo esplosivo. A partire da Adobe Flash. All’epoca, se non avevi un’animazione Flash sul tuo sito web, eri considerato un perdente! Per questo motivo, Adobe lanciò questa tecnologia che permetteva ai programmatori di creare, grazie a un linguaggio basato principalmente su Javascript e XML, un codice che veniva eseguito dai browser attraverso un apposito tag HTML che veniva generato.
Java 5
Il 2004 è stato un anno di svolta, segnato dall’arrivo di una versione di Java che per molti aspetti è ancora considerata rivoluzionaria: Java 5. Java 5 presentava alcune nuove caratteristiche, come i generics (ripresi dal linguaggio C), le annotation, le enumeration, i vararg, gli static import. I programmatori di Sun Microsystem e le comunità Java, infatti, si resero conto che in quegli anni le evoluzioni erano veloci e, se volevano rimanere competitivi e rendere Java un linguaggio moderno, avrebbero dovuto introdurre ulteriori funzionalità.
Il fatto di non essere un linguaggio statico e di evolversi continuamente nel tempo è stata una delle carte vincenti che ha permesso a Java di sopravvivere nel lungo periodo. Grazie all’implementazione di nuove funzionalità, le esigenze degli sviluppatori sono sempre state soddisfatte. Java, infatti, è open-source: tutti gli sviluppatori Java possono scaricare i sorgenti e segnalare all’interno della comunità le funzionalità che vorrebbero fossero implementate. Vengono poi realizzate le features che ricevono il maggior numero di voti da parte della comunità.
In quegli anni cominciarono ad evolversi anche le architetture basate sui servizi e le aziende iniziarono a rendersi conto che il mainframe sarebbe stato destinato a scomparire presto. Tuttavia, all’interno delle aziende c’era la necessità di mantenere la condivisione dei dati disponibili attraverso i servizi.
Si rese necessario stabilire uno standard per lo scambio di dati strutturati che ne permettesse lo scambio tra sistemi realizzati con tecnologie differenti. Questo spazio fu occupato dall’XML che per sua natura divenne lo standard de facto nello scambio di informazioni tra diversi sistemi.
Nascono le prime architetture orientata ai servizi (SOA) basata su un protocollo SOAP in grado di scambiare dati tra più tecnologie e in diversi formati. Tra il 2006 e il 2009 sono state implementate nuove soluzioni, per situazioni sempre più complesse, come, ad esempio, glienterprise service bus (ESB), che risolvono in modo brillante il problema della comunicazione punto a punto tra diverse tecnologie software.
Java fa parte di questa rivoluzione e non è più solo un linguaggio per applicazioni web, ma si sta evolvendo per seguire i nuovi requisiti del mondo dei server ed enterprise.
Seguici su LinkedIn e resta sintonizzato per i prossimi interessanti articoli di tecnologia sul nostro blog!
Si ringrazia Danilo Ventura per il prezioso contributo a questa serie di articoli.
