Java 6: le novità Enterprise

I parte: la direzione intrapresadi

A quasi 10 anni dalla sua prima apparizione, la piattaforma Java EE si appresta ad affrontare un nuovo capitolo con l‘imminente rilascio della specifica Java EE 6 prevista per questo mese. Tra le novità presentate ve ne sono tre indirizzate specificamente al problema della complessità della piattaforma.

Introduzione

Il linguaggio Java esiste da poco meno di quindici anni. E da poco meno di dieci esiste la piattaforma Enterprise. È un periodo lungo, da un punto di vista informatico, ma molti di "quelli che c'erano" allora sono ancora in pista e hanno vissuto in prima persona le trasformazioni (non sempre lineari) della piattaforma Standard e successivamente di quella Enterprise, nonche‘ la strana parabola della Micro Edition. Parallelamente, hanno anche assistito all'affermazione tutto sommato universale di Java Enterprise come piattaforma affidabile e "professionale" dalla quale non si può prescindere quando si intenda sviluppare applicazioni di un certo peso, robuste e adatte a un mondo corporate.
Alla vigilia del rilascio di Java Enterprise 6, è utile pertanto fare il punto su alcune novità. In questa serie, presenteremo alcuni brevi articoli il cui scopo principale è di illustrare quanto più semplicemente possibile, gli aspetti salienti della nuova versione.

Il punto di (ri)partenza

Il problema principale della piattaforma Enterprise, emerso negli ultimi anni e già messo in luce nel Java Specification Request 316 del luglio 2007, è la complessità raggiunta dalla piattaforma. La stratificazione delle varie API, la presenza di "eredità" scomode riferite a situazioni tecnologiche ormai superate, ha portato a una complessità, a volte scoraggiante, che presenta diverse facce. A questa complessità, frutto a volte solo di ridondanze, si è cercato di porre rimedio con tre strategie: pruining, profili ed estensibilità.
La retrocompatibilità, una delle caratteristiche più notevoli di Java, ha portato nel corso degli anni a una crescita delle dimensioni della distribuzione difficile da gestire. Occorreva pertanto trovare una soluzione che da un lato riducesse complessità e dimensioni della distribuzione, ma dall'altro non creasse problemi di funzionamento con applicazioni magari non recentissime.

Pruining

Il pruining ("potatura") è un processo di "taglio"che permetterà di dismettere in modo graduale le tecnologie superate senza incorrere in problemi di compatibilità.
La prima sorgente di complessità per la piattaforma Java EE è la presenza di tecnologie obsolete, un tempo valide, ma che la comunità degli sviluppatori ha smesso di utilizzare o ha sostituito con l'adozione di altre tecnologie più recenti.

L'esempio più evidente è la CMP (Container Managed Persistence): si trattava in EJB 2.0 della capacità, da parte di container appositi, di gestire la persistenza dei bean. Tale funzionalità non ha mai preso piede davvero: di fatto è stata rimpiazzata con successo dalla Java Persistence.
Come dobbiamo considerare tali "eredità" nell'ambito della piattaforma Java Enterprise Edition? Si è capito che ormai la gran parte di queste funzionalità ridondanti costituisce un costo che non porta alcun beneficio. Per tale ragione è stato introdotto, in modo simile a quanto già fatto su Java SE il pruining, un processo multifase indirizzato alla rimozione graduale di alcune funizonalità. Cosa significa "multifase"? Significa affrontare il problema in maniera graduale, per fasi, senza tagli drastici e improvvisi che possano creare problemi di compatibilità.

In particolare nella prima fase un package viene segnalato come candidato alla rimozione. Il suo uso viene sconsigliato, ma si lascia tempo fino alla successiva release per rimettere in discussione la decisione. Nella release seguente si deciderà se mantenere il package nella condizione attuale o se procedere alla definitiva rimozione. Nella fase seguente il package diviene un requisito opzionale: i vendor non sono più tenuti a fornirne un'implementazione. Dal momento che il pruining riguarda sempre interi package, e non singole classi o metodi, diventerà possibile, all'occorrenza, reintegrare abbastanza agevolmente (diciamo così…) la funzionalità in modo da garantire la compatibilità all'indietro.

Spiegato il meccanismo di "pruining", vediamo chi è passibile di subire il taglio. Tra i package candidati alla rimozione abbiamo

  • CMP, la Container Managed Persistence già nominata
  • l'insieme di regole e funzionalità JAX-RPC (Java APIs for XML-Based RPC) che viene sostituita da JAX-WS (Java API for XML-Based Web Services)
  • la API JAXR (JSR 93, Java API for XML Registries 1.0), una libreria per l'accesso ai web service che, per varie ragioni, non ha mai riscontrato un grosso successo.

 

Profili

Un'altra faccia della complessità della piattaforma Java EE è rappresentata dalla sua grandezza: per molte applicazioni le sue dimensioni sono eccessive. Da quando è stata introdotta la Enterprise Edition (lo ripetiamo, circa dieci anni fa), i requisiti di un'applicazione enterprise sono cambiati: quello che sembrava normale nel passato è oggi visto come qualcosa di quantomeno strano: l'idea di un unico prodotto adatto a tutti è diventata sempre meno appropriata.
Ogni categoria di applicazioni utilizza di fatto un sottoinsieme abbastanza coerente delle tecnologie disponibili: la parte inutilizzata può pertanto costituire un peso sia in termini di complessità delle API che in quello della pura e semplice dimensione. Per questa ragione vengono introdotti i "profili". I profiles altro non sono che dei veri e propri sottoinsiemi della piattaforma Enterprise pensati per risolvere una particolare categoria applicativa.

L'esempio più banale è quello degli attrezzi da lavoro: alcuni strumenti "comuni", come una chiave inglese, servono tanto all'idraulico per sistemare i rubinetti che al meccanico per aggiustare l'automobile: ma l'idraulico non ha bisogno portarsi dietro nella sua cassetta, per esempio, tutti gli attrezzi e le "tecnologie" che servono al meccanico per cambiare l'olio della macchina.

Pertanto si è pensato di creare dei "kit" specializzati di attrezzi, i "profili" appunto, adatti più a certi ambiti applicativi che ad altri. In pratica, gli sviluppatori che realizzano applicazioni particolari avranno necessità solo di alcune tecnologie, di certe API e di certe risorse e potranno fare a meno delle altre.

La reale utilità dei profili è un fatto controverso. Peter Kriens dell'OSGI ha criticato pesantemente l'idea [3], sostenendo che, se è vero che una taglia non può andar bene per tutti, è a anche vero che creare nuovi tagli non è forse la soluzione migliore. I profili richiedono di identificare delle precise nicchie di utilizzo, nicchie che nel mondo reale tendono ad avere confini molto più sfumati di quanto ci si aspetterebbe. Ogni profilo richiede una specifica e ogni specifica ha un costo. Si capisce bene quanto sia importante "centrare" esattamente la definizione di un profilo... e la perfetta definizione del profilo, con le premesse suddette, non è affatto sicura.

Va notato che al momento attuale è stato definito solamente il Web Profile, un profilo indirizzato alla programmazione web: in esso mancano le complicazioni caratteristiche delle tecnologie Enterprise.

Estensibilità

La terza fonte di complessità è la presenza, in ambiente Enterprise, di molte tecnologie complementari che si prestano a essere integrate nella piattaforma. In questi anni si sono sviluppate infatti, al di fuori della "ufficialità" Java, una serie di tecnologie estremamente utili che vengono effettivamente utilizzate sul campo dagli sviluppatori.
L'estensibilità fornirà alla piattaforma Java Enterprise Edition un numero maggiore di punti d'ingresso sui quali connettere componenti esterni, in modo da permettere un'interoperabilità simile a quella delle tecnologie native.
Un'esempio di questo tipo è dato dalla JSR 196 (Java Authentication Service Provider Interface for Containers), un'interfaccia  a livello di service provider che permette di integrare nel containter meccanismi di autenticazione.
Oltre al vantaggio già citato, l'estensibilità permette di fatto di ridurre la necessità di integrare nuove tecnologie nella piattaforma: tale requisito rappresentava un'altra fonte di complessità che in tal modo viene a essere eliminata.

Conclusioni

La piattaforma Java EE compie dieci anni. In un campo in cui i requisiti cambiano in continuazione, è impossibile pensare che una tecnologia software possa raggiungere la maturità. La necessità di adeguarsi a scenari sempre nuovi ha imposto una rivalutazione di alcune scelte fatte in passato, e la definizione di nuovi processi che possano guidare lo sviluppo futuro. Pruining, Profili ed Estensibilità sono tre soluzioni per procedere in tale direzione.

Riferimenti

[1] JSR 316: JavaTM Platform, Enterprise Edition 6 (Java EE 6) Specification
http://jcp.org/en/jsr/detail?id=316

[2] "Leading-Edge Java. Java EE 6". A Conversation with Bill Shannon and Roberto Chinnici by Frank Sommers
http://www.artima.com/lejava/articles/java_ee_6.html

[3] Peter Kriens "Can Someone Tell Sun About OSGi?"
http://www.osgi.org/blog/2007/07/can-someone-tell-sun-about-osgi.html

 

 

 

Condividi

Pubblicato nel numero
140 maggio 2009
Andrea Gini è un professionista del settore aerospaziale, un consulente IT e un giornalista scientifico. La collaborazione con MokaByte, iniziata nel lontano 1999, è stata l‘unica costante in un percorso professionale che lo ha portato dalla fotografia professionale alla scienza spaziale. Attualmente lavora al Payload Safety Review Panel presso il…
Ti potrebbe interessare anche