• Non ci sono risultati.

4. Analisi dei Linguaggi Standard descrittori di Workflow

4.3 WORKFLOW

4.3.4 Linguaggi standard per la descrizione di Workflow

4.3.4.1 WSFL (Web Services Flow Language)

E' un linguaggio basato sull' XML, progettato da IBM. Utilizza WSDL per descrivere le interfacce dei servizi ed i relativi protocolli.

WSFL attiva Web Services come implementazioni delle attività di un business process, quindi ogni attività è associata al service provider responsabile dell'esecuzione di ciascun passo del processo. Questa relazione definisce l'associazione tra le attività presenti nell'applicazione e le operazioni offerte dal service provider. Graficamente il linguaggio pensa di modellare il problema come un grafo orientato. Il principale vantaggio offerto da questo tipo di linguaggio è quello di offrire un controllo diretto sul lifecycle del processo.

WSFL considera due possibili tipologie di composizione di Web Services:

-il primo modo specifica il più appropriato usage pattern, ovvero individua la composizione di servizi in modo tale da realizzare una specifica funzione e tipicamente il risultato di questa composizione è la descrizione del business process.

-il secondo tipo invece specifica il pattern di interazioni tra Web Services e in questo caso il risultato è la descrizione delle interazioni che avvengono tra i partner.

Nel primo caso la composizione è creata descrivendo come utilizzare le funzionalità offerte dalla collection di WS ed è noto come flow composition. WSFL modella questa composizione specificando la sequenza di esecuzione delle funzionalità dei WS coinvolti. L'ordine di esecuzione è specificato dalla definizione dei flussi di dati e di controllo tra i WS. Per questo motivo questo tipo di approccio viene definito Modello di flusso.

Nel secondo caso non viene fornita nessuna sequenza di esecuzione. Dunque la composizione permette di descrivere come i vari WS interagiscono tra loro. Queste interazioni sono modellate tramite legami tra punti di uscita delle interfacce associate ai vari WS (ogni link corrisponde ad una interazione tra un WS e l'operazione di un interfaccia di un altro WS). A causa della natura decentralizzata e distribuita di queste interazioni si utilizzerà la definizione di Modello Globale. Il linguaggio WSFL permette l'utilizzo ricorsivo delle composizioni di WS, in modo tale che una qualsiasi composizione di WS (sia Global Model che Flow Model) possa essere considerata nella sua totalità come un WS. Questa proprietà permette di rappresentare il sistema in modo più aggregato, fornendo maggior leggibilità al linguaggio stesso. Il linguaggio WSFL supporta anche diversi modelli di interazioni tra i partner coinvolti nel business process. In particolare sono possibili interazioni gerarchiche (che in genere sono stabili e a lungo termine) e relazioni peer-to-per stabilite dinamicamente e definite solo peer-to-per la durata dell'istanza che ha generato l'interazione.

Per definire un'applicazione del linguaggio è necessario stabilire: -business process;

-business rules che permettono di passare a step successivi; -flussi di informazioni tra i vari step del processo.

Il flow model descrive la struttura del business process: le attività (rappresentate con cerchi) rappresentano i vari step del processo, i dati e i controlli rappresentano i flussi di informazione e le regole per passare da uno step all'altro. Per ogni attività:

-va individuato il service provider responsabile dell'esecuzione dello step del processo

-vanno individuate le associazioni tra le attività e le operazioni offerte dal service provider (elementi export e plug-in)

Utilizzando WSDL si può definire l'interfaccia tramite la quale un consumer accede al flow model e l'interfaccia attraverso cui il provider accede al flow model. Per ogni attività ci sarà un operazione eseguita dall'interfaccia esterna del flow model che permetterà di interagire con il service provider che implementa quell'attività stessa. In questo modo il sistema può essere pensato come un repository di servizi ai quali accedono due parti: chi vuole fornire il servizio attraverso il flow model e chi vuole essere il consumatore del servizio implementato dal flow model. Questo tipo di interazione è descritta dal global model. Il flow model impone un vincolo nel sequenziamento delle attività. Vengono definiti tutti i provider, dei quali vengono specificate dei legami vincolanti, che definiscono i servizi che vanno utilizzati una volta che il modello viene istanziato (questi legami possono essere statici oppure dinamici e quindi variare a seconda delle condizioni in cui viene interpellato il provider). Ogni attività è associata ad un provider, e l'ordine di precedenza con cui vengono eseguite le attività è definito dai collegamenti tra le attività stesse. Esistono due tipologie di possibili collegamenti tra le attività: data connection o control connection . La prima connette il completamento di un attività con l'esecuzione di un'altra; mentre la seconda rappresenta uno scambio di dati tra due attività. Questa distinzione è una grande potenzialità del linguaggio perchè permette di eseguire un operazione senza scambio di informazioni ma solo al completamento di un'altra attività. E' possibile gestire direttamente il lifecycle delle istanze, intervenendo in fase di esecuzione. Ogni modello di flusso è associato sempre a delle porte che permettono la gestione del lifecycle di un istanza del flow model stesso attraverso specifiche operazioni . Permette per esempio di eseguire un'istanza del modello, sospenderla e poi riprendere l'esecuzione. Un ulteriore possibilità è quella di interrogare l'applicazione per individuarne lo stato (questo rappresenta l'unico modo in cui risulta possibile tracciare il workflow dell'applicazione). Queste porte sono implementate mediante l'utilizzo dello standard WSDL. Ogni istanza è caratterizzata da uno specifico ID (che viene restituito dall'operazione di spawn), il quale permette di applicare operazioni alla particolare istanza che identifica.

Figura 4.2: Porte di accesso al sistema

Il linguaggio non offre la possibilità di tracciare la sequenza di attività svolte all'interno di un istanza. L'unico modo per valutare le prestazioni di un esecuzione è quello di appoggiarsi ad un apposito Web Service adatto a monitorare i vari step del processo.