Seminario di Ingegneria del software

1. Seminario di Ingegneria del software Studio della composizione di servizi attraverso l’uso di tecniche del data integration Autore: Paolo Urbano Docente: Giuseppe De Giacomo

2. • A View Integration Approach to Dynamic Composition of Web ServicesSnehal Thakkar, Craig Knoblock and José Luis AmbiteWorkshop on Planning for Web Services, The 13th International Conferenceon Automated Planning & Scheduling (ICAPS 2003), Trento, Italy, 2003. • A Data Integration Approach to Automatically Composing and OptimizingWeb ServicesSnehal Thakkar, José Luis Ambite and Craig A. KnoblockIn Proceeding of 2004 ICAPS Workshop on Planning and Scheduling for Web and Grid Services, June 2004. • Composing, optimizing, and executing plans for bioinformatics web services,Snehal Thakkar, Jose Luis Ambite, and Craig A. Knoblock.VLDB Journal, Special Issue on Data Management, Analysis and Mining forLife Sciences, 14(3):330--353, Sep 2005. • Retrieving and Semantically Integrating Heterogeneous Data from the Web.Martin Michalowski, José Luis Ambite, Craig A. Knoblock, Steve Minton,Snehal Thakkar, and Rattapoom TuchindaIEEE Intelligent Systems., Vol. 19, No. 3, 2004, pp. 72-79.

3. Introduzione • Il potenziale dei web services può essere sfruttato solo se si effettua la composizione dei servizi. • In questo approccio vediamo i web services come sorgenti di dati. • I primi tre articoli fanno uso di tali principi: i primi due illustrano le idee fondamentali e il terzo è un esempio di applicazione al dominio bioinformatico. • La composizione completamente automatica di servizi, in risposta ad una query utente arbitraria, rimane un problema aperto.

4. A View Integration Approach to Dynamic Composition of Web Services (/1) • Scopo: generare un piano d’integrazione universale di web service per rispondere alle query utente. • Il Mediatore è l’oggetto che costruisce il piano d’integrazione. • Il Mediatore tradizionale accetta in input una specifica query utente q e la riformula come combinazione di query alle sorgenti per rispondere a q, utilizzando un algoritmo di riformulazione di query. • In questo articolo modifichiamo l’inverse rule algorithm per produrre un web service integrato che possa rispondere ad un range di query.

5. A View Integration Approach to Dynamic Composition of Web Services (/2) Esempio conduttore: Ogni web service è rappresentato come un predicato: CitytoCounty(city’, state’, county) LAProperty(address’, city, value) NYProperty(address’, city’, county, value) YellowPages(name’, city’, state, address, phone) Gli attributi apostrofati sono richiesti come input del servizio, sugli altri non vi è nessun tipo di restrizione. Query utente: Trova il valore fiscale delle proprietà di tutte le ubicazioni ‘Burger King’ nella città di ‘Torrance’ nello stato della California (‘CA’).

6. A View Integration Approach to Dynamic Composition of Web Services (/3) • Passi fondamentali: 1) Query utente  Insieme di query datalog 2) Insieme di query datalog  Theseus Theseus è un meccanismo di esecuzione di query che permette il parallelismo delle operazioni e l’invio di un flusso di dati tra i vari componenti del piano d’integrazione generato.

7. A View Integration Approach to Dynamic Composition of Web Services (/4) Predicati del Mediatore: Location(locid, address, city, county, state) Value(locid, value) Business(name, locid, phone) Definizione delle sorgenti (approccio LAV): R1: LAProperty(address, city, value):- Location(locid, address, city, county, state) ^ Value(locid, value) ^ county = ‘LA’^ state = ‘CA’ R2: NYProperty(address, city, county, value):- Location(locid, address, city, county, state) ^ Value(locid, value) ^ state = ‘NY’

8. A View Integration Approach to Dynamic Composition of Web Services (/5) R3: YellowPages(name, address, city, state, phone) :- Business(name, locid, phone)^ Location(locid, address, city, county, state) R4: CitytoCounty(city, state, county):- Locations(locid, address, city, county, state)

9. A View Integration Approach to Dynamic Composition of Web Services (/5) • La fase 1 consiste nell’invertire le definizioni delle viste per ottenere quelle delle relazioni globali sulle sorgenti: Per ogni definizione V(X) :- S1(X1),…,Sn(Xn), dove X e Xi si riferiscono all’insieme di attributi nelle relazioni e nelle viste corrispondenti, l’Inverse Rule Algorithm genera n regole del tipo: Si(Xi’) :- V(X), dove la differenza tra gli insiemi X’ e X è che in X’ ci possono essere simboli di funzione. R1: LAProperty(address, city, value):- Location(locid, address, city, county, state) ^ Value(locid, value) ^ county = ‘LA’^ state = ‘CA’  IR1: Location( f1locid(a, ci, v), a , ci, ‘LA’, ‘CA’) :- LAProperty(a, ci, v) IR2: Value(f1val(a, ci, v), v) :- LAProperty(a, ci, v)

10. A View Integration Approach to Dynamic Composition of Web Services (/6) La Fase 2 consiste nel trasformare l’insieme di regole datalog prodotte dalla Fase 1, unitamente alla query utente, nel linguaggio di Theseus: costruzione di moduli; ogni modulo rappresenta un’operazione; ogni operazione prende in input e restituisce in output un insieme di relazioni

11. InRel(name’, city’, state’, value) Corrisponde all’esecuzione della inverse rule Business(n, f1bus(n, a, ci, s, p), p):- YellowPages(n, ,a, ci, s, p) Corrisponde all’esecuzione delle inverse rule IR1 e IR2 Tutti i web service sulle tasse delle proprietà sono interrogati in parallelo.

12. A View Integration Approach to Dynamic Composition of Web Services (/7) Problema: • Il Mediatore deve generare un nuovo piano d’integrazione per ogni query utente, anche se, per esempio, cambiano solo i valori delle costanti. Idea: • Il Mediatore diventa un generatore di web service: accetta una query utente e genera un web service capace di rispondere ad una classe di query, alla quale apparitene anche la query data.

13. A View Integration Approach to Dynamic Composition of Web Services (/8) • Generalizzazione di una query: Le tecniche per generalizzare le query si basano, generalmente, sulle combinazioni degli attributi sui quali generalizzare. Qui viene utilizzata una “generalizzazione completa”, cioè una generalizzazione su tutti i parametri, la query diventa: ‘Trova i valori fiscali di tutte le proprietà di una certa attività in una data città di un certo stato.’

14. A View Integration Approach to Dynamic Composition of Web Services (/9) Problema derivante dall’uso di questa tecnica: • Il piano generato potrebbe inviare troppe richieste a molte sorgenti di dati. Idea: Tuple – Level Filtering Algorithm Con questa tecnica, ogni sorgente viene interrogata solamente per l’informazione presente nella sorgente stessa.

15. A View Integration Approach to Dynamic Composition of Web Services (/10) Risultano quindi necessarie due modifiche all’Inverse Rule Algorithm: • Le costanti vengono trattate come variabili per generalizzare la query (il piano risultante avrà la capacità di interrogare sia il web service relativo alle proprietà della contea di Los Angeles, sia quello relativo allo stato di New York). • Le sorgenti vengono interrogate solo con input validi (Il Los Angeles web service verrà interrogato solo per le proprietà di Los Angeles e Il New York web service solamente per quelle di Newy York); le interrogazioni alle sorgenti vengono filtrate utilizzando i vincoli presenti nelle definizioni delle sorgenti.

16. A View Integration Approach to Dynamic Composition of Web Services (/11) Risultato: Numero minore di interrogazioni e interrogazioni più ‘sensate’: • Per una specifica query, solo uno dei web service sulle tasse delle proprietà viene effettivamente interrogato; • Le interrogazioni sono filtrate oltre che dalle operazioni di select, anche da interrogazioni ad altre sorgenti che contengono informazioni che permettono di risparmiare ulteriormente.

17. Il Mediatore, a partire dal programma datalog, costruisce il piano d’integrazione che viene eseguito da Theseus. L’informazione sulle Tasse è ottenuta facendo uso anche del web service CityToCounty Il Mediatore restituisce all’utente l’URL del nuovo servizio generato

18. A Data Integration Approach to AutomaticallyComposing and Optimizing Web Services(/1) • La novità sostanziale di questo articolo è rappresentata dall’implementazione di metodi per ottimizzare l’esecuzione della composizione di web service • Oltre al funzionamento del Tuple – Level Filtering Algorithm, per ridurre il numero di richieste ai web service, sarànno utilizzate delle interrogazioni aggiuntive per ottimizzare ulteriormente l’esecuzione.

19. A Data Integration Approach to AutomaticallyComposing and Optimizing Web Services(/2) Oltre alle descrizioni delle sorgenti, vengono fornite al sistema, dall’esperto del dominio, le dipendenze funzionali, nel nostro caso, per esempio, consideriamo la dipendenza funzionale: <address, city, state>  <value> Avremo in input al Mediatore: FR1: equals(value, value’) :- BusinessProperties(name, addr, city, county, state, zip, phone, value)^ BusinessProperties(name’, addr’, city’, county’, state’, zip’, phone’, value’)^ equals(addr, addr’)^ equals(city, city’)^ equals(state, state’) FR2: equals(x, z) :- equals(x, y) ^ equals(y, z)

20. A Data Integration Approach to AutomaticallyComposing and Optimizing Web Services(/3) Consideriamo il programma datalog generato dal sistema: PR1: Q1(name, addr, city, cty, st, zip, ph, val):- YellowPages(name, zip, city, st, addr, ph)^ name = <name>^ LAProperty(addr, city, zip, val) PR2: Q1(name, addr, city, cty, st, zip, ph, val):- YellowPages(name, zip, city, st, addr, ph)^ name = <name>^ TNProperty(addr, city, cty, zip, val) Il Tuple Level – Filtering Algorithm fornisce al programma i valori dei parametri per effettuare le operazioni di filtraggio.

21. A Data Integration Approach to AutomaticallyComposing and Optimizing Web Services(/4) Passi fondamentali del Tuple – Level filtering Algorithm: • Analizza la lista delle chiamate di sorgente: • Per ogni definizione di sorgente esamina i vincoli: 1) Se il valore dell’attributo coinvolto è presente nel corpo di una Inverse Rule inserisce il vincolo di filtraggio 2) Altrimenti inserisci una ‘sensing operation’ per recuperare il valore del parametro

22. A Data Integration Approach to AutomaticallyComposing and Optimizing Web Services(/5) 1) L’algoritmo fa uso di vincoli di uguaglianza e di ordinamento per ridurre l’ampiezza delle query: TR1: Q1(name, addr, city, cty, st, zip, ph, val):- YellowPages(name, zip, city, st, addr, ph)^ name = <name>^ st = ‘CA’^ LAProperty(addr, city, zip, val) TR2: Q1(name, addr, city, cty, st, zip, ph, val):- YellowPages(name, zip, city, st, addr, ph)^ name = <name>^ st = ‘TN’^ TNProperty(addr, city, cty, zip, val)

23. A Data Integration Approach to AutomaticallyComposing and Optimizing Web Services(/6) 2) Il Mediatore può chiamare altri servizi per recuperare i valori degli attributi richiesti: sensing operation Il programma datalog ottimizzato include la chiamata al servizio CityToCounty per produrre il vincolo: County = ‘Los Angeles’ SR1: Q1(name, addr, city, cty, st, zip, ph, val):- YellowPages(name, zip, city, st, addr, ph)^ name = <name>^ st = ‘CA’^ CitytoCounty(city, st, cty)^cty = ‘Los Angeles’^ LAProperty(addr, city, zip, val) SR2: Q1(name, addr, city, cty, st, zip, ph, val):- YellowPages(name, zip, city, st, addr, ph)^ name = <name>^st = ‘TN’^ TNProperty(addr, city, cty, zip, val)

24. A Data Integration Approach to AutomaticallyComposing and Optimizing Web Services(/7) Risultati sperimentali Query: ‘Richiesta di creare un web service che accetta il nome di un’attività e fornisce la lista delle ubicazioni di tali attività e i loro valori fiscali’

25. A Data Integration Approach to AutomaticallyComposing and Optimizing Web Services(/8) • L’applicazione delle tecniche di ottimizzazione descritte ha ridotto il tempo di esecuzione di due ordini di grandezza. • In generale, il Tuple – Level Filtering Algorithm, con o senza sensing operation, è notevolmente efficace nei domini dove più attributi possono essere utilizzati per ridurre le richieste a differenti web service. Per esempio: integrare l’informazione proveniente dai giornali locali o dai produttori di automobili.

26. Composing, optimizing, and executing plansfor bioinformatics web services(/1) • Questo articolo descrive un’applicazione dei risultati precedenti al dominio bioinformatico. • Consiste nella composizione automatica di piani d’integrazione parametrizzati per web service di tipo informativo: il sistema crea un piano d’integrazione che accetta i valori dei parametri forniti in input, recupera ed integra l’informazione dai web service rilevanti e restituisce il risultato all’utente. • I valori dei parametri di input non sono noti al tempo di composizione del piano.

27. Composing, optimizing, and executing plansfor bioinformatics web services(/2) • Dominio: ci sono diversi web service, che modellano l’informazione sui vari tipi di proteine e sulle interazioni tra le proteine stesse:

28. Composing, optimizing, and executing plansfor bioinformatics web services(/3) • Query: creare un web service che accetta l’identificatore di una proteina, interroga le sorgenti rilevanti e restituisce l’informazione all’utente sulla sequenza della proteina stessa e le informazioni sulle proteine con le quali interagisce direttamente o indirettamente: Le entità Protein e Protein – Protein Interaction sono entità virtuali

29. Composing, optimizing, and executing plansfor bioinformatics web services(/4)

30. Composing, optimizing, and executing plansfor bioinformatics web services(/5) Domain Rule: permette di esprimere la chiusura transitiva della relazione Protein – Protein Interaction,per non perdere l’informazione sull’interazione indiretta tra le proteine.

31. Composing, optimizing, and executing plansfor bioinformatics web services(/6) Applicazione dell’Inverse Rule Algorithm: In questo caso la corrispondenza tra le definizioni di sorgente e le regole inverse è 1 a 1 (in generale, è 1 a n).

32. Composing, optimizing, and executing plansfor bioinformatics web services(/7) • Il Mediatore combina la query utente, le regole inverse rilevanti e la domain rule per generare un piano universale, capace di rispondere alla classe di query alla quale appartiene anche quella iniziale: Nel piano sono presenti anche le sorgenti MMProtein e MMProtein Interaction, anche se non servono alla query iniziale. A questo punto diventa necessario ottimizzare l’esecuzione del piano d’integrazione generato per rimuovere le richieste inutili alle sorgenti (il valore dei parametri è noto solo a tempo di esecuzione).

33. Composing, optimizing, and executing plansfor bioinformatics web services(/8) Applicazione delle tecniche di ottimizzazione: • Consideriamo la richiesta di creare un web service che accetta l’identificatore di una proteina e il valore taxonid (un valore che rappresenta il tipo di proteina) e trova tutte le interazioni protein – proteina. • L’algoritmo utilizza i vincoli sull’attributo taxonid ed aggiunge i vincoli di filtraggio prima di interrogare il web service:

34. Composing, optimizing, and executing plansfor bioinformatics web services(/9) Aggiunta di una ‘sensing operation’: • L’algoritmo interroga la sorgente SS per ottenere i valori dei parametri non ancora noti

35. Composing, optimizing, and executing plansfor bioinformatics web services(/10) • Siccome sussiste l’ipotesi di ‘mondo aperto’, le risposte alle query potrebbero non essere complete, diventa, quindi, necessario recuperare le tuple eventualmente perse: In questo modo non vi sono tuple in meno rispetto al risultato della query iniziale. Per garantire la correttezza della tecnica utilizzata, non ci devono essere nemmeno tuple in più rispetto al risultato della query originaria: il Tuple – Level Filtering Algorithm verifica le ‘condizioni di compatibilità’ prima di interrogare una sorgente aggiuntiva, tra le quali vi è il vincolo che il risultato della query ottimizzata sia un sottoinsieme di quello della query originale.

36. Composing, optimizing, and executing plansfor bioinformatics web services(/11) • Piano effettivamente eseguito dal sistema: viene inserita una richiesta alla sorgente DipProtein (sensing operation) e successivamente il vincolo taxonid = 9606 (filtering operation) prima delle richieste ai web service riguardanti le proteine.

37. Composing, optimizing, and executing plansfor bioinformatics web services(/12) Conclusioni: • Grazie alla modularità del lavoro svolto, i vari strumenti sviluppati possono essere utlizzati indipendentemente gli uni dagli altri: Theseus come meccanismo di esecuzione dei piani generati; Tuple – Level Filtering Algorithm, con o senza sensing operation, per ottimizzare l’esecuzione dei piani; L’inverse Rule Algorithm come algoritmo di riformulazione di query.

38. Composing, optimizing, and executing plansfor bioinformatics web services(/13) Sviluppi futuri • Strategie per stabilire efficientemente come determinare i vincoli utilizzati per generalizzare la query utente. • Modellare in maniera automatica il nuovo web service generato dalla richiesta dell’utente come sorgente di dati nel dominio del mediatore (questo può essere ottenuto rappresentando il nuovo web service tramite la struttura della query). • Facilitare l’integrazione intelligente di web service differenti.

39. Retriving and semantically integrating heterogeneous data from the web(/1) Questo articolo utilizza le idee chiave degli studi precedenti e fornisce strumenti complessi d’integrazione semantica dei dati. Concetti chiave dell’articolo: • Realizzazione di tecnologie in grado di integrare i dati descritti in ontologie diverse, per esempio le immagini e i dati strutturati. • Riconoscere quando più oggetti in differenti siti rappresentano lo stesso oggetto nel mondo reale.

40. Retriving and semantically integrating heterogeneous data from the web(/2) • Building Finder integra le immagini provenienti dal satellite e i dati strutturati e semistrutturati di varie sorgenti online utilizzando il semantic web. • L’utente può interrogare una vista integrata di queste sorgenti e richiedere a Building Finder di sovrapporre accuratamente le informazioni riguardanti edifici e strade alle immagini del satellite.

41. Retriving and semantically integrating heterogeneous data from the web(/3) • I dati raccolti sono eterogenei anche in termini di come l’applicazione accede alle sorgenti: alle immagini del satellite tramite Microsoft’s web service Terra-Service, alle strade tramite US Census Bureau’s Tigerline file(un database dell’università della california del sud); inoltre accede all’informazione presente in Los Angeles Property Tax Information Web Site e a Yahoo Yellow Page Web Site. • L’utente può utilizzare Building Finder per mezzo di un’interfaccia che fa uso di agenti che interrogano l’applicazione con RDF Data Query Language (RDQL) ed ottenendo i risultati in RDF.

42. Retriving and semantically integrating heterogeneous data from the web(/4) Strumenti per l’integrazione di dati efficiente: • Tecniche di apprendimento automatico per convertire i siti tradizionali e i database in web services. • Record Linkage System per consolidare i dati presenti in sorgenti diverse che si riferiscono alla stessa entità. • Mediatore che fornisce accesso uniforme ai dati. • Sistema di esecuzione di query efficiente.

43. Retriving and semantically integrating heterogeneous data from the web(/5) • Wrapping delle sorgenti online: • E’ necessario poiché l’ampiezza e la profondità delle query non favoriscono l’uso di sistemi di immagazzinamento dei dati localmente. • Le pagine web sono scritte in HTML quindi estrarre i dati diventa un lavoro complicato perché i tag non possiedono una semantica ben precisa. • I wrapper devono ‘imparare’ ad estrarre i dati rilevanti cercando un percorso che li conduca ai dati d’interesse: possiamo utilizzare una tecnica di ragionamento automatico chiamata Wrapper Rule Learning; per esempio, per estrarre i nomi delle persone possiamo notare che il dato è presente dopo <HTML>Name:<b> e prima di </b>.

44. Retriving and semantically integrating heterogeneous data from the web(/6) (2) Record Linkage System: • Rispondere al problema: gli stessi oggetti possono esistere in formati differenti e la ricerca di un oggetto può restituire risultati multipli. • Active Atlas individua gli attributi comuni di oggetti, apparentemente diversi, per identificare un matching tra gli oggetti stessi: - seleziona una sorgente primaria per il nome dell’entità e fornisce un mapping tra tale sorgente ed ogni altra che fornisce un nome differente. Il sistema può imparare che ‘Rep’, in una sorgente, è comunemente usato come abbreviazione di ‘Republic’, che una sorgente utilizza spesso acronimi, che un’altra rappresenta le persone con ‘Nome e Cognome’, mentre un’altra ancora con ‘Cognome e Nome’. • Uso congiunto di un sistema di consolidamento di oggetti e di un mediatore: il mediatore, in questo caso, serve ad individuare automaticamente quali sorgenti secondarie interrogare nel caso in cui il sistema di consolidamento di oggetti non possa determinare se due oggetti si riferiscono alla stessa entità.

45. Retriving and semantically integrating heterogeneous data from the web(/7) • Il Mediatore: Prometheus Obiettivo: fornire un accesso unico alle varie sorgenti di dati. L’utente invia una query attraverso l’interfaccia oppure formula una RDQL query, e il Mediatore restituisce il risultato all’interfaccia.

46. Retriving and semantically integrating heterogeneous data from the web(/8) I tre componenti principali di Prometheus: • Modello di dati • Riformulazione di query • Convertitore Datalog  Theseus

47. Retriving and semantically integrating heterogeneous data from the web(/9) • Il Modello dei dati: Building Finder usa i predicati di dominio Street, Image e Building. L’utente può interrogare il sistema attraverso l’uso di questi predicati (definiti secondo l’approccio GAV)

48. Retriving and semantically integrating heterogeneous data from the web(/10) • Riformulazione di query: alla ricezione della query, Prometheus unisce la query al modello del dominio e genera un programma Datalog in grado di rispondere alla query. • Convertitore: Prometheus converte il programma Datalog per farlo eseguire a Theseus.

49. Retriving and semantically integrating heterogeneous data from the web(/11) • Esecuzione efficiente di query Cause di inefficienza: • presenza di sorgenti multiple; • ritardi di rete e/o dovuti alla capacità delle sorgenti di elaborare le richieste; • vincoli di precedenza tra le sorgenti di dati.

50. Retriving and semantically integrating heterogeneous data from the web(/12) Parallelismo orizzontale e verticale in Theseus: • orizzontale: esecuzione decentralizzata, gli operatori (le funzioni) lavorano indipendentemente gli uni dagli altri. • verticale: gli operatori si attivano appena il loro input diviene disponibile e passano il risultato agli altri operatori in modalità pipeline. Attivazione degli operatori per il recupero dell’informazione riguardante le tasse sulle proprietà e le informazioni sugli edifici: