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

IINTEGRAZIONENTEGRAZIONE S SOFTWAREOFTWARE VIAVIA W WEBEB-S-SERVICESERVICES

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.1. IINDICINDICI

1.11.1 Indice dei paragrafiIndice dei paragrafi

1. INDICI.........................................................................3

1.1 INDICE DEI PARAGRAFI.................................................................31.2 INDICE DELLE FIGURE..................................................................61.3 INDICE DELLE TABELLE..............................................................10

2. INTRODUZIONE...........................................................11

2.1 SCOPO DELLA TESI....................................................................132.2 STRUTTURA DELLA TESI.............................................................13

3. DALLO SVILUPPO PER COMPONENTI AI WEB SERVICES......14

3.1 COMPONENT-BASED SOFTWARE ENGINEERING (CBSE)...............143.1.1 Cosa sono le componenti..................................................143.1.2 Come specificare le componenti......................................153.1.3 Implementazione e distribuzione delle componenti.....173.1.4 Le relazioni tra i concetti di base....................................18

3.2 SVILUPPO DI APPLICAZIONI ORIENTATO AI SERVIZI (SODA)........193.2.1 Cosa sono i servizi.............................................................203.2.2 Architettura dei sistemi orientati ai servizi...................223.2.3 Web Service........................................................................24

3.3 UN SEMPLICE ESEMPIO..............................................................25

4. XML WEB SERVICES...................................................27

4.1 LA PILA DEI PROTOCOLLI...........................................................274.1.1 eXtensible Markup Language (XML)................................294.1.2 Simple Object Access Protocol (SOAP)............................314.1.3 Web Services Description Language (WSDL).................354.1.4 Universal Description, Discovery, and Integration (UDDI) 394.1.5 Scenario di utilizzo tipico.................................................41

4.2 I WEB SERVICE ALL’INTERNO DEL PROCESSO DI SVILUPPO...........424.2.1 Service Pattern...................................................................42

4.2.1.1 Web Service Façade...................................................424.2.1.2 Gestione dei processi di business............................434.2.1.3 Portali...........................................................................444.2.1.4 Supporto all’EAI...........................................................44

4.2.2 Progettazione di Web Service..........................................454.2.2.1 Problemi ricorrenti e soluzioni possibili...................454.2.2.2 Linee guida..................................................................464.2.2.3 Remote Procedure Call vs. Document oriented......47

4.2.3 L’esempio rivisitato...........................................................494.3 I WEB SERVICES ALL’INTERNO DELL’ORGANIZZAZIONE................51

4.3.1 La rivoluzione dei dati.......................................................524.3.2 La rivoluzione architetturale............................................53

2


4.3.3 La rivoluzione del software..............................................534.3.4 Le fasi di adozione dei Web Services..............................54

5. CASE STUDY..............................................................56

5.1 INTRODUZIONE AL PROGETTO REALIZZATO..................................565.1.1 Il CRM per gli stage...........................................................575.1.2 L’invio e la visualizzazione delle richieste nel sistema 59

5.2 COMPONENTI A DISPOSIZIONE....................................................615.2.1 Commercial Off-The Shelf (COTS)....................................615.2.2 Plumtree Corporate Portal 4.5.........................................63

5.2.2.1 Enterprise Web............................................................635.2.2.2 Architettura e caratteristiche di Plumtree Corporate Portal 4.5665.2.2.3 Gli utenti in Plumtree.................................................715.2.2.4 Sviluppo di gadget......................................................72

5.2.3 Microsoft Excel 2000.........................................................765.2.3.1 Component Object Model (COM)...............................76

5.2.4 Statsoft Statistica 6 DA-DM-QC........................................815.2.4.1 Statistical Process Control.........................................815.2.4.2 Modalità di integrazione e programmazione...........83

5.2.5 Applix iEnterprise CRM......................................................855.2.5.1 Modalità di integrazione e programmazione...........85

5.3 TOOL DI SVILUPPO E PIATTAFORME UTILIZZATE...........................885.3.1 Microsoft .Net.....................................................................88

5.3.1.1 Microsoft .Net Framework..........................................895.3.1.1.1 Common Language Runtime (CLR)...........................................905.3.1.1.2 Base Class Library (BCL)............................................................925.3.1.1.3 Interoperabilità con unmanaged code.....................................94

5.3.1.2 ADO.Net........................................................................965.3.1.3 ASP.Net.........................................................................985.3.1.4 Microsoft ASP.Net Web Matrix.................................1035.3.1.5 Interoperabilità .Net - J2EE......................................106

5.3.2 Microsoft SOAP Toolkit 3.0.............................................1095.3.2.1 XML Web Services e sistemi legacy.......................1095.3.2.2 Panoramica del tool..................................................1105.3.2.3 Web Services Meta Language (WSML)...................1105.3.2.4 La componente server-side.....................................1115.3.2.5 Il tool WSDL Generator.............................................115

5.3.3 Altova XML-Spy Enterprise Edition 5.............................1185.4 IL SISTEMA REALIZZATO..........................................................120

5.4.1 Gli utenti del sistema e la personalizzazione..............1215.4.2 Studio delle richieste nel sistema CRM........................1225.4.3 Componenti realizzate....................................................126

5.4.3.1 Databanker Server....................................................1275.4.3.1.1 Metadati......................................................................................1285.4.3.1.2 Interfaccia della componente................................................1325.4.3.1.3 Costruzione della query SQL...................................................1345.4.3.1.4 Tecniche di realizzazione e motivazioni................................135

5.4.3.2 Gadget........................................................................1375.4.3.2.1 Interfaccia della componente...............................................1375.4.3.2.2 Elaborazione delle richieste....................................................1395.4.3.2.3 Tecniche di realizzazione e motivazioni................................140

3


5.4.3.2.3.1 Invocazione degli XML Web Services.............................1405.4.3.2.3.2 Gestione delle preferenze utente...................................1415.4.3.2.3.3 Interazione con il portale.................................................1435.4.3.2.3.4 Rappresentazione delle statistiche................................144

5.4.3.3 Statistics Server........................................................1455.4.3.3.1 Metadati......................................................................................1465.4.3.3.2 Interfaccia della componente...............................................1475.4.3.3.3 Elaborazione delle richieste....................................................1475.4.3.3.4 Tecniche di realizzazione e motivazioni................................147

5.4.3.4 Excel Server...............................................................1485.4.3.4.1 Interfaccia della componente..................................................1505.4.3.4.2 Elaborazione delle richieste....................................................1505.4.3.4.3 Tecniche di realizzazione e motivazioni................................151

5.4.3.5 Statistica Server.......................................................1535.4.3.5.1 Interfaccia della componente..................................................1535.4.3.5.2 Elaborazione delle richieste....................................................1545.4.3.5.3 Tecniche di realizzazione e motivazioni................................154

5.4.3.6 Gadget Messaggi CRM..............................................1565.4.4 Allocazione del sistema e sicurezza..............................158

5.5 COMPONENTI VALUTATE MA NON UTILIZZATE............................1605.5.1 Oracle 9i Portal................................................................1605.5.2 mySAP Enterprise Portal 5.0..........................................1615.5.3 Plumtree Excel Gadget Service.....................................162

6. SPERIMENTAZIONE....................................................164

6.1 APPROCCIO ADOTTATO............................................................1646.2 PROBLEMA DEI DATI E SIMULAZIONE........................................164

6.2.1 Il tool per la simulazione................................................1646.3 RISULTATI OTTENUTI...............................................................1696.4 CONSIDERAZIONI SULLE PRESTAZIONI.......................................174

7. CONCLUSIONI...........................................................175

7.1 POSSIBILI SVILUPPI FUTURI......................................................176

8. BIBLIOGRAFIA..........................................................177

8.1 RIFERIMENTI COMUNI A TUTTI I CAPITOLI..................................1778.2 RIFERIMENTI “INTRODUZIONE”................................................1778.3 RIFERIMENTI “DALLO SVILUPPO PER COMPONENTI AI WEB SERVICES”.......................................................................................1778.4 RIFERIMENTI “XML WEB SERVICES”........................................1788.5 RIFERIMENTI “CASE STUDY”...................................................1808.6 Riferimenti “Conclusioni”.................................................184

1.21.2 Indice delle figureIndice delle figure

Figura 3-1: Relazioni tra i concetti di base.........................................18

Figura 3-2: Terminologia di base.........................................................20

Figura 3-3: Esempio di interfacce per un servizio.............................22

4


Figura 3-4: Strati dell’architettura di un sistema orientato ai servizi............................................................................................................23

Figura 3-5: Modello logico.....................................................................25

Figura 3-6: Diagramma delle componenti...........................................25

Figura 3-7: Il sistema orientato ai servizi...........................................26

Figura 4-1: Architettura a strati degli XML Web Service e relativi protocolli............................................................................................27

Figura 4-2: Un esempio di file XML......................................................30

Figura 4-3: Intestazione della richiesta HTTP.....................................32

Figura 4-4: Messaggio SOAP di richiesta.............................................32

Figura 4-5: Intestazione della risposta HTTP......................................33

Figura 4-6: Messaggio SOAP di risposta..............................................33

Figura 4-7: Struttura di un messaggio SOAP......................................34

Figura 4-8: Le cinque architetture più comuni...................................34

Figura 4-9: Documento WSDL rappresentato a livelli.......................37

Figura 4-10: Rappresentazione schematica di un documento WSDL............................................................................................................37

Figura 4-11: Frammento di un documento WSDL: i tipi....................38

Figura 4-12: Frammento di un documento WSDL: i messaggi.........38

Figura 4-13: Frammento di un documento WSDL: i tipi di porta.....38

Figura 4-14: Frammento di un documento WSDL: le modalità di accesso..............................................................................................38

Figura 4-15: Frammento di un documento WSDL: i servizi..............39

Figura 4-16: Un tipico scenario d’uso di UDDI...................................40

Figura 4-17: Terminologia di base.......................................................41

Figura 4-18: Attori e scenario tipico....................................................41

Figura 4-19: Un’interazione tra WS di organizzazioni diverse.........43

Figura 4-20: WS per eseguire un ordine in modo interattivo...........48

Figura 4-21: WS per eseguire un ordine completo............................48

Figura 4-22: Diagramma UML corrispondente....................................49

Figura 4-23: L'estensione di un'organizzazione.................................51

Figura 5-1: Visione generale del sistema............................................56

Figura 5-2: La pagina d'accesso al sistema CRM...............................58

Figura 5-3: Pagina per l'inserimento di nuove richieste...................59

Figura 5-4: Pagina per visualizzazione e risposta alle richieste......60

Figura 5-5: Una visione globale dell’Enterprise Web secondo Plumtree.............................................................................................64

5


Figura 5-6: Un portale Plumtree all'opera..........................................67

Figura 5-7: Architettura di Plumtree....................................................69

Figura 5-8: Il Gateway Space................................................................70

Figura 5-9: Funzionalità per amministratori.......................................71

Figura 5-10: La pagina di un wizard dell'amministratore.................72

Figura 5-11: La gerarchia di oggetti di Microsoft Excel 2000..........78

Figura 5-12: Un esempio di utilizzo di Excel mediante COM............79

Figura 5-13: Esempio di grafico di controllo.......................................81

Figura 5-14: Esempio di grafico X and Moving R...............................82

Figura 5-15: L'ambiente di sviluppo interno delle macro.................84

Figura 5-16: Architettura del sistema.................................................86

Figura 5-17: Un esempio di applicazione usata via Web..................87

Figura 5-18: Il framework .Net.............................................................90

Figura 5-19: Relazioni tra il CLR, il BCL e l'intero sistema...............92

Figura 5-20: La libreria di classi del framework .Net........................93

Figura 5-21: Scenari di utilizzo di RCW e CCW...................................95

Figura 5-22: L'architettura di ADO.Net................................................96

Figura 5-23: Confronto tra i due provider di dati di .Net Framework............................................................................................................98

Figura 5-24: Un Web Form con all'interno una componente server 99

Figura 5-25: Un semplicissimo XML Web Service............................100

Figura 5-26: Invocazione ed esplorazione del WS...........................101

Figura 5-27: Invocazione di un WS tramite classe proxy...............102

Figura 5-28: Web Matrix al lavoro su una pagina ASP.Net.............103

Figura 5-29: Il tool per la generazione di classi proxy....................104

Figura 5-30: Il Web Server interno....................................................105

Figura 5-31: .Net e J2EE a confronto.................................................106

Figura 5-32: Dalla dipendenza dalla piattaforma all'irrilevanza della piattaforma......................................................................................107

Figura 5-33: Frammento di un documento WSML............................111

Figura 5-34: Frammento del documento WSDL per un listener ISAPI..........................................................................................................112

Figura 5-35: Frammento del documento WSDL per un listener ASP..........................................................................................................112

Figura 5-36: Flusso di dati sul server................................................113

Figura 5-37: Flusso di dati all'interno di SoapServer30..................114

6


Figura 5-38: Come indicare la DLL in WSDL Generator..................116

Figura 5-39: La scelta dei metodi da esporre..................................117

Figura 5-40: Tipo e URL per il listener..............................................117

Figura 5-41: Invocazione di un WS a partire dal suo documento WSDL................................................................................................118

Figura 5-42: I messaggi SOAP di richiesta (a sinistra) e risposta (a destra)..............................................................................................119

Figura 5-43: Il documento WSDL di un WS in formato grafico.......119

Figura 5-44: Architettura del sistema...............................................120

Figura 5-45: Tabella con le richieste.................................................122

Figura 5-46: Ciclo di vita di una richiesta.........................................123

Figura 5-47: L'entità Richiesta...........................................................125

Figura 5-48: Architettura del sistema a un livello di dettaglio maggiore..........................................................................................126

Figura 5-49: La parte Database dei metadati..................................128

Figura 5-50: La parte Gruppi dei metadati.......................................129

Figura 5-51: Frammento della parte Tipi dei metadati...................130

Figura 5-52: Frammento della parte Periodi dei metadati.............130

Figura 5-53: La parte SoddisfazioniCliente dei metadati...............131

Figura 5-54: La parte Stati dei metadati..........................................132

Figura 5-55: Un estratto del metodo GetData()...............................136

Figura 5-56: Il gadget all'interno del portale in modalità grafica. 137

Figura 5-57: Il gadget all'interno del portale in modalità tabellare..........................................................................................................138

Figura 5-58: Personalizzazione delle statistiche..............................139

Figura 5-59: Invocazione di un XML Web Service in ASP tramite callWebService().............................................................................140

Figura 5-60: La funzione callWebService().......................................141

Figura 5-61: Lettura e scrittura di variabili di Plumtree.................142

Figura 5-62: Frammento dei metadati sulle statistiche..................146

Figura 5-63: Le tre statistiche in formato grafico...........................149

Figura 5-64: Il gadget del portale......................................................156

Figura 5-65: La pagina per l'invio delle richieste............................157

Figura 5-66: Architettura di Excel GS................................................162

Figura 6-1: Il foglio di calcolo del tool...............................................165

Figura 6-2: Interfaccia grafica della macro......................................166

Figura 6-3: Richieste simulate all'interno del foglio di calcolo......167

7


Figura 6-4: La tabella HD_INCIDENT con i record............................168

Figura 6-5: I risultati della query sul database................................169

Figura 6-6: La statistica corrispondente alla query........................170

Figura 6-7: L'inserimento della richiesta..........................................171

Figura 6-8: Il grafico prima dell'inserimento della richiesta..........171

Figura 6-9: Il grafico dopo l'inserimento della richiesta.................172

Figura 6-10: La tabella prima della chiusura della richiesta..........172

Figura 6-11: La chiusura della richiesta............................................173

Figura 6-12: La tabella dopo la chiusura della richiesta................173

1.31.3 Indice delle tabelleIndice delle tabelle

Tabella 4-1: Corrispondenza WSDL - UML...........................................50

Tabella 5-1: I settaggi di Plumtree......................................................74

Tabella 5-2: Possibili tipi di richiesta................................................124

Tabella 6-1: Schematizzazione del foglio di calcolo........................165

8


2.2. IINTRODUZIONENTRODUZIONE

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

9


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.12.1 Scopo della tesiScopo della tesiLo 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.

10


2.22.2 Struttura della tesiStruttura della tesiIl 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.

11


3.3. DDALLOALLO SVILUPPOSVILUPPO PERPER COMPONENTICOMPONENTI AIAI W WEBEB S SERVICESERVICES

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.13.1 Component-Based Software Engineering (CBSE)Component-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.13.1.1 Cosa sono le componentiCosa 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.

12


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.23.1.2 Come specificare le componentiCome 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.

13


Le interfacce sono definite usando tecnologie standard come IDL1, CORBA2 e COM3.

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.33.1.3 Implementazione e distribuzione delle componentiImplementazione 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 68.

14


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.

3.1.43.1.4 Le relazioni tra i concetti di baseLe relazioni tra i concetti di base

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.

15


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 componenti (transazioni, persistenza, sicurezza, ecc…).

3.23.2 Sviluppo di Applicazioni Orientato ai Servizi (SODA)Sviluppo 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 Orientate ai Servizi (SOA , Service Oriented Architectures ). Le SOA rappresentano un insieme di componenti eterogenee ad

16

Figura Figura 33--11: Relazioni tra i concetti di base: Relazioni tra i concetti di base


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.13.2.1 Cosa sono i serviziCosa 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.

17


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;

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;

18

Figura Figura 33--22: Terminologia di base: Terminologia di base


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.

19

Figura Figura 33--33: Esempio di interfacce per un : Esempio di interfacce per un servizioservizio


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.

3.2.23.2.2 Architettura dei sistemi orientati ai serviziArchitettura 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 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.

20

Figura Figura 33--44: Strati dell’architettura di un sistema orientato ai: Strati dell’architettura di un sistema orientato ai serviziservizi


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 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.33.2.3 Web ServiceWeb 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.

21


3.33.3 Un semplice esempioUn semplice esempioVedremo 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

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 “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

22

Figura Figura 33--55: Modello logico: Modello logico

Figura Figura 33--66: Diagramma delle componenti: Diagramma delle componenti


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.

23

Figura Figura 33--77: Il sistema orientato ai servizi: Il sistema orientato ai servizi


4.4. XML WXML WEBEB S SERVICESERVICES

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.14.1 La pila dei protocolliLa pila dei protocolliFondamentale 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

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.

24

Figura Figura 44--88: Architettura a strati degli XML Web Service e relativi : Architettura a strati degli XML Web Service e relativi protocolliprotocolli


Lo strato di base della pila è rappresentato dai servizi di rete. La rete è spesso basata sul protocollo HTTP 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 URL10 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

25


Di seguito verranno analizzati più a fondo i protocolli più importanti, ovvero XML, SOAP, WSDL e UDDI.

4.1.14.1.1 eXtensible Markup Language (XML)eXtensible Markup Language (XML)

La specifica XML è un insieme di linee guida, definito dal World Wide Web Consortium (W3C)11, 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 (ExternalPerson, 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.

26

Figura Figura 44--99: Un esempio di file XML: Un esempio di file XML


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, Street1, 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.24.1.2 Simple Object Access Protocol (SOAP)Simple Object Access Protocol (SOAP)

Le specifiche SOAP12 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.

12 Di recente con SOAP non viene più indicato l’originale Simple Object Access Protocol, bensì in modo non ufficiale Service-Oriented Access Protocol, sia per uniformarlo ai concetti di Web Service, sia perché SOAP in realtà non è né semplice né object-oriented.

27


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 tipo di contenuto del messaggio HTTP (e precisamente text/xml nel 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).

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.

28

Figura Figura 44--1010: Intestazione della richiesta: Intestazione della richiesta HTTPHTTP

Figura Figura 44--1111: Messaggio SOAP di richiesta: Messaggio SOAP di richiesta

Figura Figura 44--1212: Intestazione della: Intestazione della risposta HTTPrisposta 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 nell’esempio all’interno si trovi solo un tag con un valore di tipo semplice (true), 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.

29

Figura Figura 44--1313: Messaggio SOAP di risposta: Messaggio SOAP di risposta

Figura Figura 44--1414: Struttura di un messaggio SOAP: Struttura di un messaggio SOAP


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), Notifica , Broadcast e Workflow .

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.34.1.3 Web Services Description Language (WSDL)Web 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.

30

Figura Figura 44--1515: Le cinque architetture più comuni: Le cinque architetture più comuni


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);

Operazione (Operation): 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.

31


In Figura 4-17, viene rappresentato un documento WSDL in forma schematica13.

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.

32

Figura Figura 44--1616: Documento WSDL rappresentato a livelli: Documento WSDL rappresentato a livelli

Figura Figura 44--1717: Rappresentazione schematica di un documento WSDL: Rappresentazione schematica di un documento WSDL

Figura Figura 44--1818: Frammento di un documento WSDL: i tipi: Frammento di un documento WSDL: i tipi

http://www.altova.com/


33

Figura Figura 44--1919: Frammento di un documento WSDL: i messaggi: Frammento di un documento WSDL: i messaggi

Figura Figura 44--2020: Frammento di un documento WSDL: i tipi di porta: Frammento di un documento WSDL: i tipi di porta

Figura Figura 44--2121: Frammento di un documento WSDL: le modalità di: Frammento di un documento WSDL: le modalità di accessoaccesso

Figura Figura 44--2222: Frammento di un documento WSDL: i servizi: 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.

4.1.44.1.4 Universal Description, Discovery, and Integration (UDDI)Universal Description, Discovery, and Integration (UDDI)

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 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.

34


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 Figura4-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

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.54.1.5 Scenario di utilizzo tipicoScenario di utilizzo tipico

35

Figura Figura 44--2323: Un tipico scenario d’uso di UDDI: Un tipico scenario d’uso di UDDI


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 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.24.2 I Web Service all’interno del processo di sviluppoI Web Service all’interno del processo di sviluppoI 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.

36

Figura Figura 44--2525: Terminologia di base: Terminologia di base

Figura Figura 44--2424: Attori e scenario : Attori e scenario tipicotipico


4.2.14.2.1 Service PatternService 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.14.2.1.1 Web Service FaçadeWeb 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 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.

37


4.2.1.24.2.1.2 Gestione dei processi di businessGestione 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. 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à.

4.2.1.34.2.1.3 PortaliPortali

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.

38

Figura Figura 44--2626: Un’interazione tra WS di organizzazioni : Un’interazione tra WS di organizzazioni diversediverse


4.2.1.44.2.1.4 Supporto all’EAISupporto 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.24.2.2 Progettazione di Web ServiceProgettazione 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.14.2.2.1 Problemi ricorrenti e soluzioni possibiliProblemi ricorrenti e soluzioni possibili

I WS rendono gli schemi XML centrali nella comunicazione tra organizzazioni, mentre in passato la definizione di schemi e 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

39


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.24.2.2.2 Linee guidaLinee 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.

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

40


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.34.2.2.3 Remote Procedure Call vs. Document orientedRemote 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à 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 modellati come messaggi sincroni, quindi l’applicazione che invia il messaggio si attende una risposta.

41


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 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.34.2.3 L’esempio rivisitatoL’esempio rivisitato

42

Figura Figura 44--2727: WS per eseguire un ordine in modo interattivo: WS per eseguire un ordine in modo interattivo

Figura Figura 44--2828: WS per eseguire un ordine completo: WS per eseguire un ordine completo


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

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 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.

43

Figura Figura 44--2929: Diagramma UML corrispondente: Diagramma UML corrispondente


MANUFATTO WSDL

ELEMENTO UML COMMENTO

service «WebService»

Il servizio è rappresentato come una componente che realizza una o più

interfacce e risiede a una determinata locazione. La relazione «reside» catturerà

l’informazione sull’URL del servizio.

portType Interfaccia

Ogni portType è rappresentata come un’interfaccia UML che realizzata uno o

più servizi. La relazione «realize» catturerà le informazioni riguardanti il

collegamento.

message «WebDocument»

Ogni messaggio è rappresentato come una classe UML. E’ richiesta una

corrispondenza tra l’XML-Schema e UML per modellare il messaggio e le sue parti.

part Attributo o associazione

Ogni parte del messaggio può essere rappresentata sia come un attributo UML

del «WebDocument» sia mediante un’associazione (spesso di aggregazione)

con altri «WebDocument».

address location

Nodo Un nodo rappresenta il server su cui risiede il servizio.

Tabella Tabella 44--11: Corrispondenza WSDL - UML: Corrispondenza WSDL - UML

44


4.34.3 I Web Services all’interno dell’organizzazioneI Web Services all’interno dell’organizzazioneLa 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.

45

Figura Figura 44--3030: L'estensione di un'organizzazione: L'estensione di un'organizzazione

Rete dell’Rete dell’

organizzazioneorganizzazione


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.14.3.1 La rivoluzione dei datiLa 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.24.3.2 La rivoluzione architetturaleLa 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 14 e DCOM15, 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.34.3.3 La rivoluzione del softwareLa 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.44.3.4 Le fasi di adozione dei Web ServicesLe 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.5. CCASEASE S STUDYTUDY

5.15.1 Introduzione al progetto realizzatoIntroduzione al progetto realizzatoIl 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.

5.1.15.1.1 Il CRM per gli stageIl 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

Figura Figura 55--3131: Visione generale del sistema: Visione generale del sistema


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.

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

Figura Figura 55--3232: La pagina d'accesso al sistema CRM: La pagina d'accesso al sistema CRM


5.1.25.1.2 L’invio e la visualizzazione delle richieste nel sistemaL’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.

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 Figura 55--3333: Pagina per l'inserimento di nuove richieste: Pagina per l'inserimento di nuove richieste


53

Figura Figura 55--3434: Pagina per visualizzazione e risposta alle richieste: Pagina per visualizzazione e risposta alle richieste


5.25.2 Componenti a disposizioneComponenti a disposizioneDurante 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.15.2.1 Commercial Off-The Shelf (COTS)Commercial 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.25.2.2 Plumtree Corporate Portal 4.5Plumtree Corporate Portal 4.5

5.2.2.15.2.2.1 Enterprise WebEnterprise 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.

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

Figura Figura 55--3535: Una visione globale dell’Enterprise Web secondo Plumtree: Una visione globale dell’Enterprise Web secondo Plumtree


massimizzare il ritorno sugli investimenti (ROI, Return On Investment16).

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.25.2.2.2 Architettura e caratteristiche di Plumtree Corporate Portal 4.5Architettura 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 utenti contemporaneamente, nascondendo loro la latenza che si 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


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 8 i 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 prendono il nome di Gadget Server (GS) e che hanno la

59

Figura Figura 55--3636: Un portale Plumtree all'opera: Un portale Plumtree all'opera


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

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

Figura Figura 55--3737: Architettura di Plumtree: Architettura di Plumtree


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.35.2.2.3 Gli utenti in PlumtreeGli utenti in Plumtree

In Plumtree esistono due tipi di utenti: utenti anonimi e utenti registrati. Un utente 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

62

Figura Figura 55--3838: Il Gateway Space: Il Gateway Space


registrarsi da soli sul portale o ancora si possono importare utenti da un dominio NT o un server LDAP.

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 (ad esempio Gadget Server collegati al Portal Server, parametri di connessione al database, ecc…). Un

63

Figura Figura 55--3939: Funzionalità per: Funzionalità per amministratoriamministratori


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).

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.45.2.2.4 Sviluppo di gadgetSviluppo 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

64

Figura Figura 55--4040: La pagina di un wizard dell'amministratore: La pagina di un wizard dell'amministratore


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 portale: l’oggetto Settings 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

65


condivisi da tutti i gadget visualizzati nella stessa comunità.

In Tabella 5-2 viene riassunto quanto detto.

TIPO SETTAGGIO

SI APPLICA A:

UTENTE GADGET

Gadget Uno in particolare Uno in particolare

Administrative Tutti Uno in particolare

User Uno in particolare Tutti

Community Tutti in una particolare comunità

Tutti in una particolare comunità

Community Gadget Tutti in una particolare comunità

Uno in particolare

Tabella Tabella 55--22: I settaggi di Plumtree: 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.35.2.3 Microsoft Excel 2000Microsoft 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.15.2.3.1 Component Object Model (COM)Component 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 Application, il quale rappresenta l’applicazione stessa. L’oggetto Application contiene altri oggetti ai quali si può accedere solo quando l’oggetto Application esiste (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

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

Figura Figura 55--4141: La gerarchia di oggetti di Microsoft Excel 2000: La gerarchia di oggetti di Microsoft Excel 2000


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

precedenza, in particolare la preventiva creazione di un’istanza dell’oggetto Application (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

Figura Figura 55--4242: Un esempio di utilizzo di Excel mediante COM: Un esempio di utilizzo di Excel mediante COM


5.2.45.2.4 Statsoft Statistica 6 DA-DM-QCStatsoft 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.15.2.4.1 Statistical Process ControlStatistical 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 Charts). 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

72

Figura Figura 55--4343: Esempio di grafico di controllo: Esempio di grafico di controllo

Limite SuperioreLimite SuperioreLimite SuperioreLimite Superiore

Limite InferioreLimite InferioreLimite InferioreLimite Inferiore

Tendenza CentraleTendenza CentraleTendenza CentraleTendenza Centrale


vengono rappresentati i valori della caratteristica osservata, le due 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.

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

73

Figura Figura 55--4444: Esempio di grafico X and Moving R: Esempio di grafico X and Moving R


superiore sono indici di instabilità. Di solito questi valori vengono 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.25.2.4.2 Modalità di integrazione e programmazioneModalità 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


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.55.2.5 Applix iEnterprise CRMApplix 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 un’organizzazione a gestire le relazioni con i clienti in modo

75

Figura Figura 55--4545: L'ambiente di sviluppo interno delle macro: L'ambiente di sviluppo interno delle macro


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.15.2.5.1 Modalità di integrazione e programmazioneModalità 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


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 Figura 55--4646: Architettura del sistema: Architettura del sistema


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.35.3 Tool di sviluppo e piattaforme utilizzateTool di sviluppo e piattaforme utilizzateNei 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.15.3.1 Microsoft .NetMicrosoft .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

Figura Figura 55--4747: Un esempio di applicazione : Un esempio di applicazione usata via Webusata via Web


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.15.3.1.1 Microsoft .Net FrameworkMicrosoft .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 un’organizzazione sconosciuta e non completamente di fiducia;

79


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.

5.3.1.1.15.3.1.1.1 CCOMMONOMMON L LANGUAGEANGUAGE R RUNTIMEUNTIME (CLR) (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 chiamato unmanaged code (codice non gestito). Tutte le

80

Figura Figura 55--4848: Il framework .Net: Il framework .Net


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 17: 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.25.3.1.1.2 BBASEASE C CLASSLASS L LIBRARYIBRARY (BCL) (BCL)

La libreria di classi di .Net Framework (BCL, Base Class

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

Figura Figura 55--4949: Relazioni tra il CLR, il BCL e l'intero sistema: Relazioni tra il CLR, il BCL e l'intero sistema


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.

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.Forms);

Applicazioni Web (usando ASP.Net);

83

Figura Figura 55--5050: La libreria di classi del framework .Net: La libreria di classi del framework .Net


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.35.3.1.1.3 IINTEROPERABILITÀNTEROPERABILITÀ CONCON UNMANAGEDUNMANAGED CODECODE

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


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.

5.3.1.25.3.1.2 ADO.NetADO.Net

85

Figura Figura 55--5151: Scenari di utilizzo di RCW e CCW: Scenari di utilizzo di RCW e CCW


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 System.Data e sono integrate con le classi XML del package System.XML, è per questo

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 Connection, 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 DataTable, costituiti da righe e colonne di dati, così come da chiave primaria, chiavi esterne, vincoli referenziali e informazioni sui dati nell’oggetto DataTable.

86

Figura Figura 55--5252: L'architettura di ADO.Net: L'architettura di ADO.Net


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 Connection 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 DataSet 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.

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

Figura Figura 55--5353: Confronto tra i due provider di dati di .Net: Confronto tra i due provider di dati di .Net FrameworkFramework


5.3.1.35.3.1.3 ASP.NetASP.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 Figura 55--5454: Un Web Form con all'interno una componente: Un Web Form con all'interno una componente serverserver


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 WebService (linea 1) che indica il linguaggio scelto per l’implementazione (VB, ovvero

Visual Basic .Net) e il nome della classe (SimpleWS). Subito dopo (linea 4) viene importato il package System.Web.Services, 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 WebService. 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

Figura Figura 55--5555: Un semplicissimo XML Web Service: Un semplicissimo XML Web Service


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.

90

Figura Figura 55--5656: Invocazione ed esplorazione del WS: Invocazione ed esplorazione del WS

http://myorg.com/ws/SimpleWS.asmx?WSDL


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 SimpleWS attraverso la sua classe proxy: dopo aver istanziato un oggetto di tipo SimpleWS (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

è in grado di creare classi proxy a partire da un documento WDSL, semplicemente invocandolo come:

WSDL /language:VB http://myorg.com/ws/SimpleWS.asmx?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

Figura Figura 55--5757: Invocazione di un WS tramite classe proxy: Invocazione di un WS tramite classe proxy

http://myorg.com/ws/SimpleWS.asmx?WSDL


5.3.1.45.3.1.4 Microsoft ASP.Net Web MatrixMicrosoft 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 18 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;

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

Figura Figura 55--5858: Web Matrix al lavoro su una pagina ASP.Net: Web Matrix al lavoro su una pagina ASP.Net


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

essere usufruite tramite dispositivi portatili come telefoni cellulari e PDA.

93

Figura Figura 55--5959: Il tool per la generazione di classi proxy: Il tool per la generazione di classi proxy


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.

94

Figura Figura 55--6060: Il Web Server interno: Il Web Server interno


5.3.1.55.3.1.5 Interoperabilità .Net - J2EEInteroperabilità .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) 19 è 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 IIOP20 per J2EE). Le differenze nei linguaggi di programmazione, nei protocolli nativi per l’elaborazione distribuita,

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

Figura Figura 55--6161: .Net e J2EE a confronto: .Net e J2EE a confronto


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

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

Figura Figura 55--6262: Dalla dipendenza dalla piattaforma: Dalla dipendenza dalla piattaforma all'irrilevanza all'irrilevanza della piattaformadella piattaforma


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.25.3.2 Microsoft SOAP Toolkit 3.0Microsoft SOAP Toolkit 3.0

5.3.2.15.3.2.1 XML Web Services e sistemi legacyXML 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.25.3.2.2 Panoramica del toolPanoramica 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.35.3.2.3 Web Services Meta Language (WSML)Web 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 <service>, con gli elementi figli <using> 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.

5.3.2.45.3.2.4 La componente server-sideLa componente server-side

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)21, sia un server Active Server Pages (ASP)22.

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.

100

Figura Figura 55--6363: Frammento di un documento WSML: Frammento di un documento WSML


Per definire un listener SOAP, bisogna indicare una URL all’interno dell’elemento <soap:address> 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

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.

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

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.

101

Figura Figura 55--6464: Frammento del documento WSDL per un listener ISAPI: Frammento del documento WSDL per un listener ISAPI

Figura Figura 55--6565: Frammento del documento WSDL per un listener ASP: Frammento del documento WSDL per un listener ASP

Figura Figura 55--6666: Flusso di dati sul server: Flusso di dati sul server


risultato dell’elaborazione dell’operazione richiesta all’oggetto SoapServer30, 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 SoapServer30 è implementata usando la low-level API , ovvero gli oggetti SoapSerializer30, 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) 23 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 l’oggetto WSDLOperation30 invoca il metodo GetOperationParts(), il quale restituisce, a partire dai due alberi DOM corrispondenti ai 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

Figura Figura 55--6767: Flusso di dati all'interno di SoapServer30: Flusso di dati all'interno di SoapServer30


file WSDL e WSML, una collezione di elementi <part> definiti sia per il messaggio di richiesta sia per quello di risposta. Per ognuno di questi elementi <part>, 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.55.3.2.5 Il tool WSDL GeneratorIl 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 versione non contiene tutti i dettagli relativi alla parte server del servizio;

103


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.

104

Figura Figura 55--6868: Come indicare la DLL in WSDL Generator: Come indicare la DLL in WSDL Generator


105

Figura Figura 55--6969: La scelta dei metodi da esporre: La scelta dei metodi da esporre

Figura Figura 55--7070: Tipo e URL per il listener: Tipo e URL per il listener


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.

5.3.35.3.3 Altova XML-Spy Enterprise Edition 5Altova 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, 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 Figura 55--7171: Invocazione di un WS a partire dal suo documento WSDL: Invocazione di un WS a partire dal suo documento WSDL


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…).

5.45.4 Il sistema realizzatoIl sistema realizzato

107

Figura Figura 55--7272: I messaggi : I messaggi SOAP di richiesta (a sinistra) e risposta (aSOAP di richiesta (a sinistra) e risposta (a destra)destra)

Figura Figura 55--7373: Il documento WSDL di un WS in formato grafico: Il documento WSDL di un WS in formato grafico


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 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 è realizzato come Web Service. L’interazione tra il sistema Statistics Server e il database avviene usando un accesso basato su ODBC.

108

Figura Figura 55--7474: Architettura del sistema: Architettura del sistema


5.4.15.4.1 Gli utenti del sistema e la personalizzazioneGli 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.25.4.2 Studio delle richieste nel sistema CRMStudio delle richieste nel sistema CRM

110


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_INCIDENT, è 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:

111

Figura Figura 55--7575: Tabella: Tabella con le richiestecon le richieste


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_SATIS: 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 valori contenuti in altre tabelle relazionate ad HD_INCIDENT mediante chiave esterna. In realtà CUST_SATIS 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.

112


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.

CODICE DESCRIZIONE

STUDENTE-CARENZA DI ASSISTENZA Carenza di Assistenza

STUDENTE-ATTIVITÀ NON COERENTI CON IL PROGETTO DIDATTICO

Attività non coerenti con il Progetto Didattico

STUDENTE-CARENZA DI STRUMENTAZIONE Carenza di Strumentazione

STUDENTE-CARENZA DI SPAZI Carenza di Spazi

STUDENTE-INCONTRI DI LAVORO MANCATI Incontri di Lavoro Mancati

STUDENTE-RICHIESTA DI INCONTRO LAVORO Richiesta di Incontro Lavoro

STUDENTE-ATTIVITÀ PIANIFICATA E NON ESEGUITA

Attività Pianificata e non eseguita

STUDENTE-INDETERMINAZIONE DELLO SCOPO DELLE ATTIVITÀ

Indeterminazione dello Scopo delle Attività

STUDENTE-VIOLAZIONE DELLA SCHEDULAZIONE Violazione della Schedulazione

STUDENTE-CARENZA DI ACCOMPAGNAMENTO Carenza di Accompagnamento

STUDENTE-VARIE Varie

IMPRESA-ATTIVITÀ ESEGUITA NON CONFORME AI PIANI

Attività eseguita non conforme ai piani

IMPRESA-CATTIVO USO DELLA STRUMENTAZIONE Cattivo uso della Strumentazione

IMPRESA-INCONTRI DI LAVORO 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 ED ATTESI

Scostamento tra i risultati reali ed attesi

IMPRESA-SCOSTAMENTI TRA DATA DI CONSEGNA Scostamento tra data di consegna reale

113

Figura Figura 55--7676: Ciclo di: Ciclo di vita di una richiestavita di una richiesta


REALE E PREVISTA e prevista

IMPRESA-CARENZA CAPACITÀ Carenza Capacità

Tabella Tabella 55--33: Possibili tipi di richiesta: Possibili tipi di richiestaPer concludere, il campo OWNER_GRP può contenere i valori

STUDENTI, ORGANIZZAZIONI 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.

114

Figura Figura 55--7777: L'entità: L'entità RichiestaRichiesta


115


5.4.35.4.3 Componenti realizzateComponenti 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.

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

116

Figura Figura 55--7878: Architettura del sistema a un livello di dettaglio: Architettura del sistema a un livello di dettaglio maggioremaggiore


(documenti dinamici ASP), gestione della sessione, ecc…; un terzo livello Business 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.15.4.3.1 Databanker ServerDatabanker 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 37), è 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.15.4.3.1.1 MMETADATIETADATI

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:

117


Database: contiene una serie di informazioni che descrivono la base di dati. E’ possibile indicare sia il nome della tabella contenente le richieste (Table), 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.

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 corrisponde al codice nel campo della tabella delle 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

118

Figura Figura 55--7979: La parte Database dei metadati: La parte Database dei metadati

Figura Figura 55--8080: La parte Gruppi dei metadati: La parte Gruppi dei metadati


(ownergrp). 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,

ma solo una variazione del documento XML.

Periodi: 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.

119

Figura Figura 55--8181: Frammento della parte Tipi dei metadati: Frammento della parte Tipi dei metadati


SoddisfazioniCliente: contiene 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 (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 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.

120

Figura Figura 55--8282: Frammento della parte Periodi dei metadati: Frammento della parte Periodi dei metadati


Stati: 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 (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 lo stato delle richieste. Tramite queste informazioni un cambiamento alla struttura della tabella

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.25.4.3.1.2 IINTERFACCIANTERFACCIA DELLADELLA COMPONENTECOMPONENTE

L’interfaccia del Databanker è costituita solo da due metodi: GetMetadata() e GetData(). Con GetMetadata() i client della

121

Figura Figura 55--8383: La parte SoddisfazioniCliente dei metadati: La parte SoddisfazioniCliente dei metadati

Figura Figura 55--8484: La parte Stati dei metadati: La parte Stati dei metadati


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 GetData() dei nomi simbolici: la data con Periodi, il tipo con Tipi, 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.

122


5.4.3.1.35.4.3.1.3 CCOSTRUZIONEOSTRUZIONE DELLADELLA QUERYQUERY SQL SQL

I parametri del metodo GetData() 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 campiFROM tabellaWHERE condizioneGROUP BY campiORDER BY campi

Gli argomenti della query vengono costruiti nel seguente modo:

InformazioniRisultati: servirà a costruire i campi della clausola SELECT, ai nomi simbolici verranno fatti corrispondere i nomi fisici dei campi della tabella servendosi dei metadati;

RaggruppamentoRisultati: 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;

OrdineRisultati: servirà 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, Periodo, 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:

123


Gruppo: STUDENTIPeriodo: Settembre (01/09/2002 - 30/09/2002)Tipi: STUDENTE-CARENZA DI SPAZI, STUDENTE-VARIESoddisfazioni: Indifferente, InsoddisfattoStati: Assegnata, Ricevuta, ChiusaInformazioniRisultati: Periodi,Tipi,count(Tipi)RaggruppamentoRisultati: Periodi,TipiOrdineRisultati: Tipi,Periodi

Produrrà, secondo le attuali informazioni contenute nei metadati, la seguente query SQL:

SELECT CHANGE_DT, TYPE, count(TYPE)FROM HD_INCIDENTWHERE 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, TYPEORDER BY TYPE, CHANGE_DT;

5.4.3.1.45.4.3.1.4 TTECNICHEECNICHE DIDI REALIZZAZIONEREALIZZAZIONE EE MOTIVAZIONIMOTIVAZIONI

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 DataSet. 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 GetData(), con in evidenza l’oggetto di tipo DataSet semplicemente restituito come parametro di ritorno.

124


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.25.4.3.2 GadgetGadget

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

125

Figura Figura 55--8585: Un estratto del metodo GetData(): Un estratto del metodo GetData()


maschera che permette all’utente di personalizzare la statistica da eseguire.


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).

126

Figura Figura 55--8686: Il gadget all'interno del portale in modalità grafica: Il gadget all'interno del portale in modalità grafica


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).

127

Figura Figura 55--8787: Il gadget all'interno del portale in modalità tabellare: Il gadget all'interno del portale in modalità tabellare

Figura Figura 55--8888: Personalizzazione delle statistiche: Personalizzazione delle statistiche


5.4.3.2.25.4.3.2.2 EELABORAZIONELABORAZIONE DELLEDELLE RICHIESTERICHIESTE

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.


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.15.4.3.2.3.1 Invocazione degli XML Web ServicesInvocazione 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

128

Figura Figura 55--8989: Invocazione di un XML Web Service: Invocazione di un XML Web Service in ASP tramite in ASP tramite callWebService()callWebService()


problema è stata creata una funzione chiamata callWebService() 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 callWebService(): 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 callWebService(): la richiesta HTTP viene effettuata attraverso la componente MSXML2.ServerXMLHTTP, 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 Content-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).

5.4.3.2.3.25.4.3.2.3.2 Gestione delle preferenze utenteGestione 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.

129

Figura Figura 55--9090: La funzione callWebService(): La funzione callWebService()


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 Settings dell’interfaccia GSServices, 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 Settings. 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.35.4.3.2.3.3 Interazione con il portaleInterazione con il portale

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

130

Figura Figura 55--9191: Lettura e scrittura di variabili di Plumtree: Lettura e scrittura di variabili di Plumtree


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 <html>, <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.45.4.3.2.3.4 Rappresentazione delle statisticheRappresentazione delle statistiche

131


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.35.4.3.3 Statistics ServerStatistics 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 37), è in grado di presentare alle componenti client

132


i dati 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.15.4.3.3.1 MMETADATIETADATI

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 (codice), la componente COTS da utilizzare per eseguirla (generatore), 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.

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.

133

Figura Figura 55--9292: Frammento dei metadati sulle statistiche: Frammento dei metadati sulle statistiche



L’interfaccia di Statistics Server è costituita solo da tre metodi: GetMetadata(), GetStatisticAsGraph() 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.

GetStatisticAsGraph() e GetStatisticAsTable() 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.


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.


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.

134


5.4.3.45.4.3.4 Excel ServerExcel 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.

135


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.


L’interfaccia di Excel Server è costituita solo da due metodi: getStatisticAsChart() e getStatisticAsTable().

getStatisticAsChart() 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 132).

136

Figura Figura 55--9393: Le tre statistiche in formato grafico: Le tre statistiche in formato grafico


getStatisticAsTable() 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.


Il modo in cui la componente elabora le richieste non cambia sostanzialmente tra i due metodi getStatisticAsChart() e getStatisticAsTable(): 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 (count) è 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.


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 128). Oltre al mancato supporto dei WS,

137


non c’è alcun supporto nativo per i documenti XML se non utilizzando la componente COM XMLDOM.

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

138


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 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.

Le motivazioni che hanno spinto a realizzare questa componente 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 84) necessari in queste circostanze.

5.4.3.55.4.3.5 Statistica ServerStatistica 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 72 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.


L’interfaccia di Statistica Server è costituita solo da due metodi: getStatisticAsChart() e getStatisticAsTable().

getStatisticAsChart() 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 132).

getStatisticAsTable() invece restituisce il risultato dell’elaborazione della statistica in formato tabellare: la tabella è

139


restituita con una matrice linearizzata in un vettore con il contenuto delle celle.


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 137, sostituendo Excel con Statistica.

Stesse considerazioni vanno fatte riguardo i dati richiesti al Databanker.


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

140


uniforme il codice di gestione dei risultati sulla componente Statistics Server, con quello che gestisce i risultati del WS Excel Server.

Anche per questa componente valgono le stesse considerazioni sulla sicurezza e le autorizzazioni che si sono fatte già per la componente Excel Server.

Le motivazioni che hanno spinto a realizzare questa componente 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 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.65.4.3.6 Gadget Messaggi CRMGadget 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.

141


La componente è composta da un gadget visualizzato all’interno delle pagine del portale (Figura 5-94), dal quale è possibile 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

142

Figura Figura 55--9494: Il gadget del portale: Il gadget del portale

Figura Figura 55--9595: La pagina per l'invio delle richieste: La pagina per l'invio delle richieste


login con cui è connesso al portale. La funzione per eseguire la login è il metodo EWLogin() dell'oggetto EntWeb.Main. 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 EntWeb.Main per far corrispondere le 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 EntWeb.Main 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 EntWeb.Main è 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 EWCreateObject() di EntWeb.Main e poi il metodo EWDisplayObject() 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.45.4.4 Allocazione del sistema e sicurezzaAllocazione 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;

143


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;

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 Everyone, inoltre per i WS ASP.Net anche l’utente aspnet 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

144


l’accesso solo in modo cifrato utilizzando il protocollo HTTPS 24 o protocolli di sicurezza come WS-Security per i messaggi SOAP.

5.55.5 Componenti valutate ma non utilizzateComponenti valutate ma non utilizzatePrima 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.15.5.1 Oracle 9Oracle 9ii Portal 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 9 i 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 25 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 9 i, 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,

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.

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.

145


in quanto all’interno di un’organizzazione che non utilizza Oracle 9 i DB, Oracle Portal non è facilmente implementabile.

5.5.25.5.2 mySAP Enterprise Portal 5.0mySAP 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 26 e la soluzione mySAP.com27), 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 28

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.

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 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, supply chain management (SCM), e-procurement, business intelligence, gestione 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.

146


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.

147

Figura Figura 55--9696: Architettura di Excel: Architettura di Excel GSGS


5.5.35.5.3 Plumtree Excel Gadget ServicePlumtree 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 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 29 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.

148


6.6. SSPERIMENTAZIONEPERIMENTAZIONE

6.16.1 Approccio adottatoApproccio adottatoPer 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.26.2 Problema dei dati e simulazioneProblema dei dati e simulazioneIl 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.16.2.1 Il tool per la simulazioneIl 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.

149


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.

COMBINAZIONIPERIODI

G1 G2 Gm

C1 R1,1 R1,2 … R1,m

C2 R2,1 R2,2 … R2,m

… … … … …

Cn Rn,1 Rn,2 … Rn,m

Tabella Tabella 66--44: Schematizzazione del foglio di calcolo: Schematizzazione del foglio di calcolo

Nella parte sinistra ogni colonna indica uno dei campi della tabella HD_INCIDENT (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.

150

Figura Figura 66--9797: Il foglio di calcolo del tool: Il foglio di calcolo del tool


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.

151

Figura Figura 66--9898: Interfaccia grafica della macro: Interfaccia grafica della macro

Figura Figura 66--9999: Richieste simulate all'interno del foglio di calcolo: Richieste simulate all'interno del foglio di calcolo


Una volta inseriti i dati nel foglio di calcolo e nei campi dell’interfaccia della macro, premendo il pulsante Crea Dati vengono generate una serie di richieste simulate come quelle

visibili in Figura 6-99.

Una volta premuto il pulsante Esporta Dati invece, le richieste saranno inserite nel database del CRM come se queste fossero state inserite dal sistema CRM durante il suo normale utilizzo. In Figura 6-100 sono visibili alcuni dei record della tabella HD_INCIDENT 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.

152

Figura Figura 66--100100: La tabella HD_INCIDENT con i record: La tabella HD_INCIDENT con i record


6.36.3 Risultati ottenutiRisultati ottenutiUna 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.

153


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.

154

Figura Figura 66--101101: I risultati della query sul database: 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.

155

Figura Figura 66--102102: La statistica corrispondente alla query: 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-106 mostra il grafico dopo l’inserimento, con l’effettivo aggiornamento della statistica in tempo reale.

La Figura 6-105 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.

156

Figura Figura 66--103103: L'inserimento della richiesta: L'inserimento della richiestaFigura Figura 66--104104: Il grafico prima dell'inserimento della richiesta: Il grafico prima dell'inserimento della richiestaFigura Figura 66--105105: La tabella prima della chiusura della richiesta: La tabella prima della chiusura della richiesta


157

Figura Figura 66--106106: Il grafico dopo l'inserimento della richiesta: Il grafico dopo l'inserimento della richiesta


158

Figura Figura 66--107107: La chiusura della richiesta: La chiusura della richiestaFigura Figura 66--108108: La tabella dopo la chiusura della richiesta: La tabella dopo la chiusura della richiesta


6.46.4 Considerazioni sulle prestazioniConsiderazioni sulle prestazioniLa 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.

159


7.7. CCONCLUSIONIONCLUSIONI

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

160


connettendoli attraverso infrastrutture di rete diffuse globalmente come lo è Internet.

7.17.1 Possibili sviluppi futuriPossibili sviluppi futuriL’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.

161


8.8. BBIBLIOGRAFIAIBLIOGRAFIA

8.18.1 Riferimenti comuni a tutti i capitoliRiferimenti comuni a tutti i capitoliAutori Vari. "whatis?com". TechTarget, 2002-2003

http://whatis.techtarget.com/whome/0,,sid9,00.html

8.28.2 Riferimenti “Riferimenti “IntroduzioneIntroduzione””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.38.3 Riferimenti “Riferimenti “Dallo sviluppo per componenti ai Web Dallo sviluppo per componenti ai Web ServicesServices””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

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.


162


http://www.sei.cmu.edu/pub/documents/00.reports/pdf/00tr008.pdf


http://whatis.techtarget.com/whome/0,,sid9,00.html


C. Atkinson, J. Bayer, C. Bunse, E. Kamsties, O. Laitenberger, R. Laqua, D. Muthig, B. Paech, J. Wüst, J. Zettel, "Component-based Product Line Engineering with UML" Chapter 1. Addison Wesley, 2002

8.48.4 Riferimenti “Riferimenti “XML Web ServicesXML 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/samplechapter/0130097195.pdf

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.


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}

163

http://www.informit.com/isapi/product_id~%7BA0D14FAE-362F-4878-A624-0899FC89D76B%7D/session_id~%7B2CED9276-BEFA-4C67-B340-078E95C9F65E%7D/content/index.asp

http://www.informit.com/isapi/product_id~%7BA0D14FAE-362F-4878-A624-0899FC89D76B%7D/session_id~%7B2CED9276-BEFA-4C67-B340-078E95C9F65E%7D/content/index.asp

http://www.perfectxml.com/XMLIntro.asp#chap

http://www.research.ibm.com/journal/sj/412/gottschalk.pdf




http://www.w3.org/TR/2002/WD-wsa-reqs-20020429


M. Stal, “Web Services: Beyound Component-Based Compunting”. Communication of the ACM, October 2002/Vol 45 No. 10, Pag. 71-76.

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/webservicebasics/default.aspx?pull=/library/en-us/dnsoapspec/html/soapspecindex.asp

Autori Vari. "Web Service Basics: WSDL Specification Index Page", Microsoft MSDN Library.

http://msdn.microsoft.com/webservices/understanding/webservicebasics/default.aspx?pull=/library/en-us/dnwsdl/html/wsdlspecindex.asp

Autori Vari. "Web Service Basics: UDDI Specification Index Page", Microsoft MSDN Library.

http://msdn.microsoft.com/webservices/understanding/webservicebasics/default.aspx?pull=/library/en-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.

164












http://msdn.microsoft.com/msdnmag/issues/0300/soap/

http://www.acmqueue.org/issue/burner1.cfm


http://www.informit.com/isapi/product_id~{68E8E905-8165-465E-B648-B1F07B294D0D}/content/index.asp

8.58.5 Riferimenti “Riferimenti “Case StudyCase Study””Autori Vari. "Introduction to COTS". Center for Empirically-Based Software Engineering (CeBASE).

http://www.cebase.org/www/researchActivities/COTS/introduction.html

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.

165

http://msdn.microsoft.com/library/en-us/com/htm/com_757w.asp



http://gadgets.plumtree.com/downloads/TheGadgetBook.zip

http://www.cebase.org/www/researchActivities/COTS/definition.html



http://www.informit.com/isapi/product_id~%7B68E8E905-8165-465E-B648-B1F07B294D0D%7D/content/index.asp

http://www.informit.com/isapi/product_id~%7B68E8E905-8165-465E-B648-B1F07B294D0D%7D/content/index.asp


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

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/default.asp

Autori Vari. ".NET Framework Developer's Guide - Overview of the .NET Framework". Microsoft MSDN Library, 2002.

http://msdn.microsoft.com/library/en-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.

http://msdn.microsoft.com/library/en-us/cpguide/html/cpconintroductiontoasp.asp

Autori Vari. “ASP.Net QuickStart – Introducing Web Services”. Microsoft, 2002.

http://samples.gotdotnet.com/quickstart/aspplus/doc/webservicesintro.aspx

Autori Vari. ".NET Framework Developer's Guide - Creating an XML Web Service Proxy". Microsoft MSDN Library, 2002.

http://msdn.microsoft.com/library/en-us/cpguide/html/cpconcreatingwebserviceproxy.asp

Autori Vari. ".NET Framework Developer's Guide - Interoperating with Unmanaged Code". Microsoft MSDN Library, 2002.

166







http://msdn.microsoft.com/net/aspnet/





http://www.statsoft.com/visualbasic.html

http://serlab2.di.uniba.it/serlab/courses/2002_03/infvo/SPC.pdf


http://msdn.microsoft.com/library/en-us/cpguide/html/cpconinteroperatingwithunmanagedcode.asp

T. Archer. "Inside C#" Capitolo 2: "Introduzione a Microsoft .Net". Mondadori Informatica, 04/09/2001

http://education.mondadori.it/libri/Download/Capitoli/214_Cap02.pdf

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.

http://msdn.microsoft.com/library/en-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/rbonneau/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.jsp

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.68.6 Riferimenti “Riferimenti “ConclusioniConclusioni””

M. Stal, “Web Services: Beyound Component-Based Compunting”. Communication of the ACM, October 2002/Vol 45 No. 10, Pag. 71-76.

167

http://www.di.uniba.it/~reti/dispense/IntroAppWeb.pdf







http://www.asp.net/webmatrix/default.aspx?tabindex=4&tabid=46






168

Tesi di Laurea: Integrazione software via Web Service

Documents

Transcript of Tesi di Laurea: Integrazione software via Web Service