I Semantic Web Services

In questo articolo vedremo cosa sono i Semantic Web Services, quali sono le ragioni che hanno portato alla loro definizione e quali sono i framework che li implementano.

Introduzione

Una descrizione semantica di un Web Service è necessaria allo scopo di ottenerne la sua scoperta, la sua composizione con altri Web Service e la sua esecuzione da parte di utenti e piattaforme eterogenee.

Le tecnologie esistenti per i Web Services forniscono solo descrizioni al livello sintattico, rendendo difficile per i richiedenti (requester) e per i fornitori (provider) interpretare o rappresentare asserzioni significative come il significato degli input e degli output o i vincoli applicativi.

Questa limitazione può essere rilassata fornendo un ampio set di annotazioni semantiche che arricchiscano la descrizione del servizio. Un Semantic Web Service è definito attraverso un’ontologia di servizio (service ontology) che consente l’interpretazione da parte delle macchine delle sue capacità oltre che l’integrazione in un dominio di conoscenza.

Le infrastrutture per i Semantic Web Services, come già detto, possono essere caratterizzate lungo tre direzioni tra di loro ortogonali (figura 1): usage activities, architecture e service ontology. Le usage activities definiscono i requisiti funzionali che un framework per i Semantic Web Services deve supportare. L’architecture di un SWS descrive le componenti necessarie per il realizzamento dell’attività definita dal SWS, mentre le service ontology aggregano tutti i concetti relativi alla descrizione di un Semantic Web Service.

Dal punto di vista delle usage activities, i Semantic Web Services sono visti come degli oggetti all’interno di uno scenario applicativo di esecuzione. Le attività richieste per  l’esecuzione di una applicazione che utilizzi SWS sono: la pubblicazione, la scoperta, la selezione, la composizione, l’invocazione, il deploy e la gestione delle ontologie, come descritto di seguito.

La pubblicazione (publishing) o inserzione (advertisement) di SWS permette ad agenti software o ad altre applicazioni di scoprire i servizi basandosi sulle loro capacità e sui loro obiettivi (goals), Un registro semantico è utilizzato per registrare le istanze dell’ontologia del singolo servizio. L’ontologia del servizio deve distinguere tra l’informazione che è usata per il matching durante la scoperta del servizio, da quella utilizzata per l’invocazione del servizio stesso. Inoltre il dominio di conoscenza (ontologia) dovrebbe essere pubblicato o linkato all’ontologia di servizio.

La scoperta (discovery) dei servizi consiste in un matching semantico tra la descrizione di una richiesta di servizio e la descrizione del servizio pubblicato. Eventuali queries che coinvolgono il nome del servizio, gli input, gli output, le precondition ed altri attributi, possono essere costruite ed utilizzate per una ricerca all’interno del registro semantico. Il matching può inoltre essere fatto a livello dei task o degli obiettivi da raggiungere, seguito da una selezione dei servizi che assolvono il determinato task. Il grado di matching può essere basato su diversi criteri, come ad esempio sulle relazioni di ereditarietà tra tipi: un input di tipo Professor di un fornitore di un servizio può “matchare” con un input di tipo Academic di una richiesta di servizio.

Figura 1: Infrastruttura dei Semantic Web Services

La selezione (selection) di un servizio è richiesta nel momento in cui vi sia più di un servizio che  corrisponda ad una data richiesta. A quel punto possono essere utilizzati gli attributi non funzionali, come il costo o la qualità, per la scelta del servizio adatto.

La composizione (composition) o coreografia (coreography)  permette ai SWS di essere definiti in termini di altri servizi più semplici. Un workflow che esprima la composizione dei servizi atomici può essere definito nell’ontologia di servizio utilizzando degli appropriati costrutti di controllo. Questa descrizione potrebbe essere basata su una descrizione sintattica  come ad esempio BPEL4WS [4].

L’invocazione (invocation) di un SWS coinvolge una serie di step, una volta che gli input richiesti sono stati forniti da una richiesta di servizio. Primo, il servizio e l’ontologia di dominio associata devono essere istanziate. Secondo, gli input devono essere validati rispetto ai tipi dell’ontologia. Infine il servizio può essere invocato oppure può essere eseguito un workflow attraverso la base fornita. E’, inoltre, importante monitorare lo stato del processo di decomposizione e notificare il richiedente in caso di eccezioni o problemi.

Il deployment di un Web Service da parte di un provider è indipendente dalla pubblicazione della sua semantica descrittiva, in quanto lo stesso Web Service può espletare diverse funzioni, ma l’architettura dei SWS può fornire un aiuto per il deployment di codice per una data descrizione semantica.

La gestione delle ontologie dei servizi è anch’essa un’attività importante per un SWS, dal momento che garantisce che le descrizioni semantiche dei servizi sono create, accedute e riusate all’interno del Semantic Web.

Dal punto di vista dell’architecture (figura 6), i SWS sono definiti come un set di componenti che realizzano le attività illustrate precedentemente, con alla base meccanismi di sicurezza. I componenti principali includono  le attività discusse sopra: un register, un reasoner, un matchmaker, un decomposer e un invoker.

Il reasoner è utilizzato durante tutte le attività fin qui discusse e fornisce il supporto al resoning per l’interpretazione delle descrizioni semantiche e delle query.

Il register fornisce il meccanismo per la pubblicazione e la localizzazione dei servizi nel registro semantico oltre che funzionalità per la creazione e l’editing delle descrizioni dei servizi.

Il matchmaker fa da mediatore tra la richiesta e il registro, nel momento in cui vi è un discovery e la selezione di un servizio.

Il decomposer è il componente richiesto per eseguire il modello di composizione dei servizi compositi.

L’invoker fa da mediatore tra il richiedente (requester) ed il fornitore (provider) oppure tra fornitore e decomposer , quando quest’ultimo richiede dei servizi.

Questi componenti sono esemplificativi per la nostra discussione rispetto a quelli effettivamente implementati in un architettura per SWS,  poiché essi possono avere nomi e complessità differenti in base al diverso approccio adottato.

La service ontology (figura 6) è un’altra dimensione lungo la quale possiamo definire i SWS, per i quali rappresenta la capacità di un servizio e le restrizioni applicate al suo utilizzo. L’ontologia di servizio essenzialmente integra al livello della conoscenza (ontologico) le informazioni che sono state definite da standard per Web Services quali UDDI e WSDL, con relativo dominio di conoscenza. Questa potrebbe includere: le capacità funzionali come gli input, gli output, le pre-condition e le post-condition; le capacità non funzionali come la categoria, il costo e la qualità del servizio; le informazioni relative al provider come il nome della compagnia e l’indirizzo; le informazioni riguardanti gli obiettivi e i task; e il dominio di conoscenza, che definisca, per esempio, il tipo degli input del servizio. Questa informazione potrebbe poi essere divisa in più ontologie. Comunque, l’ontologia di servizio usata per descrivere i SWS, dipenderà dall’espressività e dalla capacità di inferenza del sottostante linguaggio ontologico supportato dal Semantic Web.

Negli ultimi anni sono stati sviluppati molti tool e framework che supportano la pubblicazione, la scoperta e la composizione di Semantic Web Services. Queste iniziative includono OWL-S [5] (precedentemente DAML-S [6]), WSMO [7], SWSF [8] e WSDL-S [9] (precedentemente METEOR-S [10]), ma nonostante ciò nessun tool o framework fornisce tutto ciò che è richiesto ad una piattaforma di modellazione generale di Web Services pronta per il Semantic Web. Tutti questi standard sono ancora incompleti e potrebbero non adempiere alle future richieste delle industrie come una maggiore complessità, scalabilità, affidabilità, solo per citarne alcune.

Inoltre, le informazioni semantiche di un Web Service  devono essere sufficientemente generali per permettere il supporto di interazioni automatizzate tra Web Services e software agent. Idealmente, “il” linguaggio dei Semantic Web Services dovrebbe permettere:

• il dinamismo in tutti i tipi di utilizzo di un Web Service, come ad esempio la selezione, la scoperta, la composizione, l’invocazione, la negoziazione e il ripristino dopo un guasto;
• di essere estensibile ed essere strettamente integrato con le risorse di conoscenza del Semantic Web.

Le prossime sezioni di questo articolo affronteranno una elencazione e comparazione tra gli attuali linguaggi e framework di modellazione dei Semantic Web Services.

OWL-S (Ontology Web Language for Services)

Owl-s è un’ontologia dei servizi definita in Owl (Ontology Web Language), sviluppata dalla DARPA, per essere di aiuto agli utenti e ai software agents per la scoperta, l’invocazione, la composizione ed il monitoraggio dei Web Services. Questa ontologia è stata sottoposta al W3C nel novembre del 2004.

La struttura di Owl-s [11] può essere suddivisa in tre parti principali, Figura 7:

• Service Profile per la pubblicazione e la scoperta dei servizi;
• Process Model per la descrizione delle operazioni di un servizio;
• Grounding per definire l’interoperabilità di un dato servizio.

Figura 2: Struttura di un OWL-S

Il Service Profile, Figura 3, descrive tre tipi di informazioni base: l’organizzazione che fornisce il servizio, cosa fa o cosa fornisce il servizio e altre caratteristiche del servizio. Il Service Profile è utilizzato principalmente ai fini della scoperta di un servizio; la descrizione del servizio (e delle query) è  costruita a partire dalle proprietà funzionali  (ad esempio gli input, gli output, precondition ed effect – IOPEs) e da quelle non funzionali ( proprietà interpretabili dagli utenti umani come il nome del servizio e parametri per definire metadati riguardanti il servizio stesso, come la qualità del servizio).

Figura 3: Classi e proprietà del Service Profile

Il Process Model descrive la composizione o l’orchestrazione di uno o più servizi in termini dei loro processi costituenti. Ciò è utilizzato sia per effettuare un reasoning sulle possibili composizioni di servizi (ad esempio per determinare se un modello è eseguibile dato uno specifico contesto) sia per controllare l’invocazione di un servizio.

Il Grounding di un servizio specifica i dettagli dei protocolli e i formati dei messaggi supportati da un servizio, se può essere serializzato, quale protocollo di trasporto utilizza e le informazioni sul suo indirizzamento. Inoltre specifica gli elementi che sono necessari per interagire con il servizio.

Come descritto in precedenza il linguaggio OWL prevede tre sottolinguaggi secondo un livello progressivamente più elevato di espressività: OWL Lite, OWL DL e OWL Full. OWL DL è stato progettato per avere la massima espressività senza però perdere in completezza computazionale (è garantito che tutte le implicazioni saranno computate) e in decidibilità (tutte le computazioni saranno completate in un tempo finito) e di conseguenza è la scelta principale quando si è interessati ad avere un supporto efficiente nei sistemi di reasoning (“sistemi di ragionamento”). Le Ontologie OWL-S sono scritte in OWL DL, in modo da supportare applicazioni dove la completezza computazionali sia garantita.

Essendo OWL-S scritta in OWL, i suoi utenti possono utilizzare gli innumerevoli tool per OWL come i validator, gli editor, i browser, ecc. Molti di questi tool sono reperibili sul sito web della DAML stessa.

OWL-S può inoltre avvalersi del supporto al SWRL [12] (Semantic Web Rule Language), il quale a sua volta è una combinazione di OWL DL e OWL Lite con il linguaggio Unary/Binary Datalog RuleML [13] (RuleML Lite), che fornisce il supporto a regole di tipo “Horn-like”, aumentando l’espressività dell’OWL-S. Le espressioni SWRL possono essere utilizzate per esprimere le precondizioni, il processo di controllo e gli input ed output dell’OWL-S, ad esempio potrebbe essere definita una regola in SWRL che stabilisca una logica di business di un fornitore, la quale imponga che un certo tipo di sconto sia applicabile ad un certo tipo di clientela piuttosto che ad un altro. Questo tipo di regole possono poi essere scritte in un file ed associate ad un Web Service o ad un processo. In seguito sarà necessario un reasoner SWRL per controllare se tali regole sono soddisfatte o meno. Purtroppo solo una versione futura di OWL-S farà uso di regole SWRL per l’inferenza.

Ricerca semantica di Servizi Web in OWL-S

I Service Profile descrivono ciò che un servizio può fare rendendo possibile l’indicizzazione e il ritrovamento di tale servizio mediante tecniche semantiche [50]. Questa è un’assoluta novità perché né WSDL (che punta la sua attenzione sulla descrizione dei messaggi), né UDDI che offre una classificazione in base al nome o a categorie standard, come quelle definite da NAICS (North American Industry Classification), offrono possibilità simili. L’architettura di riferimento è quella proposta in Figura 9, in cui i motori di ricerca sono registri che contengono descrizioni OWL-S di servizi web e sono capaci di effettuare ricerche semantiche. Il punto debole di questa architettura è che affinché siano possibili ricerche semantiche significative deve esistere un’ontologia del dominio applicativo (per ogni servizio possibile) condivisa da tutti i fornitori di servizi, in base alla quale vengano descritti i servizi offerti. Il punto di forza è che tutti i fornitori che condividono una certa ontologia di dominio possono facilmente interoperare (almeno in linea di principio) e sulle descrizioni dei loro servizi sono possibili azioni di ricerca semantica.

La ricerca semantica è molto diversa da una ricerca per keyword ed un algoritmo per effettuare tali ricerche è riportato di seguito. Si può affermare che una descrizione di un servizio soddisfi una richiesta quando “la descrizione descrive un servizio sufficientemente simile al servizio richiesto” [50]. Questa definizione implica che il motore di ricerca sia capace di fornire risposte flessibili, magari ordinate in base alla somiglianza tra la descrizione del servizio e la richiesta effettuata.

Figura 4: Architettura per la ricerca semantica

In linea generale si può dire che una descrizione (intendendo per descrizione di servizio la classe ServiceProfile di OWL-S) soddisfi una richiesta quando tutti gli output della richiesta sono soddisfatti dagli output della descrizione e tutti gli input della richiesta soddisfano gli input della descrizione. Questo garantisce che il servizio trovato soddisfi i bisogni del richiedente e che il richiedente possa fornire tutti gli input necessari ad invocare il servizio. In altre parole, per ogni output della richiesta deve esistere un output simile nella descrizione e per ogni input della descrizione deve esistere un input simile nella richiesta. Una volta verificate queste condizioni la bontà di una corrispondenza è valutata in base a alla somiglianza tra gli input e gli output richiesti e quelli offerti. Tale somiglianza viene valutata in base alla distanza (minima) tra le classi nell’ontologia OWL-S.

Per facilitare la comprensione d’ora in avanti si farà riferimento ad una semplice ontologia, Figura 5, ad un servizio di vendita di automobili che fornisca come output il tipo di macchina e il prezzo.

Figura 5: Ontologia di esempio

Chiamiamo outD l’output descritto nel registro e outR l’output richiesto. Si hanno quattro diversi livelli di corrispondenza in base alle classi di outD e di outR:

• Exact, si ha se outD e outR sono della stessa classe, oppure se outR è una sottoclasse di outD ma outD fornisce anche elementi di quella sottoclasse. Ad esempio supponiamo di richiedere un servizio il cui output siano Utilitarie, potremmo essere interessati a servizi che forniscano i prezzi di macchine (chi dichiara di vendere macchine deve avere in listino anche le utilitarie)
• Plug in, si ha se outD contiene outR ma non siamo nel caso precedente. Ad esempio un servizio dichiara di fornire prezzi di veicoli e sono interessato a prezzi di vetture sportive. Si potrebbe supporre che il servizio fornisca i prezzi di alcune macchine ma non è detto che tra queste vi siano macchine sportive.
• Subsumes, si ha se outR contiene outD. Il servizio soddisfa solo parzialmente la richiesta
• Fail, nessuna relazione tra le classi di outR e quelle di outD.

Un ragionamento complementare va fatto per gli input, considerando che le relazioni sono invertite (se inR contiene inD ho una corrispondenza di tipo plug in: si cerca un servizio che prenda in ingresso veicoli e viene offerto un servizio che prende in ingresso utilitarie).

Applicazione a UDDI

UDDI, come discusso in precedenza non offre molte possibilità per la ricerca di servizi web. I servizi web possono essere ricercati per tipi attraverso i loro tModel. In particolare è possibile ricercare tutti i servizi che hanno una certa descrizione WSDL oppure che hanno certi valori associati con i tModel. Dal momento che la ricerca in UDDI è per parole chiave non c’è alcuna possibilità di inferenza o di match flessibile, come descritto nel precedente paragrafo.

In [50] si propone un motore di ricerca semantico integrato in un sistema UDDI, che aggiunge un livello di ricerca semantica a questo tipo di registro.

Il motore di ricerca proposto è basato sull’algoritmo descritto nel precedente paragrafo, e utilizza le ontologie pubblicate sul web. I servizi pubblicati utilizzando questo nuovo registro sono anche pubblicati in un registro UDDI in maniera che possano essere ritrovati sia utilizzando la ricerca per parole chiave di UDDI, sia attraverso la ricerca semantica.

L’architettura del registro combinato UDDI/OWL-S è descritta in Figura 11.

Il server UDDI è potenziato con il modulo matching engine e con una capability port utilizzata per ricevere e spedire query semantiche. Quando il registro UDDI riceve una richiesta di pubblicazione, l’advertisement UDDI viene prima processato dalla componente UDDI del registro, dopodichè viene controllato se tale advertisement contiene delle informazioni in OWL-S. Se ciò accade, l’advertisement viene passato al matching engine per il processamento delle descrizioni in OWL-S.

Quando invece l’OWL-S/UDDI matchmaker riceve una richiesta di servizio attraverso la capability port, la richiesta è inviata al matching engine dove viene processata secondo l’algoritmo precedentemente citato.

Figura 6: Architettura del registro UDDI/OWL-S

Questo sistema è molto interessante perché non modifica l’architettura attuale e apre la strada ad un passaggio graduale verso i servizi web semantici.

WSMO (Web Service Modeling Ontology)

Il Web Service Modeling Ontology [14] fornisce un modello per descrivere i vari aspetti dei Web Services. Il suo obiettivo principale è quello di consentire e migliorare l’eCommerce applicando le tecnologie del Semantic Web a quelle per i Web Services.

WSMO è incentrata su due principi complementari: un forte disaccoppiamento delle varie componenti che realizzano un’applicazione di eCommerce; e un forte servizio di mediazione che consenta ai Web Services di comunicare tra di loro in maniera fortemente scalabile. Questa mediazione è applicata a diversi livelli: mediazione delle strutture dati, mediazione della logica di business, mediazione sui protocolli di scambio e mediazione sull’invocazione dinamica dei servizi.

WSMO consiste di quattro elementi principali: le Ontologies che forniscono la terminologia utilizzata dagli altri elementi; i Goals che definiscono i problemi che un Web Services dovrebbe risolvere; le descrizioni dei Web Services che definiscono i vari aspetti di un web service; e i Mediators che bypassano i problemi riguardanti l’interoperabilità.

Figura 7: Gli elementi di WSMO

WSMO poggia le sue basi sul Web Service Modelling Framework [15] (WSMF), di cui ne estende e ne raffina il linguaggio, e sviluppa una ontologia formale per i servizi per i Semantic Web Services.

La caratteristica principale di WSMO è la sua semplicità, completezza e facile esecuzione. La semplicità di WSMO permette di essere facile da capire da chiunque, ed incorporando tutti gli aspetti di un Web Service  e della loro composizione, è anche facile da eseguire.

Le Ontologies definite in WSMO sono utilizzate per fornire un vocabolario comune alle altre tecnologie della piattaforma WSMO. Tali Ontologies includono dunque le definizioni per i Goals, per i Mediators e per i Web Services. Questi componenti sono poi collegati tra di loro da quattro tipi di Mediators:

• OO Mediators che collegano ontologie con altre ontologie
• WW Mediators che collegano web services con altri web services
• WG Mediators che collegano web services ai goals
• GG Mediators che collegano goals ad altri goals

Tali Mediators sono elementi che possono essere di aiuto sia nel raffinamento di un componente già esistente per  produrne uno nuovo sia nel far interagire tra di loro due componenti altrimenti incompatibili. I Mediators che raffinano un componente sono detti Refiners mentre quelli che fan sì che due componenti diversi comunichino sono detti Bridge.

I Refiners sono utilizzati per raffinare Ontologies e Goals. Dato un goal pre–esistente in un repository ed è richiesto un goal che sia leggermente differente ma molto simile al goal pre-esistente, un refiner chiamato GGMediator può essere utilizzato per creare un goal richiesto a partire dal citato goal pre-esistente. Similmente un OOMediator può essere utilizzato per importare ontologie pre-esistenti, raffinarle ed utilizzarle per nuovi scopi.

I Bridge sono invece utilizzati per collegare Web services e Goals. A tal scopo viene utilizzato un WGMediator.

Per quanto riguarda un’ontologia WSMO, essa consiste di vari elementi. Tra questi vi sono le proprietà non funzionali quali il titolo, la data e altri parametri riguardanti la Quality of Service (QoS), come l’affidabilità, la sicurezza, ecc. Le ontologie fanno poi uso degli OOMediators per importare ontologie pre-esistenti e per facilitare il riuso. Un’ontologia può inoltre avere degli assiomi (Axiom), che sono espressioni logiche arricchite da informazioni dette “extra-logiche”. Gli assiomi possono essere considerati come regole utilizzabili per definire vincoli ed altre informazioni complesse. I concetti (Concept) sono invece utilizzati per fornire una visione astratta di un problema di dominio. Infine l’ontologia può avere delle relazioni (Relation), che definiscono i legami tra i diversi concetti, e le istanze (Instance), che sono i casi reali con cui un’ontologia è popolata.

WSMO utilizza la sintassi di F-Logic [16] (Frame Logic), un linguaggio del primo ordine (first order logic), per fornire il supporto agli assiomi e all’inferenza logica.  F-Logic è stato originariamente sviluppato per definire, interrogare e manipolare i database schema. F-Logic ha una valida e completa base teorica che lo distinguono dagli altri linguaggi logici, inoltre esso trova applicazione nel campo dei linguaggi per l’Intelligenza Artificiale. F-Logic è estensibile e può essere combinato con altri linguaggi, esso combina i vantaggi dei linguaggi basati su “frame” (come i linguaggi orientati agli oggetti, in quanto “frame” significa “qualcosa che può essere eseguito”), con l’espressività , la compattezza sintattica e la ben definita semantica di un linguaggio logico. Oggetti, metodi, classi, ereditarietà e le regole sono alcune delle feature di F-Logic.

Ricerca semantica di Servizi Web in WSMO

Il discovery di Web Services in WSMO segue il modello descritto in Figura 8, definendo un framework concettuale per la localizzazione dei servizi che soddisfano (totalmente o parzialmente) una richiesta di un utente.

Figura 8: I tre processi principali nel discovery di un servizio

Questo framework distingue tre step principali nel processo di discovery: goal discovery, web service discovery e service discovery.

Il goal discovery si basa sull’astrazione delle richieste di un utente in un goal che sia predefinito, riusabile e formale. Gli utenti possono descrivere i loro “desideri” in un modo assolutamente individuale, il che rende molto complicato il mapping con una descrizione di un servizio. Quindi il discovery di un servizio richiede un processo in cui le aspettative  di un cliente  siano mappate su delle descrizioni più generali (goals). Da notare che una tale cosa può essere nascosta al cliente attraverso un discovery engine che permette all’utente di scegliere (con differenti livelli di accuratezza) tra dei goals predefiniti. Un esempio di una richiesta di un utente, potrebbe essere quella di comprare un biglietto ferroviario per la tratta che va da Innsbruck a Venezia, per il giorno 12 Dicembre 2004, con orario di partenza compreso tra le 15:00 e le 17:00. Questa è una richiesta molto dettagliata e concreta, mentre i goals sono da intendersi generici e riutilizzabili, ad esempio comprare biglietti ferroviari o comprare biglietti ferroviari in Europa. Dunque diventa necessario un mapping tra i desideri dell’utente e i goals.

Il web service discovery è basato nel matching dei goals su descritti con le annotazioni semantiche dei web services. Questo processo di discovery può soltanto avvenire ad un livello ontologico, cioè concettuale. Per ottenere ciò sono richiesti due processi:

1. Gli input reali e concreti dell’utente devono essere generalizzati e formalizzati attraverso i goals;
2. I servizi concreti e le loro descrizioni devono essere generalizzate come classi di servizi che un web service può offrire.

Questa duplice astrazione è essenziale per innalzare il problema della scoperta dei web services ad un livello ontologico, che è il prerequisito fondamentale per una soluzione scalabile e realizzabile a tale problema.

L’ultimo step, il service discovery, utilizza i web services che hanno “matchato” nel precedente step, per accedere ai servizi reali che stanno dietro alle interfacce dei web services stessi, cercando quali servizi realmente soddisfano le richieste dell’utente.

SWSF (Semantic Web Services Framework)

Il Semantic Web Services Framework [17]comprende due componenti principali:

• Il Semantic Web Services Language [18] (SWSL), il quale è utilizzato per specificare le caratteristiche formali dei concetti di un Web Service e per specificare le descrizioni dei singoli servizi. Esso include a sua volta due sottolinguaggi. SWSL-FOL che è basato su di un linguaggio del primo ordine (FOL) ed è usato prevalentemente per esprimere la caratterizzazione formale (ontologia) dei concetti insiti in un Web Service. SWSL-Rules è basato sul paradigma della programmazione logica (rule), ed è usato per supportare l’utilizzo di un’ontologia di servizio per effettuarne il reasoning. SWSL è quindi un linguaggio general-purpouse, ma è stato pensato per andare incontro ai bisogni dei Semantic Web Services;
• Il Semantic Web Services Ontology [19] (SWSO), presenta un modello concettuale attraverso il quale i Web Services possono essere descritti, ed un’assiomatizzazione, o caratterizzazione formale, di quel modello. Tale assiomatizzazione è data utilizzando una logica del primo ordine (FOL), in questo caso SWSL-FOL, insieme ad un modello semantico che specifica il preciso significato dei concetti. Questo linguaggio del primo ordine applicato ad un’ontologia viene chiamato First Order Logic Ontology for Web Services (FLOWS). In aggiunta a ciò, gli assiomi tratti da FLOWS sono stati sistematicamente tradotti nel linguaggio SWSL-Rules. L’ontologia risultante è chiamata Rules Ontology for Web Services (ROWS).

Più specificamente, SWSL è un linguaggio logico general-purpouse, con alcune feature che lo rendono utilizzabile con i linguaggi base e con l’infrastruttura del Web attuale. Queste feature comprendono le URI, l’integrazione dei tipi incorporati da XML, i namespace e i meccanismi di import compatibili con XML. Inoltre SWLS, come già detto, include due livelli di espressività: SWSL-FOL e SWSL-Rules. SWSL-FOL è una logica del primo ordine, estesa con le feature di HiLog e la sintassi basata su “frame” di F-Logic. SWSL-Rules è un linguaggio logico di programmazione che include una combinazione di feature tratte dai programmi logici Courteous, da Hi-Log, e da F-Logic.

Quasi tutti gli elementi sintattici sono comuni sia a SWSL-FOL che a SWSL-Rules, così da permettere agli sviluppatori di lavorare facilmente con entrambi i livelli, e per facilitare i vari tipi di interscambio e di interoperabilità tra i livelli. La sintassi presentata è stata studiata per consentirne la leggibilità, ed incorpora alcune convenienti feature, come lo stile object-oriented, che può essere utilizzato per migliorare l’organizzazione del codice e la sua comprensibilità, ma senza alterare l’espressività del sottostante sistema logico.

Per quanto riguarda FLOWS, esso è una ontologia assiomatizzata dei concetti insiti in un servizio, la quale fornisce un framework concettuale per la descrizione ed il reasoning dei servizi. FLOWS deriva molte delle sue intuizioni dal linguaggio OWL-S, in particolare esso comprende un’ontologia per descrivere il servizio, che è un qualcosa di simile ad un OWL-S Service Profile, ma rispetto ad OWL-S fornisce un’ontologia più complessa espressa in termini di logica del primo ordine. Un contributo alle ontologie espresse da FLOWS è dato anche dallo sviluppo di un ricco modello di processo comportamentale basato sul Process Specification Language [20] (PSL). Originariamente pensato per supportare l’interoperabilità tra i linguaggi di modellazioni di processo, PSL fornisce le fondamenta ideali per l’interoperabilità tra i modelli di processo dei Web Services. FLOWS va però al di là del PSL, nella modellazione dei diversi concetti riguardanti il processo di un Web Service, tra cui i messaggi, i canali, gli input e gli output.

FLOWS è stato concepito modularmente. Esso comprende un’ontologia per la descrizione di un servizio, un’ampia ontologia riguardante il modello del processo (process model), ed un grounding che relaziona i tipi dei messaggi del processo con quelli definiti nei messaggi WSDL. L’ontologia del modello di processo è comprensiva di una core ontology e di un certo numero di estensioni.

WSDL-S (Web Service Semantics)

WSDL-S [21] ha come obiettivo quello di avere un approccio più “leggero” per aggiungere la semantica nei Web Services, rispetto agli altri standard sin qui presentati. Esso riprende ed estende il progetto METEOR-S del LSDIS Lab dell’Università della Georgia.

Con WSDL-S l’espressività del WSDL è aumentata aggiungendovi una semantica, i cui concetti sono simili a quelli impiegati in OWL-S, ma esso è  completamente “agnostico” rispetto al linguaggio per rappresentare tale semantica.

Figura 9: Aggiunta della semantica in WSDL

Il vantaggio di questo approccio è molteplice. Primo, gli utenti possono, in modo assolutamente compatibile, descrivere sia la semantica che i dettagli relativi alle operazioni in WSDL, un linguaggio che è ben familiare alla comunità di sviluppo. Secondo, rendendo esterni i modelli del dominio semantico (ontologie), si ottiene un linguaggio che è completamente indifferente al formato di rappresentazione dell’ontologia utilizzata. Ciò permette agli sviluppatori di Web Services di annotare i loro servizi con un linguaggio ontologico di loro scelta ( ad esempio OWL, ma anche WSMO, RDF, ecc.). Inoltre è relativamente semplice aggiornare i tool esistenti relativi al trattamento di WSDL, per venire incontro all’approccio incrementale presentato da WSDL-S.

Viene ora presentato e descritto il modo in cui le annotazioni semantiche sono aggiunte agli elementi di un documento WSDL, ponendo l’attenzione sull’annotazione semantica della definizione del modello di un servizio descritto in WSDL, per ottenere la scoperta dinamica del servizio stesso.  Essenzialmente sono previsti dei meccanismi per riferirsi ad URI, attraverso degli elementi estendibili legati ai costrutti di interfaccia, di operazione e di messaggi del WSDL, le quali puntano alle annotazioni semantiche definite nelle ontologie esterne al documento WSDL. Ecco un breve sommario degli elementi previsti:

• un elemento, definito wssem:modelReference, per consentire associazioni uno ad uno degli input e degli output schema element di un WSDL ed i concetti di un modello semantico;
• un attributo, definito wssem:schemaMapping, per consentire associazioni molti a molti degli input e output schema element di un WSDL ed i concetti di un modello semantico;
• due elementi, definiti wssem:precondition e wssem:effect, che sono specificati come elementi figli dell’elemento operation e descrivono la semantica delle operazioni, similmente a quanto fatto in OWL-S. Precondition ed Effect sono utilizzati principalmente nel discovery dei servizi, mentre non sono richiesti all’atto della sua invocazione;
• un attributo,definito wssem:serviceCategorization, il quale fornisce informazioni sulla categorizzazione del servizio e che può essere usato quando il servizio è pubblicato in un registry di Web Services come UDDI.

Un documento WSDL che è stato annotato seguendo questo approccio è riportato sotto. In questo esempio si è utilizzato un servizio riguardante un ordine d’acquisto. Gli input e gli output del servizio ProcessPurchaseOrder sono annotati con un riferimento ad una semantica espressa in questo caso in una ontologia OWL, PurchaseOrder.owl. L’annotazione di elementi XSD con concetti OWL rappresenta un problema che va sotto il nome di Schema Mapping, a causa dell’eterogeneità dei modelli e dato che il linguaggio OWL è  molto più espressivo di XSD.

<definitions name=”PurchaseOrder”

…

xmlns:wssem=”http://www.ibm.com/xmlns/WebServices/WSSemantics”    xmlns:POOntology=”http://www.ibm.com/ontologies/PurchaseOrder.owl”>

<types>

<xs:schema>

…

<xs:element type= “tProcessPurchaseOrderRequest”/>

<xs:complexType>

<xs:sequence>

<!– Semantic annotations for these complex types are given in their respective type definitions –>

<xs:element  name=”billingInfo”/>

<xs:element  name=”orderItem” type=”xsd1:POItem”/>

</xs:sequence>

</xs:complexType>

<!– Semantic annotation is added directly to leaf element in a complex type –>

<xs:element name= “processPurchaseOrderResponse” type=”xs:string”wssem:modelReference=”POOntology#OrderConfirmation”/>

</xs:schema>

</types>

<interface>

<operation name=”processPurchaseOrder” pattern=”http://www.w3.org/2004/03/wsdl/in-out” >

<input messageLabel = “processPurchaseOrderRequest” element=”tns:processPurchaseOrderRequest”/>

<output messageLabel =”processPurchaseOrderResponse” element=”processPurchaseOrderResponse”/>

<!– Precondition and effect are added as extensible elements on an operation –>

<wssem:precondition name=”PreExistingAcctPrecond” modelReference=”POOntology#AccountExists”/>

<wssem:effect name=”ItemReservedEffect” modelReference=”POOntology#ItemReserved”/>

</operation>

</interface>

</definitions>

Ricerca semantica di Servizi Web in WSDL-S

Come più volte ribadito in questa tesi, i registri UDDI non supportano la pubblicazione e la scoperta di Semantic Web Services. Per abilitarne il supporto alle semantiche, viene definita un’infrastruttura per mappare WSDL-S su UDDI,come mostrato in Figura 18, mentre i dettagli del mapping sono riportati nella Tabella 1. Come mostrato in Figura un servizio WSDL-S è incapsulato utilizzando la Business Service entity di UDDI, mentre i portType e le operation sono incorporate nel Technical Model (tModel).

Tabella 1: Dettagli del mapping tra WSDL-S e UDDI

Figura 11: Mapping tra WSDL-S e UDDI

Il framework di WSDL-S fornisce poi, un tool grafico denominato Lumina,  il quale è stato sviluppato per facilitare il discovery di Semantic Web Services e che si basa sul mapping tra WSDL-S e UDDI su illustrato.

Durante il processo di discovery, un utente aggiunge le URL di una o più ontologie nel discovery panel di Lumina ed inserisce i concetti ontologici che rappresentano gli input, gli output e le operation. Dopo il processo di discovery il risultato è mostrato nel pannello dei risultati.