Una panoramica sulla tecnologia J2EE di SUN

Sviluppare applicazioni di livello Enterprise è diventato, oggi, grazie a SUN relativamente semplice. Grazie, infatti, alla tecnologia J2EE (Java 2 Enterprise Edition) si possono progettare, sviluppare e gestire software che si basano su componenti standard, modulari e portabili.


Il modello multitier
J2EE utilizza, un modello software multitier e distribuito che consente di dividere la logica applicativa su più livelli (tier) che possono risiedere anche su macchine diverse. In genere i livelli sono:
♣ Client tier, che risiede sul client;
♣ Web tier, che risiede sul server J2EE;
♣ Business tier, che risiede sul server J2EE;
♣ Enterprise Information System tier (EIS), che risiede su di un server back-end.

Un classico modello di sviluppo con J2EE supera la classica suddivisione a due livelli client-server ponendo tra di essi una sorta di modello centrale (middle tier). Quindi tra la client machine e la EIS server machine si avrà la J2EE server machine (Fig.1). Ogni livello è rappresentato da componenti a se stanti, cioè da unità software scritte in Java costituite dai propri files e le proprie classi che comunicano con gli altri componenti degli altri livelli.

I livelli in dettaglio
Nel client tier rientrano:
♣ web clients, rappresentati dalle pagine dinamiche e dal web browser che le renderizza. Esse sono anche dette thin client per il fatto che eseguono parti semplici dell’intera logica applicativa;
♣ applets, rappresentati da piccole applicazioni che si eseguono nella virtual machine del web browser;
♣ stand-alone applications, rappresentate da software con una GUI (Graphic User Inteface) sicuramente più sofisticata e più ricca di contenuti di quanto una pagina HTML permetta di fare grazie all’utlizzo delle API Swing o AWT.

Nel web tier rientrano:
♣ servlets, rappresentate da classi Java che estendono le capacità di un server web permettendo
un’interazione di tipo richiesta-risposta con l’applicazione client generando contenuto dinamico;
♣ JSP pages, rappresentate da files di testo contenenti sia del codice (HTML, WML, XML) per generare contenuto statico sia del codice script-oriented (istruzioni JSP) per generare contenuto dinamico.

Nel business tier rientrano:
♣ enterprise java beans, rappresentate da componenti software che incapsulano la business logic di un’applicazione, ovvero codice che implementa classi per la gestione di complessi processi applicativi di tipo finanziario, bancario e simili che richiedono un’attenta progettazione del sistema di sicurezza, delle transazioni e dell’accesso a grandi basi dati.

Nell’ enterprise information system tier rientrano, infine, quelle infrastutture software con cui può essere necessario dialogare come sistemi ERP (Enterprise Resource Planning), mainframe, database e in genere con tutti quei sistemi che si occupano del lato back-end applicativo.

I container J2EE
Scrivere applicazioni a più livelli è generalmente complesso poiché bisogna scrivere codice per le transazioni, il multithreading, il resource pooling, la sicurezza ed in genere occuparsi anche dei dettagli low-level della piattaforma di sviluppo. L’architettura software J2EE risolve tale complessità poiché ingloba tale business logic in componenti riusabili e indipendenti dalla piattaforma. Inoltre funzionalità e servizi specifici della piattaforma (low-level) sono gestiti da apposite interfacce software tra esse e i correlativi componenti, dette containers. Lo sviluppatore deve, quindi, prima che l’applicazione venga eseguita assemblarla come applicazione J2EE e poi installarla (deploy) nel suo container settando configurazioni di sicurezza, di transazione, di connettività remote e così via (Figura 2).

Avremo quindi un:
♣ application container, che gestisce l’esecuzione delle applicazioni che girano lato client;
♣ applet container, che gestisce l’esecuzione delle applets ed è rappresentato dal web browser e dal plug-in java e gira lato client;
♣ web container, che gestisce l’esecuzione delle pagine JSP e delle servlets e gira lato server;
♣ EJB (Enterprise JavaBeans) container, che gestisce l’esecuzione dei beans e gira lato server.
I moduli J2EE
Un modulo J2EE è rappresentato da componenti software dello stesso container e da un file XML detto deployment descriptor che ne descrive i settaggi e che viene letto a run-time da un server J2EE al fine di svolgerne le azioni ivi indicate.
Si hanno i seguenti moduli:
♣ application client modules, assemblati in un file di tipo JAR con estensione .jar contenenti files di classi ed un descrittore di deployment;
♣ web modules, assemblati in un file di tipo JAR con estensione .war (Web ARchive) contenenti files JSP, files di classi per le servlets, files HTML, files GIF e il proprio descrittore di deployment;
♣ enterprise javabeans modules, assemblati in un file di tipo JAR con estensione .jar contenenti files di classi per gli enterprise beans e il proprio descrittore di deployment;
♣ resource adapter modules, assemblatati in un file di tipo JAR con estensione .rar (Resource Adapter ARchive) contenenti interfacce JAVA, classi, librerie native e il proprio descrittore di deployment per i sistemi EIS (Enterprise Information System).

Tutti questi moduli, se rappresentano un’applicazione completa che li impiega, vengono assemblati in un file di tipo JAR con estensione .ear (Enterprise Archive).
Iter e processi di un’applicazione J2EE
La possibilità di avere un’infrastruttura modulare consente di dividere i processi di sviluppo e di deploy in differenti ruoli gestiti da aziende o persone diverse se il software da sviluppare è complesso e importante.

Potremmo avere pertanto un ruolo di modules developers fornito dalle seguenti persone:
♣ application client developer, che sviluppa il modulo client:
♣ scrivendo e compilandone i sorgenti;
♣ impostandone i settaggi nel descrittore per il deploy;
♣ assemblandone i files .class e il file di descrittore nel file JAR.
♣ web developer, che sviluppa il modulo web:
♣ scrivendo e compilando i sorgenti delle servlets;
♣ scrivendo files JSP e HTML;
♣ impostandone i settaggi nel descrittore per il deploy.
♣ assemblandone i files .class, .jsp, .html e il file di descrittore nel file WAR;
♣ enterprise beans developer, che sviluppa il modulo EJB:
♣ scrivendo e compilandone i sorgenti;
♣ impostandone i settaggi nel descrittore per il deploy;
♣ assemblandone i file .class e il file di descrittore nel file EJB JAR.

Dopo lo sviluppo dei moduli potremmo avere un ruolo di application assembler dove un’azienda o delle persone ricevono i moduli sviluppati e li assemblano in un file EAR, specificandone il descrittore e controllando che i contenuti del file EAR sia conforme alle specifiche J2EE.

Infine potremmo avere un ruolo di application deployer e di administrator dove un’azienda o delle persone installano e amministrano l’applicazione nell’infrastruttura di rete dove girerà il software J2EE. Nella sostanza esse aggiungeranno il file EAR nel server J2EE configurandone il descrittore per l’ambiente operativo di esecuzione e dopo aver controllato la rispondenza dell’applicazione EAR alle specifiche J2EE provvederanno alla sua definitiva installazione nel server di produzione.
J2EE APIs
La piattaforma di sviluppo J2EE è costituita dalle principali seguenti APIs (Application Programming Interface):
♣ Enterprise JavaBeans Technology, per implementare la business logic dell’applicazione;
♣ JDBC (Java Database Connectivity), per utilizzare database;
♣ Java Servlet Technology, per avere specifiche classi che estendono le capacità di un server fornendone un modello di tipo request-response;
♣ Java Server Pages Technology, per avere in un normale documento di testo codice di scripting per la generazione di pagine dinamiche;
♣ JMS (Java Message Service), per la creazione, inoltro, ricezione e lettura di messaggi asincroni che i componenti software si possono scambiare;
♣ JNDI (Java Naming And Directory Interface), per fornire alle applicazioni un servizio di naming e di directory permettendo l’associazione e la ricerca di attributi ad oggetti Java di ogni tipo;
♣ JTA (Java Transaction API), per gestire sistemi di transazioni e governarle attraverso le classiche clausole begin/commit/rollback;
♣ Java Mail, per la gestione dei servizi di posta elettronica;
♣ JAXP (Java API for XML Processing), per la gestione di documenti XML;
♣ JAAS (Java Authentication and Authorization Service), per implementare un sistema di sicurezza attraverso fasi di autenticazione ed autorizzazione di utenti e gruppi;
♣ JAX-RPC (Java API for XML-based RPC), per sviluppare web services.
Aspetti conclusivi
Questa breve e concisa disamina della piattaforma di sviluppo J2EE ha voluto porre in evidenza come essa si presti ad essere uno strumento essenziale per la costruzione di potenti applicazioni n-tier di fascia enterprise grazie alla sua natura portabile, modulare e scalabile che nelle moderne infrastrutture software rappresentano un notevole vantaggio in termini di risparmio di mezzi e risorse.