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=" xmlns=" xmlns:xsd=" xmlns:bpws=" xmlns:wsdlns=" xmlns:xs=" <import namespace=" location="synchronoussample.wsdl" importtype=" <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=" version=".2" log=""> <s:workflowdescription lsid="urn:lsid: 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> <s:operation>generaterandomnumber</s:operation> </s:arbitrarywsdl> </s:processor> <s:processor name="generaterandomnumber"> <s:arbitrarywsdl> <s:wsdl> <s:operation>generaterandomnumber</s:operation> </s:arbitrarywsdl> </s:processor> <s:processor name="mul"> <s:arbitrarywsdl> <s:wsdl> <s:operation>mul</s:operation> </s:arbitrarywsdl> </s:processor> <s:processor name="div"> <s:arbitrarywsdl> <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> <param paramname="serializedpipe"> <value> 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> <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> <param paramname="serializedpipe"> <value> 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> <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