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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Basi di Dati. Introduzione ai sistemi di basi di dati. K.Donno - Introduzione ai sistemi di basi di dati

Basi di Dati. Introduzione ai sistemi di basi di dati. K.Donno - Introduzione ai sistemi di basi di dati Basi di Dati Introduzione ai sistemi di basi di dati Introduzione ai sistemi di basi di dati Gestione dei Dati Una prospettiva storica File system verso DBSM Vantaggi di un DBMS Modelli dei dati Utenti

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

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

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

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

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

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

Sistemi Ipermediali I modelli dei sistemi ipermediali

Sistemi Ipermediali I modelli dei sistemi ipermediali Documenti e ipermedialità Sistemi Ipermediali I modelli dei sistemi ipermediali Augusto Celentano Università Ca Foscari Venezia Documento ipertestuale insieme di informazioni testuali e grafiche, esplorabili

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

Introduzione ai sistemi di basi di dati

Introduzione ai sistemi di basi di dati Basi di Dati Introduzione ai sistemi di basi di dati Alessandro.bardine@gmail.com alessandro.bardine@iet.unipi.it Introduzione ai sistemi di basi di dati Gestione dei Dati Una prospettiva storica File

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

Scriviamo insieme il futuro

Scriviamo insieme il futuro Res User Meeting 2014 con la partecipazione di Scriviamo insieme il futuro Research for Enterprise Systems 1 Generale - 1 Obbiettivo Fornire al Cliente uno strumento a supporto della problematica Legata

Dettagli

Griglie computazionali LEZIONE N. 14. Università degli Studi di Napoli Federico II Corso di Laurea Magistrale in Informatica I Anno

Griglie computazionali LEZIONE N. 14. Università degli Studi di Napoli Federico II Corso di Laurea Magistrale in Informatica I Anno Griglie computazionali Università degli Studi di Napoli Federico II Corso di Laurea Magistrale in Informatica I Anno LEZIONE N. 14 Web Services SOAP WSDL UDDI CE-CREAM SRM Griglie computazionali - a.a.

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

Workflow nella pubblica amministrazione: BPR e simulazione dei workflow inter-organizzativi

Workflow nella pubblica amministrazione: BPR e simulazione dei workflow inter-organizzativi Workflow nella pubblica amministrazione: BPR e simulazione dei workflow inter-organizzativi E.Casalicchio, S.Tucci Corso di Governo Digitale, a.a. 10/11 1 Obiettivi re-ingegnerizzazione dei processi (BPR)

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

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

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

!"#$%&&'()#*%+%+!"#$"',,'()#*%+ -")%*&'&'+'$.)+-$$%&&) !"#$%&&'(%)'*+%",#-%"#.'%&'#/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

Introduzione ad Architetture Orientate ai Servizi e Web Service

Introduzione ad Architetture Orientate ai Servizi e Web Service Università degli Studi di Roma Tor Vergata Facoltà di Ingegneria Introduzione ad Architetture Orientate ai Servizi e Web Service Corso di Sistemi Distribuiti Stefano Iannucci iannucci@ing.uniroma2.it Anno

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

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

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

QUADRO TECNICO D INSIEME

QUADRO TECNICO D INSIEME Sistema Pubblico di Connettività e Cooperazione Sistema pubblico di cooperazione: QUADRO TECNICO D INSIEME Versione 1.0 INDICE 1. MODIFICHE DOCUMENTO...3 2. OBIETTIVI E CONTESTO DI RIFERIMENTO... 4 2.1.

Dettagli

STRATEGIE DI PERSONALIZZAZIONE PER SISTEMI DI COMMERCIO ELETTRONICO SUL WEB

STRATEGIE DI PERSONALIZZAZIONE PER SISTEMI DI COMMERCIO ELETTRONICO SUL WEB STRATEGIE DI PERSONALIZZAZIONE PER SISTEMI DI COMMERCIO ELETTRONICO SUL WEB L. Ardissono, A. Goy, G. Petrone e M. Segnan Dipartimento di Informatica Università di Torino Italia In questo articolo sono

Dettagli

INGEGNERIA DEL SOFTWARE

INGEGNERIA DEL SOFTWARE INGEGNERIA DEL SOFTWARE DESIGN Avvertenza: gli appunti si basano sul corso di Ingegneria del Software tenuto dal prof. Picco della facoltà di Ingegneria del Politecnico di Milano (che ringrazio per aver

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

Definizione di Web service (2) Un introduzione ai Web service. Caratteristiche dei Web service. Valeria Cardellini Università di Roma Tor Vergata

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

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

CURRICULUM VITAE ET STUDIORUM DANILO ARDAGNA

CURRICULUM VITAE ET STUDIORUM DANILO ARDAGNA CURRICULUM VITAE ET STUDIORUM DI DANILO ARDAGNA Maggio 2007 Indice: Dati anagrafici e stato di servizio 2 Attività di ricerca 3 Attività didattiche 8 Elenco dei lavori 10 1. DATI ANAGRAFICI E STATO DI

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

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

Standard Tecnologici Regione Basilicata ALLEGATO C03

Standard Tecnologici Regione Basilicata ALLEGATO C03 Standard Tecnologici Regione Basilicata ALLEGATO C03 UFFICIO S. I. R. S. Standard Tecnologici ver. 2.1 ultimo agg.: 06/06/2012 CONTROLLO DEL DOCUMENTO Data APPROVAZIONI Autore Redatto da: 27/05/2012 Dott.

Dettagli

Implementazione di un. linguaggio di base. per servizi web

Implementazione di un. linguaggio di base. per servizi web Università degli Studi di Firenze FACOLTÀ DI SCIENZE MATEMATICHE, FISICHE E NATURALI Tesi di Laurea in Informatica Implementazione di un linguaggio di base per servizi web Relatore: Prof. Rosario Pugliese

Dettagli

Fondamenti di Informatica 7. Linguaggi di programmazione

Fondamenti di Informatica 7. Linguaggi di programmazione I linguaggi di alto livello Fondamenti di Informatica 7. Linguaggi di programmazione Introduzione alla programmazione Caratteristiche dei linguaggi di programmazione I linguaggi di programmazione di alto

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

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

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

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

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

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

WebRatio. L altra strada per il BPM. Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8

WebRatio. L altra strada per il BPM. Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8 WebRatio L altra strada per il BPM Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8 Il BPM Il BPM (Business Process Management) non è solo una tecnologia, ma più a grandi linee una disciplina

Dettagli

CONVENZIONI DI NOMENCLATURA E SEMANTICA

CONVENZIONI DI NOMENCLATURA E SEMANTICA Sistema pubblico di cooperazione: CONVENZIONI DI NOMENCLATURA E SEMANTICA Versione 1.1 INDICE 1. MODIFICHE DOCUMENTO...3 2. OBIETTIVI E CONTESTO DI RIFERIMENTO... 4 2.1. Scopi del documento... 5 2.2. Note

Dettagli

Modellazione e progettazione con UML. Eduard Roccatello 3D GIS Specialist www.roccatello.it

Modellazione e progettazione con UML. Eduard Roccatello 3D GIS Specialist <eduard.roccatello@3dgis.it> www.roccatello.it Modellazione e progettazione con UML Eduard Roccatello 3D GIS Specialist www.roccatello.it Object Oriented Analysis and Design Consente di modellare un sistema attraverso l

Dettagli

Introduzione ai sistemi di basi di dati

Introduzione ai sistemi di basi di dati Introduzione ai sistemi di basi di dati Basi di dati 1 Introduzione ai sistemi di basi di dati Angelo Montanari Dipartimento di Matematica e Informatica Università di Udine Introduzione ai sistemi di basi

Dettagli

MAX DOLGICER EAI. Architetture, Tecnologie e Best Practices LA TECHNOLOGY TRANSFER PRESENTA

MAX DOLGICER EAI. Architetture, Tecnologie e Best Practices LA TECHNOLOGY TRANSFER PRESENTA LA TECHNOLOGY TRANSFER PRESENTA MAX DOLGICER EAI Architetture, Tecnologie e Best Practices ROMA 26-28 MARZO 2008 RESIDENZA DI RIPETTA - VIA DI RIPETTA, 231 info@technologytransfer.it www.technologytransfer.it

Dettagli

Questo documento riporta informazioni generali sul progetto europeo QALL-ME. Il pubblico al quale si rivolge è ampio e generico e il suo scopo

Questo documento riporta informazioni generali sul progetto europeo QALL-ME. Il pubblico al quale si rivolge è ampio e generico e il suo scopo QALL-ME EXECUTIVE SUMMARY Autore: Bernardo Magnini Presso: ITC-irst, Trento, Italia Introduzione Questo documento riporta informazioni generali sul progetto europeo QALL-ME. Il pubblico al quale si rivolge

Dettagli

CURRICULUM VITAE ET STUDIORUM CIRIACO CIRO PASQUALE. Luglio 2009

CURRICULUM VITAE ET STUDIORUM CIRIACO CIRO PASQUALE. Luglio 2009 CURRICULUM VITAE ET STUDIORUM DI CIRIACO CIRO PASQUALE Luglio 2009 INDICE 1. DATI ANAGRAFICI, FORMAZIONE E STATO DI SERVIZIO 2. ATTIVITÀ DI RICERCA 3. ATTIVITÀ DIDATTICHE 4. PUBBLICAZIONI 5. ATTIVITÀ ORGANIZZATIVE

Dettagli

Framework. Impianti Informatici. Web application - tecnologie

Framework. Impianti Informatici. Web application - tecnologie Framework Web application - tecnologie Web Application: tecnologie 2 Java-based (J2EE) Sviluppata inizialmente da Sun Cross-platform e open source Gestire direttamente le funzionalità dell applicazione

Dettagli

Università degli Studi "Roma Tre" Dipartimento di Informatica ed automazione. Facoltà di Ingegneria. Laurea Magistrale in Ingegneria Informatica

Università degli Studi Roma Tre Dipartimento di Informatica ed automazione. Facoltà di Ingegneria. Laurea Magistrale in Ingegneria Informatica Università degli Studi "Roma Tre" Dipartimento di Informatica ed automazione Facoltà di Ingegneria Laurea Magistrale in Ingegneria Informatica Tesi di Laurea Sistema informativo per la gestione dei processi

Dettagli

Progettazione: Tecnologie e ambienti di sviluppo

Progettazione: Tecnologie e ambienti di sviluppo Contratto per l acquisizione di servizi di Assistenza specialistica per la gestione e l evoluzione del patrimonio software della Regione Basilicata. Repertorio n. 11016 del 25/09/2009 Progettazione: Tecnologie

Dettagli

MAX DOLGICER ROMA 17-19 NOVEMBRE 2008 ROMA 20-21 NOVEMBRE 2008 VISCONTI PALACE HOTEL - VIA FEDERICO CESI, 37

MAX DOLGICER ROMA 17-19 NOVEMBRE 2008 ROMA 20-21 NOVEMBRE 2008 VISCONTI PALACE HOTEL - VIA FEDERICO CESI, 37 LA TECHNOLOGY TRANSFER PRESENTA MAX DOLGICER Architettura, Governance, Standards e Tecnologie Modellare, progettare e implementare applicazioni ROMA 17-19 NOVEMBRE 2008 ROMA 20-21 NOVEMBRE 2008 VISCONTI

Dettagli

SOA e Web Service SISTEMI INFORMATIVI MODULO II. Corso di Sistemi Informativi Modulo II A. A. 2013-2014

SOA e Web Service SISTEMI INFORMATIVI MODULO II. Corso di Sistemi Informativi Modulo II A. A. 2013-2014 Corso di Laurea Magistrale in Ingegneria Gestionale Corso di Sistemi Informativi Modulo II A. A. 2013-2014 SISTEMI INFORMATIVI MODULO II SOA e Web Service Figure tratte dal testo di riferimento, Copyright

Dettagli

UX model e Architetture di SI web-based. B. Pernici D. Ardagna

UX model e Architetture di SI web-based. B. Pernici D. Ardagna UX model e Architetture di SI web-based B. Pernici D. Ardagna Conallen, cap. 7,9 Bibliografia Modellazione concettuale: UX model Primo passo di analisi UX: user experience Schermate Modellare la navigazione,

Dettagli

icaro x Cloud Service Provider Paolo Nesi (UNIFI, DISIT Lab) Feb 2015

icaro x Cloud Service Provider Paolo Nesi (UNIFI, DISIT Lab) Feb 2015 icaro x Cloud Service Provider Paolo Nesi (UNIFI, DISIT Lab) Feb 2015 IaaS, Infrastructure as a Service: Contesto IaaS 2 Business: vendita di host a consumo Gestione: limitata al parco degli Host vari

Dettagli

Dalla Mappatura dei Processi al Business Process Management

Dalla Mappatura dei Processi al Business Process Management Dalla Mappatura dei Processi al Business Process Management Romano Stasi Responsabile Segreteria Tecnica ABI Lab Roma, 4 dicembre 2007 Agenda Il percorso metodologico Analizzare per conoscere: la mappatura

Dettagli

[Larman] Applicare UML e i pattern, Capitolo 28, Diagrammi di attività di UML e modellazione

[Larman] Applicare UML e i pattern, Capitolo 28, Diagrammi di attività di UML e modellazione Luca Cabibbo Architetture Software Dispensa T 1 ottobre 2008 1 -Fonti [Larman] Applicare UML e i pattern, Capitolo 28, Diagrammi di attività di UML e modellazione [Larman] Applicare UML e i pattern, Capitolo

Dettagli