Approcci ad Altre Fasi

Nella sezione precedente abbiamo discusso alcuni degli studi principali sul- l’adattamento di componenti. Sebbene, come abbiamo gi`a accennato, l’adat-

tamento sia forse la fase pi`u importante nel processo di creazione di mashup e composizione di servizi, non dimentichiamo che la ricerca `e diretta verso l’automatizzazione completa dell’intero processo. Per riuscire a raggiungere quest’obiettivo, uno dei punti cruciali `e l’individuazione di un insieme oppor- tuno di servizi, senza il quale non si potrebbe nemmeno accedere alla fase di adattamento. Alla luce di questa considerazione riteniamo opportuno pre- sentare alcuni studi che interessano la fase che avevamo definito di “Ricerca e matching dei servizi”.

Uno degli studi che presentiamo `e “Automatic Mash Up of Composite Appli- cations” [30], in cui si propone un approccio basato su tecniche tipicamente utilizzate per i servizi Web per riuscire a realizzare la ricerca di componenti non strettamente basati su servizi Web. Una delle motivazioni che hanno portato a questo studio `e legata alla tendenza a comporre componenti sem- pre pi`u eterogenei, che non si limitano ai servizi Web, ma spaziano a portlet, widget e altri tipi ancora, che spesso sono provvisti di interfacce grafiche, elementi tipicamente assenti nell’ambito dei servizi Web. Inoltre, se da un lato si pone il problema dell’integrazione, dall’altro si pone quello della ri- cerca e catalogazione automatizzata di un elevato numero di componenti. In [30], si mostra come sia possibile riadattare tecniche, tecnologie ed algoritmi tipici della ricerca e il matching di servizi Web (basati su WSDL) per il loro utilizzo in un contesto non necessariamente legato a servizi Web. Inoltre si dimostra come sia possibile modellare caratteristiche aggiuntive di compo- nenti, in particolare, interfacce grafiche, attraverso l’utilizzo di annotazioni semantiche con SAWSDL. Queste nuove caratteristiche possono essere ogget- to di ricerca e matching cos`ı come pero i componenti basati su servizi Web.

Queste informazioni aggiuntive oltre a contribuire ad aumentare i criteri di ricerca e matching utilizzati, permettono dei risultati pi`u precisi nella ricerca di componenti compatibili.

Le linee guida dell’algoritmo di matching utilizzato sono le seguenti:

• a partire dalla specifica di un’interfaccia e un insieme di interfacce tra cui cercare, viene calcolato un punteggio per ciascuna delle interfacce candidate in base al numero di termini corrispondenti tra l’interfaccia di input e ciascuna candidata;

• viene eseguita una seconda ricerca in cui si tiene conto anche delle anno- tazioni semantiche. Il confronto viene eseguito grazie ad un algoritmo di matching di ontologie;

• viene calcolato il punteggio finale come combinazione dei punteggi dei passi precedenti.

L’approccio descritto `e stato testato attraverso l’utilizzo della piattaforma IBM Lotus Expeditor.

Un altro studio che si occupa del problema della ricerca di servizi `e [24], in cui si presenta un sistema per la scoperta e la composizione di servizi basato su reti di Petri. Nello studio in questione si sfruttano informazioni semanti- che e comportamentali presenti in descrizioni OWL-S, che vengono tradotte in reti di Petri ed eventualmente memorizzate assieme alle stesse descrizioni OWL-S. Il sistema che viene proposto `e costituito da tre moduli indipenden- ti: un traduttore da OWL-S a reti di Petri, un analizzatore funzionale ed

un analizzatore comportamentale. Si assume l’esistenza di un repository in cui sono memorizzate le descrizioni OWL-S e le rappresentazioni dei servizi come reti di Petri, che viene aggiornato, ogni volta che si aggiunge un servi- zio, con l’inserimento della descrizione OWL-S e della relativa rete di Petri. A questo punto l’analizzatore funzionale, a partire dalla specifica dell’utente, analizzando le capacit`a funzionali dei singoli servizi, calcola un punteggio per ciascuno dei servizi del repository e restituisce una lista contenente i servizi che potrebbero intervenire nella composizione. Quindi l’analizzatore com- portamentale, dopo aver fuso le reti di Petri dei servizi candidati ed aver ottenuto una rete unica, verifica che i servizi siano in grado di soddisfare la richiesta dell’utente e in tal caso genera l’ouput della richiesta evitando gli stati che porterebbero a situazioni di stallo.

Diversamente dagli studi che abbiamo discusso in questa sezione, in un certo senso [77] approccia in maniera trasversale diverse fasi del processo di composizione di servizi, dal momento che l’approccio proposto potrebbe avere delle ripercussioni in diverse fasi. Viene proposto un modello che attra- verso un Linguaggio Domain-Specific (DSL) unifica la rappresentazione delle interfacce dei diversi tipi di servizi, realizzato attraverso la creazione del- la piattaforma Swashup, nata dall’estensione del framework Ruby on Rails (RoR) [132] con il DSL proposto. L’esigenza di uniformare in qualche mo- do le interfacce dei servizi `e effettivamente forte, dal momento che da un lato i servizi espongono in maniera estremamente diversa le loro interfacce e dall’altro esistono servizi che non hanno alcun modo per esporre le pro- prie interfacce [77]. Il framework RoR permette l’implementazione efficiente

di applicazioni Web che rispettano il pattern Model-View-Controller, inoltre include strumenti per l’invocazione di servizi Web SOAP e per l’accesso a risorse remote. Tuttavia RoR presenta alcuni limiti considerevoli quali la mancanza di una rappresentazione uniforme per tipi di servizio diversi, la mancanza di supporto per l’invocazione di operazioni asincrone tra tipi di servizi diversi e la mancanza di risorse per manipolazioni complesse di dati XML. Parte del lavoro svolto `e mirato proprio a colmare alcune di queste lacune. In ogni caso il DSL proposto rappresenta un forte contributo con- cettuale ad una visione astratta dei servizi, permettendo la rappresentazione uniforme delle interfacce di servizi eterogenei, oltre a fornire un modello uni- forme per i dati e le interazioni tra i servizi. Il DSL permette di rappresentare a livello sintattico le informazioni sugli aspetti principali di un modello con- cettuale per mashup: dati e manipolazione di dati, API dei servizi, protocolli e coreografie, strumenti per la generazione di applicazioni Web per i mashup creati. Swashup `e la piattaforma che estende l’architettura RoR con il DSL definito. L’utente finale interagisce direttamente con l’interfaccia utente di Swashup, che gli permette di creare, modificare ed eseguire progetti Swa- shup, che descrivono i servizi componenti e il mashup che si vuole creare. I progetti creati vengono automaticamente caricati su RoR per essere eseguiti come applicazioni Web.

Analisi Comparata di BPMN e

Reo

In questo capitolo ci occuperemo di due formalismi in grado di specificare modelli di coordinamento tra componenti: BPMN e Reo. Su di essi abbia- mo condotto uno studio volto a determinare la loro capacit`a di soddisfare i requisiti RUPOS specificati nella sezione 2.4.

L’analisi comparata che verr`a presentata nel corso del presente capitolo sar`a organizzata nel seguente modo:

• nelle sezioni 4.1 e 4.2 ci occuperemo di BPMN e Reo rispettivamente. Per ciascuno dei due formalismi descriveremo le caratteristiche princi- pali, introdurremo alcuni strumenti e proporremo delle considerazioni sui punti di forza e le rispettive debolezze;

• concluderemo con la sezione 4.3, in cui riporteremo un confronto diretto tra BPMN e Reo rispetto alle loro capacit`a di soddisfare ciascuno dei

requisiti desiderati.

L’analisi condotta ci ha permesso di determinare che n´e BPMN n´e Reo risultano adeguati per il soddisfacimento di tutti i requisiti. Allo stesso tempo per`o `e stata messa in risalto la complementariet`a dei due formalismi, che ha suggerito un approccio basato su un’opportuna combinazione dei due. Nel capitolo 5 mostreremo come tale approccio ci permetta di soddisfare per intero i requisiti RUPOS.

4.1

BPMN

Nel corso della presente sezione introdurremo BPMN (Business Process Mo- del and Notation), una notazione standard per la modellazione di processi di business.

BPMN `e stato portato alla nostra attenzione attraverso la documentazione tecnica del progetto RUPOS, in cui tra gli obiettivi auspicati compariva l’in- dividuazione di un formalismo con specifiche caratteristiche e si suggeriva lo studio delle potenzialit`a di BPMN. Seguendo questo suggerimento ci siamo dedicati ad analizzare questa notazione, cercando di capire se fosse plausi- bile la sua adozione come formalismo per la piattaforma RUPOS, ovvero se BPMN e gli strumenti a supporto riuscissero a soddisfare i requisiti presen- tati nella sezione 2.4.

L’ultima versione esistente di BPMN `e la 2.0 beta 2, rilasciata nel giugno 2010. Tuttavia la versione a cui faremo riferimento, in particolare presen- tando gli elementi grafici, `e la 1.2. In effetti a livello di notazione non si apprezzano differenze sostanziali significative tra le due versioni e BPMN 1.2

`

e ancora la versione ufficialmente supportata dalla maggior parte degli stru- menti di modellazione.

Nella sezione 4.1.1 presenteremo le caratteristiche principali di BPMN, de- scrivendo gli elementi grafici fondamentali e fornendo un esempio di model- lazione. Nella sezione 4.1.2 introdurremo brevemente alcuni degli strumenti di modellazione e concluderemo esponendo nella sezione 4.1.3 alcune consi- derazioni sui vantaggi e gli inconvenienti derivanti dall’utilizzo di BPMN per i nostri scopi.