2. La biblioteca digitale OpenDLib
L’obiettivo di qesta tesi è quello di costruire un’Interfaccia Utente per un sistema di Biblioteca Digitale implementato all’istituto CNR-I.S.T.I. di Pisa denominata OpenDLib.
“OpenDLib è un sistema costituito da una serie di servizi interagenti fra loro i quali implementano le funzionalità di una biblioteca digitale facendo operando alcune ipotesi sulla natura dei documenti da memorizzare e reperire. Il sistema di per sé può essere esteso se necessario con ulteriori servizi per soddisfare nuove esigenze.”[Rif-15]
I servizi che costituiscono OpenDLib debbono sottostare a delle regole e ad un modello architetturale formale, cosicché il sistema nel suo complesso manterrà sempre una struttura sistematica e ben definita. Queste regole sono state definite nella cosiddetta “OpenDLib DLSS architecture”.
In quanto servizio di OpenDLib, l’interfaccia utente che andremo a definire dovrà aderire al modello architetturale del sistema, del quale ora forniremo le specifiche.
User View of OpenDLib
System View of OpenDLib User
Authentication InformationSpace Search &Browse Consulting Options &Helpers
Profile
Databases CollectionDatabases InformationCatalog DaocumentDatabases DatabsesObject Authentication User Settings ... Collections Save Spaces ... Simple Search Advanced Search Search Options ... Document View Save Resultsets Marking Relevant ... Modify Profile Rappresentation Add/Remove Objs Language Settings ...
OpenDLib Services Instances OpenDLib Components Remote System Connection OLP Common Common Libraries Config Instance Config Params
Main Services Initialization Services Mass Storage HD Browse Info QM UI OS Collecction LibMgt Registry ES Index Meta Repository US
2.1 The OpenDLib Model
L’OpenDLib Model specifica le possibili configurazioni del Sistema, ovvero le biblioteche digitali che possono essere create con tale modello e le loro possibili evoluzioni future.
Una architettura basata su tale modello, utilizza preconcetti fondamentali: servizio (e sue specializzazioni), Server e Regione. Un Server è un network device capace di fornire servizi agli utenti della rete gestendo le risorse condivise. Questi può ospitare differenti istanze di servizio. Una Regione è una nozione astratta con la quale viene indicato un insieme dinamico di istanze di servizio le quali coprono l’intero set di funzionalità della biblioteca digitale e la quale rappresenta la configurazione ottimale in base ad alcuni criteri possibili, come ad esempio la mutua interconnessione dei servizi. Una Regione è costituita dell’intero insieme di servizi Centralizzati e Distribuiti (vedi definizione nei paragrafi seguenti) ed un insieme di istanze di servizi Replicati, uno per ogni tipo di servizio. Per ogni Regione, l’insieme di istanze dei servizi Replicati muta nel tempo in modo tale da implementare la scelta migliore per la configurazione attuale, ad esempio in accordo allo stato delle connessioni.
Qualsiasi configurazione che rispetta tale criterio, è ammissibile per l’OpenDLib Model, e costituisce una biblioteca digitale OpenDLib.
un’istanza di servizio con il Server che lo ospita, e una Regione sia con le istanze correnti del servizio che con tutte le possibili alternative. Queste relazioni indicano che è possibile sostituire le istanze correnti del servizio con le possibili alternative, qualora il criterio di ottimizzazione non sia più soddisfatto.
Per ogni Regione possono essere indicate ovviamente più di una alternativa, pertanto un valore di Priorità è associato ad ogni coppia (Regione, Istanza di servizio) come misura. Il servizio con la priorità maggiore appartiene alla Regione.
Notare che la stessa Istanza di servizio può appartenere nonché essere alternativa di più di una Regione. Ciò significa che il numero di repliche possono essere scelte liberamente e non sono vincolate al numero di Regioni costituite.
In figura, l’Entità “Architecture” rappresenta una biblioteca digitale creata dall’istanziazione di un Sistema OpenDLib. Ogni biblioteca digitale ha un nome ed è in relazione con le entità “HasMeta” e “Service”, le quali ne specificano la distribuzione e le funzionalità. La relazione “HasService” esprime la composizione della federazione dei servizi, cioè le istanze di servizio le quali nell’insieme forniscono tutte le specifiche funzionalità della biblioteca digitale in questione; “HarRegion” modella l’organizzazione delle istanze di servizio in un gruppo di servizi in grado di soddisfare un certo criterio di ottimizzazione; “HasMeta” identifica i servizi che controllano l’architettura e sono responsabili nel tempo per la sua consistenza.
Notare che l’unico vincolo sul numero di partecipanti alle relazioni consta nel minimo sufficiente a garantire l’integrità delle funzionalità della biblioteca digitale. Ciò significa che l’Architettura di una biblioteca digitale OpenDLib è completamente flessibile in termini di numero di istanze di servizio, Regioni e Server. Ognuna di queste possono essere liberamente scelte quando la biblioteca digitale viene creata e possono essere modificate dinamicamente durante la sua intera esistenza.
Notare inoltre che il Modello non impone alcun vincolo sulla tipologia di servizi che possono essere implementati dalla federazione.
Le Entità rappresentate in figura, tuttavia, sono soggette ad alcune regole che debbono essere soddisfate in ogni stato dell’Architettura OpenDLib. Un paio di tali regole sono riportate brevemente come esempio illustrativo.
Regola 1:
Il Query Mediator Service è parametrico in base al tipo di ricerca supportata, al linguaggio di interrogazione, ai formati dei metadata, ed al formato dei ResultSet restituiti. Tutte le istanze replicate del Query Mediator Service utilizzabili in una Regione debbono selezionare lo stesso tipo di ricerca, formati del ResultSet, e lo stesso sotto-insieme per il formato dei metadati gestiti dalle istanze del Repository Service. Come conseguenza di ciò, differenti istanze del Query Mediator Service possono solo offrire differenti tipi di ricerca, o tornare differenti tipi di ResultSet solo se queste appartengono a differenti Regioni;
Regola 2:
L’Index Service è distribuito e parametrico in base al criterio di distribuzione, ai motori di recupero dati supportati, ai formati di metadata, ecc… Chiaramente un’istanza dell’Index Service deve gestire un formato di metadato che sia usato dall’intero insieme di istanze del Repository Service identificate dallo specifico criterio di distribuzione. Tuttavia, poichè è replicato, tutte le istanze dell’Index Service raggiungibili in una Regione debbono riferire agli stessi formati di ResultSet ed agli stessi campi indicizzati. Come conseguenza, solo un’istanza dell’Index Service con la stessa configurazione può essere istanziata come replica dell’istanza principale.
2.2 OpenDLib: Modello Architetturale
Il processo di implementazione di OpenDLib risulta molto complesso a causa dei requisiti imposti dal concetto di DLSS. Prima di tutto è necessario comprendere come i vari servizi devono cooperare al fine di fornire tutte le funzionalità richieste. Oltre a questo si vuole anche che il sistema sia parametrico così da prevedere una possibile personalizzazione. Il sistema deve anche essere modificabile dinamicamente in modo da soddisfare dei criteri di qualità quali performance, tolleranza all’errore, ecc….
Il primo passo per cercare di gestire tale grado di complessità, consiste nel definire un modello identificato come OpenDLib Model[Rif-16]. Questo modello permette di progettare in maniera sistematica sia i servizi che i protocolli.
Le architetture di biblioteche digitali che possono essere create utilizzando OpenDLib DLSS sono specificate da un modello teorico. Questo modello
progettazione e la semantica che governa la loro coesistenza e cooperazione. Il modello è costituito da tre componenti <S, F, P>:
• S : modella le classi più significative di oggetti dell’Universo Architetturale di OpenDLib. Ogni classe è rappresentata da un insieme di elementi.
• F : rappresenta gli attributi associati ad ogni classe. Ogni attributo è modellato da una funzione definita nell’insieme associato alla classe stessa.
• P : modella le proprietà che appartengono ai diversi elementi dell’universo. In questo modello, possiamo distinguere un kernel, il quale modella gli elementi di base dell’architettura di OpenDLib DLSS e le loro istanze, ad esempio Repository, Index, ecc…. Il kernel definisce la struttura dedicata alla gestione dei servizi. La specifica dei tipi di servizi modella la classe specifica di servizi implementata da OpenDLib. Tale specifica può essere estesa per rappresentare versioni più avanzate di OpenDLib, cioè versioni contenenti nuovi tipi di servizi.
2.3 L’architettura del Kernel
I servizi ed i Server sono gli elementi basilari di una architettura OpenDLib. Un servizio è un blocco che contribuisce all’implementazione delle funzionalità del DLSS; un server è una periferica di rete in grado di fornire servizi agli utenti della rete e di gestire le risorse condivise.
Due dati insiemi, servizi e Server, modellano queste classi di elementi architetturali. Un certo numero di funzioni sono definite sopra questi insiemi per rappresentare gli attributi associati a questi elementi di base. Ne vediamo l’elenco qui sotto S F P Services serviceTypeName server_url textualDescription submissionProcedure harvestingProcedure managerServiceURL useRestrictions protocolVersion adminEMail verbsInfo url base y s Servers s url server y x w k url server w z k x eName serviceTyp y z y x w k z y x _ ) , ( _ ) , ( _ ) , ( ), , ( ) , ( ), , ( | , , , ,
Servers base_url capacity
Il formato della descrizione che caratterizza ogni servizio è definito in accordo agli attributi associati alla classe servizi. Questa descrizione è la specifica del servizio che è disseminato agli altri servizi su richiesta. Questa fornisce differenti tipi di informazioni a proposito del servizio. Per esempio, specifica le informazioni necessarie all’identificazione del servizio, sercieTypeName e server_url; informazioni che descrivono le funzionalità del servizio, verbsInfo e protocolVersion; ed informazioni su come il servizio può essere utilizzato, useRestrictions.
I server sono identificati tramite il loro indirizzo espresso da un paio di valori (url, http_port), chiamato base_url per comodità. Ogni server può ospitare diversi servizi di tipo differente. Un server è caratterizzato da una certa capacità computazionale chiamata capacity, che rappresenta anche il numero medio di sessioni contemporanee che è in grado di gestire, quindi indipendente dai servizi che ospita. Tuttavia molti altri attributi possono essere introdotti per descrivere i server[Rif-17], ma questa versione di OpenDLib utilizza questi valori per ottimizzare la distribuzione dei servizi e dei server.
Le istanze di servizi e Server sono decisi quando il DLSS è istanziato. I servizi scelti definiscono le funzionalità implementate dalla DL, i servers specificano la loro distribuzione fisica.
I servizi OpenDLib possono essere centralizzati o distribuiti e/o replicati. Questo significa che possono esserci istanze multiple di servizi nell’architettura che offrono le stesse funzionalità. Per ogni istanza, la funzione serviceTypeName specifica il tipo del servizio, ovvero la classe di funzionalità.
Il Modello OpenDLib rappresenta i servizi centralizzati, distribuiti e replicati come un sottoinsieme dell’insieme dei servizi.
S F P plicated d Distribute d Centralize Services= Re Centralized w k eName serviceTyp w y k x y x d Centralize y x w k y x plicated d Distribute d Centralize Services d Centralize = ) , ( ), , ( , | , , , ) Re (
Replicated dInput Distribute dInput Centralize NoInput plicated Services plicated = Re Re NoInput = ) ( Re dInput Distribute dInput Centralize NoInput plicated NoInput Centralized Input c_masterYesNo c_masterURL w z eName serviceTyp z y w x o masterYesN c yes y yes x y x dInput Centralize y x z w y x dInput Distribute NoInput dInput Centralize plicated dInput Centralize = ) , ( ), , ( _ ) ' ', ( ), ' ', ( , | , , , ) ( Re Distributed Input d_masterYesNo d_masterURL instancesSet w z eName serviceTyp z y w x o masterYesN c yes y yes x y x dInput Distribute y x z w y x dInput Centralize NoInput dInput Distribute plicated dInput Distribute = ) , ( ), , ( _ ) ' ', ( ), ' ', ( , | , , , ) ( Re
I servizi Centralizzati sono quei servizi che devono essere montati (istanziati) in esattamente un server per ogni OpenDLib DL. Solitamente un servizio è centralizzato quando la sicurezza e la privacy dei suoi contenuti costituiscono un obbiettivo.
I servizi Distribuiti sono quei servizi in grado di implementare funzionalità per mezzo di istanze multiple, ognuna delle quali è gestita da un server differente. Notare che le diverse istanze di un servizio sono indipendenti, ovvero non sono a conoscenza l’una dell’altra.
I servizi Replicati sono quei servizi che implementano delle funzionalità tramite un insieme di istanze, ed ogni istanza è in grado di coprire completamente le funzionalità del servizio sull’intero contenuto.
Il modello OpenDLib distingue fra tre diversi tipi di servizi Replicati:
- NoInput : sono mere copie l’uno dell’altro, ovvero le diverse istanze sono
indistinguibili, in quanto gestiscono lo stesso insieme di dati nella stessa maniera.
- CentralizedInput : hanno una sola replica principale, e un insieme di repliche
che agiscono da supporti. La replica principale è un’istanza speciale del servizio la quale ha il solo scopo di mantenere e distribuire le informazioni aggiornate inerenti al servizio su richiesta. Le altre repliche aggiornano i loro contenuti tramite delle richieste periodiche alla replica principale. I ruoli delle
repliche non sono staticamente assegnati, ma possono cambiare dinamicamente per venire incontro a problemi quali crash ecc…. Le funzioni che regolano i ruoli sono c_masterYesNo, che indica se la replica è principale o meno, e c_masterURL che identifica l’istanza principale.
- DistributedInput : questi servizi pure hanno una sola replica, che agisce da
master, ed un insieme di repliche che agiscono da slaves. Entrambe tuttavia sono in grado di accettare nuove informazioni e asservire a nuove richieste. Il master si occupa di mantenere lo stato generale del servizio: ogni qualvolta avviene un cambiamento su uno slave, questo viene comunicato al master. Come nel caso precedente, i ruoli possono cambiare dinamicamente.
Ogni servizio replicato può appartenere ad una sola delle tre classi precedenti.
2.4 I Tipi di servizio
La versione attuale di OpenDLib fornisce un insieme di servizi che abbracciano tutte le funzionalità di base per una biblioteca digitale come l’acquisizione, la descrizione, la memorizzazione, la ricerca, la visualizzazione, la selezione e lo smistamento dei documenti, l’autorizzazione e l’autenticazione degli utenti[Rif-18]. Altri servizi possono essere aggiunti a questo insieme per creare delle biblioteche digitali più complete e più potenti, purché questi soddisfino sempre le regole imposte dall’architettura del Kernel.
Riportiamo ora un elenco dei servizi disponibili con una breve descrizione:
S F P Repository contentDescription authorities sets metadataFormats documentStructure d Distribute pository Re Multimedia
Storage compositeDocumentFormats nonCompositeDocumentFormats multimediaDocumentFormats d Distribute Storage Multimedia Library Management authority set documentStructure d Distribute agement LibraryMan
Index metadataFormat indexedFields resultFormats language plicated Index d Distribute Index Re Query Mediator searchMethods resultFormats plicated tor QueryMedia Re Manager serviceDescriptionFormat Manager Replicated Browse metadataFormat browsableFields resultFormats plicated Browse Re Registry userProfileFormat
groupProfileFormat Registry Centralized Collection collectionMetadataFormat Collection Replicated User
Interface
Frameset UserInterface Replicated
2.5 Il Protocollo di OpenDLib
Un servizio chiamato Manager, mantiene uno stato sempre aggiornato di tutti i servizi, e ne dissemina le informazioni su richiesta a tutti gli altri, in più c’è un insieme di richieste comuni ed indipendenti per ogni servizio atte a descrivere lo stato e le funzionalità di ognuno.
Il Manager raccoglie tutte le informazioni sui servizi spedendo periodicamente delle richieste appropriate alle varie istanze della federazione di servizi. Dopodiché elabora le informazioni acquisite e prende le eventuali decisioni sull’organizzazione dei servizi, come ad esempio i percorsi di comunicazione. Tali decisioni possono cambiare nel tempo in accordo al cambiamento dei valori di differenti parametri, come ad esempio il carico di lavoro dei server o lo stato della connessione. Di contro, quando un servizio viene inizializzato, acquisisce le necessarie informazioni dal Manager per auto-configurarsi. I servizi, inoltre, chiedono periodicamente al Manager informazioni sull’organizzazione della federazione e sullo stato delle altre istanze. Sfruttando tali informazioni, ogni servizio acquisisce la necessaria conoscenza sugli altri per iniziare la cooperazione richiesta per rispondere alle richieste degli utenti della biblioteca digitale.
Tutte queste comunicazioni avvengono tramite l’OLP (Open Digital Library Protocol). Il protocollo definisce il formato standard dei dati scambiati fra due servizi, inclusa la sintassi dei messaggi, il set dei caratteri e la sequenza dei messaggi. Non specifica nulla su come i servizi debbano preparare le risposte e sul linguaggio di
programmazione nel quale essi sono scritti. L’obiettivo del protocollo è quello di fornire l’infrastruttura necessaria per l’interoperabilità fra i vari servizi, allo stesso tempo permettendo l’aggiunta di nuovi servizi in maniera molto semplice.
Le richieste del protocollo OLP sono inserite nell’HTTP e le risposte sono in formato XML. La specifica completa del protocollo OLP può essere trovata nel rapporto tecnico “OLP: The Open Digital Library Protocol”[Rif-19].
È possibile distinguere tre classi di richiesta di informazioni nel protocollo:
• OLP_Config
Queste sono le richieste di protocollo implementate dal Manager per disseminare le informazioni relative alla federazione dei servizi attivi ed alla configurazione di tutti i servizi Replicati necessaria per mantenere consistente l’infrastruttura di OpneDLib. Esse includono tutte le richieste necessarie alla configurazione dei servizi, all’identificazione dei loro indirizzi e allo scambio delle meta-informazioni fra essi.
• OLP_Explain
Queste richieste sono implementate da ogni servizio. Esse forniscono informazioni sullo stato e sul contenuto del singolo servizio a tutti i servizi della federazione.
• OLP_Service_Specific
Queste sono richieste dipendenti dal singolo servizio e relative alla specifica funzionalità di ciascuno.
Le richieste inerenti il protocollo OLP_Config, sono fornite dal servizio Manager. Tutte le altre devono essere formulate sistematicamente lavorando sul modello architetturale del kernel di OpenDLib. Pertanto per ogni elemento appartenente all’insieme S, deve essere introdotta una richiesta che dissemina gli elementi dell’insieme stesso.
