MokaByte 82 - Febbraio 2004 
Sviluppare applicazioni J2EE con Jakarta Struts
II parte: nozioni fondamentali su Jakarta Struts
di
Alfredo Larotonda
Nel precedente articolo della serie abbiamo introdotto il concetto di framework per collocare nel giusto ambito la discussione su Jakarta Struts. In questo secondo articolo andiamo invece ad introdurre i concetti fondamentali per la comprensione di Struts: la sua architettura, gli elementi di base che la compongono ed il loro ruolo. Per una migliore comprensione dell'articolo si pressupone una conoscenza almeno di base dei componenti fondamentali della J2EE quali servlet e JSP

Il pattern MVC (Model-View-Controller)
Jakarta Struts è un MVC web application framework, ovvero è un framework per lo sviluppo di applicazioni web J2EE basato sul pattern Model-View-Controller. Per chiarire meglio questa definizione introduciamo brevemente il pattern MVC.
Uno dei principali requisiti di qualsiasi applicazione web è quello di definire un modello applicativo che consenta di disaccoppiare i diversi componenti dell'applicazione in base al loro ruolo nell'architettura per ottenere vantaggi in termini di riusabilità e manutenibilità.
Esempio tipico di questo problema è l'utilizzo nello sviluppo di una applicazione web J2EE del modello applicativo che nella letteratura è spesso indicato come "JSP Model 1". In base a questo modello l'applicazione è costruita secondo una logica "JSP centric" in base alla quale presentation , control e business logic dell'applicazione sono tutti a carico delle pagine JSP. Il web browser accede direttamente alle pagine JSP dell'applicazione che al loro interno contengono logica applicativa e logica di controllo del flusso; all'interno delle pagine JSP sono cablati i riferimenti alle viste successive in base alla logica di flusso dell'applicazione che è codificata all'interno della pagina stessa. In questo modello non esiste un controllo centralizzato del flusso ma ogni vista si fa carico della selezione delle viste ad essa collegate. Un modello di questo tipo , come suggerito dalla stessa Sun, va evitato se non per lo sviluppo di piccoli prototipi o applicazioni molto semplici e dal flusso elaborativo praticamente statico, in quanto porta a scrivere applicazioni difficilmente gestibili al crescere della complessità e non riusabili nei suoi componenti.

Quando l'applicazione cresce in complessità non è pensabile svilupparla seguendo un simile approccio. Il pattern MVC è una implementazione di quello che va sotto il nome di "Model 2"; il Model 2 introduce il concetto di controllo centralizzato dell'applicazione, implementato da una servlet di controllo che gestisce tutte le richieste e le soddisfa delegando l'elaborazione a opportune classi Java.
In questo modello i ruoli di presentation, control e business logic vengono affidati a componenti diversi e sono tra di loro disaccoppiati, con evidenti vantaggi in termini di riusabilità, manutenibilità, estensibilità e modularità..
In un'applicazione costruita secondo il pattern MVC si possono quindi individuare tre livelli logici ben distinti che molto schematicamente svolgono i seguenti compiti:

  • Controller: determina il modo in cui l'applicazione risponde agli input dell'utente. Esamina le richieste dei client, estrae i parametri della richiesta e li convalida, si interfaccia con lo strato di business logic dell'applicazione. Sceglie la successiva vista da fornire all'utente al termine dell'elaborazione.
  • Model: contiene i dati visualizzati dalle viste; è ciò che viene elaborato e successivamente presentato all'utente.
  • View: visualizza all'utente i dati contenuti nel model. E' la rappresentazione dello stato corrente del Model.

L'implementazione di Struts del design pattern MVC
Come già detto Struts è un MVC web application framework, ovvero è un insieme di classi ed interfacce che costituiscono l'infrastruttura per costruire web application J2EE conformi al design pattern MVC.
I componenti fondamentali di struts sono:

  • ActionServlet: e' la servlet di controllo centralizzata che gestisce tutte le richieste dell'applicazione.
  • struts- config.xml E' il file XML di configurazione di tutta l'applicazione. In questo file vengono definiti gli elementi dell'applicazione e le loro associazioni.
  • Action: le Action sono le classi alle quali la ActionServlet delega l'elaborazione della richiesta.
  • ActionMapping: contiene gli oggetti associati ad una Action nello struts-config.xml come ad esempio gli ActionForward.
  • ActionForm: gli ActionForm sono classi contenitori di dati. Vengono popolati automaticamente dal framework con i dati contenuti nelle request http.
  • ActionForward: contengono i path ai quali la servlet di Struts inoltra il flusso elaborativo in base alla logica dell'applicazione.
  • Custom-tags: Struts fornisce una serie di librerie di tag per assolvere a molti dei più comuni compiti delle pagine JSP.

La ActionServlet è la servlet di controllo di Struts. Gestisce tutte le richieste client e smista il flusso applicativo in base alla logica configurata. Si potrebbe definire come la 'spina dorsale' di una applicazione costruita su Struts. Tutta la configurazione dell'applicazione è contenuta nello struts-config.xml. Questo file XML viene letto in fase di start-up dell'applicazione dalla ActionServlet e definisce le associazioni tra i vari elementi di Struts. Nello struts-config.xml sono ad esempio definite le associazioni tra i path delle richieste http e le classi Action associate alla richieste stesse.
Le associazioni tra le Action e gli ActionForm, che vengono automaticamente popolati dal framework con i dati della richiesta ad essi associata e passati in input alla Action.
Contiene inoltre l'associazione tra la Action e le ActionForward , ovvero i path configurati nello struts-config.xml ai quali la ActionServlet redirigerà il flusso applicativo al termine della elaborazione della Action.



Figura 1 - Implementazione di Struts del pattern MVC


Nella figura 1 è rappresentato schematicamente il flusso elaborativo nella logica di Struts:

  1. Il client invia una richiesta http (1)
  2. La richiesta viene ricevuta dalla servlet di Struts che provvede a popolare l'ActionForm associato alla richiesta con i dati della request (2) e l'ActionMapping con gli oggetti relativi alla Action associata alla richiesta (4) . Tutti i dati di configurazione sono stati letti in fase di start-up dell'applicazione (0) dal file XML struts-config.xml.
  3. La ActionServlet delega l'elaborazione della richiesta alla Action associata al path della richiesta (3) passandole in input request e response http e l'ActionForm e l'ActionMapping precedentemente valorizzati.
  4. La Action si interfaccia con lo strato di business che implementa la logica applicativa. Al termine dell'elaborazione restituisce alla ActionServlet un ActionForward (6) contenente l'informazione del path della vista da fornire all'utente.
  5. La ActionServlet esegue il forward alla vista specificata nell'ActionForward (7).

Ovviamente il flusso di operazioni elencato non è completo ma fornisce una indicazione di base su come viene gestito il flusso elaborativo in una applicazione sviluppata con Struts. Anche se il flusso descritto può apparire complesso, è in realtà di comprensione piuttosto semplice. Negli prossimi articoli forniremo degli esempi di quanto descritto che chiariranno la descrizione teorica fornita.

 

Caratteristiche di base di Jakarta Struts
Dalla discussione dei precedenti paragrafi possiamo quindi individuare alcune caratteristiche peculiari di Struts, che sono poi comuni anche ad altri MVC framework.

  • Esiste una sola servlet di controllo centralizzata. Tutte le richieste sono mappate sulla ActionServlet nel web.xml dell'applicazione. Ciò consente di avere un unico punto di gestione del flusso applicativo e quindi permette di implementare in modo univoco e centralizzato funzioni quali sicurezza, logging, filtri etc.
  • Le viste dell'applicazione non contengono al loro interno il riferimento al flusso dell'applicazione e non contengono logica applicativa. I livelli logici dell'applicazione sono disaccoppiati.
  • Le viste sono identificate con nomi logici definiti nel file di configurazione struts-config.xml. Nel codice Java non è presente alcun riferimento a nomi di pagine JSP il che rende molto più semplice variare il flusso applicativo.
  • Tutta la configurazione dell'applicazione è scritta esternamente in un file XML il che consente di modificare le associazioni tra le richieste http e le classi ad essa associate in modo molto semplice.

C'è da osservare che tutti i componenti di Struts descritti nel paragrafo precedente fanno parte del livello di controllo tranne i custom-tags che fanno parte della view.
Le stesse Action che sono le classi alle quali la ActionServlet delega l'elaborazione delle richieste sono componenti del controller e non del model.
Ciò per sottolineare che Struts è un framework model-neutral, ovvero che implementa esclusivamente i livelli di controller e view.
Utilizzando Struts è possibile realizzare il livello di business logic in base alle proprie scelte; con semplici classi Java quindi implementando la logica applicativa nel web-container, o ricorrendo agli EJB quindi sfruttando i servizi del EJB-container.

 

Principali vantaggi nell'uso di Jakarta Struts
Questa discussione introduttiva su Struts non può ovviamente evidenziarne tutti gli aspetti né essere considerata come una trattazione esaustiva del framework, per la quale sarebbe necessario molto più spazio.
Da quanto esposto però si possono già evidenziare alcune delle caratteristiche di una applicazione sviluppata con Jakarta Struts e alcuni vantaggi conseguenti al suo utilizzo:

  • Modularità e Riusabilità
    I diversi ruoli dell'applicazione sono affidati a diversi componenti. Ciò consente di sviluppare codice modulare e più facilmente riutilizzabile.
  • Manutenibilità
    L'applicazione è costiuita da livelli logici ben distinti. Una modifica in uno dei livelli non comporta modifiche negli altri. Ad esempio una modifica ad una pagina JSP non ha impatto sulla logica di controllo o sulla logica di business, cosa che avveniva nel JSP Model 1.
  • Rapidità di sviluppo
    A differenza di quanto avveniva utilizzando il JSP Model 1, è possibile sviluppare in parallelo le varie parti dell'applicazione, view (JSP/HTML) e logica di business (Java) sfruttando al meglio le conoscenze dei componenti del team di sviluppo. Si possono utilizzare sviluppatori meno esperti e anche con poche conoscenze di Java per la realizzazione delle view, permettendo agli sviluppatori Java più esperti di concentrarsi sulla realizzazione della business logic.

 

Conclusioni
In questo articolo abbiamo esaminato la struttura di base di Struts allo scopo di fornire una visione su quello che significa realizzare una applicazione con Jakarta Struts e sui vantaggi che ne conseguono. Molte delle funzionalità offerte da Jakarta Struts non sono state neanche accennate per ovvi motivi di spazio anche se sono molto importanti per una più completa valutazione del framework. Nei prossimi articoli inizieremo ad entrare in dettaglio e a descrivere più da vicino con esempi pratici i vari elementi che compongono Jakarta Struts.

 

Bibliografia
[1] Chuck Cavaness - "Programming Jakarta Struts", O'Reilly, 2003
[2] Rod Johnson - "J2EE Design and Development", Wrox, 2002
[3] James Goodwill, Richard Hightower - Professional Jakarta Struts" - Wrox 2004


Alfredo Larotonda, laureato in Ingegneria Elettronica, lavora da diversi anni nel settore IT. Dal 1999 si occupa di Java ed in particolare dello sviluppo di applicazioni web J2EE. Dopo diverse esperienze di disegno e sviluppo ora si occupa in particolare di aspetti architetturali per progetti rivolti al mercato finanziario ed industriale. E' Web Component Developer certificato SUN per la piattaforma J2EE e Programmer per la piattaforma Java.

MokaByte® è un marchio registrato da MokaByte s.r.l. 
Java®, Jini® e tutti i nomi derivati sono marchi registrati da Sun Microsystems.
Tutti i diritti riservati. E' vietata la riproduzione anche parziale.
Per comunicazioni inviare una mail a info@mokabyte.it