Gestione dinamica dei servizi in processi cooperativi

Transcript

1 Gestione dinamica dei servizi in processi cooperativi Enzo Colombo 1, Valeria De Antonellis 2, Fabio De Rosa 3, Luca De Santis 3, Massimo Mecella 3, Michele Melchiori 2, Enrico Mussi 1, Barbara Pernici 1, Pierluigi Plebani 1 1 Politecnico di Milano Piazza Leonardo da Vinci, Milano, Italy 2 Università di Brescia Via Branze, Brescia, Italy 3 Università di Roma La Sapienza Via Salaria, Roma, Italy Abstract. I processi cooperativi prevedono l esecuzione di attività da parte di entità differenti allo scopo di perseguire un obiettivo comune. Considerando il contesto dei distretti produttivi, attraverso il progetto VISPO si propone una serie di modelli abilitanti all esecuzione dinamica di tali processi in cui le attività sono svolte da servizi. In questo contesto il carattere di dinamicità deriva dalla possibilità da parte del processo di sopperire a problemi in esecuzione mediante la sostituzione dei servizi malfunzionanti. Viene quindi definito un modello per la valutazione di compatibilità tra servizi e per l orchestrazione del processo cooperativo in cui sono inseriti. 1 Introduzione La necessità di mettere in comunicazione sistemi informativi eterogenei in ambito Internet ha prodotto, nell ultimo periodo, un insieme di standard e proposte identificate solitamente con il generico nome di service oriented computing. Il progetto VISPO (Virtual district Internet-based Service PlatfOrm) sfrutta questo tipo di modello per eseguire processi cooperativi nati sulla base di processi produttivi, tipici di distretti industriali. In tal modo i sistemi informativi utilizzati dalle varie aziende possono essere messi in comunicazione, secondo processi cooperativi, indipendentemente dalla piattaforma e pur mantenendo la loro autonomia operativa. Volendo inoltre garantire la corretta esecuzione dei processi cooperativi si è puntato alla progettazione di processi basati su servizi, e al contempo, alla definizione di meccanismi per la sostituzione dinamica di servizi in caso, per esempio, di indisponibilità di un servizio. Infine, essendo il processo per sua natura distribuito, e volendo mantenere un alto livello di modularità, l attività di monitoraggio deve essere anch essa distribuita. Pertanto viene introdotto il concetto di responsabilità distribuita grazie al quale si demanda alle organizzazioni operanti all interno del processo

2 2 Enzo Colombo et al. in esecuzione l onere di dover controllare la correttezza di porzioni del processo stesso. In Sezione 2, viene quindi definito l ambito di applicazione proponendo un modello di definizione di processi cooperativi basati su e-services. In Sezione 3 invece si propone un modello di descrizione di un servizio che prevede tra l altro, come descritto in Sezione 8, una metodologia per l analisi di compatibilità tra i servizi stessi, necessaria per poter attuare la loro sostituibilità. In Sezione 5 viene data una visione d insieme dell architettura VISPO, la quale permette l esecuzione dei processi cooperativi così come definito in precedenza. Le restanti sezioni, dettagliano quindi i moduli principali: VISPO Registry (Sezione 6), Compatible Service Provider (Sezione 7), Compatibility Module (Sezione 8), Orchestration e Invocation Module (Sezione 9). 2 Workflow basati su e-service La cooperazione tra organizzazioni è solitamente basata su accordi di tipo contrattuale in grado sia di definire il coordinamento tra le attività che il controllo della corretta esecuzione delle attività stesse. Naturalmente la specifica di tale coordinamento e controllo deve prendere in considerazione, e non entrare in contrasto, con quella che è la natura delle organizzazioni cooperanti. Pertanto devono essere analizzati i meccanismi di cooperazione tipici di una azienda (gerarchico, mercato e ibrido) in grado di riassumere quelle che sono le mission e le decisioni strategiche proprie di una azienda. Superando le limitazioni degli attuali modelli concettuali a disposizione, è necessario definire un modello che aiuti a definire dei pattern di controllo e coordinamento all interno di workflow cooperativi, dipendenti dal meccanismo di cooperazione individuato. Il tutto nel caso particolare dei Distretti Virtuali definiti come un gruppo di organizzazioni cooperanti decisionalmente e finanziariamente indipendenti. Per il modello definito all interno del progetto VISPO [6], il controllo è definito come l attività eseguita dalle organizzazioni cooperanti allo scopo di assicurare il raggiungimento dell obiettivo proposto dalla cooperazione. Il coordinamento è invece definito come la sequenza dei messaggi che permettono alle organizzazioni cooperanti di eseguire le attività di loro competenza. Secondo questo modello, il processo cooperativo e il meccanismo di cooperazione possono assieme essere specificati in tre passi: Passo 1: individuazione dei requisiti di cooperazione; Passo 2: Progettazione delle transazioni inter-organizzative necessarie per rendere fattibile la cooperazione e comunque in grado di soddisfare i requisiti di cui al punto 1; Passo 3: Progettazione dei meccanismi di coordinamento e controllo. In particolare il Passo 2 ha portato alla definizione di una serie di pattern specifici, dettagliati in [5], che prevedono l esecuzione delle attività da parte di e-service.

3 3 Descrizione dei servizi Gestione dinamica dei servizi in processi cooperativi 3 Uno degli elementi che maggiormente caratterizza il lavoro riguarda la possibilità di eseguire il processo cooperativo basato su e-service in maniera dinamica dove i servizi in esecuzione possono essere sostituiti da altri disponibili per ragioni quali: una versione aggiornata di un servizio viene rilasciata dal medesimo produttore; un servizio compatibile e migliore rispetto ad uno esistente viene reso disponibile da un nuovo produttore; un servizio in esecuzione per diverse ragioni non è più disponibile; esiste un insieme di servizi equivalenti dal quale deve essere estratto quello che, di volta in volta, viene ritenuto migliore. Allo scopo di supportare questa componente di dinamicità, in VISPO assume particolare significato il concetto di compatibilità tra servizi, realizzato attraverso classi di compatibilità: insiemi, rappresentati da un servizio detto astratto, a cui appartengono servizi, detti concreti, che risultano compatibili tra di loro. Operando questa astrazione è quindi possibile definire l intero processo cooperativo in termini di soli servizi astratti. Il fatto che nella definizione del processo cooperativo una attività venga associata ad un servizio astratto, oltre che a permettere l associazione logica di una attività ad un pool di servizi definisce i requisiti richiesti dalla particolare attività. Ogni servizio, per poter eseguire tale attività, dovrà essere in grado di soddisfare i requisiti posti. Ciò che in questo lavoro viene identificato come servizio astratto può essere definito da tre documenti che specificano i requisiti minimi richiesti: interfaccia: derivabile direttamente dall interfaccia di un e-service e per questo motivo esprimibile attraverso il linguaggio WSDL nella sua visione astratta (WSDL Service Interface) [1]; comportamento: derivabile direttamente dal comportamento di un e-service e per questo motivo esprimibile attraverso il linguaggio quale BPEL4WS e da una descrizione in termini di pre- e post- condizioni [12]; qualità del servizio: comprendente caratteristiche quali affidabilità, costo e disponibilità esprimibile attraverso un linguaggio in fase di studio. I servizi concreti sono definiti dagli stessi tre documenti dove, a differenza del servizio astratto, vengono descritti anche aspetti tecnologici quali il protocollo di comunicazione utilizzato (WSDL Service Implementation). La classe di compatibilità può essere quindi costruita analizzando, per ogni documento, le corrispondenze terminologiche tra i termini utilizzati. Tale analisi utilizza per ogni servizio una particolare descrizione data da un service descriptor, secondo un approccio utilizzato in letteratura per l analisi di componenti software [9].

4 4 Enzo Colombo et al. In particolare un descrittore è formalmente definito da una tripla: <operation (OP), input entities (IN), output entities (OUT)> dove OP rappresenta le operazioni fornite dal servizio, IN le informazioni che una operazione richiede in ingresso e OUT le informazioni che una operazione fornisce. Queste informazioni possono essere automaticamente estratte da un documento WSDL, come mostrato a titolo d esempio in Figura 1. WSDL File <types> <!-- needed type definition--> </types> <porttype name="deliversofa"> <operation name="receiveirder"> <input message="orderid"/> <input message="orderdetails"/> </operation> <operation name="monitor"> <input message="orderid"/> <output message="status"/> </operation> <operation name="notification"> <output message="orderid"/> <output message="success"/> </operation> </porttype> Descrittore SERVICE DeliverSofa OPERATION ReceiveOrder INPUT orderid INPUT orderdetails OPERATION Monitor INPUT orderid OUTPUT status OPERATION Notification OUTPUT orderid OUTPUT success Fig. 1. Esempio di estrazione del service descriptor In realtà, riferirsi a sole somiglianze terminologiche può non essere sufficiente in quanto termini sinonimi, o addirittura identici, possono avere significato diverso se inseriti in contesti diversi. Pertanto, accanto agli aspetti sintattici, vanno considerati anche gli aspetti semantici, descritti attraverso un ontologia di servizi espressa in DAML-S[4], che catturano appunto il contesto all interno del quale il servizio opera. All interno di questa ontologia è quindi possibile mettere in relazione i servizi secondo una analisi del comportamento di un servizio espresso secondo pre- e post-condizioni. 4 Compatibilità tra servizi La valutazione di compatibilità tra servizi e la conseguente costruzione delle classi di compatibilità passa attraverso quattro passi: Pubblicazione: accanto al servizio pubblicato, viene generato in automatico il service descriptor.

5 Gestione dinamica dei servizi in processi cooperativi 5 Classificazione: sotto la supervisione di un esperto di dominio, ed utilizzando il service descriptor, i servizi vengono collocati all interno di un ontologia di dominio e collegati tra di loro attraverso diverse relazioni che esprimono un diverso grado di compatibilità. Reperimento: dato un servizio, analizzando le relazioni esistenti all interno dell ontologia, è possibile costruire una compatibility list che elenca i servizi compatibili al servizio dato. Sostituzione: ogni servizio concreto viene quindi confrontato con il servizio astratto rappresentante della classe di compatibilità cui appartiene, allo scopo di calcolare mapping information grazie alle quali è possibile conoscere le differenze esistenti tra i due servizi e quindi le azioni da intraprendere per passare dall esecuzione di un servizio all altro. Le modalità tecniche di utilizzo delle informazioni utili alla classificazione verranno affrontate nelle sezioni successive alla descrizione dell architettura. 5 Architettura generale La Figura 2 illustra l architettura del sistema VISPO che permette di realizzare il modello proposto e quindi di ricercare, invocare e comporre e-service appartenenti al distretto virtuale per creare un processo cooperativo. Compatibility Module retrieve Compatible Service Provider find Registry Terms Ontology Domain Service Ontology adapt populate Invocation Module retrieve publish Cooperative Process Specifications retrieve exception control Orchestration Engine invoke, use e-services Process instance data e-services instance data Fig. 2. Architettura del sistema VISPO I moduli principali che compongono il sistema sono: Vispo Registry: mantiene la lista di tutti gli e-services disponibili. Per ogni e-service riporta le informazioni codificate attraverso il WSDL mentre

6 6 Enzo Colombo et al. per ogni servizio conserva il descrittore. Questo modulo è stato costruito espandendo la versione standard del registry UDDI v2[10] per poter supportare le richieste aggiuntive dell ambiente cooperativo secondo quanto descritto in seguito. Cooperative Process Specification Repository: contiene la descrizione dei processi cooperativi da eseguire. Il processo cooperativo è espresso come un flusso di attività, ognuna delle quali corrisponderà ad un servizio astratto. Compatible Service Provider: dato un servizio astratto è in grado di ricercare all interno del VISPO Registry tutti i servizi concreti compatibili e calcolare il coefficiente di compatibilità per ognuno di essi. La metodologia sottesa a questo modulo è oggetto di questa seconda fase e verrà approfondita in seguito. Compatibility Module: utilizzando un meccanismo basato su ontologie, questo modulo supporta il Compatible Service Provider nella creazione delle classi di compatibilità. Il Compatibility Module fa inoltre riferimento per la valutazione del grado di similarità tra termini al sistema Artemis [2]. Invocation Module: seleziona e invoca i servizi concreti all interno della classe di compatibilità di un particolare servizio astratto. Il servizio astratto è scelto dall Orchestration Engine che decide quali attività del processo svolgere, mentre la scelta del servizio concreto contenuto nella classe di compatibilità viene fatta dall Invocation Module in base alla politica di invocazione prescelta. Durante l invocazione farà uso delle informazioni di mapping per la costruzione dei tipi di dato e dei messaggi da scambiare. Orchestration Engine Module: decide quali attività del processo cooperativo mandare in esecuzione e controlla il funzionamento dell Invocation Module. 6 VISPO Registry Il VISPO Registry è un estensione di un UDDI Registry in quanto oltre ad offrire supporto per la pubblicazione e la ricerca di servizi, si occupa anche di creare e registrare tutte le informazioni di supporto per l analisi di compatibilità quali i descrittori e le mapping information. Questo ulteriore passaggio, completamente trasparente a chi pubblica, è automatizzato per quanto riguarda la generazione dei descrittori mentre per la creazione delle classi di compatibilità è necessaria la presenza dell esperto di dominio che ha il compito di analizzare i documenti WSDL pubblicati per creare o aggiornare le classi di compatibilità dei servizi. Una classe di compatibilità è creata nel momento in cui si inserisce un nuovo servizio astratto e viene aggiornata ogni volta che viene pubblicato un servizio concreto che si scopre essere compatibile con uno astratto. In Figura 3 è rappresentato lo schema che evidenzia come le informazioni conservate all interno del Vispo Registry vengono messe in relazione tra loro.

7 Gestione dinamica dei servizi in processi cooperativi 7 Fig. 3. Organizzazione delle informazioni all interno del Vispo Registry 6.1 Pubblicazione di un servizio astratto Un servizio astratto viene pubblicato inserendo all interno del Vispo Registry un tmodel che fa riferimento al documento WSDL nel quale è definita l interfaccia del servizio. Il tmodel viene registrato specificando due categorybag. Con il primo, attraverso gli assegnamenti: tmodelkey = uuid : C1ACF26D D70 39B756E62AB4, keyname = uddi org : types, keyv alue = wsdlspec, si specifica che il documento registrato è di tipo WSDL, mentre con il secondo, attraverso gli assegnamenti: tmodelkey = uuid : A035A07C F362 44DD 8F95 E2B134BF43B4, keyname = uddi org : general keywords, keyv alue = compatibilityclass, dove compatibilityclass è deciso da chi pubblica il documento, si specifica la classe di compatibilità di appartenenza del servizio. Una volta registrato il WSDL, viene ricavato e salvato il corrispondente descrittore. L esperto di dominio deve assicurarsi che ogni nuovo servizio astratto definisca una nuova classe di compatibilità definita attraverso un WSDL Service Interface Document.

8 8 Enzo Colombo et al. 6.2 Pubblicazione di un servizio concreto Così come un servizio astratto, anche un servizio concreto è pubblicato utilizzando un tmodel e dal suo WSDL è ricavato un descrittore. La pubblicazione di un servizio concreto può portare a due diverse situazioni: Il servizio concreto implementa un servizio astratto: in questo caso il WSDL del servizio concreto pubblicato è costruito come un WSDL Service Implementation Document e fa riferimento ad un WSDL di un servizio astratto già pubblicato. La procedura di specifica del categorybag è uguale a quella descritta per la pubblicazione di un servizio astratto ma il valore del campo compatibilityclass deve essere lo stesso del servizio astratto al quale si fa riferimento. Il servizio concreto definisce anche l interfaccia del servizio: in questo caso devono essere pubblicati due WSDL. Il primo, che descrive l interfaccia del servizio, è un WSDL Service Interface Document e il tmodel che lo referenzia è registrato con un proprio categorybag che specifica la natura del documento e la classe di compatibilità. Il secondo, che descrive gli aspetti concreti del servizio, è un WSDL Service Implementation Document e per la sua registrazione si utilizza un categorybag che specifica una classe di compatibilità identica a quella definita per il WSDL Service Interface Document. Il compito dell esperto di dominio è quello di verificare che le associazioni tra i vari WSDL siano corrette, così come lo devono essere le nuove categorie inserite. 7 Compatible Service Provider La Figura 4 riporta l architettura del Compatible Service Provider in cui sono evidenziati i quattro moduli che mettono in atto la metodologia descritta per l analisi di compatibilità, da un database per contenere le informazioni di mapping generate, da un proxy verso il Compatibility Module, da un altro proxy verso il Vispo Registry e da un interfaccia attraverso la quale si può utilizzare il CSP. In particolare: Service Research Module: si occupa di gestire le ricerche all interno del Vispo Registry accedendovi attraverso la Vispo Registry Proxy. La sua funzione è di offrire servizi di ricerca ad alto livello per trovare in modo efficiente tutte le informazioni richieste dal Compatibility Engine Module. Oltre all esecuzione delle ricerche, si preoccupa anche di manipolare i dati raccolti per aggregarli e presentarli in uscita in una forma più compatta di quella utilizzata nel registro e maggiormente orientata al calcolo della compatibilità. Compatibility Evaluation Module: fornisce tutte le operazioni necessarie al calcolo della compatibilità tra le componenti di due servizi. Il suo funzionamento poggia sul Compatibility Module, al quale accede mediante il Compatibility Module Proxy, e permette di calcolare agevolmente i valori di affinità tra descrittori, tra operazioni di un servizio, tra parametri

9 Gestione dinamica dei servizi in processi cooperativi 9 Compatible Service Provider UDDI API Registry API VISPO Registry Proxy Service Search informatio storage mapping information base UDDI Business Registry UDDI Registry descriptor base Compatibility Engine Abstract Service WSDL Compatibility Module Compatibility Module Proxy Compatibility evaluation CSP Interface Mapping Information Database Methods Fig. 4. Architettura del Compatible Service Provider di un operazione e tra tipi di parametri. Le strutture dati prodotte, oltre a riportare i risultati calcolati, hanno anche metodi di accesso che ne facilitano l utilizzo da parte del Compatibility Engine Module. Information Storage Module: interagisce con il Mapping Information Database e permette di salvare al suo interno nuove informazioni, modificare quelle già esistenti e effettuare ricerche. Compatibility Engine Module: è il modulo più importante del Compatible Service Provider. Il Compatibility Engine Module utilizza gli altri moduli per implementare la metodologia di calcolo della compatibilità. In ingresso riceve la specifica del servizio astratto sottoforma di WSDL e produce in uscita il documento contenente le informazioni di mapping. Una copia del documento viene anche salvata all interno del Mapping Information Database. 8 Compatibility Module Il Compatibility Module fornisce le funzionalità di costruzione e gestione dell ontologia dei servizi allo scopo di supportare l attività del Compatible Service Provider. In particolare, nella fase di costruzione dell ontologia i servizi sono classificati secondo relazioni semantiche per rendere possibile la successiva analisi di compatibilità allo scopo di valutare la sostituibilità fra servizi stessi. I servizi vengono perciò analizzati, comparandone i descrittori associati, rispetto ai dati di Input/Output che scambiano con il processo cooperativo, e con riferimento alle operazioni che essi sono in grado di eseguire. Questa analisi ha la funzione di stabilire il grado di similarità fra coppie di servizi in funzione della similarità[3] fra gli elementi presenti nelle rispettive interfacce. Maggiore è il valore di similarità e maggiore è la somiglianza fra due servizi in termini di operazioni che essi forniscono e di dati scambiati con il processo che li utilizza.

10 10 Enzo Colombo et al. L ambiente di strumenti Artemis supporta questa analisi, in primo luogo, calcolando i coefficienti di similarità e quindi stabilendo il grado di matching fra servizi; in secondo luogo, determinando, sulla base del valore dei coefficienti, cluster di servizi simili. Tra servizi che risultano classificati nello stesso cluster sono stabilite relazioni di similarità che vengono mantenute nell ontologia di servizi. Sulla base dell esistenza di queste relazioni e dei coefficienti di similarità, il Compatibility Module è in grado di rispondere alle richieste del Compatible Service Provider. In particolare, in Artemis [2] i nomi di elementi presenti nelle interfacce di servizi sono comparati sulla base di un tesauro di relazioni terminologiche (iperonimia, sinonimia) pesate che consente di valutare l affinità di due nomi. Per coprire la terminologia usata nei descrittori di servizi, sono possibili in Artemis due alternative: usare una ontologia indipendente dal dominio (quale WordNet), oppure usare una ontologia di dominio che include sia relazioni terminologiche estratte da WordNet che relazioni terminologiche fornite da una esperto. 9 Orchestration e Invocation Module 9.1 I Moduli L Orchestration Engine ha il compito di monitorare le attività dell Invocation Module, di tenere traccia dei servizi al momento attivi e di sollevare eccezioni nel caso un servizio non sia disponibile o l ordine delle operazioni non venga rispettato. Essendo l unico conoscitore della logica del processo cooperativo è il diretto responsabile dello stato di avanzamento dello stesso durante la sua esecuzione. Dal punto di vista architetturale l Orchestration Engine si compone principalmente di due parti, come mostrato in Figura 5: Engine Component, il motore di orchestrazione vero e proprio in grado di realizzare la composizione tra diversi e-services e permettere la comunicazione reciproca attraverso una sequenza di messaggi, definita attraverso un opportuno linguaggio. Wrapper Component, il modulo interlocutore che consente la comunicazione tra l Orchestration Engine Module e l Invocation Module. L Engine Component non si preoccupa del tipo di protocollo da utilizzare per comunicare con l Invocation Module (SOAP, HTTP, HTTPS, etc.), ma si limita solo ad interagire con delle API di alto livello esposte dall interfaccia Wrapper Component (invoke, link, unlink, etc.). Per meglio modularizzare la comunicazione a due vie tra l Orchestration Engine Module e l Invocation Module, il Wrapper Component si compone di due sottomoduli: Translator Component, il gestore della comunicazione da Orchestration Engine Module a Invocation Module secondo il ciclo di vita degli e-services,

11 Gestione dinamica dei servizi in processi cooperativi 11 Fig. 5. Architettura dello Orchestration Engine Module ovvero di poter eseguire le operazione di Link, Invoke, InstanceRetry e Unlink. Notification Manager, il gestore della comunicazione da Invocation Module a Orchestration Engine Module trattando le eccezioni inviate dall Invocation Module e di comunicarle all Orchestration Engine Module. 9.2 Engine Component Secondo la logica di BPEL4WS[8], linguaggio utilizzato per la definizione del processo cooperativo, una composizione di Web Services viene espressa sotto forma di flow-chart. Ogni passo del processo è costituito da un attività primitiva la quale può essere combinata con altre attività primitive, per mezzo di opportune strutture messe a disposizione dal linguaggio. Tra le attività primitive che prevede il linguaggio sono presenti: Invoke, Receive, Reply, Wait,Terminate, Empty. Al contrario, riguardo alle attività strutturate previste da BPEL4WS, è possibile definire sequenza (Sequence), sequenza parallela (Flow), selezione (Switch e Pick) ed iterazione (While). Ogni processo definito mediante BPEL4WS è costituito da una serie di invocazioni ad altri servizi, e sarà acceduto da clients attraverso le chiamate alle operazioni che il nuovo Web Service di composizione mette a disposizione. Riguardo a ciò viene fatta una distinzione tra i partners del processo, ovvero: client partners, che accedono al processo per mezzo di costrutti receive e reply; invoked partners, acceduti dal processo per mezzo del costrutto invoke activities. Le due categorie di partners non sono necessariamente disgiunte; ci possono essere partners che vengono invocati e allo stesso tempo invocano il processo. Da qui la necessità di definire i ruoli all interno della relazione tra due (o potenzialmente più) servizi. Ciò viene realizzato per mezzo di un opportuno costrutto, il servicelinktype, che associa ad ogni ruolo una lista di porttypes, specificando

12 12 Enzo Colombo et al. in questo modo quello che ogni parte offre all interno della relazione. In generale un partner sarà definito per mezzo di un nome, un servicelinktype, il ruolo del processo e quello del partner stesso. Nei casi in cui si hanno invoked partners e client partners puri il relativo servicelinktype sarà utilizzato per definire un solo ruolo. 9.3 Corrispondenza tra Rete di Petri e file BPEL4WS Il meccanismo di orchestrazione si basa su un principio di responsabilità distribuita, per cui durante l evoluzione del processo cooperativo, i vari partecipanti assumono l onere del controllo complessivo. Il modello teorico sottostante, basato su Reti di Petri opportunamente definite [11], garantisce la correttezza del controllo e che in ogni istante uno ed un solo partecipante ne sia incaricato. In questa sezione viene descritto come tale modello può essere tradotto in un opportuno file BPEL4WS. Infatti per ogni opportuna combinazione di Place e Transition, che rappresenta una operazione eseguibile dallo Orchestrator (request-reply, one way, notification in Figura 6), in [7] viene dato il corrispettivo construtto nel linguaggio BPEL4WS. A scopo esemplificativo, per la request-reply, la Figura 7 illustra la corrispondente regola di traduzione. Fig. 6. Possibili combinazioni di Place e Transition Ottenendo quindi le regole di traduzione per le quattro operazioni, queste rappresentano i quattro passi base per il mapping della Rete di Petri in BPEL4WS. Combinandoli opportunamente è possibile tradurre completamente un qualsiasi macro-processo di orchestrazione. 9.4 Implementazione del Wrapper Component Il componente Wrapper, nel caso specifico del prototipo realizzato, viene implementato utilizzando la tecnologia Java Web Services. Nel caso in questione il BPEL4J Engine comunica via protocollo SOAP con i rispettivi moduli del Wrapper, inviando e ricevendo opportuni messaggi SOAP. Il Web Service che implementa il componente Traslator, riceve i messaggi SOAP inviati dal BPEL4J

13 Gestione dinamica dei servizi in processi cooperativi 13 Fig. 7. Costrutto Request-Reply. Engine, li traduce nel formato di messaggi HTTP e li invia all Invocation Module. Il componente Notification Manager riceve i messaggi HTTP provenienti dallo Invocator Module, li traduce nei corrispondenti messaggi SOAP e li invia al BPEL4J Engine. La sequenza dei messaggi scambiati viene guidata dalla logica di processo definita nel file BPEL4WS. 10 Conclusioni Questo lavoro ha illustrato l approccio utilizzato all interno del progetto VISPO per lo sviluppo e la gestione di sistemi cooperativi orientati ai servizi. Il modello adottato per l identificazione di tali servizi si basa sulla descrizione dell interfaccia e del comportamento in termini di pre- e post-condizioni, e dell organizzazione di tali specifiche all interno di un registry accessibile a tutte le organizzazioni cooperanti. Uno strumento di valutazione della compatibilità supporta l identificazione di servizi compatibili durante la fase di progettazione di quest ultimi, permettendo quindi la sostituibilità degli stessi durante l esecuzione. L invocazione dei servizi compatibili è resa possibile dalla presenza di informazioni di mapping in grado di trasformare le chiamate ai metodi di un servizio astratto, secondo la sintassi prevista per il servizio concreto compatibile. L architettura prevede quindi un particolare modulo in grado di supervisionare l esecuzione dell intero processo, allo scopo di controllarne la correttezza secondo uno schema predefinito, in cui la responsabilità dell esecuzione tra le organizzazioni viene descritta. I meccanismi studiati nel progetto VISPO possono essere quindi estesi all interno di un contesto di sistemi informativi adattativi e multicanale, come definito nel progetto FIRB MAIS. In questo ambito verrà studiata la possibilità da parte dei processi di potersi riconfigurare su diversi canali a seconda del contesto operativo e delle particolari caratteristiche dei canali di comunicazione stessi. Una ulteriore evoluzione riguarderà lo studio di meccanismi a supporto delle transazioni in cui sono coinvolti gruppi di servizi.

14 14 Enzo Colombo et al. Ringraziamenti Questo lavoro è stato sviluppato all interno dei progetto MIUR VISPO e MIUR FIRB MAIS. References 1. P. Brittenham, F. Cubera, D. Ehnebuske, and S. Graham. Understanding WSDL in a UDDI Registry. IBM Web Site: webservices/library/ws-wsdl/, S. Castano and V. De Antonellis. A schema analysis and reconciliation tool environment for heterogeneous databases. In Proceedings of IDEAS 99 Int. Database Engineering and Application Symposium, Montreal, Canada, August S. Castano, V. De Antonellis, and M. Melchiori. A Methodology and Tool Environment for Process Analysis and Reengineering. Data and Knowledge Engineering, 31(3): , November DAML Service Coalition. DAML-S: Semantic Markup For Web Services. October E. Colombo, C. Francalanci, and B. Pernici. Modeling Coordination and Control in Cross-organizational Workflows. In On the Move to Meaningful Internet Systems, DOA/CoopIS/ODBASE 2002 Confederated International Conferences DOA, CoopIS and ODBASE 2002 Irvine, California, USA, October 30 - November 1, 2002, Proceedings, volume 2519 of Lecture Notes in Computer Science. Springer, E. Colombo, M. Mecella, B. Pernici, and P. Plebani. Modelli per la Gestione Dinamica dei Processi con Strumenti di Workflow Management-Fase 1. Rapporto Tecnico WP1.8, Progetto MIUR-VISPO, Colombo, E., De Antonellis, V., De Rosa, F., De Santis, L., Mecella, M., Melchiori, M., Mussi, E., Pernici, B. and Plebani, P. Modelli per la Gestione Dinamica dei Processi con Strumenti di Workflow Management-Fase 1. Rapporto Tecnico WP1.8, Progetto MIUR-VISPO, F. Curbera, Y. Goland, J. Klein, F. Leymann, D. Roller, S. Thatte, and S. Weerawarana. Business Process Execution Language for Web Services, version July E. Damiani and M. G. Fugini. Dynamic Identification of Distributed Components. In Proceedings of the 5th Fuzzy Days International Conference, LNCS 1226, D. Ehnebuske, D. Rogers, and C. von Riegen. Uddi Version 2.0 Data Structure Reference. UDDI.org Web Site: M. Mecella, F. Parisi Presicce, and B. Pernici. Modeling e-service Orchestration Through Petri Nets. In Proceedings of the 3rd VLDB International Workshop on Technologies for e-services (VLDB-TES 2002), Hong Kong, Hong Kong SAR, China, A. Zaremski and J. Wing. Specification Matching of Software Components. ACM Transactions on Software Engineering and Methodology, 6(4): , October 1997.