Gestione dinamica dei servizi in processi cooperativi

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "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: 11. 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.

BPEL: Business Process Execution Language

BPEL: Business Process Execution Language Ingegneria dei processi aziendali BPEL: Business Process Execution Language Ghilardi Dario 753708 Manenti Andrea 755454 Docente: Prof. Ernesto Damiani BPEL - definizione Business Process Execution Language

Dettagli

ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO

ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO Standard tecnici Gli standard tecnici di riferimento adottati sono conformi alle specifiche e alle raccomandazioni emanate dai principali

Dettagli

UNA PIATTAFORMA DI SERVIZI AVANZATA A SUPPORTO DI DISTRETTI COOPERATIVI: IL PROGETTO DISCoRSO

UNA PIATTAFORMA DI SERVIZI AVANZATA A SUPPORTO DI DISTRETTI COOPERATIVI: IL PROGETTO DISCoRSO UNA PIATTAFORMA DI SERVIZI AVANZATA A SUPPORTO DI DISTRETTI COOPERATIVI: IL PROGETTO DISCoRSO Danilo Ardagna a, Luciano Baresi a, Sara Comai a, Marco Comuzzi a, Barbara Pernici a, Massimiliano Pianciamone

Dettagli

Introduzione ai Web Services Alberto Polzonetti

Introduzione ai Web Services Alberto Polzonetti PROGRAMMAZIONE di RETE A.A. 2003-2004 Corso di laurea in INFORMATICA Introduzione ai Web Services alberto.polzonetti@unicam.it Introduzione al problema della comunicazione fra applicazioni 2 1 Il Problema

Dettagli

Ministero del Lavoro e delle Politiche Sociali

Ministero del Lavoro e delle Politiche Sociali Ministero del Lavoro e delle Politiche Sociali Prospetto Informativo on-line Standard tecnici del sistema informativo per l invio telematico del Prospetto Informativo Documento: UNIPI.StandardTecnici Revisione

Dettagli

UN INTRODUZIONE RAGIONATA AL MONDO DEI WEB SERVICE

UN INTRODUZIONE RAGIONATA AL MONDO DEI WEB SERVICE UN INTRODUZIONE RAGIONATA A MONDO DEI EB SERVICE Il paradigma del Service Oriented Computing è visto come una rivoluzione nella comunità informatica e i eb Service una sua realizzazione. a possibilità

Dettagli

Integrazione di servizi: Enterprise Service Bus (ESB) e Business Process Execution Language (BPEL)

Integrazione di servizi: Enterprise Service Bus (ESB) e Business Process Execution Language (BPEL) Università degli Studi di Roma Tor Vergata Facoltà di Ingegneria Integrazione di servizi: Enterprise Service Bus (ESB) e Business Process Execution Language (BPEL) Corso di Sistemi Distribuiti Stefano

Dettagli

Interoperabilità e cooperazione applicativa tra sistemi informativi

Interoperabilità e cooperazione applicativa tra sistemi informativi Interoperabilità e cooperazione applicativa tra sistemi informativi Michele Ruta Dipartimento di Ingegneria Elettrica e dell Informazione Politecnico di Bari 1di 29 Indice Introduzione ai Port Community

Dettagli

Modelli per la descrizione di protocolli

Modelli per la descrizione di protocolli POLITECNICO DI MILANO Corso di Laurea in Ingegneria Informatica Modelli per la descrizione di protocolli asincroni basati sull usouso di servizi Web Relatore: Prof. Stefano Ceri Correlatori: Ing. Marco

Dettagli

Laboratorio di RETI DI CALCOLATORI

Laboratorio di RETI DI CALCOLATORI Laboratorio di RETI DI CALCOLATORI A.A. 2009-2010 I WEB SERVICES Carlo Mastroianni Laboratorio di Reti di Calcolatori - Orario lunedì, 11:30-13:30, aula 40B mercoledì, 10:00-11:30, laboratorio settimo

Dettagli

Una Architettura Open Service per la Gestione del Rischio Ambientale: il progetto ORCHESTRA

Una Architettura Open Service per la Gestione del Rischio Ambientale: il progetto ORCHESTRA Una Architettura Open Service per la Gestione del Rischio Ambientale: il progetto ORCHESTRA Olga RENDA (*), John FAVARO (**), Thomas USLÄNDER (***), Ralf DENZER (****) (*) Intecs S.p.A., Pisa, Italy, Tel.

Dettagli

Composizione e Coreografia di Web Services

Composizione e Coreografia di Web Services Composizione e Coreografia di Web Services Giusy Di Lorenzo Composizione Lo scopo della composizione è quello di comporre servizi esistenti al fine di definire un nuovo servizio a valore aggiunto Richiesta

Dettagli

Ingegneria del Software UML - Unified Modeling Language

Ingegneria del Software UML - Unified Modeling Language Ingegneria del Software UML - Unified Modeling Language Obiettivi. Presentare un approccio visuale alla progettazione. Illustrare i vantaggi dell utilizzo di diagrammi nella fase di progettazione. Rispondere

Dettagli

automation using workflow technology and web services Vassilacopoulos Med. Inform. (September 2003) vol. 28, no. 3,

automation using workflow technology and web services Vassilacopoulos Med. Inform. (September 2003) vol. 28, no. 3, Emergency healthcare process automation using workflow technology and web services M. Poulymenopoulou, F. Malamateniou, G. Vassilacopoulos Med. Inform. (September 2003) vol. 28, no. 3, 195 207 Processo

Dettagli

Registro SPICCA Architettura del Software

Registro SPICCA Architettura del Software Registro SPICCA Architettura del Software Versione 1.0 del 25/08/2009 Sommario 1 Introduzione... 4 1.1 Scopo... 4 1.2 Obiettivo... 4 1.3 Riferimenti... 4 1.4 Panoramica del documento... 4 2 Rappresentazione

Dettagli

Università degli studi di Ferrara. Sviluppo di un Web Service per la classificazione del suolo e sua integrazione sul Portale SSE

Università degli studi di Ferrara. Sviluppo di un Web Service per la classificazione del suolo e sua integrazione sul Portale SSE Università degli studi di Ferrara Facoltà di scienze MM.FF.NN. Corso di Laurea Specialistica in Informatica Sviluppo di un Web Service per la classificazione del suolo e sua integrazione sul Portale SSE

Dettagli

Modello Workflow - WIDE

Modello Workflow - WIDE Modello Workflow - WIDE Prof.ssa Gentile a.a. 2011-2012 Modello Wide Workflow on an Intelligent and Distributed database Environment Descrive processi come insiemi di attività tra loro collegate da vincoli

Dettagli

Sicurezza nei Web Services: Migrazione dell autenticazone di Web Services da ticket di sessione a WS-Security con token SAML

Sicurezza nei Web Services: Migrazione dell autenticazone di Web Services da ticket di sessione a WS-Security con token SAML Master Universitario di II livello in Interoperabilità Per la Pubblica Amministrazione e Le Imprese Sicurezza nei Web Services: Migrazione dell autenticazone di Web Services da ticket di sessione a WS-Security

Dettagli

COME FARE PER. ARMONIZZARE IL SITO COL SISTEMA DI GESTIONE DOCUMENTALE DELL ENTE

COME FARE PER. ARMONIZZARE IL SITO COL SISTEMA DI GESTIONE DOCUMENTALE DELL ENTE COME FARE PER. ARMONIZZARE IL SITO COL SISTEMA DI GESTIONE DOCUMENTALE DELL ENTE Flavia Marzano marzano@cibernet.it 10/05/2004 ARPA Club Forum PA 2004 Contenuti Cenni normativi Sistema di gestione documentale:

Dettagli

Appendice D. D. Web Services

Appendice D. D. Web Services D. D.1 : cosa sono I cosiddetti sono diventati uno degli argomenti più attuali nel panorama dello sviluppo in ambiente Internet. Posti al centro delle più recenti strategie di aziende del calibro di IBM,

Dettagli

Estrattore Semantico di Ontologie da DB Relazionali. Luca Macagnino

Estrattore Semantico di Ontologie da DB Relazionali. Luca Macagnino Estrattore Semantico di Ontologie da DB Relazionali Luca Macagnino 1 Obiettivi Estrarre un ontologia da una sorgente di dati relazionale, al fine di rendere disponibili e dotate di semantica le informazioni

Dettagli

RELAZIONE ANNUALE CONSUNTIVA

RELAZIONE ANNUALE CONSUNTIVA 1 RELAZIONE ANNUALE CONSUNTIVA PROGRAMMA DI RICERCA SETTORE Legge 449/97 SETTORE: Strumenti, Ambienti e Applicazioni per la Società dell Informazione PROGETTO: P1 Reti Internet: efficienza, integrazione

Dettagli

La Roadmap dello sviluppo per System i5: dalle Applicazioni Legacy alla SOA

La Roadmap dello sviluppo per System i5: dalle Applicazioni Legacy alla SOA IBM System i5 La Roadmap dello sviluppo per System i5: dalle Applicazioni Legacy alla SOA Massimo Marasco System i Technical Sales Support massimo_marasco@it.ibm.com Oriented Architecture (SOA) Servizio

Dettagli

Service discovery in P2P semantic communities

Service discovery in P2P semantic communities Service discovery in P2P semantic communities Università di Brescia Dipartimento di Elettronica per l Automazione Devis Bianchini, Valeria De Antonellis, Michele Melchiori, Denise Salvi 1 Definizione del

Dettagli

B.P.S. Business Process Server ALLEGATO C10

B.P.S. Business Process Server ALLEGATO C10 B.P.S. Business Process Server ALLEGATO C10 REGIONE BASILICATA DIPARTIMENTO PRESIDENZA DELLA GIUNTA REGIONALE UFFICIO SISTEMA INFORMATIVO REGIONALE E STATISTICA Via V. Verrastro, n. 4 85100 Potenza tel

Dettagli

RELAZIONE ANNUALE CONSUNTIVA

RELAZIONE ANNUALE CONSUNTIVA RELAZIONE ANNUALE CONSUNTIVA PROGRAMMA DI RICERCA SETTORE Legge 449/97 SETTORE: Strumenti, Ambienti e Applicazioni per la Società dell Informazione PROGETTO: SP1 Reti Internet: efficienza, integrazione

Dettagli

Web Services con Axis Delia Di Giorgio Anna Celada 1 marzo 2005

Web Services con Axis Delia Di Giorgio Anna Celada 1 marzo 2005 Sommario Web Services con Axis Delia Di Giorgio Anna Celada 1 marzo 2005 Introduzione.................................................................................. 1 SOAP........................................................................................

Dettagli

Progetto di Applicazioni Software

Progetto di Applicazioni Software Progetto di Applicazioni Software Antonella Poggi Dipartimento di Informatica e Sistemistica Antonio Ruberti SAPIENZA Università di Roma Anno Accademico 2008/2009 Questi lucidi sono stati prodotti sulla

Dettagli

WorkFlow Management Systems

WorkFlow Management Systems WorkFlow Management Systems Cosa è un? Automazione di un processo aziendale (business process) con: documenti, informazioni e compiti partecipanti insieme predefinito di regole obiettivo comune 2 Esempi

Dettagli

Introduzione a UML. Iolanda Salinari

Introduzione a UML. Iolanda Salinari Introduzione a UML Iolanda Salinari Perché modelliamo Un modello è una semplificazione della realtà I modelli ci aiutano a visualizzare un sistema come è o come vorremmo che fosse ci permettono di specificare

Dettagli

Introduzione ad UML. Perché modelliamo

Introduzione ad UML. Perché modelliamo Introduzione ad UML Pag. 1 Perché modelliamo Un modello è una semplificazione della realtà I modelli ci aiutano a visualizzare un sistema come è o come vorremmo che fosse ci permettono di specificare la

Dettagli

Ingegneria del Software Requisiti e Specifiche

Ingegneria del Software Requisiti e Specifiche Ingegneria del Software Requisiti e Specifiche Obiettivi. Affrontare i primi passi della produzione del software: la definizione dei requisiti ed il progetto architetturale che porta alla definizione delle

Dettagli

ECOSISTEMA DI UN REGISTRO DI COLLABORAZIONE:

ECOSISTEMA DI UN REGISTRO DI COLLABORAZIONE: ECOSISTEMA DI UN REGISTRO DI COLLABORAZIONE: Il sistema di modellazione di schemi e componenti Alfredo Scopece Consulente di Informatica Maggio 2005 Sintesi Il Registro di Collaborazione è un servizio

Dettagli

Accordi. Tecnologie di cooperazione. Cooperazione fra Amministrazioni

Accordi. Tecnologie di cooperazione. Cooperazione fra Amministrazioni Alcune considerazioni nell ambito di un sistema di cooperazione informatico che preveda lo scambio di dati tra due o più organizzazioni. Quando parliamo di un sistema di cooperazione informatico ci riferiamo

Dettagli

Linguaggi di programmazione

Linguaggi di programmazione Linguaggi di programmazione Programmazione L attività con cui si predispone l elaboratore ad eseguire un particolare insieme di azioni su particolari dati, allo scopo di risolvere un problema Dati Input

Dettagli

Università degli Studi di Roma La Sapienza. Facoltà di Ingegneria

Università degli Studi di Roma La Sapienza. Facoltà di Ingegneria Università degli Studi di Roma La Sapienza Facoltà di Ingegneria Tesi di Laurea In Ingegneria Informatica PROGETTO, REALIZZAZIONE, SPERIMENTAZIONE E TUNING DI UN ORCHESTRATORE DI WEB SERVICE Relatore:

Dettagli

Servizi Web in Registri Distribuiti Luciano Baresi 1, Debora Desideri 2, Matteo Melideo 2, Alberto Sillitti 3, Giancarlo Succi 3

Servizi Web in Registri Distribuiti Luciano Baresi 1, Debora Desideri 2, Matteo Melideo 2, Alberto Sillitti 3, Giancarlo Succi 3 Servizi Web in Registri Distribuiti Luciano Baresi 1, Debora Desideri 2, Matteo Melideo 2, Alberto Sillitti 3, Giancarlo Succi 3 1 Politecnico di Milano 2 Engineering Ingegneria Informatica 3 Libera Università

Dettagli

Un introduzione ai Web service

Un introduzione ai Web service Un introduzione ai Web service Valeria Cardellini Università di Roma Tor Vergata Definizione di Web service Definizione fornita del W3C http://www.w3.org/tr/ws-arch/ A Web service is a software system

Dettagli

Web Service Architecture

Web Service Architecture Giuseppe Della Penna Università degli Studi di L Aquila dellapenna@di.univaq.it http://dellapenna.univaq.it Engineering IgTechnology Info92 Maggioli Informatica Micron Technology Neta Nous Informatica

Dettagli

TECNICO SUPERIORE PER LO SVILUPPO DEL SOFTWARE

TECNICO SUPERIORE PER LO SVILUPPO DEL SOFTWARE ISTRUZIONE E FORMAZIONE TECNICA SUPERIORE SETTORE I.C.T. Information and Communication Technology TECNICO SUPERIORE PER LO SVILUPPO DEL SOFTWARE STANDARD MINIMI DELLE COMPETENZE TECNICO PROFESSIONALI DESCRIZIONE

Dettagli

Il.NET Framework. By Dario Maggiari. L architettura del.net Framework è riassunta, nel complesso, nella figura seguente:

Il.NET Framework. By Dario Maggiari. L architettura del.net Framework è riassunta, nel complesso, nella figura seguente: Il.NET Framework By Dario Maggiari L architettura del.net Framework è riassunta, nel complesso, nella figura seguente: Il cuore del.net Framework è costituito dal CLR (Common Language Runtime) che, secondo

Dettagli

Business Process Modeling and Notation e WebML

Business Process Modeling and Notation e WebML Business Process Modeling and Notation e WebML 24 Introduzione I Web Service e BPMN sono standard de facto per l interoperabilità in rete a servizio delle imprese moderne I Web Service sono utilizzati

Dettagli

Processi BPEL. Obiettivi

Processi BPEL. Obiettivi Università degli studi di Roma Tor Vergata Facoltà di Ingegneria Processi BPEL Corso di Sistemi Distribuiti Stefano Iannucci Anno accademico 2009/10 Email: sd@chmod.it Obiettivi Esercitazione pratica su:

Dettagli

Relazione Pinakes3 Analisi modello di business (BOZZA) di Valeriano Sandrucci 08/09/07

Relazione Pinakes3 Analisi modello di business (BOZZA) di Valeriano Sandrucci 08/09/07 Relazione Pinakes3 Analisi modello di business (BOZZA) di Valeriano Sandrucci 08/09/07 1. Introduzione...3 1.2. Application vs Tool... 3 2. Componenti logiche di un modello... 6 3. Ontologie e Semantic

Dettagli

Guida Utente della PddConsole. Guida Utente della PddConsole

Guida Utente della PddConsole. Guida Utente della PddConsole Guida Utente della PddConsole i Guida Utente della PddConsole Guida Utente della PddConsole ii Copyright 2005-2015 Link.it srl Guida Utente della PddConsole iii Indice 1 Introduzione 1 2 I protocolli di

Dettagli

Sistemi Informativi e WWW

Sistemi Informativi e WWW Premesse Sistemi Informativi e WWW WWW: introduce un nuovo paradigma di diffusione (per i fornitori) e acquisizione (per gli utilizzatori) delle informazioni, con facilità d uso, flessibilità ed economicità

Dettagli

Guida Utente della PddConsole. Guida Utente della PddConsole

Guida Utente della PddConsole. Guida Utente della PddConsole Guida Utente della PddConsole i Guida Utente della PddConsole Guida Utente della PddConsole ii Copyright 2005-2014 Link.it srl Guida Utente della PddConsole iii Indice 1 Introduzione 1 2 I protocolli di

Dettagli

Programmi. Algoritmi scritti in un linguaggio di programmazione

Programmi. Algoritmi scritti in un linguaggio di programmazione Programmi Algoritmi scritti in un linguaggio di programmazione Sistema operativo:programma supervisore che coordina tutte le operazioni del calcolatore Programmi applicativi esistenti Sistemi di videoscrittura

Dettagli

Architettura e componenti per la cooperazione applicativa nella Pubblica Amministrazione. White Paper Oracle Novembre 2002

Architettura e componenti per la cooperazione applicativa nella Pubblica Amministrazione. White Paper Oracle Novembre 2002 Architettura e componenti per la cooperazione applicativa nella Pubblica Amministrazione White Paper Oracle Novembre 2002 Architettura e componenti Oracle per la cooperazione applicativa nella Pubblica

Dettagli

CLOUD COMPUTING REFERENCE ARCHITECTURE: LE INDICAZIONI DEL NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. Prima parte: Panoramica sugli attori

CLOUD COMPUTING REFERENCE ARCHITECTURE: LE INDICAZIONI DEL NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. Prima parte: Panoramica sugli attori ANALISI 11 marzo 2012 CLOUD COMPUTING REFERENCE ARCHITECTURE: LE INDICAZIONI DEL NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY Nella newsletter N 4 abbiamo già parlato di Cloud Computing, introducendone

Dettagli

Web Services e Grid Services. OGSA e WSRF. Sommario. Page 1

Web Services e Grid Services. OGSA e WSRF. Sommario. Page 1 Sommario Web Services e Grid Services OGSA e WSRF SOA Grid: Evoluzione OGSA - Open Grid Services Architecture WSRF Web Services Resource Framework Web services Servizi stateless Gestione dello stato Grid

Dettagli

Web Services e Grid Services. OGSA e WSRF

Web Services e Grid Services. OGSA e WSRF Web Services e Grid Services OGSA e WSRF Sommario SOA Grid: Evoluzione OGSA - Open Grid Services Architecture WSRF Web Services Resource Framework Web services Servizi stateless Gestione dello stato Grid

Dettagli

Appunti lezione Database del 07/10/2015

Appunti lezione Database del 07/10/2015 Appunti lezione Database del 07/10/2015 Nelle lezioni precedenti si è visto come qualunque applicazione informativa è almeno formata da tre livelli o layers che ogni progettista conosce e sa gestire: Livello

Dettagli

Il Registro dei Servizi di OpenSPCoop i. Il Registro dei Servizi di OpenSPCoop

Il Registro dei Servizi di OpenSPCoop i. Il Registro dei Servizi di OpenSPCoop i Il Registro dei Servizi di OpenSPCoop ii Copyright 2005-2011 Link.it srl iii Indice 1 Introduzione 1 2 Visualizzazione del registro dei servizi HTTP 1 3 Visualizzazione del registro dei servizi UDDI

Dettagli

REGIONE BASILICATA DIPARTIMENTO INFRASTRUTTURE, OO.PP. E MOBILITA

REGIONE BASILICATA DIPARTIMENTO INFRASTRUTTURE, OO.PP. E MOBILITA REGIONE BASILICATA DIPARTIMENTO INFRASTRUTTURE, OO.PP. E MOBILITA Ufficio Difesa del Suolo di Potenza INTEROPERABILITÀ E COOPERAZIONE APPLICATIVA Informatizzazione dell iter procedurale e dei controlli

Dettagli

YAWL Workflow Management System

YAWL Workflow Management System YAWL Workflow Management System Gabriele Pozzani Barbara Oliboni Sistemi informativi aziendali Laurea magistrale in Ingegneria e scienze informatiche http://www.yawlfoundation.org/ Materiale prodotto da:

Dettagli

Monitoraggio della Rete di Assistenza

Monitoraggio della Rete di Assistenza Studio di fattibilità Allegato al Deliverable A Monitoraggio della Rete di Assistenza Fase 1 Anagrafica ASL Comuni assistibili () ESTRATTO Indice del documento A.20 SCOPO DELL APPLICAZIONE...3 A.20.20

Dettagli

Progetto di Applicazioni Software

Progetto di Applicazioni Software Progetto di Applicazioni Software Antonella Poggi Dipartimento di Informatica e Sistemistica Antonio Ruberti SAPIENZA Università di Roma Anno Accademico 2010/2011 Questi lucidi sono stati prodotti sulla

Dettagli

Modellazione di processi

Modellazione di processi Luca Cabibbo Architetture Software Dispensa ASW 910 ottobre 2014 La modellazione è un mestiere e a volte è un arte. William C. Burkett 1 -Fonti [Papazoglou] Papazoglou, Web Services Principles and Technology,

Dettagli

Progetto interregionale ICAR Interoperabilità e Cooperazione Applicativa tra le Regioni.

Progetto interregionale ICAR Interoperabilità e Cooperazione Applicativa tra le Regioni. <Task AP3> Progetto interregionale ICAR Interoperabilità e Cooperazione Applicativa tra le Regioni AP3-Documento Descrittivo degli Accordi di Servizio Versione AP3-specificaADSv1.2.1.doc Pag. 1

Dettagli

Release Notes di OpenSPCoop2. Release Notes di OpenSPCoop2

Release Notes di OpenSPCoop2. Release Notes di OpenSPCoop2 Release Notes di OpenSPCoop2 i Release Notes di OpenSPCoop2 Release Notes di OpenSPCoop2 ii Copyright 2005-2015 Link.it srl Release Notes di OpenSPCoop2 iii Indice 1 Versione 2.1 1 1.1 Gestione del protocollo

Dettagli

UDDI e WSDL: navigare sicuri nel mare dei Web. Col passare del tempo, la rete delle reti

UDDI e WSDL: navigare sicuri nel mare dei Web. Col passare del tempo, la rete delle reti UDDI Col proliferare dei Web service e delle aziende che li forniscono, si sente il bisogno di mettere ordine, per sfruttare pienamente le potenzialità dei servizi disponibili in rete UDDI e WSDL: navigare

Dettagli

fornitore di servizi utente all interazione tra utenti e sistemi

fornitore di servizi utente all interazione tra utenti e sistemi WEB SERVICES Successo del Web Negli anni passati il Web ha avuto un enorme successo principalmente per due motivi: Semplicità: Ubiquità Per un fornitore di servizi è semplice raggiungere un numero molto

Dettagli

Punto della Situazione. Dipartimento di Informatica e Comunicazione Università degli Studi di Milano e-mail: cazzola@dico.unimi.it

Punto della Situazione. Dipartimento di Informatica e Comunicazione Università degli Studi di Milano e-mail: cazzola@dico.unimi.it Punto della Situazione Dipartimento di Informatica e Comunicazione Università degli Studi di e-mail: cazzola@dico.unimi.it Slide 1 of 8 EOS-DUE: Informazioni Generali. L (responsabile), Lorenzo Capra e

Dettagli

Architettura SW Definizione e Notazioni

Architettura SW Definizione e Notazioni Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Stili Architetturali E. TINELLI Architettura SW Definizione e Notazioni Definizione ANSI/IEEE Std Std1471-2000

Dettagli

Considera tutti i requisiti funzionali (use cases) NON deve necessariamente modellare i requisiti non funzionali

Considera tutti i requisiti funzionali (use cases) NON deve necessariamente modellare i requisiti non funzionali Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Progettazione OO E. TINELLI Punto di Partenza Il modello di analisi E una rappresentazione minima del

Dettagli

Service Oriented Architectures (SOA)

Service Oriented Architectures (SOA) Facoltà di Ingegneria dell Informazione Laurea Specialistica in Ingegneria Informatica Facoltà di Ingegneria dei Sistemi Laurea Magistrale in Ingegneria Biomedica Dipartimento di Elettronica e Informazione

Dettagli

Sistemi Distribuiti. Il corso: informazioni utili AA 2006/2007. Riferimenti del docente: Ricevimento: Materiale Didattico:

Sistemi Distribuiti. Il corso: informazioni utili AA 2006/2007. Riferimenti del docente: Ricevimento: Materiale Didattico: Sistemi Distribuiti Corso di Laurea Specialistica in Telecomunicazioni AA 2006/2007 Slides del corso Sara Tucci Piergiovanni Il corso: informazioni utili Riferimenti del docente: - sito web: www.dis.uniroma1.it/

Dettagli

CORBA ( Common Object Request Broker Architecture ) Le specifiche più conosciute sono UML e CORBA

CORBA ( Common Object Request Broker Architecture ) Le specifiche più conosciute sono UML e CORBA CORBA ( Common Object Request Broker Architecture ) consiste in un insieme di specifiche promosse e curate da OMG (Object Management Group). L OMG è un consorzio internazionale no-profit di industrie nel

Dettagli

Allegato 1 CIG 58703795FF PROCEDURA DI AFFIDAMENTO PER LA FORNITURA DI UNA PIATTAFORMA PER SERVICE MASHUP AND DELIVERY CAPITOLATO TECNICO

Allegato 1 CIG 58703795FF PROCEDURA DI AFFIDAMENTO PER LA FORNITURA DI UNA PIATTAFORMA PER SERVICE MASHUP AND DELIVERY CAPITOLATO TECNICO PROCEDURA DI AFFIDAMENTO PER LA FORNITURA DI UNA PIATTAFORMA PER SERVICE MASHUP AND DELIVERY CAPITOLATO TECNICO SOMMARIO 1 Oggetto della Fornitura... 3 2 Composizione della Fornitura... 3 2.1 Piattaforma

Dettagli

D3.2 Documento illustrante l architettura 3D Cloud per la realizzazione di servizi in modalità SaaS

D3.2 Documento illustrante l architettura 3D Cloud per la realizzazione di servizi in modalità SaaS D3.2 Documento illustrante l architettura 3D Cloud per la realizzazione di servizi in modalità SaaS Il modello SaaS Architettura 3D Cloud Il protocollo DCV Benefici Il portale Web EnginFrame EnginFrame

Dettagli

Rational Unified Process Introduzione

Rational Unified Process Introduzione Rational Unified Process Introduzione G.Raiss - A.Apolloni - 4 maggio 2001 1 Cosa è E un processo di sviluppo definito da Booch, Rumbaugh, Jacobson (autori dell Unified Modeling Language). Il RUP è un

Dettagli

KON 3. Knowledge ON ONcology through ONtology

KON 3. Knowledge ON ONcology through ONtology KON 3 Knowledge ON ONcology through ONtology Obiettivi di KON 3 Scopo di questo progetto èquello di realizzare un sistema di supporto alle decisioni, basato su linee guida e rappresentazione semantica

Dettagli

Survey sui Framework per Testing di Sistemi Basati su Web Services

Survey sui Framework per Testing di Sistemi Basati su Web Services Survey sui Framework per Testing di Sistemi Basati su Web Services Severoni Francesco Facoltà di Scienze Dipartimento di Informatica Università degli Studi - L Aquila 67100 L Aquila, Italia Argomenti Trattati

Dettagli

Cooperazione amministrativa e semantica: Il ruolo del Documento Intelligente

Cooperazione amministrativa e semantica: Il ruolo del Documento Intelligente Cooperazione amministrativa e semantica: Il ruolo del Documento Intelligente Romeo Pruno L attuazione dell e-government ha reso possibile la presentazione sul mercato IT di una grande quantità di soluzioni

Dettagli

TECNICO SUPERIORE PER LE APPLICAZIONI INFORMATICHE

TECNICO SUPERIORE PER LE APPLICAZIONI INFORMATICHE ISTRUZIONE E FORMAZIONE TECNICA SUPERIORE SETTORE I.C.T. Information and Communication Technology TECNICO SUPERIORE PER LE APPLICAZIONI INFORMATICHE STANDARD MINIMI DELLE COMPETENZE TECNICO PROFESSIONALI

Dettagli

Centro Nazionale per l Informatica nella Pubblica Amministrazione. Gara a procedura aperta n. 1/2007. per l appalto dei

Centro Nazionale per l Informatica nella Pubblica Amministrazione. Gara a procedura aperta n. 1/2007. per l appalto dei Centro Nazionale per l Informatica nella Pubblica Amministrazione Gara a procedura aperta n. 1/2007 per l appalto dei Servizi di rilevazione e valutazione sullo stato di attuazione della normativa vigente

Dettagli

Centro Nazionale per l Informatica nella Pubblica Amministrazione

Centro Nazionale per l Informatica nella Pubblica Amministrazione Centro Nazionale per l Informatica nella Pubblica Amministrazione Procedura ristretta n. 2/2006 per l affidamento della progettazione, realizzazione e gestione di componenti di cooperazione applicativa,

Dettagli

Processi di Business e Sistemi di Gestione di Workflow: concetti di base. Prof. Giancarlo Fortino g.fortino@unical.it

Processi di Business e Sistemi di Gestione di Workflow: concetti di base. Prof. Giancarlo Fortino g.fortino@unical.it Processi di Business e Sistemi di Gestione di Workflow: concetti di base Prof. Giancarlo Fortino g.fortino@unical.it Introduzione Le aziende devono modificare la loro organizzazione per cogliere le nuove

Dettagli

Manuale di Integrazione IdM-RAS

Manuale di Integrazione IdM-RAS IdM-RAS Data: 30/11/09 File: Manuale di integrazione IdM-RAS.doc Versione: Redazione: Sardegna IT IdM-RAS Sommario 1 Introduzione... 3 2 Architettura del sistema... 4 2.1 Service Provider... 4 2.2 Local

Dettagli

Web Services. Scoperta del servizio UDDI. Descrizione del servizio WSDL. Accesso al servizio SOAP XML. Starto di comunicazione HTTP

Web Services. Scoperta del servizio UDDI. Descrizione del servizio WSDL. Accesso al servizio SOAP XML. Starto di comunicazione HTTP Web Services I web services servono a rendere interoperabili le applicazioni e favoriscono la loro integrazione. I servizi web sono applicazioni software che possono essere scoperte, descritte e usate

Dettagli

CAPITOLO 1 I SISTEMI OPERATIVI

CAPITOLO 1 I SISTEMI OPERATIVI CAPITOLO 1 I SISTEMI OPERATIVI Introduzione ai sistemi operativi pag. 3 La shell pag. 3 Tipi di sistemi operativi pag. 4 I servizi del sistema operativo pag. 4 La gestione dei file e il file system Il

Dettagli

Architetture Web. parte 1. Programmazione in Ambienti Distribuiti A.A. 2003-04

Architetture Web. parte 1. Programmazione in Ambienti Distribuiti A.A. 2003-04 Architetture Web parte 1 Programmazione in Ambienti Distribuiti A.A. 2003-04 Architetture Web (1) Modello a tre livelli in cui le interazioni tra livello presentazione e livello applicazione sono mediate

Dettagli

Informatica: Evoluzione dei Linguaggi di Specifica e Programmazione. Informatica: Evoluzione dei Linguaggi di Specifica e Programmazione

Informatica: Evoluzione dei Linguaggi di Specifica e Programmazione. Informatica: Evoluzione dei Linguaggi di Specifica e Programmazione Informatica: Evoluzione dei Linguaggi di Specifica e Programmazione Ugo Montanari Dipartimento di Informatica, Università di Pisa 0 Roadmap Perchè i linguaggi? Che cosa sono i linguaggi? Esempio: i numeri

Dettagli

Linguaggi e Paradigmi di Programmazione

Linguaggi e Paradigmi di Programmazione Linguaggi e Paradigmi di Programmazione Cos è un linguaggio Definizione 1 Un linguaggio è un insieme di parole e di metodi di combinazione delle parole usati e compresi da una comunità di persone. È una

Dettagli

Modeling and Testing of Web Services

Modeling and Testing of Web Services Modeling and Testing of Web Services Andrea Polini Dipartimento di Matematica ed Informatica Università degli Studi di Camerino andrea.polini@unicam.it (Andrea Polini) Modeling and Testing of Web Services

Dettagli

Reti e sistemi informativi II Il ruolo delle IT nell organizzazione

Reti e sistemi informativi II Il ruolo delle IT nell organizzazione Reti e sistemi informativi II Il ruolo delle IT nell organizzazione Prof. Andrea Borghesan & Dr.ssa Francesca Colgato venus.unive.it/borg borg@unive.it Ricevimento: mercoledì dalle 10.00 alle 11.00 Modalità

Dettagli

Architettura Tecnica i. Architettura Tecnica

Architettura Tecnica i. Architettura Tecnica i Architettura Tecnica ii Copyright 2005-2011 Link.it s.r.l. iii Indice 1 Scopo del documento 1 1.1 Abbreviazioni..................................................... 1 2 Overview 1 2.1 La PdD........................................................

Dettagli

ESTEEM meeting Sirmione, 16 17 Novembre 2006 Hotel Terme di Sirmione

ESTEEM meeting Sirmione, 16 17 Novembre 2006 Hotel Terme di Sirmione ESTEEM meeting Sirmione, 16 17 Novembre 2006 Hotel Terme di Sirmione NAME ORGANIZATION Tiziana Catarci, Diego Milano, Carola Aiello, Sara Tucci Piergiovanni, Silvia Bonomi Silvana Castano, Stefano Montanelli

Dettagli

MCloud.Gov l infrastruttura SaaS per la Pubblica Amministrazione locale

MCloud.Gov l infrastruttura SaaS per la Pubblica Amministrazione locale MCloud.Gov l infrastruttura SaaS per la Pubblica Amministrazione locale 1. Livello infrastrutturale Il Cloud, inteso come un ampio insieme di risorse e servizi fruibili da Internet che possono essere dinamicamente

Dettagli

Web services. 25/01/10 Web services

Web services. 25/01/10 Web services Web services Tecnologia per il computing distribuito standard W3C non dissimile da RMI, CORBA, EJB... Relazione con il Web Websites for humans, Web Services for software :-) un Web service ha un indirizzo

Dettagli

icaro x PMI ICT Paolo Nesi (UNIFI, DISIT Lab) Feb 2015

icaro x PMI ICT Paolo Nesi (UNIFI, DISIT Lab) Feb 2015 icaro x PMI ICT Paolo Nesi (UNIFI, DISIT Lab) Feb 2015 IaaS, Infrastructure as a Service: Business: vendita di host a consumo Contesto IaaS/PaaS Gestione: limitata al parco degli Host vari Gestori Monitoraggio

Dettagli

Sistemi Web Tolleranti ai Guasti

Sistemi Web Tolleranti ai Guasti Sistemi Web Tolleranti ai Guasti Candidato: Paolo Romano Relatore: Prof. Salvatore Tucci Correlatore: Prof. Bruno Ciciani Sommario Il problema: garantire semantica exactly once alle transazioni Web. Sistema

Dettagli

!"#$%&&'()#*%+%+!"#$"',,'()#*%+ -")%*&'&'+'$.)+-$$%&&) !"#$%&&'(%)'*+%",#-%"#.'%&'#/0)-+#12"+3,)4+56#7+#.')8'9

!#$%&&'()#*%+%+!#$',,'()#*%+ -)%*&'&'+'$.)+-$$%&&) !#$%&&'(%)'*+%,#-%#.'%&'#/0)-+#12+3,)4+56#7+#.')8'9 !"#$%&&'()#*%+%+!"#$"',,'()#*%+ -")%*&'&'+'$.)+-$$%&&)!"#$%&&'(%)'*+%",#-%"#.'%&'#/0)-+#12"+3,)4+56#7+#.')8'9 Slide 1 Paradigmi di Programmazione! Un linguaggio supporta uno stile di programmazione se

Dettagli

Rappresentazione della Conoscenza. Lezione 10. Rappresentazione della conoscenza, D. Nardi, 2004, Lezione 10 0

Rappresentazione della Conoscenza. Lezione 10. Rappresentazione della conoscenza, D. Nardi, 2004, Lezione 10 0 Rappresentazione della Conoscenza Lezione 10 Rappresentazione della conoscenza, D. Nardi, 2004, Lezione 10 0 Sistemi ed applicazioni Sistemi di rappresentazione della conoscenza basati su logiche descrittive.

Dettagli

Ontologie per l Informazione Geografica: prospettive e implementazione

Ontologie per l Informazione Geografica: prospettive e implementazione Ontologie per l Informazione Geografica: prospettive e implementazione Conferenza AM-FM Roma, 21-22 settembre 2006 Roberto Fresco Roberto della Maggiore Indice GIS sul Web: problematiche Semantic Web in

Dettagli

Intalio. Leader nei Sistemi Open Source per il Business Process Management. Andrea Calcagno Amministratore Delegato

Intalio. Leader nei Sistemi Open Source per il Business Process Management. Andrea Calcagno Amministratore Delegato Intalio Convegno Open Source per la Pubblica Amministrazione Leader nei Sistemi Open Source per il Business Process Management Navacchio 4 Dicembre 2008 Andrea Calcagno Amministratore Delegato 20081129-1

Dettagli

HealthSOAF Health Service Oriented Architecture Framework

HealthSOAF Health Service Oriented Architecture Framework HealthSOAF Health Service Oriented Architecture Framework Maria Carmela Groccia, de-health Lab, DIMEG Rosita Guido, Domenico Conforti Università della Calabria Maurizio Rizzo, Giampaolo Sammarco AlmavivA

Dettagli

INTRODUZIONE. Data Base Management Systems evoluzione tecniche gestione dati

INTRODUZIONE. Data Base Management Systems evoluzione tecniche gestione dati INTRODUZIONE Accesso ai dati tramite DBMS Livelli di astrazione Modello dei dati: schema / istanza / metadati Alcuni modelli dei dati Linguaggi per DBMS Architettura di base di un DBMS cesarini - BDSI

Dettagli

Progettazione di Sistemi Interattivi. Gli strati e la rete. Struttura e supporti all implementazione di applicazioni in rete (cenni)

Progettazione di Sistemi Interattivi. Gli strati e la rete. Struttura e supporti all implementazione di applicazioni in rete (cenni) Progettazione di Sistemi Interattivi Struttura e supporti all implementazione di applicazioni in rete (cenni) Docente: Daniela Fogli Gli strati e la rete Stratificazione da un altro punto di vista: i calcolatori

Dettagli