Un biologo che compone un esperimento “in silico” trascinando blocchi su una tela disegna un grafo di dipendenze tra dati; il motore che lo esegue su una griglia di calcolo, invece, orchestra un insieme di servizi web secondo un linguaggio a controllo di flusso. Far combaciare le due cose — il diagramma e l’orchestrazione — è il problema centrale di un portale che voglia rendere accessibile la bioinformatica a chi non scrive codice.

Problema

Una pipeline bioinformatica tipica è una sequenza di strumenti a riga di comando, ciascuno con il proprio formato di input e output. Si cerca una sequenza in una banca dati (GeneBank), si allineano più sequenze con ClustalW, si progettano i primer con Primer3, si verifica la specificità con BLAST. Ogni passo è un programma a sé, scritto in epoche diverse, con convenzioni proprie. ClustalW è descritto nel paper di Thompson, Higgins e Gibson del 1994; Primer3, di Rozen e Skaletsky (2000), è distribuito sotto GPL; BLAST risale all’algoritmo di Altschul e colleghi del 1990. Nessuno dei tre è stato pensato per essere orchestrato da un terzo.

Il ricercatore di laboratorio, però, non vuole incollare a mano l’output di un programma nell’input del successivo, né scrivere uno script che lo faccia. Vuole disegnare la pipeline e premere “esegui”. Tra questi due desideri ci sono due salti: dal disegno a una rappresentazione eseguibile, e da quella rappresentazione alla griglia di calcolo che la esegue davvero.

Architettura

Il primo salto è una compilazione. L’editor visuale espone una palette di operatori — i passi della pipeline come macroblocchi configurabili — e una tela su cui collegarli. Quello che l’utente costruisce è un grafo: nodi che rappresentano servizi, archi che rappresentano il passaggio di dati. Questo grafo viene tradotto automaticamente in WS-BPEL (Web Services Business Process Execution Language), diventato standard OASIS nella versione 2.0 l’11 aprile 2007. Il documento BPEL così generato descrive un processo che invoca, in ordine e con le dipendenze corrette, i web service che incapsulano ClustalW, Primer3, BLAST e gli altri strumenti.

Il secondo salto è l’esecuzione. Il processo BPEL viene affidato a un motore di orchestrazione — nel caso di ESCOGITARE l’Active BPEL Engine — che dialoga con la griglia computazionale sottostante, costruita su Globus Toolkit (la versione 4.0, dell’aprile 2005, è interamente su architettura a web service WSRF) e descritta dal servizio di informazione MDS. Il motore non sa nulla di bioinformatica: vede attività <invoke>, <receive>, <assign> e le esegue. Tutta la conoscenza del dominio sta a monte, nei macroblocchi della palette e nel compilatore che li trasforma in BPEL.

Il portale che riveste il tutto è il livello a cui l’utente accede dal browser: pubblica i contenuti del progetto, raccoglie i workflow condivisi dalla comunità e li mette a disposizione di chi voglia riusarli. Una declinazione applicativa concreta di questa architettura — l’editor visuale, il CMS e l’integrazione con la griglia ISTI-CNR — è descritta nel progetto pubblicato da noze: https://www.noze.it/progetti/escogitare/.

Punto critico

Il punto in cui la traduzione si fa difficile è la distanza tra i due modelli di calcolo. Quello che il biologo disegna è un dataflow: i blocchi si attivano quando i loro dati di ingresso sono pronti, e l’ordine di esecuzione è implicito nel grafo delle dipendenze. WS-BPEL, invece, nasce per orchestrare processi aziendali ed è un linguaggio a controllo di flusso: l’ordine è esplicito, espresso da costrutti come <sequence>, <flow>, <while>, e la correlazione fra messaggi va dichiarata. Le due semantiche non coincidono.

Compilare un dataflow in BPEL significa colmare questa distanza in modo automatico: dedurre da un grafo di dipendenze dati una struttura di controllo esplicita, decidere quali rami possono procedere in parallelo dentro un <flow> e quali devono restare in <sequence>, gestire l’adattamento dei formati fra un servizio e il successivo (in ESCOGITARE compaiono blocchi adattatori dedicati, come quello che porta l’output di una ricerca di sequenze in ingresso a Primer3). Lo stesso problema è discusso, negli stessi anni, da ambienti come Sedna, che genera BPEL da una modellazione visuale di workflow scientifici, e nel confronto fra Taverna — dataflow nativo — e BPEL come motori per i workflow di griglia. La conclusione ricorrente è che la traduzione è possibile ma non gratuita: ogni costrutto BPEL non banale che il grafo non esprime direttamente va inferito, e l’inferenza è il pezzo di ingegneria che decide se l’editor resta usabile o no.

Implicazioni

La conseguenza progettuale è che la semplicità dell’editor è un vincolo, non un di più. Se l’obiettivo è far comporre pipeline a biologi che non scrivono codice, allora il compilatore verso BPEL deve assorbire tutta la complessità che l’utente non deve vedere: la gestione delle credenziali sulla griglia, la durata dei job, l’adattamento dei tipi, la mappatura del parallelismo. Quanto più il modello visuale resta vicino al modo in cui un ricercatore pensa l’esperimento — una catena di trasformazioni sui dati — tanto più lavoro ricade sul livello di traduzione.

C’è poi un effetto sul riuso. Un workflow espresso come grafo e poi compilato in BPEL è un artefatto condivisibile: si pubblica, si copia, si modifica. La comunità di laboratori distribuiti che lo scambia non ha bisogno di sapere come quel grafo diventi un processo eseguibile; gli basta che la traduzione sia deterministica e che lo stesso disegno produca la stessa esecuzione. La riproducibilità dell’esperimento dipende quindi anche dalla stabilità del compilatore, non solo dalla correttezza dei singoli strumenti.

Limiti

La traduzione automatica copre i workflow che si lasciano esprimere come grafi di servizi ben tipati; fuori restano i casi in cui la logica scientifica richiede controllo di flusso che il modello visuale non rappresenta — iterazioni dipendenti dai dati, decisioni a runtime, gestione fine degli errori di un singolo strumento. Su questi BPEL è espressivo, ma l’editor visuale tende a non esserlo, e la scelta di tenerlo semplice taglia fuori proprio la parte difficile.

Resta inoltre aperta la questione del legame allo stack. Il processo generato presuppone Active BPEL, Globus 4 e l’insieme dei servizi che incapsulano gli strumenti bioinformatici. Spostare quei workflow su un’altra griglia, o su un’altra generazione di middleware, vuol dire riportare la traduzione su un altro bersaglio: il grafo disegnato dal biologo sopravvive, il BPEL che ne deriva molto meno. La portabilità vera sta nel modello visuale e nel suo significato, non nel codice che oggi lo esegue.

Immagine di copertina: immagine del progetto ESCOGITARE (ISTI-CNR / noze).