Questo nuovo cuore del sistema si è arricchito di componenti e tool destinati a gestire le reti wireless, i siti e-commerce, i portali e l’integrazione di applicazioni. Su Java 2 Enterprise Edition molti degli sviluppi più interessanti.
Grazie al fatto che si basa su una tecnologia e una struttura da tempo consolidate, l’application server svolge oggi un compito chiaro e ben definito. A questa situazione si è però giunti dopo un lungo periodo volto a ricercare la normalizzazione delle architetture software. Dopo aver trascorso molti anni tentando di standardizzare le interfacce di programmazione del sistema operativo Unix, l’Open Group, fusione tra X/Open e Osf (The Open Software Foundation), alla metà degli anni 90 ha iniziato a insistere sull’imperativo di avere ambienti distribuiti aperti e normalizzati. In virtù di ciò, tutte le attenzioni si sono focalizzate sul middleware, ovvero su un ambiente tecnologico destinato a far comunicare due componenti applicativi distanti.
Tanto più che, trascorsa l’epoca dei sistemi centralizzati e monolitici, il client-server ha portato a un’eterogeneità galoppante dei vari "mattoni" che compongono i sistemi informativi. Da qui è sorta la necessità di gestire l’interoperabilità, fatto questo che ha dato vita al momento di gloria dei monitor transazionali proprietari, come per esempio Tuxedo ed Encina.
Un boom legato al Web
L’esplosione di Internet non ha fatto che accrescere il modello di un’informatica orientata alla rete, ripartita e basata su un’architettura a diversi livelli (presentazioni, elaborazione e archiviazione dei dati e così via). Nel 1998, mentre si assisteva al confronto tra i modelli a oggetti distribuiti Com/Dcom (Microsoft) e Corba (Omg), Sun ha pubblicato la prima specifica del suo modello, chiamato Enterprise Javabeans (Ejb). Ed è a partire da questa data che si è cominciato a parlare di application server, presentandolo come il sistema operativo Internet. C’è chi invece lo ha definito un ambiente dell’architettura che fornisce i "mattoni" tecnici necessari all’esecuzione di applicazioni transazionali su Web. Sotto questa definizione è possibile raggruppare diversi tipi di piattaforme software: il quartetto Lamp (Linux, Apache, MySql e Php), .Net di Microsoft e J2ee (Java 2 Enterprise Edition) di Sun. Quest’ultima, ormai ben lontana dal riassumersi nel solo Ejb, può contare oggi su un ampio consenso. Tuttavia, il riallineamento a J2ee non è sinonimo dell’adozione dell’insieme dei servizi tecnici offerti da questa piattaforma.
Secondo un rapporto redatto da Gartner Group, lo scorso anno Ejb è stato globalmente utilizzato nell’8% dei progetti Internet. Un tasso di utilizzo che per l’ensamble formato dalle componenti Servlet e dalle pagine Jsp (Java Server Pages) ha superato il 60%.
Nel proprio ruolo di prescrittore di tecnologia, alcuni pensano che Ibm eviti di incoraggiare l’uso di Ejb. Infatti, ha dotato il prodotto Websphere unicamente del supporto della versione 1.0 di Ejb, che per altro è un’edizione piuttosto rudimentale. Per disporre della conformità con la release 1.2 di Ejb occorrerà attendere la versione 4 dell’application server di Big Blue. I responsabili di Borland hanno sostenuto che Ibm abbia posto un freno all’impiego di Ejb. In realtà, hanno detto, queste componenti hanno indiscutibilmente delle lacune, ma ciò non giustifica il comportamento di Ibm.
Il tallone d’Achille di Ejb
Commenti di Borland a parte, è un fatto indiscusso che Ejb abbia un proprio tallone d’Achille, il che fornisce una motivazione meno polemica alla sua scarsa diffusione: la specifica delle componenti Ejb, detta Entity Beans, che è preposta ad assicurare la persistenza di oggetti dei dati contenuti nel database relazionale è stata descritta a livello industriale. E ciò ha spinto la stessa Sun a riscriverla interamente nella versione 2.0 di Ejb al fine di consentirle di farsi carico della nozione di associazione tra gli oggetti. Questo difetto non è però un ostacolo, infatti negli scorsi anni gli editori di server di applicazioni si sono lanciati in una corsa sfrenata alla certificazione J2ee. E ciò, nonostante J2ee porti a una semplificazione della struttura applicativa per il Web, pone un serio problema per i fornitori di applicativi: come differenziarsi rispetto alla concorrenza?
La soluzione consiste nell’allargare lo spettro funzionale dei propri motori per il deployment. In questo modo sono apparsi nel corso del tempo framework dedicati all’identificazione dei siti di commercio elettronico, come per esempio Weblogic Commerce Server di Bea, un’estensione alla quale conviene associare i server di personalizzazione (Websphere Personalization Server o Weblogic Personalization Server). Nell’attesa di nuove opportunità apportate dall’m-commerce, i server J2ee si sono arricchiti di moduli per la creazione di applicazioni wireless da portare sui terminali leggeri (telefoni, Pda e via dicendo). Quanto alle più recenti anticipazioni degli editori, queste si basano sull’aggiunta di framework nell’ambito dei portali aziendali e dell’integrazione di applicazioni in un contesto di scambi elettronici tra le imprese.
