Linea guida: Progettazione di EJB (Enterprise JavaBean)
Questa linea guida descrive come progettare un EJB (Enterprise Javabean) per un'applicazione J2EE.
Relazioni
Elementi correlati
Descrizione principale

Introduzione

Questa linea guida si focalizza sulla progettazione di EJB. Un'ulteriore guida su come identificarli e modellarli è fornita da Linea guida del prodotto: EJB.

Una guida specifica sulla progettazione di tipi specifici di EJB è presente nelle seguenti linee guida:

Intefacce locali e remote

Le interfacce locali e remote sono descritte in Concetto: Panoramica di J2EE: Enterprise JavaBean.

Le interfacce locali sono più efficaci di quelle remote e dovrebbero essere fornite se vi sono client specifici sempre locali per EJB.

Una guida più specifica su quest'argomento è fornita in queste linee guida per tipi specifici di EJB.

Trasmissione di parametri

La prestazione può essere influenzata fortemente dal numero di chiamate remote e dalla quantità di dati trasferiti su ogni chiamata. Questo problema può essere risolto fornendo delle chiamate specifiche che restituiscono tutti i dati richiesti dal client remoto. Ad esempio, un bean di sessione, agendo da facciata per un insieme di bean di entità, può copiare dati da più bean di entità in oggetti di valore serializzabili, restituendoli in una singola chiamata remota. Tale procedura viene descritta dettagliatamente in Core J2EE Patterns - Value Object Pattern ([ALU01].

Ciò dev'essere controbilanciato dal problema di mantenere le interfacce il più generali possibile ed evitare di inviare troppi dati indesiderati.

Transazioni

Demarcare le transazioni significa avviarle, impegnarle e annullarle. Un progettista EJB deve decidere se implementare demarcazioni di transazioni gestite da bean o da contenitori. Si deve decidere sulle locazioni dei limiti della transazione nelle sequenze della logica di business eseguita dall'applicazione. Per ulteriori informazioni, vedere Compito: Progettazione del caso d'uso, modellazione di transazioni e la sezione intitolata Gestione di transazioni in Concetto: Panoramica di J2EE.

Laddove possibile, utilizzare transazioni gestite dal contenitore. Ciò consentirà di mantenere limitate le code e permetterà agli sviluppatori di focalizzarsi sulla logica di business dell'applicazione.

In generale, transazioni di maggiore granularità daranno luogo a una migliore prestazione generale. Supporre di stare facendo una sequenza di chiamate di metodo ad un EJB (ad esempio getX, getY e setZ). Come valore predefinito, ogni metodo sarà eseguito in una nuova transazione, con il risultato di una prestazione ridotta. Per richiamarli nella stessa transazione, creare un altro metodo, ad esempio il processoXYZ di metodo di una sessione EJB e impostare gli attributi di transazione dei metodi chiamati su Required, così che utilizzino la transazione esistente (ad esempio la transazione del metodo di chiamata nel bean di sessione). 

Sicurezza

I concetti base di sicurezza EJB sono inseriti in Concetto: Panoramica della piattaforma J2EE - Sicurezza.

È possibile definire i requisiti di sicurezza EJB specificando i ruoli di sicurezza e le autorizzazioni di metodo.  I ruoli di sicurezza e le autorizzazioni di metodo sono definiti nel descrittore di distribuzione EJB.  L'associazione di ruoli di sicurezza a utenti o gruppi di utenti (utilizzando tool di amministrazione) è a discrezione del server. 

Un ruolo di sicurezza definisce una serie di tipi di attività raggruppate sotto un unico nome. Un'autorizzazione di metodo accorda ad un particolare ruolo di sicurezza il diritto di chiamare il metodo.   Ad esempio, nel caso di un EJB di entità Employee, con metodi setAddress, setSalary ecc. sarà concesso ad un ruolo di sicurezza manager il permesso di metodo per i metodi setAddress e setSalary, mentre ad un ruolo di sicurezza employee sarà concesso solo il permesso di metodo per il metodo setAddress.  

In alcune situazioni è impossibile supportare i requisiti di sicurezza di un'applicazione utilizzando permessi di metodo espliciti nel descrittore di distribuzione. In questo caso, utilizzare i metodi getCallerPrincipal e isCallerInRole dell'interfaccia javax.ejb.EJBContext. 

Servizio timer

A partire da J2EE 1.4 (più esattamente EJB 2.1), i bean di sessione stateless e basati sui messaggi di possono utilizzare timer per pianificare i processi di batch mediante il servizio timer EJB.

Il servizio timer EJB fornisce metodi per consentire ai callback di venire pianificati per eventi basati sul tempo. Il contenitore fornisce un servizio di notifica transazionale e affidabile per gli eventi programmati. Le notifiche timer possono essere pianificate in un momento specifico, dopo un preciso periodo trascorso o ad intervalli ricorrenti.

Il servizio timer è implementato dal contenitore EJB ed un bean aziendale può accedervi mediante interfaccia EJBContext.

Il servizio timer EJB è un servizio di notifica timer dettagliato progettato per l'utilizzo nella modellazione di processi a livello di applicazione e l'utilizzo non è previsto nella modellazione di eventi in tempo reali.

Accesso diretto ai bean di entità

L'utilizzo di bean di entità permanenti fornisce un meccanismo standard, con molte funzioni per l'accesso ai dati permanenti. La decisione di utilizzare la persistenza gestita dal bean o dal contenitore può essere nascosta dai client, conferendo alla progettazione una certa flessibilità. Gli EJB possono usufruire di transazioni, gestione delle risorse, bilanciamento del carico e altre funzioni fornite dall'ambiente J2EE.

Tuttavia potrebbero esservi alcune situazioni in cui è necessario accedere al database direttamente evitando di usare bean di entità. Ad esempio se i dati sono sempre accessibili in sola lettura da un singolo client, l'accesso diretto potrebbe risultare più efficace.

Se si accede direttamente al database (ad esempio da un bean di sessione stateless), incapsulare tutti gli accessi in una classe Data Access Object, una classe Java che nasconde ed incapsula il meccanismo di memorizzazione sottostante e isola le modifiche quando e se l'interfaccia della fonte dei dati cambia. Vedere Core J2EE Patterns - Data Access Object Pattern ([ALU01].

Connessioni di database

In pratica tutti i contenitori EJB forniscono un supporto per connessioni, raggruppando e condividendo un insieme di connessioni già create tra i client. Tali connessioni vengono assegnate agli EJB se necessario. EJB approfitta del fatto di ottenere una connessione senza la spesa di doverla creare e avviare. Quando la connessione viene restituita al pool viene riciclata. Il pool dovrebbe avere pronte abbastanza connessioni disponibili a riciclare quelle utilizzate.

Per bean di entità con persistenza gestita dal contenitore, il contenitore gestisce la connessione di database e l'accesso al pool di connessione del database.

Per bean di entità con persistenza gestita dal bean (o per EJB di sessione o basati sui messaggi che accedono ad un database), lo sviluppatore è responsabile della routine di connessione. Le seguenti linee guida riguardano:

  • Isolare il codice di accesso al database in una classe DAO.
  • Non codificare in modo pesante il reale URL del database, utilizzare invece un nome logico che può essere richiamato utilizzando lo strumento di ricerca JNDI (Java Naming and Directory Interface), che consente di riutilizzare EJB in più applicazioni, possibilmente con nomi di database differenti.
  • In generale, utilizzare pool di connessione e conservare la connessione per quanto necessario. Ad esempio, un bean di entità può connettersi, aggiornare una riga in una tabella e disconnettersi. Ciò consentirà a molti EJB di condividere la stessa connessione. La specifica di JDBC comprende il supporto per l'assemblaggio di connessioni.