Dottorato di Ricerca in Telematica e società dell'informazione XXII ciclo. Presentazione di Fine II Anno

Transcript

1 Università degli Studi di Firenze Facoltà di Ingegneria Dipartimento di Elettronica e Telecomunicazioni Dottorato di Ricerca in Telematica e società dell'informazione XXII ciclo Presentazione di Fine II Anno Candidato Davide Chini Tutori Prof. Dino Giuli Prof. Franco Pirri Ing. Maria Chiara Pettenati

2 Outline Background Attività di ricerca Contributo predominante su InterDataNet Progettazione sistema dei nomi Revisione materiale prodotto negli anni e dello stato del progetto Supervisione di tesi di laurea / tesine corso Telematica Replicazione / Sistema dei nomi / Filesystem Pubblicazione articoli scientifici Pianificazione del lavoro futuro 2/41

3 Research Activity laurea in Ingegneria delle Telecomunicazioni ambito della tesi sottosistema del progetto InterDataNet (versioning) 3/41

4 Research Activity laurea in Ingegneria delle Telecomunicazioni ambito della tesi sottosistema del progetto InterDataNet (versioning) primo anno di dottorato di ricerca frequentazione dei corsi del dottorato visione interdisciplinare approccio sistemico InterDataNet visione globale 4/41

5 Research Activity laurea in Ingegneria delle Telecomunicazioni ambito della tesi sottosistema del progetto InterDataNet (versioning) primo anno di dottorato di ricerca frequentazione dei corsi del dottorato visione interdisciplinare approccio sistemico InterDataNet visione globale secondo anno di dottorato presa in carico la progettazione di un servizio sistema dei nomi supervisione evoluzione globale del progetto 5/41

6 InterDataNet We propose as a Distributed System that can provide a middleware platform for the Web of Data IDN is an interdataworking middleware providing the services needed for granular data management (sharing, authoring, etc.) in a distributed environment (Web-Wide scale) 6/41

7 InterDataNet InterDataNet has been designed using the following set of conceptual and technological design patterns: the Service Oriented Architecture (SOA) approach which allows us to develop loosely coupled and interoperable services which can be combined into more complex systems although SOA is commonly implemented using Web Services, Web Service-based architectures and technologies are too specific and concrete to be part of our general design pattern even if it can be used during the implementation phase 7/41

8 InterDataNet InterDataNet has been designed using the following set of conceptual and technological design patterns: the use of REST style (REpresentational State Transfer) services to make InterDataNet an explicit resource-centric infrastructure. As a consequence: communication should be stateless resources have to be cacheable the system has to expose an uniform interface each resource has to be global addressable through URIs the system handle resources through their representations resource representations can contain links to browse through the application states 8/41

9 InterDataNet The IDN framework is defined by three entities: IDN-IM (IDN Information Model): is the shared information model representing a generic document model IDN-SA (IDN Service Architecture): is the architectural model handling IDN-IM documents. It exposes an IDN-APIs (Application Programming Interfaces) on top of which IDN-compliant Applications can be developed IDN Compliant Applications 9/41

10 IDN-IM: Basic Concepts Generic information modelled in IDN is formalized as an aggregation of elementary data units, named primitive information units (P.I.U.s) Primitive information units contain generic data and metadata NodeTypes embed the primitive information-unit schema defining the application-level properties contained in the node 10/41

11 IDN-IM: Basic Concepts A primitive information unit is a node in a directed graph An IDN-document structures information units and it is recursively composed of nodes related to each other only through aggregation links (no cycles DAG) * numbers (near to the links) are the link names 11/41

12 IDN-IM: Basic Concepts Reference links express relations between distinct IDN-documents Cross references (therefore creating cycles in the graph) between documents are handled by IDN applications. This is done through a third type of link, named: IDN-Application-level link * numbers (near to the links) are the link names 12/41

13 IDN-IM: Node Names A canonical identifier is assigned to nodes when they are initially allocated Users can assign one or more aliases to the same node Finally, IDN-IM node names are hierarchical and each name reflects the IDN-DAG structure Each name has the structure: Where: parent_node_name + / + link_name parent_node_name is the name of the parent node + is the concatenation operator between strings link_name is the name of the link that connects the parent to the node to be addressed IDN-IM 13/41

14 IDN-IM: Node Names 0 Type:A names: path/0/ 5 Type:A names: path/0/5 Type:B names: path/0/ Type:C names: path/0/2 Type:A names: path/0/5/6 6 6 Type:A names: path/0/5/6 Type:A names: path/0/1/3 path/0/2/4 IDN-IM 14/41

15 IDN-APIs IDN-IM APIs include: Basic Functions: access, create, modify and remove nodes and documents; add/remove node types, define node types, check types constraints Identity Management: user login/logout, add/remove users, access rights management Naming and Navigation Functions: add/remove names, browse and search nodes Replication Functions: enable, disable, configure primitive information units replication policies 15/41

16 IDN-APIs IDN-IM APIs include: Versioning Management: branch, merge and history browsing Workflow Management: define node states and lifecycle, define state transitions, execute transitions Notification Management: notify registered applications about events related to changes in nodes properties and/or states Concurrency Management: locking and unlocking nodes 16/41

17 IDN-Service Architecture (SA) 17/41

18 IDN-SA Layers Storage Interface (SI): provides the data storage service Storage systems often depend on the specific platform (hardware and software) and they can be native storage or legacy systems It provides a REST-like uniform view over distributed data through URL names. It provides create, read, update and delete functions of URL-addressed resources Replica Management (RM): provides a delocalized view of resources and the resource replication service Upper layer can handle only univocal and persistent identifiers It associates several physical resources to the same identifier and these resources are replicas of the same logical information 18/41

19 IDN-SA Layers Information History (IH): manages primitive information units history Navigation into the history is consequently allowed as a result of the services provided by this layer Virtual Repository (VR): is seen by the applications as the container-repository of all primitive information units It exposes the IDN APIs to the IDN-compliant Applications It provides the maximum abstraction of structured information to the application IDN-Compliant Applications: implement the contextdependent business logic and provide the user interface (they can be multi-tier applications) 19/41

20 IDN Names: Towards Global Data Addressability IDN architecture provides a three-layer naming system: Human Friendly Names (HFNs) are flexible and descriptive names easily interpretable by people Uniform Resource Names (URNs) are defined in the IDN middleware environment and they unambiguously, univocally and persistently identify the resources independently of their physical locations Uniform Resource Locators (URLs) identify resource replicas and allow us to access to them 20/41

21 IDN Naming System Scalability All names are sub-classes of the URIs and they are hierarchical. Their direct and inverse resolution is possible using DNS-like systems This allows scalability as well as hierarchical and local delegation of responsibility in the collaborative creation, management and access to data. This enables data global addressability LDNS tree example zone 1 top zone W1 W3 W2 W3 W5 W3 W4 W6 W7 zone 4 zone 2 zone 3 W9 W8 zone 5 IDN-SA 21/41

22 InterDataNet Middleware IDN Naming System IDN Compliant Application IDN APIs Virtual Repository Layer IDN-IM names [+ version param.] LRIs [+ version param.] HFN Information History Layer Replica Management Layer PRIs [+ version param.] PRIs URN Storage Interface Layer URL URL Filesystem, database, etc. HTTP(S), SMTP(S), FTP(S), etc. Platform dependent local names Three layers IDN naming system Generic storage architecture Generic network communication architecture IDN-SA Spazi di nomi in IDN-SA IDN naming system num. spazi di nomi num. di layers del naming system??? 22/41

23 InterDataNet Middleware IDN Naming System IDN Compliant Application IDN APIs Virtual Repository Layer IDN-IM names [+ version param.] LRIs [+ version param.] LDNS HFN Information History Layer Replica Management Layer PRIs [+ version param.] PRIs LS URN Storage Interface Layer URL URL Filesystem, database, etc. HTTP(S), SMTP(S), FTP(S), etc. Platform dependent local names Three layers IDN naming system Generic storage architecture Generic network communication architecture Il naming system risolve il problema della global addressability Sono definite 3 classi di nomi: HFN, URN ed URL 23/41

24 InterDataNet Middleware IDN Naming System IDN Compliant Application IDN APIs Virtual Repository Layer IDN-IM names [+ version param.] LRIs [+ version param.] LDNS HFN Information History Layer Replica Management Layer PRIs [+ version param.] PRIs LS URN Storage Interface Layer URL URL Filesystem, database, etc. HTTP(S), SMTP(S), FTP(S), etc. Platform dependent local names Three layers IDN naming system Generic storage architecture Generic network communication architecture Appl. e VR usano nomi nella stessa classe (HFN) Appl. definisce i propri nomi, ma deve convertirli in LRI 24/41

25 InterDataNet Middleware IDN Naming System IDN Compliant Application IDN APIs Virtual Repository Layer IDN-IM names [+ version param.] LRIs [+ version param.] LDNS HFN Information History Layer Replica Management Layer PRIs [+ version param.] PRIs LS URN Storage Interface Layer URL URL Filesystem, database, etc. HTTP(S), SMTP(S), FTP(S), etc. Platform dependent local names Three layers IDN naming system Generic storage architecture Generic network communication architecture Esempio: i namespace di XML. Normalmente in XML viene dichiarato il namespace e l'utente lavora solo con la parte definita localmente, ma il nome vero degli elementi è la somma dei due (semplice trucco a livello applicativo) 25/41

26 InterDataNet Middleware IDN Naming System IDN Compliant Application IDN APIs Virtual Repository Layer IDN-IM names [+ version param.] LRIs [+ version param.] LDNS HFN Information History Layer Replica Management Layer PRIs [+ version param.] PRIs LS URN Storage Interface Layer URL URL Filesystem, database, etc. HTTP(S), SMTP(S), FTP(S), etc. Platform dependent local names Three layers IDN naming system Generic storage architecture Generic network communication architecture Risoluzione tramite sistema di nomi dedicato: LDNS 26/41

27 InterDataNet Middleware IDN Naming System IDN Compliant Application IDN APIs Virtual Repository Layer IDN-IM names [+ version param.] LRIs [+ version param.] LDNS HFN Information History Layer Replica Management Layer PRIs [+ version param.] PRIs LS URN Storage Interface Layer URL URL Filesystem, database, etc. HTTP(S), SMTP(S), FTP(S), etc. Platform dependent local names Three layers IDN naming system Generic storage architecture Generic network communication architecture Risoluzione algoritmica del parametro di versione Lavoro svolto durante la tesi di laurea 27/41

28 IDN Naming System 28/41

29 InterDataNet Middleware IDN Naming System IDN Compliant Application IDN APIs Virtual Repository Layer IDN-IM names [+ version param.] LRIs [+ version param.] LDNS HFN Information History Layer Replica Management Layer PRIs [+ version param.] PRIs LS URN Storage Interface Layer URL URL Filesystem, database, etc. HTTP(S), SMTP(S), FTP(S), etc. Platform dependent local names Three layers IDN naming system Generic storage architecture Generic network communication architecture Risoluzione tramite sistema di nomi dedicato: LS 29/41

30 InterDataNet Middleware IDN Naming System IDN Compliant Application IDN APIs Virtual Repository Layer IDN-IM names [+ version param.] LRIs [+ version param.] LDNS HFN Information History Layer Replica Management Layer PRIs [+ version param.] PRIs LS URN Storage Interface Layer URL URL Filesystem, database, etc. HTTP(S), SMTP(S), FTP(S), etc. Platform dependent local names Three layers IDN naming system Generic storage architecture Generic network communication architecture Conversione platform-dependent Esempi: < URL nome di file > < URL query SQL > 30/41

31 InterDataNet Middleware IDN Naming System IDN Compliant Application IDN APIs Virtual Repository Layer IDN-IM names [+ version param.] LRIs [+ version param.] LDNS HFN Information History Layer Replica Management Layer PRIs [+ version param.] PRIs LS URN Storage Interface Layer URL URL Filesystem, database, etc. HTTP(S), SMTP(S), FTP(S), etc. Platform dependent local names Three layers IDN naming system Generic storage architecture Generic network communication architecture Riassumendo: uno spazio di nomi per livello un meccanismo ad-hoc per la risoluzione per ogni spazio 31/41

32 Implementazione del sistema dei nomi Approccio Oasis: XDI/XRI XDI/XRI Web Internet Definisce una modalità di identificazione e di risoluzione di nomi che si pone ad un livello di astrazione più alto rispetto al DNS Permette di indirizzare nomi sia persistenti che non persistenti Intende superare i limiti del Web attuale circa l'interscambio di dati distribuiti 32/41

33 Implementazione del sistema dei nomi Approccio Oasis: XDI/XRI Punti chiave di XDI: Link: collegamenti per il controllo del flusso dei dati (Link contracts) Addressing: indirizzamento tramite gli identificatori XRI i-numbers: identificatori machine-friendly associati ad una risorsa (persona, organizzazione, file, progetto digitale, ecc.), e non riassegnabili i-names: identificatori human-friendly che possono essere trasferiti o riassegnati dall'utente verso altre risorse. Representation: definizione di un formato per lo scambio, linkaggio e sincronizzazione di dati codificati in XML 33/41

34 Implementazione del sistema dei nomi Approccio Oasis: XDI/XRI L'analisi ha portato ad accantonare l'approccio Oasis, perché: teoricamente l'architettura XDI/XRI è stata sviluppata, ma all'atto pratico è risultata scarsamente implementata molta teoria e poca pratica semplificazione eccessiva rispetto alla complessità del problema con conseguente difficoltà di concretizzazione elementi fondamentali quali i link contracts non implementati difficoltà nella realizzazione di entità fondamentali sono ancora oggetto di studio questioni importanti (es. ISCP per l'update dinamico dei dati nei server dei nomi) lacuna concettuale nello scenario in cui si propongono non è possibile non prevedere dall'inizio l'update dinamico dei server dei nomi 34/41

35 Implementazione del sistema dei nomi Approccio Tim Berners-Lee: Linked Data Use URIs as names for things Use HTTP URIs so that people can look up those names When someone looks up a URI, provide useful information Include links to other URIs, so that they can discover more things L'analisi in corso sta portando verso un'implementazione di questo tipo. I motivi principali sono, perché: è semplice si integra nativamente con il legacy è veloce da realizzare in quanto permette l'uso di tecnologie preesistenti 35/41

36 Obiettivi a medio/lungo termine Progettazione di dettaglio e implementazione: selezione e affinamento degli standard tecnologici del sistema dei nomi con approccio Linked Data 36/41

37 Obiettivi a medio/lungo termine Progettazione di dettaglio e implementazione: selezione e affinamento degli standard tecnologici del sistema dei nomi con approccio Linked Data dei vari livelli Semantic Web approfondimenti teorici Isomorfismo fra IDN-IM ed RDF? applicazioni semantiche su IDN Definizione e test di applicazioni IDN-Compliant, ad esempio: file system distribuito basato su IDN applicazioni nel settore e-government 37/41

38 Pubblicazioni Best Paper, area Semantic Web: Interdatanet: A web of data foundation for the semantic web vision IADIS International Conference WWW/Internet /41

39 Pubblicazioni Best Paper, area Semantic Web: Interdatanet: A web of data foundation for the semantic web vision IADIS International Conference WWW/Internet 2007 Ci è stato richiesto di produrre una versione estesa per la rivista IADIS INTERNATIONAL JOURNAL ON WWW/Internet (verrà pubblicata nella second issue 2008) 39/41

40 Università degli Studi di Firenze Facoltà di Ingegneria Dipartimento di Elettronica e Telecomunicazioni Dottorato di Ricerca in Telematica e società dell'informazione XXII ciclo Presentazione di Fine II Anno Candidato Davide Chini Tutori Prof. Dino Giuli Prof. Franco Pirri Ing. Maria Chiara Pettenati