POLITECNICO DI TORINO - elite.polito.itelite.polito.it/files/thesis/fulltext/vesco.pdf · Livello...

POLITECNICO DI TORINO III Facoltà di Ingegneria

Corso di Laurea in Ingegneria Informatica

TESI DI LAUREA

Architetture Web basate su Enterprise JavaBeans

in ambiente Open Source

Relatori Ing. Fulvio Corno Ing. Maurizio Rebaudengo

Candidato Federico Vesco

Novembre 2001

i

SOMMARIO

INTRODUZIONE ..................................................................................... 10 CARATTERISTICHE GENERALI DI UN’APPLICAZIONE WEB ....................... 12

Livello Client ....................................................................................... 12 Livello Presentazione .......................................................................... 13 Livello Applicazione............................................................................ 14 Livello Dati .......................................................................................... 15

SCOPO DELLA TESI.................................................................................... 15

APPLICAZIONI WEB............................................................................. 17 ARCHITETTURA J2EE............................................................................... 18 COMPONENTI J2EE .................................................................................. 20

Client component................................................................................. 20 Web Component .................................................................................. 21 Business Component ........................................................................... 22

CONTENITORI ........................................................................................... 23 DESCRITTORI E FILE.................................................................................. 24 SVILUPPO DI UN’APPLICAZIONE J2EE...................................................... 25 CONSIDERAZIONI SULL’UTILIZZO DELLA TECNOLOGIA J2EE .................. 25

ENTERPRISE JAVABEANS.................................................................. 27 CARATTERISTICHE DEGLI EJB ................................................................. 28 SESSION BEAN.......................................................................................... 32 ENTITY BEAN ........................................................................................... 34 MESSAGE-DRIVEN BEAN.......................................................................... 37

SESSION BEAN: UNO SGUARDO PIU’ APPROFONDITO ........... 38 SESSION BEAN.......................................................................................... 38 UN SEMPLICE ESEMPIO: IL SESSION BEAN HELLO .................................... 39

Codifica dell’interfaccia remota......................................................... 39 Codifica della home interface............................................................. 40 Codifica del session bean.................................................................... 40 Codifica del client ............................................................................... 41

CONSIDERAZIONI...................................................................................... 42

ENTITY BEAN: UNO SGUARDO PIU’ APPROFONDITO............. 44 ENTITY BEAN ........................................................................................... 44 UN SEMPLICE ESEMPIO: EJB CUSTOMER ACCOUNT................................ 45

Codifica dell’interfaccia remota......................................................... 45 Codifica della home interface............................................................. 46 Codifica dell’entity bean ..................................................................... 46

CONSIDERAZIONI...................................................................................... 53

ii

CONTAINER MANAGED PERSISTENCE ENTITY BEAN............................... 54

APPLICAZIONI OPEN SOURCE......................................................... 56 LA FILOSOFIA OPEN SOURCE ................................................................... 56 JBOSS ....................................................................................................... 58

Caratteristiche di JBoss ...................................................................... 59 Configurazione di JBoss ..................................................................... 61

APACHE .................................................................................................... 64 JAKARTA-TOMCAT................................................................................... 65 POSTGRESQL........................................................................................... 66

L’APPLICAZIONE JDPLANNER ........................................................ 68 NOZIONI FONDAMENTALI DI PROJECT MANAGEMENT............................. 69 L’APPLICAZIONE JDPLANNER – CARATTERISTICHE GENERALI ............... 70 DESCRIZIONE DELLA STRUTTURA DATI .................................................... 73 FUNZIONAMENTO DI JDPLANNER ............................................................ 75

Funzione di Login................................................................................ 75 Accesso al Menu Principale................................................................ 77 Area Disponibilità ............................................................................... 78 Area Consuntivazione ......................................................................... 80 Area Creazione Progetti ..................................................................... 82 Creazione nuovi utenti ........................................................................ 88

CONCLUSIONI ........................................................................................ 90

JAVA WEB START.................................................................................. 94 JAVA WEBSTART ..................................................................................... 94

Caratteristiche di Java Web Start....................................................... 95 La tecnologia di Java Web Start......................................................... 96

CONSIDERAZIONI FINALI SU JAVA WEB START...................................... 100

iii

RINGRAZIAMENTI

E’ mio desiderio ringraziare tutte le persone che mi hanno supportato ed

aiutato sia durante lo svolgimento di questa tesi e che per tutti i cinque anni

trascorsi al Politecnico di Torino.

Per primi ringrazio i miei genitori ai quali dedico il mio titolo di studio come

simbolico risarcimento per tutte le preoccupazioni e sacrifici che ho loro

arrecato durante il periodo degli studi.

Il mio relatore Ing. Fulvio Corno, per avermi pazientemente ascoltato e

consigliato nella stesura della tesi.

La società TRIM S.n.c., nelle figure dei 3 soci fondatori ed in particolare

quella di Ing. Lorenzo Bazzani, per avermi costantemente seguito ed aiutato a

superare tutte le difficoltà presentatesi durante lo svolgimento della tesi.

Grazie di cuore.

iv

A nonno Beppe,

spero che da lassù tu possa condividere parte della mia felicità per questo momento

v

GLOSSARIO

Application client container. Contenitore che gestisce il ciclo di vita dei componenti lato client

Applicazione distribuita. Applicazione composta da componenti distinti eseguiti in ambienti di runtime

Applicazione J2EE. Una qualsiasi unità eseguibile all’interno dell’architettura J2EE

Applicazione web. Applicazione scritta per Intenet; esempi sono le applicazioni scritte utilizzando la tecnologia jsp, asp, cgi, perl

Attivazione. Processo con cui si trasferisce un enterprise bean dalla memoria di massa a quella primaria

Bean Managed Persistence (BMP). Trasferimento dei valori delle variabili tra un un entity bean e il database controllato dall’entity bean

Business logic. Codice che implementa le funzionalità di una applicazione. Nel modello Enterprise JavaBeans, questa logica è implementata nei metodi degli enterprise bean

Business method. Metodo di un enterprise bean che implementa la business logic di una applicazione

Ciclo di vita. Insieme degli eventi che caratterizzano i vari stati in cui può trovarsi un componente. Ogni evento definisce una transizione dallo stato presente ad un nuovo stato, che può anche coincidere con quello di partenza

Commit. Punto di una transazione in cui tutte le modifiche apportate alle risorse impiegate nella transazione sono rese permanenti

Componente. Unità software applicativa gestista da un contenitore.Un componente viene completamente configurato al momento del deploy

Componente web. Un componente che fornisce servizi in seguito all’invio di cete richieste; nella tecnologia J2EE è implementato da un servlet o da una pagina jsp

Contratto di un componente. E’ il contratto stabilito tra un componente ed il suo contenitore. Esso include la gestione del ciclo di vita del componente,

vi

un’interfaccia usata dal componente per ottenere informazioni e servizi dal contenitore, un elenco di servizi che ogni contenitore deve fornire ai componenti che controlla

Contenitore. Entità che gestisce il ciclo di vita, la sicurezza, il deploy e i servizi runtime dei componenti. Ogni tipo di contenitore fornisce servizi specifici per i componenti che controlla. Un contenitore può essere di tipo EJB,web,jsp,servlet,applet e application client

Container Managed Persistence (CMP). Trasferimento dei dati tra le variabili di un entità bean e il database controllato dal container

Create. Metodo definito nella home interface ed invocato dal client per creare un enterprise bean

Deploy. Il processo col quale un componente software viene inserito in un ambiente operativo

Deployment descriptor. File XML associato ad ogni modulo che descrive come deve avvenire il deploy dello stesso. Questo file è utilizzato dallo strumento di deploy per configurare correttamente il modulo seguendo le proprietà specificate

EJB container. Contenitore che implementa il contratto di un componente EJB all’interno dell’architettura J2EE. Un EJB container viene implementato all’interno di un server J2EE

EJB home object. Oggetto che fornisce le operazioni per gestire il ciclo di vita di un enterprise bean. La classe che implementa un EJB home object viene automaticamente generata dallo strumento di deploy. L’EJB home object implementa la home interface dell’enterprise bean cui viene associato. Un client utilizza un riferimento ad un EJB home object (ottenuto localizzando l’home object attraverso JNDI) per gestire la vita di un EJB

EJB object. Oggetto la cui classe implementa l’interfaccia remota dell’enterprise bean. Un client non interagisce mai direttamente con un’istanza di un enterprise bean; esso “parla” sempre con il riferimento che ha ottenuto all’EJB object. La classe che implementa un EJB object è generata automaticamente dallo strumento di deploy

EJB server . Il software che fornisce i servizi per un contenitore EJB

Enterprise bean. Componente che implementa una serie di business method e vive all’interno di un contenitore EJB. Un enterprise bean può essere di tipo session, entità oppure message driver

vii

Enterprise information system. Applicazione che contiene il sistema per gestire i dati dell’impresa

Enterprise bean provider. Programmatore che implementa le classi di un enterprise bean, le sue interfacce e il deplyment descriptor

Enterprise JavaBeans. Architettura a componenti per lo sviluppo ed il deploy di applicazioni aziendali distribuite e object-oriented. Le applicazioni sviluppate con questa architettura sono scalabile, transazionali e sicure

Entity bean. Enterprise bean che rappresenta dati persistenti memorizzati in un database. Un entity bean può gestire la persistenza da solo oppure delegare tale funzione al suo contenitore. Un entity bean è caratterizzato da una chiave primaria. Se il contenitore in cui il bean vive va in crash, l’entity bean sopravvive mantendo il valore di tutte le sue variabili

Finder method. Metodo definito nella home interface ed invocato dal client per individuare un determinato entity bean

Home interface. Una delle due interfacce di un enterprise bean. Essa definisce zero o più metodi per controllare un enterprise bean; in particolare dichiara i metodi create e remove per un session bean, i metodi create, remove e i finder method per un entity bean

J2EE server. Software che fornisce i contenitori EJB e quelli web

Java 2 Platform Enterprise Edition. Ambiente per sviluppare ed effettuare il deply di applicazioni enterprise. Una piattaforma J2EE consiste di un insieme di servizi, API e protocolli che forniscono una serie di funzionalità per sviluppare applicazioni web multilivello

Java Bean. Classe java caratterizzata da un insieme di metodi che può essere instanziata ed utilizzata all’interno di applicazioni

Java Naming and Directory Interface (JNDI). API che fornisce funzionalità per localizzare componenti distribuite all’interno dell’architettura J2EE

JavaServer Pages. Tecnologia web che utilizza linguaggi di scripting, elementi specifici, oggetti java per creare pagine web dinamiche in base a dati o scelte effettuate dal client

JDBC. API che realizza la connessione verso un database, indipendentemente dal suo tipo

viii

Message-driven bean. Enterprise bean che gestisce messaggi in maniera asincrona. Non ha stato; può essere paragonato ad un ascoltatore del linguaggio java, tuttavia anziché eventi ascolta messaggi

Messaggio. In J2EE è una richiesta asincrona o un evento che è creato, spedito e utilizzato da un’applicazione enterprise

Modulo. Unità software che conrsiste in uno o più componenti J2EE all’interno dello stesso contenitore e da un deployment descriptor

Passivazione. Processo con cui si trasferisce un enterprise bean dalla memoria principale a quella secondaria

Persistenza. Protocollo per trasferire lo stato di un entità bean tra le sue variabili di istanza e il database

Remote interface. Una delle due interfacce di un enterprise bean.Definisce tutti i business method che possono essere invocati dal client

Remove. Metodo definito nella home inteface ed invocato dal client per distruggere un enterprise bean

Remote Method Invocation (RMI). Tecnologia che permette ad un oggetto che è eseguito su una Java Virtual Machine di invocare il metodo di un oggetto eseguito su una differente Java Virtual Machine

Rollback. Punto di una transazione in cui tutte le modifiche alle risorse coinvolte nella stessa vengono annullate

Servlet. Programma java che estende le funzionalità di un web server, generando contenuti dinamici ed interagendo con client web

Session bean. Enterprise bean creato dal client che esiste solo per la durata di una singola sessione. Il suo stato non è recuperabile in caso di crash del container che lo ospita

SQL (Structured Query Language). Linguaggio standard per definire e modificare database relazionali

Stateful session bean. Session bean con uno stato conversazionale

Stateless session bean. Session bean senza stato conversazionale. Tutte le istanze di uno stateless session bean sono identiche

ix

Transazione. Unità atomica di lavoro che modifica dei dati. Composta da una o più operazioni, che al termine della transazione sono o tutte rese persistenti (istruzione di commit) oppure sono tutte annullate (istruzione di rollback)

Transazione bean-managed. Transazione i cui limiti sono definiti da un enterprise bean

Transazione container managed. Una transazione i cui limiti sono definiti dal contenitore EJB

XML (Extensible Markup Language). Linguaggio basato su tag che permette di definire tag personali per identificare contenuti, dati, testo all’interno di documenti XML

Capitolo 1 INTRODUZIONE

10

C a p i t o l o 1

INTRODUZIONE

La nascita di nuovi modelli di business legati al fenomeno della New

Economy ha determinato l’esigenza di nuove soluzioni e nuove metodologie

di programmazione che spesso sono indicate con l’espressione Enterprise o

Business Computing, in italiano applicazioni enterprise (applicazioni che

accedono a sorgenti di dati persistenti in ambito distribuito).

Per questi motivi, sin dalla metà degli anni ’90 si è assistito all’evoluzione delle

architetture usate per sviluppare applicazioni web, che sono passate dal

classico schema client-server a nuovi modelli di sviluppo multi livello.

In una architettura a due livelli, il programma client (primo livello) interagisce

direttamente con il livello server (secondo livello), tipicamente un archivio di

dati.

Sui client deve essere presente sia il software di gestione dell’interfaccia utente,

sia quello (librerie e driver) con cui accedere al livello server. Programmare a

due livelli comporta quindi l’installazione (o il download via rete),

l’aggiornamento e la manutenzione di software specifico sulle macchine client.

Le moderne applicazioni enterprise sono invece sono basate su architetture a

quattro livelli , come rappresentato in figura 1-1:

• Livello client , che visualizza le pagine Web • Middle-tier, a sua volta composto da:

• Livello presentazione: ha il compito di generare le pagine web, includendo informazioni dinamiche generate in base alle scelte effettuate dal client

• Livello applicazione: contiene la logica che interpreta ed elabora i dati passati dal client

• Livello dati: rappresenta la sorgente dei dati.


11

Il vantaggio principale di questo tipo di architettura è che non è necessario

installare nessun tipo di software (driver, librerie) sul client, che sarà

indipendente dalle problematiche di accesso al livello archivio dati. In questo

modo è possibile progettare client “leggeri” (thin): il fatto che la logica di

elaborazione risieda nel livello applicazione significa ancora che le operazioni

di aggiornamento e manutenzione non comportano modifiche sulle

postazioni client.

Figura 1-1 Architettura di una moderna applicazione Web


12

Caratteristiche generali di un’applicazione Web Livello Client Il livello client di un’applicazione web rappresenta l’interfaccia utente

dell’applicazione e si occupa di acquisire i dati e visualizzare risultati; è

implementato attraverso il browser web presente sul client (nella maggioranza

dei casi il client dell’applicazione risulta essere un semplice desktop). Esistono

due tipi di approccio per implementare questo livello:

• HTML client: con questa soluzione tutta l’intelligenza dell’applicazione si trova nel middle-tier. Quando l’utente invia le pagine web, tutte le procedure di validazione sono fatte nel middle-tier ed eventuali errori vengono comunicati all’utente con l’invio di nuove pagine web generate dinamicamente

• Client “semi-intelligenti” basati su HTML dinamico: con questo approccio parte dell’intelligenza viene inclusa nella pagina web che viene interpretata dal client, attraverso linguaggi di scripting (es: JavaScript). Per esempio, il client può effettuare alcune semplici validazioni , come assicurarsi che tutti i campi obbligatori di un form siano stati completati, oppure verificare che campi numerici contengano effettivamente dei numeri; inoltre il client può includere nelle richieste inviate anche elementi HTML dinamici, come ad esempio campi nascosti

L’utilizzo di client “semplici” tende ad essere evitato per vari motivi: ad

esempio permette all’utente di inviare (intenzionalmente o non) input errati

verso i livelli successivi , causando così un incremento del traffico di rete per

la semplice gestione degli errori. Il vantaggio di questo tipo di client è che essi

sono implementabili anche nelle versioni più vecchie dei browser (che devono

semplicemente interpretare codice HTML). Questo approccio permette

inoltre di separare nettamente la business logic dal semplice livello di

presentazione.

Al contrario i client “semi-intelligenti” uniscono in parte i due livelli,

permettendo però una riduzione delle comunicazioni col server. Questi client

richiedono versioni più aggiornate dai browser (almeno Internet Explorer 4 o


13

Netscape 4 o superiori). Tuttavia poiché queste versioni sono disponibili da

più di tre anni, è possibile ritenere questa una richiesta non troppo “onerosa”.

Lo sviluppo di applicazioni web, che hanno di fatto sostituito le applicazioni

stand-alone, ha fatto sorgere un altro problema di progettazione a livello

client: in molti casi è infatti necessario poter disporre di un client che non invii

solamente dati da elaborare verso gli altri livelli, ma di un’interfaccia di

amministrazione vera e propria, che permetta alle persone autorizzate di

svolgere questi compiti sfruttando il vantaggio offerto dalla disponibilità di

accedere a queste applicazioni ovunque sia possibile connettersi alla rete (un

esempio può essere quello dei rappresentanti, in continuo movimento, che

necessitano di dover spesso accedere ai dati dell’azienda ed effettuare

modifiche a ordini e commissioni). Questi motivi hanno fatto sorgere nuove

tecnologie per l’implementazione di client sempre più “intelligenti” : tra quelle

proposte la più utilizzata è JavaWebStart, che permette di eseguire vere e

proprie applicazioni attraverso il web browser. Questa tecnologia sarà

presentata con maggior dettaglio nei prossimi capitoli.

Livello Presentazione Questo livello genera pagine web dinamiche in base ai dati forniti in input dal

client che vengono opportunamente interpretati e passati al livello

applicazione. I contenuti dinamici generalmente sono creati grazie a

informazioni ottenute da database.

Il livello presentazione può essere implementato in vari modi: fino a pochi

anni fa le applicazioni web utilizzavano i CGI (Common Gateway Interface

programs). Negli ultimi anni invece sono nate nuove tecnologie che

permettono di inserire più facilmente contenuti dinamici dentro parti di

codice HTML statico e di interpretare le pagine web inviate dal client. Le

applicazioni moderne utilizzano generalmente:

• ASP (Active Server Pages), tecnologia fornita da Microsoft oppure


14

• la tecnologia offerta da java attraverso una combinazione di Servlet e di Java Server Pages

• linguaggi di scripting, tra i quali il più diffuso è sicuramente il PHP

Il livello presentazione è di solito implementato all’interno di un Web Server

(come Microsoft IIS, Apache WebServer, IBM Websphere), che è in grado di

gestire automaticamente richieste provenienti sia da client intelligenti che da

pagine web statiche, indirizzando in maniera opportuna l’elaborazione della

risposta verso il client.

Livello Applicazione Rappresenta il “cuore” di un’applicazione Web in quanto contiene la business

logic (per questo è conosciuto anche come Business Logic Layer), ovvero la

logica applicativa che interpreta ed elabora i dati forniti in input dai livelli

precedenti. Questo livello è costituito da un application server (come

Microsoft MTS, Oracle Application Server, IBM Websphere, JBoss), che

mette a disposizione una serie di servizi (ambiente transazionale, gestione

dello stato, persistenza, sicurezza, comunicazione con DBMS e applicazioni

legacy). In questo modo il programmatore deve solo occuparsi della logica

dell’applicazione, senza dover gestire gli aspetti più “bassi” e spesso più

difficili da affrontare.

Nelle applicazioni web moderne questo livello è implementato utilizzando

due soluzioni concorrenti:

• .NET framework di Microsoft, un’evoluzione dell’architettura DNA, basato sugli oggetti COM+

• J2EE, la tecnologia proposta da Sun basata sugli Enterprise Java Beans.

Mentre nel caso di .NET si può parlare di un vero e proprio prodotto

commerciale proprietario, per la proposta di Sun bisogna sottolineare che

J2EE è una collezione di specifiche, elaborate da Sun assieme a più di 30


15

partner commerciali, che ha portato alla definizione di uno standard, la cui

implementazione è affidata ad ogni singolo venditore.

Per implementare le regole business specifiche di una applicazione entrambe

le soluzioni adottano una metodologia di progettazione basata sullo sviluppo

software a componenti (in inglese componentware): tale tecnologia presenta

alcune innovazioni rispetto alla tradizionale programmazione orientata agli

oggetti. In particolare essa sfrutta ampiamente il riuso del codice per lo

sviluppo di componenti comuni a molte applicazioni (un esempio può essere

il carrello della spesa ricorrente in molti contesti); lavorando a componenti, è

possibile usare buona parte del codice già scritto per altre applicazioni,

adattandolo con poche modifiche al contesto specifico richiesto. Questo

modo di lavorare comporta notevoli vantaggi in fase di progettazione,

sviluppo e manutenzione del software e permette di ridurre notevolmente il

time to market.

Livello Dati E’ il livello responsabile della gestione dei dati. In molti casi questo livello è

costituito semplicemente da un moderno database relazionale. Tuttavia, è

possibile che esso contenga anche procedure per accedere ad altri tipi di dati,

come database gerarchici, sistemi legacy, ecc… Il compito di questo livello è

quello di fornire al livello applicazione i dati necessari per elaborare le risposte

per i client.

Tipici esempi di applicazioni presenti a questo livello sono i server di dati

(DBMS), server di mail, server di documentazione elettronica (DMS,

Document Management System).

Scopo della tesi Attraverso questa tesi sarà mia intenzione porre in evidenza gli aspetti

progettuali fondamentali che devono essere rispettati durante lo sviluppo di

un’applicazione web aziendale basata sulla tecnologia J2EE. In particolare

cercherò di sottolineare tutti gli aspetti positivi di questa architettura, come la


16

sua potenza, la sua flessibilità e la sua portabilità, evidenziando però allo

stesso tempo come l’utilizzo delle tecniche “enterprise” debba essere

applicato solo a quelle situazioni che realmente necessitano di tali

caratteristiche, in quanto la mole e l’organizzazione di lavoro che esse

richiedono possono portare ad effetti indesiderati ed inaccettabili se applicati

in maniera affrettata a progetti che di “enterprise” hanno pochi requisiti e che

possono essere sviluppati attraverso tecniche più semplici e meno dispendiose

dal punto di vista delle risorse di sistema.

Per raggiungere questi obiettivi la tesi verrà sviluppata in due sezioni: nella

prima parte verranno introdotte e descritte in maniera dettagliata, anche

attraverso degli esempi, le caratteristiche dei componenti definiti nelle

specifiche della tecnologia J2EE; nella seconda verrà descritta JDPlanner,

un’applicazione aziendale dimostrativa per la creazione, il controllo e la

verifica di progetti ed attività realizzata durante la mia esperienza maturata

presso la Trim S.n.c., la società informatica presso la quale è stata realizzata la

tesi. In particolare verranno evidenziati quelli che sono stati i passaggi

fondamentali dell’ utilizzo “sul campo” della tecnologia J2EE, dall’analisi dei

requisiti richiesti alla scelta del modo di implementare queste funzionalità,

fino alle difficoltà incontrate nell’ adozione dei componenti J2EE.

Il risultato di questa tesi è stato un’applicazione aziendale piuttosto semplice,

utilizzata dai dipendenti della Trim S.n.c. per organizzare iin maniera più

efficiente il loro lavoro; il valore aggiunto ottenuto è stato invece la

definizione di linee guida per lo sviluppo di applicazioni aziendali e di un

“telaio” di riferimento, utilizzabile come modello per un futuro sviluppo di

applicazioni basate su J2EE.

Capitolo 2 APPLICAZIONI WEB

17

C a p i t o l o 2

APPLICAZIONI WEB

Al giorno d’oggi, nel frenetico e competitivo mondo dell’Information

Technology, uno dei requisiti fondamentali per un’impresa è di sviluppare

applicazioni nel minor tempo possibile, riducendo al tempo stesso i costi e le

risorse necessarie.

Per ottenere tutto questo, è necessario che il middle-tier di un’applicazione

web soddisfi ad una serie di requisiti, che permettono di gestire l’intera

applicazione in maniera più semplice per l’intero team di sviluppo. I requisiti

che ogni tecnologia orientata allo sviluppo di applicazioni web deve

soddisfare sono:

• elevate prestazioni: i server che realizzano i livelli presentazione ed applicazione devono innanzitutto garantire prestazioni elevate, in grado di supportare senza difficoltà un grande numero di richieste provenienti dal livello client. Per realizzare ciò, essi devono offrire le seguenti funzionalità:

• ambiente multithread: questa caratteristica permette di gestire correttamente e senza uno scadimento delle prestazioni accessi concorrenti alle risorse del sistema

• pooling: ovvero una tecnica che permette la gestione comune delle risorse da parte di processi che elaborano richieste provenienti da client differenti; questa tecnica consiste nell’instanziazione di un certo numero di risorse già pronte per essere utilizzate all’arrivo di una richiesta di un client; quando questa è eseguita, la risorsa non viene distrutta ma ritorna ad essere immediatamente disponibile

• gestione dinamica del ciclo di vita degli oggetti • caching delle informazioni statiche, per rispondere più velocemente

alle richieste dei client • meccanismo di comunicazione tra i processi che vengono eseguiti sul

server e che partecipano all’elaborazione di una richiesta del client • bilanciamento del carico: nel middle-tier spesso sono presenti più server

per l’elaborazione delle informazioni. Per questo motivo, la tecnologia usata in questo livello deve essere in grado di suddividere il lavoro in maniera equa tra i vari server, al fine di ottenere un servizio migliore e non sovraccaricare eccessivamente un solo componente


18

• clustering: ovvero replicazione dello stato di un server. Questo requisito è fondamentale in quanto permette di gestire in maniera trasparente per gli altri livelli eventuali malfunzionamenti o improvvisi crash di uno dei server.

• supporto per le transazioni: la possibilità di evitare al programmatore la gestione delle transazioni, affidandola invece al sistema, è uno degli aspetti più interessanti e importanti richiesti ad un’applicazione web

• gestione di sistema semplice: la facilità di utilizzo e di configurazione deve essere ottenuta attraverso:

• riconfigurazione ed aggiornamento dinamici al momento dell’introduzione di nuove risorse

• spegnimento “pulito” in grado di salvare correttamente lo stato e le informazioni di tutti i processi eseguiti sul server

• registrazione (log) e revisione (audit) degli eventi • bassi costi di sviluppo: altro requisito fondamentale richiesto al midlle-tier.

In particolare devono essere soddisfatti i seguenti aspetti • facilità di integrazione con i sistemi informativi pre-esistenti, per

evitare la progettazione ex-novo dell’intero sistema • generazione automatica del codice per la gestione degli aspetti comuni

ad ogni componente • riuso dei componenti

• sicurezza: a causa dell’alto rischio cui sono soggette le informazioni che transitano sulla rete, i livelli presentazione ed applicazione devono fornire strumenti per l’autenticazione e l’autorizzazione all’uso delle risorse del sistema

• servizi di naming e directory: permettono di svincolare le richieste del client dall’effetiva locazione fisica delle risorse. Il client richiede un servizio utilizzando un nome logico, mentre è il server che si preoccupa di individuare la collocazione della risorsa, attivarla ed eseguire la richiesta per conto del client

Architettura J2EE La soluzione proposta da Sun per affrontare questi problemi è la tecnologia

Java 2 Platform Enterprise Edition, comunemente abbreviata in J2EE.

Essa fornisce un modello di sviluppo distribuito e multi-livello, che permette

di gestire con facilità molti aspetti quali la gestione delle transazioni, della

sicurezza e dell’interoperabiltà tra applicazioni. Inoltre, utilizzando il

linguaggio Java, le applicazioni J2EE sviluppate da un’impresa sono platform-

independent, quindi non legate ad alcun prodotto o API particolare,


19

risultando così adatte ad un panorama commerciale il più eterogeneo

possibile.

La tecnologia J2EE si basa su un modello distribuito e multi-livello: i moduli

che compongono un’applicazione J2EE possono essere installati su macchine

differenti. Le specifiche della Sun prevedono che ad ogni livello sia associato

un diverso tipo di componente :

• Client component, che sono eseguiti sul lato client • Web component, eseguiti sui J2EE server • Business component, eseguiti sui J2EE server Essi appartengono a diversi livelli, com'è consuetudine per un’applicazione

distribuita: la figura 2-1 mostra la struttura generale di un’applicazione

sviluppata secondo la tecnologia J2EE. Essa evidenzia anche la presenza di un

quarto livello, chiamato Enterprise Information System tier, che rappresenta il

livello dati: ad esso si interfacciano i componenti business per ottenere le

informazioni necessarie ad eseguire le operazioni richieste dai client. A questo

livello non è prevista la presenza di uno specifico componente.

Figura 2-1 Architettura di un’applicazione J2EE


20

Componenti J2EE Un’applicazione J2EE è basata su componenti, unità di codice autonome che

vengono poi assemblate insieme e comunicano con le altre componenti che

costituiscono l’applicazione. Nei prossimi paragrafi verranno descritte le

caratteristiche generali dei tre diversi tipi di componenti previsti dalle

specifiche J2EE.

Client component Scritti in linguaggio java, i client component possono essere sia web-based

che applicazioni stand-alone.

Nel primo caso essi sono eseguiti all’interno di un browser web e consistono

in pagine HTML statiche o dinamiche scaricate dal server J2EE: le pagine

dinamiche sono generate dal server utilizzando la tecnologia dei servlet o, più

comunemente, quella delle JSP (che permette di includere all’interno di

normali pagine HTML oggetti java e istruzioni); talvolta queste pagine

contengono anche degli applet, ma questa situazione non è molto frequente a

causa delle restrizioni imposte per garantire la sicurezza dell’applicazione.

Le applicazioni stand-alone sono invece eseguite direttamente sulla macchina

del client e sono generalmente utilizzate per svolgere applicazioni di

amministrazione: possono essere eseguite sia tramite riga di comando che

attraverso una interfaccia grafica. Esse a differenza delle componenti web-

based possono colloquiare direttamente con gli enterprise bean.

In entrambi i casi è importante sottolineare come i componenti lato client

siano semplici interfacce verso il server J2EE, dove sono installati i

componenti che eseguono le vere operazioni di logica e di elaborazione: essi

quindi non compiono nessuna operazione complessa, quali accessi a database

o interazioni con applicazioni legacy, ma semplicemente comunicano i dati da

elaborare e ricevono le risposte, come rappresentato in figura 2-2.


21

Figura 2-2 Comunicazioni tra Client components e J2EE Server

Sempre nell’ambito dei client component, è necessario parlare di Java Web

Start, una nuova tecnologia sviluppata da Sun che permette di sviluppare

applicazioni in grado di essere lanciate dall’interno del browser. In questo

modo Java Web Start rappresenta l’anello di congiunzione tra i client web-

based e i client stand-alone, permettendo di sfruttare la facilità di utilizzo dei

primi con la potenza di elaborazione e di presentazione dei secondi. Per

questo motivo, la tecnologia Java Web Start merita una discussione

approfondita e sarà ripresa in dettaglio nell’appendice A.

In questo capitolo procederemo invece a descrivere la struttura globale di

J2EE.

Web Component Scritti in java, i web component risiedono sul server J2EE e possono essere

servlet (classi java che elaborano le richieste provenienti dal client in modo

dinamico) oppure pagine JSP (che permettono di creare pagine dinamiche in

modo più semplice, con la possibilità di inserire oggetti e istruzioni all’interno

delle stesse). Queste ultime posso contenere al loro interno riferimenti a java

bean, per separare in maniera più netta la parte di presentazione di una pagina

(aspetto grafico) dalla eventuale logica presente in essa. Un java bean è

semplicemente una classe java che può essere utilizzata da qualsiasi

applicazione che ne abbia bisogno. Un bean si differenzia da una normale


22

applicazione java in quanto esso non contiene al metodo main, ma una serie

di variabili e di funzioni che possono essere invocate dopo che è stata creata

un’istanza del bean.

Utilizzati per ricevere le richieste provenienti da componenti client web-based

(generalmente dei browser web), essi comunicano con i componenti business

ed elaborano le risposte in maniera che queste siano comprensibili

all’applicazione client, “traducendo” i dati ottenuti in pagine HTML.

Business Component Scritti in java, risiedono sul server J2EE e sono il “cuore” di un’applicazione

J2EE in quanto essi eseguono la business logic dell’intera applicazione, cioè le

procedure di elaborazione dei dati forniti dagli altri componenti.

Nelle specifiche Sun essi sono chiamate Enterprise Java Beans, o più

comunemente EJB.

La figura 2-3 mostra le operazioni compiute da questi componenti.

Figura 2-3 Comunicazioni tra business components e altri componenti

Come si vede dalla figura, oltre ad elaborare i dati ricevuti, gli EJB possono

interagire con componenti legacy oppure accedere a database per effettuare

ricerche o memorizzare i dati ricevuti.


23

Gli EJB possono essere di tre tipi: session bean, entity bean e message driven

bean.

Essi saranno oggetto di studio approfondito, in questo contesto è sufficiente

dire che i session bean possono essere visti come componenti che gestiscono

le comunicazioni con i client, gli entity bean rappresentano i dati presenti in

un database mentre i message driven bean permettono la ricezione asincrona

di messaggi.

Contenitori Tutti i componenti durante la loro esecuzione sono inseriti in un contenitore,

che gestisce il loro ciclo di vita e l’interazione con gli altri componenti.

La figura 2-4 mostra tutti i tipi di contenitori previsti della specifica Sun.

Figura 2-4 Contenitori J2EE

L’application client container è installato sulla macchina del client e gestisce le

interazioni dell’application client con gli altri componenti.

Il browser web è un applet container e anch’esso è installato sul lato client.


24

Un web container risiede sul server J2EE e gestisce l’esecuzione dei web

component, ossia dei servlet e delle pagine JSP che compongono

un’applicazione J2EE.

Un Enterprise JavaBeans Container risiede sul server J2EE e controlla le

operazioni svolte dagli EJB.

E’ fondamentale osservare che prima che ogni componente possa essere

eseguito, esso deve essere associato ad un container opportuno, che ne gestirà

tutto il ciclo di vita.

Durante questo processo, il cui termine inglese deploy viene tradotto in

italiano con l’infelice termine di “messa in campo”, è possibile specificare

delle opzioni tramite un apposito descrittore, proprio di ogni componente: in

questo modo il contenitore riceverà le istruzioni per gestire in maniera

corretta il componente. In particolare tramite il descrittore è possibile

specificare il nome col quale il componente sarà noto agli altri moduli, le

opzioni di sicurezza, le eventuali relazioni con altri componenti per gestire

correttamente gli accessi a database.

Descrittori e file Un’applicazione J2EE e ognuno dei moduli che la compongono possiede un

deployment descriptor, un file XML che descrive le proprietà di ciascun

componente. Tale descrittore permette di differenziare il comportamento di

un componente: dallo stesso codice è possibile ottenere due comportamenti

differenti, semplicemente variando il descrittore associato.

Un’applicazione J2EE è caratterizzata dall’estensione ear, acronimo di

Enterprise Archive. All’interno di questo file ear si trovano poi altri due tipi

di file: jar file, che contengono il descrittore, i file con estensione class ed

eventuali file di supporto dell’application client e i war file, simili ai jar ma

riguardanti servlet o pagine JSP. Occorre sottolineare che questa estensione

non viene in realtà supportata da tutti i Web Application Server presenti sul


25

mercato. Per esempio JBoss utilizza semplicemente i file con estensione jar,

mentre non richiede necessariamente file con estensione war.

Sviluppo di un’applicazione J2EE La suddivisione di una applicazione in vari componenti permette di procedere

allo sviluppo di un progetto secondo un paradigma del tipo “divide-et-

impera”, nel quale è possibile assegnare ruoli differenti ai membri del team: in

questo modo, ci sarà chi si occuperà dello sviluppo della logica applicativa, chi

si concentrerà sulla definizione dei vari aspetti transazionali e di sicurezza, chi

si preoccuperà di configurare i server J2EE per permettere ai componenti di

colloquiare tra loro.

Un team di sviluppo di un’applicazione J2EE è composto dalle seguenti

figure:

• J2EE Product Provider: fornisce l’implementazione di un prodotto aderente alle specifiche J2EE della Sun; può essere ad esempio la casa sviluppatrice di un sistema operativo, di un database, di un application server o di un web server. Fornisce le API e i container opportuni per la gestione dei componenti.

• Tool Provider: fornisce gli strumenti necessari per lo sviluppo e il packaging dei componenti

• Application Component Provider: è l’ addetto all’implementazione della logica dei componenti . Questa figura può essere unica, oppure essere ancora scissa in Client Component Provider, Web Component Provider, Business Component Provider

• Application Assembler: ha il compito di mettere insieme i vari componenti sviluppati dall' application component provider e assemblarli in un file ear.

• Deployer: si preoccupa di gestire l’installazione, la configurazione e l’esecuzione dell’applicazione J2EE, personalizzando con la modifica del deployement descriptor, le varie caratteristiche di una applicazione.

• System Administrator: è il responsabile della configurazione e della amministazione dell’infrastruttura informatica che ospita l’applicazione J2EE.

Considerazioni sull’utilizzo della tecnologia J2EE Considerando l’elevato quantità di risorse di sistema previste dalla specifica

della Sun e il numero di persone coinvolte nello sviluppo, la realizzazione di


26

un’applicazione Enterprise richiede investimenti elevati ed un’ottima capacità

di organizzazione. La decisione di adottare questo modello di sviluppo deve

prendere in considerazione tutti gli aspetti descritti e valutare se le funzionalità

richieste utilizzino effettivamente le risorse offerte da J2EE. Questa

valutazione è molto importante: una volta capite le reali necessità

dell’applicazione che si vuole realizzare, se queste soddisfano ai requisiti

teorizzati da Sun, sarà possibile procedere ad uno sviluppo rapido ed

efficiente dell’applicazione sfruttando tutti i componenti descritti. In caso

contrario, sarà più conveniente adottare altri modelli, che permettono di

implementare le funzionalità desiderate con un impiego minore di risorse

tecniche ed umane.

Capitolo 3 ENTERPRISE JAVABEANS

27

C a p i t o l o 3

ENTERPRISE JAVABEANS

Gli Enterprise JavaBeans (meglio conosciuti con il loro acronimo EJB) sono

componenti lato server scritti in linguaggio java che contengono la business

logic di un’applicazione. La business logic è il codice che implementa le

funzionalità di un’applicazione: si occupa cioè delle operazioni di modifica, di

elaborazione e di memorizzazione dei dati e degli oggetti ricevuti dai

componenti client.

Gli EJB sono la componente fondamentale dell’architettura J2EE ed un loro

studio approfondito permette di capire tutte le potenzialità e le innovazioni

della tecnologia proposta dalla Sun.

Essi risultano di grande importanza per lo sviluppo di applicazioni scalabili e

nelle quali per mantenere l’integrità sia necessario gestire le transazioni e la

sicurezza, evitando che accessi multipli di client violino l’integrità e la

riservatezza dei dati disponibili

Gli EJB hanno almeno 3 caratteristiche che facilitano lo sviluppo di

applicazioni enterprise distribuite:

Figura 3-1: Logo della tecnologia Enterprise Java Beans

• implementando la business logic, svincolano il componente client dallo sviluppo dell’applicazione vera e propria, permettendo al component client provider di focalizzarsi su aspetti più semplici, quali lo sviluppo


28

delle interfacce per l’immissione e l’invio dei dati al server. In questo modo inoltre i client risultano “leggeri” e di facile manutenzione

• l’EJB provider può dedicarsi al solo sviluppo della business logic, in quanto l’EJB container fornisce i servizi di livello sistema quali ad esempio la gestione delle transazioni e della sicurezza.

• gli EJB possono essere utilizzati per più di una applicazione: il fatto di essere portabili è un grande vantaggio per velocizzare i tempi di sviluppo di un'applicazione.

Nei prossimi paragrafi verranno descritti i tre tipi di EJB previsti dalle

specifiche della Sun, evidenziando le loro differenze ed i particolari ambiti di

applicazione in cui devono essere utilizzati. Prima di procedere oltre è però

necessario descrivere le caratterische comuni a tutti gli EJB e capire in che

modo un client può agire su di essi.

Caratteristiche degli EJB Un EJB di qualunque tipo è caratterizzato dalla definizione di due tipi di

interfacce, le quali rappresentano i “punti di contatto” dell’EJB con i

componenti del sistema: esse definiscono i metodi che il client può invocare

presso un determinato EJB e al tempo stesso rappresentano tutto ciò che il

client vede di un EJB. Le interfacce contengono semplicemente le signature dei

metodi offerti dall’EJB, mentre la classe che implementa la logica dei servizi

offerti risulta completamente mascherata al client ;solamente il container può

accedere direttamente a questa classe, e nel farlo esso rispetta quelle proprietà

(tipo di EJB, gestione della persistenza, della sicurezza, delle transazioni)

specificate in fase di configurazione dell’EJB.

Questo approccio rappresenta un notevole vantaggio per lo sviluppo di

applicazioni distribuite: infatti è possibile cambiare completamente la business

logic di un EJB in maniera del tutto trasparente al client , purchè i metodi

definiti nelle interfacce non vedano modificata la loro signature.


29

Figura 3-2 Interazione client-EJB

Le specifiche della Sun prevedono tre tipi di interfacce:

• interfaccia Home: deriva dall’interfaccia javax.ejb.EJBHome ed elenca tutti i metodi che permettono di gestire la vita di un EJB (create,remove,…)

• interfaccia remota: definisce i metodi che l’EJB intende esportare al resto del mondo. Estende l’interfaccia base javax.ejb.EJBObject

• interfaccia locale: definisce gli stessi metodi di quella remota, ma viene utilizzata per consentire l’accesso all’EJB da parte di codice che si trova all’interno dello stesso processo

Le ultime due interfacce descritte mettono in evidenza che un client può

accedere ad un EJB in modo locale oppure remoto. Nel primo caso il client

deve trovarsi sulla stessa Java Virtual Machine dell’EJB che vuole accedere e

deve conoscere la locazione esatta dell’EJB. In caso di accesso remoto il client

(che può essere un componente web, un application client o anche un altro

EJB) può invece trovarsi su di una macchina differente e non deve conoscere

la reale collocazione dell’EJB. La scelta tra i due tipi di accesso è affidata al

bean deployer, tuttavia l’accesso remoto è sicuramente il più utilizzato in

quanto garantisce maggior flessibilità e scalabilità.

Da quanto appena descritto, il client può agire sull’EJB solo invocando i

metodi delle interfacce e mai agendo direttamente su di esso: quando il client

invoca un metodo proprio dell’EJB, è il container che intercetta questa

EJB Container

HomeObject

EJB Object

EJBEJB CLIENT


30

chiamata e si incarica di gestire correttamente tutte le operazioni, dal

passaggio dei parametri fino alla restituzione del risultato.

Quando l’EJB deployer ha finito di scrivere la classe che implementa le

funzionalità desiderate e le interfacce, il passo da compiere per permettere agli

altri componenti di utilizzare l’EJB è effettuare il deploy: questo viene

eseguito dallo strumento di deployment fornito assieme al Web Application

Server. I passi che vengono effettuati per questa operazione sono:

• generazione, a partire dalla home interface, di una classe scheletro (factory class) che la implementa e che provvede ad instanziare, per ogni chiamata del metodo create(), la classe che implementa lo logica del servizio (home object)

• generazione, a partire dalla remote interface e dalla descrizione del comportamento nel file di configurazione, di una classe che agisce da front-end dell’EJB e che funge da metodo di accesso per le chiamate remote (EJB object) (questo avviene nel caso in cui l’EJB sia accessibile in remoto)

• generazione a partire dalla local interface e dalla descrizione del comportamento nel file di configurazione, di una classe che agisce da front-ent dell’EJB per chiamate all’interno del processo (local object) (questo avviene nel caso in cui l’EJB sia accessibile in locale)

• generazione di un archivio compresso che contiene i file generati al punto precedente

• registrazione nel sistema di directory (JNDI , Java Naming and Directory Interface) del nome che il programmatore ha scelto per l’EJB

A questo punto un qualsiasi tipo di client può creare un’istanza dell’EJB ed

ottenere l’esecuzione dei metodi che esso implement . Le figure 3-3 e 3-4

rappresentano i passi che il client deve compiere per creare un EJB e invocare

i suoi metodi..


31

Figura 3-3 Creazione di un EJB

Chiaramente le operazioni descritte nella figura 3-4 possono essere compiute

solo dopo che il client ha ottenuto un riferimento all’EJB mediante

l’operazione create.

Figura 3-4 Invocazione di un metodo dell’EJB

EJB Container

HomeObject

EJB Object

EJB

EJB CLIENT3.Richiesta di creazione

1.LocalizzoHome Object

2.Riferimento aHome Object

JNDI

4.Creazionedi EJBObject

5.Ottengoriferimentto aEJB Object

EJB Container

HomeObject

EJB ObjectEJB

EJB CLIENT

4.Ritorno

2.ServiziMiddleware

Middleware API(transazioni,sicurezza,

persistanze

3.Invocazione delmetodo

1.Chiamata


32

Il punto 2 della figura 3-4 descrive l’utilizzo da parte del container delle API

messe a disposizione dalla specifiche J2EE per la corretta gestione del ciclo di

vita di un EJB.

Session Bean Un session bean rappresenta un singolo client all’interno del server J2EE,

svolgendo per suo conto le operazioni di modifica ed elaborazione dei dati.

Il session bean non è persistente: è legato ad uno specifico client (più client

non possono condividere lo stesso session bean) solamente per la durata della

sessione. Quando questa termina, perché sono state svolte tutte le operazioni

richieste oppure a causa di un malfunzionamento, il session bean non risulta

più associato al client e può nuovamente essere assegnato ad una nuova

richiesta.

I session bean possono essere di due tipi: stateful e stateless (con o senza

stato), che si differenziano per il modo in cui gestiscono lo stato di un

oggetto, ossia i valori delle sue variabili di istanza.

Nel caso dello stateful bean, lo stato è mantenuto per tutta la durata della

sessione oppure per la vita del bean. Questo tipo di bean è utilizzato quando è

necessario mantenere alcune informazioni sul client tra l’invocazione di

metodi successivi.

La figura 3-4 rappresenta il ciclo di vita di uno stateful bean.


33

Figura 3-4 Lyfe cycle di un stateful session bean

Il client gestisce la vita di uno stateful session bean attraverso due soli metodi:

create e remove.

Dopo l’invocazione di questi metodi, è l’EJB container che si occupa della

gestione del bean, invocando metodi che lo fanno passare da uno stato

all’altro e che sono invisibili al client.

La figura mostra i tre stati in cui può trovarsi uno stateful session bean: dopo

la creazione esso si trova nello stato Ready dove il client può invocare i suoi

metodi. In particolari situazioni, come ad esempio in presenza di un numero

troppo elevato di bean in uso oppure dopo che è trascorso un certo tempo

dall’invocazione dell’ultimo metodo, il container può decidere di far passare il

bean nello stato Passive, dove viene temporaneamente spostato in memoria

secondaria e da cui può successivamente essere richiamato mediante

l’invocazione di ejbActivate da parte del container.

Attraverso remove il client informa il container circa la possibilità di rendere il

bean disponibile per la garbage collection, cioè di essere distrutto.


34

A differenza di uno stateful session bean, un stateless session bean viene

utilizzato per svolgere operazioni generiche, non legate a particolari

informazioni del client. Esso non mantiene alcuno stato se non per la durata

dell’invocazione di un metodo da parte del client.

Per questo motivo, il ciclo di vita di uno stateless session bean (figura 3-5) è

composto da due soli stati, in quanto non conservando alcuna informazione

un bean di questo tipo non necessita di trovarsi in uno stato Passive.

Figura 3-5 Lyfe cycle di un stateless session bean

Entity Bean Un entity bean rappresenta dati specifici o collezioni di dati all’interno di un

database.

Un entity bean è persistente, cioè il suo stato viene mantenuto anche dopo la

fine di una sessione oppure dopo il termine del processo all’interno del quale


35

viene eseguito, consente accessi condivisi ai dati che rappresenta (e la gestione

delle transazioni è affidata all’ EJB container), è dotato di una chiave primaria

che gli permette di essere riconosciuto in maniera univoca e può partecipare a

relazioni con altri entity bean.

Per queste proprietà gli entity bean sono utilizzati quando occorre modellare

un’entità eventualmente condivisibile da più client (a differenza dei session

bean che modellano delle procedure) e il cui stato deve essere mantenuto tra

più sessioni.

La persistenza di un entity bean può essere gestita in due modi: la bean-

managed persistence consente all’EJB provider di scrivere codice ad hoc per

implementare le operazioni di acceso al database, mentre con la container-

managed persistance è il contenitore che si preoccupa di questi aspetti. La

sostanziale differenza tra questi due tipi di gestione è che con la persistenza

container-managed il bean non è legato al particolare tipo di database

utilizzato.

Per gestire la persistenza di tipo container-managed è però necessario

informare il contenitore circa le relazioni tra i bean dell’applicazione e questo

è fatto mediante l’abstract schema.

L’abstract schema è una parte del file che descrive un entity bean: il suo

compito è quello di specificare le relazioni tra i bean e definire quali sono i

campi persistenti di un entity bean. Questi ultimi sono gli attributi e le

proprietà che costituiscono lo stato di un bean e per questo motivo sono

anche i campi che vengono salvati nel database che contiene gli entity bean.


36

Come mostrato dalla figura 3-6, il ciclo di vita di un entity bean è interamente

controllato dell’EJB container.

Figura 3-5 Lyfe cycle di un entity bean

Dopo l’instanziazione (attraverso il metodo setEntityContext), il bean si trova

nello stato Pooled, dove tutte le istanze dei bean sono identiche. Solo quando

il client invoca il metodo create (cui segue la chiamata da parte dell’ EJB

container dei metodi ejbCreate e ejbPostCreate) oppure quando è il container

a chiamare direttamente il metodo ejbActivate, il bean acquista una propria

identità e il suo stato viene inizializzato con i dati letti da database. Il passaggio

dallo stato ready a quello pooled è simmetrico, mentre la rimozione dal pool è

gestita dall’ EJB container attraverso il metodo unsetEntityContext


37

Message-driven Bean I message-driven bean permettono ad un’applicazione J2EE di ricevere

messaggi in maniera asincrona.Sono usati quando si desidera che chiamate ad

una componente lato server non siano bloccanti, in modo da non dover

perdere tempo nell’attesa del completamento delle operazioni richieste. Un

message-driven bean può essere paragonato ad un normale listener del

linguaggio java, con la differenza che esso riceve messaggi anziché eventi.

Il ciclo di vita di un message-driven bean (figura 3-6) è composto da due soli

stati: dopo che l’EJB container ha creato un pool di beans attraverso i metodi

setMessageDrivenContext e ejbCreate, questi si trovano nello stato ready

pronti per ricevere e processare messaggi

Figura 3-6 Lyfe cycle di un message-driven bean

Capitolo 4 SESSION BEAN: UNO SGUARDO PIU’ APPROFONDITO

38

C a p i t o l o 4

SESSION BEAN: UNO SGUARDO PIU’ APPROFONDITO

Dopo aver elencato le caratteristiche generali della tecnologia Enterprise Java

Bean, in questo e nel capitolo successivo verranno presentati in maniera più

dettagliata, fornendo dei semplici esempi di realizzazione, i due tipi di EJB

usati, ovvero i session bean e gli entità bean.

Session Bean I session bean sono oggetti lato server invocati da client remoti. Due sono i

ipi di session bean utilizzabili, stateless e stateful.

Gli stateless session bean sono anche detti bean “amorfi” dato che le varie

istanze dello stesso bean sono del tutto equivalenti tra loro, e infatti per

ottimizzare le prestazioni gli application server istanziano un set di bean

stateless che gestiscono mediante tecniche di pooling .Fra tutti i tipi di bean,

questi sono i più semplici e facili da utilizzare.

Gli stateful session bean sono invece in grado di memorizzare uno stato fra

due invocazioni del client, per questo un bean di questo tipo è associato ad

uno e ad un solo client. Tipicamente la gestione dello stato viene effettuata

automaticamente dalla coppia server-container: in questo modo viene

drasticamente ridotto il lavoro che si deve svolgere in fase di sviluppo sia del

client che del bean stesso.

Sempre automaticamente vengono gestite le transazioni per questo tipo di

bean, permettendo anche in questo caso al programmatore di occuparsi

semplicemente della business logic dell’applicazione.

E’ fondamentale ricordare che entrambi i tipi di bean hanno un ciclo di vita

che corrisponde a quello della sessione del client cui sono associati: pertanto


39

essi non sono persistenti e non sono adatti a conservare informazioni tra

sessioni differenti.

I session bean vengono resi pubblici ai client attraverso la definizione di due

interfacce, la EJBHome interface che permette la creazione degli oggetti da

parte del client, e l’interfaccia remota EJBObject che serve invece per

l’invocazione dei metodi veri e propri del bean.

Il client per poter utilizzare un session bean deve compiere tre passi, del tutto

simili a quelli già descritti nella figura 3-3:

• individuare il session bean attraverso JNDI utilizzando il nome pubblico del bean

• creare un’istanza del bean utilizzando l’interfaccia EJBHome • richiamare i metodi del bean pubblicati nell’interfaccia remota, utilizzando

il riferimento ottenuto al passo precedente Oltre alle due interfacce descritte, sarà compito del programmatore

implementare la classe del bean vera e propria, che deve soddisfare ad alcuni

requisiti:

• deve implementare l’interfaccia SessionBean • la classe deve essere dichiarata public • deve implementare uno o più metodi ejbCreate • deve implementare tutti i metodi appartenenti alla business logic del bean • deve contenere un costruttore pubblico senza alcun parametro Nel seguito viene presentato un semplice esempio di session bean (la classica

applicazione HelloWorld) per illustrare meglio i concetti appena esposti

Un semplice esempio: il session bean Hello Codifica dell’interfaccia remota Per prima cosa è necessario implementare l’interfaccia remota che contiene i

metodi della business logic che il client remoto potrà successivamente

invocare:

public interface Hello extends EJBObject {


40

String sayHello() throws RemoteException;

}

Come si può osservare, l’interfaccia remota richiede solamente la definizione

della signature dei metodi appartenenti alla business logic: la loro

implementazione è affidata alla classe che codifica il session bean. In questo

modo è possibile modificare la logica di una applicazione senza la necessità di

modificare il client, purchè il “contratto” stipulato (ossia l’interfaccia remota)

non venga modificato.

Codifica della home interface Il secondo passo è quello di codificare la home interface, la quale deve

contenere i metodi che permettono al client di essere associato a un’istanza

del bean:

public interface HelloHome extends EJBHome {

Hello create(String str) throws RemoteException,CreateException;

}

Dalla signature si vede come il metodo create deve avere come tipo di ritorno

un’istanza dell’interfaccia remota (in questo caso Hello). Anche nell’interfaccia

remota il programmatore deve semplicemente definire la signature del

metodo e non la sua implementazione

Codifica del session bean L’ultimo passo per la creazione del bean è la definizione della classe che

implementa tutti i metodi che gestiscono la vita del bean. In questo caso il

codice è molto semplice e si limita alla semplice definizione del metodo

ejbCreate() e di sayHello() :

public class HelloEJB implements SessionBean {

String str;

public void ejbCreate(String str) {


41

this.str = str

}

public String sayHello() throws RemoteException {

return str;

}

}

Codifica del client L’ultimo passo da compiere consiste nella codifica del client che dovrà

utilizzare il semplice EJB dell’esempio:

public class HelloClient {

public static void main() throws Exception {

Context ic = new InitialContext();

HelloHome home= PortableRemoteObject.narrow

(ic.lookup(“helloapp/Hello”),HelloHome.class);

Hello hr = home.create(“Hello World”);

System.out.println(hr.sayHello());

}

}

Anche in questa occasione il codice riportato è molto semplice e si compone

dei passi descritti in precedenza: dopo aver individuato attraverso JNDI un

riferimento all’oggetto con l’istruzione HelloHome home =

PortableRemoteObject.narrow(ic.lookup (“helloapp/Hello”) ), viene creata

un’istanza del bean e viene invocato il metodo sayHello() dell’interfaccia

remota.


42

Considerazioni L’esempio illustrato è molto semplice, tuttavia è completo e descrive tutte le

procedure necessarie per la scrittura di un session bean: nelle applicazioni reali

l’unica differenza consiste nella complessità e nel numero dei metodi definiti.

E’ da sottolineare che nei session bean, nel caso di scritture su DBMS, è

necessario gestire completamente le procedure di memorizzazione,

effettuando le operazioni di commit e di close.

La distinzione tra stateless bean e stateful bean deve essere specificata nel

descrittore del bean, per permettere all’ application server di gestire in maniera

opportuna il bean.

Nel caso dell’esempio proposto, il descrittore (che può essere ottenuto

attraverso il deploytool fornito dalla Sun nel caso in cui si utilizzi l’application

server della Sun oppure può essere scritto a mano se si usa l’application server

open-source JBoss) risulta:

<?xml version="1.0" encoding="UTF-8"?>

<ejb-jar>

<description>Hello Sample Application</description>

<display-name>Hello EJB</display-name>

<enterprise-beans>

<session>

<ejb-name>Hello</ejb-name>

<home>com.examples.helloapp.HelloHome</home>

<remote>com.example.helloapp.Hello</remote>

<ejb-class>com.example.helloapp.HelloBean </ejbclass>


43

<session-type>Stateless</session-type>

<transaction-type>Bean</transaction-type>

</session>

</enterprise-beans>

</ejb-jar>

La struttura del descrittore risulta molto semplice e abbastanza comprensibile

anche ad una prima lettura. Al suo interno è sufficiente indicare il nome del

bean, il suo tipo e il percorso delle interfacce che realizzano il bean (per

convenzione viene utilizzata una struttura gerarchica, simile a quella degli

indirizzi Internet, nel nostro esempio com.example.helloapp). E’

consuetudine chiamare le varie interfacce utilizzando i postfissi Home e Bean

per la home interface e per la classe del bean rispettivamente, mentre

l’interfaccia remota viene indicata con il nome “puro” dell’ ejb (Hello in

questo caso).

Capitolo 5 ENTITY BEAN: UNO SGUARDO PIU’ APPROFONDITO

44

C a p i t o l o 5

ENTITY BEAN: UNO SGUARDO PIU’ APPROFONDITO

In questo capitolo verranno ripresi alcuni concetti relativi agli entity bean e

presentato un semplice esempio per illustrare come si realizza nella realtà

questo tipo di EJB .

Entity Bean Gli entity bean rappresentano le strutture dati in un server, per questo sono

persistenti e possono sopravvivere ad eventuali crash del sistema; inoltre

gestiscono le transazioni e consentono accessi concorrenti.

Un entity bean viene dunque utilizzato per rappresentare un record presente

in un database oppure un’istanza di un’applicazione esistente (per esempio

un’istanza di un’applicazione che gestisce le operazioni di accredito all’interno

di una banca).

La persistenza di un entity bean può essere gestita sia dal bean stesso ( in

questo caso si parla di Bean Managed Persistence, BMP) oppure dal container

(Container Managed Persistence, CMP).

Un entity bean è caratterizzato da un identificatore univoco, rappresentato

dalla chiave primaria della classe che implementa quel bean: è poi il

contenitore che si occupa di associare dinamicamente le istanze del bean con

il loro identificatore.

Per codificare un entity bean un programmatore deve seguire i seguenti passi:

• definire l’home interface • definire l’interfaccia remota • codificare la classe che rappresenta l’entity bean, definendo la chiave

primaria


45

Un semplice esempio: EJB Customer Account Verrà ora illustrato un semplice esempio di entity bean BMP: questo EJB

rappresenta il conto di un cliente, e dunque si adatta perfettamente alle

specifiche di un entity bean, in quanto rappresenta dei dati che devono essere

persistenti e durevoli nel tempo.

L’identificatore del bean (ovvero la chiave primaria) è semplicemente il nome

del cliente, rappresentato dal tipo String del linguaggio java.

Codifica dell’interfaccia remota L’interfaccia remota riporta le signature dei business method offerti dal bean:

il client utilizzerà questi metodi per interagire con l’ejb. E’ necessario

sottolineare che tutti i metodi presentati devono seguire le regole relative alla

programmazione RMI di java, in particolare tutti i tipi scambiati tra client e

ejb devono essere serializzabili.

L’interfaccia remota deve estendere l’interfaccia javax.ejb.EJBObject.

public interface Account extends EJBObject {

public void debit(double amount) throws

InsufficientBalanceException, RemoteException;

public void credit(double amount) throws RemoteException;

public double getBalance() throws RemoteException;

public void changeName(String name) throws RemoteException;

}

In questo esempio sono quattro i metodi che il client potrà invocare sull’EJB.

In particolare il metodo debit() può lanciare un’eccezione di tipo

InsufficientBalanceException, che non è un’eccezione del linguaggio Java ma

un’eccezione creata appositamente per questa applicazione.


46

Come con i session bean, è consuetudine chiamare l’interfaccia remota con il

nome del bean che verrà specificato nel descrittore, senza alcun postfisso.

Codifica della home interface La home interface permette al client di creare, individuare e distruggere il

bean. Essa deve estendere l’intefaccia javax.ejb.EJBHome. Tutti i metodi

definiti nell’interfaccia devono seguire le regole RMI di java; inoltre la home

interface deve definire tutti i metodi per creare l’EJB e per effettuare ricerche

in base ai campi che identificano il bean (cosiddetti finder method), in

particolare deve necessariamente definire il metodo findByPrimaryKey.

public interface AccountHome extends EJBHome {

public Account create(String ssn, String name) throws CreateException,

RemoteException;

public Account findByPrimaryKey(String ssn) throws FinderException,

RemoteException;

public Account findByName(String name) throws FinderException,

RemoteException

}

Osservando il codice dell’esempio occorre evidenziare come il metodo create

deve restituire il tipo dell’interfaccia remota e che i metodi di ricerca devono

restituire o un’istanza dell’interfaccia remota oppure una Collection di istanze

dell’interfaccia remota (nel caso in cui le ricerche ritornino più risultati)

Codifica dell’entity bean La classe che rappresenta l’entity bean deve implementare l’interfaccia

javax.ejb.EntityBean e deve fornire l’implementazione di tutti i business

method definiti nell’interfaccia remota, dei metodi ejbCreate ed ejbPostCreate

e di tutti i finder method.

public class AccountBean implements EntityBean {

// entity state


47

private String name;

private double balance;

// resources

private java.sql.Connection con;

private EntityContext context;

// business methods

public void debit(double amount) throws

InsufficientBalanceException, RemoteException {

if(balance - amount < 0.0) {

throw new InsufficientBalanceException();

}

balance -= amount;

// …. Other business methods

public String ejbCreate(String ssn, String name) throws CreateException,RemoteException {

try {

// insert record into db

Statement stmt = con.createStatement();

stmt.executeUpdate(“INSERT INTO ACCOUNT …”);

stmt.close();

} catch (SQLException ex) {

throw new CreateException();

}

// initialize state

this.name = name;

this.balance = 0.0;

return ssn; // return primary key

}


48

}

public String ejbFindByPrimaryKey(String ssn) throws FinderException,RemoteException {

try {


ResultSet rs = stmt.executeQuery(“SELECT SSN …”);

if (rs.next()) { // record exists?

stmt.close();

return ssn;

} else {

stmt.close();

return null;

}


throw new FinderException();

}

}

public Enumeration ejbFindByName(String name) throws FinderException,RemoteException {

try {

Vector v = new Vector();


ResultSet rs = stmt.executeQuery(“SELECT SSN …”);

while (rs.next()) {

v.addElement(rs.getString(1));

}

stmt.close();

return v.elements();



49

throw new FinderException();

}

}

public void setEntityContext(EntityContext context) throws RemoteException{

this.context = context;

}

public void unsetEntityContext() throws RemoteException {

// empty implementation

}

public void ejbActivate() throws RemoteException

{

// set up JDBC connection

Properties prop = context.getEnvironment();

String url = prop.getProperty(“url”);

try {

this.con = DriverManager.getConnection(url);


throw new RemoteException();

}

}

public void ejbPassivate() throws RemoteException {

// free JDBC connection

try {

con.close();



}


50

}

public void ejbLoad() throws RemoteException {

// get primary key

String ssn = (String) context.getPrimaryKey();

// retrieve state from DB

try {


ResultSet rs = stmt.executeQuery

(“SELECT … ACCOUNT WHERE SSN = …”);

if (rs.next()) {

name = rs.getString(1);

balance = rs.getDouble(2);

} else {


}



}

}

public void ejbStore() throws RemoteException {

String ssn = (String) context.getPrimaryKey();

try {





51

}

}

}

Si può subito capire come la classe che codifica l’entity bean è la più

complessa e quella che richiede più attenzione al programmatore.

Dopo la definizione di eventuali variabili, è consuetudine inserire i business

method (nell’esempio ne viene riportato solo uno per semplicità).

Ogni business method deve seguire la signature riportata nell’interfaccia

remota, altrimenti al momento del deploy verrà riportato un errore: come

sottolineato altre volte, la signature di un business method rappresenta il

“contratto” che l’ejb e il client stipulano: l’ejb si impegna a fornire le

funzionalità descritte dal metodo mentre il client continuerà a invocare il

metodo passando correttamente i parametri specificati dall’interfaccia.

L’implementazione di un business method può tuttavia essere cambiata

poiché essa non fa parte del “contratto” tra ejb e client.

Successivamente troviamo il metodo (in questo caso è unico ma è possibile

definirne anche più di uno) ejbCreate: esso rispetta la signature dei metodi

create presenti nella Home interface; ejbCreate deve necessariamente

restituire il tipo cui la chiave primaria appartiene (in questo caso String); la sua

logica prevede l’inserimento nel database di un nuovo record, i cui valori sono

quelli passati dal client durante l’invocazione di create; inoltre può inizializzare

le variabili di istanza dell’entity bean.

Un metodo collegato con ejbCreate è ejbPostCreate: esso viene invocato

subito dopo e deve ricevere esattamente gli stessi parametri di ejbCreate.

Spesso è un metodo vuoto poiché tutte le operazioni di inizializzazione sono

effettuate da ejbCreate.


52

I finder method (tutti chiamati ejbFindXXX) rispettano le signature dei finder

method definiti nella Home interface. Il metodo ejbFindByPrimaryKey deve

essere necessariamente implementato.

Questi metodi si occupano di effettuare le interrogazioni al database per

conto del client, svincolandolo così dalla particolare struttura delle tabelle e

aumentando allo stesso tempo la sicurezza,evitando interrogazioni errate

oppure non permesse.

Successivamente troviamo dei metodi propri della gestione del ciclo di vita

dell’entity bean (si veda la figura 3-5) e che il programmatore deve occuparsi

di implementare.

Il metodo setEntityContext serve per permettere al container di gestire il

contesto cui il bean è associato.

Il metodo ejbActivate è utilizzato dal container per associare un’ istanza

dell’EJB con il suo identificatore univoco.

In maniera duale ejbPassivate serve al container per liberare risorse e

permettere di “scollegare” un bean che per diversi motivi non è utilizzato: il

bean viene liberato dalla particolare associazione e gli può essere nuovamente

assegnato un nuovo identificatore.

I metodi ejbLoad e ejbStore servono per sincronizzare le variabili di istanza

con i valori memorizzati sul database.

Infine il metodo ejbRemove elimina dal database l’istanza del bean e rilascia

tutte le risorse allocate durante la chaimata al metodo ejbActivate relativa a

quel bean.


53

Considerazioni La codifica di un entity bean non crea particolari difficoltà, se non il rispetto

di tutte le regole elencate in precedenza ed una corretta implementazione dei

metodi di accesso al database.

Normalmente il programmatore incontra delle difficoltà durante la codifica

del primo entity bean: a partire dai successivi sarà spesso possibile modificare

opportunamente i metodi sviluppati per altri bean e concentrarsi

esclusivamente nell’implementazione dei business methods.

Sicuramente la possibilità di riutilizzare parte del codice scritto per altre

applicazioni rappresenta un notevole vantaggio a favore dell’architettura J2EE

e permette, come auspicato da Sun, di ridurre in maniera drastica il time to

market.

Per quanto riguarda l’esempio proposto, il descrittore dell’entity bean

necessario all’application server per gestire correttamente la vita del bean è

riportato nel seguito:

<?xml version="1.0" encoding="Cp1252"?>

<ejb-jar>

<display-name>Account Bean – Entity Bean Demo</display-name>

<enterprise-beans>

<entity>

<display-name>Account Bean</display-name>

<ejb-name>AccountBean</ejb-name>

<home> com.examples.account. AccountHome</home>

<remote>com.examples.account.Account</remote>

<ejb-class>com.examples.account.AccountBean</ejb-class>


54

<persistence-type>Bean</persistence-type>

<prim-key-class>java.lang.String</prim-key-class>

<reentrant>False</reentrant>

<resource-ref>

<description>DB reference</description>

<res-ref-name>sampleDB</res-ref-name>

<res-type>javax.sql.DataSource</res-type>

<res-auth>Container</res-auth>

</resource-ref>

</entity>

</enterprise-beans>

</ejb-jar>

Il descrittore in parte segue le regole già viste nel precedente capitolo: in più è

necessario specificare il tipo di persistenza (CMP o BMP), la classe cui

appartiene la chiave primaria ed i riferimenti al database utilizzato, attraverso i

tag <resource-ref>.

Il client per accedere all’entity bean non viene riportato in quanto è del tutto

analogo a quello visto per il session bean: i passi da compiere sono gli stessi,

quindi occorrerà individuare il bean attraverso JNDI, ottenere un riferimento

ad un’istanza del bean attraverso i metodi create oppure attraverso i finder

method ed infine invocare i business method offerti dal bean

Container Managed Persistence Entity Bean Con i CMP entity bean, l’accesso al database è gestito automaticamente dal

container e il mapping tra le proprietà di un bean e i campi del database viene

realizzato a “deploy time”, cioè quando il bean viene installato in un

application server. Dal punto di vista dello sviluppo, questo approccio è


55

molto più semplice, ma è anche, per molti aspetti, meno flessibile. Non è

infatti possibile esprimere in questo modo strutture dati e relazioni

particolarmente complesse.

Per questo motivo è necessario che il programmatore valuti accuratamente

quale tipo di persistenza si rende necessaria per l’applicazione che vuole

sviluppare. Spesso se si ha già a disposizione uno schema delle tabelle da

utilizzare e ci si rende conto che esistono relazioni e interrogazioni

particolarmente complesse, allora è preferibile utilizzare degli entity beans

BMP, per superare le limitazioni imposte dalla persistenza container managed.

Nei casi più semplici invece il programmatore dovrà prendere in seria

considerazione la possibilità di utilizzare entity bean CMP, che permettono di

snellire ulteriormente la quantità di codice da scrivere e di sviluppare più

velocemente e con minori difficoltà applicazioni che richiedono accessi a

database, operazioni sempre critiche da gestire correttamente.

Capitolo 6 APPLICAZIONI OPEN SOURCE

56

C a p i t o l o 6

APPLICAZIONI OPEN SOURCE

In questo capitolo verranno brevemente descritti gli applicativi Open Source

utilizzati per lo sviluppo del progetto e la filosofia che sta dietro alla loro

realizzazione

La filosofia Open Source L’applicazione JDPlanner realizzata durante lo svolgimento di questa tesi e

descritta in maniera approfondita nel capitolo 7 è stata sviluppata facendo uso

degli applicativi open source presenti sul mercato che implementano le

funzionalità richieste dalla tecnologia J2EE.

Questa scelta può essere motivata dalle affinità che da sempre esistono tra la

filosofia che sta dietro al modello open source e l’ambiente universitario: in

entrambi i casi lo “spirito guida” è quello della ricerca e del miglioramento dei

vari aspetti che vengono studiati ed affrontati; i risultati che vengono raggiunti

non diventano poi un “patrimonio personale”, ma vengono condivisi e

discussi assieme a persone che si occupano delle stesse problematiche ed allo

stesso tempo possono essere utilizzati come punto di partenza per lo studio di

altre situazioni. Questa filosofia, il cui padre storico è Richard Stallman, che

nel 1970 pubblicò i termini della prima licenza GPL (General Public License),

ha visto accrescere attorno a sé l’interesse di tutto il mondo soprattutto a

partire dagli anni ’90, quando venne sviluppato il sistema operativo Linux, che

in poco tempo uscì dal semplice ambiente universitario per diventare un vero

e proprio concorrente di Microsoft e del suo sistema operativo Windows. Da

allora il fenomeno dell’open source divenne visibile e molte aziende decisero

di adottare questo modello (tra tutte è possibile ricordare Red Hat, che fu una

delle prime software house a rilasciare una distribuzione di Linux).


57

Il modello open source si contrappone al modello proprietario tipico del

mondo commerciale in quanto non teorizza alcun concetto di proprietà: un

software può essere scaricato e installato su un numero qualsiasi di calcolatori

ed utilizzato da un numero altrettanto vario di utenti senza la necessità di

acquistare e registrare le relative licenze. Allo stesso tempo il software open

source viene rilasciato assieme al suo codice sorgente, che può essere

modificato, migliorato o adottato con assoluta libertà da parte di chi lo

utilizza. L’unico vincolo esistente è il veto ad utilizzare software open source

per sviluppare applicativi proprietari.

La possibilità di disporre dei sorgenti di un programma è sempre stata uno

degli aspetti che più hanno aumentato il successo di questa filosofia tra gli

addetti ai lavori: oltre a comprendere il funzionamento dell’applicazione,

chiunque, se interessato, può verificare la qualità e la funzionalità del

programma Gli aspetti negativi del mondo open source consistono

essenzialmente nella mancanza di un reale supporto tecnico e di una garanzia

sui prodotti installati. Questi possono però essere superati ricorrendo alle

numerose mailing list e ai forum di discussione che accompagnano la

distribuzione di ogni prodotto open source: in esse è possibile esporre i propri

problemi e confrontare le proprie opinioni con gli altri utenti del prodotto in

questione. Proprio da queste occasioni di incontro nascono gli spunti per gli

sviluppatori (generalmente sparsi in tutto il mondo) per migliorare le qualità

dei loro prodotti, che in questo modo diventano spesso veri e propri

concorrenti dei costosi programmi proprietari presenti sul mercato.

I prodotti che verranno in seguito descritti sono un ottimo esempio dei

concetti sopra esposti : Apache è probabilmente il web server più utilizzato al

mondo, mentre l’application server JBoss offre prestazioni quasi equivalenti a

quelle dei suoi (costosissimi) concorrenti proprietari.


58

JBoss L’application server per gli EJB è l’elemento fondamentale di tutta la

piattaforma J2EE: questo componente infatti svolge buona parte del lavoro

necessario sia per rendere un componente utilizzabile dai vari client remoti,

sia per supportare i servizi più importanti (transazioni, mantenimento dello

stato, sessioni, sicurezza) associati ai vari EJB.

Figura 6-1: Logo di Jboss, Application Server leader tra i prodotti Open Source

Come si può vedere dalla figura 6-2, molti sono i server disponibili sul

mercato (l’elenco riportato è incompleto, all’indirizzo

http://www.flashline.com/components/appservermatrix.jsp è possibile

osservare una tabella comparativa di tutti gli Application Server attualmente

disponibili): dato infatti che J2EE non è un prodotto ma una specifica, i vari

produttori sono liberi di realizzare la loro implementazione compatibile con le

specifiche rilasciate da Sun.

Quasi tutti gli Application Server hanno licenze proprietarie, i cui costi sono

molto elevati :per fare alcuni esempi, AppServer della Borland costa 12K $

per CPU, WebLogic della BEA 35K $ a CPU.

Non è tuttavia possibile fare una classifica solo in base al prezzo di questi

prodotti, poiché il vero prodotto ideale non esiste: la scelta dipende da vari

fattori, quali ad esempio la scalabilità del progetto da realizzare o la possibilità

di avere un supporto tecnico.

Tra i prodotti Open Source la leadership spetta invece a JBoss, un Application

Server che giorno dopo giorno riscuote sempre maggiore successo tra gli


59

addetti del settore (oltre 40000 download al mese) , sia per il suo costo nullo

che per le performance che offre.

Figura 6-2 Elenco di alcuni application server

Caratteristiche di JBoss JBoss è un J2EE application server open-source (distribuito con licenza

LGPL) scritto interamente in Java e funzionante su qualsiasi piattaforma, *nix

e Windows NT /2000.

La comunità di sviluppatori di JBoss è al momento composta da più di mille

persone e la continua interazione attraverso i forum e le mailing list presenti

sul sito www.jboss.org permette sia ai neofiti che agli sviluppatori

professionali di avere un continuo supporto tecnico.


60

In questo momento la versione stabile di JBoss è la 2.2.2, che implementa

totalmente le specifiche EJB 1.1 e parzialmente quelle 2.0. JBoss supporta

tutti i tipi di EJB (stateless session, stateful session, BMP entity, CMP entity,

message driven).

JBoss fornisce JBossMQ per il messaging JMS, JBossMX per la gestione della

mail, JBossTX per le transazioni, JBossSX per la sicurezza e JBoss CMP per la

Container Managed Persistence.

JBoss non implementa le specifiche per i servlet e le pagine JSP, che sono

tuttavia fornite da altri due progetti open-source concorrenti, Jakarta

Tomcat(più utilizzato) e Jetty : esiste la possibilità di integrare JBoss con

questi prodotti oppure di farli girare in maniera separata.

JBoss si connette senza alcun problema a tutti i database presenti sul mercato,

sia quelli commerciali che quelli open-source (come PostgreSQL).

La figura 6-3 raffigura il possibile scenario di azione del prodotto.

Figura 5-3 Interazione di Jboss


61

Tra i vantaggi di JBoss è possibile elencare, oltre la grande comunità di

sviluppatori, la facilità di installazione (che non modifica né il registry di

Windows né altri meccanismi specifici di configurazione per altre piattaforme,

in quanto tutte le informazioni sono memorizzate in file di testo), la

“leggerezza” (richiede pochi secondi per essere avviato e necessita di appena

128MB di Ram per funzionare fluidamente). Interessante è anche la funzione

di auto-deploy dei bean: copiando semplicemente il file jar nell’apposita

cartella, JBoss si occupa di verificare ed eseguire il deploy dell’applicazione

senza richiedere alcuna interazione da parte dell’utente.

Gli svantaggi di questo prodotto sono pochi: tra questi sicuramente c’è la

mancanza di una documentazione completa, che fa sì che il primo approccio

risluti spesso difficoltoso, e la mancanza di un tool grafico per la creazione dei

jar e la creazione automatica dei file xml (come ad esempio il DeployTool

fornito da Sun): questo richiede allo sviluppatore un certo sforzo per

configurare correttamente il descrittore associato all’applicazione.

Configurazione di JBoss Come affermato nel precedente paragrafo, l’installazione e la configurazione

di JBoss è molto semplice: per prima cosa è ovviamente necessario scaricare al

sito la versione adatta al proprio sistema operativo (per Linux la dimensione

del file è contenuta, 6.4 MB).

Successivamente è necessario impostare la variabile d’ambiente PATH al

valore della directory contente i binari JDK. Quindi occorre creare una

variabile JBOSS_DIST che punti alla directory in cui JBoss verrà installato. A

questo punto si può procedere all’installazione dell’application server,

semplicemente scompattando il file zip che si è scaricato.

D’ora in poi sarà possibile avviare il server spostandosi nella directory bin

dell’installazione ed eseguire lo script di avvio (per Linux run.sh). L’avvio di


62

JBoss avviene automaticamente, in un tempo generalmente compreso tra i 20

e i 30 secondi.

Per poter effettuare il deploy dei bean sviluppati, occorre invece procedere

come segue

• Configurare opportunamente il descrittore associato all’applicazione. JBoss non fornisce un tool grafico per la creazione del file XML, tuttavia dal sito è possibile avere alcuni esempi di descrittori ed adattarli abbastanza facilmente alle proprie necessità. Di seguito è possibile osservare un esempio di descrittore

<?xml version="1.0" encoding="UTF-8"?>

<ejb-jar>

<description> JBoss Interest Sample Application </description>

<display-name>Interest EJB</display-name>

<enterprise-beans>

<session>

<ejb-name>Interest</ejb-name>

<home>org.jboss.docs.interest.InterestHome</home>

<remote>org.jboss.docs.interest.Interest</remote>

<ejb-class>org.jboss.docs.interest.InterestBean</ejbclass>

<session-type>Stateless</session-type>

<transaction-type>Bean</transaction-type>

</session>

</enterprise-beans>

</ejb-jar>


63

Come si può vedere, in esso è sufficiente definire i nomi delle interfacce

implementate e dichiarare il tipo di EJB implementato. Come sempre in caso

di difficoltà è possibile consultare le mailing list sempre aggiornate e ricche di

esaurienti spiegazioni.

• Il descrittore creato al punto precedente deve essere chiamato ejb-jar.xml e deve essere collocato nella director INSTALL_DIR/META-INF

Come terzo passo, occorre creare un file jar che contenga i file che

compongono la nostra applicazione.

• Infine è sufficiente copiare il file jar creato al passo precedente nella directory INSTALL_DIR /deploy di JBoss: sarà l’application server ad occuparsi di effettuare il deploy automatico dei bean sviluppati, informando eventualmente il programmatore con opportuni messaggi di errore o di warning nel caso in cui l’applicazione non rispetti le regole teorizzate da Sun.

Per quanto riguarda l’utilizzo dei database, JBoss supporta tutti i database più

importanti del mercato. Per utilizzare un particolare database, è sufficiente

copiare il driver JDBC del database desiderato nella directory

INSTALL_DIR /lib/ext di JBoss e modificare il file di configurazione

<mbean code=”org.jboss.jdbc.XADataSourceLoader”,

name=”DefaultDomain:service=XADataSource,name=PostgresDB”>

<attribute name="DataSourceClass">

org.opentools.minerva.jdbc.xa.wrapper.XADataSourceImpl</attribute>[JBoss2.2.2]

<attribute name="PoolName">PostgresDS</attribute>

<attribute name="URL"> jdbc:postgresql://host.domain.com/database</attribute>

<attribute name="JDBCUser">username</attribute>

<attribute name="Password">password</attribute></mbean>

Figura 6-4 : esempio di configurazione del database in Jboss


64

La figura 6-5 rappresenta lo schema delle directory che si ottiene dopo

l’installazione di JBoss.

JBoss-structure

binclientconfdbdeploydocsexternaljdplanner

com

META-INF

jdpejb

libext

log

tmpsrc

JBoss-2.2.2

Figura 6-5: struttura directory di JBoss

Apache Apache è l’httpd server open-source più utilizzato del mondo. Aderente alle

specifiche HTTP/1.1 implementa tutti i principali protocolli di rete, è

altamente configurabile e può essere integrato con moduli aggiuntivi scritti

usando l’Apache module API; funziona su tutte le piattaforme più comuni

(Windows NT/9x, Netware,OS/2, molte versioni di Unix, Linux).


65

Il codice di Apache è liberamente disponibile presso www.apache.org e il

prodotto è distribuito sotto licenza Apache Software License.

Figura 6-6 Logo di Apache

Jakarta-Tomcat Tomcat è l’implementazione ufficiale di riferimento per le tecnologie Java

Servlet e JavaServerPages sviluppate da Sun.

Tomcat fa parte del progetto Jakarta, consultabile all’indirizzo

http://jakarta.apache.org, è sviluppato in ambiente open-source e distribuito

con licenza Apache Software License; si integra facilmente con i server Web

Apache, Microsoft IIS e Netscape.

Figura 6-7 Logo di Tomcat

Tomcat risponde alla porta 8080, tuttavia è possibile installare un modulo che

permette di far colloquiare tra loro Apache e Tomcat, indirizzando

opportunamente e in maniera trasparente le richieste di pagine JSP alla porta

8080.

L’installazione di Tomcat è molto semplice e non richiede particolari

conoscenze: sotto Linux è sufficiente scompattare i file forniti sotto la


66

directory principale, settare opportunamente il valore di alcune variabili di

ambiente ed avviare il demone di Tomcat con il comando run.sh dalla

directory INSTALL-DIR/bin.

Come nel caso di ogni altro software open-source, il miglior punto di partenza

per chi è alla ricerca di supporto è il newsgroup specifico. Gli amministratori

di sistema che vogliono accostarsi a Tomcat devono conoscere bene la Java

Virtual Machine corrente, dato che, a differenza di altri server commerciali,

non è presente una console di comando o un modulo di amministrazione

basato su browser. I Webmaster devono invece modificare direttamente i file

xml di configurazione.

In ogni caso si riesce a mettere in funzione il server senza troppa fatica, anche

se, come suggerito dalla documentazione, per ottenere qualunque tipo di

scalabilità e per ottimizzare le prestazioni è necessario modificare i file di

configurazione. Tramite questi gli amministratori possono aggiungere il

supporto di Ssl e impostare altre opzioni di sicurezza (ad esempio, definire le

liste di accesso per le singole servlet).

Tomcat non prevede tool integrati di sviluppo: i programmatori possono

usare il loro ambiente preferito (ad esempio Forte for Java, scaricabile

gratuitamente presso il sito www.sun.com nella versione Community) oppure

affidarsi al compilatore Java a linea di comando fornito da Sun.

L’integrazione con i database avviene utilizzando JDBC.

PostgreSQL PostgreSQL è un DBMS relazionale ad oggetti open-source, che supporta

quasi tutti i costrutti SQL, compresi select annidati, transazioni e funzioni e

tipi definiti dall’utente.

Attualmente è disponibile la versione 7.1.3, liberamente scaricabile presso il

sito www.postgresql.org .


67

L’installazione e la configurazione di questo prodotto è molto semplice e

intuitiva, la documentazione fornita è molto buona e il supporto è fornito

attraverso una serie di forum accessibili presso il sito principale.

Assieme a PostgreSQL è consigliabile utilizzare il modulo di amministrazione

basato su browser phpPgAdmin , scaricabile gratutitamente (assieme ad una

discreta documentazione) presso il sito

http://www.greatbridge.org/project/phppgadmin/projdisplay.php

Figura 6-8 Logo di PostgreSQL

L’architettura di applicazioni J2EE realizzate utilizzando i prodotti appena

descritti è schematizzata in figura 6-9. Il sistema operativo installato è Linux,

“padre” di tutti gli applicativi Open Source

Figura 6-9 Architettura applicazione J2EE Open Source

Capitolo 7 L’APPLICAZIONE JDPLANNER

68

C a p i t o l o 7

L’APPLICAZIONE JDPLANNER

Questa tesi è il frutto della mia esperienza presso la TRIM S.n.c. , una società

di ingegneria informatica nata nel 1999 dall’unione di tre giovani

professionisti dell’ Information Technology che hanno creduto nella forte

espansione delle nuove tecnologie legate ad Internet.

Questa azienda, la cui sede è presso l’ incubatore di imprese del Politecnico di

Torino, offre servizi di consulenza in diversi ambiti tecnologici ed è in grado

di sviluppare applicazioni che sfruttano le più recenti innovazioni che

continuamente mutano il paesaggio dell’ IT: per rispettare questi propositi

TRIM offre la possiblità a studenti del settore dell’Informazione di studiare in

maniera approfondita le ultime tecnologie legate al mondo Internet e al tempo

stesso di effettuare una prima esperienza nel mondo del lavoro.

Lo svolgimento della tesi si è pertanto articolato in due distinti momenti: nel

primo l’enfasi è stata posta sullo studio approfondito della tecnologia J2EE,

con particolare attenzione rivolta verso l’apprendimento di tutti i concetti

necessari per sviluppare in maniera rapida e semplice applicazioni aziendali

scalabili e distribuite. Nel secondo periodo queste conoscenze sono state

sfruttate per sviluppare un’applicazione per i dipendenti della TRIM e allo

stesso tempo utilizzabile come “scheletro” per il progetto di nuove

applicazioni aziendali (uno dei principali vantaggi pubblicizzati da Sun

riguardo alla tecnologia J2EE è infatti la riusabilità del codice).

Al momento di scegliere quale tipo di applicativo sviluppare, la scelta è andata

verso la realizzazione di un software in grado di controllare le metodologie e

gli strumenti del Project Management, un aspetto spesso sottovalutato

durante la stesura delle specifiche e l’organizzazione del lavoro per lo sviluppo

di un progetto.


69

Nozioni fondamentali di Project Management Il Project Management è un approccio organizzativo e metodologico che

considera un progetto come un obiettivo aziendale da raggiungere nei tempi e

nei costi prefissati. I suoi obiettivi principali sono la riduzione dei tempi di

realizzazione di un progetto ed il miglioramento del controllo del flusso del

progetto. Allo stesso tempo, stabilendo delle priorità per le attività e le risorse,

il Project Management permette di ottenere un migliore utilizzo delle stesse,

migliorando il coordinamento e le comunicazioni tra i membri del team di

sviluppo e fornendo periodicamente informazioni dettagliate ed aggiornate

sullo stato del progetto.

Un progetto, “fulcro” attorno al quale si sviluppa tutta la teoria del Project

Management, è caratterizzato da alcune proprietà:

• ha un inizio e una fine • viene realizzato da una specifica organizzazione (chiamata organizzazione

di progetto) • ha un project manager che è responsabile del suo sviluppo • viene definito identificando il punto di partenza, quello di arrivo e

soprattutto il percorso tra i due • ha un budget che deve essere rispettato

Per evidenziare come la gestione corretta di un progetto risulti fondamentale

anche dal punto di vista commerciale, è interessante citare un esempio di

insuccesso di Project Management: il caso Concorde, l’aereo di linea

supersonico famoso per essere il mezzo di trasporto preferito dai manager e

dai vip, in grado di portare i propri passeggeri dall’ Europa agli Stati Uniti in

poco più di tre ore.

Su una previsione di vendite di 250 esemplari, ne furono costruiti solo 16

venduti 12. Il costo per unità previsto era di 6 milioni di dollari, mentre il

costo a consuntivo fu di 100 milioni. Infine, la realizzazione richiese 16 anni,

a fronte dei 7 previsti durante la stesura delle specifiche (dati forniti da uno


70

studio di Bo Lundberg e Andrew Wilson). Questi numeri mettono in

evidenza come un corretto approccio al problema di gestione del progetto

avrebbe potuto evitare che un successo tecnologico si rivelasse un disastro

commerciale.

L’applicazione JDPlanner – caratteristiche generali Tutte le nozioni sopra citate devono essere supportate da un qualsiasi

applicativo di Project Management, in maniera il più possibile trasparente

all’utente, che deve essere “invogliato” a partecipare attivamente ai passi che

portano al corretto flusso di svolgimento del progetto.

Tra i numerosi applicativi presenti sul mercato, il più famoso è sicuramente

Microsoft Project (http://www.microsoft.com/office/project/default.htm),

strumento che è preso come riferimento da tutte le software house che si

interessano di questo campo.

Lungi dal voler paragonare l’applicazione realizzata durante questa tesi con il

prodotto della casa di Richmond, al momento della stesura delle specifiche si

è cercato di “copiare” alcune delle funzionalità più importanti e utilizzate,

adattandole ad un ambiente aziendale distribuito per permettere l’utilizzo del

software anche attraverso Internet, offrendo così la possibiltà di accesso da

una qualsiasi macchina con un collegamento alla Rete.

L’architettura generale dell’applicazione, chiamata JDPlanner (Java

Distributed Planner), è mostrata in figura 7-1: da una sua analisi è possibile

individuare gli obiettivi funzionali che si è cercato di raggiungere utilizzando la

tecnologia J2EE della Sun.

In primo luogo JDPlanner offre un’interfaccia grafica per la creazione,

l’assegnazione, la verifica e la modifica dei progetti e delle attività: l’accesso a

questa sezione è tuttavia riservato alle persone che rivestono la carica di

Project Manager, in particolare i tre soci fondatori della Trim S.n.c.).


71

Le stesse restrizioni di accesso sono riservate alla funzione di inserimento di

nuovi utenti: anche in questo caso l’applicazione stand-alone che realizza

questa operazione è installata solo sulle macchine dei Project Manager.

Tutti gli utenti dotati di un account possono invece accedere alle altre due

funzionalità di JDPlanner: l’area disponibilità e l’area consuntivazione.

Nella prima ogni dipendente può gestire il proprio calendario lavorativo,

indicando per ogni giornata le ore che dedicherà al suo lavoro. Questa sezione

ha un duplice scopo: per l’impiegato quello di poter definire con una certa

libertà il suo carico di lavoro, per il Project Manager conoscere le ore totali

disponibili ed assegnarle opportunamente ai vari progetti.

L’area consuntivazione permette invece ai dipendenti di indicare le ore

effettivamente dedicate alle attività loro assegnate: tale sezione serve

soprattutto per poter stabilire con precisione le ore totali di lavoro dedicate a

ciascun progetto e conseguentemente facilitare la compilazione delle fatturare

da presentare ai clienti.

L’obiettivo principale che si è cercato di raggiungere attraverso JDPlanner è la

semplicità di utilizzo, inteso sia come sviluppo di un’interfaccia intuitiva e di

semplice fruizione, sia come possibiltà di accedere alle funzioni fondamentali

da una qualsiasi macchina dotata di un collegamento a Internet. Quest’ultima

è una specifica fondamentale nell’ambiente della TRIM: una delle maggiori

attività dell’azienda è quella di fornire consulenza tecnologica presso aziende

del campo informatico. Tale situazione comporta per i suoi dipendenti

l’assenza per periodi più o meno lunghi dalla sede centrale, per cui risulta

necessaria la possibilità di comunicare lo stato di avanzamento del lavoro

svolto, la propria disponibilità e la possibilità di effettuare un consuntivo delle

attività assegnate da postazioni differenti, situate nelle aziende cui di volta in

volta si prestano le proprie conoscenze.


72

Figura 7-1 Architettura dell’applicazione JDPlanner

Tra i vari problemi incontrati durante la fase di progettazione del lavoro, è

emersa la necessità di poter effettuare operazioni “complesse” (tipicamente le

funzioni proprie del Project manager) anche attraverso un browser, senza

dover utilizzare applicazioni stand-alone su cui configurare correttamente tutti

i parametri (variabili di ambiente, indirizzi, …). La soluzione trovata per

questo problema è stata quella di implementare le funzioni di amministrazione

attraverso la tecnologia JavaWebStart offerta da Sun e descritta nella

appendice A: essa è un giusto compromesso tra la semplicità di utilizzo

offerta dai browser e le potenzialità tipiche delle applicazioni.

Al contrario, per l’implementazione delle altre funzioni (definizione della

disponibiltà da parte del dipendente, consuntivazione delle ore svolte) si è

ricorso ad una tradizionale interfaccia web.

Sicuramente le funzionalità offerte da JDPlanner sono limitate all’essenziale

oppure non complete quanto quelle degli altri prodotti commerciali, tuttavia


73

la natura Open Source del progetto può permettere a chi è interessato di

utilizzare il codice già scritto per aggiungere nuove funzioni e migliorare

l’aspetto grafico del progetto, che è stato volutamente trascurato per rivolgere

maggiore attenzione agli aspetti tecnologici del lavoro.

Descrizione della struttura dati La figura 7-2 rappresenta lo schema E-R che è stato utilizzato per lo sviluppo

dell’applicazione: da esso si possono immediatamente identificare le figure

chiave e le funzionalità offerte da JDPlanner.

Un progetto viene creato da una risorsa (in questo caso rappresentata da una

persona) ed è composto da un numero variabile di attività. La creazione di un

progetto è permessa solo alle persone che ricoprono il ruolo di Project

Manager.

Una risorsa può essere assegnata a più di una attività; inoltre è suo compito

quello di dichiarare la propria disponibilità (relazione resource-

availability_calendar) ed effettuare sistematicamente una consuntivazione delle

ore effettivamente dedicate alle attività cui è stata assegnata (relazione

resource-consuntivation).

La “traduzione“ di questo schema in tabelle del database relazionale

PostgreSQL è rappresentata in figura 7-3: come si può vedere, le varie

relazioni sono state “mappate” con le relative tabelle; si è inoltre deciso di


74

Figura 7-2 Schema E-R di JDPlanner

“collassare” la relazione progetto-attività in un’unica tabella, adottando la

convenzione che in un progetto i campi idactivity e idproject hanno lo stesso

valore. Questo accorgimento si è reso necessario in quanto meglio

rappresenta la struttura gerarchica con cui sono create le attività.

Figura 7-3 Traduzione dello schema E-R nelle tabelle di PostgreSQL


75

Funzionamento di JDPlanner Nei prossimi paragrafi verranno descritte le funzionalità offerte da JDPlanner,

ponendo enfasi soprattutto sugli aspetti progettuali che hanno richiesto

maggiore impegno e cercando di evidenziare quali sono le lineee guida che

devono essere seguite nella creazione di applicazioni Enterprise distribuite.

Funzione di Login La prima operazione che occorre effettuare quando si accede a JDPlanner è

l’autenticazione: essendo un’applicazione aziendale, il suo utilizzo deve essere

riservato solamente alle persone autorizzate.

Figura 7-4 Funzione di Login- Interazione utente-bean-EJB

Il codice che implementa questa funzione è piuttosto semplice: esso utilizza

un semplice bean (chiamato jdp_login) all’interno della pagina JSP che si

preoccupa di comunicare con l’enterprise java bean e verificare se l’utente è

abilitato ad accedere al menu principale (figura 7-4). L’utilizzo del bean

all’interno della pagina jsp è giustificato dalla volontà di rendere l’applicazione

il più modulare possibile, separando la logica dalla presentazione: con questo


76

approccio, che dovrebbe essere seguito per qualsiasi tipo di applicazione, la

realizzazione del progetto può essere affidata in maniera quasi indipendente a

due persone differenti: un grafico, che deve semplicemente occuparsi

dell’aspetto visivo della pagina, e un bean developer, il quale realizza la logica

vera e propria ed “interferisce” col lavoro del grafico inserendo

semplicemente nella sezione opportuna il codice che realizza le operazioni

desiderate.

L’ EJB che realizza la funzione di login, chiamato WebSessionBean, è uno

stateless session bean: la sua unica funzione è quella di verificare la correttezza

dei dati inseriti, per cui esso non necessita di mantenere lo stato tra chiamate

successive; inoltre implementandolo come stateless ejb, il container di JBoss

crea un pool di questi bean delle dimensioni opportune rispetto alle risorse

attualmente disponibili, ottimizzando così le prestazioni generali.

public interface WebSession extends EJBObject {

public boolean is_logged() throws RemoteException;

public boolean login(String user,String password) throws

SQLException,RemoteException;

public int getId(String user,String password) throws


public boolean getSkill(String user) throws


}

Figura 7-5 L’interfaccia remota di Web Session Bean

Nella figura 7-5 è stata riportata l’interfaccia remota con i metodi “offerti” da

WebSessionBean: la funzione più importante è login, che attraverso una

semplice istruzione SQL select, accede alla base dati per verificare se l’utente è

abilitato o meno, e restituisce una variabile booleana che rappresenta il


77

risultato dell’autenticazione. Le altre funzioni implementate restituiscono

invece il valore delle variabili del bean, senza accedere al database.

Occorre infine sottolineare che lo scope del bean utilizzato è di tipo sessione ed

ogni pagina generata dall’applicazione utilizza un’istanza di questo bean:

pertanto, se un utente tenta di accedere ad una funzione di JDPlanner senza

effettuare il login, l’applicazione, constatando l’assenza di un bean jdp_login

associato all’utente, automaticamente redirige l’utente alla pagina di

autenticazione. Questa tecnica è la più utillizata per evitare accessi non

autorizzati e permette di implementare un elementare controllo di sicurezza

senza dover ricorrere a tecniche più sofisticate.

Accesso al Menu Principale Dopo aver effettuato il login, si accede al menu principale: quest’ultimo è

differenziato a seconda che l’utente sia o meno abilitato alla creazione di

progetti.

Figura 7-6 ScreenShot del menu principale di JDPlanner


78

In caso affermativo, viene presentato un semplice menu in cui sono presenti

tre link a differenti sezioni dell’applicazione: area disponibilità, area

consuntivazione, area creazione progetti. In caso negativo, quest’ultima

opzione non viene visualizzata.

Area Disponibilità Questa sezione permette all’utente di indicare in prima approssimazione il

numero di ore in cui egli sarà disponibile ogni giorno. Attraverso una sorta di

mini-wizard, l’utente è invitato a scegliere il mese e l’anno su cui dichiarare la

propria disponibilità, indicando un numero di ore di default. Al termine di

questi passi gli verrà presentata una pagina in cui dovrà indicare, giorno per

giorno, la propria disponibilità.

Anche in questo caso la logica di comunicazione con l’EJB non è inserita

direttamente all’interno delle pagine di presentazione, ma viene utilizzato un

bean (HTMLMonth.java) che in questo caso ha anche il compito di generare

dinamicamente il codice html da visualizzare in base ai dati inseriti dall’utente.

Lo schema generale di comunicazione è pertanto simile a quello già

presentato nella figura 7-4.

La scelta di utilizzare un mini-wizard per gestire questa funzionalità è

determinata dalla volontà di creare un’interfaccia semplice e intuitiva e allo

stesso tempo impedire che l’utente inserisca dati in modo non corretto.

Nell’ultimo passo del wizard, quando l’utente sceglie di memorizzare i dati

inseriti, il bean HTMLMonth crea un’istanza dell’EJB CalendarStoreBean e

invoca il metodo CalendarStoreDate, che inserisce i dati nel database

PostgreSQL.


79

Figura 7-7 ScreenShot dell’area disponibilità

L’ EJB CalendarStoreBean è un stateful session bean: a differenza della

funzione di login, in questo caso c’è la necessità di mantenere lo stato tra i vari

passi del wizard che portano alla memorizzazione dei dati. Nell’interfaccia

remota è presente un solo metodo, CalendarStoreDate, che effettua la

memorizzazione dei dati.

public interface CalendarStore extends EJBObject {

public boolean calendarStoreDate(int rid,Date day,int nro) throws


}

Figura 7-8 Interfaccia Remota di CalendarStoreBean


80

Area Consuntivazione In questa sezione l’utente dovrà indicare il numero di ore effettivamente

dedicate ad ognuna delle attività cui è stato assegnato. L’area ha un doppio

compito: il primo è di effettuare la consuntivazione relativa al mese corrente

(in questo caso viene richiesto di scegliere tra una delle attività assegnate e di

decidere se effettuare o modificare una consuntivazione relativa ad un singolo

giorno oppure relativa ad un’intera settimana), il secondo è la possibiltà di

ottenere report relativi alle consuntivazioni dei mesi precedenti. Con la

seconda opzione è possibile decidere se visualizzare report relativi ad un

determinato anno oppure se selezionare una singola attività ed ottenere il

totale delle ore ad essa dedicate nel periodo scelto.

Figura 7-9 Screenshot della sezione consuntivazione

La struttura utilizzata per la realizzazione di questa sezione è simile a quella già

utilizzata per la definizione della disponibiltà degli utenti : tale osservazione è

importante per sottolineare come, nello sviluppo di un’applicazione enterprise


81

J2EE sia possibile definire un “telaio” generale su cui costruire, con gli

opportuni adattamenti, le funzionalità richieste dal programma.

Facendo nuovamente riferimento alla figura 7-4, all’interno delle pagine jsp

generate viene utilizzata un’istanza del bean SimpleConsuntivation.java; esso

genera dinamicamente parte del codice html in base ai dati ricevuti dall’utente

e, al momento della memorizzazione, sceglie quali metodi invocare sull’EJB

ConsuntivationBean. Dopo aver creato un’istanza di quest’ultimo

componente, richiama i metodi di inserimento oppure di update dei dati

inseriti a secondo del valore di un campo HTML nascosto, generato

dinamicamente al momento di generare la pagina inviata al client.

La figura 7-10 riporta l’interfaccia remota dell’EJB ConsuntivationBean

utilizzato in questo ambito. A differenza degli EJB descritti precedentemente,

il numero di metodi offerti è maggiore e alcuni di essi, come ad esempio

getSingleReport, restituiscono un oggetto di tipo Collection, il quale contiene i

risultati dell’interrogazione effettuata sul database.

public interface Consuntivation extends EJBObject {

public Collection getAllActivities(Integer idr) throws


public Collection getAssignedActivities(Integer idr,java.sql.Date

start,java.sql.Date end) throws SQLException,RemoteException;

public Collection getAlreadyConsuntivedActivities(Integer idr,Integer

ida,java.sql.Date day)throws SQLException,RemoteException ;

public Collection getSingleReport(Integer idr,Integer ida,java.sql.Date

start,java.sql.Date end)throws SQLException,RemoteException ;

public int InsertStoreConsuntivation(Integer idr,Integer

ida,java.sql.Date day,String activityName,Integer hours,String notes)throws


public int UpdateStoreConsuntivation( Integer idr, Integer ida,

java.sql.Date day,String activityName, Integer hours,String notes) throws



82

public void EndStore(boolean result) throws RemoteException;

public void StartStore() throws RemoteException;

}

Figura 7-10 Interfaccia remota di ConsuntivationBean

In ogni caso, la logica di ognuno di questi metodi è semplice e consiste

nell’implementazione di istruzioni SQL (insert, select o update).

L’EJB usato è di tipo session: con questa scelta è compito del programmatore

gestire correttamente tutte le operazioni di modifica dei dati; se durante una

qualsiasi delle operazioni si verifica un errore e viene scatenata un’eccezione,

sarà necessario invocare un’operazione di rollback sulle istruzioni effettuate ed

informare l’utente del mancato successo dell’operazione. Questo tipo di

approccio (session bean) richiede una maggiore attenzione durante la stesura

del codice, ma ha come vantaggio la possibilità di effettuare interrogazioni

SQL complesse (come ad esempio interrogazioni multiple) che invece non

sarebbero possibili nel caso in cui si decidesse di affidare le operazioni di

manipolaizioni dei dati al container (usando un entity bean container

managed). Inoltre, poiché le operazioni effettuate non richiedono il

mantenimento dello stato, l’utilizzo di un entity bean risulterebbe inefficiente

dal punto di vista dell’occupazione delle risorse del sistema

Area Creazione Progetti L’accesso a quest’area è riservato solamente agli utenti che, nella fase di

creazione del loro account, sono stati esplicitamente abilitati a questa

funzione. Durante lo sviluppo e la stesura delle specifiche, questa è stata

certamente la sezione che ha richiesto maggiore impegno e studio.


83

Innanzitutto, è emersa la necessità di dotare quest’area di una serie di

funzionalità più “evolute” rispetto alle due precedentemente descritte:

l’obiettivo principale era quello di permettere una completa gestione di un

progetto da una qualsiasi macchina collegata ad Internet; ciò ha portato allo

sviluppo di questa area utilizzando la tecnologia JavaWebStart. Rispetto alle

altre due zone è stata così deciso di abbandonare la velocità di accesso e di

veloce utilizzo tipicamente offerta da semplici interfacce web, per ottenere

un’interfaccia del tutto simile a quella di un’applicazione stand alone, più

adatta ad adempiere alle operazioni di amministrazione (Figura 7-11).

Sicuramente quello appena descritto è un problema generale di tutte le

applicazioni enterprise distribuite: esisterà sempre una funzionalità che

necessita di requisiti difficili da implementare semplicemente attraverso il web.

Tipicamente tali difficoltà sorgono per funzioni di amministrazione e per

tutte quelle operazioni che fino a pochi anni fa erano svolte presso terminali

collegati al Centro di Elaborazione Dati, che “governava” le applicazioni

aziendali ed era il corrrispettivo di un web application server moderno.

L’approccio utilizzato con JDPlanner può pertanto essere esteso anche ad

ambiti apparentemente differenti.

La creazione di un progetto e la definizione di tutte le attività che lo

compongono segue una struttura gerarchica: quando vengono definite le date

di inizio e di fine di un progetto, tutte le attività devono rispettare questi limiti,

e questo ragionamento viene applicato recursivamente a tutte le eventuali

sotto-attività. La scelta di questa struttura ha portato alla visualizzazione dei

progetti creati mediante una vista ad albero.


84

Figura 7-11 Struttura logica della sezione Creazione Progetti

Al momento della creazione di un’attività è possibile assegnare ad essa un

budget (interpretabile come numero di ore oppure disponibilità economica) e

definire una attività vincolante: in questo caso l’attività che verrà creata non

potrà cominciare prima della fine della attività cui risulta legata.

Un’altra funzione disponibile è quella di assegnazione di una attività: essa

permette di scegliere tra tutte le risorse disponibili ed assegnare loro parte del

budget totale dell’attività.

L’ultima funzione è quella di Verifca Automatica: essa automaticamente

ottimizza la durata di un progetto, andando ad eliminare tutti gli eventuali

“buchi” tra attività consecutive. Nel fare ciò viene applicata la tecnica di

Schedulazione all’indietro propria del Project Management. La schedulazione

è il procedimento di calcolo delle date di inizio e di fine di ciascuna attività,

del loro avanzamento totale e della durata complessiva del progetto. La

tecnica di schedulazione all’indietro parte dalla data di fine dell’ultima attività

del progetto e risale progressivamente ordinando le attività in base alla loro


85

data di fine, ”compattando” eventualmente attività consecutive (fa cioè in

modo che la data di fine di una attività coincida con quella di inizio

dell’attività ad essa dipendente).

La realizzazione di questa sezione ha richiesto l’utilizzo di 3 EJB differenti:

due di essi sono di tipo stateless session bean (InsertBean e AssignBean), il

terzo è il più importante ed è un entity bean di tipo bean managed.

Il codice che implementa i due session bean è, nella struttura, del tutto simile

a quelli già descritti in precedenza: i metodi riportati nella definizione delle

interfacce remote permettono di effettuare le operazioni di

inserimento,cancellazione ed aggiornamento dei dati inseriti dall’utente.

Al contrario, l’entity bean utilizzato (ActivityBean) ha una struttura differente

e necessita di una spiegazione più dettagliata. La scelta di modellare i progetti

creati attraverso un entity bean è dovuta al fatto che essi devono

rappresentare dati persistenti, accessibili dall’utente anche durante sessioni

differenti, e che quindi necessitano del mantenimento del loro stato anche

quando l’EJB loro associato viene distrutto. Inoltre, poiché un’attività può

essere assegnata a più persone, l’utilizzo di un entity bean permette di affidare

al container (JBoss in questo caso) aspetti critici quali la gestione di accessi

concorrenti ad una stessa attività.

Le figure 7-12 e 7-13 riportano alcuni dei metodi della Home Interface e della

interfaccia remota dell’EJB. Mentre per quanto riguarda quest’ultima i metodi

implementati sono semplici e consistono essenzialmente nella lettura o

modifica degli attributi dell’entity bean, nella Home Interface sono presenti

tutti i metodi di accesso al database (il cui prefisso è comune, findBy). Essi

sono utilizzati per ottenere un entity bean associato al particolare dato che si

vuole leggere o modifcare; in alcuni casi, restituiscono una collezione di

oggetti che rappresentano il risultato di un’istruzione SQL select.


86

public interface Activity extends EJBObject {

public String getactivityName() throws RemoteException;

public Integer getidProject() throws RemoteException;

public Integer getidActivity() throws RemoteException;

public int getBudget() throws RemoteException;

public java.sql.Date getStart() throws RemoteException;

public java.sql.Date getEnd() throws RemoteException;

public int getidConstraint() throws RemoteException;

public int getidFather() throws RemoteException;

public void setStart(java.sql.Date start) throws RemoteException;

public void setEnd(java.sql.Date end) throws RemoteException;

}

Figura 7-12 Interfaccia Remota di ActivityBean

public interface ActivityHome extends EJBHome {

public Activity create(Integer idproject ,String activityName, intbudget, java.sql.Date start, java.sql.Date end,int father, int constraint,int owner) throws RemoteException, CreateException;

public Activity create(String projectName, int budget, java.sql.Datestart, java.sql.Date end, int owner) throws RemoteException,CreateException;

public Activity findByPrimaryKey(Integer id) throws FinderException,RemoteException;

public Collection findByIdProject(Integer idp) throws FinderException,RemoteException;


87

public Collection findByFather(Integer idfather)throws

FinderException,RemoteException;

. . . . . . . . . . . . . . . . . . . .

}

Figura 7-13 Home Interface di Activity Bean

Per la realizzazione dell’interfaccia utente sono state utilizzate le classi

appartenenti al package Swing di java: si è preferito l’utilizzo di classi Swing

rispetto a quelle del package AWT poiché l’aspetto dei componenti utilizzati è

migliore ed è in grado di adattarsi al sistema operativo utilizzato (Micorosoft

Windows piuttosto che Unix o Macintosh).

Per diminuire il traffico di rete ed il sovraccarico delle risorse dell’application

server è stata utilizzata una struttura dati di appoggio, realizzata mediante la

definizione di una classe privata chiamata MyTree. Al momento della

creazione dell’entity bean e della visualizzazione dei progetti e delle attività

controllate dall’utente, i dati che vengono letti dal database sono memorizzati

all’interno di oggetti della classe MyTree. In questo modo le ricerche

successive avvengono localmente presso il client, mentre solo al momento

della creazione o modifica di nuove attività oppure nel caso dell’assegnazione

delle stesse, viene nuovamente invocata una chiamata remota all’entity bean.

Questa scelta ha sicuramente incrementato il lavoro svolto dal client, tuttavia

è sembrata la più efficiente dal punto di vista delle prestazioni globali

dell’intera applicazione. Occorre però sottolineare come questa soluzione sia

adatta al caso particolare della Trim S.n.c, dove le dimensioni dei progetti

risultano sempre piuttosto contenute e le funzioni di creazione ed inserimento

di nuove attività sono affidate ad uno dei tre soci fondatori; sicuramente

l’adozione di questo approccio all’interno di aziende più grandi potrebbe

creare alcuni problemi: la presenza di progetti molto grandi (caso limite, la


88

gestione della costruzione di un Boeing o di uno Shuttle) richiederebbe un

tempo di trasferimento delle informazioni tra client e server troppo lungo e

con un’occupazione di memoria troppo onerosa per il client; inoltre nel caso

di più persone assegnate alla realizzazione del progetto, potrebbero verificarsi

problemi di sincronizzazione nel caso di ritardi nella memorizzazione sul

server delle modifiche apportate.

Creazione nuovi utenti Per l’inserimento di nuovi utenti è stato deciso di realizzare una semplice

applicazione stand alone, basata su interfaccia grafica realizzata con classi

AWT(figura 7-14).

Figura 7-14 Interazione client-JBoss

Due sono i motivi di questa scelta: in primo luogo, poiché poche persone

hanno questo privilegio e tale operazione non è eseguita molte volte,

l’inserimento di questa funzione nel menu principale avrebbe comportato un


89

overhead non necessario. In secondo luogo, l’utilizzo di un application client

era l’ideale per dimostrare tutte le modalità con cui gli EJB possono essere

utilizzati.

Per implementare questa funzione si è sviluppato un EJB di tipo sessione,

InsertBean, la cui unica funzione esportata è quella di creare un nuovo utente

con i dati passati e restituire come risposta una variabile indicante il successo

o meno dell’operazione.

Capitolo 8 CONCLUSIONI

90

C a p i t o l o 8

CONCLUSIONI

L’applicazione realizzata durante lo svolgimento di questa tesi non deve e non

può essere paragonata ad altri prodotti commerciali presenti sul mercato. La

sua realizzazione è stata intesa come un tentativo di applicare il maggior

numero possibile dei concetti della tecnologia J2EE, verificando “sul campo”

quali sono i problemi, le scelte di progetto, le difficoltà, le limitazioni ed i

vantaggi che un team di sviluppo può incontrare. Il lavoro che deve essere

svolto per sviluppare programmi di questo tipo è comunque molto vasto e,

come già descritto nei capitoli iniziali, è generalmente suddiviso tra più

persone, le cui conoscenze sono tra loro complementari e spesso limitate a

settori specifici della tecnologia. Per questo motivo JDPlanner presenta alcune

inefficienze (prima tra tutte la veste grafica molto scarna) e limitazioni;

tuttavia può essere utilizzato come “architettura pilota” sulla quale costruire in

maniera più curata applicazioni aziendali che sfruttano a pieno le prestazioni

ed i vantaggi offerti dalla tecnologia della Sun.

Dalla sua analisi è infine possibile evidenziare quali sono i passi fondamentali

da seguire per lo sviluppo di applicazioni per la piattaforma J2EE. Il primo

aspetto da considerare è la decisione di quali oggetti implementare attraverso

degli entity bean e quali codificare come semplici session bean; la soluzione da

adottare in generale è di realizzare con degli entity bean solo oggetti business

di alto livello, dotati di un comportamento di apprezzabile complessità e non

limitato alla sola lettura e scrittura delle proprietà di una classe java. Questo

perché gli EJB sono oggetti remoti e dunque le loro invocazioni “scatenano” i

meccanismi tipici delle chiamate remote, con coinvolgimento di tutti gli strati

della rete e l’introduzione di un ritardo nella risposta rispetto ad una chiamata

non remota; questo ritardo potrebbe essere giudicato inaccettabile qualora le

operazioni coinvolte fossero molto semplici come appunto la lettura e

scrittura di proprietà. Per questo motivo gli entity bean devono essere


91

utilizzati per esprimere entità ad alta granularità, tipicamente oggetti

indipendenti che rappresentano il fulcro attorno al quale viene sviluppata

l’intera applicazione (in JDPlanner ad esempio solo le attività vengono

modellate come entity bean). Negli altri casi è preferibile utilizzare session

bean.

Un altro passo da seguire è quello di decidere se utilizzare o meno strutture di

appoggio quando le operazioni da effettuare sono lunghe e complesse: questa

tecnica permette di ridurre in modo considerevole le chiamate remote e

quindi il traffico di rete, con un conseguente miglioramento delle prestazioni

generali dell’applicazione. Nel valutare se adottare o meno questa tecnica

occorre, come già sottolineato nel capitolo 7, valutare attentamente i vantaggi

ottenuti da un’esecuzione locale delle operazioni con le complicazioni che

nascono nel caso in cui la quantità di dati da scambiare e memorizzare

localmente rappresentino una richiesta troppo onerosa per il client, nonché la

gestione corretta dei meccanismi di locking nel caso di accessi concorrenti alle

risorse dell’applicazione ed i relativi problemi di sincronizzazione.

Una terza regola da rispettare consiste nell’individuare sin dalle prime fasi di

progetto quali funzionalità richiedono semplici interfacce web e quali

tecnologie più complesse: questo punto va affrontato con molta attenzione in

quanto l’utilizzo di Java WebStart se da una parte facilita lo svolgimento delle

operazioni, dall’altra richiede tempi di sviluppo maggiori (la progettazione di

interfacce grafiche risulta più lunga dello sviluppo di front-end web based) e

tempi di download maggiori cui segue una diminuzione delle prestazioni.

Infine per quanto riguarda l’accesso agli EJB da parte di client web, è sempre

preferibile evitare di inserire il codice che interagisce con la business logic

direttamente all’interno delle pagine JSP create dinamicamente al livello

presentazione, ma utilizzare dei java bean per “nascondere” queste

operazioni: in questo modo oltre a separare le funzionalità logiche da quelle

grafiche, la manutenzione e l’eventuale modifica della business logic risulta


92

notevolmente più semplice da gestire e del tutto trasparente alle persone non

coinvolte nello sviluppo e nella codifica degli EJB.

Quest’ultima osservazione evidenzia anche la necessità di organizzare in

maniera accurata l’intero lavoro tra i vari componenti del team di sviluppo;

senza dover ricorrere a tutte le figure professionali descritte nel capitolo 2, per

una migliore realizzazione di un’applicazione J2EE occorrono almeno 3

sviluppatori: un addetto alla grafica, le cui conoscenze informatiche possono

essere limitate ai soli programmi di publishing (come Paint Shop Pro oppure

Macromedia Dreamweaver), una persona esperta di tecnologia JSP ed una il

cui compito principale è la codifica ed installazione degli EJB. Per le ultime

due figure professionali sono richieste un’ottima conoscenza del linguaggio

java e, soprattutto per il EJB developer, una buona padronanza delle modalità di

programmazione e manutenzione di database. Inoltre queste due persone

devono essere dotate di una buona capacità di collaborazione, per poter

individuare assieme quali funzionalità implementare attraverso gli EJB e

definire correttamente le signature dei metodi che verranno richiamati.

Per lo sviluppo e la verifica del corretto funzionamento degli EJB risulta

conveniente utilizzare semplici client rappresentati da applicazioni stand-alone

che si limitano alla creazione degli EJB e all’invocazione dei metodi offerti:

questa tecnica risulta più adatta dell’immediato tentativo di utilizzo degli EJB

all’interno di pagine JSP in quanto permette di individuare con maggiore

facilità gli errori di programmazione presenti nel codice che implementa gli

EJB, eliminando gli eventuali errori dovuti all’acquisizione ed interpretazione

dei dati ottenuti attraverso le interfacce web offerte dalle pagine JSP.

In commercio esistono anche strumenti di sviluppo (ad esempio Forte for

Java edizione Enterprise) che permettono di eseguire operazioni di debug

sugli EJB simili a quelle normalmente utilizzate con gli altri linguaggi di

programmazione: tuttavia questi tool sono a pagamento e per questo motivo,

vista la natura Open Source di JDPlanner, non sono stati utilizzati e non è


93

possibile dare un giudizio completo sulle loro funzionalità e sulle eventuali

facilitazioni che introducono nello sviluppo di applicazioni J2EE.

L’esperienza tratta da questa tesi, sintetizzata nei paragrafi precedenti,

suggerisce che se vengono valutati e rispettati tutti questi punti l’adozione

della tecnologia J2EE può comportare grandi benefici in termini sia di

architettura generale (poiché consente di realizzare vere architetture

multilivello) che di qualità del servizio (scalabiltà, fault tolerance, load

balancing …).

Appendice A JAVA WEB START

94

A p p e n d i c e A

JAVA WEB START

Questo capitolo descrive la tecnologia Java Web Start (JWS) , sviluppata da

Sun Microsystems, che permette lo sviluppo di applicazioni in grado di essere

lanciate all’interno di un browser. In questo modo Java Web Start si propone

come un interessante anello di congiunzione per lo sviluppo di client-

components all’interno dell’architettura J2EE, in quanto unisce i vantaggi dei

client web based con quelli delle applicazioni stand-alone.

Figura A-1 Logo di Java Web Start

Java WebStart La tecnologia Java Web Start è stata rilasciata da Sun allo scopo di rilanciare la

piattaforma client, dato che da un po’ di tempo l’attenzione (sia nel mondo

Java oriented che in quello Microsoft) si era spostata prevalentemente sul lato

server.

Il concetto che è dietro a Java Web Start è abbastanza semplice e può essere

inteso come il collegamento mancante tra le Applet e le normali applicazioni

desktop scritte in Java.

JWS è sostanzialmente un client che può essere installato sulla propria

macchina come se si trattasse di un comune plug.in per il browser : dopo

l’installazione, è possibile avviare con un semplice click su un link contenuto


95

in un qualsiasi documento Web un’applicazione vera e propria in grado di

girare indipendentemente dal browser che l’ha lanciata.

Questo è possibile poiché JWS si occupa di scaricare e gestire i file che

costituiscono l’applicazione al posto del browser, fornendo loro il runtime

completo ed originale della piattaforma Java.

Una volta lanciata un’applicazione JWS-compatibile, il browser può essere

addirittura chiuso e l’applicazione avviata continuerà a funzionare

perfettamente. Il client si fa quindi carico di gestire, mantenere in cache e

aggiornare ogni applicazione ricevuta su protocollo http, fornendo numerose

utility e diverse nuove API allo sviluppatore, mantenendo l’alto tasso di

sicurezza che ha da sempre contraddistinto il marchio Java.

Caratteristiche di Java Web Start Distribuire un software tramite Internet significa sostanzialmente costringere

l’utente al download e all’avvio sulla propria macchina di un file di

installazione, con tutte le conseguenze che ne derivano. Tale operazione deve

inoltre essere ripetuta ogni volta che un aggiornamento venga reso

disponibile, sempre ammettendo che l’utente ne abbia conoscenza e voglia.

Dal lato opposto troviamo applicazioni sviluppate utilizzando il Web e le

Applet, che hanno permesso agli sviluppatori di realizzare applicazioni

universali e semplici da lanciare, l’aggiornamento delle quali viene mantenuto

costante direttamente dal browser, con lo svantaggio però di una limitatezza

di risorse disponibili e l’obbligo di convivere con un ambiente non ideale per

tutti i tipi di software.

Lo scopo di JWS è quello di unire i vantaggi di un’applicazione completa ai

pregi di un ambiente orientato al Web come quello sfruttato dalle Applet. I tre

principali benefici che se ne ricavano sono:


96

• La possibilità di avere interfacce utente complete e svincolate da limiti, del tutto paragonabili a quelle delle applicazioni desktop.

• La possibilità di far riferimento al web solo quando l’operazione risulta veramente necessaria, ad esempio per il recupero frammentato delle risorse e degli aggiornamenti.

• La possibilità di ottenere applicazioni eseguibili anche in modalità offline JWS al lancio di ogni applicazione già nota, si cura di interrogare il Web

Server al fine di individuare versioni più recenti di ogni singolo componente

del software. Pertanto si ha la possibilità di lavorare sempre con la versione

più recente dell’applicazione. Nonostante questo è comunque possibile, se

l’applicazione non richiede interazioni continue col server ( come nel caso di

applicazioni J2EE), operare in modalità offline, rinunciando ovviamente alla

facoltà di verificare che non esistano versioni più recenti del software lanciato.

La tecnologia di Java Web Start JWS si appoggia sulla tecnologia JNLP (Java Network Launching Protocol),

implementata insieme ad un set di apposite API dal client JWS. Cuore di tale

tecnologia è rappresentato da un file XML con estensione .jnlp,

comunemente definito come descrittore dell’applicazione, il cui download su

macchine appositamente configurate causa l’avvio di JWS. Il client si occupa

quindi del parsing del descrittore, estraendo da esso tutte le informazioni

necessarie per il download, l’aggiornamento e il lancio del software

selezionato.

Dal lato del server quindi non è richiesta l’installazione di alcuna estensione:

per fare in modo che il proprio Web Server sia in grado di dialogare con un

client JNLP è tuttavia necessario associare l’estensione .jnlp al particolare

MIME Type application/x-java-jnlp-file. Il discorso è ovviamente diverso per

la macchina client, che necessita dell’installazione di JWS in modo tale che il

browser sia in grado di fornire i jnlp al giusto elaboratore, anziché visualizzare

semplicemente a video o proporre all’utente di salvarli in locale.

97

I file jnlp sono costituiti da diversi elementi. Un esempio di un file .jnlp è

illustrato in figura A-2.

<?xml version="1.0" encoding="utf-8"?>



<jnlp spec="1.0+" codebase="http://javaweb.eng.com/jaws/apps"

href="swingset2.jnlp">

<information>

<title>SwingSet2 Demo Application</title>

<vendor>Sun Microsystems, Inc.</vendor>

<homepage href="docs/help.html"/>

<description>SwingSet2 Demo Application</description>

<description kind="short">A demo of the capabilities of the Swing

Graphical User Interface.</description>

<icon href="images/swingset2.jpg"/>

<offline-allowed/>

</information>

<security>

<all-permissions/>

</security>

<resources>

<j2se version="1.3"/>

<jar href="lib/SwingSet2.jar"/>

</resources>


98

<application-desc main-class="SwingSet2"/>

</jnlp>

Figura A-2 Esempio di file jnlp

Esso si riferisce all’applicazione dimostrativa della tecnologia JWS e chiamata

SwingSet2, liberamente scaricabile all’indirizzo

http://java.sun.com/products/javawebstart/demos.html

Nel momento in cui si clicca sul collegamento a SwingSet2, il client JWS

esegue le seguenti operazioni:

• Il file jnlp viene scaricato oppure recuperato dalla cache nel caso dovesse risultare già noto al sistema

• Si esegue il parsing del file jnlp. Questa è un’operazione indispensabile per poter individuare e scaricare tutte le risorse necessarie, oltre che per ottenere altre informazioni in merito al programma che si intende lanciare. Si tratta anche di un’operazione critica: nel caso in cui il file jnlp contenga un errore l’intera procedura viene interrotta e un messaggio di errore viene restituito all’utente.

• Dal parsing del file jnlp il client determina quale JRE sia richiesto dall’applicazione.

• Vengono determinate e scaricate tutte le estensioni necessarie • Vengono scaricati tutti gli archivi JAR (l’ applicazione per funzionare con

JWS deve essere impacchettata in un archivio JAR) • Viene determinata quale sia la classe di avvio dell’applicazione • Vengono verificati gli attributi relativi alla sicurezza • I servizi JNLP vengono configurati • L’applicazione viene lanciata


99

Figura A-3 Ciclo di vita di un’applicazione Java Web Start

Fondamentale è dunque descrivere in maniera corretta il file jnlp.

Analizzando la figura A-2 è possibile capire quale deve essere la sua struttura

fondamentale: l’elemento jnlp rappresenta il punto di partenza e sotto di esso

vanno posizionati tutti gli altri elementi ammessi. All’interno dei suoi attributi

vanno specificate alcune caratteristiche abbastanza importanti, come la

versione di jnlp a cui si fa riferimento e il codebase dell’applicazione.

L’elemento information si occupa di fornire informazioni riguardo

l’applicazione descritta. E’ possibile pertanto specificare un titolo, esplicare il

fornitore, fornire una sommaria descrizione del tutto e creare un

collegamento all' home page del prodotto. Attraverso l’elemento icon è poi

possibile associare un’immagine all’applicazione, che sarà sfruttata

dall’Application Manager.

Tra i sotto elementi di information spicca soprattutto offline-allowed :

inserendo questa clausola si farà in modo che l’applicazione possa essere

eseguita in modalità offline. L’elemento security , facoltativo, permette di


100

eliminare le restrizioni di accesso alle risorse del sistema garantite dal modello

di sicurezza di Java. Disponendo di una applicazione firmata è possibile

quindi abilitare ogni permesso sfruttando le righe

<security>

<all-permissions/>

</security>

Firmando i singoli pacchetti dell’applicazione ( col comando jarsigner) è

quindi possibile uscire all’esterno della sandbox gestita dal Security Manager

di Java: una volta fuori dalla sandbox l’applicazione potrà comportarsi

normalmente e non dovrà più subire ulteriori restrizioni in merito alle risorse

utilizzabili.

Per lo sviluppo di applicazioni J2EE è necessario adottare questa politica e

quindi firmare tutti i pacchetti che verranno scaricati dal server.

L’elemento resources è di importanza fondamentale: qui infatti vengono

specificate tutte le risorse delle quali si necessita per comporre l’applicazione.

Sono ammessi sei distinti sotto elementi: jar, nativelib,j2se,property,package

ed extensions.

Normalmente i file puntati da questi elementi necessitano di essere scaricati

prima che l’ applicazione venga lanciata, a meno che non venga specificato

diversamente mediante l’attributo download=”lazy” che fa si’ che essi siano

scaricati solo nel momento in cui il loro utilizzo sia realmente richiesto.

Considerazioni finali su Java Web Start Benché si tratti di una soluzione ancora troppo giovane per poter fare una

valutazione circa la stabilità, e le performance, è sicuramente possibile

affermare che si tratta di una innovazione senza dubbio molto interessante.


101

La possibilità di installare applicazioni da remoto è una delle caratteristiche più

interessanti che internet e Java hanno da sempre promesso. Se si escludono

casi molto particolari come agenti mobili o factory di oggetti, fino ad oggi in

Java questo significava essenzialmente utilizzare le applet. Le molte difficoltà

incontrate per realizzare applicazioni di un certo livello utilizzando il modello

delle applet possono far intuire le potenzialità di Web Start.

Forse è ancora un po’ presto per poter capire quali possano essere le reali

possibilità di un oggetto come questo, ma allo stato attuale la proposta di Sun

risulta tra le più interessanti presenti nel mondo dello sviluppo di applicazioni

Web.

Non resta che attendere ancora qualche mese per capire quali potranno essere

le evoluzioni di Java Web Start.

102

BIBLIOGRAFIA

Autori Vari, J2EE Tutorial, http://java.sun.com/j2ee

Autori Vari, Simplified guide to the Java 2 Platform, Enterprise Edition , http://java.sun.com/j2ee

Ed Roman, Mastering Enterprise JavaBeans and the Java 2 Platform,Enterprise Edition, 1998, Wiley

Autori Vari, Java 2 Platform, Enterprise Edition – Platform and Component Specifications, 1999, Addison-Wesley

Massimiliano Tarquini, Java Enterprise Computing, http://www.java-net.tv

Chad Vawter, Ed Roman, J2EE vs Microsoft.NET- A comparison of building XML-based web services, http://www.theserverside.com/resources/pdf/J2EE-vs-DotNET.pdf

Autori Vari, General Web Architecture, http://www.woodger.ca/archweb.htm

Autori Vari, Project Management- Metodologia e Strumenti, raccolta di slides

Maurizio Morisio, Open Source- Libre Software, raccolta di slides, http://www.polito.it/~patricia/materiale/morisio.pdf

Maurizio Bergami, Sahil Gambhir, Server Applicativi: la mente del Web, Pc Professionale luglio/agosto 2001

Giovanni Puliti, Enterprise Java Beans, Computer Programming maggio 2000

Stefano Fornari, Entità chiamate Entity Beans, Computer

Programming luglio/agosto 2001 Giovanni Malnati, Architettura J2EE- I concetti fondamentali, raccolta di slides Tony Ng, Entity Beans Tutorial, raccolta di slides Jim Driscoll, Session Bean Tutorial, raccolta di slides Richar Monson-Haefel, Enterprise Java Beans, 2000, O’Reilly Domenico Pascuzzi, J2EE: la nuova frontiera dell’Enterprise Monica Pawlan, Writing Enterprise Applications with Java 2 SDK, Enterprise Edition, 2000, Sun Microsystem Computing, Io Programmo luglio/agosto 2001 Autori Vari, Java Web Start, http://java.sun.com/products/javawebstart/developers.html Carlo Pelliccia, Java Web Start- Le applicazioni ora “girano” nel browser, Io Programmo luglio/agosto 2001 Autori Vari, JBoss Documentation, http://www.jboss.org/documentation/HTML/index.html Autori Vari, PostgreSQL – Reference Guide, http://www.postgresql.org

POLITECNICO DI TORINO - elite.polito.itelite.polito.it/files/thesis/fulltext/vesco.pdf · Livello...

Documents

Transcript of POLITECNICO DI TORINO - elite.polito.itelite.polito.it/files/thesis/fulltext/vesco.pdf · Livello...