EJB
annuncio pubblicitario
Progettazione e realizzazione di un’applicazione J2EE Corso TAPS 2001/02 Gianna Reggio Che cosa occorre (1) • conoscere “concettualemente”/dal punto di vista del design le varie parti – per lo strato server-business (non vediamo quello Web) * Enterprise Javebeans * i servizi gestiti dal container (sicurezza, transaction, persistenza) * le API più rilevanti (messaging, Javamail) – per lo strato client * Java * GUI (AWT/SWING) – per lo strato EIS * useremo solo un database con EJBC o gestito dal container si assumono già conosciuti Che cosa occorre (2) • conoscere i dettagli a livello di codice, formati, procedure per realizzare le varie parti – Enterprise Javebeans sono specializazioni della class … e sono impaccati in un file .jar… • conoscere i tools che possono aiutare a svolgere le attività collegagte Enterprise Javabeans • Reusable components – classe di tipo “bean” + classi ausiliari – un oggetto a “run-time” • Business tier = container pieno di enterprise beans • sono di tre tipi – Session bean * eseguono un task per un client * es…………. – Entity bean * rappresentano un business entity object esistente nella memoria stabile * es…………. – Message-Driven bean * è un listener per messaggi asincroni del genere “Java Message Service” * es…………. Session Bean • rappresenta un singolo cliente all’interno del server J2EE, o meglio una sessione interattiva del cliente • per accedere ad un’applicazione installata sul server il cliente invoca i session beans • i session bean fanno il lavoro • non sono condivisi tra diversi clienti • non sono persistenti (cioè, i loro dati non sono salvati su un database) • quando il cliente termina la sua sessione il bean sparisce • Due tipi – Stateful e stateless Stateful Session Bean • lo stato di un oggetto consiste nei valori delle sue instance variables • In un stateful session bean, le sue instance variables rappresentano lo stato di un’unica sessione client-bean • Lo stato viene conservato per la durata della sessione client-bean • Se il cliente rimuove il bean o termina, la sessione finisce, e lo stato scompare • E questo non è un problema, poichè quando termina la “conversazione” tra il cliente e il bean finisce, non c’è bisogno di conservare lo stato Stateless Session Bean • un stateless session bean non contiene uno stato di una conversazione con un particolare cliente • Quando un cliente invoca un metodo di un stateless bean, le instance variables del bean possono contenere uno stato, ma solo per la durata dell’invocazione; quando il metodo è finito lo stato non è conservato • Eccetto durante l’invocazione dei metodi tutte le istanze dei bean stateless sono equivalenti, permettendo al container EJB di assegnarle ai clienti • Poichè stateless session beans possono supportare differenti clienti, possono offrire una migliore scalabilità per applicazioni che richiedono un grande numero di clienti • Un’applicazione, in genere, richiede meno stateless session beans che stateful session beans per supportare lo stesso numero di clienti • Di tanto in tanto il container EJB deve scrivere un stateful session bean sulla memoria secondaria, mentre gli stateless session beans non sono mai scritti, quindi gli stateless beans possono garantire una migliore efficienza che gli stateful beans Quando usare i Session Beans (1) • In generale, si dovrebbe usare un session bean se – In ogni momento, solo un cliente ha accesso all’istanza del bean – Lo stato del bean non è persistente, ma esiste solo per un periodo di tempo limitato (forse alcune ore) • Gli stateful session beans se vale una delle seguenti condizioni – lo stato del bean rappresenta l’interazione tra il bean e uno specifico cliente – Il bean deve ritenere delle informazioni sul cliente tra le invocazioni dei vari metodi da parte del cliente – Il bean media tra il cliente e le altre componenti dell’applicazione, presentando una vista semplificata al – dietro le scene il bean gestisce il work flow di diversi enterprise beans Quando usare i Session Beans (2) • Per migliorare l’efficienza si può usare un stateless session bean, se ha uno di questi tratti – Lo stato del bean non contiene dati specifici del cliente – Durante l’invocazione di un metodo, il bean esegue un compito generico per tutti i clienti (es., per mandare la conferma di un ordine via e-mail) – Il bean recupera un insieme di dati read-only usati frequentemente dai clienti (es., per recuperare I dati relativi ai prodotti speciali del mese) Entity Bean (1) • Rappresenta un “oggetto del business” conservato in un meccanismo di memoria persistente [database relazionale] (es., consumatori, ordini, e prodotti) • tipicamente un entity bean corrisponde ad una tabella in un database relazionale, ed ogni istanza del bean corrisponde ad una riga nella tabella • le differenze principali con i session beans – – – – sono persistenti sono condivisi hanno chiavi primarie per identificarli possono essere legati ad altri beans da relazioni Entity Bean (2) • Persistenza – Due tipi * Gestita dal bean ˚ Il codice del bean contiene le chiamate al database * Gestita dal contenitore ˚ il container EJB genera automaticamente le chiamate al database • Condivisi – Possono essere condivisi fra vari clienti – Poichè diversi clienti possono volere cambiare gli stessi dati, è importante che siano dotati di un meccanismo di transazioni – In genere, il contenitore fornisce la gestione delle transazioni – La definizione dei limiti delle transazioni viene data nel deployment descriptor del bean Entity Bean (3) • Chiave primaria – Ogni entity bean ha un unico “identificatore” (es., un entity bean consumatore può essere identificato da un codice) – La chiave primaria permette al cliente di localizzare un particolare entity bean • Relazioni – Come in un database relazionale, gli entity bean possono essere collegati da relazioni * Orientate * Con molteplicità 1 o molti – se la persistenza è * Gestita dal bean ˚ Il codice del bean deve gestire le relazioni * Gestita dal contenitore ˚ Il container ci pensa lui Persistenza gestita dal container (1) • Il container EJB gestisce tutti gli accessi al database necessari; il codice del bean non contiene istruzioni SQL – quindi, il bean non è legato ad uno specifico database, pertanto se il bean è riinstallato su un altro server, non occorre modificare o ricompilare il codice dal bean, il bean è molti più portabile • per generare gli accessi al database il container necessita delle informazioni data dallo • schema astratto dell’entity bean – è parte del deployment descriptor del bean, e definisce i campi persistenti del bean e le sue relazioni con altri entity bean – astratto per distinguerlo dallo schema “concreto” del/dei database a cui il bean sarà collegato Persistenza gestita dal container (2) • schema astratto dell’entity bean (cont.) – si specifica il nome di uno schema astratto nel deployment descriptor – questo nome viene usato in query scritte in EJB QL (Enterprise JavaBeans Query Language) – occorre definire una query EJB QL per ogni finder method (eccetto findByPrimaryKey) – la query EJB QL determina la query che è eseguita dal container EJB quando il finder method è invocato • campi persistenti – sono immagazzinati nel sottostante database – collettivamente costituiscono lo stato del bean – a runtime, il container EJB automaticamente sincronizza questo stato con lo stato del database – durante il deployment, il container tipicamente mappa l’entity bean su una tabella di undatabase e mappa i campi persistenti sulle colonne di tale tabella Persistenza gestita dal container (3) • campo relazione – è come una chiave esterna in una tabella di un database, identifica il bean collegato dalla relazione – come i campi persistenti, è virtuale ed è definita nella classe del bean con gli access method • le relazioni gestite dal container – hanno molteplicità * One-to-one * One-to-many * Many-to-one * Many-to-many – sono * unidirezionali (un solo campo relazione, nel bean di partenza) * bidirezionali (due campi relazione, in entrambi i bean) Quando usare gli Entity Beans • In generale, si dovrebbe usare un entity bean se – il bean rappresenta una business entity, non una procedura (es., “carta di credito” sarebbe un entity bean, ma il “controlla carta di credito” sarebbe un session bean) – lo stato del bean deve essere persistente; se il bean termina o se il server J2EE è spento lo stato del bean esiste ancora (in un database) Message-Driven Bean (1) • un enterprise bean che permette alle applicazioni J2EE di processare messaggi asincroni – agisce come un JMS message listener, che è simila ad un event listener eccetto che ricveve messaggi, invece di eventi – i messaggi possono essere mandati da ogni componente J2EE (application client, un altro enterprise bean, or una component Web) o da una applicazione JMS o da un sistema che non usa la tecnologia J2EE • differenze con i session bean – i clienti non accedono ai message-driven bean attraverso interfaccie (dopo) • assomigliano a stateless session bean – le istanze non tengono ne dati, ne lo stato di una conversazione con il cliente – tutte le istanze di un message-driven bean sono equivalenti, permettendo al container di assegnare i messaggi ad una qualunque istanza [es., una stream di messaggi può essere processata in modo concorrente] – un singolo message-driven bean può processare messagi provenienti da diversi clienti Message-Driven Bean (2) • caratteristiche – Le instance variables delle istanze dei message-driven bean possono mantenere dei valori durante il trattamento dei messaggi – quando un messaggio arriva, il container chiama il metodo del bean onMessage per processarlo – onMessage può chiamare metodi helper, o può invocare un session o un entity bean per processare l’informazione o immagazzinarla in una database – un messaggio può essere consegnato ad un message-driven bean dentro il contesto di una transazione così che se il processamento del messaggio è rolled back, il messaggio sarà redelivered • quando usare un message-driven bean – session bean e entity bean permettono di ricevere e mandare messaggi JMS e di riceverli in modo sincrono, ma non asincronamente – per ricevere messaggi asincronamente usare un message-driven bean Accesso ai bean per mezzo di interfacce • un cliente può accedere un session o un entity bean solo attraverso i metodi definiti nelle sue interfacce – esse definiscono il punto di vista da parte del cliente del bean – tutti gli altri aspetti (implementazione dei metodi, i setting contenuti nel deployment descriptor, schema astratto, e accessi al database) sono nascosti • interfacce ben progettate semplificano lo sviluppo ed il mantenimento delle applicazioni J2EE – non solo proteggono i clienti dalle complessità dell’EJB tier, ma permettono anche di cambiare il bean al suo interno, senza influenzare i clienti (es., si può cambiare la persistenza di un entity bean senza che il client se ne accorga) – ma se si cambiano i metodi nelle interfacce, allora occorre modificare i clienti – pertanto è importante isolare i clienti il più possibile dai cambi nei bean VALIDO IN GENERALE Accesso remoto • un cliente remoto di un bean ha le seguenti caratteristiche – può girare su una macchina diverso o su una Java VM diversa da quella del bean – può essere una componente Web, un’application client J2EE, o un altro enterprise bean – al cliente remoto la locazione del bean non interessa • un bean che permette l’accesso remoto deve avere due interfacce – remote interface * business method specifici del bean – home interface * life cycle methods (create e remove) * finder method per gli entity bean (servono a ricercare tali bean) Accesso remoto (esempio) Accesso locale • un cliente locale di un bean ha le seguenti caratteristiche – deve girare sulla stessa Java VM del bean – può essere una componente Web o un altro enterprise bean – la locazione del bean non è trasparente al cliente locale – frequentemente è un entity bean che ha una relazione gestita dal contenitore con un entity bean • un bean che permette l’accesso locale deve avere due interfacce – local interface * business method specifici del bean – home interface * life cycle methods (create e remove) * finder method per gli entity bean (servono a ricercare tali bean) Relazioni gestite dal contenitore e interfacce locali • se un bean è il target di una relzione gestita dal contenitore deve avere una interfaccia locale (per ricevere chiamate da coloro con cui è in relazione) accesso locale versus remoto (1) • occorre considerare i seguenti fattori – relazioni gestite dal contenitore * se un entity bean è il target di una di queste relazioni deve permettere l’accesso locale – Tight o loose coupling di bean * se hanno strette relazioni con altri bean, in genere beneficiano di accesso locale (più efficiente) – tipo dei clienti * se un enterprise bean è usato da un J2EE application client, allora dovrà permettere l’accesso remoto, dato che in genere essi girano su macchine diverse dal server J2EE * se i clienti sono componenti Web o altri enterprise bean, allora il tipo degli accessi dipende da quanto si vuole distribuire le varie componenti – distribuzione delle componenti * le applicazioni J2EE sono scalabili poichè le componenti del server-tier possono essere distribuite su molte macchine (es. le componenti Web possono girare su una macchine differente da quella dei bean che accedono) * in uno scenario distribuito gli enterprise bean devono permettere l’accesso remoto accesso locale versus remoto (2) – se non si è certi di quale tipo di accesso usare, scegliere remoto, in modo da evitare di precludere future realizzazioni distribuite – sebbene non comune, è possibile definire un enterprise bean con acesso remoto e locale, basta definire sia l’interfaccia remota che quella locale • tipo di accesso e prestazioni – la scelta della distribuzione della propria applicazione può influenzare le prestazioni * accesso remoto più lento * distribuzione permette compiti in parallelo, più veloce VALIDO IN GENERALE Tipo di accesso e passaggio dei parametri (1) • il tipo di accesso influenza il passaggio dei parametri dei metodi (anche del valore di ritorno) – un argomento di una chiamata remota è passato per valore, è una copia di un oggetto – un argomento di una chiamata locale è passato per riferimento, come ogni normale chiamata di un metodo in Java – i parametri delle chiamate remote sono più isolati, il chiamante ed il chiamato operano su copie differenti dell’oggetto parametro * se il cliente cambia il valore di tale oggetto, la copia nel bean non cambia ˚ questa forma di isolamento aiuta a proteggere il bean se il cliente inavvertitamente modifica il dato * in una chiamata locale, sia il cliente che il bean possono modificare lo stesso oggetto ˚ non usare troppo questa tecnica, poichè non permette di rimpiazzare la chiamata locale con una remota nel futuro Tipo di accesso e passaggio dei parametri (2) • granularità dei dati passati – poichè le chiamate remote in genere sono più lente di quelle locali, i parametri dei metodi remoti dovrebbero essere più “grossi” contenenti più dati, cosicché sono necessarie meno chiamate Il contenuto di un Enterprise Bean • per produrre un bean occorre fornire i seguenti file – Deployment descriptor * un file XML che specifica informazioni sul bean, come il tipo di persistenza, e le eventuali transazioni * esistono tool che aiutano a prepararlo – Enterprise bean class * implementa i metodi contenuto nelle sue interfacce: remote + home, oppure, local + home (ricordare che i message-driven bean non hanno queste interfacce) – Helper classes * altre classi necessarie alla classe bean, come classi exception e utility questi file devono essere impacchettati in un file EJB JAR file, il modulo che immagazzina l’enterprise bean un file EJB JAR è portabile e può essere utilizzato per costruire molte diverse applicazioni Convenzioni per i nomi degli enterprise bean Item Esempio Sintassi Enterprise bean name (DD) <name>EJB AccountEJB EJB JAR display name (DD) <name>JAR AccountJAR Enterprise bean class <name>Bean AccountBean Home interface <name>Home AccountHome Remote interface <name> Account Local home interface Local<name>Home LocalAccountHome Local interface Local<name> LocalAccount Abstract schema (DD) <name> Account quelli marcati DD si trovano nel deployment descriptor Il ciclo di vita degli Enterprise Bean • un enterprise bean passa attraverso differenti stadi durante la sua vita • ogni tipo di enterprise bean (session, entity, o message-driven) ha un tipo di vita differente • conoscere tali cicli di vita, aiuta a capire come funzionano, quali metodi occorre definire nelle relative classi Ciclo di vita di un Stateful Session Bean invocati dal cliente per metterlo toglierlo dalla memoria quando poco usato definito per ogni bean invocati dal container può ricevere le chiamate dei business method dal cliente Ciclo di vita di un Stateless Session Bean definito per ogni bean invocati dal container Ciclo di vita di un Entity Bean invocati dal cliente invocati dal container istanze non associate ad alcun identità Ciclo di vita di un Message-Driven Bean invocati dal container Transactions Il problema • Una tipica applicazione enterprise accede e modifica informazioni immagazzinate in uno o più database • Dato che questa informazione è critica per le attività del business, deve essere accurata, aggiornata, e affidabile • L’integrità dei dati si perderebbe – se diversi programmi potessero modificare la stessa informazione simultaneamente – o se il sistema fallisse mentre processava una “business transaction” e lasciasse i dati coinvolti modificati in modo parziale • Il meccanismo software delle transazioni assicura l’integrità dei dati in entrambi gli scenari – Controllano l’accesso ai dati da parte di diversi programmi – In caso di fallimento del sistema, assicurano che dopo il recovery, i dati siano in uno stato consistente riepilogo Transazione: cosa è? • Un gruppo di statement/azioni/step considerati come un tutt’uno • devono essere eseguiti tutti o nessuno, altrimenti l’integrità dei dati è persa – es…… • Una transazione può finire in due modi – con un commit * le modifiche dei dati fatte dagli statement sono salvate – o con un rollback * in caso di fallimento, gli effetti degli statement sono annullati • In J2EE le transazioni possono * Essere gestite dal container * Essere gestite dai bean Container-Managed Transaction • Si può usare per ogni tipo di enterprise bean (session, entity, o message-driven) • Lo sviluppo è semplificato, poichè non occorre marcare le transazioni sul codice del bean • Il container EJB pone i limiti delle transazioni • tipicamente, il container inizia una transazione immediatamente prima che un metodo del bean inizi, e la finisce giusto prima della fine di tale metodo • ogni metodo può essere associato con una singola transazione, transazioni multiple o innestate non sono ammesse • non è necessario associare una transazione con ogni metodo • quando si usa un bean per costruire un’applicazione, si specifica quali metodi del bean sono associati con le transazioni, fissando gli attributi di transazione Transaction Attributes (1) • Controllano lo scope di una transazione • Perché è importante ? • L’esecuzione di B è dentro lo scope della transazione dove è avvenuta la chiamata?, o dentro una nuova transazione • L’attributo di transazione di B permette di ripondere a ciò Transaction Attributes (2) Required – se il cliente è dentro una transazione e invoca il metodo, il metodo viene eseguito dentro la transazione del cliente – se il cliente non è dentro una transazione, il container inizia una nuova transazione prima di iniziare il metodo Funziona per la maggior parte dei casi * Quindi si potrebe usare come defualt, almeno all’inizio dello sviluppo, tanto è possibile cambiarlo dopo RequiresNew – se il cliente è dentro una transazione e invoca il metodo, il container fa le seguenti cose 1. sospende la transazione del cliente 2. inizia una nuova transazione 3. esegue il metodo dentro essa 4. dopo il completamento del metodo, riprende la transazione del cliente – se il cliente non è dentro una transazione, il container inizia una nuova transazione prima di iniziare il metodo Si deve usare quando si vuole essere certi che il metodo viene sempre eseguito in una nuova transazione Transaction Attributes (3) Mandatory – se il cliente è dentro una transazione e invoca il metodo, il metodo viene eseguito dentro la transazione del cliente – se il cliente non è dentro una transazione, il container lancia l’eccezione TransactionRequiredException Si deve usare quando si vuole essere certi che il metodo viene sempre eseguito nella transazione del cliente NotSupported – se il cliente è dentro una transazione e invoca il metodo, il container fa le seguenti cose 1.sospende la transazione del cliente 2.esegue il metodo fuori da ogni transazione 3. dopo il completamento del metodo, riprende la transazione del cliente – se il cliente non è dentro una transazione, il container non inizia una nuova transazione Si deve usare quando non è neccessario che il metodo sia eseguito in una transazione (evitare le transazioni, migliora le prestazioni) Transaction Attributes (4) Supports – se il cliente è dentro una transazione e invoca il metodo, il metodo viene eseguito dentro la transazione del cliente – se il cliente non è dentro una transazione, il container non inizia una nuova transazione Dato che il comportamento del metodo dipende varia in dipendenza del chiamante, usarlo con cauzione Never – se il cliente non è dentro una transazione, il container lancia l’eccezione RemoteException – se il cliente non è dentro una transazione, il container non inizia una nuova transazione Transaction Attributes (5) • Fissare i Transaction Attributes – Dato che sono conservati nel deployment descriptor del bean, possono essere cambiati durante tutte le fasi dello sviluppo delle applicazioni J2EE – Tuttavia lo sviluppatore del bean deve specificare questi attributi quando lo crea – ed essi dovrebbero essere modificati solo dallo sviluppatore di applicazioni, quando assembla le componenti – mentre, non si dovrebbe fare conto sull’installatore per fissarli – è possibile fissare gli attributi per un bean o per un singolo metodo (se ci sono entrambi, l’attributo del metodo ha la precedenza) Transaction Attributes: sommario Bean Client M(…) Transaction Attribute di M Bean Client Required No-trans RequiresNew No-trans New-trans T1 Mandatory No-trans New-trans errore NotSupported No-trans Supports No-trans Never No-trans T1 T1 T1 T1 T1 New-trans T1 T1 No-trans No-trans No-trans T1 No-trans error Bean-Managed Transaction • Permessa solo per session e message-driven bean – Utilizzando i meccanismi del database con JDBC – Utilizzando l’API JTA, che implementa le transaction con il “JTS” (Java Transaction Service) Fine lezione
