Web framework in ambito Java: Java Server Faces

Transcript

1 POLITECNICO DI TORINO III Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica Monografia di Laurea Web framework in ambito Java: Java Server Faces Terzulli Pierangelo matr A.A. 2006/ 2007

2

3 CAPITOLO INTRODUZIONE... 4 METODOLOGIA DI RICERCA... 4 CAPITOLO LA PIATTAFORMA JAVA ENTERPRISE EDITION... 5 IL FRAMEWORK SPRING... 6 Spring IoC... 7 Spring AOP... 8 Spring DAO e Spring ORM... 9 SPRING MVC... 9 Controller URL Mapping View Resolver View CAPITOLO L APPLICAZIONE BANCARIA COB STRATEGIA IMPLEMENTATIVA IL PROBLEMA DEL MANTENIENTO DELLO STATO CAPITOLO ARCHITETTURA DEL FRAMEWORK JSF Execution Model User Interface Component Model Component Rendering Model Conversion Model Event e Listener Model Validation Model Navigation Model Backing Bean Management Model

4 IL CICLO DI VITA DELLE RICHIESTE JSF Restore View Apply Requests Process Validation Update Model Values Invoke Application Render Response VANTAGGI DERIVANTI DALL USO DI JSF CAPITOLO INTEGRAZIONE CON SPRING Configurazione della Web Application Il Backing Bean CriteriController La view crtieri.jsp SOLUZIONI ALTERNATIVE D INTEGRAZIONE TRA SPRING E JSF CONCLUSIONI

5 Capitolo 1 Introduzione Il tirocinio si è svolto presso l azienda Trim Srl, il cui core business è lo sviluppo di applicazioni di classe enterprise in ambiente Java/.Net. Il mio compito consisteva nell analisi dell architettura software adottata internamente al fine di individuare se e come il web framework JSF (Java Server Faces) dimostrasse una maggiore scalabilità e flessibilità rispetto a quello usato internamente e se fosse facilmente integrabile nei progetti preesistenti. Al fine di capire le reali necessità dell azienda sono stato affiancato ad un team di sviluppatori per seguire lo sviluppo di un progetto reale, nella fattispecie un applicazione bancaria, COB (COllateralizzazione dei prestiti Bancari). In tal modo ho potuto osservare da vicino le problematiche da loro riscontrate nell uso del web framework adottato correntemente, per poter così determinare se e come l uso di JSF potesse risultare vantaggioso. Metodologia di ricerca Ho suddiviso quindi la mia attività in cinque fasi fondamentali: capire il funzionamento dell architettura Java EE e Spring; analizzare la strategia implementativa dell applicazione COB, in particolar modo lo sviluppo dell interfaccia web; indivudure i problemi riscontrati nell uso del web framework corrente; analizzare le opportunità offerte da JSF in termini sviluppo e integrazione; dimostrare come JSF semplifica la codifica del WebLayer. 4

6 Capitolo 2 L architettura interna adottata dall azienda per il progetto da me seguito è basata sulla piattaforma Java Enterprise Edition (Java EE) e fa uso del framework Spring. Tale architettura è stata utilizzata anche per altri progetti realizzati precedentemente. Il progetto da me seguito consisteva nella realizzazione di una applicazione multi-layer bancaria di livello enterprise, accessibile tramite interfaccia web e supportata da un database Oracle preesistente. Oltre alle funzionalità di business, l applicazione doveva quindi gestire le transazioni e l interfacciamento con l utente. Prima di analizzare il design dell applicazione ritengo opportuno descrivere in linea generale l architettura software su cui si basa il progetto. La piattaforma Java Enterprise Edition La piattaforma Java Enterprise Edition, secondo la definizione della stessa Sun (l azienda che l ha realizzata) è uno standard industriale per lo sviluppo di applicazioni Java-based portabili, robuse, scalabili e sicure. Si tratta di una piattaforma multi-livello che fornisce un gran numero di servizi, tra i quali transazionalità, web services, un component model, un sistema di accesso ai dati, sicurezza, tutti requisiti fondamentali per un applicazione di classe enterprise. La piattaforma è definita attraverso una specifica alla quale tutti i produttori di software Java EE compatibile devono aderire. È proprio grazie a questo meccanismo che è considerata di fatto uno standard industriale. Anche i servizi da essa forniti sono definiti attraverso specifiche, denominate API specification: Enterprise Java Beans, Servlets, JDBC sono solo alcune di esse e servono rispettivamente a definire un ambiente entro cui eseguire gli oggetti di una applicazione Java EE, un ambiente entro cui eseguire una applicazione web, un sistema standard di accesso ai dati. Tutte le applicazioni Java EE devono essere eseguite all interno di un Application Server, cioè un applicazione che implementi la specifica Java EE. Considerata la complessità e la vastità della specifica, non stupisce che soluzioni basate su questa piattaforma costino non poco. In genere i produttori di software Java EE compatibile vendono licenze annuali dei loro applicativi, in quanto si rivolgono a clienti che hanno particolari esigenze sia in termini di performance, sia in termini di sicurezza e fault-tolerance. Purtroppo, proprio la complessità della specifica ha reso negli anni lo sviluppo di applicazioni Java EE piuttosto difficile, lungo e tedioso. Man mano che l ingegneria del software sviluppava nuove metodologie di sviluppo (Test Driven Development, Model Driven development, Extreme Programming solo per citarne alcuni), ci si rendeva conto di come il modello di programmazione 5

7 adottato da Java EE fosse poco flessibile: le applicazioni sviluppate per questa piattaforma erano intimamente legate ad essa e col tempo divenivano difficilmente manutenibili e scalabili. Nel 2002 alcuni di questi problemi furono esposti in un libro, Expert One-on-One J2EE Design and Development, in cui l autore Rod Johnson proponeva alcune linee guida e best practice da adottare; il codice che accompagnava il libro sarebbe diventato quello che oggi è conosciuto come il framework Spring. Figura 1 Panoramica della piattaforma Java EE Il framework Spring Spring è un framework open-source sviluppato per semplificare la realizzazione di applicazioni basate su Java EE. Nel corso degli anni però si è arricchito di una moltitudine di servizi le cui funzionalità spaziano dalla gestione delle transazioni, alla sicurezza, all ORM, al sistem management,ai web services. Ad oggi è considerato una valida e leggera (lightweight) alternativa al più pesante Java EE, soprattutto in quei casi dove è richiesto solo una piccola parte (tipicamente gestione delle transazioni e interfacciamento web) delle funzionalità offerte da un Application Server. 6

8 SPRING IOC Il framework Spring è, nella sua più intima essenza, un container che implementa l Inversion of Control pattern (IoC). Con IoC ci si riferisce ad un metodo per risolvere le dipendenze tra oggetti a run-time senza che esse siano specificate nel codice degli oggetti dipendenti. Generalmente in una qualsiasi applicazione non banale, un oggetto che voglia fornire una determinata funzionalità ha bisogno delle funzionalità fornite da uno o più oggetti esterni, siano essi locali o remoti; per ottenerle può utilizzare diversi modi: può istanziare direttamente l oggetto/gli oggetti nel corpo di uno dei suoi metodi, può ottenerlo/i attraverso un oggetto factory oppure può ottenere un riferimento ad esso/i effettuando un lookup JNDI. Qualunque approccio si preferisca, gli oggetti dell applicazione risultano fortemente legati tra di loro: nel primo caso a nulla servirebbe nascondere l oggetto desiderato dietro una interfaccia, in quanto l oggetto chiamante deve fornire comunque una implementazione specifica; nel caso in cui si usi JNDI invece, l oggetto sarà fortemente legato ad un servizio esterno, offerto generalmente dall application server in cui opera. In qualunque modo si operi dunque si sporcano gli oggetti di business logic, cioè si interrompe il flusso logico per risolvere un problema che logicamente è indipendente dalle funzionalità che gli oggetti devono fornire. Un IoC container come quello alla base di Spring, al contrario, si fa carico di risolvere queste dipendenze per loro, iniettando gli oggetti desiderati quando essi saranno richiesti e rendendoli disponibili nello Spring Context: allo sviluppatore è richiesto soltanto di dichiarare queste dipendenze nel file applicationcontext.xml. Esternalizzare le dipendenze in un file XML separato permette quindi di minimizzare quanto più possibile le dipenze tra gli oggetti stessi, favorendone un più efficace riutilizzo e rendendo l applicazione nel suo insieme più facilmente manutenibile, rendendola inoltre completamente disaccoppiata dal container entro la quale gira. 7

9 Figura 2 Spring Overview SPRING AOP AOP Altro modulo importante del framework Spring è quello che fornisce il supporto all Aspect Oriented Programming (AOP). Tale paradigma è una evoluzione del più famoso Object Oriented Programming (OOP) che sta alla base della tecnologia Java stessa e di una moltitudine di altri linguaggi moderni (C++,.Net, Delphi, Python tanto per fare alcuni esempi). L uso di AOP è indicato per tutta quella classe di problemi che non sono facilmente modellabili con un approccio object oriented, semplicemente perché interessano l applicazione nel suo insieme (sono cioè dei cross-cutting concern): esempi tipici sono la sicurezza, il logging, la transazionalità o la persistenza: sono caratteristiche che il sistema deve avere, ma sono logicamente indipendenti dalla business logic dell applicazione. Implementare questi aspetti con logica object oriented significherebbe ancora una volta sporcare gli oggetti, interrompere il flusso logico per risolvere problematiche che esulano dalla logica applicativa. L uso di AOP invece fa sì che la loro gestione sia trasparente all applicazione. 8

10 SPRING DAO E SPRING ORM DAO ORM Il supporto per l accesso ai dati in Spring è garantito dai moduli DAO (Data Access Object) e ORM (Object-Relational Mapping): il primo semplifica notevolemente il codice JDBC per l accesso alle basi di dati, evitando di aprire e chiudere le connessioni e, attraverso l uso di AOP, offre un supporto alle transazioni addirittura più esteso rispetto a quello fornito da JTA (la specifica Java EE relativa alle transazioni), che tra l altro richiede il supporto di un Application Server. Il secondo permette di fare uso nella propria applicazione delle più svariate tecnologie di ORM (Object-Relational Mapping) oggi esistenti: Hibernate, ibatis, JPA, JDO, Oracle TopLink per citare i più diffusi. A tal proposito, nonostante la scelta sia molto variegata, negli ultimi anni l elevato grado di integrazione tra l IoC container e Hibernate (altro progetto open-source) sta dimostrando un notevole successo in ambito enterprise, ponendosi in diretta concorrenza con software commerciali similari. Spring MVC Per quanto riguarda il supporto web, Spring dispone del modulo Spring MVC che fa uso delle Servlet API. Essendo questo il modulo usato per l implementazione dell interfaccia web di COB, ritengo opportuno descriverlo in maniera più approfondita. Spring MVC, come si evince dal nome, implementa il pattern Model View Controller, in cui il Model rappresenta il dato da presentare all utente, la View rappresenta ciò che l utente vede e con cui interagisce, mentre il Controller interpreta le richieste dell utente, le elabora e ne fornisce i risultati. È costruito attorno alla servlet DispatcherServlet, la quale agisce come Front Controller delegando la gestione delle richieste in arrivo alle classi Controller. Il diagramma seguente illustra il flusso del framework per rispondere ad una richiesta proveninete da un client. Il Controller quindi processa la richiesta, esegue la logica di back-end necessaria e alla fine genera un oggetto ModelAndView che la DispatcherServlet utilizzerà per effettuare il rendering della response con la collaborazione di un ViewTemplate. 9

11 Figura 3 Gestione di una request Come tutte le servlet, anche la DispatcherServlet va configurata nel file web.xml, il file descriptor della web application. Nel caso di COB, esso appare così: <context-param> <param-name>contextconfiglocation</param-name> <param-value> /WEB-INF/classes/applicationContext.xml </param-value> </context-param> <listener> <listener-class> org.springframework.web.context.contextloaderlistener </listener-class> </listener> <servlet> <servlet-name>cob</servlet-name> <servlet-class> org.springframework.web.servlet.dispatcherservlet </servlet-class> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>cob</servlet-name> <url-pattern>*.htm</url-pattern> </servlet-mapping> Da notare le definizioni del parametro contextconfiglocation e del listener ContextLoaderListener, necessari rispettivamente per localizzare il file applicationcontext.xml contenente le dipendenze del progetto e caricare all avvio l Application Context. 10

12 La servlet DispatcherServlet così configurata, denominata cob, verrà richiamata per tutte le richieste alle pagine il cui nome corrisponde all espressione *.htm. Durante la sua inizializzazione, essa carica un particolare file xml, cob-servlet.xml, all interno del quale sono configurati i vari controller, handler mapping e resolver coinvolti nell elaborazione delle richieste ad essa associate. Il file cob-servlet.xml, come l applicationcontext.xml per L IoC di Spring, definisce ciò che viene chiamato WebApplicationContext associato alla servlet cob. Figura 4 il file cob-servlet CONTROLLER I controller, come anticipato precedentemente, permettono di accedere al comportamento della web application. In Spring MVC una classe che voglia agire da controller deve implementare l interfaccia Controller: public interface Controller { } ModelAndView handlerequest( HttpServletRequest request, HttpServletResponse response) throws Exception; Essendo molto generica, il framework mette a disposizione dello sviluppatore una serie di Controller specificatamente pensati per risolvere alcune situazioni comuni. In COB ad esempio tutte i controller estendono la classe BaseMultiActionFormController, la quale estende 11

13 a sua volta il controller fornito da Spring MultiActionFormController. Esso permette ad un unico controller di gestire più richieste, siano esse di tipo GET o POST, centralizzando funzionalità comuni su un'unica classe. I controllers, così come le servlet, sono mappati ad una o più URL e hanno accesso agli oggetti HttpServletRequest e HttpServletResponse necessari per poter estrarre i dati inviati dall utente, elaborarli (attraverso i servizi messi a disposizione dallo strato di business-logic sottostante) ed infine indirizzare i risultati alla view dedicata alla loro rappresentazione. URL URL MAPPING Per determinare quale controller deve eleborare una particolare richiesta, effettuando quindi ciò che viene definito come URL Mapping, bisogna configurare un HandlerResolver. Spring, a seconda della strategia utilizzata per il mapping, mette a disposizione alcune implementazioni di HandlerResolver: nel caso di COB si è scelto di usare il PropertiesMethodNameResolver, attraverso il quale è stato possibile associare gli URL direttamente ai metodi dei Controller che si occupano della loro gestione. Tali metodi devono restituire un oggetto ModelAndView affinchè il framework sia poi in grado di determinare quale pagina restituire all utente. Figura 5 Mapping attraverso PropertiesMethodNameResolver 12

14 VIEW RESOLVER L oggetto ModelAndView contiene al suo interno un riferimento alla view da visualizzare e i risultati dell oprazione richiesta. Tale riferimento non è altro che un nome logico, che verrà poi risolto da un oggetto, il ViewResolver appunto, fornito direttamente da Spring MVC e che il programmatore deve configurare appositamente. Questa separazione permette un completo disaccoppiamento tra il Controller e la particolare tecnologia di rendering utilizzata per la view. VIEW La tecnologia di rendering predefinita per Spring MVC è JSP, la stessa adottata per l applicazione COB in quanto ben conosciuta dal team di sviluppo. È possibile però utilizzare altre tecnologie, come XML, XUL, JSF o addirittura formati binari come PDF, XSL o DOC (queste necessitano però di un ViewResolver specifico e appositamente configurato). 13

15 Capitolo 3 L applicazione bancaria COB Dall analisi si è dedotto che l applicazione da realizzare deve gestire la collateralizzazione dei prestiti bancari per conto dell azienda committente, la banca San Paolo. Nella fattispecie si tratta di gestire il rapporto che sussiste tra il cliente e la Banca d Italia duante l erogazione dei prestiti. Quando alla banca San Paolo arriva una richiesta di prestito, questa deve soddisfare una serie di condizioni (definite mediate criteri di idoneità) per poter essere autorizzata. Se queste condizioni sono soddisfatte, la richiesta viene assegnata al comitato crediti, il quale può decidere se assegnarla a sua volta alla propria tesoreria, SPIMI, o scartarla. A questo punto la tesoreria può comunicare a Banca d Italia la richiesta del prestito attraverso un sistema di messaggistica sicuro e adottato a livello internazionale, denominato SWIFT. Qualora Banca d Italia autorizzi il prestito, esso viene considerato costituito in pegno e San Paolo può richiederne lo svincolo, altrimenti viene scartato. In generale quindi il ciclo di vita di un prestito prevede quattro fasi: verifica della congruità tecnica e accettazione del comitato crediti (assegnazione a tesoreria); segnalazione a Banca d Italia; costituzione in pegno; svincolo. 14

16 scartato tecnicamente congruo da approvare comitato assegnato a tesoreria Figura 6 diagramma di stato del prestito per la congruità tecnica richiesta da San Paolo n/a (stato di part enza) stato n/a applicabile quando lo stato 1 non vale "assegnato a tesoreria" da segnalare a Bankit stato "da segnalare a Bankit" applicabile quando lo stato congruità (campo di stato 1) diventa "assegnato a tesoreria" segnalato a B ankit rifiutato da Bankit costituito in pegno non ripresentabile richiesta di svinc olo s cadut o svincolato Figura 7 Diagramma di stato del prestito per l autorizzazione da parte di Banca d Italia 15

17 In fase di analisi sono stati individuati due diversi livelli di criterio di idoneità: un criterio di idoneità "forte" (MASTER) per rispondere alle regole imposte dalla Banca d'italia e un criterio di idoneità "debole" (di PRESELEZIONE) interno a San Paolo. I criteri MASTER sono i criteri che vengono applicati dal sistema ai soli prestiti assegnati a tesoreria al fine di verificarne giornalmente la congruità tecnica richiesta da Banca d'italia per l accettazione. Sono creati da un utente amministratore e vengono applicati con scadenza giornaliera dal sistema in maniera automatica. Per ciascun criterio l amministratore può indicare se la sua mancata verifica debba portare necessariamente allo svincolo del prestito e se la cosa debba essere trascritta in un file di log: può cioè creare criteri che svincolano il prestito e criteri che tracciano soltanto l incongruità del prestito riferita al singolo criterio. I criteri di PRESELEZIONE sono legati alle opportunità definite dalla tesoreria SPIMI e possono mutare nel tempo con maggiore frequenza rispetto ai criteri MASTER. Sono creati e applicati nella fase di preselezione dei prestiti, volta a individuare quali prestiti possono essere assegnati al comitato crediti per l approvazione. Sono di competenza per l appunto dell operatore addetto alla preselezione dei crediti. Se il prestito soddisfa i criteri di idoneità imposti da Banca d Italia (criteri MASTER) esso entra nello stato da segnalare a Bankit e la tesoreria può inoltrare la richiesta a Banca d Italia: inviando un messaggio SWIFT di segnalazione a Banca d Italia. Banca d Italia, allorquando riceve la segnalazione, invia un altro messaggio SWIFT, detto di ack su segnalazione. Se la Banca d Italia conferma la validità del prestito inviando un messaggio di SWIFT di accettazione, il prestito entra nello stato costituito in pegno, altrimenti al ricevimento di un messaggio SWIFT di invalidità entra nello stato scartato. Strategia implementativa Trattandosi di una applicazione di livello enterprise piuttosto complessa, si è deciso di strutturare COB concettualmente su tre livelli o layer: Il DataLayer, che rappresenta la base dati Oracle locale ove risiedono le informazioni relative ai prestiti (ricevute giornalmente tramite un servizio remoto denominato host ), il Business Layer ove risiede la logica di business dell applicazione stessa, ed infine il Web Layer che rappresenta l interfaccia utente dell applicazione. La separazione tra business logic e interfaccia utente è fondamentale ed è considerata una best practice nello sviluppo software. Nel caso di COB in particolare semplifica una eventuale sostituzione del web framework utilizzato. 16

18 Grazie all utilizzo estensivo del framework Spring durante l ingegnerizzazione dell applicazione, l applicazione non necessita di un completo Application Server per poter funzionare, giacchè gran parte delle funzionalità di classe enterprise sono fornite dal framework stesso. In particolare Le funzionalità di accesso ai dati e la transazionalità sono ottimamente gestite dal modulo Spring DAO, mentre per quelle di ORM si è fatto uso di Hibernate. Per lo sviluppo del Web Layer ci si è affidati, come anticipiato precedentemente, al modulo Spring MVC e al servlet container Apache Tomcat: è stato quindi possibile modellare COB semplicemente come una web-application e deployare il file war corrispondente sul server Tomcat. L ambiente di sviluppo adottato quindi è costituito dall IDE Eclipse nella sua versione 3.2, affiancato da Spring versione 1.2, Hibernate versione 3.0 e dal servlet container Apache Tomcat nella versione 5.0. Figura 8 Struttura del progetto eclipse relativo all applicazione COB Il codice dell applicazione è fondamentalmente strutturato in due progetti eclipse: COBBusinessLayer, e COBWebApplication. Per quanto riguarda il primo, dalla figura sottostante si notano: 17

19 Figura 9 Struttura del progetto COBBusinessLayer Il package com.sanpaolo.cob.beans: qui risiedono i beans che rappresentano il modello dell applicazione e ne mantengono lo stato. In particolare essi sono stati automaticamente generati tramite Hibernate mappando le tabelle presenti nella base dati Oracle e la cui locazione è specificata all interno del file applicationcontext.xml; Figura 10 contenuto del package com.sanapolo.cob.beans 18

20 Il package com.sanpaolo.cob.business: come si evince dal nome, qui invece trovano spazio gli oggetti che implementano la logica di business, ovvero le funzionalità di COB. Il codice che definisce l interfaccia web si appoggia direttamente a queste classi per fornire le funzionalità di business agli utenti, perciò tali classi saranno esposte come service nel file applicaitioncontext.xm; Figura 11 contenuto del package com.sanapolo.cob.business Il package com.sanpaolo.cob.dao: contiene al suo interno l oggetto HibernateDAO che è esposto nel file applicationcontext.xml per fornire il servizio DataAccess necessario per l accesso ai dati; Figura 12 contenuto del package com.sanapolo.cob.dao 19

21 Il file applicationcontext.xml: rappresenta il file xml necessario all IoC container di Spring per capire le dipendenze tra le varie classi dell applicazione. In particolare, come si evince dalla figura, le classi che implementano la logica applicativa e quelle che realizzano la comunicazione con il database sono esposte attraverso il tag <bean>; Spring si occuperà quindi di renderle disponibili nelle classi che definiscono l interfaccia utente. Figura 13 contenuto del file applicationcontext.xml La struttura del progetto COBWebApplication è invece costituita dai sorgenti che definiscono la parte Controller e dalle pagine JSP che definiscono la parte View: 20

22 Figura 14 Struttura di COBWebApplication con espanso il package relativo ai controller Figura 15 Vista delle pagine JSP 21

23 Per quanto riguarda lo sviluppo della View, si è deciso di adottare una struttura a quattro pagine, ognuna dedicata ai casi d uso individuati in fase d analisi e cioè: definizione dei criteri MASTER; preselezione dei prestiti da presentare al comitato; gestione dei prestiti assegnati a tesoreria; gestione degli SWIFT. Figura 16 schermata iniziale di COB in modalità Amministratore La figura mostra la pagina iniziale dell applicazione attraverso cui l operatore può accedere alle varie funzionalità: ogni pagina quindi presenta una serie di TAB o sottsezioni ognuna delle quali relativa alle varie operazioni necessarie al completamento del task. 22

24 Figura 17 Definizione dei criteri MASTER Tramite il primo link l amministratore può definire le condizioni di eligibilità previste dai criteri MASTER imposti da Banca d Italia per l autorizzazione del prestito. Figura 18 Definizione dei criteri di preselezione dei crediti Il secondo link permette di gestire le operazioni relative alla preselezione dei prestiti da inviare al comitato crediti. L operatore di preselezione crediti può quindi definire i criteri di 23

25 PRESELEZIONE, avviare la procedura di preselezione dei prestiti provenienti da HOST (applicando i criteri precedentemente definiti), assegnare i prestiti preselezionati al comitato crediti e, in base alle decisioni prese da quest ultimo, assegnarli alla tesoreria o scartarli. Figura 19 Il terzo link è accessibile dagli operatori della tesoreria, e permette di gestire il ciclo di vita del prestito rispetto a Banca d Italia (segnalazione, costituzione in pegno, scarto). La generazione degli SWIFT necessari alla comunicazione è fatta automaticamente da COB (ma non l invio degli stessi la cui operazione è demandata all utente). Inoltre il sistema permette all utente di trascrivere i dettagli delle operazioni compiute in un documento MS Word (funzione richiesta da San Paolo per espletare alcuni obblighi legali e burocratici). 24

26 Figura 20 Gestione Swift e Alert Il quarto link è dedicato interamente alla gestione dei messaggi SWIFT e ALERT (messaggi informativi generati dal sistema al verificarsi di certe condizioni) generati al link precedente. Qui l utente può controllare che i messaggi SWIFT generati dal sistema siano validi e quindi autorizzarne l invio. Il problema del manteniento dello stato Durante lo sviluppo di COBWebApplication mi sono reso conto delle difficoltà incontrate dagli sviluppatori nella realizzazione nel WebLayer, in particolar modo quando era necessario gestire lo stato dell interfaccia web tra una request e l altra, ma anche nell aggiunta di funzionalità che esulavano dalla business logic e che riguardavano esclusivamente l aspetto e il comportamento della GUI. Inizialmente ho pensato fosse un problema dovuto alla mancanza, nel team di sviluppo, di un web designer, una figura esperta nella realizzazione di pagine html. In realtà col procedere dello sviluppo diventava sempre più chiaro che il problema risiedeva in alcune limitazioni del modello di programmazione proposto da Spring MVC. Il problema deriva essenzialmente dal fatto che il protocollo HTTP su cui si basa il web è essenzialmente un protocollo stateless. Ciò comporta che il passaggio dei dati da una pagina all altra e in generale il mantenimento dello stato della GUI è totalmente a carico dello sviluppatore; Spring MVC d altro canto non offre alcun supporto a questo genere di problema, concentrandosi esclusivamente sulla coordinazione tra Model, View e Controller: tale problema 25

27 dunque si riflette sia nello sviluppo delle pagine JSP che nello sviluppo dei controller ad esse associati. Un esempio particolarmente evidente di questo problema riguarda la selezione dei criteri di PRESELEZIONE e il loro successivo processamento per l assegnamento al comitato. La soluzione adottata all'interno di COB prevede che l'utente possa creare criteri su qualunque dei campi presenti all'interno del flusso prestiti proveniente da host: per uno specifico campo possono esistere soltanto un criterio di tipo "applica o non applica" o un criterio di tipo "valuta e scrivi nel log"; per ciascun criterio inoltre, l'utente può indicare se, qualora non fosse verificato, esso deve portare all'esclusione del prestito oppure se deve soltanto causare una scrittura nel log applicativo relativo all'operato dei criteri. L implementazione di questa funzionalità è affidata al controller critericontroller e alla pagina JSP criteri.jsp (forniti in allegato alla presente relazione). Il primo, attraverso l uso degli oggetti di business logic, preleva i campi SQL relativi ai prestiti provenienti da host e li inserisce all interno dell oggetto ModelAndView. Uno sguardo più approfondito al codice rivela però che buona parte di esso è dedicato all invio di variabili di controllo per la presentazione, ad esempio _selectedrow, _azione, visualizzadettagli. Tale codice, secondo chi scrive, non dovrebbe interessare il controller ma esclusivamente la view. Il controller dovrebbe solo intercettare gli input dell utente (provenienti dalla view) e provvedere di conseguenza a richiamare le funzionalità di business richieste, restituendone i risultati. D altro canto il reperimento dei parametri inviati dall utente avviene attraverso l oggetto HttpServletRequest, un oggetto messo a disposizione dalle Servlet API ma che opera a basso livello, quello HTTP, e che non ha alcuna cognizione del contesto applicativo in cui opera. Per quanto riguard criteri.jsp, si nota subito l abbondanza di codice JavaScript personalizzato, utilizzato prevalentemente per l invio dei dati al server (manipolando opportunamente gli elementi form della pagina web), mentre invece il codice JSP è usato per lo più per visualizzare i dati richiesti e controllare l aspetto della view attraverso le variabili rese disponibili da CriteriController. Nell insieme Il codice della pagina si presenta abbastanza caotico e di difficile manutenzione, a causa anche della stretta interdipendenza tra view e controller. Questo aspetto limita moltissimo il riutilizzo dei componenti; si pensi ad esempio all uso delle variabili _selectedrow, _azione e visualizzadettagli, che si riferiscono esclusivamente allo stato della view ma sono definite nel controller: se un altro controller volesse far uso della stessa view saremmo costretti a reimplementare le stesse variabili nel nuovo controller, duplicando inutilmente il codice. 26

28 La gestione lato server dello stato di un applicazione web quindi comporta numerosi problemi di scalabilità e manutenzione, e nonostante il problema sia stato discusso e affrontato in vari modi nessuna delle soluzioni proposte dal mercato è risultata soddisfacente. La piattaforma Java EE d altro canto, si è limitata finora a fornire solamente un supporto basilare alle applicazioni web (attraverso le Servlet API), senza mai affrontare direttamente il problema del mantenimento dello stato in maniera sufficiente. Da ciò è nata la necessità da parte di Trim di orientarsi verso altri framework, in particolare verso JSF. 27

29 Capitolo 4 Architettura del framework JSF JavaServer Faces (JSF) è una nuova specifica definita all interno della piattaforma Java Enterprise Edition versione 5, per la realizzazione di web application. Si tratta di un framework basato sulle Servlet API che implementa il pattern MVC ma che adotta un approccio completamente diverso e per certi versi innovativo rispetto alle soluzioni precedenti. Esso infatti fornisce un modello di sviluppo component-based, event-driven, molto simile a quello proposto da Swing per applicazioni desktop. In JSF l interfaccia utente è rappresentata lato server da un albero di oggetti (i componenti appunto) che ne rappresentano lo stato in ogni momento del suo ciclo di vita. Ogni azione che l utente effettua su un dato componente dell interfaccia genera un evento che può essere intercettato e processato lato server: il collegamento (binding) tra elementi dell interfaccia e oggetti lato server è effettuato in maniera automatica dal framework stesso, liberando lo sviluppatore dai problemi derivanti dalla natura stateless del protocollo HTTP. Figura 21 Il Modello di comunicazione a eventi di JSF JSF fa uso di servizi già presenti nella piattaforma Java EE (sulla quale del resto si basa) ma su questi costruisce un nuovo impianto architetturale entro cui fornisce alcune tipologie di servizi completamente nuove. Se si pensa l'infrastruttura di una applicazione web come uno stack di servizi che partono da un livello di astrazione minimo fino a un livello più alto infatti, si vede come i servizi di JSF forniscono uno strato di astrazione più elevato rispetto a quelli forniti da Spring MVC, che già a loro volta sono più in alto nella pila rispetto a quelli dell'implementazione standard di Servlet e JSP. 28

30 Figura 22 Visione Stack dell infrastruttura di una applicazione web I concetti chiave introdotti dunque da questo nuovo livello di astrazione sono: UI component: Un JavaBean residente sul server che incapsula le funzionalità specifiche per l interazione con l utente. Più UI Component fornano una View, cioè un albero di componenti che può essere poi renderizzato come pagina web. Renderer: Un oggetto responsabile della visualizzazione o rendering di un UI Component e che si occupa della conversione dei dati inseriti dall utente nel tipo di dato accettato dal componente. Il Renderer può operare su più UI Component e ogni UI Component può avere più Renderer. Validator: È usato allorquando è necessario assicurarsi che i dati inseriti dall utente in un UI Component siano validi. Ad ogni UI Component possono esssere assegnati più oggetti Validator. Backing Bean: Rappresenta il Controller della View. E un semplice JavaBean a cui si possono associare gli UI Component di una view e i metodi che implementano la logica di gestione del Web Layer. Converter: Converte il valore di un UI Component in una stringa (e viceversa) per la visualizzazione. Ogni UI Component può essere associato ad un solo Converter. Event e Listener: Costituiscono gli elementi base del modello di programmazione a eventi, tipico dello sviluppo Swing. L utente esegue un azione su di un UI Component, quest ultimo scatena un evento e i listener registrati per quell evento lo processerano. 29

31 Message: Rappresenta un informazione che viene inviata all utente. Infatti, qualsiasi elemento dell applicazione (backing bean, validator, converter eccetera) può generare un messaggio informativo o di errore che verrò quindi visualizzato all utente. Navigation System: Rappresenta il sistema di navigazione utilizzato in JSF. Figura 23 Modello concettuale della comunicazione tra i vai elementi di JSF La figura mostra le relazioni che intercorrono tra questi elementi: gli UI Component contenuti nella View aggiornano i Backing Bean e generano eventi (Event) in base alle azioni degli utenti. I Validator verificano che i valori degli UI Component siano validi. I Converter traducono e formattano i valori contenuti negli UI Component e li rendono disponibili per la renderizzazione. I Backing Bean contengono Event Listener e Action Method attraverso cui gestiscono gli eventi generati dagli utenti. In particolare gli Action Method sono degli Event Listener il cui valore di ritorno è usato dal Navigation Sytem per determinare quale View visualizzare all utente. Infine i Renderer effettuano il rendering degli UI Component della View selezionata. In aggiunta a questi JSF offre una serie di servizi necessari per lo sviluppo di applicazioni web: Conversioni di tipo: Come è noto, un client web può inviare via HTTP al server solo delle stringhe, per cui è necessario convertire queste stringhe in valori corrispondenti ai tipi necessari per il livello Model. JSF fornisce perciò gli strumenti per automatizzare questa conversione. 30

32 Validazione: La validazione dei dati ricevuti dal client è uno dei compiti più comuni e ripetitivi nello sviluppo dell'interfaccia web. JSF fornisce una serie di validatori standard per le esigenze tipiche, che sollevano lo sviluppatore dal realizzare questa attività e mette a disposizione un modello di sviluppo che consente di realizzare molto semplicemente validatori custom. Binding tra campi di interfaccia e attributi di JavaBean: I dati immessi lato client nell'interfaccia web di una applicazione devono poi essere contenuti in oggetti lato server che modellano le entità sulle quali devono andare ad agire le elaborazioni del livello di Model. I dati di interfaccia, dopo essere stati convertiti in valori di tipo opportuno ed essere stati sottoposti a validazione, devono andare a popolare opportuni attributi di JavaBean. JSF fornisce gli strumenti per effettuare questa operazione di "binding" in modo automatico e dichiarativo. Gestione del Flusso di Navigazione: Una parte molto importante di una applicazione web è la gestione del flusso di navigazione tra le pagine web che la costituiscono. JSF, analogamente a quanto fatto ad esempio in Spring MVC, consente di definire in maniera semplice ed esternamente al codice la logica di navigazione della propria applicazione. Rendering dei componenti: Un aspetto molto importante in JSF è la separazione tra il comportamento di un elemento di interfaccia e la sua rappresentazione grafica. L'elemento di interfaccia viene modellato da una classe che ne definisce il comportamento. L'aspetto grafico, ovvero la sua "renderizzazione", è a carico di una classe completamente distinta, un Renderer appunto. Ciò significa che una stessa interfaccia può essere "renderizzata" in formati diversi senza modificarne il comportamento funzionale. Gestione degli errori: JSF ha i meccanismi necessari per la gestione degli errori e per la segnalazione degli stessi al livello di interfaccia. Internazionalizzazione: JSF supporta la gestione dell'internazionalizzazione di una applicazione web con strumenti molto simili a quelli già in uso in altri framework. In termini di sviluppo JavaServer Faces mette a disposizione dello sviluppatore un ampio insieme di classi e API che permettono di definire i componenti dell interfaccia utente e gestirne il mantenimento dello stato, gestire gli eventi che vengono generati lato client con oggetti e codice lato server, specificare la navigazione fra le pagine all interno della web application e realizzare componenti personalizzati che estendono e potenziano le funzionalità delle classi basi del framework. Queste classi sono raggruppate in modelli, in relazione a specifici aspetti realizzativi di una applicazione Web. Execution Model; UI Component Model; Component Rendering Model; Event and Listner Model; Validation Model; Navigation Model; Backing Bean Management Model 31

33 EXECUTION MODEL Questo modello fa riferimento a tutto ciò che riguarda l esecuzione dell applicazione, quindi in particolar modo definisce le classi che costituiscono il Controller del pattern MVC. Trattandosi di un framework per lo sviluppo di applicazioni Web, la classe principale è costituita dalla servlet FacesServlet, la quale allo stesso modo della DispatcherServlet per Spring MVC, agisce da Front Controller per tutte le richieste entranti di tipo JSF. Ovviamente va configurata nel file web.xml dell applicazione: <servlet> <servlet-name>facesservlet</servlet-name> <servlet-class>javax.faces.webapp.facesservlet</servlet-class> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>facesservlet</servlet-name> <url-pattern>*.jsf</url-pattern> </servlet-mapping> La classe Application è di tipo singleton ed il suo scopo è quello di descrivere interamente la Web application ed in particolare i parametri di quest ultima che sono specificati nel file di configurazione faces-config.xml. In pratica, all avvio dell applicazione, viene eseguita la lettura del file di configurazione facesconfig.xml e tutte le informazioni in esso contenute vengono caricate all interno delle proprietà corrispondenti della classe Application, una classe che implementa il singleton pattern. In questo modo, durante l esecuzione dell applicazione è possibile accedere a queste informazioni ed eventualmente modificarle. Le classi principali che sono legate ad essa e che vengono specificate nel file faces-config.xml sono le seguenti: ActionListener: permette la gestione degli action events; NavigationHandler: gestisce la navigazione fra le pagine sulla base delle navigation-rules e degli outcome; ViewHandler: ha il compito di gestire le fasi di ricostruzione della vista di una pagina da uno stato precedente e di visualizzare una risposta, anche sulla base di dispositivi client di accesso differenti; StateManager: efettua il salvataggio ed il ripristino dello stato dell applicazione fra una richiesta ed un altra; MessageBundle: identifica il file.properties nel quale ci sono tutti i messaggi da visualizzare nell applicazione, sulla base di un certo Locale, permettendo l internazionalizzazione; Lifecycle, PhaseListener: permette la gestione del ciclo di vita di ciascuna richiesta; 32

34 VariableResolver: individua gli oggetti referenziati nelle pagine JSF attraverso l Expression Language. Se tali classi non vengono specificate nel file faces-config.xml, verranno utilizzate quelle di default. In caso contrario, lo sviluppatore ha la possibilità di personalizzare il framework, estendendo queste classi e specificandole nel file di configurazione. Ad esempio Spring dispone della classe org.springframework.web.jsf.delegatingvariableresolver attraverso cui rende disponibili in JSF gli oggetti definiti all interno del suo ApplicationContext, rendendo l integrazione tra i due framework estremamente semplice. Ovviamente lo stesso tipo di operazione può essere eseguita anche per le altre classi. Altre informazioni associate alla classe Application e quindi contenute nel file faces-config.xml, specificano il Renderer Kit di default per la visualizzazione delle pagine e l internazionalizzazione, definendo il Locale di default e tutti quelli supportati. Infine, essa è legata a tutte quelle classi che definiscono gli elementi costitutivi dell applicazione, in particolare: UIComponent: definisce ciascun componente dell interfaccia utente insieme a tutte le sue classi derivate; Validator: che implementa un validatore per i dati di input dell utente; Converter: che permette di eseguire la conversione dei dati; MethodBinding, ValueBinding: associano i componenti ed i loro valori, ai metodi o alle proprietà dei backing beans; La classe FacesContext definisce il contesto dell applicazione, cioè mantiene tutte le informazioni che caratterizzano una richiesta e ciò che riguarda la relativa risposta da generare. Essa può essere modificata in ciascuna fase del ciclo di vita di una richiesta, per garantire che il contesto sia sempre aggiornato. È ovviamente legata alla classe Application, facendo uso del metodo getapplication(). Oltre alle informazioni che riguardano l applicazione, essa è legata anche a tutte quelle classi che si occupano in particolare della fase di rendering e quindi della produzione della risposta per una specifica richiesta. Nella fattispecie tali classi sono: 33

35 UIViewRoot: rappresenta il nodo radice della view che definisce l albero dei componenti (il component-tree) di una certa pagina; RenderKit: è una collezione di istanze della classe Renderer che si occupano di visualizzare i componenti dell interfaccia utente, secondo una certa grafica, in relazione al dispositivo client che viene utilizzato per accedere all applicazione, il linguaggio di markup ed il Locale corrente; ResponseWriter: definisce uno stream attraverso il quale è possibile produrre, direttamente nella pagina di risposta, il codice specifico per la tecnologia di rendering utilizzata (markup HTML, XML eccetera); FacesMessage: è la classe che contiene un singolo messaggio associato ad un componente specifico e che va visualizzato in ogni pagina. Il messaggio in questione può essere ad esempio un messaggio di errore dovuto ad una validazione o conversione errata. Infine, attraverso il metodo getexternalcontext(), è possibile ricavare l istanza della classe ExternalContext, la quale definisce il contesto esterno, ossia tutto ciò che riguarda l ambiente in cui viene eseguita l applicazione. Da questa classe è possibile accedere direttamente a tutte le variabili il cui scope (ambito di visibilità) sia quello di tipo session, request o application e quindi ai parametri ed agli attributi di una richiesta. In pratica permette l accesso ai servizi di basso livello offerti dalle Servlet API. USER INTERFACE COMPONENT MODEL Il framework JSF mette a disposizione una serie di classi relative ai componenti della UI e le corrispondenti interfacce che ne descrivono il comportamento e le funzionalità, oltre al mantenimento dello stato, i riferimenti agli oggetti (backing beans) e la gestione degli eventi. Tali classi possono essere estese, permettendo allo sviluppatore di potenziare i componenti standard, aggiungendovi nuove funzionalità. La classe di base da cui derivano tutte le classi per i componenti standard è UIComponentBase, la quale definisce lo stato ed il comportamento di default di un generico componente ed a sua volta estende la classe UIComponent. Di seguito sono riportate tutte le classi che descrivono i componenti previsti in JSF : UIColumn: generica colonna del componente UIData; UICommand: controllo che può intercettare un action event (es. click del mouse) quando viene attivato; UIData: permette di gestire il binding con una collection di dati per la loro visualizzazione. Tale collection può essere eventualmente definita con un DataModel; UIForm: permette di raggruppare più controlli di una pagina e definire, appunto, un form di invio delle informazioni contenute. E paragonabile al tag <form> dell HTML; 34

36 UIGraphic: immagine da visualizzare in una pagina; UIInput: permette di acquisire un informazione di input dall utente; UIMessage: permette la visualizzazione di un messaggio anche sulla base della localizzazione geografica dell utente (internazionalizzazione); UIMessages: come il precedente, ma permette di visualizzare un gruppo di più messaggi; UIOutput: visualizza un informazione di output in una pagina; UIPanel: permette di raggruppare più componenti secondo un certo layout; UIParameter: usato insieme ad altri componenti per specificare una serie di parametri da passare ad essi; UISelectBoolean: controllo che permette all utente di selezionare un valore booleano; UISelectItem: definisce una singola item di una collection di items; UISelectItems: definisce un insieme di items; UISelectMany: permette all utente di selezionare una o più items da una collection di items; UISelectOne: permette all utente di selezionare una sola item nell ambito di una collection di items a disposizione; UIViewRoot: rappresenta il nodo radice dell albero dei componenti che, secondo una gerarchia, costituiscono una pagina; Le classi suddette, oltre ad estendere la classe base UIComponentBase, implementano anche una serie di interfacce che ne definiscono il comportamento : ActionSource: indica che un componente può intercettare un evento ActionEvent; ValueHolder: indica che un componente può immagazzinare un valore (local value) così come ha la possibilità di accedere al dato corrispondente all interno del Model; EditableValueHolder: estende ValueHolder aggiungendo ulteriori funzionalità ai componenti editabili, tra cui la validazione e l intercettazione di eventi del tipo ValueChange NamingContainer: fa in modo che ciascun componente abbia un identificativo univoco; StateHolder: segnala che un componente ha uno stato che va salvato ad ogni richiesta; In generale, la classe UICommand implementa ActionSource e StateHolder. La classe UIOutput e tutte le classi che la estendono, implementano StateHolder e ValueHolder. La classe UIInput e tutte le classi che la estendono, implementano StateHolder, ValueHolder ed EditableValueHolder. 35

37 Per la realizzazione di un componente personalizzato (Custom Component), è necessario estendere la classe UIComponentBase oppure una delle sue classi derivate in modo da sfruttare le potenzialità di queste ultime ed aggiungerne delle altre. Infine, per poter introdurre un componente all interno di una pagina, è necessario associare ad esso un tag realizzato mediante una classe nota come Tag Handler. Tale classe è, in generale, un estensione della classe UIComponentTag e definisce gli attributi del tag stesso. COMPONENT RENDERING MODEL L architettura dei componenti, messi a disposizione dalla tecnologia JSF prevede che le funzionalità degli stessi, così come lo stato ed il comportamento, vengano definite con le classi e le interfacce precedentemente viste, mentre la visualizzazione (rendering), venga realizzata mediante altre classi specifiche note come renderer. Questa separazione comporta i seguenti vantaggi : coloro che scrivono i componenti (Component writers) possono definire una sola volta il comportamento di un componente, mediate un unica classe, ma possono permetterne diverse visualizzazioni, mediante molteplici renderers, in relazione ai tanti dispositivi client che possono accedere alla Web application; coloro che realizzano le pagine (Page authors) e coloro che sviluppano l applicazione (Application developers) possono scegliere la grafica di un certo componente, utilizzando un tag che individui la giusta combinazione fra la classe del componente stesso ed il renderer appropriato; Un Renderer Kit definisce una mappatura fra le classi dei componenti ed i tag che permettono di inserire questi ultimi nella UI, anche in base al dispositivo client di accesso alla Web application. Le varie implementazioni di JSF, forniscono un Renderer Kit standard per i client HTML, il quale permette di inserire i componenti della UI all interno di una pagina JSP attraverso opportuni tag. La classe Renderer permette di definire un renderer associato ad un componente. Essa converte la rappresentazione interna di un componente in una rappresentazione grafica, attraverso uno stream di output sulla pagina. Mediante la realizzazione di una o più classi che estendono la classe Renderer, si possono realizzare diversi renderers che cambiano la modalità di visualizzazione dello stesso componente in base alle necessità o al dispositivo client di accesso. Ad esempio, un componente della classe UISelectOne ha tre renderers associati: il primo che visualizza il componete come un insieme di radio buttons, il secondo come una combo box e l ultimo come una list box. Il comportamento 36