ENTERPRISE JAVABEANS Approfondimento per il corso Sistemi Distribuiti A.A. 2002/2003 Marchiori Ilaria 780070 Università Ca Foscari Venezia
CENNI SULLA PROGRAMMAZIONE A COMPONENTI 3 Introduzione 3 Che cos e una componente? 3 Programmazione Java a componenti : JavaBeans 3 ENTERPRISE JAVABEANS 4 ARCHITETTURA EJB 5 EJB CONTAINER 5 ENTERPRISE BEANS (COMPONENTI SERVER DISTRIBUITI) 7 Tipologie di Enterprise Beans 8 Entity Bean 8 Session Bean 11 SERVER PER GLI EJB 13 CLIENT PER GLI EJB 13 CONCLUSIONI : UN CONFRONTO CON RMI E CORBA 14
CENNI SULLA PROGRAMMAZIONE A COMPONENTI Introduzione Quando parliamo della programmazione a componenti ci riferiamo alla programmazione orientata agli oggetti che vede quest ultimi come delle componenti. Verso questa tendenza si muovono le tecnologie CORBA, DCOM, JAVA BEAN, in cui le componenti che si creano vengono poi aggregate fino a fornire il prodotto che si vuole realizzare. Ovviamente è indispensabile uno strumento di aggregazione che ci dia la sicurezza che le componenti create si riescano a "legare bene" tra loro. Che cos e una componente? Una componente è un unità di distribuzione. Quando una componente viene distribuita in commercio viene venduta per intero, non a pezzi. Se venisse prodotta da diversi fornitori (ovvero ognuno realizza una parte della componente), i problemi di interoperabilità tra le singole parti sarebbero frequentissimi. Una componente è un unità di composizione, visto che deve essere composta con altre che formano il progetto. Una componente non è un oggetto. Un oggetto è un unità di istanziazione: unità perchè dev essere un tutt uno, un qualcosa di atomico, mentre di istanziazione perche è stato istanziato (un oggetto ha un'unica identità che viene creata al momento dell istanziazione). Una componente è un unita di composizione e di sostituzione. Deve essere considerato come una scatola nera, un qualcosa dentro il quale non si entra. Con essa possiamo interagire staticamente tramite un interfaccia. Programmazione Java a componenti : JavaBeans JavaBeans e' un modello di programmazione a componenti per il linguaggio Java. L obiettivo e' quello di ottenere componenti software riusabili ed indipendenti dalla piattaforma. Inoltre tali componenti (beans) possono essere manipolati dai moderni tool di sviluppo visuali e composti insieme per produrre applicazioni. Ogni classe Java che aderisce a precise convenzioni sulla gestione di proprieta' ed eventi puo' essere considerata un bean.
ENTERPRISE JAVABEANS Basati sulla specifica EJB Sun Microsystems, gli Enterprise JavaBeans definiscono un architettura per lo sviluppo di componenti software che consentono di costruire applicazioni ad oggetti distribuite, utilizzando Java. Esse introducono un insieme di convenzioni, di classi e di interfacce (EJB API) che costituiscono una piattaforma di sviluppo comune per i vari produttori di software, allo scopo di garantire due aspetti fondamentali quali la portabilità e l interoperabilità. Quindi da un punto di vista architetturale EJB non è che un altro modo di vedere e di implementare il modello della computazione distribuita, in cui gli oggetti distribuiti possono essere eseguiti in remoto e su più macchine indipendenti fra loro. Prima della comparsa di EJB, la soluzione più semplice per realizzare architetture distribuite full Java era rappresentata dalla Remote Method Invocation (RMI); parallelamente troviamo anche CORBA come complesso e potente sistema di gestione di oggetti remoti e distribuiti. La novità introdotta rispetto a RMI e CORBA, dove i cosiddetti distribuited object services devono essere implementati a mano o forniti per mezzo di software di terze parti, risiede nel fatto che nel modello degli EJB tutto quello che riguarda la gestione dei servizi è disponibile e utilizzabile in maniera del tutto automatica e trasparente agli occhi del client. Quando si parla di servizi ci si riferisce a tutte quelle funzionalità volte alla implementazione dei seguenti aspetti: Transazioni: ovvero un insieme di operazioni che devono essere svolte in maniere atomica. Come poi vedremo i container EJB offrono un sistema automatico per la gestione delle transazioni. Sicurezza: uno degli aspetti più importanti nell ambito dei sistemi distribuiti; nel modello EJB viene fornito il supporto offerto dal modello della security della piattaforma Java 2. Scalabilità: la modalità con cui EJB opera permette la massima flessibilità e scalabilità in funzione del traffico dati e del numero di clienti (ad esempio quali, quanti e come i beans vengano forniti ai vari client è un meccanismo gestito automaticamente dal server). EJB utilizza le funzionalità e la filosofia di base di RMI per realizzare strutture distribuite, estendendone come visto i servizi in maniera trasparente.
ARCHITETTURA EJB L architettura EJB è basata essenzialmente su tre componenti: i server, i container ed i client. Il server si occupa di fornire ai contenitori una serie di servizi di base per i vari componenti installati. Il contenitore offre una serie di funzionalità legate al life-cycle dei vari componenti, si occupa della gestione delle transazioni, e del security-management. Il client infine rappresenta l utilizzatore finale del componente. Vediamo più in dettaglio tale architettura, cominciando dall analisi del container. EJB CONTAINER Il container è l ambiente in cui operano gli Enterprise beans. Offre una serie di funzionalità legate ad ogni aspetto della vita di un bean: l accesso remoto al bean la sicurezza le transazioni la persistenza la concorrenza l accesso alle risorse. Il container isola il bean dall accesso diretto da parte dei client. Grazie all intercettazione di tutte le richieste (da parte dei vari client) dirette al bean è in grado di garantire la sicurezza e la persistenza. Inoltre è in grado di gestire le transazioni che si instaurano fra chiamate successive, in relazione a contenitori differenti e a server in esecuzione su macchine diverse. Di conseguenza lo sviluppatore di un componente può quindi concentrarsi sui dettagli implementativi della business logic, tralasciando gli altri aspetti legati alla gestione che sono a carico del container. L unica cosa che deve fare chi sviluppa un componente è implementare una serie di interfacce standard. Il container inoltre può gestire le risorse in modo del tutto trasparente ed invisibile al client. Ad esempio può organizzare le risorse in pool condividere un bean tra più client togliere un bean non usato dalla memoria riservandosi la possibilità di reinstanziarlo al momento del successivo utilizzo.
Dipendenza del bean dal container Il bean dipende completamente dal container; si rivolge ad esso quando deve accedere ad una connessione JDBC, accedere ad un altro enterprise bean, accedere all identita' del cliente, ottenere un riferimento a se stesso, accedere a proprieta' o risorse varie. Sono tre i meccanismi che un bean ha a disposizione per interagire con il proprio container: 1. callback methods: questi metodi sono definiti nell interfaccia EnterpriseBean, e vengono chiamati automaticamente dal container in corrispondenza di particolari eventi della vita di un bean. Ad esempio quando il bean sta per essere attivato o quando il suo stato sta per essere salvato in un database o sta per essere rimosso dalla memoria. I callback methods danno la possibilità al bean di compiere qualche operazione di manutenzione o di pulizia immediatamente prima o dopo determinati eventi. 2. l interfaccia EJBContext: è un riferimento direttamente al container, mediante il quale un bean può chiedere informazioni riguardo all ambiente in cui sta operando, come l identità di un cliente, lo stato di una transazione, un riferimento remoto a se stesso. 3. la Java Naming and Directory Interface (JNDI): consente di accedere a naming systems quali LDAP, NetWare, ecc. Un bean può utilizzare JNDI per accedere a risorse quali connessioni JDBC, altri enterprise bean, proprietà specifiche del bean. Obbiettivi dell interazione bean-container L interazione tra il bean e il container si basa pertanto su una serie di regole volte a garantire due obbiettivi fondamentali: portabilità del bean: un bean sviluppato per un container può essere trasportato su un altro che offra migliori prestazioni, migliori caratteristiche o che costi meno. semplicità di sviluppo del bean: come si e precedentemente detto, il container si occupate degli aspetti di gestione più complicati, lasciando allo sviluppatore il compito di concentrarsi solo sulle business rules. In questo modo se da un alto i beans sono sviluppati più velocemente, dall atro non sono richieste allo sviluppatore competenze specifiche di programmazione distribuita (gestione delle transazione, della concorrenza, etc).
ENTERPRISE BEANS (componenti server distribuiti) Gli Enterprise Java Beans sono componenti server distribuiti. Sono costituiti da due interfacce pubbliche la cui implementazione viene effettuata automaticamente dal container al momento del deploy del bean stesso. Il client utilizza le interfacce pubbliche per creare, manipolare e rimuovere il bean dal server EJB. Le due interfacce esportate dal bean verso i client rappresentano la visione che un client ha del bean stesso, sebbene il client non agisca mai direttamente sulla componente, ma tutto passa sempre attraverso l ambiente. Esse sono: la home interface che fornisce i metodi per creare, distruggere o trovare un componente. la remote interface che definisce i business methods (che possono rappresentare delle azioni o task) Un client utilizza la home interface per ottenere un riferimento alla remote interface di un bean. La remote interface può contenere sia metodi per accedere o modificare i campi di un bean sia per eseguire un qualche compito. Implementando queste due interfacce ed i loro relativi metodi, il container è in grado di intercettare le chiamate provenienti dal client, ed allo stesso tempo gli fornisce una visione semplificata del componente stesso. Va notato che il client non ha la percezione di questa interazione da parte del container. In questo modo si garantisce la flessibilità, la scalabilità oltre ad una non indifferenze semplificazione del lavoro da svolgere.
TIPOLOGIE DI ENTERPRISE BEANS Due sono i tipi di Enterprise Beans: gli entity bean e i session beans. I primi rappresentano dati specifici o collezioni di dati. In genere forniscono metodi per l interazione con i dati che essi stessi rappresentano. Questo tipo di componenti sono persistenti, dato che restano in vita per tutto il tempo che sono memorizzati all interno del database. I secondi invece rappresentano un collegamento con il client e soprattutto l interazione con esso. In genere i bean di questo tipo implementano una sequenza di operazioni all interno di una transazione. L implementazione di un bean e' una classe chiamata bean class. Essa incapsula i dati e fornisce i metodi per accedervi. ENTITY BEAN Un entity bean rappresenta dati persistenti, ovvero memorizzati all interno di un database. L accesso (e quindi l utilizzo) da parte del client a tali dati avviene attraverso la remote interface del bean. Inoltre un entity bean implementa l interfaccia javax.ejb.entitybean. Vengono sviluppati metodi per la ricerca del componente da parte del client: quello più importate è il findbyprimarykey(), il quale necessita al suo fianco della creazione di una chiave primaria (classe PrimaryKey) per consentire l identificazione unica del bean. Per creare un Entity Bean, si può operare in due modi: il client invoca i metodi di creazione della home interface in alternativa si effettua una qualche operazione che aggiunga nel database dati che rappresentino il bean. Per avere un riferimento di un componente già esistente invece, diversi sono i modi con cui il client può operare: può ricevere il bean come parametro di una invocazione di metodi remoti effettuare una ricerca presso il server per mezzo dei metodi di ricerca ottenere dinamicamente un riferimento dal container il quale provvede a fornire il bean più indicato. A seconda di chi si occupa della persistenza, gli entità beans si distinguono in: Container-Managed Persistence (CMP) Bean-Managed Persistence (BMP)
CMP Entity Beans Nel caso di entity beans di tipo CMP (Container-Managed Persistence) e' il container a occuparsi della persistenza del bean. Lo sviluppatore del bean non deve scrivere una riga di codice di accesso al database. Il supporto alla persistenza è fornito dal server e varia da produttore a produttore, a seconda degli strumenti più o meno sofisticati utilizzati per mappare i campi del bean all interno del database. Metodi di CMP Per ogni create() nella home interface corrispondono una ejbcreate() ed una ejbpostcreate() con gli stessi parametri. Esse vengono chiamate automaticamente dal container rispettivamente subito prima e subito dopo che un nuovo bean e' stato creato ed un nuovo record e' stato inserito nel database. - ejbcreate() viene utilizzata per inizializzare i campi del bean prima che questi vengano scritti nel nuovo record. Bisogna notare che un EJB tecnicamente non esiste finché il suo stato non è stato scritto nel database. - ejbpostcreate() viene eseguita dopo la creazione, ma prima che il bean inizi a servire i client. I find methods, per un bean CMP, vengono gestiti automaticamente dal container: essi sono utilizzati per localizzare determinati bean già esistenti, e si suddividono, a seconda del numero di entità che possono restituire in risposta alla loro invocazione, in - single-entity find methods : restituiscono un solo entity bean oppure una ObjectNotFoundException - multi-entity find method: restituiscono una collezione, eventualmente vuota, di entity bean. Per un entità bean è obbligatorio definire un single-entity find methods chiamato findbyprimarykey() che prende in ingresso la chiave primaria del bean e serve per l identificazione univoca del bean stesso. I callback methods vengono chiamati automaticamente dal container in corrispondenza di precisi eventi nella vita del bean. Essi sono: - setentitycontext() viene invocata all inizio della vita del bean e può essere utilizzata per ottenere un riferimento al container, utile per accedere ad informazioni sulla sicurezza, sulle transazioni o sul bean stesso. - unsetentitycontext() viene chiamata alla fine della vita del bean quando il riferimento al container viene invalidato, e può essere utilizzata per le ultime operazioni di pulizia. - ejbload() viene chiamata subito dopo che lo stato del bean è stato caricato dal database. - ejbstore() viene chiamata subito prima che lo stato del bean venga salvato nel database. Questi due metodi possono essere usati, per esempio, per decomprimere e comprimere i dati letti e scritti nel database. - ejbactivate() e ejbpassivate() sono chiamate rispettivamente subito dopo che un bean è stato attivato e subito prima che questo sia passivato, cioè venga disassociato dal suo riferimento per essere rimosso dalla memoria o riutilizzato per un altro client.
BMP Entity Beans Nel caso di entity beans di tipo BMP (Bean-Managed Persistence) il bean si occupa personalmente della persistenza del proprio stato, seppur sempre assistito dal container, che si occupa delle necessarie transazioni. Vengono usati in genere quando si hanno esigenze particolari o quando si vuole avere un maggior controllo sui dati memorizzati nel database. Metodi di BMP Un bean BMP differisce da un bean CMP principalmente per il significato assunto da ejbload(), ejbstore(). - ejbload() conterrà il codice per caricare lo stato del bean dal database, tipicamente utilizzerà una istruzione select - ejbstore() conterrà una update - ejbcreate() conterrà una insert - ejbremove() conterrà una delete Per quanto riguarda l implementazione delle ejbfind(), le single-entity devono ritornare una singola chiave primaria, mentre le multi-entity devono ritornare collezioni di chiavi primarie. Il container poi tradurrà queste chiavi in riferimenti ai bean veri e propri e li restituirà al client sotto forma di un singolo riferimento o di una collezione di riferimenti.
SESSION BEAN Un session bean rappresenta un insieme di procedure o task, che costituiscono dei servizi a favore dei client. Queste operazioni a favore dei client possono essere eseguite direttamente dal session bean oppure utilizzando altri bean. Essi non rappresentano dati o entità di cui si voglia mantenere memorizzato lo stato in un qualche database. Non godono, quindi, di persistenza. Un session bean implementa l interfaccia javax.ejb.sessionbean. Essi di dividono in due categorie: Stateless session bean: eseguono i loro compiti basandosi solo sulle informazioni passate come parametri ai loro metodi: non mantengono delle informazioni tra una invocazione e l altra. Stateful session bean: possiedono uno stato interno sebbene non persistente. Come si diceva i session beans non sono stati progettati per essere persistenti, pertanto i dati che essi memorizzano sono intesi relativamente ad una particolare sessione. E per questo motivo che un session beans non può sopravvivere a crash di sistema o semplici restart del server; infatti il riferimento creato all interno del container per accedere a quel particolare bean, viene perso nel momento in cui il client muore o la sessione finisce. Nel caso in cui il client necessiti di riutilizzare un bean rimosso, deve utilizzare le informazioni in suo possesso (sul lato client) per poter ricreare il componente sul server. Stateless Session Beans Questo tipo di session bean non mantiene un proprio stato interno, e di conseguenza ogni invocazione di un suo metodo e' indipendente dalle precedenti. I metodi del bean si comportano come tradizionali procedure. Gli stateless session beans sono in genere più performanti degli stateful, e, poiché tutte le istanze sono equivalenti tra loro, possono essere condivisi tra più client. Metodi degli Stateless La home interface di uno stateless session bean definisce solamente un metodo create() senza argomenti, dato che non ha stato da inizializzare e non può avere metodi find() perché non è persistente. Principali metodi: - ejbcreate() può essere utilizzata per inizializzare variabili e acquisire risorse (ad esempio una connessione) - ejbremove() consente di disallocare le risorse occupate prima che il bean venga distrutto Le chiamate a questi due metodi sono governate dalla politica di gestione delle risorse del container: dopo una remove() da parte di un client, il container potrebbe decidere di non distruggere il bean ma di metterlo a disposizione di altri client. - setsessioncontext() consente di ottenere un SessionContext, che ha la stessa funzione dell EntityContext.
- ejbactivate() e ejbpassivate() hanno una implementazione sempre vuota negli stateless session beans. Stateful Session Beans Gli stateful session beans mantengono uno stato interno tra due invocazioni del client. Ogni bean di questo tipo è associato ad uno ed un solo client: quindi essi non vengono condivisi tra piu' client, anzi per tutta la sua esistenza un bean appartiene al client che l ha creato. Questo rende possibile, ad esempio, compiere una serie di operazioni a favore di un client mantenendo in memoria le informazioni che non cambiano tra un invocazione e l altra, oppure un risultato parziale. Tipicamente la gestione dello stato viene effettuata automaticamente dalla coppia server-container e in questo modo si riduce il lavoro che si deve svolgere in fase di sviluppo sia del client che del bean stesso. Quando uno stateful session bean non viene utilizzato per un certo tempo, il container puo' decidere di rimuoverlo dalla memoria (passivation) e di salvare il suo stato in una memoria secondaria, da dove puo' essere recuperato al momento della successiva riattivazione. Metodi degli stateful I callback methods ejbactivate() e ejbpassivate() vengono chiamati immediatamente dopo la riattivazione di un bean ed immediatamente prima della sua disattivazione, rispettivamente. ejbpassivate(), assieme a ejbremove(), consente al bean di compiere un po di pulizia e di liberare le risorse eventualmente occupate.
SERVER per gli EJB Il server per i bean è l elemento fondamentale di tutta la piattaforma EJB: questo componente infatti svolge buona parte del lavoro necessario sia per rendere un componente utilizzabile dai vari client remoti, sia per supportare i servizi più importanti (transazioni, mantenimento dello stato, sessioni, sicurezza) associati ai vari beans. Il processo di creazione di un bean e di deploy nel server passa per la definizione delle già citate interfacce (Home interface e Remote interface) in modo che il server possa gestire il componente. E la bean implementation class che implementa l interfaccia remota e che fornisce di fatto il corpo del bean, defininendone anche il comportamento. La cosa estremamente interessante è che non è necessario fornire l implementazione delle due interfacce, compito svolto automaticamente dal server. Per poter completare con successo la fase di deploy del bean nel server è necessario inoltre fornire i cosiddetti deployment descriptors, operazione effettuabile al momento del deploy del componente utilizzando il tool fornito dal server. Il deployment descriptor contiene le seguenti informazioni: il tipo di bean, i nomi delle classi (home, remote, bean), come gestire le transazioni e la sicurezza sui singoli metodi, il tipo di persistenza ed eventualmente quali campi salvare. CLIENT per gli EJB I client di un Enterprise JavaBean possono essere applicazioni, servlet, applet o altri EJB. Sono tre le operazioni che un client deve effettuare: 1. utilizzare il nome del bean per localizzare la home interface 2. utilizzare la home interface del bean per ottenere un riferimento ad una sua istanza. 3. utilizzare direttamente il bean invocandone i metodi che mette a disposizione I client quindi interagiscono con il bean unicamente attraverso i metodi definiti nella remote interface. La localizzazione avviene individuando da qualche parte la home interface, compito che viene svolto per mezzo della classe java.naming.context. DISTRIBUZIONE DEGLI EJB Gli Enterprise JavaBeans vengono distribuiti in un archivio JAR, contenente, tra l altro, un deployment descriptor in XML.
CONCLUSIONI : UN CONFRONTO CON RMI E CORBA Come RMI e CORBA anche EJB si inserisce nello scenario della computazione distribuita. RMI rappresenta il motore che permette tutto il funzionamento della tecnologia EJB. La scelta fra le due soluzioni (solo RMI o EJB), deve essere fatta in funzione del tipo di applicazione che si deve realizzare. Nel caso si vogliano realizzare sistemi semplici, dipendenti dal caso particolare, forse il più semplice utilizzo di RMI può essere sufficiente; nel caso di situazioni complesse dove è necessaria la massima flessibilità e scalabilità (come nell ambito dell e-commerce o JSP) allora la soluzione di EJB può essere preferibile. CORBA invece è più potente e più complesso sia di RMI che di EJB ed offre prestazioni migliori e la possibilità di interagire con sistemi e tecnologie differenti. Ma non offre il supporto per i servizi distribuiti, vero punto di forza di EJB. In definitiva è utile utilizzare EJB in quei casi in cui si debbano realizzare applicazioni multistrato distribuite, basate su oggetti mobili: e Java è la soluzione (l unica) in grado di fornire massima flessibilità e potenza implementativa. BIBLIOGRAFIA Per la relazione si è fatto riferimento al contenuto di articoli pubblicati nei seguenti siti: http://www.mokabyte.com/ http://www.javaportal.it/