Enterprise Java Beans e Web Services

Transcript

1 Università degli Studi di Salerno Relazione: Enterprise Java Beans e Web Services Prof. Auletta Vincenzo

2 Partecipanti Antonio Autorino 156/ Nicola Vitiello 156/ Pasquale Paola 156/ Indice degli argomenti 1. Introduzione 3 2. J2EE Sistemi Distribuiti ad oggetti Oggetti distribuiti Oggetti distribuiti con middleware esplicito Oggetti distribuiti con middleware implicito 2.2 J2EE : overview J2EE: il container 8 3. Enterprise Java Bean La classificazione Architettura di un applicazione distribuita Session Bean Implementazione di un Session Bean Gli Entity Bean JMS 23 MDB EJB e Web Services Esportare gli EJB tramite web services Soluzioni proprietarie degli EJB container Utilizzare un motore SOAP esterno all EJB container 6.2 Esempio: HelloBean Esempio: Skatestown Entity CMP: Product Session Stateless: SkatesProducts 34 Pagina 2 di 38

3 1. Introduzione Questa relazione presenta due delle più importanti tecnologie del settore dei sistemi distribuiti ad oggetti: Enterprise Java Beans e i Web Services. Dopo una breve panoramica sulle tecnologie utilizzate per la realizzazione dei sistemi distribuiti e sulla piattaforma J2EE progettata dalla SUN per la realizzazione di applicazioni distribuite in JAVA, il seguente documento si concentra sulla descrizione degli Enterprise Java Beans, la loro classificazione, il loro ciclo di vita, la loro implementazione e il loro deployment. Nell ultima sezione della relazione viene presentata la possibilità di utilizzare gli EJB come dei Web Services, vengono analizzate tre possibili soluzioni per implementare tale scenario e sarà fornito un esempio dettagliato sull utilizzo degli EJB, in cui AXIS funge da processore SOAP lato Client e Server per la comunicazione tra le due applicazioni. Grazie alla combinazione di AXIS e J2EE è possibile ottenere l implementazione di un sistema distribuito che può basare : la robustezza, la sicurezza, l affidabilità, la gestione delle transazioni e la persistenza delle informazioni, la gestione delle risorse in generale, baandosi esclusivamnte sui servizi offerti dalla piattaforma J2EE. l interoperabilità tra l applicazione lato server e una specifica applicazione lato client (realizzata in qualsiasi linguaggio di programmazione) grazie all utilizzo dei Web Services. Bisogna infatti sottolineare che J2EE è un infrastruttura affidabile, sicura e di alta qualità, utilizzata per la realizzazione di complesse applicazioni distribuite di business. L unico limite di questo ambiente era legato al fatto che l implementazione di un meccanismo di comunicazione tra un Client C/C++/C# e un applicazione Server-Side su J2EE era molto complesso da realizzare. Grazie alla nascita dei Web Services e del protocollo SOAP è possibile interfacciare queste applicazioni di business Server-Side con qualsiasi Client. Allo stesso tempo è possibile implementare Web Services tramite EJB senza utilizzare una piattaforma troppo limitata nei servizi di middleware offerti (come il connubio Application Server Tomcat e Axis) ma utilizzando una piattaforma più robusta e completa, quale J2EE. Rimane il fatto che la modalità di implementazione dei Web Services classica, che è stata illustrata durante il corso, può essere comunque utilizzata, specialmente quando lo scenario prevede semplici funzionalità e requisiti non funzionali non troppo pressanti da rispettare. Pagina 3 di 38

4 2. J2EE J2EE è una piattaforma utilizzata per realizzare applicazioni distribuite in Java. Standardizza modelli di programmazione e modelli di deployment allo scopo di fornire gli strumenti necessari ad uno sviluppatore per implementare soluzioni veloci alla realizzazione di sistemi distribuiti ad oggetti. Per comprendere tutte le caratteristiche di J2EE dobbiamo descrivere inizialmente cos è un sistema distribuito e cosa intendiamo per sistemi distribuiti ad oggetti. 2.1 Sistemi Distribuiti ad oggetti I sistemi distribuiti offrono una maggiore accessibilità ai servizi offerti ; infatti parte del sistema può essere ubicata in locazioni diverse e lo stesso accesso al sistema può avvenire da locazioni diverse. Tra le piattaforme software più utilizzate per la realizzazione di sistemi distribuiti possiamo citare Java RMI, CORBA, DCOM, etc; queste offrono la possibilità di avere oggetti che vengono eseguiti su una macchina ed utilizzati da altre applicazioni (oggetti) su un altra macchina. Il modello che seguiamo per la realizzazione di sistemi distribuiti è descritto nella figura 2.1 Figura 2.1 Il modello presentato prende il nome di Modello 3 Tier e come è possibile osservare,abbiamo un sistema distribuito strutturato in tre livelli: Livello 1 Presentazione : è caratterizzato da i nodi del sistema in cui vi è l accesso degli utenti e in cui girano le applicazioni Client. Pagina 4 di 38

5 Livello 2 Logica di business : è caratterizzato dalla presenza dell applicazione software lato server che implementa l intera logica di business : operazioni,servizi,calcoli etc Livello 3 Logica dei Dati: è il tipico Data Layer di un applicazione ; può risiedere sulla stessa macchina dell applicazione di business o su un altro insieme di nodi remoti. In questa relazione facciamo riferimento principalmente al livello 2/3 quando parleremo di Entity Bean e al livello 2 quando tratteremo i Session Bean Il passaggio da sistemi distribuiti a sistemi distribuiti ad oggetti consiste nella sostituzione delle applicazioni tipiche della logica di business,scritte per esempio in Cobol o C,con oggetti distribuiti. L incapsulazione della logica di business in oggetti permette di ottenere software FER(Flessibile Estendibile e Riutilizzabile), che è uno degli obiettivi del paradigma di programmazione object oriented. Definizione: un modello di componenti server-side definisce una architettura per lo sviluppo di oggetti di business distribuiti. Quindi cosa sono le componenti server-side? In poche parole le componenti server-side sono gli oggetti distribuiti finora citati. Sono usate negli application server (per esempio TomCat o l application Server di J2EE),che gestiscono le componenti a run-time e permettono il loro assemblaggio. Sono pezzi indipendenti di software e possono essere acquistate, vendute e composte come tali. Un sistema di business basato su componenti server-side è: o fluido perché è costituito da oggetti o accessibile perché le componenti possono essere distribuite Oggetti distribuiti Il modello più semplice che viene utilizzato per la descrizione e l implementazione dei sistemi distribuiti è il modello ad Oggetti Distribuiti. Tra le tecnologie che implementano tal modello possiamo citare : Sun Java RMI, CORBA, MS DCOM. Pagina 5 di 38

6 Figura 2.2 La figura 2.2 rappresenta graficamente il modello : lo Stub o rappresenta il proxy del Server lato Client,cioè offre in locale all applicazione Client gli stessi metodi del Server. o Affinché avvenga ciò, lo Stub implementa un interfaccia remota che l applicazione Client deve assolutamente conoscere per invocare i metodi sullo Stub o Nasconde i dettagli della comunicazione sulla rete all applicazione Client. Lo Skeleton o Riceve i dati dalla rete inviati dallo stub (il nome della funzionalità da invocare e i parametri necessari) o Invoca il metodo sull oggetto remoto che implementa anch esso l interfaccia remota. o Restituisce il risultato allo Stub. Lo stub e lo skeleton rappresentano il middleware di tale sistema distribuito Oggetti distribuiti con middleware esplicito Il modello ad Oggetti Distribuiti con Middleware esplicito è leggermente diverso dal precedente modello perché l oggetto remoto/server accede tramite delle specifiche API,offerte dallo strato software middleware, a servizi utili, relativi per esempio alla gestione del database o alla gestione della sicurezza etc. Tra le tecnologie che implementano tale modello possiamo citare CORBA. La figura 2.3 rappresenta graficamente il modello. Pagina 6 di 38

7 Figura Oggetti distribuiti con middleware implicito Il modello ad Oggetti Distribuiti con Middleware implicito è sostanzialmente diverso dai due precedenti modelli perché nella interazione Skeleton Oggetto distribuito si interpone il Request Interceptor ; quest oggetto è parte integrante del middleware ed è configurato in fase di deployment della componente server-side affinché fornisca automaticamente i servizi necessari (per esempio la gestione del database o la gestione della sicurezza etc). Tra le tecnologie che implementano tal modello possiamo citare EJB, CORBA Component Model,.NET La figura 2.4 rappresenta graficamente il modello. Figura 2.4 Pagina 7 di 38

8 2.2 J2EE : overview Adesso possiamo descrivere le caratteristiche della piattaforma J2EE in modo esaustivo, dopo aver trattato degli argomenti chiave relativi ai sistemi distribuiti a d oggetti. J2EE sta a significare Java 2 Enterprise Edition e come abbiamo detto, è una piattaforma utilizzata per realizzare applicazioni distribuite in Java. I modelli di applicazioni distribuiti più utilizzati e supportati dall ambiente J2EE sono: Applicazioni browser-based,in cui il lato server è implementato con JSP e Servlets Applicazioni basate sull utilizzo di RMI-IIOP per la comunicazione tra Client e EJB lato Server Applicazioni basate sullo scambio di messaggi utilizzando JMS Applicazioni service-based che tramite SOAP/HTTP offrono servizi alle applicazioni client J2EE fornisce un ampia varietà di servizi : Tool per la gestione delle performance e del workload Tool per la gestione della sicurezza Tool per la gestione delle risorse Tool per la gestione delle transazioni Tool per la configurazione e il deployment di una applicazione J2EE: il container Il container è un entità logica all interno di un server J2EE, essenzialmente gestiscono tutte le componenti che sono state sottoposte ad un processo di deployment su un server J2EE. Il container è spesso definito come un entità astratta perché né il client né le componenti serverside invocano le sue funzionalità. Possiamo quindi affermare che fornisce in maniera trasparente dei servizi alle componenti caricate e attive sul server: Gestione delle transazioni Gestione della sicurezza Gestione della persistenza dei dati Astrazione tra componenti e risorse tramite il meccanismo delle resource reference Etc.. È importante citare e spiegare il meccanismo delle resource reference attraverso un esempio: nel caso in cui una componente usa un database il programmatore può definire una resource reference per il linking al DB. Successivamente il responsabile del deployment definisce il mapping tra resourse reference e DB fisico. Qual è il vantaggio di questo procedimento? Pagina 8 di 38

9 Il codice non è legato (non è hard-coded ) ad uno specifico database ma in fasi successive è possibile modificare la locazione o altre proprietà del database senza alterare il codice dell applicazione server-side. Un altra importante caratteristiche sta nel fatto che gestisce il ciclo di vita delle componenti caricate e attive sul server J2EE. Nel caso degli EJB, il container gestisce il loro ciclo di vita tramite un meccanismo di pooling. Questo meccanismo varia per ogni tipologia di bean ma possiamo generalizzarlo attraverso questi principi di base: Crea un pool di istanze dello stesso bean Una volta che il numero di bean eccede un limite fissato (del container) o allora il container può decidere di farne lo swap portando lo stato di un bean che era in memoria principale su memoria secondaria. o Questo processo prende il nome di Passivation All atto della invocazione su un bean passivato o questo viene riportato all interno del pool in memoria principale o eventualmente un altra istanza può essere passivata o questo processo prende il nome di Activation Crea o distrugge nuove istanze in base alle esigenze Pagina 9 di 38

10 3. Enterprise Java Bean Gli Enterprise Java Beans sono le componenti più importanti della piattaforma J2EE; rappresentano una vera e propria tecnologia per l implementazione della logica di business di un sistema distribuito ad oggetti: La SUN definisce così gli EJB: La architettura EJB è una architettura a componenti per lo sviluppo e la realizzazioni di applicazioni business distribuite basate su componenti. Le applicazioni scritte con EJB sono scalabili, transazionali e sicure. Queste applicazioni possono essere scritte una volta e poi portate su ogni piattaforma server che supporti lo standard EJB Possiamo dare una definizione molto più ridotta ma comunque esplicativa degli EJB: EJB è un modello di programmazione a componenti utilizzato per implementare la logica di business delle nostre applicazioni server side 3.1 La classificazione Possiamo classificare gli EJB in tre categorie : o Session bean o Entity bean o Message-driven bean I Session Bean rappresentano logicamente una sessione di operazioni di cui un applicazione client o un altro bean può aver bisogno; praticamente sono delle classi che implementano la logica di business in un applicazione server-side. Se pensiamo alla descrizione di uno scenario da implementare a livello software i session bean con i loro metodi implementano le azioni, rappresentate dai verbi della discussione. Gli Enity Bean rappresentano logicamente i dati di business tipici di un applicazione distribuita; praticamente sono delle classi che fisicamente sono mappate in tabelle di un database relazionale e le loro istanza sono le tuple delle corrispondenti tabelle. Se pensiamo alla descrizione di uno scenario da implementare a livello software gli entity bean con i loro metodi implementano i soggetti e i sostantivi dell analisi logica del periodo. I Message Driver Bean sono molto simili ai Session Bean con la differenza che non hanno metodi che vengono invocati da remoto da un applicazione client, ma gestiscono la comunicazione con altri sistemi o all interno dello stesso container tramite lo scambio di messaggi asincroni e l utilizzo del protocollo JMS. Bisogna fare un ulteriore distinzione all interno degli EJB che riguarda gli EJB locali e quelli Pagina 10 di 38

11 remoti. Gli EJB locali possono essere chiamati (stiamo parlando dei loro metodi logicamente) all interno dello stesso container da altri bean mentre quelli remoti possono essere invocati da altre applicazioni tramite la rete e l utilizzo di protocolli distribuiti come RMI-IIOP; quest ultimo lega il modello ad oggetti di JAVA(RMI) e il protocollo di trasporto di CORBA (IIOP). Un EJB può essere sia accessibile in locale che da remoto, sostanzialmente devono essere implementate interfaccie locali e remote (dopo vedremo un esempio). La distinzione tra EJB locali e EJB remoti ha senso perché è possibile garantire la comunicazione tra oggetti all interno dello stesso container senza ricorrere a protocolli di networking, garantendo prestazioni più efficienti Architettura di un applicazione distribuita Un applicazione distribuita può essere tipicamente composta da: La componente di dialogo con un database (local entity bean) La componente di supporto alla logica di business (stateless local session bean) La componente che implementa la logica di business distribuita (stateless o stefeful remote session bean) La componente che gestisce l invio e la ricezione di messaggi con altri sistemi( messagedriven beans) All interno dello schema sono stati citati l attributo stateless e l attributo stateful che saranno spiegati meglio, facendo riferimento ad ogni bean. 3.2 Session Bean Prima abbiamo definito i Session Bean in questo modo: I Session Bean rappresentano logicamente una sessione di operazioni di cui un applicazione client o un altro bean può aver bisogno; praticamente sono delle classi che implementano la logica di business in un applicazione server-side. Se pensiamo alla descrizione di uno scenario da implementare a livello software i session bean con i loro metodi implementano le azioni, rappresentate dai verbi della discussione. Un session bean è una componente server-side dalla vita breve, poiché esprime esclusivamente il comportamento di una serie di interazioni con l utente (sessione). Tipicamente i session bean sono in memoria, soggetti a tutte le caratteristiche della memoria principale: volatilità e non persistenza; il container può gestire il loro accesso attraverso tecniche di caching. Pagina 11 di 38

12 Sono di seguito presentate due tipologie di Session Bean : Stateful Session Bean Stateless Session Bean In effetti tutti i bean mantengono una conversazione con uno o più client e a seconda del tipo di conversazione esistono le tue tipologie di session bean prima citate. Se un applicazione Client accede, per la richiesta di un servizio, ad uno Stateful Session Bean lo stato della conversazione viene mantenuto. La conversazione consiste nell invocazione di una serie di metodi sul bean e lo stato invece è rappresentato da una o più variabili d istanza del Session Bean. Se un applicazione Client accede,per la richiesta di un servizio,ad uno Stateless Session Bean lo stato della conversazione non viene mantenuto. La conversazione consiste nell invocazione di un singolo metodo,dove vengono passati tutti i parametri necessari alla richiesta del servizio. Per quanto riguarda uno Stateless Session Bean,il container non assume responsabilità circa la vita del bean: può decidere di tenerlo in vita oppure di ucciderlo,allo scopo di gestire un pool di bean (per ottimizzare le prestazioni).il bean non ha uno stato da salvare ma può comunque avere una serie di una o più variabili d istanza,necessarie alla computazione. Per quanto riguarda uno Stateful Session Bean, la gestione del suo ciclo di vita non è così semplice come per il caso dei Stateless Session Bean,in quanto è necessario memorizzare in qualche maniera lo stato della conversazione con il bean. La soluzione a questo problema sta nella gestione del pool di bean attraverso il meccanismo di activation e passivation prima descritto a proposito del container, cioè: Il container crea un pool di istanze dello stesso bean Una volta che il numero di bean eccede un limite fissato (del container) o allora il container può decidere di farne lo swap portando lo stato di un bean che era in memoria principale su memoria secondaria. o Questo processo prende il nome di Passivation All atto della invocazione su un bean passivato o questo viene riportato all interno del pool in memoria principale o eventualmente un altra istanza può essere passivata o questo processo prende il nome di Activation Crea o uccide nuove istanze in base alle esigenze. Affinché vada in porto il salvataggio dello stato di un Session Bean è necessario che la interface javax.ejb.enterprisebean (vedremo dopo) estenda java.io.serializable; in questo modo ogni bean implementa l interface Serializable. In pratica, ogni variabile del bean viene considerata stato, se: Pagina 12 di 38

13 È un tipo primitivo non marcato come transient È un oggetto (estende Object) Implementazione di un Session Bean L implementazione di un Session Bean prevede la realizzazione delle seguenti componenti: La classe di Bean La interface Remote La interface Home Il deployment descriptor Eventuali interface locali Descriviamo ora cosa intendiamo per ogni componente, il ruolo di ognuna di esse La classe di Bean La classe di Bean specifica la logica di business. Nel momento in cui stiamo implementando la classe principale del bean è essenziale che essa implementi l interface javax.ejb.sessionbean, che risulta a tutti gli effetti un interface marker. Le interface marker che si utilizzano per l implementazione di una classe di Bean sono: javax.ejb.sessionbean (nel caso dei Session Bean) javax.ejb.entitybean (nel caso degli Entity Bean) javax.ejb.messagedrivenbean (nel caso dei MessageDriven Bean) Queste interfacce estendono javax.ejb.enterprisebean, che a sua volta estende java.io.serializable; ciò significa essenzialmente che è possibile serializzare un istanza della classe e quindi trasmetterla su rete o memorizzarla su disco, nel caso in cui è in atto un processo di activation e passivation. Un istanza della classe di Bean non rappresenta un vero proprio oggetto remoto perché il client non invoca mai metodi remoti su di essa L oggetto EJB e l interface remota del bean L oggetto EJB espone al client i metodi del nostro bean. Possiamo osservare la figura 3.1 che descrive in dettaglio il ruolo e le funzionalità dell oggetto EJB. Esso implementa l interface remota del bean; il programmatore devo solo: Implementare l interface remota del bean o In cui si pubblicizziamo tutti metodi che è possibile invocare da un applicazione client E le modalità di utilizzo del metodo (parametri e tipo di ritorno) Pagina 13 di 38

14 o L interface remota deve estendere l interface javax.ejb.ejbobject L oggetto EJB viene generato automaticamente da parte dei tool del container forniti dal produttore,sulla base delle indicazioni fornite dalla interface remote fornita dall implementatore. Alla luce di queste notazione è possibile comprendere i 5 passi descritti nella figura 3.1, azzardando nel dire che l oggetto EJB è il nostro Request Interceptor,citato nelle pagine precedenti. Figura L oggetto Home e l interface di Home Adesso ripetiamo il discorso fatto nel precedente sottoparagrafo, però trattando della Home di un oggetto EJB. Infatti dobbiamo chiederci spontaneamente: ma come fa l applicazione client a ottenere un riferimento remoto ad un oggetto EJB? Rispondiamo dicendo che l applicazione Client contatta precedentemente da remoto un oggetto Home che restituisce un riferimento remoto all oggetto EJB. La figura 3.2 riassume l intero processo di invocazione di un metodo da remoto di un applicazione Client,compreso la comunicazione tra Client e oggetto Home. Pagina 14 di 38

15 Figura 3.2 L oggetto Home deve : creare oggetti EJB,trovare oggetti EJB esistenti oppure rimuovere oggetti EJB. È a tutti gli effetti una factory,responsabile per creazione e distruzione di oggetti EJB. Un altra domanda è lecita : ma come fa l oggetto Home a sapere la inizializzazione dell oggetto EJB? Ciò è possibile tramite l implementazione dell interface Home del nostro Bean;il programmatore devo solo: Implementare l interface remota della Home o In cui si pubblicizziamo tutti metodi che è possibile invocare da un applicazione client per creare un oggetto EJB E le modalità di utilizzo del metodo (parametri e tipo di ritorno) o L interface remota deve estendere l interface javax.ejb.ejbhome,che estende Remote; quindi l oggetto Home può trovarsi anche su una macchina diversa dall oggetto EJB. L oggetto Home viene generato automaticamente da parte dei tool del container forniti dal produttore,sulla base delle indicazioni fornite dalla interface remote fornita dall implementatore Assemblaggio e Deployment L ultima operazione da effettua per completare l implementazione del Session Bean è assemblare le varie componenti prodotte. In realtà bisogna anche realizzare,come vedremo in seguito,il deployment descriptor del Session Bean,che contiene tutte le informazione del bean,dal nome della sua interface remota al nome della interface di Home,al nome dei servizi di middleware di cui ha bisogno etc Infine è necessario citare anche la necessità di implementare le interfacce locali per il Bean e per Pagina 15 di 38

16 la Home, nel caso in cui si realizza un Local Session Bean. Le due interfaccie devono estendere rispettivamente: javax.ejb.ejblocalobject e javax.ejb.ejblocalhome. L operazione di assemblaggio consiste nel creare un EJB-JAR file che contiene: La classe di Bean la interface Remote la interface Home il deployment descriptor eventuali interface locali file specifici per il fornitore del container In passato non veniva fatta alcuna differenza tra la conoscenza di: o Un linguaggio di programmazione o Tecnologie di database o Tecnologie di networking o Amministrazione di sistema. Inoltre per la realizzazione di un applicazione web distribuita, un programmatore doveva conoscere assolutamente anche il linguaggio html. Oggi grazie all utilizzo di una piattaforma come J2EE i ruoli di programmatore WEB,di programmatore della logica di business,di responsabile del deployment o di amministratore del sistema sono ben distinti. Si distinguono due figure chiave per il completamento dell attivazione di un applicazione server-side: L assemblatore Mette insieme le componenti implementate dagli sviluppatori al fine di realizzare un applicazione distribuita. Il responsabile del deployment: Carica l applicazione lato server sulla piattaforma affinché possa rispondere alle richieste effettuate dal lato client Sono entrambi integratori di sistema. Pagina 16 di 38

17 4. Gli Entity Bean Gli entity sono oggetti persistenti che possono essere memorizzati in memoria secondaria, servono a modellare i dati necessari agli obiettivi della applicazione, in pratica, possono sostituire completamente l utilizzo di database; sono offerti dal container al programmatore con due livelli di servizio: a carico del container a carico (parziale) del programmatore Il vecchio stile di programmazione prevede di scrivere un programma che effettua query su un database. Gli oggetti, invece, offrono una gestione semplificata ed efficiente: la possibilità di creare un tipo di oggetto (classe) che contenga non solo dati ma anche i metodi a cui i dati devono essere soggetti (compressione, aggiornamento, etc.); la ereditarietà può essere utilizzata come direste questa tabella deriva da quest altra tabella, in più i servizi di middleware impliciti offrono caratteristiche come: transazioni, accessibilità su rete, sicurezza, caching per prestazioni. La persistenza è ottenuta mediante la memorizzazione su memoria secondaria in modo da ottenere anche altri vantaggi quali il recovery da crash, tecniche di roll-back per le transazioni, compatibilità verso applicazioni legacy. Le tre tecniche tipicamente utilizzate per la persistenza dei dati sono: la serializzazione degli oggetti Java mapping oggetto/relazionale database ad oggetti La serializzazione di Java E un meccanismo per rappresentare in maniera compatta, completa e seriale (flusso di bit) un oggetto Java con tutti i suoi campi ricorsivamente serializzati Utilità: o invio su rete (passaggio parametri su RMI) o persistenza oggetti in un file, database, contesto JNDI etc. Svantaggi: o inefficienza nell usare delle query su oggetti serializzati per poterne selezionare una parte o necessario ricostruire l oggetto Java per poterne accedere i campi Mapping oggetto/relazionale Si usa un DB relazionale standard, si decompone l oggetto in tutte le sue parti che vengono memorizzate separatamente; il salvataggio di un oggetto Java in un DB consiste nell utilizzare uno o più righe di una (o più) tabelle per scrivere i dati dell oggetto. Per poter riottenere Pagina 17 di 38

18 l oggetto, basta creare un oggetto nuovo, e popolarne i campi con i dati presi dal DB. L utilità del mapping permette l uso di query sugli oggetti per esempio, ricercare i conti correnti che sono in rosso (saldo < 0) diventa un semplice statement SQL, ciò comporta facilità di ispezione e controllo della consistenza, un interazione facilitata con sistemi legaci, infatti integrare un DB relazionale con un sistema preesistente è naturale, data la natura di sistemi di gestione di BD di questi sistemi. Database a oggetti I database a oggetti sono un evoluzione dei DB relazionali, permettono di memorizzare (direttamente) oggetti, non viè quindi nessuna necessità di effettuare il mapping: un oggetto viene scritto/letto in un ODB come tale utilizzando le API del database. Le query vengono effettuate mediante l Object Query Language che astrae le query relazionali a livello degli oggetti. I vantaggi dei DB a oggetti sono: le prestazioni o dato che vengono mantenute le relazioni tra oggetti, si può navigare tra oggetti correlati (come un cliente ed il suo conto corrente) senza dover effettuare le costose join relazionali (NB: in contesti semplici, un DB relazionale è più efficiente) Scalabilità Sicurezza Due sono le tipologie di oggetti nelle applicazioni distribuite: Le componenti della logica della applicazione che forniscono i metodi per i compiti comuni; nella descrizione delle componenti rappresentano i verbi = session beans Le componenti con dati persistenti, ovvero oggetti che usano qualche meccanismo di persistenza per rappresentare dati; nella descrizione delle componenti rappresentano i sostantivi = entity beans Due sono le strade possibili per chi vuole scrivere una applicazione con EJB, ovvero: 1. scrivere session bean e poi usare JDBC per conettersi ad un DB (Session+JDBC) 2. usare gli entity bean (Entity) Vantaggi e Svantaggi Controllo della applicazione o Session+JDBC fa mantenere il controllo al programmatore: quando e come si Pagina 18 di 38

19 Efficienza Caching scrive sul DB, come si strutturano i dati nelle tabelle, etc. o se è a carico del container, attenzione alla configurazione del server un solo statement SQL potrebbe essere tradotto in un certo numero di statement. Una analogia con il passaggio di parametri: Session+JDBC = Passaggio parametri per valore; Entity = Passaggio parametri per riferimento o Efficienza in locale: uguali con Session+JDBC e Entity la query restituisce un data set al session bean; o Efficienza in remoto: attenzione alla soluzione Entity: con GUI client / EJB session che lavorano da remoto c è bisogno di un session che faccia il wrapping dei dati per inviarli tutti insieme sul client; o I session bean non possono essere posti in cache, di conseguenza non vi è nessun miglioramento sensibile delle prestazioni; o Se gli entity bean rappresentano dati condivisi allora il caching permette di riutilizzare bean, vi è quindi un miglioramento notevole: basta pensare agli entity bean che rappresentano i 100 libri più venduti di Amazon: verranno tenuti sempre in cache e riutilizzati; o In presenza di dati non condivisi la soluzione Session+JDBC può essere più efficiente. SQL scritto dal programmatore, di solito, è più efficiente di quello generato dal container; OO vs. Procedurale o A seconda del tipo di applicazione è più naturale un approccio relazionale (tabelle e procedure) oppure un approccio Object Oriented in ognuna dei due casi, risulta più adatto: Session-JDBC: approccio procedurale a tabelle di un DB per dati di grandi dimensioni ma di scarsa strutturazione (es.: grandi anagrafiche), spesso ereditati da applicazioni legaci); Entity: approccio OO a dati complessi ed eterogenei riusabili e scalabili; Indipendenza dagli schemi o Facilità di manutenzione: la gestione di tabelle tipicamente complessa su grandi dimensioni (horror stories: 1 anno/uomo per poter aggiungere due colonne in un database); o Entity bean permette di sviluppare ad uno strato superiore rispetto la struttura del Pagina 19 di 38

20 DB, cosa possibile anche con Session+JDBC ma con grande abilità. Ciò comporta la possibilità di seguire l evoluzione del sistema basandosi su OO; Facilità di uso e sviluppo rapido o Sicuramente Session+JDBC sono pù semplici e familiari da utilizzare, ovviamente è necessario valutare l impatto sul team; o Esistono sistemi rapidi di sviluppo per Entity bean che permettono di passare dal design UML al bean: vale la pena utilizzarli su grandi progetti, allo scopo di non perdere tempo scrivendo XML tutto il tempo che si era guadagnato non scrivendo codice Java; Migrazione e sistemi legaci o La maggior parte dei sistemi si scontra con i sistemi legacy progettati in tabelle (se va bene!) il che permette di riutilizzare codice SQL funzionante, testato da anni e che nessuno potrebbe avere voglia/tempo/competenza/fegato da riscrivere! In questo caso Session+JDBC può avere delle giustificazioni; o Entity ha vantaggi a medio-lungo termine ma sul breve, in questo caso, può offrire dei rischi; 4.1 Differenza tra session ed entity beans Un session bean è una componente essenzialmente dalla vita breve poiché esprime esclusivamente il comportamento di una serie di interazioni con l utente (sessione). Un entity bean è una componente dalla vita potenzialmente molto lunga in quanto rappresenta i dati come oggetti persistenti e quindi dalla vita pari a quella di dati su memorie secondarie. Un entity bean è costituito da un insieme di file standard per EJB, ovvero: interface, locali, remote, home, deployment descriptor, etc. Le uniche differenze risiedono: nella classe di entity bean che assegna la definizione dei dati in un database con i metodi per manipolarli, e nella classe di primary key che rende ogni entity bean diverso. Gli Entity EJB sopravvivono ai crash di sistema essendo oggetti persistenti assegnati a dati in memoria secondaria. Sono una vista (view) in un database NON devono essere concepiti come una visione in memoria di dati su memoria secondaria, in quanto l update è costante e a carico del container. Ogni entity deve avere i metodi ejbload() e ejbstore() chiamati dal container (e mai del client/sviluppatore); alcuni dati sono soggetti ad accesso concorrente è quindi necessario risolvere il problema della consistenza. Gli Entity EJB possono essere messi in un pool: la costosa creazione/distruzione di oggetti viene ammortizzata per un lungo periodo di tempo, ogni oggetto entity viene quindi riciclato per usi futuri anche (e soprattutto) per dati diversi dello stesso tipo. La gestione del pooling è a totale carico del container che si occupa di riutilizzare in maniera coerente oggetti entity al fine di Pagina 20 di 38