Windows Workflow Foundation (WF) è parte integrante del .Net Framework 3.0 e gli sviluppatori che utilizzano le tecnologie Microsoft prima o poi dovranno scontrarsi con questa tecnologia che nei prossimi anni farà sempre più parlare di sè.
L'obbiettivo di questo primo Post è quello di inquadrare la problematica che WF si prefigge di risolvere.
Mi piace dividere lo sviluppo delle applicazioni in due ambiti: il primo riguarda le applicazioni "sequenziali", e il secondo quelle "ad oggetti".
Le prime sono caratterizzate da un flusso logico continuo: immaginate di lasciar cadere dall'alto una biglia in una struttura piramidale composta da più piani, dove la cima della piramide corrisponde all'inizio di esecuzione del nostro programma e la base alla fine; la biglia può solo compiere un percorso, che rappresenta la logica della nostra applicazione, dall'alto verso il basso, in un modo ben delineato e facilmente prevedibile. La natura delle applicazioni sequenziali non consente alla "biglia" di tornare, con semplicità, ad un piano precendente.
Le seconde applicazioni "ad oggetti" sono invece caratterizzate da un flusso logico saltellante su oggetti che includono funzionalità precise: immaginate un oggetto che rappresenta una persona, il quale può avere i metodi, mangia, cammina, bevi, corri; il flusso di esecuzione di questi metodi è demandato al client; riprendete in considerazione la biglia, ora introdotta in una scatola contenente un insieme di oggetti-molle che rappresentano la logica applicativa; la biglia può saltare agilmente da una molla all'altra, ma controllare tutte le combinazioni possibili risulta molto laborioso.
WorkFlow Foundation entra in scena in quest'ultimo caso: noi scriviamo la logica applicativa e il flusso di lavoro lo gestiamo con WF.
Chiaramente è una visione semplificata della problematica, però spero renda l'idea.
Il classico esempio di partenza, quando si approccia una nuova tecnologia, è l'applicazione "Hello World", che però analizzeremo in una versione personalizzata, denominata "Apriti sesamo". All'avvio il programma visualizzerà il codice di apertura. In seguito resterà in attesa, anche per intere settimane, dell'input dell'utente, che se digiterà correttamente la sequenza di numeri proposta vedrà la scritta "Hello World!". Immaginiamo di svilupparla con un'applicazione di tipo Console. Il codice è il seguente:
Module ApritiSesamo
Sub Main()
Dim Chiave As String = "123"
Console.WriteLine("La chiave di apertura è: " & Chiave)
Dim str As String = Console.ReadLine
If Chiave.Equals(str) Then Console.WriteLine("Hello world!")
End Sub
End Module
L'esecuzione di questo codice è sequenziale, e il flusso di esecuzione è ben definito. Se invece immaginiamo la medesima applicazione, scritta però con l'ausilio di un WebService, il flusso di lavoro risulterebbe non definito. Il WebService può essere scritto con due metodi: il primo che restituisce la chiave di accesso e il secondo che analizza la chiave immessa. Il webservice di per sè non ha nessuna logica di esecuzione: si può richiamare il metodo di verifica della chiave immessa prima ancora di aver proposto la chiave stessa. Scrivere il webservice adeguatamente, in modo tale che i metodi siano richiamati in ordine corretto, è compito dello sviluppatore. E' dispendioso e difficile da mantenere. WF semplifica l'interazione fra i metodi, come vedremo nel prossimo post.
Concludendo, invito a riflettere sul fatto che oggi la maggior parte delle applicazioni in commercio devono seguire un flusso logico di esecuzione per rispondere alle esigenze degli utenti, e non esiste nessuno strumento di sviluppo che ci consente di approcciare la problematica analizzandone il suo flusso logico.
L'approccio più diffuso è la metodologia orientata all'oggetto che ci consente, attraverso un'attenta analisi del problema, di individuare le entità portanti. A noi è demandato il compito di sviluppare la logica di interazione fra le entità stesse. Oggi WF ci consente di analizzare il problema in modo completamente differente. Quindi non solo semplifica la scrittura del codice, ma offre anche una metodologia alternativa all'analisi del problema.