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:
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.
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).
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.
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].
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.
|