Composizione di servizi via TLV Il progetto ha come obiettivo primario la composizione automatica dei web services basandosi sulla tecnica Simulation sperimentando.

Presentazione sul tema: "Composizione di servizi via TLV Il progetto ha come obiettivo primario la composizione automatica dei web services basandosi sulla tecnica Simulation sperimentando."— Transcript della presentazione:

1 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

2 Relazione Simulation  Un transition system TS è una quintupla dove: A è l’insieme delle azioni A è l’insieme delle azioni S è l’insieme degli stati S è l’insieme degli stati S° , sottoinsieme stati iniziali S° , sottoinsieme stati iniziali δ  S x A x S, relazione di transizione δ  S x A x S, relazione di transizione F  S, sottoinsieme stati finali F  S, sottoinsieme stati finali  Simulation è una relazione binaria R che soddisfa le seguenti regole:

3 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

4 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

5 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.

6 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

7 Sottoinsiemi comuni ai TS sorgente I  Sottoservizzi in comune a tutti i servizzi sorgente : sottosistema gestione profilo utente sottosistema gestione profilo utente sottosistema per gli acquisti on-line (es :) sottosistema per gli acquisti on-line (es :)

8 Sottoinsiemi comuni ai TS sorgente II  Sottoservizzi in comune a tutti i servizzi sorgente : informazione amministrazione informazione amministrazione prenotazione eventi musicali prenotazione eventi musicali

9 I TS sorgente  I servizi sorgente sono in totale 6 : 1. i-Tunes, “S1” 2. Real Player, “S2” 3. Media Player, “S3” 4. Login, “S4” 5. Creatine Works, “S5” 6. Sound Manager, “S6”

10 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.

11 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 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” 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) Non è accettabile nessun altra aggiunta di azioni di S2, perchè si otterrebbe un target non simulabile (mostrato in seguito)

12 Target TS2-A  Il servizio target TS2-A offre in cascata informazioni di interesse relativi ai servizi “i-Tunes” e “Real Player”

13 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:

14 Target TS2-B  Il target TS2-B è una rappresentazione simile al TS2-A, però mostra una situazione di incompatibilità rispetto alla relazione Simulation :

15 Target TS2-B  TS2-B non rispetta le regole della composizione del servizio S2, quindi TLV restituisce il risultato : “La specifica non è realizzabile!!”

16 Servizio target TS1_2 sottoinsieme di T1

17 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, in base al comportamento assunto a run-time dalla sorgente S2, può portare negli stati e.

18 Servizio sorgente “Media Player” – S3  Presentazione grafica del servizio sorgente S3:

19 Servizio sorgente “Creative Works” – S5  Di sotto viene data una rappresentazione grafica del servizio S5

20 Servizio sorgente “Sound Manager” – S6  Segue la presentazione grafica del servizio S6:

21 Servizio target TS1_3 sottoinsieme di T1

22 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 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. Se all’inizio sceglie S6 per l’azione “elencoCaseDiscografiche”, allora è obbligato a scegliere S6 per le prossime 3 azioni previste.

23 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 :

24 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

25 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.

26 Servizio sorgente “i-Tunes” – S1

27 Servizio di login – S4

28 Servizio target TS1_1 sottoinsieme di T1 Segue la specifica del TS1_1 composto dalle azioni di S1, S3, S4

29 Analisi del servizio target TS1_1

30 Servizio target TS1_4 sottoinsieme di T1 Il servizio TS1_4 è composto da azioni in comune tra tutti i servizi sorgente

31 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”

32 Servizio target TS1_5 sottoinsieme di T1

33 Analisi del servizio target TS1_5