Presentazione del problema

2. Presentazione del problema Obiettivo: L’applicazione di SearchofSematicServices permette di ricercare sevizi semantici, ossia servizi a cui sono associati uno o più file descrittivi. Struttura: L’applicazione si compone di due parti, una web applicationed una desktop application. La ricerca verrà effettuata tramite keyword ed i file da ricercare saranno di tre diversi tipi: WSDL, BPEL e SWSAL. La ricerca si basa su quattro livelli ossia c’è la possibilità di ricercare i servizi interni ad un repositorylocale e/o su di un repository pubblico interno al nostro server e/o su repository predefiniti ed infine eventualmente anche nel web.

3. Servizio semantico Un servizio semantico è un servizio web a cui è associata una semantica ossia al servizio vengono affiancate informazioni e dati (metadati) che specificano il contesto semantico in un formato adatto all'interrogazione, all'interpretazione e, più in generale, all'elaborazione automatica. Nel nostro contesto elaboriamo servizi che forniscono descrittori WSDL, BPEL e SWSAL.

4. Cos’è un WSDL ed un BPEL WSDL: web servicesdescriptionlenguage, è un linguaggio formale in formato XML utilizzato per la creazione di "documenti" per la descrizione di Web Service. Mediante WSDL può essere, infatti, descritta l'interfaccia pubblica di un Web Service ovvero creata una descrizione, basata su XML, di come interagire con un determinato servizio. BPEL: Business ProcessExecutionLanguage è un linguaggio basato sull'XML costruito per descrivere formalmente i processi commerciali ed industriali in modo da permettere una suddivisione dei compiti tra attori diversi. BPEL è in particolare adatto a modellare workflow completamente automatizzati, per la composizione di web service con l'integrazione di servizi con hardware eterogenei, architetture di rete e linguaggio del relativo codice.

5. Analisi orientata agli scenari • A questo livello di astrazione abbiamo definito cosa fa il software mediante la suddivisione del problema principale in sottoproblemi che corrispondo alle funzionalità da esso offerto. Abbiamo individuato i seguenti scenari: • Ricerca • Memorizzazione file e link dei servizi • Gestione repository locale • Gestione repository pubblico • Indicizzazione dei risultati • Controllo autenticazione amministratore

6. Diagramma dei casi d’uso

7. Diagramma delle classi Desktop application Ricerca Memorizzazione Gestione repo locale

8. Diagramma dei package Desktop application

9. Diagramma delle classi Web application Ricerca Gestione repo pubblico Autenticazione Indicizzazione

10. Diagramma dei package Web application

11. Ricerca Ricerca Repository Ricerca Ricerca Web • Ovviamente punto centrale della nostra applicazione è la ricerca; questa verte su due diverse parti: • Ricerca sui repository • Ricerca sul web • La ricerca sui repository è la modalità di ricerca condotta sui repository pubblico, locale e predefiniti. • La ricerca sul web consiste nella ricerca dei file descrittori direttamente sul web mediante l’uso delle API messe a disposizione da google. • Nota implementativa di rilievo: le due ricerche nella desktop application risultano essere

12. Ricerca sui repository Definizione livelli di ricerca Reperimento file dai repository Exec ricerca con parsing file Restituzione array risultati Per il parsing dei file abbiamo utilizzato DocumentBuilderFactory, che è il parser DOM predefinito per il java, il quale ci consente di ottenere una rappresentazione ad albero del file XML.

13. Ricerca sul web Definizione motore di ricecra Costruzione query Exec ricerca con strutturazione dei risultati Restituzione array risultati Per l’esecuzione della ricerche dei file descrittori sul web abbiamo utilizzato google come motore di ricerca; ci siamo interfacciati alle sue API mediante il package org.json

14. Link privateStringservDescr; privateList<String> servMeta = newArrayList<String>(); publicLink(StringservName,StringservLink,Stringwsdl,Stringbpel,Stringswsal, StringservRepo ){ this.wsdlLink=wsdl; this.bpelLink=bpel; this.swsalLink=swsal; this.servLink=servLink; this.servName=servName; this.servRepo=servRepo; } La classe Link è una delle classi principali di tutto il progetto in quanto definisce un oggetto che ha internamente tutto quello che ci serve per definire un servizio dal punto di vista del risultato della ricerca. privateintrank; La variabile rank è utilizzata, solo dalla web application, per l’indicizzazione.

15. Parametri e file di configurazione • Come linguaggio di caratterizzazione dei nostri file di configurazione e dei repository abbiamo utilizzato l’xml. Questo metalinguaggio ci ha consentito di definire, sintatticamente e di conseguenza semanticamente, tag che poi sono stati usati per reperire parametri necessari all’esecuzione del software. • Per quanto riguarda la desktop application abbiamo utilizzato : • un file di configurazione, situato in locale, utilizzato per il settaggio del link del repository locale e per la configurazione del proxy; • Per la web application: • un file di configurazione, collocato sul server web, utilizzato per il settaggio del link del repository pubblico e predefiniti, per la configurazione del proxy e per gestire gli accessi degli amministratori.

16. Struttura dei repository La struttura da noi utilizzata è la medesima sia per il repository locale, pubblico e per quelli predefiniti. Tale struttura prevede l’utilizzo del tagrootrepository il quale all’interno conterrà un elenco di servizi. Ogni servizio è caratterizzato dalla seguente struttura a tag: <service> <name> ferrarelle</name> <servLink> www.ferra.net </servLink> <wsdl> lete.wsdl </wsdl> <bpel> lete.bpel </bpel> <swsal> lete.swsal </swsal> <rank> 35 </rank> <description> servizio acqua ferrarelle</description> <meta> acqua </meta> <meta> ferrarelle </meta> </service>

17. Indicizzazione e criterio di ranking Ricerca analisi Attribuzione valutazione Memorizzazione Risultati rank.xml • I primi 20risultati della ricerca condotta sul rank saranno aggiunti al file rank.xml; • Se un risultato era stato in precedenza memorizzato nel file rank.xml il rank associato al servizio sarà incrementato di 1; • L’operazione di associazione di un rank ad un servizio viene effettuata anche all’atto del salvataggio di un file ma in questo caso il valore sarà incrementato di 5 a fronte di un maggiore interesse riscontrato sul servizio da parte dell’utente; • Con scadenza di 30 giorni il demone esegue una potatura del file rank.xml a 100 servizi, questo al fine di evitare una crescita esponenziale di quest’ultimo. In seguito alla potatura i risultati indicizzati su rank.xml andranno ad essere accodati al repository pubblico; • Questa funzionalità riguarda la web application. • P.S. i valori numerici utilizzati sono quelli di default, cioè i valori attualmente assegnati mediante file di configurazione. Questi valori possono essere personalizzati mediante file di configurazione.

18. Difficoltà riscontrate • Difficoltà implementative per colmare il gap tra teorico e pratico; • Difficoltà legate alla gestione del formato dei file utilizzati da Google, appoggiandoci alle librerie org.json; • Impossibilità di realizzazione, nella web application, di una parte dedicata al salvataggio dei file;

19. Conclusioni • Software multipiattaforma con caratteristiche di leggerezza e semplicitàd’uso; • Sistema di indicizzazione; • Google API per sfruttare uno dei migliori motori di ricerca attuali; • Sicurezza con sistema crittografico MD5;

20. FINE