Il flusso di lavoro nelle JSP e Servlets

Abstract
In questo articolo illustriamo l'architettura delle JSP e delle servlet, concentrandoci sui flussi di esecuzione (workflow) definiti dalla specifica J2EE, nel contesto delle applicazioni web distribuite

Cosa è un WORKFLOW

Nell'ambito delle tecnologie per l'impresa parlare di WORKFLOW voleva dire essenzialmente riferirsi ad una famiglia di prodotti che mirano ad una forte automazione dei processi aziendali. L' organismo di riferimento per il workflow management, la WfMC (Workflow Management Coalition), definisce, infatti, un workflow come "l'automazione di un processo di business, in tutto o in parte, durante la quale documenti, informazioni o compiti, sono passati da un partecipante ad un altro per azioni, in accordo ad un insieme di regole procedurali." Il punto d'unione tra questa realtà e J2EE (Java 2 Platform, Enterprise Edition) è avvenuta inizialmente sul concetto di framework di componenti permettendo la realizzazione di motori per l'esecuzione di workflow o di semplici componenti d'integrazione verso prodotti preesistenti. La commistione tra Workflow e J2EE viene oggi a subire un'ulteriore spinta dalla nascita dei WEB SERVICES: la doppia funzionalità di integratori e nuovo macro strato architetturale rende i web services, e le loro future evoluzioni, un importante bridge tra due tecnologie oramai indispensabili nelle realtà aziendali. Nel mondo J2EE è possibile ancora parlare di workflow secondo un'accezione differente, maggiormente legata all'idea di FLUSSO DI LAVORO.

Architettura J2EE e WORKFLOW

Il paradigma M.V.C. (Model View Controller) è l'elemento architetturale base nel mondo J2EE: promuovendo una netta separazione tra logica ed elementi di business, logica ed elementi di presentazione nonché persistenza, la piattaforma della SUN permette la creazione di applicazioni distribuite scalabili, robuste e performanti.
La distinzione in ruoli e responsabilità implica, però, canali di comunicazione tra gli elementi architetturali, in prima istanza, e tra i Component Object in fase di deploy.
Parleremo allora di suddivisione dei compiti tra le componenti al fine di soddisfare i differenti workflow necessari al nostro applicativo.

Servlet, JSP, JavaBean

Le Web Application trovano in J2EE un completo supporto espresso da apposite web component: le Servlet e le Java Server Pages.
Le Servlet nascono prima delle JSP e vengono concepite come elemento programmativo che esegue lato server in base ad un paradigma request-response: una servlet riceve una data richiesta da parte del web client e, dopo alcune elaborazioni, ritorna una risposta, costruita dinamicamente grazie anche ai risultati precedentemente ottenuti.
La nascita delle Java Server Page arricchisce il panorama della piattaforma J2EE fornendola di elementi presentation-oriented di più facile gestione ed estensibilità (Tag Libraries e Filters). Entrambe le due tipologie di web component possiedono dei meccanismi di interazione secondo due principali politiche:

1. Forward. In questo caso il controllo del flusso esecutivo viene passato dall'elemento chiamante (chi invoca il forwarding) al chiamato (elemento ricevente l'azione di forwarding): grazie a questo meccanismo è quindi possibile ottenere il chaining delle elaborazioni di Servlet e JSP;
   

   Figura 1

2. Include. Il flusso esecutivo rimane di competenza del chiamante che però include nella sua elaborazione quella ottenuta dal chiamato.
   

   Figura 2

L' adozione di un sistema di collaborazione o di un altro non è una scelta esclusiva e questo fornisce flessibilità nelle comunicazioni Servlet-Servlet, JSP-Servlet.
Un ulteriore elemento di comunicazione tra web component sono i JavaBean che esprimono il concetto di componente nel mondo Java Standard Edition (J2SE). Questi elementi, anche se programmativamente sono delle normali classi Java, trovano supporto diretto sia nelle Servlet che nelle JSP, per le quali sono previste apposite azioni di controllo su eventuali JavaBean presenti.
Le componenti non enterprise possono svolgere tre ruoli fondamentali nell'ottica di interazione con web component:

• contenitori di dati da condividere;
• classi helper di supporto alle elaborazioni
• delle Servlet o JSP;
• ospitare logiche di controllo o propriamente di business.

La suddivisione di compiti emersa in questa discussione porta ad individuare modelli di collaborazione tra componenti web e non, capaci di adattarsi a logiche di presentazione e validazione in maniera flessibile ed efficace. Il paradigma M.V.C. risulta nuovamente come matrice comune ai molteplici modelli deducibili. Possiamo, allora, pensare a controller espressi da servlet, view gestite grazie alle JSP e modelli di dati, o elementi di bridging verso oggetti di business, estrinsecati da appositi JavaBean. L' architettura tipo può complicarsi in suddivisioni stratificate per i diversi ruoli, portandoci a distinguere, ad esempio, tra Front Controller (Servlet principale) e Application Controller (Servlet secondarie).
È possibile ugualmente concepire collaborazioni tra JSP, dove azioni di include portano ad una forte dinamicità delle presentazioni. I JavaBean possono fornire meccanismi intelligenti di caching o di wrapping di elementi cruciali, aumentandone anche la significatività, come nel caso di Session Object.
Un ulteriore grado di flessibilità è stato introdotto con XML: possibilità di facili configurazioni, portabilità e nuovi standard correlati (XSL e XSLT) aumentano le possibilità di disegno e realizzazione.
La migliore architettura da adottare dipenderà, allora, da quanto emerso in fase di analisi: dallo studio dei casi d'uso e dai diagrammi di robustezza sarà possibile individuare i differenti workflow specifici dell'applicativo e attuare un mapping con gli elementi a disposizione.

Session Bean, Message Driven Bean ed Entity Bean

I componenti distribuiti della piattaforma J2EE, comunemente conosciuti come EJB (Enterprise Java Bean), dopo una rapida evoluzione, hanno raggiunto la maturità necessaria per la creazione di uno strato middleware omogeneo ed efficace. Analizzando le linee guida proposte dalla SUN emerge in primo piano che l'interazione tra componenti è guidata da Session Bean, principalmente stateless, al fine di ottimizzare gli accessi, ed anche il design, con approcci derivati da strategie standard come nel caso dei pattern FACTORY, PROXY e FACADE. L' azione svolta dai Session Bean non si limita al disaccoppiamento tra la visione del client e le implementazioni distribuite: questi componenti svolgono anche il ruolo di collante o di coordinatori dei workflow che interessano diversi business object, secondo design riassunti in opportuni pattern. I Session Bean hanno una semantica ben precisa che propone questa tipologia di EJB come principale, anche se limitata, rappresentazione del concetto di servizio. Quanto esposto continua a valere in contesti transazionali ed evidenzia le ulteriori possibilità di coordinamento e disaccoppiamento svolta, sulle transazioni, da parte di questi componenti.
Le nuove specifiche (EJB 2.0) introducono elementi interessanti come i Message Driven Bean (MDB) e le LOCAL API, sicuramente una risposta alle richieste del mercato, che hanno già portato alla revisione dei precedenti design ed a nuove possibilità d'interazione e suddivisione delle responsabilità tra gli EJB.
La nuova tipologia di enterprise bean rafforza le possibilità di creare applicazioni debolmente accoppiate appoggiandosi al servizio di messaging di Java (JMS), proponendo quindi soluzioni asincrone grazie alle quali attuare computazioni parallele ed aumentare il throughput generale dell'applicazione. Le nuove specifiche vanno ad interessare anche la gestione della persistenza e il mapping con i DB: nuovo supporto al concetto di dependent object e nuove possibilità nelle interdipendenze tra entity bean che comprendono, tra l'altro, un linguaggio di query che permette una programmazione dichiarativa delle relazione tra gli elementi persistenti. In questa realtà, i Java Bean nuovamente si propongono come helper permettendo scambi di dati tra componenti (Value Object), rappresentando business process o attuando logiche di controllo (Action Object), consentendo l'accesso agli elementi lato server da parte del front-end o la formattazione dei messaggi.

Conclusioni

La gestione dei diversi flussi di lavoro all'interno di un'applicazione distribuita è sicuramente un'attività non facile che richiede uno studio ed un'analisi attenti. La piattaforma J2EE offre, come visto, supporto completo ai designer che possono determinare le collaborazioni più opportune per la realizzazione dei workflow.
La presenza di framework commerciali semplifica ulteriormente lo sforzo di progettazione permettendo di astrarre sensibilmente dagli aspetti implementativi; ancora di più, la tecnologia dei WEB SERVICE spinge verso CASE TOOL potenti, essenzialmente visuali, che cercano di ricondurre l'ossatura progettuale dell'applicativo nelle mani dei soggetti (business analyst) più strettamente correlati alle specifiche problematiche di business.

Informazioni sull'autore

Stefano Fago, classe 1973. Diplomato in ragioneria, ha conseguito il Diploma di Laurea in Informatica con un progetto legato alle interfacce grafiche soft-realtime in Java. Dopo esperienze in Alcatel ed Elea, ha svolto attività di consulenza come Software Developer e Trainer alla ObjectWay S.p.A. sede di Milano. Attualmente Software Designer presso la sezione Innovazione e Attività Progettuali di BPU Banca. Appassionato del linguaggio Java e di tutte le tecnolgie Object Oriented. Polistrumentista dilettante.

È possibile consultare l'elenco degli articoli scritti da Stefano Fago.

Altri articoli sul tema Web / JSP e Servlets.