Tesi - Realizzazione di un'applicazione per il monitoraggio degli accessi a pagine Web

UNIVERSITA’ D PADOVA FACOLTA’ DI INGEGNERIA

TESI DI DIPLOMA

REALIZZAZIONE DI UN’APPLICAZIONE PER IL MONITORAGGIO DEGLI ACCESSI A PAGINE WEB

Relatore: Prof.ssa Maria Emanuela Crescenti Diplomando: Alessandro Scola

CENTRO STUDI DI FELTRE

ANNO ACCADEMICO 1998-1999

CORSO DI DIPLOMA IN INGEGNERIA INFORMATICA E AUTOMATICA DEI DIPARTIMENTO DI ELETTRONICA E INFORMATICA

SOMMARIO

SOMMARIO ................................................................................................................................. 3

PREMESSA................................................................................................................................... 5

1 ...................................................................................................................................................... 7

DESCRIZIONE DELL’AZIENDA............................................................................................. 7 1.1 L’AZIENDA............................................................................................................................. 7 1.2 CONTESTO ORGANIZZATIVO................................................................................................... 7 1.3 INFORMATIZZAZIONE ........................................................................................................... 11

1.3.1 Configurazione hardware ............................................................................................ 11 1.3.2 Situazione delle applicazioni ....................................................................................... 14 1.3.3 Rete di comunicazione ................................................................................................. 15

2 .................................................................................................................................................... 19

SPECIFICHE DI SVILUPPO ................................................................................................... 19 2.1 SPECIFICHE GENERALI DI SVILUPPO...................................................................................... 19 2.2 SPECIFICHE TECNICHE DI FUNZIONAMENTO ......................................................................... 20

3 .................................................................................................................................................... 23

SCELTA DEL SOFTWARE ..................................................................................................... 23 3.1 AMBIENTE DI SVILUPPO ....................................................................................................... 23 3.2 L’AMBIENTE LOTUS NOTES E DOMINO ................................................................................ 23

3.2.1 Panoramica generale................................................................................................... 23 3.2.2 I documenti .................................................................................................................. 25 3.2.3 I campi ......................................................................................................................... 25 3.2.4 I moduli ........................................................................................................................ 27 3.2.5 Le viste ......................................................................................................................... 27 3.2.6 Cos'è un server Domino............................................................................................... 27 3.2.7 Come il server Domino interagisce con un client Web ............................................... 27 3.2.8 Come Domino gestisce gli URL................................................................................... 29 3.2.9 Due parole sulla sicurezza: le ACL ............................................................................. 30

3.3 COME SVILUPPARE UN’APPLICAZIONE PER DOMINO ............................................................ 33 3.3.1 Panoramica generale................................................................................................... 33 3.3.2 Gli agenti Notes ........................................................................................................... 33 3.3.3 Invocazione remota di Agenti ...................................................................................... 36 3.3.4 Perché Java.................................................................................................................. 37 3.3.5 Un’alternativa efficace: CORBA ................................................................................. 38 3.3.6 R5 e CORBA ............................................................................................................... 40

3.4 I FILES DI LOG ...................................................................................................................... 41 3.4.1 Cosa sono i files di log................................................................................................. 41 3.4.2 Domino e i files di log.................................................................................................. 42

4 .................................................................................................................................................... 45

SCELTA DELLE TECNOLOGIE............................................................................................ 45 4.1 INFOBUS............................................................................................................................... 45

4.1.1 cos’e l’InfoBus e come funziona .................................................................................. 45 4.1.2 Tipi di componenti ....................................................................................................... 46 4.1.3 Il protocollo InfoBus per lo scambio dei dati .............................................................. 47 4.1.4 Descrizione package javax.infobus.............................................................................. 51

4.2 LIVE CONNECT..................................................................................................................... 54 4.2.1 Comunicazionce tra JavaScript e Java........................................................................ 54 4.2.2 Comunicazione tra Java e JavaScript.......................................................................... 61

5..................................................................................................................................................... 67

REALIZZAZIONE..................................................................................................................... 67 5.1 L’IDEA DI BASE .................................................................................................................... 67 5.2 SCELTA DELLE TECNOLOGIE E MOTIVAZIONI........................................................................ 68 5.3 LA PARTE “CLIENT” ............................................................................................................. 70

5.3.1 Panoramica generale del Client .................................................................................. 70 5.3.2 Il form per l’impostazione dei parametri:.................................................................... 72 5.3.3 L’invio dei parametri ................................................................................................... 82 5.3.4 La ricezione dei risultati .............................................................................................. 84 5.3.5 La pubblicazione dei risultati ...................................................................................... 86 5.3.6 L’interazione con l’utente ............................................................................................ 87

5.4 IL MIDDLE TIER ................................................................................................................... 92 5.4.1 Multithreading ............................................................................................................. 92

5.5 IL DATA TIER....................................................................................................................... 93

6..................................................................................................................................................... 95

MASCHERE................................................................................................................................ 95 6.1 IL PRESENTATION TIER ......................................................................................................... 95

7..................................................................................................................................................... 99

CONCLUSIONI.......................................................................................................................... 99

BIBLIOGRAFIA....................................................................................................................... 101

PREMESSA

Tesi di Diploma – Alessandro Scola – [email protected] Pagina 5

PREMESSA

Sempre più aziende al giorno d’oggi si affacciano al mondo di Internet, non solo per

sfruttarne le immense risorse informative e di comunicazione che esso mette a disposizione,

bensì per divenirne parte integrante mediante la creazione di siti a loro dedicate. Sia per la

piccola fabbrica sia per la media e grande industria, avere propria una pagina Web significa

ottenere una serie di benefici in termini di pubblicità, ma non solo.

Obiettivo dello studio sarà quello di progettare e realizzare un prodotto software destinato

ad essere utilizzato da quei clienti della NetWorkGroup s.r.l. che intendono mantenere on-line un

proprio sito internet nei server della stessa NetWorkGroup. Esso consentirà a tali clienti di

monitorare quantitativamente e in tempo reale l’andamento delle visite effettuate tramite

internet, alle proprie pagine Web. Il programma dovrà rappresentare graficamente a video tali

informazioni.

L’utilizzo del software da parte dell’utente finale dovrà avvenire tramite l’ausililio di un

browser di pagine html come ad esempio Internet Explorer o Netscape Navigator. Per la

realizzazione del prodotto sono state dettate alcune specifiche da seguire, dettagliatamente

elencate e spiegate nel capitolo 2.

PREMESSA

Pagina 6 Tesi di Diploma – Alessandro Scola – [email protected]

DESCRIZIONE DELL’AZIENDA - Capitolo 1


1 DESCRIZIONE DELL’AZIENDA

1.1 L’azienda L’Azienda cui è rivolto lo studio è la NetWorkGroup s.r.l. sita a Belluno in via Col di

Salce n°5/A. E’ presente dal 1995 sul mercato del ramo informatico e delle telecomunicazioni, nella vendita di beni e servizi. I settori in cui la società ha concentrato le proprie energie sono la progettazione di applicativi evoluti per la gestione di flussi informativi particolari, l'integrazione di sistemi hardware e software in vere e proprie reti telematiche e la formazione all'uso di strumenti informatici. Inoltre, in collaborazione con l'Ente Universitario Cineca di Bologna, gestisce il POP bellunese della rete geografica Nettuno offrendo servizi di ISP (Internet Service Provider) a privati e ad aziende.

Fra le strategie adottate da NetWorkGroup (NWG), un posto di rilievo spetta all'utilizzo di nuove tecnologie nello sviluppo dei servizi, sia in campo software che hardware. Fra queste spicca l'ambiente Lotus Notes/Domino sia per la gestione dei gruppi di lavoro (anche a distanza) che per la creazioni di basi di dati facilmente utilizzabili da vari utenti anche via Internet. NetWorkGroup si è inoltre specializzata nella progettazione e costruzione di Siti Internet di fascia elevata con particolare attenzione al livello di personalizzazione e all'interfaccia grafica.

Gli obiettivi aziendali a medio termine sono orientati al consolidamento di un know-how che consenta di rimanere all'avanguardia nel mercato dei servizi informativi su rete locale e geografica, con particolare riferimento alle recenti tecnologie Intranet. Le partnership più significative coinvolgono, oltre alla IBM Lotus di cui NWG è Business Partner, l'Università “Ca' Foscari” di Venezia ed il “Cineca” di Bologna.

1.2 Contesto organizzativo

Capitolo 1 - DESCRIZIONE DELL’AZIENDA


La NetWorkGroup è attualmente composta da un'équipe di 5 giovani professionisti, di cui uno è il titolare, e si avvale dell’aiuto di 3 collaboratori esterni in qualità di: 1 grafico, 1 sistemista e 1 programmatore. Le modeste proporzioni dell’Azienda impongono che ogni dipendente svolga contemporaneamente più mansioni all’interno di essa.

La struttura organizzativa comunque, vede al vertice il socio unico dell'azienda a cui è

affidata la direzione generale e quattro distinte aree secondo il seguente organigramma.

Figura 1-1: Organigramma NetWorkGroup per aree di attività

Area tecnica:

coinvolge in totale 4 persone ed ha i seguenti scopi:

sviluppare applicazioni aziendali di varia natura utilizzando come piattaforma di sviluppo Lotus Notes e Domino 5.

sviluppare programmi a scopo gestionale e per il trattamento della documentazione

interna utilizzando come linguaggio di programmazione Delphi 3 e Lotus Domino 5.

AreaTecnica

2 sistemisti

2programmatori

1 grafico

AreaCommerciale

Areasegreteria

Areaformazione

2 commerciali

ColllaboratoriEsterni

1 analista 1 grafico

1 sistemista

1programmatore

DIREZIONE(1 persona)

1 insegnante 1 segretaria



curare tutta la parte sistemistica sia dei clienti sia della NWG stessa, garantendo il

funzionamento delle singole macchine e della LAN aziendale. curare l’aspetto grafico delle diverse applicazioni sviluppate dalla NWG progettando e

disegnando gli elementi grafici delle interfacce utente dei programmi.

Area Commerciale:

è composta da 2 persone ed è il settore che riguarda:

l’acquisto di materia prima come hardware e software d’ambiente e di base che verrà poi rivenduta ai clienti NWG. Infatti oltre al proprio software, la NWG rivende software prodotto da terzi; per lo più si tratta di licenze d’uso di sistemi operativi e pacchetti software di varia natura, a seconda delle esigenze del singolo cliente. Si occupa quindi del rapporto con i vari fornitori.

la vendita dei beni e dei servizi forniti dalla NWG. Si occupa quindi anche del

rapporto con i clienti.

Area formazione: è composta da 1 persona e riguarda:

l’addestramento di personale all’uso di programmi standard diffusi, come ad esempio Lotus Notes.

l’addestramento di personale all’uso di software prodotto dalla NetWorkGroup.

Area segreteria:



è composta da 1 persona che si occupa delle comuni funzioni di segreteria, nonché della parte finanziaria (paghe, emissione bolle, pagamento corrieri e fornitori, rapporto con le banche, ecc..).



1.3 Informatizzazione

1.3.1 Configurazione hardware All’interno degli uffici della NWG sono presenti numerose macchine, alcune per uso

interno di sviluppo software, altre adibite ad uso “Server”. Segue la configurazione hardware dei SERVER.

SERVA

PROCESSORE Intel Pentium II a 400 MHz Memoria RAM 128 MB Scheda grafica Matrox Millenium G200 AGP 8MB Hard disks Sistema Raid mylex 4MB RAM

composto da 2 dischi ibm da 9,1GB a 7200 giri/min

Lettore CD ROM Lettore CD rom 32X Floppy Disk Drive da 3”1/2 Standard Schede di rete Tricom 10/100 Mbps Mouse Mouse seriale STANDARD Sistema Operativo Windows NT

PELMO

PROCESSORE Intel Pentium III a 450 MHz Memoria RAM 128 MB Scheda grafica Matrox Millenium G200 AGP 8MB Hard disks Sistema Raid mylex 4MB RAM


Lettore CD ROM Lettore CD rom 32X Floppy Disk Drive da 3”1/2 Standard Schede di rete Tricom 10/100 Mbps Mouse Mouse seriale STANDARD



Sistema Operativo Windows NT

FEINAR PROCESSORE Intel Pentium III a 350 MHz Memoria RAM 128 MB Scheda grafica ATI Graphics Accelerator 4MB Hard disks Sistema Raid mylex 4MB RAM

composto da 2 dischi ibm da 4,5 GB a 7200 giri/min

Lettore CD ROM Lettore CD rom 32X Floppy Disk Drive da 3”1/2 Standard Schede di rete Tricom 10/100 Mbps Mouse Mouse seriale STANDARD Sistema Operativo Windows NT

SCO UNIX PROCESSORE 2 processori Intel Pentium Pro a 200

MHz Memoria RAM 128 MB Scheda grafica SVGA Hard disks Sistema Raid Mylex 8MB RAM

composto da 2 dischi ibm da 4 GB Lettore CD ROM Lettore CD rom 32X Floppy Disk Drive da 3”1/2 Standard Schede di rete Tricom 10/100 Mbps



Mouse Mouse seriale STANDARD Sistema Operativo Windows NT

MARMOLADA PROCESSORE Intel Pentium III a 450 MHz Memoria RAM 128 MB Scheda grafica Matrox Millenium G200 AGP 8MB Hard disks Sistema Raid mylex 4MB RAM


+ disco HD Quantum

Lettore CD ROM Lettore CD rom 32X Floppy Disk Drive da 3”1/2 Standard Schede di rete Tricom 10/100 Mbps Mouse Mouse seriale STANDARD Sistema Operativo Windows NT Server+service pack 4

SERVER LINUX PROCESSORE SUN Netra int. Server Sparc 110 Memoria RAM 32 MB Scheda grafica SVGA Hard disks 2 dischi SCSI da 1GB Lettore CD ROM Lettore CD rom 32X Floppy Disk Drive da 3”1/2 Standard



Schede di rete Tricom 10/100 Mbps Mouse Mouse seriale STANDARD Sistema Operativo Red HAT Linux 4.1

Vi sono poi 6 comuni PC, che rappresentano le postazioni di lavoro di ogni dipendente.

Montano processori Intel Pentium II, Pentium III o AMD K6 e Windows NT come sistema operativo. Sono tutti dotati di scheda di rete 10/100 Mbps mediante la quale sono connessi alla LAN aziendale e ad Internet;

1.3.2 Situazione delle applicazioni Nei Server della NWG è installato software specifico, a seconda del tipo di impiego cui è

destinata ogni singola macchina. Ecco brevemente riassunto il software presente nei diversi computer ad uso SERVER:

MARMOLADA:

� domino 5.01 a � software di “fax server” � server di posta NWG � software di Serial Communication Service saps (per poter utilizzare un unico

modem da più persone contemporaneamente)

SERVA: � Internet Information Server IIS 4.0 � Server di posta MDAEMON

PELMO:

� Domino Server 5 � Server di posta MDAEMON (dolomites.it)

FEINAR:

� Domino 5.01 a

SCO UNIX: attualmente inutilizzato



Nei 6 PC è installato software specifico per il tipo di mansione svolta dai dipendenti:

programmi di grafica (Photoshop, Corel Draw, ecc…) nella postazione grafica, programmi di sviluppo applicativi (Lotus Domino Designer, JDK, Delphi, ecc…) nelle postazioni dei programmatori.

1.3.3 Rete di comunicazione Tutte le macchine all’interno dell’azienda sono dotate di scheda di rete 10/100 Mbps e

sono connesse tra di loro tramite l’impiego di doppini telefonici CAT.5, connettori RJ45 e numerosi hub, che però supportano solo i 10Mbps limitando di fatto tutta la LAN a tale velocità. Il protocollo di comunicazione impiegato è il TCP/IP. Lo schema dettagliato della rete è rappresentato in figura 1-2 nella pagina seguente.



Figura 1-2: schema rete NWG

Come si può notare dallo schema, il cuore della rete aziendale è costituita dai due router : “Cisco AS 5200” e “Cisco 1600”.

CISCO AS 5200: E’ connesso tramite linea Frame Relay 384Kbps CIR 50% al POP “Cineca” di Bologna e

rappresenta il collegamento con Internet. In esso entra un flusso primario ISDN BRI da 2Mbps utilizzato per consentire ai privati e alle ditte di accedere ad internet tramite linea telefonica commutata (mediante modem) oppure tramite collegamento digitale ISDN.

Al “Cisco AS 5200” è inoltre collegato un POP con sede a Primiero (TN) tramite linea dedicata CDN a 64Kbps e ai 5 server (“Pelmo”,”Serva”,”Feinar”,”Feinar SSL”,Nevegal”) visibili da Internet. Uno di essi, “Feinar SSL” svolge funzioni di Firewall.

CISCO 1600: Al Cisco 5200 è conesso il Router Cisco 1600. Ad esso sono collegate tutti i 6 PC della

LAN aziendale, che però non risultano visibili da Internet, più due macchine “Marmolada” e “Sco Unix” che svolgono funzioni di Server e sono visibili da Internet. In particolare “Marmolada” è contemporaneamente Server per uso interno (LAN) e per uso esterno, gestendo la posta elettronica in arrivo a in partenza verso Internet.

Un cliente è inoltre connesso al Cisco 1600 mediante linea dedicata CDN a 64Kbps, e attraverso cui accede ad Internet.

Uno dei 6 PC, “Segreteria” svolge funzioni di Print Server, consentendo l’utilizzo

dell’unica stampante laser da parte di tutti i dipendenti.

SPECIFICHE DI SVILUPPO - Capitolo 2


2 SPECIFICHE DI SVILUPPO

2.1 Specifiche generali di sviluppo

Ambiente di sviluppo:

l’applicazione dovrà girare in Lotus Domino 5.01a come piattaforma Server di base, per tanto essa dovrà essere scritta utilizzando Domino Lotus Designer.

le informazioni che il prodotto tratterà ed elaborerà saranno prelevate da un database Domino, attualmente residente sul server “Marmolada” e contenente tutti i log degli accessi effettuati da parte di navigatori internet;

Modalità di accesso all’applicazione: l’accesso all’applicazione dovrà poter avvenire via Web tramite l’utilizzo di un comune Browser di pagine HTML (in particolare dovrà essere completamente compatibile con Microsoft Internet Explorer e Netscape Navigator).

Regolamentazione per l’accesso ai dati: l’accesso alle informazioni statistiche che il software fornirà dovrà essere regolamentato dalla politica secondo la quale l’utente può ottenere le statistiche dei soli siti (uno o più di uno) di cui è proprietario;

Capitolo 2 - SPECIFICHE DI SVILUPPO


2.2 Specifiche tecniche di funzionamento Verranno qui sotto esposte le caratteristiche di funzionamento cui il prodotto software

finito dovrà aderire.

Tipi di utenze: Data la natura confidenziale dei dati trattati, è stato esplicitamente richiesto che il

programma possa riconoscere l’utente collegato in quel momento e far vedere oppure celare alcune informazioni, a seconda della categoria di utenza a cui fa parte.

Le categorie possibili sono due: NWG (NetWorkGroup): ne fanno parte il WebMaster (in questo caso il sottoscritto) ed

eventualmente altri componenti del Team della NetWorkGroup; essi hanno accesso alle informazioni statistiche relative a tutte le pagine web cui il programma può accedere.

Clienti: ne fanno parte tutti gli altri utenti, ovvero i clienti ordinari per i quali è stato

sviluppato il software. Essi avranno accesso alle informazioni statistiche relative alle sole pagine web di cui sono proprietari. Di norma ad un cliente appartiene un solo sito, ma può averne anche molti di più.

Il programma dovrà quindi essere in grado di far scegliere all’utente il sito di interesse di

cui desidera avere informazioni, visualizzando a video una lista dei soli domini a lui consentiti. Ulteriori vincoli sulla sicurezza sono descritti più avanti in questo capitolo.

Il contatto: Ogni sito web che si rispetti ha molte visitazioni giornaliere, ovvero molte pagine html,

immagini, e documenti di varia natura che vengono inviati dal server ai client che ne fanno richiesta. Ma quanti di questi client sono effettivamente visitatori differenti?

Un conto è infatti considerare le richieste fatte al server in modo assoluto, un conto è invece considerare quante e quali richieste sono state inviate dalla stessa persona in un determinato arco di tempo, ad esempio in una giornata. Un utente che ricarica la stessa pagina cliccando sul tasto “aggiorna” del proprio browser, non è certo da considerare come un nuovo visitatore, anche se nel file di log la sua richiesta appare come tutte le altre.

SPECIFICHE DI SVILUPPO - Capitolo 2


E’ stato richiesto che il programma potesse considerare e quindi contare le entry nel file di log, in entrambe le interpretazioni. Dette entry saranno anche chiamate d’ora in poi con il termine “contatto”.

L’utente del programma dovrà poter scegliere tra le due interpretazioni di contatto:

Host Distinti per giornata : considera solo le richieste fatte da utenti distinti nell’arco di una giornata.

Richieste totali : considera tutte le richieste indistintamente.

Aggregazione: Infine l’aggregazione rappresenta un criterio in cui dividere ogni serie di dati. Per il

momento è stato richiesto che le serie siano suddivise in categorie temporali di un mese. Ciò significa che il grafico (istogramma) dovrà rappresentare con ogni singola colonna il totale degli accessi fatti in un mese diverso.

Sicurezza: La natura dei dati che il programma mette a disposizione è abbastanza delicata, ma non

critica. E’ stato richiesto un livello di sicurezza medio-basso per garantire la privacy dei dati forniti dal programma. Si vuole impedire che utenti non autorizzati accedano a informazioni cui non dovrebbero aver accesso.

Ciò che non compare esplicitamente nelle suddette specifiche sarà liberamente

interpretato ed implementato.

Capitolo 2 - SPECIFICHE DI SVILUPPO


SCELTA DEL SOFTWARE - Capitolo 3


3 SCELTA DEL SOFTWARE

In questo capitolo vengono fornite minime ma basilari nozioni di carattere generale sul software utilizzato per il progetto, al fine di poter capire quanto esposto nel capitolo 5 “Realizzazione”.

3.1 Ambiente di sviluppo E’ stato imposto l’utilizzo di “Lotus Domino Designer” per piattaforme Intel come

ambiente di sviluppo del programma.

3.2 L’ambiente Lotus Notes e Domino

3.2.1 Panoramica generale

Domino Designer è un programma di sviluppo incluso nel pacchetto chiamato Lotus Notes, che include oltre al Designer, il motore server Lotus Domino, il client Lotus Notes (che ha lo stesso nome del pacchetto in cui è contenuto) e l’utility di amministrazione Lotus Domino Administrator.

Lotus Notes è sostanzialmente una piattaforma client-server che consente di accedere, condividere e gestire le informazioni presenti all’interno di una rete, sia interna sia esterna. Una rete di Notes è costituita da almeno un server e da una o più stazioni di lavoro (client); al server si interfacciano i vari client per lo svolgimento di tutta una serie di attività: dallo scambio di documenti alla condivisione di rubriche comuni; dalla gestione della posta elettronica al controllo e sincronizzazione di database distribuiti. Offre inoltre interessanti funzionalità nel settore della pubblicazione di pagine Web interattive.

Il client è un computer che accede alle risorse messe a disposizione dal server Domino, e può farlo secondo due modalità:

� attraverso l’utilizzo del software client Lotus Notes � attraverso l’utilizzo di un browser di pagine html

Capitolo 3 - SCELTA DEL SOFTWARE


Ciascuna delle due modalità comporta pregi e difetti che verranno discusse nel paragrafo 3.2.7.

La principale peculiarità e punto di forza del prodotto è l’utilizzo del formato database per la raccolta di ogni genere di dato; tutto può essere inglobato in un db di tipo “nsf”: documenti multimediali, mail, messaggi, file di testo, ma soprattutto applicazioni. Tutto quello che si desideri inserire nel sistema di gestione condiviso viene gestito tramite database; perfino i files di configurazione del sistema, quelli di impostazione dei profili utente e gli archivi di posta sono database. Con i debiti adattamenti questo tipo di concezione la ritroviamo in (o deriva da) Unix dove tutte le risorse di sistema vengono viste come file. Per questo motivo l’ambiente Lotus Notes viene spesso considerato un vero e proprio database, che però sfugge alla classica e diffusa filosofia dei db relazionali. Non c’è niente di relazionale in Notes, non esistono i concetti di tabelle o relazioni, e anche se la relazionalità la si potrebbe anche simulare, non rappresenta certo lo spirito con cui i progettisti della Lotus hanno voluto sviluppare questo prodotto. Infatti, mentre i DBMS relazionali hanno meccanismi intrinseci per mantenere consistenza e integrità referenziale, in Notes questi meccanismi andrebbero implementati manualmente tramite procedure che rispondono a particolari eventi. Piuttosto Notes lo si potrebbe pensare come un database documentale, un database cioè nel quale l’unità atomica di memorizzazione è il documento. Ogni oggetto che si vuole inglobare nel database viene considerato genericamente un documento, sia esso un file di testo, sia esso un oggetto multimediale.

Ogni db inoltre è personalizzabile per mezzo di Lotus Script o Java in modo da creare delle vere e proprie applicazioni. Questa caratteristica, che all’inizio porta un po’ di confusione nell’utente/programmatore alle prime armi, ha il grosso vantaggio di uniformare la metodologia di gestione delle varie risorse.

Tenendo presente che in maniera quasi automatica un database può essere pubblicato su internet senza sforzi aggiuntivi, si comprende la potenza del sistema: un archivio di prodotti ad esempio può essere trasformato in pagine html (è il server stesso che se ne preoccupa in maniera dinamica) con la possibilità di eseguire ricerche e aggiornamenti in tempo reale (modificato il database con il client Notes, la parte web delle pagine html resta sempre aggiornata) oppure sincronizzazione con altri database (l’altra grossa potenza del sistema). La pubblicazione dinamica su web è un meccanismo molto simile a quello che da poco è stato introdotto con le pagine ASP o ancora più recentemente con JSP: in questo caso pero’ la parte d’interfacciamento web si integra con un back-end aziendale altamente sofisticato, con un livello di sicurezza molto elevato. Si può dunque affermare in maniera forse un po’ sintetica ma sicuramente efficace, che in Domino tutto è un database, e tutte le operazioni di gestione possono essere eseguite semplicemente modificando gli oggetti che lo compongono.

Nei paragrafi seguenti verrà data una breve spiegazione dei termini chiave di Notes, quali: documenti, campi, moduli e viste.



3.2.2 I documenti Il documento è il cuore del database; Notes è particolarmente flessibile per quanto

riguarda il tipo di informazioni che si possono memorizzare in un database. Infatti un documento può contenere praticamente ogni tipo di informazione leggibile dalla macchina.

Un singolo database può contenere un numero qualsiasi di documenti di diverso tipo. Per esempio, un database può avere al suo interno una serie di documenti con informazioni su nomi e indirizzi; un’altra serie di documenti potrebbe contenere informazioni finanziarie riservate; e ancora un’altra serie di documenti potrebbe essere dedicata a informazioni personali o storiche, tutto nello stesso database. Attraverso il documento si accede ai dati di campo.

3.2.3 I campi Un campo è un’area del modulo (vedi oltre) che contiene un singolo tipo d’informazione.

Il tipo di dato del campo determina la tipologia di dati che l’utente può inserire all’interno del campo.

I campi Notes hanno alcune caratteristiche molto singolari che li distinguono da quelli utilizzati dagli altri sistemi di database. Innanzitutto i campi sono di lunghezza variabile. I vantaggi significativi di questa caratteristica sono due.

Primo: ogni documento occupa nel disco rigido soltanto lo spazio di cui ha bisogno; non c’è più lo spazio sprecato su disco come nel caso di campi a lunghezza fissa.

Secondo: la grandezza dello stesso campo in documenti diversi non deve più essere la stessa, per cui si potranno introdurre nel campo tutte le informazioni che si desiderano e non si avrà spazio sprecato nel campo corrispondente in altri documenti.

Come opzione d’impostazione del database, alcuni campi possono essere configurati a

valori multipli. Se si sceglie di introdurre più di un valore in uno di questi campi, ognuno di questi valori può essere di differente lunghezza.

Notes dispone di otto diversi campi: � Testo:

possono contenere lettere, simboli di punteggiatura, spazi e numeri non utilizzabili per calcoli matematici; inoltre non sono formattabili dall'utente, cioè mantengono le impostazioni date in fase di creazione del modulo.

� Numeri:



contengono informazioni sulle quali è possibile eseguire calcoli matematici. Vengono riconosciuti tutti i numeri tra 0 e 9, 1 segni + e -, la virgola decimale e la notazione scientifica (E). E possibile determinare lo stile di visualizzazione dei dati (Generale, Fissa, Scientifica e Valuta).

� Valori di data e ora: le informazioni relative alle date e ore sono composte da numeri separati

da segni di punteggiatura. Il formato predefinito è GG/MM/AA HH:MM:SS, ma è possibile personalizzare la visualizzazione.

� Parole chiave: Consentono di creare un elenco con una serie di opzioni predefinite che

possono essere selezionate dagli utenti. E’ possibile abilitare gli utenti alla multiselezione degli elementi elencati, oppure all’inserimento di valori non presenti nella lista.

� Rich-Text: i campi rich-text possono contenere testo, testo formattato, tabelle, uno o

più elementi grafici intervallati da testo. E’ anche possibile includere pop-up, allegati e oggetti OLE collegati o incorporati. Un file può essere allegato a un documento attraverso un campo rich-text.

� Autori: Viene utilizzato per specificare gli utenti che possono modificare il

documento; serve a elevare l’accesso nel caso questi non siano abilitati a intervenire sul documento.

� Nomi: I campi nomi vengono utilizzati per visualizzare nomi distinti completi in

forma abbreviata. Per esempio, se il nome canonico è:

CN=Cristiana Bernardi /OU=Interni /O=SINERGIA Emilia Romagna s.r.l. /C=IT

il formato abbreviato sarà:

Cristiana Bernardi/Interni/SINERGIA Emilla Romagna s.r.l./IT � Lettori:

Viene utilizzato per determinare gli utenti che possono leggere un documento; se questo campo è vuoto il documento è visibile a tutti, mentre se viene inserito un nome, il documento è visibile solo a quello specifico lettore.



3.2.4 I moduli All'interno di un database si possono creare diversi moduli (forms). Il modulo viene usato

per creare, visualizzare e stampare documenti. E’ possibile creare infiniti moduli in ogni database e quindi utilizzarli per creare, visualizzare o stampare un documento.

3.2.5 Le viste Una vista di database è una finestra all’interno dei documenti memorizzati in un database.

Le viste sono in qualche modo simili agli indici utilizzati dai precedenti tipi tradizionali di database come dBASE, Paradox, ecc… Ogni vista mostra un sottoinsieme di tutti i documenti di un database selezionati secondo dei criteri, e di essi ne visualizza uno o più campi (si vada al paragrafo 3.4.2 per un esempio).

3.2.6 Cos'è un server Domino Il server Web Domino è un processo scritto in C++ che utilizza specifiche API di Notes

per integrarsi con i restanti servizi, allo stesso modo di una generica applicazione non Web. E’ costituito essenzialmente da due componenti: l’HTTP Server e il Domino Application

Server. Il primo può essere visto come il “front end” del server Web, mentre il secondo come il “back end”. Similmente a ogni altro server HTTP, il server HTTP di Domino è un processo multi-threaded che attende le richieste da parte di client Web e invia loro una risposta in base alle richieste fattegli.

3.2.7 Come il server Domino interagisce con un client Web L'interazione tra il server Web Domino e un client Web avviene secondo il seguente

schema: � il server Domino esamina l'indirizzo URL della richiesta in arrivo e determina se

la richiesta è per un elemento in un database di Domino oppure se è per un file HTML che si trova all'interno del file system;

� se la richiesta è relativa a un file HTML, Domino si comporta esattamente come

qualsiasi altro server Web e fornisce il file al client Web;



� nel caso la richiesta sia per qualcosa che si trova all'interno di un database, Domino interagirà con quel database per fornire le informazioni al client Web, o viceversa per inserire nel database le informazioni provenienti dal client Web.

Ora, nel paragrafo 3.2.1 si è accennato alla duplice possibilità di accedere via Web ad un

database o, (che è un po’ la stessa cosa), ad una applicazione Notes: tramite browser di pagine html oppure tramite il client Lotus Notes. Ebbene, deve essere ben chiaro quale dei due client sarà quello utilizzato dagli utenti finali dell’applicazione Notes, o se saranno utilizzati entrambi; la scelta da parte dello sviluppatore di applicativi Notes deve essere fatta prima d’iniziare lo sviluppo. Entrambe le due alternative infatti vincola:

� l’utilizzo di alcune tecnologie piuttosto che altre; � la gamma dei linguaggi di programmazione utilizzabili.

Lo sviluppo di un’applicazione destinata ad essere utilizzata tramite il client Lotus Notes è enormemente facilitato grazie a potenti funzionalità già pronte e utilizzabili con poche righe di codice. Queste funzionalità sono rese disponibili grazie all’utilizzo di un linguaggio proprietario detto LotusScript e delle cosiddette formule, costituite anch’esse da un linguaggio proprietario. Questi due strumenti consentono al client Lotus Notes di effettuare operazioni anche complesse su un db di Notes in maniera diretta e trasparente, ossia senza che ci si debba preoccupare della connessione, e di fatto rendendo le cose facili come se si stesse operando su un db locale, nel file system della macchina client.

Al contrario, l’impiego di un browser di pagine html come client è molto più

problematico per due ragioni in particolare: � mancanza di molte di quelle potenti funzioni già pronte data dall’impossibilità di

inserire codice Lotus Script nell’html. � problematiche relative alla mancanza di totale compatibilità dei browser

attualmente più diffusi come Internet Explorer e Netscape Navigator. L’incompatibilità riguarda per la maggior parte l’html dinamico (DHTML) di cui oggi si comincia a fare gran uso.

Domino supporta le estensioni degli URL che espongono funzionalità al client Web.

Nella figura 3-1 viene visualizzata la sequenza delle operazioni precedentemente descritte che consentono a un generico browser Web di interagire con il server Web Domino.



Figura 3-1: processo d’iterazione tra il server Domino e il client

3.2.8 Come Domino gestisce gli URL

Domino utilizza gli URL per fornire l'accesso a server, database, e a tutti i componenti di

un'applicazione Web restituendone contenuto o il risultato all'utente che ha fatto la richiesta. La sintassi di un URL Domino è del seguente tipo: http://Host/NomeDatabase/OggettoDomino?Azione&Argomenti

dove: � Host rappresenta l'indirizzo IP o il DNS del sito in cui è installata l'applicazione; è

importante ricordarsi di configurare il DSN (Domino Server Name); � NomeDatabase è il nome del database Domino “.nsf”a cui si vuole accedere,

relativo alla directory notes\data o l’ID di replica del database stesso;

Server WebNavigator (R5.0)

SERVER DOMINO

CLIENT NOTES CLIENT NOTES

RICHIESTADOCUMENTO

RESTITUZIONE

DOCUMENTONOTES

RESTITUZIONEDOCUMENTO

NOTES

RICHIESTAPAGINA

CONVERTITOIN

PAGINAHTML



� OggettoDomino è un oggetto o elemento di base di Domino (una vista, un documento, un modulo, un navigatore, un'agente, una pagina ecc ... );

� Azione rappresenta l'operazione che si intende eseguire sullo specifico oggetto

Notes, per esempio ?OpenDatabase per aprire un database, ?OpenView per accedere ad una vista, ?OpenDocument e ?EditDocument per aprire un documento rispettivamente in lettura e in modifica, ?OpenForm, ?ReadForm, ecc…;

� Argomenti è un'informazione aggiuntiva specificata per un'azione richiesta a un

determinato oggetto Domino. Per esempio Count=10 unita all'azione ?OpenView limita a 10 il numero di righe visualizzate dal browser in una specifica vista.

3.2.9 Due parole sulla sicurezza: le ACL Associata a ogni database si trova una ACL (Access Control List) che specifica chi può

accedere a quel determinato database e cosa può fare su di esso. Chiunque acceda a un database può vederne l'ACL, ma solamente il gestore (manager) può modificarla. Tanto per averne un’idea la finestra di visualizzazione dell'ACL si presenta come nella figura 3-2.

Figura 3-2: finestra di visualizzazione ACL

Il campo di visualizzazione principale interno mostra tutti i nomi delle persone, server e

gruppi per i quali il manager del database ha specificato un tipo di accesso.



Selezionando una voce vengono visualizzati i permessi di accesso associati a quel nome. Come si nota, a sinistra del campo di visualizzazione principale appaiono dei checkbox che servono per meglio definire l'accesso.

Oltre ai nomi di singole persone, l’ACL può contenere anche i nomi di gruppi di persone, server o gruppi di server; ogni membro di un gruppo possiede gli stessi diritti. Se si vuole dare un privilegio diverso a una persona (o server) all'interno di un gruppo, lo si deve indicare, oltre che all’interno del gruppo, anche come entità singola. Infatti quando Notes deve decidere quali diritti applicare a un utente guarda per prima cosa se il suo nome appare come utente singolo; se non lo trova cerca all'interno dei gruppi.

I possibili livelli d’accesso ad un db sono sette: � Nessuno: l’utente non può accedere al database in nessun modo; � Composizione: l’utente può creare nuovi documenti all'interno del database ma

non può leggere nessun documento, nemmeno quelli creati da lui;

� Lettura: l’utente può leggere i documenti ma non crearne di nuovi o modificare quelli esistenti;

� Redazione: l’utente può creare nuovi documenti e leggere i documenti esistenti

ma può modificarli solamente se li ha creati;

� Revisione: ha gli stessi privilegi di Redazione, tranne il fatto che l’utente può modificare qualsiasi documento;

� Impostazione: ha gli stessi privilegi di Revisione, ma in più l’utente può

modificare il design (Moduli e Viste) del database;

� Gestione: l’utente è autorizzato ad eseguire qualsiasi operazione sul database e solo lui può cancellare il database. Ogni database deve avere almeno un gestore.

Ogni ACL ha inoltre un elemento di default; Notes applica i permessi a esso associati a chiunque non sia indicato esplicitamente. Due elementi predefiniti appaiono sempre in una ACL:

• il LocalDomainServers, il cui valore rappresenta il livello di accesso degli altri

server appartenenti al dominio locale; per i database che sono replicati su altri



server appartenenti al proprio dominio, questo elemento deve avere come minimo il valore di accesso Lettura;

• l'OtherDomainServers, il cui valore rappresenta il livello di accesso dei server al

di fuori del dominio locale; è normalmente settato a Nessuno, a meno che esistano dei database il cui accesso può avvenire anche da fuori.



3.3 Come sviluppare un’applicazione per Domino 3.3.1 Panoramica generale

Esistono varie tipologie d’approccio per sviluppare un’applicazione sotto Domino. La

prima distinzione a cui si può pensare è legata all’ambiente di esecuzione dell’applicazione stessa; possiamo infatti avere:

• applicazioni esterne che per mezzo di una particolare interfaccia si colleghino

con Domino • applicazioni interne: applicazioni che risiedano dentro il sistema e che vengano

eseguite dal sistema stesso. In entrambi i casi si devono utilizzare le Java Notes Object Interface (NOI) API, un set di

classi Java create da Lotus proprio per tale scopo. La strada più semplice per "entrare" in Domino dall’esterno è creare un’applicazione Java che utilizzi tali packages: in tal modo è possibile aprire i vari database, ed effettuare le classiche operazioni di lettura, scrittura, modifica. Questo tipo di operazione può significare sia la gestione di dati, ma anche del sistema stesso.

Un’applicazione interna invece si distingue per il fatto che viene eseguita dal sistema. Anche in questo caso abbiamo due tipologie di programmi: gli agenti, che agiscono direttamente nell’ambito di un database e qui spendono il loro ciclo di vita, oppure i servlet. In questo caso un servlet Domino è a tutti gli effetti un servlet standard derivante dalla HttpServlet del JDK 1.2 ed in esecuzione all’interno della JVM del web server di Domino.

La differenza fondamentale fra un servlet ed un agente è che quest’ultimo è un qualcosa che non può esser pensato al di fuori del database sul quale viene fatto lavorare: ad esempio possiamo pensare a un agente che esegua (ad intervalli regolari o su comando) operazioni di pulizia e di riordino del database stesso. Un servlet invece viene eseguito tutte le volte che se ne richiede l’esecuzione secondo il classico schema di esecuzione init()+doGet()/doPost(). Un servlet tipicamente viene utilizzato per estendere le funzionalità del web server andando a prelevare informazioni nei vari file nsf (i database di Domino).

3.3.2 Gli agenti Notes Gli Agenti Notes sono programmi il cui codice risiede internamente ad un database Notes

e che possono eseguire operazioni sullo stesso database che li ospita, o su un database differente. Il loro codice può essere costituito da una semplice azione oppure da veri e propri programmi



scritti indifferentemente in Java, Lotus Script, o utilizzando il linguaggio Notes delle cosiddette “formule”.

La loro esecuzione può essere invocata allo scatenarsi di un preciso evento come la pressione di un bottone, su comando di un utente, oppure allo scadere di un preciso istante temporale o ancora automaticamente ad intervalli di tempo prestabiliti (agenti schedulati). In qualunque modo vengano invocati, gli agenti vengono eseguiti dalla macchina che li ospita, o meglio dalla macchina che ospita il database in cui sono inseriti, e concludono in essa il loro ciclo di vita.

Normalmente gli agenti vengono utilizzati per eseguire operazioni automatizzate su database, ma si prestano benissimo anche per accedere processare e manipolare dati contenuti in altri servers o all’interno di altri database.

Lotus Designer mette a disposizione del programmatore un ambiente di sviluppo per gli agenti che permette la progettazione, la compilazione e il debugging direttamente all’interno del database in cui se ne vuole creare uno. E’ così possibile scegliere di scrivere codice Java utilizzando l’editor Notes oppure importare classi Java esterne, sia in formato sorgente, sia in formato bytecode java costituito dai classici files con estensione “.class”.

Ecco le caratteristiche che fanno degli agenti Domino strumenti molto potenti e versatili: � non sono vincolati a nessun elemento specifico del database in cui risiedono; � possono a loro volta invocare l’esecuzione di altri agenti; � possono essere distribuiti facilmente perché possono venir “replicati”; � possono essere personali o condivisi (shared agents).Un agente personale è creato

fatto eseguire da parte del medesimo utente; nessun altro è autorizzato ad utilizzarlo.Un agente condiviso è creato da un utente ma può essere fatto eseguire da altri;

L’ “Agent Manager” è quella parte di Domino che si occupa di tutto l’aspetto di

costruzione, esecuzione e problematiche riguardanti gli agenti. Esso controlla la sicurezza, gestisce l’invocazione degli agenti schedulati, monitorizza gli eventi che sono associati all’esecuzione di uno specifico agente, memorizza informazioni riguardanti gli agenti in un log detto “agent log”.

Sebbene lo sviluppatore non debba lavorare direttamente con l’ ”Agent Manager” deve comunque utilizzare i suoi componenti per poter costruire un agente. Nel caso si utilizzi Java per esempio, l’agente da costruire deve obbligatoriamente essere costituito da una classe Java che estende la classe Notes AgentBase e che usi al suo interno come punto di avvio (il tipico “main”) un metodo chiamato NotesMain().



Un tipico agente Notes quindi incomincia sempre con il codice seguente:

import lotus.domino.*;

public class JavaAgent extends AgentBase

{

public void NotesMain()

{

try {

Session session = getSession();

AgentContext agentContext = session.getAgentContext();

// (IL RESTO DEL CODICE VA QUI)

}

catch(Exception e)

{

e.printStackTrace();

}

}

}

il restante codice va inserito all’interno del costrutto try{} oppure in altre classi esterne.

L’importante è che l’esecuzione dell’agente parta dal metodo NotesMain().



Figura 3-3: ambiente di sviluppo Java per Agenti in Lotus Domino Designer

3.3.3 Invocazione remota di Agenti L’esecuzione di un Agente Notes può essere invocata da Web utilizzando un comune

browser di pagine html. E’ sufficiente digitare nell’apposito spazio riservato all’URL da caricare, una stringa simile a questa:

http://host/NomeDatabase.nsf/nomeAgente?OpenAgent[&parametro2=valore1&

parametro2=valore2….&parametroN=valoreN]

le parentesi quadre indicano l’opzionalità dei parametri successivi. La sintassi del comando è molto semplice: � si specifica l’indirizzo IP o il dominio di una certa macchina presente nella rete

( HOST ) � al suo interno si specifica il nome del database che contiene l’agente



� si specifica il nome dell’agente ( nomeAgente ) e l’azione da eseguire su di esso ?OpenAgent.

Gli eventuali parametri seguenti sono passati all’agente secondo il noto standard chiamato CGI (Common Gateway Interface).

Appena un po’ più complesso è il codice interno all’agente che permette di recuperare tali

parametri. Senza entrare in merito al codice Java utilizzato basti sapere che è necessario analizzare il contenuto della richiesta http inviata dal browser grazie ad alcuni metodi di facile utilizzo inclusi nel package Java lotus.domino.

3.3.4 Perché Java

Anche se ormai Java ha assunto una popolarità enorme, verrebbe da chiedersi come mai prodotti come Domino e Notes si appoggino così fortemente Java per la gestione e comunicazione verso l’esterno.

La riposta viene direttamente analizzando le principali caratteristiche del linguaggio. La portabilità di Java infatti si sposa perfettamente con la politica di IBM (la casa madre di Lotus) che fa della copertura globale delle varie piattaforme uno dei sui punti di forza. Dato infatti che sono disponibili versioni del prodotto per i più importanti sistemi operativi disponibili sul mercato, è possibile portare da una piattaforma ad una altra sia i database, sia, grazie alla portabilità di Java, i programmi (agenti, applicazioni, servlet).

La sicurezza che Java offre invece diviene quasi indispensabile se si pensa a come IBM si sia impegnata in tal senso.

La facilità poi con cui in Java sia possibile interfacciarsi con il mondo delle reti risulta essere un punto a favore per l’impiego in un prodotto fortemente orientato al lavoro di gruppo network-based.

Il fatto infine che Java sia un linguaggio conosciuto da molti permette una facile integrazione di coloro che inizialmente possono avere una ridotta conoscenza del sistema, ma hanno una buona familiarità con Java.

Si deve comunque dire che sebbene Java rappresenti la strada più semplice per la programmazione in Domino, esiste l’alternativa del LotusScript (che pero’ offre poche possibilità in confronto a Java), oltre alla possibilità di interfacciarsi tramite CORBA, ad un mondo composto da un numero praticamente infinito di opzioni e possibili alternative.



3.3.5 Un’alternativa efficace: CORBA L'acronimo CORBA sta per Common Object Request Broker Architecture. Il cuore della

specifica CORBA, o meglio il principale obiettivo che questa specifica si pone, è quello di stabilire una serie di regole standard per la realizzazione di una architettura per oggetti distribuiti. Al centro di questa architettura si trova l'idea di un ORB (Object Request Broker), ovvero la realizzazione di un bus software attraverso il quale possano scorrere i messaggi che gli oggetti distribuiti si scambiano tra loro. Un'implementazione reale di un ORB è lasciata all'abilità di produttori di software, come ad esempio Inprise e IONA.

L’OMG (Object Management Group), l'organismo che controlla lo standard CORBA, ha realizzato un protocollo al fine di stabilire l'interoperabilità tra ORB differenti. Questo protocollo si chiama GIOP (General Inter-ORB Protocol), e definisce il formato dei messaggi e la rappresentazione dei dati per tutte le comunicazioni tra oggetti distribuiti su uno stesso ORB, o su ORB di produttori differenti. Il protocollo GIOP si appoggia a sua volta ad un qualunque protocollo di trasporto purchè orientato alla connessione, per portare a destinazione i suoi messaggi. Una particolare implementazione del protocollo GIOP chiamata IIOP (Internet Inter-ORB Protocol), si avvale del protocollo TCP/IP per la realizzazione dello strato di trasporto dei messaggi tra oggetti remoti.

L' ORB ha quindi un duplice scopo: � Veicolare tramite un protocollo standard le invocazioni dei metodi dell' oggetto di

rete dal client verso l' object-server e viceversa; � Nascondere al client l' allocazione sulla macchine fisica dei processi server.

Esistono quindi in CORBA sempre due ruoli protocollari ben definiti: client e server di

oggetti. Questo non vuol dire però che uno stesso processo non possa essere client di uno o più server ed essere contemporaneamente server per altri oggetti, anzi questa é la norma per sistemi anche di non grandi dimensioni.

Figura 3-4: Object Request Broker



IDL: Interface Definition Language IDL é il linguaggio che permette di definire i metodi e gli attributi degli oggetti

distribuiti. La loro descrizione viene denominata "interfaccia". IDL è indipendente dallo specifico linguaggio di codifica utilizzato ed indipendente dal

sistema operativo/architettura della CPU degli host su cui i client o i server sono in esecuzione. IDL non specifica implementazioni dell'oggetto e supporta l'ereditarietá multipla delle interfacce.

L' OMG ha specificato le regole per mappare nei vari linguaggi il linguaggio IDL, tra di essi c'è lo SmallTalk, il C, il C++, ADA, Java e persino l’anziano COBOL. Le implementazioni di CORBA posseggono un “compilatore” IDL che traduce l’ interfaccia in codice del linguaggio prescelto (tra quelli disponibili) nel caso di Java classi ed interfacce.

Da quanto detto si evince che:

• i processi client/server possono stare su qualunque macchina in rete. • possono essere scritti in uno dei linguaggi supporati da IDL • le macchine possono avere architettura differente.



3.3.6 R5 e CORBA La grande rivoluzione della release 5 di Domino (d'ora in poi R5) è rappresentata

dall'introduzione di CORBA per l'accesso ai dati. L'implementazione di un ORB (Object Request Broker) all'interno del motore della R5

infatti, ha cambiato radicalmente la modalità di accesso ai database Domino: non occorre più un Notes client per interagire direttamente con il server ma è sufficiente un'applet in grado di parlare IIOP. In particolare, insieme alla R5 vengono distribuiti alcuni file JAR che consentono di accedere agli oggetti Notes (documenti, viste, lista degli accessi, ecc.) via Java. Tra questi troviamo i file NCSO.JAR e NCSOC.JAR che contengono l'implementazione delle classi CORBA a lato client. Questo consente due cose: creare applet o applicazioni Java in grado di accedere agli oggetti Domino attraverso IIOP.

L'applet, tramite le classi CORBA, potrà avere accesso alla Notes Object Interface (NOI) e colloquiare direttamente con il server per visualizzare il contenuto di viste, documenti, ecc.)

Figura 3-5: schema del modello CORBA

Un'applicazione Java consentirà a computer privi del Notes Client di accedere agli stessi

dati semplicemente aggiungendo NCSO.JAR e NOTES.JAR al CLASSPATH. Ovviamente questi accessi saranno regolati dalle rigorose politiche di accesso dei server Domino.

Alcune note per l'installazione dell'ambiente.; per consentire all'applet di interagire con l'ORB implementato nella R5, occorre fare tre cose, entrambe importanti:

� avviare l'ORB � consentire le connessioni IIOP



� includere le classi CORBA nell'applet attraverso il Designer (quest’ultimo punto ha pesato notevolmente nella scelta della tecnologia (vedere capitolo 5, paragrafo 2).

3.4 I files di log 3.4.1 Cosa sono i files di log

Quando si naviga in Internet non si fa altro che richiedere un servizio ad una macchina

server remota: l’invio di alcuni files sulla nostra macchina client. Questi files possono essere di vario genere e dimensione, tipicamente si tratta di files di testo contenenti il codice HTML della pagina richiesta, ma anche immagini, suoni, codice Java, ed altro ancora.

Perché si possa instaurare questo tipo di servizio occorrono, oltre alle due macchine ed ai dispositivi fisici che le mettano in contatto tra di loro, un protocollo di comunicazione comune e del software specifico a seconda del ruolo assunto da ogni macchina. Nel caso di nostro interesse, il protocollo comune utilizzato è l’HTTP ed il servizio erogato dal server si chiama appunto servizio di “http server” o “web server”. Il software normalmente utilizzato su una macchina client è un browser di pagine html, mentre sul server deve girare un programma di http server. Ve ne sono diversi in commercio, per ogni tipo di piattaforma. Due nomi per tutti: “Internet Information Server” della Microsoft e Domino della Lotus. Questi programmi restano in ascolto su una determinata porta (normalmente la 8080 per i servizi di http), pronti ad esaudire le richieste dei numerosi client che ad essa si connettono.

Quando un client richiede l’invio di un determinato file residente sulla macchina server, quest’ultima, oltre ad inviarglielo se ne ha facoltà e se l’utente è autorizzato ad accedervi, tiene memoria della richiesta fattagli memorizzando alcune informazioni sottoforma di files nel proprio file system. Questi files sono appunto detti “files di log” o “log files” e contengono numerosi dati riguardanti le richieste fatte al Web server, come:

� data e ora in cui è stata fatta � il nome e il tipo del file richiesto � l’indirizzo IP della macchina che ne ha fatto richiesta e/o il nome dell’utente � il codice d’errore che specifica se la richiesta è stata esaudita o, se non è stata

soddisfatta, il perché � il tipo di browser utilizzato dall’utente � il sistema operativo installato nella macchina client

Esistono diversi standard riguardanti i formati in cui vengono creati i files di log. Microsoft Internet information Server ad esempio crea dei files di testo con estensione “.log”. In essi ogni richiesta effettuata è rappresentata da una riga all’interno della quale le diverse



informazioni sono separate da una “,” secondo una semantica precisa. Ecco un esempio di file di log di Microsoft Internet Information Server:

Figura 3-6: un file di log di Internet Information Server

3.4.2 Domino e i files di log Esattamente in linea con la filosofia di Domino che “vede” tutto come documenti

contenuti in database, anche i files di log sono in realtà dei documenti contenuti in un database. Ogni singola richiesta effettuata al web server di Domino viene automaticamente memorizzata in un database sottoforma di entry, in cui poi ciascuna singola informazione viene memorizzata in un campo dal nome e tipo specifico.

Ad esempio, nella versione Inglese di Domino l’informazione relativa alla data della richiesta è memorizzata in un campo di tipo data e dal nome “Date”, mentre l’indirizzo IP dell’utente è contenuta in un campo di tipo testo denominato “UserAddress”. Attraverso le viste è possibile poi visualizzare e selezionare le singole entries.

Per questo tipo di database esistono delle viste già preparate in automatico e pronte all’uso come quella denominata “Requests”, ma l’utente può crearne di nuove a piacimento. Su queste viste si possono eseguire delle query in sql o utilizzando apposite API Java.

Ecco come appaiono nella vista “Requests” le singole entries relative ai log:



Figura 3-7: contenuto della vista “Requests”

Va detto che ciascuna colonna della vista di figura 3-7 rappresenta un determinato

campo, ma il nome che porta la colonna non è necessariamente il nome del campo. Ad esempio la colonna di nome “Address” visualizza le entries del campo “UserAddress”. Si veda la figura seguente per comprendere meglio.

nomi

entry selezionatavista selezionata

Nomi delle colonne

xxxxxxxxxxxxxxx

Nomi dei campi Valori dei campi



Figura 3-8: esempio di log entry in Domino

La figura 3-8 è un esempio di come appare la singola log entry selezionata in figura 3-7. Domino offre molte possibilità di personalizzazione dei database dei log; è possibile ad

esempio escludere dalla memorizzazione le richieste relative a files di un particolare tipo come le immagini o altro.

SCELTA DELLE TECNOLOGIE - Capitolo 4


4 SCELTA DELLE TECNOLOGIE

Verranno illustrate in questo capitolo le principali tecnologie impiegate per lo sviluppo

del software. Le motivazioni che hanno portato alla scelta delle seguenti tecnologie, e la collocazione delle stesse all’interno del progetto saranno invece oggetto di discussione nel capitolo 5 “REALIZZAZIONE”.

4.1 Infobus

4.1.1 cos’e l’InfoBus e come funziona InfoBus è una tecnologia sviluppata da Sun Microsystems e Lotus che consente lo

scambio dinamico di dati tra componenti Java. InfoBus intende fornire degli standards tramite i quali un grande numero di componenti Java possono scambiarsi dati (dai produttori dei dati ai consumatori), e lo fa definendo un set di interfacce che tali componenti dovranno poi implementare.

La metafora adottata da InfoBus è appunto quella del bus dati: i componenti si collegano al bus sul quale vengono immessi e prelevati i dati. (Figura 4-1).

Capitolo 4 - SCELTA DELLE TECNOLOGIE


Figura 4-1: modello di funzionamento per l’InfoBus

I tipi di dati che è possibile scambiare tramite InfoBus vanno dalle semplici stringhe e valori numerici a dati più complessi come liste, array e tabelle.

La tecnologia InfoBus è simile al Dynamic Data Exchange (DDE) di Microsoft, ma con alcune rilevanti differenze. In primo luogo il meccanismo di scambio di dati tra i componenti avviene tramite una infrastruttura neutrale (InfoBus) e non tramite uno scambio di eventi e risposte (callback) specifici delle applicazioni cooperanti, come avviene per il DDE. Questo aspetto insieme al fatto che i riferimenti ai dati che “viaggiano” sul bus vengono fatti per nome, rende l’interazione tra i componenti Java veramente indipendente. Infatti un “consumatore di dati” non ha bisogno di conoscere chi è il “produttore di dati” che gli fornirà i dati; esso rimarrà in attesa che sull’InfoBus arrivi un dato che ha un determinato nome, ad esempio “QueryResult”, senza preoccuparsi di stabilire un collegamento diretto con il componente che ha immesso il dato sul bus. Il vantaggio per gli sviluppatori Java è evidente; non è più necessario definire un protocollo specifico per lo scambio di dati tra i componenti di un’applicazione, con tutte le conseguenze che questo comporta (codice aggiuntivo, performance, compatibilità con altri componenti), ma è sufficiente che i componenti utilizzino la tecnologia InfoBus. Attualmente InfoBus consente la comunicazione tra oggetti presenti sulla stessa macchina virtuale (JVM). Essa non consente lo scambio di dati tra componenti che si trovano su macchine virtuali diverse, ad esempio tra un JavaBean che gira su un server e uno che gira su un client. Al momento è allo stadio di prototipo una versione distribuita di InfoBus (Distributed InfoBus): questa tecnologia aggiunge un proxy di rete all’InfoBus locale che rileva eventi e dati sulla rete.

4.1.2 Tipi di componenti Diversamente dal modello ad eventi in cui l’interazione dipende dalla comprensione di

eventi specifici dei vari componenti, InfoBus mette a disposizione dei meccanismi standard comprensibili da tutti i componenti che supportano questa tecnologia.

I componenti che costituiscono un’applicazione basata su InfoBus possono essere classificati in tre categorie:

Data producer (produttori di dati): sono i componenti che forniscono i dati

richiesti dai data consumer; in genere questi componenti prelevano i dati da un database, da un foglio di calcolo o da una qualsiasi altra fonte di dati e li rendono disponibili sull’InfoBus;



Data consumer (consumatori di dati): sono i componenti che richiedono informazioni; questi componenti recuperano i dati dal bus per poterli elaborare o visualizzare;

Data controller (controllori di dati): sono componenti speciali che regolano o

redirigono il flusso di dati tra data producer e data consumer. Un componente può essere al tempo stesso data producer e data consumer. Questa

separazione di ruoli tra produttori e consumatori di dati consente alle applicazioni di essere indipendenti dai dati stessi. Ad esempio, un applet o un JavaBean per la visualizzazione di un grafico non ha bisogno di utilizzare SQL o JDBC per accedere ai dati di un DBMS; esso richiede i dati di cui ha bisogno e sarà un componente specializzato a fornirglieli tramite l’InfoBus. I dati “viaggiano” sull’InfoBus in oggetti a cui viene associato un nome e che vengono classificati come data items.

4.1.3 Il protocollo InfoBus per lo scambio dei dati

L’interazione tra i componenti per mezzo di InfoBus avviene tramite quattro attività: 1) registrazione (membership): con questa attività un qualsiasi componente Java si

connette all’InfoBus ottenendo un identificatore univoco che lo qualifica come membro dell’InfoBus;

2) attesa degli eventi: i membri ricevono dal bus notifiche diverse in base al proprio

ruolo: i data producer riceveranno richieste di dati mentre i data consumer riceveranno notifiche di disponibilità dei dati richiesti;

3) rendez-vous per lo scambio di dati: i data producers comunicano la disponibilità

dei dati richiesti mentre i data consumer richiedono i dati di cui hanno bisogno; 4) recupero dei dati: i vari data producer gestiscono diversi tipi di dati mentre un

determinato data consumer può avere necessità di acquisire i dati secondo le proprie necessità; InfoBus definisce una serie di interfacce per l’accesso sia a dati semplici, come ad esempio stringhe e valori numerici, che a dati strutturati secondo varie tipologie (array, liste, tabelle, ecc.); in ogni caso il meccanismo di riferimento ai dati avviene per nome.



Scendendo un po’ più in dettaglio nelle varie attività:

Passo 1. Partecipazione (Membership) — Stabilire la partecipazione ad un InfoBus dei componenti

Ogni componente Java può collegarsi ad un InfoBus. Questo è realizzato implementando l'interfaccia InfoBusMember, ottenendo un'istanza InfoBus, e unendosi (join) a tale istanza.

Passo 2. Ascoltare gli eventi riguardanti l'InfoBus

Una volta che l'oggetto è un elemento di un Infobus, esso riceverà notifiche del bus. Due interfacce ascoltatrici di eventi sono state create per supportare le due tipologie di

applicazioni InfoBus. Il consumatore riceve la notifica della disponibilità dei dati, mentre il produttore riceve la richiesta del dato.

Queste interfacce sono: InfoBusDataConsumer e InfoBusDataProducer Entrambe estensioni dell'interfaccia InfoBusEventListener Inoltre esiste anche DataItemChangeListener che gestisce il cambiamento del dato;

vengono usate anche le liste ascoltatrici: PropertyChangeListener e VetoableChangeListener

Passo 3. Appuntamento per il dato da trasmettere

Nel modello InfoBus il produttore annuncia la disponibilità del nuovo dato appena il dato è pronto (per esempio dopo il completamento della lettura di un URL, il completamento di un calcolo ecc.)

I consumatori richiedono i dati al produttore al verificarsi di particolare condizioni (inizializzazione dell'applet, evento collegato al bottone, ecc.). L'appuntamento è stabilito tramite il nome del dato.

Quindi tutti i produttori e consumatori devono fornire dei meccanismi nell'applicazione che possano specificare i nomi dei dati per l'appuntamento. Per esempio in un componente consistente in un foglio elettronico, l'utente può dare un nome agli intervalli nel foglio.



Questo nome è un naturale meccanismo per il riconoscimento dei dati che possono essere esportati dal foglio che assume il ruolo di produttore.



Passo 4. Navigazione dei dati strutturati Differenti produttori spesso usano rappresentazioni dei dati che sono solo

superficialmente simili. Per esempio un foglio elettronico e un database ambedue lavorano con le tabelle, ma

spesso memorizzano i dati in modo abbastanza differente. In un foglio elettronico, la tabella dei dati potrebbe essere rappresentata come un output

di un calcolo (come una matrice invertita), o come una matrice di formule, laddove in un database la stessa informazione potrebbe essere rappresentata come per esempio il risultato di una query join.

Un consumatore non ha bisogno di capire dettagliatamente la rappresentazione interna del dato preparato dal produttore.

Un componente che gestisce dati dovrebbe poter disegnare un grafico a partire da una tabella indipendentemente se questa è il risultato di un foglio elettronico o di un database.

In pratica questa condivisione di informazioni tra produttori e consumatori richiedono una comune codifica dei dati.

Sono quindi state disegnate una serie di interfacce per vari protocolli standard che sono usati per creare elementi di dati con comuni accessi.

Passo 5. Ricerca della codifica per il valore del dato

Un elemento di dato può essere restituito come una String o come un oggetto Java. Gli oggetti Java sono tipicamente classi che corrispondono ai vari tipi primitivi (per

esempio Double che corrisponde al tipo primitivo double), oppure sono istanze di classi viste come collezioni di dati (array). L'obiettivo è la richiesta di specializzati e comprensibili formati dei dati da parte del consumatore.

Per questo viene utilizzata l'interfaccia DataItem che fornisce informazioni sul dato e sui suoi DataFlavor, e l'interfaccia ImmediateAccess che fornisce informazione dirette su dati semplici trattando solo il formato String e Object.

Passo 6. Opzionale: La modifica del valore del dato

Un consumatore può cercare di cambiare il valore del dato. Il produttore impone una politica su chi voglia cambiare il dato. Con il JDK 1.2, esso può

anche gestire permessi per i vari consumatori. La classe che gestisce tale operazione è DefaultPolicy che implementa l'interfaccia

InfoBusPolicyHelper.



4.1.4 Descrizione package javax.infobus

INTERFACCE:

ArrayAccess DataItem Questa interfaccia fornisce informazioni di identificazione e di descrizione del dato da trasmettere.

I produttori implementano sempre questa interfaccia.

DataItemChangeListener Gestori di dati possono implementare opzionalmente DataItemChangeListener in modo da potersi registrare alla lista tramite i metodi contenuti nell'interfaccia DateItemChangeManager.

Una classe che implementa DataItemChangeManager spedisce le notifiche del cambiamento del valore attraverso l'evento DataItemChangeEvents.

DataItemChangeManager Questa interfaccia permette di registrarsi e di rimuovere la registrazione dalla lista ascoltatrice DataItemChangeListener

DbAccess Gestisce i dati provenienti da un data base

ImmediateAccess Restituisce il dato semplice, non tratta quindi le collezioni di dati, e offre dei metodi per estrarre e per impostare il dato in formato String o Object.

InfoBusDataConsumer Viene implementata dai consumatori, ed è la lista ascoltatrice che gestisce gli eventi di disponibilità e di revoca della disponibilità del dato, notificati dal produttore.

InfoBusDataController Personalizzazioni alle implementazioni di InfoBusDataController possono essere aggiunte per ottimizzare la distribuzione dell'evento InfoBusEvent gestito da InfoBusDataProducer e

InfoBusDataConsumer. Viene utilizzata dalle classi che fungono da mediatori tra produttori e consumatori.

InfoBusDataProducer Viene implementata dai produttori, ed è la lista ascoltatrice che gestisce l'evento di richiesta del dato, notificato dal consumatore.

InfoBusEventListener E' l'interfaccia comune di InfoBusDataConsumer e InfoBusDataProducer

InfoBusMember E' necessario implementare questa interfaccia per poter



gestire una proprietà con condizioni chiamata infoBus . Intorno a questa proprietà gira tutto il presente package.

InfoBusPolicyHelper Interfaccia che pone un insieme di regole da adottare in caso di cambiamento del dato da parte dei consumatori.

InfoBusPropertyMap Interfaccia temporanea adottata per fornire un meccanismo per l'uso dei componenti InfoBus 1.1 che desiderino fornire proprietà nell'evento DataItemChangeEvents.

Fornisce il solo metodo get(Object key) che ritorna l'oggetto corrispondente allo specifico nome della proprietà key.

RowsetAccess Metodi di supporto per la gestione delle righe di tabelle DB

ScrollableRowsetAccess Metodi di supporto per la gestione delle righe di tabelle DB

CLASSI:

DataItemAddedEvent Evento che si verifica quando un elemento viene aggiunto ad una collezione di dati.

DataItemChangeEvent Evento che si verifica quando avviene un cambiamento del dato.

DataItemChangeSupport Classe di supporto per la gestione degli eventi che gestiscono il cambiamento dei dati.

DataItemDeletedEvent Evento che si verifica quando un elemento viene cancellato da una collezione di dati.

DataItemRevokedEvent Evento che viene notificato dal produttore quando il dato non è più disponibile.

DataItemValueChangedEvent Evento che si verifica quando avviene un cambiamento nel valore del dato. E' una sottoclasse di DataItemChangeEvent

DefaultPolicy Classe per la gestione della sicurezza in caso di cambiamento del dato da parte dei consumatori.

Questa classe implementa l'interfaccia InfoBusPolicyHelper

InfoBus Un oggetto InfoBus detiene una lista di InfoBusMember e abilita la comunicazione tra le classi che implementano



gli InfoBusMember.

InfoBusEvent Evento di base per la gestione di una comunicazione InfoBus. Viene gestito dalla lista ascoltatrice InfoBusEventListener

In genere questo evento non viene utilizzato, perché vengono utilizzate le sue sottoclassi specializzate (InfoBusItemAvailableEvent, InfoBusItemRevokedEvent, InfoBusItemRequestedEvent)

InfoBusItemAvailableEvent Evento che notifica la disponibilità di un dato. Spedito dal produttore ad uso dei consumatori registrati alla lista ascoltatrice InfoBusEventListener.

InfoBusItemRequestedEvent Evento che notifica la richiesta di un dato. Spedito dal consumatore ad uso dei produttori registrati alla lista ascoltatrice InfoBusEventListener.

InfoBusItemRevokedEvent Evento che notifica la revoca della disponibilità di un dato. Spedito dal produttore ad uso dei consumatori registrati alla lista ascoltatrice InfoBusEventListener.

InfoBusMemberSupport Questa classe implementa l'interfaccia InfoBusMember e serve a gestire le funzionalità del protocollo InfoBus protocol. Incapsula luna proprietà InfoBus e gli oggetti PropertyChangeSupport e VetoableChangeSupport dato che tale proprietà è bound e soggetta a condizione.

RowsetCursorMovedEvent Descrive un cambiamento di valore in un elemento che può anche essere una collezione.

ECCEZIONI:

ColumnNotFoundException Usata per la gestione dei DB, viene sollevata nel caso in cui la colonna non viene trovata.

DuplicateColumnException Usata per la gestione dei DB, viene sollevata nel caso in cui si tenta di inserire una colonna già presente.

InfoBusMembershipException Viene sollevata quando si tenta di fare una join su di un InfoBus ormai molto vecchio oppure quando non si ha il permesso di fare la join.

InvalidDataException Viene sollevata da un DataItem quando si cerca di cambiarne il valore con un formato illegale.

RowsetValidationException Usata per la gestione dei DB, viene sollevata nel caso in cui la modifica di un valore fallisce per qualche ragione.



UnsupportedOperationException Può essere sollevata se il partecipante all'Infobus non supporta il metodo chiamato

4.2 Live Connect La tecnologia LiveConnect è un meccanismo di comunicazione introdotto dalla Netscape

(sin dalla versione 3.0 del relativo browser Web) che consente:

• ai programmi JavaScript di comunicare con le applet Java contenute all'interno di un documento HTML;

• alle applet Java di richiamare funzioni JavaScript; • alle applet Java di comunicare con altre applet Java.

Verranno ora descritte quali siano le potenzialità della tecnologia LiveConnect e in

particolare verrà spiegato:

• come utilizzare JavaScript per accedere alle variabili, ai metodi, alle classi di un'applet Java;

• come scrivere codice Java per accedere ai metodi e alle proprietà di JavaScript.

4.2.1 Comunicazionce tra JavaScript e Java La tecnologia LiveConnect offre tre possibili strategie per consentire a JavaScript di

comunicare con Java: 1) richiamare i metodi di Java direttamente; 2) controllare le applet Java; 3) controllare i plugins Java; Nella figura 4-2 viene rappresentata graficamente l'idea che sta alla base della tecnologia

LiveConnect.



Figura 4-2: la tecnologia LiveConnect

Richiamare direttamente i metodi di Java: Quando la tecnologia LiveConnect è abilitata nel browser, javaScript può richiamare in

modo diretto tutti i metodi delle classi Java. Per esempio, è possibile richiamare il metodo “System.out.println” per visualizzare nella console Java dei generici messaggi.

In JavaScript le classi sono rese disponibili all'interno del pacchetto Packages, che contiene una collezione di classi Java e di metodi richiamabili da JavaScript tramite il loro nome, nel seguente modo:

[Packages.]packageName.className.methodName Il nome [Packages] è opzionale sia per Java, sia per Sun e Netscape; di fatto nella

scrittura del codice Java, Sun e Netscape risultano alias per Packages.java, Packages.sun e Packages.netscape. E’ possibile referenziare la classe Java “java.lang.System” sia come “Packages.java.lang.System” sia come “java.lang.System”.

Per accedere alle variabili e ai metodi di una classe Java è sufficiente richiamarle allo stesso modo in cui vengono utilizzate in un programma Java. Per esempio il codice JavaScript per scrivere un messaggio nella console Java si presenta nella forma:

var Sistema = java.lang.System

Sistema.err.println(“Messaggio inserito da JavaScript”)

La prima riga consente a JavaScript di istanziare la variabile Sistema alla classe Java

“java.lang.System”. La seconda riga invoca invece il metodo “println” della variabile statica “err” nella classe System.

applet JavaScr ipt plugins

applet plugins Tecnologia LiveConnect

Connessione java diretta



Dato che il metodo "println" si aspetta dei parametri d'ingresso come argomenti della classe “java.lang.String”, la stringa JavaScript viene automaticamente convertita in un oggetto della classe “java.lang.String”.

In questo modo è quindi possibile utilizzare tutti i costruttori delle classi Java nei programmi JavaScript. Il seguente codice JavaScript crea un oggetto “Data” e ne stampa il contenuto nella console Java.

var Data = new java.util.Date()

System.out. println(Data)



Controllare le applet Java: Un'altra caratteristica della tecnologia LiveConnect è la possibilità di utilizzare JavaScript

per controllare il comportamento di un'applet Java senza conoscerne il codice ma solamente i metodi e le proprietà esportati.

Infatti tutte le variabili, i metodi, e le proprietà definite pubbliche di un'applet sono disponibili per l'accesso tramite JavaScript. Per esempio, è possibile creare un bottone e associarvi all'evento “onClick” i metodi start() e stop() di un'applet Java che naturalmente sia contenuta all'interno del documento HTML.

Per riferirsi a un'applet all'interno di un documento HTML mediante JavaScript è possibile utilizzare più metodi:

� document.NomeApplet; � document.applets[NomeApplet]; � document.applets[index];

dove “NomeApplet” rappresenta il valore dell'attributo NAME del tag <APPLET> ,

mentre “index” è l'indice del vettore delle applet contenute nel documento Web: tale indice parte dal valore zero e viene assegnato alle applet della pagina in ordine crescente e di comparsa.

Per esempio, consideriamo l'applet standard fornito dalla Sun “Hello World”:

import java.applet.Applet;

import java.awt.Graphics;

public class HelloWorld extends Applet

{

public void paint(Graphics g)

{

g.drawString(“Hello world!”, 50, 25);

}

}

Questa applet viene inserita all'interno di un documento HTML mediante il tag

<APPLET> nel seguente modo:

<APPLET CODE = “He11oWor1d.class” NAME = “HelloWorld” WIDTH = 150

HEIGHT = 25 > </APPLET>



Se l'applet è la prima del documento (partendo dall'inizio della pagina), sarà possibile riferirsi a essa tramite codice JavaScript nei seguenti modi:

� document.HelloWorld; � document.applets[“HelloWorld”]; � document.applets[0].

E’ importante ricordarsi che solamente i metodi, le variabili e le proprietà dichiarate come pubbliche o statiche all'interno di un'applet possono essere utilizzate dal codice JavaScript. E’ possibile quindi impostare e leggere le variabili di un'applet, richiamare metodi e utilizzare il valore che esse restituiscono come stringhe, numeri e valori booleani.

Di seguito viene esaminato nei dettagli l'esempio “Hello World” precedentemente introdotto.

Esempio: Hello World Tramite JavaScript è possibile modificare una generica applet Java nel seguenti modi: � sovrascrivendone i metodi, per esempio il metodo “Init()” in cui viene

inizializzata la variabile "myString"; � definendo nuovi metodi che accettino valori d'ingresso: per esempio alla variabile

“myString” può essere assegnata una stringa; inoltre richiamando altri metodi dell'applet, quale il metodo repaint (i metodi paint e repaint sono ereditati dal classe java.awt.Component).

Trasformando l'applet dell'esempio come di seguito

import java.applet.Applet;

import java.awt.Graphics;

public class HelloWorld extends Applet

{ String myString;

public void init()

{ myString = new String(“Hello, world!”);

}




{ g.drawString(myString, 25, 20);

}

public void setString(String aString)

{ myString = aString;

repaint();

}

sarà quindi possibile far visualizzare il messaggio dall'applet dinamica semplicemente

utilizzando codice JavaScript unito a codice HTML del documento.

< APPLET CODE = “HelloWorld.class” NAME = “Hello” >

</APPLET>

< FORM NAME=”form” >

< INPUT TYPE="button" VALUE=”Modifica il testo”

onClick=”document.HelloWorld.setString(document.form.Valore.value)”>

<BR>

< INPUT TYPE=“text” SIZE=”20” NAME=”Valore” >

</FORM>

Quando l'utente aprirà per la prima volta la pagina HTML l'applet HelloWorld

inizializzerà il valore del testo visualizzato con “Hello, World!”. A questo punto scrivendo un generico testo nel campo “Valore” sarà possibile modificare il testo visualizzato dall'applet semplicemente premendo il pulsante “Modifica il testo” (figura 4-3).



Figura 4-3: esempio d’uso d’iterazione JavaScript verso java mediante LiveConnect

Questo semplice esempio dimostra le infinite potenzialità della tecnologia LiveConnect come strumento d'interazione di una pagina HTML con un'appletJava inserita al suo interno.

Conversione dei tipi da JavaScript a Java: Nell'utilizzo della tecnologia LiveConnect è importante discutere della conversione dei

tipi di dati passati da JavaScript a Java dato che il non tenerne in considerazione potrebbe causare notevoli problemi allo sviluppatore. I tipi di dati supportati e la loro conversione possono essere così raggruppati:

• le stringhe, i numeri e i dati booleani sono convertiti da Java rispettivamente negli oggetti

String, Float e Boolean; • gli oggetti nativi Java vengono riconvertiti nel loro formato originale; • tutti i restanti oggetti sono incapsulati nell'oggetto JSObject;

Questo significa che tutti i dati JavaScript vengono trasformati, in oggetti della classe

Java “java.lang.Object” e dunque per utilizzarli sarà necessario convertirne il valore nell'appropriata sottoclasse mediante casting, per esempio:

(String) window.getMember("name"); (JSObject) window.getMember("document");.



4.2.2 Comunicazione tra Java e JavaScript

Per accedere al metodi, alle proprietà e ai dati di JavaScript da una propria applet Java è

necessario importare il pacchetto JavaScript di Netscape:

import netscape.javascript.*;

Questo pacchetto (package) “netscape.javascript” definisce la classe JSObject e gli

oggetti JSException che ne gestiscono le eccezioni. Lo sviluppatore di pagine HTML deve inoltre consentire all'applet di poter accedere a

JavaScript specificandone l'attributo MAYSCRIPT nel tag <APPLET>. Questo è dettato da motivi di sicurezza, volti a prevenire l'utilizzo improprio del codice

JavaScript senza l'autorizzazioni dell'autore del documento Web. L'accesso da parte di un'applet al codice JavaScript senza diritti genera un'eccezione in

fase di esecuzione dell'applet. Il tag MAYSCRIPT è necessario solamente per consentire l'accesso da parte dell'applet a codice JavaScript della pagina HTML, e non viceversa.

Come ottenere il riferimento a JavaScript: Prima di accedere agli oggetti di JavaScript è necessario ottenere l'identificativo (handle)

della finestra del browser; per farlo si utilizza il metodo “getWindow” presente nella classe “netscape.javascript.JSObject”, passando come parametro l'applet.

Per esempio, se Window è una variabile precedentemente dichiarata del tipo JSObject, il codice per assegnarvi l'identificativo della finestra del Navigatore risulta:

public class myApplet extends Applet

{ public void init()

{ JSObject window = JSObject.getWindow(this);

}

}

Accesso agli oggetti e alle proprietà di JavaScript: Una volta ottenuto l'identificativo della pagina HTML, per accedere alle proprietà e agli

oggetti di JavaScript si utilizza il metodo “getMember” della classe “netscape.javascript.JSObject”. Per esempio, il seguente codice Java consente di accedere all'oggetto "document.FormDiProva" tramite la variabile FormProva:



public void init()

{ window=JSObject.getWindow(this);

FormProva = window.eval (“document.FormDiProva”)

}

Invece il seguente codice consente l'accesso all'oggetto checkbox presente nel modulo

FormDiProva per controllarne il valore:

public void init()

{ win=JSObject.getWindow(this);

JSObject doc = (JSObject) win.getMember(“document”);

JSObject FormProva = (JSObject) doc.getMember(“FormDiProva”);

JSObject check = (JSObject) myForm.getMember(“NomeDelCheckBox”);

Boolean isChecked = (Boolean) check.getMember(“checked”);

Come richiamare i metodi di JavaScript Per richiamare i metodi definiti in JavaScript si utilizza il metodo “eval” presente nella

classe “netscape.javascript.JSObject”. Questo metodo consente all'applet Java di eseguire una funzione JavaScript nella pagina HTML contenuta dal browser. Per utilizzare il metodo “eval” è necessario avere, come nei precedenti casi, l'identificativo (handle) della finestra del browser.

La sintassi del comando “eval” è la seguente:

JSObject.getWindow().eval(“espressione”)

Dove espressione è un'istruzione JavaScript che si riferisce alla chiamata di un metodo. Nel seguente esempio viene richiamato il metodo “alert” definito sull'evento di rilascio

del mouse (MouseUp) per visualizzare un messaggio nel browser:

public void init()

{ JSObject window = JSObject.getWindow(this);

}

public boolean mouseUp(Event e, int x, int y)

{ window.eval(“alert(\” Pulsante destro de mouse rilasciato !\”);”);

return true;

}



Un'altra tecnica per richiamare metodi e funzioni JavaScript utilizza il metodo “call”

dell'oggetto JSObject. La sintassi di questo metodo è la seguente:

JSObject.call (“NomeMetodo”, argArray)

Dove NomeMetodo è il metodo JavaScript da richiamare e argArray è un vettore di

oggetti Java utilizzato per passare dei parametri al metodo JavaScript. Nota: se si desidera passare un dato primitivo a un metodo JavaScript, è necessario

utilizzare i tipi di dati incapsulati (wrapped), quali gli interi, le stringhe e i booleani.



Esempio: Hello World Viene modificato ora il metodo paint dell'esempio HelloWorld in modo da richiamare la

funzione JavaScript alert come segue:


{ g.drawString(Stringa, 25, 20);

JSObject window = JSObject.getWindow(this);

String args[] = {“In Stampa!”};

window.call("alert", args);

}

Nota: è importante ricordarsi di aggiungere l'attributo MAYSCRIPT al tag <APPLET>

nella pagina HTML per consentire all'applet di accedere al metodi di JavaScript. Come richiamare le funzioni JavaScript definite dall'utente E’ possibile tramite la tecnologia LiveConnect richiamare da un'applet le funzioni definite

all'interno di un documento HTML da parte dell'autore della pagina. Per esempio, si supponga che nel documento HTML sia presente il seguente codice javaScript:

<SCRIPT>

function FunzionePersonale()

{ alert(“L'applet sta utilizzando una funzione definita

dall'utente!”);

</SCRIPT>

Modificando il codice applet dell'esempio Hello World nel seguente modo:

public void init()

{ Stinga = new String("Hello, world!")

JSObject win = JSObject.getWindow(this)

String args2[] = {“”}

win.call(“FunzionePersonale”, args2)

}

si otterrà la visualizzazione di una finestra di dialogo nel browser contenente il

messaggio: “L’applet sta utilizzando una funzione definita dall’utente”.



Conversione dei tipi da Java a JavaScript Le variabili passate da Java a JavaScript sono convertite nel seguente modo: � i dati byte, char, short, int, long, float e double sono convertiti nel tipo numerico

di JavaScript; � il tipo booleano di Java nel booleano di JavaScript; � gli oggetti della classe "JSObject" sono convertiti nell'oggetto primitivo di

JavaScript; � tutti i restanti oggetti sono incapsulati (wrapped) nell'oggetto Java di JavaScript,

che può essere utilizzato per accedere ai metodi e alle proprietà dell'oggetto stesso; per riportare un oggetto Java nel dato originale è necessario eseguirne la conversione; per esempio per convertire un oggetto Java in stringa è necessario richiamare la funzione “toString” mentre per convertirlo in un numero si utilizza la funzione "floatValue", che potrebbe anche fallire nel caso in cui l'oggetto non sia un numero;

� i vettori Java sono convertiti nell'oggetto vettore di JavaScript. Conclusioni I vantaggi che questa tecnologia può portare nello sviluppo di applicazioni per il Web

sono evidenti e lo diventano maggiormente se si considera che ora Domino supporta nativamente sia il codice JavaScript sia le applet Java all'interno dei propri elementi di sviluppo.

REALIZZAZIONE - Capitolo 5


5 REALIZZAZIONE

5.1 L’idea di base L’idea che è stata presa in considerazione da subito è stata quella voler di creare

un’applicazione in cui l’interattività e la semplicità d’utilizzo fossero requisiti indispensabili. Si voleva creare un prodotto che si differenziasse da quelli che attualmente si trovano su internet e che offrono questo servizio, dando all’utente finale la sensazione di trovarsi di fronte ad un vero e proprio programma interattivo, e non semplicemente ad una fredda e statica serie di pagine html prodotte dall’output di qualche query. Contemporaneamente, dato che l’applicazione sarebbe dovuta “girare” su Web, doveva risultare il più leggera possibile per non rischiare di annoiare l’utente con interminabili minuti in attesa del caricamento del codice.

Per ottenere il risultato richiesto, bisognava realizzare un’applicazione client-server di qualche tipo. La scelta è caduta su un’architettura di base a tre livelli (o “Three Tier”). In generale, l’approccio di partenza rispecchia il seguente schema:

Figura 5-1: architettura a tre livelli

Presentation tier Middle tier Data tier

SERVER SERVER

C LIENT

C LIENT

C ontiene l'interfaccia utente C ontiene il motore SERVER C ontiene i dati

Capitolo 5 - REALIZZAZIONE


Dove ciascun livello (o tier) ha compiti ben distinti. Presentation tier: rappresentato dalla macchina client con cui l’utente accede al servizio. Compiti: � raccogliere le richieste dell’utente relative alla natura dei dati d’interesse

sottoforma di parametri pre-confezionati; � inviare i parametri al server; � ricevere i risultati ottenuti dalla query sottoforma di dati già formattati secondo un

preciso protocollo; � visualizzarli graficamente.

Middle tier: rappresentato da una macchina server, è il vero motore server dell’applicazione. Compiti: � restare in ascolto di richieste da parte dei diversi client; � elaborare i parametri inviategli, implementando le regole “di business” (o

business rules); regolamenta cioè l’accesso al contenuto del database secondo alcune regole di sicurezza;

� trasformare i parametri in query che effettuerà sui dati contenuti nel “Data tier”. Data tier: rappresentato da una macchina server. Può essere una macchina fisicamente distinta dal Middle Tier o, come nel caso in esame, coincidere con il Middle Tier. Ad essa sono delegati i seguenti compiti: � contenere i dati “grezzi” (il db Notes dei log) che saranno oggetto di query; � accedere fisicamente ai dati per conto del Middle Tier.

5.2 Scelta delle tecnologie e motivazioni Dovendo creare un’applicazione fortemente legata al mondo delle reti, la prima scelta

riguardante le tecnologie da utilizzare ha preso in considerazione CORBA, per i notevoli vantaggi che essa poteva offrire in questo ambito (si vada ai paragrafi 3.3.5 e 3.3.6 per ulteriori dettagli sulle potenzialità di CORBA):

1) possibilità di interagire con un database remoto direttamente dalla pagina di un

browser 2) completa trasparenza delle connessioni tra client e server



3) maggiore rapidità nelle connessioni 4) facilità nell’implementazione

Mediante la creazione di un applet in una pagina html, sarebbe stato molto semplice interrogare la base di dati e rappresentarli poi graficamente a video (si vada al paragrafo 3.3.6 “R5 e CORBA” per ulteriori dettagli).

L’unico aspetto negativo legato a CORBA è presto detto: è necessario che la macchina client possegga nel proprio file system l’implementazione delle classi CORBA lato client. Domino offre queste classi in un file compresso in formato “jar” e con il nome di “NCSOC.JAR”. Ora, quello rende problematico l’uso di questa tecnologia in un contesto Internet, è il fatto che la versione "compact" delle classi CORBA lato client di Domino (il file NCSOC.JAR) consta di ben 790 KB. Questo significa che l’utente dovrebbe in qualche modo scaricare questo file dalla rete almeno una prima volta, e comunque ogni volta che perde il contenuto della cache del proprio browser. Se non si dispone di una connessione piuttosto veloce, questa operazione può rendere il caricamento ella pagina veramente interminabile, con la conseguenza che l’utente perde interesse nell’utilizzo dell’applicazione. Ai 790 KB va poi aggiunto il peso delle pagine html vere e proprie e degli applet.

Una possibile soluzione a questo problema è la seguente: dotare ogni singola macchina

cliente del file “NCSOC.JAR”, modificando il classpath il modo tale che la macchina virtuale java del browser riesca a localizzare le classi java contenute in locale, senza dover ogni volta scaricare l’intero jar dalla rete. Questa soluzione sebbene efficace, rende l’applicazione riservata a pochi eletti (possessori del file in questione) e difficilmente espandibile.

Questo è il motivo per cui la tecnologia CORBA è stata accantonata, e sono state prese in considerazione soluzioni alternative. La modalità con cui le tecnologie sono state inserite nel progetto saranno oggetto di discussione dei paragrafi seguenti.



5.3 La parte “client”

5.3.1 Panoramica generale del Client La parte client del prodotto software è costituita da una pagina HTML che adempie a

tutte le mansioni del “presentation tier” elencate al paragrafo 5.1 di questo capitolo. E’ sicuramente il modulo software più complesso dell’intero progetto.

La pagina Web è stata fisicamente divisa in tre frame html, come in figura 5-2.

Figura 5-2: pagina html client

Dove risiede il codice: La pagina html, oltre agli elementi grafici che saranno illustrati nel capitolo 6

“Maschere”, contiene il codice che permette all’applicazione di funzionare. Il Frame 1: contiene un form html che raccoglie le impostazione dei parametri relativi alle richieste. Il Frame 2: contiene il motore Client del programma, nonché l’OUTPUT ovvero i grafici statistici. In

esso vi sono 3 applets Java che chiameremo “Appet Bridge”, “Applet Grafico 1” e “Applet Grafico 2”. Gli ultimi due sono “visibili”, producono cioè OUTPUT visivo; “Appet Bridge” invece è “invisibile” ed opera senza che l’utente se ne possa accorgere.

In particolare ciascuno dei due applet grafici disegna a video un grafico statistico differente. Il primo dei due si occupa di tracciare una statistica che potremmo definire “generale” mentre il secondo rappresenta un particolare del primo.

Frame 3

Frame 1 Frame 2



Il Frame 3 contiene un applet provvisto di sue spie luminose che hanno lo scopo di informare l’utente dell’avvenuta connessione/disconnessione con il server. Il frame 3 contiene un applet denominato “Applet Banner”.

La pagina html inoltre ingloba al suo interno numerose funzioni scritte in JavaScript che

interagiscono con gli elementi della pagina html, con gli applets e con in Server. L’applicazione lato Client possiede una struttura fisica-funzionale secondo lo schema di

figura 5-3. Ne verrà di seguito analizzato ogni dettaglio. Si faccia riferimento a tale schema per tutta la spiegazione del client.

Figura 5-3: schema di funzionamento per il Client

codice JavaScript

Applet Bridge

Applet Banner

INFO

BU

S

Applet Grafico 2

Flussi informativi InfoBus

Flussi informativi LiveConnect

Attivazione HTML-JavaScript

Applet Produttori

Applet Consumatori

form perimpostazione

Parametri

Applet Grafico 1

Attivazione tramite LiveConnect

Flussi informativi HTML <-> JavaScript

bottone



Per comodità espositiva si preferisce suddividere la spiegazione del funzionamento del

client e di come è stato possibile realizzarlo, in 4 distinte fasi: � il form per l’impostazione dei parametri; � l’invio dei parametri; � la ricezione dei risultati; � la pubblicazione dei risultati.

5.3.2 Il form per l’impostazione dei parametri:

tramite un form html (figura 5-4) contenuto nel frame, l’utente imposta i parametri che

specificano il tipo d’informazioni a cui desidera accedere; I parametri sono: 1) la data d’inizio e la data di fine periodo nel quale considerare le visite 2) il sito d’interesse; l’utente può scegliere uno alla volta, tra una lista composta dai soli

siti di cui è proprietario 3) il tipo di contatto 4) l’aggregazione e possono essere impostati riempiendo dei campi come questi:

Figura 5-4: form per l’impostazione dei parametri



avanza di un mese retrocedi di un mese

Giorno selezionato Numero settimana

mese e anno

1) la data d’inizio e la data di fine sono dei semplici campi di tipo testo che però hanno una proprietà paricolare: non sono editabili, ovvero all’utente non è consentita la digitazione diretta di una data al loro interno. L’introduzione di una data all’interno del campo avviene grazie ad un meccanismo un po’ più complesso, illustrato di seguito.

Accanto ai due campi c’è un bottone la cui pressione fa comparire un calendario per l’impostazione della data.

Il calendario per la scelta della data offre un’interfaccia amichevole e rapida per

l’inserimento della data.

Figura 5-6: applet per l’inserimento della data

Inoltre impedisce all’utente d’inserire date errate o inesistenti come ad esempio il 29

febbraio per gli anni non bisestili. Passando con il mouse sopra ai numeri corrispondenti ai giorni, viene visualizzata una stringa che descrive il giorno che si sta per scegliere (nella figura 5-6 ad esempio si sta per scegliere il 14 gennaio 2000).

Il calendario compare



L’utente sceglie il mese e l’anno scorrendo il calendario mese per mese mediante i due bottoni laterali e il giorno facendo clic con il mouse sul numero corrispondente.

Cliccando sul giorno prescelto: � il calendario scompare gradualmente dalla pagina uscendo sempre dalla stessa

parte da cui era entrato (a sinistra); � la data prescelta viene automaticamente riportata in modo corretto nel campo data

inizio o data fine, a seconda di cosa si era scelto d’introdurre.

Figura 5-7: scelta della data con l’applet “calendario”

Com’ è stato realizzato: innanzitutto è stata inibita la possibilità di modificare i due campi data da parte

dell’utente. E’ stato sufficiente inserire nel codice html dei campi data la proprietà: onFocus="this.blur();"

che fa in modo che l’utente non abbia mai il focus del campo, ovvero la proprietà di editarlo.

Sono state create due pagine HTML contenenti ciascuna l’applet per la scelta della data, e sono state inserite nel frame 1 in modo che risultassero posizionate al di fuori dell’area visibile dello schermo. Alla pressione del bottone una o l’altra delle due pagine compaiono scorrendo da sinistra verso destra, sovrapponendosi al contenuto del form1 e posizionandosi appena sotto il campo data (data inizio o datatine).

Questo è stato possibile realizzarlo grazie all’uso del DHTML (Dinamic HTML) e in particolare utilizzando i frames e i layers. Come dice il nome, questa tecnologia abbatte il limite

Il calendario scompare

La data viene riportata



che l’html tradizionale ha sempre imposto, ovvero la staticità, permettendo di modificare il contenuto e l’aspetto di una pagina in modo dinamico.

Putroppo i due browser più famosi (Microsoft Internet Explorer e Netscape Navigator) implementano il DHTML in maniera assai diversa, utilizzando istruzioni differenti. Questo problema è stato risolto duplicando del codice html presente nel form 1 e creando 4 anziché 2 pagine contenenti gli applet calendario: una pagina con il calendario per la data d’inizio e una pagina con il calendario per la data di fine per Internet Explorer, una pagina con il calendario per la data d’inizio e una pagina con il calendario per la data di fine per Netscape Navigator. Al caricamento della pagina principale, in base al browser utilizzato dal cliente vengono caricate comunque solo le 2 pagine che contengono il codice html corretto.

L’applet è composto da due classi che vengono trasferite al browser in un unico file compresso secondo lo standard “JAR” pesando in tutto 6,84 KB.

Riassumendo, i vantaggi di un’interfaccia simile sono:

� facilità da parte dell’utente che può continuare ad usare il mouse � possibilità per l’utente di consultare il calendario prima di scegliere una data (utile ad

esempio se non si ricorda bene un giorno particolare legato ad un certo evento) � impossibilità d’inserimento di date inesistenti o errate; il programmatore si è risparmiato così

numerose righe di codice JavaScript che sarebbe stato comunque necessario per il controllo di correttezza della data.

� interattività e grafica piacevoli che stimolano l’utente all’uso dell’applicazione 2) il sito d’interesse può essere scelto tramite un campo denominato “SitoListBox” di

tipo “ListBox” contenuto nel form e che visualizza una lista di possibili domini tra cui l’utente può selezionarne uno soltanto.

Al caricamento della pagina principale il contenuto di “SitoListBox” viene automaticamente riempito dall’http server Domino con tutti i nomi di domini di cui l’utente è proprietario e per ciò autorizzato ad accedervi.

Esempio: si supponga che l’utente net1 sia proprietario dei siti www.miosito.it e www.net1.it ebbene, egli potrà scegliere di accedere alle statistiche del primo o del secondo sito

manipolando una listbox come questa:



Figura 5-8: listbox per la scelta del sito

Com’ è stato realizzato: E’ stato creata all’interno del database NetWorkStats.nsf una raccolta di documenti che

specifica per ogni utente presente nell’ACL del database, quanti e quali siti sono a lui accessibili; chiameremo semplicemente “diritti d’accesso” tale raccolta. Ogni documento è stato creato con un form Notes appositamente ideato, il cui nome è “ACLclienti”:

Figura 5-9: il form ACLclienti

in esso compaiono i campi NomeUtente, DescrizioneCliente e ACLcliente. I primi due campi sono di tipo testo mentre il terzo è di tipo “Dialog list”, un tipo di

Notes simile alla listbox ma che in più permette di selezionare da nessuna a tutte le voci elencate. Il database manager (il sottoscritto) utilizza questo form per creare dei documenti contenenti ciascuno questi tre campi. Ogni singolo documento si riferisce ad un cliente differente. Il significato dei tre campi è il seguente:

• NomeUtente: rappresenta il nome ufficiale con il quale l’utente compare nell’ACL. In altre parole è la login dell’account.

• DescrizioneUtente: è una sorta di commento fatta da una breve frase che descrive la natura dell’utente.

• ACLcliente: è l’elenco dei siti cui l’utente è proprietario. Contiene da nessuno ad n valori.

Per l’utente net1 ad esempio si sarebbe dovuto creare un documento con i valori:



Nome Utente net1

Descrizione Utente fittizio creato per l’esempio

ACL www.miosito.it, www.net1.it

Autorizzando quindi l’utente net1 ad avere accesso alle informazioni statistiche relative

ai siti www.miosito.it, www.net1.it. Come vengono impostati i diritti d’accesso: I diritti d’accesso sono impostabili creando modificando o eliminando documenti con il

modulo (form) ACLcliente. Questo modulo - come ogni elemento di database di Notes - possiede un proprio ACL; ciò significa che solamente determinate persone sono autorizzate ad utilizzarlo e ad impostare quindi i diritti d’accesso. Nella fattispecie solo il database manager può farlo.

L’applicazione è stata pensata per poter essere configurata anche da una postazione remota via Web. Utilizzando un semplice browser di pagine html è consentito al database manager modificare, aggiungere o rimuovere i diritti d’accesso.

Figura 5-10: modifica via Web dei diritti d’accesso dell’utente net1

Il database manager può quindi scegliere come contenuto del campo ACL nessuno, uno, oppure anche tutti i domini che compaiono come possibile scelta nel campo ACL (figura 5-10). La cosa interessante da far notare è che il campo ACL del form ACLcliente non contiene una lista



statica di domini ma una raccolta di stringhe risultato di una query. La query è espressa dalla formula seguente:

@DbColumn("";"":"lavaredodomlog.nsf";"domini";1)

impostata come contenuto del campo ACL tramite il Domino Designer:

I log infatti sono contenuti in un database chiamato “lavaredodomlog.nsf” nel disco fisso

della macchina remota che rappresenta il “Data tier”. In esso è definita una vista “domini” che contiene tutti i domini presenti nel db dei logs. Tale vista viene aggiornata automaticamente dal sistema con il nome di tutti i domini contenuti del db dei logs; non appena compare una entry log relativa ad un dominio nuovo, il nome del nuovo dominio viene aggiunto nella vista “domini”.

La formula @DbColumn("";"":"lavaredodomlog.nsf";"domini";1) dice proprio all’http server Domino di accedere alla vista “domini” contenuta nel database “lavaredodomlog.nsf” e di selezionarne la colonna numero 1 ovvero quella che contiene l’elenco dei nomi dei domini. L’immagine seguente è un esempio di come appare la vista “domini”.

Figura 5-12: vista “domini” del db “lavaredodomlog.nsf”

Il tipo è Dialog list

Figura 5-11: impostazioni delle proprietà del campo ACLcliente

Il contenuto è una formula

la formula



Detto questo può essere spiegato come avviene l’impostazione del campo “SitoListBox” al caricamento della pagina principale.

Innanzi tutto per accedere alla pagina contenete l’applicazione, l’utente deve digitare nella finestra degli indirizzi del proprio browser un indirizzo internet (URL) simile a:

Figura 5-13: accedere all’applicazione da Web

che non è altro che una richiesta di apertura di un database Notes chiamato

“networkstats.nsf” e situato sul server “mail.nwg.it” nella cartella “sviluppo/networkstats”. Ad una richiesta simile il server Domino risponde secondo le direttive impostate dallo

sviluppatore (si vada il paragrafo 3.2.8 “Come Domino gestisce gli URL” per dettagli). In questo caso è stato deciso che a tale richiesta deve essere fornita la “home page” (pagina principale) dell’applicazione e cioè quella che compare nella figura 5-14.

Figura 5-14: impostazione delle proprietà d’avvio dell’applicazione domino

A questo punto il server verifica se il documento richiesto è soggetto a restrizioni di

accesso mediante la consultazione dell’ ACL (Access Control List) relativa. (capitolo 3.2.9). Il database è protetto ed è accessibile solo ai clienti NWG che abbiano acquistato un

account, ossia una login ed una password per accedere all’applicazione. Il browser visualizza la schermata tipica che richiede all’utente di identificarsi inserimento negli appositi spazi la propria login e password.

Nome della pagina da fornire

Avvio dell’applicazione



Figura 5-15: schermata per l’identificazione dell’utente

Questa fase prende il nome di identificazione dell’utente ed ha un duplice scopo: � inibire l’uso del programma ad utenti che non siano clienti NWG e che non siano

provvisti di regolare account; � limitare l’uso del programma alle persone che abbiano passato con successo

l’identificazione utente, consentendo l’accesso alle informazioni relative ai soli siti di propria appartenenza.

Se l’account immesso non corrisponde ad uno valido, l’utente non riuscirà a caricare la

pagina, altrimenti la pagina verrà caricata e la listbox “SitoListBox” di figura 5-8 sarà impostata con l’elenco dei siti accessibili all’utente. L’elenco dei siti all’interno di questo campo non è statico, cioè non è stato impostato manualmente da qualcuno ma viene calcolato dal server Domino ad ogni richiesta di caricamento della pagina secondo la formula seguente contenuta nel campo “SitoListBox”:

dbName:=@Subset(@DbName; -1);

@Unique (@DbLookup("":"" ;

"":"lavaredodomlog.nsf";"domini";@DbLookup("":"" ; "":dbName ;

"viewACLclienti"; @Trim(@Name([CN];@UserName));3);1) )

Ad ogni richiesta di caricamento della pagina principale, il server Domino:

1. calcola la formula 2. con il risultato riempie il campo “SitoListBox”



3. spedisce al browser via http la pagina ottenuta contenente il campo “SitoListBox” calcolato.

La formula non è altro che una query doppia il cui risultato è una lista di stringhe; RIGA 1: nella variabile dbName viene messo il nome dell’utente (dopo che lo stesso si è

identificato con login e password). RIGA 2 e seguenti: viene fatta una query nidificata; prima si accede alla vista

viewACLclienti nel db “NetWorkStats.nsf” che contiene tutti i documenti relativi ai diritti d’accesso creati con il form ACLcliente. In essa si selezionano tutti i domini contenuti, quelli cioè che il database manager decide di rendere accessibili all’utente. Di questi poi si prendono in considerazione solo quelli che posseggono almeno una entry di log nel database dei logs “lavaredodomlog.nsf” e che perciò compaiono nella vista domini dello stesso database. Questo controllo potrebbe sembrare ridondante, tuttavia è necessario per garantire che le statistiche possano aver luogo. Senza entry di logs non è possibile fare alcuna statistica.

Per capire meglio segue un esempio: Esempio: si supponga che l’utente net1 sia proprietario dei siti www.miosito1.it, www.miosito2.it

e www.miosito3.it ma che quest’ultimo sia stato soppresso da diverso tempo o che per motivi vari (manutenzione, ecc…) non abbia avuto accessi per un lungo periodo. Inoltre si consideri che ad intervalli regolari il database contenente i logs viene ripulito (di solito a fine anno) ed è quindi possibile che ad almeno un dominio non corrisponda nemmeno una entry di log.

La prima riga della formula selezionerebbe tutti e tre i domini perché ancora di proprietà del cliente net1. Le righe seguenti invece prenderebbe in considerazione solo quei domini (tra questi tre selezionati) che compaiono anche nella vista domini del database dei logs “lavaredodomlog.nsf” e che quindi hanno almeno una entry di log che li riguardino.

Al caricamento della pagina principale il campo “SitoListBox” conterrebbe una lista formata dai soli domini www.miosito1.it e www.miosito2.it tra cui l’utente net1 può scegliere.

3) il tipo di contatto è sceglibile impostando un campo di tipo RadioButton che offre

due possibili scelte: “host distinti” e “richieste totali” (vedere specifiche al capitolo 4) l’aggregazione degli accessi è una semplice ListBox statica e permette di scegliere

un tipo di aggregazione alla volta.



5.3.3 L’invio dei parametri

Una volta impostati tutti i parametri è possibile dare inizio alle statistiche premendo un

bottone situato sempre nel frame 1, appena sotto il form. La pressione del bottone genera un evento che scatena poi tutta una reazione a catena di

eventi successivi. Si può suddividere logicamente il tutto nelle seguenti fasi: � il client preleva i parametri contenuti nel form d’impostazione parametri � li invia al middle tier � resta in attesa della restituzione dei risultati � pubblica i risultati su InfoBus

Come avviene l’innesco: Alla pressione del bottone viene richiamata una funzione JavaScript che legge i parametri

contenuti nel form e li passa ad una seconda funzione che, tramite la tecnologia LiveConnect invoca un metodo Java dell’applet “Applet bridge” chiamato JS_doQuery, passandogli tutti i parametri appena prelevati. Il resto lo fa l’applet.

L’applet “Applet Bridge”: funzionamento generale Il nome “Applet Bridge” indica il ruolo che questo applet svolge all’interno della pagina

HTML. Esso si comporta infatti come un ponte (bridge) fra il Browser (e quindi la pagina html visibile all’utente) ed il middle tier. Applet Bridge rappresenta il fulcro del software contenuto nel client.

Attraverso il metodo java JS_doQuery viene aperta una connessione http con il server “middle tier” e vengono spediti ad esso i parametri sottoforma di oggetti di tipo stringa. L’ordine con cui vengono inviati rispetta un protocollo specifico e di comune accordo tra l’applet e il middle tier, mentre la modalità con cui viene aperta la connessione verrà spiegata nel paragrafo 5.4 “Il middle tier”.

L’applet a questo punto resta in attesa che il middle tier interpreti i parametri, esegua le query necessarie, e ritorni i risultati. Una volta ricevuti i risultati li pubblica su InfoBus.



Com’ è stato realizzato: La funzione Javascript che innesca tutto il processo è associata all’evento di pressione del

bottone (evento “onClick()). Essa richiama una seconda funzione “aggiornaGrafico()”la quale legge i valori impostati nei campi del form semplicemente utilizzando codice JavaScript che può accedere alle proprietà dei componenti contenuti nella pagina html. La seconda funzione richiama poi un metodo Java tramite LiveConnect. Ecco il codice di “aggiornaGrafico()”:

function aggiornaGrafico()

{

appletGrafico=parent.FrameGrafico.document.applets["InfoBusBarChart"];

appletBridge=parent.FrameGrafico.document.applets["appletBridge"];

FieldSitoListBox=document.forms[0].SitoListBox;

Sito=FieldSitoListBox.options[FieldSitoListBox.selectedIndex].text;

// Sito corrente

FieldContatto=document.forms[0].Contatto;

Contatto=(FieldContatto[0].checked) ? "true" : "false"; // Contatto

FieldAggregazioneListBox=document.forms[0].AggregazioneListBox;

Aggregazione=FieldAggregazioneListBox.options[FieldAggregazioneListBox

.selectedIndex].text; // Tipo di aggregazione

FieldDataInizio=document.forms[0].DataInizio;

DataInizio=FieldDataInizio.value;

FieldDataFine=document.forms[0].DataFine;

DataFine=FieldDataFine.value;

// Ordina all'applet di eseguire la query:

appletBridge.JS_doQuery("GENERIC","null","null",Sito,Contatto,Aggregaz

ione,DataInizio,DataFine);

}



L’invio dei parametri avviene all’interno dell’applet AppletBridge. Senza entrare in merito allo specifico codice Java utilizzato, basti sapere che la connessione avviene grazie all’utilizzo delle classi contenute nel package standard java.net e utilizzando il metodo d’istanza openConnection() della classe URL. Grazie a questo metodo viene invocato un URL simile a questo:

http://host/database/nomeAgente?OpenAgent&parametro2=valore1

& parametro2=valore2….& parametroN=valoreN

La prima parte dell’URL (in rosso) serve ad invocare l’esecuzione di un’agente remoto

Notes da Web. Per dettagli riguardo l’invocazione remota di agenti si veda il paragrafo 3.3.3. Il resto dell’URL è il passaggio degli N parametri. Ogni parametro è specificato con una coppia di valori di tipo Stringa nomeParametro=valoreParametro e separato dagli altri con un carattere ‘&’, esattamente come per l’utilizzo di variabili CGI.

La ricezione dei parametri da parte del middle tier è un poco più complessa e va gestita spulciando il pacchetto http in arrivo. Questa fase verrà solo accennata nel paragrafo 5-4.

5.3.4 La ricezione dei risultati Dopo che il middle tier ha ricevuto i parametri inviategli dal client, esegue una query e ne

ritorna l’esito al client sempre utilizzando il protocollo di trasporto http. I risultati ottenuti sono di due tipi: � dati Grafici � dati Parametrici

I primi rappresentano i valori numerici da rappresentare nel grafico, mentre i secondi

danno indicazioni agli applet su come visualizzare tali dati.



Grafici dinamici a tutti gli effetti: Il tutto è stato progettato per fare in modo che i grafici generati possano venir pilotati

completamente dal server e cioè dal middle tier. Questo significa che il middle tier può stabilirne non solo il contenuto, ma anche il tipo e l’aspetto in base al tipo di statistica richiesta.

Contenuto: si intendono i valori rappresentati nel grafico, quindi i dati

numerici o Dati Grafici Tipo: istogramma, grafico a linee, grafico a torta

l’aspetto è a sua volta stabilito per mezzo di alcuni parametri o dati parametrici che sono differenti a seconda del TIPO specificato. Ad esempio per un ISTOGRAMMA sono: Titolo SI / NO Il Titolo Legenda SI / NO Posizione Legenda (in alto, in basso, a destra, a sinistra) Etichette sui valori Modalità 3D SI / NO Colore interno di sfondo Colore di sfondo del riquadro esterno Colore interno di sfondo 2 Colore di sfondo del riquadro esterno 2 Modalità colori SI / NO

Etichette sulle barre dell’istogramma SI / NO Griglia righello SI / NO Etichette per il range dei valori SI / NO Allineamento delle barre (orizzontale o verticale)

Aspetto:

Etichette, barra per barra

I possibili tipi di grafici sono tre: istogramma, grafico a linee, grafico a torta, ma in

questo progetto ne sono stati utilizzati solo due: l’istogramma e il diagramma a torta. Entrambi i tipi di dati vengono ricevuti dall’applet “Applet Bridge” racchiusi in dati di

tipo stringa nel pacchetto http inviato dal server.



5.3.5 La pubblicazione dei risultati

I dati ricevuti vengono smistati dall’applet “Applet Bridge” tra dati grafici e dati

parametrici. Vengono poi costruiti due oggetti Java strutturati del tutto simili agli array, i Vector. Uno di essi contiene tutte le informazioni grafiche mentre l’altro quelle parametriche. Tali oggetti poi vengono etichettati con nomi particolari in modo tale che l’applet interessato sappia riconoscerli e se di proprio interesse prelevarli e pubblicati su InfoBus.



I dati vengono inviati su InfoBus sempre a coppie: � un dato parametrico che specifica il tipo e l’aspetto � un dato grafico che ne specifica i valori

La pubblicazione avviene secondo quanto spiegato nel paragrafo 4.1.3 “Il protocollo InfoBus per lo scambio dei dati”. Al caricamento della pagina html gli applet che avranno a che fare con l’InfoBus si registrano come membri dell’InfoBus, chi come produttore chi come consumatore.

AppletBridge si dichiara produttore dei quattro tipi di dati che viaggeranno su InfoBus: i due Dati Grafici e i due Dati Parametrici. Resta poi in attesa che gli altri due applet si registrino come consumatori di un Dato Grafico e di un Dato Parametrico ciascuno.

Gli applet grafici a questo punto restano in attesa che appletBridge notifichi la disponibilità di dati sull’InfoBus, non appena il risultato di una query è stata ottenuta dal server.

E’ compito dell’applet interessato prelevare il dato da InfoBus e interpretare le istruzioni contenute nel dato parametrico e visualizzare i valori contenuti nel dato grafico.

5.3.6 L’interazione con l’utente

Si faccia riferimento sempre allo schema di figura 5-3. L’applet grafico 1 visualizza un istogramma relativo all’intero periodo di tempo scelto

dall’utente e in cui ogni colonna rappresenta un periodo di aggregazione (per il momento è stato richiesto solamente il mese come periodo di aggregazione). Ciò significa che ogni colonna rappresenta il totale degli accessi in un determinato mese. Si avranno tante colonne quanti sono i mesi compresi nel periodo totale di tempo scelto dall’utente.

Selezionando col mouse ogni singola colonna quest’ultima viene evidenziata e se la legenda è visibile anche la rispettiva voce al suo interno viene cerchiata. Funziona anche il viceversa: cliccando su una voce nella legenda viene evidenziata oltre che la voce stessa, la relativa colonna.

Figura 5-16: esempio di grafico interattivo

colonna selezionata



Ma non è tutto; selezionando una colonna del grafico 1 si richiede di generare una statistica più particolare relativa al mese selezionato. Da specifica è stato richiesto che in un secondo grafico venisse mostrata la ripartizione degli accessi per nazione di provenienza relativa al mese selezionato. Questo grafico è di tipo “diagramma a torta”, come quello che segue.

Figura 5-17: grafico del dettaglio del mese di aprile 2000

basta posizionare il puntatore del mouse sopra un settore perché compaia il numero di

accessi e la percentuale rispetto al totale del mese selezionato. Cliccando sul settore della torta o sopra una voce della legenda, viene selezionato sia il settore sia la voce in legenda.

In figura 5-17 è rappresentata la ripartizione del mese di aprile 2000 del grafico di figura 5-16. Il totale del mese letto dal primo grafico era di 13 accessi. Sul secondo grafico si legge invece che di questi 13, 6 sono stati effettuati dall’Italia per una percentuale del 46% sul totale di 13.

Inoltre l’utente può modificare parzialmente ma istantaneamente l’aspetto del grafico

cliccando su alcuni bottoni circostanti che fungono da interruttori per alcune caratteristiche (si vada al capitolo 6 “MASCHERE” per vedere l’interfaccia utente).

Le caratteristiche grafiche modificabili dall’utente sono esemplificate nella pagina seguente:



Multicolor On/Off

Modalità 3D On / Off

Legenda On/Off



Etichette On/Off

E’ possibile ovviamente combinare fra loro tutte le possibili caratteristiche. La cosa

importante è che operando sui bottoni l’aspetto del grafico viene modificato all’istante senza bisogno di ricaricare la pagina e senza aprire connessioni con il server. Semplicemente è l’applet che provvede a ridisegnarsi sul video con i valori numerici e parametrici ricevuti.

Modificando opportunamente il codice sarebbe stato possibile delegare all’utente anche la scelta dei colori, dei fonts utilizzati per le scritte, e numerosi altri parametri grafici. Tuttavia per il momento ciò non è stato ritenuto fondamentale.

Com’ è stato realizzato: Si faccia riferimento allo schema di funzionamento di figura 5-3. Quando l’utente clicca sul primo grafico genera un evento che il codice java dell’applet

stesso intercetta. Tramite la tecnologia Live Connect l’applet richiama una funzione JavaScript a cui passa come parametri il numero della colonna selezionata e l’etichetta corrispondente. La funzione JavaScript a sua volta invoca il solito metodo Java dell’applet appletBridge chiamato JS_doQuery,passando queste due informazioni insieme ai parametri e specificando che l’utente desidera ottenere un “detailed chart”, ovvero un grafico che rappresenti il dettaglio. appletBridge.JS_doQuery("DETAILED",msg1,msg2,Sito,Contatto,Aggregazion

e,DataInizio,DataFine);

Questo metodo riapre una connessione con il server a cui vengono rispediti tutti i parametri, compresa la stringa “DETAILED”. Il server interpreta tutte le informazioni inviategli ed esegue le query necessarie.

La modifica dell’aspetto grafico degli applets invece è stata realizzata così: sono stati inseriti nella pagina alcuni bottoni, uno per ogni funzione da attivare /

disattivare. La pressione del bottone richiama una specifica funzione JavaScript. La funzione a



sua volta richiama un particolare metodo pubblico dell’ applet che abilita o disabilita la caratteristica grafica selezionata e forzando poi il rinfresco istantaneo del grafico.



5.4 Il Middle Tier Il Middle Tier è costituito da una macchina NT server che nella cartella di default di

Domino possiede il database “NetWorkStats.nsf” contenete l’applicazione. Il codice che funge da middle tier all’interno del database è un Agente condiviso Notes

chiamato “queryAgent”. Esso è scritto interamente in Java, utilizza i packages standard java del jdk1.1 e in package Notes lotus.domino. Per comodità è stato suddiviso in 4 classi:

� queryAgent.class: è la classe che contiene il “main” dell’Agente e per questo

estende la classe Notes AgentBase. Consta di poche righe perché il suo scopo è solo quello di avviare l’esecuzione dell’Agente; di fatto crea un oggetto di classe serverQueryEngine (vedi oltre) e richiama su di esso il metodo pubblico GO() per far partire l’applicazione

� serverQueryEngine.class: costituisce il nocciolo del middle tier. Consta di un

costruttore e di ben 11 metodi. Il suo compito è quello di verificare l’identità dell’utente conesso, di riceverne le richieste, di eseguire le query e restituire i risultati. Si avvale delle due classi seguenti.

� Domini.class: serve per tradurre le estensione dei domini internet (come “.it”,

“.au”) nei corrispondenti stati di appartenenza Ad esempio traduce “.it” in Italia. Contiene un’hash table con tutte le corrispondenze e tre metodi per accedervi.

� DatiParametrici.class: serve per costruire correttamente ed inviare al client le

direttive riguardanti il tipo e l’aspetto di grafico da visualizzare ovvero i DatiParametrici dei grafici. Possiede 3 costruttori e 7 metodi.

Su di esso è impostato un ACL con i nomi dei soli clienti NWG autorizzati ad utilizzare

l’applicazione. L’agente viene invocato via URL dall’applet bridge presente nella pagina html del client e viene eseguito nella macchina virtuale Java del server. Solo i dati grafici e dati parametrici di ritorno sono restituiti al client sottoforma di stringhe.

5.4.1 Multithreading L’agente può essere invocato da più utenti contemporaneamente perché un Agente Notes

è di per se “threadizzato”. Ciò significa che il codice Java che descrive l’agente può venir scritto dal programmatore come se si trattasse di un unico processo. E’ compito della macchina virtuale



Java del server Domino “duplicare” il processo per soddisfare a tutte le richieste che parallelamente giungono dalla rete.

Come spiegato nel paragrafo 3.3.2 “Gli agenti Notes” un agente Notes deve estendere la classe Notes chiamata AgentBase. Infatti il “main” dell’agente è rappresentato dalla classe “queryAgent” il cui breve codice è il seguente:

import lotus.domino.*;

import java.util.*;

import java.io.*;

public class queryAgent extends AgentBase

{

public void NotesMain()

{

try

{

// (Your code goes here)

Session session = getSession();

AgentContext agentContext = session.getAgentContext();

Database db = agentContext.getCurrentDatabase();

ServerQueryEngine myAgent=new

ServerQueryEngine(this,session,agentContext,db);

// attiva l'agente che esegue la query e spedisce i risultati al client:

myAgent.GO();

} // fine try

catch(Exception e)

{ e.printStackTrace();}

} // fine public void NotesMain()

} // fine classe

Per maggiori dettagli si riveda il paragrafo 3.3.2 Si tralascia la spiegazione del codice relativo alle altri classi.

5.5 Il Data Tier



Nulla c’è da dire sul Data Tier se non che fisicamente coincide con la macchina del middle tier in cui è installato Lotus Domino. Per il data tier non è stao sviluppato alcun codice specifico. Esso contiene solamente un database Notes con i dati grezzi relativi agli accessi.

MASCHERE - Capitolo 6


6 MASCHERE

6.1 Il presentation tier Per poter accedere all’applicazione “NetWorkStats” l’utente deve prima caricare nel

proprio browser una pagina html introduttiva che ha una duplice finalità: � dare alcune informazioni sull’uso del software � preparare la pagina del browser per il caricamento dell’applicazione vera e propria, La pagina iniziale dell’applicazione “NetWorkStats” attualmente è piuttosto spoglia. Contiene soltanto un bottone per l’accesso alle statistiche:

Capitolo 6 - MASCHERE


Figura 6-1: schermata introduttiva all’applicazione “NetWorkStats”

Per accedere all’applicazione vera e propria l’utente deve premere un bottone. La pressione del bottone fa aprire una nuova pagina di navigazione a cui viene eliminata la barra degli indirizzi, la barra di stato e la barra dei pulsanti standard; l’area della finestra viene inoltre dimensionata alla massima dimensione dello schermo. Questo per poter sfruttare al massimo lo spazio visivo disponibile e visualizzare grafici di una dimensione apprezzabile.

A questo punto viene caricata la pagina contenente la parte “client” dell’applicazione che appare come in figura 6-2.

Figura 6-2: schermata iniziale dell’applicazione “NetWorkStats”

La parte sinistra contiene il form per l’impostazione dei parametri, la parte superiore visualizza un banner scorrevole dotato delle due spie luminose per informare dell’avvenuta connessione, mentre la parte centrale contiene due grafici (in figura 6-2 è visibile solo il primo) incassati in una sorta di monitor virtuale. L’applet grafico descritto nei capitoli precedenti è situato al centro del monitor e visualizza inizialmente l’immagine di uno schermo spento, per indicare che nessuna statistica è stata ancora effettuata.

MASCHERE - Capitolo 6


Alla pressione del tasto si accende la luce rossa che indica che la connessione con il

server è stata stabilita:

Dopo qualche secondo d’attesa appare il primo grafico:

Capitolo 6 - MASCHERE


La luce verde in alto indica che i dati statistici sono stati ricevuti e visualizzati

correttamente. Mediante i bottoni situati sull’immagine del monitor è possibile disabilitare e riabilitare

alcune caratteristiche grafiche: Selezionando con il mouse una colonna del primo grafico, si apre una seconda

connessione al termine della quale la pagina scrolla verso il basso per far apparire il secondo grafico, che visualizza il dettaglio del primo.

CONCLUSIONI - Capitolo 7


7 CONCLUSIONI

Gli obiettivi prefissati sono stati tutti raggiunti. E’ stato realizzato un prodotto software

(NetWorkStats) corretto performante e completamente aderente alle specifiche di partenza. Se si considera la gamma di statistiche che attualmente è in grado di offrire rispetto a

quelle che potenzialmente potrebbe generare si può concludere che NetWorkStats non rappresenta certamente un programma finito, ma ogni sforzo è stato fatto affinché si possa in futuro migliorare aggiungendo nuovi grafici interattivi e nuove funzionalità con poco sforzo da parte dello sviluppatore e soprattutto con un basso costo di manutenzione di codice.

Per la parte client è sufficiente modificare il codice Java dell’applet produttore “appletBridge” e aggiungere nuovi applet grafici, le cui classi java però sono per la quasi totalità identiche. I diversi tipi di applet grafici infatti sono progettati in modo che il grosso del codice è comune a tutti, a prescindere del tipo di grafico e di dati trattati. Questo rende inoltre i tempi di caricamento dell’applicazione alla portata delle connessioni internet più lente in quanto è sufficiente caricare una volta sola gran parte del codice che viene poi “duplicato”.

Il software che costituisce il “middle tier” necessità di un modesto aggiornamento; la parte client che si occupa della connessione remota con il middle tier rimane esattamente identica, anche aggiungendo nuovi parametri di query.

Il data tier non necessita di alcun tipo di manutenzione; esso contiene solamente i dati grezzi relativi agli accessi, che vengono aggiornati automaticamente e in tempo reale dal sistema Domino.

Capitolo 7 - CONCLUSIONI


BIBLIOGRAFIA


BIBLIOGRAFIA

Mauro Roncolato “Lotus Notes & Domino 5, come realizzare applicazioni professionali”- HOEPLI - 1998 [MokaByte www.mokabyte.it] Daniela Ruggeri “InfoBus, un’autostrada per i Beans” MokaByte numero 21 - Luglio 1998 [MokaByte www.mokabyte.it] Andrea Chiarelli “InfoBus” MokaByte numero 30 - Maggio 1999 [www.java.sun.com] Mark Colan “InfoBus 1.2 Specifications” - Febbraio 1999 [MokaByte www.mokabyte.it] Marco Fabbri “Domino R5, eSuite e Java ” MokaByte numero 34 - Ottobre 1999 [MokaByte www.mokabyte.it] Giovanni Puliti “La programmazione di Lotus Domino in Java” MokaByte numero 31 - Giugno 1999

[MokaByte www.mokabyte.it] Olindo Pindaro “Corba & Java, Una accoppiata vincente per l’integrazione di sistemi eterogenei (PARTE 1)” MokaByte numero 18 - Aprile 1998

[MokaByte] Alessandro Bemporad “GIOP / IOPP sull’autostrada di CORBA” - MokaByte numero 25 - Dicembre 1998

Tesi - Realizzazione di un'applicazione per il monitoraggio degli accessi a pagine Web

Documents

Transcript of Tesi - Realizzazione di un'applicazione per il monitoraggio degli accessi a pagine Web