Introduzione
Nel mondo contemporaneo delle applicazioni complesse distribuite, caratterizzato dalla velocità dell'e-business, la
rapida immissione delle applicazioni aziendali sul mercato risulta decisiva. Ciò significa che il team di progetto non
può perdere tempo sviluppando servizi a livello di sistema, come connettività remota, denominazione, persistenza,
sicurezza o gestione delle transazioni. È necessario che il team di progetto possa sviluppare e utilizzare componenti
portatili, riutilizzabili; è consigliabile non perdere tempo reinventando architetture già consolidate e attinenti
all'originale.
J2EE™ (Java™ 2 Platform Enterprise Edition) fa fronte alla necessità appena esposta fornendo un framework ben
documentato, basato sugli standard, per lo sviluppo e l'esecuzione di applicazioni Java multi-tier distribuite, basate
sui componenti. La complessità di basso livello delle applicazioni, come connettività remota, denominazione,
persistenza, sicurezza e gestione delle transazioni, viene gestita quasi esclusivamente dal framework citato in
precedenza; in questo modo gli sviluppatori possono concentrarsi sulla logica di business delle applicazioni.
La piattaforma J2EE comprende:
-
Un insieme di standard relativi ai componenti e alle piattaforme J2EE sui cui vengono eseguiti i componenti.
-
Un piano per lo sviluppo delle applicazioni, che descrive nei dettagli la piattaforma J2EE e fornisce informazioni
relative alla solidità settoriale e alla procedura ottimale per sviluppare le applicazioni J2EE.
-
Un'implementazione del riferimento della piattaforma J2EE, fornita da Sun Microsystems Inc. come uno standard
rispetto al quale misurare i prodotti commerciali J2EE. Tale implementazione include le applicazioni
esemplificative pienamente sviluppate.
-
Una suite di test di compatibilità, per verificare e valutare le implementazioni commerciali J2EE rispetto ai
relativi standard.
La piattaforma J2EE è simile ai servizi forniti dai tool di programmazione utilizzati dal sistema operativo del
computer, il quale fornisce servizi standard dove è possibile sviluppare ed eseguire applicazioni, senza interessarsi
alla gestione dell'accesso a disco, memoria, output video, rete, ecc. È necessario occuparsi dei dettagli delle proprie
applicazioni e non di quelli relativi al sistema sottostante. La piattaforma J2EE fornisce un sistema operativo
sofisticato per le applicazioni aziendali.
Utilizzando la piattaforma J2EE, lo sforzo di sviluppo si semplifica in modo che il team di progetto possa concentrarsi
sulla logica di business dell'applicazione invece che perdere tempo dedicato allo sviluppo critico per risolvere
problematiche a livello di sistema. È più probabile che un team di progetto, interessato più all'operato delle
applicazioni che alla produzione di tutti i servizi sottostanti necessari all'applicazione, produca un sistema preciso
e libero da errori che soddisfi i requisiti dell'utente.
Per ulteriori informazioni, vedere la panoramica della piattaforma J2EE di Sun sul sito http://java.sun.com/. Seguire i link Products & API > J2EE™ (Java™ 2 Platform, Enterprise
Edition) > Overview.
Sviluppo J2EE in breve
Dalla prospettiva di uno sviluppatore di applicazioni:
-
Acquisto di una piattaforma commerciale J2EE, come server compatibile con J2EE (il comportamento del server J2EE
viene specificato dal relativo standard).
-
Sviluppo o acquisto di componenti J2EE già pronti.
-
Distribuzione ed esecuzione di componenti J2EE sul proprio server compatibile con J2EE,
che fornisce tutti i servizi necessari ai componenti J2EE.
Un esempio molto semplice di applicazione J2EE è un sito e-commerce, dove un client (utente) utilizza un browser Web
per l'accesso remoto ad un server J2EE, che a sua volta fornisce servizi a livello Web e a livello Business e interagisce con un livello Sistemi di informazione
aziendale (back end) che consente l'accesso a RDBMS.
Perché utilizzare J2EE?
La piattaforma J2EE per lo sviluppo dell'e-commerce di Java o dell'applicazione Enterprise verrà utilizzata se si
verificano le seguenti condizioni:
Ogni condizione verrà esaminata nella parte rimanente di questa sezione, aggiungendo ulteriori dettagli.
Framework
standardizzato e collaudato
I componenti J2EE vengono eseguiti in contenitori J2EE,
forniti di solito come parte del server compatibile con J2EE. Tali contenitori offrono un insieme di servizi standard
(API) utilizzati dai componenti J2EE. Le API sono:
-
J2SE 1.4
-
JDBC
-
Java IDL
-
RMI-IIOP (Remote Method Invocation with CORBA's Internet Inter-ORB Protocol)
-
JNDI (Java Naming and Directory Interface)
-
JAAS (Java Authentication and Authorization Service)
-
JTA (Java Transaction API)
-
JavaMail
-
JMS (Java Message Service).
Per maggiori informazioni su JMS, vedere Concetto: JMS (Java Messaging Service).
-
JAF (JavaBeans Activation Framework)
-
EJB (Enterprise JavaBeans)
-
Servlet Java
-
JAXP (Java API for XML Processing)
-
Connettore Java (Nota: non supportato da versioni precedenti a J2EE 1.3)
-
JSP (JavaServer Pages)
-
Servizi Web per J2EE (Nota: non supportati da versioni precedenti a J2EE 1.4)
-
JAX-RPC (Java API for XML-based RPC) (Nota: non supportato da versioni precedenti a J2EE 1.4)
-
SAAJ (SOAP with attachments API for Java) (Nota: non supportato da versioni precedenti a J2EE 1.4)
-
JAXR (Java API for XML Registries) (Nota: non supportato da versioni precedenti a J2EE 1.4)
-
Gestione di J2EE (Nota: non supportato da versioni precedenti a J2EE 1.4)
-
JMX (Java Management Extensions) (Nota: non supportato da versioni precedenti a J2EE 1.4)
-
Distribuzione di J2EE (Nota: non supportato da versioni precedenti a J2EE 1.4)
-
JACC (Java Authorization Service Provider Contract for Containers) (Nota: non supportato da versioni
precedenti a J2EE 1.4)
I componenti e le applicazioni J2EE possono essere trasferiti a server compatibili con J2EE, senza necessarie modifiche
di codice; in questo modo è possibile distribuire le applicazioni al server scelto, aggiornando informazioni di
distribuzione specifiche del server contenute nei file descrittori di
distribuzione di XML (eXtended Markup Language).
La standardizzazione delle specifiche J2EE ha portato alla competizione settoriale (è possibile scegliere server
compatibili con J2EE in base alle proprie esigenze e al budget).
Componenti riutilizzabili
Poiché risultano conformi allo standard J2EE, i componenti J2EE possono essere già acquistati e collegati alle relative
applicazioni come richiesto, risparmiando lo sforzo di sviluppo (specialmente nell'esecuzione di debug e test).
Se un componente viene sviluppato, è possibile riutilizzarlo in un'altra applicazione o distribuirlo in server
differenti compatibili con J2EE, come richiesto.
Pattern di architettura e progettazione consolidati e
attinenti all'originale
La piattaforma J2EE definisce un'architettura di applicazioni multi-tiered ben
strutturata. Potenziando l'architettura J2EE, gli sviluppatori possono continuare a far crescere velocemente la logica
di business effettiva delle applicazioni.
La documentazione J2EE include:
-
Un piano per lo sviluppo delle applicazioni, che descrive nei dettagli la piattaforma J2EE e fornisce informazioni
riguardo la solidità settoriale e la procedura ottimale per sviluppare le applicazioni J2EE.
-
Pattern J2EE ben documentati (di procedura settoriale ottimale), che descrivono soluzioni comuni a problemi
strutturali e progettuali.
Per ulteriori informazioni, consultare il sito http://java.sun.com/.
Seguire i link J2EE > Blueprint.
Scalabilità
J2EE supporta la scalabilità per aumentare le prestazioni o soddisfare carichi incrementati in diversi modi:
-
Funzioni di miglioramento delle prestazioni nel contenitore J2EE, che comprendono assemblaggio di risorse
(assemblaggio di connessioni database, di istanze di bean di sessione e di thread), trasferimento di messaggi
asincroni e gestione del ciclo di vita dei componenti efficienti. Ad esempio, l'apertura di una connessione ad un
database risulta lenta. Le connessioni ad un database inoltre possono essere una risorsa scarsa a causa di
restrizioni della licenza, ad esempio. La piattaforma J2EE gestisce la situazione appena descritta utilizzando l'assemblaggio delle connessioni del database; il contenitore J2EE mantiene
un assemblaggio di connessioni aperte che possono essere assegnate ad un componente come richiesto, che determina
connessioni veloci ed efficienti.
-
Realizzazione dell'equilibrio dei carichi tramite raggruppamento (distribuzione degli stessi componenti in
sever multipli su macchine differenti). Il carico di ciascun server può essere poi equilibrato come richiesto; ad
esempio, in base ad algoritmi round-robin o al carico del server. Le specifiche della piattaforma J2EE non
richiedono la capacità di equilibrio dei carichi in un server J2EE, ma un server high end potrebbe averla. I vendor
di server J2EE offrono varie soluzioni all'equilibrio dei carichi.
-
Partizionamento dell'applicazione (parti logicamente distinte di un'applicazione possono essere distribuite
a server differenti). Ad esempio, nel caso in cui si distribuisce online un inventario dell'applicazione
dell'ordine tramite e-mail e si esegue l'account di sottosistemi su server distinti.
Tool di sviluppo e distribuzione
In risposta alle esigenze dei tool J2EE, i vendor hanno fornito un supporto eccellente per lo sviluppo J2EE negli IDE
(Java Integrated Development Environments), che includono:
-
Procedure guidate per la creazione di servlet.
-
Procedure guidate e finestre di dialogo per la creazione e la manutenzione EJB.
-
Produzione e manutenzione di descrittore di distribuzione.
-
Oggetti EJB per la mappatura di database (inclusa la creazione di informazioni di descrittore di distribuzione per
relazioni gestite dal contenitore).
-
Integrazione con un contenitore Web per la verifica di servizi Web.
-
Distribuzione fluida, esecuzione di debug e test in IDE degli EJB mediante l'integrazione con il contenitore EJB di
J2EE e i relativi tool di distribuzione.
-
Creazione automatica di client di verifica J2EE.
-
Integrazione con tool di modellazione UML.
Integrazione di Back End
Con il termine back end si fa riferimento al livello EIS (Enterprise Information System) dell'applicazione. Ad esempio,
i sistemi di back end possono essere: RDBMS, sistemi precedenti o sistemi ERP (Enterprise Resource Planning).
J2EE supporta l'accesso transazionale agli EIS di RDBMS, utilizzando le API di JDBC e JTA. I contenitori EJB supportano
inoltre la persistenza gestita dal contenitore, che amministra automaticamente la connessione e l'accesso transazionale
di RDBMS.
Connector Architecture SPI (Service Provider Interface) di J2EE definisce uno standard per la connessione delle risorse
EIS non appartenenti a RDBMS ad un contenitore J2EE. Un adattatore di risorse specifico di EIS (fornito dal vendor EIS)
viene collegato ad un contenitore J2EE, ampliando quest'ultimo in modo che fornisca supporto sicuro e transazionale per
l'EIS. I componenti all'interno del contenitore possono accedere poi a EIS attraverso Connector Architecture SPI di
J2EE.
Nota: Connector Architecture SPI di J2EE non è supportato da versioni precedenti a J2EE 1.3.
Sicurezza
J2EE fornisce funzioni di sicurezza semplici, ma efficaci. Le informazioni sulla sicurezza per i componenti di J2EE
vengono definite nei relativi descrittori di distribuzione e delineano quali ruoli di sicurezza sono autorizzati
ad accedere ad un particolare URL e/o a metodi di un componente. Un ruolo di sicurezza è semplicemente un nome logico
per un gruppo di utenti; ad esempio, si può assegnare un ruolo denominato "responsabili" a tutti i membri di un team di
gestione dell'organizzazione.
Poiché le informazioni sulla sicurezza sono dichiarate nel descrittore di distribuzione, il comportamento di sicurezza
può essere modificato senza un ciclo aggiornamento-cancellazione errori-verifica di codice dispendioso.
Architettura multi-tier
J2EE è un'applicazione multi-tier distribuita, inclusa nell'architettura, di un livello
Client, livello Intermedio e livello EIS o back end.
La Figura 1 mostra l'architettura multi-tier di una piattaforma J2EE, nonché i molteplici contenitori J2EE che
supportano i relativi componenti.
Figura 1: Architettura Multi-tier J2EE
Livello Client
I componenti di livello Client si eseguono in contenitori client. Il livello Client può essere implementato in questo
modo:
-
Applicazioni Java autonome, ad esempio le GUI, che devono essere installate su
tutte le macchine client. Un'applicazione Java consente l'accesso al livello EIS o livello Intermedio mediante API
come JDBC.
-
Pagine statiche HTML, che forniscono una GUI limitata per un'applicazione.
-
Pagine dinamiche HTML, create da pagine JSP o da servlet.
-
Applet, che si eseguono in un browser Web. Le applet vengono inserite in una pagina HTML e
sono utilizzate di solito per fornire una GUI.
Livello Intermedio
Il livello Intermedio è formato dal livello Web e dal livello
Business. I componenti del livello Web si eseguono in un server Web J2EE che fornisce un contenitore Web. I componenti del livello Business si eseguono in un server di applicazioni J2EE che fornisce un contenitore EJB.
Livello Web
I componenti di livello Web comprendono servlet e pagine
JSP, che gestiscono le interazioni con il livello Client, le quali isolano i client dai livelli Business e EIS. I
client richiedono il livello Web, che elabora i requisiti e riporta i risultati al client. Le richieste del client ai
componenti nel livello Web generalmente risultano nelle richieste dello stesso livello ai componenti nel livello
Business, che a loro volta possono risultare nelle richieste al livello EIS.
Livello Business
I componenti del livello Business sono gli EJB.
-
Contengono la logica di business dell'applicazione.
-
Fanno richieste al livello EIS in base alla logica di business, di solito in risposta ad una richiesta dal livello
Web.
Livello EIS
Il livello EIS rappresenta i dati archiviati dell'applicazione, spesso sotto forma di un RDBMS. Il livello EIS è
formato di solito da sistemi precedenti o ERP, cui si accede tramite Connector Architecture API di J2EE.
Per ulteriori informazioni riguardo Connector Architecture API di J2EE, consultare il sito http://java.sun.com/. Seguire i collegamenti Products &
Technologies > J2EE > J2EE Connector Architecture.
Per maggiori informazioni sulle configurazioni di distribuzione standard J2EE, vedere Concetto: Configurazioni di distribuzione J2EE.
Server J2EE
I server J2EE sono prodotti commerciali che implementano la piattaforma J2EE. Esempi di server commerciali J2EE sono
BEA WebLogic, Borland Enterprise Server, IBM WebSphere e iPlanet.
L'utilizzo della terminologia "server J2EE" ha perso di importanza. Ciò significa di solito che "un server J2EE
supporta entrambi i contenitori Web e EJB". Volendo utilizzare un tipo di terminologia così ermetica, un server Web
J2EE (come Tomcat di implementazione del server Web di riferimento J2EE) supporta un contenitore Web; un server di
applicazione J2EE (o EJB) supporta un contenitore EJB.
Contenitori J2EE
I componenti J2EE si eseguono su, o sono ospitati da, contenitori J2EE di solito forniti
come parte del server commerciale J2EE. I contenitori definiscono un ambiente runtime e un insieme standard di servizi (API) per i componenti J2EE che si eseguono nel contenitore,
oltre al supporto dello standard delle API J2SE.
J2EE delinea i seguenti tipi di contenitori:
Contenitore di applicazione del client
Un client di applicazione J2EE si esegue in un contenitore di applicazione del
client, che supporta queste API di J2EE: JDBC, JMS, JAXP, JAAS, JavaMail, JAF, JSR, JAX-RPC, SAAJ, Gestione di J2EE e
JMX.
In termini pratici, l'installazione standard di J2SE comprende i contenitori del client di applicazione, chedevono
supportare l'interfaccia responsabile del richiamo JAAS per soddisfare i vincoli di sicurezza del resto
dell'applicazione aziendale nei contenitori Web e EJB.
Contenitore Applet
Un'applet si esegue in un contenitore Applet, che supporta il modello di programmazione e le API
di J2SE standard. In termini pratici, i contenitori Applet vengono supportati allo stesso modo in cui il plugin Java
supporta un browser Web.
Contenitore Web
I componenti Web (pagine JSP e servlet) si eseguono in un contenitore Web, fornito come parte di un server J2EE server o
come un server Web autonomo J2EE, che supporta queste API di J2EE: JDBC, JMS, JAXP, JAX-RPC, JAXR, JAAS, Java Mail,
JAF, Connector Architecture J2EE, JTA, JSR, SAAJ, Gestione di J2EE, Servlet di Java e JSP.
Contenitore EJB
I componenti EJB si eseguono in un contenitore EJB, fornito come parte di un server
J2EE.
Un contenitore EJB supporta le seguenti API e tecnologie di J2EE: EJB, JDBC, JMS, JAXP, JAX-RPC, JAXR, JAAS, Java Mail,
JAF, JTA, JSR, SAAJ, Gestione di J2EE e Connector Architecture J2EE.
Le sezioni secondarie riportate di seguito sintetizzano la funzionalità centrale supportata dai contenitori EJB:
Comunicazioni remote
I contenitori EJB celano la complessità delle comunicazioni remote agli sviluppatori mediante l'utilizzo di classi
fornite dal contenitore (create dai tool di contenitore quando EJB è compilato, insieme a classi di stub RMI per
l'utilizzo dei client) che implementano le interfacce EJB. Queste classi di implementazione sono oggetti remoti di Java
cui un client può accedere utilizzando RMI di Java. Dalla prospettiva del client, quest'ultimo chiama semplicemente
metodi sulle interfacce EJB, senza alcuna considerazione delle comunicazioni remote.
Simultaneità
I contenitori EJB gestiscono in modo trasparente le richieste di simultaneità di client multipli, che possono agire
come se avessero l'accesso esclusivo a EJB. Ad esempio, se due client richiedono la stessa entità EJB, il contenitore
fornisce a ciascuno le proprie istanze e gestisce sincronizzazioni internamente senza che il client lo sappia.
Denominazione
Il contenitore EJB fornisce uno spazio di nome JNDI per situare gli EJB distribuiti nel contenitore. I client EJB
possono cercare gli EJB per ottenere un'interfaccia Home. L'interfaccia Home per EJB fornisce metodi per ricercare e
creare istanze EJB. Finché il contesto di denominazione JNDI è libero dalla relativa ubicazione, i client possono
accedere a EJBs.
Persistenza
Gli sviluppatori EJB scelgono due piani per la memorizzazione di dati persistenti di EJB di entità: CMP (Container
Managed Persistence) e BMP (Bean Managed Persistence). CMP delega al contenitore la responsabilità dell'implementazione
del codice di accesso ai dati, mentre per BMP il responsabile dell'implementazione di tale codice è lo sviluppatore
EJB. CMP consente allo sviluppatore EJB di utilizzare un'implementazione standard per l'accesso alla memorizzazione
persistente mediante la dichiarazione di campi gestiti dal contenitore in un descrittore di distribuzione.
Gestione della transazione
Una transazione è una sequenza di operazioni che si succede o fallisce clamorosamente, in modo che se le operazioni
all'interno della sequenza falliscono, non è possibile effettuare modifiche allo stato del sistema. Ad esempio,
ipotizziamo che si desidera acquistare biglietti aerei: è necessario convalidare il conto della carta di credito del
cliente, effettuare l'addebito su tale conto e infine emettere i biglietti. È necessario che questa sequenza di
operazioni avvenga in una singola transazione, così che se le operazioni non vanno a buon fine, non sarà possibile
effettuare modifiche al conto della carta di credito del cliente e emettere i biglietti.
Gli EJB possono utilizzare o la demarcazione di transazione gestita dal
bean o la demarcazione della transazione gestita dal
contenitore, descritte nelle prossime due intestazioni.
Demarcazione di
transazione gestita dal bean
In una demarcazione di transazione gestita dal bean, viene utilizzata una API semplice per tracciare i limiti della
transazione. Questa è la JTA (Java Transaction API), utilizzata per controllare in modo programmatico la demarcazione
di transazione; ad esempio, chiamando i metodi begin() , commit() e rollback()
dell'interfaccia UserTransaction di JTA. Lo sviluppatore ha la responsabilità di codificare la logica rollback quando
si verificano condizioni eccezionali di transazione, poichè il contenitore non è in grado di gestirla automaticamente.
Nota: gli EJB dell'entità non possono utilizzare la demarcazione di transazione gestita dal bean, ma soltanto la
demarcazione di transazione gestita dal contenitore.
Demarcazione di
transazione gestita dal contenitore
In una demarcazione di transazione gestita dal contenitore, non è possibile fornire il codice per l'avvio e l'arresto
delle transazioni. È possibile invece fornire le informazioni di attributo della transazione all'interno del
descrittore di distribuzione EJB per ciascun metodo di EJB. L'attributo di transazione (Required, RequiresNew,
NotSupported, Supports, Mandatory o Never) suggerisce al contenitore l'ambito da utilizzare per quel metodo. Ad
esempio, se un client sta eseguendo una transazione e chiama un metodo di EJB per il quale l'attributo di transazione è
impostato su Required, allora il metodo sarà chiamato all'interno dell'ambito della transazione esistente.
Utilizzare la demarcazione di transazione gestita dal contenitore piuttosto che quella gestita dal bean, se possibile;
in questo modo non sarà necessario aggiungere, effettuare il debug e verificare il codice di demarcazione di
transazione nel proprio componente. Il comportamento di transazione di ogni metodo di EJB invece è specificato al
momento della distribuzione, all'interno del descrittore di distribuzione. Ciò significa che il comportamento di
transazione può essere modificato senza un ciclo aggiornamento-cancellazione errori-verifica di codice dispendioso.
Transazioni distribuite
Una transazione distribuita è una transazione che deve essere coordinata a database e/o applicazioni multipli. Questo
contrasta con la transazione centralizzata, così come un singolo server di applicazione J2EE che esegue transazioni
verso un unico database.
Nelle transazioni distribuite risulta necessario un metodo commit a due fasi; ad esempio, dove c'è più di un
database in fase di aggiornamento. Alcuni contenitori EJB (come BEA WebLogic Server 6.0) forniscono supporto al metodo
commit a due fasi, utilizzando il protocollo XA di Open Group. Per gestire il metodo committ a due fasi, il
programmatore di applicazione non ha bisogno di scrivere codici, poiché il metodo viene gestito dal contenitore EJB.
Gestione della sicurezza
La sicurezza EJB viene gestita dal relativo contenitore, utilizzando informazioni sulla sicurezza all'interno del
descrittore di distribuzione, dove viene dichiarato un insieme di ruoli e, per ogni metodo EJB, vengono
dichiarati i ruoli autorizzati a chiamare il metodo.
Al momento del runtime, ad ogni client EJB viene assegnato un ruolo e il contenitore EJB gestisce l'accesso ai relativi
metodi, verificando che il ruolo del client sia autorizzato a chiamare quel metodo.
Poiché le informazioni sulla sicurezza sono dichiarate nel descrittore di distribuzione, il comportamento di sicurezza
può essere modificato senza un ciclo aggiornamento-cancellazione errori-verifica di codice dispendioso.
Gestione del ciclo di vita
Gli EJB si muovono attraverso una serie di stati durante il ciclo di vita, in risposta alle richieste del client. Il
contenitore EJB è responsabile della gestione di questo ciclo di vita.
Nel momento dell'avvio del contenitore, quest'ultimo crea un assemblaggio di istanze EJB all'interno di un assemblaggio
di risorse (per salvare il momento di avvio quando viene richiesta la risorsa EJB). Quando un client EJB richiede la
creazione di un EJB, l'assemblaggio assegna un'istanza. Adesso il client può richiedere l'EJB. Quando un client EJB
richiede l'eliminazione di un EJB, quell'istanza viene riportata all'assemblaggio.
Il contenitore notifica un'istanza EJB di vari eventi all'interno del relativo ciclo di vita, utilizzando un insieme di
metodi callback standard, quali:
-
ejbCreate() , chiamato dal contenitore dopo che è stata creata l'istanza EJB
-
ejbRemove() , chiamato dal contenitore quando l'istanza EJB sta per essere eliminata
-
ejbActivate() , chiamato dal contenitore dopo che l'istanza EJB è stata ripristinata da uno stato
passivo
-
ejbPassivate() , chiamato dal contenitore quando l'istanza EJB sta per essere portata ad uno stato
passivo
-
ejbStore() , chiamato dal contenitore quando l'istanza EJB sta per essere scritta su un database
-
ejbLoad() , chiamato dal contenitore dopo che i campi dell'istanza EJB vengono caricati dal database
Ogni EJB è richiesto per implementare questi metodi callback, sebbene l'implementazione di EJB di questo metodo è
vuota. Ad esempio, il contenitore chiama il metodo ejbRemove() di EJB per notificare che EJB sta per
essere eliminato (il client ne ha richiesto l'eliminazione). Nel metodo ejbRemove() di EJB, è possibile
sia codificare le operazioni prima che EJB venga eliminato che rilasciare le risorse trattenute da EJB.
Gli EJB possono essere portati in stato passivo (le informazioni sullo stato vengono salvate e l'istanza EJB liberata
per essere utilizzata dall'assemblaggio di risorse), come richiesto dal contenitore. Un EJB posto in stato passivo sarà
reso attivo dal contenitore (le informazioni sullo stato vengono ripristinate), se viene ricevuta una richiesta del
client a questo particolare oggetto EJB.
Assemblaggio della connessione di database
L'apertura di una connessione ad un database risulta lenta. Le connessioni ad un database inoltre possono essere una
risorsa scarsa a causa di restrizioni della licenza, ad esempio. Il contenitore EJB gestisce questa spesa mediante un
assemblaggio delle connessioni del database (il contenitore mantiene un assemblaggio di connessioni aperte che possono
essere assegnate e non assegnate ad un EJB come richiesto), che determina connessioni veloci ed efficienti.
Per gli EJB di entità che utilizzano CMP, le connessioni ad un database sono gestite automaticamente. Non è necessario
scrivere connessioni o codici SQL, è sufficiente specificare il nome di JNDI della fonte di dati JDBC nel descrittore
di distribuzione EJB e utilizzare tool di distribuzione specifici del contenitore per creare procedure di collegamento.
Il contenitore gestisce l'assemblaggio di connessione del database.
Per gli EJB di entità che utilizzano BMP o per EJB di sessione, è necessario scrivere codici di connessione per
collegarsi ad una fonte di dati JDBC e codici SQL per avere accesso al database. La fonte di dati JDBC viene gestita
ancora dal contenitore (al momento attuale utilizza un assemblaggio di connessione del database gestito dal
contenitore).
Messaggistica
I contenitori EJB vengono richiesti per fornire supporto alla messaggistica relativa allo scambio asincrono di
messaggi. JMS, o altri tipi di messaggistica, possono essere utilizzati dai messaggi trasmessi del processo di EJB
basato sui messaggi. A causa del coinvolgimento di JMS con gli EJB, questi ultimi devono fornire supporto per l'accesso
transazionale dal Web e i componenti del contenitore EJB, quali: servlet, pagine JSP e EJB.
Componenti J2EE
La sezione seguente fornisce una breve descrizione di tutti i tipi di componenti J2EE, che includono applet, client di applicazione, componenti Web e Enterprise JavaBean. I componenti J2EE
si eseguono nei contenitori J2EE.
Applet
Gli applet sono piccoli programmi che possono essere inviati insieme ad una pagina Web e si eseguono in un browser Web
o in altri ambienti che supportano il modello di programmazione di applet.
Gli applet sono utilizzati principalmente per implementare le interfacce utente e possono estendere fortemente le
capacità delle pagine HTML.
Client di applicazione
I client di applicazione sono applicazioni Java. Hanno accesso alle funzioni del livello Intermedio J2EE e al livello
EIS. Sono applicazioni tipiche del desktop che forniscono un'interfaccia utente e possono essere utilizzate per
implementare un "client maggiore", come descritto in Concetto:
Pattern di distribuzione.
Componenti Web
Servlet Java
La tecnologia Servlet Java consente ad un server Web di gestire le richieste che provengono dal client Web e fornisce
risposte con contenuto dinamico. Un servlet Java è in grado di interagire con altri componenti Web e EJB per produrre
tale contenuto dinamico. Il contenuto generato può assumere la forma di documento basato sul testo, inclusi HTML e XML.
Servlet Java può anche essere utilizzato come endpoint di servizi Web, in collaborazione con API di JAX-RPC.
Nota: l'utilizzo di servlet come endpoint di servizi Web è una funzione di J2EE 1.4 (JAX-RPC 1.1) e così non è
supportato dalle versioni precedenti.
Per ulteriori informazioni sui servlet J2EE, consultare il sito http://java.sun.com/. Seguire i link J2EE > Blueprint.
Pagine JavaServer
La tecnologia JSP (JavaServer Pages) è realizzata sui servlet Java, ma è basata sul testo anziché sul codice. Una
pagina JSP elabora richieste e genera risposte come un servlet, ma la logica si basa fondamentalmente sulla
presentazione e contiene principalmente HTML statico, che definisce il formato relativo alla presentazione dei dati
ottenuti da altre fonti, quali JavaBean e EJB. Uno sviluppatore di componenti Web può creare librerie di tag
personalizzati per estendere JSP al fine di aggiungere nuove capacità.
Per ulteriori informazioni su JSP, consultare il sito http://java.sun.com/. Seguire i link J2EE > Blueprint.
Pagine HTML
Le pagine HTML possono essere utilizzate per supportare le interfacce utente. Possono essere definite come pagine Web
statiche o generate da servlet e pagine JSP. Le specifiche J2EE richiedono che i client Web J2EE supportino la
visualizzazione di pagine HTML.
JavaBean
L'API JavaBean definisce un'architettura per creare semplici componenti riutilizzabili, che possono essere modificati e
assemblati, utilizzando tool di costruttore di applicazione. Un codice Java regolare è utilizzato per implementare i
JavaBean, così che l'implementazione rimanga leggibile per gli altri programmatori, che possono usare sia i componenti
che i tool.
I JavaBean non sono una tecnologia J2EE, ma vengono utilizzati da tecnologie J2EE. Ad esempio, gli EJB possono
utilizzare i JavaBean come oggetto di valore. Consultare la sezione Confronto tra JavaBean e EJB per le differenze tra JavaBean e
Enterprise JavaBean.
Per maggiori informazioni sui Javabean, vedere Concetto:
JavaBean.
Enterprise JavaBean
Le specifiche di Enterprise JavaBean determinano un'architettura relativa allo sviluppo e alla distribuzione delle
applicazioni distribuite di business, transazionali e basate sui componenti.
I componenti definiti dalle specifiche EJB vengono chiamati Enterprise JavaBean (EJB). Gli EJB sono componenti Java
lato server in cui implementare i ruoli di business delle proprie applicazioni.
Gli EJB sono distribuiti, e si eseguono, in un ambiente chiamato contenitore EJB, descritto in precedenza
nell'intestazione Contenitore EJB, che fornisce servizi come gestione di transazione, connettività di
database e sicurezza. Volendo celare tali complessità, l'architettura EJB
consente agli sviluppatori di componenti di focalizzarsi sulla logica di business.
Un EJB (Enterprise JavaBean) è una collaborazione delle interfacce Java, una classe di implementazione EJB e un
descrittore di distribuzione XML. Le interfacce e le classi di implementazione EJB devono essere conformi ai ruoli
definiti dalle specifiche EJB, implementare alcune interfacce e fornire certi metodi callback.
Le interfacce EJB comprendono interfacce Home, che forniscono metodi per ricercare e creare istanze EJB, e interfacce
di componenti, che forniscono i metodi di business per una particolare istanza EJB. Le interfacce possono essere
remote, cioè possono essere richiamate nella rete o nelle interfacce locali; ciò significa che il chiamante deve
trovarsi nella stessa procedura (più precisamente, nella stessa macchina virtuale Java). Le interfacce EJB vengono
implementate dalle classi di contenitore EJB, che delegano metodi alla classe di implementazione EJB. Un'eccezione è
costituita dal metodo finder di un EJB di entità gestito dal contenitore, amministrato dalla classe di contenitore.
Esistono tre tipi di EJB: bean di sessione, bean di entità e
bean basati sui messaggi.
Per ulteriori informazioni sugli EJB, consultare il sito http://java.sun.com/. Seguire i link J2EE > Blueprint.
Bean di sessione
Un componente di bean di sessione fornisce servizi che implementano la logica di business specifica del client. Un
singolo client può avere accesso a tutte le istanze di bean di sessione mediante interfacce locali o remote. I bean di
sessione sono in grado di salvare dati su un database, ma di solito viene chiesto ai bean di entità che rappresentano
gli oggetti di business. Le istanze di bean di sessione possono gestire uno stato conversazionale transitorio.
Un bean di sessione deve avere un metodo getAllCustomers() che restituisca una raccolta di tutti gli
utenti all'interno del database, dovrebbe ottenere le informazioni dal bean di entità Cliente e produrre i risultati al
client.
I bean di sessione stateless possono essere utilizzati come un endpoint di servizi Web, come definito in JSR e nella
specifica EJB.
Nota: l'utilizzo di bean di sessione stateless come servizi Web è una nuova funzione di J2EE 1.4 (JSR 109 e EJB
2.1) e così non è supportato dalle versioni precedenti.
Per ulteriori informazioni sui bean di sessione, vedere Specifiche Enterprise JavaBeans, Versione 2.1, al sito http://java.sun.com/. Seguire i link Products & Technologies
> J2EE > Enterprise JavaBean.
Bean di entità
Un componente di bean di entità fornisce servizi che implementano la logica di business specifica dell'oggetto. Client
multipli possono accedere simultaneamente all'istanza di bean di entità mediante interfacce locali o remote. I bean di
entità salvano dati di oggetto di business sui database e i dati persistenti sono in grado di sopravvivere alle
interruzioni del contenitore o del client.
Un bean di entità può rappresentare un cliente, che deve essere memorizzato come una riga nella tabella cliente del
database relazionale. Lo sviluppatore EJB sceglie il metodo di persistenza, in questo caso un database relazionale.
Esistono due tipi di persistenza di bean di entità: BMP (Bean-Managed Persistence) e CMP (Container-Managed
Persistence). I bean di entità BMP devono implementare il codice di accesso ai dati, mentre per i bean di entità CMP
questa abilità viene implementata dal contenitore. Le implementazioni del contenitore CMP generalmente vengono fornite
per la persistenza di database relazionale, sebbene sono possibili altri tipi di persistenza (database di oggetti,
persistenza basata sul file, ecc.).
Per ulteriori informazioni sui bean di entità, vedere Specifiche Enterprise JavaBean, Versione 2.1at, al sito http://java.sun.com/. Seguire i link Products & Technologies
> J2EE > Enterprise JavaBean.
Bean basati sui messaggi
Un componente di bean basato sui messaggi fornisce un servizio che implementa la logica di business specifica
dell'elaborazione del messaggio. Soltanto il contenitore può chiamare questo servizio; il client non può chiamarlo
direttamente mediante interfacce remote o locali. Al contrario, quando un messaggio arriva a destinazione o a un
endpoint servito dal bean, il contenitore chiama un'istanza del bean basato sui messaggi come Listener di messaggio
alla destinazione. Le istanze di bean basato sui messaggi non gestiscono uno stato conversazionale, ma possono
amministrare istanze variabili con riferimenti alle risorse (ad esempio, connessione di database) in chiamate di
metodo.
Nota: i bean basati sui messaggi non sono supportati da versioni precedenti a EJB 2.0. Il supporto ai tipi di
messaggistica differenti da JMS è una nuova funzione della specifica EJB 2.1 e non è supportato dalle versioni
precedenti.
Per ulteriori informazioni sui bean basati sui messaggi, Specifiche Enterprise JavaBean, Versione 2.0, al sito http://java.sun.com/. Seguire i link Products & Technologies
> J2EE > Enterprise JavaBean.
Confronto tra JavaBean e EJB
Sebbene abbiano un nome simile, gli EJB sono più complessi dei JavaBean regolari. Entrambi definiscono le architetture
per componenti riutilizzabili, ma gli EJB aggiungono il supporto richiesto per la creazione dei servizi multi-user,
distribuiti. Entrambi i tipi di componenti possono essere assemblati utilizzando tool di costruttore di applicazione,
ma è necessario che gli EJB vengano distribuiti in un contenitore EJB per essere eseguiti.
Servizi (API) per componenti
J2EE
I contenitori J2EE supportano tutte le API standard J2SE, nonché un sottoinsieme di API J2EE che dipende dal tipo di
contenitore. I componenti all'interno di un contenitore possono accedere a questo sottoinsieme disponibile. La tabella
seguente fornisce una breve descrizione di ciascuna API ed elenca i contenitori J2EE in cui sono disponibili.
Nome
|
Descrizione
|
Contenitori J2EE,
in cui le API sono disponibili
|
EJB 2.1
|
Le specifiche EJB definiscono un modello di componente per i componenti di livello Business degli
EJB che supportano automaticamente servizi quali comunicazioni remote, gestione della transazione,
sicurezza e persistenza.
Per ulteriori informazioni su EJB, visitare il sito http://java.sun.com/ e seguire i collegamenti Products & Technologies
> J2EE > Enterprise JavaBean.
|
-
EJB
-
Client di applicazione*
-
Web*
* Solo API di client
|
JAAS
|
JAAS (Java Authentication and Authorization Service) fornisce servizi di autenticazione e
autorizzazione degli utenti per assicurarsi che possano effettuare questa azione.
Per ulteriori informazioni su JAAS, visitare il sito http://java.sun.com/ e seguire i collegamenti Products & Technologies
> J2SE > Core Java > JAAS (Java Authentication and Authorization Service).
|
-
Client di applicazione
-
Web
-
EJB
|
JAF 1.0
|
JAF (JavaBeans Activation Framework) fornisce servizi per identificare dati e creare un JavaBean al
fine di manipolarli.
Per ulteriori informazioni su JAF, visitare il sito http://java.sun.com/ e seguire i link Products & Technologies > J2SE
> Desktop Java > JavaBean > JavaBeans Activation Framework.
|
-
Client di applicazione
-
Web
-
EJB
|
JAXP 1.2
|
JAXP (Java API for XML Processing) fornisce un'interfaccia astratta per l'elaborazione di documenti
XML che può essere utilizzata con parser compatibili e trasformatori che usano DOM SAX o XSLT.
Per ulteriori informazioni su JAXP, visitare il sito http://java.sun.com/ e seguire i collegamenti Products & Technologies
> J2EE > JAXP (Java API for XML Processing).
|
-
Client di applicazione
-
Web
-
EJB
|
JAX-RPC 1.1
|
Le specifiche JAX-RPC definiscono le API client per l'accesso a servizi Web, nonché a tecnologie
per implementare gli endpoint di servizi Web.
Per maggiori informazioni su JAX-RPC, consultare JAX-RPC/carattere>
|
-
Client di applicazione
-
Web
-
EJB
|
Servizi Web per J2EE 1.1
|
I servizi Web per la specifica J2EE (JSR-109) definiscono le capacità che un server di applicazione
J2EE
deve supportare per distribuire endpoint di servizi Web.
Per maggiori informazioni sui servizi Web per J2EE, visitare il sito http://jcp.org/aboutJava/communityprocess/final/jsr109/index.html
|
-
Client di applicazione
-
Web
-
EJB
|
SAAJ 1.2
|
L'API di SSAJ fornisce la capacità di influenzare messaggi SOAP..
Per ulteriori informazioni su JAXP, visitare il sito http://java.sun.com/ e seguire i collegamenti Products & Technologies
> J2EE > SAAJ (SOAP with Attachments API for Java).
|
-
Client di applicazione
-
Web
-
EJB
|
JAXR 1.0
|
Le specifiche JAXR definiscono le API per l'accesso di client sia a registri basati su XML, che a
registri WebXML e UDDI.
Per ulteriori informazioni su JAXP, visitare il sito http://java.sun.com/ e seguire i link Products & Technologies > J2EE
> JAXR (Java API for XML Registries).
|
-
Client di applicazione
-
Web
-
EJB
|
JavaMail 1.3
|
L'API di JavaMail fornisce un framework che può essere esteso per creare applicazioni mail basate
su Java.
Per ulteriori informazioni su JavaMail, visitare il sito http://java.sun.com/ e seguire i collegamenti Products & Technologies
> J2EE > JavaMail.
|
-
Client di applicazione
-
Web
-
EJB
|
JDBC 3.0
|
JDBC (Java Database Connectivity) è una API per l'accesso a fonti di dati tabulari, come database
SQL, fogli di calcolo elettronico e file piatti.
Per ulteriori informazioni su JDBC, visitare il sito http://java.sun.com/ e seguire i collegamenti Products & Technologies
> J2EE > JDBC.
|
-
Client di applicazione
-
Web
-
EJB
|
JMS 1.1
|
JMS (Java Message Service) fornisce servizi di messaggistica asincroni relativi al trasferimento di
dati e notifica di eventi. Con JMS è possibile utilizzare gli EJB basati sui messaggi per elaborare
in modo asincrono messaggi trasmessi ad sezioni JMS e code.
Per ulteriori informazioni su JMS, visitare il sito http://java.sun.com/ e seguire i collegamenti Products & Technologies
> J2EE > Java Message Service.
|
-
Client di applicazione
-
Web
-
EJB
|
JNDI
|
JNDI (Java Naming and Directory Interface Specification) fornisce servizi di denominazione e di
directory per registrare e ricercare componenti e risorse distribuiti. I client desiderano soltanto
sapere il nome JNDI registrato relativo al componente o alle risorse e non la loro ubicazione
effettiva.
Esempio: gli EJB vengono registrati nella directory aziendale al momento della distribuzione,
utilizzando il campo ejb-name del descrittore di distribuzione. I client J2EE
ricercano un EJB utilizzando la ricerca JNDI (tutti i client desiderano sapere il nome con cui
viene registrato EJB nella directory). La ricerca JNDI restituisce un riferimento all'oggetto
principale di EJB.
Per ulteriori informazioni su JNDI, visitare il sito http://java.sun.com/ e seguire i link Products & Technologies > J2SE
> Core Java > JNDI (Java Naming and Directory Interface).
|
-
Client di applicazione
-
Web
-
EJB
|
JTA 1.0
|
JTA (Java Transaction API) definisce interfacce per gestire servizi di transazione distribuiti tra
il responsabile di transazione, il responsabile di risorse, il server di applicazione e
l'applicazione.
Per ulteriori informazioni su JTA, visitare il sito http://java.sun.com/ e seguire i collegamenti Products & Technologies
> J2EE > Transaction.
|
|
J2EE Connector 1.5
|
SPI (Service Provider Interface) Connector Architecture di J2EE definisce uno standard per
connettere le risorse EIS ad un contenitore J2EE - un adattatore di risorse specifico di EIS
(fornito dal vendor EIS) viene collegato ad un contenitore J2EE, ampliando il contenitore in modo
che fornisca supporto sicuro e transazionale per l'EIS. I componenti all'interno del contenitore
possono accedere poi a EIS attraverso SPI Connector Architecture di J2EE.
Per ulteriori informazioni sui Connettori J2EE, visitare il sito http://java.sun.com/ e seguire i collegamenti Products & Technologies
> J2EE > J2EE Connector Architecture.
|
|
JSP 2.0
|
La tecnologia di pagine JavaServer fornisce agli sviluppatori Web la capacità di creare e gestire
pagine Web dinamiche. Le pagine JSP sono basate sul testo e utilizzano tag simili a XML per
eseguire la logica di business e creare il contenuto del cliente. La tecnologia JSP consente alla
logica di business di essere delegata ad altri componenti, in modo che soltanto la logica di
presentazione deve essere inclusa nella pagina JSP.
Per ulteriori informazioni su JSP, visitare il sito http://java.sun.com/ e seguire i collegamenti Products & Technologies
> J2EE > JavaServer Page.
|
Web
|
Servlet 2.4
|
I servlet di Java estendono la capacità del server Web di assistere le applicazioni basate sul Web
del build. I servlet sono spesso utilizzati in applicazioni Web interattive in cui il server Web
risponde alle richieste dell'utente con un contenuto generato in modo dinamico, ottenuto dai
sistemi di business esistenti.
Per ulteriori informazioni sui servlet Java, visitare il sito http://java.sun.com/ e seguire i collegamenti Products & Technologies
> J2EE > Java Servlet.
|
Web
|
RMI-IIOP
|
RMI-IIOP (Remote Method Invocation technology run over Internet Inter-Orb Protocol) consente ai
componenti Java di comunicare con componenti CORBA precedenti, scritti in altri linguaggi tipo C++
o Smalltalk.
Per ulteriori informazioni su RMI-IIOP, visitare il sito http://java.sun.com/ e seguire i link Products and API > RMI-IIOP.
|
-
Client di applicazione
-
Web
-
EJB
|
Gestione J2EE 1.0
|
L'API di gestione J2EE fornisce le API per tool di gestione al fine di eseguire una query di un
server di applicazione J2EE
per determinare il suo stato attuale, le applicazioni distribuite, ecc.
Per ulteriori informazioni su RMI-IIOP, visitare il sito http://java.sun.com/ e seguire i collegamenti Products & Technologies
> J2EE > J2EE Management Specification.
|
-
Client di applicazione
-
Web
-
EJB
|
JMX 1.2
|
L'API di JMX viene utilizzata dall'API di gestione J2EE per fornire un po' del supporto richiesto
per amministrare un prodotto J2EE.
Per ulteriori informazioni su RMI-IIOP, visitare il sito http://java.sun.com/ e seguire i collegamenti Products & Technologies
> J2SE > Core Java > JMX (Java Management Extensions).
|
-
Client di applicazione
-
Web
-
EJB
|
Distribuzione J2EE 1.1
|
L'API di distribuzione J2EE definisce le interfacce tra l'ambiente runtime di un tool di
distribuzione e i componenti forniti dal server di
applicazione J2EE.
Per ulteriori informazioni sulla distribuzione J2EE, visitare il sito http://java.sun.com/ e seguire i collegamenti
Products & Technologies > J2EE > J2EE Deployment Specification.
|
|
JACC 1.0
|
La specifica JACC definisce un contratto tra il server di applicazione J2EE e
un provider della politica di autorizzazione.
Per ulteriori informazioni su JACC, visitare il sito http://java.sun.com/ e seguire i collegamenti Products & Technologies
> J2EE > Java Authorization Contract for Containers.
|
-
Client di applicazione
-
Web
-
EJB
|
Assemblaggio e distribuzione
Le applicazioni J2EE sono composte dal descrittore di distribuzione dell'applicazione (application.xml) e da uno o più
moduli J2EE dell'applicazione stessa. I moduli sono componenti riutilizzabili e portatili. Le applicazioni J2EE sono
incluse in archivi .ear.
Descrittori di distribuzione
I descrittori di distribuzione sono file XML utilizzati nelle applicazioni e nei moduli J2EE. Forniscono informazioni
sulla configurazione, lette dal server J2EE nel momento della distribuzione, che consentono al server di personalizzare
l'applicazione J2EE o il modulo senza modificare il codice o le classi della fonte.
Esiste un tipo di descrittore di distribuzione generico per ogni applicazione o modulo J2EE. I descrittori di
distribuzione generici, come ejb-jar.xml del modulo EJB, definiscono le informazioni che si applicano a EJB
indipendentemente dal server su quale viene distribuito. I descrittori di distribuzione specifici del server
individuano informazioni che hanno significato soltanto per un server particolare e hanno nomi che riflettono il server
per il quale hanno significato.
Moduli J2EE
Un modulo J2EE è formato da un descrittore di distribuzione relativo al modulo e da elementi del modulo, inclusi:
-
Elementi non appartenenti a Java distribuiti sul server Web (pagine JSP, file di immagine, pagine HTML statiche);
in altre parole, elementi della directory virtuale.
-
Elementi Java distribuiti sul server Web (servlet, JavaBean, classi Java).
-
Elementi distribuiti sul server EJB (gli EJB e le classi Java di supporto).
Esistono tre tipi di moduli J2EE:
Client di applicazione J2EE
I moduli del client di applicazione J2EE vengono inclusi in archivi .jar e contengono:
-
descrittore di distribuzione client d'applicazione.xml
-
file di implementazione client d'applicazione.class
Componente Web
I moduli del componente Web vengono inclusi in archivi .war e contengono:
-
descrittore di distribuzione web.xml e descrittori di distribuzione specifici del server
-
pagine JSP
-
pagine HTML
-
immagini (ad esempio, .gif e .jpg)
-
file di classe di servlet
Se il modulo è un servizio Web, l'archivio .war contiene:
-
descrittore di distribuzione servizi Web.xml
-
file di classe di servlet
-
file WSDL
Enterprise JavaBean
Un singolo archivio JAR di Enterprise JavaBean può contenere degli EJB, ma le informazioni di distribuzione sono
memorizzate in un insieme di descrittori di distribuzione (ejb-jar.xml oltre a descrittori di distribuzione specifici
del server).
Un modulo standard Enterprise JavaBean contiene:
-
ejb-jar.xml e descrittori di distribuzione specifici del server
-
file di classe di implementazione EJB
Un modulo Enterprise JavaBean di servizio Web contiene:
-
descrittori di distribuzione servizi Web.xml
-
file di classe di implementazione EJB
Per ulteriori informazioni sull'imballaggio e la distribuzione J2EE, consultare il sito http://java.sun.com/. Seguire i link Docs & Training > J2EE Platform, Enterprise Edition
> Java Blueprints Program.
Sviluppo di applicazione J2EE
L'elaborazione dello sviluppo di applicazione J2EE definisce molti ruoli e stadi. Le seguenti sezioni definiscono i ruoli di sviluppo forniti dalla specifica J2EE e gli stadi di sviluppo nei quali questi ruoli vengono coinvolti.
Ruoli di sviluppo di
applicazione J2EE
In questa tabella sono sintetizzati i ruoli di sviluppo dell'applicazione.
Nome del ruolo
|
Descrizione
|
Provider del prodotto J2EE
|
Un provider del prodotto J2EE è il fornitore dell'implementazione della piattaforma J2EE,
conosciuto anche come prodotto J2EE. I provider del prodotto J2EE comprendono BEA, IBM e Sun. Tali
organizzazioni giocano in genere sul proprio punto di forza precedente nella produzione di una
implementazione per la piattaforma J2EE. Ad esempio, l'implementazione BEA si basa sul controllo
del processo di transazione Tuxedo di BEA di maggiore successo. Un provider del prodotto J2EE
fornisce anche i tool richiesti per supportare la distribuzione e la gestione dell'applicazione.
|
Provider del
componente di applicazione
|
Il provider del componente dell'applicazione include effettivamente numerosi ruoli, come gli
sviluppatori EJB e i progettisti del documento HTML, che sono responsabili della produzione dei
componenti dell'applicazione J2EE mediante l'utilizzo dei tool forniti.
|
Assemblatore di applicazione
|
L'assemblatore di applicazione crea un'applicazione J2EE dai componenti di quest'ultima mediante
l'utilizzo dei tool forniti. L'applicazione J2EE viene prodotta come un file EAR (Enterprise
Archive) e l'assemblatore di applicazione ne descrive inoltre le dipendenze esterne. Il
distributore risolve queste dipendenze nel momento in cui distribuisce in modo effettivo
l'applicazione J2EE.
|
Distributore
|
Il distributore è responsabile della distribuzione di un'applicazione J2EE e dei componenti di
applicazione, che lo includono nell'ambiente operativo. La prima operazione della distribuzione è
l'installazione di vari componenti dell'applicazione all'interno dei contenitori J2EE rilevanti. La
seconda è la configurazione di dipendenze esterne che sono state dichiarate per ottenere una
risoluzione. Ad esempio, i ruoli di sicurezza già definiti vengono mappati in gruppi di utenti e
associati nell'ambiente operativo. La terza operazione è l'esecuzione di una nuova applicazione in
modo da renderla pronta a ricevere le richieste.
|
Responsabile del sistema
|
L'amministratore di sistema è responsabile dell'infrastruttura runtime, che include applicazioni
J2EE distribuite. Questo ruolo utilizza i tool appropriati, forniti dal provider di prodotto J2EE,
per portare a termine questa attività.
|
Provider del tool
|
Il provider del tool fornisce tool per supportare la distribuzione e l'imballaggio dei componenti
dell'applicazione. Questi tool corrispondono spesso ai diversi tipi di componenti dell'applicazione
prodotti e includono IDE quali VisualAge per Java di IBM e Borland JBuilder.
|
Provider del componente di sistema
|
Il provider del componente di sistema fornisce componenti differenti a livello di sistema come
adattatori di risorse o il provider della politica di autorizzazione.
|
Tali ruoli non sono esclusivi e una persona non può assumere più di un ruolo, specialmente in piccoli team di sviluppo
o in una situazione in cui si creano prototipi.
Stadi di sviluppo di
applicazione J2EE
Questa sezione descrive i differenti stadi dello sviluppo di applicazione J2EE, come definito nella specifica J2EE. Gli
stadi dello sviluppo sono:
-
Sviluppo dei componenti
-
È necessario che un'applicazione J2EE contenga almeno un modulo J2EE, in modo che venga richiesto almeno un
componente degli stadi di sviluppo. Le due operazioni finali sono sempre necessarie, poiché tutte le
applicazioni J2EE devono essere assemblate e distribuite.
La tabella seguente sintetizza gli stadi di sviluppo per le applicazioni J2EE.
Stadio di sviluppo J2EE
|
Attività
|
Esecuzione da parte del ruolo J2EE
|
Risultati in (Distribuibile)
|
Creazione del client di applicazione J2EE
|
-
Scrittura del codice client e compilazione delle classi
-
Creazione del descrittore di distribuzione client d'applicazione.xml
-
Creazione di un archivio di file JAR contenente la Classe e i file XML
|
Provider del componente di applicazione
(sviluppatore software)
|
Un file JAR contenente il client di applicazione J2EE
|
Creazione del componente
Web
|
-
Scrittura del codice servlet e compilazione delle classi
-
Scrittura di JSP e di pagine HTML
-
Creazione del descrittore di distribuzione Web.xml
-
Creazione di un archivio di file WAR (Web Application Archive) contenente la Classe e i
file .jsp, .html e XML
|
Provider del componente di applicazione
(sviluppatore software: servlet; progettista Web: pagine JSP e HTML)
|
Un file WAR contenente il componente Web
|
Creazione di
Enterprise JavaBean
|
-
Scrittura del codice EJB e compilazione delle classi
-
Creazione di ejb-jar.xml e di descrittori di distribuzione specifici del server
-
Creazione di un archivio di file JAR contenente la Classe e i file XML
|
Provider del componente di applicazione
(sviluppatore software)
|
Un file JAR contenente Enterprise JavaBean
|
Assemblaggio di
applicazione J2EE
|
-
Creazione del descrittore di distribuzione applicazione.xml
-
Creazione di un archivio di file EAR contenente gli EJB (JAR), i componenti Web (WAR) e
i file XML
|
Assemblatore di applicazione
|
Un file EAR contenente l'applicazione J2EE
|
Distribuzione
dell'applicazione J2EE
|
-
Aggiunta dell'applicazione J2EE (EAR) all'ambiente del server J2EE
-
Modifica del descrittore di distribuzione dell'applicazione.xml con la configurazione
dell'ambiente locale
-
Visualizzazione dell'applicazione J2EE sul server J2EE
|
Distributore
|
Applicazione J2EE installata e configurata
|
Ogni stadio del processo di sviluppo produce un componente distribuibile utilizzato nello stadio successivo. I
componenti creati negli stadi Sviluppo del componente vengono utilizzati nella fase Assemblaggio
dell'applicazione J2EE per produrre l'archivio EAR dell'applicazione J2EE. Nello stadio Distribuzione
dell'applicazione J2EE, l'archivio EAR viene distribuito al server J2EE.
Per ogni stadio, i componenti distribuibili sono portatili e non devono essere eseguiti dalle stesse persone o
nello stesso ambiente, purché quest'ultimo soddisfi i requisiti della Piattaforma J2EE.
Per ulteriori informazioni sull'imballaggio e la distribuzione J2EE, consultare il sito http://java.sun.com/. Seguire i link J2EE >
Blueprint.
Informazioni ulteriori
Maggiori informazioni su J2EE si possono trovare nei Blueprint di Sun J2EE, consultando il sito http://java.sun.com/. Seguire i collegamenti J2EE >
Blueprint > Guidelines: Designing Enterprise Applications with the J2EE Platform, Second Edition.
Una copia di questo documento è inclusa anche in RUP (Rational Unified Process).
La seguente tabella sintetizza i capitoli contenenti le informazioni su argomenti specifici dei Blueprint di
Sun J2EE.
Concetto J2EE
|
Capitolo sui Blueprint J2EE
|
Tecnologie della Piattaforma J2EE
|
Capitolo 2
|
Enterprise JavaBean
|
Capitolo 5
|
Transazioni
|
Capitolo 8
|
Sicurezza
|
Capitolo 9
|
Servlet
|
Capitolo 4
|
Pagine JavaServer
|
Capitolo 4
|
Distribuzione e imballaggio
|
Capitolo 7
|
|