Tesi Di Laurea: Integrazione Software Via Web Service

UNIVERSITA’ DEGLI STUDI DI BARI
FACOLTA’ DI SCIENZE MATEMATICHE FISICHE E NATURALI

CORSO DI LAUREA IN INFORMATICA
TESI DI LAUREA
IN
INGEGNERIA DEL SOFTWARE
INTEGRAZIONE S OFTWARE VIA W EB -S ERVICES
Relatori:
Chiar.mo Prof Giuseppe VISAGGIO
Dott. Danilo CAIVANO
Laureando:
Damiano Diego de Felice
ANNO ACCADEMICO 2001 - 2002

Dallo sviluppo per componenti ai Web Services
1.INDICI
1.1Indice dei paragrafi

1. I NDICI ....................................................................... ......2
1.1 I NDICE DEI PARAGRAFI ........................................................................2
1.2 I NDICE DELLE FIGURE .........................................................................4
1.3 I NDICE DELLE TABELLE ........................................................................9
2. I NTRODUZIONE ..................................................................10
2.1 S COPO DELL A TESI ..........................................................................11
2.2 S TRUTTURA DELL A TESI ....................................................................12
3. D ALLO SVILUPPO PER COMPONENTI AI W EB S ERVICES ....................13

3.1 C OMPONENT -B ASED S OFTWARE E NGINEERING (CBSE) ...........................13
3.1.1 Cosa sono le componenti .......................................................13
3.1.2 Come specificare le componenti ...........................................14
3.1.3 Implementazione e distribuzione delle componenti ..........15
3.1.4 Le relazioni tra i concetti di base .........................................17
3.2 S VILUPPO DI A PPLICAZIONI O RIENTATO AI S ERVIZI (SODA) .....................17
3.2.1 Cosa sono i servizi ..................................................................18
3.2.2 Architettura dei sistemi orientati ai servizi .........................21
3.2.3 Web Service .............................................................................22
3.3 U N SEMPLICE ESEMPIO ......................................................................23
4. XML W EB S ERVICES ......................................................... 25

4.1 L A PIL A DEI PROTOCOLLI ...................................................................25
4.1.1 eXtensible Markup Language (XML) .....................................27
4.1.2 Simple Object Access Protocol (SOAP) .................................28
4.1.3 Web Services Description Language (WSDL) ......................31
4.1.4 Universal Description, Discovery, and Integration (UDDI) 37
4.1.5 Scenario di utilizzo tipico .......................................................39
4.2 I W EB S ERVICE ALL ’ INTERNO DEL PROCESSO DI SVILUPPO .........................40
4.2.1 Service Pattern ........................................................................40
4.2.1.1 Web Service Façade ........................................................40
4.2.1.2 Gestione dei processi di business ................................41
4.2.1.3 Portali ...............................................................................42
4.2.1.4 Supporto all’EAI ..............................................................42
4.2.2 Progettazione di Web Service ...............................................42
4.2.2.1 Problemi ricorrenti e soluzioni possibili .......................42
4.2.2.2 Linee guida ......................................................................43
4.2.2.3 Remote Procedure Call vs. Document oriented ..........44
4.2.3 L’esempio rivisitato .................................................................47
4.3 I W EB S ERVICES ALL ’ INTERNO DELL ’ ORGANIZZAZIONE ..............................50
4.3.1 La rivoluzione dei dati ............................................................51
4.3.2 La rivoluzione architetturale .................................................52
4.3.3 La rivoluzione del software ...................................................52
2
4.3.4 Le fasi di adozione dei Web Services ...................................53
5. C ASE S TUDY ....................................................................54

5.1 I NTRODUZIONE AL PROGETTO REALIZZATO ..............................................54
5.1.1 Il CRM per gli stage ................................................................54
5.1.2 L’invio e la visualizzazione delle richieste nel sistema ......59
5.2 C OMPONENTI A DISPOSIZIONE .............................................................61
5.2.1 Commercial Off-The Shelf (COTS) .........................................61
5.2.2 Plumtree Corporate Portal 4.5 ..............................................63
5.2.2.1 Enterprise Web ................................................................63
5.2.2.2 Architettura e caratteristiche di Plumtree Corporate
Portal 4.5 .......................................................................................65
5.2.2.3 Gli utenti in Plumtree .....................................................69
5.2.2.4 Sviluppo di gadget ..........................................................72
5.2.3 Microsoft Excel 2000 ..............................................................76
5.2.3.1 Component Object Model (COM) ...................................76
5.2.4 Statsoft Statistica 6 DA-DM-QC .............................................80
5.2.4.1 Statistical Process Control .............................................80
5.2.4.2 Modalità di integrazione e programmazione ...............82
5.2.5 Applix iEnterprise CRM ...........................................................84
5.2.5.1 Modalità di integrazione e programmazione ...............85
5.3 T OOL DI SVILUPPO E PIATTAFORME UTILIZZATE .......................................87
5.3.1 Microsoft .Net ..........................................................................87
5.3.1.1 Microsoft .Net Framework ..............................................88
5.3.1.1.1 Common Language Runtime (CLR) ..................... ........................90
5.3.1.1.2 Base Class Library (BCL) ............................................ ..................91
5.3.1.1.3 Interoperabilità con unmanaged code .......................................93
5.3.1.2 ADO.Net ............................................................................95
5.3.1.3 ASP.Net .............................................................................97
5.3.1.4 Microsoft ASP.Net Web Matrix .....................................103
5.3.1.5 Interoperabilità .Net - J2EE ..........................................106
5.3.2 Microsoft SOAP Toolkit 3.0 ...................................................109
5.3.2.1 XML Web Services e sistemi legacy ...........................109
5.3.2.2 Panoramica del tool ......................................................110
5.3.2.3 Web Services Meta Language (WSML) .......................110
5.3.2.4 La componente server-side .........................................111
5.3.2.5 Il tool WSDL Generator ................................................115
5.3.3 Altova XML-Spy Enterprise Edition 5 ..................................118
5.4 I L SISTEMA REALIZZATO .................................................................120
5.4.1 Gli utenti del sistema e la personalizzazione ...................121
5.4.2 Studio delle richieste nel sistema CRM .............................122
5.4.3 Componenti realizzate .........................................................126
5.4.3.1 Databanker Server .......................................................127
5.4.3.1.1 Metadati ........................................................................................ 127
5.4.3.1.2 Interfaccia della componente ....................... ...........................132
5.4.3.1.3 Costruzione della query SQL ............................... ......................134
5.4.3.1.4 Tecniche di realizzazione e motivazioni .................................. .135
5.4.3.2 Gadget ............................................................................ 136
5.4.3.2.1 Interfaccia della componente ............................ .....................137
5.4.3.2.2 Elaborazione delle richieste ................................... ...................139
5.4.3.2.3.1 Invocazione degli XML Web Services ..................... ...........140
5.4.3.2.3.2 Gestione delle preferenze utente ..................................... .141
3
5.4.3.2.3.3 Interazione con il portale ............................... ....................142

5.4.3.2.3.4 Rappresentazione delle statistiche ........................... ........143
5.4.3.3 Statistics Server ...........................................................144
5.4.3.3.1 Metadati ........................................................................................ 144
5.4.3.3.2 Interfaccia della componente ............................ .....................148
5.4.3.4 Excel Server ..................................................................149
5.4.3.4.1 Interfaccia della componente ................................................. ...150
5.4.3.5 Statistica Server ...........................................................153
5.4.3.5.1 Interfaccia della componente ................................................. ...153
5.4.3.6 Gadget Messaggi CRM .................................................155
5.4.4 Allocazione del sistema e sicurezza ...................................157
5.5 C OMPONENTI VALUTATE MA NON UTILIZZATE .........................................159
5.5.1 Oracle 9i Portal .....................................................................159
5.5.2 mySAP Enterprise Portal 5.0 ...............................................160
5.5.3 Plumtree Excel Gadget Service ...........................................161
6. S PERIMENTAZIONE ............................................................162
6.1 A PPROCCIO ADOTTATO ....................................................................162
6.2 P ROBLEMA DEI DATI E SIMUL AZIONE ...................................................162
6.2.1 Il tool per la simulazione .....................................................162
6.3 R ISULTATI OTTENUTI .......................................................................166
6.4 C ONSIDERAZIONI SULLE PRESTAZIONI ..................................................173
7. C ONCLUSIONI ............................................................... ..174

7.1 P OSSIBILI SVILUPPI FUTURI ...............................................................175
8. B IBLIOGRAFIA .................................................................176
8.1 R IFERIMENTI COMUNI A TUTTI I CAPITOLI .............................................176
8.2 R IFERIMENTI “I NTRODUZIONE ” .........................................................176
8.3 R IFERIMENTI “D ALLO SVILUPPO PER COMPONENTI AI W EB S ERVICES ” ........176
8.4 R IFERIMENTI “XML W EB S ERVICES ” ................................................177
8.5 R IFERIMENTI “C ASE S TUDY ” ...........................................................179
8.6 R IFERIMENTI “C ONCLUSIONI ” ..........................................................181
1.2Indice delle figure
F IGURA 3-1: R ELAZIONI TRA I CONCET TI DI BASE ............................17
F IGURA 3-2: T ERMINOLOGIA DI BASE ..........................................19
F IGURA 3-3: E SEMPIO DI INTERFACCE PER UN SERVIZIO .....................20
4
F IGURA 3-4: S TRATI DELL ’ ARCHITET TURA DI UN SISTEMA ORIENTATO AI

SERVIZI .................................................... .......................... 21
F IGURA 3-5: M ODELLO LOGICO ......................................... ........23
F IGURA 3-6: D IAGRAMMA DELLE COMPONENTI ................................23
F IGURA 3-7: I L SISTEMA ORIENTATO AI SERVIZI ...............................24
F IGURA 4-8: A RCHITET TURA A STRATI DEGLI XML W EB S ERVICE E

RELATIVI PROTOCOLLI .................................................. ............25
F IGURA 4-9: U N ESEMPIO DI FILE XML......................... .............27
F IGURA 4-10: I NTESTAZIONE DELLA RICHIESTA HTTP......................28
F IGURA 4-11: M ESSAGGIO SOAP DI RICHIESTA .............................29
F IGURA 4-12: I NTESTAZIONE DELLA RISPOSTA HTTP.......................29
F IGURA 4-13: M ESSAGGIO SOAP DI RISPOSTA .............................29
F IGURA 4-14: S TRUT TURA DI UN MESSAGGIO SOAP.......................30
F IGURA 4-15: L E CINQUE ARCHITET TURE PIÙ COMUNI .......................30
F IGURA 4-16: D OCUMENTO WSDL RAPPRESENTATO A LIVELLI ............36
F IGURA 4-17: R APPRESENTAZIONE SCHEMATICA DI UN DOCUMENTO WSDL

.......................................................................................36
F IGURA 4-18: F RAMMENTO DI UN DOCUMENTO WSDL: I TIPI ............36
F IGURA 4-19: F RAMMENTO DI UN DOCUMENTO WSDL: I MESSAGGI .....37
F IGURA 4-20: F RAMMENTO DI UN DOCUMENTO WSDL: I TIPI DI PORTA .37
F IGURA 4-21: F RAMMENTO DI UN DOCUMENTO WSDL: LE MODALITÀ DI

ACCESSO .............................................................................37
F IGURA 4-22: F RAMMENTO DI UN DOCUMENTO WSDL: I SERVIZI ........37
F IGURA 4-23: U N TIPICO SCENARIO D ’ USO DI UDDI.......................39
F IGURA 4-24: A T TORI E SCENARIO TIPICO ...................... ..............39
F IGURA 4-25: T ERMINOLOGIA DI BASE ........................................39
F IGURA 4-26: U N ’ INTERAZIONE TRA WS DI ORGANIZZAZIONI DIVERSE ...41
5
F IGURA 4-27: WS PER ESEGUIRE UN ORDINE IN MODO INTERAT TIVO ......45
F IGURA 4-28: WS PER ESEGUIRE UN ORDINE COMPLETO ...................45
F IGURA 4-29: D IAGRAMMA UML CORRISPONDENTE .........................48
F IGURA 4-30: L' ESTENSIONE DI UN ' ORGANIZZAZIONE .......................50
F IGURA 5-31: V ISIONE GENERALE DEL SISTEMA ....................... .......54
F IGURA 5-32: L A PAGINA D ' ACCESSO AL SISTEMA CRM...................58
F IGURA 5-33: P AGINA PER L ' INSERIMENTO DI NUOVE RICHIESTE ...........59
F IGURA 5-34: P AGINA PER VISUALIZZAZIONE E RISPOSTA ALLE RICHIESTE 60
F IGURA 5-35: U NA VISIONE GLOBALE DELL ’E NTERPRISE W EB SECONDO

P LUMTREE ...........................................................................64
F IGURA 5-36: U N PORTALE P LUMTREE ALL ' OPERA ......................... ..66
F IGURA 5-37: A RCHITET TURA DI P LUMTREE ............................. .....68
F IGURA 5-38: I L G ATEWAY S PACE .............................................69
F IGURA 5-39: F UNZIONALITÀ PER AMMINISTRATORI ......................... .71
F IGURA 5-40: L A PAGINA DI UN WIZARD DELL ' AMMINISTRATORE ...........72
F IGURA 5-41: L A GERARCHIA DI OGGET TI DI M ICROSOFT E XCEL 2000. 78
F IGURA 5-42: U N ESEMPIO DI UTILIZZO DI E XCEL MEDIANTE COM......79
F IGURA 5-43: E SEMPIO DI GRAFICO DI CONTROLLO ...................... ....80
F IGURA 5-44: E SEMPIO DI GRAFICO X AND M OVING R....................81
F IGURA 5-45: L' AMBIENTE DI SVILUPPO INTERNO DELLE MACRO ...........84
F IGURA 5-46: A RCHITET TURA DEL SISTEMA ...................................86
F IGURA 5-47: U N ESEMPIO DI APPLICAZIONE USATA VIA W EB .............87
F IGURA 5-48: I L FRAMEWORK .N ET ...................................... .....89
F IGURA 5-49: R ELAZIONI TRA IL CLR, IL BCL E L ' INTERO SISTEMA ... .91
F IGURA 5-50: L A LIBRERIA DI CLASSI DEL FRAMEWORK .N ET ..............92
F IGURA 5-51: S CENARI DI UTILIZZO DI RCW E CCW.....................94
6
F IGURA 5-52: L' ARCHITET TURA DI ADO.N ET ...............................95
F IGURA 5-53: C ONFRONTO TRA I DUE PROVIDER DI DATI DI .N ET

F RAMEWORK ........................................................................ 96
F IGURA 5-54: U N W EB F ORM CON ALL ' INTERNO UNA COMPONENTE SERVER
.......................................................................................97
F IGURA 5-55: U N SEMPLICISSIMO XML W EB S ERVICE ..................100
F IGURA 5-56: I NVOCAZIONE ED ESPLORAZIONE DEL WS..................101
F IGURA 5-57: I NVOCAZIONE DI UN WS TRAMITE CLASSE PROXY .........102
F IGURA 5-58: W EB M ATRIX AL LAVORO SU UNA PAGINA ASP.N ET . . . .103
F IGURA 5-59: I L TOOL PER LA GENERAZIONE DI CLASSI PROXY ...........104
F IGURA 5-60: I L W EB S ERVER INTERNO ....................................105
F IGURA 5-61: .N ET E J2EE A CONFRONTO ................................106
F IGURA 5-62: D ALLA DIPENDENZA DALLA PIAT TAFORMA ALL ' IRRILEVANZA
DELLA PIAT TAFORMA ..............................................................107
F IGURA 5-63: F RAMMENTO DI UN DOCUMENTO WSML..................111
F IGURA 5-64: F RAMMENTO DEL DOCUMENTO WSDL PER UN LISTENER

ISAPI........................................................................ ....112
F IGURA 5-65: F RAMMENTO DEL DOCUMENTO WSDL PER UN LISTENER

ASP...............................................................................112
F IGURA 5-66: F LUSSO DI DATI SUL SERVER .................................112
F IGURA 5-67: F LUSSO DI DATI ALL ' INTERNO DI S OAP S ERVER 30........114
F IGURA 5-68: C OME INDICARE LA DLL IN WSDL G ENERATOR ........116
F IGURA 5-69: L A SCELTA DEI METODI DA ESPORRE ........................117
F IGURA 5-70: T IPO E URL PER IL LISTENER ...............................117
F IGURA 5-71: I NVOCAZIONE DI UN WS A PARTIRE DAL SUO DOCUMENTO

WSDL............................................................................118
F IGURA 5-72: I MESSAGGI SOAP DI RICHIESTA ( A SINISTRA ) E RISPOSTA

( A DESTRA ).......................................................................118
7
F IGURA 5-73: I L DOCUMENTO WSDL DI UN WS IN FORMATO GRAFICO

.....................................................................................119
F IGURA 5-74: A RCHITET TURA DEL SISTEMA .................................120
F IGURA 5-75: T ABELLA CON LE RICHIESTE ................................ ..122
F IGURA 5-76: C ICLO DI VITA DI UNA RICHIESTA ........................... .123
F IGURA 5-77: L' ENTITÀ R ICHIESTA ............................... ...........124
F IGURA 5-78: A RCHITET TURA DEL SISTEMA A UN LIVELLO DI DET TAGLIO

MAGGIORE ......................................................................... 126
F IGURA 5-79: L A PARTE D ATABASE DEI METADATI .........................128
F IGURA 5-80: L A PARTE G RUPPI DEI METADATI ............................128
F IGURA 5-81: F RAMMENTO DELLA PARTE T IPI DEI METADATI .............129
F IGURA 5-82: F RAMMENTO DELLA PARTE P ERIODI DEI METADATI ........131
F IGURA 5-83: L A PARTE S ODDISFAZIONI C LIENTE DEI METADATI ..........132
F IGURA 5-84: L A PARTE S TATI DEI METADATI ..............................132
F IGURA 5-85: U N ESTRAT TO DEL METODO G ET D ATA ()...................136
F IGURA 5-86: I L GADGET ALL ' INTERNO DEL PORTALE IN MODALITÀ GRAFICA
.....................................................................................137
F IGURA 5-87: I L GADGET ALL ' INTERNO DEL PORTALE IN MODALITÀ

TABELLARE .........................................................................138
F IGURA 5-88: P ERSONALIZZAZIONE DELLE STATISTICHE ...................139
F IGURA 5-89: I NVOCAZIONE DI UN XML W EB S ERVICE IN ASP TRAMITE

CALL W EB S ERVICE ()......................................................... ....140
F IGURA 5-90: L A FUNZIONE CALL W EB S ERVICE ()..........................141
F IGURA 5-91: L ET TURA E SCRIT TURA DI VARIABILI DI P LUMTREE ........141
F IGURA 5-92: F RAMMENTO DEI METADATI SULLE STATISTICHE ............148
F IGURA 5-93: L E TRE STATISTICHE IN FORMATO GRAFICO .................150
F IGURA 5-94: I L GADGET DEL PORTALE ......................................156
F IGURA 5-95: L A PAGINA PER L ' INVIO DELLE RICHIESTE ..................156
8
F IGURA 5-96: A RCHITET TURA DI E XCEL GS...............................160
F IGURA 6-97: I L FOGLIO DI CALCOLO DEL TOOL ........................... .163
F IGURA 6-98: I NTERFACCIA GRAFICA DELLA MACRO ........................164
F IGURA 6-99: R ICHIESTE SIMULATE ALL ' INTERNO DEL FOGLIO DI CALCOLO
.....................................................................................164
F IGURA 6-100: L A TABELLA HD_INCIDENT CON I RECORD ..........165
F IGURA 6-101: I RISULTATI DELLA QUERY SUL DATABASE .................167
F IGURA 6-102: L A STATISTICA CORRISPONDENTE ALLA QUERY ...........168
F IGURA 6-103: L' INSERIMENTO DELLA RICHIESTA ..........................170
F IGURA 6-104: I L GRAFICO PRIMA DELL ' INSERIMENTO DELLA RICHIESTA 170
F IGURA 6-105: I L GRAFICO DOPO L ' INSERIMENTO DELLA RICHIESTA .....170
F IGURA 6-106: L A TABELLA PRIMA DELLA CHIUSURA DELLA RICHIESTA ..170
F IGURA 6-107: L A CHIUSURA DELLA RICHIESTA ....................... .....172
F IGURA 6-108: L A TABELLA DOPO LA CHIUSURA DELLA RICHIESTA ......172
1.3Indice delle tabelle
T ABELLA 4-1: C ORRISPONDENZA WSDL - UML...........................49
T ABELLA 5-2: I SET TAGGI DI P LUMTREE ................................... ....74
T ABELLA 5-3: P OSSIBILI TIPI DI RICHIESTA ..................................124
T ABELLA 6-4: S CHEMATIZZAZIONE DEL FOGLIO DI CALCOLO ...............163
9
2.INTRODUZIONE
Con il termine sistemi di livello enterprise si indica

un’ampia classe di applicazioni che eseguono funzioni di business
strategiche, come pianificazione delle risorse aziendali (ERP),
automazione dei processi di business (BPM), gestione delle risorse
umane (HRM), della catena del valore (SCM) e delle relazioni con il
cliente (CRM).
La progettazione di tali sistemi è un’impresa ardua: nonostante
decenni di sviluppo tecnologico nel mondo dell’informatica, i
requisiti imposti dai moderni sistemi informativi molto spesso
rendono difficoltoso se non impossibile per un’organizzazione
costruire ex-novo una soluzione software mission-critical. Piuttosto,
il compito di un ingegnere del software di solito è quello di
estendere la vita di una soluzione esistente descrivendo nuova
logica di business che manipoli archivi di dati esistenti, presenti
dati e transazioni esistenti attraverso nuovi canali comunicativi
come browser Internet o dispositivi portatili, integri sistemi legacy
che rischiano di dover essere esclusi dai processi di business a
causa dell’impossibilità di integrazione.
In tempi recenti, l’ingegneria del software ha puntato
l’attenzione su approcci di sviluppo, processi e strumenti che
supportano l’idea base che grossi sistemi software possano essere
assemblati a partire da collezioni di funzionalità indipendenti e
riusabili. Alcune di queste funzionalità possono essere già
disponibili all’interno dell’organizzazione o essere acquistate da
terze parti, mentre le rimanenti possono essere sviluppate ex-novo.
In ogni caso, l’intero sistema deve essere pensato e progettato in
modo da far convivere tutti questi elementi in un unico e coerente
insieme. Oggi tutto questo è semplificato dallo sviluppo basato su
componenti (CBD), un concetto realizzato da approcci tecnologici
come la piattaforma Microsoft .Net e Java 2 Enterprise Edition
(J2EE.
Ma tutto ciò non basta. Una soluzione di livello enterprise deve
coordinare funzionalità eseguite su un insieme di sistemi basati su
piattaforme hardware e software eterogenee, spesso incompatibili
tra loro e appartenenti a periodi storici in cui l’interoperabilità e
l’integrazione non erano requisiti sentiti come lo sono oggi. Questi
insiemi di sistemi vengono spesso definiti isole di applicazioni,
proprio per sottolineare la loro predisposizione naturale all’essere
isolati e non facilmente integrabili.
Un modo per concepire un sistema di livello enterprise è di
considerarlo come composto da un insieme di servizi che
interagiscono tra loro, dove ogni servizio fornisce l’accesso a un
ben definito insieme di funzionalità. Il sistema nella sua interezza è
progettato e implementato come un insieme di interazioni tra
questi servizi. L’esposizione delle funzionalità come servizi è la
chiave verso la flessibilità. Ciò permette ad altri pacchetti di
10
funzionalità (magari implementate esse stesse come servizi) di

usare altri servizi in modo naturale, indipendentemente dalla loro
locazione fisica e dalle tecnologie hardware e software utilizzate
per l’implementazione. Un sistema si evolve attraverso l’aggiunta
di nuovi servizi. La risultante architettura orientata ai servizi (SOA)
definisce i servizi da cui il sistema è composto, descrive le
interazioni che avvengono tra i servizi che realizzano determinate
funzioni e fa coincidere i servizi a una o più implementazioni in una
determinata tecnologia.
In tempi recenti, una tecnologia in particolare è emersa e si è
sviluppata proprio allo scopo di costituire uno standard per
l’esposizione, l’accesso e la pubblicazione di servizi: gli XML Web
Services. Basati su tecnologie standard e comunemente
accettate, hanno in poco tempo raccolto il favore di tutti i maggiori
produttori di software e soluzioni informatiche, tanto da essere oggi
la tecnologia più promettente e sulla quale si concentra tutta
l’attenzione degli esperti del settore. I maggiori produttori come
Sun, IBM e Microsoft propongono sul mercato una serie di
piattaforme (ONE, .Net) e di tool di sviluppo e integrazione
(Websphere, Visual Studio, iPlanet), in cui i Web Services sono la
tecnologia centrale.
Così come nella progettazione di qualsiasi struttura complessa,
le soluzioni di qualità elevata sono il risultato di decisioni
architetturali preliminari supportate da un insieme di tecniche di
progettazione consolidate, di pattern strutturali e di stili. Questi
pattern risolvono problemi ricorrenti per i servizi, come scalabilità,
affidabilità e sicurezza.
Questo lavoro di tesi, fornisce un contesto per una comprensione
dei servizi Web e di architetture orientate ai servizi per soluzioni
software di livello enterprise. In particolare, considera i servizi in
relazione a concetti più maturi come lo sviluppo per componenti e
mostra come le attuali tecniche di sviluppo per componenti
forniscono una base affidabile e testata per l’implementazione di
un’architettura basata sui servizi. Inoltre viene mostrato come la
progettazione basata su interfacce è la chiave per entrambi i tipi di
progettazione (per servizi e per componenti).
2.1Scopo della tesi

Lo scopo di questo lavoro di tesi è sperimentare, su un progetto
reale, la tecnologia emergente degli XML Web Services come
tecnica per eseguire l’integrazione dei sistemi tipici di
un’organizzazione di livello enterprise. La tesi ha anche lo scopo di
mostrare come nello sviluppo di sistemi basati su XML Web
Services, l’approccio e la metodologia da utilizzare sia lo sviluppo
orientato ai servizi.
11
2.2Struttura della tesi

Il presente lavoro di tesi è strutturato nel seguente modo: il
capitolo 2 presenta un’introduzione all’intero lavoro di tesi. Il
capitolo 3 mostra come i Web Services siano il risultato di una
evoluzione partita dallo sviluppo per componenti e che ha raccolto
l’eredità delle migliori metodologie e pratiche dell’Ingegneria del
Software. Il capitolo 4 presenta i dettagli tecnici degli XML Web
Services e come questi si integrano all’interno del processo di
sviluppo software e nell’organizzazione che decide di adottarli. Il
capitolo 5 presenta il caso di studio utilizzato per fare
sperimentazione: in particolare viene data una panoramica del
progetto, le componenti a disposizione, i tool e le piattaforme a
disposizione per lo sviluppo e infine una descrizione approfondita
del sistema realizzato. Il capitolo 6 riporta la sperimentazione del
sistema realizzato e i problemi incontrati. Il capitolo 7 riassume le
conclusioni tratte al termine dell’intero lavoro di tesi e alcuni
possibili sviluppi futuri. Il capitolo 8 riporta la bibliografia
completa. Il volume allegato contiene le Specifiche dei Requisiti
Software (SRS) e le Specifiche di Progettazione Software (SPS) del
sistema realizzato.
12
3.DALLO SVILUPPO PER COMPONENTI AI WEB SERVICES
I Web Services non sono “nati dal nulla”, ma sono l’evoluzione

delle migliori tecniche e metodologie dell’ingegneria del software.
Nei prossimi paragrafi verranno esposte le tecniche e le
metodologie che sono state precursori dei Web Services e che
hanno portato alla loro nascita.
3.1Component-Based Software Engineering (CBSE)

L’ingegneria del software basata sulle componenti (CBSE,
Component-Based Software Engineering) si occupa della
costruzione rapida di sistemi a partire da componenti poste
all’interno di framework, dove le componenti e i framework
possiedono proprietà certificate e queste proprietà pongono le basi
per predire le proprietà dei sistemi costruiti.
3.1.1Cosa
3.1.1Cosa sono le componenti
Una componente è un’unità di composizione specificata in
modo tale da rendere possibile la sua composizione con altre
componenti e la sua integrazione in modo prevedibile all’interno di
sistemi. Una componente può essere distribuita indipendentemente
ed è soggetta a composizione da terze parti. Affinché una
componente sia distribuibile in modo indipendente, è richiesta una
chiara e netta distinzione dal suo ambiente e dalle altre
componenti. La comunicazione con il suo ambiente avviene
attraverso interfacce: una componente deve avere quindi delle
interfacce specificate in modo chiaro e formale, inoltre la sua
implementazione deve essere incapsulata e non accessibile
dall’ambiente esterno.
La caratteristica più importante di una componente è la
separazione della sua interfaccia dalla sua implementazione.
Questa separazione è differente da quella trovata nella
programmazione orientata agli oggetti (OOP, Object Oriented
Programming), dove la definizione di una classe è separata dalla
sua implementazione.
L’integrazione e la distribuzione di una componente dovrebbero
essere indipendenti dal suo ciclo di sviluppo, e non dovrebbe
essere mai necessario ricompilare un’applicazione che fa uso di
una componente quando si rende necessaria una nuova versione di
quest’ultima. Tutto questo per garantire un corretto uso da parte di
terzi.
Un’altra caratteristica importante di una componente è la sua
visibilità esclusivamente attraverso la sua interfaccia. Ciò implica
la necessità di una sua specifica completa, che includa le sue
proprietà funzionali ed extra-funzionali (ovvero attributi di qualità
come accuratezza, disponibilità, latenza, sicurezza, prestazioni,
risorse richieste), casi d’uso, casi di test, e così via.
13
Come detto, molti dei concetti della CBSE derivano dagli

approcci della OOP e della riusabilità. Proprio la riusabilità si
manifesta su diversi livelli. Prima di tutto, una componente può
essere composta a run-time senza nessun bisogno di compilare.
Una componente separa la sua interfaccia dalla sua
implementazione, nascondendo dettagli implementativi e rendendo
possibile una composizione che non abbia bisogno di conoscere i
suoi dettagli implementativi. Inoltre, una componente interagisce
con altre componenti o framework all’interno di un’architettura
predefinita. Infine, è richiesta una standardizzazione di
un’interfaccia comune per le componenti, affinché queste possano
essere riusate “in grande”.
Una componente non va confusa con un oggetto nell’accezione
della OOP: una componente può essere vista come un insieme di
oggetti che cooperano tra loro. Il confine tra una componente e le
altre è ben definita e l’interazione avviene come detto attraverso le
interfacce. Detto ciò, nulla vieta di realizzare una componente
usando approcci diversi dalla OOP, ad esempio usando il paradigma
funzionale o addirittura adoperando linguaggi di programmazione
come l’Assembly. Inoltre i pattern architetturali e i framework sono
due metodi comunemente utilizzati per la realizzazione e la
distribuzione delle componenti.
3.1.2Come
3.1.2Come specificare le componenti
Una componente è specificata in termini delle sue proprietà
funzionali ed extra-funzionali. Mentre la specifica dell’interfaccia
cattura la sintassi delle proprietà funzionali, i contratti giocano un
ruolo importante nella comprensione della semantica delle
proprietà funzionali di una componente.
L’interfaccia di una componente può essere definita come la
specifica dei suoi punti d’accesso. Un’applicazione accede ai servizi
forniti dalla componente usando questi punti d’accesso.
Un’interfaccia non comprende alcuna implementazione delle sue
operazioni, al contrario, elenca solo un insieme di operazioni e
fornisce esclusivamente una descrizione di esse. Questa
separazione rende possibile sostituire la parte implementativa
senza il bisogno di cambiare l’interfaccia, e in tal modo rende
superflua la ricompilazione del sistema che la usa.
14
Le interfacce sono definite usando tecnologie standard come

IDL 1 , CORBA 2 e COM 3 .
Un contratto esprime la semantica di un’interfaccia. Un
contratto elenca i requisiti globali che una componente manterrà
(le invarianti). Per ogni operazione della componente, un contratto
elenca anche i requisiti che devono essere soddisfatti
dall’utilizzatore (le pre-condizioni) e quelli che la componente
promette di stabilire in ritorno (le post-condizioni). Pre-condizioni,
invarianti e post-condizioni costituiscono la specifica del
comportamento di una componente.
Oltre al comportamento di una singola componente, i contratti
possono essere usati per specificare l’interazione tra gruppi di
componenti, in termini di:
• un insieme di componenti attori;
• il ruolo di ogni componente attraverso i suoi doveri di
contratto;
• le invarianti che le componenti devono mantenere.
La specifica delle proprietà extra-funzionali è invece la parte più
complessa, in quanto non può essere espressa mediante interfacce
standard.
3.1.3Implementazione
3.1.3Implementazione e distribuzione delle componenti
I concetti alla base dell’implementazione e della distribuzione
delle componenti sono i pattern e i framework.
Un pattern definisce una soluzione ricorrente a un problema
ricorrente. I pattern possono essere classificati in tre grandi
categorie in relazione al livello di astrazione usato per
documentare una soluzione software. Al livello di astrazione più
alto ci sono i pattern architetturali (architectural pattern), i
quali trattano le proprietà globali e l’architettura di un sistema
composto da componenti di grosse dimensioni. I pattern
architetturali catturano l’intera struttura e organizzazione di un
sistema software, specificano soluzioni di alto livello, descrivono
l’insieme dei sottosistemi partecipanti, i loro ruoli ed esprimono le
relazioni tra di loro. Ad un livello di astrazione più basso, i pattern
1
IDL (Interface Definition Language) è un termine generico usato per indicare un
linguaggio che permette a un programma o a un oggetto scritto in un linguaggio
di comunicare con un altro programma scritto in un linguaggio a lui sconosciuto.
Nelle tecnologie ad oggetti distribuiti, è importante che nuovi oggetti siano in
grado di essere inviati su una qualsiasi piattaforma o ambiente, e che siano in
grado di scoprire come essere eseguiti in tale ambiente.
2
CORBA (Common Object Request Broker Architecture) è un'architettura e un
insieme di specifiche per creare, distribuire e gestire oggetti distribuiti
all'interno di una rete. Permette a programmi in locazioni differenti e sviluppati
da diversi fornitori in linguaggi differenti, di comunicare in una rete attraverso le
cosiddette "interface broker".
3
Component Object Model, verrà trattato in modo approfondito nel paragrafo
5.2.3.1 a pagina 76.
15
di progetto (design pattern) rifiniscono la struttura e il

comportamento dei sottosistemi e delle componenti di un sistema
software, e le relazioni che esistono tra loro. Infine, al livello più
basso di astrazione, gli idiomi sono pattern di basso livello e
dipendenti dal paradigma e dal linguaggio di programmazione
scelti.
I pattern realizzano il riuso ad alto livello di granularità 4 , in
quanto facilitano il riuso di strategie per assemblare blocchi di
base. I blocchi di base non sono altro che le componenti con le
quali le soluzioni vengono costruite e i pattern rappresentano le
strategie riusabili per mettere insieme tali blocchi.
Un framework è il contesto nel quale le componenti possono
essere usate. Un buon modo di pensare a un framework è quello di
immaginarlo come un sistema operativo in miniatura. In questa
analogia, le componenti per un framework sono come i processi per
un sistema operativo. Il framework gestisce le risorse condivise
dalle componenti e fornisce i meccanismi di base che rendono
possibile la comunicazione (interazione) tra le componenti stesse.
Come i sistemi operativi, i framework sono attivi e agiscono
direttamente sulle componenti in modo da gestire il loro ciclo di
vita o le loro risorse. La differenza in questa analogia con i sistemi
operativi è che non è necessario che un framework abbia
un’esistenza a run-time indipendente dalle componenti.
4
La granularità è la dimensione relativa, la scala, il livello di dettaglio, o la
profondità che caratterizza un oggetto o un'attività. Questo termine è usato in
astronomia, fotografia, fisica, linguistica e molto spesso in informatica. Ci si può
riferire ad essa come livello di una gerarchia di oggetti o azioni, al livello di
dettaglio di una fotografia, o alla quantità di informazioni di un messaggio.
16
3.1.4Le
3.1.4Le relazioni tra i concetti di base
Per comprendere meglio le relazioni che ci sono tra i concetti
finora esposti, si può far riferimento alla Figura 3-1.
Una componente (1) è un’implementazione software eseguibile

su un dispositivo fisico o logico. Una componente implementa una o
più interfacce (2) e soddisfa determinati obblighi specificati nel
contratto (3). Tali obblighi contrattuali assicurano che componenti
sviluppate indipendentemente interagiscano (o non interagiscano)
in modo prevedibile e che possano essere allocate in ambienti
standard a build-time o a run-time (4). Un sistema basato su
componenti si basa su un piccolo numero di tipi di componenti,
ognuno dei quali gioca un ruolo specializzato all’interno del sistema
(5) ed è descritto da un’interfaccia (2). Il modello delle componenti
(6) è l’insieme dei tipi di componenti, delle loro interfacce e, in
aggiunta, di una specifica dei pattern di interazione consentiti tra i
tipi di componenti. Un framework (7) fornisce una varietà di servizi
di run-time (8) per supportare e rafforzare il modello delle
Figura 3 - 1 : Relazioni tra i concetti di base
componenti (transazioni, persistenza, sicurezza, ecc…).
3.2Sviluppo di Applicazioni Orientato ai Servizi (SODA)

Lo sviluppo di applicazioni orientato ai servizi (SODA, Service-
Oriented Development of Applications) è una metodologia di
sviluppo software nata per lavorare all’interno di Architetture
17
Orientate ai Servizi (SOA, Service Oriented Architecture s). Le

SOA rappresentano un insieme di componenti eterogenee ad
accoppiamento lasco che possono essere combinate facilmente
usando i servizi.
Il SODA si occupa della creazione e dell’assemblaggio di servizi
piuttosto che dello sviluppo di codice di programmazione a basso
livello. Gli sviluppatori che usano tale approccio si concentrano più
sul flusso del processo interno e tra applicazioni, e meno sul codice
che è alla base dei sistemi sottostanti. L’applicazione quindi
coincide con il processo di business.
I sistemi sono progettati in modo da fornire servizi sia ad
applicazioni utente sia ad altri servizi, mediante interfacce
pubblicate e scopribili 5 . In molti casi, i servizi forniscono la
modalità migliore per esporre funzioni di business e spesso sono un
ottimo metodo per sviluppare applicazioni che supportano processi
di business. Il SODA non è una nozione nuova, ma recentemente ha
assunto grande interesse grazie all’emergere della tecnologia degli
XML Web Services, che verranno trattati in seguito.
Le soluzioni e le applicazioni orientate ai servizi devono essere
sviluppate come insiemi indipendenti di servizi che interagiscono
tra loro offrendo ben determinate interfacce ai loro potenziali
utenti. Inoltre devono essere disponibili simili tecnologie di
supporto che rendano possibile agli sviluppatori di applicazioni di
navigare le collezioni di servizi, selezionare quelli di proprio
interesse e assemblarli per ricreare le funzionalità desiderate.
3.2.1Cosa
3.2.1Cosa sono i servizi
Un servizio si intende come un’entità software di ampia
granularità e scopribile, che esiste come una singola istanza e
interagisce con applicazioni e altri servizi secondo un modello di
comunicazione a basso accoppiamento (spesso asincrono) e basato
su messaggistica.
5
In tutto il seguito di questa tesi si farà uso del termine italiano “scopribile”
come traduzione dell’originale inglese “discoverable”, usato nei testi di
riferimento. Sebbene il termine “scopribile” in italiano non sia stilisticamente
gradevole, se ne fa uso in quanto è quello che più si avvicina al significato
dell’originale inglese e più ne rende l’idea.
18
In alcuni punti, la terminologia per i servizi è molto simile alla

terminologia usata per descrivere lo sviluppo per componenti,
sebbene esistano termini specifici usati per definire elementi
all’interno dei servizi, come mostrato in Figura 3-2.
Un servizio è un’entità logica e coincide con il contratto

specificato da una o più interfacce pubblicate. Un Service
Provider è un’entità software che implementa le specifiche di un
servizio. Un Service Requestor è l’entità software che chiama un
Service Provider, di solito tale entità viene chiamata client, anche
se un Service Requestor può essere sia un’applicazione utente sia
un altro servizio. Un Service Locator è un tipo particolare di
Service Provider che agisce come un registro e permette di
ottenere le interfacce e le locazioni dei Service Provider. Infine un
Service Broker è un tipo particolare di Service Provider che ha il
compito di smistare le richieste di servizio a uno o più Service
Provider.
Alcune delle caratteristiche chiave che un servizio deve avere
sono le seguenti:
• Grossa granularità: le operazioni sui servizi di solito sono
implementate per coinvolgere più funzionalità e operare su
insiemi di dati più ampi rispetto a quanto accade nello
sviluppo per componenti;
• Basato su interfacce: i servizi implementano interfacce
specificate separatamente. Il beneficio di ciò è che diversi
servizi possono implementare un’interfaccia comune e un
servizio può a sua volta implementare più interfacce;
Figura 3 - 2 : Terminologia di base
19
• Scopribile: i servizi richiedono di essere individuati sia nel

momento in cui si sviluppa, sia a run-time, non solo come
un’unica identità, ma anche per interfaccia e per tipo;
• A singola istanza: diversamente dallo sviluppo basato su
componenti, dove una componente può essere istanziata
più volte, un servizio invece è un’unica istanza sempre in
esecuzione con cui più client possono comunicare;
• Ad accoppiamento lasco: i servizi sono connessi tra loro
attraverso metodi standard, che riducono le dipendenze,
ma soprattutto basati su messaggi non accoppiati. Un
esempio di metodo è lo scambio di documenti in formato
XML;
• Asincrono: generalmente i servizi usano un approccio di
invio asincrono di messaggi, anche se questo non è
richiesto. Infatti molti servizi usano un approccio sincrono.
Sia nello sviluppo basato su componenti sia in quello basato sui
servizi, la progettazione delle interfacce è fatta in modo che
un’entità software implementi ed esponga solo una parte chiave
della sua definizione. Un’interfaccia definisce un insieme di
metodi pubblici, raggruppati logicamente ma che non forniscono
implementazione. Un’interfaccia definisce un contratto tra chi
richiede il servizio e chi lo offre. Qualsiasi implementazione di
un’interfaccia deve fornire tutti i metodi di essa. Un’interfaccia
pubblicata è un’interfaccia univocamente identificabile e resa
disponibile attraverso un registro ai richiedenti affinché questi
possano scoprirla dinamicamente. Un’interfaccia pubblica è
un’interfaccia disponibile all’uso da parte dei client ma non
pubblicata e quindi che richiede una sua conoscenza statica da
parte del client. Un’interfaccia duale è un’interfaccia che
dipende da un’altra.
Nella Figura 3-3 viene mostrato un esempio di servizio
rappresentato in UML come una componente che implementa le
interfacce GestioneClienti, GestioneContatti, GestioneSistemi.
Come si può
notare, tra tutte le
interfacce solo le
prime due sono
pubblicate, l’ultima
invece è solo
pubblica. Infine
l’interfaccia
GestioneSistemi e
ServizioGestione
formano
un’interfaccia duale.
Figura 3 - 3 : Esempio di interfacce per un

servizio
20
3.2.2Architettura
3.2.2Architettura dei sistemi orientati ai servizi
Nell’ingegneria del software ogni nuovo progetto di sviluppo è
basato su tecniche e tool che hanno funzionato con successo in
progetti precedenti. Si è già menzionato il fatto che componenti e
servizi, anche se simili, non sono la stessa cosa: esistono infatti
criteri di progettazione e design pattern differenti. Va tenuto conto
anche del fatto che non tutti i componenti di alta qualità,
trasformati in un servizio, risultino in un servizio di qualità
paragonabile.
La tendenza a risolvere nuovi problemi usando vecchie soluzioni
non è una pratica nuova. In modo simile, nel momento in cui gli
sviluppatori cominciano a creare sistemi basati su componenti, essi
tentano di sfruttare tutta la loro conoscenza nel campo dello
sviluppo orientato agli oggetti, ovviamente con tutti i vecchi
problemi. In modo simile per implementare servizi si usano le
componenti come il metodo migliore. La chiave per effettuare una
transizione da un sistema basato su componenti a uno basato su
Figura 3 - 4 : Strati dell’architettura di un sistema orientato ai

servizi
servizi sta nel capire che un approccio orientato ai servizi, implica

un ulteriore livello architetturali nel sistema. Nella Figura 3-4 viene
mostrata una visione schematica dell’architettura.
Come si può notare dalla figura, lo strato Service Layer
fornisce un’implementazione del sistema a granularità maggiore
del livello Component Layer, così come quest’ultimo
dell’Object/Class Layer. Si può quindi concludere che man mano
che ci si avvicina all’utilizzatore del sistema, quest’ultimo fornisca
implementazioni granularità sempre maggiore. Spesso ci si riferisce
al Service Layer con il termine di “confine dell’applicazione”, per
21
riflettere l’idea che un servizio è un ottimo modo per esporre una

visione esterna di un sistema, con riuso interno e composizione
ottenuta mediante le tradizionali tecniche di sviluppo per
componenti.
3.2.3Web
3.2.3Web Service
Mentre i servizi incapsulano le funzionalità di business, è
richiesta una forma di infrastruttura per facilitare l’interazione e la
comunicazione tra i servizi stessi. Di questa infrastruttura, sono
possibili diverse forme, in quanto i servizi possono essere
implementati su una singola macchina, distribuiti su una serie di
computer appartenenti a una rete locale (LAN), o distribuiti in
modo più ampio su reti di diverse organizzazioni. Un caso
particolare si ha quando i servizi usano Internet come meccanismo
di comunicazione. Il risultante servizio web (Web Service)
condivide le caratteristiche dei più generali servizi, ma richiede
particolari considerazioni dovuti all’uso di meccanismi di
comunicazione pubblici, insicuri e a bassa affidabilità, per
l’interazione tra servizi.
I Web Service così come appena descritti, rappresentano quindi
l’idea astratta di un servizio usufruibile via web. Un caso
particolare di Web Service sono gli XML Web Service, i quali
verranno trattati in modo più specifico nel seguito.
22
3.3Un semplice esempio

Vedremo di seguito un semplice esempio di un sistema di
gestione clienti, definito dal modello logico in Figura 3-5 usando la
notazione UML. Vedremo prima una possibile implementazione
usando l’approccio basato su componenti e poi una usando
l’approccio orientato ai servizi. Lo stesso esempio verrà ripreso nel
capitolo seguente dopo aver introdotto in modo approfondito gli
XML Web Services.
Solitamente, nello sviluppo basato su componenti viene
applicato sempre lo stesso pattern: per ogni classe nel modello
Figura 3 - 5 : Modello logico
logico, viene prodotta una componente e per ogni attributo della

classe vengono fornite due operazioni, una per avvalorare
l’attributo e una per leggerne il contenuto. Nella Figura 3-6 viene
mostrata una delle componenti corrispondenti alle classi nel
modello logico, precisamente la componente Cliente.
Se invece passiamo allo sviluppo orientato ai servizi, bisogna
prima fare delle premesse. Per un servizio esiste un’unica istanza
che gestisce un
insieme di risorse,
le quali saranno per
lo più stateless.
Questo implica che
dobbiamo vedere il
servizio come un
unico oggetto che
può creare e gestire
istanze di un tipo o
di un insieme di tipi.
Si fa quindi uso di
un design pattern
chiamato Value
Object: un Figura 3 - 6 : Diagramma delle componenti
“oggetto valore”
(Value Object appunto) rappresenta lo stato di una istanza. Con
tale approccio, invece di un gran numero di piccole operazioni per
ottenere lo stato di una componente (di solito metodi di tipo get e
set), un servizio avrà una singola grande operazione che restituisce
intere istanze di oggetti. Ovviamente operazioni di questo tipo
23
hanno conseguenze sia sull’occupazione della rete, così come sul

modo in cui i richiedenti devono gestire oggetti di dimensioni così
grandi rispetto alla norma. Inoltre, un approccio simile richiede una
riflessione accurata sui problemi di transazione e aggiornamento (si
pensi a un sistema che tratta azioni in borsa).
In Figura 3-7 viene rappresentata una delle possibili
implementazioni del servizio corrispondente al modello logico
iniziale.
Figura 3 - 7 : Il sistema orientato ai servizi
24
4.XML WEB SERVICES
Un XML Web Service è un’applicazione software identificata

da una URI 6 , le cui interfacce e legami sono definibili, descrivibili e
scopribili mediante manufatti XML e supportano interazioni dirette
con altre applicazioni software usando messaggi basati su XML e
utilizzando protocolli Internet.
4.1La pila dei protocolli

Fondamentale importanza nella descrizione degli XML WS riveste
la sua pila di protocolli (Figura 4-8), ovvero un insieme di protocolli
e interfacce per la programmazione di applicazioni (API,
Application Programming Interface) standard, che permettono a
individui e applicazioni di individuare e utilizzare gli XML WS.
Su ogni livello della pila è stata effettuata una standardizzazione
Figura 4 - 8 : Architettura a strati degli XML Web Service e relativi

protocolli
di protocolli e API semplici e aperti. Proprio questa

standardizzazione è la chiave della diffusione onnipresente delle
architetture basate su XML WS e la diffusione onnipresente
dell’infrastruttura è la chiave per l’adozione generale degli XML WS
da parte delle organizzazioni.
Facendo riferimento alla Figura 4-8 viene qui data una visione
generale dei livelli e dei protocolli, mentre nei paragrafi successivi
alcuni di questi ultimi verranno analizzati più in dettaglio.
6
Come specificato nell’RFC (Request For Comment) numero 2396 dell’IETF
(Internet Engineering Task Force), una URI è una stringa compatta di caratteri
usata per identificare in modo univoco una risorsa astratta o fisica.
25
Lo strato di base della pila è rappresentato dai servizi di rete. La

rete è spesso basata sul protocollo HT TP 7 , ma anche su altri
protocolli di rete, come FTP 8 , SMTP 9 e altri meno diffusi. Subito
sopra lo strato di rete è posto uno strato di messaggistica basata
su XML, il quale facilita la comunicazione tra WS e i loro client. Lo
strato di messaggistica è basato su SOAP, un protocollo XML che
facilita la pubblicazione, la ricerca, il collegamento e l’invocazione
delle operazioni del WS. Lo strato di descrizione del servizio è
basato su WSDL, un protocollo usato per specificare un WS e per
descrivere ai client i servizi disponibili. Queste descrizioni hanno la
forma di documenti XML che descrivono l’interfaccia di
programmazione e la locazione dei servizi stessi.
I tre strati descritti finora sono essenziali per rendere
interoperabili i WS e danno una modalità a basso costo per
diffondere tali servizi attraverso Internet. Gli strati rimanenti nella
pila sono opzionali e saranno usati solo quando richiesti da una
particolare tipo di sistema da sviluppare.
La pubblicazione di un servizio corrisponde a una qualunque
azione del fornitore (service provider) che renda il documento
WSDL disponibile a un richiedente (service requestor). Un WS viene
considerato “pubblicato” anche quando il documento WSDL (o una
URL 1 0 che punta ad esso) viene inviata per email a uno
sviluppatore. In realtà la pubblicazione vera e propria è quella
ottenuta usando i registri pubblici UDDI. In modo simile la scoperta
di un servizio è una qualunque azione del richiedente (service
requestor) di accedere al documento WSDL. Un WS viene
“scoperto” semplicemente accedendo direttamente (o tramite URL)
al file contenente il documento WSDL. In realtà la scoperta vera e
propria è quella ottenuta interrogando i registri pubblici UDDI e
usando i documenti WSDL per selezionare uno o più potenziali
servizi. La pubblicazione e la scoperta dei WS avvengono quindi
attraverso il protocollo UDDI.
Lo strato alla sommità della pila semplifica la composizione di
WS all’interno di workflow e la rappresentazione di questa
aggregazione come un unico WS di livello più alto. A questo livello
della pila la standardizzazione dei protocolli è ancora in corso al
momento della stesura di questa tesi. Molte grandi organizzazioni
hanno già proposto però i loro “standard”, ad esempio IBM propone
il protocollo Web Services Flow Language (WSFL), ma esistono altri
protocolli come Web Service Interoperability (WS- I) di WS-I
Organization e Web Service Choreography Interface (WSCI) di SAP.
7
HTTP: HyperText Transfer Protocol. Protocollo standardizzato dall’IETF e nato
per il trasferimento di ipertesti su Internet, di fatto attualmente è il protocollo
più diffuso per il trasferimento di file generici su Internet.
8
FTP: File Transfer Protocol. Protocollo standardizzato dall’IEFT e usato per il
trasferimento bidirezionale di file tra due host.
9
SMTP: Simple Mail Transfer Protocol. Protocollo standardizzato dall’IEFT e usato
per lo scambio di messaggi email tra server.
10
URL: termine usato come sinonimo del termine URI, quest’ultimo ormai andato
quasi in disuso
26
Di seguito verranno analizzati più a fondo i protocolli più

importanti, ovvero XML, SOAP, WSDL e UDDI.
4.1.1eXtensible
4.1.1eXtensible Markup Language (XML)
La specifica XML è un insieme di linee guida, definito dal World
Wide Web Consortium (W3C) 1 1 , per descrivere dati strutturati in
formato testuale. Come HTML, XML è un linguaggio di markup
(marcatura) basato su tag (marcatori) all’interno di parentesi
angolari (< e >), ed è un sottoinsieme del più complesso SGML
(Standard Generalized Markup Language). Come per HTML, la
natura testuale di XML rende i dati altamente portabili e
largamente diffondibili. Diversamente però da HTML, XML non ha
un insieme fisso di tag, ma data la sua natura di metalinguaggio,
permette di creare altri linguaggi di markup mediante la definizione
di nuovi tag. E’ proprio questa possibilità di definire nuovi tag che
rende XML un linguaggio estendibile. Un’altra differenza da HTML, il
quale si concentra più sulla presentazione dei dati, è l’attenzione di
XML sui dati e sulla loro struttura. Per questo motivo XML è molto
più rigoroso nelle sue regole sintattiche: un documento XML deve
essere ben formato (well formed), ovvero a ogni tag deve essere
associato il corrispondente tag di chiusura, i tag non devono
sovrapporsi e altro.
Un esempio di documento XML viene riportato in Figura 4-9. Gli
elementi su cui soffermare l’attenzione sono i già citati tag
(Externa lPerson
, Person, Name, ecc…), gli attributi dei tag (id per
Person), usati per specificare ulteriori informazioni riguardo il
contenuto di un tag e i namespace.
11
Il W3C riveste un ruolo fondamentale per gli XML WS. Essa è un’organizzazione
indipendente consistente di circa 500 membri, formata nel 1994 sotto la
direzione di Tim Berners-Lee. Il suo obiettivo primario è pubblicare standard per
tecnologie direttamente legate al Web (come HTML e XML). Ciò che viene
proposto da W3C non è ufficialmente uno “standard”, infatti il termine usato è
“raccomandazione” (recommendation), comunque tali raccomandazioni sono
standard di fatto in molti settori, grazie alla natura imparziale del W3C stesso.
Una volta che uno standard ha ottenuto lo stato di raccomandazione, questo non
verrà più né modificato né subirà aggiunte. Ma prima di raggiungere tale stato,
gli standard sono classificati prima come schema in lavorazione (Working Draft),
in quanto soggetti ancora a modifiche, e solo alla fine dopo uno schema in
lavorazione di richiamo (Call Working Draft) diventeranno raccomandazioni.
Figura 4 - 9 : Un esempio di file XML
27
Per i namespace bisogna porre particolare attenzione in quanto

sono essenziali per gli XML WS. Si è prima parlato della possibilità
di estendere il linguaggio XML, per questo motivo chiunque ha la
capacità di definire un proprio linguaggio di markup usando tag
creati per l’occasione. Nel momento in cui due soggetti diversi si
scambiano dati usando documenti XML, è molto probabile che
entrambi abbiano definito un tag con lo stesso nome ma con
significato e struttura diversi tra loro, ovvero si ha una collisione di
nomi. Proprio per evitare queste inconsistenze, vengono in aiuto i
namespace. Ogni individuo definisce un proprio spazio di nomi
(namespace appunto) univoco e indica nel documento XML quali
tag fanno parte di questo spazio. Nell’esempio in figura i tag
Address, St reet1, City, PoliticalDivision e PostalCode fanno parte del
namespace urn:xmlabs-com-schemas:location, come indicato dalla
parola loc (in pratica una label arbitraria usata per riferirsi al
namespace). La possibilità di usare i namespace è alla base del
successo ottenuto da XML come formato per lo scambio di dati e
per l’integrazione di sistemi di diverse organizzazioni.
4.1.2Simple
4.1.2Simple Object Access Protocol (SOAP)
Le specifiche SOAP 1 2 definiscono un framework di messaggistica
per lo scambio di dati formattati in XML attraverso Internet. Il
framework è semplice, facile da sviluppare e completamente
neutrale rispetto al sistema operativo, al linguaggio di
programmazione o della piattaforma hardware. SOAP fornisce un
livello minimo di trasporto sulla base del quale possono essere
costruiti protocolli e interazioni più complessi.
SOAP è fondamentalmente un modello di comunicazione a una
via che assicura che un messaggio coerente sia trasferito dal
mittente al ricevente, includendo anche potenziali intermediari che
possono aggiungere o modificare parti del messaggio.
Le specifiche SOAP contengono convenzioni per adattare la sua
natura di messaggistica unidirezionale al paradigma
richiesta/risposta tipico dello stile di comunicazione del Remote
Procedure Call (RPC). Inoltre definiscono come trasmettere interi
documenti XML e una regola opzionale di codifica per i tipi di dati,
lasciando anche la libertà al ricevente di interpretare liberamente
tali tipi.
Facendo riferimento alla Figura 4-10 e alla Figura 4-11, una
richiesta SOAP trasportata usando il protocollo di rete HTTP, è una
richiesta HTTP di tipo POST. All’interno dell’intestazione HTTP,
oltre ai comuni campi
di una richiesta HTTP,
deve essere
specificato anche il
12
Di recente con SOAP non viene più indicato l’originale Simple Object Access
Protocol, bensì in modo non Figura
ufficiale 4Service-Oriented Access
- 10 : Intestazione Protocol,
della sia per
richiesta
uniformarlo ai concetti di Web
HTTP Service, sia perché SOAP in realtà non è né
semplice né object-oriented.
28
tipo di contenuto del messaggio HTTP (e precisamente tex t /xmlnel

campo Content - Type
) e il metodo da invocare sul Web Service (nel
campo SOAPMethodName).
Il carico (body) del messaggio HTTP contiene un documento XML
che sarà il vero e proprio messaggio SOAP.
Il messaggio SOAP di richiesta vero e proprio invece contiene le
seguenti parti:
• Un contenitore (Envelope) dell’intero messaggio;
• Una intestazione (Header) opzionale contenente
informazioni aggiuntive per il messaggio SOAP.
• Un corpo (Body) contenente informazioni per il ricevente
finale del messaggio (per ogni metodo invocato, i
parametri di input).
Figura 4 - 12 : Intestazione della

risposta HTTP
Figura 4 - 11 : Messaggio SOAP di richiesta
La risposta SOAP ha una struttura molto simile alla richiesta e

sarà sempre contenuta in una risposta di tipo HTTP, con i comuni
campi (Figura 4-12). La risposta SOAP viaggia sempre con lo stesso
protocollo con cui è stata effettuata la richiesta. Come detto
inizialmente, il protocollo di trasporto può essere un qualunque
protocollo Internet quale HTTP, FTP, SMTP, anche se il più utilizzato
è attualmente HTTP.
Il messaggio SOAP di risposta vero e proprio (Figura 4-13)
presenta le tre parti prima elencate. Nel body solitamente si trova
il risultato dell’invocazione del servizio, ovvero i parametri di
ritorno del metodo invocato. Spesso inoltre l’Header non è
presente. Da notare anche che il risultato dell’invocazione del
metodo è contenuto sempre in un tag avente nome composto dal
nome del metodo invocato e dalla parola chiave Response. Sebbene
29
Figura 4 - 13 : Messaggio SOAP di risposta

nell’esempio all’interno si trovi solo un tag con un valore di tipo

semplice (t rue), nulla vieta che un metodo possa ritornare un
messaggio più complesso, costituito da più tag.
Una schematizzazione ad alto livello della struttura di un

generico messaggio SOAP è riportata in Figura 4-14.
In Figura 4-15 invece vengono rappresentate tutte le cinque più

comuni architetture usate con i sistemi basati su SOAP: Invia e
dimentica (Fire and forget), Richiesta-Risposta (Request-
Response),
Figura 4 - 14 : Notifica,
Struttura diBroadcast e Workflow.
un messaggio SOAP
Figura 4 - 15 : Le cinque architetture più comuni
30
Tale varietà di architetture è possibile grazie alla caratteristica

di SOAP di poter collegare i riceventi tra loro, non limitandosi al
semplice scenario di mittente e ricevente. Un qualsiasi nodo che
non sia un ricevente finale, viene detto intermediario. Le
specifiche SOAP permettono agli intermediari di modificare
parzialmente il messaggio SOAP prima di inviarlo al prossimo nodo.
4.1.3Web
4.1.3Web Services Description Language (WSDL)
Le specifiche WSDL definiscono un framework estendibile per la
descrizione delle interfacce dei Web Service. Sviluppato
originariamente da Microsoft e IBM, è stato poi approvato e reso
standard dal W3C. WSDL è il cuore del framework dei Web Service,
in quanto fornisce una modalità comune in cui rappresentare i tipi
di dati passati nei messaggi, le operazioni da eseguire sui messaggi
e la corrispondenza dei messaggi con i protocolli di trasporto di
rete.
Un documento WSDL è composto da tre elementi principali:
• Definizione dei tipi di dati;
• Operazioni astratte;
• Modalità di accesso.
Ognuno di questi elementi può essere specificato in un
documento XML separato e poi importato in diverse combinazioni
per creare la descrizione finale del WS, oppure possono essere
definite insieme in un unico documento.
La definizione dei tipi di dati determina la struttura e il
contenuto dei messaggi. Le operazioni astratte determinano le
operazioni eseguite sul contenuto del messaggio, infine le modalità
di accesso determinano il protocollo di trasporto di rete che porterà
il messaggio alla sua destinazione (detta endpoint, ovvero “punto
finale”). Le operazioni e i messaggi sono descritti in modo astratto,
una volta però legati a un protocollo di rete e a un formato di
messaggio, allora definiscono un endpoint. Diversi endpoint
concreti, tra loro legati, sono combinati in endpoint astratti, detti
servizi.
In ognuno dei tre elementi principali esistono ulteriori sotto-
elementi di livello di astrazione più basso, per un totale di sette:
• Tipo (Type ): definisce tutti i tipi di dati usati nei messaggi,
in particolare la loro struttura, la cardinalità e i tipi degli
elementi costituenti, fino ad arrivare ai tipi di dati
primitivi;
• Messaggio (Message ): definisce le diverse parti di un
messaggio (per esempio intestazione (Header), corpo
(Body), parametri);
31
• Operazione (Operat ion ): elenca i messaggi coinvolti nel

flusso verso il punto finale. Per esempio, un’operazione di
tipo richiesta-risposta avrà i riferimenti a due messaggi
(input e output);
• Tipo porta (PortType ): l’insieme di operazioni previste da
un particolare tipo di endpoint, senza alcun dettaglio
relativo al trasporto o alla codifica;
• Modalità d’accesso (Binding): specifica i particolari
riguardo il protocollo di trasporto e di codifica per una
determinata porta;
• Porta (Port): l’indirizzo di rete di un endpoint e il Binding a
cui si riferisce;
• Servizio (Service): un insieme di endpoint tra loro correlati.
In Figura 4-16, vengono mostrati tutti gli elementi di un

documento WSDL, stratificati rispetto a uno dei tre livelli di
astrazione.
Da notare che tutti gli elementi sono definiti in modo
indipendente dalla modalità di trasporto, di modo che possano
essere definite più modalità per lo stesso servizio (ad esempio
SOAP su HTTP oppure SOAP su JMS). Analogamente le definizioni
dei tipi di dati sono poste in una sezione separata in modo che
queste possano essere usate nella definizione di diversi servizi.
32
Figura 4 - 18 : Frammento di un documento WSDL: i tipi
Figura 4 - 16 : Documento WSDL rappresentato a livelli
In Figura 4-17, viene rappresentato un documento WSDL in

forma schematica 1 3 .
Figura 4 - 17 : Rappresentazione schematica di un documento WSDL
Nelle figure successive invece sono riportati alcuni esempi degli

elementi di basso livello di un documento WSDL.
13
Tale rappresentazione viene fornita dal tool di sviluppo XML-Spy 5 di Altova
Inc. (http://www.altova.com/ ), di cui si parlerà anche nel seguito.
33
Figura 4 - 22 : Frammento di un documento WSDL: i servizi
Nonostante un documento WSDL (così come uno SOAP) sembri

complesso, va detto che grazie ai tool di sviluppo attualmente sul
mercato, durante lo sviluppo dei WS non si avrà quasi mai la
necessità di accedere direttamente a tali documenti, se non per
effettuare modifiche dettate da particolari e rare situazioni.
Figura 4 - 19 : Frammento di un documento WSDL: i messaggi
Figura 4 - 20 : Frammento di un documento WSDL: i tipi di porta
4.1.4Universal
4.1.4Universal Description, Discovery, and Integration (UDDI)
Figura 4 - 21 : Frammento di un documento WSDL: le modalità di

accesso
Le specifiche UDDI formano le fondamenta tecniche necessarie

per la pubblicazione e scoperta di implementazioni di XML WS sia
all’interno di un’organizzazione sia tra organizzazioni diverse. Nelle
34
specifiche sono presenti strutture per la descrizione formale di

servizi astratti e di servizi esistenti. Inoltre, a queste informazioni
può essere associato un ricco insieme di metadati, per favorire la
scoperta efficiente di informazioni sui WS attraverso ben precisi
criteri di ricerca. UDDI stesso è un WS per gestire e localizzare altri
servizi a partire da una risorsa logicamente centralizzata, il
cosiddetto registro UDDI.
Un documento UDDI contiene principalmente quattro elementi:
• businessEntity rappresenta il proprietario del servizio e
include informazioni come nome, descrizione, indirizzo,
ecc…. Nel momento della registrazione, ogni
organizzazione riceve un'unica businessKey che la
identifica univocamente nel registro.
• businessService contiene informazioni riguardo un
singolo Web Service o un gruppo di Web Service simili. Le
informazioni sono nome, descrizione, proprietario e una
lista di bindingTemplate. Ogni servizio è univocamente
identificato da una serviceKey.
• bindingTemplate rappresenta un singolo servizio e
contiene tutte le informazioni richieste su come e dove
accedere il servizio (ad esempio la URL e il protocollo
utilizzato per accedervi). Ogni bindingTemplate è
univocamente identificato da una bindingKey.
• tModel (abbreviazione di technical model) è usato
principalmente per legare il servizio con la sua specifica
esterna. Per un Web Service questo elemento punta al
documento WSDL che lo descrive. Se due o più tModel
hanno lo stesso valore della chiave, allora i servizi puntati
possono essere considerati equivalenti, permettendo così
a chi utilizza un servizio di usare un altro service provider
a seconda delle proprie richieste. Per capire meglio il
concetto di tModel, si può utilizzare la metafora di
un'interfaccia con diverse implementazioni fornite
presumibilmente da diversi produttori. Lo sviluppatore
sceglie l'implementazione che più soddisfa i propri
requisiti.
35
La caratteristica più importante di UDDI è che le informazioni

presenti in un registro possono essere accedute sia da un umano
(mediante portale Internet), sia da un sistema software (mediante
gli stessi protocolli di cui si è parlato precedentemente). In Figura
4-23 è mostrato tale scenario.
Non vengono forniti altri dettagli di più basso livello su UDDI in
quanto al momento della stesura di questa tesi, è un servizio non
Figura 4 - 23 : Un tipico scenario d’uso di UDDI
ancora adottato a pieno dalle organizzazioni. Inoltre nel progetto

sviluppato per questa tesi non si fa uso di UDDI, in quanto non
particolarmente necessario.
4.1.5Scenario
4.1.5Scenario di utilizzo tipico
Dopo aver parlato di tutti i protocolli su cui si basano gli XML
WS, è ora possibile definire il tipico scenario di utilizzo. Così come
per lo sviluppo orientato ai servizi, anche per gli XML WS si
riconoscono tre attori
principali: Service
Figura 4 - 24 : Attori e scenario

tipico
36
Figura 4 - 25 : Terminologia di base

Provider, Service Broker (che coincide con il registro UDDI) e

Service Requestor (le loro definizioni sono identiche a quelle già
date in precedenza). Tale scenario è visibile in Figura 4-24. La
differenza qui sta nel fatto che le interazioni tra gli attori
avvengono mediante protocolli standard ben definiti. In Figura 4-25
viene riportato un diagramma molto simile a quello già riportato in
precedenza, proprio per dimostrare questa similarità.
4.2I Web Service all’interno del processo di sviluppo

I WS non cambiano in alcun modo i processi di analisi e
progettazione di un sistema. Di seguito verranno presentati alcuni
utilizzi tipici dei Web Service e verrà posta inoltre attenzione su
una serie di vincoli e di potenziali problemi nell’area dei requisiti
non funzionali. Infine verrà presentato il modo in cui introdurre i
WS all’interno della modellazione tramite UML, riprendendo il
semplice esempio presentato nel capitolo precedente.
4.2.1Service
4.2.1Service Pattern
L’architettura WS non è perfetta, ma per alcune classi di
problemi è la tecnologia più appropriata attualmente disponibile. I
WS sono particolarmente utili per esporre servizi di gestione dello
stato verso una rete eterogenea di componenti client. I service
pattern presentati di seguito tendono a comprendere funzionalità di
dimensioni molto più ampie dei tradizionali design pattern, i quali
sono generalmente più orientati al livello delle componenti.
4.2.1.1Web
4.2.1.1Web Service Façade
Il façade pattern (pattern di facciata) è un design pattern
comune per le componenti e consiste nel presentare un’interfaccia
“amichevole” per una logica di applicazione “non amichevole”. Di
solito l’uso più comune del façade pattern è quello di nascondere la
chiamata a una risorsa esterna, come un database, la quale
richiede un linguaggio o una sintassi differente da quelle usate nel
resto dell’applicazione.
Il façade service pattern è del tutto simile: agisce come un
front-end XML verso un servizio componente che non è nativo XML,
rispettando al tempo stesso gli stessi requisiti di sicurezza del
servizio originale (autenticazione, accessi privilegiati, ecc…). Alcuni
esempi di possibili applicazioni del façade service pattern sono
quelli di seguito elencati:
• Front-end XML verso database. Servizi di questo tipo si
specializzano nell’offrire interfacce di interrogazione e
modifica di specifici insiemi di dati logici (ad esempio
record di impiegati). La facciata nasconde sia il linguaggio
di interrogazione sia la struttura fisica dei dati nelle
tabelle e nelle viste. L’applicazione di questo pattern
permette di progettare ottimamente il database senza
37
variare l’interfaccia del client e consente alla stessa

interfaccia di essere supportata da diversi database
ognuno con un diverso linguaggio di interrogazione;
• Front-end XML verso applicazioni di business. Solitamente
le applicazioni di business più grandi, come pacchetti di
contabilità, gestione personale, o gestione dei rapporti con
la clientela (CRM), hanno storicamente una interoperabilità
bassissima. Un façade può esporre determinate
funzionalità e dati richiesti per l’interoperabilità, di modo
che più client possano manipolare in modo semplice lo
stato del sistema;
• Gestione di servizi comuni su piattaforme differenti. La
maggior parte delle moderne reti aziendali contengono
una varietà di sistemi operativi (OS), incluse versioni
multiple di un OS dello stesso fornitore. Un façade può
dotare lo staff tecnico di un’interfaccia comune per
raccogliere le informazioni sui sistemi e mutare il
comportamento dell’intero sistema.
4.2.1.2Gestione
4.2.1.2Gestione dei processi di business
I WS possono orchestrare processi complessi all’interno di grosse
organizzazioni (come l’assunzione di personale o la gestione delle
risorse umane), sia processi che si estendono oltre i loro confini
(come pagamenti o acquisti). In questi processi i WS sono molto
utili, in quanto sono progettati per essere indipendenti dalla
tecnologia sottostante e per superare facilmente tutti i ponti tra i
diversi sistemi coinvolti (Figura 4-26).
Tuttavia
quest’area è
ancora in fase
di sviluppo
soprattutto nel
campo della
sicurezza e
delle
transazioni.
Figura 4 - 26 : Un’interazione tra WS di organizzazioni

diverse
Tradizionalmente una transazione blocca i record soggetti a

modifica e rende definitivi i cambiamenti solo quando tutti i
partecipanti alla transazione danno il consenso definitivo
all’esecuzione della transazione stessa. Questo approccio non si
adatta bene a un ambiente come quello dei WS, basato su
connessioni pubbliche ad alta latenza e a bassa affidabilità.
38
4.2.1.3Portali
4.2.1.3Portali
Sin dai primordi del Web, i portali hanno sempre fornito servizi di
valore: da siti di notizie come MyYahoo!, fino a siti di gestione dei
sistemi di rete sviluppati da settori tecnici di un’organizzazione. I
WS offrono un nuovo approccio per la costruzione dei portali,
definendo un approccio comune e uno schema per lo scambio dei
dati. Con l’esposizione dei dati mediante servizi web, chi pubblica i
dati permette ai client di utilizzare sia i dati senza costringerli a un
determinato schema o formato di rappresentazione, sia le
funzionalità attualmente svolte da pagine web tramite interazione
uomo-macchina, creando così un vero e proprio Web
programmabile.
4.2.1.4Supporto
4.2.1.4Supporto all’EAI
L’integrazione di applicazioni enterprise (EAI, Enterprise
Application Integration) è il processo tradizionalmente costoso
di costruire sistemi di interscambio di dati tra applicazioni di
business. Le soluzioni di EAI devono capire i protocolli e le
interfacce dei servizi delle applicazioni che gestiscono, estrarre i
dati da applicazioni differenti e tradurre i dati in schemi e tipi
compresi dalle altre applicazioni da integrare. Un efficiente modello
per le soluzioni di EAI sono i concentratori (hub ). Un
concentratore solitamente traduce i dati estratti in una
rappresentazione interna, dalla quale produrre rappresentazioni
comprensibili da tutte le applicazioni che supporta. Un
concentratore può usare un approccio a connettore in modo da
aggiungere modularmene applicazioni supportate a un’installazione
preesistente.
Nel mondo dei WS, le rappresentazioni interne dei dati sono un
insieme di documenti XML, mentre i connettori sono WS façade che
producono questi documenti a partire dai dati interni delle
applicazioni supportate. Di supporto alla rappresentazione interna
e alle trasformazioni tra formati differenti vengono in aiuto
rispettivamente gli standard XML-Schema (XSD) e eXtensible
Stylesheet Language Transformations (XSLT), entrambi ratificati
dal W3C e pienamente supportati dai moderni tool di sviluppo.
4.2.2Progettazione
4.2.2Progettazione di Web Service
Lo sviluppo di servizi completi, robusti e scalabili richiede a
volte di pensare in modo differente dal solito. Durante la
progettazione dei sistemi che fanno uso di WS bisogna porre
attenzione ad alcuni particolari che se tralasciati possono portare il
sistema implementato ad essere inefficiente e poco manutenibile
dopo un breve periodo di reale utilizzo.
4.2.2.1Problemi
4.2.2.1Problemi ricorrenti e soluzioni possibili
I WS rendono gli schemi XML centrali nella comunicazione tra
organizzazioni, mentre in passato la definizione di schemi e
39
strutture dati era dominio dei progettisti delle basi di dati

dell’organizzazione. Uno schema XML dovrebbe essere progettato
in modo da seguire gli standard, da essere estendibile,
indipendente dalla piattaforma e di uso generale.
Se pensiamo poi alla gestione delle autorizzazioni e delle
autenticazioni, il passaggio dai servizi interni all’organizzazione a
quelli tra organizzazioni, può presentare problemi a volte di
soluzione difficile. I servizi interni ad esempio possono usare i
sistemi esistenti di accesso al dominio per autenticare gli utenti (ad
esempio Active Directory), ma quando si vuole autenticare utenti
appartenenti a sorgenti esterne, le cose si complicano, tanto che si
sta affrontando il problema proponendo nuovi standard specifici per
gli XML WS (come WS-Security) e nuove tecnologie come il
single sign-on (SSO), ad esempio Liberty Alliance e Passport di
Microsoft.
Sempre nell’ottica dell’uscita dai confini dell’organizzazione,
ulteriore attenzione va posta sul mezzo di comunicazione usato dai
WS, ovvero la rete. Di solito la rete interna dell’organizzazione
presenta bassi livelli di latenza, brevi periodi di blocco dovuti a
manutenzione o problemi inattesi ed elevati livelli di sicurezza. I
servizi che si estendono fuori dai confini dell’organizzazione invece
devono affidarsi a una rete pubblica, ovvero Internet. Una rete
pubblica, come è noto, non è affidabile, non è sicura, può avere alti
livelli di latenza, ma soprattutto non è sotto il controllo
dell’organizzazione. Per i servizi più critici andrebbe usata una
connessione privata. Per i servizi che raccolgono richieste in coda
bisogna prevedere dei servizi di supporto che gestiscano le
richieste in attesa e distribuiscano il carico di lavoro. In generale la
gestione dei guasti va ben studiata: la ripetizione dell’invio delle
richieste fallite potrebbe causare sovraffollamento della rete, in
quanto come già detto i WS trasmettono messaggi di dimensione
maggiore dei soliti parametri scambiati tra componenti. Proprio
questa considerazione sulle dimensioni dei messaggi potrebbe
richiedere la progettazione di un sistema di caching dei documenti
in modo da ridurre il numero di richieste e in generale ridurre
l’occupazione della rete soprattutto facendo svolgere a un servizio
delle operazioni molto più complesse ad esempio dell’esecuzione
della somma tra due interi.
4.2.2.2Linee
4.2.2.2Linee guida
I punti di forza e le limitazioni dei WS suggeriscono design
pattern diversi da quelli usati per sviluppare i tradizionali sistemi,
riassumendo si possono trarre le seguenti linee guida:
• Messaggi a granularità ampia. I servizi non devono esporre
interfacce per eseguire piccole modifiche agli elementi di
un dato, piuttosto devono eseguire modifiche generiche
con una singola chiamata di servizio.
40
• Messaggistica asincrona. Per i servizi con tempi di risposta

non determinati, è buona pratica prevedere uno scenario
differente da quello di richiesta-risposta, ovvero inviare la
richiesta, usare la risposta solo come semplice conferma di
ricezione, disconnettersi e continuare l’elaborazione in
attesa che il server completi l’elaborazione.
• Bi-direzionalità dei servizi. In relazione al punto
precedente, i WS andrebbero progettati in coppia, in modo
da poter gestire il ciclo di richiesta-risposta.
• Scoperta degli endpoint. Diversi endpoint possono
implementare lo stesso servizio. Un client dovrebbe
scegliere il miglior endpoint a run-time e non codificare gli
endpoint a build-time. In questo modo si ottiene un
bilanciamento dinamico del carico, un sistema tollerante ai
guasti (fault-tolerant) e un’affinità topologica e geografica
tra il client e l’istanza del servizio. Di supporto alla
scoperta dinamica degli endpoint, sono i registri UDDI
pubblici o privati.
• Idempotenza. Problemi sulla rete possono portare alla
ricezione multipla dello stesso messaggio. Messaggi che
influenzano incrementalmente lo stato del servizio (come
le richieste d’acquisto) andrebbero dotati di identificatori
univoci per riconoscere i messaggi duplicati.
• Librerie di servizi. Nel momento in cui un’organizzazione
comincia ad adottare in larga scala i WS, è concepibile
raccogliere i processi ricorrenti (come gestione degli
accessi e delle autorizzazioni) in librerie di servizi da
condividere in tutti i sistemi sviluppati. Ovviamente i
servizi di libreria devono essere progettati in modo da
essere generali e astratti per adattarsi al maggior numero
di situazioni.
4.2.2.3Remote
4.2.2.3Remote Procedure Call vs. Document oriented
Per chi utilizza un WS, l’interazione con un Web Service può
apparire come una interazione batch oppure in tempo reale. Gli
standard e le tecnologie per i WS generalmente comprendono due
tipi di pattern di interazione per le applicazioni: Remote Procedure
Call oriented (RPC, chiamata di procedure remote) e Document
oriented (orientato ai documenti).
Nell’interazione RPC oriented, una richiesta ha la forma di una
chiamata di un metodo o di una procedura con i relativi parametri
di input e output. Inoltre nell’interazione RPC oriented viene inviato
un documento in un formato specifico in modo da comunicare con
un’unica applicazione software o stored procedure di un database,
come mostrato in Figura 4-27. Se ad esempio l’ordine di un
prodotto dipende dalle scorte di magazzino, il sistema accede al
database per controllare l’effettiva disponibilità. Se c’è disponibilità
41
il sistema ritorna un documento XML che indica che l’ordine è stato

accettato e sarà effettuato. Altrimenti, il documento XML indica che
l’ordine è stato rifiutato. I due messaggi di richiesta e risposta sono
Figura 4 - 27 : WS per eseguire un ordine in modo interattivo
modellati come messaggi sincroni, quindi l’applicazione che invia il

messaggio si attende una risposta.
Nell’interazione Document oriented invece, le richieste hanno

la forma di documenti XML completi che sono sottoposti a una
elaborazione completa. Come mostrato in Figura 4-28 e tornando
all’esempio dell’ordine di un prodotto, la richiesta coincide con
l’intero ordine. Il sistema risponderà con un breve messaggio di
conferma della ricezione dell’ordine e comincerà un processo
Figura 4 - 28 : WS per eseguire un ordine completo
42
interno che porterà infine all’invio della risposta sotto forma di un

documento XML corrispondente alla fattura.
L’interazione Document oriented presuppone che tutte le parti
coinvolte nella conversazione, condividano un documento di
business comune, come un ordine, una fattura, ecc…. Queste parti
coinvolte vengono spesso identificate come partner commerciali o
partner collaborativi.
4.2.3L’esempio
4.2.3L’esempio rivisitato
Se si considera l’esempio del sistema di gestione clienti esposto
nel capitolo precedente, si può notare come questo, rivisitato
mediante gli XML Web Service, non presenti sostanziali differenze
da come era stato implementato seguendo l’approccio di sviluppo
orientato ai servizi. Nella modellazione UML verranno solo introdotti
due nuovi stereotipi (ovvero estensioni del linguaggio UML
esistente) chiamati «WebService» e «WebDocument».
In Figura 4-29 viene data una rappresentazione visuale di un
Figura 4 - 29 : Diagramma UML corrispondente
Web Service così come definito nel suo documento WSDL, come
esempio di uso dei due stereotipi. In realtà questi possono essere
usati in qualsiasi altro diagramma UML oltre a quello di
Deployment. E’ importante notare come questo metodo di
progettare i WS promuove il riuso sia dei documenti che
definiscono lo scambio di dati sia delle interfacce supportate dai
43
servizi. Questa è una caratteristica chiave per la progettazione di

soluzioni di dimensioni enterprise. Tutti i servizi che interagiscono
con il documento Contatto devono agire sulla stessa definizione del
documento.
Nella Tabella 4-1, vengono rappresentati i legami tra i manufatti
del documento WSDL del servizio MyAgenda e gli elementi del
linguaggio UML.
M ANUFATTO
E LEMENTO UML C OMMENTO
WSDL
Il servizio è rappresentato come una

componente che realizza una o più
service «WebService» interfacce e risiede a una determinata
locazione. La relazione «reside» catturerà
l’informazione sull’URL del servizio.
Ogni portType è rappresentata come

un’interfaccia UML che realizzata uno o
portType Interfaccia più servizi. La relazione «realize»
catturerà le informazioni riguardanti il
collegamento.
Ogni messaggio è rappresentato come
«WebDocument una classe UML. E’ richiesta una
message
» corrispondenza tra l’XML-Schema e UML
per modellare il messaggio e le sue parti.
Ogni parte del messaggio può essere
rappresentata sia come un attributo UML
Attributo o
part del «WebDocument» sia mediante
associazione
un’associazione (spesso di aggregazione)
con altri «WebDocument».
address Un nodo rappresenta il server su cui

Nodo
location risiede il servizio.
Tabella 4 - 1 : Corrispondenza WSDL - UML
44
4.3I Web Services all’interno dell’organizzazione

La motivazione principale per cui un’organizzazione dovrebbe
adottare i Web Services è l’estensione al di fuori dei propri confini e
questa estensione coincide spesso nell’uscita dai confini della rete
locale.
Rete dell’
organizzazione
45
Figura 4 - 30 : L'estensione di un'organizzazione
Le opportunità più importanti nell’estensione di

un’organizzazione da una rete relativamente ristretta ad una ad
ampia diffusione come il Web sono principalmente tre tipi di
connessione con l’esterno (Figura 4-30):
• Business-To-Consumer (B2C): per esplorare e catturare
nuove opportunità di business derivanti dal commercio
online.
• Business-To-Employee (B2E): per l’incremento
dell’efficienza nelle operazioni e nei rapporti con la
clientela, mediante l’uso del Web al posto delle reti
proprietarie.
• Business-To-Business (B2B): l’area di maggior interesse
per le organizzazioni che vogliono sopravvivere all’interno
di mercati resi sempre più competitivi e globali grazie
all’avvento di Internet e del Web.
Le aree di impatto all’interno dell’organizzazione sono
principalmente tre: dati, architettura e software.
4.3.1La
4.3.1La rivoluzione dei dati
Prima dell’avvento di XML, i dati erano molto spesso in formati
proprietari, accoppiati profondamente con le applicazioni che
capivano come i dati erano strutturati e come elaborarli. I formati
basati su XML specifici per l’industria e l’e-commerce forniscono
un’alternativa alle soluzioni specializzate di Electronic Data
Interchange (EDI), facilitando lo scambio di dati nella logica B2B e
giocando un ruolo chiave nell’infrastruttura di messaggistica per il
modello di elaborazione distribuita.
La forza di XML è l’indipendenza dai dati. XML è pura descrizione
di dati, non legato ad alcun linguaggio di programmazione, sistema
operativo o protocollo di trasporto. I dati sono quindi liberi di
muoversi senza i limiti imposti dalle architetture fortemente
accoppiate e dipendenti da determinati protocolli di trasporto.
XML deriva dalla cultura dei documenti, la quale cultura è
distinta e contrapposta a quella del codice e dei dati, ovvero quelle
che spingono maggiormente il mercato dell’informatica. La cultura
del codice è caratterizzata da un’attenzione sui linguaggi di
programmazione, partendo da Fortran e arrivando a C, C++ e Java.
La cultura dei dati è caratterizzata da COBOL, elaborazione dati e
database. Entrambi i due modi di pensare portano con se la
propensione a vedere la risoluzione dei problemi solo attraverso
codice o dati. Dalla prospettiva del codice, i dati sono unicamente
qualcosa da trasferire attraverso chiamate di procedura. Dalla
prospettiva dei dati, i dati sono solo qualcosa da immagazzinare in
database per poi manipolare. La cultura da cui ha origine XML ha
forzato un ridimensionamento delle modalità di sviluppo delle
applicazioni, soprattutto per chi è legato alla cultura del codice.
Un’organizzazione che decidesse di intraprendere la strada dei Web
46
Service deve progettare una graduale migrazione dei propri sistemi

verso un’ottica più vicina a quella dei documenti.
4.3.2La
4.3.2La rivoluzione architetturale
Le tecnologie basate su XML aprono nuove possibilità per
l’elaborazione distribuita potenziando l’attuale infrastruttura del
Web e creando una transizione dai sistemi distribuiti basati su
oggetti ad architetture basate su servizi Web che possono essere
scoperti, usati e assemblati usando tecnologie standard e aperte. Il
cambiamento in quest’area è stato lo spostamento da sistemi ad
alto accoppiamento, basati su infrastrutture come CORBA, RMI 1 4 e
DCOM 1 5 , ognuna con i propri protocolli di trasporto, a sistemi a
basso accoppiamento basati su protocolli Web come TCP/IP. Anche
se i protocolli sottostanti CORBA, RMI e DCOM forniscono un mezzo
di comunicazione efficiente tra i nodi, il loro svantaggio è la
difficoltà di comunicare con altri sistemi o direttamente con il Web.
I sistemi ad accoppiamento lasco basati sul Web, invece, forniscono
ciò che è stato sempre ricercato nell’informatica: la connettività
universale.
Anche se è possibile costruire ponti software che legano sistemi
legacy tra loro o con il Web, questa pratica non è semplice e
aggiunge un ulteriore strato di complessità su un’infrastruttura già
di per se complessa. Tuttavia l’introduzione dei Web Services
all’interno dei sistemi preesistenti rende possibili nuove
architetture.
4.3.3La
4.3.3La rivoluzione del software
Durante gli anni 70 e 80, il software era costruito come
applicazioni monolitiche progettate per risolvere particolari
problemi. Nei progetti più vasti, nel tentativo di risolvere diversi
problemi contemporaneamente, il software decadeva di qualità a
ogni incremento di funzionalità o adattamento a cambiamenti di
tecnologia. Negli anni 90 emerge un nuovo modello di software:
invece di definire tutti i requisiti in anticipo, il nuovo modo di agire
nasceva intorno al concetto di costruire blocchi capaci di
combinarsi con altri già esistenti o non ancora creati.
Il Web è proprio un esempio di questa nuova filosofia: dopo anni
di tentativi di costruire infrastrutture complesse per scambiare
informazioni tra reti distribuite, il Web è nato come l’assemblaggio
14
RMI (Remote Method Invocation) è la modalità in cui uno sviluppatore, usando
il linguaggio di programmazione e la piattaforma di sviluppo Java, può scrivere
codice in cui oggetti Java su diversi computer possono interagire su una rete
distribuita come se fossero però locali all'oggetto che li utilizza. RMI è la
versione Java di quello che è generalmente chiamato col nome RPC (Remote
Procedure Call), di diverso ha la possibilità di passare uno o più oggetti
all'interno di una richiesta.
15
DCOM (Distributed Component Object Model) è la versione di COM per oggetti
distribuiti su un rete.
47
di tecnologie di base come HTTP, HTML, browser e protocolli

collaudati e affidabili come TCP/IP.
All’interno di un’organizzazione, grazie ai Web Service, si adotta
proprio questa filosofia: software pensato per essere integrato e
collaborare con altri sistemi, in modo trasparente, senza limiti
imposti da tecnologie sottostanti, in un’ottica di apertura.
4.3.4Le
4.3.4Le fasi di adozione dei Web Services
Nella maggior parte delle ricerche di mercato condotte dagli
analisti (Gartner Group, Forrester, IDC e altri), gli XML Web Services
risultano essere una tecnologia che sarà adottata nelle
organizzazioni coinvolte nelle ricerche. Comunque, l’adozione non
avverrà in una singola ondata. Secondo gli analisti, l’adozione
avverrà mediante tre fasi distinte:
• Fase I (2002-2003 e oltre): in questa fase, le organizzazioni
adotteranno i WS come una modalità più economica e
semplice per eseguire l’integrazione di applicazioni
all’interno dei confini della rete dell’organizzazione stessa. Il
primo uso naturale da parte di un’organizzazione sarà quello
di utilizzare i WS al posto del middleware tradizionale per
integrare informazioni all’interno di portali.
• Fase II (2003-2005): nel momento in cui gli standard
diventano più maturi (specialmente in materia di sicurezza e
controllo delle transazioni), le organizzazioni cominceranno a
integrare processi di business e applicazioni al di fuori dei
propri confini. Gli standard per il workflow saranno anche più
maturi e permetteranno alle organizzazioni di costruire
sistemi sofisticati di collaborazione con i propri partner.
• Fase III (2006 e oltre): in questo periodo, i registri UDDI
dovrebbero contenere un gran numero di WS pubblicamente
disponibili. Questo permetterà agli analisti di cominciare a
costruire applicazioni complesse a partire da WS disponibili e
un tempo di solo appannaggio degli sviluppatori. Soprattutto
grazie agli standard e al software di automazione, sarà
possibile per un agente software mutare dinamicamente il
comportamento del sistema, riconfigurando il workflow in
modo che reagisca al cambiamento di condizioni nel
processo. Lo scenario sarà quello di un mercato globale di WS
in cui organizzazioni diverse usano WS di altre organizzazioni
secondo la logica di mercato B2B.
48
5.CASE STUDY
5.1Introduzione al progetto realizzato

Il sistema realizzato (STATCRM) per sperimentare quanto
esposto in precedenza è un sistema in grado di integrare,
all’interno di un portale, un sistema di elaborazione statistica dei
dati di un sistema CRM. Come mostrato in Figura 5-31, gli elementi
che interagiscono nel sistema sono essenzialmente quattro:
l’Utente che accede al sistema tramite il portale usando un
comune browser Internet, il sistema Statistics Server che
elabora statistiche sui dati del CRM System, il Portale che funge
da unico punto d’accesso ai sistemi dell’organizzazione,
unificandoli all’interno di un ambiente unico e presentando le
informazioni in modo personalizzato all’utente. Sia il CRM System
sia l’interazione tra Portale e CRM System non sono stati realizzati
in questo progetto: il CRM System esiste in forma prototipale ma
completa, l’interazione esiste in forma incompleta sebbene
funzionante.
Figura 5 - 31 : Visione generale del sistema
5.1.1Il
5.1.1Il CRM per gli stage
Lo Stage risulta essere la parte pratica del percorso formativo,
un periodo all'interno di un'azienda che permette allo studente di
acquisire esperienza sul campo ed integrare le nozioni apprese
all'Università. La legge definisce lo Stage come uno strumento
49
inteso a "realizzare momenti di alternanza tra studio e lavoro ed

agevolare le scelte professionali mediante la conoscenza diretta del
mondo del lavoro". La finalità che si propone è quella di avvicinare
la realtà universitaria e il tipo di formazione fornita in tale ambito
alla realtà d'impresa e ai suoi processi produttivi e di crescita.
Il CRM è un pacchetto software che l'Università degli Studi di
Bari mette a disposizione di tutti coloro che sono interessati
all'argomento Stage. Il software offre infatti supporto a tutte le
possibili figure che si possono individuare in materia di Stage.
Perché uno Stage abbia motivo di esistere infatti, occorre
individuare: un soggetto promotore (l'Università), un soggetto
ospitante (l'Impresa) e un soggetto fruitore (lo Stagista). La legge
inoltre prevede la presenza di due ulteriori figure: i Tutor, uno
afferente al soggetto ospitante (Tutor Aziendale) e uno al soggetto
promotore (Tutor Universitario).
Il CRM offre supporto automatico ad ognuna di queste figure:
• le Imprese possono offrire stage e selezionare i candidati;
• gli Studenti possono candidarsi per uno stage, o
richiederne l'attivazione;
• i Manager Didattici possono governare i vari flussi
informativi;
• i Docenti possono assistere gli Studenti.
Il sistema CRM è stato realizzato dal Dipartimento di Informatica
(e in particolare dal gruppo di ricercatori del laboratorio SER_Lab)
per l'Università degli Studi di Bari nell'ambito del progetto di
ricerca Campus One. Al momento della stesura di questo lavoro di
tesi e della realizzazione del sistema STATCRM, il sistema CRM si
trovava in fase prototipale e soggetto a possibili e continui
cambiamenti. Per questo motivo molti particolari sono ancora in
fase di sviluppo e non completamente chiari, come ad esempio la
figura del Tutor: attualmente il sistema prevede che il tutor
universitario sia un docente, e che il tutor aziendale sia un
referente aziendale.
50
L’accesso al sistema CRM avviene mediante un comune browser

Internet. In Figura 5-32 è mostrata la pagina Web iniziale per
l’accesso al sistema, in modo autonomo, senza cioè accedere dal
portale.
Figura 5 - 32 : La pagina d'accesso al sistema CRM
Attualmente esiste anche la possibilità di accedere al sistema

CRM attraverso il portale, ma tale integrazione è ancora in fase
embrionale e non completamente funzionante.
Il sistema CRM offre innumerevoli funzionalità per gli utenti. Di
tutte quelle presenti, per il progetto realizzato è stata considerata
solo l’area che racchiude le funzioni di richiesta d’assistenza (nel
sistema le “richieste” vengono chiamate anche “messaggi”).
51
5.1.2L’invio
5.1.2L’invio e la visualizzazione delle richieste nel sistema
Una volta nel sistema, l’utente ha la possibilità di inviare
richieste a un destinatario a sua scelta. Per ogni richiesta, oltre al
testo, è possibile indicare anche il tipo e il progetto formativo a cui
si riferisce. In Figura 5-33 viene mostrata la pagina Web in cui
avviene l’inserimento delle richieste. L’accesso a tale pagina
avviene dalla funzione Invio Messaggi nella sezione Funzioni.
Figura 5 - 33 : Pagina per l'inserimento di nuove richieste
Una volta immessa nel sistema, la richiesta viene smistata al

destinatario appropriato, che dopo averne preso visione, potrà
decidere di rispondere o no ad essa. L’accesso alle richieste
ricevute avviene dalla funzione Messaggi Ricevuti nella sezione
Interrogazioni. La pagina Web è formata da più sottopagine: in
Figura 5-34 viene mostrata la sottopagina in cui il ricevente può
inserire la risposta alla richiesta, che sarà a sua volta inviata al
mittente come se fosse un nuovo messaggio, a cui può a sua volta
rispondere indicando un valore che quantifichi la propria
soddisfazione nella lettura della risposta ricevuta. Questo ciclo può
continuare e ripetersi più volte, finché uno dei due soggetti
(mittente o ricevente) non ritengano chiusa la pratica di richiesta
assistenza.
52
Figura 5 - 34 : Pagina per visualizzazione e risposta alle richieste
53
5.2Componenti a disposizione
Durante la realizzazione del progetto, si è cercato laddove
possibile di preferire l’utilizzo di una componente o di un sistema
preesistente piuttosto che la realizzazione ex-novo di una
componente che svolgesse le funzionalità richieste. Per
componente si intende qui un’applicazione commerciale, ovvero un
COTS. Dopo una breve introduzione ai COTS, verranno approfonditi
i COTS utilizzati, soffermandosi solo sulle caratteristiche utilizzate
durante lo sviluppo del sistema.
5.2.1Commercial
5.2.1Commercial Off-The Shelf (COTS)
Un Commercial Off-The Shelf (COTS) è un prodotto software:
• Sviluppato da un’organizzazione di terze parti, che
controlla il supporto e l’evoluzione di tale prodotto;
• Posseduto, comprato o pagato su licenza;
• Che ha lo scopo di essere integrato in un sistema di
dimensioni più ampie come una parte integrante, ovvero
che sarà poi fornito al cliente come una parte del sistema
e non come un tool;
• Che permette o non permette modifiche al proprio codice
sorgente;
• Che include meccanismi di personalizzazione;
• Posseduto e utilizzato da un numero significativo di
sviluppatori di sistemi.
I sistemi basati su COTS (CBS, COTS-based systems)
includono prodotti COTS a fianco di componenti software sviluppate
ex-novo all’interno dell’organizzazione (ci si riferisce a tali
componenti con il termine “in-house”). La caratteristica più
importante dei prodotti COTS è la loro predisposizione
all’integrazione in sistemi differenti e la loro disponibilità
commerciale. Questi aspetti permettono ai COTS di fornire
funzionalità preconfezionate di alta qualità. Inoltre, l’uso di COTS
come componenti di un nuovo sistema può ridurre lo sforzo nello
sviluppo e incrementare la qualità del sistema stesso. Come
risultato, lo sviluppo CBS può aiutare in modo significativo gli
sviluppatori nel costruire un prodotto migliore in tempi brevi.
Comunque, lo sviluppo CBS può introdurre alcuni specifici
problemi:
• Valutazione: i prodotti COTS vanno valutati per decidere se
devono o non devono essere usati durante la fase di
sviluppo;
54
• Integrazione: componenti software sviluppate in-house e

prodotti COTS hanno le proprie assunzioni riguardo
interfacce, packaging, funzionalità e altro; se queste
assunzioni sono differenti, sarà necessario un lavoro di
integrazione per fare in modo che i prodotti COTS lavorino
all’interno del sistema;
• Sicurezza: i COTS possono essere sorgente di potenziali
rischi riguardo la sicurezza, permettendo ad esempio
comportamenti pericolosi dovuti a virus o anche
semplicemente dovuti a malfunzionamenti accidentali;
• Manutenzione: essendo i prodotti COTS soggetti a
frequenti aggiornamenti da parte dei loro produttori,
incompatibilità di versione possono essere causa di
problemi di manutenzione seri.
Questi problemi possono a volte ostacolare lo sviluppo CBS,
creando rischi di non rispetto di scadenze o di deterioramento della
qualità del prodotto.
55
5.2.2Plumtree
5.2.2Plumtree Corporate Portal 4.5
5.2.2.1Enterprise
5.2.2.1Enterprise Web
L’Enterprise Web è un ambiente aperto che ha lo scopo di
gestire e fornire applicazioni Web. L’Enterprise Web combina servizi
provenienti da fornitori differenti all’interno di uno strato
tecnologico che racchiude piattaforme rivali e sistemi di business,
creando le fondamenta per la costruzione a basso costo di
applicazioni. Queste fondamenta sono costituite dai servizi più
comunemente utilizzati dalle applicazioni Web, inclusi integrazione,
collaborazione, lavoro cooperativo, gestione contenuti e ricerca.
Tutti questi servizi lavorano insieme attraverso i Web Services. Il
portale è il framework per la distribuzione delle applicazioni create
a partire da queste fondamenta. Il risultato è un ambiente che
comprende l’intera organizzazione, aperto a tutte le piattaforme e
disponibile a tutti i tipi di utenti.
Fornendo delle fondamenta comuni per le applicazioni Web
costruite su qualsiasi piattaforma, diminuisce i costi di
infrastruttura e di sviluppo. L’integrazione di risorse provenienti da
sistemi differenti in applicazioni Web, aumenta il ritorno economico
di questi sistemi. La creazione di un’interfaccia comune per gli
utenti di un’organizzazione, favorisce la collaborazione e aumenta
la produttività dell’organizzazione stessa, aumentandone i profitti.
L’Enterprise Web consiste di quattro elementi (Figura 5-35):
• Servizi di base (Foundation Services): i servizi di base
comunemente utilizzati per costruire applicazioni Web;
• Sistemi di integrazione (Integration Products): componenti
che integrano contenuti, altre applicazioni e sicurezza a
partire da sistemi esistenti, quali sistemi di Groupware,
ERP e CRM;
• Portale (Portal Platform): il framework per la
personalizzazione, l’amministrazione e il knowledge
management, capace di racchiudere insieme un vasto
insieme di risorse in formato elettronico attraverso
un’interfaccia di tipo Web-based;
56
• Applicazioni composte (Composite Applications):

applicazioni Web ospitate all’interno del portale e che
combinano i servizi provenienti da diversi sistemi, a loro
volta gestiti all’interno di processi di business comuni.
Figura 5 - 35 : Una visione globale dell’Enterprise Web secondo Plumtree
L’architettura dell’Enterprise Web è basato su tre principi:

• Basata su Internet: mentre i sistemi client-server
dipendono generalmente su connessioni sulla rete locale
tra database, application server e applicazioni, l’Enterprise
Web si basa sul protocollo HTTP, il quale può coprire
diverse reti superando le barriere dell’organizzazione;
• Cross-Platform: mentre le applicazioni client-server
tipicamente ospitano ogni componente dell’applicazione su
un singolo application server, l’Enterprise Web usa i Web
Services per combinare componenti provenienti da diversi
application server, assicurando che l’Enterprise Web
stesso rimanga aperto a infrastrutture di organizzazioni
eterogenee;
• Estendibile: mentre le applicazioni client-server sono
basate sulla loro business logic, la quale può essere
modificata solo con grandi sforzi economici e di tempo,
l’Enterprise Web è progettato per essere flessibile ed
estendibile, integrando gli altri sistemi in modo da
57
massimizzare il ritorno sugli investimenti (ROI, Return On

Investment 1 6 ).
All’interno dell’Enterprise Web il portale fornisce un framework
per creare e gestire applicazioni dell’Enterprise Web, basate sia su
servizi di base sia su risorse integrate da altri sistemi. Mentre la
maggior parte dei portali attualmente sul mercato permettono agli
amministratori di creare pagine che mostrano elementi provenienti
da diverse applicazioni, recentemente sta emergendo una nuova
generazione di portali che possono ospitare non solo semplici
pagine, ma anche applicazioni Web sofisticate costruite a partire da
componenti dell’Enterprise Web. Tutto ciò richiede:
• Applicazioni composte: il portale ospita applicazioni Web
differenti, ognuna delle quali possiede domini e ruoli
amministrativi separati, presentando all’utente
un’interfaccia più flessibile;
• Servizi di base: il portale gestisce i servizi di base come
parte del processo alla base dell’applicazione,
permettendo agli amministratori del portale di assemblare
velocemente nuove applicazioni basate su questi servizi;
• Integrazione dei processi di business: il portale instrada i
dati attraverso diversi servizi di base e sistemi tradizionali,
permettendo ai processi di business di estendersi su
diverse tecnologie;
• Usage tracking: il portale tiene sotto controllo gli interessi
e le attività degli utenti delle diverse applicazioni, in modo
da personalizzare le risorse dell’Enterprise Web sulla base
degli interessi degli utenti.
5.2.2.2Architettura
5.2.2.2Architettura e caratteristiche di Plumtree Corporate Portal 4.5
Prima di analizzare l’architettura del sistema, si premette che
nel seguito non verranno analizzate tutte le caratteristiche di
questo sistema. Tale scelta è dovuta alla vastità eccessiva delle
funzionalità di un sistema delle dimensioni di un portale e al fatto
che non tutte queste funzionalità sono state poi utilizzate
all’interno del sistema realizzato per questo lavoro di tesi.
Dopo questa doverosa premessa, analizziamo l’architettura di
Plumtree Corporate Portal 4.5 (nel seguito Plumtree).
Plumtree è basato su un modello di architettura distribuita che
separa le funzioni su server logici e fisici separati in modo da
massimizzare sia la scalabilità che la tolleranza ai guasti dell’intero
sistema. L’architettura è progettata per servire un gran numero di
16
In un'organizzazione, per un determinato utilizzo di denaro, il ROI (Return On
Investment) coincide con quanto di questo denaro "ritorna", tipicamente
corrisponde al profitto o al risparmio sui costi. Il calcolo del ROI a volte è usato
insieme ad altri approcci per sviluppare una strategia di business per un
determinato obiettivo. Il ROI totale di un'organizzazione è a volte usato per
capire quanto bene sia gestita tale organizzazione.
58
utenti contemporaneamente, nascondendo loro la latenza che si

manifesta come risultato di un sistema sottostante lento o
malfunzionante.
L’architettura è composta da diverse componenti:
• Backend database standard: il backend database, che
immagazzina tutti i metadati di Plumtree, risiede su un
comune database relazionale, tipicamente Oracle 8i o SQL
Server 7 e può essere in esecuzione sia un sistemi
Windows NT sia su UNIX. La connessione con il database
avviene attraverso ODBC;
• Gestore distribuito dei compiti: i server che gestiscono in
modo asincrono i compiti di manutenzione ordinaria di
Plumtree, sono fisicamente e logicamente separati dai
server Web che servono gli utenti, in questo modo la
scalabilità del Web server non è mai compromessa da
operazioni complesse di backend come ad esempio il
controllo delle risorse, la pubblicazione di nuovi contenuti
e la sincronizzazione degli utenti appartenenti a varie
sorgenti di autenticazione;
• Gestore Web distribuito: un’installazione di Plumtree può
comprendere diversi server Web. Ci si riferisce spesso a un
server Web di Plumtree con il termine Portal Server
(PS);
• Gestore di applicazioni distribuito: i moduli che generano i
gadget, ovvero le componenti che interagiscono con le
applicazioni dell’organizzazione e i servizi su Internet per
costruire i gadget all’interno delle pagine del portale,
possono essere eseguiti su application server diversi, che
59
Figura 5 - 36 : Un portale Plumtree all'opera

prendono il nome di Gadget Server (GS) e che hanno la

funzione di isolare l’application logic dal server Web
centrale in modo da incrementare la scalabilità e la
stabilità dell’intero sistema. La comunicazione con i
gadget server avviene usando il protocollo HTTP,
attraverso il Massively Parallel Portal Engine
(MPPE), una componente software capace di gestire la
comunicazione con i vari GS in modo parallelo.
Plumtree integra applicazioni e servizi Internet all’interno di
pagine personalizzate del potale come Gadget Web Services (o
più semplicemente gadget). I gadget sono componenti modulari
che incorporano informazioni e servizi provenienti da applicazioni
dell’organizzazione e siti internet, come notizie economiche,
messaggi email, ecc…. L’interazione tra l’utente e i servizi offerti
dal portale avviene tramite i gadget. In Figura 5-36 è mostrata una
tipica pagina di Plumtree: nella parte superiore è composta da una
serie di strumenti per la navigazione all’interno del portale stesso,
nella parte inferiore sono disposti su più colonne i gadget (My
Bookmarks, Online Help, MyWeather e How To Get Started). I
gadget presenti sulla pagina e la loro disposizione sono
completamente personalizzabili dall’utente, così come è
personalizzabile il numero di colonne che compongono la pagina
(una, due o tre colonne), la colorazione e la lingua con cui
rappresentare il portale e i gadget (se progettati in più lingue).
Gli amministratori di un portale Plumtree possono offrire agli
utenti nuovi servizi semplicemente registrando questi gadget
all’interno del portale. Gli utenti potranno poi disporre a propria
discrezione i gadget all’interno di pagine personali. Oltre alle
pagine personali esistono particolari pagine, dette di comunità, il
cui contenuto viene invece deciso dagli amministratori della
comunità.
I gadget elaborano e scambiano informazioni interagendo con
database, applicazioni e Web Services e presentando i dati come
XML o HTML al Portal Server, affinché questo possa mostrarli
all’interno di pagine personalizzate. Un Gadget Web Service è
quindi una qualsiasi applicazione Web che restituisce documenti
HTML o XML attraverso il protocollo HTTP.
I gadget sono sviluppati come componenti del portale che
operano su server separati dal Portal Server principale, tali gadget
vengono denominati remoti. In realtà è possibile sviluppare e
distribuire gadget anche sul Portal Server, questi gadget vengono
detti nativi. I gadget remoti usufruiscono di tutti i vantaggi del
MPPE (esecuzione parallela, bilanciamento del carico e tolleranza ai
guasti). I gadget nativi invece essendo eseguiti sul Portal server
possono creare ripercussioni negative sulle prestazioni del portale
o nel peggiore dei casi, cioè un errore di esecuzione del gadget,
creare un malfunzionamento nell’intero portale. L’uso dei gadget
remoti è comunque consigliato a quello dei nativi, a meno che non
siano richieste chiamate alle API di basso livello del portale.
60
L’architettura generale del sistema è un’architettura a tre livelli

(raffigurata in Figura 5-37). Il primo livello è composto da uno o più
Portal Server, i quali costruiscono le pagine del portale e
gestiscono le richieste degli utenti. Il secondo livello è composto
dai Gadget Server, i quali ospitano i Gadget Web Service, che sono
poi usati dal Portal Server per costruire le pagine. Il terzo livello è il
livello di tipo Application ed è composto dalle applicazioni dalle
quali il portale estrae le risorse attraverso i Gadget Web Service.
Quest’ultimo livello non appartiene al framework del portale.
Il Portal Server comunica con i Gadget Server usando il
protocollo HTTP, mentre i Gadget Server comunicano con il livello
inferiore con un protocollo che può variare a seconda del sistema
utilizzato: RMI, CORBA, SOAP, COM, .Net, ecc…. I Gadget Server,
essendo collegati al Portal Server in HTTP con un’architettura a
basso accoppiamento, possono essere distribuiti in qualunque
Figura 5 - 37 : Architettura di Plumtree
luogo su Internet o sulla rete locale dell’organizzazione.

Quando il browser di un utente richiede una pagina del portale,
il Portal Server effettua simultaneamente le richieste a ogni Gadget
Server (usando il MPPE). Ogni Gadget Server legge le preferenze
61
utente (contenute nel database del portale) e invia la pagina HTML

o il documento XML risultato dell’elaborazione. A questo punto il
Portal Server trasforma l’eventuale documento XML, e inserisce la
parte HTML all’interno della pagina. Il portale è accessibile anche
mediante dispositivi diversi dal comune browser per PC desktop:
Plumtree infatti supporta browser per dispositivi mobili come
telefoni cellulari e PDA.
Sulla connessione tra i vari livelli bisogna porre particolare
attenzione: il Portal Server agisce da server gateway per i Gadget
Server. Una configurazione di questo tipo è usata tipicamente per
fornire contenuto a client che senza di esso non potrebbero
accedere al server d’origine, ma può anche essere usata per
imporre ulteriori restrizioni di sicurezza. Il server gateway nasconde
l’esistenza del server d’origine all’utente finale, il contenuto infatti
appare come proveniente direttamente dal server gateway.
Quest’architettura rende il Portal Server l’unico punto di accesso al
contenuto dei Gadget Web Service e permette ai Gadget Server di
risiedere su una rete privata oppure pubblica ma protetta da un
firewall, come mostrato in Figura 5-38. Ogni gadget ha associata
una collezione di URL per le quali il Portal Server agisce da
gateway. Questa
collezione di URL è
chiamata Gateway
Space (spazio del
gateway). Uscire dal
Gateway Space
significa uscire dal
portale.
5.2.2.3Gli
5.2.2.3Gli utenti in
Plumtree
In Plumtree esistono
due tipi di utenti:
utenti anonimi e utenti
registrati. Un utente
Figura 5 - 38 : Il Gateway Space
anonimo è chiunque
acceda alla pagina
principale del portale ma non possiede login e password per
accedere al portale. Un utente registrato invece è un utente
abilitato ad accedervi in quanto dotato di login e password.
Esistono diversi modi per registrare un utente sul portale: un
amministratore può registrare l’utente creando un account sul
portale, oppure si può permettere agli utenti di registrarsi da soli
attraverso il portale stesso, oppure si possono invitare utenti a
registrarsi da soli sul portale o ancora si possono importare utenti
da un dominio NT o un server LDAP.
62
A ogni utente è assegnato un gruppo e a ogni gruppo sono

associati dei ruoli. I ruoli disponibili sono quattro: Administrator
(amministratore), Content Manager (gestore dei contenuti),
Content Maintainer (fornitore dei contenuti) oppure Browsing
User (utente generico). I ruoli fondamentali in realtà sono
l’amministratore e l’utente generico.
Un utente generico è in
grado di creare pagine
personali, aggiungervi
contenuti scegliendo i
gadget di proprio
interesse, personalizzare
l’aspetto del portale
(colorazione e lingua),
accedere alla
documentazione ed
effettuare ricerche. In
ogni caso ogni oggetto
del portale sarà
accessibile solo se il suo
gruppo di appartenenza è
abilitato ad accedervi, in
caso contrario non saprà
mai dell’esistenza di tali
oggetti. Un
amministratore è un
utente normale con in
aggiunta dei diritti che gli
permettono di accedere
sia a tutti gli oggetti nel
portale sia di gestirne le
modalità di accesso, sia
di cambiare parametri e
gestire configurazioni di
basso livello del portale Figura 5 - 39 : Funzionalità per
(ad esempio Gadget amministratori
Server collegati al Portal
Server, parametri di connessione al database, ecc…). Un
amministratore è dotato di una pagina particolare che contiene una
serie di strumenti per la gestione del portale. In Figura 5-39 viene
mostrato il menu che compare nella pagina di amministrazione di
Plumtree con tutti i gruppi di funzionalità disponibili, mentre in
Figura 5-40 viene mostrato un esempio di una pagina di uno dei
wizard che permettono di configurare il portale (in particolare i
parametri di sicurezza di un gadget).
63
Figura 5 - 40 : La pagina di un wizard dell'amministratore
Riguardo i gruppi, Plumtree ne fornisce di predefiniti due:

Administrators (amministratori del portale) e Everyone (tutti gli
utenti del portale), ma agli amministratori del portale è consentito
crearne di nuovi e inserire al loro interno gli utenti registrati. Un
utente registrato appartiene comunque al gruppo Everyone.
5.2.2.4Sviluppo
5.2.2.4Sviluppo di gadget
Gli sviluppatori di gadget possono scrivere il codice per generarli
usando appositi kit di sviluppo chiamati Gadget Development
Kits (GDK) specifici per un particolare linguaggio o piattaforma. Le
funzioni nel GDK agiscono come API per accedere e gestire
preferenze e informazioni amministrative. I GDK attualmente
disponibili sono per tecnologia ASP, Java, .Net, Perl e Coldfusion, e
sono del tutto equivalenti come funzionalità. Essendo i GDK
disponibili per i più importanti ambienti di sviluppo,
un’organizzazione che sceglie Plumtree può sviluppare i propri
gadget usando il o i linguaggi con cui i propri sviluppatori sono più
esperti, o una qualsiasi combinazione di linguaggi e piattaforme
server (i Gadget Server infatti sono disponibili per piattaforma
Windows 2k/NT, Linux e Sun Solaris) in modo da realizzare
integrazione di sistemi anche eterogenei.
Come detto, i cinque kit di sviluppo sono del tutto equivalenti e
forniscono le medesime funzionalità. Ogni kit di sviluppo una volta
installato sul Gadget Server (o un sistema usato solo per lo
sviluppo) permette di accedere a una serie di componenti che
mettono a disposizione particolari oggetti usati per interagire con il
portale.
L’interfaccia verso il portale è chiamata GSServices e contiene
una serie di oggetti ognuno dotato di una moltitudine di metodi che
rendono possibile controllare la maggior parte dell’interazione col
64
portale: l’oggetto Sett ings include una serie di metodi che

forniscono l’accesso ai settaggi sul Portal Server. L’oggetto Caching
permette la gestione dell’intestazione standard dei messaggi HTTP
per il controllo della cache. L’oggetto Localization permette di
gestire la localizzazione e internazionalizzazione dei gadget e
l’oggetto Encryption si occupa di tutta la gestione della crittografia
dei dati sensibili.
L’oggetto più importante però è Settings, in quanto contiene un
gran numero di metodi e perché in Plumtree viene data molta
importanza e attenzione ai settaggi. Un Gadget Web Service infatti
usa cinque tipi di Settaggi per personalizzare il contenuto:
Gadget, Administrative, User, Community e Community Gadget.
Tutti i settaggi sono trasmessi attraverso l’intestazione delle
richieste e risposte HTTP e sono disponibili solo a pagine che
appartengono al Gateway Space.
In particolare:
• I settaggi Gadget si applicano a un gadget e a un utente.
L’utilizzo tipico è quello di permettere all’utente di
personalizzare l’aspetto del gadget a seconda dei suoi
gusti;
• I settaggi Administrative si applicano a un gadget per
tutti gli utenti. L’utilizzo tipico è quello di configurare
parametri particolari per la connessione nel backend del
Gadget Server oppure configurare l’aspetto di un gadget
per tutti gli utenti che lo utilizzano. Quindi questo tipo di
settaggi sono di solito modificabili solo dagli
amministratori e non dagli utenti normali del portale;
• I settaggi User si applicano a un utente e a tutti i gadget
di cui usufruisce. L’utilizzo tipico è quello di memorizzare
alcuni dati dell’utente che saranno poi condivisi da tutti i
gadget che utilizza nel portale (ad esempio login,
password, email, indirizzo, numero telefonico, ecc…);
• I settaggi Community si applicano a tutti i gadget e a
tutti gli utenti di una particolare comunità. L’utilizzo tipico
è modificare i contenuti mostrati all’interno di una
comunità;
• I settaggi Community Gadget si applicano a un gadget
in una comunità, per tutti gli utenti di tale comunità.
L’utilizzo tipico è configurare dei parametri che saranno
condivisi da tutti i gadget visualizzati nella stessa
comunità.
In Tabella 5-2 viene riassunto quanto detto.
65
SI APPLICA A :
T IPO S ETTAGGIO
U TENTE G ADGET
Gadget Uno in particolare Uno in particolare

Administrative Tutti Uno in particolare
User Uno in particolare Tutti

Tutti in una Tutti in una
Community
particolare comunità particolare comunità
Tutti in una Uno in particolare
Community Gadget
particolare comunità
Tabella 5 - 2 : I settaggi di Plumtree
Tramite l’oggetto Settings è possibile leggere, modificare e

cancellare tutti i settaggi di un particolare tipo, oltre che crearne di
nuovi. E’ possibile usare i settaggi anche per immagazzinare dati
dalle dimensioni maggiori di quelle di un indirizzo email o di un
numero telefonico. Questa caratteristica è particolarmente utile in
quanto, essendo i settaggi immagazzinati nel database del portale,
la loro persistenza può andare oltre quella ad esempio dei tipici
settaggi di sessione o di applicazione di un normale server Web.
Sono presenti anche metodi per gestire da codice la navigazione
tra le pagine del portale, cambiarne la modalità di visualizzazione,
ma anche per ottenere particolari informazioni come i fogli di stile
usati nel portale.
66
67
5.2.3Microsoft
5.2.3Microsoft Excel 2000
Microsoft Excel 2000 è una delle applicazioni comprese nella
suite di prodotti denominata Microsoft Office 2000. Le
funzionalità svolte da Excel sono principalmente quelle svolte da
un tipico foglio di calcolo con in aggiunta alcune funzionalità
specifiche per la produzione di statistiche e analisi di tipo semplice
e reportistica in forma tabellare o grafica. Piuttosto che descrivere
in modo approfondito l’applicazione, è molto più interessante
descrivere le modalità di integrazione offerte.
Ogni applicazione della suite Microsoft Office contiene un
insieme di tool progettati per svolgere un ben determinato insieme
di compiti tra loro correlati. Ogni applicazione può anche essere
integrata con altre della stessa suite o di produttori diversi, in
modo da creare nuove applicazioni dalle funzionalità estese.
La tecnologia chiave che rende le applicazioni Office
“programmabili” e integrabili è la tecnologia Component Object
Model (COM) chiamata Automation (in passato conosciuta con il
nome di OLE Automation). Automation permette a uno sviluppatore
di creare e controllare, nel proprio codice, oggetti esposti da
un’applicazione, da una Dynamic-Link Library (DLL) o da un
controllo ActiveX che supporti l’interfaccia COM.
La possibilità di sviluppare software che integri al suo interno
applicazioni Office dipende quindi pesantemente sull’architettura
software COM.
5.2.3.1Component
5.2.3.1Component Object Model (COM)
Il Microsoft Component Object Model (COM) è un sistema
indipendente dalla piattaforma, distribuito e object-oriented per
creare componenti software binari che possono interagire tra loro.
COM e tutte le tecnologie basate su di esso (come OLE e ActiveX)
non sono un linguaggio object-oriented, bensì uno standard. COM
non specifica come un’applicazione debba essere strutturata: il
linguaggio, la struttura e i dettagli implementativi sono lasciati a
chi programma l’applicazione. Piuttosto, COM specifica un modello
di oggetti e di requisiti che rendono gli oggetti COM (anche dette
componenti COM, o anche semplicemente oggetti) capaci di
interagire con altri oggetti. Questi oggetti possono essere usati in
un processo, in più processi concorrenti, o anche su macchine
remote. Possono essere scritti in linguaggi diversi ed essere anche
strutturalmente differenti.
L’unico requisito del linguaggio per COM è che questo linguaggio
possa creare strutture di puntatori ed effettuare chiamate di
funzione tramite puntatori in modo esplicito o implicito.
Attualmente una componente COM può essere creata in linguaggi
object-oriented come C++, Smalltalk, ma anche in C, Pascal, ADA,
e Visual Basic.
68
In generale un oggetto software è costituito da un insieme di

dati e da funzioni che manipolano questi dati. Un oggetto COM è un
oggetto in cui l’accesso ai suoi dati avviene esclusivamente
attraverso una o più funzioni correlate. Questi insiemi di funzioni
sono chiamati interfacce e le funzioni delle interfacce sono dette
metodi, rispettando la classica nomenclatura usata nella
letteratura dello sviluppo per componenti.
L’architettura software COM permette agli sviluppatori software
di costruire applicazioni e servizi a partire da single componenti
software. Una componente COM consiste dei file fisici compilati che
contengono classi. Esistono due tipi di componenti COM:
componenti in-process e componenti out-of-process. Le componenti
in-process sono sia DLL sia controlli ActiveX (di solito file .ocx) e
possono essere eseguite solo all’interno del processo di
un’applicazione. Le componenti out-of-process sono file
eseguibili (.exe) e sono eseguiti come applicazioni autonome. Il
sistema operativo Windows e la suite di applicazioni Office sono
esempi di prodotti sviluppati usando l’architettura software COM.
Un’applicazione consiste fondamentalmente di due elementi: il
contenuto e le funzionalità. Il contenuto si riferisce alle
informazioni all’interno delle applicazioni, ovvero documenti, fogli
di calcolo, tabelle e alle informazioni che questi oggetti
contengono. Il contenuto si riferisce anche alle informazioni
riguardo gli attributi dei singoli elementi nell’applicazione
(dimensioni della finestra, colore degli elementi grafici, ecc…). Le
funzionalità si riferiscono a tutte le modalità in cui è possibile
lavorare con il contenuto dell’applicazione, per esempio aprire,
chiudere, stampare, inviare copiare il contenuto nell’applicazione.
Il contenuto e le funzionalità che costituiscono un’applicazione,
sono presentati a un linguaggio quale Visual Basic come unità
discrete chiamate oggetti. Di solito l’insieme degli oggetti esposti
da un’applicazione corrispondono a tutti gli oggetti che possono
essere usati nell’applicazione usando la sua interfaccia grafica.
69
Gli oggetti esposti da un’applicazione sono collegati tra loro

mediante delle relazioni gerarchiche. In un’applicazione Office (ma
questa pratica è seguita anche da altre applicazioni di produttori
differenti) l’oggetto principale è un oggetto chiamato Appl icat ion, il
quale rappresenta l’applicazione stessa. L’oggetto App l i ca t ion
contiene altri oggetti ai quali si può accedere solo quando l’oggetto
App l i ca t ionesiste (ovvero quando è in esecuzione una istanza
dell’applicazione stessa). Ad esempio l’oggetto Application di Excel
contiene gli oggetti Workbook, i quali, dipendendo dall’esistenza
dell’oggetto Application, vengono definiti suoi oggetti figli (child
object), così come l’oggetto Application è detto oggetto genitore
(parent object).
Ovviamente gli oggetti figli possono avere altri figli, per esempio
l’oggetto Workbook contiene l’oggetto Worksheets. In particolare
Figura 5 - 41 : La gerarchia di oggetti di Microsoft Excel 2000
questo oggetto è di tipo speciale ed è chiamato collection

(collezione) e rappresenta un insieme di oggetti. In Figura 5-41
viene mostrata la gerarchia di oggetti di Microsoft Excel 2000 (la
colorazione distingue gli oggetti semplici in azzurro dalle collection
in giallo).
Ogni oggetto oltre a contenere oggetti figli, comprende anche
contenuti e funzionalità che si applicano sia all’oggetto stesso sia a
tutti gli oggetti figli. Per manipolare contenuti e funzionalità di un
oggetto si usano le proprietà e i metodi dell’oggetto stesso.
70
Utilizzare una componente COM all’interno del proprio codice,

grazie ai tool di sviluppo attualmente sul mercato, è una pratica
semplicissima e del tutto simile alla creazione di una istanza di una
normalissima classe e all’invocazione dei suoi metodi o accesso ai
suoi attributi. In Figura 5-42 è mostrato un esempio di utilizzo di
Excel mediante la sua interfaccia COM all’interno di una procedura
scritta in Visual Basic. In questo semplice esempio è possibile
riconoscere alcune pratiche ricorrenti di cui si è parlato in
Figura 5 - 42 : Un esempio di utilizzo di Excel mediante COM
precedenza, in particolare la preventiva creazione di un’istanza

dell’oggetto App l i c a t i on(linea 8) e l’accesso ai suoi oggetti (linea
21) e collection (linea 11) mediante invocazione di metodi (linea
24) e accesso agli attributi (linea 21). Infine la distruzione di tutte
le istanze create in precedenza (linee 28 e 29).
71
5.2.4Statsoft
5.2.4Statsoft Statistica 6 DA-DM-QC
Statistica è un’applicazione completa e integrata per l’analisi dei
dati, la creazione di grafici, l’analisi di basi di dati e lo sviluppo di
applicazioni personalizzate, che fornisce una serie di procedure
avanzate di analisi per applicazioni finanziarie, di data mining,
scientifiche e ingegneristiche.
5.2.4.1Statistical
5.2.4.1Statistical Process Control
La versione utilizzata di Statistica è denominata Statistica 6
DA-DM-QC, dove DA è acronimo di Data Analysis, DM di Data
Mining e QC di Quality Control e contiene una serie di
funzionalità extra rispetto alla versione di base del pacchetto
(chiamata Base). In questa versione, tra tutte le funzionalità
presenti, quelle utilizzate durante la realizzazione del progetto
sono quelle presenti nella parte Quality Control. Tramite le analisi
presenti nel Quality Control è possibile effettuare il controllo
statistico dei processi (SPC, Statistical Process Control),
ovvero un utile strumento statistico per il controllo della stabilità e
della capacità di un processo, oltre che per l’individuazione delle
variazioni nelle prestazioni di un processo dovute a cause
eccezionali.
Lo SPC sfrutta una molteplicità di grafici di controllo
(Control Chart s). Un grafico di controllo, fa riferimento ad una
prefissata caratteristica di un processo, che viene valutata
determinando una misura della tendenza centrale e i limiti (detti
limiti di controllo) entro i quali si disperdono le osservazioni. Se le
osservazioni ricadono entro i limiti individuati e si distribuiscono
uniformemente attorno alla tendenza centrale, allora non ci sono
eventi singolari nel processo. Osservando la Figura 5-43, in blu
vengono rappresentati i valori della caratteristica osservata, le due
Limite Superiore
Tendenza Centrale
Limite Inferiore
72
Figura 5 - 43 : Esempio di grafico di controllo

linee rosse rappresentano i limiti superiore e inferiore, mentre la

linea nera centrale rappresenta la tendenza centrale.
In particolare tra i vari grafici di controllo disponibili, è stato
scelto il grafico Individual & moving range anche chiamato X
and Moving R Chart (XmR), del quale viene mostrato un
esempio in Figura 5-44.
Figura 5 - 44 : Esempio di grafico X and Moving R
Questo grafico in realtà è composto da 2 grafici, ognuno

accompagnato da un grafico che ne mostra la rappresentazione
come istogramma:
• X (individual) chart: rappresenta la media delle medie
delle singole osservazioni. La tendenza centrale è riferita
alla totalità delle misure disponibili;
• Moving range chart: la media degli intervalli delle singole
osservazioni, usata per valutarne la dispersione. Per il
calcolo dell’intervallo si utilizza la differenza tra due
rilevazioni successive (2 points moving range).
La valutazione della stabilità avviene osservando il grafico XmR,
in particolare i valori che ricadono fuori dai limiti inferiore e
superiore sono indici di instabilità. Di solito questi valori vengono
73
rappresentati con un punto rosso più marcato rispetto ai valori

normali. La capacità invece viene valutata attraverso gli
istogrammi che accompagnano i grafici XmR.
5.2.4.2Modalità
5.2.4.2Modalità di integrazione e programmazione
Così come avviene in Microsoft Excel 2000, anche in Statistica,
grazie a COM, tramite il modello di oggetti è possibile accedere
all’architettura completa del sistema. La libreria di oggetti di
Statistica offre la possibilità di accedere a ogni aspetto
dell’ambiente operativo dell’applicazione: analisi, grafici, query sul
database, documenti e ogni aspetto dell’interfaccia grafica
dell’applicazione stessa. Tutto quello che è stato detto riguardo
COM nei paragrafi relativi a Excel, vale anche per Statistica.
Esistono diversi metodi in cui sviluppare applicazioni che si
interfacciano con Statistica:
• Registrare una macro. Quando si esegue un’analisi o si
crea un grafico, il codice Visual Basic corrispondente a
tutte le specifiche grafiche o alle operazioni di output,
sono registrate automaticamente in background. Questo
codice può poi essere personalizzato, parametrizzato ed
eseguito come macro;
• Utilizzare l’ambiente di sviluppo di Statistica Visual
Basic (SVB ). E’ possibile scrivere codice usando
direttamente l’ambiente di sviluppo integrato
nell’applicazione principale. Tale ambiente, mostrato in
Figura 5-45, presenta funzioni avanzate come
completamento del codice, aiuto in tempo reale, editor
visuale di form e debugger. Il codice scritto in questo
modo può poi essere salvato come macro e riutilizzato;
74
Figura 5 - 45 : L'ambiente di sviluppo interno delle macro
• Accedere al modello di oggetti da altre applicazioni. Grazie

a COM, è possibile utilizzare un qualsiasi ambiente di
sviluppo e un qualsiasi linguaggio di programmazione che
supporti tale tecnologia per scrivere codice che utilizzi il
modello di oggetti di Statistica. In particolare è possibile
sfruttare il codice generato automaticamente durante la
registrazione delle macro per scrivere con poco sforzo
programmi in Visual Basic che integrino al proprio interno
le funzionalità di Statistica. Oltre all’interfaccia COM,
StatSoft fornisce anche supporto per il .Net Framework
tramite delle particolari classi wrapper (consultare i
paragrafi successivi per maggiori dettagli). Attualmente
però non tutti gli oggetti dell’applicazione presentano il
supporto per .Net Framework, in particolare sono
supportati solo gli oggetti di base e quelli relativi ai
grafici. Nonostante ciò, è ancora possibile usufruire di
tutte le funzionalità (anche quelle appartenenti alle
estensioni come DA-DM-QC) scrivendo delle macro con
l’editor interno e richiamando tali macro dal codice
esterno.
5.2.5Applix
5.2.5Applix iEnterprise CRM
Con il termine CRM (Customer Relationship Management,
gestione relazioni con la clientela), si intendono le metodologie, il
software e le capacità offerte da Internet che aiutano
75
un’organizzazione a gestire le relazioni con i clienti in modo

organizzato. Per esempio, un’organizzazione potrebbe costruire un
database sui propri clienti che descriva le relazioni in dettagli che
permettano al management, a chi fornisce i servizi e al cliente
stesso di accedere direttamente a queste informazioni, di
soddisfare le necessità dei clienti con prodotti e offerte, di
segnalare le richieste dei clienti, di conoscere quali altri prodotti
sono stati acquistati da un cliente, ecc….
Applix iEnterprise CRM viene definito dal suo produttore un
iCRM, dove la “i” indica la natura Internet-based del sistema. La
soluzione offre all’organizzazione l’abilità di gestire e analizzare i
dati sui clienti, così come offre una soluzione collaborativa che
estende l’accesso ai dati a clienti, impiegati e partner. Nella
transizione dal business al business su Internet, le organizzazioni
affrontano nuove problematiche su come espandere le proprie
operazioni da un’ottica locale a una globale. In particolare è offerta
la possibilità di ospitare l’intero sistema su un sito centrale e
rendere disponibile l’accesso agli utenti da ogni parte del mondo e
in qualsiasi momento, attraverso un semplice browser Internet.
5.2.5.1Modalità
5.2.5.1Modalità di integrazione e programmazione
Applix fornisce come tutti i sistemi analizzati finora la possibilità
di accedere ai suoi oggetti da altre applicazioni. In particolare
viene fornita sia un’interfaccia COM per ambienti Microsoft, sia
un’interfaccia Java per ambienti Java. Ciò che però rende Applix
particolarmente portato per un’integrazione all’interno di
un’applicazione Web o un portale è l’interfaccia denominata
Weblink 2000.
Weblink 2000 è un sistema che permette di eseguire le
applicazioni di Applix all’interno di un browser web. Queste
applicazioni sono le stesse a cui si può accedere tramite il client
standard di Applix, ma sono ospitate sul sito Web
dell’organizzazione. L’interfaccia per utilizzare Weblink 2000 è
chiamata Weblink 2000 API e si appoggia sul server Web Microsoft
IIS, su piattaforma Windows 2k/NT. In Figura 5-46 viene riportata
l’architettura del sistema risultante.
76
Figura 5 - 46 : Architettura del sistema
Weblink 2000 include una serie di componenti che sono richieste

da una qualunque applicazione Weblink 2000:
• EntWeb.dll ed EntWeb.js. Tutte le funzioni della
Weblink 2000 API sono definite in queste due componenti.
EntWeb.dll è un oggetto COM, mentre EntWeb.js è un
insieme di funzioni javascript che hanno lo scopo di
rappresentare graficamente in formato Web-based (form
HTML) gli elementi grafici delle applicazioni;
• EntWeb.cssx. il foglio di stile usato per rappresentare
graficamente gli elementi delle applicazioni (colori, stile e
dimensioni carattere, ecc…);
• Enterprise.dll. Una componente COM che permettere di
accedere agli oggetti all’interno del database di Applix.
Applix infatti archivia tutte le informazioni sulle
applicazioni sviluppate con esso all’interno del database.
Di tutte le componenti appena citate, la più importante è la
EntWeb.dll. Questa infatti contiene una serie di funzioni per il
login/logout al sistema, l’estrazione dei form che compongono
l’applicazione, la lettura e modifica dei valori nei form, ecc….
In Figura 5-47 viene mostrato un esempio di applicazione Applix
utilizzata da un comune browser Web. Si può notare come
l’interfaccia utente, nonostante sia in HTML, riproduca il più
possibile una comune interfaccia utente Windows-based.
77
Figura 5 - 47 : Un esempio di applicazione usata via Web
Un’altra modalità di integrazione è quella data driven. Un

sistema CRM infatti fa un uso pesante del database, archiviando al
suo interno tutte le informazioni delle applicazioni, più ulteriori
informazioni di supporto e monitoraggio dell’utente. Per i sistemi
che fanno elaborazioni statistiche su queste informazioni, l’accesso
diretto alla base di dati rappresenta una modalità di integrazione
semplice e veloce.
5.3 Tool di sviluppo e piattaforme utilizzate

Nei paragrafi successivi verranno presentati tutti i tool di
sviluppo e le piattaforme utilizzate durante la fase di sviluppo del
sistema. Di ogni tool e piattaforma verrà data una panoramica
generale e poi si approfondiranno solo le caratteristiche usate nel
sistema sviluppato.
5.3.1Microsoft
5.3.1Microsoft .Net
Microsoft .Net è un software che connette informazioni,
persone, sistemi e dispositivi cambiando radicalmente lo scenario
di elaborazione attuale: da un mondo in cui dispositivi e siti Web
sono semplicemente collegati a Internet a un mondo in cui
dispositivi, servizi e computer lavorano in modo cooperativo al fine
78
di fornire soluzioni più complete agli utilizzatori di tali servizi,

ovvero gli utenti.
Le componenti principali di .Net sono quattro:
• .Net Framework: un modello di sviluppo che permette agli
sviluppatori di costruire applicazioni Web-based,
applicazioni per smart client (ad esempio PDA, Personal
Digital Assistant), e Web Services, i quali espongono le
proprie funzionalità sulla rete usando protocolli standard
come SOAP e HTTP;
• Tool di sviluppo: un insieme di tool di sviluppo specifici per
.Net, come Microsoft Visual Studio .Net, i quali forniscono
un ambiente di sviluppo rapido e integrato (IDE,
Integrated Development Environment) per programmare
nel framework .Net;
• Server: un insieme di applicazioni server, come il sistema
operativo Microsoft Windows 2000/2003, il DBMS (Data
Base Management System) Microsoft SQL Server e
Microsoft BizTalk Server, i quali integrano, eseguono e
gestiscono applicazioni e XML Web Services;
• Client: un insieme di applicazioni, come Windows XP,
Windows CE, Office XP, i quali aiutano gli sviluppatori a
distribuire una soluzione completa all’interno di una
famiglia di dispositivi e prodotti esistente.
Delle quattro componenti, quella più interessante per gli
sviluppatori è la prima, ovvero .Net Framework, tanto che spesso ci
si riferisce a questa solo con il termine .Net.
5.3.1.1Microsoft
5.3.1.1Microsoft .Net Framework
.Net Framework è il modello di sviluppo per la costruzione,
distribuzione ed esecuzione di applicazioni Web-based e XML WS.
Esso si occupa dei dettagli di basso livello, permettendo allo
sviluppatore di concentrarsi più sul codice per la business logic
dell’applicazione.
Il .Net Framework è progettato per soddisfare alcuni obiettivi
primari, ovvero fornire:
• un ambiente di sviluppo object-oriented consistente,
all’interno del quale gli oggetti possono essere eseguiti
localmente, oppure eseguiti localmente ma distribuiti su
Internet, o anche eseguiti in remoto;
• un ambiente di esecuzione del codice che minimizzi
conflitti nella distribuzione del software o dovuti a
incompatibilità di versione;
• un ambiente di esecuzione del codice che garantisca
un’esecuzione sicura anche di codice creato da
79
un’organizzazione sconosciuta e non completamente di

fiducia;
• un ambiente di esecuzione del codice che elimini i
problemi di prestazione comuni agli ambienti di scripting o
interpretati;
• un ambiente di sviluppo consistente tra applicazioni che
vanno da applicazioni Windows-based ad applicazioni Web-
based;
• un ambiente di sviluppo che garantisca che tutto il codice
basato sul .Net Framework si integri perfettamente, grazie
al rispetto degli standard di comunicazione.
Per rispettare tali obiettivi, all’interno del framework sono

presenti due componenti principali: il Common Language Runtime
(CLR) e la Base Classes Library (BCL). In Figura 5-48 viene mostrato
il .Net Framework in una rappresentazione a livelli. I vari livelli
saranno trattati nel seguito.
Figura 5 - 48 : Il framework .Net
5.3.1.1.1C
5.3.1.1.1COMMON LANGUAGE RUNTIME (CLR)
Il Common Language Runtime (CLR) costituisce le
fondamenta del .Net Framework. Si può pensare ad esso come ad
un agente che gestisce il codice durante la sua esecuzione,
fornendo i servizi di base come gestione della memoria e della
concorrenza dei thread, oltre che forzare la tipizzazione forte e
altre forme di accuratezza sul codice e che insieme assicurano
sicurezza e robustezza delle applicazioni sviluppate. Infatti il
concetto di gestione del codice è uno dei principi fondamentali del
CLR. Il codice eseguito all’interno del CLR viene chiamato
managed code (codice gestito che compone applicazioni e
componenti gestite), mentre il codice eseguito all’esterno viene
80
chiamato unmanaged code (codice non gestito). Tutte le

caratteristiche di cui si è parlato in precedenza si riferiscono solo al
managed code.
Riguardo la sicurezza, le componenti con managed code hanno
assegnati vari livelli di sicurezza a seconda di vari fattori che
includono ad esempio la loro origine (Internet, la rete aziendale, il
computer locale). Ciò implica che una componente con managed
code può o non può essere in grado di eseguire tutte le operazioni
sensibili (come accesso ai file, accesso al registro di sistema,
ecc…). Il CLR rafforza la sicurezza del codice favorendo così la
distribuzione sicura di componenti.
Il CLR rafforza anche la robustezza del codice, implementando
una infrastruttura a forte tipizzazione e verifica del codice
chiamata Common Type System (CTS). Il CTS assicura che tutto
il managed code sia auto descrittivo e tutti i tool di sviluppo di
Microsoft e di terze parti generino managed code conforme al CTS.
Questo significa che il managed code può utilizzare altri tipi e
istanze con la sicurezza della fedeltà e sicurezza dei tipi.
In aggiunta, il CLR elimina alcuni problemi comuni del software.
Per esempio il CLR gestisce automaticamente i riferimenti agli
oggetti, rilasciando la memoria da loro occupata quando questi non
sono più necessari. La gestione automatica della memoria risolve i
due difetti più noti delle applicazioni, ovvero la perdita dei
riferimenti alla memoria e i riferimenti a indirizzi di memoria non
validi.
Una delle caratteristiche più importanti del CLR è la sua
interoperabilità cross-language. Uno sviluppatore può scrivere le
proprie applicazioni nel linguaggio di propria scelta, continuando a
beneficiare delle caratteristiche del CLR, della libreria di classi e di
componenti scritte in altri linguaggi da altri sviluppatori. Inoltre il
CLR fornisce una serie di tecniche per gestire l’interoperabilità con
l’unmanaged code, permettendo così agli sviluppatori di continuare
ad usare componenti COM e DLL legacy.
Il managed code, sebbene non sia compilato in un linguaggio
macchina specifico, esso non è mai interpretato 1 7 : una
caratteristica chiamata compilazione just-in-time (JIT, ovvero
compilazione “appena in tempo”) fa sì che il managed code sia
eseguito sempre nel linguaggio macchina nativo del sistema che ne
richiede l’esecuzione, solo nel momento in cui questo necessita di
essere eseguito.
17
Se si ha familiarità con Java, si può pensare a questo concetto allo stesso
modo: il codice su .Net viene compilato in un linguaggio intermedio simile al
bytecode Java e poi ricompilato “al volo” nel linguaggio macchina del sistema
che lo esegue come fatto dalla Java Virtual Machine (JVM). Le analogie tra Java e
.Net sono tantissime, in alcuni casi anche imbarazzanti (il linguaggio C# di .Net
è stato a volte definito in modo dispregiativo come una “scopiazzatura” del
linguaggio Java).
81
Il managed code può essere ospitato da applicazioni server

come Microsoft SQL Server e Internet Information Services (IIS). In
questo modo il managed code viene usato per scrivere la business
logic, mentre tali applicazioni si occupano in modo trasparente di
ospitare l’ambiente di runtime.
5.3.1.1.2B
5.3.1.1.2BASE CLASS LIBRARY (BCL)
La libreria di classi di .Net Framework (BCL, Base Class
Figura 5 - 49 : Relazioni tra il CLR, il BCL e l'intero sistema
Library) è una collezione di tipi riusabili che si integrano

strettamente con il CLR. La BCL è object-oriented e fornisce tipi dai
quali il managed code può derivare funzionalità. In Figura 5-50
viene presentata una visione schematica della BCL. La BCL fornisce
funzionalità standard basilari come input/output, manipolazione di
stringhe, gestione della sicurezza, comunicazione di rete, gestione
dei thread, gestione di testo, funzioni per la costruzione di
interfacce utente, ecc…. Tali classi sono contenute nel package
System .
Il package System.Data contiene le classi di ADO.Net che
supportano una gestione dei dati persistenti e includono le classi
SQL per la gestione degli archivi di dati persistenti attraverso
un’interfaccia standard SQL.
82
Le classi del package System.XML permettono la

manipolazione, la ricerca e la trasformazione di dati XML.
Le classi nel package System.Web supportano, tramite ASP.Net,
lo sviluppo di applicazioni Web-based e di XML Web Services.
Infine, il package System.Drawing contiene classi per la gestione
completa di grafica e testo, mentre il package
System.Windows.Forms supporta lo sviluppo di applicazioni
client Windows-based.
Figura 5 - 50 : La libreria di classi del framework .Net
Nell’insieme, la libreria di classi fornisce un’interfaccia di

sviluppo comune a tutti i linguaggi supportati dal .Net Framework,
come i nuovi Visual Basic .Net (VB.Net) e C# e altri linguaggi
meno moderni, come C++, COBOL, ADA, Fortran (il supporto è
fornito da terze parti).
Tramite la libreria di classi BCL è possibile sviluppare vari tipi di
applicazioni:
• Applicazioni per console (applicazioni senza interfaccia
grafica);
• Applicazioni in formato script;
• Applicazioni Windows (usando Windows . Fo rms);
• Applicazioni Web (usando ASP.Net);
83
• XML Web Services;

• Servizi Windows.
Ogni libreria di classi di .Net, così come ogni componente built-

in o sviluppata da terze parti, è contenuta nel cosiddetto
assembly. Un assembly è una collezione di funzionalità compilate
e distribuite come una singola unità di implementazione (uno o più
file). Tutti i tipi e le risorse managed possono essere accessibili
solo all’interno della propria unità di implementazione oppure
essere esposte all’uso da parte di codice esterno all’unità.
5.3.1.1.3I
5.3.1.1.3INTEROPERABILITÀ CON UNMANAGED CODE
Il .Net Framework promuove l’interazione con componenti COM,
servizi COM+, DLL e con la maggior parte dei servizi del sistema
operativo. Per semplificare l’interazione tra componenti del .Net
Framework e l’unmanaged code e per semplificare il processo di
migrazione, il CLR si occupa di gestire tutte le differenze dei diversi
modelli di oggetti su client e server.
.Net Framework è la naturale evoluzione di COM dato che i due
modelli condividono molti dei temi centrali, incluso il riuso di
componenti e l’indipendenza dal linguaggio di programmazione.
Per compatibilità con il passato, l’interoperabilità COM fornisce
accesso a componenti COM esistenti senza che sia necessario
modificare la componente originale. Uno sviluppatore .Net può
incorporare componenti COM all’interno di managed code usando
determinati tool per importare i tipi COM richiesti. Una volta
importati, questi tipi saranno pronti per l’uso.
L’interazione con COM introduce anche una compatibilità al
contrario permettendo ai client COM di accedere al managed code
allo stesso modo in cui accedono ad altri oggetti COM. La
conversione tra i dati COM e .Net avviene in automatico e a run-
time da parte del CLR.
Per superare le differenze tra i due approcci, il CLR fornisce delle
classi wrapper per far in modo che i client managed e unmanaged
pensino di chiamare oggetti nel loro rispettivo ambiente. Quando
un client managed invoca un metodo di un oggetto COM, il CLR
crea un Runtime Callable Wrapper (RCW). Il CLR crea un COM
Callable Wrapper (CCW) nel caso contrario, permettendo così a
un client COM di invocare metodi su un oggetto .Net. Come
mostrato in Figura 5-51, la prospettiva della chiamata del codice
determina quale classe wrapper istanziare a run-time.
84
Figura 5 - 51 : Scenari di utilizzo di RCW e CCW
Il CLR espone gli oggetti COM tramite classi proxy RCW. Anche se
un RCW appare come un normale oggetto ai client .Net, la sua
funzione primaria è quella di gestire le chiamate tra un client .Net
e un oggetto COM.
Il CLR istanzia esattamente un RCW per ogni oggetto COM, senza
curarsi del numero di riferimenti che esistono a un oggetto.
L’ambiente di run-time quindi mantiene un singolo RCW per ogni
oggetto. Stessa cosa avviene per i CCW: un solo oggetto CCW
senza badare al numero di client COM che invocano l’oggetto .Net.
Le definizioni dei tipi COM risiedono in una libreria di tipi. Al
contrario un compilatore conforme a .Net Framework per ogni tipo
produce i metadati all’interno di un assembly. Le due risorse di
informazioni sono in realtà completamente differenti.
Le librerie di tipi COM possono essere contenute in particolari
file TLB, ma anche nella sezione risorse di un file DLL o EXE. Una
volta individuata la locazione della libreria di tipi, la generazione
dell’RCW è possibile in tre modi: uso di tool specializzati come ad
esempio quelli inclusi nell’IDE Visual Studio .Net, uso di tool da riga
di comando compresi nel .Net Framework SDK, oppure generazione
manuale dell’RCW. Nel caso di generazione di CCW sono allo stesso
modo disponibili tool specializzati oppure tool compresi nell’SDK. E’
possibile anche che il produttore di una particolare componente
COM o .Net fornisca già i rispettivi RCW e CCW, in tal caso non è
necessario eseguire alcuna operazione di conversione o
generazione.
85
5.3.1.2ADO.Net
5.3.1.2ADO.Net
ActiveX Data Objects for .Net Framework (ADO.Net) è un
insieme di classi che rendono disponibile allo sviluppatore .Net una
serie di servizi per l’accesso ai dati. ADO.Net è una parte
integrante del .Net Framework e permette accesso a database
relazionali e XML, sviluppo di front-end per client di database,
oggetti di business nel middle-tier, tool e applicazioni.
Le classi di ADO.Net si trovano nel package Sys tem .Da ta e sono
integrate con le classi XML del package Sys t em .XML , è per questo
Figura 5 - 52 : L'architettura di ADO.Net
che il supporto di dati in formato XML è così trasparente allo

sviluppatore. L’architettura di ADO.Net viene mostrata in Figura 5-
52.
L’accesso ai dati avviene tramite le sorgenti di dati (data
sources) esposte tramite lo standard OLE DB oppure XML. Le
applicazioni usano ADO.Net per collegarsi a queste sorgenti e
ottenere, manipolare e modificare dati.
Le componenti di ADO.Net sono state progettate per separare
l’accesso ai dati dalla manipolazione dei dati. Esistono due
componenti centrali che eseguono tale compito: il DataSet e il
provider di dati, ovvero un insieme di componenti che include gli
oggetti Connec t i on, Command , DataReader e DataAdapter.
Il DataSet è la componente centrale dell’architettura di
ADO.Net. Il DataSet è progettato esplicitamente per l’accesso ai
dati indipendentemente dalla sorgente dati. Come risultato, un
DataSet può essere usato con molte diverse sorgenti di dati, con
dati XML, o usato per gestire dati localmente all’applicazione. Un
DataSet contiene una collezione di uno o più oggetti DataTab le ,
costituiti da righe e colonne di dati, così come da chiave primaria,
chiavi esterne, vincoli referenziali e informazioni sui dati
nell’oggetto DataTable.
86
L’altro elemento centrale dell’architettura ADO.Net è il provider

di dati .Net, le cui componenti sono progettate esplicitamente per
la manipolazione di dati e l’accesso veloce ai dati in sola lettura.
L’oggetto Connect ion fornisce la connettività alla sorgente dati.
Questo oggetto permette l’accesso ai comandi del database per
ottenere e modificare dati, eseguire stored procedure e inviare o
ottenere informazioni sulla struttura del database stesso. L’oggetto
DataReader fornisce un flusso di dati a sola lettura ad alte
prestazioni dalla sorgente dati. Infine, l’oggetto DataAdapter è il
ponte tra l’oggetto Da taSe t e la sorgente dati. L’oggetto
DataAdapter usa l’oggetto Command per eseguire comandi SQL
sulla sorgente dati sia per caricare dati nel DataSet, sia per
sincronizzare i dati modificati nel DataSet con quelli contenuti nella
sorgente dati.
Il .Net Framework supporta due provider di dati: l’SQL Server
.Net Data Provider e l’OLE DB .Net Data Provider, il quale permette
l’accesso a qualunque database con interfaccia ODBC.
Figura 5 - 53 : Confronto tra i due provider di dati di .Net

Framework
Per concludere, ADO.Net incrementa la potenza di XML

integrandolo in modo trasparente con i concetti propri delle basi di
dati. ADO.Net è stato progettato insieme alle classi XML nel .Net
Framework ed entrambi sono componenti di una singola
architettura. I due insiemi di classi convergono infatti nell’oggetto
DataSet: un DataSet può essere popolato con dati provenienti da
una sorgente XML, che sia un file o un flusso XML, la procedura è
identica e trasparente. Un DataSet può anche essere scritto come
un documento XML rispettoso dello standard del W3C, compreso
del suo schema senza nessuna relazione con la sorgente dati del
DataSet (viene usato il linguaggio standard di definizione XML-
Schema, anche conosciuto come XSD).
Grazie a questa caratteristica, il DataSet è un mezzo eccellente
per lo scambio di dati tra i sottosistemi di un’applicazione software
o per lo scambio di dati con un XML Web Service remoto.
Un DataSet può anche essere sincronizzato con un oggetto
XmlDataDocument in modo da ottenere un accesso relazionale e
gerarchico ai dati in tempo reale.
87
5.3.1.3ASP.Net
5.3.1.3ASP.Net
Active Server Pages for .Net Framework (ASP.Net) è un
insieme di tecnologie nel .Net Framework per la costruzione di
applicazioni Web e XML WS. Le pagine ASP.Net vengono eseguite
sul server e generano codice HTML, WML e XML poi inviato a un
client, che può essere sia un browser di un normale PC desktop sia
un browser di un dispositivo portatile.
Le pagine ASP.Net usano un modello di programmazione
compilato e guidato da eventi, che incrementa le prestazioni e
permette la separazione dell’application logic dall’interfaccia
utente. Le pagine ASP.Net e gli ASP.Net XML WS, contengono logica
server-side scritta in Visual Basic .Net, C# o uno qualsiasi dei
linguaggi compatibili con .Net. Le applicazioni Web e gli XML WS
ereditano tutti i vantaggi delle caratteristiche del CLR, come
sicurezza, interoperabilità tra linguaggi e sicurezza integrata, così
come le funzionalità del .Net Framework e della BCL. ASP.Net stesso
è un ambiente basato su .Net
ASP.Net è qualcosa di più di una nuova versione del vecchio
Active Server Pages (ASP). Esso infatti fornisce un modello di
sviluppo Web unificato che include i servizi necessari agli
sviluppatori per creare applicazioni Web di classe enterprise.
ASP.Net è in gran parte compatibile con ASP, ma l’approccio da
seguire nella migrazione da ASP ad ASP.Net deve essere
necessariamente graduale.
Nel momento in cui vuole creare un’applicazione ASP.Net, lo
sviluppatore ha la facoltà di scegliere tra due possibilità: Web
Forms e Web Services, o una combinazione delle due. In ogni caso
ognuna delle scelta è supportata dalla stessa infrastruttura.
I Web Forms permettono di costruire pagine Web basate su
form. Quando si costruiscono queste pagine, è possibile usare i
controlli server di ASP.Net per creare elementi comuni delle
interfacce grafiche e programmarli per eseguire compiti comuni.
Questi controlli server permettono di costruire rapidamente form
Web riusando componenti standard o personalizzate, semplificando
così il codice di una pagina. In Figura 5-54, è mostrato un esempio
88
Figura 5 - 54 : Un Web Form con all'interno una componente

server
di Web Form con all’interno uno dei componenti server più

complessi. Una pagina ASP.Net di solito è contenuta in un file con
estensione .aspx, che verrà posta su un server che ospita il .Net
Framework e un Web server come Microsoft IIS.
ASP.Net fornisce il supporto anche per gli XML Web Services.

Di solito questi sono contenuti in un file con estensione .asmx,
molto simile a un file .aspx contenente un Web Form. In Figura 5-55
viene mostrato come esempio un semplicissimo Web Service che
ritorna la semplice somma di due interi, scritto usando il linguaggio
Visual Basic .Net.
Il file comincia con la direttiva ASP.Net WebServ i ce (linea 1)
che indica il linguaggio scelto per l’implementazione (VB, ovvero
Figura 5 - 55 : Un semplicissimo XML Web Service
Visual Basic .Net) e il nome della classe (S imp l eWS ). Subito dopo
(linea 4) viene importato il package System.Web .Serv i ces ,
operazione necessaria per poter poi usare le classi al suo interno.
Accanto alla dichiarazione della classe SimpleWS opzionalmente
può essere specificato che tale classe è derivata dalla classe base
WebSe rv i ce. Infine, qualsiasi metodo che sarà accessibile
dall’esterno presenta l’attributo <WebMethod()> davanti alla sua
dichiarazione ([WebMethod] in C#).
Per rendere questo servizio disponibile, non bisogna far altro che
porre il file .asmx all’interno di una directory virtuale sul server
web e accedervi alla tipica URL per il protocollo HTTP (ad esempio
http://myorg.com/ws/SimpleWS.asmx ) usando i comuni metodi
standard di accesso degli XML WS (SOAP o HTTP GET/POST).
89
In modo completamente automatico, ASP.Net è in grado di

fornire in tempo reale il documento WSDL utilizzando la URL
impiegata per accedere al servizio, concatenata con la stringa ?
WSDL (ad esempio http://myorg.com/ws/SimpleWS.asmx?WSDL ).
Sempre in modo automatico, ai fini del testing veloce del WS,
ASP.Net è in grado di mostrare una pagina Web per l’invocazione, la
visualizzazione dei risultati e la navigazione del documento WSDL
del WS. In Figura 5-56 viene mostrata una serie di finestre generate
automaticamente e navigabili dallo sviluppatore in tempo reale.
Figura 5 - 56 : Invocazione ed esplorazione del WS

90
In aggiunta alla tecnologia server side che permette agli

sviluppatori di creare XML WS tramite ASP.Net, il .Net Framework
fornisce un insieme di sofisticati tool e codice per l’invocazione dei
WS. Inoltre, gli XML WS essendo basati su protocolli aperti e
standard come ad esempio SOAP, la tecnologia client può anche
essere usata per invocare WS costruiti con tecnologie diverse da
ASP.Net.
Per definizione, un XML WS può essere invocato sulla rete
usando dei protocolli standard. Un client e un XML WS quindi
comunicano tramite scambio di messaggi SOAP, che incapsulano i
parametri di input e output in XML. Per evitare che uno
sviluppatore si occupi della gestione a basso livello dei messaggi
SOAP (costruzione, recupero e inserimento dati al suo interno e
invio), vengono in aiuto le classi proxy. Tali classi si occupano di
tutto il compito di creazione del messaggio SOAP vuoto, di
inserimento dei parametri di input al suo interno e dell’invio
attraverso la rete. Allo stesso modo una classe proxy si occupa di
recuperare i parametri di output da un messaggio di risposta SOAP.
Una classe proxy può essere generata in automatico se e solo se
è disponibile una descrizione del WS mediante il relativo
documento WSDL. Una volta generata, un client può invocare i
metodi della classe proxy (che corrisponderanno alle operazioni del
WS), che in automatico comunicherà con l’XML WS attraverso la
rete, gestendo da sola l’invio e ricezione dei messaggi SOAP. In
Figura 5-57 viene mostrato il codice da usare sul client per invocare
il WS S imp l eWS attraverso la sua classe proxy: dopo aver istanziato
un oggetto di tipo S imp l eWS (linea 1), l’invocazione del medito
Add() avviene nello stesso modo in cui si invoca il metodo di una
classe (linea 2). La conversione di tipi per i parametri in input ed
output avviene in automatico.
All’interno del .Net SDK (Software Developer Kit), esiste un tool

chiamato WSDL Tool (WSDL.exe). Questo tool da riga di comando
Figura 5 - 57 : Invocazione di un WS tramite classe proxy
è in grado di creare classi proxy a partire da un documento WDSL,

semplicemente invocandolo come:
WSDL /language:VB h t t p : / /myo rg . c om/ws / S imp l eWS . a smx?WSDL
Il risultato sarà un file chiamato SimpleWS.vb (nel caso di VB.Net

o .cs nel caso di C#), che conterrà la classe proxy.
91
5.3.1.4Microsoft
5.3.1.4Microsoft ASP.Net Web Matrix
Tra tutti i tool di sviluppo disponibili per .Net sul mercato, uno
dei migliori è senza dubbio Microsoft ASP.Net Web Matrix.
Web Matrix è tool di sviluppo WYSIWYG 1 8 per ASP.Net, semplice
da usare, supportato da una comunità di sviluppatori, ma
soprattutto freeware. Le sue caratteristiche principali sono:
• Un editor di pagine ASP.Net: editor visuale di tipo
WYSIWYG di pagine con costruzione drag-and-drop di
pagine a partire da un insieme di controlli server o client (i
semplici elementi HTML). L’editor dà anche la possibilità di
accedere istantaneamente al codice associato agli eventi
dei controlli e di modificare le proprietà di ogni oggetto;
Figura 5 - 58 : Web Matrix al lavoro su una pagina ASP.Net
• Gestione di database SQL Server: supporto integrato per la

modifica di database SQL Server, con possibilità di
creazione di nuovi database, aggiunta, modifica e
cancellazione di tabelle e stored procedure, modifica dei
dati contenuti all’interno delle tabelle. Web Matrix
18
WYSIWYG è acronimo di What You See Is What You Get ed indica di solito quei
tool che permettono di comporre documenti osservando in tempo reale
l’effettivo output. Esempi di applicazioni di questo tipo sono Microsoft Word e
Macromedia Dreamweaver.
92
permette anche di creare automaticamente codice

ADO.Net per l’esecuzione di query SQL.
• Generazione di pagine legate ai dati: tramite Web Matrix è
possibile in modo semplice generare pagine direttamente
legate ai dati mediante wizard. Le pagine generate
contengono codice e controlli per l’interrogazione,
inserimento, modifica e cancellazione di dati tramite SQL.
• Supporto degli XML WS: aggiunta semplice del supporto
degli XML WS alle applicazioni sviluppate. Web Matrix
fornisce agli sviluppatori il supporto per l’esposizione di
XML WS basati su SOAP, così come invocazione di XML WS
ospitati da altri server. A tale scopo infatti è presente un
tool per la generazione automatica di classi proxy a partire
da documenti WSDL (in Figura 5-59 viene mostrato questo
tool).
• Costruzione di applicazioni “mobile”: Web Matrix fornisce
supporto per la creazione di applicazioni Web adatte ad
Figura 5 - 59 : Il tool per la generazione di classi proxy
essere usufruite tramite dispositivi portatili come telefoni

cellulari e PDA.
93
• Web Server integrato: Web Matrix include un Web server

leggero capace di ospitare le applicazioni Web sviluppate,
incluse pagine ASP.Net e XML Web Services per le richieste
locali. Questo tool (Figura 5-60) è utilissimo per eseguire
velocemente test delle applicazioni sviluppate, evitando
l’uso del più complesso IIS.
Figura 5 - 60 : Il Web Server interno
94
5.3.1.5Interoperabilità
5.3.1.5Interoperabilità .Net - J2EE
La sfida nella ricerca di una soluzione per la compatibilità
software tra diverse piattaforme hardware e sistemi operativi è uno
dei problemi più grandi e costosi nell’industria del software.
L’iteroperabilità tra .Net e J2EE (Java2 Enterprise Edition) 1 9 è un
argomento essenziale, in quanto la maggior parte delle
organizzazioni sviluppano nuove applicazioni su una o entrambe le
piattaforme. .Net e J2EE rappresentano due approcci differenti per
la soluzione dello stesso problema: sviluppare, distribuire e
mantenere applicazioni di business.
L’interoperabilità tra .Net e J2EE non è così semplice come
creare una connessione HTTP tra applicazioni sviluppate su tali
piattaforme, questo perché le applicazioni sono sviluppate al livello
di astrazione del linguaggio di programmazione poggiando il tutto
su un sistema operativo. Come visibile in Figura 5-61 le differenze
tra le due piattaforme sono molteplici, a partire dai linguaggi di
programmazione utilizzati per lo sviluppo, fino ad arrivare ai tipi di
dati (diversi anche tra gli stessi VB.Net e C#) e ai protocolli di
comunicazione per l’elaborazione distribuita (.Net remoting per
.Net e IIOP 2 0 per J2EE). Le differenze nei linguaggi di
programmazione, nei protocolli nativi per l’elaborazione distribuita,
Figura 5 - 61 : .Net e J2EE a confronto
19
J2EE è una piattaforma Java progettata per l'elaborazione di dimensioni
mainframe, tipica delle grandi organizzazioni. Sun Microsystems (insieme ad altri
partner come IBM) ha progettato J2EE per semplificare lo sviluppo di applicazioni
mediante la creazione standardizzata di componenti riusabili e mediante la
delega alla piattaforma della gestione automatica di diversi aspetti di
programmazione, come gestione di sicurezza, transazioni, connessione ai
database, ecc...
20
IIOP (Internet Inter- ORB Protocol) è un protocollo che rende possibile la
comunicazione tramite Internet di programmi distribuiti, sviluppati in differenti
linguaggi di programmazione. IIOP è una parte dello standard CORBA (Common
Object Request Broker Architecture).
95
nei tipi di dati e strutture, insieme con l’isolamento dai servizi del
sistema operativo, tutte insieme influiscono sull’interoperabilità.
Gli XML Web Services invece vengono in aiuto proprio per
risolvere questi problemi di interoperabilità, in particolare tra .Net
e J2EE, tanto che lo sviluppo orientato ai servizi rende l’intero
problema della piattaforma, assolutamente irrilevante (Figura 5-
62).
La sola esposizione dei sistemi come servizi e l’utilizzo degli XML
Web Services, assicurano la trasparente integrazione e
interoperabilità tra i sistemi, indipendentemente dalla piattaforma
su cui sono stati sviluppati. Quello che un tempo aveva realizzato
Java, ovvero l’irrilevanza della piattaforma hardware e del sistema
operativo, è stato portato a un livello di astrazione maggiore dagli
Figura 5 - 62 : Dalla dipendenza dalla piattaforma

all'irrilevanza della piattaforma
XML WS: l’irrilevanza della piattaforma hardware e software di

sviluppo.
Uno scenario di questo tipo risolve l’annoso problema della
scelta tra le due piattaforme più importanti sul mercato. Inoltre per
un’organizzazione che adotta al suo interno sistemi basati su
diverse piattaforme, l’uso degli XML WS apre nuove possibilità di
integrazione, prima difficilmente raggiungibili.
96
Nonostante l’assenza di problemi a livello di standard di

comunicazione (HTTP, SMTP, FTP), di messaggistica (SOAP), di
descrizione dei servizi (WSDL) e di descrizione e scoperta (UDDI),
esistono tuttora alcuni problemi dovuti ai diversi modi di
implementare i WS (argomento di cui si è già parlato in
precedenza): RPC oriented e Document oriented. Le due
piattaforme supportano entrambe le modalità, in quanto SOAP è
stato progettato per essere compatibile con entrambe. Tuttavia la
compatibilità di formato si scontra spesso con l’incompatibilità di
comportamento dei due modi di pensare il servizio. Inoltre ognuna
delle due piattaforme spinge all’utilizzo di una sola delle due
modalità: .Net la modalità Document oriented, J2EE la RPC
oriented.
Allo scopo di mettere fine anche a questo ultimo problema di
interoperabilità, l’organizzazione indipendente WS-I (Web Services
Interoperability) sta ratificando una serie di raccomandazioni che
aiutino i progettisti in quest’area. WS-I propone C# (.Net) e Java
(J2EE) come piattaforme di riferimento per i tool e le applicazioni di
base. Inoltre spinge all’uso della modalità Document oriented a
causa di alcuni problemi insormontabili nella modalità RPC
oriented, riconosciuti durante uno studio approfondito dei due
approcci.
97
5.3.2Microsoft
5.3.2Microsoft SOAP Toolkit 3.0
5.3.2.1XML
5.3.2.1XML Web Services e sistemi legacy
Per un’organizzazione, l’adozione della tecnologia degli XML WS
o del framework Microsoft .Net può rappresentare un’ottima
occasione per aprire il proprio sistema alle nuove tecnologie o a
nuove possibilità di integrazione e di business. Tuttavia il passaggio
da una vecchia tecnologia a una nuova, non è mai così indolore
come spesso dichiarato dai fornitori della tecnologia stessa o da chi
produce tool di sviluppo o applicazioni legati ad essa.
Solitamente esistono due scenari ricorrenti quando si considera
la migrazione di un sistema legacy (o di un sottosistema) verso una
nuova tecnologia:
• l’organizzazione possiede documentazione e codice
sorgente del sistema o sottosistema;
• l’organizzazione possiede il sistema o il sottosistema
esclusivamente in formato binario già compilato, senza
codice sorgente o altro.
Nel primo caso la tecnica adottata è di solito la migrazione di
tutto il codice, o di parte di esso, attraverso tool automatici verso
la nuova tecnologia, nel secondo caso invece l’unica tecnica
adottabile è la costruzione di wrapper. Nel caso di esposizione dei
servizi di un sistema legacy come WS, è possibile migrare il codice
del sistema verso una piattaforma che supporti in modo nativo i WS
(ad esempio il framework .Net) oppure esporre tali servizi tramite
wrapper.
La migrazione del codice è forse la scelta più rischiosa,
soprattutto nel caso di migrazione dell’intero codice del sistema.
Ad esempio la migrazione da Visual Basic a Visual Basic .Net,
nonostante il processo automatizzato, presenta grossi rischi dovuti
soprattutto all’incompatibilità tra VB.Net con il vecchio codiceb VB.
A volte la migrazione è impossibile o perché come detto in
precedenza non si possiede il codice sorgente, oppure perché
nonostante il codice sorgente, questo non presenti alcuna
possibilità di essere portato verso la nuova piattaforma, o presenti
difficoltà eccessive.
La situazione è ancor più aggravata se l’organizzazione ha fatto
un enorme investimento in passato sul sistema e ritiene questo
strategico per il proprio business così come ritiene strategica la
necessità di esporre tale sistema tramite WS. In queste situazioni,
un aiuto viene dato da un semplice tool chiamato Microsoft SOAP
Toolkit.
SOAP Toolkit è essenzialmente uno strumento per esporre i
metodi dell’interfaccia di una componente COM come operazioni di
un XML Web Service. Come si intuisce, uno strumento del genere
98
risolve molti dei problemi citati in precedenza e fornisce una strada

alternativa laddove il sistema non sia stato progettato usando la
tecnologia COM, ovvero la creazione di un wrapper COM del
sistema.
5.3.2.2Panoramica
5.3.2.2Panoramica del tool
Il tool Microsoft SOAP Toolkit nella versione 3.0, consiste
delle seguenti componenti:
• Una componente COM client-side che permette a
un’applicazione di invocare XML WS descritti dal rispettivo
documento WSDL;
• Una componente COM server-side che fa corrispondere le
operazioni invocate di un XML WS alle chiamate dei metodi
di un oggetto COM, come descritto nel documento WSDL e
WSML (di quest’ultimo si parlerà nel seguito);
• Le componenti richieste per costruire, trasmettere, leggere
e processare i messaggi SOAP. A questi processi ci si
riferisce con i termini marshalling e unmarshalling.
In aggiunta, SOAP Toolkit fornisce un tool per la generazione di
documenti WSDL/WSML chiamato WSDL Generator, che
alleggerisce lo sviluppatore del tedioso processo di creazione
manuale di tali documenti.
5.3.2.3Web
5.3.2.3Web Services Meta Language (WSML)
Oltre alla creazione di un documento WSDL che descriva i servizi
e le operazioni sul server, è richiesta la creazione sul server di un
documento nel formato WSML (Web Services Meta Language ),
un formato specifico al tool SOAP Toolkit, di cui non si daranno qui
dettagli tecnici approfonditi in quanto la sua gestione è del tutto
automatizzata e non è richiesto alcun intervento su un documento
in tale formato da parte dello sviluppatore.
Un documento WSML contiene informazioni che fanno
corrispondere le operazioni di un servizio (così come descritte nel
documento WSDL) a specifici metodi in un componente COM. Il
documento WSML determina quali oggetti COM usare in modo da
servire la richiesta per ogni operazione.
99
Si consideri il documento WSML corrispondente a un

semplicissimo servizio, rappresentato in Figura 5-63: in questo
documento esiste un elemento <se rv i ce>, con gli elementi figli
<us i ng> e <port>. L’elemento <using> specifica l’oggetto COM
usato dal servizio. L’elemento <port> invece elenca tutte le
operazioni. Per ogni operazione, l’elemento <execute> fa
corrispondere l’operazione a un metodo sull’oggetto COM, così
come <parameter> si occupa della corrispondenza dei parametri.
Figura 5 - 63 : Frammento di un documento WSML
Tralasciando la componente client-side, l’uso della quale è

completamente opzionale in quanto un XML WS può essere
invocato anche mediante tecnologia non Microsoft, verrà ora
descritto il funzionamento della parte server-side del tool.
Sul server è richiesta la presenza di un listener SOAP
(letteralmente un “ascoltatore”), ovvero di una componente che
gestisca i messaggi SOAP di richiesta inviati al server. Questo
listener SOAP può essere sia un server Internet Server API
(ISAPI) 2 1 , sia un server Active Server Pages (ASP) 2 2 .
21
ISAPI (Internet Server Application Program Interface) è una tecnologia
Windows che permette di scrivere un'applicazione Web più efficiente di
un'applicazione basata sulla vecchia tecnologia Common Gateway Interface
(CGI). Uno degli svantaggi di un'applicazione CGI è che, ogni volta che viene
eseguita, essa viva come un processo separato, con il suo spazio di indirizzi. Con
ISAPI invece, l'applicazione risiede in una libreria DLL che può essere eseguita
come parte del processo e dello spazio di indirizzi del server HTTP. La libreria
DLL è caricata in memoria quando il server HTTP è avviato e rimane in memoria
fin quando richiesto, senza la necessità di essere caricata così frequentemente
come un'applicazione CGI.
22
Una Active Server Page (ASP) è una pagina HTML che include uno o più script
(piccoli programmi) che sono eseguiti su un Web server Microsoft prima che la
pagina sia inviata all'utente.
100
Per definire un listener SOAP, bisogna indicare una URL

all’interno dell’elemento <soap : add re s s> del documento WSDL. In
Figura 5-64 viene mostrato il frammento del documento WSDL per
definire un listener ISAPI, mentre in Figura 5-65 l’equivalente per
un listener ASP. Come si può notare, nel caso del listener ISAPI
l’URL corrisponde a quella di un file WSDL, nel caso invece del
listener ASP, l’URL corrisponde a quella di un file ASP.
Usando il tool WSDL Generator, il documento WSDL
Figura 5 - 64 : Frammento del documento WSDL per un listener ISAPI
Figura 5 - 65 : Frammento del documento WSDL per un listener ASP
corrispondente al WS viene generato automaticamente, senza

alcuna necessità di gestire manualmente tali dettagli.
Sia che si invochi il servizio tramite il listner ISAPI, sia che lo si
faccia tramite quello ASP, il modo in cui il server gestisce i dati in
ingresso e in uscita è lo stesso.
In Figura 5-66 viene mostrato come la high-level API di SOAP
Toolkit, ovvero l’oggetto SoapServer30 , gestisce il flusso di dati
sul server.
Figura 5 - 66 : Flusso di dati sul server
Quando si usa la high-level API, l’oggetto SoapServer30 riceve il

messaggio di richiesta SOAP dal client, processa questa richiesta e
inoltra una chiamata al metodo COM che corrisponde all’operazione
richiesta (ovvero la chiamata al metodo AddNum ). Il metodo invia il
risultato dell’elaborazione dell’operazione richiesta all’oggetto
101
SoapSe rve r30, il quale formula quest’informazione in un messaggio

di risposta SOAP che viene inviato al client.
SOAP Toolkit supporta solo il modello di programmazione
stateless. Quindi, per ogni richiesta SOAP, l’oggetto COM è creato e
poi distrutto.
In SOAP Toolkit, la high-level API SoapSe rve r30 è implementata
usando la low-level API, ovvero gli oggetti SoapSe r i a l i z e r 30
,
SoapReader30, WSDLReader30 e altri.
Come mostrato in Figura 5-67, l’oggetto SoapServer30 esegue
diverse operazioni internamente per processare un messaggio di
richiesta SOAP e formulare la relative risposta. Una volta ricevuta
la richiesta SOAP dal client, l’oggetto SoapServer30 usa l’oggetto
SoapReader30 per caricare questo messaggio in una struttura
DOM (Documento Object Model) 2 3 e l’oggetto WSDLReader30 per
caricare i file WSDL e WSML in due strutture DOM distinte.
L’oggetto WSDLReader30 analizza la richiesta e crea un oggetto
WSDLOperation30 per l’operazione richiesta. A questo punto
Figura 5 - 67 : Flusso di dati all'interno di SoapServer30
l’oggetto WSDLOperation30 invoca il metodo GetOperationParts(), il

quale restituisce, a partire dai due alberi DOM corrispondenti ai file
23
Document Object Model (DOM) è una specifica di interfaccia di
programmazione sviluppata dal W3C che permette agli sviluppatori di creare e
modificare documenti XML come se fossero dei veri e propri oggetti.
102
WSDL e WSML, una collezione di elementi <pa r t> definiti sia per il
messaggio di richiesta sia per quello di risposta. Per ognuno di
questi elementi <pa r t> , l’oggetto SoapServer30 crea un oggetto
SoapMapper e carica in esso i valori contenuti nella richiesta
SOAP. Quindi l’oggetto SoapServer30 richiama il metodo della
componente COM corrispondente all’operazione richiesta. Il metodo
COM elabora i parametri inclusi nella chiamata e ritorna il risultato
all’oggetto SoapServer30, il quale fa corrispondere il valore di
ritorno all’oggetto SoapMapper appropriato. Quindi SoapServer30
usa l’oggetto SoapSerializer30 per costruire il messaggio di
risposta SOAP che contiene il valore di ritorno e lo invia al client.
Esistono quindi due possibilità di sviluppare utilizzando il SOAP
Toolkit:
• Utilizzo della high-level API e gestione automatica di tutti
gli oggetti della low-level API da parte del tool;
• Utilizzo diretto delle componenti della low-level API e
gestione manuale di tutte queste.
Ovviamente vi sono pro e contro nell’uso di una o dell’altra
strategia. Con la prima lo sviluppatore non deve occuparsi di tutti i
dettagli di basso livello come la creazione manuale dei file WSDL e
WSML e la creazione della corrispondenza tra l’operazione invocata
sul servizio e l’invocazione del metodo corrispondente nella
componente COM. Con la seconda invece si rinuncia a tutti gli
automatismi del tool, ma si guadagna la possibilità di
personalizzare alcuni dettagli di basso livello, o di aggiungere
caratteristiche non contemplate dal tool.
5.3.2.5Il
5.3.2.5Il tool WSDL Generator
Come detto in precedenza, la creazione dei file WSDL e WSML
può essere un’operazione tediosa. All’interno di SOAP Toolkit viene
fornito un tool che ha lo scopo proprio di generare
automaticamente questi file.
Data in input una libreria DLL, il tool analizza la libreria di tipi e
fornisce una lista delle interfacce dell’oggetto COM nella DLL dalla
quale lista è possibile selezionare i metodi che si vogliono esporre
come operazioni del WS. Una volta selezionati i metodi e aver
indicato un nome per il servizio (NomeServizio), una URL dove sarà
disponibile il servizio, il tipo di listener (ASP o ISAPI) e i namespace
desiderati, il tool produce una serie di file:
• NomeServizio.wsdl: il file che contiene il documento WSDL
usato dal WS;
• NomeServizio.wsml: il file che contiene il documento WSML
usato dal WS;
• NomeServizioClient.wsml: una versione semplificata del
file WSML di solito distribuita insieme al client. Questa
103
versione non contiene tutti i dettagli relativi alla parte

server del servizio;
• NomeServizio.Wgen: un file di configurazione contenente
tutti i parametri immessi nel tool per la creazione dei file
WSDL e WSML. Questo file viene usato quando si vuole
ripetere il procedimento, in tal caso non sarà necessario
reinserire tutti i valori nel tool;
• NomeServizio.asp: nel caso di listener di tipo ASP, questo
file contiene tutto il necessario per gestire l’invocazione
delle operazioni del servizio sul server.
Figura 5 - 68 : Come indicare la DLL in WSDL Generator
104
Una volta generati i file all’interno di una directory, questa va

ressa disponibile come directory virtuale del server Web di
Microsoft IIS (Internet Information Services). Tale operazione è
eseguibile in modo semi automatico attraverso il tool
SOAPVDIR .CMD (uno script di tipo batch), il quale si occupa della
creazione e condivisione della directory oltre che della corretta
configurazione dei diritti di accesso ad essa. L’uso di questo tool è
indispensabile nel caso di listener ISAPI a causa della complessità
dell’operazione di configurazione, meno indispensabile invece nel
caso di listener ASP dove l’operazione è semplicissima.
Figura 5 - 69 : La scelta dei metodi da esporre
Figura 5 - 70 : Tipo e URL per il listener
105
5.3.3Altova
5.3.3Altova XML-Spy Enterprise Edition 5
Come si intuisce dal nome, XML-Spy è un tool per la generazione
e modifica di file XML. Ciò che però distingue XML-Spy da altri tool
simili, è la gestione nativa degli XML WS. Tramite XML-Spy è infatti
possibile eseguire una serie di operazioni come: creazione,
modifica e visualizzazione di documenti WSDL in maniera visuale,
generazione di messaggi SOAP di richiesta e risposta per XML WS,
Figura 5 - 72 : I messaggi SOAP di richiesta (a sinistra) e risposta (a

destra)
Figura 5 - 71 : Invocazione di un WS a partire dal suo documento WSDL
invocazione e debug di XML WS. Nella Figura 5-71, Figura 5-72 e

Figura 5-73 è possibile notare alcune di queste funzionalità.
106
Figura 5 - 73 : Il documento WSDL di un WS in formato grafico
Oltre a queste funzionalità strettamente legate agli XML WS, ne

sono presenti anche altre utilissime che alleggeriscono il lavoro
dello sviluppatore che decidesse di fare un uso pesante di XML per
immagazzinare o rappresentare dati (supporto di DTD, XSD, XSLT,
XPath, XHTML, ecc…).
107
5.4 Il sistema realizzato

Come già anticipato, il sistema realizzato elabora i dati presenti
nel database del sistema CRM e ne presenta i risultati all’interno
del portale. In Figura 5-74 viene mostrata l’architettura del sistema
a un livello di dettaglio più basso. Nel diagramma la parte
evidenziata con il colore grigio, sta a indicare la parte del sistema
realmente realizzata e le componenti con cui interagisce.
L’interazione tra il sistema STATCRM e il sistema CRM avviene
esclusivamente attraverso la base di dati di quest’ultimo.
L’integrazione scelta è quindi di tipo data-driven.
L’interazione tra le varie parti del sistema varia a seconda dei
Figura 5 - 74 : Architettura del sistema
sistemi presi in considerazione: tra il Plumtree Portal Server e i vari

Plumtree Gadget Server l’interazione avviene come già detto
tramite i protocolli HTTP e SOAP, in quanto l’architettura di
Plumtree è basata su Web Services. L’interazione tra il sistema
Statistics Server e il Gadget Server avviene sempre tramite
protocolli HTTP e SOAP, in quanto il sistema Statistics Server è
108
realizzato come Web Service. L’interazione tra il sistema Statistics

Server e il database avviene usando un accesso basato su ODBC.
5.4.1Gli
5.4.1Gli utenti del sistema e la personalizzazione
Gli utenti che possono avere accesso al sistema STATCRM sono
una parte di quelli che hanno accesso al sistema CRM completo. In
particolare gli utenti del gruppo Docenti e Manager Didattici.
Questa scelta è dovuta alla loro funzione di controllo dell’attività
degli stage: infatti gli utenti di questi due gruppi sono quelli più
interessati ad eseguire statistiche e a tenere sotto controllo
l’andamento degli stage nel tempo.
La mansione di Manager Didattico è solitamente svolta
all’interno di una facoltà da un impiegato amministrativo, avviene
quindi che i dati e i tipi di statistiche a cui può essere interessato
siano differenti da quelle di un Docente, solitamente con un
background culturale maggiore in materia di statistica. Sfruttando
quindi le possibilità fornite dal portale Plumtree di
personalizzazione dei contenuti in base al gruppo di appartenenza
di un utente, a seconda che un utente appartenga al gruppo dei
Docenti o al gruppo dei Manager Didattici, esso è abilitato a
eseguire e visualizzare solo determinate statistiche.
Il sistema STATCRM è in grado di realizzare statistiche di tipo
semplice rappresentate come diagrammi a torta, istogrammi o
diagrammi a punti, e statistiche di tipo complesso come diagrammi
per il controllo statistico dei processi. Un Docente avrà accesso sia
alle statistiche di tipo semplice che quelle di tipo complesso,
mentre un Manager Didattico avrà accesso solo a quelle di tipo
semplice.
Oltre alla possibilità di scelta della statistica da eseguire, il
sistema permette agli utenti di entrambi i gruppi di personalizzare
le statistiche eseguibili, in modo da adattarle maggiormente ai
propri interessi o restringerle a un particolare periodo
d’osservazione o ancora indicare sulla base di quali parametri
scegliere i dati da elaborare.
109
5.4.2Studio
5.4.2Studio delle richieste nel sistema CRM
Come detto in precedenza, le richieste
vengono inviate al sistema CRM tramite
un form dell’applicazione che gestisce gli
stage. Dallo studio di tale sezione del
sistema, si è appreso che tutte le
richieste vengono immagazzinate in
un’unica tabella del database di sistema
di Applix. Il nome di questa tabella è
HD_ INC IDENT , è contenuta nello spazio
delle tabelle AXENT e viene riportata in
Figura 5-75. Tralasciando le dovute
considerazioni ingegneristiche sulla
struttura di questa tabella, servendosi
della poca documentazione del sistema
ed effettuando un reverse engineering
del sistema stesso, si è arrivati alla
comprensione della quasi totalità dei
campi. In realtà molti di essi sono usati
dal sistema Applix per archiviare dati
utili al monitoraggio dell’attività
dell’utente del sistema. I campi invece di
interesse per la realizzazione delle
statistiche sono risultati essere:
• OWNER_GRP : il gruppo di
appartenenza dell’utente che
ha effettuato la richiesta;
• TYPE: l’argomento cui si
riferisce la richiesta (il tipo);
• CHANGE_DT : la data dell’ultima
modifica avvenuta sulla
richiesta;
• CUST_SAT I S: quando chi ha
inviato la richiesta riceve una
risposta, egli può indicare un
valore con cui quantificare la
sua soddisfazione riguardo la
risposta stessa;
• STATE: uno degli stati in cui
può trovarsi la richiesta
all’interno del suo ciclo di vita.
Ad esclusione di CHANGE_DT che è

una data, tutti gli altri quattro campi
dovrebbero contenere codici associati a
Figura 5 - 75 : Tabella
con le richieste
110
valori contenuti in altre tabelle relazionate ad HD_ INC IDENT

mediante chiave esterna. In realtà CUST_SAT I S e STATE contengono
direttamente i valori, mentre OWNER_GRP e TYPE sono codici di
valori contenuti in altre tabelle (rispettivamente GRP ed
HD_EXPORT_V7 entrambe nello spazio AXENT), ma non sono legati
ad esse da alcuna relazione e da alcun vincolo referenziale. Tramite
l’analisi di queste tabelle, si sono potuti estrarre tutti i valori
possibili per questi campi, facendo attenzione ad escludere
particolari valori usati solo internamente dal sistema ma non
corrispondenti a valori selezionabili dall’utente, oppure da altri
appartenenti ad applicazioni completamente indipendenti da quella
che tratta gli stage.
Dall’analisi dei valori del campo STATUS e dell’applicazione si è
potuto ricavare il ciclo di vita di una richiesta nel sistema (Figura 5-
76): una volta inserita tramite il form, questa viene subito
archiviata nel database, smistata al destinatario indicato
dall’utente e contrassegnata con lo stato Assegnata. Nel momento
in cui il destinatario riceve la richiesta questa passa nello stato
Ricevuta. A questo punto il destinatario può decidere se chiudere la
richiesta, in tal caso questa passa nello stato di Chiusa, oppure
rispondere, in tal caso il ciclo riprenderà come se fosse una nuova
richiesta, solo che il destinatario sarà il mittente del ciclo
precedente.
Nel momento in cui il mittente
originale riceve una risposta, egli ha la
possibilità di indicare un valore che
quantifichi il suo grado di soddisfazione
derivato dalla lettura della risposta
ricevuta. I valori possibili sono contenuti
nel campo CUST_SATIS e possono essere
tre: Soddisfatto, Insoddisfatto e
Indifferente.
Il campo TYPE contiene, come già
detto, l’argomento della richiesta, o
anche detto tipo di richiesta. I valori
possibili sono numerosi, ma divisi in due
categorie principali: Studente e Impresa.
Tutti i valori possibili sono riportati nella
Tabella 5-3.
C ODICE D ESCRIZIONE
STUDENTE-CARENZA DI ASSISTENZA Carenza di Assistenza

STUDENTE-ATTIVITÀ NON COERENTI CON IL Attività non coerenti con il Progetto
PROGETTO DIDATTICO Didattico
STUDENTE-CARENZA DI STRUMENTAZIONE Carenza di Strumentazione
STUDENTE-CARENZA DI SPAZI Carenza Figura
di Spazi 5 - 76 : Ciclo di
vita di una richiesta
111
STUDENTE-INCONTRI DI LAVORO MANCATI Incontri di Lavoro Mancati

STUDENTE-RICHIESTA DI INCONTRO L AVORO Richiesta di Incontro Lavoro
STUDENTE-ATTIVITÀ PIANIFICATA E NON Attività Pianificata e non eseguita
ESEGUITA
STUDENTE-INDETERMINAZIONE DELLO SCOPO Indeterminazione dello Scopo delle
DELLE ATTIVITÀ Attività
STUDENTE-VIOL AZIONE DELL A SCHEDUL AZIONE Violazione della Schedulazione
STUDENTE-CARENZA DI ACCOMPAGNAMENTO Carenza di Accompagnamento
STUDENTE-VARIE Varie
IMPRESA-ATTIVITÀ ESEGUITA NON CONFORME AI Attività eseguita non conforme ai piani
PIANI
IMPRESA-CATTIVO USO DELLA STRUMENTAZIONE Cattivo uso della Strumentazione
IMPRESA-INCONTRI DI L AVORO MANCATI Incontri di Lavoro Mancati
IMPRESA-RICHIESTA DI LAVORO Richiesta di Lavoro
IMPRESA-ATTIVITÀ PIANIFICATA E NON ESEGUITA Attività pianificata e non eseguita
IMPRESA-SCOSTAMENTO TRA I RISULTATI REALI Scostamento tra i risultati reali ed
ED ATTESI attesi
IMPRESA-SCOSTAMENTI TRA DATA DI CONSEGNA Scostamento tra data di consegna reale
REALE E PREVISTA e prevista
IMPRESA-CARENZA CAPACITÀ Carenza Capacità
Figura 5 - 77 : L'entità
Tabella 5 - 3 : Possibili tipi di richiesta
Richiesta
Per concludere, il campo
OWNER_GRP può contenere i valori STUDENT I , ORGAN IZZAZ ION I e
DOCENTI. Un appartenente al gruppo Organizzazioni può effettuare
richieste di un tipo nella categoria Impresa (questa inconsistenza di
nomi è dovuta alla natura prototipale dell’applicazione che gestisce
gli stage) mentre un appartenente al gruppo Studenti può
effettuare richieste di un tipo nella categoria Studente. I Docenti
invece allo stato attuale del sistema non potrebbero effettuare
richieste.
Detto ciò, l’entità Richiesta (rappresentata in Figura 5-77) è
quindi caratterizzata dalla data in cui è stata effettuata, il suo tipo,
il gruppo di chi l’ha effettuata, il livello di soddisfazione di chi ha
ricevuto la risposta e lo stato in cui si trova all’interno del sistema.
Sulla base di queste informazioni è stato possibile strutturare i
metadati e scegliere le possibilità di personalizzazione delle
statistiche.
112
113
5.4.3Componenti
5.4.3Componenti realizzate
Considerando la Figura 5-74, la parte del sistema realmente
implementata si trova nella parte evidenziata con la colorazione
grigia. In Figura 5-78 invece viene riportata l’architettura
rappresentata ad un livello di dettaglio maggiore.
Figura 5 - 78 : Architettura del sistema a un livello di dettaglio maggiore
L’architettura è la tipica architettura per sistemi basati su Web

Service: un primo livello Presentation GUI (non visibile in figura)
formato da script e componenti client-side, coincide con il browser
usato dall’utente per accedere al sistema via Web; un secondo
livello Presentation Logic formato dalla componente Gadget e
dal portale, le quali forniscono un’interfaccia di tipo thin-client
(documenti dinamici ASP), gestione della sessione, ecc…; un terzo
114
livello Busine ss Logic formato dalle componenti Statistics Server,

Excel Server e Statistica Server, le quali forniscono funzionalità
proprie dell’applicazione e realizzano la logica di business; un
quarto livello Data Access Logic formato dalla componente
Databanker Server, la quale fornisce servizi generici di accesso ai
dati persistenti; infine un quinto livello Data Storage Logic (non
visibile in figura) fornisce servizi di memorizzazione e ritrovamento
dati persistenti, ovvero il DBMS del sistema CRM.
Oltre alle componenti rappresentate in figura, è stata realizzata
anche una componente usata esclusivamente ai fini della
sperimentazione di cui si parlerà a conclusione di questa sezione.
Nel seguito saranno analizzate le componenti realizzate. Per
ulteriori dettagli tecnici è possibile consultare l’allegato alla tesi, al
cui interno vengono riportate l’analisi dei requisiti software (SRS) e
le specifiche di progettazione (SPS) del sistema.
5.4.3.1Databanker
5.4.3.1Databanker Server
La funzione principale della componente Databanker Server è
quella di accedere alla base di dati del sistema CRM al fine di
leggere le informazioni richieste. Realizzato secondo il design
pattern façade (vedere Pagina 40), è in grado di fare astrazione sia
sulla locazione fisica del database, sia sul tipo di database, sia sui
dati contenuti al suo interno. Inoltre è progettato in modo da
essere parametrico.
Si è detto che una richiesta è caratterizzata da una data, da un
gruppo, da un tipo, da uno stato e da un livello di soddisfazione del
cliente. Dovendo il sistema effettuare statistiche sulle richieste, si
è osservato che al variare della statistica, la modalità di
interrogazione della base di dati non cambia come struttura, ma
solo come parametri. In particolare, essendo la base di dati di tipo
relazionale, le query SQL usate per effettuare le interrogazioni
hanno tutte la stessa struttura.
Inoltre, data la natura prototipale del sistema CRM, è stato
deciso di fare in modo che cambiamenti nella struttura della base
di dati avessero un impatto minimo se non nullo sulla componente.
Per ottenere ciò, il Databanker fa uso di metadati.
5.4.3.1.1M
5.4.3.1.1METADATI
I metadati descrivono i dati presenti nel database e il database
stesso. Il formato scelto per la loro archiviazione sul server è quello
XML, in alternativa sarebbe stato possibile archiviarli all’interno del
database stesso, ma questo avrebbe creato un legame troppo forte
con ciò su cui si voleva effettuare astrazione, ovvero il database
stesso.
All’interno del documento XML sono presenti diverse sezioni,
ognuna descrive un elemento differente su cui fare astrazione:
115
• Da tabase: contiene una serie di informazioni che

descrivono la base di dati. E’ possibile indicare sia il nome
della tabella contenente le richieste (Tab l e), sia le
informazioni necessarie per effettuare una connessione
ODBC con il DBMS che ospita il database del CRM, quindi il
tipo di database (Provider), la sorgente dati (DataSource),
la user name (UserId) e la password (Password) per
accedervi. Grazie a queste informazioni cambiare il nome
della tabella, il tipo di database (Oracle, Access, SQL
Server, ecc…) e le modalità di accesso, non richiedono
alcuna modifica al codice della componente.
Figura 5 - 79 : La parte Database dei metadati
Figura 5 - 80 : La parte Gruppi dei metadati
• Gruppi: contiene l’elenco di tutti i gruppi per i quali si

vuole permettere la generazione di statistiche. Per ogni
gruppo viene indicato il codice (codice) interno (che
corrisponde al codice nel campo della tabella delle
richieste) e una descrizione (descrizione) da mostrare
all’utente nell’interfaccia grafica del sistema. Inoltre viene
anche indicato il nome del campo della tabella (campo)
che contiene il gruppo di chi ha effettuato la richiesta.
Tramite queste informazioni un cambiamento alla struttura
della tabella delle richieste o un’aggiunta, rimozione o
variazione di uno o più gruppi all’interno del sistema CRM,
non comporta alcuna modifica al codice della componente,
ma solo una variazione del documento XML.
• Tipi: contiene l’elenco di tutti i tipi di richieste per i quali

si vuole permettere la generazione di statistiche. Per ogni
tipo viene indicato il codice (codice) interno (che
richieste), una descrizione (descrizione) da mostrare
all’utente nell’interfaccia grafica del sistema e il gruppo di
utenti che possono effettuare richieste di questo tipo
116
(owne rg rp). Inoltre viene anche indicato il nome del campo

della tabella (campo ) che contiene il tipo delle richieste.
Tramite queste informazioni un cambiamento alla struttura
della tabella delle richieste o un’aggiunta, rimozione o
variazione di uno o più tipi all’interno del sistema CRM,
non comporta alcuna modifica al codice della componente,
Figura 5 - 81 : Frammento della parte Tipi dei metadati
ma solo una variazione del documento XML.
• Pe r i od:i contiene l’elenco di tutti gli intervalli di tempo su

cui è possibile effettuare statistiche. Per ogni periodo
viene indicato il nome (nome ), la durata in giorni
(numerogiorni), la data iniziale (datainizio) e finale
(datafine) in un formato standard comprendente data e ora
(in modo da rendere il formato delle date indipendente dal
particolare DBMS usato per il database del sistema CRM).
Inoltre viene anche indicato il nome del campo della
tabella (campo) contenente la data delle richieste. Tramite
queste informazioni un cambiamento alla struttura della
tabella delle richieste o un’aggiunta, rimozione o
variazione di uno o più periodi di tempo su cui effettuare
statistiche, non comporta alcuna modifica al codice della
componente, ma solo una variazione del documento XML.
Sempre a proposito dei periodi, a run-time la componente
databanker aggiunge sempre ai periodi presenti nei
metadati, tre nuovi periodi corrispondenti agli ultimi 7, 30
e 60 giorni rispetto alla data di sistema. Questo consente
di effettuare statistiche sempre aggiornate alla data
corrente.
117
Figura 5 - 82 : Frammento della parte Periodi dei metadati
• Sodd i s f a z i on iC l i en: tcontiene

e l’elenco di tutti i valori di
soddisfazione del cliente per i quali si vuole permettere la
generazione di statistiche. Per ogni valore viene indicato il
codice (cod i ce) interno (che corrisponde al codice nel
campo della tabella delle richieste) e una descrizione
(descrizione) da mostrare all’utente nell’interfaccia grafica
del sistema. Inoltre viene anche indicato il nome del
campo della tabella (campo) che contiene il valore di
soddisfazione delle richieste. Tramite queste informazioni
un cambiamento alla struttura della tabella delle richieste
o un’aggiunta, rimozione o variazione di uno o più valori di
soddisfazione all’interno del sistema CRM, non comporta
alcuna modifica al codice della componente, ma solo una
variazione del documento XML.
118
• S ta t :i contiene l’elenco di tutti gli stati delle richieste per i

quali si vuole permettere la generazione di statistiche. Per
ogni stato viene indicato il codice (cod i ce) interno (che
richieste) e una descrizione (descrizione) da mostrare
all’utente nell’interfaccia grafica del sistema. Inoltre viene
anche indicato il nome del campo della tabella (campo)
che contiene lo stato delle richieste. Tramite queste
informazioni un cambiamento alla struttura della tabella
Figura 5 - 84 : La parte Stati dei metadati
Figura 5 - 83 : La parte SoddisfazioniCliente dei metadati
delle richieste o un’aggiunta, rimozione o variazione di uno

o più stati all’interno del sistema CRM, non comporta
alcuna modifica al codice della componente, ma solo una
variazione del documento XML.
5.4.3.1.2I
5.4.3.1.2INTERFACCIA DELLA COMPONENTE
L’interfaccia del Databanker è costituita solo da due metodi:

Ge tMe tada ta ( ) e Ge tDa ta ( ). Con GetMetadata ( ) i client della
119
componente possono richiedere i metadati pubblici al Databanker. I

metadati pubblici corrispondono a tutti quelli descritti
precedentemente ad esclusione delle informazioni sul database
(quindi la parte Database e tutti i nomi dei campi all’interno di Tipi,
Periodi, Gruppi, SoddisfazioniClienti e Stati).
Con GetData ( ) invece si richiedono i dati veri e propri. Il
metodo restituisce una tabella contenente le informazioni richieste.
Le colonne della tabella sono decise mediante i parametri. Per
conservare un livello di astrazione sui dati, delle richieste è
possibile richiedere gli attributi dell’entità astratta Richiesta,
individuata in fase di analisi dei requisiti e durante lo studio delle
richieste all’interno del sistema CRM. Quindi di tutte le richieste
che soddisfano determinate condizioni, si può ottenere uno o più
informazioni, passando come parametri a Ge tDa ta ( ) dei nomi
simbolici: la data con Pe r i od,i il tipo con T i p ,i il valore di
soddisfazione con SoddisfazioniCliente, il gruppo con Gruppi e lo
stato con Stati. Sarà poi il Databanker a far corrispondere questi
nomi simbolici a quelli fisici nel database. Inoltre è possibile
specificare operatori aggregati come il conteggio dei record
risultanti da una query usando la parola chiave
count(nomesimbolico).
I parametri di questo metodo per scegliere le informazioni da
restituire sono:
• InformazioniRisultati: indica i nomi simbolici delle
informazioni desiderate sulle richieste che soddisfano le
condizioni;
• RaggruppamentoRisultati: indica i nomi simbolici per cui
raggruppare le richieste che soddisfano le condizioni;
• OrdineRisultati: indica i nomi simbolici per cui ordinare le
richieste che soddisfano le condizioni;
mentre i parametri per selezionare le richieste da considerare (le
condizioni) sono:
• Gruppo: permette di scegliere le richieste effettuate da
uno o più gruppi di utenti
• Periodo: permette di scegliere le richieste che ricadono
nell’intervallo di tempo specificato nel periodo;
• Tipi: permette di scegliere le richieste di uno o più tipi;
• Soddisfazioni: permette di scegliere le richieste con uno o
più valori di soddisfazione;
• Stati: permette di scegliere le richieste in uno o più stati;
I valori per tutti i parametri sono sempre scelti tra quelli
contenuti nei metadati, in quanto il sistema permette all’utente di
personalizzare le statistiche scegliendo sempre i valori a partire da
quelli presenti nei metadati.
120
5.4.3.1.3C
5.4.3.1.3COSTRUZIONE DELLA QUERY SQL
I parametri del metodo Ge tDa ta ( ) e i metadati, insieme,
permettono al Databanker di costruire automaticamente la query
SQL che servirà ad estrarre i dati richiesti dal client.
Una query SQL standard ha la seguente forma:
SELECT campi
FROM tabella
WHERE condizione
GROUP BY campi
ORDER BY campi
Gli argomenti della query vengono costruiti nel seguente modo:

• I n f o rmaz i on iR i su l t:a tservirà
i a costruire i campi della
clausola SELECT , ai nomi simbolici verranno fatti
corrispondere i nomi fisici dei campi della tabella
servendosi dei metadati;
• Ragg ruppamen toR i su l t a t: i servirà a costruire i campi della
clausola GROUP BY , ai nomi simbolici verranno fatti
corrispondere i nomi fisici dei campi della tabella
servendosi dei metadati;
• Ord i neR i su l t a:t servirà
i a costruire i campi della clausola
ORDER BY , ai nomi simbolici verranno fatti corrispondere i
nomi fisici dei campi della tabella servendosi dei metadati;
• tramite le informazioni presenti nei metadati viene
ricavato il nome della tabella per la clausola FROM ;
• Gruppo , Pe r i odo, Tipi, Soddisfazioni e Stati: serviranno a
costruire la condizione della clausola WHERE . In
particolare dal nome del Periodo verrà creata una
condizione di confronto su un intervallo di date. Inoltre per
Tipi, Soddisfazioni e Stati verrà creata una condizione in
OR;
Ad esempio una chiamata del metodo GetData() del Databanker

con i seguenti parametri:
121
Gruppo: STUDENTI
Periodo: Settembre (01/09/2002 - 30/09/2002)
Tipi: STUDENTE-CARENZA DI SPAZI, STUDENTE-VARIE
Soddisfazioni: Indifferente, Insoddisfatto
Stati: Assegnata, Ricevuta, Chiusa
InformazioniRisultati: Periodi,Tipi,count(Tipi)
RaggruppamentoRisultati: Periodi,Tipi
OrdineRisultati: Tipi,Periodi
Produrrà, secondo le attuali informazioni contenute nei metadati,
la seguente query SQL:
SELECT CHANGE_DT, TYPE, count(TYPE)

FROM HD_INCIDENT
WHERE OWNER_GRP=’STUDENTI’ AND
(CHANGE_DT
BETWEEN
TO_DATE(‘01-09-2002 01:00:00 AM’, 'DD-MM-YYYY HH12:MI:SS PM')
AND
TO_DATE(‘30-09-2002 11:59:59 PM’, 'DD-MM-YYYY HH12:MI:SS PM')
) AND
(TYPE=’STUDENTE-CARENZA DI SPAZI’ OR TYPE=’STUDENTE-VARIE’)
AND
(CUST_SATIS=’Indifferente’ OR CUST_SATIS=’Insoddisfatto’)
AND
(STATE=’Assegnata’ OR STATE=’Ricevuta’ OR STATE=’Chiusa’)
GROUP BY CHANGE_DT, TYPE
ORDER BY TYPE, CHANGE_DT;
5.4.3.1.4T
5.4.3.1.4TECNICHE DI REALIZZAZIONE E MOTIVAZIONI
La componente Databanker è stata realizzata come un XML Web
Service, in Visual Basic .Net usando la tecnologia ASP.Net del .Net
Framework.
L’accesso al database è stato realizzato usando la tecnologia
ADO.Net in quanto ha reso estremamente semplice la restituzione
dei dati estratti dal database al client richiedente. Infatti in
ADO.Net una volta eseguita una query SQL i risultati sono posti in
un oggetto di tipo Da taSe t. Tale oggetto, se usato come tipo di
ritorno di un metodo di un Web Service ASP.Net, viene
automaticamente convertito in XML e incapsulato in un messaggio
di richiesta SOAP senza alcuno sforzo da parte dello sviluppatore.
In Figura 5-85 viene mostrata la struttura del metodo Ge tDa ta ( ),
con in evidenza l’oggetto di tipo DataSet semplicemente restituito
come parametro di ritorno.
122
Figura 5 - 85 : Un estratto del metodo GetData()
Le motivazioni che hanno spinto alla realizzazione del

Databanker come un Web Service sono di tipo logistico. Molto
spesso infatti succede che il sistema CRM risieda in una locazione
fisicamente separata da quella in cui risiede il sistema
dell’organizzazione che implementa un sistema di analisi
statistiche, sia perché un’organizzazione può essere distribuita su
più siti sia perché il sistema CRM può anche appartenere a partner
dell’organizzazione. Sfruttando così Internet come mezzo di
comunicazione tra siti distribuiti geograficamente è possibile con i
Web Service richiedere informazioni anche a distanze notevoli.
Un’altra motivazione importante è quella dell’eterogeneità dei
sistemi: molto spesso infatti i sistemi di un’organizzazione possono
essere realizzati con tecnologie e piattaforme differenti da quelli
con cui si comunica. Realizzando il Databanker come WS si assicura
che qualunque sistema richiedente che sia in grado di effettuare
richieste SOAP, sarà in grado di interrogare il databanker, a
prescindere dalla tecnologia con cui è realizzato.
Ulteriori motivazioni riguardano il superamento dei limiti delle
tecnologie proprietarie. Un’interazione mediante protocollo RMI di
Java ad esempio comporta molti problemi quando i sistemi server
sono protetti da firewall. Un WS invece utilizza il protocollo HTTP,
che solitamente non presenta problemi con i firewall.
Le motivazioni che hanno invece spinto a realizzare il Web
Service con tecnologia .Net sono da ricercare principalmente nelle
funzionalità di .Net per quanto riguarda la gestione nativa di Web
Service e documenti XML. Il codice risultante è molto semplice e
non si cura di dettagli di basso livello di ostacolo al normale lavoro
di implementazione della logica di business di un sistema.
5.4.3.2Gadget
5.4.3.2Gadget
La funzione principale della componente Gadget è di costruire
tutta l’interfaccia utente del sistema, in modo che possa essere
integrata nel portale. L’interfaccia è costituita da due elementi:
una maschera che rappresenta i risultati delle statistiche e una
123
maschera che permette all’utente di personalizzare la statistica da

eseguire.
5.4.3.2.1I
La prima maschera viene visualizzata all’interno di un gadget

del portale (chiamato Statistiche CRM) e permette anche di
accedere alla maschera di personalizzazione delle statistiche. A
seconda della modalità scelta per rappresentare i risultati, questi
saranno mostrati come un’immagine grafica (Figura 5-86) oppure
come una tabella (Figura 5-87).
Figura 5 - 86 : Il gadget all'interno del portale in modalità grafica
124
Figura 5 - 87 : Il gadget all'interno del portale in modalità tabellare
Figura 5 - 88 : Personalizzazione delle statistiche
Facendo riferimento alla Figura 5-87, tramite il link

Personalizzazione Statistiche è possibile accedere alla seconda
maschera, visibile in Figura 5-88. In questa finestra è possibile
scegliere la statistica da eseguire (nell’elenco vengono visualizzate
solo quelle che l’utente è autorizzato ad eseguire), la modalità di
visualizzazione (grafico o tabella), il numero di righe per pagina
della tabella nel caso di visualizzazione tabellare e indicare le
informazioni per scegliere determinati tipi di richieste su cui
effettuare le statistiche: il gruppo di utenti, il periodo, i tipi, i valori
di soddisfazione e gli stati. Per questi ultimi parametri è possibile
effettuare una selezione multipla. Inoltre il sistema controlla
sempre la correttezza dei dati selezionati dall’utente, onde evitare
comportamenti errati del sistema stesso e non presenta all’utente
informazioni e dettagli di basso livello (quindi niente codici, ma
solo nomi).
125
5.4.3.2.2E
5.4.3.2.2ELABORAZIONE DELLE RICHIESTE
Nel momento in cui l’utente accede alla pagina del portale che
contiene il gadget, questo comincia l’elaborazione. Vengono prima
caricate tutte le impostazioni di personalizzazione delle statistiche,
con cui verrà effettuata la chiamata alla componente Statistics
Server in modo da ottenere i risultati nel formato desiderato. Una
volta ottenuti i risultati questi vengono rappresentati o come
immagine o come tabella all’interno del gadget. Se invece l’utente
accede alla sezione di personalizzazione delle statistiche, il sistema
ottiene i metadati dalla componente Statistics Server, ottiene dal
portale i vecchi parametri di personalizzazione relativi all’utente e
infine costruisce la pagina in cui l’utente può effettuare le
modifiche ai parametri.
5.4.3.2.3T
La componente Gadget è stata realizzata come applicazione
Web, in VBScript usando la tecnologia ASP.
Le motivazioni che hanno spinto a sviluppare il sistema in ASP,
rispetto ad ASP.Net (già usato peraltro nel sistema stesso), sono
dovute alla mancanza del Plumtree .Net Gadget Developer Kit al
momento dello sviluppo di alcune parti fondamentali di questa
componente (come la formattazione della tabella e la gestione
delle preferenze dell’utente). La codifica di tale componente in
ASP.Net avrebbe invece comportato una semplificazione notevole
sia della parte di rappresentazione dei risultati (la tabella ad
esempio è disponibile come componente server di ASP.Net e la
decodifica della stringa con l’immagine avviene in automatico in
ASP.Net), sia della parte di invocazione dei Web Services
(utilizzando le classi proxy).
5.4.3.2.3.1 Invocazione degli XML Web Services
Essendo la tecnologia ASP “vecchia” rispetto agli XML Web

Services, l’invocazione del sistema Statistics Server avviene
occupandosi di dettagli di basso livello come messaggi SOAP e
richieste con protocollo HTTP. Per risolvere parzialmente questo
Figura 5 - 89 : Invocazione di un XML Web Service in ASP tramite

callWebService()
126
problema è stata creata una funzione chiamata ca l lWebSe rv i c e ( )

che si occupa dei dettagli riguardanti la parte di comunicazione
tramite HTTP, mentre nel codice che utilizza tale funzione si
gestiscono solo i dettagli riguardanti il messaggio SOAP.
In Figura 5-89 viene rappresentato un frammento di codice in cui
è usata la funzione ca l lWebSe rv i ce (: )viene prima caricato da disco
un messaggio di richiesta SOAP costruito tramite il tool XML-Spy
(linea 3), vengono inseriti i parametri all’interno dei tag XML (linee
da 5 a 7), viene richiamata la funzione (linea 10) passandole i
parametri necessari a invocare il Web Service (host che ospita il
WS, punto di accesso, namespace del servizio, metodo da invocare
e messaggio SOAP completo). Infine viene caricato il risultato del
WS all’interno di un documento XML (linea 16).
In Figura 5-90 viene invece rappresentata la funzione
ca l lWebServ i ce ( ): la richiesta HTTP viene effettuata attraverso la
componente MSXML2 .Se r ve rXMLHTTP , capace di effettuare
richieste HTTP di ogni tipo, specificando anche i parametri per
l’header del messaggio. In particolare la richiesta effettuata è di
tipo POST (linea 7), vengono indicati nell’header alcuni valori
particolari per l’invocazione del WS, ovvero Con ten t - Type e
SOAPAction (linee 11 e 12) e infine viene inviato tutto il messaggio
SOAP nel corpo del messaggio HTTP (linea 11). Il risultato viene
restituito dalla funzione così come è ricevuto dal WS (linea 17).
Figura 5 - 90 : La funzione callWebService()
5.4.3.2.3.2 Gestione delle preferenze utente
Per immagazzinare le preferenze che l’utente sceglie nella

sezione di personalizzazione delle statistiche, vengono usati i
settaggi di tipo Gadget di Plumtree. In questo modo il portale è in
grado di memorizzare le preferenze per ogni utente senza che
queste interferiscano con quelle degli altri utenti, inoltre se si
fanno più copie dello stesso gadget e le si inseriscono sulle pagine
dello stesso utente, ogni gadget avrà preferenze diverse l’uno
dall’altro.
127
Sia per estrarre che per modificare il contenuto delle variabili di

Plumtree, viene usata l’API del portale contenuta nel Plumtree ASP
Gadget Developer Kit. In particolare l’oggetto Se t t i ng s
dell’interfaccia GSSe rv i c e s, fornisce metodi per leggere e scrivere il
contenuto delle variabili. In Figura 5-91 viene mostrato un
frammento di codice in cui viene usato l’oggetto Se t t i ng .s Dopo la
creazione di un’istanza dell’oggetto Settings (linea 2), vengono
recuperati tutti i settaggi correnti (linea 3). Successivamente è
possibile sia leggere il contenuto di una variabile (linea 14, la
variabile si chiama Statistica), sia modificare il suo contenuto (linea
18) e poi riaggiornare tutti i settaggi del Portale (linea 19). In ogni
caso, sia dopo la lettura, sia dopo la scrittura, gli oggetti istanziati
vanno sempre distrutti correttamente (linee 23 e 24).
L’utilizzo delle variabili di Plumtree è stato possibile in quanto

tutte le pagine ASP sono contenute nello spazio del gateway.
5.4.3.2.3.3 Interazione con il portale
Figura 5 - 91 : Lettura e scrittura di variabili di Plumtree
L’interazione con il portale oltre che per le variabili avviene

anche per altri scopi:
• Gruppi: si è detto che il sistema si comporta in maniera
differente a seconda del gruppo a cui appartiene l’utente.
Infatti a seconda che questi appartenga a un gruppo
piuttosto che a un altro, il gadget può essere disponibile o
no e, se disponibile, può consentire di scegliere
128
determinate statistiche da eseguire. La gestione dei

permessi di visualizzazione del gadget all’interno delle
pagine dell’utente è a totale carico del sistema Plumtree,
mentre la gestione delle statistiche da visualizzare è a
carico dello sviluppatore. Inoltre nella versione del portale
utilizzata durante lo sviluppo del sistema, non erano
ancora presenti funzioni per recuperare l’elenco dei gruppi
a cui un utente appartiene. Per risolvere questo problema
è stato necessario accedere a tale informazione
direttamente nel database di Plumtree.
• HTML e aspetto grafico: un gadget di Plumtree, quando
sviluppato, deve rispettare alcune semplici regole. Prima
di tutto, quando il portale deve costruire una pagina da
mostrare all’utente, dovendo incorporare all’interno del
proprio codice HTML, anche il codice HTML del gadget,
quest’ultimo deve essere strutturato in modo che non
interferisca con il resto del codice. Quindi il codice HTML
risultante di ogni gadget non deve presentare i tag
<htm l> , <head> e <body>, ma solo quello che appare
normalmente nel tag <body> di una pagina HTML. Inoltre
non devono essere presenti frame e tutti i nomi degli
oggetti delle pagine devono avere identificatori univoci,
così come i nomi delle eventuali funzioni client-side.
Un’altra semplice regola riguarda l’aspetto grafico:
esistono nelle API di Plumtree funzioni apposite per
ottenere il foglio di stile (CSS) attualmente in uso nel
portale. Una volta ottenuto, esso va usato in tutti i gadget
in modo da rendere uniforme la colorazione e la
formattazione del testo con quella attualmente in uso nel
portale. La componente Gadget è stata sviluppata
rispettando tali regole, infatti il suo codice non interferisce
mai con il codice del portale e la colorazione e
formattazione del testo si adatta sempre a quella scelta
dall’organizzazione o dall’utente.
• Navigazione nel portale: questo tipo di interazione non
richiede particolari considerazioni, se non quella di
indicare sempre link relativi piuttosto che assoluti
all’interno delle pagine statiche e dinamiche. Infatti nelle
pagine statiche Plumtree è in grado di riconoscere i link
relativi e di sostituirli correttamente con link contenuti
all’interno dello spazio del gateway. I link assoluti invece
rimangono tali e, se seguiti, portano l’utente fuori dal
portale, con conseguente perdita della sessione. Inoltre
laddove sia necessario riaggiornare i contenuti della
pagina del portale, vengono sempre usate le funzioni
messe a disposizione dalle API di Plumtree.
5.4.3.2.3.4 Rappresentazione delle statistiche
129
Si è detto in precedenza che i risultati delle statistiche possono

essere rappresentati in formato tabellare o in formato grafico.
Nel caso del formato tabellare, il sistema dopo aver richiesto
l’elaborazione di una statistica, trasforma i risultati in una tabella
HTML da mostrare nel gadget del portale (Figura 5-87).
L’invocazione del Web Service componente Statistics Server
restituisce sempre un documento XML contenente un vettore con
tutte le celle della tabella e le dimensioni della tabella. Una
funzione si occupa di ricreare dal vettore la struttura tabellare dei
dati. Inoltre, a seconda delle preferenze dell’utente, viene mostrato
solo un determinato numero di righe per pagina, dando all’utente la
possibilità di navigare tra le pagine della tabella tramite una barra
con i link alle pagine.
Nel caso del formato grafico, il sistema dopo aver richiesto
l’elaborazione di una statistica, inserisce semplicemente un
riferimento HTML all’immagine grafica. Questa immagine viene
immagazzinata in un file che risiede sul Gadget Server che ospita il
gadget e grazie al gateway sarà correttamente visualizzata
dall’utente, anche se il GS non è direttamente accessibile da
Internet (come dovrebbe sempre avvenire). L’invocazione del Web
Service Statistics Server restituisce sempre un documento XML
contenente una stringa. All’interno di questa stringa è contenuta
l’immagine ma codificata secondo l’algoritmo Base64. Questo è
necessario in quanto i messaggi SOAP, essendo in realtà XML, non
sono in grado di trasportare dati in formato binario. La codifica
Base64 invece è in grado di rappresentare dati binari in formato
testuale (ovviamente a scapito di un aumento delle dimensioni del
file). Una volta ottenuta la stringa, questa viene prima convertita
da stringa Base64 in un vettore di byte, per poi essere salvata su
disco come un normalissimo file binario. La conversione è ottenuta
sfruttando una componente chiamata JSBin installata sul Gadget
Server. Tale componente è infatti in grado di codificare e
decodificare usando l’algoritmo Base64 ed è usata anche in altre
parti del sistema.
Per evitare conflitti tra i file immagazzinati sul GS, questi
vengono salvati usando l’identificatore univoco del gadget
(GadgetID), ottenibile sempre attraverso l’API del portale. Tale
pratica di usare il GadgetID all’interno del proprio codice, è molto
ricorrente e permette di risolvere moltissimi problemi ricorrenti
durante lo sviluppo di applicazioni di tipo Web multiutente.
5.4.3.3Statistics
5.4.3.3Statistics Server
La funzione principale della componente Statistics Server è
quella di fornire un’interfaccia di accesso unica al sistema per la
componente Gadget (quindi la parte del sistema che si occupa della
presentazione). Realizzato secondo il design pattern façade (vedere
Pagina 40), è in grado di presentare alle componenti client i dati
130
provenienti da sistemi eterogenei (Excel e Statistica) in un formato

unico.
La componente non esegue nessuna elaborazione statistica, ma
si occupa solo di invocare la componente in grado di effettuare la
statistica richiesta dall’utente e di convertire i dati ottenuti in un
formato standard. Altra funzionalità svolta è quella di restituire alla
componente Gadget i metadati relativi sia alle statistiche che il
sistema è in grado di effettuare, sia su quali dati il sistema è in
grado di effettuare statistiche.
Inoltre, è stato deciso di fare in modo che cambiamenti nelle
statistiche effettuabili dal sistema avessero un impatto minimo se
non nullo sulla componente. Per ottenere ciò, la componente fa uso
di metadati.
5.4.3.3.1M
5.4.3.3.1METADATI
I metadati descrivono quali statistiche il sistema è in grado di
eseguire. Il formato scelto per la loro archiviazione sul server è
quello XML, per la semplicità con cui è possibile gestire documenti
di questo tipo e per la loro predisposizione naturale a contenere
informazioni quali i metadati.
All’interno del documento XML (Figura 5-92) sono elencate tutte
le statistiche, ognuna descritta da diversi elementi: un codice
interno al sistema (cod i ce), la componente COTS da utilizzare per
eseguirla (gene ra t o r e), un nome da mostrare all’utente durante la
sua interazione con il sistema (nome), i gruppi di utenti del portale
che sono abilitati a visualizzare la statistica (gruppi) e una serie di
informazioni utilizzate per richiedere al Databanker i dati corretti
sulle richieste (informazioniRisultati, raggruppamentoRisultati,
ordineRisultati), di cui si è parlato in modo approfondito in
precedenza. In aggiunta è presente anche un elenco di nomi
(informazioniRisultatiTitoloTabella) che verranno usati, nel caso di
rappresentazione tabellare dei risultati, come intestazioni delle
colonne della tabella.
Figura 5 - 92 : Frammento dei metadati sulle statistiche
L’aggiunta, modifica o cancellazione di una statistica dal sistema

non comporta alcuna modifica al codice della componente
Statistics Server, ma solo al documento XML dei metadati.
131
5.4.3.3.2I
L’interfaccia di Statistics Server è costituita solo da tre metodi:

Ge tMe tada ta ( ), Ge tS ta t i s t i cA sG raph (e) GetStatisticAsTable(). Con
GetMetadata ( ) i client della componente possono richiedere i
metadati pubblici dell’intero sistema, composti a partire dai
metadati relativi a:
• Statistiche: di tutti i metadati descritti in precedenza
riguardo le statistiche, solo il codice interno, il nome e i
gruppi sono considerati pubblici;
• Dati: corrispondono ai metadati pubblici del Databanker.
GetStat i s t i cAsGraph( ) e GetStat i s t i cAsTab le ( ) sono usati

invece entrambi per richiedere al sistema di eseguire una
statistica, restituendo però i risultati in due formati diversi: un
grafico o una tabella. Sui risultati delle statistiche, la componente
non esegue nessun intervento, vengono invece solo incapsulati in
una struttura di un unico formato a prescindere dal sistema che li
ha generati. Nel caso del grafico questa struttura corrisponde a una
stringa di testo contenente l’immagine grafica codificata, mentre
nel caso della tabella corrisponde a una matrice linearizzata in un
vettore con il contenuto delle celle e due valori per indicare il
numero di righe e di colonne della tabella.
5.4.3.3.3E
Il modo in cui la componente elabora le richieste è molto
semplice e non cambia tra i due metodi GetStatisticAsGraph() e
GetStatisticAsTable(): quando un client richiede l’esecuzione di una
statistica, Statistics Server legge i metadati sulle statistiche,
individua la componente da utilizzare per eseguire la statistica, di
quest’ultima invoca il metodo relativo al formato richiesto per i
risultati (tabella o grafico), prepara i risultati nel formato unico e li
restituisce al richiedente.
5.4.3.3.4T
La componente Statistics Server è stata realizzata come un XML
Web Service, in Visual Basic .Net usando la tecnologia ASP.Net del
.Net Framework e l’ambiente di sviluppo Web Matrix.
Per ognuno dei Web Service invocati dalla componente, è stata
generata una classe proxy utilizzando il tool di Web Matrix. Questo
ha permesso sia di ridurre e semplificare drasticamente il codice
necessario, sia di riusare strutture dati come quella che contiene i
metadati del Databanker.
Le motivazioni che hanno spinto a realizzare questa componente
come Web Service sono del tutto simili a quelle già citate per il
Databanker.
132
5.4.3.4Excel
5.4.3.4Excel Server
La funzione principale della componente Excel Server è eseguire
statistiche di tipo semplice a partire dai dati sulle richieste ottenuti
dal Databanker. Il nome della componente deriva dall’aver usato il
COTS Microsoft Excel 2000 per eseguire le statistiche.
Le statistiche eseguite da questa componente sono tre (Figura 5-
93):
• Andamento richieste per tipo: quando rappresentata come
grafico, mostra un diagramma con due assi: sull’asse X
sono indicati tutti i giorni nel periodo scelto, sull’asse Y è
riportata una scala di valori corrispondenti al numero di
richieste. Per ogni tipo di richiesta viene rappresentato,
con un colore diverso, il numero totale di richieste di
questo tipo per ogni giorno. I punti poi sono legati tra loro
da una linea, in modo da mostrare l’andamento delle
richieste giorno per giorno. Quando rappresentata come
tabella, mostra una tabella a tre colonne: nella prima sono
riportati i giorni nel periodo, nella seconda i tipi e nella
terza il numero di richieste. Chi richiede l’elaborazione,
può indicare i tipi, il periodo, gli stati e i valori di
soddisfazione per poter selezionare le richieste.
• Totale richieste per tipo: quando rappresentata come
grafico, mostra un istogramma con due assi: sull’asse X è
indicata una scala di valori corrispondenti al numero di
richieste, sull’asse Y sono riportati i tipi. Per ogni tipo di
richiesta viene rappresentato il numero totale di richieste
di questo tipo, come valore e come barra. Quando
rappresentata come tabella, mostra una tabella a due
colonne: nella prima sono riportati i tipi e nella seconda il
numero di richieste. Chi richiede l’elaborazione, può
indicare i tipi, il periodo, gli stati e i valori di soddisfazione
per poter selezionare le richieste.
133
• Percentuale soddisfazione clienti: quando rappresentata

come grafico, mostra un grafico a torta. Le fette della
torta rappresentano la percentuale di richieste che hanno
un determinato valore di soddisfazione cliente. Per ogni
fetta viene indicata anche la percentuale di richieste.
Quando rappresentata come tabella, mostra una tabella a
due colonne: nella prima sono riportati i valori di
soddisfazione e nella seconda il numero di richieste. Chi
richiede l’elaborazione, può indicare i tipi, il periodo, gli
stati e i valori di soddisfazione per poter selezionare le
richieste.
Figura 5 - 93 : Le tre statistiche in formato grafico
L’interfaccia di Excel Server è costituita solo da due metodi:

ge tS t a t i s t i cA sCha r te( ge
) tS t a t i s t i cA s Tab l.e ( )
getStat i s t i cAsChar t ( ) restituisce il risultato dell’elaborazione
della statistica in formato grafico: il grafico corrisponde a una
immagine che viene restituita all’interno di una stringa codificata
secondo l’algoritmo Base64 (confrontare quanto già detto a Pagina
143).
getStat i s t i cAsTab le ( ) invece restituisce il risultato
dell’elaborazione della statistica in formato tabellare: la tabella è
134
restituita con una matrice linearizzata in un vettore con il

contenuto delle celle.
5.4.3.4.2E
Il modo in cui la componente elabora le richieste non cambia
sostanzialmente tra i due metodi ge tS t a t i s t i cA sCha r t ( e
)
ge tS t a t i s t i cA s Tab l:e quando
() un client richiede l’elaborazione di
una statistica, Excel Server richiede al Databanker prima i metadati
e poi i dati corrispondenti ai parametri inviati dal client. Una volta
ottenuti i dati, a seconda della statistica richiesta viene richiamata
la funzione che la effettua (attualmente quindi ci sono tre funzioni).
All’interno di ognuna di queste funzioni, viene creato un foglio di
calcolo in Excel e al suo interno vengono inseriti i dati secondo il
formato appropriato. Se la statistica è richiesta in formato grafico,
viene prima creato il grafico con Excel e poi restituito al
richiedente. Se invece la statistica è richiesta in formato tabellare,
viene restituito il contenuto delle celle del foglio di calcolo.
L’elaborazione dei dati richiesti al Databanker richiede
particolari considerazioni: si è detto che il Databanker estrae i dati
dal database usando query SQL. Come è noto, una query SQL di
selezione con un operatore aggregato quale il conteggio di record
(coun t) è in grado di estrarre solo dati realmente esistenti. Ad
esempio, se si richiede di contare tutte le richieste di tipo A, ma nel
database non esiste nessun record con richieste di tipo A, nel
risultato della query non sarà indicato il valore 0 (zero) come ci si
aspetta, semplicemente non apparirà alcun valore. Per ovviare a
questo problema durante l’elaborazione dei dati, viene effettuato
un controllo aggiuntivo sui dati restituiti.
5.4.3.4.3T
La componente Excel Server è stata realizzata come un XML Web
Service, a partire da una componente COM realizzata in Visual
Basic e poi esposta come Web Service attraverso il tool SOAP
Toolkit.
La componente COM è stata realizzata come DLL usando
l’ambiente di sviluppo integrato Microsoft Visual Studio 6. Una volta
compilata, la DLL è stata prima registrata sul sistema server che
ospita il Web Service e poi esposta come Web Service utilizzando il
tool SOAP Toolkit.
La componente è una normalissima classe Visual Basic, per la
quale però vanno fatte alcune considerazioni tecniche: prima di
tutto Visual Basic 6 non fornisce alcun supporto nativo per i Web
Service, quindi tutte le interazioni con essi vanno gestite allo
stesso modo in cui vanno gestite in ASP e di cui si è parlato in
precedenza (vedere Pagina 140). Oltre al mancato supporto dei WS,
non c’è alcun supporto nativo per i documenti XML se non
utilizzando la componente COM XMLDOM .
135
Ma l’attenzione maggiore va posta all’interazione della DLL con

il resto del sistema: nel momento in cui la DLL viene richiamata a
run-time perché invocata come WS, non si può far alcun riferimento
a file usando percorsi relativi. Nel momento in cui si vuole caricare
da disco i messaggi SOAP per le richieste al Databanker, si deve
ricorrere a un particolare stratagemma: invece di aprire il file XML
da disco, lo si “scarica” utilizzando il protocollo HTTP dalla
directory virtuale del server Web su cui risiede il WS stesso. Un
altro problema deriva da questioni di sicurezza e autorizzazioni: nel
momento in cui viene invocato il WS, il sistema carica ed esegue la
DLL utilizzando come utente l’utente anonimo Internet (Internet
Guest Account). Tale utente, per motivi di sicurezza, sui sistemi
Windows 2k/NT ha pochissimi diritti, a volte di sola lettura sui file
nella directory virtuale del server Web. Se all’interno della DLL si
vuole quindi accedere a file che risiedono in altre directory del
sistema, o si vuole accedere in scrittura a file (ad esempio per
esportare da Excel l’immagine del grafico in una directory
temporanea), o ancora si vuole eseguire programmi (come Excel), è
necessario assegnare i diritti necessari all’utente anonimo, pena il
fallimento di qualsiasi operazione di questo tipo.
Per quanto riguarda invece i dati restituiti dal WS, si notano
subito le limitazioni di un linguaggio quale Visual Basic 6 (VB6)
rispetto a questa tecnologia: quando si sviluppa un WS, uno dei
vantaggi maggiori che alleggerisce notevolmente il carico di lavoro
dello sviluppatore, deriva dalla possibilità di far restituire ai metodi
oggetti complessi e strutture dati senza preoccuparsi in alcun modo
della conversione in documenti XML. In VB6 invece un metodo
pubblico di una classe non può restituire tipi di dati diversi da
quelli primitivi. A causa di ciò, lo sviluppatore deve preoccuparsi di
convertire tutti i dati in un formato tra quelli disponibili e molto
spesso la scelta ricade o sulla stringa o sul vettore. Nella
componente Excel Server, per restituire l’immagine grafica è stata
utilizzata una stringa contenente la rappresentazione in Base64 dei
dati binari, utilizzando la componente JSBin per effettuare la
conversione. Per restituire invece la tabella, questa è stata prima
linearizzata in un vettore di stringhe. La conversione in documenti
XML avviene invece in automatico grazie al tool SOAP Toolkit, ma
solo se si usano tipi di dati supportati dalla tecnologia COM.
Queste pratiche oltre a richiedere uno sforzo di programmazione
notevole, diminuiscono anche la naturalezza del codice sia sul
server sia sul client di un WS, oltre ad aumentarne la complessità.
L’interazione con il COTS MS Excel 2000 avviene utilizzando la
sua interfaccia COM. Di essa si è già parlato in precedenza, ciò che
qui va aggiunto è il modo in cui questa interazione deve avvenire:
in un WS Document oriented si è detto che l’interazione è di tipo
richiesta-risposta e che tutta l’elaborazione sul server deve essere
eseguita tra la richiesta e la risposta. Tutto questo comporta in
termini pratici la necessità di strutturare il sistema in un modo
particolare: ogni volta che viene invocato un metodo del WS e per
ogni richiesta, il sistema deve eseguire Excel, ottenere dal
136
Databanker metadati e dati, elaborare la statistica, chiudere Excel

e restituire i risultati. Non è possibile ad esempio aprire Excel una
sola volta e riusare la stessa istanza dell’oggetto COM per tutte le
richieste pervenute al WS.
come Web Service sono simili a quelle già citate per il Databanker.
Ciò che ha spinto invece a realizzarla a partire da una componente
COM è prima di tutto una motivazione di tipo sperimentale, ovvero
esplorare le modalità in cui sia possibile esporre come Web Service
un sistema appartenente alla “vecchia generazione”, misurandone
la difficoltà effettiva. Un’altra motivazione è invece di tipo tecnico:
il COTS Microsoft Excel 2000, a differenza della versione XP, non
fornisce alcun supporto per il .Net Framework. Una realizzazione
della componente utilizzando la tecnologia .Net avrebbe
comportato difficoltà eccessive a causa della mancanza degli RCW
(vedere Pagina 93) necessari in queste circostanze.
5.4.3.5Statistica
5.4.3.5Statistica Server
La funzione principale della componente Statistica Server è
eseguire statistiche di tipo complesso a partire dai dati sulle
richieste ottenuti dal Databanker. Il nome della componente deriva
dall’aver usato il COTS Statsoft Statistica 6 per eseguire le
statistiche.
Le statistiche eseguite da questa componente sono
essenzialmente una, ovvero il Grafico X and Moving R sulle
richieste. Quando rappresentata come grafico, mostra un
diagramma XmR come quello descritto a Pagina 80 e visibile in
Figura 5-44. La variabile utilizzata per la statistica è quella
contenente per ogni data nel periodo, il numero totale di richieste.
Chi richiede l’elaborazione, può indicare i tipi, il periodo, gli stati e
i valori di soddisfazione per poter selezionare le richieste.
5.4.3.5.1I
L’interfaccia di Statistica Server è costituita solo da due metodi:
ge tS t a t i s t i cA sCha r te( ge
) tS t a t i s t i cA s Tab l.e ( )
getStat i s t i cAsChar t ( ) restituisce il risultato dell’elaborazione
della statistica in formato grafico: il grafico corrisponde a una
immagine che viene restituita all’interno di una stringa codificata
secondo l’algoritmo Base64 (confrontare quanto già detto a Pagina
143).
getStat i s t i cAsTab le ( ) invece restituisce il risultato
dell’elaborazione della statistica in formato tabellare: la tabella è
restituita con una matrice linearizzata in un vettore con il
contenuto delle celle.
137
5.4.3.5.2E
L’elaborazione delle richieste è del tutto simile a quella della
componente Excel Server, tanto che sia il codice, che le modalità di
utilizzo del COTS sono identiche. Si può far riferimento quindi a
quanto già detto a Pagina 151, sostituendo Excel con Statistica.
Stesse considerazioni vanno fatte riguardo i dati richiesti al
Databanker.
5.4.3.5.3T
La componente Statistica Server è stata realizzata come un XML
Web Service, in Visual Basic .Net usando la tecnologia ASP.Net del
.Net Framework e l’ambiente di sviluppo Web Matrix.
La struttura del sistema e il codice sono del tutto simili a quelli
di Excel Server, tanto che si è riusato molto del codice scritto per
quest’ultimo.
Per l’interazione con il COTS Statsoft Statistica 6 è stato
utilizzato l’RCW fornito da Statsoft all’interno di un pacchetto di
esempi di integrazione. L’utilizzo quindi all’interno del codice è del
tutto identico a quello di una normalissima classe appartenente ad
esempio alla BCL di .Net Framework. A causa però della mancanza
di un RCW per l’espansione Quality Control (QC) del pacchetto, nel
momento in cui si voleva restituire i risultati della statistica in
formato grafico, è stato necessario ricorrere a uno stratagemma:
invece di utilizzare gli oggetti e le funzionalità di QC direttamente
nel codice ASP.Net, si è costruita una macro SVB utilizzando l’editor
interno di Statistica, che viene poi lanciata nel momento richiesto
dal codice ASP.Net. Lo scambio di dati tra la macro e la componente
Statistica Server, avviene mediante file temporanei (nello stesso
modo in cui avviene in Excel Server). Infine anche per Statistica
Server valgono le considerazioni sulla strutturazione del sistema
dettate dalla natura Document oriented dei WS.
Per l’invocazione del Web Service Databanker Server, è stata
generata una classe proxy utilizzando il tool di Web Matrix. Questo
ha permesso sia di ridurre e semplificare drasticamente il codice
necessario, sia di riusare strutture dati come quella che contiene i
metadati del Databanker.
Per quanto riguarda i dati restituiti, in ASP.Net non vi sono
problemi come quelli incontrati durante lo sviluppo di Excel Server:
la conversione in documenti XML è automatica, per qualunque tipo
di dato di .Net Framework. Inoltre in VB.Net i metodi pubblici delle
classi possono restituire oggetti di qualsiasi tipo, anche definito
dall’utente. La codifica delle immagini in Base64 avviene usando
funzionalità delle BCL, senza utilizzare alcun componente esterno.
Si è scelto inoltre di restituire la tabella come vettore, per rendere
uniforme il codice di gestione dei risultati sulla componente
Statistics Server, con quello che gestisce i risultati del WS Excel
Server.
138
Anche per questa componente valgono le stesse considerazioni

sulla sicurezza e le autorizzazioni che si sono fatte già per la
componente Excel Server.
come Web Service sono del tutto simili a quelle già citate per il
Databanker. In aggiunta è stato necessario sviluppare la
componente in questo modo a causa di discutibili limitazioni di
licenze sul COTS Statistica: infatti Statsoft non permette di
utilizzare il proprio prodotto se questo viene istanziato come
componente COM da un utente Internet anonimo. Una realizzazione
come quella di Excel Server è da scartare, in quanto l’oggetto COM
sarebbe stato istanziato dall’utente anonimo. Si è però notato che,
data la relativa novità del .Net Framework, gli sviluppatori di
Statistica 6 non hanno pensato di escludere l’utente anonimo di
ASP.Net (che ha un nome diverso da Internet Guest Account) e
quindi istanziando l’oggetto COM tramite relativo RCW all’interno di
un WS realizzato in ASP.Net, il COTS Statistica 6 funziona senza
alcun problema. A posteriori si è però notato che, anche
realizzando la componente come WS ASP.Net, la creazione
dell’istanza dell’oggetto COM tramite relativo RCW, avviene
correttamente solo se la
richiesta al WS è eseguita
in locale dallo stesso
sistema che ospita il WS e
se il server Web che ospita
il WS non è Microsoft IIS.
Per ovviare a questo
problema è bastato
Figura 5 - 94 : Il gadget del portale
ospitare sullo stesso
sistema sia il WS Statistica
Server sia Statistics Server, in questo modo per Statistica Server la
richiesta appare come una richiesta locale, anche se in realtà poi
Statistics Server viene invocato da remoto. Per ovviare invece al
problema del server Web, si è utilizzato il server Web fornito nel
tool Web Matrix, il quale come detto accetta solo richieste da
locale.
5.4.3.6Gadget
5.4.3.6Gadget Messaggi CRM
Questa componente non comprare nell’architettura del sistema
in quanto è stata sviluppata solo ai fini della sperimentazione, per
simulare una situazione tipica in cui un utente accede alla sezione
Messaggi del sistema CRM attraverso il portale (facendo
riferimento alla Figura 5-74, questa componente dovrebbe
appartenere in futuro alla parte destra dell’architettura). Non sono
stati quindi curati molto i dettagli implementativi e l’interazione
con il portale non è perfetta.
La componente è composta da un gadget visualizzato all’interno
delle pagine del portale (Figura 5-94), dal quale è possibile
139
Figura 5 - 95 : La pagina per l'invio delle richieste
accedere a tutte le funzionalità di messaggistica del sistema CRM:

invio di messaggi (Invia Messaggio) al sistema CRM, visualizzazione
dei messaggi inviati (Messaggi Inviati) e ricevuti (Messaggi
Ricevuti).
Ognuno di questi link mostra una finestra del browser con
all’interno la stessa pagina Web accessibile dal sistema CRM. La
differenza è che l’accesso al sistema avviene in modo automatico
dopo aver effettuato la login nel portale. In Figura 5-95 viene
mostrata la pagina per l’invio di una richiesta al sistema.
L’interazione con il portale avviene allo stesso modo in cui
avviene nella componente Gadget (in particolare con la pagina
della personalizzazione delle statistiche). L’interazione invece con
il sistema Applix iEnterprise CRM avviene utilizzando la API Weblink
2000.
Grazie all’API Weblink 2000, la componente è in grado di

effettuare automaticamente il login sul sistema CRM a partire dalla
login con cui è connesso al portale. La funzione per eseguire la
login è il metodo EWLog in ( ) dell'oggetto EntWeb.Ma in . Questo
metodo ritorna un codice che identifica la sessione corrente
dell’utente all’interno del sistema CRM e che verrà usato in tutti gli
altri metodi dell’oggetto En tWeb .Ma i n per far corrispondere le
140
operazioni che si effettuano con la sessione dell’utente. In realtà il

motivo di tale scelta è dovuto alla modalità di elaborazione di
un’applicazione Web: quando si usa l’oggetto En tWeb .Ma i n
all’interno di una pagina (dinamica o statica) si usa un’istanza di
questo oggetto, nel momento che si passa a un’altra pagina
l’istanza dell’oggetto En tWeb .Ma i n è diversa da quella della pagina
precedente. Per ovviare a questo o si riesegue la login sul sistema
ogni volta che si istanzia l’oggetto EntWeb.Main o si tiene traccia
della sessione tramite un codice (come hanno pensato i progettisti
dell’API WebLink 2000) e si usa tale codice per riferirsi ad essa
all’interno di tutte le pagine dinamiche.
Dopo l’operazione di login automatica la componente estrae dal
server Applix, le pagine Web che formano l’applicazione (o una sua
parte). L’estrazione delle pagine avviene richiamando prima il
metodo EWCreateOb jec t ( ) di EntWeb.Main e poi il metodo
EWDisp layOb jec t ( ) dello stesso oggetto. Con il primo metodo
viene creato sul server Applix un oggetto corrispondente
all’oggetto dell’applicazione desiderata (un form, una query, un
grafico, ecc…). Con il secondo metodo invece viene recuperato dal
server Applix il file HTML con all’interno la versione HTML
dell’oggetto.
Durante l’interazione con le pagine Web, vengono richiamate
diverse pagine dinamiche appartenenti al pacchetto WebLink 2000.
Tali pagine sono tuttavia modificabili e personalizzabili, in quanto in
formato ASP.
Al termine dell’interazione viene eseguito il logout dal sistema
tramite il metodo EWLogout ( ) di EntWeb.Main.
5.4.4Allocazione
5.4.4Allocazione del sistema e sicurezza
Il sistema realizzato utilizzando i Web Services ha permesso una
semplice distribuzione delle componenti su diversi sistemi, in modo
da distribuire il carico di lavoro e riprodurre quanto più possibile la
situazione reale di utilizzo di un sistema del genere quando messo
in funzione realmente.
All’interno del laboratorio di ricerca SER_Lab sono state
utilizzate per ospitare il sistema tre macchine:
• Serlab10: sistema Windows 2000 Server con Microsoft IIS
5, Plumtree Gadget Server e Plumtree ASP GDK. Ospita la
componente Gadget e il Gadget Messaggi CRM usato per la
sperimentazione;
• Serlab23: sistema Windows 2000 Server con Microsoft IIS
5, Web Matrix Web Server, Microsoft Excel 2000, Statsoft
Statistica 6, Microsoft .Net Framework. Ospita le
componenti Statistics Server, Excel Server e Statistica
Server. Questa macchina ospita anche il sistema CRM
usato per la sperimentazione;
141
• Serlab26: sistema Windows XP Professional con Microsoft

IIS 5, Microsoft .Net Framework, Oracle 8i DB. Ospita la
componente Databanker Server, in quanto su questa
macchina è installato il database del sistema CRM. In
realtà questa macchina ospita anche il Plumtree Portal
Server, ma ciò non ha influito minimamente sul sistema
realizzato.
Tutti i Web Services utilizzano come server Web Microsoft IIS 5,

ad esclusione di Statistica Server che utilizza il server Web interno
di Web Matrix. Alla configurazione di IIS e delle directory virtuali va
prestata molta attenzione, a causa dei requisiti di sicurezza dovuti
ai Web Services: tutte le directory che ospitano WS devono avere
diritti di accesso per gli utenti Internet anonimi ed Eve r yone,
inoltre per i WS ASP.Net anche l’utente aspne t e SYSTEM devono
avere diritti di accesso alle directory. I WS che utilizzano Excel e
Statistica devono risiedere in directory virtuali con permesso di
esecuzione di script ed eseguibili (i due COTS) e devono
impersonificare un utente del gruppo Amministratori. I diritti di
accesso alle directory per il WS Databanker server sono di sola
lettura e l’utente impersonificato è quello Internet anonimo.
Nonostante questa configurazione di sicurezza possa sembrare in
alcuni punti troppo insicura, c’è da dire che tutto il sistema
solitamente non è accessibile direttamente da Internet, ma solo
attraverso il portale, il quale grazie il gateway nasconde all’esterno
il sistema compreso nello spazio del gateway. Lo spazio del
gateway quindi coincide con la rete interna dell’organizzazione o
una rete privata sicura. Ma anche se in futuro si decidesse, com’è
prevedibile che sia, di distribuire le componenti su altri sistemi
appartenenti a reti diverse tra loro interconnesse attraverso
Internet, la sicurezza può essere facilmente incrementata,
semplicemente installando firewall su ogni macchina esposta e
configurando il server Web in modo che accetti solo connessioni
protette da password e su porte non convenzionali (cioè diverse
dalla porta HTTP standard 80), o ancora, soprattutto per il
Databanker Server che restituisce dati sensibili, permettendo
l’accesso solo in modo cifrato utilizzando il protocollo HTTPS 2 4 o
protocolli di sicurezza come WS-Security per i messaggi SOAP.
24
HTTPS (Hypertext Transfer Protocol over Secure Socket Layer, o HTTP over SSL)
è un protocollo Web sviluppato da Netscape che cripta e decripta le richieste di
pagine così come le pagine restituite dal server Web. HTTPS è uno strato
sottostante il normale stratto HTTP, ma nell'interazione con il livello TCP/IP
sottostante utilizza la porta 443 al posto della normale porta 80. SSL inoltre
utilizza chiavi di 40-bit di dimensione per l'algoritmo di crittazione del flusso
RC4, la dimensione di 40-bit per le chiavi fornisce un livello di crittazione
considerato adeguato per scambi di tipo commerciale.
142
5.5Componenti valutate ma non utilizzate

Prima della realizzazione effettiva del progetto è stata effettuata
una valutazione di alcuni sistemi e COTS, al fine di valutarne le
possibilità di integrazione, i pregi e i difetti derivanti dal loro
effettivo utilizzo. In particolare sono state valutate due alternative
al portale poi effettivamente utilizzato e un’alternativa a una parte
del sistema poi realizzato.
5.5.1Oracle
5.5.1Oracle 9i
9i Portal
La soluzione di Oracle per il mercato dei portali segue
l’approccio di tutti i prodotti appartenenti alla famiglia di prodotti
Oracle: integrazione completa con il DBMS Oracle 9i DB, supporto
completo della piattaforma Java2 (soprattutto Enterprise Edition),
attenzione particolare per scalabilità, sicurezza e tolleranza ai
guasti. Tuttavia la valutazione di Oracle Portal ha evidenziato
grosse carenze soprattutto nell’area delle tecnologie supportate.
Oracle, come è noto, è da sempre sostenitrice della tecnologia Java
e in competizione con altri fornitori, soprattutto Microsoft. Come
risultato, il difetto maggiore di Oracle Portal è risultato essere il
supporto esclusivo di Java per lo sviluppo di portlet 2 5 e supporto
pressoché assente di qualsiasi tecnologia Microsoft. Anche se i Web
services permettono di fare astrazione sulla piattaforma, è pur
sempre vero che all’interno di un’organizzazione spesso sia
necessario utilizzare tecnologie diverse da Java, soprattutto per
integrare sistemi legacy pesantemente legati a tecnologie
Microsoft.
I vantaggi di Oracle Portal rispetto agli altri portali valutati,
vanno cercati soprattutto nell’area della formattazione e
disposizione dei contenuti nelle pagine del portale. Inoltre grazie al
legame con il DBMS Oracle 9i, sono presenti numerosi strumenti
per esporre le informazioni presenti all’interno del database
all’interno delle portlet. Tuttavia questo legame profondo con il
database Oracle 9i DB potrebbe anche essere un punto a sfavore,
in quanto all’interno di un’organizzazione che non utilizza Oracle 9i
DB, Oracle Portal non è facilmente implementabile.
5.5.2mySAP
5.5.2mySAP Enterprise Portal 5.0
La soluzione di SAP per il mercato dei portali è un sistema che,
contrariamente all’opinione comune, è completamente
indipendente dagli altri prodotti di SAP (R/3 2 6 e la soluzione
25
Portlet è il termine con cui si indica solitamente un’applicazione Java
sviluppata per essere utilizzata all’interno di un portale. Il termine ha origine
simile ai termini applet e servlet.
26
R/3 è l'insieme di applicazioni di business integrate fornito da SAP. R/3 usa il
modello client/server e fornisce la possibilità di immagazzinare, accedere,
analizzare e processare in modi differenti i dati dell'organizzazione per analisi
finanziarie, ciclo produttivo, gestione delle risorse umane e in generale la
maggiorparte dei processi di business. Un sistema di questo tipo viene indicato
con il nome di Enterprise Resource Planning (ERP), di cui SAP è leader mondiale
143
mySAP.com 2 7 ), pur mantenendo elevate possibilità di integrazione

fornite da tool e ambienti di sviluppo fornite da SAP stessa.
Contrariamente a quanto dichiarato dal produttore, il supporto
per la tecnologia Microsoft è molto limitato, mentre il supporto di
Java2EE è agli stessi livelli, se non superiore a quanto verificato in
Oracle Portal. SAP dichiara di supportare il .Net Framework, mentre
nei fatti l’unica possibilità fornita è quella di poter scrivere iViews 2 8
in ASP, che come noto non appartiene al .Net Framework. Inoltre il
supporto per ASP non contempla la possibilità di interagire dal
codice con il portale stesso, mancando infatti tutti quegli oggetti
che permettono invece al codice scritto in Java di interagire con
ogni singolo dettaglio del portale. Questo dislivello di supporto per
le due tecnologie, crea a tutti gli effetti gli stessi svantaggi
incontrati in Oracle Portal.
Se a tutto ciò si aggiunge una complessità eccessiva
nell’ambiente di amministrazione e nella gestione degli utenti, si è
arrivati alla conclusione che tale prodotto non è assolutamente
conciliabile con i requisiti del lavoro di tesi. Gravissime lacune
esistono anche nel supporto dei
browser diversi da Microsoft
Internet Explorer 5 o superiori.
5.5.3Plumtree
5.5.3Plumtree Excel Gadget
Service
Plumtree Excel GS permette
agli utenti del portale di creare
gadget che mostrano le
informazioni presenti all’interno
di fogli di calcolo, tabelle e
grafici archiviati in file di
Microsoft Excel. Questo COTS è
stato valutato al fine di
verificarne l’adeguatezza per
l’integrazione all’interno del
sistema, al fine di evitare
l’implementazione della
componente, poi effettivamente
proprio con R/3.

27
mySAP.com è il software di integrazione per l’e-business che fornisce contenuti
agli utenti in base al loro ruolo nell'organizzazione. Esistono più di 200 modelli
predefiniti disponibili per fornire l'accesso ad applicazioni e risorse come CRM,
Figura 5 - 96 : Architettura di Excel
supply chain management (SCM), e-procurement, business intelligence, gestione
GS
del ciclo di vita dei prodotti, risorse umane (HR). L'utente è in grado di interagire
con le applicazioni SAP attraverso un comune browser Web attraverso Internet,
collegandosi al portale Web di mySAP.com, chiamato "Workplace".
28
IViews è il termine con cui in mySAP Enterprise Portal vengono indicati i
gadget o le portlet. SAP comunque utilizza spesso anche il termine portlet per
uniformarsi alla letteratura sui portali.
144
realizzata, di gestione della presentazione ed elaborazione delle

statistiche di tipo semplice.
Nonostante l’architettura elaborata (Figura 5-96), la componente
si è rivelata subito essere inadeguata allo scopo, a causa di tre
grosse limitazioni:
• Limite minimo di aggiornamento dei contenuti del gadget
pari a 30 minuti. Tale limite esclude ai fini pratici tutti i
vantaggi nell’avere un’elaborazione statistica dei dati in
tempo reale.
• Possibilità di visualizzare solo informazioni all’interno di
documenti Excel salvati sul file system NTFS 2 9 o inviati sul
Gadget Server via HTTP. Una limitazione grave in quanto i
documenti devono essere già disponibili su disco e non
possono essere invece creati in tempo reale a runtime.
Inoltre i documenti sono “statici”, nel senso che su di essi
non è possibile eseguire operazioni, come importazione
dati da altri sistemi o generazione di grafici in modo
parametrico. Si potrebbe ovviare includendo nei documenti
Excel il codice che effettua tali elaborazioni, ma questo
violerebbe la divisione a livelli dell’architettura, in quanto
nei documenti sarebbe presente della Business Logic.
• Eccessiva difficoltà di personalizzazione della componente.
Nonostante tutta la parte di Presentation Logic sia fornita
come pagine ASP, la personalizzazione è difficoltosa, a
causa di codice illeggibile e soprattutto non documentato,
e della cattiva divisione in livelli di tutta l’architettura.
Infatti molti metodi della componente che elabora i
documenti Excel, ritorna intere porzioni di documenti
HTML, mentre la formattazione dei dati dovrebbe essere a
carico del Presentation Layer dell’architettura.
29
NTFS (NT file system, o anche New Technology File System) è il file system che
i sistemi operativo basati su Windows NT (NT, 2000, 2003, XP) usano per
archiviare e accedere ai file su hard disk. NTFS è l'equivalente della File
Allocation Table (FAT) di Windows 95/98 e di High Performance File System
(HPFS) di OS/2. Comunque, NTFS offre un gran numero di miglioramenti rispetto
a FAT ed HPFS in termini di prestazioni, estendibilità, sicurezza e multi utenza.
145
6.SPERIMENTAZIONE
6.1Approccio adottato
Per testare effettivamente il sistema “sul campo”, sono stati
pensati due possibili scenari. In entrambi si presuppone l’intero
sistema in funzione da diverso tempo, la variante sta invece nel
come si considera il sistema CRM:
• staticamente: i dati all’interno del database del sistema
CRM rimangono immutati durante l’intervallo di tempo nel
quale si testa il sistema STATCRM;
• dinamicamente: i dati all’interno del database del sistema
CRM cambiano durante l’intervallo di tempo nel quale si
testa il sistema STATCRM, in base a possibili interazioni
degli utenti del sistema CRM durante il suo normale uso
attraverso il portale o l’interfaccia Web indipendente.
6.2Problema dei dati e simulazione

Il problema, citato peraltro più volte in precedenza, presentatosi
subito è stato quello dell’assenza pressoché totale di informazioni
all’interno del database del sistema CRM. In entrambi gli scenari
invece viene richiesta la presenza di informazioni. Inoltre, dovendo
testare il sistema anche in condizioni di normale utilizzo del
sistema CRM, è necessario che lo stato del database rifletta il più
possibile lo stato del database di un CRM, ovvero un database al
cui interno sia presente una grossa mole di dati.
Durante lo sviluppo del sistema è stata eseguita un’analisi della
tabella contenente le richieste del sistema CRM. Tramite
quest’analisi è emersa un’idea di come sono strutturate le
informazioni e della relativa semplicità di creazione di dati per una
simulazione.
6.2.1Il
6.2.1Il tool per la simulazione
Per la creazione dei dati per la simulazione, è stato creato un
tool apposito utilizzando l’applicazione Microsoft Excel 2000.
Il tool consiste di un foglio di calcolo e di una macro con relativa
interfaccia grafica. Tramite i dati inseriti all’interno del foglio di
calcolo (che chiameremo dati aggregati) e i parametri inseriti nei
campi dell’interfaccia grafica della macro, il tool genera una serie
di nuovi dati usati per generare le richieste simulate.
146
Il foglio di calcolo (visibile in Figura 6-97 e schematizzato in

Tabella 6-4) è diviso in due sezioni principali che analizzeremo qui
nel dettaglio.
C OMBINAZIONI P ERIODI
G1 G2 Gm
C1 R 1 ,1 R 1 ,2 … R 1 ,m
C2 R 2 ,1 R 2 ,2 … R 2 ,m
… … … … …
Cn R n ,1 R n ,2 … R n ,m
Figura 6 - 97 : Il foglio di calcolo del tool
Tabella 6 - 4 : Schematizzazione del foglio di calcolo
Nella parte sinistra ogni colonna indica uno dei campi della
tabella HD_ INC IDENT (contenente le richieste) che contiene
informazioni utilizzate per eseguire le statistiche, ad esclusione
della data. Sono presenti quindi quattro colonne indicanti il tipo di
richiesta (TYPE), il gruppo di utenti che ha effettuato la richiesta
(OWNER_GRP), il livello di soddisfazione (CUST_SATIS) e lo stato
della richiesta (STATE). Le righe di questa tabella contengono tutte
le possibili combinazioni C i lecite dei valori per questi campi.
Nella parte destra invece ogni colonna corrisponde a un giorno
generico. Fissata la riga i della tabella, al variare della colonna j, la
cella R i,j indica il numero di richieste C i nel giorno G j . Gruppi di
giorni concorreranno a formare periodi di analisi.
147
Lo scopo della macro è molto semplice: per ogni giorno G j

produrre un numero R i,j di richieste C i . Tramite l’interfaccia grafica
(riportata in Figura 6-98) è possibile inoltre personalizzare la
generazione dei dati. E’ possibile scegliere in quale foglio di calcolo
sono presenti i dati aggregati, l’intervallo di righe per selezionare
le combinazioni C i , le colonne della parte sinistra da considerare
per generare le richieste simulate, l’intervallo di colonne per
selezionare i giorni G j , il foglio di calcolo destinazione che conterrà
le richieste simulate e infine la data iniziale corrispondente al
primo dei giorni G j .
Le funzioni possibili invece sono: creazione delle richieste
simulate all’interno del foglio di calcolo, esportazione delle
richieste generate all’interno del database del CRM, cancellazione
delle richieste simulate e di quelle presenti nel database, chiusura
della macro.
Una volta inseriti i dati nel foglio di calcolo e nei campi
Figura 6 - 99 : Richieste simulate all'interno del foglio di calcolo
Figura 6 - 98 : Interfaccia grafica della macro
148
Una volta premuto il pulsante Esporta Dati invece, le richieste

saranno inserite nel database del CRM come se queste fossero
Figura 6 - 100 : La tabella HD_INCIDENT con i record
state inserite dal sistema CRM durante il suo normale utilizzo. In

Figura 6-100 sono visibili alcuni dei record della tabella
HD_ INC IDENT all’interno del database Oracle del sistema CRM. Il
numero totale di record generati è pari a 10231, per tre periodi di
30 giorni ciascuno, corrispondenti ai mesi di Settembre, Ottobre e
Novembre 2002.
L’intero tool, nonostante esegua un’operazione non molto

ricorrente, è stato realizzato in modo parametrico sia per
permettere l’eventuale aggiunta di nuove richieste nel database in
modo semplice, sia per ridurre l’impatto che l’eventuale modifica
dei dati del sistema CRM può comportare sul tool e sui dati simulati
da generare nuovamente.
149
6.3Risultati ottenuti
Una volta messo in funzione, il sistema ha eseguito le statistiche
in modo corretto, in entrambi gli scenari citati all’inizio di questo
capitolo. Nel primo scenario, i risultati rappresentati nei grafici e
nelle tabelle all’interno del Gadget corrispondo effettivamente a
quelli che si ottengono eseguendo le query sul database del
sistema CRM.
In Figura 6-101 e in Figura 6-102 viene proprio mostrata la
corrispondenza tra i dati effettivamente presenti nel database e
quelli elaborati dal sistema STATCRM.
150
La Figura 6-101 mostra in alto la query usata per estrarre i dati

della statistica Totale richieste per tipo, ristretta alle richieste di
tipo Carenza di spazi e Varie (per chiarezza espositiva non vengono
mostrate tutte), in basso invece i risultati dell’esecuzione della
query, con evidenziati i due valori 82 per le richieste di tipo
Carenza di spazi e 91 per quelle di tipo Varie.
151
Figura 6 - 101 : I risultati della query sul database

La Figura 6-102 mostra invece i risultati della statistica

visualizzati nel portale in forma tabellare. Sono evidenziati i due
valori relativi alle richieste di tipo Carenza di spazi e Varie, e come
è possibile notare, questi corrispondono ai valori ottenuti con la
query SQL eseguita sul database.
152
Figura 6 - 102 : La statistica corrispondente alla query

Anche nel secondo scenario, i risultati continuano a

corrispondere, anche nel momento in cui si interagisce con il
sistema attraverso il Gadget Messaggi CRM costruito per la
sperimentazione. Di queste prove vengono mostrati alcuni passi,
ovvero l’inserimento di una nuova richiesta di tipo Attività
Pianificata e non eseguita e la chiusura di una richiesta con
indicazione del livello di soddisfazione Soddisfatto. La Figura 6-104
mostra il grafico corrispondente alla statistica Totale richieste per
tipo prima dell’inserimento, la Figura 6-103 mostra l’inserimento
della nuova richiesta nel CRM e infine la Figura 6-105 mostra il
grafico dopo l’inserimento, con l’effettivo aggiornamento della
statistica in tempo reale.
153
La Figura 6-106 invece mostra la tabella corrispondente alla

statistica Percentuale soddisfazione clienti prima della chiusura
della richiesta, la Figura 6-107 mostra la chiusura della richiesta
nel CRM e infine la Figura 6-108 mostra la tabella dopo la chiusura
della richiesta, con l’effettivo aggiornamento della statistica in
tempo reale.
Figura 6 - 105 : Il grafico dopo l'inserimento della richiesta
Figura 6 - 104 : Il grafico prima dell'inserimento della richiesta
154
FiguraFigura
6 - 106 :6 -La
103
tabella
: L'inserimento
prima della
della
chiusura
richiesta
della richiesta
155
Figura
Figura 6
6--107
108:: La
La chiusura
tabella dopo
dellalarichiesta
chiusura della richiesta
6.4Considerazioni sulle prestazioni

La sperimentazione ha permesso di trarre delle importanti
conclusioni sull’uso dei Web Service come tecnologia per
l’integrazione. Prima di tutto si è sperimentato che i tempi di attesa
e i ritardi per l’invocazione di un Web Service non sono in generale
maggiori di altre tecnologie come ad esempio RMI. Ciò che invece
può risultare un problema e che in realtà nel progetto realizzato è
stato visibilmente osservato, sono i tempi di attesa che possono
potenzialmente crescere a causa della modalità di realizzazione
Document oriented dei sistemi: soprattutto nei sottosistemi che
realizzano l’interazione con i due COTS Excel e Statistica, si sono
rilevati tempi di attesa eccessiva per l’apertura e chiusura dei due
applicativi per ogni invocazione del Web Service. Questo è dovuto
unicamente alla mancanza della possibilità di tenere sempre in
funzione un’istanza dei due COTS e di poter utilizzare quell’unica
istanza per tutte le invocazioni del servizio. Si è potuto
sperimentare che i tempi di attesa si riducono di molto quando le
richieste vengono effettuate a breve distanza l’una dall’altra,
questo perché viene sfruttata la caratteristica del sistema
operativo di non liberare subito la memoria occupata dalle
componenti delle applicazioni chiuse, al fine di velocizzarne un
eventuale caricamento nel breve futuro. Direttamente legato a
questa caratteristica, è stato anche sperimentato che di questo
problema può soffrire anche il server Web e la piattaforma su cui si
appoggiano i Web Services sviluppati: la prima richiesta a un Web
Service scritto in ASP.Net richiede l’inizializzazione di tutta una
serie di componenti del server Web IIS e del .Net Framework stesso,
tanto che la somma dei tempi di attesa può spesso portare a un
timeout nelle richieste HTTP. La situazione non si ripresenta per le
future richieste, ma si ripresenta in forma ridotta per richieste
eseguite dopo un lungo periodo dall’ultima richiesta effettuata. In
uno scenario come quello di utilizzo in un portale, a cui gli accessi
contemporanei e continui, è vero che questo problema
statisticamente non dovrebbe presentarsi, ma una strategia di
caching dovrebbe essere sempre progettata per sistemi di questo
tipo. Così come dovrebbe essere tenuta in considerazione la
possibilità che un gran numero di richieste contemporanee ai
servizi che utilizzano COTS di una certa “pesantezza”, possano
pregiudicare la qualità del servizio di un portale.
156
7.CONCLUSIONI
Il progetto realizzato durante questo lavoro di tesi ha permesso

di sperimentare l’uso degli XML Web Services con i tipici sistemi
presenti all’interno di un’organizzazione di livello enterprise, al fine
di integrarli. Grazie agli XML WS è stato possibile integrare
all’interno di un portale, un sistema CRM e un sistema di
elaborazione statistica composto da diversi sottosistemi. E’ stato
anche mostrato come fare astrazione su una base di dati, come
superare i limiti dei comuni protocolli di trasporto tramite HTTP,
così come strutturare le componenti che implementano i servizi in
modo che realizzino un’interazione di tipo Document oriented.
Relativamente all’integrazione dei sistemi, è stato mostrato
come integrare sistemi che supportano le nuove tecnologie come
.Net Framework, come utilizzare i Web Services per l’integrazione
data-driven e come integrare sistemi di tipo legacy che invece sono
legati a tecnologie del passato come ASP oppure COM. Si è potuto
provare come per i sistemi che supportano .Net, l’integrazione è
semplice in termini di codifica e di architettura del sistema, grazie
al supporto nativo di nuove tecnologie come XML, i Web Services
stessi, i protocolli di rete come HTTP e i tipi di dati più astratti
(immagini grafiche soprattutto). Per i sistemi invece legati alle
vecchie tecnologie lo sforzo necessario all’implementazione e
integrazione di sistemi è eccessivo e mal supportato dai sistemi di
sviluppo moderni. Nonostante ciò, i grossi fornitori di software
supportano lo sviluppatore con tool di indubbia utilità come SOAP
Toolkit, dimostrando così l’importanza data a sistemi sui quali le
organizzazioni hanno investito in passato.
Si è sperimentato che i Web Services sono una tecnologia
promettente per l’integrazione di sistemi eterogeneri. La tecnologia
sempre in evoluzione è esclusivamente basata su concetti
architetturali come middleware object-oriented e standard diffusi e
comunemente accettati come XML e i protocolli Internet. E’ per
questo che organizzazioni come Sun Microsystems, Microsoft, IBM e
BEA considerano i Web Service come la tecnologia più promettente
dell’informatica del futuro.
Tuttavia gli sviluppatori dovrebbero sempre ricordare che, al
momento, i Web Services sono ancora una tecnologia immatura.
L’interoperabilità tra le implementazioni differenti non è ancora
assicurata a causa di standard aperti a interpretazioni differenti o
scarsamente utilizzati (come UDDI), oppure non ancora definiti o
ratificati (come un protocollo unico per il workflow, che unifichi i
vari WSFL, WSCI e altri). Inoltre i Web Services mancano dei
concetti basilari dell’approccio object-oriented, come l’ereditarietà,
il polimorfismo e la nozione stessa di oggetto. Ecco perché il
tradizionale middleware come CORBA, RMI e COM, saranno ancora
necessari per implementare sofisticati servizi di backend. I Web
Service invece entreranno in gioco per integrare tali sistemi
157
connettendoli attraverso infrastrutture di rete diffuse globalmente

come lo è Internet.
7.1Possibili sviluppi futuri

L’argomento trattato in questo lavoro di tesi contiene una serie
di novità per le attuali pratiche dell’Ingegneria del Software e lo
sviluppo di sistemi informatici in generale. Per questo motivo, vista
la mole degli argomenti da trattare e l’assenza o relativa
giovinezza di standard e metodi per alcune aree dei Web Service,
non è stato possibile esplorare tutto l’argomento. In particolare un
possibile sviluppo del sistema realizzato, potrebbe essere
l’inserimento di un ulteriore livello di astrazione corrispondente alla
scoperta e pubblicazione dei servizi Web realizzati, utilizzando il
protocollo UDDI e implementando un registro UDDI privato
all’interno del laboratorio di ricerca.
Un altro possibile sviluppo, potrebbe risiedere
nell’ottimizzazione delle prestazioni del sistema, soprattutto in
ottica del modo in cui questo viene usato, ovvero un servizio
utilizzato all’interno di un portale da un elevato numero di utenti
contemporaneamente.
Rimanendo in ambito tecnico, ulteriori sviluppi potrebbero
includere lo sviluppo di nuovi servizi Web da interfacciare con quelli
già realizzati, utilizzando la piattaforma Java2 Enterprise Edition, al
fine di dimostrare l’irrilevanza della piattaforma di sviluppo.
158
8.BIBLIOGRAFIA
8.1Riferimenti comuni a tutti i capitoli

Autori Vari. "whatis?com". TechTarget, 2002-2003
http://whatis.techtarget.com/whome/0,,sid9,00.html
8.2Riferimenti “Introduzione”
A. Brown, S. Johnston, K. Kelly. "Using Service-Oriented Architecture
and Component-Based Development to build Web Service
Applications". Rational Software White Papers, October 2002.
http://www.rational.com/media/whitepapers/TP032.pdf
A. Gokhale, D.C. Schmidt, B. Natarajan, N. Wang. “Applying Model-

Integrated Computing to Component Middleware and Enterprise
Applications”. Communication of the ACM, October 2002/Vol 45 No.
10, Pag. 65-70.
8.3Riferimenti “Dallo sviluppo per componenti ai Web

Services”
I. Crnkovic, B. Hnich, T. Jonsson, Z Kiziltan, “Specification,
Implementaion, and Deployment of Components”. Communication
of the ACM, October 2002/Vol 45 No. 10, Pag. 35-40.
F. Bachman, L. Bass, C. Buhman, S. Comella-Dorda, F. Long, J.

Robert, R. Seacord, K. Wallnau. "Volume II: Technical Concepts of
Component-Based Software Engineering, 2nd Edition". Carnegie
Mellon Software Engineering Institute (CMI/SEI) Technical Report,
May 2000.
http://www.sei.cmu.edu/pub/documents/00.reports/pdf/00tr008.pdf

C. Atkinson, J. Bayer, C. Bunse, E. Kamsties, O. Laitenberger, R.

Laqua, D. Muthig, B. Paech, J. Wüst, J. Zettel, "Component-based
159
Product Line Engineering with UML" Chapter 1. Addison Wesley,

2002
8.4Riferimenti “XML Web Services”

D. Austin, A. Barbir, S. Garg. "Web Services Architecture
Requirements". W3C Working Draft, 29 April 2002
http://www.w3.org/TR/2002/WD-wsa-reqs-20020429
A. Nghiem. "IT Web Services: A Roadmap for the Enterprise"

Chapter 2: "The Basic Web Services Stack". Prentice Hall PTR, 08
October 2002
http://www.informit.com/content/images/0130097195/samplechapte
r/0130097195.pdf

K. Gottschalk, S. Graham, H. Kreger, J. Snell. "Introduction to Web

services architecture". IBM Systems Journal, Vol 41, No. 2, 2002 Pag
170-177.
http://www.research.ibm.com/journal/sj/412/gottschalk.pdf
M. Palermo, D. Singh, S. Mohr, P. Siegers, C. Knowles. "Professional

ASP.NET 1.0 XML with C#", Chapter 1: "Introduction to XML
Technologies". Wrox Press Inc. 1st edition July 2002.
http://www.perfectxml.com/XMLIntro.asp#chap
E. Newcomer. "Understanding Web Services: XML, WSDL, SOAP, and

UDDI", Chapter 1 "Introducing Web Services". Addison Wesley
Professional, 13 May 2002.
http://www.informit.com/content/index.asp?product_id={A0D14FAE-
362F-4878-A624-0899FC89D76B}
M. Stal, “Web Services: Beyound Component-Based Compunting”.

Communication of the ACM, October 2002/Vol 45 No. 10, Pag. 71-
76.
160
M. Burner. "The Deliberate Revolution Transforming Integration

With XML Web Services". ACM Queue, February 2003.
http://www.acmqueue.org/issue/burner1.cfm
D. Box. "A Young Person's Guide to The Simple Object Access

Protocol: SOAP Increases Interoperability Across Platforms and
Languages". Microsoft MSDN Magazine Vol. 15 No.2, March 2000.
http://msdn.microsoft.com/msdnmag/issues/0300/soap/
Autori Vari. "Web Service Basics: SOAP Specification Index Page",

Microsoft MSDN Library.
http://msdn.microsoft.com/webservices/understanding/webserviceb
asics/default.aspx?pull=/library/en-
us/dnsoapspec/html/soapspecindex.asp
Autori Vari. "Web Service Basics: WSDL Specification Index Page",

us/dnwsdl/html/wsdlspecindex.asp
Autori Vari. "Web Service Basics: UDDI Specification Index Page",

us/dnuddispec/html/uddispecindex.asp
T. Bellwood. “Understanding UDDI – Tracking the evolvine

specification”. IBM developerWorks Journal, May 2002.
http://www-106.ibm.com/developerworks/webservices/library/ws-
featuddi/
F. Coyle. "XML, Web Services, and the Data Revolution" Chapter 1:

"XML: Extending the Enterprise". Addison Wesley Professional, 05-
03-2002.
http://www.informit.com/isapi/product_id~{68E8E905-8165-465E-
B648-B1F07B294D0D}/content/index.asp
161
8.5Riferimenti “Case Study”

Autori Vari. "Introduction to COTS". Center for Empirically-Based
Software Engineering (CeBASE).
http://www.cebase.org/www/researchActivities/COTS/introduction.ht
ml
Autori Vari. "COTS Definition used by CeBASE". Center for

Empirically-Based Software Engineering (CeBASE).
http://www.cebase.org/www/researchActivities/COTS/definition.html
Autori Vari. "The Enterprise Web - A New Paradigm for Building and
Managing Web Applications". Plumtree Software White Papers,
October 2002.
Autori Vari. "Plumtree Corporate Portal 4.5". Plumtree Software

White Papers, September 2001.
Autori Vari. "The Gadget Book (Plumtree 4.5 WS) - Plumtree Gadget
Web Services Design and Development". Plumtree Software Press,
8/31/2002.
http://gadgets.plumtree.com/downloads/TheGadgetBook.zip
Autori Vari. "The Plumtree Corporate Portal 4.5 - Administrator’s

Guide". Plumtree Software Press, August 2001.
Autori Vari. "Microsoft Office 2000/Visual Basic Programmer's

Guide". Microsoft MSDN Library
http://msdn.microsoft.com/library/en-
us/odeopg/html/deovroffice2000visualbasicprogrammersguide.asp
Autori Vari. "The Component Object Model". Microsoft MSDN Library

http://msdn.microsoft.com/library/en-us/com/htm/com_757w.asp
Autori Vari. “StatSoft Statistica 6 Electronic Manual”. StatSoft,

2002.
G. Visaggio, D. Caivano. "Controllo Statistico dei Processi".

Dispense del corso "Modelli di Valutazione e Miglioramento del
Software & Ingegneria del Software II", A.A. 2002/2003.
http://serlab2.di.uniba.it/serlab/courses/2002_03/infvo/SPC.pdf
162
Autori Vari. "Statistica Visual Basic". StatSoft, 2001

http://www.statsoft.com/visualbasic.html
Autori Vari. "Microsoft .Net Framework: Product Overview".

Microsoft MSDN Library, July 09 2002
http://msdn.microsoft.com/netframework/productinfo/overview/defa
ult.asp
Autori Vari. ".NET Framework Developer's Guide - Overview of the

.NET Framework". Microsoft MSDN Library, 2002.
us/cpguide/html/cpovrintroductiontonetframeworksdk.asp
Autori Vari. ".NET Development – ASP.Net". Microsoft MSDN Library,

2002.
http://msdn.microsoft.com/net/aspnet/
Autori Vari. ".NET Framework Developer's Guide – Introduction to

ASP.Net". Microsoft MSDN Library, 2002.
us/cpguide/html/cpconintroductiontoasp.asp
Autori Vari. “ASP.Net QuickStart – Introducing Web Services”.

Microsoft, 2002.
http://samples.gotdotnet.com/quickstart/aspplus/doc/webservicesin
tro.aspx
Autori Vari. ".NET Framework Developer's Guide - Creating an XML

Web Service Proxy". Microsoft MSDN Library, 2002.
us/cpguide/html/cpconcreatingwebserviceproxy.asp
Autori Vari. ".NET Framework Developer's Guide - Interoperating

with Unmanaged Code". Microsoft MSDN Library, 2002.
us/cpguide/html/cpconinteroperatingwithunmanagedcode.asp
163
T. Archer. "Inside C#" Capitolo 2: "Introduzione a Microsoft .Net".

Mondadori Informatica, 04/09/2001
http://education.mondadori.it/libri/Download/Capitoli/214_Cap02.pd
f
Autori Vari. “The ASP.NET Web Matrix Project”. Microsoft, 2002.

http://www.asp.net/webmatrix/default.aspx?tabindex=4&tabid=46
Autori Vari. ".NET Framework Developer's Guide - Accessing Data

with ADO.NET". Microsoft MSDN Library, 2002.
us/cpguide/html/cpconaccessingdatawithadonet.asp
R. Bonneau, E. Newcomer. "Integrate .NET and J2EE With Web

Services". .Net Magazine, February 2003.
http://www.fawcette.com/dotnetmag/2003_02/magazine/features/rb
onneau/default_pf.asp
J. Bloomberg. "Web Services and a New Approach to Software

Development". The Rational Edge, April 2002
http://www.therationaledge.com/content/apr_02/f_webServices_jb.js
p
F. Lanubile. "Introduzione alle applicazioni web". Dispense del corso

“Reti di Calcolatori: Ingegneria del Software in Rete”, A.A.
2002/2003
http://www.di.uniba.it/~reti/dispense/IntroAppWeb.pdf
8.6Riferimenti “Conclusioni”
M. Stal, “Web Services: Beyound Component-Based Compunting”.

Communication of the ACM, October 2002/Vol 45 No. 10, Pag. 71-
76.
164

Tesi Di Laurea: Integrazione Software Via Web Service

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Tesi Di Laurea: Integrazione Software Via Web Service

Caricato da

Copyright:

Formati disponibili

UNIVERSITA’ DEGLI STUDI DI BARI

FACOLTA’ DI SCIENZE MATEMATICHE FISICHE E NATURALI

INTEGRAZIONE S OFTWARE VIA W EB -S ERVICES

ANNO ACCADEMICO 2001 - 2002

1.1Indice dei paragrafi

3. D ALLO SVILUPPO PER COMPONENTI AI W EB S ERVICES ....................13

4. XML W EB S ERVICES ......................................................... 25

4.3.4 Le fasi di adozione dei Web Services ...................................53

5. C ASE S TUDY ....................................................................54

5.4.3.2.3.3 Interazione con il portale ............................... ....................142

7. C ONCLUSIONI ............................................................... ..174

1.2Indice delle figure

F IGURA 3-1: R ELAZIONI TRA I CONCET TI DI BASE ............................17

F IGURA 3-2: T ERMINOLOGIA DI BASE ..........................................19

F IGURA 3-3: E SEMPIO DI INTERFACCE PER UN SERVIZIO .....................20

F IGURA 3-4: S TRATI DELL ’ ARCHITET TURA DI UN SISTEMA ORIENTATO AI

F IGURA 3-5: M ODELLO LOGICO ......................................... ........23

F IGURA 3-6: D IAGRAMMA DELLE COMPONENTI ................................23

F IGURA 3-7: I L SISTEMA ORIENTATO AI SERVIZI ...............................24

F IGURA 4-8: A RCHITET TURA A STRATI DEGLI XML W EB S ERVICE E

F IGURA 4-9: U N ESEMPIO DI FILE XML......................... .............27

F IGURA 4-10: I NTESTAZIONE DELLA RICHIESTA HTTP......................28

F IGURA 4-11: M ESSAGGIO SOAP DI RICHIESTA .............................29

F IGURA 4-12: I NTESTAZIONE DELLA RISPOSTA HTTP.......................29

F IGURA 4-13: M ESSAGGIO SOAP DI RISPOSTA .............................29

F IGURA 4-14: S TRUT TURA DI UN MESSAGGIO SOAP.......................30

F IGURA 4-15: L E CINQUE ARCHITET TURE PIÙ COMUNI .......................30

F IGURA 4-16: D OCUMENTO WSDL RAPPRESENTATO A LIVELLI ............36

F IGURA 4-17: R APPRESENTAZIONE SCHEMATICA DI UN DOCUMENTO WSDL

F IGURA 4-18: F RAMMENTO DI UN DOCUMENTO WSDL: I TIPI ............36

F IGURA 4-19: F RAMMENTO DI UN DOCUMENTO WSDL: I MESSAGGI .....37

F IGURA 4-20: F RAMMENTO DI UN DOCUMENTO WSDL: I TIPI DI PORTA .37

F IGURA 4-21: F RAMMENTO DI UN DOCUMENTO WSDL: LE MODALITÀ DI

F IGURA 4-22: F RAMMENTO DI UN DOCUMENTO WSDL: I SERVIZI ........37

F IGURA 4-23: U N TIPICO SCENARIO D ’ USO DI UDDI.......................39

F IGURA 4-24: A T TORI E SCENARIO TIPICO ...................... ..............39

F IGURA 4-25: T ERMINOLOGIA DI BASE ........................................39

F IGURA 4-26: U N ’ INTERAZIONE TRA WS DI ORGANIZZAZIONI DIVERSE ...41

F IGURA 4-27: WS PER ESEGUIRE UN ORDINE IN MODO INTERAT TIVO ......45

F IGURA 4-28: WS PER ESEGUIRE UN ORDINE COMPLETO ...................45

F IGURA 4-29: D IAGRAMMA UML CORRISPONDENTE .........................48

F IGURA 4-30: L' ESTENSIONE DI UN ' ORGANIZZAZIONE .......................50

F IGURA 5-31: V ISIONE GENERALE DEL SISTEMA ....................... .......54

F IGURA 5-32: L A PAGINA D ' ACCESSO AL SISTEMA CRM...................58

F IGURA 5-33: P AGINA PER L ' INSERIMENTO DI NUOVE RICHIESTE ...........59

F IGURA 5-34: P AGINA PER VISUALIZZAZIONE E RISPOSTA ALLE RICHIESTE 60

F IGURA 5-35: U NA VISIONE GLOBALE DELL ’E NTERPRISE W EB SECONDO

F IGURA 5-36: U N PORTALE P LUMTREE ALL ' OPERA ......................... ..66

F IGURA 5-37: A RCHITET TURA DI P LUMTREE ............................. .....68

F IGURA 5-38: I L G ATEWAY S PACE .............................................69

F IGURA 5-39: F UNZIONALITÀ PER AMMINISTRATORI ......................... .71

F IGURA 5-40: L A PAGINA DI UN WIZARD DELL ' AMMINISTRATORE ...........72

F IGURA 5-41: L A GERARCHIA DI OGGET TI DI M ICROSOFT E XCEL 2000. 78

F IGURA 5-42: U N ESEMPIO DI UTILIZZO DI E XCEL MEDIANTE COM......79

F IGURA 5-43: E SEMPIO DI GRAFICO DI CONTROLLO ...................... ....80

F IGURA 5-44: E SEMPIO DI GRAFICO X AND M OVING R....................81

F IGURA 5-45: L' AMBIENTE DI SVILUPPO INTERNO DELLE MACRO ...........84

F IGURA 5-46: A RCHITET TURA DEL SISTEMA ...................................86

F IGURA 5-47: U N ESEMPIO DI APPLICAZIONE USATA VIA W EB .............87

F IGURA 5-48: I L FRAMEWORK .N ET ...................................... .....89

F IGURA 5-50: L A LIBRERIA DI CLASSI DEL FRAMEWORK .N ET ..............92

F IGURA 5-51: S CENARI DI UTILIZZO DI RCW E CCW.....................94

F IGURA 5-52: L' ARCHITET TURA DI ADO.N ET ...............................95