ALMA MATER STUDIORUM - UNIVERSITA' DI BOLOGNA PROGETTO DI STRUMENTI PER LA CONFIGURAZIONE DI APPLICAZIONI JAVA ENTERPRISE

Transcript

1 ALMA MATER STUDIORUM - UNIVERSITA' DI BOLOGNA FACOLTA DI INGEGNERIA CORSO DI LAUREA IN INGEGNERIA INFORMATICA DIPARTIMENTO DI ELETTRONICA, INFORMATICA E SISTEMISTICA TESI DI LAUREA in Reti di Calcolatori L-A PROGETTO DI STRUMENTI PER LA CONFIGURAZIONE DI APPLICAZIONI JAVA ENTERPRISE CANDIDATO Andrea Bondi RELATORE: Chiar.mo Prof. Antonio Corradi CORRELATORI Ing. Stefano Monti Ing. Samuele Pasini Anno Accademico 2006/2007 Sessione III

2 SOMMARIO 1. Introduzione Scelte Tecnologiche Le Applicazioni Multi Tier La Tecnologia Java EE Le Java Annotations La Tecnologia Java Management Extension (JMX) L Application Server JBoss Il Linguaggio XML Conclusioni I Requisiti dell Applicazione Il Quadro Generale Gestire l Ordine di Deploy Eseguire l Upload di Componenti Chiamare Servizi MBean Invocare Metodi Custom Gestire l Undeploy dei Componenti Conclusioni La Progettazione La Struttura dell Enterprise Java Deployer L Architettura Client Server dell EJD Il File XML di Configurazione Use Case: Upload, Deploy e Configurazione di un Applicazione Use Case: Undeploy di un Applicazione Conclusioni Implementazione Il Parser XML

3 5.2 Il Sistema di Upload dei File Risalire alle Informazioni di Deploy di un pacchetto Risalire all Indirizzo di Deploy di un Pacchetto Il Deploy tramite MBean L Undeploy tramite MBean L MBean Principale EjdMainMBean Conclusioni Un Esempio Concreto L MBean di Test L Applicazione Web di Test La Configurazione Custom di Test Il File ejd-app.xml ScreenShots del Funzionamento Conclusioni Conclusioni Appendice A: Ordinamento di Oggetti Appendice B: Trasformare un File in un Array di Byte Bibliografia

4 1. INTRODUZIONE L architettura delle applicazioni è una parte degli studi di ingegneria del software in continuo mutamento. Un tempo erano pochi i programmi per computer che facevano affidamento sul collegamento ad altre macchine. Per lo più si trattava di applicazioni eseguite in maniera stand alone, ovvero completamente autonome, che per lo scambio di informazioni si appoggiavano su supporti esterni. Oppure, all estremo opposto, si avevano i cosiddetti thin client, macchine spesso prive di disco fisso che per il loro funzionamento erano vincolate ad un server centrale, il quale non lasciava loro alcuna possibilità di elaborazione autonoma. Con la grande diffusione di Internet si è trovata una via di mezzo a questi due estremi, grazie alla nascita del mercato del middleware. Applicazioni che si occupano dell elaborazione delle richieste, lasciando comunque un autonomia al client ed affidandosi per la gestione dei dati ad un altra macchina, il database server. Il middleware rappresenta la risposta alla necessità di delegare responsabilità e funzionalità, la cosiddetta business logic, a sistemi esterni. Solitamente le applicazioni middleware sono costituite da più componenti, tutti strettamente collegati ed il più delle volte dipendenti l uno con l altro. Questo frazionamento del programma apre un problema per quanto riguarda le unità che devono eseguire le varie operazioni: ogni qualvolta è necessario installare o configurare l applicativo, ciascuna parte del sistema deve essere caricata e configurata nella maniera e nell ordine corretto. E stata quindi valutata l opportunità di progettare un sistema di deploy e configurazione delle varie componenti che costituiscono l applicazione. Una sorta di procedura di installer capace di gestire anche da remoto e tramite istruzioni facilmente personalizzabili tutte le azioni necessarie per mettere in funzionamento il programma. L Enterprise Java Deployer EJD qui progettato facilita le operazioni di upload, installazione e configurazione di un programma middleware, effettuate seguendo le istruzioni fornite in un semplice file di configurazione. Nel cap. 2 vengono illustrate le principali tecnologie utilizzate, orientate prevalentemente allo sviluppo di applicazioni Java distribuite. Nel cap. 3 si studiano i requisiti dell applicazione e le richieste che l EJD deve soddisfare. Sulla base di questo elenco, nel cap. 4 si guarda alle scelte architetturali prese in merito alla progettazione: è in questo passaggio che viene deciso come ed in che ordine verrà data risposta alle richieste precedenti. In seguito, nel cap. 5, viene riportato come, a livello di codice, è stato implementato il sistema richiesto. In questo capitolo sono riportati anche alcuni stralci del codice. Dopo l implementazione, nel cap. 6, si espone un esempio concreto del funzionamento del programma, con lo sviluppo di una semplice applicazione formata da tre componenti dei quali l EJD deve gestire l upload, il deploy e la configurazione. Infine, nel cap. 7, vengono riportate le conclusioni al termine del progetto. Nelle appendici sono ripresi due argomenti utilizzati durante lo sviluppo ma 3

5 che non sono strettamente pertinenti le tematiche trattate. Nell appendice A viene descritto come il linguaggio Java gestisce l ordinamento degli oggetti, mentre nell appendice B viene riportato come estrarre da un file un array di byte. 4

6 2. SCELTE TECNOLOGICHE In questo capitolo vengono analizzate le tecnologie che costituiscono le fondamenta dell applicazione sviluppata. Si fornisce un quadro generale di ciò che sta alla base delle applicazioni e dei servizi web. 2.1 LE APPLICAZIONI MULTI TIER Il termine multi tier (o n tier) indica, nell ingegneria del software, una particolare architettura che divide il sistema in diversi moduli, ognuno dei quali ha una competenza propria. Solitamente la suddivisione prevede tre componenti, in questo caso viene chiamata architettura three tier [BauHib]. Si articola in: Presentation Tier (tier 1): si occupa dell interazione con l utente, della creazione dell interfaccia grafica, della visualizzazione dei dati. Nelle applicazioni web il client è solitamente rappresentato dal browser web Business Logic (middle tier): controlla le funzionalità dell applicazione. E costituita da un insieme di moduli, tenuti insieme da un Application Server. Nel caso di web applications questo può utilizzare la tecnologia Java EE Data Tier (tier 3): si occupa della persistenza dei dati, ovvero del loro salvataggio, aggiornamento e reperimento da un database o un qualche sistema di catalogazione dei dati Una rappresentazione dell architettura Three tier è riportata nella figura Figura 2.1.1: Rappresentazione dell architettura Three tier (da esol.com.au) In questa architettura si possono trovare alcune analogie con il design pattern tipico delle interfacce grafiche, ovvero il Model View Controller (MVC). I due schemi sono comunque sostanzialmente differenti: l architettura three tier è fortemente lineare, si basa sulla regola fondamentale che il client non interagisce mai con il Database Server e tutta la comunicazione passa attraverso il Middle Tier. Diversamente, 5

7 il MVC è triangolare: il View manda i messaggi al Controller, il Controller aggiorna il Model ed il View viene modificato direttamente dal Model. 2.2 LA TECNOLOGIA JAVA EE Java EE [Jee] è la versione enterprise della piattaforma Java. E costituita da un insieme di librerie e specifiche orientate alla costruzione di applicazioni di servizio e web applications di nuova generazione. La base è costituita dal linguaggio Java con le sue numerose funzionalità, arricchite da altre basate fortemente sullo scambio e l elaborazione di informazioni tramite la rete. Una fotografia delle tecnologie e delle API che compongono il linguaggio Java si ha in Figura Figura 2.2.1: L architettura Java (da La tecnologie Java EE, fino alla versione 5.0 di Java J2EE [WlsAa], fa uso diffusamente delle seguenti librerie: Java Servlet [Serv] e Java Server Pages [Jsp], rispettivamente tecnologie per scrivere classi Java e pagine web che utilizzano funzionalità di Java EE Enterprise Java Beans [Ejb], particolari componenti Java con possibilità di fornire servizi di tipo enterprise, come metodi accessibili da remoto, persistenza degli oggetti, modalità di chiamata asincrona Java Transaction Api [Jta], specifica la possibilità di gestire transazioni, ovvero sequenze di operazioni su database con proprietà ACID (Atomicità, Consistenza, Isolamento e Durabilità) Java Message Service [Jms], un insieme di API standard per permettere lo scambio di messaggi tra applicazioni Java 6

8 Le applicazioni Java EE sono solitamente multi tier, ovvero distribuite su più macchine, secondo uno schema indicato in Figura Figura 2.2.2: Architettura multi tier in un applicazione Java EE Queste tecnologie sopra elencate costituiscono il cuore della piattaforma Java EE, insieme a JMX, della quale si tratta nel paragrafo LE JAVA ANNOTATIONS Da evidenziare il grande passo avanti sulla facilità di sviluppo e di deploy grazie alle Annotations [Ann] (o annotazioni), introdotte nella versione 5.0 del linguaggio Java. Si tratta di informazioni in merito ad un programma che non fanno però parte del programma stesso, ovvero che non hanno un effetto diretto sul codice al quale si riferiscono. Sono fondamentalmente di tre tipologie: informazioni per il compilatore; istruzioni da processare al momento di compilazione o di deploy; informazioni necessarie a run time. Le Annotations si riconoscono perché sono introdotte dal seguito dal nome dell annotazione. Eventualmente, è assegnato anche un valore o una coppia nome valore. Prima della diffusione delle annotazioni, per specificare le istruzioni di deploy e configurazione di applicazioni java enterprise era continuo il ricorso a numerosi file Xml, che rendevano complicata e ridondante la distribuzione dei programmi. In un 7

9 secondo tempo, hanno preso piede tecnologie complementari come le XDoclets [Xdoc], sostanzialmente estensioni ai commenti che venivano lette da un pre-processore apposito e grazie alle quali veniva automaticamente generato il file Xml necessario per il deploy. Con la versione 5.0 della piattaforma Java, si è deciso di standardizzare queste estensioni e di renderle parte del linguaggio, permettendo la loro lettura a run time e di fatto eliminando nella maggior parte dei casi la necessità di un file Xml di accompagnamento. 2.4 LA TECNOLOGIA JAVA MANAGEMENT EXTENSION (JMX) JMX Java Management Extension [SunJmx] è uno standard Java per la gestione ed il monitoraggio di tutti i componenti, sia hardware che software, compresa la stessa Java Virtual Machine (JVM). E definita da due specifiche Java Specification Request strettamente collegate tra loro, sviluppate attraverso Java Community Process ed entrate a far parte della piattaforma J2SE dalla versione 5.0: Java Management Extension Specification [JSR3] Java Management Extension Remote Api [JSR160] Tali specifiche suddividono l architettura JMX in tre livelli separati, come indicato in Tabella Livello Instrumentation Agent Remote Management Descrizione Le risorse, come applicazioni, dispositivi e servizi, sono rese disponibili usando oggetti Java denominati Managed Bean (MBeans). Gli MBeans espongono le loro interfacce d amministrazione, composte di attributi e di metodi, attraverso un agente JMX per il management ed il monitoring remoto Il componente principale di un agent JMX è il server MBean. Questo è il nucleo del sistema dove vengono registrati gli MBeans. Un agente JMX include un insieme di servizi per la gestione degli MBeans. Gli agenti JMX controllano direttamente le risorse e le mettono a disposizione degli agent remoti per l amministrazione Protocol adaptors e standard connectors rendono un Agent JMX accessibile da remoto Tabella 2.4.1: Architettura della tecnologia JMX I primi due livelli, vale a dire Instrumentation ed Agent, sono definiti dalla JSR3, mentre il livello di Remote management è definito dalla JDR160. Un illustrazione della stessa architettura è in Figura

10 Figura 2.4.1: Architettura della tecnologia JMX (da Il controllo remoto JMX tramite codice è facilitato da interfacce standard che semplificano la chiamata ai metodi utilizzando la tecnologia Java RMI [Rmi] Remote Method Invocation ovvero l invocazione di metodi java su altre Java Virtual Machines. 2.5 L APPLICATION SERVER JBOSS JBoss è un azienda, di proprietà di Red Hat, specializzata nella costruzione di software middleware basato sulla piattaforma Java. Il suo Application Server è rilasciato con licenza GNU LGPL, Open Source. La sua caratteristica fondamentale è la forte modularità, la capacità di poter configurare nei dettagli parti dell Application Server. Lo stesso JBoss è infatti costituito da un microcontainer sopra al quale si innestano i vari servizi, utilizzando la tecnologia JMX (par. 2.4). La Figura illustra chiaramente questa architettura, sulla quale noi andremo ad appoggiarci per il nostro strumento di configurazione. 9

11 Figura 2.5.1: Struttura dell Application Server JBoss (da JBoss Configuration Guide ) Il microkernel di JBoss funziona come un server MBean e tutti i servizi forniti sono MBeans che si appoggiano sull infrastruttura sottostante, rispondente allo standard JMX. Ad esempio, inizialmente JBoss usava Jetty per fornire servlet e jsp. E poi passato a Tomcat [Tom], ma è ancora possibile usare Jetty [Jet] come MBean all interno di JBoss. Una volta caricati dentro a JBoss usando JMX è possibile amministrarli, tramite l adattatore RMI incluso in JBoss. Jboss è quindi stato scelto valutandone modularità, scalabilità, documentazione [JbDocs] ed affidabilità. La versione utilizzata è la 4.2.2GA, attualmente l ultima versione stabile. 2.6 IL LINGUAGGIO XML XML [Xml], acronimo di Extensible Markup Language, è un metalinguaggio nato e gestito dal World Wide Web Consortium [W3c], nato come evoluzione e semplificazione dell SGML. A differenza dell HTML, utilizzato esclusivamente per la descrizione e la creazione di pagine web ed ipertesti e con un definito gruppo di tag disponibili, il linguaggio XML può essere utilizzato per definire dei propri tag a seconda delle necessità. E molto utilizzato per lo scambio dei dati come standard aperto per la trasmissione di informazioni strutturate tramite file di testo, grazie al suo vasto supporto da parte di numerosi linguaggi ed alla sua facilità di lettura, esemplificata nel listato <?xml version="1.0" encoding="iso "?> <utenti> <utente> <nome>luca</nome> <cognome>ruggiero</cognome> <indirizzo>milano</indirizzo> 10

12 </utente> <utente> <nome>max</nome> <cognome>rossi</cognome> <indirizzo>roma</indirizzo> </utente> </utenti> Listato 2.6.1: esempio di codice XML I tag utilizzati vengono descritti tramite un altro file creato secondo lo standard XML Schema [Xsch], metodo per la descrizione formale di una grammatica per un linguaggio di markup basato su Xml. Utilizza la stessa sintassi di un documento Xml ma ha dei tag specifici. In questo progetto si è scelto di utilizzare Xml per trasmettere dati ed impostazioni piuttosto che un normale file di testo per l ampio ed il nativo supporto che il linguaggio Java ha per questo metalinguaggio [MokaXml]. 2.7 CONCLUSIONI In questo secondo capitolo sono state analizzate le tecnologie principali utilizzate nello sviluppo dell EJD. Trattandosi di un applicazione Java EE distribuita, particolare rilevanza la coprono le tecnologie fornite dalla piattaforma Java per il controllo remoto, soprattutto la Java Management Extension. Come piattaforma di riferimento è stato scelto l Application Server JBoss, del quale verranno utilizzate alcune caratteristiche che limitano la portabilità su altri Application Server, quali Web Sphere [WSph] o WebLogic [WLog]. Per gestire la configurazione da parte dell utente è stato impiegato il linguaggio XML, organico, flessibile e che permette un agevole lettura delle impostazioni. Inoltre Java dispone di un ampio supporto a questo standard, che ne facilita il parsing. 11

13 3. I REQUISITI DELL APPLICAZIONE In questo capitolo vengono analizzati i requisiti richiesti all applicazione, ovvero le sue funzionalità necessarie. Un analisi dei requisiti per individuare le linee guida da seguire. 3.1 IL QUADRO GENERALE L applicazione richiesta deve soddisfare la necessità di pacchettizzare, distribuire e configurare nel minor tempo possibile un programma Java EE complesso basato su JBoss. Per fare questo è necessario suddividere il progetto in due: una parte server che si occupa del coordinamento di tutte le operazioni ed una parte client capace di gestire il trasferimento di un file ed il suo salvataggio in una cartella temporanea. Il deploy, a partire da questa cartella, è competenza del server. Il bisogno di un meccanismo di trasferimento file rende indispensabile che, sulle macchine client, sia già installata una parte dell EJD. L applicazione da distribuire è frazionata in più componenti e l EJD deve saper gestire: l ordine di deploy dei vari componenti. Uno può dipendere dalla corretta installazione di quello precedente; la possibilità di eseguire l upload di un pacchetto su una macchina remota. Come precedentemente detto, una parte specifica dell EJD si occuperà di questa operazione; l esecuzione di servizi MBean sulla macchina remota. Anche questi possono avere una priorità di esecuzione ed uno o più parametri; la chiamata di metodi custom per la configurazione. Questo prevede la possibilità di arricchire l applicazione di base con ulteriori funzionalità; l undeploy dei componenti. 3.2 GESTIRE L ORDINE DI DEPLOY Questa è la prima caratteristica richiesta all EJD. Un applicazione distribuita è infatti composta da più pacchetti, ognuno responsabile di una parte. Ad esempio, ci sarà sulla macchina A il componente che si occupa dell interazione con l utente, sulla macchina B il componente che elabora le richieste e sulla macchina C il componente che interroga ed aggiorna il database. Supponiamo inoltre che, su una quarta macchina D, ci sia un registro dove tutti i componenti si devono iscrivere per essere coordinati. Anche il registro sarà una parte dell applicazione. In questo quadro è chiara l importanza centrale rivestita dalla gestione corretta dell ordine del deploy di queste parti: se non è correttamente configurato il registro, nessuno degli altri componenti potrà iscriversi. Inoltre, in mancanza della possibilità di 12

14 interrogare il database, è impossibile elaborare delle richieste. Ed ancora, se non si possono elaborare correttamente le richieste, l interfaccia per l utente finale non avrà alcuna funzionalità. Nello scenario qui descritto, l ordine di deploy sarebbe quindi D C B A. Tutte le parti possono essere sulla medesima macchina o su macchine diverse, pratica usuale per le applicazioni con architettura multi tier. Per questo, oltre alla priorità, ogni componente dovrà avere anche una sua macchina di destinazione. 3.3 ESEGUIRE L UPLOAD DI COMPONENTI Nello sviluppo di questo strumento non si può dare per scontata la disponibilità, nella macchina di destinazione, del pacchetto corretto del quale effettuare il deploy. Anzi, nello scenario comune è necessario pensare ad una strada per trasferire ogni pacchetto presso la macchina di destinazione. L upload è ben distinto dal deploy. Jboss prevede, infatti, l autodeploy di un pacchetto scritto nella sua cartella deploy. Non è però consigliabile trasferire un pacchetto via rete direttamente nella cartella di deploy: potrebbero verificarsi numerose problematiche, principalmente il tentativo di scompattare un archivio trasferito solo parzialmente. E quindi necessario trasferire il file presso la cartella tmp del JBoss di destinazione. Solamente una volta completato correttamente tutto il trasferimento, la parte server dell EJD chiamerà il metodo deploy() dell MBean jboss.system:service=maindeployer sulla macchina di destinazione, specificando come argomento il file appena trasferito. La parte client dell EJD, quindi, sarà sostanzialmente un MBean con la sola capacità di ricevere un array di byte e scriverlo sulla cartella tmp locale. 3.4 CHIAMARE SERVIZI MBEAN Una volta eseguito l upload ed il deploy di un componente, lo stesso ha molto probabilmente la necessità di essere configurato. In un primo caso, si suppone che vi siano a disposizione servizi MBean con dei metodi di configurazione. Sia gli MBean che i metodi da chiamare per ognuno di essi possono essere uno o più. Per questo, come già indicato nel caso dei componenti, anche loro hanno la necessità di poter esprimere una priorità nell esecuzione. 3.5 INVOCARE METODI CUSTOM Nel caso di particolari configurazioni, può essere necessario avere la possibilità di invocare metodi custom, ovvero metodi di classi create ad-hoc per la configurazione. Questi saranno eseguiti sulla macchina server e, nel caso avessero la necessità di dialogare con qualche client, sarà loro compito occuparsi della connessione. 13

15 Anche in questo caso, ogni classe per la configurazione custom può avere uno o più metodi e parametri. Per questo, analogamente a quanto indicato nel paragrafo precedente, anche nei metodi custom è necessario indicare una priorità di esecuzione. In questo scenario si apre, però, un altra problematica. L invocazione di metodi custom viene eseguita utilizzando la tecnologia Reflection di Java [Refl], il che rende la cosa configurabile tramite file xml ma pone un problema di classpath, ovvero come dare la possibilità alla JVM locale di accedere alle classi necessarie. La strada per la soluzione a questo problema è impacchettare le classi con i metodi custom da eseguire in librerie jar, trattate come componenti dell applicazione da installare. Indicando come host di distribuzione il localhost e dando loro la giusta priorità, vengono installate presso il JBoss localmente in esecuzione come librerie, in modo che, al momento della chiamata tramite Reflection, siano accessibili nel classpath. 3.6 GESTIRE L UNDEPLOY DEI COMPONENTI Oltre al deploy, l EJD deve essere in grado di gestire anche l undeploy dei componenti. In questo caso non si pone il problema dell upload di file mentre potrebbe essere necessario chiamare servizi MBean o metodi custom per eseguire una sorta di shutdown controllato del programma. 3.7 CONCLUSIONI In questo capitolo si è fornito un elenco delle specifiche che l Enterprise Java Deployer deve soddisfare. Queste sono fondamentalmente tre: Gestire l upload dei componenti di un applicazione Gestire l ordine di deploy / undeploy Facilitare la configurazione tramite chiamate a MBean o metodi custom Con questo quadro delle richieste è possibile passare alla progettazione dell EJD, ovvero al momento in cui si definiscono i principi di funzionamento dell applicazione. 14

16 4. LA PROGETTAZIONE In questo capitolo viene studiata la progettazione dell EJD. Si tratta di un passaggio fondamentale poiché indica le strade che vengono seguite per soddisfare le specifiche indicate nel capitolo precedente. 4.1 LA STRUTTURA DELL ENTERPRISE JAVA DEPLOYER Il programma necessita di un punto da dove controllare il procedimento di deploy e configurazione, da dove partire e dare l impulso iniziale del procedimento. Questa sorta di repository centrale dovrà avere la completa conoscenza della mappa del programma del quale sta per eseguire il deploy, essere in possesso di tutti i componenti e delle istruzioni per la loro configurazione, comprese eventuali classi custom o estensioni. Il repository centrale non entrerà però nel merito del dialogo tra le varie componenti del programma: questo momento riguarda infatti un livello più basso rispetto alla configurazione ed al deploy dell applicazione. Solamente una volta che i componenti di un determinato programma sono a conoscenza del corretto funzionamento di tutti quelli dai quali dipendono inizieranno infatti a cercare un dialogo tra loro, anche tramite i metodi di configurazione da chiamare. Il cuore centrale dell EJD, quindi, sarà responsabile del coordinamento di tutte le operazioni. 4.2 L ARCHITETTURA CLIENT SERVER DELL EJD Per lo sviluppo dell applicazione è stato scelto un orientamento client server. Questa è la tipologia più classica delle applicazioni distribuite. Sono coinvolte due entità: il server, che eroga il servizio, ed il client che lo richiede. Una rappresentazione di tale architettura è fornita in Figura 4.2.1, dove il server al centro è il computer che si occupa dell organizzazione ed i client fanno riferimento esclusivamente a lui. 15

17 Figura 4.2.1: Architettura Client Server (da Il compito del server, per le necessità del programma, è quello di coordinare il deploy e la configurazione delle varie macchine. Da questo computer, partendo dal presupposto che su tutti gli altri sia già installata e funzionante l applicazione di gestione dell upload, vengono caricati i componenti del programma. Il server decide, in base alle istruzioni fornite, l ordine di deploy e le configurazioni delle parti. L architettura Client Server è stata scelta dopo aver valutato la sua alternativa, ovvero il peer to peer. Nel modello peer to peer non ci sono client o server fissi, ma un numero di nodi equivalenti (peer) che fungono sia da client che da server verso altri nodi della rete. Una rappresentazione si trova nella figura 4.2.2, che rende ben evidente come questo modello sia in antitesi rispetto a quello client server. Figura 4.2.2: Architettura Peer to Peer (da it.wikipedia.org) Questo modello è più complicato da coordinare rispetto al normale Client Server ma permette il dialogo tra i computer coinvolti. Questo dialogo, per lo scopo della nostra applicazione, non è però necessario: i vari componenti interagiranno con loro ma solo in un momento successivo al loro deploy, che dunque esula dalle competenze dell EJD. 4.3 IL FILE XML DI CONFIGURAZIONE La configurazione delle modalità di deploy di un applicazione è passata all EJD tramite un file XML, chiamato di default ejd-app.xml. La sua struttura deve rispondere allo standard Xml, avendo quindi una radice ed i nodi interni formattati correttamente. La radice è il nodo <project>, che indica quindi l applicazione di cui fare deploy e da configurare. Ogni applicazione può però avere diverse modalità e necessità di configurazione: possiamo voler configurare solo una parte del programma oppure possiamo voler avere a disposizione diverse configurazioni dello stesso programma. La necessità potrebbe essere anche quella di voler configurare sullo stesso file le istruzioni 16

18 di deploy e di undeploy dell applicazione. Per questo ogni <project> potrà avere uno o più <target>, che verrà selezionato al momento dell esecuzione dell EJD. Ciascun nodo <target> è composto quindi dalle varie parti del programma, indicate come <component>. Qui deve essere scritto il nome del componente, il file ed il percorso dove si trova, l host di destinazione e l ordine di priorità. I componenti vengono eseguiti in ordine crescente, ovvero dal numero 1 in avanti. Su ogni componente può essere necessario eseguire delle azioni. Le principali sono: <upload/> come istruzione per indicare l intenzione di eseguire l upload <deploy/> per indicare la volontà di deployare il pacchetto. E un istruzione solitamente eseguita in seguito alla precedente di upload. Per eseguirla senza chiamare la precedente è necessario avere la certezza dell esistenza del pacchetto indicato sulla macchina di destinazione <undeploy/> per eseguire l undeploy del componente indicato. Le azioni di configurazione sono indicate con i tag <mbean> e <custom>. Per quanto riguarda il primo sarà necessario indicare l objectname, mentre nel secondo caso si indicherà la classe da ricercare. Anche per queste configurazioni viene indicata la priorità in maniera crescente. L ordine di priorità non fa distinzione tra configurazioni di tipo <mbean> e di tipo <custom>. Ogni configurazione ha la possibilità di chiamare uno o più metodi, anch essi ordinati con priorità crescente, ognuno con uno o più parametri. In figura si trova una rappresentazione ad albero di un tipico file di configurazione ejd-app.xml 17

19 Figura 4.3.1: Struttura ad albero di un file di configurazione ejd-app.xml 4.4 USE CASE: UPLOAD, DEPLOY E CONFIGURAZIONE DI UN APPLICAZIONE Il primo Caso di studio si inquadra nello scenario più classico, ovvero l upload, il deploy e la configurazione di un componente. I passaggi sono indicati nel diagramma in Figura e di seguito: 1. selezione, da parte dell utente, del target desiderato. Questo viene effettuato tramite una chiamata al metodo execute() dell MBean principale EjdMainMBean, indicando come argomento il target voluto; 2. processo del file xml di configurazione e costruita la sua rappresentazione tramite un albero ordinato di oggetti; 3. il primo componente per priorità viene processato. Prima di tutto viene controllato se è necessario eseguirne l upload. In caso di risposta affermativa, il componente viene caricato sulla macchina di destinazione; 4. dopo l upload, viene controllato se di questo componente è richiesto il deploy. Per configurazioni particolari può infatti non essere richiesto il deploy di alcun componente ma solo l esecuzione di metodi MBean o Custom dei quali si sa già 18

20 l esistenza sulla macchina client. Nel caso invece in cui si chieda il deploy questo è reso possibile tramite chiamate RMI al metodo deploy() dell MBean di JBoss jboss.system:service=maindeployer. Prima di eseguire il deploy di un pacchetto è necessario verificare che lo stesso non sia già in esecuzione nella macchina di destinazione. In tal caso ne viene effettuato prima l undeploy; 5. ogni componente, dopo l eventuale upload e deploy, può avere la sua configurazione. Questa può essere di due tipi: MBean oppure Custom. Nel caso di chiamate ad uno o più metodi MBean si stabilisce una connessione RMI al server di destinazione e vengono eseguiti i metodi richiesti. In una configurazione Custom, la chiamata avviene tramite le Reflection API. Per tale motivo è indispensabile avere nel proprio classpath locale le classi che vengono utilizzate. La libreria utilizzata può essere inclusa nel pacchetto dell EJD, e quindi immediatamente utilizzabile, oppure caricata sul localhost come un componente dell applicazione del quale eseguire il deploy. Entrambe le soluzioni funzionano e permettono alle Reflection API di accedere ai metodi richiesti; 6. per ogni componente vengono ripetuti i punti dal 3 al 5. 19

21 Figura 4.4.1: Diagramma di flusso del Case Study di Upload, Deploy e Configurazione di un applicazione 4.5 USE CASE: UNDEPLOY DI UN APPLICAZIONE Nel caso di undeploy di un applicazione, la possibile richiesta è quella di eseguire alcuni metodi di configurazione per eseguire uno shutdown pulito. In questo caso, l utente specificherà un componente privo di filename e filepath ma con priorità alta. Di questo componente l utente non dovrà indicare né l upload né il deploy 20

22 ma solo la configurazione, tramite tag <mbean> o <custom>. Queste istruzioni conterranno i metodi da eseguire prima dell undeploy vero e proprio. In seguito, al componente effettivo del quale eseguire l undeploy viene assegnata una priorità più bassa. L EJD ricercherà tra le applicazioni deployate presso la macchina di destinazione quella che fa riferimento al file indicato. Una chiamata RMI al metodo undeploy() dell MBean di JBoss jboss.system:service=maindeployer permetterà di disinstallarla. Uno schema di tale funzionamento è fornito in Figura Figura 4.5.1: Use Case di undeploy di un applicazione 4.6 CONCLUSIONI Scopo di questo capitolo era chiarire, tramite anche l ausilio di schemi, il funzionamento dell EJD. Dopo lo studio delle specifiche, è stata scelta un architettura 21

23 client server, che facilita il coordinamento delle operazioni. E stata studiata anche la struttura che deve seguire il file xml di configurazione per soddisfare tutte le richieste possibili da parte dell utente. Ultimi passaggi sono stati la descrizione nei particolari dei due funzionamenti principali del programma, ovvero la fase di deploy e configurazione e quella di undeploy. 22

24 5. IMPLEMENTAZIONE In questo capitolo, dedicato all implementazione, viene descritto come quanto indicato nei due capitoli precedenti, ovvero Requisiti dell Applicazione e Progettazione, viene tradotto in codice. Sono riportati alcuni listati, le parti di codice più significative per comprendere il funzionamento. 5.1 IL PARSER XML Il lavoro dell EJD parte dal Parser XML, ovvero il motore che, prendendo il file di configurazione, costruisce l albero di oggetti che rappresenta l applicazione da configurare. E stata scelta come tecnologia di accesso al file Xml DOM Document Object Model [Dom] che permette la navigazione di un file Xml come un albero di oggetti. In seguito, in modo iterativo, questa struttura viene tradotta in un vero albero di oggetti predefiniti a seconda del loro tag. Alternativa a DOM è la tecnologia SAX Simple Api for XML [Sax] che permette l accesso sequenziale ad un file xml. Questo rende più difficile la costruzione di un albero come desiderato ma, nel caso di documenti molto grandi, velocizza e facilita la lettura. Essendo i file xml di configurazione per l EJD di dimensioni relativamente ridotte, non si pone questo problema. E stata quindi scelta la tecnologia DOM. Il parsing del file di configurazione viene eseguito tramite una chiamata al metodo parse(), del quale la firma si trova nel Listato public ArrayList<Component> parse(string file, String target) Listato 5.1.1: Firma del metodo parse() La prima operazione eseguita dal Parser è la ricerca del root tag <project>. In seguito, tramite le istruzioni indicate nel listato 5.1.2, si risale al target richiesto. NodeList targets = projects.getelementsbytagname("target"); Element e; /* * Legge tutti i target e cerca quello richiesto */ for (int i = 0; i < targets.getlength(); i++) { e = (Element) targets.item(i); if (!e.getattribute("name").equalsignorecase(target)) continue; /* * Una volta trovato il target richiesto, processa e ordina * tutti i componenti */ 23

25 } NodeList compnodes = e.getelementsbytagname("component"); for (int j = 0; j < compnodes.getlength(); j++) components.add(parsecomponent(((element) compnodes.item(j)))); Collections.sort(components); Listato 5.1.2: Ricerca del target richiesto e parsing iterativo dei componenti Una volta trovato il target, come si legge dal Listato si esegue il parsing di ogni componente tramite la chiamata al metodo parsecomponent(element e). Questo metodo crea un nuovo oggetto Component, ne imposta le proprietà secondo gli attributi indicati e legge i suoi nodi figli. Possono essere di due tipologie: <mbean> oppure <custom>. Nel primo caso, il metodo chiamato è parsembeanconfig(), mentre nel secondo viene chiamato il metodo parsecustomconfig(). Questi due metodi differiscono per gli oggetti creati e per alcuni attributi che vengono impostati, ma entrambi controllano tra i nodi figli i metodi da eseguire con i relativi parametri. L ArrayList creata all interno del Component, con i configuratori MBeanConfig e CustomConfig, è unica. Le due classi sono infatti entrambe estensioni della classe Config. Questo permette di ordinare i metodi da chiamare secondo la priorità, senza fare distinzione tra metodi di configurazione MBean o Custom. Terminato il ciclo di analisi di tutti i componenti, l ArrayList costruita viene ordinata secondo le priorità dei componenti (Rif. Appendice A) e restituita al chiamante. Il funzionamento del Parser è schematizzato in Figura

26 Figura 5.1.1: Diagramma di flusso del funzionamento del Parser 5.2 IL SISTEMA DI UPLOAD DEI FILE L unica parte client dell EJD è rappresentata dal sistema di upload di un file. Questo permette di avere un interlocutore certo da parte della macchina di destinazione sul quale contare per il trasferimento del file contenente il componente. 25

27 Si tratta di un MBean contenente un metodo fileupload() con la firma indicata in listato public boolean fileupload(byte[] bytes, String filename) Listato 5.2.1: Firma del metodo fileupload La prima operazione del metodo è la ricerca della cartella temporanea, tramite l accesso via RMI al server JBoss locale indicato nel listato In questa cartella viene in seguito scritto tramite un oggetto FileOutputStream l array di byte passato come argomento, in un file chiamato come l argomento passato che, se esistente, viene cancellato. InitialContext ic; ic = new InitialContext(); MBeanServerConnection server = (MBeanServerConnection) ic.lookup("jmx/invoker/rmiadaptor"); ObjectName obj = new ObjectName("jboss.system:type=ServerConfig"); File tempdir = (File) server.getattribute(obj, "ServerTempDir"); Listato 5.2.2: Ricerca della cartella Temp del Jboss locale L MBean configurato è reperibile all indirizzo ejd:service=ejdclient, come indicato dalle direttive iniziali riportate nel listato = public class EjdClientMBean implements EjdClient { Listato 5.2.3: Le direttive iniziali per indicare il servizio MBean Dal lato server, l operazione principale è quella di trasformare un file in un array di byte (rif. Appendice B), e passare questo array come argomento insieme al nome del file da scrivere sul client. 5.3 RISALIRE ALLE INFORMAZIONI DI DEPLOY DI UN PACCHETTO Risalire alle informazioni di Deploy di un pacchetto è una pratica utilizzata, nell EJD, in due casi: Verificare se di un pacchetto è già stato eseguito il deploy Ottenere le informazioni necessarie per l undeploy di un pacchetto Viene effettuata ricercando, all interno della lista di tutte le applicazioni installate nella macchina interessata, quella che fa riferimento al file indicato. La lista si ottiene tramite 26

28 una chiamata all MBean di JBoss jboss.system:service=maindeployer. Questa operazione è indicata nel Listato ObjectName deplo; deplo = new ObjectName("jboss.system:service=MainDeployer"); Object[] arg = {}; String[] sign = {}; List<DeploymentInfo> deployed = (List<DeploymentInfo>) server.invoke(deplo, "listdeployed", arg, sign); /* * Scorro tutta la lista alla ricerca del filename che mi serve */ for (DeploymentInfo item : deployed) { if (item.url.getpath().contains(filename)) return item; } } Listato 5.3.1: risalire al DeploymentInfo di un pacchetto 5.4 RISALIRE ALL INDIRIZZO DI DEPLOY DI UN PACCHETTO Per accedere tramite codice a file e archivi contenuti nel pacchetto di distribuzione del progetto è necessario risalire alla cartella o all archivio di deploy dell ear o jar. Per fare questo bisogna trovare il ClassLoader di una istanza di una classe del progetto, creata ad hoc o accedendo alla stessa istanza in esecuzione tramite la keyword this. Viene a questo punto in aiuto una classe di JBoss, org.jboss.mx.loading.unifiedclassloader, che è il ClassLoader delle istanze eseguite all interno del server JBoss [JBServ]. Questa è un estensione della classe java.net.urlclassloader che fornisce l opportunità di individuare con il metodo geturl().getpath() l indirizzo locale dove è localizzato il Class Loader. Questo indirizzo è proprio il path cercato del deploy dell applicazione. Un esempio di questo sistema è fornito nel listato UnifiedClassLoader cl = (UnifiedClassLoader) new Parser().getClass().getClassLoader(); String deploydir = cl.geturl().getpath(); Listato 5.4.1: risalire alla directory di deploy. L oggetto Parser è un oggetto contenuto nell EJB 5.5 IL DEPLOY TRAMITE MBEAN Il deploy di un pacchetto, nell Application Server JBoss, è solitamente eseguito tramite la copia del pacchetto stesso nella cartella deploy del server e la decisione dei tempi e modi è delegata al meccanismo di Hot Deployment [HtDe]. Nel caso dell EJD, è stata 27

29 scelta la possibilità di gestire il deploy delle applicazioni tramite chiamate al metodo deploy dell MBean di JBoss jboss.system:service=maindeployer poiché: Questo permette una maggiore flessibilità ed autonomia nel deploy, separando il momento dell upload da quello del deploy Con l Hot Deployment vi è il rischio, già precedentemente indicato, di un deploy del pacchetto su una macchina remota quando ancora questo non è stato completamente trasferito, causando così un errore dell Application Server e pregiudicando la corretta configurazione del sistema La chiamata al metodo deploy() ha un solo argomento, che è l indirizzo del file del quale eseguire il deploy. Il pacchetto viene cercato nella cartella temp remota e con il nome indicato nell attributo filename del tag <component>. Le righe di codice che effettuano il deploy sono riportate nel listato ObjectName deplo = new ObjectName( "jboss.system:service=maindeployer"); Object[] arg = { filename }; String[] sign = { "java.lang.string" }; server.invoke(deplo, "deploy", arg, sign); Listato 5.5.1: deploy di un file tramite chiamata MBean 5.6 L UNDEPLOY TRAMITE MBEAN L interazione con l MBean di JBoss jboss.system:service=maindeployer è necessaria anche per quanto concerne la fase di undeploy. Nel caso dell undeploy viene chiamato il metodo undeploy(), al quale viene passato come argomento il DeploymentInfo del pacchetto interessato, ottenuto come indicato nel paragrafo 5.3. Una volta in possesso del DeploymentInfo corretto, l istruzione è semplice e si ritrova nel listato ObjectName deplo = new ObjectName( "jboss.system:service=maindeployer"); Object[] arg = { info }; String[] sign = { "org.jboss.deployment.deploymentinfo" }; server.invoke(deplo, "undeploy", arg, sign); Listato 5.6.1: undeploy di un applicazione 5.7 L MBEAN PRINCIPALE EJDMAINMBEAN Il cuore dell applicazione è rappresentato dall MBean EjdMainMBean. Questo implementa l interfaccia EjdMain che descrive tre metodi, indicati nel listato public void execute(string filename, String target); 28

30 public void execute(string target); public void create() throws Exception; Listato 5.7.1: Le firme dei metodi dell interfaccia EjdMain I primi due metodi execute() rappresentano un esempio di Overloading [Overl] dei metodi in Java. Nel caso in cui venga chiamato con due argomenti, il primo rappresenta l indirizzo del file xml di configurazione ed il secondo il target da eseguire. Se invece lo stesso metodo execute() viene chiamato con solo un argomento, questo indica il target da eseguire e come file xml di configurazione viene preso di default il nome ejdapp.xml all interno dell archivio di deploy dell EJD. Il metodo create() proviene invece dalle specifiche per gli MBean [Ej3Tr]. Viene chiamato quando si crea il servizio dall Application Server. In questo caso viene utilizzato all interno dell MBean per due scopi: risalire alla cartella Temp locale, in maniera analoga a quanto già illustrato nel listato 5.2.2; risalire all indirizzo di deploy dell EJD (vedi Par. 5.4); individuare se il programma è deployato tramite un archivio compresso o tramite una cartella. Queste ultime due necessità sono dovute al bisogno di individuare l indirizzo dei componenti distribuiti insieme al pacchetto dell EJD e, nel caso questo sia stato deployato come jar e non come cartella, estrarre dall archivio i file necessari. All interno del metodo execute(), la prima chiamata riguarda il parsing del file xml desiderato, effettuato come indicato nel paragrafo 5.1. Il risultato di un corretto parsing è una ArrayList di Component ordinata per priorità. Il ciclo for principale è incaricato di scorrere l intera lista e, per ogni componente, eseguire le richieste. La prima operazione è l apertura di una connessione al server MBean di destinazione, sia esso localhost o una macchina remota. Questo permette di avere un oggetto MBeanServerConnection al quale viene fatto riferimento per ogni operazione successiva. Le chiamate avvengono utilizzando le api RMI. Nel listato è indicato come aprire questa connessione. Context ic; Properties contextproperties; String hostname = c.gethostname(); contextproperties = new Properties(); contextproperties.setproperty(context.initial_context_factory, "org.jnp.interfaces.namingcontextfactory"); contextproperties.setproperty(context.provider_url, "jnp://" + hostname + ":1099"); ic = new InitialContext(contextProperties); MBeanServerConnection server = (MBeanServerConnection) ic.lookup("jmx/invoker/rmiadaptor"); 29

31 Listato 5.7.2: Apertura di un canale MBeanServerConnection I passi successivi, eseguiti tramite la connessione aperta, sono la ricerca della cartella ServerTempDir remota e delle eventuali informazioni di deploy del componente, nel caso sia già installato. Quest ultima operazione è possibile tramite la chiamata al metodo listdeployed() dell MBean di JBoss jboss.system:service=maindeployer. Il metodo restituisce una lista di DeploymentInfo che viene navigata fino al ritrovamento di un descrittore di deploy che faccia riferimento al file indicato. Nel caso non ve ne siano, il risultato sarà null. Maggiori informazioni su questa pratica sono state fornite nel Paragrafo 5.3. Il seguito del funzionamento dell EjdMainMBean è quello indicato in figura Per ogni componente viene eseguito l upload, se richiesto, e l eventuale deploy o undeploy. Come prima, se un componente è già deployato, prima di effettuarne il deploy si disinstalla dalla macchina di destinazione. Allo stesso modo non viene effettuato il deploy se il componente indicato non risulta essere deployato. Dopo questi passaggi, il punto in seguito più importante è la configurazione. Questa può essere di due tipi: tramite MBean, con oggetti MBeanConfig; tramite chiatate custom, con oggetti CustomConfig. L oggetto Component ha però una sola ArrayList di Config, strada dettata dalla necessità di non effettuare distinzioni in priorità tra configurazioni MBean e Custom. Nella navigazione di questa lista, quindi, il primo passaggio è quello di distinguere le due strade di configurazione, tramite il codice in listato /* * Per ogni componente, è possibile chiamare più di un metodo di * configurazione, ordinati per priorità. */ for (Config conf : c.getconfig()) { if (conf instanceof MBeanConfig) { /* * Configurazione MBean */ } else if (conf instanceof CustomConfig) { /* * Configurazione Custom */ } } Listato 5.7.3: Distinzione tra configurazione MBean e Custom Iniziando con il caso di configurazioni tramite MBean, il metodo è quello utilizzato finora di chiamate RMI e metodi di MBean con la connessione 30

32 MBeanServerConnection precedentemente creata. Ogni configurazione MBean può richiedere l invocazione di uno o più metodi, ordinati con priorità crescente. Ciascuno di questi avrà la sua firma, il numero di argomenti richiesti ed il loro tipo. La chiamata utilizzata è indicata nel listato 5.7.4, dove server è la connessione creata, object è l ObjectName instanziato come indicato negli attributi del tag <mbean>, met è l oggetto MethodConf che rappresenta il tag <method>, ovvero il metodo da chiamare, paramvalue è una lista contenente i valori dei parametri e strtype è un array che indica, ad indice corrispondente nei valori dei parametri, il tipo. server.invoke(object, met.getname(), paramvalue.toarray(),strtype); Listato 5.7.4: Chiamata di una configurazione MBean Nel caso di configurazione custom l accesso avviene tramite le Reflection API di Java. La prima attenzione da dedicare a questo passaggio è la certezza, da parte dell utente, di avere disponibile all interno del classpath locale la classe creata per la configurazione. Questa può essere impacchettata in un jar del quale eseguire il deploy esattamente come un componente. Risolta questa problematica, il procedimento è per certi versi analogo alla precedente configurazione tramite MBean. Tramite il codice in listato si crea un istanza della classe voluta, sulla quale si opera. CustomConfig cc = (CustomConfig) conf; Class<?> cls = Class.forName(cc.getClassName()); Object object = cls.newinstance(); Listato 5.7.5: Creazione di un istanza tramite Reflection A sua volta ogni configurazione custom può avere uno o più metodi da eseguire, ai quali si accede tramite un ciclo iterativo for. Per risalire al metodo da invocare, bisogna chiamare il getdeclaredmethod() sull oggetto rappresentante la classe, indicando negli argomenti il nome del metodo ed il tipo dei suoi argomenti, ovvero la firma del metodo. Sull oggetto Method restituito viene eseguito il metodo invoke() con argomenti l oggetto di destinazione ed un array con gli argomenti. Terminata la chiamata a tutte le configurazioni indicate, si passa al componente successivo, fino al termine dei componenti. 5.8 CONCLUSIONI In questo capitolo si è visto, con l ausilio anche di ampi stralci di codice, il funzionamento del programma. Sono state indicate le strade scelte per la soddisfazione delle specifiche, in particolare la struttura del parser XML, la gestione dell upload dei 31

33 file, del deploy e dell undeploy tramite chiamate a metodi di servizi MBean, sviluppati ad hoc o forniti dalla piattaforma JBoss. Una volta descritto il sistema di gestione di questi problemi specifici, si è studiato il codice dell MBean principale dell applicazione, chiamato EjdMainMBean, che si occupa di tutto il coordinamento delle operazioni. 32

34 6. UN ESEMPIO CONCRETO Per descrivere il funzionamento dell Enterprise Java Deployer in uno scenario possibile si è creata un applicazione distribuita molto semplice costituita da parti di varia natura. 6.1 L MBEAN DI TEST La prima parte del progetto d esempio è costituita da un MBean. Questo non fa nulla, se non avere un metodo al suo interno che prende una stringa e la scrive sullo standard output. Il codice è riportato nel public class TestMBean implements Test { public void echo(string echo) { System.out.println("Metodo echo MBean:" + echo); } } Listato 6.1.1: codice di TestMBean.java Questo MBean è impacchettato nell archivio TestMBean.jar, successivamente rinominato TestMBean.comp e trasferito nella directory /tmp/. 6.2 L APPLICAZIONE WEB DI TEST Il secondo pacchetto che compone il nostro ambiente di test è una semplice pagina web che riporta il classico testo Ciao Mondo sul browser. Impacchettata in Prova.war, successivamente rinominato Prova.comp e inserito nella cartella di base del nostro pacchetto EnterpriseJavaDeployer.jar. 6.3 LA CONFIGURAZIONE CUSTOM DI TEST Il terzo ed ultimo pacchetto del test è un jar contenente una semplice classe di prova, che rappresenta il caso di una chiamata ad una configurazione custom. Il codice della classe è riportato nel listato package testejd; public class Prova { public void scrivi(string echo) { System.out.println("Custom scrive: " + echo); } public void parla(string echo) { System.out.println("Custom parla: " + echo); } } 33