Upload
vukiet
View
219
Download
1
Embed Size (px)
Citation preview
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 1
Modelli a Componenti eModelli a Componenti eEnterpriseEnterprise Java Java BeansBeans
Università di BolognaCdS Laurea Specialistica in Ingegneria Informatica
III Ciclo - A.A. 2008/2009
04 – Enterprise Java Beans 3.0 e Servizi di Sistema (Pooling, Transazioni, …)
Docente: Paolo [email protected]
http://lia.deis.unibo.it/Courses/sd0809-info/
http://lia.deis.unibo.it/Staff/PaoloBellavista/
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 2
DaDa EJB2.1 a EJB3.0:EJB2.1 a EJB3.0:Ease of Development!Ease of Development!
EJB2.1 è stato considerato dagli sviluppatori molto potentema anche complesso da utilizzare
Modello di programmazione non sempre naturale
Descrittori di deployment
Numerose classi e interfacce
Difficoltà di uso corretto (vedi qualche antipattern emerso, soprattutto per gli entity bean), lookup dei componenti sempre basato su JNDI, ...
EJB3.0 risponde alla necessità di essere più semplice (siaapprendimento che utilizzo)
Minor numero di classi e interfacce
Dependency injection
Lookup di componenti più sempliceNon necessari le interfacce per il container e i descrittori di deployment
…
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 3
DaDa EJB2.1 a EJB3.0:EJB2.1 a EJB3.0:Ease of Development!Ease of Development!
EJB3.0 risponde alla necessità di essere più semplice (siaapprendimento che utilizzo)
Gestione semplificata della persistenza: entity bean come POJO e persistenza come servizio esterno alla specifica EJB (Java Persistence API, la vedremo più avanti nel corso)
Java Persistence API si occupa sostanzialmente del mapping oggetti/db relazionali
Compatibilità e migrazioneTutte le applicazioni EJB esistenti continuano a funzionareSupporto a metodologie di integrazione per applicazioni e componentipre-esistenti
Supporto all’aggiornamento e alla sostituzione di componenti(attraverso API EJB3.0) senza impatto sui clienti esistenti
Idea di facilitare l’adozione della tecnologia EJB3.0 tramitemigrazione incrementale
Perché non se occupa direttamente il programmatore
di applicazioni?
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 4
LL’’ApproccioApproccio didi EJB3.0EJB3.0
Semplificazione delle API EJBNon più necessari EJBHome e EJBObjectNon più necessari i descrittori di deploymentRimozione di API JNDI dalla vista cliente e sviluppatore
Sfrutta i vantaggi dei nuovi metadati (annotation) dilinguaggio Java
Defaulting per i casi più usualiTra l’altro, annotation progettate perché i casi più comuni siano i più semplici da esprimere
Più attività svolte dal container, meno dallosviluppatore
“Inversione di contratto” (inversion of contract) I componenti specificano le loro necessità tramite metadati
Interposizione dinamica del container per fornire i servizirichiesti
Ne parleremo ampiamente quando affronteremo la
tecnologia Spring
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 5
SemplificazioneSemplificazione delledelle APIAPIper per ComponentiComponenti EJBEJB
Quindi, scendendo in maggiore dettaglio dal punto di vista dellaprogrammazione EJB:
Eliminazione di requisiti sulle interfacce dei componentiEJB
Interfacce di business sono interfacce Java plain (POJI)
Eliminazione di requisiti sulle interfacce HomeNecessità solo di interfacce di business, non più di Home
Eliminazione di requisiti sulle interfaccejavax.ejb.EnterpriseBean
Annotation per sfruttare callback (anche addizionali e opzionali)
Eliminazione della necessità di utilizzo di API JNDIUso di dependency injection, metodo di lookup semplificato
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 6
EsempioEsempio EJB2.1EJB2.1
// EJB 2.1
public class PayrollBeanimplements javax.ejb.SessionBean {
SessionContext ctx;DataSource empDB;
public void setSessionContext(SessionContext ctx) {this.ctx = ctx;
}
public void ejbCreate() {Context initialContext = new InitialContext();empDB = (DataSource)initialContext.lookup(“java:comp/env/jdbc/empDB”);
}
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 7
// EJB 2.1 (cont.)
public void ejbActivate() {}public void ejbPassivate() {}public void ejbRemove() {}
public void setBenefitsDeduction (int empId, double deduction) {...Connection conn = empDB.getConnection();...
}...
}
// NOTA: il descrittore di deployment è NECESSARIO
EsempioEsempio EJB2.1EJB2.1
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 8
<session><ejb-name>PayrollBean</ejb-name><local-home>PayrollHome</local-home><local>Payroll</local><ejb-class>com.example.PayrollBean</ejb-class><session-type>Stateless</session-type><transaction-type>Container</transaction-type><resource-ref><res-ref-name>jdbc/empDB</res-ref-name><res-ref-type>javax.sql.DataSource</res-ref-type><res-auth>Container</res-auth>
</resource-ref></session>...<assembly-descriptor>...</assembly-descriptor>
EsempioEsempio EJB2.1EJB2.1
Esempio di Descrittore di deployment - NECESSARIO
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 9
// EJB 3.0
@Stateless public class PayrollBeanimplements Payroll {
@Resource DataSource empDB;
public void setBenefitsDeduction (int empId, double deduction) {...Connection conn = empDB.getConnection();...
}
...}
EsempioEsempio EJB3.0EJB3.0
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 10
Dependency InjectionDependency Injection
Le risorse di cui un bean ha necessità sono “iniettate”(injected) quando l’istanza del bean viene effettivamentecostruita
Ad esempio, riferimenti a:– EJBContext - sorgenti di dati
– UserTransaction - entry di ambiente
– EntityManager - TimerService
– Altri componenti EJB - ...
Dependency injection realizzata tramite annotation come via primaria (anche descrittori di deployment NON completi, se preferito)
@EJB
Riferimenti alle interfacce di business EJBUtilizzato anche per riferimenti a EJBHome (per compatibilità con componenti EJB 2.1)
@Resource: qualsiasi altro riferimento
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 11
Dependency InjectionDependency Injection
Le risorse di cui un bean ha necessità sono“iniettate” (injected) quando l’istanza del bean viene effettivamente costruita
Valutazione delle annotazioni anche a runtime
Discussione:Quali vantaggi/svantaggi rispetto a scelte a tempo discrittura del codice, a tempo di compilazione, a tempo di caricamento?Quali vantaggi/svantaggi rispetto a descrittori dideployment?
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 12
InoltreInoltre, Lookup , Lookup SemplificatoSemplificato
Lo sviluppatore NON ha più visibilità delle API JNDI(vista sviluppatore)
Le dipendenze corrispondenti sono espresse a livello diclasse beanA runtime si utilizza il metodo EJBContext.lookup
@Resource(name=”myDB”, type=javax.sql.DataSource)@Stateful public class ShoppingCartBean
implements ShoppingCart {
@Resource SessionContext ctx;
public Collection startToShop (String productName) {...DataSource productDB = (DataSource)ctx.lookup(“myDB”);Connection conn = myDB.getConnection();...
}... }
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 13
EsempioEsempio: : ClienteCliente in EJB2.xin EJB2.x
// Vista cliente di ShoppingCart bean in EJB2.1
...Context initialContext = new InitialContext();ShoppingCartHome myCartHome = (ShoppingCartHome)
initialContext.lookup(“java:comp/env/ejb/cart”);ShoppingCart myCart= myCartHome.create();
//Utilizzo del bean
Collection widgets = myCart.startToShop(“widgets”)
...
// necessario anche il codice per gestire esplicitamente// l’eccezione javax.ejb.CreateException...
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 14
Vista Vista ClienteClienteSemplificataSemplificata in EJB3.0in EJB3.0
// Vista cliente in EJB3.0
@EJB ShoppingCart myCart;
...
Collection widgets = myCart.startToShop(“widgets”);
...
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 15
InteroperabilitInteroperabilitàà e e MigrazioneMigrazionefrafra EJB 3.0 e EJB 2.xEJB 3.0 e EJB 2.x
Applicazioni scritte in modo conforme alla specificaEJB2.1 eseguono senza necessità di modifica anchenei container EJB3.0Migrazione suggerita verso le API EJB3.0
Nuove applicazioni possono essere cliente di “vecchi” beanVecchi clienti possono accedere anche ai nuovi componentiEJB3.0
Anche senza modifiche alla vista cliente preesistenteMolte funzionalità EJB3.0 sono disponibili anche per componenti conformi a EJB2.1 (offerte dal nuovocontainer)
Dependency injection, annotazioni per transazioni e callback, …
// Vista cliente da EJB3.0 di un bean EJB2.1...@EJB ShoppingCartHome cartHome;Cart cart = cartHome.create();cart.addItem(...); ...cart.remove(); ...
Importantissimo per gli sviluppatori e per le
industrie, meno da un punto di vista concettuale
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 16
“Vecchi” bean conformi a EJB2.1 possono utilizzare nuovicomponenti
Questo consente a componenti server di essere aggiornati o sostituiti senza impatto sui clienti già distribuiti
I nuovi bean supportano sia clienti EJB3.0 che di tipologieprecedenti
Le interfacce EJBHome e EJBObject vengono automaticamentemappate sulla classe del bean di tipo EJB3.0
InteroperabilitInteroperabilitàà e e MigrazioneMigrazionefrafra EJB 3.0 e EJB 2.xEJB 3.0 e EJB 2.x
// Vista cliente da EJB2.1 di un bean conforme a EJB3.0...Context initialContext = new InitialContext();ShoppingCartHome myCartHome = (ShoppingCartHome)
initialContext.lookup(“java:comp/env/ejb/cart”);ShoppingCart cart= myCartHome.create();cart.addItem(...); ...cart.remove();...
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 17
Annotation vs.Annotation vs.DescrittoriDescrittori didi DeploymentDeployment
Annotation Rendono i descrittori di deployment non necessari
I casi di default non necessitano di specifica
I casi più comuni possono essere specificati in modo moltosemplice
Descrittori di deployment continuano a poter essereutilizzati anche in EJB3.0 come alternativa
Alcuni sviluppatori preferiscono usare descrittori
I descrittori possono essere usati per rendere “più esterni” i metadati
Possono essere anche utilizzati per fare override di annotation
A partire da EJB3.0, i descrittori possono essereanche parziali e incompleti (“sparse descriptor”)
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 18
TipologieTipologie didi Bean EJB3.0Bean EJB3.0
Dopo la panoramica appena fatta, ora scendiamo nel dettaglio tecnicodi qualche aspetto…
In EJB 3.0, i bean di tipo sessione e message-driven sono classi Java ordinarie
Rimossi i requisiti di interfaccia
Tipo di bean specificato da una annotation (o da un descrittore)
Annotation principali@Stateless, @Stateful, @MessageDriven
Specificati nella classe del bean
Gli entity bean di EJB2.x non sono stati modificati e possono continuare a essere utilizzati
Ma Java Persistence API supporta nuove funzionalità@Entity si applica solo alle nuove entità relative a Java Persistence API
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 19
EsempioEsempio// EJB2.1 Stateless Session Bean: Bean Class
public class PayrollBean implements javax.ejb.SessionBean {SessionContext ctx;public void setSessionContext(SessionContext ctx) {
this.ctx = ctx;}public void ejbCreate() {...}public void ejbActivate() {}public void ejbPassivate() {}public void ejbRemove() {}
public void setTaxDeductions(int empId, int deductions) {...
} }
// EJB3.0 Stateless Session Bean: Bean Class
@Stateless public class PayrollBean implements Payroll {
public void setTaxDeductions(int empId,int deductions) {...
}}
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 20
InterfacceInterfacce didi BusinessBusiness
Interfacce in plain Java language (POJI), nessunrequisito aggiuntivo rispetto ad un normale oggetto
Vincoli sulle interfacce EJBObject, EJBHome rimossi
Accesso locale o remotoLocale a defaultRemoto tramite annotation o descrittore di deploymentI metodi remoti non sono obbligati a lanciare esplicitamenteRemoteException
La classe bean si occupa solo di implementare la sua interfaccia di businessAnnotation: @Remote, @Local, @WebService
Si può specificare a livello di classe di bean o di interfaccia in modo equivalente (vedi regole generali delle annotation)
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 21
// EJB 2.1 Stateless Session Bean: Interfacce
public interface PayrollHome extends javax.ejb.EJBLocalHome {
public Payroll create() throws CreateException;}
public interface Payroll extends javax.ejb.EJBLocalObject {
public void setTaxDeductions(int empId, int deductions);
}
EsempioEsempio
// EJB 3.0 Stateless Session Bean: Interfaccia di business // (solo logica applicativa)
public interface Payroll {
public void setTaxDeductions(int empId, int deductions);
}
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 22
// EJB 3.0 Stateless Session Bean: Interfaccia remota
@Remotepublic interface Payroll {
public void setTaxDeductions(int empId, int deductions);
}
EsempioEsempio
// EJB 3.0 Stateless Session Bean: // Alternativa: @Remote annotation applicata direttamente allaclasse bean
@Stateless @Remote public class PayrollBean implements Payroll {
public void setTaxDeductions(int empId,int deductions) {...
}}
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 23
Message Driven Bean in EJB3.0Message Driven Bean in EJB3.0
Deve implementare l’interfaccia del listener dimessaggi jms.MessageListener ma, a parte questo, sipuò focalizzare sulla sola logica applicativaNessun requisito per l’implementazione di altre interfacceAnnotation@MessageDriven
// EJB 3.0 Message-driven bean
@MessageDriven public class PayrollMDBimplements javax.jms.MessageListener {
public void onMessage(Message msg) {...
}}
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 24
AccessoAccesso allall’’AmbienteAmbientee Dependency Injectione Dependency Injection
Come già accennato, si accede all’ambiente di esecuzionetramite dependency injection o azioni di lookup semplificate
Dipendenze specificate tramite annotation o descrittori(parziali) basati su XML
Annotation per l’accesso all’ambiente:
@ResourceUtilizzata per indicare factory di connessioni, semplici entry di ambiente,
topic/queue per JMS, EJBContext, UserTransaction, ...
@EJBUtilizzata per indicare interfacce applicative che sono EJB o per integrare
interfacce EJBHome di versioni precedenti
@PersistenceContext, @PersistenceUnitUtilizzate per EntityManager (vedremo in relazione a Java Persistence)
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 25
// EJB 3.0 Stateless Session Bean: classe bean// Accesso ai dati usando injection e Java Persistence API
@Stateless public class PayrollBean implements Payroll {
@PersistenceContext EntityManager payrollMgr;
public void setTaxDeductions(int empId, int deductions) {payrollMgr.find(Employee.class, empId).setTaxDeductions
(deductions);}}
EsempioEsempio
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 26
Qualche Ulteriore Dettaglio su Dependency Injection…
Annotazione @Resource serve a dichiarare un riferimento a una risorsa, come sorgenti dati o hook all’ambiente di esecuzione
Equivalente della dichiarazione di un elemento resource-ref neldeployment descriptor
@Resource può essere specificata a livello di classe, metodo o campo
Il container è responsabile per la gestione delladependency injcetion e per completare il binding verso la risorsa JNDI appropriata
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 27
Qualche Ulteriore Dettaglio su Dependency Injection…
@Resource javax.sql.DataSource catalogDS;
public getProductsByCategory() {
Connection conn = catalogDS.getConnection();
... }
Il container si occupa dell’injection all’attodell’istanziazione del componente
Mapping con la risorsa JNDI è risolto tramite inferenza a partire dal nome catalogDS e dal tipo javax.sql.DataSource
Nel caso di risorse multiple:@Resources ({
@Resource (name="myDB" type=java.sql.DataSource),
@Resource(name="myMQ" type=javax.jms.ConnectionFactory) })
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 28
Elementi di @Resource
Più precisamente, il container si occupa dell’injection dellarisorsa nel componente o a runtime o quando ilcomponente è inizializzato, in dipendenza dal fatto chela dependency injection sia relativa a campo/metodo o a classeCampo/metodo => all’inizializzazione dell’applicazioneClasse => a runtime
@Resource ha i seguenti elementiname: nome JNDI della risorsatype: tipo (Java language type) per la risorsaauthenticationType: tipo di autenticazione da usarsishareable: possibilità di condividere la risorsamappedName: nome non portabile e implementation-specific a cui associare la risorsadescription
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 29
Elementi di @Resource
NameL’elemento name è opzionale per la injection a livello di campo o
metodoLivello di campo: nome di default è il nome del campo qualificato dal nome della classeLivello di metodo: nome di default è il nome della proprietàbasato sul metodo indicato dal nome della classe
Tipo di risorsaDeterminato da:
Livello di campo: tipo del campo che l’annotazione @Resource sta decorandoLivello di metodo: tipo della proprietà del componente chel’annotazione @Resource sta decorandoDall’elemento type di @Resource
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 30
Elementi di @Resource
authenticationType: solo per risorse di tipo connection factory. Può avere valore CONTAINER (default) o APPLICATION
shareable: usato solo per risorse che sono istanze di ORB o connection factory
mappedName: nome non portabile (su diverese implementazioni diJava EE server) e implementation-specific a cui la risorsa deveessere mappata. Usato tipicamente per riferire la risorsa al di fuoridell’application server
description: descrizione della risorsa, tipicamente nel linguaggio didefault del sistema su cui si fa il deployment della risorsa. Usato per aiutare nell’identificazione della risorsa
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 31
Injection a Livello di Campo
In questo caso, quindi, il container inferisce nome e tipodella risorsa se gli elementi name e type non sono statispecificati
public class SomeClass {@Resourceprivate javax.sql.DataSource myDB; ... }
In questo codice l’inferenza è fatta sulla base del nome della classe e del campo: com.example.SomeClass/myDB per il nome, javax.sql.DataSource.class per iltipo
public class SomeClass {@Resource(name="customerDB")private javax.sql.DataSource myDB; ... }
In questo codice, il nome JNDI è customerDB e il tipo, determinato tramiteinferenza, è javax.sql.DataSource.class
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 32
Injection a Livello di Metodo
Il container inferisce nome e tipo della risorsa se non specificati. Il metodo di set deve seguire le convenzioniclassiche dei bean per i nomi della proprietà: deve cominciare con set, restituire void come tipo di ritorno e avere un solo parametro
public class SomeClass {
private javax.sql.DataSource myDB; ...
@Resource
private void setMyDB(javax.sql.DataSource ds) {
myDB = ds;
} ... }
In questo codice il container inferisce il nome della risorsa sulla base dei nomidi classe e metodo: com.example.SomeClass/myDB per il nome, javax.sql.DataSource.class per il tipo
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 33
Injection a Livello di Metodo
Il container inferisce nome e tipo della risorsa se non specificati. Il metodo di set deve seguire le convenzioniclassiche dei bean per i nomi della proprietà: deve cominciare con set, restituire void come tipo di ritorno e avere un solo parametro
public class SomeClass {
private javax.sql.DataSource myDB; ...
@Resource(name="customerDB")
private void setMyDB(javax.sql.DataSource ds) {
myDB = ds;
} ... }
In questo codice il nome JNDI è customerDB
e il tipo javax.sql.DataSource.class
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 34
Injection a Livello di Classe
In questo caso è obbligatorio utilizzare gli elementi name e type
@Resource(name="myMessageQueue",
type="javax.jms.ConnectionFactory")
public class SomeMessageBean { ... }
@Resources serve a raggruppare insieme diverse dichiarazioni @Resource a livello di classe
@Resources({
@Resource(name="myMessageQueue",
type="javax.jms.ConnectionFactory"),
@Resource(name="myMailSession",
type="javax.mail.Session")
})
public class SomeMessageBean { ... }
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 35
Servizi Container-based
Oltre ai dettagli di programmazione, ancora più rilevante ècapire quali servizi e come vengono supportati dall’ambiente (principalmente tramite container):
Pooling e concorrenza
Transazionalità
Gestione delle connessioni a risorse
Persistenza (vedi Java Persistence API)
Messaggistica (vedi Java Messaging System – JMS)
Sicurezza
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 36
Che cos’è quindi un container?
Applicazioni multi-tier sono usualmente difficili da realizzare: codice complicato per gestire mantenimento dello stato, transazioni, multi-threading, pooling delle risorse, …
L’ambiente Java fornisce container, ovvero ambienti di esecuzione per componenti che forniscono servizi di sistema. Uso di container in molte tecnologie. Tipi di container:Java EE server (ospita EJB e Web container)
EJB container
Web container (gestisce l’esecuzione di pagine JSP e servlet)
Applet container
Container per applicazioni cliente (integrato in Web browser)
…
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 37
1) Gestione della Concorrenza
Migliaia fino a milioni di oggetti in uso simultaneo
Come gestire la relazione fra numero di clienti e numero di oggetti distribuiti richiesti per servire le richieste cliente?
Resource PoolingPooling dei componenti server-side da parte di EJB container (instance pooling). Idea base è di evitare di mantenere una istanza separata di ogni EJB per ogni cliente. Si applica a stateless session bean e message-driven bean
Anche pooling dei connector (vedremo in seguito)
ActivationUtilizzata da stateful session bean per risparmiare risorse
Discussione: voi come realizzereste
instance pooling?
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 38
Stateless Session Bean
Ogni EJB container mantiene un insieme di istanze del bean pronte per servire richieste cliente
Non esiste stato di sessione da mantenere fra richieste successive; ogni invocazione di metodo è indipendentedalle precedenti
Implementazione delle strategie di istance poolingdemandate ai vendor di EJB container, ma analoghi principi
Ciclo di vita di uno stateless session bean:No state (non istanziato; stato iniziale e terminale del ciclo di vita)
Pooled state (istanziato ma non ancora associato ad alcuna richiesta cliente)
Ready state (già associato con una richiesta EJB e pronto a rispondere ad una invocazione di metodo)
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 39
Stateless Session Bean
Istanza del bean nel pool riceve un riferimento a javax.ejb.EJBContext (in caso di richiesta di injection nel codice tramite apposita annotation)
EJBContext fornisce un’interfaccia per il bean per comunicare con l’ambiente EJB
Quando il bean passa in stato ready, EJBContext contiene anche informazioni sul cliente che sta utilizzando il bean. Inoltre contiene il riferimento al proprio EJB stub, utile per passare riferimenti ad altri bean
Ricordiamo che il fatto di essere stateless è indicato semplicemente tramite decoration con annotation @javax.ejb.Stateless (NOTA: variabili di istanza non possono essere usate per mantenere stato della sessione)
Altrimenti che cosa succederebbe?
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 40
Message-driven Bean
Come nel caso di stateless session bean, anche questi bean non mantengono lo stato della sessione e quindi il container può effettuare pooling in modo relativamente semplice
Strategie di pooling analoghe alle precedenti. Unica differenza che ogni EJB container contiene molti pool, ciascuno dei quali è composto di istanze con la stessa destination JMS
Messaggi asincroni in JMS e processamento messaggi da parte di message-driven bean prima del delivery verso il destinatario (lo vedremo quando parleremo di JMS)
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 41
Activation
Usata nel caso di stateful session bean
Gestione della coppia oggetto EJB + istanza di bean stateful
Passivation: disassociazione fra stateful bean instance e suo oggetto EJB, con salvataggio dell’istanza su memoria (serializzazione). Processo del tutto trasparente per cliente
Activation: recupero dalla memoria (deserializzazione) dello stato dell’istanza e riassociazione con oggetto EJB
Nella specifica J2EE, non richiesto che la classe di uno stateful sessionbean sia serializzabile. Quindi?
Dipendenza dall’implementazione dello specifico vendor e attenzione al trattamento dei transient…
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 42
Activation
La procedura di activation può essere associata anche all’invocazione di metodi di callback sui cambi di stato nel ciclo di vita di uno stateful session bean
Ad esempio, l’annotation @javax.ejb.PostActivate associa l’invocazione del metodo a cui si applica immediatamente dopo l’attivazione di un’istanza
Similmente, @javax.ejb.PrePassivate (prima dell’azione di passivation)
Ad esempio, utilizzati spesso per la chiusura/apertura di connessioni a risorse per gestione più efficiente (a default vengono mantenuti e serializzati nello stato solo i riferimenti remoti ad altri bean, a SessionContext, al servizio EntityManager e all’oggetto UserTransaction, descritti in seguito)
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 43
Gestione Concorrenza
Per definizione, session bean non possono essere concorrenti, nel senso che una singola istanza èassociata ad un singolo cliente
Vietato l’utilizzo di thread a livello applicativo e, ad esempio, della keyword synchronized
Una singola istanza di entity bean invece può essere acceduta da più clienti: JPA e copia dell’istanza in dipendenza dalla transazione (vedi nel seguito)
Message-driven bean e concorrenza come processamento concorrente di più messaggi verso la stessa destinazione: ovviamente, supportata
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 44
2) Transazioni
Sappiamo tutti, vero ☺?, che cosa si intende per transazione e per proprietà di transazionalità
Proprietà ACID (Atomicity, Consistency, Isolation e Durability)
Transazione come unità indivisibile di processamento; può terminare con un commit o un rollback
Session bean e message-driven bean possono sfruttare o Container-Managed Transaction o Bean-ManagedTransaction
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 45
DemarcazioneDemarcazione AutomaticaAutomatica: : ContainerContainer--Managed Trans.Managed Trans.
Sono la tipologia di defaultTransazione associata con l’intera esecuzione di un metodo (demarcazione automatica della transazione: inizioimmediatamente prima dell’esecuzione del metodo e commit immediatamente prima della terminazione del metodo)
NON si possono utilizzare metodi per la gestione delletransazioni che interferiscano con la gestioneautomatica del container (ad esempio, proibito l’uso di commito rollback di java.sql.Connection, di rollback di javax.jms.Sessiono dell’intera interfaccia javax.Transaction.UserTransaction)
Annotation: @TransactionManagementValore uguale a container (default) oppure a bean
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 46
ContainerContainer--Managed TransactionManaged Transaction
I cosiddetti attributi di transazione permettonodi controllare lo scope di una transazione
Perchè sono necessari?
Annotation: @TransactionAttributeValori possibili: REQUIRED (implicito a default), REQUIRES_NEW, MANDATORY, NOT_SUPPORTED, SUPPORTS, NEVER
…
method1(){
…
bean2.method2();
}
…
method2(){
…
}
bean1 bean2
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 47
ContainerContainer--Managed TransactionManaged Transaction
Nessuna
Errore
Nessuna
T1
Never
Nessuna
T1
Nessuna
T1
Supports
Nessuna
Nessuna
Nessuna
T1
NotSupported
Errore
T1
Nessuna
T1
Mandatory
T2
T2
Nessuna
T1
RequiresNew
T2
T1
Nessuna
T1
Required
Transazione lato servitore?
Transazione lato cliente?
Attributo
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 48
ContainerContainer--Managed TransactionManaged Transaction
Rollback di una transazione di questo tipo può esserescatenato da due cause:Eccezione di sistema => il container automaticamente lancia ilrollback
Invocando il metodo setRollBackOnly di EJBContext
È possibile sincronizzare l’esecuzione di un session bean a seconda di eventi dovuti alla transazione:metodo afterBegin invocato dal container immediatamenteprima dell’invocazione del metodo di business all’interno dellatransazione
metodo beforeCompletion invocato dal container immediatamente prima del commit della transazione
metodo afterCompletion invocato dal container immediatamente dopo il completamente della transazione (con commit o rollback)
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 49
BeanBean--Managed TransactionManaged Transaction
I limiti di demarcazione della transazione sono in questo caso decisi dal programmatore stesso
Maggiore complessità ma maggiore flessibilitàAd esempio:begin transaction
… update tableA
…
if (condition1) commit transaction
else if (condition2) { update tableB
commit transaction }
else rollback transaction …
Possibilità di utilizzo di Java Transactions API per indipendenzadall’implementazione dello specifico transaction manager
Sia per Container- che Bean-Managed, possibilità diconfigurare l’intervallo di timeout per le transazioni(Admin Console di J2EE); valore di default 0, ovvero nessun timeout
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 50
// EJB 3.0: Container-managed transaction@TransactionAttribute(MANDATORY)@Stateless public class PayrollBean implements Payroll {
public void setTaxDeductions(int empId,int deductions) {...
}@TransactionAttribute(REQUIRED) public int getTaxDeductions(int empId) {
...} }
EsempioEsempio
// EJB 3.0: Bean-managed transaction
@TransactionManagement(BEAN)@Stateless public class PayrollBean implements Payroll {
@Resource UserTransaction utx;@PersistenceContext EntityManager payrollMgr;
public void setTaxDeductions(int empId, int deductions) {utx.begin();payrollMgr.find(Employee.class, empId).setDeductions(deductions);utx.commit();
} ... }
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 51
3) Gestione Connessioni a Risorse
Un componente può avere bisogno di utilizzare altri componenti e risorse, come database e sistemi di messaging, ad esempio
In Java EE il ritrovamento delle risorse desiderate è basato su un sistema di nomi ad alta portabilità come Java Naming and Directory Interface (JNDI)
Se un componente usa resource injection, sarà il container a utilizzare JNDI per ritrovare la risorsa desiderata, e non il componente stesso com’era usuale prima di EJB3.0
In particolare, relativamente a risorse a database, connection pooling: connessioni sono riutilizzabili per ridurre latenza e incrementare prestazioni nell’accesso a DB
Vedi quanto detto precedentemente per annotazione @Resource
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 52
4) 4) PersistenzaPersistenza
Semplificare il modello di programmazione degli entity beanSupporto ad una modellazione lightweight e semplificata del dominio, che consenta ereditarietà e polimorfismo
Ricche capacità di query
Supporto per mapping mondo a oggetti/relazionale
Rendere le istanze delle entità utilizzabili anche fuori daun container EJB
Rimozione delle necessità di DTO e antipattern simili
Evoluzione verso API di Java persistence comuniIntegrata l’esperienza e il feedback da Hibernate, Java Data Objects, TopLink, e precedenti versioni di tecnologia EJB
Supporto per provider di persistenza come terze parti, anchedeterminabili dinamicamente
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 53
ModelloModello didiPersistenzaPersistenza in EJB3.0in EJB3.0
Entità sono semplici classi JavaClassi “normali” – semplice utilizzo di new
Metodi per effettuare get/set di proprietà o variabili diistanza persistenti
Interfacce bean e interfacce di callback NON necessarie
Utilizzabili anche come oggetti “detached” in altri tier delleapplicazioni
Nessuna necessità di DTO
EntityManager svolge il ruolo di “Home” non tipataper le operazioni di entity
Metodi per le operazioni sul ciclo di vita (persist, remove, merge, flush, refresh, ...)
Funzionalità simili a Hibernate Session, JDO PersistenceManager, …
Gestisce il contesto della persistenza, sia con lo scope dellasingola transazione che con scope più esteso
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 54
PersistenzaPersistenza: : Mapping O/RMapping O/R
Facility di supporto di semplice utilizzo per effettuare il mapping fra modello a oggetti e modello di database relazionaleLo sviluppatore ha visibilità di tale mapping
Ne ha pieno controllo e ha consapevolezza dellasemantica associata
Mapping può essere espresso tramiteannotation o frammenti di descrittore XML
Supporto a mapping di default
Per il resto dei dettagli su mapping O/R, posso confidarenel corso di Sistemi Informativi LS ☺?
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 55
5) Messaging
Java Messaging System (JMS) come servizio di supportoJ2EE: specifica che definisce come un cliente JMS acceda alle funzionalità supportate da un sistema dimessaging di livello enterprise. Solitamente:Produzione, distribuzione e consegna di messaggiSemantiche di consegna supportate:
sincrona/asincronatransacted garantitadurevole
Java™ ApplicationJava™ Application
JMS APIJMS API
JMS Provider
JMS Provider
IBMMQSeries
IBMMQSeries
JMS Provider
JMS Provider
ProgressSonicMqProgressSonicMq
JMS Provider
JMS Provider
FioranoFiorano
JMS Provider
JMS Provider
JMS Provider
JMS Provider
BEABEA SUN MQSUN MQ
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 56
Messaging
Supporto ai principali modelli di messaging in uso
Point-to-Point (code affidabili)
Publish/Subscribe
Selettori di messaggi (lato ricevente)
Diverse tipologie di messaggi (le vedremo in seguito…)
JMS Provider
EJB Container
Destin-ation
ConsumerInstances
Msg-drivenBean Class
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 57
MDB come consumatoridi messaggi JMS
OrderBean
InventoryManagement
Bean
MessageDrivenBean
JMS Topics
Publish/subscribe
ProcessOrder
Procure Inventory
<Entity EJB>
<Entity EJB>
Message-driven bean come consumatori asincroni di messaggi JMS. Ad esempio:
Perché èimportante che
siano asincroni?
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 58
6) Sicurezza
Il container EJB è anche responsabile per svolgere azionidi controllo dell’accesso sui metodi del beanConsulta policy di sicurezza da applicare (derivante dal deployment descriptor) per determinare i differenti ruoli con accesso al bean
Per ogni ruolo, il container EJB usa il contesto di sicurezzaassociato con l’invocazione per determinare i permessi di chiamata
“is authorized” quando il container può mappare le credenziali del chiamante ad un ruolo autorizzato: controllo passato a EJB
“not authorized” => container lancia un’eccezione
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 59
Sicurezza e Meccanismi
Già Java SE supporta numerose funzionalità e meccanismi di sicurezza. Ad esempio:
Java Authentication and Authorization Service (JAAS)
JavaGeneric Security Services (Java GSS-API): token-based API per lo scambio sicuro di messaggi fra applicazioni (anche Kerberos-based)
Java Cryptography Extension (JCE): meccanismi per crittografiasimmetrica, asimmetrica, ciphering blocco/flusso, …
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 60
Sicurezza: realm e ruoli
e ancora:
Java Secure Sockets Extension (JSSE): protocolli SSL e TLS
Simple Authentication and Security Layer (SASL): Internet standard (RFC 2222) per definire come i dati di autenticazione debbano esserescambiati
Il container EJB basa le sue decisioni di sicurezza sui concetti di Realm, Utenti, Gruppi e Ruoli
Realm come collezione di utenti di una singola applicazione (o diun loro insieme), controllati dalla stessa policy di autenticazione. Possono o meno essere parte dello stesso gruppo
Ad esempio, nel realm predefinito “file” informazioni di autenticazionememorizzate nel file keyfile; nel realm predefinito “certificate”, informazioni mantenute in un db di certificati X.509
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 61
Sicurezza: realm e ruoli
Sicurezza: realm, gruppi, ruoli e utenti
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 62
SicurezzaSicurezza
Definizione di permessi di esecuzione sui metodiRuoli a cui si concede il diritto di eseguire un dato insieme di metodi
Annotation@RolesAllowed (valore è una lista di nomi di ruoli), @PermitAll,
@DenyAll (applicabile solo a livello di singolo metodo)
Identità (principal) del chiamante
@RunAs per definire il principal di esecuzione
Determinazione dei ruoli di sicurezza svolta a runtime dal container
La configurazione della sicurezza viene tipicamentesvolta a deployment time in ambienti enterprise
Sviluppatori possono però dare una guida…
Attributi di sicurezza (se non specificati => configurati al deployment o non controllati)
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 63
EsempioEsempio
// EJB 3.0: Sicurezza
@Stateless public PayrollBean implements Payroll {
public void setBenefitsDeduction(int empId, double deduction) {...}
public double getBenefitsDeduction(int empId) {...}
public double getSalary(int empid) {...}
// setting del salario ha un accesso più restrittivo@RolesAllowed(“HR_PayrollAdministrator”)public void setSalary(int empId, double salary) {...}
}
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 64
ServiziServizi addizionaliaddizionali::gligli IntercettoriIntercettori
Sono una facility di semplice utilizzo per la realizzazionedi casi e applicazioni avanzati. Sono oggetti capaci diinterporsi sulle chiamate di metodo o su eventi del ciclo di vita di session e message-driven beanContainer si interpone sempre sulle invocazioni dei metodi dellalogica applicativa
Gli intercettori (interceptor), quando presenti, si interpongonodopo il container stesso (quindi prima dell’esecuzione del metododella logica applicativa)
Esempio di quanto tempo impiega l’esecuzione di un metodolong startTime=System.currentTimeMillis();
try { …
} finally { long endTime=System.currentTimeMillis() – startTime; …
}Perché non ci piace troppo?
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 65
ServiziServizi addizionaliaddizionali::gligli IntercettoriIntercettori
Modello di invocazione: metodi “around”Fanno da wrapper per l’invocazione dei metodi di business
Controllano l’invocazione del metodo successivo (sia di altrointercettore che di business, vedi InvocationContext.proceed())
Possono manipolare argomenti e risultati
Invocati nello stesso stack di chiamate Java, con stessocontesto di sicurezza e di transazioni
Dati di contesto possono anche essere mantenuti nellacatena degli intercettori (vedi javax.interceptor. InvocationContext)
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 66
Annotation: @Interceptors (per associare una classe/metododi un componente di business alla classe intercettore correlata), @AroundInvoke (per definire quale metodo della classeintercettore eseguire all’atto dell’intercettazione)
Intercettori di defaultSi applicano a tutti i metodi di business di ogni componentenel file ejb-jarSpecificati nel descrittore di deployment
Non ci sono metadati di annotation a livello di applicazione
Intercettori a livello di classeSi applicano ai metodi di business della classe bean
Intercettori a livello di metodo, anche per fare overriding diassociazioni precedenti
IntercettoriIntercettori
EJB3.0 e Servizi di Sistema – Sistemi Distribuiti LS 67
Ad esempio://classe Profiler
public class Profiler {
@AroundInvoke
public Object profile() throws Exception {
… }
}
//classe intercettata
…
@Interceptors(Profiler.class)
public Objecty m1(…) throws … {
… }
IntercettoriIntercettori