Per lo sviluppo dei servizi applicativi di rete sono stati
utilizzati diversi tool ed ambienti di sviluppo object oriented
e web.
L’attività di definizione dei requisiti e di
progettazione è stata condotta mediante l’utilizzo
di IBM Rational Rose. In virtù della visione unitaria
e modulare, tutti gli artefatti della progettazione sono allocati
su un unico Rose model, condiviso da tutti gli analisti, progettisti
e sviluppatori del team e pertanto sottoposto a controllo
di configurazione mediante un tool di configuration management.
Il Rose model contiene tutte le specifiche del sistema, funzionali
e non, sottoforma di modello dei casi d’uso. Con lo
stesso tool viene modellata la vista logica del sistema, comprendente
i diagrammi delle classi e le specifiche di ogni classe, nonché
la definizione della base dati dei servizi applicativi di
rete. Nel model viene inoltre allocata e resa disponibile
a tutto il team di sviluppo il modello dell’architettura
applicativa e la documentazione delle interfacce web e dei
servizi, rispettivamente mediante i diagrammi di Conallen
e mediante una specifica dei flussi XML/SOAP scambiati tra
il richiedente del servizio ed il provider dello stesso. La
documentazione tecnica e di specifica viene prodotta automaticamente
a partire da quanto riportato nel Rose model, utilizzando
Rational SoDA for Word, della stessa suite di prodotti Rose.
Il tool di configuration management è Microsoft Visual
Source Safe.
La tecnologia utilizzata per lo sviluppo di tutti i servizi
applicativi di rete è Java 2 Enterprise Edition (J2EE).
Per lo sviluppo di componenti Java e XML, aderenti alle specifiche
J2EE, viene utilizzato un ambiente di sviluppo visuale: Borland
Jbuilder. La scelta di J2EE garantisce ai prodotti sviluppati
caratteristiche di elevata portabilità e integrazione
via XML, che consentono la realizzazione di soluzioni BusinessToBusiness
e BusinessToConsumer. Infatti il deployment delle componenti
sviluppate potrà essere effettuato su tutti gli application
server conformi J2EE, sia proprietari (come ad esempio SunONE
Application Server, Bea Weblogic o IBM WebSphere) oppure Open
Source (come ad esempio Jboss).
La scelta strategiche di utilizzare J2EE garantisce una estrema
flessibilità di configurazione dei prodotti in ambiente
di produzione. Infatti, dipendentemente dalla loro criticità
e complessità architetturale, alcuni servizi applicativi
possono essere configurati in modo da prevedere o meno la
presenza di un application server J2EE; per alcuni servizi
infatti la presenza di un tale componente tecnologico potrebbe
risultare eccessiva e si preferisce adottare soluzioni in
cui risulta sufficiente un servlet container, come ad esempio
Tomcat.
Per garantire la massima aderenza alle specifiche Sun, si
è scelto di effettuare lo sviluppo ed il test utilizzando
dome application server di riferimento SunONE Application
Server, essendo questo l’application server che in maniera
più stringente e rigorosa ne implementa le specifiche.
Con Borland Jbuilder vengono realizzate tutte le componenti
servlet (i controller del pattern Model View Controller),
tutte le classi architetturali di servizio (proxy, helper,
ecc.) i Java Beans che tipicamente implementano logica transazionale,
di business e realizzano i servizi web offerti dai servizi
applicativi di rete e le componenti di accesso ai dati (Data
Access Object) che si occupano di richiedere servizi ai data
manager.
Il DBMS supportato dai servizi applicativi di rete è
Oracle e gli script di definizione degli schemi (DDL) vengono
prodotti automaticamente dal model di Rose.
La presenza di un insieme di classi architetturali che implementano
servizi riutilizzabili come la connessione al database, la
costruzione automatica delle stringhe XML/SOAP a partire da
oggetti java e viceversa, servizi di autenticazione ed autorizzazione,
ecc. consentono alla maggior parte degli sviluppatori di concentrarsi
sulla definizione della logica applicativa, trascurando gli
elementi tecnologici. Analogamente, per le componenti della
user interface, i template delle pagine sono tutti definiti
dallo User Interface Manager che alloca la definizione della
presentation e del layout all’interno di fogli di stile,
che gli sviluppatori devono includere all’interno delle
loro pagine. Per la progettazione del layout e delle componenti
grafiche vengono utilizzati i tool della suite Adobe.
Le componenti della user interface sono realizzate, coerentemente
con la scelta operata in termini di tecnologia per lo sviluppo,
utilizzando le seguenti tecnologie e linguaggi: JavaServerPages
(JSP), XHTML e Javascript. Per la realizzazione di queste
componenti il team di sviluppo utilizza i tool della suite
Macromedia Dreamweaver (Fireworks, Homesite e Flash). Per
i controlli che vengono effettuati dalla componente di frontend
si usa il linguaggio di scripting Javascript, anche questo
standard de jure, tuttavia tutti i controlli sono replicati
sulla componenti web questo per garantire che le applicazioni
possano comunque essere eseguite anche laddove l’utente
abbia disattivato sul suo browser il linguaggio Javascript.
Tutte le stazioni di lavoro degli analisti, progettisti e
degli sviluppatori sono configurate con sistema operativo
Windows e con i seguenti tool:
- Client del Microsoft Visual Source Safe
- Rational Rose
- Rational SoDA for Word
- Borland Jbuilder
- Macromedia Dreamweaver (con Firefox, Homesite e Flash)
- Tomcat
- SunOne Application Server
Ogni sviluppatore realizza le componenti sulla sua workstation,
facendo riferimento al repository di sviluppo, effettua tutti
i test unitari, quindi consolida nel repository quanto sviluppato
e testato e chiede al Configuration Manager il deploy delle
componenti sviluppate sul server di test per poter effettuare
il successivo test di integrazione.
Il team di sviluppo esegue i test sui sistemi operativi più
diffusi (ad esempio Microsoft Windows 98/2000/XP, Linux) e
sui browser più diffusi (le diverse versioni di IE,
Mozilla, Opera, Netscape, Lynx, ecc.). Tutte le pagine sviluppate
vengono inoltre sottoposte, mediante il validatore del W3C,
a verifica di rispondenza del linguaggio utilizzato alla definizione
formale.
|
|
I servizi applicativi di rete sono basati su una architettura
multi tier tipica delle applicazioni web di tipo enterprise.
I servizi applicativi sono esposti agli utilizzatori sia sottoforma
di web services (XML su protocollo SOAP) che come applicazioni
web (XHTML su protocollo HTTP) e fruibili dagli utenti mediante
browser.
Tutti i servizi applicativi fanno riferimento ad un servizio
di cooperazione applicativa che è la componente che
realizza le funzionalità tipiche della cooperazione
orientata ai servizi (Services Oriented Architecture) e ha
la responsabilità di coordinare i servizi forniti dai
diversi domini partecipanti. Il servizio di cooperazione applicativa
realizza il modello di cooperazione per richiesta di servizio
mediante interrogazione del database dei domini federati (che
può essere anche un UDDI registry) e conseguente inoltro
della richiesta di servizio alla porta applicativa del dominio
coinvolto.
I macrocomponenti coinvolti sono distribuiti su tre tier:
- il web tier che espone l’interfaccia utente dei
servizi ed i web services e si occupa del dispatching delle
richieste e confezionamento delle risposte sottoforma di
messaggi SOAP su http, da inoltrare ad altri domini per
via del communication tier. Per il trattamento dei messaggi
SOAP vengono utilizzate le librerie Sun SOAP with Attachments
API for Java (SAAJ) e Java API for XML Messaging (JAXM);
- il communication tier che conosce la sintassi di utilizzo
dei web services di ogni dominio e si preoccupa di invocarli,
se necessario anche in modalità concorrente, comunicando
il risultato al presentation tier; si tratta di un client
di web services di tipo multithreaded;
- l’EJB tier che implementa la logica applicativa
e di accesso ai dati e si occupa principalmente dell’analisi
delle richieste, individuazione del dominio interessato
e inoltro della richiesta al communication tier e smistamento
della risposta al web tier.
Il diagramma che segue rappresenta l’architettura
dei sistemi applicativi di rete, inquadrata in uno dei due
possibili scenari di utilizzo. In questo caso, un’applicazione
di un dominio applicativo A utilizza un servizio web reso
disponibile nella componente web tier. Il servizio web viene
implementato da componenti EJB che a loro volta, tramite il
communication tier, possono invocare i servizi sui restanti
domini federati che li rendono disponibili in un ambiente
cooperativo. Le risposte dei domini federati, quando necessario,
vengono rielaborate dalla componente che implementa la logica
di business ed i risultati vengono inoltrati dalla componente
web tier all’applicativo del dominio A che ha inoltrato
la richiesta di servizio.
|
