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

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

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

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

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

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

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

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

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

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

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

Le Basi di dati: generalità. Unità di Apprendimento A1 1

Le Basi di dati: generalità. Unità di Apprendimento A1 1 Le Basi di dati: generalità Unità di Apprendimento A1 1 1 Cosa è una base di dati In ogni modello di organizzazione della vita dell uomo vengono trattate informazioni Una volta individuate e raccolte devono

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ciclo di Vita Evolutivo

Ciclo di Vita Evolutivo Ciclo di Vita Evolutivo Prof.ssa Enrica Gentile a.a. 2011-2012 Modello del ciclo di vita Stabiliti gli obiettivi ed i requisiti Si procede: All analisi del sistema nella sua interezza Alla progettazione

Dettagli

EXPLOit Content Management Data Base per documenti SGML/XML

EXPLOit Content Management Data Base per documenti SGML/XML EXPLOit Content Management Data Base per documenti SGML/XML Introduzione L applicazione EXPLOit gestisce i contenuti dei documenti strutturati in SGML o XML, utilizzando il prodotto Adobe FrameMaker per

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

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

Informatica Documentale

Informatica Documentale Informatica Documentale Ivan Scagnetto (scagnett@dimi.uniud.it) Stanza 3, Nodo Sud Dipartimento di Matematica e Informatica Via delle Scienze, n. 206 33100 Udine Tel. 0432 558451 Ricevimento: giovedì,

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

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

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

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

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

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

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

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

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

Il File System. È la componente del S.O. che si occupa della gestione della memoria di massa e dell organizzazione logica dei dati

Il File System. È la componente del S.O. che si occupa della gestione della memoria di massa e dell organizzazione logica dei dati Il File System È la componente del S.O. che si occupa della gestione della memoria di massa e dell organizzazione logica dei dati Le operazioni supportate da un file system sono: eliminazione di dati modifica

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

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

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

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

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

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

Analisi dei requisiti e casi d uso

Analisi dei requisiti e casi d uso Analisi dei requisiti e casi d uso Indice 1 Introduzione 2 1.1 Terminologia........................... 2 2 Modello del sistema 4 2.1 Requisiti hardware........................ 4 2.2 Requisiti software.........................

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

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

Il sistema operativo

Il sistema operativo Il sistema operativo Percorso di Preparazione agli Studi di Ingegneria Università degli Studi di Brescia Docente: Massimiliano Giacomin Cos è un Sistema Operativo? Per capirlo, immaginiamo inizialmente

Dettagli

Modellazione di sistema

Modellazione di sistema Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Modellazione di sistema E. TINELLI Contenuti Approcci di analisi Linguaggi di specifica Modelli di

Dettagli

TECNICO SUPERIORE PER I SISTEMI E LE TECNOLOGIE INFORMATICHE

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

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

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 Prerequisiti per

Dettagli

FONDAMENTI di INFORMATICA L. Mezzalira

FONDAMENTI di INFORMATICA L. Mezzalira FONDAMENTI di INFORMATICA L. Mezzalira Possibili domande 1 --- Caratteristiche delle macchine tipiche dell informatica Componenti hardware del modello funzionale di sistema informatico Componenti software

Dettagli

Tecnopolis CSATA s.c.r.l. APQ in Materia di Ricerca Scientifica nella Regione Puglia

Tecnopolis CSATA s.c.r.l. APQ in Materia di Ricerca Scientifica nella Regione Puglia BANDO ACQUISIZIONI Prodotti Software ALLEGATO 6.3 Capitolato Tecnico Piattaforma per l Analisi e la Progettazione di alto livello del Software Allegato 6.3: capitolato tecnico Pag. 1 1 Ambiente di Analisi

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

MODELLAZIONE DEI PROCESSI AZIENDALI. workflow 1

MODELLAZIONE DEI PROCESSI AZIENDALI. workflow 1 MODELLAZIONE DEI PROCESSI AZIENDALI workflow 1 I Processi Definizione: Un Processo è un insieme di attività elementari svolte per raggiungere un certo obiettivo Tipologie di processi: Processi Fisici es.

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

Introduzione alla Programmazione ad Oggetti in C++

Introduzione alla Programmazione ad Oggetti in C++ Introduzione alla Programmazione ad Oggetti in C++ Lezione 1 Cosa è la Programmazione Orientata agli Oggetti Metodologia per costruire prodotti software di grosse dimensioni che siano affidabili e facilmente

Dettagli

SDD System design document

SDD System design document UNIVERSITA DEGLI STUDI DI PALERMO FACOLTA DI INGEGNERIA CORSO DI LAUREA IN INGEGNERIA INFORMATICA TESINA DI INGEGNERIA DEL SOFTWARE Progetto DocS (Documents Sharing) http://www.magsoft.it/progettodocs

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

MODELLAZIONE DEI PROCESSI AZIENDALI. workflow 1

MODELLAZIONE DEI PROCESSI AZIENDALI. workflow 1 MODELLAZIONE DEI PROCESSI AZIENDALI workflow 1 I Processi Definizione: Un Processo è un insieme di attività elementari svolte per raggiungere un certo obiettivo Tipologie di processi: Processi Fisici es.

Dettagli

Manuale Gestione di OpenSPCoop 1.4 i. Manuale Gestione di OpenSPCoop 1.4

Manuale Gestione di OpenSPCoop 1.4 i. Manuale Gestione di OpenSPCoop 1.4 i Manuale Gestione di OpenSPCoop 1.4 ii Copyright 2005-2011 Link.it srl iii Indice 1 Introduzione 1 2 Prerequisiti per la Configurazione della Porta di Dominio 1 2.1 Verifica dell applicazione di gestione

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

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

Pag. 1 WIDE (I) josh: la piattaforma software per il KM. josh - Modello logico WIDE (II) josh - Modello fisico. Modello dei processi (I)

Pag. 1 WIDE (I) josh: la piattaforma software per il KM. josh - Modello logico WIDE (II) josh - Modello fisico. Modello dei processi (I) : la piattaforma software per il KM Nicolino Ambrosini it Consult WIDE (I) WIDE (Workflows on an Intelligent and Distribuited database Environment) E un progetto ESPRIT, il programma della Comunità Europea

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

Gestione Requisiti. Ingegneria dei Requisiti. Requisito. Tipi di Requisiti e Relativi Documenti. La gestione requisiti consiste in

Gestione Requisiti. Ingegneria dei Requisiti. Requisito. Tipi di Requisiti e Relativi Documenti. La gestione requisiti consiste in Ingegneria dei Requisiti Il processo che stabilisce i servizi che il cliente richiede I requisiti sono la descrizione dei servizi del sistema Funzionalità astratte che il sistema deve fornire Le proprietà

Dettagli

Metodologia Classica di Progettazione delle Basi di Dati

Metodologia Classica di Progettazione delle Basi di Dati Metodologia Classica di Progettazione delle Basi di Dati Metodologia DB 1 Due Situazioni Estreme Realtà Descritta da un documento testuale che rappresenta un insieme di requisiti del software La maggiore

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

Progettaz. e sviluppo Data Base

Progettaz. e sviluppo Data Base Progettaz. e sviluppo Data Base! Introduzione ai Database! Tipologie di DB (gerarchici, reticolari, relazionali, oodb) Introduzione ai database Cos è un Database Cos e un Data Base Management System (DBMS)

Dettagli

Principi dell ingegneria del software Relazioni fra

Principi dell ingegneria del software Relazioni fra Sommario Principi dell ingegneria del software Leggere Cap. 3 Ghezzi et al. Principi dell ingegneria del software Relazioni fra Principi Metodi e tecniche Metodologie Strumenti Descrizione dei principi

Dettagli

Il Sistema Operativo. C. Marrocco. Università degli Studi di Cassino

Il Sistema Operativo. C. Marrocco. Università degli Studi di Cassino Il Sistema Operativo Il Sistema Operativo è uno strato software che: opera direttamente sull hardware; isola dai dettagli dell architettura hardware; fornisce un insieme di funzionalità di alto livello.

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

http://mb.unisalento.it/index.htm

http://mb.unisalento.it/index.htm Appunti Fondamenti di Informatica 7/05/015 I motori di ricerca Algoritmi e strutture dati I motori di ricerca sono tra i servizi internet maggiormente utilizzati. Come in un libro sono generalmente presenti

Dettagli

SISTEMI OPERATIVI DISTRIBUITI

SISTEMI OPERATIVI DISTRIBUITI SISTEMI OPERATIVI DISTRIBUITI E FILE SYSTEM DISTRIBUITI 12.1 Sistemi Distribuiti Sistemi operativi di rete Sistemi operativi distribuiti Robustezza File system distribuiti Naming e Trasparenza Caching

Dettagli

Configuratore di Prodotto Diapason

Configuratore di Prodotto Diapason Configuratore di Prodotto Diapason Indice Scopo di questo documento...1 Perché il nuovo Configuratore di Prodotto...2 Il configuratore di prodotto...3 Architettura e impostazione tecnica...5 Piano dei

Dettagli

DD - Design Document

DD - Design Document Politecnico di Milano Progetto di Ingegneria del Software 2 DD - Design Document Autori: Claudia Foglieni Giovanni Matteo Fumarola Massimo Maggi Professori: Elisabetta Di Nitto Raffaela Mirandola 1 gennaio

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

Modellazione dei dati in UML

Modellazione dei dati in UML Corso di Basi di Dati e Sistemi Informativi Modellazione dei dati in UML Angelo Montanari Dipartimento di Matematica e Informatica Università degli Studi di Udine Introduzione UML (Unified Modeling Language):

Dettagli

SWIM v2 Design Document

SWIM v2 Design Document PROGETTO DI INGEGNERIA DEL SOFTWARE 2 SWIM v2 DD Design Document Matteo Danelli Daniel Cantoni 22 Dicembre 2012 1 Indice Progettazione concettuale Modello ER Entità e relazioni nel dettaglio User Feedback

Dettagli

SOA GOVERNANCE: WHAT DOES IT MEAN? Giorgio Marras

SOA GOVERNANCE: WHAT DOES IT MEAN? Giorgio Marras SOA GOVERNANCE: WHAT DOES IT MEAN? Giorgio Marras 2 Introduzione Le architetture basate sui servizi (SOA) stanno rapidamente diventando lo standard de facto per lo sviluppo delle applicazioni aziendali.

Dettagli

Caratteristiche principali. Contesti di utilizzo

Caratteristiche principali. Contesti di utilizzo Dalle basi di dati distribuite alle BASI DI DATI FEDERATE Antonella Poggi Dipartimento di Informatica e Sistemistica Antonio Ruberti Università di Roma La Sapienza Anno Accademico 2006/2007 http://www.dis.uniroma1.it/

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

Abstract Data Type (ADT)

Abstract Data Type (ADT) Abstract Data Type Pag. 1/10 Abstract Data Type (ADT) Iniziamo la nostra trattazione presentando una nozione che ci accompagnerà lungo l intero corso di Laboratorio Algoritmi e Strutture Dati: il Tipo

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

PROGRAMMAZIONE MODULARE DI INFORMATICA CLASSE QUINTA - INDIRIZZO MERCURIO SEZIONE TECNICO

PROGRAMMAZIONE MODULARE DI INFORMATICA CLASSE QUINTA - INDIRIZZO MERCURIO SEZIONE TECNICO PROGRAMMAZIONE MODULARE DI INFORMATICA CLASSE QUINTA - INDIRIZZO MERCURIO SEZIONE TECNICO Modulo 1: IL LINGUAGGIO HTML Formato degli oggetti utilizzati nel Web Elementi del linguaggio HTML: tag, e attributi

Dettagli