enterprise java beans e web services...enterprise java beans e web services data:20/05/2005...

Università degli Studi di Salerno Programmazione su Reti 2

Relazione:

Enterprise Java Beans e Web Services

Prof. Auletta Vincenzo

Enterprise Java Beans e Web Services Data:20/05/2005

Programmazione su Reti 2 2004/2005

Pagina 2 di 38

Partecipanti

Antonio Autorino 156/000006

Nicola Vitiello 156/000001

Pasquale Paola 156/000003

Indice degli argomenti

1. Introduzione 3

2. J2EE 4 2.1 Sistemi Distribuiti ad oggetti 4 2.1.1 Oggetti distribuiti 5 2.1.2 Oggetti distribuiti con middleware esplicito 6 2.1.3 Oggetti distribuiti con middleware implicito 7 2.2 J2EE : overview 8 2.2.1 J2EE: il container 8

3. Enterprise Java Bean 10 3.1 La classificazione 10 3.1.1 Architettura di un applicazione distribuita 11 3.2 Session Bean 11 3.2.1 Implementazione di un Session Bean 13

4. Gli Entity Bean 17

5. JMS 23 MDB 25 5.1 25

6. EJB e Web Services 26 6.1 Esportare gli EJB tramite web services 26 6.1.1 Soluzioni proprietarie degli EJB container 26 6.1.2 Utilizzare un motore SOAP esterno all’EJB container 26 6.2 Esempio: HelloBean 27 6.3 Esempio: Skatestown 30 6.3.1 Entity CMP: Product 30 6.3.2 Session Stateless: SkatesProducts 34



Pagina 3 di 38

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 4 di 38

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

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 .

Figura 2.1



Pagina 5 di 38

• 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

2.1.1 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 6 di 38

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.

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

Figura 2.2



Pagina 7 di 38

2.1.3 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.3

Figura 2.4



Pagina 8 di 38

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

2.2.1 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 server-side 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 9 di 38

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 10 di 38

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 11 di 38

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.

3.1.1 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( message-

driven 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 12 di 38

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 13 di 38

• È un tipo primitivo non marcato come transient • È un oggetto (estende Object)

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

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

3.2.1.2 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 14 di 38

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.

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

Figura 3.1



Pagina 15 di 38

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.

3.2.1.4 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

Figura 3.2



Pagina 16 di 38

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 17 di 38

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 18 di 38

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 19 di 38

scrive sul DB, come si strutturano i dati nelle tabelle, etc.

• Efficienza

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;

• Caching

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 20 di 38

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 21 di 38

ottimizzare le prestazioni (callback: ejbActivate() e ejbPassivate() ). Qualcuno deve scrivere, in qualche momento, il codice che accede al database per poter assicurare la persistenza degli oggetti entity :

o se lo fa lo sviluppatore, allora si ha un bean-managed persistent bean (BMP) o altrimenti, lo fa il container e si ha un container-managed persistent bean (CMP): lo

sviluppatore informa solamente del tipo di operazioni e della struttura del bean, poi il container a deployment time crea il codice necessario…enorme risparmio di codice (al costo di affidarsi alla tecnologia EJB!).

All’atto della creazione e rimozione di un entity si deve fisicamente creare nel DB di supporto una riga in una tabella (creazione) oppure si deve cancellare. L’oggetto Home dell’Entity si occupa di effettuare la creazione dell’entity che prende come parametri i dati necessari per riempire il record e restituisce un parametro di chiave primaria (come definito dallo sviluppatore) E’ necessario specificare, per gli entity bean-managed, uno (o più) metodi di finder() che servono per poter implementare la ricerca di un dato bean, corrispondono di solito ad una SELECT SQL; ovviamente, se si usa un DB, si possono modificare i dati direttamente sul DB (utile per i legacy) e i cambi sono riflessi sull’entity. Attenzione alla configurazione del container per i problemi di caching (coerenza)! Il metodo getPrimaryKey() restituisce la chiave associata alla istanza del bean essenzialmente serve per evitare che ci siano problemi con il riuso ed il pooling di risorse: si chiama per poter sapere ejbLoad() da che riga della tabella deve caricare i dati oppure si chiama per ejbRemove(). 4.2 BMP e CMP E’ necessario che sia scritto il codice che accede al database per poter assicurare la persistenza degli oggetti entity :

• se lo fa lo sviluppatore, allora si ha un bean-managed persistent bean (BMP Entity Bean) • altrimenti, lo fa il container e si ha un container-managed persistent bean (CMP Entity

Bean) lo sviluppatore informa solamente del tipo di operazioni e della struttura del bean, poi il container a deployment time crea il codice necessario

L’implementazione di un BMP entity bean è complessa e tediosa, e poco utilizzata di conseguenza sposto l’attenzione più verso i CMP. Tipicamente gli entity bean implementano solamente le interfacce local, in quanto tipicamente vengono chiamati solamente da altri oggetti (EJB session, servlet, etc.) che sono locali per motivi di testing, viene comunque di solito fornita una interface remota (che viene soppressa in produzione). Un CMP è costituito dall’entity bean (la logica presente nei dati) e dalla rappresentazione persistente di tali dati. Il meccanismo del subclassing consiste in due fasi il programmatore scrive una classe astratta e il container (a deployment time) la rende “concreta”



Pagina 22 di 38

derivando da essa una classe con i metodi per la persistenza. In maniera simile a come vengono specificati gli attributi negli ambienti distribuiti (dove la sintassi non offre tale possibilità dichiarando, cioè, i metodi accessori) si specificano nella classe astratta esclusivamente i metodi accessori lasciando al container (durante il deployment) il compito di generare i campi nella classe concreta derivata, ovviamente, questo vale esclusivamente per i campi persistenti, altri campi di uso da parte del bean vanno dichiarati nella classe astratta dal programmatore. L’abstract persistence schema: è la dichiarazione nel deployment descriptor dei campi che devono essere resi persistenti. Lo scopo è di permettere all’atto del deployment di generare il codice necessario per la persistenza. Si dichiara:

• la versione utilizzata di EJB • il nome dell’abstract persistence schema • il nome dei campi persistenti • consistenti con il nome dei metodi accessori (get,set) • consistenti con le regole di naming (prima lettera minuscola)

4.3 EJB Query Language Viene fornito come linguaggio per effettuare le query, è orientato agli oggetti con una sintassi SQL-like; dovrebbe essere portabile in pratica non lo è! Viene inserito nel deployment descriptor che per ogni metodo descrive il nome del metodo, i parametri, la query EJB-QL da eseguire. Una altra differenza tra BMP e CMP entity bean è la presenza dei metodi di select: sono come un metodo finder ai quali non è possibile accedere dal client (attraverso la home interface o la component interface); viene usato internamente come metodo per accedere ai dati per operazioni sul DB che non devono essere esposte, per reperire dati da altri entity beans con i quali il bean ha relazioni: possono restituire non solo entity beans (o loro collection) ma anche campi (gestiti dal container) o loro collection. Le differenze tra Bean Managed Persistent e Container Managed Persistent risiedono esclusivamente nella classe dell’entity bean e nel deployment descriptor. Questo permette una facile transizione tra BMP e CMP e viceversa facilitando lo sviluppo della logica dei dati che risulta così indipendente dalle scelte relative alla persistenza dei dati. Tutto il lavoro risparmiato con i CMP viene di fatto demandato a:

• al container che si occupa della persistenza • alla fase di deployment che richiede una complessa dichiarazione delle caratteristiche del

bean

Quindi, il lavoro del “programmatore” colui/colei che programma diventa anche lavoro di “dichiaratore” colui/colei che dichiarano nel deployment descriptor quali sono i dati di cui assicurare la persistenza e in cosa si traducono le operazioni necessarie sugli oggetti Le fasi di deployment:



Pagina 23 di 38

• Configurazione del database reference • Creazione del bean:

o scelta delle classi o persistenza: scelta dei campi o persistenza: EJB-QL per i metodi o persistenza: informazioni per la creazione della tabella SQL

• Verifica del bean (se rispetta le specifiche del container) • Deployment sul container

5. JMS Prima di parlare dell’ultimo tipo di bean bisogna parlare di JMS ovvero Java Message Service. E’ un servizio Servizio di Messaging per componenti software peer-to-peer che permette di scambiare messaggi tra peer che possono assolvere il ruolo di producer o consumer di messaggi in maniera intercambiabile (P2P). E’ un servizio alla base del Middleware Orientato ai Messaggi (MOM): trasmissione asincrona e debolmente accoppiata (loosely couplet). Il motivo per cui si è scelto di utilizzare un meccanismo di messaging è che il tradizionale meccanismo di comunicazione (Remote callout) comporta delle situazioni non adeguatamente risolte da RMI-IIOP ovvero:

• chiamate bloccanti e sincrone, il client si blocca fino a quando il server non completa la chiamata, questo vale anche con le implementazioni non bloccanti (call-back, etc.) che servono solo a ridurre il problema;

• il server deve essere in esecuzione quando il client effettua la chiamata Il Messaging è una alternativa alle invocazioni remote: viene utilizzato un intermediario (software di middleware) che offre il servizio di message permettendo lo stile di programmazione asincrono; le chiamate sono “veramente” asincrone:

• il client invia il messaggio e continua con le sue computazioni, questa è un’importante caratteristica quando non è necessario un feedback immediato al client (o all’utente). Il ruolo dell’intermediario sostituisce il server (destinazione del messaggio): se il server non è in esecuzione, il middleman mantiene il messaggio del client, sarà compito dell’intermediario recapitare il messaggio quando il server sarà di nuovo in esecuzione (garanzia di recapito).

L’intermediario può agire (se configurato opportunamente) in maniera da distribuire il messaggio a più destinatari (broadcasting del messaggio), utile per: facilità di programmazione, efficienza (il client non deve effettuare n spedizioni, ma sarà l’intermediario a svolgere il compito). Java Message Service è un’API sviluppata dalla Sun; due sono le componenti principali:



Pagina 24 di 38

• Application Programming Interface (API): permette di scrivere codice per inviare e ricevere messaggi;

• Service Programming Interface (SPI) permette di scrivere JMS drivers per poter usare implementazioni MOM specifiche, simile al concetto di driver in JDBC e JNDI, permette la modularità e indipendenza dalla piattaforma di MOM utilizzata.

Due sono le modalità presenti nei sistemi MOM esistenti:

• point-to-point o I messaggi vengono indirizzati ad una singola coda da un sender; i receiver

estraggono i messaggi dalla coda per leggerli; la coda memorizza i messaggi fino a quando essi sono estratti da un receiver oppure il messaggio scade di validità (expiration) Tre sono le caratteristiche fondamentali:

� I messaggi hanno un solo receiver � Il sender ed il receiver non hanno dipendenze temporali � il receiver può prelevare il messaggio anche se esso è stato spedito prima

che il receiver fosse attivo. Il receiver fa l’acknowledgment del messaggio ricevuto.

o In generale è buona norma usare il dominio point-to-point quando si vuole che: ogni messaggio deve essere ricevuto in maniera affidabile da esattamente un receiver

• publish/subscribe o I messaggi vengono indirizzati ad un topic (una sorta di bullettin board) da un

publisher e i subscriber ricevono i messaggi dal topic. La coda memorizza i messaggi solamente per poterli distribuire a tutti i subscriber. Le caratteristiche fondamentali del publish/subscribe sono:

� I messaggi possono avere multipli subscriber � Il publisher ed il subscriber hanno dipendenze temporali � Il subscriber può prelevare solo i messaggi che sono stati pubblicati dopo

la sua sottoscrizione � Per poter ricevere messaggi, il subscriber deve essere attivo (esistono le

durable subscription in cui il subscriber riceve messaggi anche se temporaneamente non attivo)

o Il dominio publish/subscribe viene utilizzato quando si vuole che i messaggi devono essere spediti/ricevuti da client multipli ed anonimi

Le modalità di ricezione dei messaggi (i messaggi sono inerentemente asincroni) sono due:

• sincrona: o un receiver/subscriber chiama esplicitamente il metodo receive() (bloccante

oppure fino ad un timeout definibile ) • asincrona:

o un receiver/subscriber registra un message listener presso un consumer: quando



Pagina 25 di 38

arriva un messaggio, viene chiamato il metodo onMessage() del Message Listener

5.1 MDB Un’idea interessante fu proposta nella versione 2.0 di Enterprise JavaBeans, ovvero “Permettere ad un EJB di poter ricevere messaggi JMS, in una qualche maniera”. I Message Driven Bean sono EJB a tutti gli effetti potendo quindi godere di tutti i servizi forniti dal container, ma sono dei consumatori di messaggi: i client possono esclusivamente inviare messaggi e quindi non ci sono interfacce da definire di alcun tipo c’è un solo metodo da implementare che è lo stesso della interface MessageListener cioè onMessage(). Non ci sono valori da restituire né eccezioni da lanciare, non c’è stato da mantenere (gli MDB sono stateless). Un MDB deve implementare le interfacce MessageDrivenBean e MessageListener; la classe deve essere pubblica (non astratta o final) deve implementare un metodo ejbCreate() e un metodo ejbRemove() pubblici, non static/final, senza argomenti o eccezioni della applicazione. Deve contenere un costruttore pubblico senza argomenti, non deve definire metodi final. I vincoli da seguire per onMessage() sono: il metodo deve essere pubblico (e non dichiarato final o static), il tipo di ritorno deve essere void, non deve lanciare eccezioni specifiche della applicazione (ma solo eventualmente quelle EJB), non deve gestire le transazioni di per sé (questo viene fatto settando il parametro corretto nel descriptor file).



Pagina 26 di 38

6. EJB e Web Services Come già presentato in precedenza, gli ejb sono stati progettati per avere un alto grado d’interoperabilità verso altri linguaggi di programmazione, affinché sia possibile integrare in un'unica piattaforma sistemi sviluppati con tecnologie diverse, soprattutto per il riuso di sistemi legasy. In modo nativo un sistema sviluppato con ejb permette di interagire tramite:

• 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 (implicitamente si ha così l’integrazione in sistemi sviluppati con CORBA) • Applicazioni basate sullo scambio di messaggi utilizzando JMS

Volendo integrare il sistema implementato con altri che non utilizzano i sistemi descritti, si ricorre all’utilizzo dei web services. Inoltre i due ultimi sistemi d’interazione anche se più efficienti non sono utilizzati per interagire a traverso reti esterne all’intranet aziendale, aumentando così la sicurezza interna alla rete aziendale.

6.1 Esportare gli EJB tramite web services Le soluzioni principali per esportare gli ejb tramite web services sono sostanzialmente le seguenti:

6.1.1 Soluzioni proprietarie degli EJB container

Quasi tutti i container permettono di esportare i propri EJB come web services. Nel caso di SUN JavaTM System Application Server Platform Edition 81, all’atto del deployment si specifica di voler esportare l’ejb come web services. Il tool chiederà di inserire il file WSDL che descrive il servizio ed un file XML per ulteriori informazioni che serviranno al container all’atto del deployment (stessa funzionalità del file WSDD di Axis).

6.1.2 Utilizzare un motore SOAP esterno all’EJB con tainer

6.1.2.1 Wrapper

Utilizzando un motore SOAP esterno all’EJB container, posso implementare un web services che fa da wrapper tra i miei EJB ed il client SOAP. Il web services implementerà al suo interno tutta la logica per l’accesso all’EJB2. La presente soluzione è sempre applicabile, con qualsiasi sistema si utilizza. In realtà è

1 Su cui abbiamo effetuato i test. Liberamente scaricabile dal sito della Sun nella sezione J2EE.

2 Utilizzando RMI-IIOP o JMS per interagire con esso.



Pagina 27 di 38

molto più utile, quando non si vuole esportare esattamente la logica implementata negli EJB, mascherandone parte di essa.

6.1.2.2 Soluzione offerta da AXIS

Axis permette d’interagire con gli EJB di tipo Session Stateless in modo semiautomatico, tramite l’utilizzo di uno dei suoi tanti provider. Precisamente il provider “Java:EJB”. Non serve altro che scrivere un file WSDD per il deployment su axis dei servizi che si vogliono esportare inserendo come parametri al servizio i seguenti attributi: � beanJndiName: il nome registrato nell’architettura JNDI del Session Bean Stateless

con cui si vuole interagire; � homeInterfaceName: il nome dell’interfaccia home remota; � remoteInterfaceName: il nome dell’interfaccia remota del servizio; � jndiContextClass: il nome della classe che implementa l’interfaccia JNDI; � jndiURL: l’url del server di naming.

6.2 Esempio: HelloBean Vediamo di seguito un semplice esempio di session bean stateless che offre il servizio di hello. Per prima cosa illustriamo il codice dell’Ejb HelloBean. Per quanto riguarda le interfacce remote e locali mettono a disposizione un unico metodo che è quello di hello, che prende in input una stringa e ritorna una stringa.

� Hello.java import java.rmi.RemoteException; import javax.ejb.EJBObject; public interface Hello extends EJBObject { public String hello(String in) throws RemoteException; } � HelloLocal.java import javax.ejb.EJBLocalObject; public interface HelloLocal extends EJBLocalObject { public String hello(String in); }

La differenza sostanziale è che il metodo hello in locale non deve lanciare eccezioni remote. Per quanto riguarda le interfacce Home di seguito riportare, offrono il metodo create, il quale permette di “creare” un istanza di HelloBean è di accedervi tramite l’interfaccia remota o locale.

� HelloHome.java import java.rmi.RemoteException; import javax.ejb.CreateException;



Pagina 28 di 38

import javax.ejb.EJBHome; public interface HelloHome extends EJBHome { public Hello create() throws RemoteException,CreateException; } � HelloLocalHome.java import javax.ejb.CreateException; import javax.ejb.EJBLocalHome; public interface HelloLocalHome extends EJBLocalHome { public HelloLocal create() throws CreateException; }

Fino a questo momento abbiamo creato soltanto interface dove abbiamo inserito le firme dei metodi che ci servono. L’implementazione di questi metodi è a carico del container tranne per i metodi di business (il metodo hello). A questo punto non ci resta che implementare la logica del bean.

� HelloBean.java import java.rmi.RemoteException; import javax.ejb.EJBException; import javax.ejb.SessionBean; import javax.ejb.SessionContext; public class HelloBean implements SessionBean { public void ejbCreate() throws EJBException{ } public void ejbActivate() throws EJBException, RemoteException { } public void ejbPassivate() throws EJBException, RemoteException { } public void ejbRemove() throws EJBException, RemoteException { } public void setSessionContext(SessionContext arg0) throws EJBException, RemoteException { this.ctx = arg0; } public String hello(String in){ return "Ciao "+in; } private SessionContext ctx; }



Pagina 29 di 38

La nostra classe implementa l’interfaccia javax.ejb.SessionBean, implementando i metodi che gli servono (in questo caso nessuno), e fornendo l’implementazione del metodo hello. A questo punto si compila il tutto è lo si inserisce in un file jar fornendo il file xml per il deployment3. Di seguito riportiamo parte del file ejb-jar.xml:

<enterprise-beans> <session> <ejb-name>HelloBean</ejb-name> <home>HelloHome</home> <remote>Hello</remote> <local-home>HelloLocalHome</local-home> <local>HelloLocal</local> <ejb-class>HelloBean</ejb-class> <session-type>Stateless</session-type> <transaction-type>Bean</transaction-type> <security-identity> <use-caller-identity/> </security-identity> </session>

</enterprise-beans> Dopo aver fatto il deployment sul container dobbiamo eseguire il deployment su axis per esportare il servizio di hello tramite web services. Utilizziamo il seguente file WSDD come descritto in precedenza.

<deployment xmlns="http://xml.apache.org/axis/wsdd/" xmlns:java="http://xml.apache.org/axis/wsdd/providers/java"> <service name="HelloBean" provider="java:EJB"> <parameter name="beanJndiName" value="HelloBean"/> <parameter name="homeInterfaceName" value="HelloHome"/> <parameter name="remoteInterfaceName" value="Hello"/> <parameter name="allowedMethods" value="hello"/> <parameter name="jndiContextClass" value="com.sun.jndi.cosnaming.CNCtxFactory"/> <parameter name="jndiURL" value="iiop://localhost:3700"/> </service> </deployment>

È molto importante che prima di eseguire il deploy su AXIS tramite Adminclient, bisogna copiare il file jar generato dall’AS per i client, nella directory {TomcatHome}\webapps\axis\WEB-INF\lib. Inoltre per far sì che AXIS possa accedere agli EJB bisogna copiare il file j2ee.jar (reperibile nelle distribuzioni di j2ee) nella cartella di Tomcat contenente le librerie condivise ({TomcatHome}\common\lib). A questo punto non ci resta che eseguire il client Soap che del tutto simile al client hello visto

3 Nel nostro caso è stato utilizzato il tool (Deploytool) fornito dalla Sun per creare in modo semiautomatico i file jar per il deployment.



Pagina 30 di 38

nelle prime esercitazioni sui web services4.

6.3 Esempio: Skatestown Vediamo in quest’ultima parte un esempio più complesso d’interazione con più ejb. Vogliamo costruire un sistema software che permette di memorizzare dei prodotti commerciali ed inoltre il sistema dovrà permetterci di effettuare operazioni di ricerca sui prodotti memorizzati. Per ogni prodotto vogliamo memorizzare l’ID del prodotto, il suo nome, una descrizione e il prezzo base, mentre come operazioni che il sistema deve offrire vogliamo: inserire articoli, estrarre tutti i prodotti presenti e ricercare il prezzo di un prodotto tramite il suo ID. Il sistema sarà implementato utilizzando due ejb, il primo di tipo entity CMP che modellerà l’entità prodotto, permettendoci di rendere persistenti le informazioni sui prodotti. Mentre per le operazioni su di essi si utilizzerà un ejb di tipo session stateless che metterà a disposizione tre metodi per le tre operazioni richieste. Il diagramma illustra i due ejb.

6.3.1 Entity CMP: Product L’ejb product implementerà la persistenza dei dati sui prodotti. Non sarà fornita un’interfaccia remota, ma soltanto quella locale, questo permetterà l’accesso all’ejb solo all’interno del container, quindi le interazioni da remoto dovranno essere fatte con l’ejb session. Di seguito riportiamo l’interfaccia locale dell’entity e la sua home locale.

4 Il codice non viene riportato, si vedanoo gli allegati alla relazione.



Pagina 31 di 38

� ProductLocal.java import javax.ejb.EJBLocalObject; public interface ProductLocal extends EJBLocalObject { public String getName(); public void setName(String name); public String getDescription(); public void setDescription(String desc); public double getBasePrice(); public void setBasePrice(double price); public String getProductID(); } � ProductLocaHomel.java import java.util.Collection; import javax.ejb.CreateException; import javax.ejb.EJBLocalHome; import javax.ejb.FinderException; public interface ProductLocalHome extends EJBLocalHome { ProductLocal create(String productID,String name,String desc,double price)throws CreateException; public ProductLocal findByPrimaryKey(String key)throws FinderException; public Collection findAll()throws FinderException; }

Come spiegato in precedenza l’interfaccia locale espone metodi get e set per ogni attributo da rendere persistente, da notare che non c’è il metodo setProductID perché non deve essere possibile cambiare la chiave primaria una volta creato un prodotto5. Per la classe home ci sono tre metodi: il primo crea un nuovo prodotto, il secondo permette la ricerca su chiave primaria ed in fine il terzo metodo estrae tutti i prodotti presenti e ritorna una collezione. Presentiamo ora l’implementazione dell’entity bean:

� ProductBean.java import java.rmi.RemoteException; import javax.ejb.CreateException; import javax.ejb.EJBException; import javax.ejb.EntityBean; import javax.ejb.EntityContext;

5 Equivarrebbe ad una cancellazione e reazione di un nuovo prodotto.



Pagina 32 di 38

import javax.ejb.RemoveException; public abstract class ProductBean implements EntityBean { protected EntityContext ctx; public ProductBean(){} public abstract String getName(); public abstract void setName(String name); public abstract String getDescription(); public abstract void setDescription(String desc); public abstract double getBasePrice(); public abstract void setBasePrice(double price); public abstract String getProductID(); public abstract void setProductID(String ID); public void ejbActivate() throws EJBException, RemoteException {} public void ejbLoad() throws EJBException, RemoteException {} public void ejbPassivate() throws EJBException, RemoteException {} public void ejbRemove() throws RemoveException, EJBException, RemoteException {} public void ejbStore() throws EJBException, RemoteException {} public void unsetEntityContext() throws EJBException, RemoteException { this.ctx = null; } public void setEntityContext(EntityContext arg0) throws EJBException, RemoteException { this.ctx = arg0; } public String ejbCreate(String productID,String name,String desc,double basePrice)throws CreateException{ setProductID(productID); setDescription(desc); setName(name); setBasePrice(basePrice); return productID; }



Pagina 33 di 38

public void ejbPostCreate(String productID,String name,String desc,double basePrice){} }

La classe ProductBean è astratta ed anche i suoi metodi accessori sono astratti, il container a deployment time renderà concreta la classe implementando i metodi accessori, i quali conterranno la logica per la persistenza dei dati. Oltre ai metodi che già si trovano nell’interfaccia EntityBean, implementiamo il metodo ejbCreate e il corrispondente ejbPostCreate6. Da notare che l’ejbCreate ritorna una stringa (il productID), mentre il metodo Create dell’home ritornava un ProductLocal, perché il container utilizza la chiave primaria come riferimento agli oggetti. Una volta compilato si crea il file jar dove s’inserisce il file ejb-jar.xml che conterrà inoltre la query per il metodo findAll, mentre per la findByprimaryKey il container sa come implementarla. Di seguito riportiamo parte del file xml:

<enterprise-beans> <entity> <ejb-name>ProductBean</ejb-name> <local-home>ProductLocalHome</local-home> <local>ProductLocal</local> <ejb-class>ProductBean</ejb-class> <persistence-type>Container</persistence-type> <prim-key-class>java.lang.String</prim-key-class> <reentrant>false</reentrant> <cmp-version>2.x</cmp-version> <abstract-schema-name>ProductBean</abstract-schema-name> <cmp-field> <description xml:lang="it">no description</description> <field-name>basePrice</field-name> </cmp-field> <cmp-field> <description xml:lang="it">no description</description> <field-name>productID</field-name> </cmp-field> <cmp-field> <description xml:lang="it">no description</description> <field-name>description</field-name> </cmp-field> <cmp-field> <description xml:lang="it">no description</description> <field-name>name</field-name> </cmp-field> <primkey-field>productID</primkey-field> <security-identity> <use-caller-identity/> </security-identity> <query>

6 Utilizzato per eventuali elaborazioni dei dati dopo la creazione di un prodotto.



Pagina 34 di 38

<query-method> <method-name>findAll</method-name> <method-params/> </query-method> <ejb-ql>SELECT OBJECT(a)ProductBean AS aa.productID IS NOT NULL</ejb-ql> </query> </entity> </enterprise-beans>

6.3.2 Session Stateless: SkatesProducts I metodi di business saranno forniti dal session bean SkatesProducts che implementerà tre metodi per le tre operazioni richieste. SkatesProducts interagirà con il bean Product potendo così creare ed effettuare ricerche sui prodotti memorizzati. Si forniranno soltanto interfacce remote visto che in locale non sarà utilizzato da nessun altro bean. Riportiamo di seguito il codice dell’interfaccia home e dell’oggetto remoto:

� SkatesProducts.java import java.rmi.RemoteException; import javax.ejb.EJBObject; public interface SkatesProducts extends EJBObject { public void addProduct(String pID,String name,String descr, double price)throws RemoteException; public double getPriceOfProduct(String pID)throws RemoteException; public String getAllProducts()throws RemoteException; } � SkatesProductsHome.java import java.rmi.RemoteException; import javax.ejb.CreateException; import javax.ejb.EJBHome; public interface SkatesProductsHome extends EJBHome { public SkatesProducts create() throws RemoteException,CreateException; }

Nell’interfaccia dell’oggetto remoto sono stati messi i tre metodi richiesti per il sistema, da notare che il metodo getAllProducts restituisce una stringa, semplicemente per ovviare al problema del passaggio di tipi complessi che non erano stati ancora affrontati nel corso di programmazione su reti. L’interfaccia home espone il solito metodo per la creazione di un oggetto di tipo SkatesProducts. Vediamo ora il codice d’implementazione del bean:



Pagina 35 di 38

� SkatesProductsBean.java import java.rmi.RemoteException; import java.util.Iterator; import javax.ejb.CreateException; import javax.ejb.EJBException; import javax.ejb.FinderException; import javax.ejb.SessionBean; import javax.ejb.SessionContext; import javax.naming.InitialContext; import javax.rmi.PortableRemoteObject; public class SkatesProductsBean implements SessionBean { private SessionContext ctx; public void ejbCreate() throws EJBException{} public void addProduct(String pID,String name,String descr, double price){ ProductLocalHome homeEntity = null; try{ InitialContext ic = new InitialContext(); Object obj = ic.lookup("java:comp/env/ejb/Product"); homeEntity = (ProductLocalHome)PortableRemoteObject.narrow(obj,ProductLocalHome.class); }catch(Exception e){ System.out.println("Errore nella addProduct: nella ricerca dell'entity bean."); } try { homeEntity.create(pID,name,descr,price); } catch (CreateException e1) { System.out.println("Errore nella addProduct: nella creazione dell'entity bean."); } } public double getPriceOfProduct(String pID){ ProductLocalHome homeEntity = null; try{ InitialContext ic = new InitialContext(); Object obj = ic.lookup("java:comp/env/ejb/Product"); homeEntity = (ProductLocalHome)PortableRemoteObject.narrow(obj,ProductLocalHome.class); }catch(Exception e){ System.out.println("Errore nella getPriceOfProduct: nella ricerca dell'entity bean."); } ProductLocal entity = null; try { entity = homeEntity.findByPrimaryKey(pID); } catch (FinderException e1) { System.out.println("Errore nella getPriceOfProduct: entity non trovato.");



Pagina 36 di 38

} if(entity!=null){ return entity.getBasePrice(); }else{ System.out.println("Errore nella getPriceOfProduct: alla getBasePrice."); } return -1; } public String getAllProducts(){ ProductLocalHome homeEntity = null; try{ InitialContext ic = new InitialContext(); Object obj = ic.lookup("java:comp/env/ejb/Product"); homeEntity = (ProductLocalHome)PortableRemoteObject.narrow(obj,ProductLocalHome.class); }catch(Exception e){ System.out.println("Errore nella getAllProducts: nella ricerca dell'entity bean."); } ProductLocal entity = null; Iterator i = null; String str = ""; try { i = homeEntity.findAll().iterator(); } catch (FinderException e1) { System.out.println("Errore nella getAllProducts: entity non trovato."); } while(i.hasNext()){ entity = (ProductLocal)PortableRemoteObject.narrow(i.next(),ProductLocal.class); str += entity.getProductID()+" "+entity.getName()+" "+entity.getDescription()+" "+entity.getBasePrice()+"\n"; } return str; } public void ejbActivate() throws EJBException, RemoteException {} public void ejbPassivate() throws EJBException, RemoteException {} public void ejbRemove() throws EJBException, RemoteException {} public void setSessionContext(SessionContext arg0) throws EJBException, RemoteException { this.ctx = arg0; } }

Nell’implementazione del bean troviamo i tre metodi prima descritti. In tutti e tre si cerca il riferimento all’entity bean Product tramite il riference ejb/Product il quale sarà specificato nel file di descrizione ejb-jar.xml. poi a questo punto ogni metodo richiama un metodo di Product a



Pagina 37 di 38

seconda della logica da implementare. Dopo aver compilato il tutto si creerà il file punto jar dove oltre alle classi compilate s’inserirà il file xml di deployment che qui di seguito se ne riporta una parte.

<enterprise-beans> <session> <ejb-name>SkatesProductsBean</ejb-name> <home>SkatesProductsHome</home> <remote>SkatesProducts</remote> <ejb-class>SkatesProductsBean</ejb-class> <session-type>Stateless</session-type> <transaction-type>Bean</transaction-type> <ejb-local-ref> <ejb-ref-name>ejb/Product</ejb-ref-name> <ejb-ref-type>Entity</ejb-ref-type> <local-home>ProductLocalHome</local-home> <local>ProductLocal</local> <ejb-link>Product.jar#ProductBean</ejb-link> </ejb-local-ref> <security-identity> <use-caller-identity/> </security-identity> </session> </enterprise-beans>

6.3.3 Skatestown.ear In fine per creare un unico file di deployment si uniscono i due file jar fin ora prodotti, uno per Product e l’altro per SkatesProducts, in un unico file con estensione ear7 inserendovi un file di descrizione chiamato application.xml:

<?xml version="1.0" encoding="UTF-8"?> <application xmlns="http://java.sun.com/xml/ns/j2ee" version="1.4" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/application_1_4.xsd"> <description xml:lang="it">Application description</description> <display-name xml:lang="it">Skatestown</display-name> <module> <ejb>Product.jar</ejb> </module> <module> <ejb>SkatesProducts.jar</ejb> </module> </application>

A questo punto bisogna fare il deployment sul container, ma prima di effettuarlo bisogna 7 Un file ear è anchesso un file zippato come i file jar, utilizzato per mettere insieme più componenti di un progetto sviluppato in

J2EE.

Reference a Product



Pagina 38 di 38

costruire un riferimento ad un database dove si memorizzeranno i prodotti. Nel nostro esempio utilizzando AS 8.0 si dovrà creare uno JDBC Resources di nome jdbc/Product con l'admin console della distribuzione, il riferimento sarà di tipo PointBasePool8. Dopo aver fatto il deployment sul container ci facciamo restituire il jar per il client e scriviamo il file wsdd per Axis. È importante mettere il client jar che vi fate generare con il deploytool, nella cartella {TomcatHome}\webapps\axis\WEB-INF\lib prima di effettuare il deployment con Adminclient. Ricordatevi che per abilitare Axis all'uso degli ejb mettete j2ee.jar sotto la cartella {TomcatHome}\common\lib. Per quanto riguarda il client basta eseguirlo con i jar di Axis. Tutto il materiale citato si trova in allegato alla presente relazione.

8 Utilizziamo l’ODB della distribbuzione della Sun

enterprise java beans e web services...enterprise java beans e web services data:20/05/2005...

Documents