politecnico di torino tesi di laurea - e-Lite

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
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
i
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
ii
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.
iii
A nonno Beppe,
spero che da lassù tu possa condividere parte della mia felicità per questo momento
iv
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.
dell’architettura J2EE
Una
qualsiasi
unità
eseguibile
all’interno
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,
v
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
vi
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
indipendentemente dal suo tipo
la
connessione
vii
verso
un
database,
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
viii
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
ix
Capitolo 1
INTRODUZIONE
Capitolo 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.
10
Capitolo 1
INTRODUZIONE
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
11
Capitolo 1
INTRODUZIONE
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
12
Capitolo 1
INTRODUZIONE
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
13
Capitolo 1
•
•
INTRODUZIONE
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
14
Capitolo 1
INTRODUZIONE
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
15
Capitolo 1
INTRODUZIONE
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.
16
Capitolo 2
APPLICAZIONI WEB
Capitolo 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
17
Capitolo 2
•
•
•
•
•
•
APPLICAZIONI WEB
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 platformindependent, quindi non legate ad alcun prodotto o API particolare,
18
Capitolo 2
APPLICAZIONI WEB
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
19
Capitolo 2
APPLICAZIONI WEB
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 webbased 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.
20
Capitolo 2
APPLICAZIONI WEB
Figura 2-2 Comunicazioni
components e J2EE Server
tra
Client
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 webbased 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
21
Capitolo 2
APPLICAZIONI WEB
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
components e altri componenti
business
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.
22
Capitolo 2
APPLICAZIONI WEB
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.
23
Capitolo 2
APPLICAZIONI WEB
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
24
Capitolo 2
APPLICAZIONI WEB
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-etimpera”, 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
25
Capitolo 2
APPLICAZIONI WEB
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.
26
Capitolo 3
ENTERPRISE JAVABEANS
Capitolo 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
27
Capitolo 3
ENTERPRISE JAVABEANS
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.
28
Capitolo 3
ENTERPRISE JAVABEANS
EJB Container
HomeObject
EJB CLIENT
EJB
EJB Object
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
29
Capitolo 3
ENTERPRISE JAVABEANS
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:
•
•
•
•
•
A
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
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..
30
Capitolo 3
EJB CLIENT
ENTERPRISE JAVABEANS
3. R
ichie
sta
di c
re
EJB Container
azio
ne
HomeObject
1.Localizzo
Home Object
5.Ottengo
riferimentto a
EJB Object
EJB
4.Creazione
di EJB
Object
2.Riferimento a
Home Object
EJB Object
JNDI
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.
EJB Container
HomeObject
EJB CLIENT
1.Chiamata
Middleware API
(transazioni,sicurezza,
persistanze
2.Servizi
Middleware
4.Ritorno
EJB Object
EJB
3.Invocazione del
metodo
Figura 3-4 Invocazione di un metodo dell’EJB
31
Capitolo 3
ENTERPRISE JAVABEANS
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.
32
Capitolo 3
ENTERPRISE JAVABEANS
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.
33
Capitolo 3
ENTERPRISE JAVABEANS
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
34
Capitolo 3
ENTERPRISE JAVABEANS
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 beanmanaged persistence consente all’EJB provider di scrivere codice ad hoc per
implementare le operazioni di acceso al database, mentre con la containermanaged 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.
35
Capitolo 3
ENTERPRISE JAVABEANS
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
36
Capitolo 3
ENTERPRISE JAVABEANS
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
37
Capitolo 4 SESSION BEAN: UNO SGUARDO PIU’ APPROFONDITO
Capitolo 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
38
Capitolo 4 SESSION BEAN: UNO SGUARDO PIU’ APPROFONDITO
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 {
39
Capitolo 4 SESSION BEAN: UNO SGUARDO PIU’ APPROFONDITO
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) {
40
Capitolo 4 SESSION BEAN: UNO SGUARDO PIU’ APPROFONDITO
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
PortableRemoteObject.narrow(ic.lookup
HelloHome
(“helloapp/Hello”)
),
home
=
viene creata
un’istanza del bean e viene invocato il metodo sayHello() dell’interfaccia
remota.
41
Capitolo 4 SESSION BEAN: UNO SGUARDO PIU’ APPROFONDITO
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
42
</ejbclass>
Capitolo 4 SESSION BEAN: UNO SGUARDO PIU’ APPROFONDITO
<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).
43
Capitolo 5
ENTITY BEAN: UNO SGUARDO PIU’ APPROFONDITO
Capitolo 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
44
Capitolo 5
ENTITY BEAN: UNO SGUARDO PIU’ APPROFONDITO
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.
45
Capitolo 5
ENTITY BEAN: UNO SGUARDO PIU’ APPROFONDITO
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,
throws
FinderException,
RemoteException;
public
Account
findByName(String
name)
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
46
Capitolo 5
ENTITY BEAN: UNO SGUARDO PIU’ APPROFONDITO
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
}
47
Capitolo 5
ENTITY BEAN: UNO SGUARDO PIU’ APPROFONDITO
}
public String ejbFindByPrimaryKey(String
RemoteException {
ssn)
throws
FinderException,
throws
FinderException,
try {
Statement stmt = con.createStatement();
ResultSet rs = stmt.executeQuery(“SELECT SSN …”);
if (rs.next()) {
// record exists?
stmt.close();
return ssn;
} else {
stmt.close();
return null;
}
} catch (SQLException ex) {
throw new FinderException();
}
}
public Enumeration
RemoteException {
ejbFindByName(String
name)
try {
Vector v = new Vector();
Statement stmt = con.createStatement();
ResultSet rs = stmt.executeQuery(“SELECT SSN …”);
while (rs.next()) {
v.addElement(rs.getString(1));
}
stmt.close();
return v.elements();
} catch (SQLException ex) {
48
Capitolo 5
ENTITY BEAN: UNO SGUARDO PIU’ APPROFONDITO
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);
} catch (SQLException ex) {
throw new RemoteException();
}
}
public void ejbPassivate() throws RemoteException {
// free JDBC connection
try {
con.close();
} catch (SQLException ex) {
throw new RemoteException();
}
49
Capitolo 5
ENTITY BEAN: UNO SGUARDO PIU’ APPROFONDITO
}
public void ejbLoad() throws RemoteException {
// get primary key
String ssn = (String) context.getPrimaryKey();
// retrieve state from DB
try {
Statement stmt = con.createStatement();
ResultSet rs = stmt.executeQuery
(“SELECT … ACCOUNT WHERE SSN = …”);
if (rs.next()) {
name = rs.getString(1);
balance = rs.getDouble(2);
} else {
throw new RemoteException();
}
} catch (SQLException ex) {
throw new RemoteException();
}
}
public void ejbStore() throws RemoteException {
String ssn = (String) context.getPrimaryKey();
try {
Statement stmt = con.createStatement();
} catch (SQLException ex) {
throw new RemoteException();
50
Capitolo 5
ENTITY BEAN: UNO SGUARDO PIU’ APPROFONDITO
}
}
}
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.
51
Capitolo 5
ENTITY BEAN: UNO SGUARDO PIU’ APPROFONDITO
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.
52
Capitolo 5
ENTITY BEAN: UNO SGUARDO PIU’ APPROFONDITO
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>
53
Capitolo 5
ENTITY BEAN: UNO SGUARDO PIU’ APPROFONDITO
<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 è
54
Capitolo 5
ENTITY BEAN: UNO SGUARDO PIU’ APPROFONDITO
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.
55
Capitolo 6
APPLICAZIONI OPEN SOURCE
Capitolo 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).
56
Capitolo 6
APPLICAZIONI OPEN SOURCE
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.
57
Capitolo 6
APPLICAZIONI OPEN SOURCE
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
58
Capitolo 6
APPLICAZIONI OPEN SOURCE
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.
59
Capitolo 6
APPLICAZIONI OPEN SOURCE
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
60
Capitolo 6
APPLICAZIONI OPEN SOURCE
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
61
Capitolo 6
APPLICAZIONI OPEN SOURCE
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>
62
Capitolo 6
APPLICAZIONI OPEN SOURCE
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>[JBoss
2.2.2]
<attribute name="PoolName">PostgresDS</attribute>
<attribute
</attribute>
name="URL">
jdbc:postgresql://host.domain.com/database
<attribute name="JDBCUser">username</attribute>
<attribute name="Password">password</attribute></mbean>
Figura 6-4 : esempio di configurazione del
database in Jboss
63
Capitolo 6
APPLICAZIONI OPEN SOURCE
La figura 6-5 rappresenta lo schema delle directory che si ottiene dopo
l’installazione di JBoss.
JBoss-structure
JBoss-2.2.2
bin
client
conf
db
deploy
docs
external
jdplanner
com
jdp
ejb
META-INF
lib
ext
log
src
tmp
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).
64
Capitolo 6
APPLICAZIONI OPEN SOURCE
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
65
Capitolo 6
APPLICAZIONI OPEN SOURCE
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 .
66
Capitolo 6
APPLICAZIONI OPEN SOURCE
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
67
Capitolo 7
L’APPLICAZIONE JDPLANNER
Capitolo 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.
68
Capitolo 7
L’APPLICAZIONE JDPLANNER
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
69
Capitolo 7
L’APPLICAZIONE JDPLANNER
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.).
70
Capitolo 7
L’APPLICAZIONE JDPLANNER
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.
71
Capitolo 7
L’APPLICAZIONE JDPLANNER
Figura 7-1
JDPlanner
Architettura
dell’applicazione
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
72
Capitolo 7
L’APPLICAZIONE JDPLANNER
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
73
Capitolo 7
L’APPLICAZIONE JDPLANNER
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
74
Capitolo 7
L’APPLICAZIONE JDPLANNER
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
75
Capitolo 7
L’APPLICAZIONE JDPLANNER
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
SQLException,RemoteException;
public
boolean
getSkill(String
user)
throws
SQLException,RemoteException;
}
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
76
Capitolo 7
L’APPLICAZIONE JDPLANNER
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
77
Capitolo 7
L’APPLICAZIONE JDPLANNER
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.
78
Capitolo 7
L’APPLICAZIONE JDPLANNER
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
SQLException,RemoteException;
}
Figura
7-8
Interfaccia
CalendarStoreBean
79
Remota
di
nro)
throws
Capitolo 7
L’APPLICAZIONE JDPLANNER
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
consuntivazione
della
sezione
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
80
Capitolo 7
L’APPLICAZIONE JDPLANNER
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
SQLException,RemoteException;
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
SQLException,RemoteException;
public
int
UpdateStoreConsuntivation(
Integer
idr,
Integer
ida,
java.sql.Date day,String activityName, Integer hours,String notes) throws
SQLException,RemoteException;
81
Capitolo 7
L’APPLICAZIONE JDPLANNER
public void EndStore(boolean result) throws RemoteException;
public void StartStore() throws RemoteException;
}
Figura
7-10
Interfaccia
ConsuntivationBean
remota
di
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.
82
Capitolo 7
L’APPLICAZIONE JDPLANNER
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.
83
Capitolo 7
L’APPLICAZIONE JDPLANNER
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
84
Capitolo 7
L’APPLICAZIONE JDPLANNER
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.
85
Capitolo 7
L’APPLICAZIONE JDPLANNER
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
ActivityBean
Interfaccia
Remota
di
public interface ActivityHome extends EJBHome {
public Activity create(Integer idproject ,String activityName, int
budget, 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.Date
start,
java.sql.Date
end,
int
owner)
throws
RemoteException,
CreateException;
public Activity
RemoteException;
findByPrimaryKey(Integer
id)
throws
FinderException,
public Collection findByIdProject(Integer idp) throws FinderException,
RemoteException;
86
Capitolo 7
public
L’APPLICAZIONE JDPLANNER
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
87
Capitolo 7
L’APPLICAZIONE JDPLANNER
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
88
Capitolo 7
L’APPLICAZIONE JDPLANNER
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.
89
Capitolo 8
CONCLUSIONI
Capitolo 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
90
Capitolo 8
CONCLUSIONI
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
91
Capitolo 8
CONCLUSIONI
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 è
92
Capitolo 8
CONCLUSIONI
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 …).
93
Appendice A
JAVA WEB START
Appendice 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 clientcomponents 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
94
Appendice A
JAVA WEB START
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:
95
Appendice A
JAVA WEB START
•
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.
96
Appendice A
JAVA WEB START
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 File for SwingSet2 Demo Application -->
<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
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>
97
of
the
capabilities
of
the
Swing
Appendice A
JAVA WEB START
<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
98
Appendice A
JAVA WEB START
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
99
Appendice A
JAVA WEB START
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.
100
Appendice A
JAVA WEB START
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.
101
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-vsDotNET.pdf
Autori Vari, General Web
Architecture,
http://www.woodger.ca/archw
eb.htm
Autori Vari, Project ManagementMetodologia e Strumenti,
raccolta di slides
Maurizio Morisio, Open SourceLibre 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/java
webstart/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/documentati
on/HTML/index.html
Autori Vari, PostgreSQL –
Reference Guide,
http://www.postgresql.org
102
4