JBoss Application Server e Sviluppo di Applicazioni Distribuite in J2EE. Concetti di Base ed Esempi.

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "JBoss Application Server e Sviluppo di Applicazioni Distribuite in J2EE. Concetti di Base ed Esempi."

Transcript

1 SAPIENZA Università di Roma Facoltà di Ingegneria Corso di Laurea in Ingegneria Gestionale e Ingegneria Informatica Dispensa didattica JBoss Application Server e Sviluppo di Applicazioni Distribuite in J2EE. Concetti di Base ed Esempi. M. Bartiromo, V. De Angelis, M. de Leoni, F. de Leoni, M. Mecella, R. Russo, S. Saltarelli

2 Creative Commons License Deed Attribuzione - Non commerciale - Non opere derivate 2.5 Italia Tu sei libero: di riprodurre, distribuire, comunicare al pubblico, esporre in pubblico, rappresentare, eseguire e recitare questa opera Alle seguenti condizioni: Attribuzione. Devi attribuire la paternità dell opera nei modi indicati dall autore o da chi ti ha dato l opera in licenza. Non commerciale. Non puoi usare questa opera per fini commerciali. Non opere derivate. Non puoi alterare o trasformare quest opera, nè usarla per crearne un altra. Ogni volta che usi o distribuisci questa opera, devi farlo secondo i termini di questa licenza, che va comunicata con chiarezza. In ogni caso, puoi concordare col titolare dei diritti d autore utilizzi di quest - opera non consentiti da questa licenza. Niente in questa licenza indebolisce o restringe i diritti degli autori. Le utilizzazioni consentite dalla legge sul diritto d autore e gli altri diritti non sono in alcun modo limitati da quanto sopra. Questo è un riassunto in linguaggio accessibile a tutti del Codice Legale (la licenza integrale) disponibile all indirizzo:

3 Indice Introduzione 5 1 RMI Dalle RPC a RMI (Object Broker) La serializzazione e la trasmissione degli oggetti Architettura RMI Uso di RMI Esempio: Sender e Receiver Swing Il package Swing Top Level Container Uso di JFrame Paranoramica di alcuni widget L ereditarietà per personalizzare i frame I Layout Manager e la gerarchia di contenimento Layout Management Progettazione della GUI con le gerarchie di contenimento Progettazione top down di interfacce grafiche La Gestione degli Eventi Implementazione dell event delegation Un esempio: elaborare gli eventi del mouse Uso di adapter nella definizione degli ascoltatori La gestione degli eventi Azione Accedere dall ascoltatore agli oggetti di una finestra Condividere gli ascoltatori per più oggetti Conclusioni Servlet e Java Server Pages (JSP) Introduzione alle Servlet Il Ciclo di Vita di una Servlet

4 INDICE Come Interagire con una Servlet: Richieste e Risposte Esempio Data Esempio Rubrica Le Sessioni Esempio Login Le Java Server Pages (JSP) Esempio Lista Prodotti (carrello) JMS: Enterprise Messaging (ed introduzione su MOM) Introduzione al MOM (richiami) Modelli di Messaging Introduzione a JMS Enterprise Java Bean (EJB) Introduzione agli EJB Fondamenti degli EJB Scheletro di un Enterprise Bean Enterprise Bean Class L EJB Object L Home Object Le interfacce locali Deployment Descriptor Session Bean Esempi Ciclo vita dei Session Bean Creazione di un Session Bean Stateless Creazione di un Session Bean Stateful Entity Bean Caratteristiche Esempi Creazione di un Entity Bean Bean-Managed persistent Creazione di un Entity Bean Container-Managed persistent Message-driven Bean Utilizzo dei MDB Applicazione completa sugli EJB Vendita di libri on-line Alcuni Diagrammi UML dell Applicazione Package BookOrder Package BookOrderMDB

5 INDICE Package Archivio Package BookStoreSwing Modulo Accesso.war Il deployment descriptor Provare l applicazione Web Service Le tecnologie alla base dei Web Services SOAP: Simple Object Access Protocol WSDL: Web Service Definition Language UDDI: Universal Description Discovery and Integration Applicazione completa sui Web Service Il Web Service Il Client Appendice 257 A.1 Servlet e JSP A.2 Uso di JMS con JBOSS Bibliografia 261

6 Introduzione Oggigiorno, un numero sempre crescente di sviluppatori di sistemi software per le imprese sta spostando il suo interesse verso applicazioni distribuite transazionali con lo scopo di usufruire della maggiore velocità, sicurezza e affidabilità delle tecnologie server-side. Molti, infatti, sono i vantaggi derivanti dall adozione di un modello distribuito: un sensibile miglioramento delle prestazioni complessive, una maggiore semplicità nella gestione delle risorse distribuite e un sostanziale incremento delle potenzialità operative. Ad esempio, si può pensare di suddividere un processo computazionalmente pesante in sottoroutine più piccole ed eseguire tali pezzi di applicazione su macchine diverse, ottenendo una drastica diminuzione del tempo complessivo di esecuzione. L esigente mondo dell e-commerce e dell information technology, in continuo cambiamento, richiede che le applicazioni aziendali siano progettate e costruite con uso di minori risorse economiche e maggiore velocità di quanto non accadesse in precedenza. Un importante scenario in cui è utile l utilizzo del modello distribuito è quello in cui si devono realizzare applicazioni che si interfacciano con codice legacy: in tal caso si può pensare di inglobare gli applicativi esistenti (legacy appunto) in oggetti remoti e pilotarne in tal modo le funzionalità da un client scritto con i nuovi paradigmi di programmazione. Per programmazione distribuita si intende tipicamente quel particolare paradigma computazionale in cui una applicazione viene organizzata in moduli differenti, localizzati in spazi di indirizzamento diversi tra loro. La programmazione distribuita consente di realizzare sistemi service-oriented in cui un componente A è in grado di invocare i servizi di un componente B dispiegato su un computer remoto: in tale scenario, per semplicità, si definisce client il componente chiamante, mentre il remoto è detto server. I sistemi distribuiti sono generalmente costruiti al di sopra di un middleware. Esso fornisce astrazioni di programmazione che nascondono alcune delle complessità che costituiscono la realizzazione di un applicazione distribuita. I diversi componenti che cooperano a fornire un servizio composito 5

7 Introduzione 6 possono essere dispiegati su piattaforme diverse. I middleware hanno quindi anche il compito di nascondere l eterogeneità delle piattaforme dietro una astrazione comune. Il crescente uso del Web come canale di accesso ai sistemi informativi ha forzato le piattaforme middleware a fornire il supporto per l accesso al Web. Questo supporto è tipicamente fornito sotto forma di Application Server. Gli Application Server sono equivalenti alle piattaforme middleware. La differenza principale è l incorporazione del Web come canale di accesso ai servizi implementati utilizzando il middleware. Le tecnologie su cui possono basarsi gli Application Server sono due: Microsoft.NET e Java di Sun. In termini di funzionalità, gli Application Server basati su Java e quelli basati su.net presentano molte similitudini. Ciononostante, quella basata su Java è nettamente più diffusa e accettata, ed annovera numerose implementazioni sia commerciali che open source. Per ridurre i costi, il progetto e lo sviluppo di applicazioni, la Piattaforma Java2 Enterprise Edition (J2EE) fornisce un approccio basato sui componenti per la progettazione, lo sviluppo, l assemblamento e il dispiegamento delle applicazioni d impresa. La piattaforma J2EE offre un modello di applicazione distribuita multilivello, componenti riusabili, un modello di sicurezza unificato, un controllo flessibile delle transazioni, e un supporto ai servizi web mediante scambio di informazioni basato su XML. Generalmente, gli Application Server di tipo open source vengono impiegati per la ricerca, la didattica e nelle piccole e medie imprese, che non possono permettersi soluzioni commerciali. Spesso, questi prodotti a basso costo non hanno nulla da invidiare alle soluzioni commerciali, sia nell efficienza che nelle fnzionalità disponibili. Tuttavia, soffrono di una scarsa documentazione. Alla luce di queste considerazioni, questo lavoro ha come obbiettivo quello di fornire una valida documentazione di supporto all uso delle tecnologie J2EE, con particolare attenzione a uno dei maggiori e più conosciuti Application Server di tipo open source: JBOSS. In particolare, questo materiale è utilizzato come supporto didattico dagli studenti del corso di Progettazione del Software 2, tenuto dall Ing. Massimo Mecella nei corsi di Laurea Specialistica in Ingegneria Informatica e in Ingegneria Gestionale di SAPIENZA Università di Roma, per l anno accademico 2006/2007 e 2007/2008.

8 Capitolo 1 RMI 1.1 Dalle RPC a RMI (Object Broker) Uno dei requisiti fondamentali per implementare un sistema distribuito è disporre di un sistema di comunicazione fra macchine diverse, basato su standard e protocolli prestabiliti. In Java la gestione dei socket è un compito relativamente semplice, tanto che si possono realizzare in maniera veloce sistemi di comunicazione con i quali scambiare informazioni in rete o controllare sistemi remoti. L implementazione di una connessione via socket risolve però solo il problema di fondo (come instaurare la connessione) ma lascia in sospeso tutta la parte di definizione delle modalità di invocazione e dei vari protocolli per lo scambio delle informazioni. Prima dell introduzione di RMI, erano già disponibili strumenti per l esecuzione di codice remoto, basti pensare alla Remote Procedure Call (RPC). Con questa tecnologia è possibile gestire procedure facenti parte di applicazioni remote rispetto al chiamante. Le RPC furono introdotte all inizio degli anni Ottanta e divennero immediatamente la base per costruire sistemi 2-tier, i quali ereditarono molte delle notazioni e delle assunzioni usate a partire dalle RPC. In particolare, le RPC stabilirono la nozione di client (il programma che chiama una procedura remota) e di server (il programma che implementa la chiamata di procedura remota che viene invocata), nonchè il concetto di Interface Definition Language (IDL). La forza delle RPC era il fatto che esse si basavano su un concetto che i programmatori di quel tempo conoscevano molto bene: la procedura. Le RPC resero possibile cominciare a costruire applicazioni distribuite senza dover cambiare il linguaggio o il paradigma di programmazione. Molti sono i vantaggi derivanti dall adozione di tale modello: un sensibile miglioramento delle prestazioni complessive, una maggiore semplicità nella gestione delle risorse distribuite, e un sostanziale incremento delle 7

9 1.1 Dalle RPC a RMI (Object Broker) 8 potenzialità operative. Ad esempio si può pensare di suddividere un processo computazionalmente pesante in subroutine più piccole ed eseguire tali pezzi di applicazione su macchine diverse ottenendo una drastica diminuzione del tempo complessivo di esecuzione. Nel caso in cui invece l efficienza non sia l obiettivo principale, si può comunque trarre vantaggio da una organizzazione distribuita, potendo gestire meglio e più semplicemente le varie risorse localizzate nei differenti spazi di indirizzamento. Si pensi per esempio a una strutturazione a tre livelli (3-Tier) per la gestione di database relazionali in Internet: dal punto di vista del client ci si deve preoccupare esclusivamente dell interfacciamento con l utente e dello scambio con il server remoto delle informazioni contenute nel database. Un altro importante scenario in cui è utile l utilizzo del modello distribuito è quello in cui si debbano realizzare applicazioni che si interfacciano con codice legacy: in tal caso si può pensare di inglobare gli applicativi esistenti (legacy appunto) in oggetti remoti e pilotarne in tal modo le funzionalità da un client. Tutto ciò che veniva richiesto a un programma per diventare un componente di un sistema distribuito era di essere compilato e collegato con il corretto set di librerie RPC. Lo sviluppo di una applicazione distribuita con le RPC è basato su una metodologia ben definita. Assumiamo di voler sviluppare un server che implementi una procedura che debba essere usata in remoto da un singolo client. Il primo passo è quello di definire l interfaccia della procedura. Questo viene fatto con un IDL, che fornisce una rappresentazione astratta della procedura in termini di quali parametri essa prende in ingresso e quali parametri restituisce. Tale descrizione IDL può essere considerata la specifica dei servizi offerti dal server. Una volta ottenuta la descrizione IDL si può procedere nello sviluppo del client e del server. Il secondo passo consiste nel compilare la descrizione IDL. Ogni implementazione delle RPC e ogni middleware che utilizza le RPC fornisce un compilatore di interfaccia. Osservando la Figura 1.1 possiamo osservare che la compilazione di una interfaccia IDL produce: Client Stub: lo stub è un pezzo di codice da compilare e collegare con il client. Quando il client chiama una procedura remota, la chiamata che viene realmente eseguita è una chiamata locale alla procedura fornita dallo stub. Lo stub allora si preoccupa di localizzare il server, formattare i dati in modo opportuno (il che implica marshaling e serializzazione 1, comunicare con il server, ottenere una risposta, e inoltrare tale risposta come parametro di ritorno della procedura invocata dal 1 il marshaling è l operazione di trasformazione dei dati in un formato intermedio sul quale i diversi processi remoti si sono accordati o che è stato stabilito in una specifica rilasciata da un consorzio internazionale (vedi XDR). Infatti, i vari processi remoti possono girare eventualmente su differenti piattaforme. In questo modo il messaggio può essere compreso da ogni ricevente; la serializzazione consiste nel trasformare il messaggio e i suoi

10 1.1 Dalle RPC a RMI (Object Broker) 9 codice client processo client interfaccia nel linguaggio client client stub ambiente di sviluppo IDL sorgenti IDL compilatore IDL processo server interfaccia nel linguaggio server server stub codice server moduli di supporto Figura 1.1: Sviluppo di applicazioni distribuite con RPC client. In altre parole, lo stub è un proxy per la reale procedura implementata al server. Lo stub fa apparire la procedura come una normale procedura locale (dal momento che è una parte di codice del client). Lo stub, comunque, non implementa la procedura, ma tutti i meccanismi necessari a interagire con il server remoto, allo scopo di eseguire quella particolare procedura. Server Stub: la natura del server stub è simile a quella del client stub eccetto che per il fatto che esso implementa il lato server dell invocazione. Esso cioè contiene il codice per ricevere l invocazione dal client stub, formattare i dati in modo opportuno (in modo speculare rispetto al client stub, comporta deserializzazione e unmarshaling), invocare la reale procedura implementata nel server, e inoltrare i valori di ritorno della procedura al client stub. Così come il client stub, anche il server stub deve essere compilato e collegato con il codice del server. Le RPC hanno visto il massimo del loro successo nei sistemi Unix e sono strettamente legate al concetto di processo, ma male si inseriscono nel contesto del paradigma basato sugli oggetti. È questo il motivo principale alla base dell esigenza di una tecnologia apposita, come RMI, per la gestione di oggetti distribuiti. La Remote Method Invocation (RMI) consente di complessi parametri in una stringa di byte prima di mandare il messaggio in un canale di comunicazione

11 1.2 La serializzazione e la trasmissione degli oggetti 10 realizzare applicazioni distribuite in cui un programma A è in grado di invocare i metodi di un oggetto B in esecuzione su un computer remoto. In realtà il panorama della progettazione e gestione di oggetti distribuiti offre valide alternative, come ad esempio CORBA: la scelta può ricadere su RMI nel caso in cui si voglia implementare, in maniera semplice e veloce, una struttura a oggetti distribuiti full-java (sia il lato client che quello server devono essere realizzati obbligatoriamente utilizzando tale linguaggio). 1.2 La serializzazione e la trasmissione degli oggetti Il meccanismo base utilizzato da RMI per la trasmissione dei dati fra client e server è quello della serializzazione: è quindi sicuramente utile soffermarsi su questo importante sistema di trasmissione prima di affrontare nello specifico la Remote Method Invocation. Grazie all estrema semplicità con la quale essa permette il flusso di dati complessi all interno di uno stream, la serializzazione spesso viene utilizzata anche indipendentemente da applicazioni RMI, e quindi quanto verrà qui detto resta di utilità generale. L obiettivo principale della serializzazione è permettere la trasformazione in modo semplice di oggetti e strutture di oggetti in sequenze di byte manipolabili con i vari stream del package java.io. Ad esempio, grazie alla serializzazione è possibile inviare strutture dati di complessità arbitraria tramite un socket (utilizzando gli stream associati al socket stesso), oppure salvarli su file al fine di mantenere la persistenza. La scrittura su stream avviene mediante il metodo writeobject() appartenente alla classe ObjectOutputStream. Ad esempio, volendo salvare su file un istanza di una ipotetica classe Record, si potrebbe scrivere: Record record = new Record(); FileOutputStream fos = new FileOutputStream("data.ser"); ObjectOutputStream oos = new ObjectOutputStream(fos); oos.writeobject(record); dove si è salvato su file binario (data.ser) un oggetto di tipo Record. L operazione, in questo caso, è stata fatta in due fasi: creazione di uno stream di serializzazione prima, e associazione di tale stream a un comune FileOutput- Stream. In modo altrettanto semplice si può effettuare l operazione opposta che permette la trasformazione da stream a oggetto: FileInputStream fis = new FileInputStream("data.ser"); ObjectInputStream ois = new ObjectInputStream(fis);

12 1.2 La serializzazione e la trasmissione degli oggetti 11 public class Record implements Serializable private String firstname; private String lastname; private int phone; public Record (String firstname,string lastname,int phone) this.firstname = firstname; this.lastname = lastname; this.phone = phone; Listato 1.1: Uso dell interfaccia Serializable record = (Record)ois.readObject(); ois.close(); In questo caso si utilizza la classe ObjectInputStream e il metodo readobject(), il quale restituisce un oggetto di tipo Object, rendendo necessaria una operazione di conversione (cast esplicito). In entrambi i casi le operazioni di lettura e scrittura devono essere inserite in appositi blocchi try-catch al fine di prevenire possibili problemi di lettura scrittura o di conversione. Per poter serializzare un oggetto, un gruppo di oggetti, una struttura di complessità arbitraria, si utilizza sempre la medesima procedura e non ci sono particolari differenze di cui tener conto, a patto che l oggetto sia serializzabile: per rispettare questo vincolo, un oggetto deve implementare l interfaccia Serializable. L interfaccia Serializable è vuota e non definisce alcun metodo; il suo scopo è esclusivamente quello di dichiarare la possibilità per l oggetto di essere serializzato. Per questo, ad esempio, l oggetto Record visto nell esempio di cui sopra potrebbe essere definito come nel Listato 1.1. La regola della serializzazione è ricorsiva, per cui un oggetto, per essere serializzabile, deve contenere esclusivamente riferimenti a oggetti serializzabili. La maggior parte delle classi contenute all interno del JDK è serializzabile, fatta eccezione per alcuni casi particolari: non sono serializzabili tutte le classi che inglobano al loro interno strutture dati binarie dipendenti dalla piattaforma, come ad esempio molti degli oggetti dell API JDBC. In questo caso infatti i vari oggetti contengono al loro interno puntatori a strutture dati o codice nativo utilizzato per la comunicazione con lo strato driver del database. Per sapere se un dato oggetto sia serializzabile o meno si può utilizzare il tool Serial Version Inspector (comando serialver), messo a disposizione dal JDK, passando ad esso il nome completo della classe da analizzare. Ad esempio,

13 1.2 La serializzazione e la trasmissione degli oggetti 12 per verificare che la classe java.lang.string sia serializzabile si può scrivere da linea di comando la seguente istruzione: serialver java.lang.string che restituisce il serialversionuid dell oggetto: java.lang.string: static final long serialversionuid = L; Invece tramite: serialver -show si manda in esecuzione la versione con interfaccia grafica di tale strumento (Figura 1.2). Figura 1.2: Versione grafica Benché il suo utilizzo sia relativamente semplice, la serializzazione nasconde alcuni aspetti importanti relativamente alla trasmissione degli oggetti. Per quanto visto finora si potrebbe immaginare che la serializzazione permetta la trasmissione di oggetti per mezzo di stream: in realtà questa concezione è quanto mai errata, dato che a spostarsi sono solamente le informazioni che caratterizzano un istanza di un particolare oggetto. Ad esempio, durante la trasmissione in un socket l oggetto non viene mai spostato fisicamente, ma ne viene inviata solo la sua rappresentazione e, successivamente, viene ricreata una copia identica dall altra parte del socket: al momento della creazione di questa copia, il runtime creerà un oggetto nuovo, riempiendo i suoi dati con quelli ricevuti dal client. Risulta ovvio quindi che, al fine di consentire questo spostamento virtuale, su entrambi i lati, sia server che client, debba essere presente il codice relativo all oggetto: il runtime quindi deve poter disporre dei file.class necessari per istanziare l oggetto, o deve poterli reperire in qualche modo. Il serialversionuid della classe serve proprio per identificare di quale tipo di oggetto siano i dati prelevati dallo stream. Si tenga presente che nella trasmissione delle informazioni relative all oggetto sono inviati solamente quei dati realmente significativi della particolare istanza. Per questo

14 1.3 Architettura RMI 13 non vengono inviati i metodi (che non cambiano mai), le costanti, le variabili con specificatore static, che formalmente sono associate alla classe e non alla istanza, e quelle identificate con la parola chiave transient. Tale keyword qualifica una variabile non persistente, ovvero una variabile il cui valore non verrà inviato nello stream durante la serializzazione. Il valore assunto da una variabile di questo tipo dipende da come essa è stata definita. Ad esempio, supponendo di scrivere: transient Integer Int = new Integer(10); al momento della deserializzazione, alla variabile Int verrà impostato il valore 10. Se invece si fosse scritto: transient Integer Int; durante la fase di deserializzazione, Int assumerebbe il proprio valore di default che per tutte le variabili di tipo reference è null, mentre per i tipi primitivi corrisponde al valore base (0 per gli int, false per i boolean, 0.0 per i float e così via). Riconsiderando l esempio visto in precedenza, la classe Record viene serializzata e deserializzata su uno stream. In questo caso, il processo di trasformazione da oggetto a sequenza di byte è effettuato utilizzando le procedure standard di conversione della JVM. Anche gli oggetti contenuti all interno di Record sono trasformati in modo ricorsivo, utilizzando le medesime tecniche. 1.3 Architettura RMI In Figura 1.3 è riportata la struttura tipica di una applicazione RMI: è possibile notare come essa sia organizzata orizzontalmente in strati sovrapposti, e in due moduli verticali paralleli fra loro. Questa suddivisione verticale vede da una parte il lato client, e dall altra il server: il primo è quello che contiene l applicazione che richiede il servizio di un oggetto remoto, che a sua volta diviene il servente del servizio RMI. Lo strato più alto del grafico è costituito su entrambi i lati (client e server) da una applicazione eseguita sulla Java Virtual Machine in esecuzione su quel lato: nel caso del client si tratta di una applicazione che effettua le chiamate ai metodi di oggetti remoti, i quali poi sono eseguiti dall applicazione remota. Questa ha quindi un ciclo di vita indipendente dal client che di fatto ignora la sua presenza. Subito sotto il livello applicazione troviamo i due elementi fondamentali dell architettura RMI, ovvero lo stub e lo skeleton. Questi due oggetti forniscono una duplice rappresentazione dell oggetto remoto: lo stub rappresenta una simulazione locale sul client dell oggetto remoto che però, grazie

15 1.3 Architettura RMI 14 allo skeleton, vive e viene eseguito sul lato server; i due elementi quindi non sono utilizzabili separatamente. Da un punto di vista funzionale, il client, Figura 1.3: Architettura RMI dopo aver ottenuto un reference dell oggetto remoto (lo stub di tale oggetto), ne esegue i metodi messi a disposizione per l invocazione remota, in modo del tutto analogo al caso in cui l oggetto sia locale. Si può quindi scrivere: OggettoRemoto.nomeMetodo(); Da un punto di vista sintattico non vi è quindi nessuna differenza fra un oggetto locale e uno remoto. In conclusione il client (intendendo sia il programma che il programmatore della applicazione lato client) non ha che in minima parte la percezione di utilizzare un oggetto remoto. Uno dei grossi vantaggi nell utilizzo di RMI consiste nella semplicità con cui si possono passare parametri durante l invocazione dei metodi remoti e riceverne indietro i risultati; senza nessuna differenza rispetto al caso locale si può scrivere: Ris = OggettoRemoto.nomeMetodo(param_1,..., param_n); Riconsiderando lo schema riportato nella figura 1.3, si ha che i vari parametri vengono serializzati dalla virtual machine del client, inviati sotto forma di stream al server, il quale li utilizzerà in forma deserializzata per utilizzarli all interno del corpo del metodo invocato. Anche il durante percorso inverso, ovvero quello che restituisce un risultato al client, viene effettuata una serializzazione e quindi una deserializzazione dei dati.

16 1.3 Architettura RMI 15 Il procedimento, che da un punto di vista teorico risulta essere piuttosto complesso, è molto semplice da utilizzare. L unico vincolo di cui si deve tener conto è che i parametri passati e il risultato ricevuto siano oggetti serializzabili, cioè devono implementare l interfaccia Serializable. Il lato server e client sono collegati col sottostante Remote Reference Layer (RRL) che a sua volta si appoggia al Transport Layer (TL). Il primo dei due ha il compito di instaurare un collegamento logico fra i due lati, di codificare le richieste del client, inviarle al server, decodificare le richieste e inoltrarle allo skeleton. Ovviamente nel caso in cui quest ultimo fornisca dei risultati per il particolare tipo di servizio richiesto, il meccanismo di restituzione di tali valori avviene in maniera del tutto simile ma in senso opposto. Al livello RRL viene instaurato un collegamento virtuale fra i due lati client e server, mentre fisicamente la connessione avviene al livello sottostante, il Transport Layer. Tale collegamento è di tipo sequenziale ed è per questo che si richiede la serializzazione dei parametri da passare ai metodi. Il collegamento virtuale dello strato RRL si basa su un protocollo di comunicazione generico e indipendente dal particolare tipo di stub o skeleton utilizzati: questa genericità permette di mantenere la massima indipendenza dal livello stub/skeleton, tanto che è possibile sostituire il RRL con versioni successive più ottimizzate. Il protocollo di conversione delle invocazioni dei metodi, l impacchettamento dei riferimenti ai vari oggetti, e tutto quello che concerne la gestione a basso livello sono operazioni a carico sia dello strato RRL, sia e soprattutto dal TL, in cui si perde la concezione di oggetto remoto e/o locale e i dati vengono semplicemente visti come sequenze di byte da inviare o leggere verso certi indirizzi di memoria. Quando il TL riceve una richiesta di connessione da parte del client, localizza il server RMI relativo all oggetto remoto richiesto: successivamente viene eseguita una connessione per mezzo di un socket appositamente creato per il servizio. Si tenga presente che, quando un client vuole chiamare un metodo, serializza i parametri e li invia sul canale. Il server deserializza i parametri ricevuti con l invocazione e ricostruisce una copia locale dell oggetto. Proprio per questo meccanismo, l oggetto lato client e la sua copialato server sono indipendenti. Quindi una modifica sullo stato interno (ad esempio, le variabili di istanza) di uno dei due non si ripercuote sull altro. In questo contesto, particolarmente importante è la presenza di un garbage collector apposito per RMI, il quale provvede in modo automatico e trasparente a eseguire le opportune operazioni di ripulitura delle aree di memoria non più utilizzate. Per ogni oggetto RMI remoto, il reference layer del server mantiene la lista dei riferimenti remoti che sono registrati dai client. Ogni riferimento remoto di ogni client è stato ottenuto esplicitamente attraverso una lookup o implicitamente come risultato dell invocazione di un metodo remoto. Il client

17 1.4 Uso di RMI 16 mantiene questi riferimenti nel suo Reference Layer. Quando la Java Virtual Machine del client si accorge che un oggetto remoto non è più referenziato localmente, questa notifica in modo asincrono al server RMI l evento unreferenced cosicchè il server può aggiornare la lista dei riferimenti. Quando un oggetto RMI non ha più riferimenti remoti nella lista, la possibilità di tale oggetto di essere garbage collected è basata solamente sull esistenza di riferimenti locali, come ogni altro oggetto java. Il distributed garbage collector associa ad ogni riferimento remoto un lease, cioè una sorta di timeout che può scadere. Quando il lease scade, il riferimento è eliminato dalla lista e viene inviato una richiesta di lease renew al reference layer del client che utilizzava tale riferimento. In questo modo al client viene notificato che il riferimento remoto è scaduto. A questo punto il client notifica al server RMI di mantenere ancora il riferimento remoto nella lista perchè valido. L obiettivo del meccanismo di lease renewal è di permettere al server di accorgersi della terminazione anormale dei client e quindi di eliminare i riferimenti remoti non utili. Infatti, se non si facesse uso dei lease, un client andato in crash non manderebbe mai il messaggio appropriato di unreferenced prima di terminare l esecuzione. In questo contesto, un client che invoca una System.exit() è considerato terminato in maniere anormale perchè tale operazione non permette al reference layer del client di mandare l appropriato messaggio unreferenced al server. L ultimo livello che però non viene incluso nella struttura RMI, è quello che riguarda la gestione della connessione al livello di socket e protocolli TCP/IP. Questo aspetto segue le specifiche standard di networking di Java e non offre particolari interessanti in ottica RMI. 1.4 Uso di RMI Si può ora procedere ad analizzare quali siano i passi necessari per realizzare una applicazione RMI. Tutte le classi e i metodi che si analizzeranno e, in generale, tutte le API necessarie per lavorare con RMI sono contenute nei package java.rmi e java.rmi.server. Anche se, dal punto di vista della programmazione a oggetti, sarebbe più corretto parlare di classi, in questo caso si parlerà genericamente di oggetti remoti e locali intendendo sia il tipo che la variabile. A tal proposito, in base alla definizione ufficiale, si definisce remoto un oggetto che implementi l interfaccia Remote e i cui metodi possano essere eseguiti da una applicazione client non residente sulla stessa macchina virtuale. Un interfaccia remota invece rende disponibile il set di metodi utilizzabili

18 1.4 Uso di RMI 17 per l invocazione a distanza; ovviamente non è necessario definire nell interfaccia quei metodi a solo uso interno della classe. Si immagini quindi di definire MyServer un oggetto per il momento non remoto: public class MyServer public void String concat(string a, String b) return a + b; Il metodo concat() in questo caso esegue una concatenazione fra i due argomenti passati in input restituendo in uscita la stringa risultante. A parte il vincolo della serializzabilità dei parametri, non ci sono limiti alla complessità delle operazioni eseguibili all interno di metodi remoti. Dopo aver definito questa semplice classe, per trasformarla nella versione remota si deve per prima cosa definire la sua interfaccia remota: public interface MyServerInterface extends Remote public String concat(string a, String b) throws RemoteException; Come si può osservare da queste poche righe di codice, per definire un interfaccia remota è necessario estendere la java.rmi.remote: questa è una interfaccia vuota e serve solo per verificare durante l esecuzione che le operazioni di invocazione remota siano plausibili. Un oggetto utilizzato come parametro di input o di ritorno può implementare l interfaccia Remote invece che quella Serializable. La differenza principale tra oggetti remoti e serializzabili è che gli oggetti remoti sono inviati come riferimento, mentre gli oggetti non remoti, serializzabili sono inviati come copia. Se l oggetto è serializzabile ma non remoto esso viene serializzato e inviato al processo remoto come flusso di byte. È obbligatoria la gestione dell eccezione java.rmi.remoteexception: infatti, a causa della distribuzione in rete, oltre alla gestione di eventuali problemi derivanti dalla normale esecuzione del codice (bug o incongruenze di vario tipo), si deve adesso proteggere tutta l applicazione da anomalie derivanti dall utilizzo di risorse remote: ad esempio potrebbe venire a mancare improvvisamente la connessione fisica verso l host dove è in esecuzione il server RMI. Definita l interfaccia remota si deve modificare leggermente la classe di partenza, in modo che implementi questa interfaccia, come mostrato nel Listato 1.2. Il nome della classe è stato cambiato a indicare l implementazione

19 1.4 Uso di RMI 18 public class MyServerImpl implements MyServerInterface extends UnicastRemoteObject public MyServerImpl() throws RemoteException... public String concat(string a, String b) throws RemoteException return a + b; Listato 1.2: Uso dell interfaccia MyServerInterface che estende Remote dell interfaccia remota; come si può notare, oltre a dichiarare di implementare l interfaccia precedentemente definita, si deve anche estendere la classe UnicastRemoteObject. Oltre a ciò, all oggetto è stato aggiunto un costruttore di default il quale dichiara di propagare eccezioni RemoteException: tale passaggio non ha una motivazione apparente, ma è necessario per permettere al compilatore di creare correttamente tutte le parti che compongono il lato server (stub e skeleton). La classe UnicastRemoteObject deriva dalle due classi, RemoteServer e RemoteObject: la prima è una superclasse comune per tutte le implementazioni di oggetti remoti (la parola Unicast ha importanti conseguenze come si avrà modo di vedere in seguito), mentre l altra semplicemente ridefinisce hashcode() ed equals() in modo da permettere correttamente il confronto tra oggetti remoti. L uso della classe RemoteServer permette di utilizzare implementazioni di oggetti remoti diverse da UnicastRemoteObject, anche se per il momento quest ultima è l unica supportata. L organizzazione delle più importanti classi per RMI è raffigurata in Figura 1.4. Dopo questa trasformazione, l oggetto è visibile dall esterno, ma ancora non utilizzabile secondo la logica RMI: si devono infatti creare i cosiddetti stub e skeleton. Tali oggetti sono ottenibili in maniera molto semplice per mezzo del compilatore rmic, disponibile all interno del JDK 1.1 e successivi: partendo dal bytecode ottenuto dopo la compilazione dell oggetto remoto, questo tool produce stub e skeleton. Ad esempio, riconsiderando il caso della

20 1.4 Uso di RMI 19 Figura 1.4: Struttura gerarchica delle principali classi e interfacce RMI classe MyServerImpl, con una operazione del tipo: rmic MyServerImpl si ottengono i due file MyServerImpl stub.class e MyServerImpl skel.class. A questo punto si hanno a disposizione tutti i componenti per utilizzare l oggetto remoto MyServerImpl: resta quindi da rendere possibile il collegamento tra client e server per l invocazione remota. Si definisce server RMI l applicazione che istanzia un oggetto remoto e lo registra tramite una bind all interno dell RMI registry. Il server RMI non è quindi l oggetto che implementa la business logic, ma solamente una applicazione di servizio necessaria per attivare il meccanismo di invocazione remota. Sul lato server, l applicazione che gestisce lo skeleton deve notificare di possedere al suo interno un oggetto abilitato all invocazione remota. Per far questo è necessario utilizzare il metodo statico java.rmi.naming.bind() che associa all istanza dell oggetto remoto un nome logico con cui tale oggetto può essere identificato in rete. Quindi, dopo aver creato una istanza dell oggetto remoto tramite: MyServerImpl server = new MyServerImpl(); si provvede a effettuarne la registrazione utilizzando un nome simbolico:

21 1.4 Uso di RMI 20 import java.rmi.*; import java.rmi.server.*; public class Registration public static void main(string args[]) try MyServerImpl server =new MyServerImpl(); Naming.bind("Paperino", server); catch (Exception e) System.out.println("Implerr: " + e.getmessage()); e.printstacktrace(); Listato 1.3: Registrazione dell oggetto remoto Naming.bind("Paperino", server); Questa operazione, detta registrazione, può fallire e in tal caso viene generata una eccezione in funzione del tipo di errore. In particolare si otterrà una AlreadyBoundException nel caso in cui il nome logico sia già stato utilizzato per un altra associazione, una MalformedURLException per errori nella sintassi dell URL, mentre il runtime produrrà RemoteException per tutti gli altri tipi di errore legati alla gestione da remoto dell oggetto. Ogni associazione nome logico - oggetto remoto è memorizzata in un apposito registro detto RMI registry. In questo caso rmiregistry è anche il comando che lancia l applicazione per gestire tale archivio, applicazione che deve essere lanciata sul lato server prima di ogni bind. Una volta che l RMI registry è attivo, è possibile registrare l oggetto. Il codice completo per registrare l oggetto è mostrato nel Listato 1.3. Il client a questo punto è in grado di ottenere un reference all oggetto con una ricerca presso l host remoto utilizzando il nome logico con cui l oggetto è stato registrato. Ad esempio si potrebbe scrivere: MyServerInterface server; String url = "//" + serverhost + "/MyServer"; server = (MyServerInterface) Naming.lookup(url);

22 1.4 Uso di RMI 21 e quindi utilizzare il reference per effettuare le invocazioni ai metodi remoti: System.out.println(server.concat("Hello ", "world!")); Sul client per ottenere il reference si utilizza il metodo statico Naming.lookup(), che può essere considerato il corrispettivo alla operazione di bind sul server. L URL passato come parametro al lookup() identifica il nome della macchina che ospita l oggetto remoto e il nome con cui l oggetto è stato registrato. Entrambe le operazioni di registrazione e di ricerca accettano come parametro un URL: il formato di tale stringa è la seguente: rmi://host:port/name dove host è il nome del server RMI, port la porta dove si mette in ascolto il registry, name il nome logico. Sul server non è necessario specificare l host, dato che per default assume l indirizzo della macchina stessa sulla quale l applicazione server RMI è mandata in esecuzione. In entrambi i casi il numero della porta di default è la 1099 ma, se si specifica altrimenti, allora tale informazione dovrà essere passata al rmiregistry con il seguente comando: rmiregistry numero_porta Ogni volta che un parametro viene passato ad un metodo remoto, o viceversa, ogni volta che si preleva un oggetto come risultato di una computazione remota, si dà vita a un processo di serializzazione o deserializzazione dell oggetto in questione. In realtà, come si è potuto vedere, l oggetto serializzato non viene spostato dal client al server, ma vengono inviate nella rete solamente le informazioni necessarie per ricreare una copia dell oggetto dal client al server (e viceversa). Questo significa che sia il client che il server devono poter disporre dello stesso bytecode relativo all oggetto serializzato in modo da poterne ricreare l istanza. La soluzione più semplice è copiare fisicamente i vari file.class sia sul server che sul client: in questo caso si potrà essere sicuri che le varie operazioni di serializzazione e deserializzazione potranno essere effettuate correttamente. Lo svantaggio di questa organizzazione risiede nel dovere ridistribuire tutti i file per ogni modifica delle varie classi. In alcuni casi questa soluzione è scomoda, se non addirittura impraticabile. RMI mette a disposizione un meccanismo molto potente che consente di scaricare dalla rete, tramite un file server HTTP, i file necessari per il funzionamento del client. Per ulteriori dettagli sul loading remoto delle classi si faccia riferimento a [1]. Se si ripensa per un momento alla modalità di pubblicazione di un oggetto remoto da parte del server RMI, si potrà osservare come la funzione di creazione e registrazione sia un compito totalmente a carico del server. Per

23 1.4 Uso di RMI 22 public interface Messaggio extends Remote String gettesto() throws RemoteException; Date getdata() throws RemoteException; String getmittente() throws RemoteException; Listato 1.4: Interfaccia Messaggio una precisa scelta progettuale quindi, visto che la registrazione dell oggetto avviene una volta sola, l istanza dell oggetto remoto sarà l unica disponibile e quindi condivisa fra tutti i client possibili. Pensata per semplificare al massimo il lavoro del programmatore, in molti casi però questa soluzione risulta essere troppo rigida e non sufficiente per supportare architetture distribuite complesse. Una soluzione semplicistica potrebbe essere quella di istanziare un numero prefissato di oggetti per poter servire più client; ovviamente tale soluzione, oltre ad essere poco flessibile e per niente elegante, non risolve il problema della creazione on demand di oggetti remoti da parte del client. Questo tipo di problema, che ricade nella sfera del pooling degli oggetti, può essere risolto in RMI tramite due tecniche: una basata sull utilizzo di particolari pattern progettuali (soluzione quindi non strettamente legata a RMI, ma di valenza generale) e una basata sull utilizzo di una particolare interfaccia remota messa appositamente a disposizione per risolvere questo problema. Il framework EJB che, per certi versi, può essere considerato come l evoluzione di RMI nasce per risolvere una serie di problemi presenti nei modelli di programmazione distribuita come RMI, ma anche CORBA. Infatti in EJB il problema del pooling degli oggetti viene risolto in modo molto potente ed elegante, demandando al container la gestione del numero degli oggetti remoti in esecuzione in base alle esigenze di sistema e alle richieste dei vari client. Il problema del pooling di oggetti può essere risolto utilizzando una tecnica introdotta in RMI ad hoc, basata su Java Activation, ma risulta essere alquanto complessa(vedi [1]). Invece, utilizzando il pattern Factory Method, si può ottenere lo stesso risultato in modo molto più semplice ed elegante. si supponga di avere una classe remota che implementi l interfaccia mostrata nel Listato 1.4. L implementazione di tale classe è mostrata nel Listato 1.5 In uno scenario reale si potrebbe ipotizzare che ogni client debba o voglia poter produrre messaggi propri, indipendentemente dagli altri, e che tali messaggi siano gestiti da un server centrale. Si noti come le proprietà siano

24 1.4 Uso di RMI 23 public class MessaggioImpl extends UnicastRemoteObject implements Messaggio String testo; Date data; String mittente; public MessaggioImpl(String unmittente,string untesto) throws RemoteException super(); data=new Date(); testo=untesto; mittente=unmittente; public String gettesto() throws RemoteException return(testo); public Date getdata() throws RemoteException return(data); public String getmittente() throws RemoteException return(mittente); Listato 1.5: Classe MessaggioImpl

25 1.4 Uso di RMI 24 import java.rmi.*; import java.util.*; public interface Factory extends Remote Messaggio creamessaggio(string sndr, String text) throws RemoteException; public class FactoryImpl extends UnicastRemoteObject implements Factory public FactoryImpl() throws RemoteException super(); public Messaggio creamessaggio(string sndr, String text) throws RemoteException MessaggioImpl unmessaggio=new MessaggioImpl(sndr,text); return (unmessaggio); Listato 1.6: Interfaccia Factory immutabili e impostate nel costruttore; si noti anche come, addirittura, la proprietà Data sia in realtà impostata automaticamente alla data attuale del Sistema. Per fare questo, si deve predisporre un meccanismo che permetta la creazione di tali oggetti anche da parte di client RMI. La classe MessaggioFactory che implementa il pattern Factory, è a tutti gli effetti un oggetto remoto come quelli visti in precedenza: tramite la sua registrazione, ogni client potrà ottenerne lo stub e invocarne il metodo remoto getlogger(), la cui implementazione è riportata di seguito, nel Listato 1.6: Il client che vuole creare una nuova instanza della classe MessaggioImpl (che implementa l interfaccia Messaggio) deve semplicemente chiamare il metodo creamessaggio

26 1.5 Esempio: Sender e Receiver 25 public class Application public static void main(string args[]) String sndr=... String text=... Factory fact= (Factory)Naming.lookup(...); Messaggio mex = fact.creamessaggio(sndr,text);... Listato 1.7: Classe Application (vedi Listato 1.7). La chiamata al metodo Factory creamessaggio in realtà non fa nient altro che creare un nuovo oggetto Messaggio e restituirne un riferimento remoto al client richiedente. Tale messaggio avrà per le proprietà Mittente e Testo i valori passati al metodo Factory e la proprietà Data impostato con la data del server (e non quella del client). Il client invocando il metodo remoto creamessaggio() riceverà lo stub dell oggetto remoto, il quale verrà eseguito sul server remoto, in perfetto accordo con il modello teorico di RMI. L utilizzo del pattern Factory risolve in maniera piuttosto agile alcune delle limitazioni imposte dal modello RMI: con tale tecnica infatti è possibile attivare oggetti al momento della effettiva necessità su richiesta del client ed in modo esclusivo. 1.5 Esempio: Sender e Receiver Vediamo ora un esempio pratico di quanto detto finora. In questo esempio si vuole gestire una applicazione client/server per fornire un servizio di pubblicazione/lettura di messaggi di testo. L interfaccia del servizio può essere definita con l interfaccia Archivio che estende a sua volta l interfaccia Java Remote(Listato 1.8). Tale interfaccia definisce l interfaccia del servizio, espressa in linguaggio Java e quindi corrisponde all IDL del servizio. In Archivio vengono dichiarati due metodi, send e receive, che devono essere definiti nella classe ArchivioImpl(implementazione del servizio), come mostrato nel Listato 1.8. Questa classe estende UnicastRemoteObject e implementa Archivio. Per gestire la lista dei messaggi, viene utilizzato un oggetto (coda) di tipo ArrayList. Il costruttore deve per prima cosa chiamare la superclasse. I due metodi, send e receive, utilizzano la variabile x come semaforo (syn-

27 1.5 Esempio: Sender e Receiver 26 import java.rmi.*; public interface Archivio extends Remote void send(string mex) throws RemoteException; String receive() throws RemoteException; Listato 1.8: Definizione dell interfaccia Archivio chronized), consentono di accedere alla lista (sia in lettura che in scrittura) in modo consistente, evitando situazioni ambigue. Qualsiasi situazione di accesso concorrente (due letture, due scritture, una lettura e una scrittura) potrebbero generare situazioni non desiderate, come la perdita di messaggi. Grazie all istruzione synchronized(x), se un client sta pubblicando o leggendo un messaggio, un altro client che vuole a sua volta leggere o pubblicarne uno deve attendere che il primo client abbia terminato l operazione per poterne cominciare una. Il client si implementa con due classi, la classe Sender e la classe Receiver. Queste sono mostrate rispettivamente nel Listato 1.11 e nel Listato Nelle classi Sender e Receiver viene passato come parametro la stringa args[0] che è il nome oppure l indirizzo IP del server che fornisce il servizio. La stringa args[1] utilizzata nella classe Sender è invece il messaggio che si vuole inserire in coda. RMI non fornisce alcun meccanismo di serializzazione delle invocazioni dei metodi remoti. La serializzazione deve essere realizzata dal programmatore mediante l uso di codice opportuno (ad esempio, i blocchi synchronized). Questa limitazione è stata superata dalla naturale evoluzione di RMI, cioè gli EJB.

28 1.5 Esempio: Sender e Receiver 27 import java.rmi.server.*; public class ArchivioImpl extends UnicastRemoteObject implements Archivio ArrayList coda; String x=""; public ArchivioImpl() throws RemoteException super(); coda=new ArrayList(); public void send(string messaggio) throws RemoteException synchronized(x) coda.add(messaggio); public String receive() throws RemoteException if (coda.isempty()) return(null); synchronized(x) try String messaggio=(string)coda.get(0); coda.remove(0); return(messaggio); catch(nosuchelementexception err) return(null); Listato 1.9: Implementazione del servizio definito dall Interfaccia Archivio

29 1.5 Esempio: Sender e Receiver 28 import java.rmi.*; import java.rmi.server.*; public class ArchivioServer public static void main(string args[]) try ArchivioImpl obj=new ArchivioImpl(); Naming.rebind("Coda", obj); catch (Exception e) System.out.println("Implerr: " + e.getmessage()); e.printstacktrace(); Listato 1.10: Codice per la registrazione dell oggetto nell RMI Registry import java.rmi.*; public class Sender public static void main(string args[]) throws Exception if (args.length==0) System.out.println("Nessun messaggio da inviare"); return; Archivio obj= (Archivio)Naming.lookup("//"+args[0]+"/Coda"); obj.send(args[1]); Listato 1.11: Classe Sender

30 1.5 Esempio: Sender e Receiver 29 import java.rmi.*; public class Receiver public static void main(string args[]) throws Exception Archivio obj= (Archivio)Naming.lookup("//"+args[0]+"/Coda"); String messaggio=obj.receive(); if (messaggio==null) System.out.println("Nessun messaggio in coda!"); else System.out.println(messaggio); Listato 1.12: Classe Receiver

31 Capitolo 2 Swing Uno dei problemi più grossi emersi durante la progettazione di Java fu senza dubbio la realizzazione di un toolkit grafico capace di funzionare con prestazioni di buon livello su piattaforme molto differenti tra loro. La soluzione adottata nel 1996 fu AWT(Abstract Window Toolkit), un package grafico che mappa i componenti del sistema ospite con apposite classi dette peer, scritte in gran parte in codice nativo. In pratica, ogni volta che il programmatore crea un componente AWT e lo inserisce in un interfaccia grafica, il sistema AWT posiziona sullo schermo un oggetto grafico della piattaforma ospite, e si occupa di inoltrare ad esso tutte le chiamate a metodo effettuate sull oggetto Java corrispondente, ricorrendo a procedure scritte in buona parte in codice nativo; nel contempo, ogni volta che l utente manipola un elemento dell interfaccia grafica, un apposita routine (scritta sempre in codice nativo) crea un apposito oggetto Event e lo inoltra al corrispondente oggetto Java, in modo da permettere al programmatore di gestire il dialogo con il componente e le azioni dell utente con una sintassi completamente Object Oriented e indipendente dal sistema sottostante. A causa di questa scelta progettuale, il set di componenti grafici AWT comprende solamente quel limitato insieme di controlli grafici che costituiscono il minimo comune denominatore tra tutti i sistemi a finestre esistenti: un grosso limite rispetto alle reali esigenze dei programmatori. In secondo luogo, questa architettura presenta un grave inconveniente: i programmi grafici AWT assumono un aspetto ed un comportamento differente a seconda della JVM su cui vengono eseguite, a causa delle macroscopiche differenze implementative esistenti tra le versioni di uno stesso componente presenti nelle diverse piattaforme. Spesso le interfacce grafiche realizzate su una particolare piattaforma mostrano grossi difetti se eseguite su un sistema differente, arrivando in casi estremi a risultare inutilizzabili. Il motto della Sun per Java era scrivi (il codice) una volta sola ed eseguilo 30

32 2.1 Il package Swing 31 Component Container JComponent Window JFrame JDialog JPanel JApplet java.awt javax.swing Figura 2.1: Diagramma UML di base del package Swing. ovunque ; nel caso di AWT questo si era trasformato in scrivi una volta sola e correggilo ovunque. 2.1 Il package Swing Nel 1998, con l uscita del JDK 1.2, venne introdotto il package Swing, i cui componenti erano stati realizzati completamente in Java, ricorrendo unicamente alle primitive di disegno più semplici, tipo traccia una linea o disegna un cerchio, accessibili attraverso i metodi dell oggetto Graphics, un oggetto AWT utilizzato dai componenti Swing per interfacciarsi con la piattaforma ospite. Le primitive di disegno sono le stesse su tutti i sistemi grafici, e il loro utilizzo non presenta sorprese: il codice java che disegna un pulsante Swing sullo schermo di un PC produrrà lo stesso identico risultato su un Mac o su un sistema Linux. Questa architettura risolve alla radice i problemi di uniformità visuale, visto che la stessa identica libreria viene ora utilizzata, senza alcuna modifca, su qualunque JVM. Liberi dal vincolo del minimo comune denominatore, i progettisti di Swing hanno scelto di percorrere la via opposta, creando un package ricco di componenti e funzionalità spesso non presenti nella piattaforma ospite. Il procedimento di disegno è ovviamente più lento perché la JVM deve disegnare per proprio conto tutte le linee degli oggetti grafici e gestirne direttamente il comportamento, però è più coerente. Le classi Swing sono definite nel pacchetto javax.swing, il cui nome javax

33 2.2 Top Level Container 32 indica estensione standard a Java. Inizialmente Swing venne rilasciato, infatti, come estensione per poi divenire un omponente standad di Java 2. Per motivi di compatibilita il nome del pacchetto javax non venne corretto in java. Gli oggetti grafici Swing derivano dai corrispettivi AWT; quindi è possibile utilizzare oggetti Swing, ove erano previsti i oggetti antenati. Swing usa ancora alcuni elementi AWT per disegnare; anche la gestione degli eventi è fatta per la maggior parte da classi AWT. La Figura 2.1 riassume molto sinteticamente le classi base del package Swing e come queste derivino da classi AWT. Ogni oggetto grafico (una finestra, un bottone, un campo di testo,... ) è implementato come classe del package javax.swing. Ogni classe che identifica un oggetto Swing deriva per lo più dalla classe javax.swing.jcomponent; si stima che esistono circa 70 o più oggetti diversi. Gli oggetti grafici utilizzati per disegnare le interfacce vengono chiamati anche controlli oppure tecnicamente widget. JComponent eredita da java.awt.container, una sorta di controllo che di default è vuoto e il cui scopo è offrire la possibilità di disporre altri componenti all interno. Non a caso la classe AWT Window e le sottoclassi Swing JFrame e JDialog, le cui istanze rappresentano finestre, sono sottoclasse di Container. La cosa più sorprendente è che, siccome JComponent deriva da Container, è possibile inserire all interno di un qualsiasi widget qualsiasi altro. Ad esempio - sebbene poco utile - è possibile aggiungere un campo di testo all interno di un bottone oppure - molto usato - un Container all interno di un altro Container. La classe Container (e ogni sottoclasse) definisce un metodo per aggiungere un controllo ad un Container: void add(component); Il metodo prende come parametro un oggetto Component che è la superclasse di qualsiasi oggetto o container Swing o AWT. 2.2 Top Level Container I top level container sono i componenti all interno dei quali si creano le interfacce grafiche: ogni programma grafico ne possiede almeno uno, di solito un JFrame, che rappresenta la finestra principale. Ogni top level container possiede un pannello (accessibile tramite il metodo getcontentpane()) all interno del quale vanno disposti i controlli dell interfaccia grafca. Esistono tre tipi principali di top level Container: JFrame, JApplet e JDialog. Il primo viene solitamente usato come finestra principale per il programma, il secondo è utilizzato per costruire Applet da visualizzare nella finestra di un web browser mentre il terzo serve a creare le finestre di dialogo con l utente.

34 2.2 Top Level Container Uso di JFrame Un oggetto della classe JFrame può essere creato usando i costruttori: JFrame(); JFrame(String titolofinestra); Il primo costruisce un JFrame senza titolo; il secondo permette di specificarlo. È sempre possibile impostare il titolo ricorrendo al metodo settitle(string s). Due importanti proprietà dell oggetto sono la dimensione e la posizione, che possono essere impostate sia specificando le singole componenti sia mediante oggetti Dimension e Point del package AWT: public void setsize(dimension d); public void setsize(int width,int height); public void setlocation(point p); public void setlocation(int x,int y); Ricorrendo al metodo setresizable(boolean b) è possibile stabilire se si vuole permettere all utente di ridimensionare la finestra manualmente. Infine, vi sono tre metodi piuttosto importanti: public void pack(); public void setvisible(boolean b); public void setdefaultcloseoperation(int operation); Il primo ridimensiona la finestra tenendo conto delle dimensioni ottimali di ciascuno dei componenti presenti all interno. Il secondo permette di visualizzare o di nascondere la finestra. Il terzo imposta l azione da eseguire alla pressione del bottone close, con quattro impostazioni disponibili: JFrame.DO NOTHING ON CLOSE (nessun effetto), JFrame.HIDE ON CLOSE (nasconde la finestra), JFrame.DISPOSE ON CLOSE (chiude la finestra e libera le risorse di sistema) e JFrame.EXIT ON CLOSE (chiude la finestra e conclude l esecuzione del programma). Per impostazione di default, un JFrame viene costruito non visibile e di dimensione 0 x 0. Per questa ragione, affinchè la finestra sia visibile, è necessario chiamare i metodi setsize() o pack() per specificare la dimensione e mettere a true la proprietà Visible chiamando il metodo: setvisible(true). Per poter lavorare con i Frame Swing, è opportuno conoscere il linea generale la struttura della superficie. La superficie di un frame Swing è coperta da quattro lastre: Glass Pane La lastra di vetro è nascosta di default ed ha il compito di catturare gli eventi di input sulla finestra. Normalmente è completamente trasparente a meno che venga implementato il metodo paintcomponent

35 2.3 Paranoramica di alcuni widget 34 Figura 2.2: Anatomia di un Frame Swing. del GlassPane. Poichè è davanti a tutte le altre, qualsiasi oggetto disegnato su questa lastra nasconde qualsiasi altro disegnato sulle altre Content Pane La lastra dei contenuti è la più importante perchè è quella che ospita i componenti che volete visualizzare nella finestra e la maggior parte dei programmatori Java lavora solo su questa Layered Pane Contiene la lastra dei contenuti ed eventualmente i menu. I menu, infatti, non vengono mai aggiunti al Content Pane ma a questa lastra. Root Pane La lastra radice ospita la lastra di vetro insieme con la lastra dei contenuti e i bordi della finestra. Per maggiori dettagli si faccia riferimento a [4]. Quindi, un componente, quale un pulsante, un immagine o altro, non viene aggiunto direttamente alla finestra ma alla lastra dei contenuti. Di conseguenza, occorre per prima cosa procurarsi un riferimento all oggetto ContentPane, mediante la chiamata al metodo: public Container getcontentpane(); Come era da aspettarsi, il ContentPane è un Container perchè predisposto a contenere altri componenti. A questo punto, come per ogni altro Container, è possibile aggiungere ad esso un componente con il metodo add già descritto. A questo punto è possibile disegnare la prima finestra. Il codice descritto nel Listato 2.1 mostra la finestra in Figura Paranoramica di alcuni widget I nomi delle classi per la maggior parte dei componenti dell interfaccia utente Swing iniziano con la J.

36 2.3 Paranoramica di alcuni widget 35 import javax.swing.*; import java.awt.*; public class Application public static void main(string args[]) JFrame win; win = new JFrame("Prima finestra"); Container c = win.getcontentpane(); c.add(new JLabel("Buona Lezione")); win.setsize(200,200); win.setdefaultcloseoperation(jframe.exit_on_close); win.setvisible(true); Listato 2.1: La prima finestra Figura 2.3: La prima finestra.

37 2.3 Paranoramica di alcuni widget 36 JTextField è un campo di testo Swing. Tale classe eredita da TextField, l obsoleto analogo del package AWT. Per costruire un campo di testo occorre fornirne l ampiezza, cioè il numero approssimato di caratteri che vi aspettate verranno inseriti dall utente. JTextField xfield=new JTextField(5); Gli utenti possono digitare anche un numero maggiore di caratteri ma sempre 5 contemporaneamente saranno vicini: i 5 attorno alla posizione del cursore nel campo. Sarebbe opportuno etichettare ciascun campo di testo in modo che l utente sappia cosa scriverci. Ogni etichetta è un oggetto di tipo JLabel che viene costruito, sfruttando il costruttore con un parametro stringa; tale parametro rappresenta il testo dell etichetta: JLabel xfield=new JLabel("x = "); Figura 2.4: Alcuni Bottoni delle Swing. Inoltre vorrete dare all utente la possibilità di inserire informazione in tutti i campi di testo prima di elaborarli per cui avete bisogno di un pulsante che l utente possa premere per segnalare che i dati sono pronti per essere elaborati. Un pulsante è un oggetto JButton che può essere costruito fornendo una stringa che fungerò da etichetta, un immagine come icona o entrambe JButton movebutton=new JButton("Move"); JButton movebutton=new JButton(new ImageIcon("hand.gif")); JButton movebutton=new JButton("Move",new ImageIcon("hand.gif")); JCheckBox è una sottoclasse di JButton che crea caselle di controllo, con un aspetto simile a quello delle caselle di spunta dei questionari. Il suo funzionamento è analogo a quello della superclasse, ma di fatto tende a

38 2.3 Paranoramica di alcuni widget 37 essere utilizzato in contesti in cui si offre all utente la possibilità di scegliere una o più opzioni tra un insieme, come avviene per esempio nei pannelli di controllo. I costruttori disponibili sono gli stessi della superclasse, quindi non sarà necessario ripetere quanto è stato già detto. JCheckBox check1=new JCheckBox("JCheck"); JRadioButton è una sottoclasse di JButton, dotata dei medesimi costruttori. Questo tipo di controllo, chiamato pulsante di opzione, viene usato tipicamente per fornire all utente la possibilità di operare una scelta tra un insieme di possibilità, in contesti nei quali un opzione esclude l altra. I costruttori disponibili sono gli stessi della superclasse. Per implementare il comportamento di mutua esclusione, è necessario registrare i JRadioButton che costituiscono l insieme presso un istanza della classe ButtonGroup, come viene mostrato nelle righe seguenti: JRadioButton radiobutton1=new JRadioButton("R1"); JRadioButton radiobutton2=new JRadioButton("R2"); JRadioButton radiobutton2=new JRadioButton("R3"); ButtonGroup group = new ButtonGroup(); group.add(radiobutton1); group.add(radiobutton2); group.add(radiobutton3); Ogni volta che l utente attiva uno dei pulsanti registrati presso il Button- Group, gli altri vengono automaticamente messi a riposo. I JComboBox offrono all utente la possibilità di effettuare una scelta a partire da un elenco elementi, anche molto lungo. A riposo il componente si presenta come un pulsante, con l etichetta corrispondente al valore attualmente selezionato. Un clic del mouse provoca la comparsa di un menu provvisto di barra laterale di scorrimento, che mostra le opzioni disponibili. Se si imposta la proprietà editable di un JComboBox a true esso si comporterà a riposo come un JTextField, permettendo all utente di inserire valori non presenti nella lista. È possibile creare un JComboBox usando i seguenti costruttori: JComboBox(); JComboBox(Object[] items); Il secondo costruttore permette di inizializzare il componente con una lista di elementi di qualsiasi tipo (ad esempio String). Se viene aggiunto al ComboBox un oggetto generico (ad esempio un oggetto Libro), allora il valore corrispondente visualizzato nella lista delle opzioni è quello ottenuto chiamando sull oggetto il metodo tostring(). Quindi se si desidera aggiungere oggetti generici (magari definiti all interno del programma), bisognerà

39 2.3 Paranoramica di alcuni widget 38 import javax.swing.*; import java.awt.*; public class Application public static void main(string args[]) JFrame win; win = new JFrame("Esempio di JComboBox"); String lista[]=new String[10]; for(int i=0;i<lista.length;i++) lista[i]="elemento numero "+i; JComboBox cbox=new JComboBox(lista); Container c = win.getcontentpane(); c.add(cbox); win.setsize(200,200); win.setdefaultcloseoperation(jframe.exit_on_close); win.setvisible(true); Listato 2.2: Esempio di uso dei ComboBox avere la cura di ridefinire tale metodo. Un gruppo di metodi permette di aggiungere, togliere o manipolare gli elementi dell elenco, così come si fa con un Vector: public void additem(object anobject); public void removeitem(object anobject) public void removeitemat(int anindex); public void removeallitems(); public Object getitemat(int index); public int getitemcount(); public void insertitemat(object anobject, int index) Per ottenere l elemento correntemente selezionato, è disponibile il metodo: public Object getselecteditem(); La Figura 2.5 mostra un esempio di suo uso. Il Listato 2.2 rappresenta il codice corrispondente:

40 2.4 L ereditarietà per personalizzare i frame 39 Figura 2.5: Uso di ComboBox. 2.4 L ereditarietà per personalizzare i frame Aggiungendo ad un frame molti componenti dell interfaccia utente, il frame stesso può diventare abbastanza complesso: per frame che contengono molti componenti è opportuno utilizzare l ereditarietà. Infatti, se il software che si sta sviluppando contiene molte finestre ricche di componenti ci si troverebbe a dover fronteggiare una soluzione il cui caso limite è di un metodo main che contiene la definizione di tutte le finestre del programma. Senza arrivare a questa situazione, si otterrebbero moduli sono molto accoppiati e poco coesi; inoltre, gli stessi moduli sarebbero poco leggibili e non sarebbe facile manutenerli. In parole povere, non si sfrutterebbe le potenzialità dell Object Orientation: non sarebbe possibile permette l information hiding dei contenuti dei frame e dei controlli in essi contenuti; non sarebbe nemmeno sfruttato l incapsulamento delle implementazione, mettendo insieme concetti eterogenei e finestre diverse tra loro. Il Listato 2.3 produce la stessa finestra in Figura 2.3 sfruttando l ereditarietà. La differenza rispetto agli esempi già visti non è da poco: a questo punto ogni finestra diventa una nuova classe che, ereditando da JFrame, è un modello per le finestre. É opportuno definire gli oggetti che mappano i widgets come variabili di instanza (nel l esempio l unico widget è una etichetta (JLabel). La definizione della finestra e dei componenti contenuti viene fatta direttamente nel costruttore (o in metodo chiamati da questo). La prima istruzione chiama il costruttore della superclasse che prende come parametro una stringa; in questo modo è possibile impostare il titolo della finestra. Infatti, se non fosse stato esplicitamente chiamato il costruttore

41 2.4 L ereditarietà per personalizzare i frame 40 import javax.swing.*; import java.awt.*; class MyFrame extends JFrame JLabel jl = new JLabel("Buona Lezione"); public MyFrame() super("prima finestra"); Container c = this.getcontentpane(); c.add(jl); this.setsize(200,200); this.setdefaultcloseoperation (JFrame.EXIT_ON_CLOSE); this.setvisible(true); public class Application public static void main(string args[]) MyFrame = new MyFrame(); Listato 2.3: Esempio con l ereditarietà

42 2.5 I Layout Manager e la gerarchia di contenimento 41 ad un parametro String, sarebbe stato chiamato implicitamente il costruttore della superclasse di default (quello senza parametri) prima di continuare l esecuzione di quello della classe derivata. Il costruttore senza parametri avrebbe impostato a vuoto il titolo della finestra. 1 Il resto del costruttore è simile alla tecnica di definizione delle finestre degli esempi precedenti con l unica differenza che i metodi sono chiamati su this (cioè se stesso) perchè a questo punto i metodi da chiamare sono quelli ereditati dalla superclasse JFrame. 2.5 I Layout Manager e la gerarchia di contenimento Layout Management Quando si dispongono i componenti all interno di un Container sorge il problema di come gestire il posizionamento: infatti, sebbene sia possibile specificare le coordinate assolute di ogni elemento dell interfaccia, queste possono cambiare nel corso della vita del programma allorquando la finestra principale venga ridimensionata. In molti Container i controlli sono inseriti da sinistra verso destra con su una ipotetica riga: può non essere sempre la politica per la GUI (Graphic User Interface) desiderata. Per semplificare il lavoro di impaginazione e risolvere questo tipo di problemi possibile ricorrere ai layout manager, oggetti che si occupano di gestire la strategia di posizionamento dei componenti all interno di un contenitore. Un gestore di layout è una qualsiasi classe che implementa l interfaccia LayoutManager; ogni container nasce con un certo Layout Manager ma è possibile assegnare il più opportuno per quel Container con il metodo: public void setlayout(layoutmanager m); Il primo layout da essere citato è il gestore a scorrimento (Flow Layout) che sono inseriti da sinistra verso destra con la loro Preferred Size, cioè la dimensione minima necessaria a disegnarlo interamente. Usando il paragone con un editor di testi, ogni controllo rappresenta una parola che ha una sua propria dimensione. Come le parole in un editor vengono inseriti da sinistra verso destra finchè entrano in una riga, così viene fatto per i controlli inseriti da sinistra verso destra. Quando un componente non entra in una riga viene posizionato in quella successiva. I costruttori più importanti di oggetti FlowLayout sono i seguenti: 1 A dire il vero, sarebbe stato possibile impostare il titolo della finestra in un secondo momento modificando la proprietà Title: settitle( Prima Finestra );

43 2.5 I Layout Manager e la gerarchia di contenimento 42 (a) (b) Figura 2.6: Aspetto grafico del frame definito nel Listato 2.4 e comportamento del Flow Layout rispetto al ridimensionamento public FlowLayout(); public FlowLayout(int allin); Il secondo costruttore specifica l allineamento dei controlli su una riga; il parametro può essere una delle seguenti costanti che rispettivamente allineano a sinistra, centro o destra: FlowLayout.LEFT FlowLayout.CENTER FlowLayout.RIGHT Il costruttore di default imposta l allineamento centrale. Il Listato 2.4 mostra un esempio di uso del Flow Layout. L aspetto del frame risultato è mostrato in Figura 2.6. É opportuno osservare come l allineamento dei componenti del frame si adatti durante l esecuzione quando la stessa finestra viene ridimensionata (vedi situazione 2.6(b)). Ovviamente se non esiste nessun allineamento per i componenti del frame tale che tutti siano contemporaneamente visibile, allora alcuni di questi risulteranno in parte o del tutto non visibili; per esempio, la finestra è troppo piccola. Il gestore a griglia (GridLayout) suddivide il contenitore in una griglia di celle di uguali dimensioni. Le dimensioni della griglia vengono definite mediante il costruttore: public GridLayout(int rows, int columns) in cui i parametri rows e columns specificano rispettivamente le righe e le colonne della griglia. A differenza di quanto avviene con FlowLayout, i componenti all interno della griglia assumono automaticamente la stessa dimensione, dividendo equamente lo spazio disponibile. L esempio descritto nel Listato 2.5 permette di illustrare il funzionamento di questo pratico layout manager; il risultato è in Figura 2.7. Il gestore a bordi (BorderLayout) suddivide il contenitore esattamente in cinque aree, disposte a croce, come nella Figura 2.8. Ogni zona può

44 2.5 I Layout Manager e la gerarchia di contenimento 43 import javax.swing.*; import java.awt.*; public class MyFrame extends JFrame JButton uno=new JButton("Uno"); JButton due=new JButton("Due"); JButton tre=new JButton("Tre"); JButton quattro=new JButton("Quattro"); JButton cinque = new JButton("Cinque"); public MyFrame() super("flow Layout"); Container c = this.getcontentpane(); c.setlayout(new FlowLayout()); c.add(uno); c.add(due); c.add(tre); c.add(quattro); c.add(cinque); setsize(300,100); setvisible(true); public class Application public static void main(string args[]) MyFrame = new MyFrame(); Listato 2.4: Uso del Flow Layout

45 2.5 I Layout Manager e la gerarchia di contenimento 44 public class MyFrame extends JFrame public MyFrame() super("grid Layout"); Container c = this.getcontentpane(); c.setlayout(new GridLayout(4,4)); for(int i = 0; i<15; i++) c.add(new JButton(String.valueOf(i)); setsize(300,300); setvisible(true); Listato 2.5: Uso del Grid Layout Figura 2.7: Aspetto grafico del frame definito nel Listato 2.5.

46 2.5 I Layout Manager e la gerarchia di contenimento 45 Figura 2.8: Le aree di una disposizione a bordi contenere uno ed un solo widget (o Container): un secondo widget inserito in una zona sostituisce il precedente. Se una o più zone non vengono riempite, allora i componenti nelle altre zone sono estesi a riempire le zone vuote. Il BorderLayout è il gestore di layout di default per la Lastra dei Contenuti di un JFrame. Il programmatore può decidere in quale posizione aggiungere un controllo utilizzando la variante presente nei Container: public void add(component c,string s); dove il primo parametro specifica il componente da aggiungere e il secondo indica la posizione. I valori validi per il secondo parametro sono le costanti BorderLayout.NORTH, BorderLayout.SOUTH, BorderLayout.CENTER, BorderLayout.EAST e BorderLayout.WEST. Si osservi l esempio nel Listato Progettazione della GUI con le gerarchie di contenimento I gestori di layout permettono maggiore versatilità nell inserimento dei controlli nelle finestre. Tuttavia nella stragrande maggioranza delle situazioni un intera finestra non può seguire un unico layout. Si prenda, ad esempio, in considerazione il frame in Figura 2.9. Non è difficile convincersi che la parte in alto contenente una sorta di tastierino numerico segue un Grid- Layout mentre i bottoni in basso seguono un FlowLayout centrato. Poichè ogni Container può seguire uno ed un unico layout, occorre predisporre più Container, uno per ogni zona che ha un layout differente. Ovviamente ad ogni Container possono essere aggiunti direttamente i controlli oppure altri Container. La lastra dei contenuti è il Container radice ed altri si possono aggiungere all interno. I Container (insieme con i componenti contenuti) aggiunti in un altro Container si comporteranno come ogni altro widget la cui

47 2.5 I Layout Manager e la gerarchia di contenimento 46 public class MyFrame extends JFrame JButton nord = new JButton("Nord"); JButton centro = new JButton("Centro"); JButton ovest=new JButton("Ovest"); public MyFrame() super("border Layout"); Container c = this.getcontentpane(); c.setlayout(new BorderLayout()); c.add(nord,borderlayout.north); c.add(centro,borderlayout.center); c.add(ovest,borderlayout.west); setsize(300,300); setvisible(true); Listato 2.6: Uso del Border Layout Figura 2.9: Un frame più complesso dimensione preferita è quella minima necessaria a visualizzare tutti i componenti all interno. Per creare nuovi Container conviene utilizzare la classe

48 2.5 I Layout Manager e la gerarchia di contenimento 47 javax.swing.jpanel che eredita da java.awt.container. La forza di questa soluzione è data dall alta modularità: è possibile usare un layout per il pannello interno e un altro layout per il ContentPane. Il pannello interno verrà inserito nella finestra coerentemente con il layout della lastra dei contenuti. Inoltre all interno pannelli interni se ne possono inserire altri con loro layout e così via, come nel gioco delle scatole cinesi. Il numero di soluzioni diverse sono praticamente infinite. Ad esempio per il frame in Figura 2.9 è possibile creare due contenitoripannelli JPanel: uno per contenere il tastierino numerico organizzato il GridLayout ed un altro il FlowLayout per i tre bottoni in basso. La lastra dei Contenuti viene lasciata in BorderLayout: al centro viene aggiunto il pannello tastierino ed a sud il pannello con i tre bottoni Progettazione top down di interfacce grafiche Durante la progettazione delle interfacce grafiche, può essere utile ricorrere a un approccio top down, descrivendo l insieme dei componenti a partire dal componente più esterno per poi procedere a mano a mano verso quelli più interni. Si può sviluppare una GUI come quella dell esempio precedente seguendo questa procedura: 1. Si definisce il tipo di top level container su cui si vuole lavorare (tipicamente un JFrame). 2. Si assegna un layout manager al content pane del JFrame, in modo da suddividerne la superficie in aree più piccole. 3. Per ogni area messa a disposizione dal layout manager è possibile definire un nuovo JPanel. Ogni sotto pannello può utilizzare un layout manager differente. 4. Ogni pannello identificato nel terzo passaggio può essere sviluppato ulteriormente, creando al suo interno ulteriori pannelli o disponendo dei controlli. Il risultato della progettazione può essere rappresentato con un albero della GUI. L obiettivo di tale albero è mostrare come i Container (a partire dalla lastra dei contenuti) sono stati suddivisi per inserire i componenti o altri Container. Ogni componente (o Container) è rappresentato da un nodo i cui figli sono i componenti (o i Container) contenuti all interno e il padre è il componente che lo contiene.

49 2.5 I Layout Manager e la gerarchia di contenimento 48 Figura 2.10: Un frame d esempio Una volta conclusa la fase progettuale, si può passare a scrivere il codice relativo all interfaccia: in questo secondo momento, è opportuno adottare un approccio bottom up, realizzando dapprima il codice relativo ai componenti atomici, quindi quello dei contenitori e infine quello del JFrame. Esempio di Progettazione Top-Down JFrame BorderLayout nordpnl FlowLayout centropnl GridLayout (2,1) sudpnl FlowLayout infolbl opz1chk opz2chk okbtn Figura 2.11: Un frame più complesso cancbtn Un esempio finale viene mostrato per riassumere quanto è stato finora detto. Si inizierà mostrando la progettazione top-down dell interfaccia e si concluderá mostrandone la realizzazione bottom-up. Si consideri la semplice finestra in Figura L albero della GUI corrispondente è in Figura Il codice per mostrare tale finestra è nel Listato 2.7. Si osservi l invocazione del metodo pack() che sostituisce il metodo setsize(x,y) e che imposta la dimensione della finestra alla minima necessaria a visualizzare tutti i controlli. Inoltre si osservi come le due istruzioni successive hanno

50 2.5 I Layout Manager e la gerarchia di contenimento 49 public class MyFrame extends JFrame JPanel nordpnl = new JPanel(); JPanel centropnl = new JPanel(); JPanel sudpnl = new JPanel(); JLabel infolbl = new Label("Selezionare:"); JCheckBox opz1chk = new JCheckBox("Opz1"); JCheckBox opz2chk = new JCheckBox("Opz2"); JButton okbtn=new JButton("OK"); JButton cancbtn=new JButton("Annulla"); public MyFrame() super("esempio"); centropnl.setlayout(new GridLayout(2,1)); centropnl.add(opz1chk); centropnl.add(opz2chk); nordpnl.add(infolbl); sudpnl.add(okbtn); sudpnl.add(cancbtn); getcontentpane().add(nordpnl,borderlayout.north); getcontentpane().add(centropnl,borderlayout.center); getcontentpane().add(sudpnl,borderlayout.south); pack(); Dimension dim= Toolkit.getDefaultToolkit().getScreenSize(); setlocation((dim.getwidth()-this.getwidth())/2, (dim.getheight()-this.getheight())/2); setvisible(true); Listato 2.7: Il codice della figura 2.10

51 2.5 I Layout Manager e la gerarchia di contenimento 50 lo scopo di centrare la finestra sullo schermo. Il metodo getscreensize() chiamato sulla classe Singleton 2 Toolkit del package java.awt restituisce un riferimento ad un oggetto java.awt.dimension. Questo possiede due proprietà Width e Height che, nel caso specifico, conterranno la dimensione dello schermo in pixel. L istruzione successiva sposta la finestra al centro dello schermo con il metodo setlocation(int x,int y) dove x, y sono le coordinate dell angolo in alto a sinistra. 2 Una classe Singleton è tale che di essa esista sempre al più una instanza. Per maggiori dettagli si faccia riferimento a [5] (in ogni modo sarà anche argomento del corso).

52 2.6 La Gestione degli Eventi La Gestione degli Eventi Figura 2.12: La gestione ad event delegation La gestione degli eventi grafici in Java segue il paradigma event delegation (conosciuto anche come event forwarding). Ogni oggetto grafico è predisposto ad essere sollecitato in qualche modo dall utente e ad ogni sollecitazione genera eventi che vengono inoltrati ad appositi ascoltatori, che reagiscono agli eventi secondo i desideri del programmatore. L event delegation presenta il vantaggio di separare la sorgente degli eventi dal comportamento a essi associato: un componente non sa (e non è interessato a sapere) cosa avverrà al momento della sua sollecitazione: esso si limita a notificare ai propri ascoltatori che l evento che essi attendevano è avvenuto, e questi provvederanno a produrre l effetto desiderato. Ogni componente può avere più ascoltatori per un determinato evento o per eventi differenti, come anche è possibile installare uno stesso ascoltatore su più componenti anche diversi a patto che entrambi possono essere sollecitati per generare l evento. L operazione di installare lo stesso ascoltatore su più controlli (che quindi si comporteranno nello stesso modo se sollecitati dallo stesso evento) è frequente: si pensi alle voci di un menu che vengono replicate su una toolbar per un più facile accesso ad alcune funzionalità frequenti Implementazione dell event delegation Il gestore delle finestre può generare un numero enorme di eventi (sono eventi muovere il mouse nella finestra, spostare o ridimensionare una finestra, scri-

53 2.6 La Gestione degli Eventi 52 vere o abbandonare un campo di testo,... ). Molte volte si è interessati a pochi di questi eventi. Per fortuna, il programmatore può considerare solo gli eventi di cui ha interesse, gestendoli con un ascoltatore opportuno, ignorando completamente tutti gli altri che di default verranno gestiti come eventi vuoti. Quando accade un evento per il quale esiste un ricevitore, la sorgente dell evento chiama i metodi da voi forniti nell ricevitore, dando, in un oggetto di una classe evento, informazioni più dettagliate sull evento stesso. In generale sono coinvolte tre classi: La classe del ricevitore. Implementa una particolare interfaccia del tipo XXXListener tipica degli eventi di una certa classe. I metodi dell interfaccia che la classe dell ascoltatore implementa contengono il codice eseguito allo scatenarsi degli eventi di una classe che l ascoltatore intercetta. Grazie al fatto che ogni ascoltatore è caratterizzato da una particolare interfaccia Java, qualsiasi classe può comportarsi come un ascoltatore, a patto che fornisca un implementazione per i metodi definiti dalla corrispondente interfaccia listener L origine dell evento. É il componente che genera l evento che si vuole gestire su cui si vuole installare l ascoltatore. Ogni componente dispone per ogni evento supportato di due metodi: void addxxxlistener(xxxlistener ascoltatore); void removexxxlistener(xxxlistener ascoltatore); La classe evento. Contiene le informazioni riguardanti le caratteristiche dell evento generato. Gli oggetti di questa classe sono istanziati direttamente dai componenti che notificano eventi agli ascoltatori. Formalmente sono parametri di input dei metodi dell interfaccia implementata dall ascoltatore. Nel momento in cui il componente viene sollecitato, esso chiama gli ascoltatori in modalità callback, passando come parametro della chiamata un apposita sottoclasse di Event. Queste classi contengono tutte le informazioni significative per l evento stesso e possono essere utilizzate per modificare il comportamento dell ascoltatore in base alle informazioni sull evento scatenato Le classi che permettono di gestire gli eventi generati dai componenti Swing sono in gran parte gli stessi utilizzati dai corrispondenti componenti AWT, e si trovano nel package java.awt.event. Alcuni componenti Swing, tuttavia, non hanno un omologo componente AWT: in questo caso le classi necessarie a gestirne gli eventi sono presenti nel package javax.swing.event.

54 2.6 La Gestione degli Eventi Un esempio: elaborare gli eventi del mouse Per chiarire il funzionamento, a prima vista complesso, della gestione degli eventi Swing, verra fatto un esempio. In particolare, vogliamo realizzare un meccanismo per spiare gli eventi del mouse su una finestra e stamparli. Una classe che desidera catturare gli eventi del mouse deve implementare l interfaccia MouseListener definita nel package java.awt.event che è così definita: public interface MouseListener void mouseclicked(mouseevent e); void mouseentered(mouseevent e); void mouseexited (MouseEvent e); void mousepressed(mouseevent e); void mousereleased(mouseevent e); dove MouseEvent è la corrispondente classe evento il cui scopo è dare informazioni aggiuntive sull evento del mouse. Infatti, questa definisce due metodi che permettono di conoscere le coordinate del mouse allo scatenarsi dell evento (i primi due) e un terzo metodo che permette di determinare quale bottone del mouse è stato premuto: int getx(); int gety(); int getmodifiers() Nel codice del Listato 2.9 viene mostrata l implementazione della spia. Si noti come la classe ascoltatore MouseSpy implementi l interfaccia MouseListener e come la classe definisca due metodi vuoti: mouseentered e mouseexited. La definizione dei due metodi vuoti ha lo scopo di dichiarare che gli eventi legati all entrata e all uscita del mouse dall area della finestra devono essere ignorati. In effetti, ignorare gli eventi è già il comportamento di default e quindi tale dichiarazione è superflua. La ragione per cui è stata comunque dichiarata la gestione di tali eventi è legata al linguaggio Java: affinché una classe implementi una interfaccia, tale classe deve implentare tutti i metodi dell interfaccia. E questo vale anche in questo caso: la classe MouseSpy deve implementare tutti i metodi dell interfaccia MouseListener per poter dichiarare di implementarla. Nella Tabella 2.1 sono riassunti gli ascoltatori più importanti. Per ulteriori dettagli si consiglia di consultare la documentazione Java Swing [6].

55 2.6 La Gestione degli Eventi 54 import java.awt.event.*; import javax.swing.*; public class MouseSpy implements MouseListener public void mouseclicked(mouseevent e) System.out.println ("Click su ("+e.getx()+","+e.gety()+")"); public void mousepressed(mouseevent e) System.out.println ("Premuto su ("+e.getx()+","+e.gety()+")"); public void mousereleased(mouseevent e) System.out.println ("Rilasciato su ("+e.getx()+","+e.gety()+")") public void mouseentered(mouseevent e) public void mouseexited(mouseevent e) public class MyFrame extends JFrame public MyFrame() super("mousetest"); this.addmouselistener(new MouseSpy()); setsize(200,200); setvisible(true); Listato 2.8: Primo esempio della gestione degli eventi

56 2.7 La gestione degli eventi Azione 55 ActionListener Definisce 1 metodo per ricevere eventi-azione ComponentListener Definisce 4 metodi per riconoscere quando un componente viene nascosto, spostato, mostrato o ridimensionato FocusListener Definisce 2 metodi per riconoscere quando un componente ottiene o perde il focus KeyListener Definisce 3 metodi per riconoscere quando viene premuto, rilasciato o battuto un tasto MouseMotionListener Definisce 2 metodi per riconoscere quando il mouse e trascinato o spostato MouseListener Se ne è già parlato... TextListener Definisce 1 metodo per riconoscere quando cambia il valore di un campo testo WindowListener Definisce 7 metodi per riconoscere quando un finestra viene attivata, chiusa, disattivata, ripristinata, ridotta a icona, ecc. Tabella 2.1: Gli ascoltatori più importanti Uso di adapter nella definizione degli ascoltatori Alcuni componenti grafici generano eventi così articolati da richiedere, per la loro gestione, ascoltatori caratterizzati da più di un metodo. Si è già visto che MouseListener, ne definisce tre. L interfaccia WindowListener (vedi Listato 2.9) ne dichiara addirittura sette, ossia uno per ogni possibile cambiamento di stato della finestra. Si è detto che se si desidera creare un ascoltatore interessato a un solo evento (per esempio uno che intervenga quando la finestra viene chiusa), esso dovrà comunque fornire un implementazione vuota anche dei metodi cui non è interessato. Nei casi come questo è possibile ricorrere agli adapter: classi di libreria che forniscono un implementazione vuota di un determinato ascoltatore. Per esempio, il package java.awt.event contiene la classe WindowAdapter, che fornisce un implementazione vuota di tutti i metodi previsti dall interfaccia. Una sottoclasse di WindowAdapter, pertanto, è un valido WindowListener, con in più il vantaggio di una maggior concisione. Si veda l esempio La gestione degli eventi Azione La maggior parte dei componenti Swing generano eventi, noti come eventi azione, che possono essere catturati da un ActionListener. Essa definisce un

57 2.7 La gestione degli eventi Azione 56 public interface WindowListener public void windowopened(windowevent e); public void windowclosing(windowevent e); public void windowclosed(windowevent e); public void windowiconified(windowevent e); public void windowdeiconified(windowevent e); public void windowactivated(windowevent e); public void windowdeactivated(windowevent e); Listato 2.9: L interfaccia MouseListener class WindowClosedListener extends WindowAdapter public void windowclosed(windowevent e) // codice da eseguire alla chiusura della finestra Listato 2.10: Esempio dell uso degli Adapter unico metodo: public interface ActionListener public void actionperformed(actionevent ae); L oggetto ActionEvent da informazioni aggiuntive sull evento generato. Ad esempio, definisce il metodo Object getsource() che restituisce l oggetto che ha generato l evento. La maggior parte dei widget java sono predisposti per generare eventi azione. Ad esempio quando si clicca su un bottone, si preme INVIO in un campo di testo, si seleziona una voce di un menu oppure si seleziona/deseleziona una voce di una checkbox o un radiobutton, viene generato un evento azione. Si potrebbe obiettare che, la gestione del click di un bottone, potrebbe essere fatta usando un mouselistener. Il vantaggio di utilizzare un evento azione risiede nel fatto che è possibile cliccare su un bottone anche con la tastiera (anche se in quel caso non è un vero click!): l utente con il tasto TAB potrebbe spostarsi sulla schermata, mettere il focus su un bottone e qui premere la barra spaziatrice per voler cliccare sul bottone.

58 2.8 Accedere dall ascoltatore agli oggetti di una finestra 57 Figura 2.13: La finestra ottenuta dal Listato 2.11 É possibile installare uno stesso ascoltatore, ad esempio, per un bottone della toolbar e una voce di menu. Il vantaggio risiede nel fatto che sia la voce del menu che il bottone hanno lo stesso ascoltatore invece che due ascoltatori separati che fanno la stessa cosa. Un primo esempio di uso degli eventi azione è nel Listato Il comportamento è quello in Figura 2.13: quando l utente seleziona uno dei bottoni della finestra MyFrame viene aperta una finestra di dialogo con il testo del bottone premuto. Su ogni bottone è installato lo stesso ascoltatore per gli eventi azione. Alla pressione di un bottone viene eseguito il metodo action- Performed, il quale si fa restituire con il metodo getsource() il bottone premuto (si noti il cast giacchè il metodo lo restituisce come riferimento ad Object). A partire dal bottone premuto, con il metodo gettext() viene restituito il testo visualizzato nel bottone. 2.8 Accedere dall ascoltatore agli oggetti di una finestra L approccio finora descritto funziona abbastanza bene anche se presenta ancora alcune problematiche. Il primo problema è legato al fatto che la finestra e i suoi ascoltatori sono divisi in classi separate. Supponiamo di avere ascoltatori per gestire gli eventi scatenati da alcuni componenti installati in una data finestra. Essendo le due classi formalmente indipendenti tra loro, per quanto detto, non è possibile accedere dagli ascoltatori a tutti i componenti della finestra (tranne il componente che ha generato l evento). Supponiamo di voler realizzare una finestra come quella in Figura Alla pressione del bottone OK il contenuto del campo di testo deve essere visualizzato in un message dialog box. Si consideri il codice nel Listato Nell ascoltatore definiamo un nuovo JTextField text. Quest approccio non funziona perchè il campo di testo definito è un nuovo campo di testo e non quello della finestra. Quindi la pressione del bottone mostrerà sempre

59 2.8 Accedere dall ascoltatore agli oggetti di una finestra 58 public class MyFrame extends JFrame private JButton uno = new JButton("Uno"); private JButton due = new JButton("Due"); private JButton tre = new JButton("Tre"); private JButton quattro = new JButton("Quattro"); private JButton cinque = new JButton("Cinque"); Ascoltatore listener = new Ascoltatore(); public MyFrame()... Container c = this.getcontentpane(); c.add(uno); uno.addactionlistener(listener);... c.add(cinque); cinque.addactionlistener(listener); public class Ascoltatore implements ActionListener public void actionperformed(actionevent event) JButton b = (JButton)event.getSource(); JOptionPane.showMessageDialog(null, "È stato premuto"+b.gettext()); Listato 2.11: Esempio uso di ActionPerformed Figura 2.14: La finestra ottenuta dal Listato 2.12

60 2.8 Accedere dall ascoltatore agli oggetti di una finestra 59 public class MyFrame extends JFrame JPanel centro = new JPanel(); JPanel sud = new JPanel(); JTextField txt = new JTextField(20); JButton button = new JButton("Premi"); public MyFrame() super("esempio"); centro.add(txt); sud.add(button); getcontentpane().add(centro,borderlayout.center); getcontentpane().add(sud,borderlayout.south); button.addactionlistener(new Listen());... class Listen implements ActionListener public void actionperformed(actionevent e) JTextField text = new JTextField(); JOptionPane.showMessageDialog( null,text.gettext()); Listato 2.12: Un esempio che non funziona una finestra dal contenuto vuoto perchè di default un campo di testo viene inizializzato con il contenuto vuoto. Un primo approccio è utilizzare una classe interna. Una classe interna è definita all interno di un altra classe e può accedere a tutte le variabili e i metodi di istanza della classe esterna (anche a quelli privati). Si consideri il Listato 2.13 che fa uso della classi interne: l istruzione text = txt nell ascoltatore fa sì che il riferimento text punti allo stesso campo di testo riferito da txt. Quindi quando nel codice successivo, l ascoltatore chiede text.gettext() ottiene effettivamente il codice richiesto. Questa tecnica è accettabile se l ascoltatore esegue poche operazioni e pochi ascoltatori esistono. Altrimenti la classe MyFrame diventa eccessivamente grande. Inoltre il codice ottenuto diventa poco leggibile perchè si tende ad accorpare classi che rappresentano concetti diversi. La soluzione preferibile è quella in cui l ascoltatore definisce un costruttore che prende come parametro un riferimento alla finestra con i componenti

61 2.8 Accedere dall ascoltatore agli oggetti di una finestra 60 public class MyFrame extends JFrame JPanel centro = new JPanel(); JPanel sud = new JPanel(); JTextField txt = new JTextField(20); JButton button = new JButton("Premi"); public MyFrame() super("esempio"); centro.add(txt);... button.addactionlistener(new Listen());... class Listen implements ActionListener public void actionperformed(actionevent e) JTextField text = txt; JOptionPane.showMessageDialog( null,text.gettext()); Listato 2.13: Una soluzione che funziona con le classi interne

62 2.9 Condividere gli ascoltatori per più oggetti 61 richiesti. Il costruttore memorizza tale riferimento come variabile di classe. La classe ascoltatore resta comunque esterna: essa accede ai widget della finestra tramite tale riferimento e l operatore punto. Ovviamente i widget non devono essere memorizzati privati. La soluzione è descritta nel Listato Nel codice viene anche mostrato una grande potenzialità degli eventi azione: l evento azione del campo di testo è gestito nello stesso modo della finestra. Ne risulta, di conseguenza, che la pressione del bottone e la pressione del tasto ENTER sul campo di testo vengono gestiti dallo stesso ActionListener e quindi gestiti nello stesso modo. 2.9 Condividere gli ascoltatori per più oggetti La tecnica più naive per gestire più eventi associati ad un controllo è quello di creare una classe ascoltatore per ogni oggetto e per ogni classe di eventi da gestire per quello oggetto. Ciò vorrebbe dire che se dovessimo gestire l evento di pressione di X bottoni, dovrebbe realizzare X classi che implementano ActionListener. Ovviamente è nella pratica improponibile prevedere una classe per ogni bottone, voce del menu e così via. Infatti, consideriamo per esempio un applicazione con 5 finestre, ognuna con 5 bottoni. Supponiamo che una di tali finestre abbia anche 3 voci del menu di 4 opzioni ciascuno. Ciò significherebbe che avremmo 37 classi solo per gestire la pressione dei bottoni o della voci del menu! L idea più elegante è raggruppare gli oggetti su cui ascoltare in classi, prevedendo un ascoltatore condiviso per tutti gli oggetti della stessa classe. Da questo punto in poi consideriamo solo gli eventi actionlistener senza perdere di generalità. Lo stesso approccio si applica in tutti gli altri casi. I componenti della stessa classe, ovviamente, condivideranno lo stesso metodo actionperformed. A meno che tutti i componenti della stessa classe si devo comportare nello stesso modo allo scatenarsi dell evento azione, occore essere in grado di capire quale oggetto ha generato l evento. Questo al fine di capire quale comportamente adottare. Esistono due modi per capire chi ha generato l evento: 1. Attraverso il metodo getsource() della classe ActionEvent che restituisce un riferimento all oggetto che ha scatenato l evento. In questo modo è possibile utilizzare un approccio di tipo switch/case: se il riferimento punta a X, allora chiama un metodo privato che corrisponde alla gestione di pressione del bottone X; se il riferimento punta a Y,

63 2.9 Condividere gli ascoltatori per più oggetti 62 public class MyFrame extends JFrame JPanel centro = new JPanel(); JPanel sud = new JPanel(); JTextField txt = new JTextField(20); JButton button = new JButton("Premi"); Listen ascolt=new Listen(this); public MyFrame() super("esempio"); centro.add(txt);... button.addactionlistener(ascolt); txt.addactionlistener(ascolt);... class Listen implements ActionListener MyFrame frame; public Listen(MyFrame aframe) frame = aframe; public void actionperformed(actionevent e) JTextField text = frame.txt; JOptionPane.showMessageDialog( null,text.gettext()); Listato 2.14: La soluzione migliore

64 2.9 Condividere gli ascoltatori per più oggetti 63 allora chiama il metodo per Y. E cosi via. E ovviamente chiaro se questa approccio è fattibile se è possibile confrontare i riferimenti ottenuti con il metodo getsource() con i riferimenti memorizzati internamente alla classe che estende JFrame e che disegna la finestra con i bottoni X, Y e gli altri. Questo approccio è generalmente fattibile, quindi, con le classi interne. 2. Utilizzando la proprietà actioncommand, implementata per ogni componente, che permette di associare una stringa identificativa univoca ad ogni componente che scatena un evento azione. A questo punto è possibile definire all interno del metodo actionperformed un approccio di tipo switch/case sugli actioncommand. Se lo actioncommand dell oggetto è ACTX (che è stato associato ad X) allora l ascoltatore esegue una certa porzione di codice, se lo actioncommand è ACTY fa un altra cosa. E così via. In questo nuovo contesto non è più necessario per l ascoltatore di avere accesso ai riferimenti. Si consideri, ad esempio, la porzione di condice nel Listato 2.15 dove ci sono tre voci di menu UpOpt, DownOpt, RandomOpt. Le tre voci del menu hanno associati lo stesso ascoltatore con lo stesso metodo actionperformed. All interno del metodo la discriminazione su come l ascoltatore si deve comportare in funzione del metodo invocato è fatto analizzando i riferimenti. L istruzione src=e.getsource() restituisce un riferimento all oggetto che ha generato l evento. Se tale riferimento è uguale a UpOpt (entrambi puntano allo stesso oggetto corrispondente alla voce del menu Up, allora la voce del menu scelta è Up. Quindi viene eseguita la porzione di codice relativa a tale voce. Lo stesso per le altre voci. L ascoltatore è realizzato come classe interna in modo tale da poter realizzare l uguaglianza tra i puntato e verificare se coincidono. Come si è detto, l approccio con le classi interne ha molti svantaggi. la metodologia che vogliamo qui introdurre per capire chi ha generato l evento non deve assumere classi interne e, quindi, non può basarsi sull uguaglianza tra puntatori. Quando si usano classi esterne, è possibile capire il componente che ha notificato l evento associando ai diversi componenti un diverso valore della proprietà actioncommand. Nell esempio nel Listato 2.16 i possibili valori per le proprietà actioncommand sono memorizzate come costanti stringa, cioè public final static, della classe ascoltatore Listener. Ad ogni oggetto da predisporre per gestire gli eventi azione viene associato un valore per la actioncommand presi tra tali costanti stringa. Questo viene fatto grazie al metodo

65 2.9 Condividere gli ascoltatori per più oggetti 64 public class MyFrame extends JFrame... JMenuItem UpOpt = new JMenuItem("Up"); JMenuItem DownOpt = new JMenuItem("Down"); JMenuItem RandomOpt = new JMenuItem("Random"); Listener ascoltatore = new Listener(); public MyFrame()... UpOpt.addActionListener(ascoltatore); DownOpt.addActionListener(ascoltatore); RandomOpt.addActionListener(ascoltatore);... class Listener implements ActionListener public void actionperformed(actionevent e) Object src = e.getsource(); if (src == UpOpt) codice della voce del menu Up else if (src == DownOpt) codice della voce del menu Down else if (src == RandomOpt) codice della voce del menu Random Listato 2.15: Ascoltatore condiviso come classe Interna

66 2.9 Condividere gli ascoltatori per più oggetti 65 public class MyFrame extends JFrame... JMenuItem UpOpt = new JMenuItem("Up"); JMenuItem DownOpt = new JMenuItem("Down"); JMenuItem RandomOpt = new JMenuItem("Random"); Listener ascolt = new Listener(); public MyFrame()... UpOpt.addActionListener(ascolt); UpOpt.setActionCommand(ascolt.UPOPT); DownOpt.addActionListener(ascolt); DownOpt.setActionCommand(ascolt.DOWNOPT); RandomOpt.addActionListener(ascolt); RandomOpt.setActionCommand(ascolt.RANDOMOPT)... Listato 2.16: Il JFrame per usare ascoltatori esterni void setactioncommand(string); Il metodo actionperformed dell actionlistener legge il valore della proprietà actioncommand del componente che ha notificato l evento e, in funzione del valore letto, sceglie la porzione di codice da eseguire. Eventualmente è possibile associare lo stesso actioncommand a componenti gestiti dallo stesso ascoltatore se si desidera che questi gestiscano l evento azione nello stesso modo. Questo cosa è molto utile quando si desidera replicare la voce di un dato menu con un bottone da inserire nella toolbar della finestra: per fare sì che sia la voce del menu che il bottone nella toolbar gestiscano l evento nello stesso modo è sufficiente associare ad entrambi lo stesso actioncommand. Concludiamo il capitolo con l ascoltatore relativo all esempio nel Listato Il suo scheletro è nel Listato Si possono osservare sempre tre parti in questo tipo di ascoltatori: La parte che definisce le costanti stringa (le tre dichiarazioni di oggetti pubblici, costanti 3 e statici) 3 In Java è possibile definire che il valore di un riferimento non può cambiare dichiarandolo final. Questo ovviamente non è sufficiente per dichiarare un oggetto costante. Tuttavia nel caso di oggetti String le due cose coincidono dato che gli oggetti stringa sono immutabili: non può cambiare il riferimento, nè può cambiare il valore dell oggetto puntato

67 2.9 Condividere gli ascoltatori per più oggetti 66 public class Listener implements ActionListener public final static String UPOPT = "up"; public final static String DOWNOPT = "down"; public final static String RANDOMOPT = "random"; public void actionperformed(actionevent e) String com = e.getactioncommand(); if (com == UPOPT) upopt(); else if (src == DOWNOPT) downopt(); else if (src == RANDOMOPT) randomopt(); private void upopt()... private void randomopt()... private void downopt()... Listato 2.17: Ascoltatore condiviso come classe Interna Il metodo actionperformed che gestisce l evento. Questo metodo in questi casi non fa nient altro che leggere il valore della proprietà actioncommand dell oggetto che ha generato l evento. In funzione del valore della proprietà (e quindi dell oggetto scatenante), viene attivata una gestione separata che consiste nell invocare metodi diversi. I diversi metodi privati che eseguono effettivamente le operazioni associate all attivazione dei diversi controlli/widget.

68 2.10 Conclusioni Conclusioni Questo capitolo ha introdotto la progettazione delle Graphical User Interface (GUI) attraverso il package Swing. Swing garantisce alta portabilità tra le piattaforme grazie al fatto che la JVM stessa disegna le linee e colora per creare i controlli. Questo è anche uno degli svantaggi delle Swing. Disegnare e colorare a livello di JVM è fatto parzialmente in modo utente del Sistema Operativo. Quindi, risulta meno efficiente e veloce rispetto a delegare al Sistema operativo con delle chiamate di sistema che vengono eseguite in modo superuser. Questo aspetto, per fortuna, in molti casi va in secondo piano grazie al fatto che le moderne schede video, progettate per videogiochi, risultano molto potenti.

69 Capitolo 3 Servlet e Java Server Pages (JSP) 3.1 Introduzione alle Servlet Uno dei settori sui quali si focalizza maggiormente l attenzione dello scenario della Information Technology è quello della programmazione web oriented, ovvero quella in cui la parte client è costituita da un semplice browser che interagisce con la parte server per mezzo del protocollo HTTP. Questa tipologia di programmi, il cui modello di funzionamento viene tipicamente denominato Common Gateway Interface (CGI), ha l obiettivo di permettere l interfacciamento da parte di un client web con una serie di risorse e di servizi residenti sul server. Poco prima dell uscita definitiva del JDK 1.2, per la realizzazione di applicazioni CGI in Java, Sun ha introdotto la Servlet API, diventata in poco tempo una delle più importanti di tutta la piattaforma Java2. Le servlet hanno introdotto alcune importanti innovazioni nel modello operativo del CGI, innovazioni che poi sono state adottate di riflesso sia nelle tecnologie più obsolete, sia in quelle direttamente concorrenti. Secondo la definizione ufficiale, una servlet è un componente lato server per l estensione di web server Java enabled, cioè un qualcosa di più generale del solo WWW. Una servlet è quindi un programma Java in esecuzione sul server e in grado di colloquiare con il client per mezzo del protocollo HTTP. Tipicamente questo si traduce nella possibilità di generare dinamicamente contenuti web da visualizzare nella finestra del client-browser. I package che contengono tutte le classi necessarie per la programmazione delle servlet sono il javax.servlet e il javax.servlet.http. Quando si lavora con le servlet, è importante specificare quale versione 68

70 3.2 Il Ciclo di Vita di una Servlet 69 della API si utilizza, dato che il servlet engine utilizzato potrebbe non supportare l ultima versione delle API. Con la versione 2.2, le Servlet API sono entrate a far parte formalmente della cosiddetta Java 2 Enterprise Edition, al fianco di altre importanti tecnologie come JDBC, JNDI, JSP, EJB e RMI. Questa nuova organizzazione logica, anche se non ha alterato l architettura di base, ha introdotto alcune nuove definizioni e formalismi. L innovazione più importante da questo punto di vista è l introduzione del concetto di container al posto di server: un container è un oggetto all interno del quale una servlet vive e nel quale trova un contesto di esecuzione personalizzato. Il concetto di container ha poi una visione più ampia dato che viene adottato anche nel caso di JSP ed EJB. Essendo composta al 100% da classi Java, una servlet è integrabile con il resto della tecnologia Java dando luogo a soluzioni scalabili in maniera molto semplice. Ogni volta che il client esegue una richiesta di un servizio basato su CGI, il web server deve mandare in esecuzione un processo dedicato per quel client. Se n client effettuano la stessa richiesta, allora n processi devono essere prima istanziati e poi eseguiti. Questo comporta un notevole dispendio di tempo e di risorse di macchina. Il modello multithread permette a una sola servlet, dopo la fase di inizializzazione, di servire un numero n di richieste senza la necessità di ulteriori esecuzioni. Tutto questo porta a notevoli vantaggi dal punto di vista della efficienza e delle potenzialità operative. Va sottolineato il fatto che utilizzare una applicazione web basata su servlet, pagine JSP o comunemente Java, garantisce portabilità dell applicazione stessa, in quanto essa potrà essere spostata da una piattaforma a un altra in funzione delle esigenze e del carico di lavoro: tutti i sistemi operativi moderni, infatti, hanno una JVM di ultima generazione. 3.2 Il Ciclo di Vita di una Servlet Quando una servlet è invocata per la prima volta, il servlet container (Tomcat) chiama il metodo init(). Tale metodo serve per inizializzare la servlet e per il corretto funzionamento successivo, ed è qui che tipicamente si eseguono le operazioni computazionalmente costose da effettuare una volta per tutte (come ad esempio la connessione a un DB). Dal punto di vista dell implementazione, per realizzare una servlet HTTP è sufficiente estendere la classe HttpServlet, appartenente al package javax.servlet.http, e ridefinire alcuni metodi fondamentali, uno per personalizzare l inizializzazione della servlet (init(), appunto!) e altri per definirne invece il comportamento in

71 3.2 Il Ciclo di Vita di una Servlet 70 funzione delle invocazioni del client. In Figura 3.1 è mostrata la gerarchia delle principali classi per la gestione delle servlet. Il metodo init(), derivato Figura 3.1: Gerarchia delle classi principali per la gestione delle Servlet dalla classe GenericServlet, ha la seguente firma: public void init() throws ServletException Se durante il processo di inizializzazione si verifica un errore tale da compromettere il corretto funzionamento successivo, allora la servlet potrà segnalare tale evento generando una eccezione di tipo ServletException. In questo caso, la servlet non verrà resa disponibile per l invocazione e l istanza appena creata verrà immediatamente rilasciata. Dopo il rilascio dell istanza fallita, il server procederà immediatamente, alla istanziazione e inizializzazione di una nuova servlet; la generazione di una UnavailableException permette di specificare il tempo minimo necessario da attendere prima di intraprendere nuovamente il processo di inizializzazione. Dopo l inizializzazione, una servlet si mette in attesa di una eventuale chiamata da parte del client, che potrà essere indistintamente una GET o una POST HTTP. La differenza fondamentale tra questi due tipi di chiamata è che con una chiamata di tipo GET i parametri sono passati nella URL della richiesta, separati da una &, ad esempio:

72 3.2 Il Ciclo di Vita di una Servlet 71 Con una chiamata di tipo POST invece i parametri vengono specificati nello header del pacchetto HTTP. Quindi, poichè una URL è composta al più da 255 byte, c è un limite al numero di parametri e alla loro lunghezza quando si usa una GET. Un vantaggio invece nell utilizzo di questo tipo di chiamata sta nel fatto che trattandosi di una URL, una chiamata di tipo GET potrà essere memorizzata dal browser come un bookmark (tra i preferiti). L interfaccia Servlet mette a disposizione il metodo service() che viene invocato direttamente dal server in modalità multithread (il server, per ogni invocazione del client, manda in esecuzione un metodo service in un thread separato). In questo modo, il programmatore dovrà solo preoccuparsi di scrivere il codice relativo alle operazioni da effettuare in funzione della richiesta di un client. La firma del metodo è la seguente: public void service(httpservletrequest req, HttpServletResponse res) throws ServletException, IOException Il service viene invocato indistintamente sia nel caso di una invocazione tipo GET che di una POST. La ridefinizione del metodo service permette di definire il comportamento della servlet stessa. Se nella servlet è definito il metodo service(), esso è eseguito al posto dei metodi doget() e dopost(). I due parametri passati sono ServletRequest e ServletResponse, che permettono di interagire con la richiesta effettuata dal client e di inviare risposta tramite pacchetti HTTP. In seguito saranno analizzati in dettaglio gli aspetti legati a queste due interfacce. Nel caso in cui invece si desideri implementare un controllo più fine si possono utilizzare i due metodi doget() e dopost(), che risponderanno rispettivamente a una chiamata di tipo GET e a una di tipo POST. Ad esempio, se si vuole evitare che una servlet sia invocata con una POST, si può implementare soltanto il metodo doget(); oppure, nel caso in cui si voglia gestire in modo differente i due tipi di chiamata, basta implementare in maniera appropriata i due metodi corrispondenti. A completamento del ciclo di vita, vi è la fase di distruzione della servlet. Il metodo che viene utilizzato per questo scopo è destroy(), che consente altresì la terminazione del processo e il log dello status. La ridefinizione di tale metodo, derivato dalla interfaccia Servlet, permette di specificare tutte le operazioni simmetriche alla inizializzazione, oltre a sincronizzare e a rendere persistente lo stati della memoria. Anche la chiamata della destroy() come quella della init() è a carico del server che ha in gestione la servlet. La distruzione di una servlet e il relativo scaricamento dalla memoria avvengono solamente nel momento in cui tutte le chiamate a service() da

73 3.3 Come Interagire con una Servlet: Richieste e Risposte 72 parte dei client sono state eseguite. Quando invece si verifica un errore durante il processo di inizializzazione e la servlet non può essere resa disponibile, l istanza appena creata verrà immediatamente rilasciata, ma il metodo destroy() in tale situazione non verrà invocato dal server. 3.3 Come Interagire con una Servlet: Richieste e Risposte Una servlet può comunicare con il client in maniera bidirezionale per mezzo delle due interfacce HttpServletRequest e HttpServletResponse: la prima rappresenta la richiesta e contiene i dati provenienti dal client, mentre la seconda rappresenta la risposta e permette di incapsulare tutto ciò che deve essere inviato indietro al client stesso. La Risposta: HttpServletResponse La risposta di una servlet può essere inviata al client per mezzo di un oggetto di tipo HttpServletResponse, che offre due metodi per inviare dati al client: il getwriter() che restituisce un oggetto di tipo java.io.writer, e il getoutputstream() che, come lascia intuire il nome, restituisce un oggetto di tipo ServletOutputStream (Figura 3.2). Si deve utilizzare il primo tipo per inviare dati di tipo testuale al client, mentre un OutputStream può essere utile per inviare anche dati in forma binaria. Da notare che la chiusura di un Writer o di un ServletOutputStream dopo l invio dei dati permette al server di conoscere quando la risposta è completa. Con i metodi setcontent- Type() e setheader() si può stabilire il tipo MIME della pagina di risposta e, nel caso sia HTML, avere un controllo fine su alcuni parametri. Ad esempio, il content-type può essere impostato a text/html, a indicare l invio di una pagina HTML al browser, mentre pragma no-cache serve per forzare il browser a non memorizzare la pagina dalla cache Esempio Data Vediamo un semplice esempio, in cui la servlet deve restituire una pagina HTML in output con la data e l ora corrente (che ovviamente cambierà ad ogni invocazione!) e in più la data e l ora in cui è stato invocato il metodo init() (che sarà la stessa per ogni invocazione!). Per l installazione e le operazioni preliminari da effettuare per poter utilizzare JBOSS, fare riferimento all Appendice A.1. I Listati 3.1 e 3.2 contengono il codice della classe GeneraDataInit.

74 3.3 Come Interagire con una Servlet: Richieste e Risposte 73 import javax.servlet.http.*; import javax.servlet.*; import java.io.*; import java.util.*; public class GeneraDataInit extends HttpServlet Calendar datainit; private String converttostring (Calendar data) String giornosettimana = null; String ilmese = null; String giornomese, lanno, lora; String iminuti, isecondi, datafinale; int ggsettimana = data.get(calendar.day_of_week); switch (ggsettimana) case 1: giornosettimana = "domenica, "; break; case 2: giornosettimana = "lunedi, "; break; case 3: giornosettimana = "martedi, "; break; case 4: giornosettimana = "mercoledi, "; break; case 5: giornosettimana = "giovedi, "; break; case 6: giornosettimana = "venerdi, "; break; case 7: giornosettimana = "sabato, "; break; int ggmese = data.get(calendar.day_of_month); giornomese = ggmese+" "; int mese = data.get(calendar.month); switch (mese) case 0: ilmese = "Gennaio "; break; case 1: ilmese = "Febbraio "; break; case 2: ilmese = "Marzo "; break; case 3: ilmese = "Aprile "; break; case 4: ilmese = "Maggio "; break; case 5: ilmese = "Giugno "; break; case 6: ilmese = "Luglio "; break; case 7: ilmese = "Agosto "; break; case 8: ilmese = "Settembre "; break; case 9: ilmese = "Ottobre "; break; case 10: ilmese = "Novembre "; break; case 11: ilmese = "Dicembre "; break; Listato 3.1: Classe GeneraDataInit

75 3.3 Come Interagire con una Servlet: Richieste e Risposte 74 int anno = data.get(calendar.year); lanno = anno+", "; int ore = data.get(calendar.hour_of_day); lora = ore+":"; int minuti = data.get(calendar.minute); if(minuti<10) iminuti = "0"+minuti+":"; else iminuti = minuti+":"; int secondi = data.get(calendar.second); if(secondi<10) isecondi = "0"+secondi+". "; else isecondi = secondi+". "; datafinale = giornosettimana+giornomese +ilmese+lanno+lora+iminuti+isecondi; return datafinale; public void init() throws ServletException datainit = Calendar.getInstance(); public void service (HttpServletRequest req, HttpServletResponse res) throws IOException, ServletException OutputStream os = res.getoutputstream(); PrintWriter out = new PrintWriter(os, true); out.println ("<HTML><HEAD><TITLE>GeneraDataMigliore </TITLE></HEAD>"); out.println ("<BODY>"); out.println ("Ciao, la data e l ora correnti sono: "); Calendar rightnow = Calendar.getInstance(); out.println (converttostring(rightnow)); out.println ("<BR>"); out.println ("La data e l ora in cui e stato invocato il metodo init sono le seguenti: "); out.println (converttostring(datainit)); out.println ("</BODY>"); out.println ("</HTML>"); Listato 3.2: Classe GeneraDataInit (continuo)

76 3.3 Come Interagire con una Servlet: Richieste e Risposte 75 Figura 3.2: Classi per la gestione delle risposte verso il client: ServletResponse e HTTPServletResponse Il file web.xml relativo all esempio è nel Listato 3.3. Si supponga di impacchettare l intero esempio in un archivio datainit.war. Per invocare la servlet sarà necessario scrivere nella barra degli indirizzi del browser La Richiesta: HttpServletRequest La HttpServletRequest, oltre a permettere l accesso a tutte le informazioni relative all header HTTP (come ad esempio i vari cookies memorizzati nella cache del browser), permette di ricavare i parametri passati insieme all invocazione del client. Tali parametri sono inviati come coppie nome-valore, sia che la richiesta sia di tipo GET che POST. Ogni parametro può assumere valori multipli. L interfaccia ServletRequest dalla quale discende la HttpServletRequest mette a disposizione alcuni metodi per ottenere i valori dei parametri passati alla servlet: ad esempio, per ottenere il valore di un parametro dato il nome, si può utilizzare il metodo fornito dalla interfaccia public String getparameter(string name)

77 3.3 Come Interagire con una Servlet: Richieste e Risposte 76 <?xml version="1.0" encoding="utf-8"?> <!-- per invocarla --> <servlet> <servlet-name>servletdatainit</servlet-name> <servlet-class>generadatainit</servlet-class> </servlet> <servlet-mapping> <servlet-name>servletdatainit</servlet-name> <url-pattern>/init</url-pattern> </servlet-mapping> </web-app> Listato 3.3: File web.xml Nel caso di valori multipli per la stessa variabile - come quando l invocazione viene fatta tramite un form HTML - a partire dalla API 2.1 si ottiene sempre un array di stringhe, risultato analogo a quello fornito dal metodo public String[] getparametervalues(string name) Per ottenere invece tutti i nomi o tutti i valori dei parametri si possono utilizzare i metodi public Enumeration getparameternames() public String[] getparametervalues(string name) Infine, nel caso di una GET http, il metodo getquerystring() restituisce una stringa con tutti i parametri concatenati. Nel caso in cui si attendano dati non strutturati, in forma testuale, e l invocazione sia una POST, una PUT o una DELETE, si può utilizzare il metodo getreader(), che restituisce un BufferedReader. Se invece i dati inviati sono in formato binario, allora è indicato utilizzare il metodo getinputstream(), il quale a sua volta restituisce un oggetto di tipo ServletInputStream. Ecco di seguito un semplice esempio public class MyServlet extends HttpServlet public void service(httpservletrequest req, HttpServletResponse res) throws ServletException res.setcontenttype("text/html"); res.setheader("pragma", "no-cache"); res.writeheaders(); String param = req.getparameter("parametro");

78 3.3 Come Interagire con una Servlet: Richieste e Risposte 77 // esegue programma di servizio OutputStream out = res.getoutputstream(); // usa out per scrivere sulla pagina di risposta Da notare l utilizzo dello statement OutputStream out = res.getoutputstream(); impiegato per ricavare lo stream di output con il quale inviare dati (ad esempio codice HTML) al client Esempio Rubrica In questo esempio vediamo come, a partire da una form HTML, possiamo richiedere a un server il numero di telefono corrispondete al nome della persona specificata (attraverso la form, appunto). La form è quella in Figura 3.3 e il codice HTML relativo è nel Listato 3.4. La pressione del bottone di submit della form deve invocare una servlet codificata nella classe Rubrica (vedi Listati 3.6 e 3.7). L ultimo punto da analizzare è come configurare l applicazione in modo tale che la pressione del bottone di submit invochi direttamente la servlet rubrica. Analizzando il file web.xml(listato 3.8) si osserva che la servlet è invocabile mediante l URL war/rubrica. Ciò vuol dire che l elemento form della pagina HTML dovrà specificare come action rubrica, ovvero l URL relativo della servlet. Si osservi inoltre il nome dei campi di input della form: il campo di testo si chiama Nome e quindi alla servlet Rubrica verrà passato un parametro Nome il cui valore è il contenuto del campo di testo. Inoltre esistono tre checkbox. Il comportamento delle checkbox nel passaggio di parametri alla servlet è leggermente diverso: solo se una checkbox è selezionata allora viene passato come parametro il nome della checkbox (e valore quello specificato nell attributo value). Nel caso specifico, ad esempio, se la checkbox relativa al numero di casa è selezionata, allora alla servlet verrà passato il parametro Casa con valore ON. Se la stessa non è selezionata, il parametro non verrà passato e quindi l invocazione dell istruzione getparameter( Casa ) restituirà null. La classe fa uso dei servigi della classe Numero descritta nel Listato 3.5 che permette l accesso al repository dei numeri di telefoni. Si osservi come l unico costruttore della classe sia privato a sottolineare che gli oggetti di tale classe possono essere creati solamente attraverso il metodo static ottieninumero(string abbonato). Per semplicità il repository è implementato come un file di testo Rubrica.txt una cui instanza è rappresentata in Figura 3.3.

79 3.3 Come Interagire con una Servlet: Richieste e Risposte 78 <html> <head> <title>nome</title> </head> <body> <form method="get" action="rubrica"> <p>nome: <input type="text" name="nome" size="20"> </p> <p>tipo: <input type="checkbox" name="casa" value="on"> Casa <input type="checkbox" name="cellulare" value="on"> Cellulare <input type="checkbox" name="ufficio" value="on"> Ufficio </p> <p><input type="submit" value="invia"> <input type="reset" value="reimposta"></p> </form> </body> </html> Listato 3.4: Il file HTML della form

80 3.3 Come Interagire con una Servlet: Richieste e Risposte 79 import java.io.*; public class Numero public static String nome; public String casa; public String ufficio; public String cellulare; private Numero() public static Numero ottieninumeri (String unnome) throws IOException FileReader in = new FileReader ("C:\\Rubrica.txt"); BufferedReader riga = new BufferedReader (in); nome = riga.readline(); while(!nome.equals(unnome) && nome!=null) riga.readline(); riga.readline(); riga.readline(); nome = riga.readline(); if (nome.equals(unnome)) Numero n = new Numero(); n.casa = riga.readline(); n.ufficio = riga.readline(); n.cell = riga.readline(); return (n); else return null; Listato 3.5: Classe Numero

81 3.3 Come Interagire con una Servlet: Richieste e Risposte 80 import javax.servlet.http.*; import javax.servlet.*; import java.io.*; public class Rubrica extends HttpServlet public void service (HttpServletRequest req, HttpServletResponse resp) throws ServletException,IOException String nome=req.getparameter("nome"); boolean casa=(req.getparameter("casa")==null); boolean ufficio=(req.getparameter("ufficio")==null); boolean cell=(req.getparameter("cellulare")==null); OutputStream os = resp.getoutputstream(); PrintWriter out = new PrintWriter(os, true); out.println ("<HTML><HEAD><TITLE>Esempio2</TITLE> </HEAD>"); out.println ("<BODY>"); out.println ("Ciao, sono stati richiesti i seguenti numeri di telefono di "); out.println ("<B>"); out.println (nome); out.println ("</B>"); out.println (":"); out.println ("<BR>"); Numero unnumero = Numero.ottieniNumeri(nome); Listato 3.6: Classe Rubrica

82 3.3 Come Interagire con una Servlet: Richieste e Risposte 81 if(!casa) out.println ("<P>"); out.println ("<I>"); out.println ("Casa:"); out.println ("</I>"); out.println (unnumero.casa); out.println ("</P>"); if(!ufficio) out.println ("<P>"); out.println ("<I>"); out.println ("Ufficio:"); out.println ("</I>"); out.println (unnumero.ufficio); out.println ("</P>"); if(!cell) out.println ("<P>"); out.println ("<I>"); out.println ("Cellulare:"); out.println ("</I>"); out.println (unnumero.cell); out.println ("</P>"); out.println ("</BODY>"); out.println ("</HTML>"); Listato 3.7: Classe Rubrica

83 3.4 Le Sessioni 82 Figura 3.3: La Form HTML I numeri di telefono vanno memorizzati su un documento di testo, come mostrato in Figura Le Sessioni Il fatto che più esecuzioni di una stessa servlet facciano capo allo stesso oggetto permette di condividere proprietà e metodi della classe e, in definitiva, l informazione. In pratica ciò si traduce nell istanziare nel metodo init delle variabili di classe, che saranno successivamente visibili nelle varie esecuzioni dei metodi dopost e doget (o service) della nostra servlet. La necessità di passare informazioni tra le pagine Web è particolarmente sentita tra chi sviluppa procedure Intranet / Extranet, nelle quali, una volta identificato l utente, si permette che esso compia una serie di operazioni che non si concludono necessariamente in una pagina; è così necessario tenere traccia delle operazioni, fornire un ambiente che si adatti all utente stesso secondo le sue preferenze e diritti di accesso; questo si traduce tecnicamente nel mantenimento dell indentità dell utente e dello stato attraverso la richiesta di più pagine. Viene così ad identificarsi un concetto analogo a quanto noto da anni nei mainframe e nei DBMS, cioè la sessione. L uso di variabili

84 3.4 Le Sessioni 83 Figura 3.4: Rubrica.txt <?xml version="1.0" encoding="utf-8"?> <servlet> <servlet-name>servletrubrica</servlet-name> <servlet-class>rubrica</servlet-class> </servlet> <servlet-mapping> <servlet-name>servletrubrica</servlet-name> <url-pattern>/rubrica</url-pattern> </servlet-mapping> </web-app> Listato 3.8: File web.xml di classe in questa ottica non è più sufficiente, in quanto esse sono visibili da qualunque client invochi quella servlet, noi invece vogliamo tenere traccia di una informazione specifica per quella servlet chiamata da quel particolare client. Le Servlet API forniscono una serie di strumenti per fare tutto ciò in maniera efficace e rapida, dunque in pieno stile Java. Cosa accade quando si crea una nuova sessione? Il server deve predisporre l area della memoria che conterrà l informazione e fare in modo di marcare il browser dell utente in modo da poter successivamente associare ogni richiesta di quel client con quella determinata sessione; in pratica viene registrato un cookie sul browser con un numero di identificazione della sessione, il Session Id. Molte persone si preoccupano per i cookie e per la scarsa sicurezza che offrono in quanto l utente un po smaliziato può divertirsi a modificarli

85 3.4 Le Sessioni 84 e creare problemi all applicazione; nel caso delle sessioni in Java ciò non è possibile in quanto l informazione continua a risiedere là dove è più al sicuro, cioè sul server. Per gestire le sessioni in Java, il package javax.servlet.http mette a disposizione tre classi: HttpSession, HttpSessionBindingListener e HttpSessionContext. Una volta inizializzata correttamente la servlet, sarà possibile ottenere nel metodo doget, dopost o service un riferimento all oggetto HttpSession tramite una chiamata al metodo getsession di HttpServletRequest: HttpSession session = request.getsession(); La servlet cerca di identificare il client (nel nostro caso il browser) che la chiama; se esiste già un oggetto HttpSession per quel client session, allora riferirà a quello, altrimenti ne verrà creato uno nuovo. Riassumendo, ecco cosa accade: 1. Il browser richiede la servlet (ad es.: localhost/servlet/myservlet) 2. La servlet controlla se il browser richiedente possiede un cookie, se lo possiede verifica se esso punta ad una sessione valida. Altrimenti crea una nuova sessione e ne registra l identificativo in un cookie (generato da una Servlet che gira col web server) 3. Una volta ottenuto l oggetto session è possibile usarlo per memorizzare qualsiasi tipo di informazione, basta usare gli opportuni metodi di HttpSession. Ad esempio, per tenere un semplice contatore delle volte che viene chiamata quella servlet da quel determinato client, sarà sufficiente: // Tento di ricavare dalla sessione // il valore di sessiontest.counter Integer ival = (Integer) session.getvalue("sessiontest.counter"); if (ival==null) // ival nonè definito... ival = new Integer(1); else // il valore di ivalè definito, lo // incremento di uno ival = new Integer(ival.intValue() + 1); // Memorizzo nella sessione il nuovo valore session.putvalue("sessiontest.counter", ival);

86 3.4 Le Sessioni 85 Questo esempio è tratto dal tutorial del JSDK 2.0, per il codice completo potete fare riferimento a quello [3]. Una sessione rimane valida finché non viene invalidata esplicitamente mediante il metodo invalidate, oppure supera un determinato tempo di inattività. Il time-out può essere settato a proprio piacimento, attraverso il metodo setmaxinactiveinterval. Le sessioni sono un meccanismo intrinseco del web server; ciò significa anche che non tutti i Web Server che permettono di usare servlet permettono anche di usare le sessioni, inoltre si potrebbero sperimentare alcune differenze di comportamento tra un Web Server e l altro. Il cookie presenta numerosi vantaggi: è molto elegante perché il tutto avviene di nascosto, senza annoiare l utente con URL complesse, inoltre, anche se il browser viene chiuso, il cookie viene mantenuto in modo da poter riprendere il lavoro da dove l avevamo lasciato. Se però in una logica Intranet è abbastanza plausibile aspettarsi che tutti i browser supportino i cookie o comunque siano configurati per usarli, una volta nel mare di Internet questa certezza non c è più; in effetti molti utenti preferiscono disabilitare i cookie per motivi di sicurezza. Un aspetto particolarmente interessante delle HttpSession è che queste si preoccupano per noi di verificare se sono uitilizzabili i cookie sul client (browser), e di eseguire le opportune contromosse in caso negativo. In pratica, invece di usare i cookie, viene aggiunto in coda alla query string il Session ID, cosicché l URL prende questo forma: = L unica accortezza che dobbiamo usare nello scrivere il codice è di generare le URL attraverso il metodo HttpServletResponse.encodeUrl, in modo che venga inserita nella pagina HTML la chiamata opportuna per entrambe le situazioni Esempio Login Il seguente esempio mostra l uso delle sessioni per realizzare il login. Il client inizia invocando la servlet codificata nella classe HomeServlet (Listato 3.9) che è accedibile dal client inserendo nella barra degli indirizzi del browser l indirizzo (ovviamente supponendo che il deploy sia stato fatto mediante il file sessioni.war). Tale servlet legge dalla sessione l attributo login che, nell esempio, è predisposto per memorizzare l account dell utente che si è loggato. Se non esiste nella tabella delle sessioni nessun valore per quello attributo, allora significa che l utente non si è ancora loggato. In tal caso la servlet ridirezione il browser dell utente sulla

87 3.4 Le Sessioni 86 import javax.servlet.http.*; import javax.servlet.*; import java.io.*; public class HomeServlet extends HttpServlet public void service (HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException HttpSession s = req.getsession(true); Object value = s.getattribute("login"); if(value==null) resp.sendredirect("login.htm"); else resp.sendredirect("homepage.htm"); Listato 3.9: Classe HomeServlet pagina login, altrimenti il browser viene ridirezionato alla pagina principale. La ridirezione viene fatta con il metodo HttpServletResponse.sendRedict(String url). La Figura 3.5 contiene la pagina del Login con un unico campo di testo il cui nome è Nome. La pressione del bottone di Submit invoca la servlet LoginServlet, passando ovviamente come parametro il nome dell utente che desidera loggarsi. La servlet è molto semplice: prende il parametro Nome ed aggiunge l attributo login alla tabella delle sessioni. Quindi effettua la redirezione alla homepage. La successiva volta in cui l utente invoca la servlet all indirizzo l output verrà automaticamente redirezionato alla pagina homepage. Questo perchè troverà nella tabella delle sessioni un valore impostato per l attributo login.

88 3.4 Le Sessioni 87 Figura 3.5: La pagina per il login import javax.servlet.http.*; import javax.servlet.*; import java.io.*; public class LoginServlet extends HttpServlet public void service (HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException String nome = req.getparameter("nome"); HttpSession s = req.getsession(true); s.setattribute("login", nome); resp.sendredirect("homepage.htm"); Listato 3.10: Classe LoginServlet

89 3.5 Le Java Server Pages (JSP) 88 <?xml version="1.0" encoding="utf-8"?> <servlet> <servlet-name>homesessioni</servlet-name> <servlet-class>homeservlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>homesessioni</servlet-name> <url-pattern>/start</url-pattern> </servlet-mapping> <servlet> <servlet-name>loginsessioni</servlet-name> <servlet-class>loginservlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>loginsessioni</servlet-name> <url-pattern>/login</url-pattern> </servlet-mapping> </web-app> Listato 3.11: File web.xml 3.5 Le Java Server Pages (JSP) Per venire in contro all esigenza di una maggiore interazione tra client e server e per fornire all utente contenuti più vari e meno statici sono state introdotte svariate tecnologie, che introducono elementi dinamici nei siti web. Il supporto di queste tecnologie ha comportato modifiche ai vari elementi coinvolti nell interazione client/server: estensione delle funzionalità del client (web browser), estensione delle funzionalità del server ed estensione del linguaggio HTML. Nuove versioni dei browser e dei server si sono unite alla realizzazione di moduli aggiuntivi, detti plugin, che vengono collegati, tramite opportune API, con il browser o con il server web. É possibile stilare una classificazione sulla base di dove viene eseguito il codice che compie le elaborazioni che rendono l funzionamento dinamico. Tecnologie lato client (client side) la dinamicità e l interazione con l utente sono gestite direttamente da codice eseguito dal client o da un suo plugin. É il caso delle Applet Java. Tecnologie lato server (server side) il client ha un ruolo passivo ed è il server, o un suo plugin, a gestire a parte dinamica. Il caso più tipico

90 3.5 Le Java Server Pages (JSP) 89 è la comunicazione client/server per mezzo del protocollo HTTP, supportata in HTML dai form e dai suoi componenti. Attraverso questi, l utente può inserire dati, mandarli al server e ottenerne una risposta. Il browser manda questi dati sotto forma di una richiesta HTTP, utilizzando uno dei metodi previsti dal protocollo (in genere get o post) a cui il server fa seguire una appropriata risposta. Queste tecnologie devono innanzitutto fornire al programmatore i mezzi per scrivere sul lato server il codice che elabora le risposte: in Java, troviamo i Servlet e le Java Server Pages. Approcci misti presentano elementi dinamici sia sul lato server che sul lato client, realizzati mediante l interazione dei rispettivi plugin (lato server e lato client). Rientra in questa categoria l uso congiunto di Applet e Servlet Java. Tra questi diversi approcci, assume particolare rilevanza quelo delle tecnologie server side, basate sul protocollo HTTP. Sono infatti quelle che più si prestano allo sviluppo di applicazioni web centrate sulla gestione di basi di dati. Le tecnologie Java, nate per ultime, hanno usufruito delle precedenti idee ed esperienze, apportando però anche significativi miglioramenti. L uso di Servlet infatti ha apportato il vantaggio di avere un minore impiego di risorse, dato che tutti i Servlet sono eseguiti dalla stessa Java virtual machine, messa in esecuzione dal server, come thread distinti e non come processi distinti. E proprio come i Servlet, JSP regala gli stessi vantaggi legati all uso di Java, e una reale portabilità in tutte le piattaforme in cui esista una implementazione della macchina virtuale Java (quindi, praticamente tutte quelle comunemente usate). In tutte le tecnologie server side, si è detto, si ha la generazione di pagine web come risultato di una determinata richiesta da parte del client. La pagina non esiste come risorsa statica, ma viene generata dinamicamente. Il problema sta nel fatto che chiamare funzioni o metodi di output che scrivano letteralmente codice HTML può portare alla generazione di continui errori. Con le Java Server Pages l intero processo di generazione del codice, compilazione ed esecuzione è gestito automaticamente in modo trasparente. JSP ha anche la peculiarità di permettere l inserimento diretto di codice Java nella pagina. Ma entriamo più nel dettaglio. Da un punto di vista funzionale, una pagina JSP si può considerare come un file di testo scritto secondo le regole di un markup language in base al quale il contenuto del file viene elaborato da un JSP container (ovvero, un software per l elaborazione di pagine JSP), per restituire il risultato di una trasformazione del testo originale, secondo le istruzioni inserite nel testo. Si

91 3.5 Le Java Server Pages (JSP) 90 tratta quindi di pagine web a contenuto dinamico generato al momento in cui la pagina viene richiesta dal client. Una pagina JSP contiene essenzialmente due tipi di testo: template text ovvero testo letterale destinato a rimanere tale dopo l elaborazione della pagina; JSP text porzioni di testo che vengono interpretate ed elaborate dal JSP container (Tomcat). Nella maggior parte dei casi, il template text è in formato HTML (o a volte XML), dato che le JSP sono pagine web. Dal punto di vista del programmatore Java, una JSP viene vista come un modo particolare per interfacciarsi a oggetti Java. Il JSP container infatti converte la pagina JSP in un Servlet, generando prima il codice sorgente, poi compilandolo. Vediamo un semplice (anzi, banale!) esempio di pagina JSP: <html> <head> <title>data e ora</title> </head> <body> <p> Data e ora corrente:<br> <b><%= new java.util.date()%></b> </p> </body> </html> Si tratta, come si può vedere, di una normale pagina HTML, con un solo elemento estraneo a questo linguaggio <%= new java.util.date()%>. Si tratta di una espressione JSP in linguaggio Java che verrà interpretata e valutata dal JSP container e sostituita dalla data e ora corrente. Quindi con new java.util.date() viene creato un oggetto rappresentante l istante attuale. Giacchè è richiesta una rappresentazione stringa, allora l oggetto è convertito in una stringa 1 Finora si sono visti soltanto alcuni degli elementi di una pagina JSP: il template text e le espressioni. Ora verrà fatta una breve descrizione di tutti gli elementi: 1 Per essere precisi, la conversione in Stringa è ottenuta automaticamente invocando per l oggetto il metodo ereditato da Object tostring(), in questo caso sovrascritto per rappresentare la data in forma di stringa.

92 3.5 Le Java Server Pages (JSP) 91 Template Text tutte le parti di testo che non sono definite come elementi JSP; vengono copiate tali e quali nella pagina di risposta. Comment con sintassi: <%- - comment - -%>; sono commenti che riguardano la pagina JSP in quanto tale, e pertanto vengono eliminati dal JSP container nella fase di traduzione-compilazione; da non confondere con i commenti HTML e XML, che vengono inclusi nella risposta come normale template text. Directive con sintassi: directive...%>; sono direttive di carattere generale, indipendenti dal contenuto specifico della pagina, relative alla fase di traduzione-compilazione. Action seguono la sintassi dei tag XML ossia <tag attributes> body </tag> oppure <tag attributes/> dove attributes sono nella forma attr1 = value1 attr2 = value2...; le azioni sono eseguite nella fase di processing, e danno origine a codice Java specifico per la loro esecuzione. Sripting element sono porzioni di codice in uno scripting language specificato nelle direttive; il linguaggio di default è lo stesso Java; si dividono in tre sottotipi: Scriplet con sintassi: <% code %>; sono porzioni di codice nello scripting language che danno origine a porzioni di codice Java; generalmente inserite nel metodo service() del Servlet; se contengono dichiarazioni di variabile, queste saranno variabili locali valide solo nell ambito di una singola esecuzione del Servlet; se il codice contiene istruzioni che scrivono sullo stream di output, il contenuto mandato in output sarà inserito nela pagina di risposta nella stessa posizione in cui si trova lo scriptlet. Declaration con sintassi <%! declaration [declaration]...%>; sono dichiarazioni che vengono inserite nel Servlet come elementi della classe, al di fuori di qualunque metodo. Possono essere sia variabili di classe che metodi. Expression con sintassi <%= expression %>; contengono un espressione che segue le regole dele espressioni dello scripting language; l espressione viene valutata e scritta nella pagina di risposta nella posizione corrispondente a quella dell espressione JSP. Torniamo all esempio della pagina JSP per vedere come essa viene elaborata dal JSP container. In primo luogo, viene generato il codice che definisce una classe Java; questa classe è una Servlet, e il codice generato sarà il seguente:

93 3.5 Le Java Server Pages (JSP) 92 class JSPDataOra extends HttpJspServlet public void _jspservice (HttpServletRequest request, HttpServletResponse response)... PrintWriter out = response.getwriter(); out.println("<html>"); out.println(); out.println("<head>"); out.println("<title>data e Ora</title>"); out.println("</head>"); out.println(); out.println("<body>"); out.println("<p>"); out.println("data e ora corrente:<br>"); out.println("<b>"); out.println(new java.util.date()); out.println("</b>"); out.println("</p>"); out.println("</body>"); out.println(); out.println("</html>");... La classe è derivata da una ipotetica classe HttpJspServlet, che potrà essere una sottoclasse di HttpServlet e dovrà implementare l interfaccia HttpJspPage, definita nella JSP API. Questa interfaccia contiene il metodo jspservice(), corrispondente al metodo service() del Servlet generico. Il Servlet non fa altro che rimandare in output le parti del file che non contengono tag JSP come string literal mentre l espressione JSP viene eseguita e valutata prima di essere scritta nello stream. Prescindendo dai dettagli implementativi, l esecuzione di una pagina JSP prevede due fasi distinte: 1. fase di traduzione-compilazione, durante la quale viene costruito un oggetto costruibile dalla VM (in genere un Servlet) in grado di elaborare una risposta alle richieste implicite o esplicite contenute nella pagina;

94 3.5 Le Java Server Pages (JSP) fase di processing, in cui viene mandato in esecuzione il codice generato e viene effettivamente elaborata e restituita la risposta. Il Servlet manipola una serie di oggetti per svolgere il suo lavoro, principalmente i due oggetti ServletRequest e ServletResponse, su cui si basa tutto il meccanismo di funzionamento. Quindi, per poter usufruire dei servizi del Servlet nella pagina JSP, occorre avere un modo per accedere a questi oggetti: a questo scopo esistono gli oggetti impliciti JSP, utilizzabili in tutti gli scriptlet. Eccone un elenco. Request Corrisponde generalmente all oggetto ServletRequest passato come parametro al metodo service(); può essere una qualunque sottoclasse di ServletRequest; generalmente si tratta di una sottoclasse di HttpServletRequest. Response Corrisponde all oggetto ServletResponse passato come parametro al metodo service() del Servlet; può essere una qualunque sottoclasse di ServletResponse; generalmente si tratta di una sottoclasse di HttpServletResponse. Out Poichè il container deve fornire un meccanismo di buffering, non è dato accesso direttamente all oggetto PrintWriter restituito da response.getwriter(). L oggetto out è invece uno stream bufferizzato di tipo javax.servlet.jsp.jspwriter, restituito da un metodo del PageContext. Il trasferimento sullo output stream del ServletResponse avviene in un secondo tempo, dopo che tutti i dati sono stati scritti sull oggetto out. Page É un riferimento all oggetto che gestisce la richiesta corrente, che si è vista essere generalmente un Servlet. In Java corrisponde al this dell oggetto, pertanto è di scarsa utilità. Si presume risulti utile con altri linguaggi di script. PageContext Si tratta di un oggetto della classe javax.servlet.jsp.pagecontext utilizzata prevalentemente per incapsulare oggetti e features particolari di ciascuna implementazione del container. Il PageContext viene utilizzato anche per condividere oggetti tra diversi elementi. Session Corrisponde all oggetto HttpSession del Servlet, viene restituito da un metodo del PageContext.

95 3.5 Le Java Server Pages (JSP) Esempio Lista Prodotti (carrello) Questo esempio mostra l utilizzo di JSP e i vantaggi rispetto alle servlet quando occorre creare dinamicamente pagine Web complesse in cui la maggior parte del contenuto è statico. L esempio mostra una bozza di un possibile sito per l acquisto di prodotti on-line. Tutte le pagine JSP fanno uso della classe Prodotto che forniscono due metodi statici per ottenere la lista di tutti i prodotti acquistabili e per ottenere le informazioni di un prodotto attraverso il nome. Per semplicità l esempio assume che non possano esistere due prodotti con lo stesso nome e quindi il nome può essere preso come chiave. Il repository è implementato come un file di testo. L interazione inizia dalla pagina JSP nel Listato 3.14 (vedi Figura 3.6) dove vengono visualizzate la lista dei prodotti esistenti. Si osservi come la tabella inserita in una form sia generata dinamicamente. Anche lo stesso campo di testo è generato dinamicamente con il nome uguale al prodotto che rappresenta. L utente inserisce nei campi di testo le quantità desiderate dei singoli prodotti e preme il bottone di submit. A questo i parametri delle form (cioè il nome dei prodotti con le loro quantità) sono passati alla pagina JSP addcarrello.jsp (vedi Listato 3.15 e Figura 3.7). La seconda pagina JSP utilizza l attributo Carrello della sessione per memorizzare una Hashtable che contiene le associazioni tra le chiavi (i nomi dei prodotti) e i valori (le quantità nel carrello). La pagina JSP carrello.jsp mostra il resoconto dei prodotti nel carrello. Essa fa uso dell attributo Carrello della sessione per ottenere le informazioni sui prodotti nel carrello.

96 3.5 Le Java Server Pages (JSP) 95 package examplejsp; import java.io.*; import java.util.*; public class Prodotto private String nome; private float prezzo; private String marca; private Prodotto () public String getnome () return (nome); public float getprezzo () return (prezzo); public String getmarca () return (marca); public static Vector listaprodotti() /*Per ogni prodotto crea un oggetto Prodotto ed aggiungilo al vector*/ Vector lista = new Vector(); String nome; try BufferedReader riga = new BufferedReader (new FileReader ("C:\\ListaProdotti.txt")); nome = riga.readline(); while(nome!=null) Prodotto p = new Prodotto(); p.nome = nome; p.marca = riga.readline(); p.prezzo = Float.parseFloat(riga.readLine()); lista.addelement(p); nome = riga.readline(); Listato 3.12: Classe Prodotto

97 3.5 Le Java Server Pages (JSP) 96 catch (IOException err) return null; return(lista); public static Prodotto getprodottobyname(string unnome) try String nome; FileReader in = new FileReader ("C:\\ListaProdotti.txt"); BufferedReader riga = new BufferedReader (in); nome = riga.readline(); while(!nome.equals(unnome) && nome!=null) riga.readline(); riga.readline(); nome = riga.readline(); if (nome.equals(unnome)) Prodotto p = new Prodotto(); p.marca = riga.readline(); p.prezzo = Float.parseFloat(riga.readLine()); p.nome = nome; return (p); else return null; catch (IOException err) return null; Listato 3.13: Classe Prodotto (continuo)

98 3.5 Le Java Server Pages (JSP) 97 <html> page import = "java.util.*, examplejsp.*" %> <% Vector listaprodotti=prodotto.listaprodotti(); %>... <body>...<form method="get" action="addcarrello.jsp"> <table border="1" width="100%" id="table1" height="172"> <tr> <td align="center" height="20"> <b><font size="2">nome</font></b> </td> <td align="center" height="20"> <b><font size="2">marca</font></b> </td> <td align="center" height="20"> <b><font size="2">prezzo</font></b> </td> <td align="center" width="148" height="20"> <b><font size="2">àquantit</font></b> </td> </tr> <% int size=listaprodotti.size(); for (int i=0;i<size;i++) Prodotto p=(prodotto)listaprodotti.get(i); %> <tr> <td><%= p.getnome() %></td> <td><% out.print(p.getmarca()); %></td> <td><% out.print("euro "+p.getprezzo()); %></td> <td> <p><input type="text" name="<%= p.getnome() %>" size="20" value="0"></p> </td> </tr><% %> </table> <p align="center"><button>aggiungi</button></p> </form>... </body></html> Listato 3.14: homepage.jsp

99 3.5 Le Java Server Pages (JSP) 98 Figura 3.6: La Homepage Figura 3.7: La pagina Aggiunti al Carrello

100 3.5 Le Java Server Pages (JSP) 99 <html> page import = "java.util.*, examplejsp.*" %>... <body> <p align="center"><i> <font size="4"> Sono stati aggiunti al carrello i seguenti prodotti: </font></i></p> <% Enumeration e = request.getparameternames(); int counter = 0; Hashtable carrello = (Hashtable)session.getAttribute("Carrello"); if(carrello==null) carrello = new Hashtable(); session.setattribute("carrello", carrello); while(e.hasmoreelements()) String nome = (String)e.nextElement(); int quantita = Integer.parseInt(request.getParameter(nome)); %> <ul> <% if(quantita!=0) out.println("<li>"+quantita+" "+nome+"</li>"); counter = counter+1; Integer q = (Integer)carrello.get(nome); int v=0; if (q!=null) v=q.intvalue(); Integer vquantita = new Integer(v+quantita); carrello.put(nome, vquantita); %> </ul> <% if(counter==0) out.println("non e stato selezionato alcun prodotto!"); %>...</body></html> Listato 3.15: addcarrello.jsp

101 3.5 Le Java Server Pages (JSP) 100 <html> page import = "java.util.*, examplejsp.*" %>... <body> <font size="4"> Il carrello contiene attualmente i seguenti prodotti:</font> <table border="1" width="100%" id="table1"> <tr> <td align="center"> <b><font size="2">nome</font></b> </td> <td align="center"> <b><font size="2">marca</font></b> </td> <td align="center"> <b><font size="2">prezzo unitario</font></b> </td> <td align="center"> <b><font size="2">quantita</font></b> </td> </tr> <% Prodotto prodotto; Hashtable carrello = (Hashtable)session.getAttribute("Carrello"); Enumeration enum = carrello.keys(); while(enum.hasmoreelements()) String nome = (String)enum.nextElement(); prodotto = Prodotto.getProdottoByName(nome); out.println("<tr><td>"); out.println(nome); out.println(prodotto.getmarca()); out.println("</td><td>"); out.println(prodotto.getprezzo()); out.println("</td><td>"); out.println(carrello.get(nome)); out.println("</td>"); out.println("</tr>"); %> </table>...</body></html> Listato 3.16: carrello.jsp

102 3.5 Le Java Server Pages (JSP) 101 Figura 3.8: La pagina del Carrello

103 Capitolo 4 JMS: Enterprise Messaging (ed introduzione su MOM) Figura 4.1: Schematizzazione di un Message Oriented Middleware 102

104 4.1 Introduzione al MOM (richiami) Introduzione al MOM (richiami) Con il termine messaging si definisce un meccanismo che permette la comunicazione asincrona tra client (detti peer-element) mediante scambio di messaggi caratterizzato da uno scarso grado di accoppiamento. Data questa definizione si può considerare messaging system un qualsiasi sistema che scambi pacchetti TCP/IP tra programmi client. Piuttosto che creare un meccanismo di messaging specifico per ogni situazione che richieda lo scambio di dati, diversi produttori hanno creato un sistema che permette di scambiare messaggi tra applicazioni diverse in modo generico. Questi sistemi sono chiamati Message Oriented Middleware (MOM). Tramite l infrastruttura middleware del MOM (Figura 4.1), processi residenti su macchine diverse possono interagire tra loro mediante l invio e ricezione di messaggi tipicamente asincroni. È importante notare che si è in presenza di un sistema di messaging peer-to-peer dove i client interagiscono tra loro non in modo diretto, bensì mediante un messaging server, che fa le veci del postino : riceve i messaggi dai mittenti ( produttori ) e li recapita ai relativi destinatari ( consumatori ). Grazie alla mediazione del messaging server, i client risultano essere disaccoppiati, cioè non devono sapere nulla l uno dell altro. Il disaccoppiamento nei MOM è una caratteristica molto importante ed è maggiore rispetto ai sistemi middleware basati su architettura ORB (Object Request Broker). Si pensi ad esempio a RMI o CORBA: per poter comunicare con un oggetto remoto, un applicazione deve essere a conoscenza dei suoi metodi, in modo da poterli invocare. Nei sistemi MOM, i client non interagiscono direttamente tra di loro. Inoltre né il produttore né il ricevitore devono essere a conoscenza l uno dell altro. L unica cosa che entrambi devono sapere è il formato del messaggio e la casella di posta (destination) da usare. Altra importante caratteristica offerta dai sistemi MOM è il concetto di Guaranteed Message Delivery (GMD) che garantisce la consegna del messaggio. Al fine di prevenire una perdita di informazioni in caso di crash del message server, i messaggi devono essere resi persistenti (per esempio mediante JDBC) prima di essere recapitati ai consumatori Modelli di Messaging I Message-oriented middleware defiscono due diversi paradigmi di scambio di messaggi (Figura 4.2): point-to-point e publish and subscribe. Il modello di messaging point-to-point (p2p) è caratterizzato dal fatto che più produttori e più consumatori possono condividere la stessa destinazione (queue) e ogni messaggio ha un solo consumatore; questo permette di fatto una comunicazione uno-a-uno. Il modello publish/subscribe (pub/sub) permette

105 4.1 Introduzione al MOM (richiami) 104 Figura 4.2: I Modelli di Messaging supportati da JMS una comunicazione uno-a-molti dal momento che ogni messaggio inserito nella destinazione (topic) può essere inoltrato a tutti i destinatari che si sono dichiarati (subscription) interessati. Point-to-Point Nel modello p2p un client può mandare uno o più messaggi a un altro client.la comunicazione non avviene in modo diretto, bensì condividendo una stessa destinazione verso cui si inviano e da cui si prelevano i messaggi. La destinazione nel modello point-to-point prende il nome di queue ( coda ). Più produttori e più consumatori possono condividere la stessa coda ma ogni messaggio ha un solo consumatore; questo permette di fatto una comunicazione uno a uno. Non ci sono dipendenze temporali tra sender e receiver del messaggio e quindi il ricevente può ricevere il messaggio anche se non era in ascolto sulla coda al momento dell invio. Il messaggio viene tolto dalla coda una volta che il ricevente l ha prelevato confermando (acknowledge) la ricezione al produttore. L utilizzo del messaging p2p è da utilizzare nel caso si abbia l esigenza che ogni messaggio spedito sia ricevuto da un solo consumatore che ne confermi l avvenuta ricezione. PUB/SUB Nel modello publish/subscribe (detto anche sistema di messag-

106 4.2 Introduzione a JMS 105 ing event-driven), i client inviano messaggi a un topic, una coda speciale in grado di inoltrare i messaggi a più destinatari. Il sistema si prende carico di distribuire i messaggi inviati (publish) da più publishers: tali messaggi sono automaticamente ricevuti da tutti i client che hanno effettuato la sottoscrizione (subscribe), cioè che si sono dichiarati interessati alla ricezione. Il modello pub/sub permette quindi una comunicazione uno-a-molti visto che ogni messaggio può avere più consumatori. È il MOM che si occupa di recapitare una copia di ogni messaggio pubblicato agli appropriati destinatari. Il messaggio una volta consumato da tutti i subscriber interessati viene tolto dal topic. I client possono essere dinamicamente publisher oppure subscriber o anche entrambi. Esiste una dipendenza temporale tra publisher e subscriber, visto che il receiver può consumare il messaggio solo dopo essersi sottoscritto (subscription) al topic d interesse, una volta che il client abbia effettivamente inviato il messaggio. Inoltre il receiver deve rimanere attivo, se vuole continuare a ricevere. Molti MOM (tra cui JBOSS) rilassano tale vincolo temporale mediante il concetto di durable subscriptions. Le durable subscriptions infatti permettono di ricevere i messaggi anche se i subscribers non erano in ascolto al momento dell invio del messaggio. L utilizzo di messaging publish/- subscribe è da preferire quando si ha la necessità che ogni messaggio sia ricevuto da più consumatori. Le destinazioni sono accessibili in modo concorrente e si possono definire anche dei filtri per esprimere le condizioni da rispettare affinché un messaggio venga recapitato a una certa destinazione. 4.2 Introduzione a JMS Java Message Service (JMS) è un insieme di API Java che permette di creare, spedire, ricevere e leggere messaggi. JMS è stato sviluppato da Sun insieme ai maggior produttori di sistemi per definire un interfaccia comune indipendente dalla specifica implementazione del sistema di messaging, in modo analogo a quanto avviene con JDBC, JNDI, JCA e così via. L applicazione Java JMS risulta così essere indipendente, oltre che dal sistema operativo, anche dalla specifica implementazione del sistema di messaging. Mediante JMS è quindi possibile interagire con sistemi MOM esistenti quali MQSeries di IBM, Fiorano MQ, Microsoft MQ. Si capisce come lo scarso disaccoppiamento rispetto ai sistemi RPC, l intrinseca asincronia delle operazioni di messaging, la sua integrazione in ambito J2EE (i Message Driven Bean) e l indipendenza dello specifico provider rendono JMS una tecnologia potente, flessibile e fondamen-

107 4.2 Introduzione a JMS 106 Figura 4.3: Gli Attori JMS tale soprattutto per interazioni business-to-business (B2B) e integrazioni di sistemi eterogenei in ambito EAI (Enterprise Application Integration). In un applicazione JMS gli attori coinvolti sono ConnectionFactory, Destination, Connection, Session, MessageProducer, Message e MessageConsumer, come rappresentato in Figura 4.3. Di seguito viene descritto brevemente il compito di ciascun attore JMS. Administered Objects Le Destination (queue/topic) e le ConnectionFactory sono dette administered objects perché incapsulano le specifiche implementazioni dei provider JMS. Gli administered objects sono vendor-dependent, cioè la loro specifica implementazione varia da provider a provider e per questo motivo non sono gestiti all interno del programma Java. Le interfacce JMS permettono allo sviluppatore Java di astrarsi dai dettagli implementativi della specifica versione di MOM, permettendo il riutilizzo del codice al variare dell implementazione JMS, rispettando appieno la filosofia Java. La creazione di ConnectionFactory e di Destination è compito dell amministratore JMS che deve inserirli all interno di un contesto JNDI in un opportuno namespace in modo che possano essere recuperati da qualsiasi client mediante le normali API JNDI. Per inviare messaggi (sender/publisher) o per riceverli (receiver/subscriber), un applicazione JMS client utilizza i servizi JNDI per

108 4.2 Introduzione a JMS 107 ottenere un oggetto di tipo ConnectionFactory e uno o più oggetti di tipo Destination (Queue o Topic). Connection Factory È l administered object utilizzato dal client per ottenere una connessione con il message server. Nel caso point-to-point si utilizza l interfaccia QueueConnectionFactory: Context ctx = new InitialContext(); QueueConnectionFactoryqueueConnectionFactory = (QueueConnectionFactory)ctx. lookup("myqueueconnectionfactory"); mentre nel caso di publish/subscribe si utilizza l interfaccia TopicConnectionFactory: TopicConnectionFactory topicconnectionfactory = (TopicConnectionFactory)ctx. lookup("mytopicconnectionfactory"); Destination È l administered object che rappresenta l astrazione di una particolare destinazione. Anche in questo caso il client identifica la destinazione mediante l utilizzo delle API JNDI. Nel caso point-to-point, la destinazione è rappresentata dall interfaccia Queue: Queue queue = (Queue) jndicontext.lookup("myqueue"); mentre, nel caso di publish/subscribe, si usa l interfaccia Topic: Topic topic = (Topic) jndicontext.lookup("mytopic"); Connection Rappresenta l astrazione di una connessione attiva con un particolare JMS provider e si ottiene dall oggetto ConnectionFactory. Nel caso point-to-point, si ottiene un reference d interfaccia QueueConnection invocando il metodo createqueueconnection sull oggetto Connection Factory: Analogamente, nel caso di publish/subscribe, si ottiene un reference d interfaccia TopicConnection invocando il metodo createtopicconnection() sull oggetto ConnectionFactory:

109 4.2 Introduzione a JMS 108 TopicConnection topicconnection = topicconnectionfactory.createtopicconnection(); Session L interfaccia Session si ottiene dall oggetto Connection e rappresenta il canale di comunicazione con una destinazione: permette la creazione sia di produttori che di consumatori di messaggi. La creazione della sessione permette di specificare il controllo della transazione e la modalità di acknowledge. Nel caso point-to-point, la Session è identificata mediante l interfaccia QueueSession: QueueSession queuesession = queueconnection. createqueuesession(false,session.auto_acknowledge); Nel caso di publish/subscribe, la Session viene identificata tramite interfaccia TopicSession: TopicSession topicsession = topicconnection. createtopicsession(false,session.auto_acknowledge); Messages I messaggi JMS sono costituiti da tre parti: un intestazione (message header), una serie di campi contenenti proprietà (property fields) e il corpo (message body). Il message header è costituito esattamente da 10 campi obbligatoriamente presenti. Tali campi sono valorizzati dal provider o dal client al fine di identificare, configurare e inoltrare il messaggio. Tra questi campi è presente l identificatore univoco del pacchetto (JMSMessageID), il nome della Queue o Topic a cui il pacchetto è destinato(jmsdestination),la priorità (JMSPriority), il timestamp del tempo d inoltro(jmstimestamp), il flag indicante se il messaggio è stato re-inoltrato(jmsredelivered), l ID per correlare i messaggi JMS tra di loro (JMSCorrelationID), la modalità di invio(jmsdeliverymode), la destinazione a cui inoltrare il messaggio di risposta(jmsreplyto). I campi JM- SReplyTo e JMSCorrelationID e il campo opzionale JMSType sono assegnati dall applicazione JMS in modo esplicito sull oggetto Message; tutti gli altri, invece, dal provider JMS. I property fields sono coppie di nome e valore e sono utili per costruire filtri a livello applicativo. La caratteristica di questi campi è che possono essere esaminati mediante i message selectors. Quando

110 4.2 Introduzione a JMS 109 un consumatore si connette al server può definire un message selector il quale esamina l header e i property fields (non il body message) del pacchetto JMS di una specifica destinazione sia essa una Queue o un Topic. Questo permette alle applicazioni JMS di utilizzare i message selector per specificare quali messaggi è interessata a ricevere utilizzando una sintassi condizionale sottoinsieme del linguaggio SQL-92. Il filtraggio avviene a livello di server e permette di inoltrare ai client lungo la rete i messaggi strettamente necessari o utili, risparmiando così la banda del canale. Un message selector non è altro che un oggetto di classe String che può contenere boolean literals(true, true, FALSE e false), operatori logici (NOT, AND, OR), aritmetici (+, -, *, /), di comparazione( =, >, >=, <, <=, < >) di ricerca (IS, LIKE, IN, NOT IN) e così via. Esempi di message selector: "squadra = Pittsburgh Steelers " "squadra <> Dallas Cowboys " "age NOT BETWEEN 20 and 32" "type = FIAT AND color = blue AND weight >= 100" "NewsType = Opinion OR NewsType = Sports " I property field possono essere impostati mediante la classe di metodi setxxxproperty(string name, XXX value) dove XXX possono essere Boolean, Byte, Short, Integer, Long, Float, Double e String e rappresenta il tipo del campo proprietà. Ovviamente esistono i getter corrispondenti XXX getxxxproperty(string name) che restituiscono i valori delle proprietà a partire dal loro nome. Infine le proprietà possono essere cancellate mediante il metodo clearproperties(), lasciando il messaggio JMS senza campi proprietà. Body Message I messaggi JMS possono essere di varie tipi, ognuno dei quali mette a disposizione gli appositi metodi get e set. JMS non supporta uno specifico body per messaggi XML; in questi casi è utilizzabile il text message. I messaggi vengono creati mediante i metodi dell interfaccia Session dalla quale estendono sia l interfaccia QueueSession che TopicSession. L interfaccia mette a disposizione i metodi di creazione relativi a ogni tipologia di message: create- TextMessage, createobjectmessage, createmapmessage, createbytesmessage e createstreammessage, prevedendo per ognuno di essi la versione overloaded che contempla come parametro in ingresso un oggetto di inizializzazione. Per creare messaggi, nel caso di tipologia point-to-point è sufficiente invocare il metodo create opportuno sulla QueueSession, mentre nel caso di pub-

111 4.2 Introduzione a JMS 110 lish/subscribe sull oggetto TopicConnection come mostrato negli esempi che seguono: TextMessage txtmsg = queuesession.createtextmessage(); txtmsg.settext("hello JMS PTP World!"); TextMessage txtmsg2 = queuesession.createtextmessage("hello JMS PTP World!"); ObjectMessage objmsg = queuesession.createobjectmessage(); objmsg.setobject(my_ptp_order); ObjectMessage objmsg2 = topicsession.createobjectmessage(); ObjMsg2.setObject(my_pubSub_chat_msg); MessageProducer Il MessageProducer è l oggetto che permette l invio dei messaggi verso una particolare destinazione. Utilizzando gli oggetti Session e Destination creati, si possono inizializzare uno o più message producer. Nel caso point-to-point, il MessageProducer per inviare messaggi sulla Queue è referenziato mediante l interfaccia QueueSender: QueueSender queuesender = queuesession.createsender(queue); mentre nel caso di publish/subscribe l invio dei messaggi verso il Topic può avvenire mediante l interfaccia TopicPublisher: TopicPublisher topicpublisher = topicsession.createpublisher(topic); Una volta creato il produttore, basta invocare il metodo send sull oggetto QueueSender nel caso PTP, mentre nel caso pub/sub, il metodo publish(string message) va invocato sull oggetto topicpublisher; entrambi i metodi send richiedono in ingresso un parametro d interfaccia Message e presentano firme overloaded. queuesender.send(message); topicpublisher.publish(message); MessageConsumer Il MessageConsumer rappresenta un oggetto in grado di ricevere messaggi. Analogamente a quanto avviene per il MessageProducer, bisogna indicare l oggetto Session e la Destination d interesse per inizializzare correttamente il MessageConsumer.

112 4.2 Introduzione a JMS 111 public class TextListener implements MessageListener public void onmessage(message message) try if (message instanceof TextMessage) TextMessage txtmsg = (TextMessage) message; System.out. println("ricevuto: " + txtmsg.gettext()); catch(jmsexception err) System.err.println("Errore JMS:"+err.getMessage()); Listato 4.1: Esempio di Consumatore Asincrono QueueReceiver queuereceiver = queuesession.createreceiver(queue); TopicSubscriber topicsubscriber = topicsession.createsubscriber(topic); Nella modalità asincrona, il MessageProducer (sender o publisher) non è tenuto ad attendere che il messaggio sia ricevuto per proseguire nel suo funzionamento, e l elaborazione del messaggio stesso non è necessariamente sequenziale. Il MessageConsumer è in grado di ricevere i messaggi in modo asincrono definendo un message listener: si tratta di una classe che implementa l interfaccia javax.jms.messagelistener. Ogni qualvolta un messaggio arriva alla destinazione d interesse viene automaticamente invocato il metodo di callback onmessage(). Il Listato 4.1 mostra l implementazione di un consumatore asincrono: TextListener è una normale classe Java che implementa l interfaccia JMS MessageListener ridefinendo perciò il metodo onmessage(). In tale metodo si mette la logica applicativa per gestire il contenuto del messaggio ricevuto; si effettua il controllo del tipo del messaggio ricevuto e, se è del tipo corretto, se ne elabora il contenuto.

113 4.2 Introduzione a JMS 112 Per associare il consumatore alla coda opportuna occorre creare un oggetto d interfaccia javax.jms.messagelistener: TopicListener topiclistener = new TextListener(); QueueListener queuelistener = new TextListener(); e passarlo come argomento al metodi setmessagelistener dell oggetto Receiver topicsubscriber.setmessagelistener(topiclistener); queuereceiver.setmessagelistener(queuelistener); Connesso il listener, ci si pone in ascolto, in attesa di ricevere ed elaborare i messaggi, invocando il metodo start sull oggetto Connection: queueconnection.start(); topicconnection.start(); I prodotti di messaging sono intrinsecamente asincroni ma è bene specificare che un MessageConsumer può ricevere i messaggi anche in modo sincrono. Nella ricezione dei messaggi in modo sincrono il consumatore richiede esplicitamente alla destinazione di prelevare il messaggio (fetch) invocando il metodo receive. Il metodo receive() appartiene all interfaccia javax.jms.messageconsumer (dalla quale estendono sia QueueReceiver che TopicReceiver) ed è sospensivo, cioè rimane bloccato fino alla ricezione del messaggio, a meno che non si espliciti un timeout finito il quale il metodo termina: public Message receive() throws JMSException public Message receive(long timeout) throws JMSException Esempio di ricezione sincrona: while(<condition>) Message m = queuereceiver.receive(1000); if( (m!=null)&&(m instanceof TextMessage) message = (TextMessage) m; System.out.println("Rx:" + message.gettext()); Finite le operazioni di gestione del messaggio ricevuto, si esegue il cosiddetto codice di pulizia chiudendo la connessione JMS mediante il metodo close.

114 4.2 Introduzione a JMS 113 queueconnection.close(); topicconnection.close();

115 Capitolo 5 Enterprise Java Bean (EJB) Gli Enterprise Java Bean (EJB) sono componenti di un architettura lato server utilizzati per semplificare il processo di sviluppo delle applicazioni a componenti in Java. Infatti, usando gli EJB è possibile produrre facilmente e velocemente applicazioni server-side e applicazioni scalabili per sistemi distribuiti. Il vantaggio di poter disporre di tali componenti risiede nel fatto che in questo modo è possibile concentrarsi meglio nella scrittura del codice necessario per la propria applicazione e quindi nella realizzazione di una applicazione server robusta piuttosto che sullo sviluppo del middleware. 5.1 Introduzione agli EJB Essendo gli Enterprise JavaBeans (EJB) componenti standard della tecnologia server-side in Java è possibile utilizzarli su qualsiasi tipologia di applicazione server. Per tale motivo c è stata una notevole diffusione nell utilizzo degli EJB, si è cercato quindi di facilitarne la comprensione e l apprendimento, ma soprattutto si è resa particolarmente efficiente la loro portabilità a seguito della pubblicazione delle specifiche. Una critica che si può fare verso tali componenti è che questi devono essere scritti esclusivamente in linguaggio java. Questa, che apparentemente potrebbe sembrare una restrizione, in realtà è compensata dal fatto che Java è un linguaggio ideale nella costruzione di componenti, per diverse ragioni tra cui: Separazione interfaccia/implementazione: Secondo il paradigma MVC, la separazione tra interfaccia e implementazione consente maggiore modularità. Lo strato di presentation è separato, dunque posso aggiornare il mio portale senza aggiornare la logica o viceversa. Gli EJB 114

116 5.1 Introduzione agli EJB 115 non sono come i componenti GUI (Graphical User Interface), cioè non sono visibili agli utenti, anzi agiscono dietro di essi ed eseguono il vero lavoro. La differenza principale tra GUI ed EJB sta nel loro dominio applicativo. I GUI sono componenti lato client, cioè agiscono direttamente per il client creando interfacce grafiche o piccole operazioni logiche. Gli EJB, d altra parte, sono componenti lato server, effettuano operazioni server come eseguire complessi algoritmi o eseguire un gran numero di transazioni; i loro componenti hanno bisogno di essere sempre in esecuzione e forniscono inoltre un sicuro ambiente multiutente transazionale. In un paradigma MVC (Model View Controller), attraverso gli EJB viene implementato lo strato di logica applicativa, cioè le applicazioni vere e proprie che realizzano le funzionalità del sistema. Per questo gli EJB non prevedono interazione diretta con i client. Per accedere agli EJB vengono utilizzati i GUI (che implementano la parte del Controller). Sicurezza: L architettura Java è molto più sicura dei tradizionali linguaggi di programmazione sotto diversi punti di vista. Infatti con il linguaggio Java si hanno perdite di dati in memoria meno frequenti, maggior robustezza. Per esempio, se durante una comunicazione cade un Thread realizzato in linguaggio Java, l applicazione continua la sua esecuzione. Inoltre Java comprende una ricca serie di librerie, che permette agli sviluppatori di non reinventare codice riducendo il rischio di creare errori. Portabilità: Java gira su qualsiasi piattaforma. Questo significa che gli EJB non hanno problemi di portabilità, e quindi possono essere utilizzati senza alcun problema anche da coloro che hanno investito su diverse piattaforme (UNIX, win32 e mainframes). Generalmente gli EJB sono utilizzati in modo specifico per aiutare a risolvere business problems. Per tale ragione essi possono eseguire qualunque dei seguenti task: Eseguire business logic: Cioè implementare la logica di un applicazione server side, per esempio attraverso l utilizzo della JavaMail API, gli EJB possono essere utilizzati ad esempio per elaborare il pagamento delle tasse di un attività, per verificare i permessi degli utenti che approvano degli ordini di acquisto o mandano una conferma di un ordine.. Accedere ad un database: L accesso al database avviene attraverso l uso delle Java Database Connectivity (JDBC) API. Tale accesso può essere

117 5.2 Fondamenti degli EJB 116 richiesto per esempio per immettere un ordine di alcuni libri, trasferire del denaro tra due conti bancari. Accedere ad un altro sistema: Gli EJB ottengono questa integrazione con il Java Connector Architecture (JCA). Un esempio di tale integrazione può essere il collegamento ad un sistema COBOL che elabora il fattore di rischio per una nuova assicurazione. 5.2 Fondamenti degli EJB Un Enterprise Bean può essere composto da uno o più oggetti Java, in quanto un componente potrebbe essere composto da più di un oggetto semplice. La tecnologia EJB si basa su altre due tecnologie: java RMI-IIOP e JNDI. I client di un EJB possono riferirsi ad esso senza preoccuparsi di come sia composto, cioè può essere utilizzato come una scatola nera. In particolare il funzionamento avviene nel seguente modo: il client del bean utilizza una semplice interfaccia pubblica la quale deve contenere le stesse specifiche del bean; tali specifiche obbligano il bean ad avere alcuni metodi definiti, i quali permettono all EJB Container di maneggiare i bean senza preoccuparsi di quale sia in esecuzione. Un EJB è sempre contenuto in un EJB Container. I Container amministrano i componenti in modo da ottimizzare l uso di risorse (es. pooling). Un contenitore EJB è responsabile per mediare l accesso di un EJB alle risorse. Chiunque può chiamare un enterprise bean, una servlet, un applet o un altro bean. Quest ultimo caso può dar vita ad una lunga catena di chiamate. Tale compito, notevolmente complesso se realizzato manualmente dal programma seguendo tutte le chiamate, può essere suddiviso utilizzando una varietà di bean già scritti che gestiscono i sotto compiti. Esistono 3 tipi diversi di EJB: Session Beans. Rappresentano le sessioni di interazione con i client. Possono eseguire qualunque tipo di azione, dal sommare i numeri ad accedere ad un database o chiamare un altro Bean. I Session Bean hanno la caratteristica di essere transienti: il loro stato non viene memorizzato in modo persistente in un database o simili. Entity Beans. Sono i dati di un applicazione, ne rappresentano gli oggetti di business, (es. prodotti agli ordini, numeri di carta di credito di un applicazione di ecommerce). Tipicamente gli entity bean sono gestiti dai session bean per raggiungere un obiettivo. Sono memorizzati in modo

118 5.2 Fondamenti degli EJB 117 Figura 5.1: Catena di invocazioni da applicazioni Swing persistente spesso, un istanza di entity Bean corrisponde ad una tupla di un DB. Message-Driven Beans. I Message-Driven Beans sono simili ai session bean. La differenza principale riguarda l attivazione, in particolare essi possono essere attivati solo tramite l invio di messaggi, infatti i Message-Driven Beans restano in ascolto su un topic/coda JMS e si attivano solo quando un messaggio è inviato a quel topic/coda. Possono essere utilizzati per chiamare un altro enterprise beans. Un aspetto rilevante di tale tecnologia è dato dalla possibilità di incrociare le chiamate tra bean (Figura 5.1) ovvero quando un client chiama in modo sincrono un bean, quest ultimo potrebbe aver bisogno di alcuni dati, per eseguire i propri metodi, che sono reperibili solo attraverso un ulteriore chiamata ad un entity bean. La stessa modalità di incrociare le chiamate può avvenire anche con l uso dei message-driven bean, i quali possono essere attivati a seguito della ricezione di un messaggio da un client su una coda/- topic JMS, e come i session bean possono invocare successivamente gli entity bean per eseguire l applicazione. Queste azioni possono essere eseguite anche attraverso browser internet grazie alle JSP/Servlet, i quali possono invocare i session bean o i message bean. Queste azioni sono mostrate in Figura 5.2 La tecnologia EJB, come l RMI, è basata su oggetti distribuiti. La Figura 5.3 mostra come avviene il collegamento tra un client ed un oggetto distribuito, in particolare, essa mostra come: 1. Il client chiama lo stub, che è un oggetto proxy client-side. Lo stub è responsabile di mascherare la comunicazione sulla rete dal client, attraverso l uso delle sockets, e quando necessario, attraverso la conver-

119 5.2 Fondamenti degli EJB 118 Figura 5.2: Catena di invocazioni da pagine Internet tramite JSP/Servlet Figura 5.3: Chiamata di un oggetto distribuito

120 5.3 Scheletro di un Enterprise Bean 119 sione dei parametri nella rappresentazione della rete, lo stub comunica attraverso la rete. 2. Lo stub chiama lo skeleton, il quale è un oggetto proxy server-side. Lo skeleton maschera le comunicazioni sulla rete dell oggetto distribuito, riceve una chiamata dalla socket e converte i parametri ricevuti in un opportuna rappresentazione Java. 3. Lo skeleton passa la chiamata all oggetto distribuito, il quale esegue dei compiti. Una volta eseguiti tali compiti, tale oggetto passa di nuovo il controllo allo skeleton, il quale successivamente passa la chiamata dapprima allo stub e poi di nuovo al client. Un punto chiave è che sia lo stub che l oggetto distribuito implementano la stessa interfaccia (Remote Object), questo significa che lo stub clona la segnalazione dei metodi, e il client che invoca i metodi sullo stub crede in realtà di eseguire i metodi dell oggetto distribuito. Generalmente gli oggetti distribuiti sono complessi da costruire interamente, per tale motivo ci sarà bisogno dei servizi Middleware, come per esempio quelli per la gestione delle transazioni e della sicurezza. Ci sono due diversi tipi di Middleware: Esplicito e Implicito. La differenza principale tra l una e l altra tipologia risiede nella quantità di codice da scrivere; infatti, nel primo caso bisogna invocare direttamente i middleware API necessari al raggiungimento dell obiettivo, nel secondo caso, invece, la richiesta dei servizi viene delegata ad un Request Interceptor che provvederà a chiamare i servizi middleware richiesti. Ciò avviene attraverso la creazione di uno speciale file descrittore. 5.3 Scheletro di un Enterprise Bean Un Enterprise Bean non è un file monolitico, ma è costituito da un insieme di file che lavorano per creare il bean Enterprise Bean Class La prima parte del bean è costituita dall implementazione vera e propria, il vero oggetto distribuito, cioè quel file che contiene i metodi della logica di business, chiamato Enterprise Bean Class. Questa è una classe Java conforme ad una interfaccia well-defined e obbedisce a regole certe che permettono al bean di poter essere eseguito in ogni Container.

121 5.3 Scheletro di un Enterprise Bean 120 public interface javax.ejb.enterprisebean extends Serializable Listato 5.1: L interfaccia javax.ejb.enterprisebean Le specifiche dell EJB definiscono poche interfacce standard che il bean può implementare, le quali forzano il bean a fornire dei metodi, come definito dal modello dei componenti EJB. L EJB Container chiama questi metodi per allertare o informare il bean di alcuni eventi significativi. L interfaccia base che tutti i bean devono implementare è la javax.ejb.enterprisebean, mostrata nel Listato 5.1 Questa interfaccia contrassegna il bean come un vero enterprise bean class. L aspetto interessante di questa interfaccia è che estende java.io.serializable, ciò significa che tutti gli enterprise bean possono essere convertiti in un flusso di byte e condividere tutte le proprietà degli oggetti serializabili. Session Beans, Entity Beans e Message-driven Beans hanno tutti un interfaccia che estende la javax.ejb.enterprisebean. Tutti i Session Bean devono implementare la javax.ejb.sessionbean; tutti gli Entity Bean devono implementare la javax.ejb.entitybean; tutti i Message-driven Bean devono implementare la javax.ejb.messagedriverbean. Quindi il bean non deve implementare direttamente la javax.ejb.enterprisebean, ma piuttosto implementare l interfaccia corrispondente al proprio tipo L EJB Object Quando un client vuole usare un istanza dell enterprise class, non può invocare mai direttamente l istanza. Piuttosto l invocazione viene intercettata dall EJB Container e in seguito delegata all istanza del bean. Questo è il concetto del request interceptor accennato in precedenza. Grazie ad esso, l EJB Container può eseguire automaticamente il middleware implicito. Tale modo di operare facilita lo sviluppo perchè non si deve scrivere, correggere o mantenere il codice che chiama i middleware API, quindi, il container agisce come un livello intermedio tra il cliente e il bean. Questo livello viene chiamato EJBObject. L EJBObject viene generato automaticamente dal container in quanto cambia per ogni bean Remote Interface Il client invoca i metodi sull EJBObject, piuttosto che sul bean, per tale motivo l EJBObject deve clonare tutti i metodi che il bean espone. Questo

122 5.3 Scheletro di un Enterprise Bean 121 public interface javax.ejb.ejbobject extends java.rmi.remote public javax.ejb.ejbhome getejbhome() throws java.rmi.remoteexception; public java.lang.object getprimarykey() throws java.rmi.remoteexception; public void remove() throws java.rmi.remoteexception, javax.ejb.removeexception; public javax.ejb.handle gethandle() throws java.rmi.remoteexception; public boolean isidentical(javax.ejb.ejbobject) throws java.rmi.remoteexception; Listato 5.2: L interfaccia javax.ejb.ejbobjeect avviene attraverso un interfaccia speciale: la Remote Interface. Questa interfaccia deve essere conforme alle regole definite dalle specifiche EJB; per esempio: tutte le remote interface devono derivare da una interfaccia comune, cioè dalla javax.ejb.ejbobject descritta nel Listato 5.2 Questi metodi verranno implementati dal container e non dal client; la remote interface estende anche java.rmi.remote, ciò fornisce la possibilità di chiamare tale oggetto da un altra Java Virtual Machine. La remote interface deve essere conforme alla convenzione RMI-IIOP dei parametri passati L Home Object Si è visto che il client invoca direttamente l EJBObject invece del bean, in realtà ciò può avvenire solo se il client ha modo di avere il riferimento a questo oggetto. In particolare, il client ottiene il riferimento attraverso una fabbrica di EJBObject: l Home Object. Quest oggetto è responsabile della creazione, ricerca e rimozione di un EJBObject. Come l EJBObject, l home object è specifico per ogni bean. La differenza è che per ogni bean si ha un unica istanza dell Home Object, invece gli EJB Object sono tanti quanti sono i client che richiedono l uso di quel bean.

123 5.3 Scheletro di un Enterprise Bean 122 public interface javax.ejb.ejbhome extends java.rmi.remote public EJBMetaData getejbmetadata() throws java.rmi.remoteexception; public void remove(javax.ejb.handle) throws java.rmi.remoteexception, javax.ejb.removeexception; public javax.ejb.homehandle gethomehandle() throws java.rmi.remoteexception; public void remove(object) throws java.rmi.remoteexception, javax.ejb.removeexception; Listato 5.3: L interfaccia javax.ejb.ejbhome Home Interface L Home Interface permette al client di inizializzare correttamente un EJBObject. Per esempio se un EJBObject ha due costruttori, uno che prende in ingresso un intero e l altro che prende in ingresso una stringa, tramite l home interface il client sceglie quale costruttore usare, e come ritorno si ha il puntatore all EJBObject mascherato dalla remote interface. Come per la remote interface, l home interface deve estendere l interfaccia javax.ejb.ejbhome illustrata nel Listato 5.3 L home object deriva dalla java.rmi.remote, il che significa che può essere invocato attraverso la rete. Inoltre, i tipi di parametri passati nei metodi della home interface devono essere tipi validi per la Java RMI-IIOP Le interfacce locali Un problema rilevante che si riscontra con l utilizzo delle home interface e delle remote interface è nella lentezza della loro creazione. Di seguito sono riportati tutti i passi che devono essere eseguiti al fine di creare una home interface: 1. Il client chiama lo stub locale. 2. Lo stub converte i parametri nel formato adatto alla rete.

124 5.3 Scheletro di un Enterprise Bean Lo stub si connette attraverso la rete allo skeleton. 4. Lo skeleton riconverte i parametri nel formato adatto a Java. 5. Lo skeleton chiama l EJB object 6. L EJB object esegue i middleware necessari 7. Una volta che l EJB object chiama l istanza dell enterprise bean e il bean esegue il suo lavoro, ogni passo precedente deve essere ripetuto per ritornare al client. Come si può notare è un percorso piuttosto laborioso; per tale motivo un modo più efficiente per invocare un EJB è riferirsi alle interfacce locali: local object invece che EJB object e local interface al posto della remote interface. In tal caso il processo di chiamata attraverso le interfacce locali sarà: 1. Il client chiama un local object. 2. Il local object esegue le operazioni necessarie. 3. Una volta che l enterprise bean ha finito il suo lavoro restituisce il controllo al local object che lo restituisce al client. E evidente che con tale approccio si salta tutta la parte relativa alla rete, dalle chiamate allo stub e allo skeleton fino al marshalling/unmarshalling dei parametri. Le local interface estendono la javax.ejb.ejblocalobject mentre le home interface estendono la javax.ejb.ejblocalhome. Il codice di queste classi è mostrato nel Listato 5.4 Lo svantaggio nell utilizzo di tali interfacce locali sta nel fatto che esse non estendono le classi RMI e quindi, per tale motivo, non possono essere chiamate da client remoti ma solo da bean presenti nello stesso processo, inoltre, il passaggio dei parametri non avviene per valore ma per riferimento e ciò comporta un cambio nella semantica dell applicazione client Deployment Descriptor Per comunicare al container quali middleware utilizzare si devono dichiarare i servizi che il componente richiede in un deployment descriptor file.

125 5.3 Scheletro di un Enterprise Bean 124 public interface javax.ejb.ejblocalobject public javax.ejb.ejblocalhome getejblocalhome() throws javax.ejb.ejbexception; public java.lang.object getprimarykey() throws javax.ejb.ejbexception; public void remove() throws javax.ejb.ejbexception; javax.ejb.removeexception; public boolean isidentical(javax.ejb.ejblocalobject) throws javax.ejb.ejbexception; public interface java.ejb.ejblocalhome public void remove/java.lang.object) throws javax.ejb.ejbexception; javax.ejb.removeexception; Listato 5.4: Interfacce locali

126 5.4 Session Bean Session Bean Un Session Bean rappresenta una sessione di interazione con i client. Esso implementa la logica di business, le regole di business e gli algoritmi. E un componente riusabile che contiene i processi della logica di business. Un Session Bean rappresenta un singolo client nell Application Server. Il client accede al Business Layer di una applicazione invocando i metodi dei Session Beans. I Session Beans nascondono la complessità della logica di business dietro a chiamate semplici. Un importante differenza tra Entity Bean e Session Bean sta nel fatto che i session bean sono componenti a vita breve, mentre gli entity bean possono vivere per anni perche sono oggetti persistenti e fanno parte di sistemi di salvataggio permanente (come ad esempio i database). La vita di un session bean dura il tempo dell esecuzione dei metodi richiesti dal client. Generalmente la lunghezza della sessione del client determina il tempo in cui il session bean sara in uso. L EJBContainer ha l autorità di distruggere i session bean se il client va in time out. Tipicamente i session bean non sopravvivono ai crash dell applicazione e sicuramente non sopravvivono ai crash della macchina. I session bean sono non persistenti, cio significa che non vengono salvati su un archivio fisico. Essi possono eseguire azioni su database ma non possono essere salvati su di esso. Tutti gli enterprise bean ottengono una conversazione con i client. Una conversazione è un interazione tra client e bean, ed è composta da una serie di metodi chiamati tra il client e il bean. Esistono due tipi di session bean: stateful session bean e stateless session bean, ognuno dei quali modella un tipo diverso di conversazione. Stateless Session Bean Le conversazioni di alcuni processi si limitano semplicemente ad una sola richiesta. Un singolo processo non ha bisogno di mantenere uno stato tra le diverse invocazioni dei metodi. Dopo ogni invocazione, il container può decidere di distruggere il bean, ricrearlo o pulirlo di tutte le informazioni contenute su di esso nelle passate invocazioni. Un tipico esempio di stateless session bean è un motore ad alte prestazioni che risolve complesse operazioni matematiche, come la compressione o la decompressione di dati audio o video. Dal momento che i session bean non hanno stato, tutte le istanze dello stesso bean sono equivalenti e indistinguibili dal client. Non importa quale istanza è stata invocata da un client specifico, ogni stateless session bean può servire ogni richiesta di un client.

127 5.4 Session Bean 126 Stateful Session Beans In alcuni processi è necessario ricordare lo stato della conversazione, cioè lo stato del sistema. Per esempio potrebbe essere necessario ricordare cio che abbiamo immesso nel carrello della spesa di un sito web. I bean di tipo stateful contengono variabili che hanno il compito di mantenere lo stato della sessione del client. Quando un client invoca un metodo sul bean, il client fa partire una conversazione con il bean. Questa conversazione viene salvata dal bean e deve essere accessibile ad ogni chiamata dello stesso client. Per limitare il numero di bean presenti in memoria (per non sovraccaricare la memoria fisica del computer), l EJB container esegue l operazione di pooling. Questa operazione consiste nell esecuzione di uno swap out dello stato della conversazione dalla memoria fisica nell hard disk quando sono presenti troppi bean in memoria. Successivamente, quando il client richiede l uso del bean, il container esegue uno swap in della conversazione nel bean. L operazione di salvataggio del bean su un archivio permanente viene chiamata passivazione. L operazione inversa viene chiamata attivazione. E da notare che, quando la conversazione viene riattivata, il bean potrebbe non essere quello originario. Questo non costituisce un problema in quanto cio che interessa non è il bean stesso ma lo stato della conversazione tra il bean e il client. Come si può immaginare, lo stato della conversazione deve seguire le regole della Java object serialization. Quando un bean viene messo in modalità passiva, il container usa il protocollo serialization per convertire lo stato della conversazione in un flusso di dati, formato che consente la scrittura su disco. L istanza del bean continua ad esistere, e può essere assegnata ad un altra conversazione con un nuovo client. Il processo di attivazione è l inverso: un dato che è stato salvato su hard disk viene riletto, riportato in memoria e riconvertito nella modalità appropriata. L interfaccia Serializable, che l enterprise bean indirettamente implementa, permette tali processi. Quando l EJB container passa una conversazione in modalità passiva, informa il bean chiamando uno dei metodi che devono essere implementati obbligatoriamente: ejbpassivate(). Questo metodo notifica al bean che la conversazione sta per essere trasferita su disco rigido. In questo modo il bean può rilasciare le risorse che in altri momenti aveva occupato, come una connessione ad un database, l apertura di una socket, un file aperto, o altre risorse che non possono essere salvate usando la serializzazione. Quello che accade durante l attivazione è l esatto opposto. Lo stato della conversazione viene riportato in memoria, successivamente il container chia-

128 5.4 Session Bean 127 ma il metodo richiesto ejbactivate(), che dà l opportunità di riaprire le risorse che erano state chiuse nella fase di passività. Nel caso in cui non ci sono risorse da rilasciare come le socket o le connessioni a database, non c è bisogno di implementare questi metodi Esempi Nelle sezioni che seguono vedremo in pratica come viene creato un EJB attraverso alcuni esempi. Il primo esempio sarà un Session Bean Stateless: il bean avrà due metodi per la cifratura e la decifratura di una stringa secondo una chiave numerica inserita. Il secondo esempio sarà un semplice Session Bean Stateful: questo bean conterrà semplicemente il numero di chiamate da parte del client (un numero passato dal client oppure l intero 1 in caso di nessuna comunicazione). Quando si crea un componente EJB, i tipici passi da eseguire sono i seguenti: 1. Scrivere le classi.java che compongono il bean: le interfacce remote, le home interface, la enterprise bean class e tutte le altre classi necessarie all applicazione. 2. Scrivere il deployment descriptor. 3. Compilare le classi creando i file.class 4. Creare un file EJB-jar che contiene le classi java e il deployment descriptor, secondo uno schema che vedremo in seguito. 5. Installare il bean all interno del Container (per esempio JBoss). 6. Configurare il container per le esigenze del bean (per esempio le connessioni al database o la dimensione del pooling). 7. Far partire il Container e verificare se il bean è stato installato correttamente. 8. Opzionalmente creare una applicazione stand-alone per testare la funzionalità effettiva del bean creato Ciclo vita dei Session Bean Session Bean Stateless Quando è stato realizzato il bean e installato all interno del container, è quest ultimo che si prende l onere di gestire la sua vita, dalla creazione alla

129 5.4 Session Bean 128 Figura 5.4: Schema del ciclo vita di un stateless session bean cancellazione. In figura è mostrato lo schema del ciclo vita del Session Bean Stateless. Quando un client richiede la creazione di un Session Bean Stateless, il Container può agire in due modi differenti: - Creare un nuovo EJB e quindi aggiungerlo al pool dei Session Stateless. Questo comporta l invocazione dei metodi 1 e 2 mostrati in Figura 5.4. Dopo l invocazione del metodo ejbcreate, ovvero dopo che il client chiama il metodo create, il bean si trova nello stato Ready e quindi il client può invocare i business methods. - Restituire un bean già creato e presente nel pool. Il client non potrà mai sapere che non è stato creato in quanto i bean stateless sono indistinguibili, non hanno stato. Dopo l utilizzo del bean e alla fine della sessione, il container può eliminare l EJB dal pool, dopo aver invocato il metodo ejbremove, oppure non effettuare nessuna operazione invocando il bean alla richiesta di un nuovo bean. Come si vede dallo schema, i metodi ejbactivate e ejbpassivate possono anche venir lasciati vuoti in quanto non verranno mai chiamati. Session Bean Stateful In Figura 5.5 è mostrato il ciclo di vita di un stateful session bean. Da ricordare che i metodi del bean sono chiamati dal container, non dal client. Questo ciclo di vita è molto simile a quello di un stateless session bean, ma ci sono alcune grandi differenze:

130 5.4 Session Bean 129 Figura 5.5: Schema del ciclo vita di un stateful session bean - Il container non può restituire un altro bean presente nel pool in quanto il suo stato appartiene ad una conversazione precedente e quindi diversa da quella scelta. - Esistono le transazioni tra lo stato attivo e passivo. Quando il client richiede la creazione di un Session Bean Stateless, l EJB container crea un nuovo bean, usato solo da quel client, ed invoca i metodi 2 e 3 del grafico. Ora il bean è pronto a ricevere invocazioni remote per i suoi metodi di business. Mentre si trova nello stato attivo, il container può decidere di disattivare il bean, facendo lo swap in memoria secondaria, o eliminarlo. Quando avviene questa disattivazione, il container chiama il metodo ejbpassivate e successivamente lo disattiva. Se decide di eliminarlo, chiama prima il metodo ejbremove e poi elimina il bean ed il suo stato. Quando il client invoca un metodo sul bean passivo, il container lo attiva, chiama il metodo ejbactivate, e lo riporta in modalità Ready. Se il bean si trova in modalità passiva può andare in timeout ed in tal caso il container elimina direttamente il bean Creazione di un Session Bean Stateless L interfaccia remota Il primo passo consiste nello scrivere l interfaccia remota. L interfaccia remota duplica tutti i metodi implementati dall enterprise bean class. Il codice è mostrato nel Listato 5.5 (e fa riferimento ad un applicazione per la criptazione di una password). Ci sono alcune cose da notare:

131 5.4 Session Bean 130 package crypt; public interface Crypt extends javax.ejb.ejbobject String crypt(string origine, int key) throws java.rmi.remoteexception; String decrypt(string criptata, int key) throws java.rmi.remoteexception; Listato 5.5: L interfaccia Remota - La classe estende javax.ejb.ejbobject. Ciò significa che l oggetto generato dal container conterrà tutti i metodi che l interfaccia javax.ejb.- EJBObject definisce, quindi un metodo per comparare due EJB Object, un metodo per rimuovere un EJB Object, e così via. - Nell interfaccia remota appaiono due metodi, crypt(string,int) e decrypt(string,int), che devono essere implementati nella enterprise bean class. Dal momento che EJBObject estende java.rmi.remote, anche l interfaccia remota la estenderà e quindi dovrà lanciare la java.rmi.remoteexception. Inoltre, anche i parametri passati devono rispettare le regole RMI-IIOP, per questo i parametri che sono usati nell esempio sono serializzabili (String é una classe che estende la serializzazione). La classe enterprise bean Il secondo passo è scrivere la classe che fornisce l implementazione del servizio, cioè il vero Bean. Il codice è mostrato nel Listato 5.6. Bisogna notare che: - La nostra implementazione estende javax.ejb.sessionbean, che fa del bean un Session Bean. Questa interfaccia definisce alcuni metodi che la classe deve obbligatoriamente implementare. Il container usa questi metodi per interagire con il bean, invocandoli in caso di eventi importanti (come l attivazione o la rimozione del bean). - Il bean ha un metodo ejbcreate() che il container chiama quando il bean viene creato. Questo metodo non può essere inserito nell interfaccia javax.ejb.sessionbean, in quanto i parametri passati possono cambiare

132 5.4 Session Bean 131 package crypt; public class CryptBean implements javax.ejb.sessionbean public void ejbcreate() public void ejbremove() public void ejbactivate() public void ejbpassivate() public void setsessioncontext(javax.ejb.sessioncontext ctx) public String crypt(string origine, int key) char dest[] = new char[origine.length()]; for (int i = 0; i < origine.length(); i++) dest[i] = (char) ( ( (int) origine.charat(i)) + key); return (new String(dest)); public String decrypt(string criptata, int key) char dest[] = new char[criptata.length()]; for (int i = 0; i < criptata.length(); i++) dest[i] = (char) ( ( (int) criptata.charat(i)) - key); return (new String(dest)); Listato 5.6: La classe enterprise bean

133 5.4 Session Bean 132 package crypt; public interface CryptHome extends javax.ejb.ejbhome Crypt create() throws java.rmi.remoteexception, javax.ejb.createexception; Listato 5.7: La home interface oppure essere assenti come nell esempio. I parametri qui passati devono essere gli stessi presenti nel metodo create() della Home interface. - I metodi ejbactivate() e ejbpassivate() vengono lasciati vuoti in quanto non ci sono risorse da ottenere o rilasciare nel caso di azioni del Container. - Quando il bean viene distrutto, non c è nulla da rimuovere, quindi il metodo ejbremove() può essere lasciato vuoto. - Se il Container deve comunicare con il bean, utilizza i metodi descritti in precedenza. Se invece il bean deve comunicare con il Container, può utilizzare la classe SessionContext. Il container chiama il metodo setsessioncontext in caso di cambiamento di alcuni parametri. La Home interface Il passo successivo consiste nella creazione della home interface. La home interface ha i metodi per creare e distruggere gli EJB Object. Infatti il client chiamerà il metodo create() per avere la enterprise bean class, mascherata dall interfaccia remota. Il codice per la home interface è mostrato nel Listato 5.7. Bisogna notare che: - Il metodo create() lancia una javax.rmi.remoteexception e javax.ejb.createexception. La RemoteException è necessaria in quanto sono oggetti remoti che lavorano sulla rete. La CreateException è richiesta per ogni metodo create() - La classe Home interface estende javax.ejb.ejbhome, estensione richiesta a tutte le home interface, che definisce il modo per distruggere un EJB Object.

134 5.4 Session Bean 133 <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE ejb-jar PUBLIC -//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN > <ejb-jar> <enterprise-beans> <session> <ejb-name>crypt</ejb-name> <home>crypt.crypthome</home> <remote>crypt.crypt</remote> <ejb-class>crypt.cryptbean</ejb-class> <session-type>stateless</session-type> <transaction-type>container</transaction-type> </session> </enterprise-beans> </ejb-jar> Listato 5.8: Il deployment descriptor Il deployment descriptor Successivamente c è bisogno di generare il deployment descriptor. Il deployment descriptor è una delle chiavi degli EJB in quanto permette di descrivere gli attributi specifici invece di programmare funzioni interne. Il deployment descriptor è un documento XML. Il deployment descriptor per il nostro esempio è mostrato nel Listato 5.8. <ejb-name> Questo è il nickname per uso interno. <home> Il nome completo della home interface (completo di package) <remote> Il nome completo del interfaccia remota <ejb-class> Il nome completo della classe che implementa il session bean <session-type> Il tipo di session bean: Stateless o Stateful Il file jboss.xml Questo è un file specifico per ogni Container. Ci sono alcune differenze tra container, come gli algoritmi sul pooling, algoritmi sul clustering e altro.

135 5.4 Session Bean 134 <?xml version="1.0" encoding="utf-8"?> <jboss> <enterprise-beans> <session> <ejb-name>crypt</ejb-name> <jndi-name>crypt</jndi-name> </session> </enterprise-beans> </jboss> Listato 5.9: jboss.xml Per JBoss il file che descrive queste caratteristiche è chiamato jboss.xml ed è mostrato per il nostro esempio nel Listato 5.9. Anche questo file è in formato XML: <ejb-name> Questo è il nickname per uso interno. <jndi-name> Questo è il nome usato per il look-up JNDI Il file Ejb-jar Una volta creati questi file bisogna raggrupparli in un Ejb-jar, file che nel caso di JBoss e semplicemente una cartella che viene chiamata nomeejb.jar (per esempio crypt.jar) I file.class devono venir generati inserendo nel classpath il package javax.ejb presente nella cartella: dir. inst\client\jboss-j2ee.jar (per esempio C:\Programmi\jboss-4.0.3SP1\client\jboss-j2ee.jar). Una volta creati i file.class bisogna inserirli nella cartella, insieme ai descriptor file, secondo lo schema in Figura 5.6 Successivamente inserire la cartella creata nella directory di installazione: dir.inst\server\default\deploy. Se JBoss è gia in esecuzione dopo qualche secondo compariranno tre righe come in Figura 5.7 Il client La scrittura del client è molto semplice, grazie alla trasparenza della programmazione EJB è possibile scrivere il codice senza preoccuparsi di dove verrà eseguito. Questo avviene grazie al looking up del JNDI. I passi da eseguire per la scrittura di un client sono semplici:

136 5.4 Session Bean 135 Figura 5.6: Scema del ejb-jar file Figura 5.7: Visualizzazione del deploy su JBoss

137 5.4 Session Bean Effettuare il look-up per ottenere il riferimento alla home interface. 2. Usare la home interface per creare il riferimento al EJBObject. 3. Eseguire i metodi del bean per risolvere la propria applicazione di business. 4. Opzionalmente si può rimuovere il bean. Il container eliminerà automaticamente il bean dopo un certo periodo. Per poter compilare ed eseguire le classi.java, c è bisogno dei package contenuti nel file dir.inst\client\jbossall-client.jar. Inoltre c è bisogno della copia delle interfacce home e remote (Crypt.class e CryptHome.class) Nel caso in cui queste classi siano nella stessa directory del client (se non ci sono c è bisogno di specificare la loro posizione nel classpath), il classpath per compilare i file.java potrebbe essere per esempio: C:\Programmi\jboss-4.0.3SP1\ client\jboss-all-client.jar;. La classe del client è riportata nel Listato Creazione di un Session Bean Stateful La remote interface Per prima cosa si implementa la remote interface illustrata nel Listato Quest interfaccia definisce un singolo metodo, add(), che implementerà la enterprise bean class. Questo metodo aggiunge una unità al contatore del bean e restituisce il valore aggiornato. La enterprise bean class Questa classe è responsabile dell incremento della variabile intera val. In questo esempio lo stato della conversazione è semplicemente la variabile val definita all interno della classe. Il codice della classe è mostrato nel Listato 5.12 e Ci sono alcune cose da notare: - Esistono due metodi ejbcreate, uno prende come paramentro un intero, l altro nessun parametro. Questi due metodi sono responsabili dell inizio della conversazione, partendo da uno stato già definito o da un nuovo stato. - La variabile val, in quanto primitiva, è serializzabile e quindi è possibile salvare il suo stato. In questo modo lo stato della conversazione sopravvive alle diverse chiamate dei metodi ed è salvato automaticamente durante l attivazione o durante la passivazione.

138 5.4 Session Bean 137 package client; import javax.naming.*; import java.util.properties; import crypto.*; public class Index public static void main(string args[]) throws Exception Properties prop = new Properties(); prop.put(context.initial_context_factory, "org.jnp.interfaces.namingcontextfactory"); prop.put(context.url_pkg_prefixes, "org.jnp.interfaces"); prop.put(context.provider_url, "localhost"); Context ctx = new InitialContext(prop); Object obj = ctx.lookup("crypt"); CryptHome home = (CryptHome) javax.rmi.portableremoteobject. narrow(obj, CryptHome.class); Crypto convert = home.create(); String cryptargs0 = convert.crypt(args[0], 3); System.out.println("La stringa criptataè : " + cryptargs0); cryptargs0 = convert.decrypt(cryptargs0, 3); System.out.println("La stringa decriptataè : " + cryptargs0); Listato 5.10: Il client package statefullbean; public interface CountRemote extends javax.ejb.ejbobject public int add() throws java.rmi.remoteexception ; Listato 5.11: L interfaccia Remota

139 5.4 Session Bean 138 package statefulbean; public class CountBean implements javax.ejb.sessionbean private int val; public int add() val++; System.out.println("Hai chiamato il metodo di incremento... ora stai a "+val+" chiamate"); return val; public void ejbcreate(int val) throws javax.ejb.createexception this.val = val; System.out.println("Creazione del bean con valore val="+val); public void ejbcreate() throws javax.ejb.createexception this.val = 0; System.out.println("Creazione del bean con valore val="+val); public void ejbremove() System.out.println("Il bean àverr ora rimosso"); public void ejbpassivate() System.out.println("Il bean àverr messo passivo e il suo stato salvato su hard disk"); Listato 5.12: L Enterprise Bean

140 5.4 Session Bean 139 public void ejbactivate() System.out.println("Il beanè stato attivato e la sua conversazioneè stata ricreata"); public void setsessioncontext(javax.ejb.sessioncontext ctx) package statefullbean; Listato 5.13: L Enterprise Bean public interface CountHome extends javax.ejb.ejbhome public CountRemote create(int val) throws javax.ejb.createexception, java.rmi.remoteexception; public CountRemote create() throws javax.ejb.createexception, java.rmi.remoteexception; Listato 5.14: La home interface - Questa classe implementa il metodo setsessioncontext(). Nel nostro esempio non è utilizzato ma, come già spiegato nell esempio precedente, esso è il collegamento tra bean e Container. Attraverso questa classe il bean può comunicare con il Container. In Java è possibile passare il proprio riferimento usando la parola chiave this, in EJB non è possibile in quanto il bean viene chiamato indirettamente attraverso l EJBObject. La home interface Per completare il codice del bean stateful, bisogna definire la home interface. Tale interfaccia specifica come creare e distruggere il bean. Il codice è mostrato nel Listato Da notare le due ricorrenze del metodo create(),una per ciacun metodo ejbcreate nell Enterprise Bean (Listato 5.12).

141 5.4 Session Bean 140 <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE ejb-jar PUBLIC -//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN > <ejb-jar> <enterprise-beans> <session> <ejb-name>countbean</ejb-name> <home>statefullbean.counthome</home> <remote>statefullbean.countremote</remote> <ejb-class>statefullbean.countbean</ejb-class> <session-type>stateful</session-type> <transaction-type>container</transaction-type> </session> </enterprise-beans> </ejb-jar> Listato 5.15: Il deploy descriptor Il deployment descriptor Ora che tutte le classi.java sono state create, c è bisogno di definire il deployment descriptor per specificare al Container i settaggi del bean. Lo schema XML è esposto nel Listato Si può notare che nel tag <Session-type> si specifica la natura del bean (Stateless o Statefull), evitando di introdurre la notazione all interno del codice. In questo modo si semplifica lo scambio tra stateless e stateful. Il file jboss.xml Il file specifico per JBoss è mostrato nel Listato Per completare l installazione c è bisogno della creazione del file ejb-jar. I passi da seguire sono i medesimi dell esempio precedente. Un settaggio che è possibile cambiare nel Container è il numero massimo di bean attivi, cioè il pooling. E possibile modificarlo all interno del file standardjboss.xml che si trova nella directory dir.inst\server\default\conf. All interno di questo file bisogna cercare il tipo di bean all interno del tag <container-name> (per esempio StandardStatefulSessionBean) e modificare

142 5.4 Session Bean 141 <?xml version="1.0" encoding="utf-8"?> <jboss> <enterprise-beans> <session> <ejb-name>countbean</ejb-name> <jndi-name>count</jndi-name> <max-pool-size>2</max-pool-size> <min-pool-size>1</min-pool-size> </session> </enterprise-beans> </jboss> Listato 5.16: jboss.xml il tag <max-capacity>. Questo tag impone al container il numero massimo di bean presenti in memoria. Per fare in modo che la modifica venga accettata bisogna far ripartire JBOSS. Il client Ora che il bean è stato installato, possiamo scrivere il codice Java per testarlo. I passi da eseguire saranno i seguenti: 1. Acquisire un JNDI initial context. 2. Trovare l home object attraverso il look-up JNDI 3. Creare tre diversi Count EJB object, quindi creare tre diverse conversazioni e simulare tre diversi client. 4. Limitare la bean pool capacity a due bean, in modo tale che durante la creazione delle tre conversazioni uno dei tre bean debba essere reso passivo. Per essere certi che questo avvenga,è stato inserito un messaggio all interno del metodo ejbpassivate(). 5. Chiamare il metodo add() su ogni EJB object. Ciò forza il container ad attivare i bean messi precedentemente in modalità passiva. Come per il metodo precedente è stato inserito un messaggio all interno del metodo ejbactive 6. Rimuovere i tre bean il codice è mostrato nei Listati 5.17 e 5.18.

143 5.4 Session Bean 142 package clientbean; import javax.naming.*; import statefullbean.*; public class Index public static void main(string[] args) try java.util.properties prop = new java.util.properties(); prop.put(context.initial_context_factory, "org.jnp.interfaces.namingcontextfactory"); prop.put(context.url_pkg_prefixes,"org.jnp.interfaces"); prop.put(context.provider_url, "localhost"); Context ctx = new InitialContext(prop); Object obj = ctx.lookup("count"); CountHome home = (CountHome) javax.rmi. PortableRemoteObject.narrow(obj, CountHome.class); CountRemote count[] = new CountRemote[3]; int countval; System.out.println("inizializzazioione dei bean"); count[i] = home.create(); Listato 5.17: Il Client

144 5.4 Session Bean 143 package clientbean; System.out.println("Bean creato con valore iniziale: 0"); count[i] = home.create(1); System.out.println("Bean creato con valore iniziale: 1"); count[i] = home.create(3); System.out.println("Bean creato con valore iniziale: 3"); System.out.println("chiamo il metodo count sui beans"); for (int i=0;i<3 ;i++) countval = count[i].add(); System.out.println("Contatore a: "+countval); Thread.sleep(500); for(int i = 0; i < 3 ; i++) count[i].remove(); catch(exception er) er.printstacktrace(); Listato 5.18: Il Client

145 5.5 Entity Bean Entity Bean Gli Entity Bean sono oggetti persistenti che possono essere salvati in un dispositivo permanente, come un database. Questo significa che è possibile modellare i dati come un Entity Bean. I dati vengono salvati in un database, mappando una tupla come un oggetto. Questo avviene salvando ogni parte costituente il Bean in un campo della tabella. Quando si desidera caricare il Bean dal database, viene creato un nuovo Bean e riempito con i campi ottenuti dal database. Questa operazione di mappatura di un oggetto in un database relazionale è chiamata object relational mapping (O/R mapping). Si tratta di un azione di conversione e riconversione da un oggetto in memoria ad un dato relazionale e viceversa. Si noti che questo meccanismo è molto diverso dalla serializzazione e quindi dal salvataggio su hard disk: decomponendo un oggetto è infatti possibile eseguire query per una qualsiasi informazione piuttosto che caricare tutto l oggetto in memoria. In una qualunque applicazione object-oriented, anche la più sofisticata, è sempre possibile effettuare una distinzione tra due tipi di componenti: Applicazioni logiche. Questo tipo di componenti fornisce, attraverso l uso dei Session Bean, metodi per l esecuzione di azioni comuni. Contengono spesso algoritmi per la risoluzione di problemi e nascondono la complessità dietro semplici chiamate. Dati persistenti. Si tratta di oggetti che possono rappresentare dati semplici o complessi che devono essere salvati. Possono rappresentare, inoltre, persone, luoghi o cose. Questi componenti usano meccanismi persistenti, come la serializzazione o l O/R mapping in un database relazionale o in un object database. I dati potrebbero essere sempre usati come righe di un database, ma è più vantaggioso usarli come oggetti perchè in questo modo risultano più compatti e sono quindi più facili da gestire. Inoltre, è possibile associare dati ad azioni, raggruppare i dati in oggetti e ottenere il middleware necessario per un applicazione server. Gli Entity Bean sono componenti che rappresentano gli oggetti di business conservati in un meccanismo di memoria persistente (database relazionale). Sono completamente diversi dai Session Bean: questi ultimi modellano processi e azioni, mentre gli Entity Bean contengono i dati necessari per l applicazione. Per esempio, un Session Bean potrebbe trasferire una certa quantità di denaro da un account ad un altro, mentre i dati di questi account sono rappresentati negli Entity Bean.

146 5.5 Entity Bean 145 Gli Entity Bean contengono un set di interfacce standard comune a tutti gli EJB, tra cui: interfacce locali e remote, local interface e local home interface, la classe enterprise bean e il deployment descriptor. Esistono notevoli differenze tra le interfacce e i file degli Entity Bean e quelli degli altri tipi di EJB: Le classi entity bean tracciano una definizione dell entità in uno schema del database. Per esempio, un Entity Bean potrebbe essere mappato in una definizione di tabella relazionale. In questo caso, un istanza di un Entity Bean della classe verrà salvata in una riga di una tabella. Inoltre, il Bean potrebbe fornire alcuni semplici metodi per manipolare dati o per accedervi, come decrementare il bilancio di un conto bancario. Come la classe session bean anche questa classe deve fornire alcuni metodi standard. La classe primary key fa si che ogni Entity Bean sia diverso. Per esempio, se abbiamo un milione di account bancari, ogni account ha bisogno di un ID unico che non può essere mai ripetuto in un altro account. Questa classe può contenere un numero qualsiasi di attributi. Gli EJB consentono di definire in maniera flessibile ciò che identifica il bean, compresa la classe primary key. L unica regola è che questa classe deve essere serializzabile e seguire le regole della object serialization di Java Caratteristiche Gli Entity Bean sono resistenti a errori critici, come crash di applicazioni server o anche crash di macchina. Questo perchè sono rappresentazioni di dati in un sistema di salvataggio permanente e fault-tolerant. Se si verifica un crash del sistema o della macchina, l Entity Bean può essere ricreato in memoria. Questa è la differenza fondamentale tra i Session e gli Entity Bean. Gli Entity Bean hanno un ciclo di vita molto più lungo di una sessione di un client, può durare anche anni, dipende da quanto tempo i dati sono sul database. La potenza di questo sistema risiede nel fatto che i dati situati in memoria e sul database possono essere visti come una cosa sola: cioè se un dato viene cambiato in memoria viene immediatamente cambiato anche nel database. Ovviamente, i dati in memoria sono la copia dei dati presenti sul database, quindi deve esserci un meccanismo di trasferimento di informazioni tra gli oggetti Java e il database. Questo trasferimento è compiuto con due metodi speciali che gli Entity Bean devono implementare: ejbload() e ejbstore().

147 5.5 Entity Bean 146 L EJBContainer usa questi metodi per manipolare gli EJB: il metodo ejbload() viene invocato quando i dati vengono letti dal sistema di salvataggio permanente in memoria, mentre il metodo ejbstore() viene invocato quando i dati devono essere salvati nel database. Il container si preoccupa di chiamare questi metodi: possono essere chiamati in qualunque momento (tranne che nei metodi di business). Inoltre, il container si preoccupa anche della sincronizzazione dei dati. Quando ci sono molti accessi agli stessi dati, il container crea istanze multiple della stessa classe Entity Bean. Questo permette a molti client di interagire concorrentemente con istanze separate, ognuna rappresentante i medesimi dati. Per mantenere la consistenza dei dati, i Bean devono essere sincronizzati costantemente. Il container sincronizza i dati chiamando i metodi ejbload() e ejbstore(). Questi metodi, come i metodi relativi al pooling (ejbactivate() ed ejbpassivate()), sono metodi che il container utilizza per comunicare al Bean che sta per essere caricato o salvato sul database. Anche gli Entity Bean sono soggetti al pooling. Invece di creare e distruggere un Bean quando un client si connette o disconnette, i Bean vengono riutilizzati in quanto la struttura del Bean non cambia e i dati possono essere ricavati dal database. Come accade per i Session Bean, il container utilizza i metodi ejbactivate() e ejbpassivate() per comunicare al Bean che verrà messo in modalità attivo o passivo e quindi che esso dovrà lasciare o recuperare risorse che non possono essere salvate (come le connessioni ad un database o ad una socket). Ovviamente quando un EJB viene reso passivo, oltre a rilasciare le risorse, deve anche salvare il proprio stato su database. Quindi verrà chiamato il metodo ejbstore(). In maniera duale, quando esso verrà attivato, oltre a riprendere le risorse deve ricreare il suo stato e quindi chiamare il metodo ejbload() Qualunque sia il tipo di supporto scelto per il salvataggio c è bisogno di scrivere il codice di accesso al supporto per salvare o caricare i dati. Esistono due tipi di approcci: bean-managed persistent e container-managed persistent. Nel primo caso, è lo sviluppatore del Bean a scrivere tutto il codice necessario per trasferire i campi in memoria nel supporto di salvataggio scelto (un database relazionale o ad oggetti). Nel secondo caso, invece, è il Container che si fa carico di scrivere il codice necessario alle operazioni di salvataggio, caricamento e modifica dei dati. Come vedremo negli esempi, questo tipo di approccio riduce drasticamente la quantità di codice da scrivere. Siccome l istanza di un Entity Bean e i dati sul database possono essere pensati come una cosa sola, l inizializzazione di un Bean potrebbe richiedere l inizializzazione di una tupla sul database. Quindi, quando un Bean viene creato con il metodo ejbcreate(), viene creata la corrispondente riga sul

148 5.5 Entity Bean 147 database. Così, in un approccio bean-managed persistent il metodo ejbcreate() è responsabile della creazione dei dati sul database. Dualmente, il metodo ejbremove() è responsabile della rimozioni dei dati dal database. Nel caso, invece, container-managed persistent è il Container a modificare il database e i metodi create e remove possono essere lasciati vuoti dal codice di accesso al supporto di salvataggio (per esempio codice SQL). C è da ricordare che il client non invoca direttamente il Bean. L EJB object è generato attraverso l home object. Quindi, ad ogni metodo ejbcreate() deve corrispondere il metodo create() nella home interface. Per esempio, consideriamo un Entity Bean che contenga un account bancario AccountBean con un interfaccia remota Account, home interface AccountHome e primary key AccountPK. Dato questo metodo ejbcreate() in AccountBean: public AccountPK ejbcreate(string accountid,string proprietario)... il metodo Create() deve essere implementato nella home interface (da notare la mancanza del prefisso ejb ): public Account Create(String accountid,string proprietario)... Il valore di ritorno dei due metodi è diverso. L istanza del Bean ritorna la primary key AccountPK mentre l home object ritorna un EJB object Account. Questo avviene in quanto il metodo ejbcreate() viene eseguito dal Container, il quale ha bisogno della primary key per identificare il bean. Con la primary key il container può generare l EJBObject e restituirlo al client. Per distruggere i dati di un Entity Bean in un database, il client deve chiamare il metodo remove() sulla remote interface. Bisogna osservare che questo metodo non rimuove l oggetto in memoria, ma solo i dati dal database. Ciò accade perchè gli oggetti in memoria vengono riutilizzati da un altro Bean. Il metodo ejbremote() è un metodo presente nell interfaccia e che deve quindi essere implementato. Poichè gli Entity Bean contengono informazioni che altri Bean possono acquisire, essi devono essere facilmente reperibili. Per individuare uno specifico Entity Bean è possibile eseguire diversi tipi di ricerca definiti come metodi e detti finder. La home interface contiene questi metodi addizionali, oltre ai metodi di creazione e di distruzione Esempi Di seguito saranno proposti due esempi che spiegheranno in dettaglio la differenza tra Entity Bean container-managed persistent e bean-managed persistent. Il primo esempio tratta la gestione di Account Bancari ed è stato

149 5.5 Entity Bean 148 public interface javax.ejb.entitybean public void setentitycontext(javax.ejb.entitycontext); public void unsetentitycontext(); public void ejbremove(); public void ejbactivate(); public void ejbpassivate(): public void ejbload(); public void ejbstore(); Listato 5.19: L interfaccia javax.ejb.entitybean realizzato con gli Entity Bean di tipo bean-managed persistent. Il secondo invece si occupa della Gestione di Prodotti ed è stato realizzato con un EJB container-managed persistent Creazione di un Entity Bean Bean-Managed persistent Quando si scrive questo tipo di bean, il programmatore deve fornire il codice necessario per l accesso ai dati. Per scrivere un Entity Bean, bisogna scrivere un file Java che implementi l interfaccia javax.ejb.entitybean. Questa interfaccia, come le altre derivanti da javax.ejb.enterprisebean, definisce alcuni metodi che il Bean deve implementare. Il codice di questa interfaccia è mostrato nel Listato Questi sono i metodi che il container invoca in caso di un evento. Tale interfaccia deve essere implementata da entrambi i tipi di Entity Bean. Ci sono anche altri metodi che si possono definire, come i metodi per creare nuovi Bean o individuare quelli già esistenti. I metodi ejbfind() I metodi ejbfind() non creano nuovi dati dal database, ma caricano dati dagli Entity Bean. Questi metodi vengono implementati solo in questo tipo di Bean, in quanto per i container-managed persistent i metodi in questione vengono automaticamente generati. Si possono avere diversi tipi di metodi finder. Una regola fondamentale è che tutti questi tipi di metodi devono iniziare con ejbfind. Per esempio, ejbfindtuttiprodotti() oppure ejbfindnomeprodotto().

150 5.5 Entity Bean 149 Un altra regola consiste nel definire obbligatoriamente un metodo find: ejbfindbyprimarykey(). Questo metodo, a differenza degli altri metodi che restituiscono una Collection, trova un unica istanza dell Entity Bean (basata sulla chiave primaria del Bean), e della tabella del database corrispondente. Così come per il metodo ejbcreate(), il client non invoca direttamente questi metodi, ma invoca i corrispettivi metodi sulla home interface. Per far capire la corrispondenza tra questi metodi si prenda ad esempio il metodo public Collection ejbfindbigaccount (int unminimo) throws FinderException. Il corrispettivo nella home interface sarà: public Collection findbigaccount(int unminimo) throws FinderException (da notare il prefisso ejb). I metodi sopra descritti seguono tutti i seguenti passi: - Quando il client invoca il metodi find sulla home interface, l home object chiede al Bean di trovare tutte le primary key class che corrispondono ai parametri richiesti. Il Bean restituisce una Collection di queste chiavi primarie al container. - Quando riceve la collezione di chiavi dal Bean, il container crea una collezione di EJB Object, uno per ogni chiave, e restituisce questa collezione di oggetti al client. Ogni EJB Object rappresenta l istanza relativa ai dati contenuti nel database. La remote interface: Account.java La classe Account è la prima classe del nostro Bean, la remote interface. É mostrata nel Listato Come tutte le remote interface, estende la javax.ejb.ejbobject. Inoltre, offre una serie di metodi per manipolare l Entity Bean, come i metodi per effettuare il prelievo ed il deposito. Da notare l AccountException, una eccezione creata per gestire gli errori di prelievo o di deposito o altri errori relativi all account. L home interface: AccountHome.java Questa classe ha la responsabilità di creare i dati sul database che rappresenta l account bancario. Il metodo create() restituisce un EJB Object al client capace di manipolare i dati appena creati. La classe è mostrata nel Listato Inoltre, sono presenti due metodi finder. findbyprimarykey cerca all interno del database se esiste l account con chiave primaria AccountPK. findname cerca all interno del database tutti gli account con nome nomeprop.

151 5.5 Entity Bean 150 package entitybean; import javax.ejb.*; import java.rmi.remoteexception; public interface Account extends EJBObject public void deposit(double amt) throws AccountException,RemoteException; public void prelievo(double amt) throws AccountException,RemoteException; public double getbilancio() throws RemoteException; public String getnomeproprietario() throws RemoteException; public void setnomeproprietario(string unnome) throws RemoteException; public String getaccountid() throws RemoteException; public void setaccountid(string id) throws RemoteException; Listato 5.20: La remote interface

152 5.5 Entity Bean 151 package entitybean; import javax.ejb.*; import java.rmi.remoteexception; import java.util.collection; public interface AccountHome extends EJBHome public Account create(string accountid, String nomeprop) throws RemoteException,CreateException; public Account findbyprimarykey(accountpk key) throws RemoteException,FinderException; public Collection findname(string nomeprop) throws RemoteException,FinderException; public double gettotalbankvalue() throws AccountException,RemoteException; Listato 5.21: La home interface

153 5.5 Entity Bean 152 Infine c è il metodo gettotalbankvalue() che restituisce l ammontare dell intera banca, ovvero la somma di tutti gli account presenti nel database. La primary key class: AccountPK.java Il codice di questa classe è mostrato nel Listato Nel nostro caso, la chiave primaria si riduce ad una semplice stringa: AccountID. Questa stringa deve essere unica all interno dell account bancario. Nei casi più complessi, dove ci sono più campi che identificano la chiave primaria, questa classe conterrebbe diverse variabili. Il metodo tostring() è un metodo richiesto. Il container chiama questo metodo per ricevere la descrizione della chiave primaria sotto forma di String. In questo caso, il metodo ritorna semplicemente il campo. In casi più complessi, bisogna combinare i vari campi per formare una stringa. Ci sono, inoltre, altri due metodi richiesti: hashcode() e equals(). Il primo viene utilizzato dal container in quanto può decidere di salvare la primary key class in una Hashtable. Questo può avvenire quando all interno del container viene creata una lista di tutti gli Entity Bean in memoria. Il metodo equals() viene usato dal container per determinare, al suo interno, se due entity bean rappresentano gli stessi dati. L enterprise bean class: AccountBean.java Il passo decisivo è creare l implementazione dell entity bean. L implementazione di questo esempio è abbastanza lunga ed è stata suddivisa in 3 parti contenenti: 1. i campi che identificano lo stato del bean gestito. 2. i metodi di business che il client usa. Questi metodi sono esposti nella remote interface. 3. i metodi richiesti dall interfaccia javax.ejb.entitybean più i metodi find e i metodi per creare il bean definiti nella home interface. Questa classe è molto pesante e lunga in quanto ad essa compete tutta la gestione dei dati sul database. Il codice è mostrato dal Listato 5.23 al Listato AccountException.java Questa classe è mostrata nel Listato Questa è una semplice classe che delega alla classe padre java.lang.exception gli errori sull account bancario,

154 5.5 Entity Bean 153 package entitybean; public class AccountPK implements java.io.serializable private String accountid; public AccountPK(String ID) accountid = ID; public int hashcode() return accountid.hashcode(); public String tostring() return accountid; public boolean equals(object obj) if(obj instanceof AccountPK) if(((accountpk)obj).accountid.equals(accountid)) return true; else return false; else return false; Listato 5.22: La primary key class

155 5.5 Entity Bean 154 package entitybean; import java.sql.*; import javax.naming.*; import javax.ejb.*; import java.util.*; public class AccountBean implements EntityBean private EntityContext ctx; // Campi dello stato del bean private String accountid; private String nomeprop; private double bilancio; public AccountBean() System.out.println("Un nuovo accountè stato creato."); Listato 5.23: AccountBean.java

156 5.5 Entity Bean 155 // Metodi della business logic public void deposit(double amt) throws AccountException System.out.println("Sto depositando l ammontare di " + amt + " sul conto " + accountid); bilancio += amt; public void prelievo(double amt) throws AccountException System.out.println("Sto prelevando " + amt + " dal conto " + accountid); if (amt > bilancio)throw new AccountException( "Il bilancion non copre il prelievo. Il Bilancio del conto " + accountid + "è di: " + bilancio + "); bilancio -= amt; // Metodi get e set dell entity bean public double getbilancio() System.out.println("Il bilancio del conto "+accountid+"è di "+bilancio+"); return bilancio; public void setnomeproprietario(string unnome) System.out.println("inserisco il nome proprietario"); nomeprop = unnome; public String getnomeproprietario() System.out.println("E stato richiesto il nome del proprietario del conto "+accountid); return nomeprop; Listato 5.24: AccountBean.java

157 5.5 Entity Bean 156 public String getaccountid() System.out.println("Miè stato richiesto l account di questo conto: "+accountid); return accountid; public void setaccountid(string unaccount) System.out.println("Ho ricevuto la richiesta di cambio dell account: \n dal vecchio "+accountid+" al nuovo "+unaccount); accountid = unaccount; public double ejbhomegettotalbankvalue() throws AccountException PreparedStatement pst = null; Connection conn = null; try System.out.println("E stato chiamato il metodo per la visione completa del bilancio della banca"); conn = getconnection(); pst = conn.preparestatement("select sum(bilancio) as total from accounts"); ResultSet rs = pst.executequery(); if(rs.next()) return rs.getdouble("total"); Listato 5.25: AccountBean.java

158 5.5 Entity Bean 157 catch(exception e) e.printstacktrace(); throw new AccountException(e); finally try if(pst!=null) pst.close(); if(conn!=null) conn.close(); catch(exception er)er.printstacktrace(); throw new AccountException("errore!"); // connessione al database interno a JBOSS public Connection getconnection() throws Exception try Context ctx = new InitialContext(); javax.sql.datasource data = (javax.sql.datasource) ctx.lookup("java:comp/env/jdbc/ejbpool"); return data.getconnection(); catch(exception er) System.err.println("errore nel caricare il database"); er.printstacktrace(); throw er; Listato 5.26: AccountBean.java

159 5.5 Entity Bean 158 // metodi richiesti dall interfaccia public void ejbactivate() System.out.println("Il conto "+accountid+ "è stato attivato"); public void ejbpassivate() System.out.println("il conto "+accountid+"è stato messo in àmodalit passivo"); public void ejbremove() throws RemoveException System.out.println("il conto "+accountid+ "è stato rimosso"); AccountPK pk = (AccountPK) ctx.getprimarykey(); String id = pk.tostring(); System.out.println("la kiave ottentutaè "+pk); PreparedStatement st = null; Connection conn = null; try conn = getconnection(); st = conn.preparestatement("delete from accounts where id =?"); st.setstring(1,id); if(st.executeupdate() == 0) throw new RemoveException("impossibile cancellare dal database l account " + pk); catch(exception e) throw new EJBException(e.toString()); Listato 5.27: AccountBean.java

160 5.5 Entity Bean 159 finally try if(st!=null) st.close(); if(conn!=null) conn.close(); catch(exception er)er.printstacktrace(); public void ejbload() AccountPK pk = (AccountPK) ctx.getprimarykey(); String id = pk.tostring(); System.out.println("la kiave ottentutaè " + pk); PreparedStatement st = null; Connection conn = null; try conn = getconnection(); st = conn.preparestatement("select nomeprop, bilancio from accounts where id =?"); st.setstring(1,id); ResultSet rs = st.executequery(); rs.next(); nomeprop = rs.getstring("nomeprop"); bilancio = rs.getdouble("bilancio"); catch (Exception er) throw new EJBException("impossibile caricare l account "+pk+" dal database",er); Listato 5.28: AccountBean.java

161 5.5 Entity Bean 160 finally try if(st!=null) st.close(); if(conn!=null) conn.close(); catch(exception er)er.printstacktrace(); public void ejbstore() System.out.println("E stato chiamato il metodo per il salvatagggio su database"); PreparedStatement st = null; Connection conn = null; try conn = getconnection(); st = conn.preparestatement("update accounts set nomeprop =?, bilancio =? where id =?"); st.setstring(1, nomeprop); st.setdouble(2,bilancio); st.setstring(3,accountid); st.executeupdate(); catch (Exception er) throw new EJBException("impossibile salvare l account "+accountid+" dal database",er); Listato 5.29: AccountBean.java

162 5.5 Entity Bean 161 finally try if(st!=null) st.close(); if(conn!=null) conn.close(); catch(exception er)er.printstacktrace(); public void setentitycontext(entitycontext ctx) System.out.println("chiamato il metodo setentitycontext"); this.ctx = ctx; public void unsetentitycontext() System.out.println("chiamato l unset del entitycontext"); ctx = null; public void ejbpostcreate(string accountid,string nomeprop) System.out.println("chiamato il metodo postcreate"); public AccountPK ejbcreate(string accountid, String nomeprop) throws CreateException PreparedStatement st = null; Connection conn = null; Listato 5.30: AccountBean.java

163 5.5 Entity Bean 162 try System.out.println("Creazione del conto"); this.accountid = accountid; this.nomeprop = nomeprop; bilancio = 0; conn = getconnection(); st = conn.preparestatement( "insert into accounts (id,nomeprop,bilancio) values(?,?,?)"); st.setstring(2, nomeprop); st.setdouble(3, bilancio); st.setstring(1, accountid); st.executeupdate(); return new AccountPK(accountID); catch (Exception er) throw new CreateException(er.toString()); finally try if (st!= null) st.close(); catch (Exception er) er.printstacktrace(); try if (conn!= null) conn.close(); catch (Exception er) er.printstacktrace(); Listato 5.31: AccountBean.java

164 5.5 Entity Bean 163 //metodi find public AccountPK ejbfindbyprimarykey(accountpk key) throws FinderException PreparedStatement st = null; Connection conn = null; try System.out.println("chiamato il metodo per la ricerca della chiave"); conn = getconnection(); st = conn.preparestatement( "select id from accounts where id =?"); st.setstring(1, key.tostring()); ResultSet rs = st.executequery(); rs.next(); return key; catch (Exception er) throw new FinderException(er.toString()); finally try if (st!= null) st.close(); catch (Exception er) er.printstacktrace(); try if (conn!= null) conn.close(); catch (Exception er) er.printstacktrace(); Listato 5.32: AccountBean.java

165 5.5 Entity Bean 164 public Collection ejbfindname(string name) throws FinderException PreparedStatement st = null; Connection conn = null; Vector v = new Vector(); try System.out.println("chiamato il metodo per la ricerca del nome del proprietario del cont"); conn = getconnection(); st = conn.preparestatement( "select id from accounts where nomeprop =?"); st.setstring(1, name); ResultSet rs = st.executequery(); while(rs.next()) String id = rs.getstring("id"); v.addelement(new AccountPK(id)); return v; catch (Exception er) throw new FinderException(er.toString()); finally try if (st!= null) st.close(); catch (Exception er) er.printstacktrace(); try if (conn!= null) conn.close(); catch (Exception er) er.printstacktrace(); Listato 5.33: AccountBean.java

166 5.5 Entity Bean 165 package entitybean; public class AccountException extends Exception public AccountException() super(); public AccountException(Exception e) super(e.tostring()); public AccountException(String e) super(e); Listato 5.34: AccountException.java come per esempio il prelievo di un quantitativo non presente sul conto. Inoltre distingue tra i problemi relativi all account e altri problemi relativi al malfunzionamento del programma. Il deployment descriptor e jboss.xml Infine per completare il bean da installare su JBoss c è bisogno degli ultimi due file XML rappresentati nei listati 5.35 e Il file JBoss.xml non cambia rispetto agli esempi precedenti. Nel deployment descriptor ci sono alcuni nuovi tag: <persistence-type> Questo elemento indica il tipo di persistenza: Bean- Managed o Container-Managed. <prim-key-class> Specifica il nome della Primary Key class <reentrant> Questo tag indica se il bean può chiamare se stesso attraverso un altro bean. Cioè, dati due bean A e B, sussiste il reentrant se, il bean A chiama il B, il quale richiama il bean A. <resource-ref> Questo elemento specifica i driver JDBC.

167 5.5 Entity Bean 166 <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE ejb-jar PUBLIC -//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN > <ejb-jar> <enterprise-beans> <entity> <ejb-name>account</ejb-name> <home>entitybean.accounthome</home> <remote>entitybean.accountremote</remote> <ejb-class>entitybean.accountbean</ejb-class> <persistence-type>bean</persistence-type> <prim-key-class>entitybean.accountpk</prim-key-class> <reentrant>false</reentrant> <resource-ref> <res-ref-name>jdbc/ejbpool</res-ref-name> <res-type>javax.sql.datasource</res-type> <res-auth>container</res-auth> </resource-ref> </entity> </enterprise-beans> </ejb-jar> Listato 5.35: Deployment descriptor <?xml version="1.0" encoding="utf-8"?> <jboss> <enterprise-beans> <session> <ejb-name>account</ejb-name> <jndi-name>bank</jndi-name> </session> </enterprise-beans> </jboss> Listato 5.36: JBoss.xml

168 5.5 Entity Bean 167 Setup del database Hypersonic Ultimo passo, prima di poter installare il bean e poter usarlo, c è bisogno di creare la tabella sul database. Per abilitare il database interno di JBoss bisogna modificare il file hsqldb-ds.xml che si trova nella cartella dir.inst \server\default\deploy. All interno di questo file XML, sono presenti tre tag connection-url, due di questi sono commentati. Per abilitare il database si deve commentare il tag esistente e selezionare il tag <connectionurl>jdbc:hsqldb:hsql://localhost:1701</connection-url>. Inoltre bisogna eliminare il commento dai seguenti tag: <mbean code="org.jboss.jdbc.hypersonicdatabase" name="jboss:service=hypersonic"> <attribute name="port">1701</attribute> <attribute name="silent">true</attribute> <attribute name="database">default</attribute> <attribute name="trace">false</attribute> <attribute name="no_system_exit">true</attribute> </mbean> <mbean code="org.jboss.jdbc.hypersonicdatabase" name="jboss:service=hypersonic,database=localdb"> <attribute name="database">localdb</attribute> <attribute name="inprocessmode">true</attribute> </mbean> Una volta salvato questo file, nella pagina iniziale di JBoss raggiungibile attraverso la pagina all interno della JMX Console cliccare sul servizio: service=hypersonic nella sezione jboss. All interno di questa pagina, il metodo void startdatabasemanager() apre il programma per la gestione del database Hypersonic. Con questo programma è possibile, attraverso il linguaggio SQL, creare le tabelle per gli Entity Bean. Questo passaggio è automatico per i Container-Managed Bean. Per questo esempio c è bisogno della tabella accounts creata con il seguente codice sql: ( ) CREATE TABLE accounts id varchar(64), nomeprop varchar(64), bilancio numeric(18) Ora il bean è pronto per essere usato.

169 5.5 Entity Bean 168 Il Client Nei Listati 5.37 e 5.38 è proposta una semplice classe Java che effettua alcune operazioni bancarie come un deposito e un prelievo. Per evitare di far rimanere dati inutili sul database è stato creato un blocco try-catch allo scopo di eliminare il bean in qualunque caso Creazione di un Entity Bean Container-Managed persistent Nel caso di un EJB Container-Managed Persistent (CMP), non c è bisogno di implementare alcuna linea di codice relativa alla gestione dei dati, è l EJB Container che fornisce le operazioni di salvataggio. Un altro vantaggio di questo modello e che c è una separazione tra un entity bean e la sua rappresentazione statica. Questa separazione comporta una maggiore facilità nel modificare la rappresentazione del bean in quanto questa descrizione non si trova nel codice. Per ottenere quest obiettivo, i sorgenti devono poter esser privi di qualunque codice JDBC o altro codice per la manipolazione dei dati. Il codice per la manipolazione dei dati viene generato dal container creando una sotto classe della classe entity bean. In questo modo non c è bisogno di scrivere i campi da salvare in quanto sono generati dal container nella sotto classe. L assenza di questi campi comporta l assenza dei metodi get e set nella classe enterprise bean. Anche questi metodi sono generati dal container, per sapere la nomenclatura di questi metodi bisogna creare la classe enterprise bean come una classe astratta, dove i metodi get e set sono solo dichiarati. Il Container conosce il nome di questi campi dal deployment descriptor. I nomi di questi campi, delimitati dal tag <cmp-field>, devono avere la stessa nomenclatura dei metodi get e set: per esempio data una variabile prezzobase il nome dei metodi get e set dovrà essere getprezzobase() e setprezzobase(). Il passo successivo per la completa comprensione del modello CMP è sapere come il Container crea i metodi finder. Per scrivere il codice in maniera indipendente dal Container specifico in modo da mantenere la proprietà fondamentale degli EJB si utilizza il linguaggio EJB Query Language (EJB-QL). Con questo linguaggio object-oriented molto simile a SQL, il container è capace di generare il codice necessario per l accesso e il salvataggio dei dati. L esempio seguente mostra un entity bean Container-Managed Persistent.

170 5.5 Entity Bean 169 package clientbean; import entitybean.*; import javax.naming.*; import javax.rmi.*; import java.util.*; public class Index public static void main(string[] args) AccountRemote account = null; try Properties prop = new Properties(); prop.put(context.initial_context_factory, "org.jnp.interfaces.namingcontextfactory"); prop.put(context.url_pkg_prefixes,"org.jnp.interfaces"); prop.put(context.provider_url, "localhost"); Context ctx = new InitialContext(prop); Object obj = ctx.lookup("bank"); AccountHome home = (AccountHome) javax.rmi.portableremoteobject. narrow(obj, AccountHome.class); System.out.println("Il totale degli account iniziale in bancaè : "+home.gettotalbankvalue()); home.create(" ","jonh Smith"); Iterator i = home.findname("jonh Smith").iterator(); if(i.hasnext()) account = (AccountRemote) javax.rmi. PortableRemoteObject.narrow(i.next(), AccountRemote.class); else throw new Exception("Account non trovato"); System.out.println("Bilancio iniziale = "+account.getbilancio()); Listato 5.37: Il client Index.java

171 5.5 Entity Bean 170 account.deposit(100); System.out.println("Dopo aver depositato i soldi il uovo bilancioè : "+account.getbilancio()); AccountPK pk = (AccountPK) account.getprimarykey(); account = null; account = home.findbyprimarykey(pk); System.out.println("trovato account con il seguente id: "+pk+". Il suo bilancioè di : "+ account.getbilancio()); System.out.println("Ora provo a prelevare 150"); account.prelievo(150); catch(exception er) System.out.println("l eccezioneè stata lanciata...: "+er.tostring()); er.printstacktrace(); finally try System.out.println("distruzione del bean"); account.remove(); catch(exception e) e.printstacktrace(); Listato 5.38: Il client Index.java

172 5.5 Entity Bean 171 package entitybean; import javax.ejb.*; import java.rmi.remoteexception; public interface Product extends EJBObject public String getnome() throws RemoteException; public void setnome(string unnome) throws RemoteException; public String getdescrizione() throws RemoteException; public void setdescrizione(string unadescrizione) throws RemoteException; public double getprezzobase() throws RemoteException; public void setprezzobase(double unprezzo) throws RemoteException; public String getprodotto() throws RemoteException; Listato 5.39: Product.java La remote interface: Product.java E l interfaccia che il client invoca, essa è mostrata nel Listato La home interface: ProductHome.java Questa classe è mostrata nel Listato Qui sono esposti i metodi per la creazione e la ricerca degli entity bean. La primary key class: ProductPK.java Come per il modello BMP, anche il Container-Manager Persistent ha bisogno della classe che identifica la chiave primaria. La classe è mostrata nel Listato 5.41.

173 5.5 Entity Bean 172 package entitybean; import java.rmi.remoteexception; import java.util.collection; import javax.ejb.*; public interface ProductHome extends EJBHome public Product create(string prodotto,string name, String descrizione,double prezzo) throws CreateException, RemoteException; public Product findbyprimarykey(productpk key) throws FinderException, RemoteException; public Collection findnome(string unnome) throws FinderException, RemoteException; public Collection finddescrizione(string unadescrizione) throws FinderException, RemoteException; public Collection findprezzobase(double unprezzo) throws FinderException, RemoteException; public Collection findprodotticostosi(double unprezzo) throws FinderException, RemoteException; public Collection findprodottieconomici(double unprezzo) throws FinderException, RemoteException; public Collection findall() throws FinderException, RemoteException; Listato 5.40: ProductHome.java

174 5.5 Entity Bean 173 package entitybean; import java.io.serializable; public class ProductPK implements Serializable public String prodotto; public ProductPK(String ID) prodotto = ID; public ProductPK() public int hashcode() return prodotto.hashcode(); public String tostring() return prodotto; public boolean equals(object obj) if(obj instanceof ProductPK) if(((productpk)obj).prodotto.equals(prodotto)) return true; else return false; else return false; Listato 5.41: ProductPK.java

175 5.5 Entity Bean 174 La enterprise bean class: ProductBean.java Nel Listato 5.42 è mostrata l implementazione dell entity bean containermanaged persistent. Come si nota la dimensione del codice da scrivere è notevolmente diminuita. Questo diminuisce la possibilità di bug nel codice e aumenta la facilità di manutenzione. Non sono utilizzati campi quindi il metodo ejbcreate() utilizza i metodi set per popolare il database. Il deployment descriptor Il deployment descriptor in questo modello diventa fondamentale. Viene usato dal container per conoscere i campi del bean e come realizzare il metodo finder. Il codice per questo esempio è mostrato nei Listati dal 5.44 al La prima parte è la stessa che caratterizza anche il modello BMP. Successivamente c è la definizione dei campi del bean, che devono essere gli stessi dei metodi get/set. Infine le query per i metodi find. jboss.xml e jbosscmp-jdbc.xml Questi file servono a JBoss per inizializzare il database e sapere come abbinare ai campi del bean la corrispettiva colonna del database. Nel Listato 5.48 è mostrato il file jboss.xml mentre nel Listato 5.49 è mostrato il file jbosscmp-jdbc.xml. Quest ultimo file gestisce il database nel tag </defaults>, mentre nel tag </enterprise-beans> gestisce i campi della tabella. I tag <datasource> e <datasource-mapping> sono specifichi per JBOSS e identificano il database Hypersonic. Il tag <create-table> indica se al momento del deploy del bean il container deve creare la cartella. Il tag <remove-table> viene usato dal container per conoscere se alla rimozione del bean deve rimuovere anche la tabella. Il tag <pk-constraint> indica il bisogno di creare una chiave primaria per questa tabella Per le colonne del database i tag <field-name> e <column-name> specificano l associazione tra colonna e campo del bean. field-name è lo stesso campo che si trova nel deployment descriptor, column-name è il campo utilizzato nelle query per i metodi finder. Il client: Index.java Questa è una semplice classe Java che ha lo scopo di testare il bean. Normalmente non è il client ad effettuare queste operazioni ma i session bean che interagiscono con gli entity bean. Il codice client è mostrato nel Listato 5.49.

176 5.5 Entity Bean 175 package entitybean; import javax.ejb.*; public abstract class ProductBean implements EntityBean private EntityContext ctx; public abstract String getnome(); public abstract void setnome(string unnome); public abstract String getdescrizione(); public abstract void setdescrizione(string unadescrizione); public abstract double getprezzobase(); public abstract void setprezzobase(double unprezzo); public abstract String getprodotto(); public abstract void setprodotto(string unid); public void ejbactivate() System.out.println("Bean attivato"); public void ejbpassivate() System.out.println("Bean passivato"); public void ejbremove() System.out.println("Bean rimosso"); public void ejbload() System.out.println("Bean caricato"); Listato 5.42: ProductBean.java

177 5.5 Entity Bean 176 public void ejbstore() System.out.println("Bean salvato"); public void setentitycontext(entitycontext unctx) System.out.println("Settato entity context"); ctx = unctx; public void ejbpostcreate(string prodotto,string name, String descrizione,double prezzo) System.out.println("Chiamato il post create"); public ProductPK ejbcreate(string prodotto,string name, String descrizione,double prezzo) throws CreateException System.out.println("bean creato "); setprodotto(prodotto); setnome(name); setdescrizione(descrizione); setprezzobase(prezzo); ProductPK pk = new ProductPK(prodotto); return pk; public void unsetentitycontext()ctx = null; Listato 5.43: ProductBean.java

178 5.5 Entity Bean 177 <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE ejb-jar PUBLIC -//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN > <ejb-jar> <enterprise-beans> <entity> <ejb-name>productsbean</ejb-name> <home>entitybean.producthome</home> <remote>entitybean.product</remote> <ejb-class>entitybean.productbean</ejb-class> <persistence-type>container</persistence-type> <prim-key-class>entitybean.productpk</prim-key-class> <reentrant>false</reentrant> <cmp-version>2.x</cmp-version> <abstract-schema-name>products</abstract-schema-name> <cmp-field> <field-name>prodotto</field-name> </cmp-field> <cmp-field> <field-name>nome</field-name> </cmp-field> <cmp-field> <field-name>descrizione</field-name> </cmp-field> <cmp-field> <field-name>prezzobase</field-name> </cmp-field> Listato 5.44: ejb-jar.xml

179 5.5 Entity Bean 178 <query> <query-method> <method-name>findnome</method-name> <method-params> <method-param>java.lang.string</method-param> </method-params> </query-method> <ejb-ql> <![CDATA[select object(a) from products as a where a.nome =?1]]> </ejb-ql> </query> <query> <query-method> <method-name>finddescrizione</method-name> <method-params> <method-param>java.lang.string</method-param> </method-params> </query-method> <ejb-ql> <![CDATA[select object(a) from products as a where a.descrizione =?1]]> </ejb-ql> </query> <query> <query-method> <method-name>findprezzobase</method-name> <method-params> <method-param>double</method-param> </method-params> </query-method> Listato 5.45: Product.java

180 5.5 Entity Bean 179 <ejb-ql> <![CDATA[select object(a) from products as a where a.prezzobase =?1 ]]> </ejb-ql> </query> <query> <query-method> <method-name>findprodotticostosi</method-name> <method-params> <method-param>double</method-param> </method-params> </query-method> <ejb-ql> <![CDATA[select object(a) from products as a where a.prezzobase >?1]]> </ejb-ql> </query> <query> <query-method> <method-name>findprodottieconomici</method-name> <method-params> <method-param>double</method-param> </method-params> </query-method> <ejb-ql> <![CDATA[select object(a) from products as a where a.prezzobase <?1]]> </ejb-ql> </query> Listato 5.46: Product.java

181 5.5 Entity Bean 180 <query> <query-method> <method-name>findall</method-name> <method-params> </method-params> </query-method> <ejb-ql> <![CDATA[select object(a) from products as a where a.prodotto is not null]]> </ejb-ql> </query> </entity> </enterprise-beans> </ejb-jar> Listato 5.47: Product.java <?xml version="1.0" encoding="utf-8"?> <jboss> <enterprise-beans> <entity> <ejb-name>productsbean</ejb-name> <jndi-name>prodotti</jndi-name> </entity> </enterprise-beans> </jboss> Listato 5.48: jboss.xml

182 5.5 Entity Bean 181 <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE jbosscmp-jdbc PUBLIC "-//JBoss//DTD JBOSSCMP-JDBC 3.0//EN" "http://www.jboss.org/j2ee/dtd/jbosscmp-jdbc_3_0.dtd"> <jbosscmp-jdbc> <defaults> <datasource>java:/defaultds</datasource> <datasource-mapping>hypersonic SQL</datasource-mapping> <create-table>true</create-table> <remove-table>true</remove-table> <pk-constraint>false</pk-constraint> </defaults> <enterprise-beans> <entity> <ejb-name>productsbean</ejb-name> <table-name>products</table-name> <cmp-field> <field-name>nome</field-name> <column-name>nomeprod</column-name> </cmp-field> <cmp-field> <field-name>descrizione</field-name> <column-name>descrizioneprod</column-name> </cmp-field> <cmp-field> <field-name>prezzobase</field-name> <column-name>prezzo</column-name> </cmp-field> <cmp-field> <field-name>prodotto</field-name> <column-name>prod</column-name> </cmp-field> </entity> </enterprise-beans> </jbosscmp-jdbc> Listato 5.49: jbosscmp-jdbc.xml

183 5.5 Entity Bean 182 package clientbean; import entitybean.*; import javax.naming.*; import javax.rmi.portableremoteobject; import java.util.*; public class Index public static void main(string[] args) ProductHome home = null; try Properties prop = new Properties(); prop.put(context.initial_context_factory, "org.jnp.interfaces.namingcontextfactory"); prop.put(context.url_pkg_prefixes,"org.jnp.interfaces"); Context ctx = new InitialContext(prop); Object obj = ctx.lookup("prodotti"); home = (ProductHome) javax.rmi.portableremoteobject. narrow(obj, ProductHome.class); Product c = home.create("123","p5-200", "Pentium 2 GHz",100); home.create("124","p5-300", "Pentium 3 GHz",600); home.create("125","p5-350", "Pentium 3,5 GHz",1000); home.create("126","amd-300", "AMD 3 GHz",1000); home.create("127","amd-320", "AMD 3,2 GHz",1200); home.create("128","amd-35", "AMD 3.5 GHz",1500); Iterator i = home.findnome("p5-300").iterator(); System.out.println("Questi sono i prodotto trovati"); while(i.hasnext()) Product prod = (Product) PortableRemoteObject. narrow(i.next(),product.class); System.out.println(prod.getDescrizione()); Listato 5.50: Il client

184 5.5 Entity Bean 183 System.out.println("ricerca tutti i prodotti che costano 1000"); i = home.findprezzobase(1000).iterator(); while(i.hasnext()) Product prod = (Product) PortableRemoteObject. narrow(i.next(),product.class); System.out.println(prod.getDescrizione()); catch(exception er) er.printstacktrace(); finally try if (home!= null) Iterator i = home.findall().iterator(); while (i.hasnext()) Product prod = (Product) PortableRemoteObject. narrow(i.next(), Product.class); System.out.println("rimozione del prodotto "+ prod.getnome()); prod.remove(); catch(exception er) er.printstacktrace(); Listato 5.51: Il client

185 5.6 Message-driven Bean Message-driven Bean Un Message-Driven Bean (MDB) è un Bean in cui il concetto di interfaccia remota è del tutto assente, ed il solo meccanismo di interazione con il mondo esterno è quello basato sulla ricezione di messaggi JMS. Si tratta quindi di componenti stateless transaction aware, il cui unico compito è quello di processare messaggi JMS provenienti da topic o code. Il valore aggiunto che si ha nell usare un MDB al posto di una normale applicazione client JMS è che in questo caso l ascoltatore, essendo un Enterprise Bean, vive completamente all interno di un contesto sicuro, transazionale e fault-tolerant. Un altro grosso vantaggio è che, rispetto ad un semplice client, il MDB è in grado di processare i messaggi in modo concorrente: lo sviluppatore si deve concentrare sullo sviluppo di un solo componente, ovvero sulla logica di processamento di un messaggio, mentre al resto pensa il Container che potrà eseguire i vari Bean in modo concorrente. Un MDB può ricevere centinaia di messaggi e processarli anche tutti nello stesso istante dato che il Container eseguirà più istanze dello stesso MDB gestite in modalità di pool. In modo del tutto analogo a quanto avviene per i Session o gli Entity, anche gli MDB sono gestiti in tutto il loro ciclo di vita e durante l esecuzione dei metodi di business dal Container. Per questo, sebbene essi siano in grado di processare messaggi JMS, l effettiva ricezione viene gestita dal container, che poi in modalità di callback inoltra la chiamata al Bean Utilizzo dei MDB Per chi si avvicina per la prima volta agli MDB uno dei dubbi più ricorrenti è su come e quando un MDB debba essere utilizzato. La modalità corretta di utilizzo di un MDB è anche la più semplice che si possa immaginare. Se in un contesto EJB gli Entity rappresentano entità astratte e i Session degli oggetti di servizio in cui eseguire metodi di business logic, gli MDB sono oggetti il cui solo scopo è quello di operare come intermediari per l esecuzione della business logic in concomitanza di determinati eventi (ovvero all arrivo di un messaggio). Per questo motivo un MDB dovrebbe implementare solamente la logica di gestione del messaggio e dell analisi delle sue caratteristiche e dar vita ad un flusso di operazioni invocando la business logic contenuta nei metodi remoti di un session bean. Ad esempio un MDB potrebbe estrapolare i campi dall header del messaggio e successivamente stabilire quale metodo di un Session invocare passandogli gli opportuni parametri. I MDB possono avere campi di istanza come i Session e sono mantenuti durante il loro ciclo di vita, ma essendo stateless e non potendo essere associati ad un client in

186 5.6 Message-driven Bean 185 Figura 5.8: Scema del ciclo vita di un message-driven bean particolare, devono essere gestiti dal container in modo autonomo secondo la logica del pool. Questi Bean sono i più semplici da implementare in quanto richiedono solo la enterprise bean class. L unico modo di interazione con i client è attraverso i messaggi JMS, quindi non c è bisogno delle interfacce home e remote con il client. Questo Bean deve implementare le interfacce sia con JMS (MessageListener) che con il container MessageDrivenBean). Quando viene installato un MDB sul container, su di esso vengono chiamati i metodi setmessagedrivencontext() e ejbcreate(). A questo punto, il MDB è pronto a ricevere messaggi. Dopo l installazione per ogni messaggio ricevuto dal MDB, il metodo onmessage(message) viene invocato. Il Container è responsabile di serializzare i messaggi: ogni MDB può processare al più un solo messaggio alla volta ma il container può avere copie dello stesso Bean permettendo così l accesso concorrenziale. Quando viene disinstallato il MDB viene invocato il metodo ejbremove(). La Figura 5.8 mostra il ciclo vita di un MDB, molto simile ad un session bean stateless.

187 Capitolo 6 Applicazione completa sugli EJB In tale capitolo verrà mostrata un applicazione riassuntiva contenente Session Bean e Message Driven-Bean. Si riporterà ora in dettaglio il funzionamento di tale applicazione per meglio comprendere il contesto in cui si opera e le funzionalità che l applicazione implementa. Successivamente si descriverà nei particolari la tecnologia utilizzata per la sua realizzazione. Per la creazione dell intero applicativo ci si può riferire alla Figura 6.1 che mostra le classi dell applicazione. Tutti i bean sono contenuti nella stessa applicazione: ciò significa che il deployment descriptor sarà uno solo e conterrà le informazioni di tutti i beans. Per maggiore chiarezza, ogni bean ha un proprio package, in questo modo è più semplice capire quali siano le classi relative ad ogni bean. Iniziamo nel descrivere l applicazione. 6.1 Vendita di libri on-line Tale esempio riguarda una vendita di libri on-line. In particolare, la pagina iniziale che si presenta all utente nel momento in cui si collega all applicazione attraverso un browser riporta semplicemente gli strumenti necessari per effettuare il login, come si evince dalla Figura 6.2. Se i dati sono stati inseriti correttamente, si accede ad una seconda pagina in cui si notifica che il login è avvenuto con successo, nel caso in cui il nome utente e la password inseriti siano corretti; in caso contrario, la pagina conterrà un messaggio che avvisa del fallimento del login (di seguito è ripor- 186

188 6.1 Vendita di libri on-line 187 Figura 6.1: Schema dell applicazione Figura 6.2: Pagina iniziale

189 6.1 Vendita di libri on-line 188 Figura 6.3: Caso A: inserimento dei dati; Caso B: login avvenuto con successo; Caso C: login errato. tata una sequenza di immagini in cui si visualizzano i vari casi possibili del login) Figura 6.3. Una volta inserito il nome utente e la password in modo corretto, si giunge alla pagina principale dell applicazione Figura 6.4 in cui è presente una lista dei libri disponibili dalla quale l utente può scegliere quelli di interesse ed aggiungerli nel proprio carrello. La scelta avviene selezionando il libro scelto e cliccando sul bottone Add to. A questo punto, verrà visualizzata una nuova pagina attraverso la quale viene fornito il feedback all utente: il libro è stato aggiunto correttamente nel carrello (Figura 6.5). A questo punto, cliccando su Continua si torna di nuovo nella pagina principale che riporta, in alto a sinistra, il carrello contenente tutti i libri che il cliente ha deciso di acquistare con il relativo conto. Il cliente può rimuovere dei libri dal proprio carrello selezionandoli e cliccando sul tasto Delete (anche in tal caso verrà visualizzata un ulteriore pagina che dà conferma all utente che il libro in questione è stato eliminato con successo dal carrello). Una volta che l utente ha finito i propri acquisti può procedere al pagamento attraverso il tasto Procedi al pagamento. Si giunge così ad un altra pagina dell applicazione nella quale vengono richiesti all utente alcune informazioni per effettuare il pagamento (Figura 6.6) quali: nome, numero di carta di credito e tipo di

190 6.1 Vendita di libri on-line 189 Figura 6.4: Pagina principale Figura 6.5: Conferma del corretto inserimento del nuovo ordine nel carrello

191 6.1 Vendita di libri on-line 190 Figura 6.6: Richiesta dati per il pagamento Figura 6.7: Schermata riepilogativa dei dati per il pagamento carta di credito. Una volta inseriti tutti i dati, attraverso il bottone Send To viene caricata una pagina riepilogativa dei dati inseriti per il pagamento (Figura 6.7) in questa, una volta cliccato su Continua, si torna all home page dove altri utenti potranno effettuare nuovi acquisti. L applicazione consente al venditore di avere una gestione degli ordini automatizzata mediante un interfaccia che gli elenca gli ordini dei clienti (Figura 6.8). Ciò avviene cliccando sul tasto start. Una volta che l ordine è stato evaso, esso può essere rimosso selezionandolo e cliccando sul tasto Processato. Il tasto Chiudi consente invece di chiudere l intera applicazione.

192 6.2 Alcuni Diagrammi UML dell Applicazione 191 Figura 6.8: Ordini dei clienti 6.2 Alcuni Diagrammi UML dell Applicazione Di seguito, mostriamo alcuni diagrammi UML dell Applicazione. Use Case Consideriamo come scenario principale quello in cui tutto va a buon fine: Acquista un libro 1. Il cliente effettua il login 2. Il cliente scorre la lista e seleziona il libro da acquistare 3. Il cliente aggiunge il libro al carrello 4. Il cliente va alla cassa 5. Il cliente riempie i campi relativi alla carta di credito 6. Il sistema autorizza l acquisto Una possibile variante allo scenario principale può essere la seguente: Autorizzazione Fallita al passo 6, il sistema boccia l autorizzazione a rilevare il credito. Consente al cliente di reinserire le informazioni relative alla carta di credito e riprovare. In Figura 6.9 è mostrato il Diagramma dei Casi d Uso della nostra Applicazione. Class Diagram In Figura 6.10 è rappresentato il diagramma delle classi relativo al componente Client Swing della nostra applicazione. Il dia-

193 6.2 Alcuni Diagrammi UML dell Applicazione * BookOrder Costumer 1 Acquistare Libri Figura 6.9: Diagramma Casi d Uso Application main() : void PrincipaleListener START : String CHIUDI : String ELIMINA : String start() : void chiudi() : void elimina() : void 1 1 OrderListener listmodel : DefaultListModel connection : DefaultListModel onmessage(message : void) : void stop() : void 1 Order 1 Principale lista : JList model : DefaultListModel startbtn : JButton chiudibtn : JButton eliminabtn : JButton sudpnl : JPanel listscrollpane : int user : String books : String getuser() : void getbooks() : void Figura 6.10: Diagramma delle Classi relativo a Client Swing

194 6.3 Package BookOrder 193 <<Form>> DeleteBook 1 <<submit>> 1 <<Servlet>> DeleteBook index.html 1 1 <<Jsp>> Ordini <<Form>> Pagamento 1 <<submit>> 1 <<Jsp>> Pagamento 1 <<Form>> Login <<Form>> Controller <<submit>> 1 1 <<redirect>> 1 1 <<submit>> <<Servlet>> PagamentoServlet <<submit>> 1 1 <<Form>> PagamentoServlet <<Servlet>> ConfirmServlet <<Servlet>> Controller <<submit>> 1 1 Figura 6.11: Diagramma delle Classi relativo ad Accesso Web gramma delle classi in Figura 6.11 è relativo alla parte web (componente Accesso web) ed è stato modellato secondo la metodologia descritta da Jim Conallen nel suo articolo [12] 6.3 Package BookOrder Il package BookOrder contiene al suo interno le seguenti classi: BookOrder: interfaccia remota che descrive i metodi implementati dal Bean per fornire il servizio di acquisto on line (quando un client vuole usare un istanza dell enterprise class, non invocherà mai direttamente l istanza, piuttosto l invocazione viene intercettata dal ContainerEJB che agisce come livello intermedio tra client e bean). BookOrderBean: contiene la logica del sistema (è un esempio tipico di sessionbean stateful). Tale bean tiene memoria dello stato di ogni client (carrello della spesa e costi) e gestisce la comunicazione JMS degli eventi associati all acquisto di un libro. All interno del metodo setsessioncontext si realizza la comunicazione tra il Bean ed il Container. All interno di tale classe sono contenuti i metodi di gestione dell ejb, compresi quelli standard per la gestione degli ejb stateful (ejbactivate utilizzato per richiamare l EJB dalla memoria di massa

195 6.4 Package BookOrderMDB 194 quando la conversazione con il client torna attiva, ejbpassivate che consente di memorizzare l EJB su un archivio permamente per ridurre il consumo di memoria) e i metodi che implementano la logica di business vera e propria. BookOrderHome: classe che contiene il client che invoca l EJBObject e non il bean. Questo avviene solo se il client ha il riferimento a questo oggetto. Il client ottiene il riferimento attraverso un produttore di EJBObject: l HomeObject responsabile della creazione, della ricerca e della rimozione di un EJBObject. BookOrderHome è l interfaccia che consente di inizializzare correttamente l EJBObject. Il Listato 6.2 mostra la classe BookOrderHome.Java. Il vero e proprio bean viene mostrato nei Listati da 6.3 a 6.8. dove sono implementati tutti i metodi che sono disponibili nella remote interface. 6.4 Package BookOrderMDB Nel package BookOrderMDB c è solo la classe BookMDBean contenente i metodi di gestione del bean tra cui il metodo onmessage(). Il bean riceve il messaggio con l ordine che è stato eseguito dal client e lo scrive in maniera opportuna su un file di log C:\orders.log 6.5 Package Archivio La cartella RMIBookStore contiene il package Archivio. sono le seguenti classi: Al suo interno ci Book: contiene i metodi gettitolo, getlistaautori e getcosto. DataLayer: l interfaccia remota, contenente i metodi di business dell rmi server invocabili remotamente (è l oggetto che consente la comunicazione remota tra il nostro client realizzato con l EJB ed il server). DataLayerImpl: è l implementazione dell Interfaccia remota in una classe concreta che estende UnicastRemoteObject (facilita la creazione di oggetti remoti). Dentro tale classe viene definito univocamente l elenco degli utenti che possono accedere ai nostri servizi con le rispettive password, quindi viene effettuato il controllo dell identità degli utenti che tentano di accedere al sistema per comprare i libri e viene verificato che il codice della carta sia di 16 caratteri e che i caratteri siano numeri, dopodichè

196 6.5 Package Archivio 195 package BookOrder; import javax.ejb.ejbobject; import java.util.*; import Archivio.*; public interface BookOrder extends EJBObject boolean addbook(string name) throws java.rmi.remoteexception; boolean delbook(string name) throws java.rmi.remoteexception; Book[] getcarrello() throws java.rmi.remoteexception; float getconto() throws java.rmi.remoteexception; Book[] getavailablebooks() throws java.rmi.remoteexception; boolean closeorder(string numcarta,int tipo) throws java.rmi.remoteexception; int VISA = 0; int MASTERCARD = 1; int AMERICANEXPR = 2; //definizione del tipo di carta Listato 6.1: BookOrder.java package BookOrder; import javax.ejb.*; public interface BookOrderHome extends EJBHome BookOrder create(string user,string pass) throws java.rmi.remoteexception, CreateException; Listato 6.2: BookOrderHome.java

197 6.5 Package Archivio 196 package BookOrder; import javax.ejb.*; import java.rmi.*; import Archivio.*; import java.util.*; import javax.jms.*; import javax.naming.*; public class BookOrderBean implements SessionBean private SessionContext ctx; private DataLayer istanza; private String user; private Vector carrello; private float conto; private javax.jms.topic destination; private TopicConnection connection; //comunicazione jms degli eventi associati all acquisto //di un libro public BookOrderBean() carrello=new Vector(); conto=0; destination = null; connection = null; public void setsessioncontext(sessioncontext parm1) throws EJBException, RemoteException //realizza la comunicazione tra il Bean ed il Container //il parametro viene utilizzato dal MDB ctx=parm1; Listato 6.3: BookOrderBean.java

198 6.5 Package Archivio 197 //********* //metodi di gestione degli EJB //********* public void ejbcreate(string utente,string passwd) throws RemoteException, CreateException System.out.println("BookOrderBean:Create()"); try istanza=(datalayer)naming.lookup ("rmi://localhost:2000/archivio"); if (istanza.checkuser(utente,passwd)) user=utente; createjmsconnection(); else throw(new CreateException()); catch(jmsexception jme) jme.printstacktrace(); throw(new CreateException()); catch(namingexception nme) nme.printstacktrace(); throw(new CreateException()); catch(java.net.malformedurlexception mue) mue.printstacktrace(); throw(new CreateException()); catch(notboundexception nbe) nbe.printstacktrace(); throw(new CreateException()); Listato 6.4: BookOrderBean.java

199 6.5 Package Archivio 198 public void ejbremove() throws EJBException, RemoteException try System.out.println("BookOrderBean:Remove()"); connection.close(); catch(jmsexception err) err.printstacktrace(); //metodi standard per la gestione dell EJB stateful public void ejbactivate() throws EJBException, RemoteException public void ejbpassivate() throws EJBException, RemoteException //************** //metodi che implementano la logica di business vera e propria //************** public boolean addbook(string name) throws RemoteException Book newbook=istanza.getbookbyname(name); if (carrello.indexof(newbook)==-1) //se il libro nonè nel carrello carrello.add(newbook); conto+=newbook.getcosto(); return(true); else return(false); Listato 6.5: BookOrderBean.java

200 6.5 Package Archivio 199 public boolean delbook(string name) throws RemoteException Iterator iter=carrello.iterator(); while(iter.hasnext()) Book abook=(book)iter.next(); if (abook.gettitolo().equals(name)) iter.remove(); conto-=abook.getcosto(); return(true); return(false); public Book[] getcarrello() throws RemoteException //restituisce i libri che si trovano nel carrello Book[] retvalue=new Book[carrello.size()]; Iterator iter=carrello.iterator(); int i=0; while(iter.hasnext()) retvalue[i++]=(book)iter.next(); return(retvalue); Listato 6.6: BookOrderBean.java

201 6.5 Package Archivio 200 public float getconto() throws RemoteException return(conto); public Book[] getavailablebooks() throws RemoteException Book list[]=istanza.getlist(); int size=list.length-carrello.size(); //numero di libri rimasti ancora non acquistati Book retvalue[]=new Book[size]; int j=0; for(int i=0;i<list.length;i++) if (carrello.indexof(list[i])<0) //verifica sei i libri sono nel carrello o meno retvalue[j++]=list[i]; //se non ci sono aggiorna l array dei libri //ancora disponibili return(retvalue); Listato 6.7: BookOrderBean.java

202 6.5 Package Archivio 201 public boolean closeorder(string numcarta, int tipo) throws RemoteException try if(!istanza.checkcreditcard(user,numcarta,tipo)) //se la cartaè sbagliata non chiude l ordine return(false); TopicSession session=connection.createtopicsession (false,session.auto_acknowledge); TopicPublisher publisher = session.createpublisher(destination); ObjectMessage message=session.createobjectmessage(); message.setobject(new Order(user,carrello)); publisher.send(message); return(true); catch(jmsexception err) err.printstacktrace(); return(false); private void createjmsconnection() throws NamingException,JMSException Context ctx = new InitialContext(); TopicConnectionFactory cf = (TopicConnectionFactory)ctx. lookup("connectionfactory"); connection = cf.createtopicconnection(); destination = (javax.jms.topic)ctx.lookup("topic/ordinitopic"); Listato 6.8: BookOrderBean.java

203 6.5 Package Archivio 202 package BookOrderMDB; import javax.jms.*; import javax.ejb.*; import java.io.*; import Archivio.*; public class BookMDBean implements MessageListener, MessageDrivenBean private MessageDrivenContext ctx; private static final String nomefilelog="/orders.log"; public void setmessagedrivencontext (MessageDrivenContext parm1) throws EJBException ctx=parm1; public void ejbcreate() public void ejbremove() throws EJBException System.out.println("BookMDBean:remove()"); Listato 6.9: BookMDBean.java

204 6.5 Package Archivio 203 public void onmessage(message m) if (m instanceof ObjectMessage) try ObjectMessage om=(objectmessage)m; Order unordine=(order)om.getobject(); FileWriter fw=new FileWriter(nomeFileLog,true); PrintWriter pw=new PrintWriter(fw,true); pw.print(unordine.getuser()); pw.print(":"); String[] books=unordine.getbooks(); if (books.length==0) return; pw.print(" "+books[0]); for(int i=1;i<books.length;i++) pw.print(", "+books[i]); pw.println(); fw.close(); catch(jmsexception e) e.printstacktrace(); catch(ioexception e) e.printstacktrace(); Listato 6.10: BookMDBean.java

205 6.6 Package BookStoreSwing 204 definisce il magazzino, cioè i libri che abbiamo a disposizione per gli utenti. Tale classe restituisce le caratteristiche di un libro il cui nome è dato da bookname. DataLayerReg: in tale classe si abilita il collegamento tra server e client RMI, l applicazione instanzia un oggetto remoto e lo registra tramite un bind all interno dell rmi registry. 6.6 Package BookStoreSwing Il package BookStoreSwing contiene al suo interno le seguenti classi Application: è la classe contenente il metodo main, al cui interno si inizializza una nuova istanza della classe Principale. E da tale classe che parte l esecuzione di tutta l applicazione. Principale: classe che estende JFrame, cioè eredita tutte le proprietà di JFrame. Non contiene metodi, ma all interno del suo costruttore ha sia la creazione di nuove istanze dei diversi componenti che andranno a comporre l interfaccia principale che visualizzerà l utente nell utilizzo dell applicazione, sia l implemantazione della gestione degli eventi, richiamando l ascoltatore definito nella classe PrincipaleListener. PrincipaleListener: tale classe implementa gli ActionListener, cioè definisce le funzioni dichiarate nell interfaccia ActionListener. Nel metodo actionperformed di tale classe vengono definite le azioni che saranno eseguite dal sistema a seconda dell evento catturato. Tali azioni sono definite richiamando i metodi start(), chiudi() ed elimina() definiti sempre all interno di tale classe. OrderListener: in questa classe si definisce una comunicazione JMS attraverso un topic (cioè attraverso un canale virtuale), tramite il metodo onmessage si definisce il formato dei messaggi da ricevere. 6.7 Modulo Accesso.war Nel progetto è inoltre presente il modulo Accesso.war. Tale modulo implementa la view, cioè sono state aggiunte delle servlet e delle JSP per permettere agli utenti di visionare ciò che si ottiene dal dialogo con i Beans. Le classi appartenenti a questo modulo sono:

206 6.7 Modulo Accesso.war 205 package Archivio; public class Book implements java.io.serializable private String titolo; private String[] listaautori; private float costo; public Book(String untitolo, String[] autori, float uncosto) titolo=untitolo; listaautori=autori; costo=uncosto; public String gettitolo() return(titolo); public String[] getlistaautori() return(listaautori); public float getcosto() return(costo); public boolean equals(object unaltro) if (!(unaltro instanceof Book)) return(false); return(((book)unaltro).titolo.equals(titolo)); Listato 6.11: Book.java

207 6.7 Modulo Accesso.war 206 package Archivio; import java.rmi.*; public interface DataLayer extends Remote boolean checkuser(string nome, String passwd) throws RemoteException; Book[] getlist() throws RemoteException; boolean checkcreditcard (String nome, String numcarta, int tipo) throws RemoteException; Book getbookbyname(string bookname) throws RemoteException; Listato 6.12: DataLayer.java Order.jsp In tale JSP viene realizzata la gestione delle ordinazioni. Tale gestione comprende la possibilità di ottenere diversi servizi come la lista dei libri ordinati ( contenuta in carrello), la possibilità di eliminare degli ordini, etc. Come noto, una JSP è una pagina web contente sia codice HTML che codice Java, il quale viene compilato solo al momento della prima invocazione della pagina JSP generando una Servlet. In questo file abbiamo principalmente codice HTML, mentre le richieste Java e le chiamate ai Java Beans sono contenute in appositi tag. Pagamento.jsp In questa pagina avviene la gestione dei pagamenti. All utente si presenta una form contenente la richiesta di diverse informazioni relative alla sua identità ed alla carta di credito utilizzata per i pagamenti. Nell esempio considerato l identità è cablata nel codice ( sono abilitati solo alcuni utenti). Controller In tale classe viene implementata una Servlet. Controller estende HttpServlet, cioè eredita le proprietà dell interfaccia HttpServlet. In questa classe si ha solo l implementazione del metodo service() il quale realizza la comunicazione bidirezionale con i client tramite i suoi due parametri: HttpServletRequest che contiene i dati inviati dal client, e HttpServletResponse che rappresenta la risposta della Servlet al client. All interno di service viene dapprima richiamata la sessione,

208 6.7 Modulo Accesso.war 207 package Archivio; import java.rmi.server.*; import java.rmi.*; public class DataLayerImpl extends UnicastRemoteObject implements DataLayer private static String[][] userlist= "de Leoni", "Max", "Russo", "Ruggero", "Mecella", "One", "Topolino", "313", "Paperino", "Qui" ; private static Book[] booklist=new Book[5]; public DataLayerImpl() throws RemoteException super(); String[] autori1="de Leoni","Russo","Mecella"; booklist[0]=new Book("J2EE",autori1,100); String[] autori2="e","cay Horstmann"; booklist[1]=new Book("Concetti di informatica e Fondamenti di Java 2",autori2,40); String[] autori3="p. Yao","D. Durant"; booklist[2]=new Book(".NET Compact Programming", autori3,50); String[] autori4="aa.vv."; booklist[3]=new Book("XYZ",autori4,2); String[] autori5="s. Ambler","T. Jewell"; booklist[4]=new Book("Mastering EJB",autori5,77); Listato 6.13: DataLayerImpl.java

209 6.7 Modulo Accesso.war 208 public boolean checkuser(string nome, String passwd) throws RemoteException for(int i=0;i<userlist.length;i++) if(userlist[i][0].equals(nome)) return(userlist[i][1].equals(passwd)); return(false); public Book[] getlist() throws RemoteException return(booklist); public boolean checkcreditcard (String nome, String numcarta, int tipo) throws RemoteException if (numcarta.length()!=16) return(false); char array[]=numcarta.tochararray(); for (int i=0;i<array.length;i++) if (array[i]< 0 array[i]> 9 ) return(false); return(true); public Book getbookbyname(string bookname) throws RemoteException for(int i=0;i<userlist.length;i++) if(booklist[i].gettitolo().equals(bookname)) return(booklist[i]); return(null); Listato 6.14: DataLayerImpl.java

210 6.7 Modulo Accesso.war 209 package Archivio; import java.rmi.*; public class DataLayerReg public static void main(string[] args) throws Exception DataLayerImpl obj=new DataLayerImpl(); Naming.rebind("rmi://localhost:2000/Archivio",obj); // NUMERO DI PORTA! Listato 6.15: DataLayerReg.java public class Application public static void main(string[] args) new Principale(); Listato 6.16: Application.java

211 6.7 Modulo Accesso.war 210 import javax.swing.*; import java.awt.*; import Archivio.*; public class Principale extends JFrame public JList lista; public DefaultListModel model; private JPanel sudpnl=new JPanel(); private JScrollPane listscrollpane; public JButton startbtn=new JButton("Start"); public JButton chiudibtn=new JButton("Chiudi"); public JButton eliminabtn=new JButton("Processato"); private PrincipaleListener ascoltatore; public Principale() super("client ordini"); model=new DefaultListModel(); lista = new JList(model); listscrollpane = new JScrollPane(lista); sudpnl.add(startbtn); ascoltatore=new PrincipaleListener(this); sudpnl.add(eliminabtn); sudpnl.add(chiudibtn); startbtn.addactionlistener(ascoltatore); chiudibtn.addactionlistener(ascoltatore); eliminabtn.addactionlistener(ascoltatore); startbtn.setactioncommand(ascoltatore.start); chiudibtn.setactioncommand(ascoltatore.chiudi); eliminabtn.setactioncommand(ascoltatore.elimina); getcontentpane().add (listscrollpane,borderlayout.center); getcontentpane().add(sudpnl,borderlayout.south); setdefaultcloseoperation(jframe.exit_on_close); chiudibtn.setenabled(false); eliminabtn.setenabled(false); setsize(300,300); setvisible(true); Listato 6.17: Principale.java

212 6.7 Modulo Accesso.war 211 import java.awt.event.*; import javax.swing.*; import Archivio.*; import javax.jms.jmsexception; importjavax.naming.namingexception; public class PrincipaleListener implements ActionListener private Principale frame; public static final String START="S"; public static final String CHIUDI="C"; public static final String ELIMINA="E"; private OrderListener jmslistener=null; public PrincipaleListener(Principale unframe) frame=unframe; public void actionperformed(actionevent e) try String com=e.getactioncommand(); if (com == START) start(); else if (com == CHIUDI) chiudi(); else if (com == ELIMINA) elimina(); catch(exception err) JOptionPane.showMessageDialog (frame,err.getmessage(),"lanciata eccez.", JOptionPane.ERROR_MESSAGE); err.printstacktrace(); Listato 6.18: PrincipaleListener.java

213 6.7 Modulo Accesso.war 212 private void start() throws NamingException,JMSException jmslistener=new OrderListener (frame.model,"topic/ordinitopic"); frame.startbtn.setenabled(false); frame.chiudibtn.setenabled(true); frame.eliminabtn.setenabled(true); private void chiudi() throws JMSException jmslistener.stop(); frame.dispose(); private void elimina() /*Restituisce l indice dell elemento selezionato (-1 se nessun indiceè stato selezionato)*/ int index=frame.lista.getselectedindex(); if (index==-1) /*Se nonè stato selezionato alcun indice, allora errore, altrimenti lo visualizza*/ JOptionPane.showMessageDialog (frame,"nessun indice selezionato","errore", JOptionPane.ERROR_MESSAGE); else frame.model.remove(index); Listato 6.19: PrincipaleListener.java

214 6.7 Modulo Accesso.war 213 import javax.jms.*; import javax.naming.*; import javax.swing.*; import java.util.properties; import Archivio.*; public class OrderListener implements MessageListener private DefaultListModel listmodel; private TopicConnection connection = null; public OrderListener (DefaultListModel model, String topicname) throws NamingException, JMSException listmodel = model; InitialContext ctx = null; TopicConnectionFactory cf = null; TopicSession session = null; Topic destination = null; TopicSubscriber subscriber = null; Properties properties = new Properties(); properties.put(context.initial_context_factory, "org.jnp.interfaces.namingcontextfactory"); properties.put (Context.URL_PKG_PREFIXES, "org.jnp.interfaces"); properties.put(context.provider_url, "localhost"); ctx = new InitialContext(properties); cf = (TopicConnectionFactory)ctx. lookup("connectionfactory"); destination = (Topic)ctx.lookup(topicName); connection = cf.createtopicconnection(); session = connection.createtopicsession(false, Session.AUTO_ACKNOWLEDGE); subscriber = session.createsubscriber(destination); subscriber.setmessagelistener (this); connection.start(); Listato 6.20: OrderListener.java

215 6.7 Modulo Accesso.war 214 public void onmessage(message mex) try if (mex instanceof ObjectMessage) ObjectMessage objmex=(objectmessage)mex; Object obj=objmex.getobject(); if (obj instanceof Order) Order ordine=(order)obj; String text=ordine.getuser()+":"; String lista[]=ordine.getbooks(); for(int i=0;i<lista.length;i++) text+=" "+lista[i]; listmodel.addelement(text); catch(jmsexception jmsexc) listmodel.addelement ("Errore: "+jmsexc.getmessage()); public void stop() throws JMSException connection.close(); Listato 6.21: OrderListener.java

216 6.8 Il deployment descriptor 215 dopodichè viene aggiunto un nuovo elemento al carrello virtuale di spesa dell utente. PagamentoServlet Anche in tale classe si ha l implementazione di una Servlet e quindi l implementazione del metodo service(). In questa Servlet prima di tutto viene richiamata la sessione, dopodichè si verifica la tipologia di pagamento e se è avvenuto con successo. ConfirmServlet In tale classe viene implementata la Servlet necessaria alla verifica dei dati inseriti dall utente per fare il login. Se il login ha avuto esito positivo allora viene inizializzato il contesto JNDI. DeleteBook L implementazione di tale Servlet serve per eliminare degli elementi dal carrello di spesa dell utente. Anche in tal caso abbiamo l implementazione del metodo service(), nel quale come prima cosa appare la chiamata alla sessione. 6.8 Il deployment descriptor Essendo un singolo EJB composto da diversi bean, i deployment descriptor sono uniti in un singolo file. L ejb-jar file di questa applicazione è mostrato nel Listato Il file specifico per JBoss è jboss.xml (Listato 6.33). Di seguito vengono riportati i file jboss.xml e ejb-jar.xml. 6.9 Provare l applicazione Per provare l applicazione, innanzitutto bisogna compilare e avviare RMI. I passi da seguire per la compilazione sono i seguenti: Per compilare RMI: 1. Compilare i file ponendosi nella directory...\rmibookstore con l istruzione javac Archivio\*.java 2. Compilare l implementazione dell interfaccia DataLayerImpl(in questo modo viene prodotto DataLayerImpl stub.class) attraverso l istruzione rmic Archivio.DataLayerImpl per la creazione dello stub 3. Copiare lo stub nella directory del client

217 6.9 Provare l applicazione 216 <html> page contenttype="text/html; charset=iso " language="java" import="java.util.*, javax.naming.*, java.io.*, BookOrder.*, Archivio.*" errorpage="" %> <head> <title>gestione delle Ordinazioni</title> </head> <body bgcolor="#ffffcc" text="#000000"> </style> </head> <% BookOrder carrello = (BookOrder)session.getAttribute("carrello"); if (carrello==null) out.println("effettuare il <a href=\"index.html\"> login</a> prima di continuare!"); return; Book[] booklist = (Book[])carrello.getCarrello(); %> <b>libri nel Carrello:</b> <table width="41%" border="0"> <tr> <td> <form method="get" action="deletebook"> <select size="3" name="dellibro"> <% for(int i=0;i<booklist.length;i++) out.print("<option>"); out.print(booklist[i].gettitolo()); out.println("</option>"); %> Listato 6.22: Order.jsp

218 6.9 Provare l applicazione 217 </select></td> <td align="center" valign="middle"> </td> </tr> <tr> <td width="45%" align="center" valign="middle"></td> <td width="55%" align="center" valign="middle"></td> </tr> <tr> <td align="center" valign="middle"> <input type="submit" value="delete..."></td> </form> <form method="get" action="pagamento.jsp"> <td align="center" valign="middle"> <input type="submit" value="procedi al pagamento"></td> </form> Conto: <%= carrello.getconto() %> <td align="center" valign="middle"></td> </tr> </table> <p> </p> <p><b>libri Disponibili:</b> </p> <table width="41%" border="0"> <tr> <td align="center"> <form method="get" action="controller"> <select size="3" name="biblioteca"> <% Book[] avail=carrello.getavailablebooks(); for(int i=0;i<avail.length;i++) out.print("<option>"); out.print(avail[i].gettitolo()); out.println("</option>"); %> Listato 6.23: Order.jsp

219 6.9 Provare l applicazione 218 </select></td> <td align="center" valign="middle"> </td> </tr> <tr> <td width="45%" align="center" valign="middle"></td> <td width="55%" align="center" valign="middle"></td> </tr> <tr> <td align="center" valign="middle"> <input type="submit" value="add to..."></td> </form> </tr> <tr> <td align="center" valign="middle"></td> <td align="center" valign="middle"></td> </tr> </table> </body> </html> Listato 6.24: Order.jsp 4. Mandare in esecuzione il registry con l istruzione start rmiregistry 2000 (2000 è il numero di porta utilizzato nell esempio considerato, è necessario scegliere il numero di porta perchè JBoss occupa quella utilizzata di default da RMI) 5. Registrare il Remote Server Object attraverso l istruzione java Archivio.DataLayerReg Per la compilazione della servlet: BookStore.jar 1. BookStore.jar: compilo i file in Archivio, da BookStore.jar compilo i file in BookOrder: javac -classpath C:\<jboss home>\client\jboss-j2ee.jar;. BookOrder\*.java javac -classpath.;c:\<jboss home>\client\jboss-j2ee.jar BookOrderMDB\*.java 2. Accesso.war: compilo le classi java javac-classpath.; C:\<jboss home>\client\jbossj2ee.jar; C:\<jboss home>\client\javax.servlet.jar *.java Infine per il deploy: 1. Deploy delle servlet: Accesso.war in <jboss home> \... \ deploy

220 6.9 Provare l applicazione 219 <html> page contenttype="text/html; charset=iso " language="java", import="java.util.*, javax.naming.*, java.io.*, BookOrder.*, Archivio.*" errorpage="" %> <head> <title>pagamento</title> </head> <body> <% BookOrder b = (BookOrder)session.getAttribute("carrello"); %> <form method=get action="pagamentoservlet"> Nome:<input TYPE=text SIZE=30 NAME="Utente"><br><p> Credit Card (16 cifre): <input TYPE=text SIZE=30 NAME="CC"><p> <tr> <td>tipo:</td><p> <td> <input type="radio" name="tipo" value="0" checked>visa<br> <input type="radio" name="tipo" value="1"checked>mastercard<br> <input type="radio" name="tipo" value="2"checked>americanexpr<br><p> </td> </tr> <tr> <td colspan=2> <input type="submit" value="send Data"> </td> </tr> </form> </body> </html> Listato 6.25: Pagamento.jsp

221 6.9 Provare l applicazione 220 import javax.servlet.*; import javax.servlet.http.*; import java.io.*; import javax.naming.*; import BookOrder.*; importjava.util.*; import javax.ejb.*; import java.net.*; public class Controller extends HttpServlet public void service(httpservletrequest req, HttpServletResponse res) throws IOException,ServletException HttpSession s=req.getsession(); BookOrder b=(bookorder)s.getattribute("carrello"); String titolo=(string)req.getparameter("biblioteca"); b.addbook(titolo); String messaggio="libro aggiunto al carrello"; String link="order.jsp"; OutputStream os=res.getoutputstream(); PrintWriter out=new PrintWriter(os); out.println("<html><head><title>ok</title></head>"); out.println("<body>"); out.println(messaggio); out.println("<a href=\"" +link+ "\">Continua</a>"); out.println("</body></html>"); out.close(); Listato 6.26: Controller.java

222 6.9 Provare l applicazione 221 import javax.servlet.*; import javax.servlet.http.*; import java.io.*; import javax.naming.*; import BookOrder.*; import java.util.*; import javax.ejb.*; import java.lang.*; public class PagamentoServlet extends HttpServlet public void service (HttpServletRequest req, HttpServletResponse res) throws IOException,ServletException //richiamo la sessione HttpSession s=req.getsession(); BookOrder b=(bookorder)s.getattribute("carrello"); String Uid=req.getParameter("Utente"); String CCString=req.getParameter("CC"); String tipostringa=req.getparameter("tipo"); int tipoint= Integer.parseInt(tipoStringa); String Carta=null; String messaggio=null; String messaggio2=null; String link=null; if (tipoint==0) Carta="VISA"; if (tipoint==1) Carta="MASTERCARD"; if (tipoint==2) Carta="AMERICANEXPR"; Listato 6.27: PagamentoServlet.java

223 6.9 Provare l applicazione 222 if(b.closeorder(ccstring,tipoint)) messaggio="hai inserito i seguenti dati: "; messaggio2="pagamento avvenuto con successo!!!"; link="index.html"; //Annullo la sessione Servlet/JSP s.invalidate(); /*Notifico al Container che il Session Bean nonè necessario oltre */ try b.remove(); catch(removeexception e) e.printstacktrace(); else messaggio="i seguenti dati sono errati: "; messaggio2="verifica l inserimento"; link="pagamento.jsp"; OutputStream os=res.getoutputstream(); PrintWriter out=new PrintWriter(os); out.println("<html><head><title> Pagina di conferma</title></head>"); out.println("<body>"); out.println("<b>"+messaggio+ "</b><br>"); out.println("<p>"); out.println("<b>nome: " +Uid+"</b><br>"); out.println("<p>"); out.println("<b>carta: "+Carta+ "</b><br><p>"); out.println("<b>"+messaggio2+"</b>"); out.println("<a href=\"" +link+ "\">Continua</a>"); out.println("</body></html>"); out.close(); Listato 6.28: PagamentoServlet.java

224 6.9 Provare l applicazione 223 import javax.servlet.*; import javax.servlet.http.*; import java.io.*; import javax.naming.*; import BookOrder.*; import java.util.*; import javax.ejb.*; public class ConfirmServlet extends HttpServlet //fa da client del BookOrderBean public void service (HttpServletRequest req, HttpServletResponse res) throws IOException,ServletException String Uid=req.getParameter("Uid"); String password=req.getparameter("password"); String messaggio = "<b>login avvenuto con successo!</b>"; String link="order.jsp"; OutputStream os=res.getoutputstream(); PrintWriter out=new PrintWriter(os); HttpSession sess=req.getsession(); //recupero l oggetto session //porzione di codice per l inizializzazione del contesto JNDI Properties prop = new Properties(); prop.put(javax.naming.context.initial_context_factory, "org.jnp.interfaces.namingcontextfactory"); prop.put(javax.naming.context.url_pkg_prefixes, "org.jnp.interfaces"); prop.put(javax.naming.context.provider_url, "localhost"); Listato 6.29: ConfirmServlet.java

225 6.9 Provare l applicazione 224 try //inizializzazione del contesto javax.naming.context ctx = new InitialContext(prop); //acquisizione dell interfaccia HOME Object object = ctx.lookup("bookorder"); BookOrderHome home = (BookOrderHome)javax.rmi.PortableRemoteObject.narrow(object, BookOrderHome.class); //utilizzo l interfaccia home per creare l EJB BookOrder bookserver = home.create(uid,password); sess.setattribute("carrello",bookserver); catch (CreateException e) //inviata da BookOrderBean messaggio="login errato!!!"; link="index.html"; catch (NamingException e) messaggio="impossibile creare contesto:" + e.tostring(); out.println("<html><head><title> Login Page</TITLE></HEAD>"); out.println("<body>"); out.println(messaggio); out.println("<a href=\"" +link+ "\">Continua</a>"); out.println("</body></html>"); out.close(); Listato 6.30: ConfirmServlet.java

226 6.9 Provare l applicazione 225 import javax.servlet.*; import javax.servlet.http.*; import java.io.*; import javax.naming.*; import BookOrder.*; import java.util.*; import javax.ejb.*; import java.net.*; //import Archivio.*; public class DeleteBook extends HttpServlet public void service (HttpServletRequest req, HttpServletResponse res) throws IOException,ServletException HttpSession s=req.getsession(); BookOrder b=(bookorder)s.getattribute("carrello"); String titolo=(string)req.getparameter("dellibro"); b.delbook(titolo); String messaggio="libro eliminato dal carrello"; String link="order.jsp"; /* ServletContext app = getservletcontext(); RequestDispatcher disp; disp = app.getrequestdispatcher("/order.jsp"); OutputStream os=res.getoutputstream(); PrintWriter out=new PrintWriter(os); out.println("<html><head><title> Libro eliminato</title></head>"); out.println("<body>"); out.println(messaggio); out.println("<a href=\"" +link+ "\">Continua</a>"); out.println("</body></html>"); out.close(); Listato 6.31: DeleteBook.java

227 6.9 Provare l applicazione 226 <?xml version="1.0" encoding="utf-8"?> <web-appxmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xsi:schemalocation="http://java.sun.com/xml/ns/j2ee version="2.4"> <servlet> <servlet-name>confirmservlet</servlet-name> <servlet-class>confirmservlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>confirmservlet</servlet-name> <url-pattern>/confirmservlet</url-pattern> </servlet-mapping> <servlet> <servlet-name>controller</servlet-name> <servlet-class>controller</servlet-class> </servlet> <servlet-mapping> <servlet-name>controller</servlet-name> <url-pattern>/controller</url-pattern> </servlet-mapping> <servlet> <servlet-name>deletebook</servlet-name> <servlet-class>deletebook</servlet-class> </servlet> <servlet-mapping> <servlet-name>deletebook</servlet-name> <url-pattern>/deletebook</url-pattern> </servlet-mapping> <servlet> <servlet-name>pagamentoservlet</servlet-name> <servlet-class>pagamentoservlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>pagamentoservlet</servlet-name> <url-pattern>/pagamentoservlet</url-pattern> </servlet-mapping> </web-app> Listato 6.32: web.xml

228 6.9 Provare l applicazione 227 <?xml version="1.0" encoding="utf-8"?> <jboss> <enterprise-beans> <session> <ejb-name>bookorderejb</ejb-name> <jndi-name>bookorder</jndi-name> </session> <message-driven> <ejb-name>bookmdbean</ejb-name> <destination-jndi-name> topic/ordinitopic </destination-jndi-name> </message-driven> </enterprise-beans> </jboss> Listato 6.33: jboss.xml 2. Deploy del topic ordinitopic-service.xml in <jboss home>\... \deploy 3. Deploy dell EJB: BookOrder.jar in <jboss home> \... \deploy Per la compilazione dell interfaccia per il venditore: BookStoreSwing 1. Compilo le classi java javac -classpath C:\<jboss home>\client\jbossallclient.jar;. *.java 2. Per visualizzare l interfaccia, mando in esecuzione la classe Application contenente il main java -classpath C:\<jboss home>\client\jbossall-client.jar;. Application

229 6.9 Provare l applicazione 228 <!DOCTYPE ejb-jar PUBLIC -//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN http ://java.sun.com/dtd/ejb-jar_2_0.dtd > <ejb-jar> <enterprise-beans> <session> <ejb-name>bookorderejb</ejb-name> <home>bookorder.bookorderhome</home> <remote>bookorder.bookorder</remote> <ejb-class>bookorder.bookorderbean</ejb-class> <session-type>stateful</session-type> <transaction-type>container</transaction-type> </session> <message-driven> <ejb-name>bookmdbean</ejb-name> <ejb-class>bookordermdb.bookmdbean</ejb-class> <message-driven-destination> <destination-type> javax.jms.topic </destination-type> </message-driven-destination> <transaction-type>container</transaction-type> </message-driven> </enterprise-beans> </ejb-jar> Listato 6.34: ejb-jar.xml

230 Capitolo 7 Web Service Secondo la definizione data dal W3C 1 un Web Service (servizio web) è un sistema software progettato per supportare l interoperabilità tra diversi elaboratori su di una medesima rete. Il concetto di Web Service è molto simile a quello di oggetto, nel significato con cui lo si usa nella programmazione ad oggetti: un oggetto è un modulo software che offre una serie di funzioni utilizzabili dall esterno da parte di un altro software tramite un interfaccia di comunicazione dichiarata dall oggetto stesso. Allo stesso modo anche un Web Service offre una funzionalità, un servizio, ad altri client sulla rete attraverso un interfaccia ben definita tramite il protocollo HTTP. Caratteristica fondamentale di un Web Service è quella di offrire un interfaccia software basata su XML (descritta in un formato automaticamente elaborabile quale, ad esempio, il WSDL) tramite la quale comunica le funzioni che mette a disposizione e le relative modalità di utilizzo. L XML può essere utilizzato correttamente tra piattaforme differenti (Linux, Windows, Mac) e differenti linguaggi di programmazione. XML è inoltre in grado di esprimere messaggi e funzioni anche molto complesse e garantisce che tutti i dati scambiati possano essere utilizzati ad entrambi i capi della connessione, essendo uno standard facilmente interpretabile grazie a software specifici; si può quindi dire che i Web Service sono basati su XML ed HTTP e che possono essere utilizzati su ogni piattaforma e con ogni tipo di software. Utilizzando tale interfaccia, altri sistemi possono interagire con il Web Service invocando le operazioni descritte nell interfaccia tramite appositi messaggi inclusi in una busta SOAP: tali messaggi sono solitamente trasportati tramite il protocollo HTTP e formattati secondo lo standard XML. Questi messaggi sono utilizzati come un contenitore (envelope), dove le applicazioni inseriscono ogni informazione che deve essere spedita. Ogni envelope è formato da due par- 1 The World Wide Web Consortium 229

231 7.1 Le tecnologie alla base dei Web Services 230 Figura 7.1: Rappresentazione schematica di un messaggio SOAP ti: un intestazione (header) ed un corpo del messaggio (body) (Figura 7.1) L header è opzionale, il body invece è obbligatorio, tutti i messaggi SOAP devono avere un corpo del messaggio. Sia l header che il body possono avere sottostrati multipli nella forma di header blocks o body blocks. Il protocollo SOAP assume che ogni messaggio abbia un mittente ed un destinatario finale, e che un numero arbitrario di intermediari (detti nodi), processano il messaggio e lo instradano al destinatario. L informazione che il mittente vuole trasmettere al destinatario sarà incapsulata nel body del messaggio, invece, ogni informazione aggiuntiva necessaria per il processamento intermedio è posta nell header. L idea base è quella di qualsiasi protocollo standard di comunicazione. La differenza sostanziale tra un servizio web offerto in Internet e un Web Service sta nel tipo di fornitore del servizio. Per i servizi web (come per esempio per gli accessi a banche o ad ) è la persona fisica che accede direttamente attraverso una form html, mentre i Web Service sono a disposizione di programmi che, tramite il protocollo SOAP, si scambiano informazioni e quindi l integrazione con il servizio avviene attraverso lo scambio di messaggi sulla rete. 7.1 Le tecnologie alla base dei Web Services Il protocollo di base per i Web Service è HTTP. Questo protocollo si occupa di mettere in comunicazione il Web Service con l applicazione che intende usufruire delle sue funzioni. I Web Service si basano su tre tecnologie di

232 7.1 Le tecnologie alla base dei Web Services 231 fondamentali: SOAP (Simple Object Access Protocol) per la comunicazione. Le interazioni con i Web Service sono basate sul Simple Object Access Protocol (SOAP) per la definizione dei messaggi. Mediante l uso di tale protocollo, è possibile lo scambio di messaggi usando uno standard che permetta la conversione del servizio in messaggi XML. SOAP sta al di sopra del livello applicativo/trasporto e un suo punto di forza è che questo protocollo può essere usato insieme a una varietà di protocolli (http, smtp, ftp, jabber e così via). Il più usato è solitamente HTTP grazie alla sua vasta diffusione è adatto allo sviluppo di Web Service. Questo è dovuto alla sua semplicità, alla robustezza e alla possibilità di viaggiare sulla rete evitando problematiche legate ai firewall, come invece può accadere usando protocolli come CORBA o RMI. WSDL (Web Services Description Language) per la descrizione dell interfaccia del servizio. Il Web Service Definition Language (WSDL) è il modo standardizzato in cui viene descritto il servizio e in cui vengono mostrate le sue interfacce. Questo protocollo è un XML-based IDL (Interface Definition Language) che introduce delle estensioni rese necessarie dalla mancanza di un middleware centralizzato. Attraverso il WSDL è possibile conoscere i metodi supportati dal Web Service e quali sono i loro input ed output. Grazie ad esso, è possibile generare lo stub e gli strati intermedi che rendono la chiamata al Web Service trasparente. In generale WSDL cerca di separare gli aspetti astratti della descrizione di un servizio da quelli concreti che lo legano a particolari protocolli di rete o di RPC. UDDI (Universal Description, Discovery and Integration) Per poter utilizzare i Web Service in modo dominante e su scala globale è necessario standardizzare i registri dei Web Service. Questo standard prende il nome di Universal Description Discovery and Indegration (UDDI), ovvero un linguaggio che rappresenta il repository che contiene il servizio. Tramite esso, gli utenti possono ricercare servizi adatti alle proprie necessità. Un UDDI registry è utilizzato con il significato di scoperta dei Web Service descritti usando WSDL. L idea è che l UDDI registry può essere cercato in vari modi per ottenere il contatto dell informazione e la disponibilità dei Web Service per varie organizzazioni. L UDDI potrebbe essere un modo di tenere aggiornato il Web Service che l organizzazione ha appena utilizzato. Questi tre protocolli aperti sono alla base della interoperabilità tra i diversi sistemi software e tra le diverse piattaforme hardware. Grazie a questi proto-

233 7.1 Le tecnologie alla base dei Web Services 232 colli indipendenti dal linguaggio di programmazione o dal sistema operativo, è possibile far coesistere per esempio un client scritto in C con un server scritto in Java. Questo avviene grazie all XML su cui, come già detto, sono basati i protocolli utilizzati. Nei prossimi paragrafi entreremo più nel dettaglio dei tre elementi caratterizzanti il Web Service e descritti sommariamente nel presente paragrafo SOAP: Simple Object Access Protocol Questo protocollo fornisce una via di comunicazione tra applicazioni eseguite su sistemi operativi diversi, con diverse tecnologie e linguaggi di programmazione, tramite HTTP ed XML. Acronimo di Simple Object Access Protocol, è uno standard nato in casa Microsoft e supportato in una seconda fase da IBM. Ora è uno standard W3C. Un messaggio SOAP è un documento XML che contiene i seguenti elementi: 1. Envelope, identifica il documento come un messaggio SOAP 2. Un elemento Header opzionale contenente informazioni specifiche per l applicazione che permette di definire alcuni messaggi anche con diversi destinatari nel caso il messaggio dovesse attraversare più punti di arrivo 3. Body, elemento indispensabile che contiene le informazioni scambiate dalle richieste/risposte 4. Fault, elemento opzionale che fornisce informazioni riguardo ad eventuali errori manifestati durante la lettura del messaggio Le regole principali per realizzare un messaggio SOAP sono le seguenti: 1. Deve essere codificato con XML; 2. Non deve contenere il collegamento ad un DTD 2 e non deve contenere istruzioni per processare XML Nelle specifiche SOAP convivono quattro diversi aspetti: 1. Il modello di scambio dei messaggi definisce un modo standard per definire come strutturare messaggi XML che saranno scambiati tra i diversi nodi, come gestire gli errori e come chiamare i tag XML che contengono informazioni. 2 Document Type Definition, definisce le componenti ammesse nella costruzione di un documento XML

234 7.1 Le tecnologie alla base dei Web Services 233 <?xml version="1.0"?> <SOAP-ENV:Envelope smlns:soap-env=http://schemas.xmlsoap.org/soap/envelope/> <SOAP-ENV:Body> <ns1:getrate xmlns:ns1="urn:xmethods-currencyexcange"> <contry1>inghilterra</contry1> <contry2>giappone</contry2> </ns1:getrate> <SOAP-ENV:Body> <SOAP-ENV:Envelope> Listato 7.1: Una richiesta SOAP 2. L encoding SOAP fornisce una specifica (opzionale) per definire come strutture dati vengono rappresentate in XML. Essa è basata su una prima bozza delle specifiche XML Schema. 3. Il collegamento tra SOAP e HTTP. Il collegamento HTTP definisce il modo in cui i messaggi SOAP debbano essere veicolati e come devono essere utilizzate le intestazioni HTTP e i codici di ritorno per l invio di messaggi SOAP. 4. L utilizzo di SOAP come meccanismo di RPC. Il modello RPC definisce il modo in cui SOAP può essere utilizzato per rappresentare chiamate a procedure remote. Le specifiche SOAP consentono infatti di realizzare applicazioni distribuite di semplice messaggistica o più evolute. Anatomia del messaggio La comunicazione tramite SOAP avviene con lo scambio di messaggi strutturati in modo specifico comprendente elementi obbligatori ed elementi opzionali. Il tag principale che racchiude tutti gli altri è Envelope. Dentro questo sono presenti Header e Body. Il primo è opzionale, mentre nel corpo sono presenti tutte le informazioni applicative che il nodo vuole inviare. Nel listato 7.1 è presente un semplice messaggio SOAP. I tag Envelope e Body appartengono al namespace

235 7.1 Le tecnologie alla base dei Web Services 234 <?xml version="1.0"?> <SOAP-ENV:Envelope smlns:soap-env=http://schemas.xmlsoap.org/soap/envelope/> <SOAP-ENV:Body> <ns1:getrateresponse xmlns:ns1= "urn:xmethods-currencyexcange"> <return> </return> </ns1:getrate> <SOAP-ENV:Body> <SOAP-ENV:Envelope> Listato 7.2: La risposta L utilizzo di SOAP-ENV è semplicemente una convenzione: al suo posto si sarebbe potuto utilizzare qualsiasi nome simbolico, come ad esempio ns1, utilizzato nel corpo del messaggio. Come si può notare, all interno del tag Body è definito il messaggio applicativo: nel tag getrate sono presenti i tag country1 e country2. Questo blocco SOAP potrebbe essere un messaggio utilizzato in una applicazione che si occupa di fornire il tasso di conversione tra diverse valute. La risposta SOAP (Listato 7.2) è strutturata in modo da simulare una risposta applicativa. Per convenzione, il nome del tag utilizzato nella risposta è lo stesso della richiesta, a cui è aggiunta la parola Response. Dopo aver visto come è strutturato un messaggio SOAP, cerchiamo ora di capire dove dev essere inviato il messaggio SOAP di richiesta per contattare il Web service e come si collega questo documento SOAP ad HTTP per raggiungere il Web service. Per rispondere bene a queste domande bisogna ricordare il tag <service> e gli attributi soapaction impostati all interno del binding. Partiamo dal tag <service>. Al suo interno si sceglie il nome del nostro Web Service e si crea una porta tramite l elemento <port> collegandola al binding SOAP. All interno di quella porta si definisce un indirizzo scrivendo questa riga: <soap:address location= ai Web

236 7.1 Le tecnologie alla base dei Web Services 235 services/esempio.php/ > L attributo location indica ad un applicazione, che intende sfruttare il Web Service dove deve inviare le sue richieste HTTP. A questo punto SOAP viene incapsulato nel protocollo HTTP ed inviato sulla rete per raggiungere il Web Service. All URL fornito naturalmente il Web Service è in attesa di ricevere delle richieste ed è pronto a dare le risposte più appropriate. Per far comprendere al Web Service quale azione deve intraprendere, l applicazione aggiunge all header HTTP una stringa in grado di indicare l azione SOAP da intraprendere (così come viene inserita nel binding per ogni operazione definita) WSDL: Web Service Definition Language Un altro elemento fondamentale nell insieme di tecnologie che supportano i Web Service è lo standard WSDL (Web Service Definition Language). Esso consente di descrivere un servizio in tutti i suoi aspetti. In un documento WSDL si trovano tutte le chiamate che si possono fare ad un Web Service, le specifiche delle strutture dati di input e output e le URL per accedere ai servizi. WSDL, a differenza di SOAP, non è uno standard legato a un livello di trasporto particolare ma è aperto all utilizzo con protocolli differenti, specificando di volta in volta i bindings (collegamenti) verso il protocollo adottato. Concretamente, la descrizione di un Web Service è composta da: 1. I binding che legano ciascuna porta astratta a un protocollo e a un formato dati per i messaggi scambiati; 2. Dalle porte che legano le porte astratte istanziate dai binding ad indirizzi di rete reali; 3. I servizi composti da insiemi di porte correlate (che spesso offrono modalità differenti di accesso alla stessa tipologia di servizio). La definizione astratta dei Web Service di WSDL è composta da cinque diversi elementi: - I tipi (types) cioè strutture dati utilizzate come elementi di base per la costruzione dei messaggi di input e output; - I messaggi (messages) sono gli elementi che costituiscono gli input e gli output dei servizi; - Le operazioni (porttype) sono le funzionalità offerte dal servizio;

237 7.1 Le tecnologie alla base dei Web Services I collegamenti (bindings) utilizzati per la mappatura del servizio astratto; - La definizione del servizio (service) necessaria per raccogliere tutte le operazioni sotto un unico nome. Lo standard WSDL privilegia il protocollo SOAP, indicando in una sezione delle sue specifiche le modalità di collegamento a questo standard. Avendo a disposizione un documento WSDL, un sistema software evoluto può dinamicamente invocare un Web Service ed elaborarne il risultato. Questo tipo di informazioni sono quelle che dovranno essere presenti all interno del registry dei Web Service e costituiscono le specifiche tecniche per l accesso a un servizio. L utilizzo di WSDL ha diversi vantaggi tra cui la possibilità di avere a disposizione strumenti di sviluppo che sono in grado di prendere in input file WSDL e produrne codice che implementa l infrastruttura per la realizzazione del servizio, inoltre è un modo per disaccoppiare il Web Service dal protocollo di trasporto e dai percorsi fisici. Come accennato, nel file WSDL è presente l indicazione del protocollo da utilizzare (per esempio un sistema di runtime che supporti diversi protocolli di comunicazione XML potrebbe capire dal WSDL come ricondurre a messaggi SOAP reali le rappresentazioni astratte contenute nel documento WSDL). Un servizio potrebbe infatti partire utilizzando SOAP come protocollo per poi passare ad un nuovo tipo di protocollo con l intento di ottimizzarne le prestazioni, ad esempio per via della sua potenziale minore occupazione di banda. All interno di WSDL Un documento WSDL è un file XML contenente un insieme di definizioni. L aspetto principale del WSDL è costituito dall insieme di regole che consentono di definire in modo astratto un Web Service. Non meno importanti sono le specifiche per collegare il servizio a SOAP e HTTP. Tipi Per ogni messaggio scambiato nell ambito delle operazioni WSDL deve essere definito il tipo. I tipi definiti da WSDL sono l equivalente delle strutture (struct) del linguaggio C, cioè sono strutture dati anche complesse utilizzate come elementi di base per costruire i messaggi di input e output definiti nella sezione messaggi. Per definire i tipi usati all interno del documento, WSDL usa l elemento types. All interno di types può essere inserito un intero

238 7.1 Le tecnologie alla base dei Web Services 237 <types> <schema targetnamespace="http://examples.com/stockquote.xsd" xmlns="http://www.w3c.org/2000/10/xmlschema"> <element name="tradeprincerequest"> <complextype> <all> <element name="ticjedsymbol" type="string"/> </all> </complextype> </element> <element name="tradeprince"> <complextype> <all> <element name="price" type="float"/> </all> </complextype> </element> </schema> </types> Listato 7.3: il primo elemento dei WSDL: i tipi schema XML o qualsiasi altra definizione di tipo valida e definibile tramite una notazione XML riconosciuta. A titolo di esempio, nel Listato 7.3 sono definiti due elementi Trade- PriceRequest, composto da una stringa, e TradePrice, composto da un valore in virgola mobile. In questo caso, dove la struttura dati contiene un solo campo, la definizione di un tipo specifico non è indispensabile: la sua utilità è per lo più relativa alla capacità di mantenere coerenza all interno del documento WSDL. In questo modo infatti viene creato un alias e nel resto del documento WSDL si utilizzeranno i tipi definiti al posto dei tipi di dati primitivi, disaccoppiando il resto delle definizioni dai tipi di dati reali. Messaggi I messaggi sono la base della costruzione di un Web Service con WSDL. Sono gli elementi che costituiscono gli input e gli output dei servizi, e sono definiti in uno o più elementi message che seguono la sezione types. Ciascun messaggio ha un nome univoco ed è costituito da una o più parti, ciascuna

239 7.1 Le tecnologie alla base dei Web Services 238 <message name="getraterequest"> <part name="contry1" type="xsd:string"/> <part name="contry2" type="xsd:string"/> </message> <message name="getrateresponse"> <part name="result" type="xsd:float"/> </message> Listato 7.4: Un messaggio di esempio con un nome e un tipo distinti. I singoli messaggi possono contenere i tipi di dati complessi definiti nella sezione Type oppure semplici dati primitivi. La definizione dei messaggi segue immediatamente quella dei tipi, ciascun elemento message contiene una o più part, ognuna delle quali specifica una parte del messaggio con un determinato nome e tipo. Nel Listato 7.4 è mostrato un file WSDL del servizio mostrato nell esempio precedente. Come si può notare osservando il listato, vengono definiti due diversi messaggi, uno relativo alla richiesta (getraterequest) e uno relativo alla risposta (getrateresponse). Il primo definisce due elementi di tipo Stringa, chiamati Country1 e Country2, il secondo definisce un unico elemento di risposta Result di tipo float. Operazioni In tale sezione definiamo le operazioni fornite dal Web Service. Le operazioni equivalgono alle funzionalità che saranno esposte dall interfaccia del servizio, sono definite in WSDL all interno degli elementi operation; a loro volta gli elementi operation contengono elementi input, output e fault specificanti i messaggi scambiati durante l operazione. Se si ponessero in relazione i Web Service con la programmazione distribuita (ad esempio RMI) le operazioni WSDL equivarrebbero ai singoli metodi di input e di output. Un operazione di riferimento è presente nel Listato 7.5. L elemento <operation>, come già detto, definisce una singola operazione e può contenere opzionalmente almeno uno dei due sottoelementi <output> ed <input>. La presenza e l ordine di questi elementi determina la tipologia del servizio, che può rientrare all interno di quattro diverse categorie: One-way. Anche detto fire&forget, è una configurazione dove l endpoint si limita a ricevere il messaggio inviato dal client. In tal caso è presente

240 7.1 Le tecnologie alla base dei Web Services 239 <porttype name="currencyexchangeporttype"> <operation name="getrate"> <input message = "tns:getraterequest" /> <output message = "tns:getrateresponse" /> </operation> </porttype> Listato 7.5: Un operazione di esempio un solo elemento di input, quindi il client spedisce un messaggio al servizio. Request-response. In tal caso l endpoint riceve un messaggio di richiesta, esegue l elaborazione necessaria e restituisce al client un messaggio di risposta correlato alla richiesta ricevuta. Sono presenti gli elementi input e output, quindi il client spedisce un messaggio al servizio e riceve una risposta. Solicit-response. E l opposto del caso precedente. In questo caso infatti è l endpoint che inizia la comunicazione inviando un messaggio al client che a sua volta dovrà rispondere, quindi il servizio invia un messaggio a un client e questo risponde. Nel file WSDL è presente prima l elemento output e poi quello input. Notification. E l opposto della tipologia one-way, l endpoint invia un messaggio al client senza che questo debba inviare una risposta. E presente solo l elemento output. Il modello di interazione da utilizzare dipende dalla natura del servizio. L interazione request-response costituisce il tipico modello di comunicazione RPC quindi potrebbe essere quella usata per la maggior parte dei servizi, mentre le altre modalità potrebbero risultare più indicate in altri ambiti. Ad esempio una interazione one-way può essere utile in sistemi dove il client non è interessato al risultato dell elaborazione dei dati inviati al servizio. La definizione di una operazione corrisponde alla dichiarazione di un metodo Java appartenente all interfaccia di servizio. Il messaggio di input della operazione consta di argomenti e tipi corrispondenti, mentre il messaggio di output contiene solo il tipo. Qualora il messaggio di output fosse costituito da più parti, l operazione definita non potrebbe avere un suo corrispondente Java, in quanto non potrebbe più essere interpretata come una RPC.

241 7.1 Le tecnologie alla base dei Web Services 240 <wsdl:binding name="nmtoken" type="qname">* <wsdl:operation name="nmtoken">* <wsdl:input>? </wsdl:input> <wsdl:output>? </wsdl:output> <wsdl:fault name="nmtoken"> * </wsdl:fault> </wsdl:operation> </wsdl:binding> Listato 7.6: Sezione WSDL relativa ai collegamenti Collegamenti In questa sezione avviene la mappatura del servizio astratto, definito nelle sezioni precedenti, con il protocollo concreto di comunicazione (ad esempio SOAP). Il contenuto di questa sezione è fortemente dipendente dal protocollo utilizzato e quindi dalle estensioni WSDL relative. Un binding è l istanziazione di una porta astratta, ogni elemento bindings contiene un attributo type che si riferisce al particolare porttype istanziato. La definizione del port- Type viene ripetuta aggiungendo nuovi elementi che specificano come codificare le operazioni e i messaggi. WSDL definisce gli elementi per esprimere vari tipi di binding: SOAP, HTTP, MIME. In WSDL, la struttura di un collegamento (semplificata) è mostrata nel Listato 7.6 Come si può notare, un collegamento può contenere diverse operazioni, ciascuna delle quali può avere un elemento di input, di output e una serie di elementi di errore (fault). Nel listato 7.7, in particolare, è presente un esempio di collegamento con SOAP. La struttura del collegamento è la seguente: sono definiti lo stile di codifica e il tipo di trasporto. Lo stile di codifica viene specificato dall attributo style di soap:bindings e/o soap/operation, il quale può essere RPC oppure document. Se è di tipo RPC, allora il messaggio WSDL viene codificato come una RPC. All interno del body del messaggio viene inserito un elemento con lo stesso nome dell operazione e tanti figli quante sono le part del messaggio associato; se invece è di tipo document, il

242 7.1 Le tecnologie alla base dei Web Services 241 messaggio WSDL viene codificato usandone il contenuto letteralmente. In tal caso, ogni part del messaggio associato a un operazione figurerà come figlio distinto dell elemento Body nel messaggio SOAP. <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/> In questo caso la comunicazione è di tipo RPC e il trasporto avviene sul protocollo HTTP. In secondo luogo, è necessario definire come trattare i messaggi di input ed output per ciascuna operazione. Il contenuto degli elementi input e/o output che compongono ciascuna operation non deve essere ripetuto all interno del binding; gli input e gli output conterranno invece dei nuovi elementi che specificano più in dettaglio come verrà costruito il corrispondente messaggio SOAP, in particolare quali informazioni dovranno essere mappate nell Header e quali nel Body del messaggio. Per definire il contenuto del corpo del messaggio SOAP si usa l elemento soap:body specificando: 1. Le parti del messaggio che saranno incluse nel corpo (attributo parts); 2. La codifica dei tipi interessati (attributi use e encodingstyle): (Use= encoded richiede la codifica di ogni parte in base al suo tipo secondo le regole di encodingstyle, Use=literal indica che le parti vanno copiate letteralmente nel messaggio). 3. Il namespace di provenienza degli elementi usati nel messaggio (attributo namespace) Il messaggio di input è così definito: <soap:body use ="encoded" namespace="urn:xmethods-currencyexchange" encodingstyle="http://schemas.xmlsoap.org/soap/encoding/"/> In questo elemento viene indicato il namespace del messaggio (urn:xmethods - CurrencyExchange) e il tipo di encoding. L attributo use assume valore encoding, quindi l attributo encodingstyle dovrà indicare il tipo di encoding utilizzato. In questo caso viene utilizzato l encoding SOAP. Gli elementi del namespace SOAP contenuti nell elemento binding servono a descrivere come costruire un messaggio SOAP a partire dal messaggio astratto definito in WSDL. In questo caso viene utilizzato l encoding SOAP. è mostrato un esempio di collegamento, relativo sempre al cambio valuta.

243 7.1 Le tecnologie alla base dei Web Services 242 <binding name="currencyexchangebinding" type="tns:currencyexchangeporttype"> <soap:binding style="rpc"transport= "http://schemas.xmlsoap.org/soap/http"/> <operation name="getrate"> <soap:operation soapaction=""/> <input> <soap:body use ="encoded" namespace= "urn:xmethods-currencyexchange" encodingstyle= "http://schemas.xmlsoap.org/soap/encoding/"/> </input> <output> <soap:body use ="encoded" namespace= "urn:xmethods-currencyexchange" encodingstyle= "http://schemas.xmlsoap.org/soap/encoding/"/> </output> </operation> </binding> Listato 7.7: Esempio di un collegamento

244 7.1 Le tecnologie alla base dei Web Services 243 <service name="currencyexchangeservice"> <documentation> Ritorna il tasso di scambio tra due valute </documentation> <port name="currencyexchangeport" binding="tns:currencyexchangebinding"> <soap:address location= "http://service.xmethods.net:80/soap"/> </port> </service> Listato 7.8: Definizione del servizio Definizione del servizio L ultimo elemento di un file WSDL è la definizione del servizio: questa sezione consente di raccogliere tutte le operazioni sotto un unico nome. Il servizio è identificato da un nome (l attributo name dell elemento service) e può avere una descrizione contenuta nel sottoelemento opzionale documentation. L elemento service è l elemento di livello più alto in WSDL. Esso dichiara un servizio web con un particolare nome come raccolta di porte. Al suo interno vengono elencate tutte le operazioni esposte dal servizio sotto forma di elementi port. Per ciascuno di questi viene indicato il collegamento utilizzato. Il contenuto dell elemento port cambia in funzione del tipo di collegamento utilizzato. Nel Listato 7.8 è presente una definizione di servizio, in particolare del servizio di cambio valute, dove il collegamento utilizzato è quello con SOAP. In questo caso nell elemento port è presente un elemento address appartenente al namespace soap (utilizzato in tutto il WSDL per riferirsi agli elementi strettamente relativi al collegamento di WSDL con SOAP). Questo elemento indica l URL fisico dell endpoint del servizio. L utilizzo di WSDL può diventare anche molto complesso nel momento in cui ci si addentra in collegamenti e protocolli diversi da SOAP e HTTP. Per ciascun protocollo e livello di trasporto è infatti necessario definire una estensione di WSDL specifica e costruire i documenti WSDL secondo questa grammatica. Il vantaggio di grande estendibilità di WSDL si paga quindi in termini di complessità.

245 7.1 Le tecnologie alla base dei Web Services UDDI: Universal Description Discovery and Integration L UDDI (acronimo di Universal Description Discovery and Integration) è un registry (ovvero una base dati ordinata ed indicizzata) basato su XML ed indipendente dalla piattaforma hardware, che permette alle aziende la pubblicazione dei propri dati e dei servizi offerti su internet. UDDI, un iniziativa open sviluppata tra il 1999 ed il 2000 e sponsorizzata dall Organization for the Advancement of Structured Information Standards (OASIS: consorzio internazionale per lo sviluppo e l adozione di standard nel campo dell e-business e dei Web Services), permette quindi la scoperta e l interrogazione dei servizi offerti sul web, delle aziende che li offrono e della maniera per usufruirne. Il registro UDDI è supportato da una rete mondiale di nodi collegati tra di loro in una sorta di federazione in modo similare alla tecnologia DNS. Quando un client sottopone una informazione al registro, questo la propaga agli altri nodi. In questo modo si attua la ridondanza dei dati fornendo una certa affidabilità. Il ruolo del singolo nodo rimane comunque fondamentale poichè nel momento in cui un client sottopone dei dati, questo ne diviene il proprietario, e sarà in futuro solo questo nodo a poter operare importanti operazioni sui dati quali la loro eliminazione. Le chiamate a UDDI sono implementate tramite comunicazioni SOAP di tipo request-response e permettono sostanzialmente due operazioni: quella di pubblicazione delle informazioni e quelle di ricerca delle stesse. Le informazioni gestite dal registro UDDI sono di tre tipi: - Pagine bianche. Contengono informazioni anagrafiche delle aziende, come l indirizzo e i numeri di telefono. Costituiscono un primo approccio alle aziende, di tipo umano prima che tecnico. - Pagine gialle. Definiscono la categorizzazione (tassonomia) dei servizi e delle aziende. Un azienda potrebbe essere infatti catalogata in base alla sua posizione geografica o al proprio settore industriale. Le tassonomie dovrebbero rispettare standard internazionali, quali quelli dettati dall ISO. - Pagine Verdi. Costituiscono le informazioni tecniche dei servizi, quelle utili a livello informatico. Queste riguardano gli URL dei servizi o gli eventuali documenti WSDL. Nei registri UDDI, la descrizione dei Web Service contiene quattro tipi di informazioni: business information, service information, binding information, e informazioni sulle specifiche del servizio, descritte da diverse entità.

246 7.1 Le tecnologie alla base dei Web Services 245 businessentity fornisce una descrizione delle organizzazioni che forniscono il Web Service. È una lista di nomi, indirizzi, telefoni e altri tipi di informazioni relative alla società fisica. businessservice descrive un gruppo di Web Service offerti dalla società descritta nel businessentity. Questo gruppo comprende servizi dello stesso tipo ma forniti in diversi indirizzi, diverse versioni o diverse tecnologie. Ad un businessentity possono corrispondere diversi businessservice, ma ad un businessservice è associato uno ed un solo businessentity. businesstemplate fornisce una descrizione tecnica necessaria per l uso di un particolare Web Service. Essenzialmente esso definisce l indirizzo dove reperire il servizio ed una serie di dettagli tecnici che descrivono l interfaccia del Web Service o altre proprietà del servizio. Ad un businessservice possono corrispondere diversi businesstemplate (uno per ogni interfaccia o indirizzo), ma ad un businesstemplate è associato uno ed un solo businessservice. tmodel acronimo di technical model, esso è il contenitore generico per ogni tipo di specifiche. Può rappresentare l interfaccia di un servizio WSDL, una classificazione, un protocollo di interazione o può descrivere la semantica di un operazione. Diversamente dalle entità precedenti, il tmodel non è soggetto a nessuna relazione fissa. Riassumendo, se vogliamo pubblicare uno o più servizi in un registro UDDI, prima dobbiamo definire un insieme di tmodel che descrivono le diverse caratteristiche del servizio (come l interfaccia WSDL o le operazioni svolte dal servizio). Successivamente bisogna pubblicare le informazioni sulla compagnia (businessentity), le informazioni generali sul servizio proposto (businessservice) e infine un set di informazioni tecniche per ogni diversa implementazione e punto di accesso (businesstemplate). JAXR L accesso ai registri di servizi Web dalla piattaforma Java avviene tramite le Java API for XML Registries (JAXR). In generale si parla di registri perché JAXR ha un architettura multiregistro, capace di accedere anche ad altre tipologie di registry, come ebxml R. Inoltre JAXR può propagare una singola ricerca di servizi a più registry contemporaneamente. L accesso ai registri avviene tramite una connessione ottenuta dalla classe ConnectionFactory che viene opportunamente configurata tramite una serie di proprietà che

247 7.1 Le tecnologie alla base dei Web Services 246 indicano, tra le altre cose, l URL del registro al quale si vuole accedere. Una volta in possesso della connessione, è possibile eseguire ricerche e realizzare la registrazione di aziende e servizi. Quest ultima operazione è però sottoposta ad autenticazione e per poterla portare a termine è necessario essere registrati presso il particolare registro a cui si vuole accedere. Un aspetto interessante di JAXR è il suo uso del pattern futures (anche detto lazy-loading): una ricerca su un registro mondiale può potenzialmente restituire una grande mole di informazioni che non è garantito venga poi analizzata tutta. Per ovviare a questo inconveniente, ad ogni ricerca gli oggetti creati da JAXR non contengono tutte le informazioni ma solo quelle indispensabili. Nel momento in cui si renda necessario ottenere quelle mancanti, il runtime di JAXR esegue l accesso ai dati necessari. Questa caratteristica ha due aspetti: per prima cosa, vengono recuperati solo i dati effettivamente necessari, con un guadagno in termini di performance; in secondo luogo, i client JAXR devono per forza essere sempre connessi alla rete in modo che i successivi caricamenti dati possano essere eseguiti correttamente. Le JAXR consentono la gestione delle informazioni presenti nel registro come la creazione, l aggiornamento e l eliminazione di elementi. Inoltre é supportata l interrogazione del registro per eseguire le ricerche di servizi ed aziende. Ciascun elemento del registro é individuato univocamente da una UUID conforme al DCE 128 bit. Questa chiave é solitamente creata in modo trasparente dal registro, anche se per alcuni registri (come ebxml) é possibile fornire dall esterno la chiave da utilizzare. Il ciclo di vita degli oggetti del registro inizia con l operazione di creazione (l interfaccia LifeCycleManager fornisce una serie di metodi di utilità per creare i differenti oggetti definiti nel modello informativo). Un oggetto creato non é ancora presente all interno del registro e non può dunque essere oggetto di aggiornamenti o cancellazioni. Per inserire l oggetto nel registro é necessario che questo passi attraverso un operazione di salvataggio (save). Una caratteristica interessante di JAXR é la possibilità di deprecare gli oggetti, con un concetto simile al di Javadoc. Gli oggetti deprecati non consentono nuove referenze (come associazioni o classificazioni), ma continuano a funzionare normalmente. Se da una parte l interfaccia LifeCycleManager consente di gestire tutti gli elementi ad alto e basso livello del registro, dall altra può essere necessario concentrarsi più su elementi di business. L interfaccia BusinessLifeCycleManager contiene alcune importanti chiamate ad alto livello definendo una API simile alle Publisher API di UDDI. Con questa interfaccia non vengono introdotte nuove funzionalità ma vengono aiutati gli sviluppatori UDDI, che dovrebbero trovarsi ad operare con

248 7.1 Le tecnologie alla base dei Web Services 247 API più familiari. Un limite di JAXR in questa versione é che le operazioni sul ciclo di vita degli oggetti non sono applicabili a connessioni federate. Non é ad esempio possibile creare la stessa entità direttamente in due registri differenti. A differenza delle operazioni di disposizione (come la creazione o la modifica di informazioni), le operazioni di ricerca avvengono in modo non privilegiato. Non é necessaria dunque l autenticazione dell utente. L interrogazione può avvenire in modo puntuale o tramite query. Nel primo caso viene utilizzata l interfaccia BusinessQueryManager che, in modo similare a BusinessLifeCycleManager, ha una impostazione più ad alto livello e permette l interrogazione delle interfacce più funzionali del modello informativo. Molti metodi dell interfaccia richiedono argomenti simili, alcuni tra i più importanti sono: - findqualifiers. Definiscono le regole di confronto di stringhe, ordinamento e operatori logici sui parametri di ricerca. - namepatterns. E una Collection di stringhe che contengono nomi anche parziali con eventuali wildcard come specificato nelle SQL-92 per la parola chiave LIKE. - classifications. E una Collection di Classification che identifica in quali classificazioni eseguire la ricerca. Nel secondo caso é possibile utilizzare una query dichiarativa, tramite l interfaccia DeclarativeQueryManager. Ad oggi l unico standard supportato é una derivazione di SQL-92, in particolare dell istruzione SELECT, estesa con le specifiche relative alle stored procedures. Le query dichiarative sono supportate anche su connessioni federate ma sono una caratteristica opzionale dei provider JAXR 1.0.

249 Capitolo 8 Applicazione completa sui Web Service Questa semplice applicazione invia e riceve messaggi. 8.1 Il Web Service Per la realizzazione di un Web Service con JBoss, inizialmente si creano le classi Java: un interfaccia che espone i metodi del web service (Listato 8.1) e la classe che implementa il Web Service (Listati 8.2 e 8.3). Successivamente, bisogna creare una serie di file XML che servono al Container per gestire il Web Service, per creare l interfaccia WSDL e il file di mapping JAXR. Il file config.xml (Listato 8.4) definisce l interfaccia del Web Service e serve per generare automaticamente il file WSDL e il file mapping.xml. package Archivio; import java.rmi.*; public interface Messaggio extends Remote void sendmex(string mex) throws RemoteException; String receivemex() throws RemoteException; Listato 8.1: Messaggio.java 248

250 8.1 Il Web Service 249 package Archivio; import java.rmi.*; import java.util.*; import java.rmi.server.*; import java.io.*; public class MessaggioImpl extends UnicastRemoteObject public MessaggioImpl() throws RemoteException System.out.println("MessaggioImpl()"); public void sendmex(string messaggio) throws RemoteException Vector coda; System.out.println("send()"); try coda = (Vector)new ObjectInputStream (new FileInputStream ("appoggio")).readobject(); catch(ioexception err) coda=new Vector(); catch(classnotfoundexception clfe) return; coda.add(messaggio); try new ObjectOutputStream (new FileOutputStream ("appoggio")). writeobject(coda); Listato 8.2: MessaggioImpl.java

251 8.1 Il Web Service 250 catch(ioexception err) err.printstacktrace(); public String receivemex() throws RemoteException Vector coda; System.out.println("send()"); try coda = (Vector) new ObjectInputStream (new FileInputStream ("appoggio")). readobject(); catch(ioexception err) return(null); catch(classnotfoundexception clfe) return(null); try String messaggio = (String) coda.get(0); coda.remove(0); new ObjectOutputStream (new FileOutputStream ("appoggio")). writeobject(coda); return(messaggio); catch(nosuchelementexception nsee) return(null); catch(ioexception err) err.printstacktrace(); return(null); Listato 8.3: MessaggioImpl.java

252 8.1 Il Web Service 251 <?xml version="1.0" encoding="utf-8"?> <configuration xmlns= "http://java.sun.com/xml/ns/jax-rpc/ri/config"> <service name="archivioservice" targetnamespace="http://archivio.ws.jboss.org/" typenamespace="http://archivio.ws.jboss.org/types" packagename="archivio"> <interface name ="Archivio.Messaggio"/> </service> </configuration> Listato 8.4: config.xml <?xml version="1.0" encoding="utf-8"?> <web-app> <servlet> <servlet-name>archiviows</servlet-name> <servlet-class>archivio.archivioimpl</servlet-class> </servlet> <servlet-mapping> <servlet-name>archiviows</servlet-name> <url-pattern>/archiviourl</url-pattern> </servlet-mapping> </web-app> Listato 8.5: web.xml La generazione di questi file avviene attraverso il tool wscompile che fa parte del Java Web Service Developer Pack (WSDP). Di seguito è mostrata la stringa di compilazione per questo Web Service: wscompile -classpath <classpath> -gen:server -f:rpcliteral -mapping config.xml Il classpath si riferisce alla directory dove trovare le classi java. A questo punto bisogna creare un package (nel nostro caso Archivio), all interno del quale si pone una sottocartella con lo stesso nome del package in cui sono presenti i file.java. Il passo successivo consiste nella creazione del file web.xml (Listato 8.5) che non ha al suo interno elementi di configurazione ma serve unicamente per comunicare al Container come installare il Web Service. L ultimo file xml da creare è webservices.xml (Listato 8.6). Quest ultimo deployment descriptor è necessario a JBoss per comunicare che stiamo realizzando un Web Service e non una normale Servlet. Questo file comunica al Container dove trovare il file wsdl tramite l elemento <wsdl-file>, mentre l elemento <jaxrpc-mapping-file> indica

253 8.1 Il Web Service 252 <webservices> <webservice-description> <webservice-description-name> ArchivioService </webservice-description-name> <wsdl-file>web-inf/wsdl/archivioservice.wsdl </wsdl-file> <jaxrpc-mapping-file> WEB-INF/mapping.xml </jaxrpc-mapping-file> <port-component> <port-component-name>messaggio</port-component-name> <wsdl-port>messaggioport</wsdl-port> <service-endpoint-interface> Archivio.Messaggio </service-endpoint-interface> <service-impl-bean> <servlet-link>archiviows</servlet-link> </service-impl-bean> </port-component> </webservice-description> </webservices> Listato 8.6: webservices.xml Figura 8.1: Schema WebService dove trovare il file mapping generato dal tool wscompile. Una volta creato anche quest ultimo file, il Web Service è pronto per essere installato all interno del container. Lo schema di come preparare i file è mostrato in Figura 8.1 Il deploy va eseguito come negli EJB, ponendo la cartella esempiows.war in deploy all interno di JBoss. Dopo pochi secondi nella finestra di avvio di

254 8.1 Il Web Service 253 JBoss si può verificare l avvenuta installazione.

255 8.2 Il Client 254 import Archivio.*; import javax.xml.rpc.service; import javax.xml.rpc.servicefactory; import javax.xml.namespace.qname; import java.net.url; public class send public static void main(string[] args) throws Exception String urlstr = "http://localhost:8080/esempiows/ ArchivioUrl?wsdl"; System.out.println ("Contacting webservice at " + urlstr); URL url = new URL(urlstr); QName qname = new QName ("http://archivio.ws.jboss.org/","archivioservice"); ServiceFactory factory = ServiceFactory.newInstance(); Service service = factory.createservice(url, qname); Messaggio arch = (Messaggio) service.getport(messaggio.class); arch.sendmex(args[0]); Listato 8.7: send.java 8.2 Il Client Di seguito viene illustrata la struttura del client, che compie due operazioni: invia e riceve messaggi. Sarà perciò composto da due classi di cui illustriamo il codice (Listati 8.7 e 8.8) e che servono a inviare un messaggio passato da linea di comando al Web service e a verificare l avvenuta ricezione. Quando viene eseguito, il client come prima cosa cerca di connettersi al WSDL del Web Service all indirizzo ArchivioUrl?wsdl. L indirizzo di questo esempio si riferisce ad un Web Service presente nello stesso computer del client (localhost), nel caso sia diverso è necessario cambiare localhost nel nome o nell indirizzo IP del server su cui il Web Service è dispiegato. La seconda parte dell indirizzo esempiows è il nome della cartella nella quale il Web Service è stato installato all interno di JBoss. In questo esempio era esempiows.war. L ultima parte ArchivioUrl è il nome del pattern che si trova all interno del file web.xml all interno dei tag <url-pattern>.

256 8.2 Il Client 255 import Archivio.*; import javax.xml.rpc.service; import javax.xml.rpc.servicefactory; import javax.xml.namespace.qname; import java.net.url; public class receive public static void main(string[] args) throws Exception String urlstr = "http://localhost:8080/esempiows/archiviourl?wsdl"; System.out.println ("Contacting webservice at " + urlstr); URL url = new URL(urlstr); QName qname = new QName ("http://archivio.ws.jboss.org/","archivioservice"); ServiceFactory factory = ServiceFactory.newInstance(); Service service = factory.createservice(url, qname); Messaggio arch = (Messaggio) service.getport(messaggio.class); String mex=arch.receivemex(); System.out.println(mex); Listato 8.8: receive.java

257 8.2 Il Client 256 Figura 8.2: deploy del web service su JBoss Quest indirizzo è visibile nella finestra di JBoss mostrata in Figura 8.2 dove vengono mostrate le quattro righe con cui JBoss comunica l avvenuta installazione. Il passo successivo che il client esegue è la richiesta dell interfaccia del web service, la classe Messaggio. Questo avviene creando un oggetto QNAME con i parametri del targetnamespace inserito nel file config.xml e il nome del servizio. Una volta ottenuta la classe di interfaccia del web service, si utilizzano i metodi esposti (sendmex() e receivemex()) come se fossero in locale.

258 Appendice Compilazione e Deploy 1 di componenti J2EE in JBOSS. A.1 Servlet e JSP Vediamo quali sono i passi preliminari da compiere per poter provare e far girare una servlet. Per prima cosa, va installato JBoss. Per maggiori dettagli sull installazione e il deploy si faccia riferimento [11] e [9]. Quando si vuol far girare una servlet con JBoss, bisogna predisporre con un certo criterio le classi java e gli altri file necessari (xml e jsp) che sono stati creati. Innanzi tutto, si crea una cartella nomecartella.war. All interno di questa directory va creata una sottodirectory, che deve essere nominata WEB-INF. Al suo interno, la directory WEB-INF conterrà una sottodirectory classes con i file.java e.class della servlet; essa conterrà inoltre il file web.xml. Quando si crea un Progetto con JCreator e si vuole compilare, bisogna prima aggiungere il package javax.servlet.jar, nel modo seguente: dal menu Project si sceglie Project Properties e poi Required Libraries (vedi Figura 8.3), dopo di che si clicca il bottone Add e si seleziona Add Archive; a questo punto, verrà visualizzata una nuova finestra dalla quale sarà possibile accedere al package richiesto, dal seguente percorso: Dir. installaz. di JBoss\server\default\lib\javax.servlet.jar (vedi Figura 8.4). Una volta selezionato e aggiunto il package, gli si dà un nome simbolico, come mostrato in Figura 8.5. Dopo aver premuto il tasto 1 Con il termine Deploy si intende la messa in esercizio di un componente distribuito all interno di un Application Server 257

259 Appendice 258 Figura 8.3: Finestra Set Library Figura 8.4: Finestra Apri OK, dalla finestra Set Library, sarà possibile selezionare il package rappresentato dal nome simbolico scelto (nel nostro caso Servlet), come mostrato in Figura 8.6. Infine, è possibile compilare la servlet, semplicemente attraverso il comando del menu Build\Compile Project. A.2 Uso di JMS con JBOSS I passi per la compilazione delle classi che fanno uso del package J2EE javax.jms sono analoghi a quelli per compilare le servlet. In questo caso, però, occorre importare l archivio JAR:

260 Appendice 259 Figura 8.5: Finestra Set Library Name Figura 8.6: Finestra Project Properties Finale

RMI. Introduzione DI GIOVANNI PULITI

RMI. Introduzione DI GIOVANNI PULITI 2001 proprietà di MokaByte s.r.l. tutti i diritti riservati è vietata la riproduzione non autorizzata anche parziale RMI DI GIOVANNI PULITI Introduzione La programmazione distribuita è tra gli argomenti

Dettagli

Introduzione a Java Remote Method Invocation (RMI)

Introduzione a Java Remote Method Invocation (RMI) Introduzione a Java Remote Method Invocation (RMI) SAPIENZA Università di Roma Corso di Architetture Software Orientate ai Servizi E risuona il mio barbarico yawp sopra i tetti del mondo ( I sound my barbaric

Dettagli

RMI. Java RMI RMI. G. Prencipe prencipe@di.unipi.it

RMI. Java RMI RMI. G. Prencipe prencipe@di.unipi.it Java Remote Method Invocation -- RMI G. Prencipe prencipe@di.unipi.it RMI RMI è una tecnologia JAVA che permette a una JVM di comunicare con un altra JVM per farle eseguire metodi È possibile che oggetti

Dettagli

Programmazione di sistemi distribuiti

Programmazione di sistemi distribuiti Programmazione di sistemi distribuiti I Sistemi Distribuiti, per loro natura, prevedono che computazioni differenti possano essere eseguite su VM differenti, possibilmente su host differenti, comunicanti

Dettagli

Remote Method Invocation (RMI)

Remote Method Invocation (RMI) (RMI) Remote Method Invocation (RMI) in Java. Walter Cazzola Dipartimento di Informatica e Comunicazione Università à degli Studi di Milano. e-mail: cazzola@disi disi.unige.it Walter Cazzola Java: Remote

Dettagli

Java Remote Method Invocation

Java Remote Method Invocation Java Remote Method Invocation Programmazione in Rete e Laboratorio Comunicazione distribuita Port1 Java VM1 Java VM2 Port 2 Matteo Baldoni Dipartimento di Informatica Universita` degli Studi di Torino

Dettagli

Organizzazione della lezione. 15. Java Remote Method Invocation (3) Lo schema del Factory Design Pattern - 1. Factory design pattern

Organizzazione della lezione. 15. Java Remote Method Invocation (3) Lo schema del Factory Design Pattern - 1. Factory design pattern Organizzazione della lezione 15. Java Remote Method Invocation (3) Vittorio Scarano Corso di Programmazione Distribuita Laurea di I livello in Informatica Università degli Studi di Salerno Il design pattern

Dettagli

Programmazione distribuita

Programmazione distribuita Programmazione distribuita 1 Architettura client-server È il modo classico di progettare applicazioni distribuite su rete Server offre un servizio "centralizzato" attende che altri (client) lo contattino

Dettagli

RMI Remote Method Invocation

RMI Remote Method Invocation RMI Remote Method Invocation [Pagina intenzionalmente vuota] (1 12 2004) slide 4:1/18 (p.106) Un applicazione RMI è un applicazione distribuita ad oggetti. Applicazione RMI tipica, strutturata in: server:

Dettagli

Progettazione: Tecnologie e ambienti di sviluppo

Progettazione: Tecnologie e ambienti di sviluppo Contratto per l acquisizione di servizi di Assistenza specialistica per la gestione e l evoluzione del patrimonio software della Regione Basilicata. Repertorio n. 11016 del 25/09/2009 Progettazione: Tecnologie

Dettagli

Sistemi Distribuiti Multiagente A.A.2010-11 Informatica Magistrale Università di Bari

Sistemi Distribuiti Multiagente A.A.2010-11 Informatica Magistrale Università di Bari Java RMI I lucidi che seguono sono stati prodotti sulla base dei seguenti riferimenti: - Sistemi Distribuiti Dip. Informatica (S.Pizzutilo) - Seminario Java RMI di G.Cozzolongo Java RMI: Remote Method

Dettagli

RMI: metodi equals e hashcode

RMI: metodi equals e hashcode RMI: metodi equals e hashcode Per verificare se due oggetti remoti contengono gli stessi dati, la chiamata indirizzata al metodo equals() avrebbe bisogno di contattare i server dove si trovano gli oggetti

Dettagli

UnicastRemoteObject. Massimo Merro Programmazione di Rete 103 / 124

UnicastRemoteObject. Massimo Merro Programmazione di Rete 103 / 124 UnicastRemoteObject Java RMI fornisce diverse classi base per definire server remoti: UnicastRemoteObject < RemoteServer < RemoteObject dove A < B significa che A è una sottoclasse di B. UnicastRemotObject

Dettagli

Gli EJB offrono vari vantaggi allo sviluppatore di una applicazione

Gli EJB offrono vari vantaggi allo sviluppatore di una applicazione Gli EJB offrono vari vantaggi allo sviluppatore di una applicazione Un ambiente di esecuzione che gestisce o naming di oggetti, sicurezza, concorrenza, transazioni, persistenza, distribuzione oggetti (location

Dettagli

Organizzazione della lezione. Lezione 18 Remote Method Invocation - 6. (con callback) L accesso al registry per il rebind()

Organizzazione della lezione. Lezione 18 Remote Method Invocation - 6. (con callback) L accesso al registry per il rebind() Organizzazione della lezione Lezione 18 Remote Method Invocation - 6 Vittorio Scarano Corso di Programmazione Distribuita (2003-2004) Laurea di I livello in Informatica Università degli Studi di Salerno

Dettagli

Framework. Impianti Informatici. Web application - tecnologie

Framework. Impianti Informatici. Web application - tecnologie Framework Web application - tecnologie Web Application: tecnologie 2 Java-based (J2EE) Sviluppata inizialmente da Sun Cross-platform e open source Gestire direttamente le funzionalità dell applicazione

Dettagli

Sistemi Operativi (modulo di Informatica II)

Sistemi Operativi (modulo di Informatica II) Sistemi Operativi (modulo di Informatica II) La comunicazione tra processi Patrizia Scandurra Università degli Studi di Bergamo a.a. 2008-09 Sommario Processi cooperanti La comunicazione tra processi Necessità

Dettagli

Activation In sintesi: è inutile avere attivi degli oggetti se non vengono utilizzati

Activation In sintesi: è inutile avere attivi degli oggetti se non vengono utilizzati Activation In generale i Sistemi ad oggetti distribuiti sono progettati per lavorare con oggetti persistenti. Dato che questi sistemi saranno composti da migliaia (forse milioni) di tali oggetti, sarebbe

Dettagli

Contesto e motivazioni Architettura e concetti di base Componenti di RMI RMIRegistry Interfacce, eccezioni e classi Lo sviluppo di una applicazione L

Contesto e motivazioni Architettura e concetti di base Componenti di RMI RMIRegistry Interfacce, eccezioni e classi Lo sviluppo di una applicazione L CEFRIEL Consorzio per la Formazione e la Ricerca in Ingegneria dell Informazione Politecnico di Milano Programmazione Object Oriented in Java Java Remote Method Invocation Docente: Diego Peroni CEFRIEL

Dettagli

Mobilità di Codice. Massimo Merro Programmazione di Rete 128 / 144

Mobilità di Codice. Massimo Merro Programmazione di Rete 128 / 144 Mobilità di Codice Abbiamo già visto come un dato host possa trasmettere un oggetto (serializzabile) ad un altro host. Quest ultimo potrà eseguire l oggetto pur non possedendo il bytecode della classe

Dettagli

7 Esercitazione (svolta): Callback. Polling. Java RMI: callback. Server. Server. Client. Client. due possibilità:

7 Esercitazione (svolta): Callback. Polling. Java RMI: callback. Server. Server. Client. Client. due possibilità: 7 Esercitazione (svolta): due possibilità: Java RMI: callback Molte applicazioni richiedono un meccanismo publish/subscribe I partecipanti (client) necessitano di notifiche da parte del coordinatore (server)

Dettagli

Java RMI (Remote Method Invocation)

Java RMI (Remote Method Invocation) Java RMI (Remote Method Invocation) Accesso ad oggetti remoti In Java non sono possibili riferimenti remoti RPC in JAVA Le RMI introducono la possibilità di richiedere esecuzione di metodi remoti in JAVA

Dettagli

Comunicazione fra oggetti distribuiti

Comunicazione fra oggetti distribuiti Comunicazione fra oggetti distribuiti RMI RPC invocazione di metodo remoto - gli oggetti remoti ricevono le RMI interfaccia remota meccanismo per la comunicazione cliente servente come primitiva di un

Dettagli

Socket & RMI Ingegneria del Software - San Pietro

Socket & RMI Ingegneria del Software - San Pietro Socket & RMI Ingegneria del Software - San Pietro Socket È possibile trattare la comunicazione di rete allo stesso modo con cui è possibile trattare la lettura da file. La classe Socket rappresenta la

Dettagli

Servers Activatable. Massimo Merro Programmazione di Rete 166 / 193

Servers Activatable. Massimo Merro Programmazione di Rete 166 / 193 Servers Activatable Nelle lezioni precedenti abbiamo detto che una referenza remota ad un server di tipo UnicastRemoteObject rimane valida finchè il server è in esecuzione. Quando il server termina, o

Dettagli

Registri RMI. Massimo Merro Univ. Verona Programmazione di Rete 90 / 247

Registri RMI. Massimo Merro Univ. Verona Programmazione di Rete 90 / 247 Registri RMI Per poter interagire con un server remoto, un client deve essere in possesso di una sua referenza remota (ovvero un oggetto stub). Un servizio di Naming è una risorsa centralizzata che può

Dettagli

RMI. Prova pratica di Sistemi Distribuiti:

RMI. Prova pratica di Sistemi Distribuiti: Prova pratica di Sistemi Distribuiti: RMI Di Nicola Milella Al fine di toccare con mano queste tecnologie e capirne i rispettivi pro e contro si è deciso di sviluppare un applicazione distribuita sfruttando

Dettagli

Esercitazione di Sistemi Distribuiti: Java RMI

Esercitazione di Sistemi Distribuiti: Java RMI Esercitazione di Sistemi Distribuiti: Java RMI Anno Accademico 2007-08 Marco Comerio comerio@disco.unimib.it Richiami Teorici Oggetti distribuiti 2-16 Usuale organizzazione di un oggetto remoto con un

Dettagli

Web Services con Axis Delia Di Giorgio Anna Celada 1 marzo 2005

Web Services con Axis Delia Di Giorgio Anna Celada 1 marzo 2005 Sommario Web Services con Axis Delia Di Giorgio Anna Celada 1 marzo 2005 Introduzione.................................................................................. 1 SOAP........................................................................................

Dettagli

Candidato: Luca Russo Docente: Prof. Raffaele Montella. 27 Marzo 2013

Candidato: Luca Russo Docente: Prof. Raffaele Montella. 27 Marzo 2013 e di e di Candidato: Luca Russo Docente: Corso di laurea in Informatica Applicata Facoltá di Scienze e Tecnologie Programmazione su Reti 27 Marzo 2013 Traccia d esame Sviluppare multitier con disaccoppiamento

Dettagli

20 - Input/Output su File

20 - Input/Output su File 20 - Input/Output su File Programmazione e analisi di dati Modulo A: Programmazione in Java Paolo Milazzo Dipartimento di Informatica, Università di Pisa http://www.di.unipi.it/ milazzo milazzo di.unipi.it

Dettagli

Linguaggio Java. Robusto. Orientato agli oggetti. Protegge e gestisce dagli errori. Non permette costrutti pericolosi

Linguaggio Java. Robusto. Orientato agli oggetti. Protegge e gestisce dagli errori. Non permette costrutti pericolosi Linguaggio Java Robusto Non permette costrutti pericolosi Eredità Multipla Gestione della Memoria Orientato agli oggetti Ogni cosa ha un tipo Ogni tipo è un oggetto (quasi) Protegge e gestisce dagli errori

Dettagli

Quando si sa chiaramente come si deve comportare l applicazione si può analizzare una possibile soluzione applicativa.

Quando si sa chiaramente come si deve comportare l applicazione si può analizzare una possibile soluzione applicativa. Introduzione alla tecnologia JMX 1 Viene analizzata l architettura sottostante le Java Managment Extensions (JMX) mostrandone un utilizzo applicativo e analizzando altri possibili scenari d uso di Ivan

Dettagli

Corso Online. We Train Italy info@wetrainitaly.it

Corso Online. We Train Italy info@wetrainitaly.it Corso Online Programmatore Java New Edition We Train Italy info@wetrainitaly.it Programma Generale del Corso Programmatore Java New Edition 1. Introduzione al corso Java da 0 al web Presentazione del corso

Dettagli

ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO

ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO Standard tecnici Gli standard tecnici di riferimento adottati sono conformi alle specifiche e alle raccomandazioni emanate dai principali

Dettagli

Corso Android New Edition Corso Online Programmatore Android New Edition

Corso Android New Edition Corso Online Programmatore Android New Edition Corso Android New Edition Corso Online Programmatore Android New Edition Accademia Domani Via Pietro Blaserna, 101-00146 ROMA (RM) info@accademiadomani.it Programma Generale del Corso di Programmatore

Dettagli

Concetti base. Impianti Informatici. Web application

Concetti base. Impianti Informatici. Web application Concetti base Web application La diffusione del World Wide Web 2 Supporto ai ricercatori Organizzazione documentazione Condivisione informazioni Scambio di informazioni di qualsiasi natura Chat Forum Intranet

Dettagli

INDICE. Indice. Introduzione

INDICE. Indice. Introduzione V Indice Introduzione XIII Capitolo 1 La programmazione multithread 1 1.1 Cosa sono i thread 2 Utilizzare i thread per dare una possibilità ad altri task 9 Avvio ed esecuzione dei thread 10 Esecuzione

Dettagli

Il linguaggio Java. Oggetto remoto. Remote Method Invocation (RMI) Oggetto remoto: oggetto i cui metodi possono essere invocati attraverso la rete

Il linguaggio Java. Oggetto remoto. Remote Method Invocation (RMI) Oggetto remoto: oggetto i cui metodi possono essere invocati attraverso la rete Il linguaggio Java Remote Method Invocation (RMI) Oggetto remoto Oggetto remoto: oggetto i cui metodi possono essere invocati attraverso la rete Client Server 2 Schema di principio oggetto client oggetto

Dettagli

RMI e Firewall. Una soluzione è offerta dal transport layer di RMI stesso

RMI e Firewall. Una soluzione è offerta dal transport layer di RMI stesso Firewall Ogni applicazione di rete, che opera fuori da quelli che sono i confini di una rete locale, incontra inevitabilmente i cosiddetti firewall Tipicamente i firewall bloccano tutto il traffico di

Dettagli

La Roadmap dello sviluppo per System i5: dalle Applicazioni Legacy alla SOA

La Roadmap dello sviluppo per System i5: dalle Applicazioni Legacy alla SOA IBM System i5 La Roadmap dello sviluppo per System i5: dalle Applicazioni Legacy alla SOA Massimo Marasco System i Technical Sales Support massimo_marasco@it.ibm.com Oriented Architecture (SOA) Servizio

Dettagli

Programmazione di rete in Java

Programmazione di rete in Java Programmazione di rete in Java Reti di calcolatori Una rete di calcolatori è un sistema che permette la condivisione di dati informativi e risorse (sia hardware sia software) tra diversi calcolatori. Lo

Dettagli

Sistemi Distribuiti. Anno Accademico 2005-06 Prof. Flavio De Paoli. Il modello ad oggetti

Sistemi Distribuiti. Anno Accademico 2005-06 Prof. Flavio De Paoli. Il modello ad oggetti Sistemi Distribuiti Anno Accademico 2005-06 Prof. Flavio De Paoli 1 Il modello ad oggetti 2 Distributed Objects 2-16 Common organization of a remote object with client-side proxy. 3 Caratteristiche Oggetti

Dettagli

Framework di Middleware. per Architetture Enterprise

Framework di Middleware. per Architetture Enterprise Framework di Middleware per Architetture Enterprise Corso di Ingegneria del Software A.A.2011-2012 Un po di storia 1998: Sun Microsystem comprende l importanza del World Wide Web come possibile interfaccia

Dettagli

SWIM v2 Design Document

SWIM v2 Design Document PROGETTO DI INGEGNERIA DEL SOFTWARE 2 SWIM v2 DD Design Document Matteo Danelli Daniel Cantoni 22 Dicembre 2012 1 Indice Progettazione concettuale Modello ER Entità e relazioni nel dettaglio User Feedback

Dettagli

Java e Serializzazione dalla A all'xml di Leonardo Puleggi

Java e Serializzazione dalla A all'xml di Leonardo Puleggi dalla A all'xml di Leonardo Puleggi Indice generale Introduzione2 Grafo di Riferimenti 4 Attributi Transient.. 6 Metodi writeobject e readobject... 7 Ereditarietà e Serializzazione...10 Serializzazione

Dettagli

PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY

PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY Giampiero Allamprese 0000260193 PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY Reti di Calcolatori LS prof. Antonio Corradi A.A. 2007/2008 ABSTRACT L obiettivo di questo progetto è la realizzazione

Dettagli

Sommario. G. Piscitelli

Sommario. G. Piscitelli Sommario Interprocess Communication Processi (e thread) cooperanti Il paradigma produttore-consumatore Shared Memory e Inter Process Communication (IPC) facility Proprietà caratteristiche della comunicazione

Dettagli

UNIVERSITÀ DEGLI STUDI DI FIRENZE FACOLTA DI INGEGNERIA DIPARTIMENTO DI SISTEMI E INFORMATICA. Elaborato di Tecnologie del Software per Internet

UNIVERSITÀ DEGLI STUDI DI FIRENZE FACOLTA DI INGEGNERIA DIPARTIMENTO DI SISTEMI E INFORMATICA. Elaborato di Tecnologie del Software per Internet UNIVERSITÀ DEGLI STUDI DI FIRENZE FACOLTA DI INGEGNERIA DIPARTIMENTO DI SISTEMI E INFORMATICA Elaborato di Tecnologie del Software per Internet JMSWEB 2 SISTEMA PER LO SCAMBIO DI MESSAGGI TRA APPLICAZIONI

Dettagli

PROGRAMMA CORSO Analista Programmatore JAVA - ORACLE

PROGRAMMA CORSO Analista Programmatore JAVA - ORACLE PROGRAMMA CORSO Analista Programmatore JAVA - ORACLE 1. JAVA 1.1 Introduzione a Java Introduzione Cosa è Java 1.2 Sintassi e programmazione strutturata variabili e metodi tipi di dati, array operatori

Dettagli

CORSO DI PROGRAMMAZIONE JAVA

CORSO DI PROGRAMMAZIONE JAVA CORSO DI PROGRAMMAZIONE JAVA Corso di Programmazione Java Standard Edition ( MODULO A) OBIETTIVI ll corso ha come obiettivo quello di introdurre la programmazione a oggetti (OOP) e di fornire solide basi

Dettagli

QUEUE : considerazioni. QUEUE : considerazioni. QUEUE : esempio. QUEUE : esempio

QUEUE : considerazioni. QUEUE : considerazioni. QUEUE : esempio. QUEUE : esempio QUEUE : considerazioni QUEUE : considerazioni Si è realizzata una struttura dati complessa utilizzandone una primitiva, l array. Il pregio di tale implementazione è il basso costo computazionale, mentre

Dettagli

Il Pattern PROXY. Ex presentazione realizzata dallo studente Paolo Melchiori (matricola 65734) nell a.a. 2007-2008

Il Pattern PROXY. Ex presentazione realizzata dallo studente Paolo Melchiori (matricola 65734) nell a.a. 2007-2008 UNIVERSITÀ DEGLI STUDI DI BRESCIA FACOLTÀ DI INGEGNERIA CORSO DI LAUREA SPECIALISTICA IN INGEGNERIA INFORMATICA DIPARTIMENTO DI ELETTRONICA PER L'AUTOMAZIONE Il Pattern PROXY Ex presentazione realizzata

Dettagli

Le basi della grafica in Java. Prof. Francesco Accarino IIS Altiero Spinelli via Leopardi 132 Sesto san Giovanni

Le basi della grafica in Java. Prof. Francesco Accarino IIS Altiero Spinelli via Leopardi 132 Sesto san Giovanni Le basi della grafica in Java Prof. Francesco Accarino IIS Altiero Spinelli via Leopardi 132 Sesto san Giovanni Elaborazione classica o imperativa L elaborazione è concentrata nel momento centrale, durante

Dettagli

Progetto di Applicazioni Software

Progetto di Applicazioni Software Progetto di Applicazioni Software Antonella Poggi Dipartimento di Informatica e Sistemistica Antonio Ruberti SAPIENZA Università di Roma Anno Accademico 2008/2009 Questi lucidi sono stati prodotti sulla

Dettagli

Architettura Tecnica i. Architettura Tecnica

Architettura Tecnica i. Architettura Tecnica i Architettura Tecnica ii Copyright 2005-2011 Link.it s.r.l. iii Indice 1 Scopo del documento 1 1.1 Abbreviazioni..................................................... 1 2 Overview 1 2.1 La PdD........................................................

Dettagli

Gestione delle eccezioni in Java

Gestione delle eccezioni in Java Gestione delle eccezioni in Java - Introduzione al concetto di eccezioni E possibile definire un eccezione come un situazione imprevista che il flusso di un applicazione può incontrare. È possibile gestire

Dettagli

Outline. Remote Method Invocation in Java. Remote Procedure Call (RPC) Introduzione Storica. Remote Procedure Call (RPC) Remote Procedure Call (RPC)

Outline. Remote Method Invocation in Java. Remote Procedure Call (RPC) Introduzione Storica. Remote Procedure Call (RPC) Remote Procedure Call (RPC) Outline Remote Method Invocation in Java Walter Cazzola Dipartimento di Informatica e Comunicazione Università degli Studi di Milano 1 2 3 Walter Cazzola Remote Method Invocation in Java Slide 1 of 33

Dettagli

Oggetto: MASTER DI ALTA FORMAZIONE PROFESSIONALE IN PROGRAMMATORE JAVA PARTECIPAZIONE GRATUITA

Oggetto: MASTER DI ALTA FORMAZIONE PROFESSIONALE IN PROGRAMMATORE JAVA PARTECIPAZIONE GRATUITA Oggetto: MASTER DI ALTA FORMAZIONE PROFESSIONALE IN PROGRAMMATORE JAVA PARTECIPAZIONE GRATUITA Salerno Formazione, società operante nel settore della didattica, della formazione professionale e certificata

Dettagli

Architettura SW Definizione e Notazioni

Architettura SW Definizione e Notazioni Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Stili Architetturali E. TINELLI Architettura SW Definizione e Notazioni Definizione ANSI/IEEE Std Std1471-2000

Dettagli

Architetture di sistema

Architetture di sistema Università di Bergamo Facoltà di Ingegneria Applicazioni Internet B Paolo Salvaneschi B1_1 V1.6 Architetture di sistema Il contenuto del documento è liberamente utilizzabile dagli studenti, per studio

Dettagli

Appendice D. D. Web Services

Appendice D. D. Web Services D. D.1 : cosa sono I cosiddetti sono diventati uno degli argomenti più attuali nel panorama dello sviluppo in ambiente Internet. Posti al centro delle più recenti strategie di aziende del calibro di IBM,

Dettagli

Corso di Reti di Calcolatori LS

Corso di Reti di Calcolatori LS Università degli Studi di Bologna Facoltà di Ingegneria Corso di Reti di Calcolatori LS CORBA - Implementazione Naming Service e Interface Repository Luca Foschini Anno accademico 2008/2009 Agenda CORBA

Dettagli

Java Enterprise Edi.on. Gabriele Tolomei DAIS Università Ca Foscari Venezia

Java Enterprise Edi.on. Gabriele Tolomei DAIS Università Ca Foscari Venezia Java Enterprise Edi.on Gabriele Tolomei DAIS Università Ca Foscari Venezia Java Web Services Web Services: SOAP vs. RESTful 2 diversi.pi di Web Services I Web Services SOAP sono quelli classici Si basano

Dettagli

Java RMI: Esempio Completo di un Applicazione Distribuita

Java RMI: Esempio Completo di un Applicazione Distribuita Java RMI: Esempio Completo di un Applicazione Distribuita Il Problema Produttore/Consumatore in Ambiente Distribuito* *a cura del Prof. L. Nigro, Università della Calabria Java RMI (Remote Method Invocation)

Dettagli

Architetture per le applicazioni web-based. Mario Cannataro

Architetture per le applicazioni web-based. Mario Cannataro Architetture per le applicazioni web-based Mario Cannataro 1 Sommario Internet e le applicazioni web-based Caratteristiche delle applicazioni web-based Soluzioni per l architettura three-tier Livello utente

Dettagli

InterProcess Communication (IPC)

InterProcess Communication (IPC) CdL MAGISTRALE in INFORMATICA A.A. 2013-2014 corso di Sistemi Distribuiti 5. IPC (Inter Process Communication) (parte 2): da RPC a RMI Prof. S.Pizzutilo InterProcess Communication (IPC) Modelli e tecnologie

Dettagli

Corso di Informatica Modulo T3 B2 - Database in rete

Corso di Informatica Modulo T3 B2 - Database in rete Corso di Informatica Modulo T3 B2 - Database in rete 1 Prerequisiti Programmazione web Applicazione web Modello OSI Architettura client/server Conoscenze generali sui database Tecnologia ADO in Visual

Dettagli

Seminario di Sistemi Distribuiti: RPC su SOAP

Seminario di Sistemi Distribuiti: RPC su SOAP Corso di Sistemi Distribuiti Prof. S. Balsamo Seminario di Sistemi Distribuiti: RPC su SOAP [ 777775] 1 INTRODUZIONE 3 2 RPC 3 3 SOAP (SIMPLE OBJECT ACCESS PROTOCOL) 3 4 UTILIZZO DI SOAP COME PROTOCOLLO

Dettagli

Analisi, progettazione e implementazione di un repository di componenti distribuite in Java basato su JNDI.

Analisi, progettazione e implementazione di un repository di componenti distribuite in Java basato su JNDI. UNIVERSITÀ DEGLI STUDI DI ROMA LA SAPIENZA TESI DI LAUREA IN SCIENZE DELL INFORMAZIONE Analisi, progettazione e implementazione di un repository di componenti distribuite in Java basato su JNDI. Relatore:

Dettagli

Sviluppo Applicazioni Mobile Lezione 11. Dr. Paolo Casoto, Ph.D - 2012

Sviluppo Applicazioni Mobile Lezione 11. Dr. Paolo Casoto, Ph.D - 2012 + Sviluppo Applicazioni Mobile Lezione 11 + Credits I lucidi di questa lezione sono stati preparati da: Professor Stefano Mizzaro Professor Paolo Coppola e sono stati modificati e completati dal Dr. Paolo

Dettagli

JDBC di base. Le classi/interfacce principali di JDBC

JDBC di base. Le classi/interfacce principali di JDBC JDBC di base Java Database Connectivity è il package Java per l accesso a database relazionali il package contiene interfacce e classi astratte completa indipendenza del codice dal tipo di database o di

Dettagli

CORBA ( Common Object Request Broker Architecture ) Le specifiche più conosciute sono UML e CORBA

CORBA ( Common Object Request Broker Architecture ) Le specifiche più conosciute sono UML e CORBA CORBA ( Common Object Request Broker Architecture ) consiste in un insieme di specifiche promosse e curate da OMG (Object Management Group). L OMG è un consorzio internazionale no-profit di industrie nel

Dettagli

UNIVERSITA DI FIRENZE Facoltà di Ingegneria. Persistenza Applicazioni Enterprise Uso dei modelli

UNIVERSITA DI FIRENZE Facoltà di Ingegneria. Persistenza Applicazioni Enterprise Uso dei modelli UNIVERSITA DI FIRENZE Facoltà di Ingegneria Persistenza Applicazioni Enterprise Uso dei modelli 1 IL problema della persistenza APPLICAZIONE (programmi) (oggetti) DATI PERSISTENTI (file, record) (basi

Dettagli

Progetto di Applicazioni Software

Progetto di Applicazioni Software Progetto di Applicazioni Software Antonella Poggi Dipartimento di Informatica e Sistemistica Antonio Ruberti SAPIENZA Università di Roma Anno Accademico 2010/2011 Questi lucidi sono stati prodotti sulla

Dettagli

Compute engine generici in RMI

Compute engine generici in RMI Compute engine generici in RMI Esempio: Calcolo del prodotto scalare Un unico server offre il servizio di calcolo del prodotto scalare tra vettori di interi Un client richiede al server il calcolo del

Dettagli

UNIVERSITA DI FIRENZE Facoltà di Ingegneria. Persistenza Applicazioni Enterprise Uso dei modelli

UNIVERSITA DI FIRENZE Facoltà di Ingegneria. Persistenza Applicazioni Enterprise Uso dei modelli UNIVERSITA DI FIRENZE Facoltà di Ingegneria Persistenza Applicazioni Enterprise Uso dei modelli 1 IL problema della persistenza APPLICAZIONE (programmi) (oggetti) DATI PERSISTENTI (file, record) (basi

Dettagli

JDBC: Introduzione. Java Database Connectivity (JDBC): parte 1. Schema dei legami tra le classi principali. Principali classi/interfacce di JDBC

JDBC: Introduzione. Java Database Connectivity (JDBC): parte 1. Schema dei legami tra le classi principali. Principali classi/interfacce di JDBC JDBC: Introduzione Java Database Connectivity (JDBC): parte 1 Gianluca Moro DEIS - Università di Bologna gmoro@deis.unibo.it Java Database Connectivity è il package Java per l accesso a database relazionali

Dettagli

Componenti di una applicazione. Un programma applicativo è strutturato come un insieme organizzato di tre componenti funzionali:

Componenti di una applicazione. Un programma applicativo è strutturato come un insieme organizzato di tre componenti funzionali: Componenti di una applicazione Un programma applicativo è strutturato come un insieme organizzato di tre componenti funzionali: Un sottosistema di interfaccia con l utente (IU, user interface o anche presentation

Dettagli

Programmazione server-side: Java Servlet

Programmazione server-side: Java Servlet Programmazione server-side: Java Servlet Corso di Applicazioni Telematiche A.A. 2006-07 Lezione n.11 parte II Prof. Roberto Canonico Università degli Studi di Napoli Federico II Facoltà di Ingegneria Cos

Dettagli

Introduzione al linguaggio Java: Servlet e JSP

Introduzione al linguaggio Java: Servlet e JSP Introduzione al linguaggio Java: Servlet e JSP Corso di Gestione della Conoscenza d Impresa A. A. 2006/2007 Dipartimento di Informatica Università degli Studi di Bari 1 Servlet e JSP: il contesto Un applicazione

Dettagli

Appunti dei corsi di Programmazione di Rete Sistemi di elaborazione: Reti II

Appunti dei corsi di Programmazione di Rete Sistemi di elaborazione: Reti II Appunti dei corsi di Programmazione di Rete Sistemi di elaborazione: Reti II PROF. G. BONGIOVANNI 0) INTRODUZIONE AL LINGUAGGIO JAVA PER PROGRAMMATORI C++...2 0.1) Caratteristiche principali... 2 0.1.1)

Dettagli

Applicazione: OIL Online Interactive helpdesk

Applicazione: OIL Online Interactive helpdesk Riusabilità del software - Catalogo delle applicazioni: Gestione ICT Applicazione: OIL Online Interactive helpdesk Amministrazione: Consiglio Nazionale delle Ricerche (CNR) Responsabile dei sistemi informativi

Dettagli

27/03/2013. Contenuti

27/03/2013. Contenuti Corso Sistemi Distribuiti 6 cfu Docente: Prof. Marcello Castellano Contenuti Virtualizzazione - 3 Macchina virtuale - 4 Architetture delle macchine virtuali - 6 Tipi di virtualizzazione - 7 Monitor della

Dettagli

8. Sistemi Distribuiti e Middleware

8. Sistemi Distribuiti e Middleware 8. Sistemi Distribuiti e Middleware Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 8. Sistemi distribuiti e Middleware 1 / 32 Sommario 1 Sistemi distribuiti

Dettagli

Eredità in C++ Corso di Linguaggi di Programmazione ad Oggetti 1. a cura di Giancarlo Cherchi

Eredità in C++ Corso di Linguaggi di Programmazione ad Oggetti 1. a cura di Giancarlo Cherchi Eredità in C++ Corso di Linguaggi di Programmazione ad Oggetti 1 a cura di Giancarlo Cherchi 1 Introduzione Il meccanismo dell eredità consente di sfruttare delle relazioni tipo/sottotipo, ereditando attributi

Dettagli

Introduzione al mondo della persistenza. Dott. Doria Mauro doriamauro@gmail.com

Introduzione al mondo della persistenza. Dott. Doria Mauro doriamauro@gmail.com Hibernate Introduzione al mondo della persistenza Dott. Doria Mauro doriamauro@gmail.com La questione della persistenza Il modo dei database è complesso e le tecniche e le tecnologie sono molte. Per anni

Dettagli

Università degli Studi di Modena e Reggio Emilia. Facoltà di Ingegneria Reggio Emilia CORSO DI TECNOLOGIE E APPLICAZIONI WEB. Http con java, URL

Università degli Studi di Modena e Reggio Emilia. Facoltà di Ingegneria Reggio Emilia CORSO DI TECNOLOGIE E APPLICAZIONI WEB. Http con java, URL Università degli Studi di Modena e Reggio Emilia Facoltà di Ingegneria Reggio Emilia CORSO DI TECNOLOGIE E APPLICAZIONI WEB Http con java, URL Ing. Marco Mamei Anno Accademico 2004-2005 M. Mamei - Tecnologie

Dettagli

JDBC versione base. Le classi/interfacce principali di JDBC

JDBC versione base. Le classi/interfacce principali di JDBC JDBC versione base Java Database Connectivity è il package Java per l accesso a database relazionali il package contiene interfacce e classi astratte uno dei pregi è la completa indipendenza del codice

Dettagli

10.7 La classe BitSet... 555 Esercizi di autovalutazione... 558 Risposte agli esercizi di autovalutazione... 559 Esercizi 559

10.7 La classe BitSet... 555 Esercizi di autovalutazione... 558 Risposte agli esercizi di autovalutazione... 559 Esercizi 559 Sommario PREFAZIONE... XI Il nostro approccio didattico... xi Una panoramica del libro... xiv Ringraziamenti... xvii Gli autori... xix Deitel & Associates, Inc.... xx CAPITOLO 1 LA GRAFICA E JAVA2D...

Dettagli

Introduzione ai Web Services Alberto Polzonetti

Introduzione ai Web Services Alberto Polzonetti PROGRAMMAZIONE di RETE A.A. 2003-2004 Corso di laurea in INFORMATICA Introduzione ai Web Services alberto.polzonetti@unicam.it Introduzione al problema della comunicazione fra applicazioni 2 1 Il Problema

Dettagli

Programmazione Java Avanzata Concetti su Java

Programmazione Java Avanzata Concetti su Java Programmazione Java Avanzata Concetti su Java Ing. Giuseppe D'Aquì Testi di Riferimento Java ( R. Liguori, P. Liguori), O'Reilly Hops Tecniche Nuove (2008) Java Virtual Machine Il codice scritto in Java

Dettagli

Contenuti. Applicazioni di rete e protocolli applicativi

Contenuti. Applicazioni di rete e protocolli applicativi Contenuti Architettura di Internet Principi di interconnessione e trasmissione World Wide Web Posta elettronica Motori di ricerca Tecnologie delle reti di calcolatori Servizi Internet (come funzionano

Dettagli

Esercitazione sui Design Pattern

Esercitazione sui Design Pattern Esercitazione sui Design Pattern Pattern Creazionali Singleton Permette la creazione di una sola istanza della classe all interno dell applicazione Fornisce un metodo con cui ottenere l istanza Il costruttore

Dettagli

POLITECNICO DI TORINO III Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica TESI DI LAUREA

POLITECNICO DI TORINO III Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica TESI DI LAUREA POLITECNICO DI TORINO III Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica TESI DI LAUREA Architetture Web basate su Enterprise JavaBeans in ambiente Open Source Relatori Ing. Fulvio Corno

Dettagli

Architetture di sistema

Architetture di sistema Università di Bergamo Facoltà di Ingegneria Applicazioni Internet B Paolo Salvaneschi B1_1 V1.7 Architetture di sistema Il contenuto del documento è liberamente utilizzabile dagli studenti, per studio

Dettagli