Progettazione e realizzazione di un’applicazione J2EE

Corso TAPS 2001/02

Gianna Reggio

si assumono già conosciuti

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

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

VALIDO IN GENERALE

• 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

Accesso ai bean per mezzo di interfacce

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

VALIDO IN GENERALE

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

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

EsempioItem Sintassi

quelli marcati DD si trovano nel deployment descriptor

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

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

per metterlo toglierlodalla memoriaquando poco usato

può ricevere le chiamate dei business method dal cliente

definito per ogni bean

invocati dal cliente

invocati dal container

Ciclo di vita di un Stateless Session Bean

definito per ogni bean

invocati dal container

Ciclo di vita di un Entity Bean

istanze non associate ad alcun identità

invocati dal cliente

invocati dal container

Ciclo di vita di un Message-Driven Bean

invocati dal container

riepilogo

TransactionsIl 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

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 transazione3. 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

Required

RequiresNew

T1

No-trans New-trans

T1

No-trans New-trans

T1 New-trans

Mandatory No-trans errore

T1 T1

NotSupported

Supports

No-trans

No-trans No-trans

T1

No-trans No-trans

T1 T1

Never No-trans No-trans

T1 error

BeanClient

M(…)

BeanTransaction Attribute di M Client

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