Composizione di servizi via TLV
Il progetto ha come obiettivo primario la
composizione automatica dei web
services basandosi sulla tecnica
Simulation sperimentando il tool TLV
Relazione Simulation

Un transition system TS è una quintupla <A,S,S°,δ,F>
dove:






A è l’insieme delle azioni
S è l’insieme degli stati
S°  , sottoinsieme stati iniziali
δ  S x A x S, relazione di transizione
F  S, sottoinsieme stati finali
Simulation è una relazione binaria R che soddisfa le
seguenti regole:
Composizione via Simulation e
l’uso del tool TLV ( 1/2 )
- n TS sorgenti deterministici-e-non parti della comunità
-
un TS target che rappresenta un comportamento
obiettivo deterministico
dimostrare se è possibile simulare quest’ ultimo
attraverso una opportuna composizione delle sorgenti
che costituiscono la comunità.
- ogni azione del target sarà automaticamente attribuita ad
uno dei TS sorgenti
-
Composizione via Simulation e
l’uso del tool TLV ( 2/2 )
 TLV
è un tool pratico che permette di
trovare una computazione(trovare uno
orchestratore – OG), quando esiste, a
partire dalle codifiche smv delle sorgenti e
del target
Scenario di interesse I

Si ipotizza che all’interno di una Music Gallery virtuale
vengano presentati servizi web di intrattenimento legati
alla consultazione delle canzoni e degli eventi musicali.

Dal punto di vista dell’aplicazione, possiamo distinguere
due settori; da una parte ci sono le attività di
consultazione dei brani musicali e dall’altra il materiale
legato agli eventi musicali, cantanti e testi delle canzoni.
Scenario di interese II

In questo ambito ogni servizio sorgente potrebbe
presentare una serie di funzionalità particolari, diverse
dagli altri servizi in termini di opzioni di ricerca o
disposizione delle informazioni richieste dal cliente,
oppure funzionalità comuni a tutti i servizi come:
- gestione account utente
- prenotazione partecipazione eventi
- area acquisti
- informazioni amministrazione
- …etc
Sottoinsiemi comuni ai TS sorgente I
 Sottoservizzi in comune a tutti i servizzi sorgente :
•
•
sottosistema gestione profilo utente
sottosistema per gli acquisti on-line (es :)
Sottoinsiemi comuni ai TS sorgente II

Sottoservizzi in comune a tutti i servizzi sorgente :
• informazione amministrazione
•
prenotazione eventi musicali
I TS sorgente
I
servizi sorgente sono in totale 6 :
1. i-Tunes , “S1”
2.
3.
4.
5.
6.
Real Player, “S2”
Media Player, “S3”
Login, “S4”
Creatine Works, “S5”
Sound Manager, “S6”
Servizio sorgente “Real Player” – S2
S2 è di tipo non deterministico a causa dell’azione “consultaTesto_2
Questo comporterà delle restrizioni nelle modalità di invocazione
delle azioni di S2 da parte di un ipotetico target T.
Considerazioni sulla simulabilità del Target

Un servizio target che voglia richiamare tale azione, per essere
simulabile, deve rispettare le seguenti regole:



Lo stato che segue l’azione “cercaCanzoneConAlbum_2” non deve essere
finale
Una volta invocata l’azione “consultaTesto_2”, il target, per quanto riguarda
le sole azioni di S2 può eseguire solo le azioni “cercaCanzoneConAlbum_2”
e “cercaTestoConAlbum_2”
Non è accettabile nessun altra aggiunta di azioni di S2, perchè si otterrebbe
un target non simulabile (mostrato in seguito)
Target TS2-A

Il servizio target TS2-A offre in cascata informazioni di
interesse relativi ai servizi “i-Tunes” e “Real Player”
Target TS2-A

Il target TS2A esercita il non determinismo dell’azione
“consultaTesto_2” di S2. Di seguito viene data una
rappresentazione grafica dell’OG ottenuto negli stati di
interesse:
Target TS2-B

Il target TS2-B è una rappresentazione simile al TS2-A, però mostra
una situazione di incompatibilità rispetto alla relazione Simulation :
Target TS2-B

TS2-B non rispetta le regole della composizione del
servizio S2, quindi TLV restituisce il risultato :
“La specifica non è realizzabile!!”
Servizio target TS1_2 sottoinsieme di T1
Servizio target TS1_2 sottoinsieme di T1
Il target TS1_2 contiene l’azione “consultaTesto_2” si S2 ed esercita il suo
non determinismo. L’invocazione di tale azione a partire dallo stato <12,1>,
in base al comportamento assunto a run-time dalla sorgente S2, può
portare negli stati <0,0> e <0,1>.
Servizio sorgente “Media Player” – S3

Presentazione grafica del servizio sorgente S3:
Servizio sorgente “Creative Works” – S5

Di sotto viene data una rappresentazione grafica del
servizio S5
Servizio sorgente “Sound Manager” – S6

Segue la presentazione grafica del servizio S6:
Servizio target TS1_3 sottoinsieme di T1
Considerazioni sulla simulabilità dei target I

il servizio S5 è di tipo indeterministico a causa dell’azione
“elencoCaseDiscografiche”.Inoltre si deve notare che le azioni “elencoCaseDiscografiche”,
“elencoGiorniDisponibili,”, “elencoSaleDisponibili”, “prenotaSala” sono offerte sia da S5
che da S6.
L’OG effettua le sue scelte a run-time: In un primo momento dovrà scegliere se computare
l’azione “elencoCaseDiscografiche” su S5 o S6.
Se sceglie S5 l’OG necessita di osservare lo stato raggiunto: se esso è lo stato S5_1,
deve scegliere obbligatoriamente S6 per le prossime 3 azioni, se invece S5 raggiunge lo
stato S5_3, l’OG continuerà a mappare le prossime azioni su S5 per via della definizione di
Simulabilità.
Se all’inizio sceglie S6 per l’azione “elencoCaseDiscografiche”, allora è obbligato a
scegliere S6 per le prossime 3 azioni previste.
Servizio target TS1_3 sottoinsieme di T1

Il target TS1_3 esercita il non determinismo dell’azione
“elencoCaseDiscografiche” presente nei servizi sorgente S5 ed S6. L’
Orchestrator generator ottenuto dalla computazione tratta questa
caratteristica negli stati corrispondenti :
Servizio target TS1_3 sottoinsieme di T1

Se l’OG mappa l’azione “elencoCaseDiscografiche” su S5, è forzato ad osservare lo
stato di arrivo per poter scegliere su chi mappare la successiva azione
“elencoSaleDisponibili”

Se lo stato di arrivo è S5_1(S5.loc=0), allora è obbligato a mappare la prossima
azione “ESD” su S6, mentre se lo stato di arrivo è S5_3(S5.loc=2), allora l’OG è
obbligato a continuare a mappare le prossime azioni su S5 perché altrimenti
rimarrebbe in uno stato non-finale e non soddisferebbe la relazione di Simulation
Considerazioni sulla simulabilità dei target II

Si nota che le azioni “cercaToplist” e “salvaTesto” hanno una caratteristica
particolare. Se fossero di esclusiva competenza di S6, questo
comporterebbe per un target che a partire dal suo stato iniziale volesse
chiamare questi azioni e finire con l’azione “salvaToplist”,
allora si otterrebbe una specifica non simulabile, per la definizione
coinduttiva di Simulation estesa al caso delle sorgenti non deterministiche.
Poiché però tali azioni non sono di esclusiva competenza di S6,ma anche di
S3, allora l’OG, ogni volta che riceve a run-time l’azione “cercaToplist”, non
sceglierà mai di mapparla su S6, ma solo su S3.
Servizio sorgente “i-Tunes” – S1
Servizio di login – S4
Servizio target TS1_1 sottoinsieme di T1
Segue la specifica del TS1_1 composto dalle azioni di S1, S3, S4
Analisi del servizio target TS1_1
Servizio target TS1_4 sottoinsieme di T1
• Il servizio TS1_4 è composto da azioni in comune tra tutti i
servizi sorgente
Analisi del servizio target TS1_4
Si nota un alto numero di transazioni
in uscita dagli stati, dovuto all’alto
grado di non determinismo delle azioni
“infoLogin” e “elencoMusicStore”
Servizio target TS1_5 sottoinsieme di T1
Analisi del servizio target TS1_5