UNIVERSITÀ DEGLI STUDI DI CAGLIARI

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "UNIVERSITÀ DEGLI STUDI DI CAGLIARI"

Transcript

1 UNIVERSITÀ DEGLI STUDI DI CAGLIARI FACOLTÀ DI SCIENZE MATEMATICHE FISICHE E NATURALI Corso di Laurea Specialistica in Tecnologie Informatiche Anno Accademico Applicazioni Distribuite mediante Web Service e sistemi di Workflow Tesi di Laurea di Antonio Pintus Relatore Prof. Andrea Bosin

2 Questo lavoro è dedicato in particolare modo a Claudia, per tantissimi e importanti motivi ma soprattutto per il sostegno e l'incoraggiamento che negli ultimi due anni non è mai mancato. Ringrazio la mia famiglia: papà Franco, mamma Anna e mia sorella Maria Delfina, per l'appoggio costante e per essere come sono. Ringrazio il Prof. Andrea Bosin per l'aiuto, la pazienza e la competenza. Un caloroso ringraziamento va agli amici Stefano Sanna, Andrea Piras e Luca Atzori, per esserci, sempre. 2

3 Indice generale. Introduzione Service Oriented Architecture Tecnologia dei Web Service Web Services Description Language (WSDL) Universal Description Discovery and Integration (UDDI) Simple Object Access Protocol (SOAP) Web Services Orchestration BPEL, Business Process Execution Language (for Web Services) Ambienti e tool di sviluppo per i Web Service in Java Apache Tomcat Apache Axis Sistemi di gestione di Workflow Process Parallel Routing Sequential Routing AND-Split AND-Join OR-Split OR-Join

4 3.8.Iteration Pre-Condition Post-Condition Transition Transition Condition Analisi di due Workflow Management System per l'e-science Taverna Triana Distributed Computing con Triana Funzionalità di Taverna e Triana a confronto Sequential Routing Parallel Routing Conditional Processing Iteration Bioinformatica e servizi per la bioinformatica Un esempio di applicazione dei Web Service e sistemi di Workflow alla bioinformatica Un possibile scenario applicativo Conclusioni Bibliografia

5 8. APPENDICE A... 5

6 Indice delle figure Figura : I tre attori principali nell'architettura dei Web Service... 6 Figura 2: Il descrittore WSDL per un semplice Web Service...9 Figura 3: Il documento XML Schema con la dichiarazione dei tipi di dato utilizzati nel WSDL della figura precedente... 2 Figura 4: UDDI Registry, attori e suo utilizzo...22 Figura 5: La struttura di un generico messaggio SOAP Figura 6: Messaggio SOAP inviato dall'applicazione client al Web Service per ottenere la somma degli interi 2 e Figura 7: Messaggio SOAP, inviato dal Web Service al client, per comunicare la somma dei due interi specificati nella richiesta, ossia il risultato dell'operazione remota...26 Figura 8: Esempio di documento di descrizione di un workflow espresso in BPEL Figura 9: Rappresentazione grafica di un processo BPEL (creato con Netbeans, un popolare ambiente di sviluppo per Java)...35 Figura : Apache Tomcat visto come una "blackbox"...38 Figura : L'architettura interna di Apache Tomcat...39 Figura 2: Il Workflow Reference Model secondo la Workflow Management Coalition (WfMC)...44 Figura 3: Architettura generica della definizione di un processo di workflow secondo la WfMC...45 Figura 4: Il meta-modello di base per la definizione di un workflow così come definito dalla WfMC...47 Figura 5: Un processo come sequenza di attività... 5 Figura 6: AND-Split...5 6

7 Figura 7: AND-Join Figura 8: OR-Split Figura 9: OR-Join Figura 2: Iteration...53 Figura 2: Il workbench di Taverna con un workflow in fase di design Figura 22: Esecuzione di un workflow in Taverna, la finestra dell'enactor mostra il flusso d'esecuzione e gli eventuali problemi, come in questo caso Figura 23: Documento in formato XSCUFL per la descrizione di un workflow in Taverna...6 Figura 24: L'ambiente di Triana con la composizione e la personalizzazione di un workflow Figura 25: Architettura generale di Triana...65 Figura 26: Formato XML nativo di Triana per la descrizione dei workflow...73 Figura 27: Workflow realizzato con Taverna per incrementare di uno la somma di due numeri casuali...79 Figura 28: Workflow realizzato con Triana per incrementare di uno la somma di due numeri casuali Figura 29: Parallel Routing in Taverna...8 Figura 3: Parallel Routing in Triana...8 Figura 3: Lo script in Java, per il confronto di due numeri in virgola mobile, che viene eseguito da BeanShell all'interno di Taverna Figura 32: Workflow con salto condizionato in Taverna...82 Figura 33: Implicit Iteration in Taverna; se ad un processore che accetta un parametro a in input viene passata una lista di elementi, Taverna applica automaticamente un iterazione invocando il processore per ciascun elemento in lista Figura 34: Le due diverse configurabili strategie di iterazione in Taverna nel caso 7

8 di parametri multipli: strategie di cross e dot product Figura 35: Implementazione di un loop in Triana: utilizzando il componente Loop ed impostando la condizione d'uscita tra le sue proprietà possiamo creare un ciclo condizionato. In questo esempio viene invocato un Web Service che genera un numero casuale il quale viene incrementato (sempre mediante l'invocazione di un servizio remoto) per volte Figura 36: Esempio di un microarray con circa 4 DNA spot...9 Figura 37: Esperimento di classificazione di attributi genomici mediante workflow composto con Triana: i componenti in celeste sono i componenti locali all'ambiente, in rosso i componenti distribuiti, ovvero i Web Service dislocati su macchine remote...93 Figura 38: Esperimento di classificazione di attributi genomici mediante workflow composto con Taverna: i componenti in violetto sono i componenti locali all'ambiente, in verde i componenti distribuiti, ovvero i Web Service dislocati su macchine remote; in figura sono messi in evidenza anche le operazioni invocate Figura 39: I risultati dell'esperimento effettuato vengono sia scritti su file in locale, sia mostrato a video come richiesto dai due workflow, creati ed eseguiti in Triana e Taverna, per un attributenumber uguale a Figura 4: Risultati per l'esperimento ripetuto facendo uso dell'implicit loop di Taverna, in input la lista di valori, 5, 8,, 2, 5, 8, 2, 22, 25, 28, 3, 32, 35, 38, 4 come attributenumber, ovvero il numero di feature da selezionare di volta in volta...98 Figura 4: Il nuovo workflow, realizzato con Triana, per ripetere ciclicamente l'esperimento con una lista di attributenumber passata in input mediante il parametro inputlist...99 Figura 42: Scenario collaborativo per esperimenti scientifici, reso possibile 8

9 dall'utilizzo congiunto di SOA, Web Service e di Workflow Management System... 9

10 Indice delle tabelle Tabella : Le possibili combinazioni di Binding Style, Encoding Style in un messaggio SOAP Tabella 2: Operazioni esposte dal SimpleMathWebService, Web Service di test Tabella 3: Le operazione esposte dal UtilitiesWebService, Web Service di test...77 Tabella 4: Operazioni remote messe a disposizione dai Web Service implementati per esperimenti di bioinformatica... 92

11 . Introduzione. Introduzione A partire dagli anni '7, sono state date molteplici definizioni di sistema distribuito, naturalmente ognuna risentiva delle tecnologie e della visione dell'hardware e del software all'epoca prevalenti. Nel 995, ad esempio, Andrew S. Tanembaum dava la seguente definizione: un sistema distribuito consiste di un insieme di calcolatori indipendenti che appaiono all'utente del sistema come un singolo calcolatore [22], ma anche questa definizione era decisamente orientata verso una definizione di un sistema operativo distribuito piuttosto che verso una visione fatta di applicazioni distribuite. In questo lavoro, per sistemi distribuiti, intendiamo piuttosto applicazioni indipendenti, distribuite in rete, che cooperano per il raggiungimento di un risultato comune e la comunicazione tra di esse avviene mediante lo scambio di messaggi. Lo studio e la realizzazione di tecnologie e strumenti per l'implementazione di una reale cooperazione tra sistemi, anche decisamente eterogenei tra loro, è stato il motore che ha fatto si che fossero creati sistemi come CORBA, Java RMI, DCOM, XML-RPC ed altri. Negli ultimi anni, con l'introduzione della tecnologia dei Web Service e la connessa definizione di protocolli per lo scambio dei messaggi tra applicazioni, come SOAP, si è assistito ad una ulteriore evoluzione nel campo delle applicazioni distribuite. Infatti, con il grande successo che questa tecnologia ha avuto e sta avendo, e quindi grazie ad una sua ampia adozione nei più eterogenei domini applicativi, per esempio applicazioni di e-business, e-learning, escience e bioinformatica, tanto per citarne qualcuna, si sta vivendo ora in una nuova era dei sistemi distribuiti, quella delle architetture orientate ai servizi (Service Oriented Architectures) nelle quali le applicazioni distribuite in rete sono viste come servizi, perché in grado di fare o fornire qualcosa di utile a qualunque altra applicazione ne avesse bisogno per il completamento delle proprie funzionalità o

12 . Introduzione per il raggiungimento di uno scopo prefissato; di conseguenza sono stati coniati termini come Web Service Orchestration e Web Service Coreography che rendono l'idea di un nuovo modo di concepire e vedere le applicazioni distribuite ed il suo utilizzo, finalmente consentendo la comunicazione tra sistemi, piattaforme (implementative e di supporto) ed applicazioni spesso realmente eterogenee tra loro nonché dislocate fisicamente su macchine remote connesse ad Internet. Con questa nuova prospettiva per i sistemi distribuiti, ritornano in auge, concetti come i workflow e i relativi Workflow Management System, che trovano anch'essi nuova vita e reale terreno fertile per una loro applicazione e diffusione. In questo lavoro verranno analizzati tutti questi argomenti, sia dal punto di vista teorico e dello stato dell'arte, sia dal punto di vista applicativo, dando preferenza ai Web Service realizzati mediante SOAP (anziché quelli, emergenti, realizzati attraverso il modello REST, Representational State Transfer) e con la presentazione di due sistemi di workflow, entrambi disponibili secondo il modello open-source, entrambi orientati alle applicazioni di carattere scientifico. Si parlerà anche dello standard BPEL (Business Process Execution Language) ma quest'ultimo verrà relegato solamente al discorso sullo stato dell'arte perché uno degli scopi di questo lavoro è capire la reale applicabilità dei sistemi di workflow orientati all'e-science e alla bioinformatica in particolare modo; a tal proposito, nell'ultima parte di questo documento, verrà presentato un reale esperimento di applicazione dei workflow e della tecnologia dei Web Service alla bioinformatica e al data-mining di dati genomici. 2

13 2. Service Oriented Architecture 2. Service Oriented Architecture La Service Oriented Architecture (SOA) nasce principalmente per rispondere all'esigenza di integrare tra loro sistemi, generalmente eterogenei, orientati al Business to Business (B2B). Quindi l'introduzione delle tecnologie riunite attorno al concetto di SOA, agiscono con lo scopo primario di realizzare un passaggio da un mondo di architetture eterogenee alla creazione di una infrastruttura di integrazione che ne permetta un loro collegamento. In modo più astratto: la SOA può essere considerata come un'architettura il cui scopo è il raggiungimento di un disaccoppiamento tra agenti software interagenti tra loro. Un servizio è inteso, quindi, come una unità di lavoro eseguita da un particolare fornitore di servizi in grado di soddisfare una particolare esigenza per un consumatore di quel servizio che ne fa esplicita richiesta. Entrambi i ruoli di fornitore e consumatore del servizio sono ricoperti da agenti software sotto richiesta dei loro implementatori []. Per completare il nostro punto di vista, la SOA può essere considerata sia come una architettura avente le caratteristiche principali sopra riportate, sia un modello di programmazione, ovvero una filosofia per la costruzione di software; infatti, la SOA, permette ora di progettare sistemi software con l'idea (di più alto livello) che essi forniscano dei servizi rivolti ad altre applicazioni, esponendo una interfaccia ben definita che può essere pubblicata e ricercata ed i servizi offerti possano essere invocati attraverso una rete. I pilastri su cui si basa la SOA sono costituiti da una serie di standard e tecnologie che vengono illustrate nelle sezioni seguenti; parte fondamentale per una reale implementazione della SOA, la ricopre la tecnologia dei Web Service: implementando la SOA utilizzando questa tecnologia, significa implementare applicazioni software con un modello di programmazione potente e più flessibile, potendo prescindere dalle piattaforme e dai linguaggi utilizzati. 3

14 2. Service Oriented Architecture Il futuro della SOA, come ogni altro modello o tecnologia, è rappresentato dalla sua reale applicazione e già due concetti emergenti stanno cominciando a diventare significativi: GRID computing e on-demand computing [23]. Rappresentando ogni applicazione, risorsa o funzionalità business come un servizio dotato di una interfaccia standardizzata, si raggiunge l'opportunità di combinare applicazioni esistenti e nuove per la costruzione di soluzioni di successo nei più svariati campi d'applicazione. 2.. Tecnologia dei Web Service La tecnologia dei Web Service, negli ultimi anni, ha cambiato e sta cambiando Internet [3] introducendo la possibilità di usare la rete per costituire un Web transazionale; con l'introduzione dei Web Service, si è permessa l'evoluzione del Web da quello più prettamente program-to-user o business-to-consumer (B2C) al Web transazionale con l'aggiunta di applicazioni del tipo program-to-program, ovvero le cosiddette applicazioni Business-to-Business (B2C). Questa evoluzione è alimentata dalla tecnologia dei Web Service, la quale si basa su alcuni standard, ora ben definiti, alcuni dei quali esistenti da tempo; essi sono: HyperText Transfer Protocol, (HTTP), Extensible Markup Language (XML), Simple Object Access Protocol (SOAP), WebServices Description Language (WSDL), e Universal Description, Discovery, and Integration (UDDI). Prima di esaminare brevemente cosa queste tecnologie permettono di fare e come sono usate, possiamo affermare che la tecnologia Web Service ha permesso di definire un sistema, indipendente dai linguaggi di programmazione, indipendente dalle piattaforma utilizzata e che permette di ridurre i tempi di 4

15 2. Service Oriented Architecture integrazione nelle applicazioni di classe enterprise. Questa integrazione può ora avvenire mediante un basso livello di accoppiamento tra i sistemi di business. Essenzialmente, un Web Service, è un'interfaccia la quale descrive una collezione di operazioni che possono essere invocate da remoto attraverso un sistema di scambio di messaggi basati su un formato XML standardizzato. Un Web Service mette a disposizione, quindi, una serie di operazioni, le quali possono corrispondere ai più svariati domini di applicazione; la descrizione del particolare Web Service e di queste sue pubbliche funzionalità sono esplicitate mediante un altro standard, basato su XML, che viene chiamato il descrittore del servizio. Il descrittore non solo elenca queste funzionalità, ma fornisce tutti i dettagli necessari per l'interazione con il servizio: il formato dei messaggi, i tipi di dato utilizzati, l'url al quale è possibile contattare il servizio, il protocollo di trasporto da utilizzare. Il descrittore è espresso mediante il formato WSDL (WebServices Description Language). Per analizzare l'architettura e gli attori coinvolti nella tecnologia Web Service, individuiamo tre ruoli principali: il Service Provider, il Service Client, il Service Registry. 5

16 2. Service Oriented Architecture Figura : I tre attori principali nell'architettura dei Web Service Come illustrato nella figura precedente, un Service Provider crea un Web Service e il suo file descrittore (WSDL) e pubblica la descrizione su un Service Registry basato su UDDI (Universal Description, Discovery and Integration). Una volta pubblicato, un potenziale Service Client può trovare (fase di discovery) il servizio interrogando a sua volta il Service Registry ed utilizzando l'interfaccia UDDI. Il Service Registry, se in grado, soddisfa la richiesta del Service Client fornendogli il descrittore espresso in formato WSDL e un URL al quale contattare il Web Service vero e proprio. Il Service Client, a questo punto, è in grado di effettuare il bind del servizio e iniziare ad invocare le operazioni remote messe a disposizione da quest'ultimo utilizzando le giuste convenzioni (nome metodo e parametri) come descritte nel suo descrittore WSDL. A questo punto le operazioni di richiesta-risposta tra Service Client e Web Service avvengono mediante lo scambio di messaggi espressi secondo le specifiche definite da 6

17 2. Service Oriented Architecture SOAP (Simple Object Access Protocol) Web Services Description Language (WSDL) WSDL è un formato XML, creato per descrivere dei web service nella rete come un insieme di endpoint i quali sono capaci di operare su una comunicazione basata su messaggi, contenenti sia informazioni orientate ai documenti, sia informazioni orientate alle procedure[]. Le operazioni e i messaggi vengono descritti in modo astratto e successivamente vengono associate ad un protocollo di rete ben noto e ad un formato di messaggio, a scelta tra quelli consentiti, allo scopo di definire un endpoint. In linea generale, un documento WSDL definisce i servizi come collezioni di endpoint o port e, come detto in precedenza, la definizione astratta di questi ultimi e dei messaggi è separata dalla loro concreta definizione in termini di formato di dati o protocolli di rete; questa separazione permette un riutilizzo delle definizioni astratte: messaggi, che altro non sono che le descrizioni dei dati scambiati, e tipi di porte, le quali sono collezioni astratte di operazioni. Una porta viene definita associando un indirizzo di rete ad una definizione riutilizzabile ed un insieme di porte definiscono un servizio. Concretamente, un documento WSDL utilizza i seguenti elementi nella definizione dei servizi: Types: contenitore di definizioni di tipi di dati facente uso di qualche sistema di definizione di tipi (per esempio XML Schema); Message: definizione astratta e tipizzata dei dati che vengono comunicati; 7

18 2. Service Oriented Architecture Operation: descrizione astratta di un'azione messa a disposizione dal servizio; Port Type: insieme astratto di operazioni messe a disposizione da uno o più endpoint; Binding: protocollo concreto e definizione di un formato di dati per una particolare port type; Port: singolo endpoint definito dalla coppia indirizzo di rete binding; Service: un insieme di endpoint; Una importante caratteristica di WSDL è che esso non introduce un nuovo linguaggio di definizione dei tipi di dato; WSDL riconosce la necessità di avere tipi di dato sufficienti per descrivere dati strutturati nel formato dei messaggi, perciò, a tal uopo, supporta le specifiche del XML Schema (XSD) come il proprio sistema standard di descrizione dei tipi. Questo non limita, comunque, l'estensibilità del formato WSDL, il quale rimane aperto verso altri linguaggi di definizione dei tipi di dato. 8

19 2. Service Oriented Architecture Figura 2: Il descrittore WSDL per un semplice Web 9 Service

20 2. Service Oriented Architecture La seguente figura mostra un documento WSDL che descrive un semplice Web Service il quale espone due operation, ovvero i metodi invocabili da remoto, chiamate somma e incrementa: la prima delle due effettua la somma tra due numeri e restituisce il risultato e la seconda incrementa un valore numero passato come parametro restituendo anch'essa il risultato. I tipi di dato utilizzati sia nei parametri, sia nei valori restituiti, sono specificati mediante un XML Schema, riportato nella seguente figura: Figura 3: Il documento XML Schema con la dichiarazione dei tipi di dato utilizzati nel WSDL della figura precedente 2

21 2. Service Oriented Architecture Universal Description Discovery and Integration (UDDI) Il protocollo UDDI, sviluppato dalla Organization for the Advancement of Structured Information Standards (OASIS), costituisce uno dei protocolli chiave facenti parte dell'insieme di quelli definiti per l'implementazione dei fondamenti della tecnologia dei Web Service. Esso definisce una metodologia standard per la pubblicazione e il discovery in una Service-Oriented Architecture (SOA)[2]. Lo standard UDDI definisce, come illustrato in figura, i protocolli per poter accedere ad un registry di Web Service, fornisce i metodi per controllare l'accesso a questo registro e un meccanismo per distribuire o delegare i dati, presenti in esso, verso altri registri. In pratica, un registro UDDI fornisce un approccio standardizzato per consentire la localizzazione di un servizio software, per invocare le operazioni che tale servizio mette a disposizione e per gestirne i metadati associati. UDDI è giunto oramai alla versione 3., introdotta a quattro anni di distanza dalla versione., rilasciata nel 2. La seguente figura illustra uno scenario con gli utilizzi tipici di un registro UDDI. 2

22 2. Service Oriented Architecture Figura 4: UDDI Registry, attori e suo utilizzo 22

23 2. Service Oriented Architecture Simple Object Access Protocol (SOAP) Definito dal W3C, SOAP è un protocollo, basato su XML, per lo scambio di messaggi tra componenti software ed è divenuto il linguaggio standard con cui vengono codificati i messaggi inviati tra i Web Service e le loro applicazioni client. Raggiunta la versione.2, SOAP viene definito leggero dal W3C, ed è stato creato, come detto precedentemente, allo scopo di realizzare lo scambio di informazioni strutturate tra applicazioni in un ambiente distribuito e decentralizzato. SOAP è basato sulle tecnologie XML allo scopo di definire un framework estensibile per lo scambio di messaggi fornendo un costrutto che può essere scambiato grazie ad una varietà di sottostanti protocolli di comunicazione; ancora, SOAP è stato progettato per rimanere indipendente da un particolare modello di programmazione o da altre specifiche semantiche d'implementazione [3]. Per alcuni suoi aspetti, possiamo affermare che SOAP si pone in qualche modo come un'evoluzione del più semplice protocollo di Remote Procedure Call noto come XML-RPC. Un messaggio SOAP è un normale documento XML che contiene i seguenti elementi: un Envelope, elemento obbligatorio che identifica il documento XML come un messaggio SOAP; un Header, elemento opzionale che contiene informazioni di tipo header; un Body, elemento richiesto il quale contiene le informazioni sulla chiamata e la risposta; un Fault, elemento opzionale che fornisce informazioni sugli eventuali errori che potrebbero verificarsi in fase di processo dei messaggi; 23

24 2. Service Oriented Architecture La seguente figura illustra un generico messaggio SOAP. Figura 5: La struttura di un generico messaggio SOAP Le regole principali che un messaggio SOAP deve seguire sono: deve essere codificato in XML valido; deve far uso del SOAP Envelope Namespace; deve far uso del SOAP Encoding Namespace; non deve contenere riferimenti ad un DTD come pure non deve contenere istruzioni di XML processing; Vediamo ora un semplice esempio di comunicazione SOAP tra un Web Service e un suo consumer. Il Web Service possiede un operazione denominata sum che effettua la somma di due numeri interi passati come parametri e restituisce il 24

25 2. Service Oriented Architecture risultato. Assumendo che sia ben noto l'url del servizio (quest'ultimo potrebbe anche essere stato, ad esempio, ricavato mediante interrogazione di un UDDI Registry), l'applicazione client, il consumer, che vuole effettuare la somma degli interi 2 e 3 può invocare l'operazione remota inviando un messaggio SOAP, la figura seguente mostra tale messaggio inviato dal client al Web Service: Figura 6: Messaggio SOAP inviato dall'applicazione client al Web Service per ottenere la somma degli interi 2e3 Come si può notare in Figura 6, il Body del messaggio SOAP contiene il nome dell'operazione remota invocata e i parametri, di tipo intero, dei quali si richiede la somma. Il Web Service è capace di processare la richiesta e risponde al client con un messaggio SOAP, che contiene la risposta all'invocazione dell'operazione di somma, come illustrato nella figura seguente: 25

26 2. Service Oriented Architecture Figura 7: Messaggio SOAP, inviato dal Web Service al client, per comunicare la somma dei due interi specificati nella richiesta, ossia il risultato dell'operazione remota Nel Body possiamo individuare la risposta del Web Service che restituisce un intero di valore 5, ovvero la somma dei due numeri interi passati nella richiesta del client. Naturalmente quanto presentato è solamente un piccolo esempio di messaggistica SOAP per la comunicazione tra due entità software distribuite; le applicazioni più comuni non si limitano ad usare i tipi di dato base ma anche tipi strutturati e complessi, segue che i messaggi SOAP avranno a che fare con tipi definiti in qualche modo attraverso grammatiche XML. Un aspetto rilevante da considerare nella definizione dei Web Service e che ricade nella tipologia dei contenuti dei messaggi SOAP è rappresentato dal formato dei dati che viaggiano nel SOAP Envelope. Quest'ultimo e sostanzialmente è composto da due parametri: Binding Style: che può essere di tipo document o di tipo rpc; Encoding Style: che può essere di tipo encoded o di tipo literal; Il Binding Style rappresenta il modo nel quale vengono descritte le operazioni e i 26

27 2. Service Oriented Architecture loro parametri durante l'invocazione di un Web Service: lo stile rpc viene usato per descrivere i Web Service come se fossero delle tradizionali procedure remote ed ogni parametro contenuto in una invocazione mediante messaggio SOAP viene incapsulato da dei tag che lo descrivono; lo stile document è sostanzialmente utilizzato per descrivere i Web Service come entità software orientate al consumo di documenti ed infatti ogni parametro in questo caso è rappresentato dal documento che lo descrive senza nessuna modifica. L'Encoding style specifica il modo in cui vengono scritti i dati facenti parte delle richieste e delle risposte dei Web Service; lo stile encoded prescrive che i dati debbano essere descritti come tipi definiti nello standard XML-Schema (a parte alcune eccezioni definite dalle specifiche di SOAP) e viene utilizzato nel caso in cui si abbia la necessità di serializzare-deserializzare grafi composti di oggetti da una parte e dell'altra delle due entità comunicanti, per i tipi complessi, invece si ricorre all'utilizzo dell'xml-schema; lo stile literal, prescrive che i dati debbano essere descritti mediante un documento XML-Schema e non fa nessuna supposizione sul modo in cui i dati vengono serializzati-deserializzati; l'unico vincolo che si richiede è che il documento sia sempre descritto mediante XMLSchema. Riassumendo si hanno, quindi, quattro possibili combinazioni, come illustrato nella figura seguente: rpc/encoded rpc/literal document/encoded document/literal Tabella : Le possibili combinazioni di Binding Style, Encoding Style in un messaggio SOAP Questa varietà di combinazioni ha introdotto diversi problemi di interoperabilità tra diverse implementazioni di Web Service SOAP, soprattuto in relazione ai 27

28 2. Service Oriented Architecture diversi linguaggi di programmazione e piattaforme utilizzati. Per questo motivo si è costituito il consorzio WS-I (Web Service Interoperability)[27] il cui scopo è proprio quello della creazione di specifiche per permettere una reale interoperabilità tra le diverse implementazioni dei Web Service. Per questo motivo l'organizzazione WS-I ha elaborato un set di specifiche chiamato WS-I Basic Profile che devono essere supportate dagli implementatori dei servizi affinche si abbia un minimo livello di interoperabilità per i Web Service, tra le altre cose, il WS-I Basic Profile prevede, per esempio, che venga utilizzato il formato document/literal come encoding. 28

29 2. Service Oriented Architecture 2.2. Web Services Orchestration Per Web Service Orchestration (WSO) si intende il tentativo di una integrazione e composizione di singoli Web Service in processi di business standardizzati. Ultimamente questo modello tecnologico sta diventando un componente chiave per la realizzazione di una reale e standardizzata Service Oriented Architecture, nonché un componente fondamentale nello stack di layer basati sulla tecnologia Web Service; inoltre, la sua natura di meccanismo di disaccoppiamento dei servizi costituisce un promettente avvio verso le architetture distribuite basate su servizi eterogenei ma uniti sotto una ben definita interfaccia di comunicazione e discovery. Una formulazione precisa di standard per l'esecuzione di processi business basati su Web Service porterà presto al raggiungimento di un duplice scopo: riduzione dei costi e sostanziale miglioramento dell'interoperabilità tra servizi, senza contare i benefit di un loro reale riutilizzo. 29

30 2. Service Oriented Architecture BPEL, Business Process Execution Language (for Web Services) Con l'introduzione e utilizzo delle tecnologie basate su Web Service, si è assistito ad un reale cambiamento-ampliamento di Internet e del suo utilizzo quale strumento per applicazioni B2B. Attuale capitolo di questa evoluzione è quello di una formalizzazione di alcuni standard e sistemi di gestione di flussi di lavoro ed esecuzione per sistemi distribuiti basati su Web Service. Le classiche applicazioni software per il supporto di flussi di lavoro con queste caratteristiche sono i sistemi di gestione di workflow (WfMS, WorkFlow Management Systems), che consentono la gestione contemporanea di un numero, anche elevato, di istanze di processi seguendo schemi di processo predefiniti[4][5]. In questo ambito, il processo viene definito come una rete di attività e di relazioni esistenti tra di esse, criteri per indicare l inizio e la fine di un processo, e informazioni riguardo alle singole attività, quali: i partecipanti, le applicazioni, i dati utilizzati e scambiati, e così via. La rappresentazione di un processo in una forma che consente l esecuzione automatica delle attività automatizzatili e la gestione automatica del passaggio tra un attività e quelle che seguono nel flusso di lavoro è basata su alcuni costrutti fondamentali quali: sequenza: le attività vengono svolte l una di seguito all altra: una attività viene attivata solo al termine di un attività precedente; parallelo (AND split): dopo la terminazione di una attività vengono attivate più attività in parallelo; alternativa (OR split): dopo la terminazione di una attività vengono attivate più attività in alternativa; vengono specificate le condizioni di attivazione delle 3

31 2. Service Oriented Architecture attività oppure può essere effettuata una scelta non deterministica; join (AND oppure OR): per proseguire nel flusso di lavoro devono essere terminate tutte le attività precedenti (caso AND), o almeno una delle attività precedenti. Sulla base di questi costrutti è possibile rappresentare reti di attività di tipo generale. Nelle precedenti sezioni si è visto come lo scopo della tecnologia dei Web Services sia quello di raggiungere una interoperabilità universale tra applicazioni utilizzando il Web standard [6]. Questa tecnologia utilizza un modello di disaccoppiamento tra le parti, in modo da permettere una flessibile integrazione tra sistemi eterogenei in una molteplice varietà di domini. Tutto questo indipendentemente dalla piattaforma e dai linguaggi di programmazione utilizzati. La completa potenzialità della tecnologia dei Web Service come piattaforma di integrazione sarà raggiunta solamente quando le applicazioni e i processi di business saranno capaci di integrare le loro complesse interazioni facendo uso di un modello standardizzato di integrazione. Il modello di interazione, che è automaticamente supportato dal formato WSDL, è essenzialmente un modello stateless sincrono o asincrono mentre i modelli per le interazioni business assumono tipicamente la forma di sequenze di scambi di messaggi di tipo peer-to-peer, (P2P) sia sincrone che asincrone, con una gestione stateful di interazioni a lungo termine tra due o più parti. Per definire questo tipo di interazioni business è necessaria una descrizione formale del protocollo di scambio dei messaggi in questo contesto aggiuntivo. La definizione di questa tipologia di protocolli implica una precisa specifica del mutuo scambio di messaggi tra le parti coinvolte nel protocollo, senza una esposizione pubblica della loro implementazione interna. Ci sono essenzialmente 3

32 2. Service Oriented Architecture due buone ragioni per la separazione degli aspetti pubblici di un processo business dagli aspetti privati o interni: la prima, ovviamente, è data dal fatto che gli attori coinvolti nel business non vogliono rivelare le loro strategie o i loro data management ai corrispettivi partner d'affari; la seconda è che questa separazione introduce la libertà di cambiare gli aspetti privati dell'implementazione dei processi senza avere nessun effetto sul protocollo pubblico di business. I protocolli di business devono essere necessariamente e chiaramente descritti in modo indipendente dalla piattaforma e dai linguaggi utilizzati. I concetti chiave per descrivere un protocollo di business sono: presenza di costrutti condizionali e di time-out, poichè il protocollo include comportamenti dipendenti dai flussi di dati; capacità di reazione ad eventi eccezionali, come sequenze di recovery; ricca capacità descrittiva della notazione includendo reminescenze dei linguaggi di programmazione tradizionali. BPEL (il nome originario è BPEL4WS), è un linguaggio nato dall'unione delle esperienze su XLANG e WSFL (Web Service Flow Language) e si è guadagnato il ruolo di principale tecnologia per la Web Service Orchestration e tiene conto, tra i suoi obiettivi, delle caratteristiche e delle problematiche sopra esposte. BPEL permette di specificare un modello di comportamento di Web Service durante un processo di business ed esso assume che questi servizi siano descritti mediante WSDL ed eventualmente memorizzati in un UDDI Registry. BPEL è basato su una grammatica XML interpretabile da un orchestration engine il 32

33 2. Service Oriented Architecture cui compito è quello di coordinare i vari Web Service che compongono il processo. BPEL permette di considerare un Web Service come un processo di collaborazione composto da altri Web Service, definendone una natura di tipo ricorsivo e questo processo di processi così definito avrà una sua propria interfaccia WSDL. Un processo definito mediante BPEL è composto da attività che rappresentano sia richieste di tipo client, sia risposte al client medesimo; come specificato in precedenza, il processo si basa su una serie di di Web Service che vengono chiamati partner invocati attraverso l attività di invoke che può essere di tipo sincrono o asincrono. Il seguente listato XML e la figura illustrano rispettivamente un documento espresso in BPEL e la relativa rappresentazione grafica del processo. 33

34 2. Service Oriented Architecture <?xml version="." encoding="utf-8"?> <process name="synchronoussample" targetnamespace="http://www.mycomp.org/synchronoussample" xmlns="http://schemas.xmlsoap.org/ws/24/3/business-process/" xmlns:xsd="http://www.w3.org/2/xmlschema" xmlns:bpws="http://schemas.xmlsoap.org/ws/24/3/business-process/" xmlns:wsdlns="http://www.mycomp.org/synchronoussample" xmlns:xs="http://www.mycomp.org/synchronoussampleschemanamespace"> <import namespace="http://www.mycomp.org/synchronoussample" location="synchronoussample.wsdl" importtype="http://schemas.xmlsoap.org/wsdl/"/> <partnerlinks> <partnerlink name="partnerlinka" partnerlinktype="wsdlns:synchronoussamplepartnerlinktype" myrole="synchronoussampleprovider"/> </partnerlinks> <variables> <variable name="inputvar" messagetype="wsdlns:requestmessage"/> <variable name="outputvar" messagetype="wsdlns:responsemessage"/> </variables> <sequence> <receive name="start" partnerlink="partnerlinka" porttype="wsdlns:myporttype" operation="operationa" variable="inputvar" createinstance="yes"/> <assign name="assign"> <copy> <from variable="inputvar" part="inputtype"/> <to variable="outputvar" part="resulttype"/> </copy> </assign> <reply name="end" partnerlink="partnerlinka" porttype="wsdlns:myporttype" operation="operationa" variable="outputvar"/> </sequence> </process> Figura 8: Esempio di documento di descrizione di un workflow espresso in BPEL 34

35 2. Service Oriented Architecture Figura 9: Rappresentazione grafica di un processo BPEL (creato con Netbeans, un popolare ambiente di sviluppo per Java) Per la definizione vera e propria di questi processi si utilizzano dei costrutti che provengono da quelli definiti per modelli di workflow: sequence, per le attività in sequenza; flow, per l esecuzione di attività in parallelo; switch e pick per le alternative tra attività; 35

36 2. Service Oriented Architecture while, come costrutto iterativo. BPEL permette anche di utilizzare delle variabili allo scopo di permettere un mantenimento dello stato tra chiamate diverse. 36

37 2. Service Oriented Architecture 2.3. Ambienti e tool di sviluppo per i Web Service in Java Tutti i moderni linguaggi di programmazione prevedono, oramai, un set più o meno ricco, di librerie per l'implementazione dei Web Service e dei relativi client. In questa sezione verranno descritte alcune tecnologie utilizzate per l'implementazione di Web Service, basati sul linguaggio Java. Per questo linguaggio i framework disponibili sono svariati, in questo lavoro verranno analizzati il framework Apache Axis per l'implementazione dei Web Service e il web container Apache Tomcat per la loro pubblicazione. Il primo è stato scelto per la sua semplicità di installazione, per la versatilità dei tool messi a disposizione dello sviluppatore e per la velocità di creazione di un Web Service a partire da un semplice JavaBean. Inoltre la sua buona diffusione ed utilizzo costituisce una eccellente alternativa al nuovo framework, recentemente incluso da Sun Microsystems nelle ultime distribuzioni del linguaggio Java, chiamato JAX-WS. Il secondo, Apache Tomcat, è probabilmente il più popolare Web Container per le Web Application scritte in Java, nonché piattaforma di riferimento di alcune connesse tecnologie. 37

38 2. Service Oriented Architecture Apache Tomcat Come descritto nella relativa home page del progetto, Tomcat è un Servlet container usato per l'implementazione di riferimento delle tecnologie Java Servlet e JavaServer Pages di Sun. Tomcat è completamente open-source e viene rilasciato sotto la Apache Software License [8]. Considerando Tomcat come un sistema di tipo blackbox, possiamo riassumere le funzionalità di base nella figura che segue. Figura : Apache Tomcat visto come una "blackbox" Tomcat è in grado di agire sia da HTTP server classico per contenuti statici, come pagine HTML, immagini, risorse, sia da Servlet container, in quanto mette a disposizione il runtime per eseguire, mantenere e rispondere a richieste indirizzate a web application dinamiche realizzate attraverso Java Servlet e JavaServer Pages. Una delle potenzialità più sfruttate di Tomcat è la possibilità di accoppiarlo ad un HTTP Server più performante, per le richieste a risorse statiche, come Apache HTTP Server. 38

39 2. Service Oriented Architecture L'architettura interna di Tomcat può essere riassunta nella seguente figura: Figura : L'architettura interna di Apache Tomcat Il Connector è il modulo di Tomcat che si occupa del suo interfacciamento con l'esterno e gestisce, perciò, le comunicazioni con il client. Esistono vari Connector disponibili per Tomcat: per esempio il Coyote Connector, utilizzato per il traffico HTTP e il JK2 Connector il quale implementa il protocollo AJP, utilizzato per eseguire Tomcat in coppia con Apache HTTP Server. Un Engine rappresenta la pipeline della gestione delle richieste per un servizio 39

40 2. Service Oriented Architecture specifico; poiché ogni servizio potrebbe avere Connector multipli, l'engine riceve e processa tutte le richieste provenienti dai Connector associati, fornendo la risposta indietro all'appropriato Connector, il quale provvederà alla trasmissione al client. Un Host è un'associazione di un nome di rete, per esempio: a Tomcat. Un singolo Engine può contenere più di un Host, a un singolo componente Host possono essere associati diversi alias di rete. Un Context rappresenta una Web Application. Un Host, naturalmente, può contenere più di un Context, ciascuno di essi raggiungibile con un path univoco. Le Web Application sono le applicazioni vere e proprie scritte in Java con la tecnologia Servlet, JSP e derivate. Il container Tomcat viene utilizzato anche per il deployment di Web Service scritti in Java poiché, questi ultimi, solitamente vengono tecnicamente realizzati mediante la creazione (più o meno automatica grazie a numerosi tool disponibili) di Servlet che implementano di fatto il servizio e permettono la sua pubblicazione su di un server Java enabled, come Tomcat appunto. 4

41 2. Service Oriented Architecture Apache Axis Axis è un SOAP Engine, ovvero un framework open-source per la costruzione di processori SOAP e Web Service, sia parte server che client consumer. Il framework è disponibile sia per il linguaggio Java che per C++ [7]. Per quanto riguarda la versione per il linguaggio della Sun, Axis mette a disposizione: un semplice server stand-alone; l'implementazione di SOAP versione. e.2; il supporto per la serializzazione/deserializzazione; un server installabile come web application su un Servlet Container; supporto per il Web Service Description Language (WSDL); i tool di generazione automatica del codice Java a partire da un file WSDL e viceversa; un TCP/IP monitor e un SOAP Monitor; possibilità di tre modalità di invocazione dei Web Service: mediante Dynamic Invocation Interface, mediante stub generato automaticamente a partire dal WSDL e Dynamic Proxy. Una caratteristica, spesso molto utile, per creare dei semplici web service con Axis è rappresentata dall'opportunità di crearne uno a partire da una classe Java (JavaBean), semplicemente rinominando il file da.java a.jws; copiando il file rinominato all'interno dell'installazione della web application server di Axis, tutti i necessari SOAP handler e classi di utilità verranno automaticamente generati dal framework e il Web Wervice così generato sarà automaticamente raggiungibile mediante URL ben definito. L'utilità di questa particolare 4

42 2. Service Oriented Architecture caratteristica si riduce, comunque, alla creazione di semplici Web Service, in quanto è possibile solamente l'utilizzo dei soli tipi primitivi nell'invocazione delle operazioni e sono presenti anche altre limitazioni che ne rendono, comunque, limitato l'utilizzo in campo production. In ogni caso, questa potenziale opzione, costituisce un valido metodo per fare del rapid prototyping di applicazioni orientate ai servizi. Il framework Axis consente anche la creazione delle classi client a partire dal WSDL che descrive il servizio. 42

43 3. Sistemi di gestione di Workflow 3. Sistemi di gestione di Workflow Le organizzazioni attuali, sia che esse operino nel campo più prettamente business, sia che operino nel campo della ricerca, un esempio su tutti è rappresentato dalla bioinformatica, tipicamente necessitano della gestione di una grande mole di flussi di dati e di risorse computazionali, sempre più decentralizzate e distribuite, a partire da risorse distribuite nello stesso dipartimento/edificio sino ad arrivare a quelle distribuite su Internet e quindi a livello planetario. Ora più che mai, trovandoci in piena epoca di realizzazione di architetture orientate ai servizi (SOA), trovano applicazione e vita nuova i sistemi di workflow. I Workflow Management System vengono definiti come sistemi di ausilio per le organizzazioni per specificare, eseguire e coordinare il flusso di processi di lavoro all'interno di un ambiente lavorativo distribuito [8]. Ancora, in generale, un sistema di workflow riguarda l'automazione delle procedure nelle quali i documenti, le informazioni o le singole unità di lavoro vengono passate tra i partecipanti in accordo ad un ben definito insieme di regole per il raggiungimento di un determinato obiettivo di business [9]. In questo modo possiamo dare una definizione più coincisa di un workflow: Un workflow è un meccanismo computerizzato per l'automazione di un processo di business, nella sua interezza o in parte Da queste definizioni segue che un Workflow Management System è un sistema che fornisce delle automazioni in forma procedurale di un processo di business, mediante la gestione di una sequenza di attività di lavoro e l'invocazione di appropriate risorse computazionali associate ai vari passi delle attività. 43

44 3. Sistemi di gestione di Workflow Quindi, più formalmente: Un Workflow Management System è un sistema che definisce, gestisce ed esegue completamente dei workflow attraverso l'esecuzione di componenti software il cui ordine di esecuzione è guidato da una rappresentazione computerizzata della logica di workflow Le definizioni precedenti sono state elaborate dalla Workflow Management Coalition (WfMC), organizzazione di cui fanno parte aziende come Oracle, BEA, IBM, Sun Microsystems e molte altre, il cui scopo è quella di gestire i lavori e collaborare all'evoluzione dei sistemi di workflow. Figura 2: Il Workflow Reference Model secondo la Workflow Management Coalition (WfMC) 44

45 3. Sistemi di gestione di Workflow L'evoluzione dei sistemi di workflow ha visto il loro impiego in differenti aree di applicazione, ricordiamo tra le tante: elaborazione di immagini, document management, posta elettronica e sistemi di directory, applicazioni di groupware, gestione dei cicli di sviluppo del software. Figura 3: Architettura generica della definizione di un processo di workflow secondo la WfMC 45

46 3. Sistemi di gestione di Workflow Nella figura precedente viene illustrata la generica architettura per la definizione di un processo di workflow. Mediante un tool di composizione (Definition Tool) è possibile creare una definizione di processo il quale si serve di applicazioni esterne per il suo completamento. La definizione del processo viene interpretata da un enactor, chiamato in figura Workflow Management Engine (WFM Engine) il quale esegue il processo così come definito nella prima fase. In ogni fase delle elaborazioni, l'utente (appartenente a diverse tipologie: supervisore, utente del workflow, ecc...) ha una vista sul progresso delle operazioni. La figura precedente potrebbe essere facilmente estesa per rappresentare un sistema di workflow distribuito, nel senso che, se dislocassimo diversi Workflow Management Engine su diverse macchine (remote) e facessimo in modo che un workflow definito su un host facesse uso di un altro definito su secondo host, potremmo avere un sistema di workflow di tipologia distribuita. Da quanto introdotto sinora, si evince che, per la definizione di un sistema di workflow, sono fondamentali il modello del workflow e la sua rappresentazione mediante qualche formalismo (process definition) e la presenza di un Workflow Engine. Il secondo di questi, si occupa di fornire essenzialmente un ambiente di run-time per una istanza di workflow definita mediante un formalismo (un linguaggio dotato di una ben definita grammatica). Un Workflow Engine dovrebbe possedere le seguenti funzionalità: interpretazione della definizione del processo ; controllo delle istanze del processo: creazione, attivazione, sospensione, terminazione, ecc...; definizione di una interfaccia per l'invocazione di servizi ed applicazioni esterne; 46

47 3. Sistemi di gestione di Workflow facility di supervisione per il controllo, l'amministrazione e l'auditing dei processi. La definizione del processo implica la definizione di un qualche formalismo o meta-modello per la descrizione dell'intero workflow; nella stesura del suo modello di riferimento, la WfMC definì un meta-modello di base per la definizione dei flussi, includendo anche l'introduzione delle entità partecipanti al processo. Il meta-modello di base definito è illustrato nella Figura 4 Figura 4: Il meta-modello di base per la definizione di un workflow così come definito dalla WfMC 47

48 3. Sistemi di gestione di Workflow La figura precedente introduce un meta-modello costituito dalle seguenti entità e le relazioni tra di essi per la definizione di un workflow: Workflow Definition: per la definizione del processo, il meta-modello deve possedere i seguenti attributi: nome del processo di workflow; numero della versione; condizioni di start e di terminazione del processo; sicurezza ed altri dati di controllo; Activity: ciascuna attività di cui è composto un workflow deve possedere i seguenti attributi: nome dell'attività tipo (subflow, atomic flow, ecc..) condizioni di pre e post esecuzione dell'attività altri vincoli di scheduling Transition Conditions: questa entità rappresenta ed esprime le condizioni di esecuzione e transizione del workflow (costrutti condizionali e di iterazione). Workflow relevant data: i dati rilevanti per il flusso all'interno della definizione: nome dei dati e percorso tipi di dato Role: il nome e l'entità dell'organizzazione 48

49 3. Sistemi di gestione di Workflow Invoked Application/Service: applicazioni esterne al workflow richiamate per l'elaborazione del processo di workflow, esse sono definite da: tipo generico o nome parametri d'esecuzione localizzazione del servizio o percorso Particolare importanza riveste la definizione di una interfaccia comune per l'invocazione di applicazioni remote. Per questo motivo un meta-modello per un sistema di workflow deve definire quali sono gli standard d'interfaccia per perseguire questa funzionalità. Nei moderni sistemi di workflow, tra i quali quelli che verranno esaminati più avanti in questo lavoro, l'interfaccia principale per le applicazioni remote è rappresentata dal Web Service Description Language (WSDL). Un'altra caratteristica chiave che un sistema di workflow dovrebbe possedere è quella della interoperabilità tra diversi sistemi e diverse piattaforme (intesi come sistemi operativi, linguaggi di programmazione, ecc...). Ancora una volta, gli intenti originari nella definizione formale dei sistemi di workflow sono stati raggiunti facendo uso delle tecnologie basate su Web Service. Come abbiamo visto, la definizione di un processo di workflow, implica quindi la definizione di una serie di passi e coordinamento di attività per la persecuzione di un determinato obiettivo di business. Introduciamo ora brevemente la terminologia utilizzata durante la definizione del processo e la sua esecuzione per descrivere la natura del suo flusso e delle sue interazioni []. 49

50 3. Sistemi di gestione di Workflow 3.. Process Il processo è una rappresentazione formalizzata di un processo di business, rappresentata come un insieme coordinato (parallelo e/o seriale) di attività le quali sono interconnesse per perseguire uno scopo ben preciso. Le attività possono essere considerate come le singole unità di lavoro (funzioni) oppure come dei blocchi di attività stesse. Figura 5: Un processo come sequenza di attività 3.2. Parallel Routing Segmento di un processo in fase di esecuzione durante il quale due o più attività sono in esecuzione parallelamente all'interno del workflow dando origine a molteplici thread di controllo. Il routing parallelo solitamente ha origine da un AND-Split e termina con un AND-Join Sequential Routing Segmento di un processo in fase di esecuzione nel quale diverse attività vengono 5

51 3. Sistemi di gestione di Workflow eseguite in ordine sequenziale sotto un unico thread di esecuzione. In questo caso non vengono usati nessun AND-Split e nessun AND-Join AND-Split Un punto, all'interno del workflow, nel quale un singolo thread di controllo si divide in due o più thread i quali vengono eseguiti in parallelo consentendo ad attività multiple di essere eseguite simultaneamente. Figura 6: AND-Split 3.5. AND-Join Un punto, all'interno del workflow, nel quale due o più attività ad esecuzione parallela convergono in un unico thread di controllo. 5

52 3. Sistemi di gestione di Workflow Figura 7: AND-Join 3.6. OR-Split Un punto, all'interno del workflow, nel quale un singolo thread di controllo prende la decisione di scegliere un determinato ramo d'esecuzione quando incontra un insieme di differenti alternative nel workflow. Figura 8: OR-Split 52

53 3. Sistemi di gestione di Workflow 3.7. OR-Join Un punto, all'interno del workflow, nel quale due o più attività alternative convergono verso una singola attività comune al prossimo passo di esecuzione nel workflow. Poiché non è stata eseguita nessuna esecuzione parallela delle attività al punto di join, non è necessaria nessuna sincronizzazione tra thread. Figura 9: OR-Join 3.8. Iteration Un ciclo di attività, all'interno del workflow, che implica l'esecuzione ripetitiva di una o più attività del workflow sino a quando una determinata condizione viene soddisfatta. Equivalente ad un loop di tipo while. Figura 2: Iteration 53

54 3. Sistemi di gestione di Workflow 3.9. Pre-Condition Espressione logica che può essere valutata da un workflow engine per decidere se una istanza di processo, o un'attività all'interno di un processo, può essere iniziata. 3.. Post-Condition Espressione logica che può essere valutata da un workflow engine allo scopo di decidere se un'istanza di processo, o un'attività all'interno di un processo, è da ritenere completata. 3.. Transition Un punto, durante l'esecuzione di un processo, nel quale un'attività completa le sue operazioni e il thread di controllo passa ad un'altra, la quale inizia le sue operazioni Transition Condition Espressione logica che può essere valutata da un workflow engine per determinare la sequenza di esecuzione delle attività all'interno di un processo. 54

55 4. Analisi di due Workflow Management System per l'e-science 4. Analisi di due Workflow Management System per l'e- Science In questo capitolo verranno esaminati due Workflow Management System opensource orientati all'e-science: Taverna e Triana. Il primo particolarmente orientato alla bioinformatica, il secondo divenuto, con la versione attuale, indipendente da un particolare dominio di applicazione ma sempre orientato all'ambito delle sperimentazioni scientifiche. Come accennato nell'introduzione, non vengono considerati WfMS basati su BPEL, ma sono stati scelti i due sistemi citati per il loro particolare dominio di orientamento: e-science anziché generici processi di business. 4.. Taverna Gli scopi del progetto Taverna sono quelli di fornire un linguaggio e un toolkit software per facilitare l'utilizzo dei workflow e delle applicazioni distribuite all'interno della comunità escience. Taverna è gratuitamente disponibile sotto licenza GNU Lesser General Public License (LGPL). Il progetto Taverna nasce da una collaborazione tra l'european Bioinformatics Institute (EBI), IT Innovation, la School of Computer Science, University of Newcastle, Newcastle Centre for Life, School of Computer Science at the University of Manchester e la Nottingham University Mixed Reality Lab. Altre collaborazioni includono il Biomoby project, Seqhound, Biomart e molte altre persone dislocate geograficamente [9]. 55

56 4. Analisi di due Workflow Management System per l'e-science Figura 2: Il workbench di Taverna con un workflow in fase di design Il toolkit Taverna si presenta come un workbench completamente visuale il quale permette agli utilizzatori di costruire complessi workflow a partire da componenti (Web Service) localizzati sia su macchine remote che su macchine locali; permette l'esecuzione del workflow e la visualizzazione dei risultati. Taverna permette anche di effettuare svariate operazioni sui componenti, come, per esempio, il discovery, la descrizione e la selezione di librerie personalizzate a partire dai componenti disponibili in modo che si possano adattare all'utilizzo in una particolare applicazione. 56

57 4. Analisi di due Workflow Management System per l'e-science Figura 22: Esecuzione di un workflow in Taverna, la finestra dell'enactor mostra il flusso d'esecuzione e gli eventuali problemi, come in questo caso Taverna definisce alcuni concetti principali: Workflow: definito come un set di componenti e relazioni tra essi utilizzati per definire un processo di una certa complessità a partire da blocchi costruttivi più semplici. Le relazioni posso essere di tipo dati, le quali trasferiscono l'output da un componente all'input di un altro componente; possono essere di tipo controllo le quali specificano alcune condizioni sull'esecuzione dei componenti. Un esempio di una relazione di tipo controllo può essere il classico ordine temporale tipo: non eseguire il componente C finchè non si è completata l'esecuzione del componente C2. Taverna esprime un workflow in un formato XML chiamato XSCUFL (XML Simple Conceptual Unified Flow Language); la Figura 23, illustra il documento XSCUFL riguardante un workflow creato con Taverna. 57

58 4. Analisi di due Workflow Management System per l'e-science Componenti: un componente è un blocco costruttivo riusabile il quale esegue una ben definita funzione all'interno del processo di esecuzione. Naturalmente, trattandosi di applicazioni distribuite, i componenti possono trovarsi fisicamente su qualsiasi risorsa computazionale su Internet oppure in locale sulla macchina dell'utente di Taverna. Service: tutti i servizi sono anche Componenti. Un servizio viene definito come un componente remoto. Taverna nasconde i protocolli di comunicazione con i servizi, per esempio SOAP, rendendoli trasparenti all'utilizzatore del workbench. Enactor: Un Workflow Enactor è l'entità responsabile della coordinazione dell'invocazione dei Component costituenti un Workflow. L'Enactor governa l'intero processo di esecuzione del workflow includendo una visualizzazione della fase di esecuzione e dei trasferimenti di dati tra i componenti. 58

59 4. Analisi di due Workflow Management System per l'e-science <?xml version="." encoding="utf-8"?> <s:scufl xmlns:s="http://org.embl.ebi.escience/xscufl/.alpha" version=".2" log=""> <s:workflowdescription lsid="urn:lsid:www.mygrid.org.uk:operation:mq3x8z9ex2" author="" title=""/> <s:processor name="fail_if_false"> <s:local>org.embl.ebi.escience.scuflworkers.java.failiffalse</s:local> </s:processor> <s:processor name="if_script"> <s:beanshell> <s:scriptvalue> if(double.valueof(a)>=double.valueof(b)) { = "true"; } { = "false"; }res;</s:scriptvalue> <s:beanshellinputlist> <s:beanshellinput s:syntactictype="'text/plain'">a</s:beanshellinput> <s:beanshellinput s:syntactictype="'text/plain'">b</s:beanshellinput> </s:beanshellinputlist> <s:beanshelloutputlist> <s:beanshelloutput s:syntactictype="'text/plain'">res</s:beanshelloutput> </s:beanshelloutputlist> </s:beanshell> </s:processor> <s:processor name="fail_if_true"> <s:local>org.embl.ebi.escience.scuflworkers.java.failiftrue</s:local> </s:processor> <s:processor name="generaterandomnumber"> <s:arbitrarywsdl> <s:wsdl>http://localhost:888/axis/utilitieswebservice.jws?wsdl</s:wsdl> <s:operation>generaterandomnumber</s:operation> </s:arbitrarywsdl> </s:processor> <s:processor name="generaterandomnumber"> <s:arbitrarywsdl> <s:wsdl>http://localhost:888/axis/utilitieswebservice.jws?wsdl</s:wsdl> <s:operation>generaterandomnumber</s:operation> </s:arbitrarywsdl> </s:processor> <s:processor name="mul"> <s:arbitrarywsdl> <s:wsdl>http://localhost:888/axis/simplemathwebservice.jws?wsdl</s:wsdl> <s:operation>mul</s:operation> </s:arbitrarywsdl> </s:processor> <s:processor name="div"> <s:arbitrarywsdl> <s:wsdl>http://localhost:888/axis/simplemathwebservice.jws?wsdl</s:wsdl> <s:operation>div</s:operation> </s:arbitrarywsdl> 59

60 4. Analisi di due Workflow Management System per l'e-science </s:processor> <s:link source="generaterandomnumber:generaterandomnumberreturn" sink="div:b"/> <s:link source="generaterandomnumber:generaterandomnumberreturn" sink="if_script:b"/> <s:link source="generaterandomnumber:generaterandomnumberreturn" sink="mul:b"/> <s:link source="generaterandomnumber:generaterandomnumberreturn" sink="div:a"/> <s:link source="generaterandomnumber:generaterandomnumberreturn" sink="if_script:a"/> <s:link source="generaterandomnumber:generaterandomnumberreturn" sink="mul:a"/> <s:link source="if_script:res" sink="fail_if_false:test"/> <s:link source="if_script:res" sink="fail_if_true:test"/> <s:coordination name="mul_blockon_fail_if_false"> <s:condition> <s:state>completed</s:state> <s:target>fail_if_false</s:target> </s:condition> <s:action> <s:target>mul</s:target> <s:statechange> <s:from>scheduled</s:from> <s:to>running</s:to> </s:statechange> </s:action> </s:coordination> <s:coordination name="div_blockon_fail_if_true"> <s:condition> <s:state>completed</s:state> <s:target>fail_if_true</s:target> </s:condition> <s:action> <s:target>div</s:target> <s:statechange> <s:from>scheduled</s:from> <s:to>running</s:to> </s:statechange> </s:action> </s:coordination> </s:scufl> Figura 23: Documento in formato XSCUFL per la descrizione di un workflow in Taverna L'ambiente di Taverna mette a disposizione dell'utente altre caratteristiche degne di nota, mediante le quali è possibile creare dei workflow davvero complessi e robusti, tra quelle più interessanti, riportiamo: Retries: la possibilità di specificare, per ogni processore (e quindi anche per i Web Service), il numero di tentativi che l'enactor del workflow deve 6

61 4. Analisi di due Workflow Management System per l'e-science effettuare nel caso si verifichi un fallimento nell'invocazione dei servizi o dei componenti; Delay: la possibilità di specificare un ritardo, in millisecondi, tra un tentativo di invocazione dei processori e il successivo, naturalmente questa proprietà può essere legata alla precedente; Backoff: la possibilità di specificare un fattore per determinare di quanto il Delay deve essere incrementato per retries successive dopo il primo tentativo di invocazione dei processori; Threads: la possibilità di specificare, per ogni processore, il numero di istanze concorrenti che dovrebbero essere utilizzate dall'enactor durante una iterazione; Critical: valore booleano che indica la possibilità di definire il processore come critico. Se impostato come critico, al fallire dell'invocazione del processore segue un fallimento dell'intero workflow con conseguente interruzione della sua esecuzione; se non impostato, l'esecuzione del workflow, se possibile, continua, escludendo tutti i processori in qualche modo correlati a quello la cui invocazione è fallita; Alternate Processor: è possibile specificare, per un processore, un processore alternativo nel caso tutte le sue invocazioni da parte dell'enactor dovessero fallire, in accordo con le proprietà di Retries, Delay e Critical; naturalmente il processore alternativo specificato deve essere coerente con l'interfaccia esposta da quello principale, ovvero il processore 6

62 4. Analisi di due Workflow Management System per l'e-science alternativo presumibilmente deve essere in grado di effettuare lo stesso lavoro del principale. 62

63 4. Analisi di due Workflow Management System per l'e-science 4.2. Triana Triana, creato e distribuito secondo modello open-source dall' Università di Cardiff, è un altro Workflow Management System, scritto interamente in Java e quindi eseguibile su diverse piattaforme. Triana mette a disposizione un ambiente completamente grafico che permette di creare potenti costrutti di alto livello con uno sforzo minimo da parte dello sviluppatore, questo mediante creazione di workflow e composizione di servizi. Secondo quanto riportato dagli stessi creatori di Triana, esso permette di sviluppare rapidamente potenti programmi e applicazioni software senza avere a che fare con i dettagli e i costrutti dei linguaggi di programmazione classici. Triana può agevolmente essere usato per trattare una grossa varietà di tipi di dato: dati numerici, audio, immagini, file di testo. A questo scopo il suo ambiente mette a disposizione un toolkit di analisi dei segnali, di manipolazione di immagini, di desktop-publishing ad altre risorse software. 63

64 4. Analisi di due Workflow Management System per l'e-science Figura 24: L'ambiente di Triana con la composizione e la personalizzazione di un workflow Triana dimostra la sua potenza nell'automazione di task ripetitivi e il conseguente monitoraggio degli spettri di dati provenienti da eventuali esperimenti che possono durare giorni o mesi. Come altresì detto, Triana viene sviluppato da scienziati all'università di Cardiff, nel Regno Unito e viene abitualmente utilizzato in progetti europei come: GEO6 (gravitational wave experiment) [24] Distributed Computing con Triana All'interno del contesto di Triana, il toolkit distingue due tipi di componenti distribuiti: componenti Grid-Oriented e componenti Service-Oriented [25]. I componenti Servive-Oriented, come Web Service, sono componenti software di computazione accessibili da remoto; questi componenti possono essere 64

65 4. Analisi di due Workflow Management System per l'e-science invocati da Triana e costituiscono gli eventuali moduli che compongono un workflow. I componenti Grid-Oriented rappresentano dei lavori, avviati da Triana, su macchine remote utilizzando un grid resource manager. Diversamente dai componenti Service-Oriented, questi ultimi espongono interfacce accessibili da remoto perciò la comunicazione con essi è disponibile solamente mediante input/output su file. Come illustrato in Figura 25, Triana utilizza diverse interfacce per accedere a queste due diverse categorie di componenti, in breve: per i componenti Service-Oriented viene usata la GAP (Grid Application Prototype) Interface. Per i componenti Grid-Oriented vengono utilizzate le GridLab GAT (Grid Application Toolkit) API. Figura 25: Architettura generale di Triana In aggiunta a questi componenti, esiste anche una buona gamma di componenti 65

66 4. Analisi di due Workflow Management System per l'e-science Java locali utilizzabili per la composizione dei workflow o per lo sfruttamento di facilities comunemente utilizzate: dalla semplice concatenazione di stringhe alla visualizzazione di grafici ottenuti dall'elaborazione dei segnali. Grazie alla sua architettura e alle caratteristiche, Triana, originalmente creato per l'elaborazione dei segnali è diventato indipendente da un particolare dominio d'applicazione e quindi può essere usato con profitto in svariati campi d'applicazione come, citandone alcuni: bioinformatica, elaborazione dei segnali come l'individuazione delle onde gravitazionali e radio astronomia, data-mining, elaborazione di immagini mediche, elaborazione audio distribuita. Come accennato precedentemente, anche Triana è un tool completamente scritto in Java ed ha la possibilità di essere esteso con la creazione di nuovi componenti locali, questo avviene grazie al fatto che sono messe a disposizione delle API (Application Program Interface) ben documentate per l'implementazione di processori personalizzati. Naturalmente essi possono essere redistribuiti ed utilizzati da altri utenti che necessitano di essi. Un'altra caratteristica molto interessante è che Triana mette a disposizione delle procedure per pubblicare i workflow creati sotto forma di Web Service in un UDDI Registry specificato; in questo modo, un potenziale utente remoto può includere nel suo workflow, in via di composizione, un altro workflow completamente già definito e disponibile remotamente come Web Service, ergo descritto da un WSDL. In Triana, un workflow è rappresentato mediante un formato XML simile al formato WSFL (Web Service Flow Language) il quale è un linguaggio basato su XML per la composizione e la coreografia di flussi di Web Service; WSFL viene utilizzato per la rappresentazione XML di un processo. La figura seguente illustra la definizione di un workflow con Triana mediante il suo formato XML nativo. 66

67 4. Analisi di due Workflow Management System per l'e-science <?xml version="." encoding="utf-8"?> <tool> <toolname>triana-loop</toolname> <package /> <inportnum></inportnum> <outportnum></outportnum> <inparam /> <outparam /> <parameters> <param name="popupdescription" type="unknown"> <value>no description for tool</value> </parameters> <tasks> <task> <toolname>generaterandomnumber</toolname> <package>webservices.utilitieswebservice</package> <proxy type="webservice"> <param paramname="portname"> <value>utilitieswebservice</value> <param paramname="wsdllocation"> <value>http://localhost:888/axis/utilitieswebservice.jws?wsdl</value> <param paramname="serializedpipe"> <value>http://localhost:888/axis/utilitieswebservice.jws?wsdl:utilitie swebservice:generaterandomnumber</value> <param paramname="operation"> <value>generaterandomnumber</value> </proxy> <renderinghints> <renderinghint hint="taskgraphfactory" proxydependent="true"> <param paramname="factory"> <value>webservices (GAP)</value> </renderinghint> <renderinghint hint="webservice" proxydependent="true" /> </renderinghints> <inportnum></inportnum> <outportnum></outportnum> <inparam /> <outparam /> <input> <type>unknown Type</type> </input> <output> <type>unknown Type</type> </output> <parameters> <param name="minout" type="unknown"> <value></value> <param name="helpfile" type="unknown"> <value>http://localhost:888/axis/utilitieswebservice.jws?wsdl</value> <param name="popupdescription" type="unknown"> <value>no description for tool</value> <param name="maxin" type="unknown"> <value></value> 67

68 4. Analisi di due Workflow Management System per l'e-science <param name="maxout" type="unknown"> <value></value> <param name="guiy" type="gui"> <value> </value> <param name="guix" type="gui"> <value> </value> <param name="outputtype" type="unknown"> <value>java.lang.double</value> <param name="defaultout" type="unknown"> <value></value> <param name="minin" type="unknown"> <value></value> <param name="defaultin" type="unknown"> <value></value> </parameters> </task> <task> <toolname>constview</toolname> <package>common.const</package> <proxy type="java"> <param paramname="unitpackage"> <value>common\output</value> <param paramname="unitname"> <value>triana.tools.constview</value> </proxy> <renderinghints> <renderinghint hint="taskgraphfactory" proxydependent="true"> <param paramname="factory"> <value>default</value> </renderinghint> </renderinghints> <inportnum></inportnum> <outportnum></outportnum> <inparam /> <outparam /> <input> <type>java.lang.number</type> <type>triana.types.const</type> </input> <parameters> <param name="minout" type="internal"> <value></value> <param name="helpfile" type="internal"> <value>constview.html</value> <param name="popupdescription" type="internal"> <value>displays a Const in a Window</value> <param name="maxin" type="internal"> <value></value> 68

69 4. Analisi di due Workflow Management System per l'e-science <param name="maxout" type="internal"> <value> </value> <param name="guiy" type="gui"> <value> </value> <param name="guix" type="gui"> <value> </value> <param name="constvalue" type="unknown"> <value> </value> <param name="trigger" type="useraccessible"> <value>active</value> <param name="defaultout" type="internal"> <value></value> <param name="parampanelclass" type="internal"> <value>triana.tools.constviewpanel</value> <param name="minin" type="internal"> <value></value> <param name="toolversion" type="internal"> <value>3</value> <param name="defaultin" type="internal"> <value></value> </parameters> </task> <task> <toolname>inc</toolname> <package>webservices.simplemathwebservice</package> <proxy type="webservice"> <param paramname="portname"> <value>simplemathwebservice</value> <param paramname="wsdllocation"> <value>http://localhost:888/axis/simplemathwebservice.jws?wsdl</value> <param paramname="serializedpipe"> <value>http://localhost:888/axis/simplemathwebservice.jws?wsdl:simplem athwebservice:inc</value> <param paramname="operation"> <value>inc</value> </proxy> <renderinghints> <renderinghint hint="taskgraphfactory" proxydependent="true"> <param paramname="factory"> <value>webservices (GAP)</value> </renderinghint> <renderinghint hint="webservice" proxydependent="true" /> </renderinghints> <inportnum></inportnum> <outportnum></outportnum> <inparam /> 69

70 4. Analisi di due Workflow Management System per l'e-science <outparam /> <input> <type>unknown Type</type> </input> <output> <type>unknown Type</type> </output> <parameters> <param name="minout" type="unknown"> <value></value> <param name="helpfile" type="unknown"> <value>http://localhost:888/axis/simplemathwebservice.jws?wsdl</value> <param name="popupdescription" type="unknown"> <value>no description for tool</value> <param name="maxin" type="unknown"> <value></value> <param name="maxout" type="unknown"> <value></value> <param name="guiy" type="gui"> <value> </value> <param name="guix" type="gui"> <value> </value> <param name="outputtype" type="unknown"> <value>java.lang.double</value> <param name="defaultout" type="unknown"> <value></value> <param name="minin" type="unknown"> <value></value> <param name="defaultin" type="unknown"> <value></value> </parameters> </task> <task> <toolname>loop</toolname> <package>common.control</package> <proxy type="java"> <param paramname="unitpackage"> <value>common\logic</value> <param paramname="unitname"> <value>common.logic.loop</value> </proxy> <renderinghints> <renderinghint hint="controltool" proxydependent="false"> <param paramname="description"> <value /> <param paramname="validstandalone"> <value>true</value> 7

71 4. Analisi di due Workflow Management System per l'e-science <param paramname="controlname"> <value>loop</value> <param paramname="validtoplevel"> <value>false</value> </renderinghint> <renderinghint hint="taskgraphfactory" proxydependent="true"> <param paramname="factory"> <value>default</value> </renderinghint> </renderinghints> <inportnum>2</inportnum> <outportnum>2</outportnum> <inparam /> <outparam /> <input> <type>java.lang.object</type> </input> <output> <type>java.lang.object</type> </output> <parameters> <param name="comp" type="internal"> <value>=</value> <param name="conditionunit" type="useraccessible"> <value>common.logic.defaultexitcondition</value> <param name="maxout" type="internal"> <value> </value> <param name="popupdescription" type="internal"> <value>a conditional looping unit</value> <param name="$var3" type="useraccessible"> <value></value> <param name="$var2" type="useraccessible"> <value></value> <param name="$var" type="useraccessible"> <value></value> <param name="defaultin" type="internal"> <value>2</value> <param name="$var" type="useraccessible"> <value></value> <param name="outputtype" type="unknown"> <value>java.lang.double</value> <param name="toolversion" type="internal"> <value>3</value> <param name="minin" type="internal"> <value>2</value> <param name="outputtype" type="unknown"> <value>java.lang.double</value> 7

72 4. Analisi di due Workflow Management System per l'e-science <param name="eq" type="internal"> <value></value> <param name="param" type="internal"> <value>iterations</value> <param name="enabled" type="useraccessible"> <value>true</value> <param name="exitcondition" type="useraccessible"> <value>(iterations = )</value> <param name="defaultout" type="internal"> <value>2</value> <param name="defaultnoderequirement" type="internal"> <value>optional</value> <param name="paramupdatepolicy" type="internal"> <value>processupdate</value> <param name="minout" type="internal"> <value>2</value> <param name="maxin" type="internal"> <value> </value> <param name="totaliterations" type="useraccessible"> <value></value> <param name="iterations" type="useraccessible"> <value></value> <param name="init$" type="internal"> <value /> <param name="parampanelclass" type="internal"> <value>common.logic.looppanel</value> <param name="helpfile" type="internal"> <value>loop.html</value> <param name="guiy" type="gui"> <value> </value> <param name="guix" type="gui"> <value> </value> </parameters> </task> <connections> <connection> <source taskname="generaterandomnumber" node="" /> <target taskname="loop" node="" /> </connection> <connection> <source taskname="loop" node="" /> <target taskname="constview" node="" /> </connection> <connection> <source taskname="loop" node="" /> 72

73 4. Analisi di due Workflow Management System per l'e-science <target taskname="inc" node="" /> </connection> <connection> <source taskname="inc" node="" /> <target taskname="loop" node="" /> </connection> </connections> </tasks> </tool> Figura 26: Formato XML nativo di Triana per la descrizione dei workflow 73

74 4. Analisi di due Workflow Management System per l'e-science 4.3. Funzionalità di Taverna e Triana a confronto Continuando l'analisi dei due Workflow Management System (WfMS) orientati all'e-science, descritti nella sezione precedente, non possiamo non effettuare un'analisi più accurata delle funzionalità messe a disposizione dai due tool. Cominciamo dicendo che Taverna, già in configurazione standard, effettua il discovery di molti Web Service per la bioinformatica disponibili in rete, citandone qualcuno abbiamo servizi, immediatamente utilizzabili per costruire dei workflow, mediante processori per Soaplab, registri BioMOBY, Biomart, SeqHound ed altri. Triana si pone, invece, in una posizione che possiamo definire più neutra, infatti, pur mettendo a disposizione funzionalità specifiche all'escience, non effettua nessun particolare discovery di servizi. Tralasciando questi aspetti, concentreremo la nostra attenzione sui costrutti messi a disposizione e sul loro tipo di implementazione; in particolare, faremo riferimento ai principali costrutti generici dei sistemi di Workflow, così come teorizzati e descritti nel capitolo relativo in questo documento. Entrambi i tool, permettono la costruzione e l'esecuzione di workflow assemblando tra loro componenti Web Service e componenti locali, come costanti, visualizzatori di messaggi, immagini, ecc... Per la nostra analisi ci serviremo di due semplici Web Service, realizzati in Java con Apache Axis e Apache Tomcat, che espongono le seguenti funzionalità: 74

75 4. Analisi di due Workflow Management System per l'e-science SimpleMathWebService Operazioni sum div Parametri Due numeri in Risultato Somma dei valori Descrizione L'operazione virgola mobile con passati come effettua la somma precisione doppia parametri tra due numeri Due numeri in L'operazione Risultato della virgola mobile con divisione del effettia la divisione precisione doppia numero passato tra i due numeri come primo passati come parametro quello parametri passato come secondo parametro dec Un numero in Il numero passato Decrementa di il virgola mobile con come parametro numero passato precisione doppia decrementato di come parametro isgreater Due numeri in Valore booleano virgola mobile con true se e solo se il Confronta i due numeri passati precisione doppia primo parametro è come parametri e maggiore del verifica se il primo secondo, è maggiore del restituisce false secondo altrimenti inc Un numero in Il numero passato Incrementa di il virgola mobile con come parametro valore numerico precisione doppia incrementato di passato come parametro getversion nessuno Il numero di 75 Restituisce il

76 4. Analisi di due Workflow Management System per l'e-science SimpleMathWebService sub Due numeri in versione del numero di servizio come versione attuale del stringa servizio Il risultato della Sottrae i due virgola mobile con sottrazione del numeri passati precisione doppia secondo come parametri parametro dal primo mul Due numeri in Il risultato della Moltiplica i valori virgola mobile con moltiplicazione del numerici passati precisione doppia primo parametro per il secondo Tabella 2: Operazioni esposte dal SimpleMathWebService, Web Service di test 76 come parametri

77 4. Analisi di due Workflow Management System per l'e-science UtilitiesWebService Operazioni generatetimestampstring Parametri nessuno Risultato Descrizione Una stringa con il Restituisce la data timestamp e l'ora al momento corrente dell'invocazione del servizio generaterandomnumber nessuno Un numero in L'operazione precisione doppia genera e restituisce casuale tra. e un numero casuale. in virgola mobile con precisione doppia compreso tra. e. generatedoublearray nessuno Un array di L'operazione numeri in virgola genera e restituisce mobile con un array di precisione doppia numeri casuali in virgola mobile con precisione doppia compresi tra. e. getversion nessuno Il numero di Restituisce il versione del numero di servizio come versione attuale del stringa servizio Tabella 3: Le operazione esposte dal UtilitiesWebService, Web Service di test 77

78 4. Analisi di due Workflow Management System per l'e-science Per effettuare l'analisi, i due Web Service precedenti vengono entrambi importati nei due WfMS attraverso le loro specifiche operazioni di discovery e import a partire dalla locazione del descrittore WSDL e successivamente le loro operazioni vengono combinate in modo da ottenere e testare una certa logica applicativa come illustrata nelle sezioni successive Sequential Routing Questa funzionalità di base dei sistemi di workflow è trattata in maniera pressoché identica da entrambi i WfMS; entrambi infatti permettono, in via del tutto grafica, la selezione delle componenti e il collegamento per la creazione di un flusso di esecuzione sequenziale. Considerando i due Web Service di test illustrati nelle tabelle precedenti, un esempio di elaborazione sequenziale potrebbe essere la seguente: Genera due numeri casuali e sommali, dopodiché incrementa di uno il risultato della somma Le figure seguenti illustrano i workflow appositamente creati con Taverna e Triana per ottenere l'elaborazione precedente. 78

79 4. Analisi di due Workflow Management System per l'e-science Figura 27: Workflow realizzato con Taverna per incrementare di uno la somma di due numeri casuali Figura 28: Workflow realizzato con Triana per incrementare di uno la somma di due numeri casuali Parallel Routing Per testare questa funzionalità, nei due WfMS, cerchiamo di creare un workflow 79

80 4. Analisi di due Workflow Management System per l'e-science che effettui le seguenti operazioni: Genera, contemporaneamente, due coppie di numeri casuali e calcola la loro somma per ciascuna coppia, dopodiché effettua la moltiplicazione delle due somme. Le figure seguenti illustrano i workflow ottenuti. Figura 29: Parallel Routing in Taverna In Triana l'elaborazione parallela è ottenuta consentendo all'utente di specificare il numero nodi di input-output in una unità del workflow. In pratica i nodi di AND-Split e di AND-Join sono implementati da un qualsiasi blocco nel diagramma; Figura 3: Parallel Routing in Triana 8

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

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

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

più del mercato applicazioni dei processi modificato. Reply www.reply.eu

più del mercato applicazioni dei processi modificato. Reply www.reply.eu SOA IN AMBITO TELCO Al fine di ottimizzare i costi e di migliorare la gestione dell'it, le aziende guardano, sempre più con maggiore interesse, alle problematiche di gestionee ed ottimizzazione dei processi

Dettagli

Introduzione. E un sistema EAI molto flessibile, semplice ed efficace:

Introduzione. E un sistema EAI molto flessibile, semplice ed efficace: Overview tecnica Introduzione E un sistema EAI molto flessibile, semplice ed efficace: Introduce un architettura ESB nella realtà del cliente Si basa su standard aperti Utilizza un qualsiasi Application

Dettagli

Università degli Studi di Parma. Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica

Università degli Studi di Parma. Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica A.A. 2007-08 CORSO DI INGEGNERIA DEL SOFTWARE Prof. Giulio Destri http://www.areasp.com (C) 2007 AreaSP for

Dettagli

Le caratteristiche di interoperabilità del Terrapack 32 M

Le caratteristiche di interoperabilità del Terrapack 32 M I T P E l e t t r o n i c a Le caratteristiche di interoperabilità del Terrapack 32 M M. Guerriero*, V. Ferrara**, L. de Santis*** * ITP Elettronica ** Dipartimento di Ingegneria Elettronica Univ. La Sapienza

Dettagli

Introduzione alle applicazioni di rete

Introduzione alle applicazioni di rete Introduzione alle applicazioni di rete Definizioni base Modelli client-server e peer-to-peer Socket API Scelta del tipo di servizio Indirizzamento dei processi Identificazione di un servizio Concorrenza

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

Informatica per la comunicazione" - lezione 9 -

Informatica per la comunicazione - lezione 9 - Informatica per la comunicazione" - lezione 9 - Protocolli di livello intermedio:" TCP/IP" IP: Internet Protocol" E il protocollo che viene seguito per trasmettere un pacchetto da un host a un altro, in

Dettagli

Applicazione: DoQui/Index - Motore di gestione dei contenuti digitali

Applicazione: DoQui/Index - Motore di gestione dei contenuti digitali Riusabilità del software - Catalogo delle applicazioni: Applicativo verticale Applicazione: DoQui/Index - Motore di gestione dei contenuti digitali Amministrazione: Regione Piemonte - Direzione Innovazione,

Dettagli

Corso di Programmazione ad Oggetti

Corso di Programmazione ad Oggetti Corso di Programmazione ad Oggetti Introduzione alla programmazione ad oggetti a.a. 2008/2009 Claudio De Stefano 1 La programmazione modulare Un programma può essere visto come un insieme di moduli che

Dettagli

SMS API. Documentazione Tecnica YouSMS SOAP API. YouSMS Evet Limited 2015 http://www.yousms.it

SMS API. Documentazione Tecnica YouSMS SOAP API. YouSMS Evet Limited 2015 http://www.yousms.it SMS API Documentazione Tecnica YouSMS SOAP API YouSMS Evet Limited 2015 http://www.yousms.it INDICE DEI CONTENUTI Introduzione... 2 Autenticazione & Sicurezza... 2 Username e Password... 2 Connessione

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

AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma. Unified Process. Prof. Agostino Poggi

AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma. Unified Process. Prof. Agostino Poggi AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma Unified Process Prof. Agostino Poggi Unified Process Unified Software Development Process (USDP), comunemente chiamato

Dettagli

F O R M A T O E U R O P E O

F O R M A T O E U R O P E O F O R M A T O E U R O P E O P E R I L C U R R I C U L U M V I T A E INFORMAZIONI PERSONALI Nome Indirizzo Laura Bacci, PMP Via Tezze, 36 46100 MANTOVA Telefono (+39) 348 6947997 Fax (+39) 0376 1810801

Dettagli

Metadati e Modellazione. standard P_META

Metadati e Modellazione. standard P_META Metadati e Modellazione Lo standard Parte I ing. Laurent Boch, ing. Roberto Del Pero Rai Centro Ricerche e Innovazione Tecnologica Torino 1. Introduzione 1.1 Scopo dell articolo Questo articolo prosegue

Dettagli

Elementi di Informatica e Programmazione

Elementi di Informatica e Programmazione Elementi di Informatica e Programmazione Le Reti di Calcolatori (parte 2) Corsi di Laurea in: Ingegneria Civile Ingegneria per l Ambiente e il Territorio Università degli Studi di Brescia Docente: Daniela

Dettagli

Architettura SPC e porta di dominio per le PA

Architettura SPC e porta di dominio per le PA Libro bianco sulla SOA v.1.0 Allegato 2_1 Architettura SPC e porta di dominio per le PA vs 02 marzo 2008 Gruppo di Lavoro SOA del ClubTI di Milano Premessa L architettura SPC e la relativa porta di dominio

Dettagli

Il Concetto di Processo

Il Concetto di Processo Processi e Thread Il Concetto di Processo Il processo è un programma in esecuzione. È l unità di esecuzione all interno del S.O. Solitamente, l esecuzione di un processo è sequenziale (le istruzioni vengono

Dettagli

FileMaker Server 13. Guida introduttiva

FileMaker Server 13. Guida introduttiva FileMaker Server 13 Guida introduttiva 2007-2013 FileMaker, Inc. Tutti i diritti riservati. FileMaker, Inc. 5201 Patrick Henry Drive Santa Clara, California 95054 Stati Uniti FileMaker e Bento sono marchi

Dettagli

La piattaforma IBM Cognos

La piattaforma IBM Cognos La piattaforma IBM Cognos Fornire informazioni complete, coerenti e puntuali a tutti gli utenti, con una soluzione economicamente scalabile Caratteristiche principali Accedere a tutte le informazioni in

Dettagli

REGIONE BASILICATA (ART. 125 DEL D.LGS. N. 163/06) ALLEGATO N. 1 CARATTERISTICHE TECNICHE DEL SERVIZIO

REGIONE BASILICATA (ART. 125 DEL D.LGS. N. 163/06) ALLEGATO N. 1 CARATTERISTICHE TECNICHE DEL SERVIZIO REGIONE BASILICATA PROCEDURA NEGOZIATA PER L AFFIDAMENTO DEL SERVIZIO DI PROGETTAZIONE, REALIZZAZIONE E GESTIONE DEL SISTEMA INTEGRATO SERB ECM DELLA REGIONE BASILICATA (ART. 125 DEL D.LGS. N. 163/06)

Dettagli

Applicazione: Share - Sistema per la gestione strutturata di documenti

Applicazione: Share - Sistema per la gestione strutturata di documenti Riusabilità del software - Catalogo delle applicazioni: Gestione Documentale Applicazione: Share - Sistema per la gestione strutturata di documenti Amministrazione: Regione Piemonte - Direzione Innovazione,

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

FileMaker Server 12. Guida introduttiva

FileMaker Server 12. Guida introduttiva FileMaker Server 12 Guida introduttiva 2007 2012 FileMaker, Inc. Tutti i diritti riservati. FileMaker, Inc. 5201 Patrick Henry Drive Santa Clara, California 95054 FileMaker e Bento sono marchi di FileMaker,

Dettagli

Elementi di UML (7): Diagrammi dei componenti e di deployment

Elementi di UML (7): Diagrammi dei componenti e di deployment Elementi di UML (7): Diagrammi dei componenti e di deployment Università degli Studi di Bologna Facoltà di Scienze MM. FF. NN. Corso di Laurea in Scienze di Internet Anno Accademico 2004-2005 Laboratorio

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

Il World Wide Web: nozioni introduttive

Il World Wide Web: nozioni introduttive Il World Wide Web: nozioni introduttive Dott. Nicole NOVIELLI novielli@di.uniba.it http://www.di.uniba.it/intint/people/nicole.html Cos è Internet! Acronimo di "interconnected networks" ("reti interconnesse")!

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

UNIVERSITÀ DEGLI STUDI DI BERGAMO. PROPOSTE di TIROCINI/TESI di LAUREA - Prof. Patrizia Scandurra

UNIVERSITÀ DEGLI STUDI DI BERGAMO. PROPOSTE di TIROCINI/TESI di LAUREA - Prof. Patrizia Scandurra PROPOSTE di TIROCINI/TESI di LAUREA - Prof. Patrizia Scandurra A seguire alcune proposte di tirocini/tesi in tre ambiti dell ingegneria del software (non del tutto scorrelati): (1) Model-driven driven

Dettagli

PROFILI ALLEGATO A. Profili professionali

PROFILI ALLEGATO A. Profili professionali ALLEGATO A Profili professionali Nei profili di seguito descritti vengono sintetizzate le caratteristiche di delle figure professionali che verranno coinvolte nell erogazione dei servizi oggetto della

Dettagli

Lezione n 1! Introduzione"

Lezione n 1! Introduzione Lezione n 1! Introduzione" Corso sui linguaggi del web" Fondamentali del web" Fondamentali di una gestione FTP" Nomenclatura di base del linguaggio del web" Come funziona la rete internet?" Connessione"

Dettagli

CA Process Automation

CA Process Automation CA Process Automation Glossario Release 04.2.00 La presente documentazione, che include il sistema di guida in linea integrato e materiale distribuibile elettronicamente (d'ora in avanti indicata come

Dettagli

Enterprise Content Management. Terminologia. KM, ECM e BPM per creare valore nell impresa. Giovanni Marrè Amm. Del., it Consult

Enterprise Content Management. Terminologia. KM, ECM e BPM per creare valore nell impresa. Giovanni Marrè Amm. Del., it Consult KM, ECM e BPM per creare valore nell impresa Giovanni Marrè Amm. Del., it Consult Terminologia Ci sono alcuni termini che, a vario titolo, hanno a che fare col tema dell intervento KM ECM BPM E20 Enterprise

Dettagli

VIRTUALIZE IT. www.digibyte.it - digibyte@digibyte.it

VIRTUALIZE IT. www.digibyte.it - digibyte@digibyte.it il server? virtualizzalo!! Se ti stai domandando: ma cosa stanno dicendo? ancora non sai che la virtualizzazione è una tecnologia software, oggi ormai consolidata, che sta progressivamente modificando

Dettagli

RedDot Content Management Server Content Management Server Non sottovalutate il potenziale della comunicazione online: usatela! RedDot CMS vi permette di... Implementare, gestire ed estendere progetti

Dettagli

Estensione di un servizo di messaggistica per telefonia mobile (per una società di agenti TuCSoN)

Estensione di un servizo di messaggistica per telefonia mobile (per una società di agenti TuCSoN) Estensione di un servizo di messaggistica per telefonia mobile (per una società di agenti TuCSoN) System Overview di Mattia Bargellini 1 CAPITOLO 1 1.1 Introduzione Il seguente progetto intende estendere

Dettagli

Modello OSI e architettura TCP/IP

Modello OSI e architettura TCP/IP Modello OSI e architettura TCP/IP Differenza tra modello e architettura - Modello: è puramente teorico, definisce relazioni e caratteristiche dei livelli ma non i protocolli effettivi - Architettura: è

Dettagli

***** Il software IBM e semplice *****

***** Il software IBM e semplice ***** Il IBM e semplice ***** ***** Tutto quello che hai sempre voluto sapere sui prodotti IBM per qualificare i potenziali clienti, sensibilizzarli sulle nostre offerte e riuscire a convincerli. WebSphere IL

Dettagli

IBM Cognos 8 BI Midmarket Reporting Packages Per soddisfare tutte le vostre esigenze di reporting restando nel budget

IBM Cognos 8 BI Midmarket Reporting Packages Per soddisfare tutte le vostre esigenze di reporting restando nel budget Data Sheet IBM Cognos 8 BI Midmarket Reporting Packages Per soddisfare tutte le vostre esigenze di reporting restando nel budget Panoramica Le medie aziende devono migliorare nettamente le loro capacità

Dettagli

Il Business Process Management: nuova via verso la competitività aziendale

Il Business Process Management: nuova via verso la competitività aziendale Il Business Process Management: nuova via verso la competitività Renata Bortolin Che cosa significa Business Process Management? In che cosa si distingue dal Business Process Reingeneering? Cosa ha a che

Dettagli

Le Reti Informatiche

Le Reti Informatiche Le Reti Informatiche modulo 10 Prof. Salvatore Rosta www.byteman.it s.rosta@byteman.it 1 Nomenclatura: 1 La rappresentazione di uno schema richiede una serie di abbreviazioni per i vari componenti. Seguiremo

Dettagli

DataFix. La soluzione innovativa per l'help Desk aziendale

DataFix. La soluzione innovativa per l'help Desk aziendale DataFix D A T A N O S T O P La soluzione innovativa per l'help Desk aziendale La soluzione innovativa per l'help Desk aziendale L a necessità di fornire un adeguato supporto agli utenti di sistemi informatici

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 della Web Application 5 3 Struttura della web Application 6 4 Casi di utilizzo della Web

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

Oggetti Lezione 3. aspetti generali e definizione di classi I

Oggetti Lezione 3. aspetti generali e definizione di classi I Programmazione a Oggetti Lezione 3 Il linguaggio Java: aspetti generali e definizione di classi I Sommario Storia e Motivazioni Definizione di Classi Campi e Metodi Istanziazione di oggetti Introduzione

Dettagli

PROPOSTE SISTEMA DI CITIZEN RELATIONSHIP MANAGEMENT (CRM) REGIONALE

PROPOSTE SISTEMA DI CITIZEN RELATIONSHIP MANAGEMENT (CRM) REGIONALE PROPOSTE SISTEMA DI CITIZEN RELATIONSHIP MANAGEMENT (CRM) REGIONALE Versione 1.0 Via della Fisica 18/C Tel. 0971 476311 Fax 0971 476333 85100 POTENZA Via Castiglione,4 Tel. 051 7459619 Fax 051 7459619

Dettagli

ISTRUZIONI PER IL SERVIZIO SPCOOP - RICEZIONE

ISTRUZIONI PER IL SERVIZIO SPCOOP - RICEZIONE ISTRUZIONI PER IL SERVIZIO SPCOOP - RICEZIONE Pag. 1 di 14 INDICE 1. Glossario... 3 2. il servizio SPCoop - Ricezione... 5 3. Il web-service RicezioneFatture... 8 3.1 Operazione RiceviFatture... 9 3.1.1

Dettagli

REAL WORLD AND VIRTUAL WORLD ARCHITECTURE FOR INTERCONN INTERCONNECTING FIRST AND SECOND LIFE

REAL WORLD AND VIRTUAL WORLD ARCHITECTURE FOR INTERCONN INTERCONNECTING FIRST AND SECOND LIFE REAL WORLD AND VIRTUAL WORLD ARCHITECTURE FOR INTERCONNECTING FIRST AND SECOND LIFE Università degli studi di Catania Facoltà di Ingegneria 26 Gennaio 2009 Sommario 1 Introduzione 2 Middleware Middleware:

Dettagli

1 EJB e Portal Component Object http://desvino.altervista.org

1 EJB e Portal Component Object http://desvino.altervista.org 1 EJB e Portal Component Object http://desvino.altervista.org In questo tutorial studiamo come sfruttare la tecnologia EJB, Enterprise JavaBean, all interno del SAP Netweaver Portal. In breve, EJB è un

Dettagli

UML Component and Deployment diagram

UML Component and Deployment diagram UML Component and Deployment diagram Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it Dipartimento di Ingegneria Informatica e delle Telecomunicazioni Università di Catania I diagrammi UML Classificazione

Dettagli

La configurazione degli indirizzi IP. Configurazione statica, con DHCP, e stateless

La configurazione degli indirizzi IP. Configurazione statica, con DHCP, e stateless La configurazione degli indirizzi IP Configurazione statica, con DHCP, e stateless 1 Parametri essenziali per una stazione IP Parametri obbligatori Indirizzo IP Netmask Parametri formalmente non obbligatori,

Dettagli

Copyright Università degli Studi di Torino, Progetto Atlante delle Professioni 2009 IT PROCESS EXPERT

Copyright Università degli Studi di Torino, Progetto Atlante delle Professioni 2009 IT PROCESS EXPERT IT PROCESS EXPERT 1. CARTA D IDENTITÀ... 2 2. CHE COSA FA... 3 3. DOVE LAVORA... 4 4. CONDIZIONI DI LAVORO... 5 5. COMPETENZE... 6 Quali competenze sono necessarie... 6 Conoscenze... 8 Abilità... 9 Comportamenti

Dettagli

12.5 UDP (User Datagram Protocol)

12.5 UDP (User Datagram Protocol) CAPITOLO 12. SUITE DI PROTOCOLLI TCP/IP 88 12.5 UDP (User Datagram Protocol) L UDP (User Datagram Protocol) é uno dei due protocolli del livello di trasporto. Come l IP, é un protocollo inaffidabile, che

Dettagli

Sempre attenti ad ogni dettaglio Bosch Intelligent Video Analysis

Sempre attenti ad ogni dettaglio Bosch Intelligent Video Analysis Sempre attenti ad ogni dettaglio Bosch Intelligent Video Analysis 2 Intervento immediato con Bosch Intelligent Video Analysis Indipendentemente da quante telecamere il sistema utilizza, la sorveglianza

Dettagli

MODALITÀ DI QUALIFICAZIONE DELLA PORTA DI DOMINIO

MODALITÀ DI QUALIFICAZIONE DELLA PORTA DI DOMINIO MODALITÀ DI QUALIFICAZIONE DELLA PORTA DI DOMINIO Versione 1.1 INDICE 1. PREFAZIONE 3 1.1 Autori 3 1.2 Modifiche Documento 3 1.3 Riferimenti 4 1.4 Acronimi e Definizioni 4 2. OBIETTIVI E CONTESTO DI RIFERIMENTO

Dettagli

FORM Il sistema informativo di gestione della modulistica elettronica.

FORM Il sistema informativo di gestione della modulistica elettronica. Studio FORM FORM Il sistema informativo di gestione della modulistica elettronica. We believe in what we create This is FORM power La soluzione FORM permette di realizzare qualsiasi documento in formato

Dettagli

ORACLE BUSINESS INTELLIGENCE STANDARD EDITION ONE A WORLD CLASS PERFORMANCE

ORACLE BUSINESS INTELLIGENCE STANDARD EDITION ONE A WORLD CLASS PERFORMANCE ORACLE BUSINESS INTELLIGENCE STANDARD EDITION ONE A WORLD CLASS PERFORMANCE Oracle Business Intelligence Standard Edition One è una soluzione BI completa, integrata destinata alle piccole e medie imprese.oracle

Dettagli

Sistemi di supporto alle decisioni Ing. Valerio Lacagnina

Sistemi di supporto alle decisioni Ing. Valerio Lacagnina Cosa è il DSS L elevato sviluppo dei personal computer, delle reti di calcolatori, dei sistemi database di grandi dimensioni, e la forte espansione di modelli basati sui calcolatori rappresentano gli sviluppi

Dettagli

Sistemi Web-Based - Terminologia. Progetto di Sistemi Web-Based Prof. Luigi Laura, Univ. Tor Vergata, a.a. 2010/2011

Sistemi Web-Based - Terminologia. Progetto di Sistemi Web-Based Prof. Luigi Laura, Univ. Tor Vergata, a.a. 2010/2011 Sistemi Web-Based - Terminologia Progetto di Sistemi Web-Based Prof. Luigi Laura, Univ. Tor Vergata, a.a. 2010/2011 CLIENT: il client è il programma che richiede un servizio a un computer collegato in

Dettagli

MIB PER IL CONTROLLO DELLO STATO DI UN SERVER FTP

MIB PER IL CONTROLLO DELLO STATO DI UN SERVER FTP Università degli Studi di Pisa Facoltà di Scienze Matematiche,Fisiche e Naturali Corso di Laurea in Informatica Michela Chiucini MIB PER IL CONTROLLO DELLO STATO DI UN SERVER

Dettagli

EMC Documentum xcp for Business Process Management

EMC Documentum xcp for Business Process Management Analisi dettagliata Abstract Oggi le aziende devono affrontare una sfida comune: ottimizzare i processi di business e la loro efficienza operativa. Per vincere questa sfida, EMC Documentum xcelerated Composition

Dettagli

Valutazione comparativa di applicazioni open source per il Business Process Management

Valutazione comparativa di applicazioni open source per il Business Process Management Valutazione comparativa di applicazioni open source per il Business Process Management Abstract Uno dei passi fondamentali della metodologia USBD (Unified Scenario-Based Design) è la modellazione dei processi

Dettagli

Il ciclo di vita del software

Il ciclo di vita del software Il ciclo di vita del software Il ciclo di vita del software Definisce un modello per il software, dalla sua concezione iniziale fino al suo sviluppo completo, al suo rilascio, alla sua successiva evoluzione,

Dettagli

Talento LAB 4.1 - UTILIZZARE FTP (FILE TRANSFER PROTOCOL) L'UTILIZZO DI ALTRI SERVIZI INTERNET. In questa lezione imparerete a:

Talento LAB 4.1 - UTILIZZARE FTP (FILE TRANSFER PROTOCOL) L'UTILIZZO DI ALTRI SERVIZI INTERNET. In questa lezione imparerete a: Lab 4.1 Utilizzare FTP (File Tranfer Protocol) LAB 4.1 - UTILIZZARE FTP (FILE TRANSFER PROTOCOL) In questa lezione imparerete a: Utilizzare altri servizi Internet, Collegarsi al servizio Telnet, Accedere

Dettagli

Web Conferencing and Collaboration tool

Web Conferencing and Collaboration tool Web Conferencing and Collaboration tool La piattaforma Meetecho Piattaforma di Web Conferencing e Collaborazione on line in tempo reale Caratteristiche generali Soluzione client-server progettata per essere

Dettagli

Processi di business sovra-regionali relativi ai sistemi regionali di FSE. Versione 1.0 24 Giugno 2014

Processi di business sovra-regionali relativi ai sistemi regionali di FSE. Versione 1.0 24 Giugno 2014 Processi di business sovra-regionali relativi ai sistemi regionali di FSE Versione 1.0 24 Giugno 2014 1 Indice Indice... 2 Indice delle figure... 3 Indice delle tabelle... 4 Obiettivi del documento...

Dettagli

Web Conferencing Open Source

Web Conferencing Open Source Web Conferencing Open Source A cura di Giuseppe Maugeri g.maugeri@bembughi.org 1 Cos è BigBlueButton? Sistema di Web Conferencing Open Source Basato su più di quattordici componenti Open-Source. Fornisce

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

Programmazione di rete in Java

Programmazione di rete in Java Programmazione di rete in Java Reti di calcolatori Una rete di calcolatori è un sistema che permette la condivisione di dati informativi e risorse (sia hardware sia software) tra diversi calcolatori. Lo

Dettagli

Appunti di Antonio Bernardo

Appunti di Antonio Bernardo Internet Appunti di Antonio Bernardo Cos è Internet Internet può essere vista come una rete logica di enorme complessità, appoggiata a strutture fisiche e collegamenti di vario tipo (fibre ottiche, cavi

Dettagli

Piazza delle Imprese alimentari. Viale delle Manifatture. Via della Produzione

Piazza delle Imprese alimentari. Viale delle Manifatture. Via della Produzione Piazza delle Imprese alimentari Viale delle Manifatture Via della Produzione PASSEPARTOUT MEXAL è una soluzione gestionale potente e completa per le imprese che necessitano di un prodotto estremamente

Dettagli

FileMaker Server 13. Pubblicazione Web personalizzata con PHP

FileMaker Server 13. Pubblicazione Web personalizzata con PHP FileMaker Server 13 Pubblicazione Web personalizzata con PHP 2007-2013 FileMaker, Inc. Tutti i diritti riservati. FileMaker, Inc. 5201 Patrick Henry Drive Santa Clara, California 95054 Stati Uniti FileMaker

Dettagli

Processi (di sviluppo del) software. Fase di Analisi dei Requisiti. Esempi di Feature e Requisiti. Progettazione ed implementazione

Processi (di sviluppo del) software. Fase di Analisi dei Requisiti. Esempi di Feature e Requisiti. Progettazione ed implementazione Processi (di sviluppo del) software Fase di Analisi dei Requisiti Un processo software descrive le attività (o task) necessarie allo sviluppo di un prodotto software e come queste attività sono collegate

Dettagli

Dispense di Informatica Anno Scolastico 2008/2009 Classe 3APS. Dal Problema all'algoritmo

Dispense di Informatica Anno Scolastico 2008/2009 Classe 3APS. Dal Problema all'algoritmo stituto Tecnico Statale Commerciale Dante Alighieri Cerignola (FG) Dispense di nformatica Anno Scolastico 2008/2009 Classe 3APS Dal Problema all'algoritmo Pr.: 001 Ver.:1.0 Autore: prof. Michele Salvemini

Dettagli

Luca Mari, Sistemi informativi applicati (reti di calcolatori) appunti delle lezioni. Architetture client/server: applicazioni client

Luca Mari, Sistemi informativi applicati (reti di calcolatori) appunti delle lezioni. Architetture client/server: applicazioni client Versione 25.4.05 Sistemi informativi applicati (reti di calcolatori): appunti delle lezioni Architetture client/server: applicazioni client 1 Architetture client/server: un esempio World wide web è un

Dettagli

Inter Process Communication. Laboratorio Software 2008-2009 C. Brandolese

Inter Process Communication. Laboratorio Software 2008-2009 C. Brandolese Inter Process Communication Laboratorio Software 2008-2009 C. Brandolese Introduzione Più processi o thread Concorrono alla relaizzazione di una funzione applicativa Devono poter realizzare Sincronizzazione

Dettagli

Internet Internet è universalmente nota come la Rete delle reti: un insieme smisurato di computer collegati tra loro per scambiarsi dati e servizi.

Internet Internet è universalmente nota come la Rete delle reti: un insieme smisurato di computer collegati tra loro per scambiarsi dati e servizi. Internet Internet è universalmente nota come la Rete delle reti: un insieme smisurato di computer collegati tra loro per scambiarsi dati e servizi. Internet: la rete delle reti Alberto Ferrari Connessioni

Dettagli

SIASFi: il sistema ed il suo sviluppo

SIASFi: il sistema ed il suo sviluppo SIASFI: IL SISTEMA ED IL SUO SVILUPPO 187 SIASFi: il sistema ed il suo sviluppo Antonio Ronca Il progetto SIASFi nasce dall esperienza maturata da parte dell Archivio di Stato di Firenze nella gestione

Dettagli

Business Process Management

Business Process Management Corso di Certificazione in Business Process Management Progetto Didattico 2015 con la supervisione scientifica del Dipartimento di Informatica Università degli Studi di Torino Responsabile scientifico

Dettagli

DynDevice ECM. La Suite di applicazioni web per velocizzare, standardizzare e ottimizzare il flusso delle informazioni aziendali

DynDevice ECM. La Suite di applicazioni web per velocizzare, standardizzare e ottimizzare il flusso delle informazioni aziendali DynDevice ECM La Suite di applicazioni web per velocizzare, standardizzare e ottimizzare il flusso delle informazioni aziendali Presentazione DynDevice ECM Cos è DynDevice ICMS Le soluzioni di DynDevice

Dettagli

Ing. Andrea Saccà. Stato civile: Celibe Nazionalità: Italiana Data di nascita: 9 Ottobre 1978 Luogo di nascita: Roma Residenza: Roma

Ing. Andrea Saccà. Stato civile: Celibe Nazionalità: Italiana Data di nascita: 9 Ottobre 1978 Luogo di nascita: Roma Residenza: Roma Indirizzo: Via dell'automobilismo, 109 00142 Roma (RM) Sito Web : http://www.andreasacca.com Telefono: 3776855061 Email : sacca.andrea@gmail.com PEC : andrea.sacca@pec.ording.roma.it Ing. Andrea Saccà

Dettagli

Enterprise Services Infrastructure ESI 2.0

Enterprise Services Infrastructure ESI 2.0 Enterprise Services Infrastructure ESI 2.0 Caratteristiche e Posizionamento ver. 2.1 del 21/01/2013 Cos è ESI - Enterprise Service Infrastructure? Cos è ESI? ESI (Enteprise Service Infrastructure) è una

Dettagli

nasce il futuro v secolo a. c. agorà virtuale

nasce il futuro v secolo a. c. agorà virtuale dell e-learning nasce il futuro v secolo a. c. Con Agorà, nell antica Grecia, si indicava la piazza principale della polis, il suo cuore pulsante, il luogo per eccellenza di una fertilità culturale e scientifica

Dettagli

Utilizzato con successo nei più svariati settori aziendali, Passepartout Mexal BP è disponibile in diverse versioni e configurazioni:

Utilizzato con successo nei più svariati settori aziendali, Passepartout Mexal BP è disponibile in diverse versioni e configurazioni: Passepartout Mexal BP è una soluzione gestionale potente e completa per le imprese che necessitano di un prodotto estremamente flessibile, sia dal punto di vista tecnologico sia funzionale. Con più di

Dettagli

Gestione delle Architetture e dei Servizi IT con ADOit. Un Prodotto della Suite BOC Management Office

Gestione delle Architetture e dei Servizi IT con ADOit. Un Prodotto della Suite BOC Management Office Gestione delle Architetture e dei Servizi IT con ADOit Un Prodotto della Suite BOC Management Office Controllo Globale e Permanente delle Architetture IT Aziendali e dei Processi IT: IT-Governance Definire

Dettagli

REALIZZARE UN MODELLO DI IMPRESA

REALIZZARE UN MODELLO DI IMPRESA REALIZZARE UN MODELLO DI IMPRESA - organizzare e gestire l insieme delle attività, utilizzando una piattaforma per la gestione aziendale: integrata, completa, flessibile, coerente e con un grado di complessità

Dettagli

CARATTERISTICHE DELLE CRYPTO BOX

CARATTERISTICHE DELLE CRYPTO BOX Secure Stream PANORAMICA Il sistema Secure Stream è costituito da due appliance (Crypto BOX) in grado di stabilire tra loro un collegamento sicuro. Le Crypto BOX sono dei veri e propri router in grado

Dettagli

RUP (Rational Unified Process)

RUP (Rational Unified Process) RUP (Rational Unified Process) Caratteristiche, Punti di forza, Limiti versione del tutorial: 3.3 (febbraio 2007) Pag. 1 Unified Process Booch, Rumbaugh, Jacobson UML (Unified Modeling Language) notazione

Dettagli

ITIL v3 e' parte di un processo teso a migliorare le best practices ITIL. In effetti, ITIL predica il "continuous improvement" ed e'

ITIL v3 e' parte di un processo teso a migliorare le best practices ITIL. In effetti, ITIL predica il continuous improvement ed e' ITIL v3 ITIL v3 e' parte di un processo teso a migliorare le best practices ITIL. In effetti, ITIL predica il "continuous improvement" ed e' giusto che lo applichi anche a se' stessa... Naturalmente una

Dettagli

Prova di Esame - Rete Internet (ing. Giovanni Neglia) Prova completa Mercoledì 2 Marzo 2005, ore 14.30

Prova di Esame - Rete Internet (ing. Giovanni Neglia) Prova completa Mercoledì 2 Marzo 2005, ore 14.30 Prova di Esame - Rete Internet (ing. Giovanni Neglia) Prova completa Mercoledì 2 Marzo 2005, ore 14.30 NB: alcune domande hanno risposta multipla: si richiede di identificare TUTTE le risposte corrette.

Dettagli

I N F I N I T Y Z U C C H E T T I WORKFLOW HR

I N F I N I T Y Z U C C H E T T I WORKFLOW HR I N F I N I T Y Z U C C H E T T I WORKFLOW HR WORKFLOW HR Zucchetti, nell ambito delle proprie soluzioni per la gestione del personale, ha realizzato una serie di moduli di Workflow in grado di informatizzare

Dettagli

Protocollo HTTP. Alessandro Sorato

Protocollo HTTP. Alessandro Sorato Un protocollo è un insieme di regole che permettono di trovare uno standard di comunicazione tra diversi computer attraverso la rete. Quando due o più computer comunicano tra di loro si scambiano una serie

Dettagli

MARKETING INTELLIGENCE SUL WEB:

MARKETING INTELLIGENCE SUL WEB: Via Durini, 23-20122 Milano (MI) Tel.+39.02.77.88.931 Fax +39.02.76.31.33.84 Piazza Marconi,15-00144 Roma Tel.+39.06.32.80.37.33 Fax +39.06.32.80.36.00 www.valuelab.it valuelab@valuelab.it MARKETING INTELLIGENCE

Dettagli

La soluzione open source per l'it Asset Management: CMDB, workflow, interoperabilità www.cmdbuild.org

La soluzione open source per l'it Asset Management: CMDB, workflow, interoperabilità www.cmdbuild.org 1 La soluzione open source per l'it Asset Management: CMDB, workflow, interoperabilità www.cmdbuild.org Fabio Bottega f.bottega@tecnoteca.com www.tecnoteca.com Il progetto CMDBuild CMDBuild è nato nel

Dettagli

GESTIONE DELLA E-MAIL

GESTIONE DELLA E-MAIL GESTIONE DELLA E-MAIL Esistono due metodologie, completamente diverse tra loro, in grado di consentire la gestione di più caselle di Posta Elettronica: 1. tramite un'interfaccia Web Mail; 2. tramite alcuni

Dettagli

I sistemi operativi si susseguirono, fino alla comparsa di Windows NT, il primo s.o. in cui ci son già implementati dei concetti significativi.

I sistemi operativi si susseguirono, fino alla comparsa di Windows NT, il primo s.o. in cui ci son già implementati dei concetti significativi. DCOM, COM,.NET 2 Quando si parla di architetture proprietarie, si intendono tutta una serie di cose, in particolare si pensa alla storia dei sistemi operativi, in questo caso del S.O. di Microsoft. Mentre

Dettagli

RESPONS.In.City - Methodology

RESPONS.In.City - Methodology RESPONS.In.City - Methodology THE METHODOLOGY OF A RESPONSIBLE CITIZENSHIP PROMOTION Metodologia di Promozione della Cittadinanza come Responsabilità Condivisa 1 Premessa La possibilità di partecipare

Dettagli