Concetto: Panoramica di J2EE (Java 2 Platform Enterprise Edition)
Questa linea guida fornisce una panoramica completa della piattaforma J2EE.
Relazioni
Elementi correlati
Descrizione principale

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.

Esempio

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)

Portabilità

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.

Diagramma descritto nel testo di accompagnamento.

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.

  • Web
  • EJB

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.

  • Web
  • EJB

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