Introduzione a Microsoft Windows Workflow Foundation: un'anteprima

 

David Chappell
Chappell & Associates

Agosto 2005

Si applica a:
   Microsoft Windows Workflow Foundation
   Microsoft Windows Vista

Riepilogo: Descrive le funzionalità e i vantaggi di Microsoft Windows Workflow Foundation, presto una parte standard della piattaforma Microsoft Windows. Windows Workflow Foundation offre un framework generale per la definizione del flusso di lavoro, uno che può essere usato in molti tipi diversi di applicazioni. (20 pagine stampate)

Nota Questo documento descrive la prima versione beta di Windows Workflow Foundation. Tenere presente che alcune modifiche sono probabilmente prima della versione finale della tecnologia.

Contenuto

Descrizione di Windows Workflow Foundation
Uso di Windows Workflow Foundation
Windows Workflow Foundation e altre tecnologie Microsoft
Conclusione

Descrizione di Windows Workflow Foundation

Praticamente tutto il software usato nelle aziende oggi ha lo stesso obiettivo: supportare i processi aziendali. Alcuni processi sono completamente automatizzati, basandosi esclusivamente sulla comunicazione tra le applicazioni. Altri, probabilmente la maggioranza, si affidano anche alle persone per avviare il processo, approvare i documenti usati dal processo, risolvere eventuali situazioni eccezionali che si verificano e altro ancora. In entrambi i casi, spesso è possibile specificare una serie discreta di passaggi noti come flusso di lavoro che descrive le attività delle persone e del software coinvolte nel processo. Dopo aver definito questo flusso di lavoro, è possibile creare un'applicazione intorno a tale definizione per supportare il processo aziendale.

La creazione e l'esecuzione di un flusso di lavoro nel software comporta sfide uniche. Alcuni processi aziendali possono richiedere ore, giorni o settimane per essere completati, ad esempio. In che modo uno sviluppatore può mantenere le informazioni sullo stato corrente del flusso di lavoro per questo periodo di tempo? Questo tipo di flusso di lavoro a esecuzione prolungata comunicherà in genere anche con altri software in modo non bloccatore. In che modo le sfide della comunicazione asincrona possono essere semplificate per gli sviluppatori? Mentre la modellazione delle interazioni fisse tra software è relativamente semplice, le persone tendono a volere una maggiore flessibilità, tra cui la possibilità di modificare un processo aziendale in tempo reale. In che modo il flusso di lavoro può gestire il comportamento diversificato e imprevedibile degli esseri umani? Senza la giusta base da costruire, soddisfare i requisiti come questi è difficile. Tuttavia, se la tecnologia progettata in modo esplicito per supportare i flussi di lavoro è disponibile, la creazione di questo tipo di software utile può essere semplice.

Microsoft Windows Workflow Foundation è stato creato per soddisfare questi requisiti. Un componente di base di Microsoft .NET Framework 3.0, sarà una parte fondamentale della piattaforma Windows per gli sviluppatori. Windows Workflow Foundation offre un framework comune per la creazione di flussi di lavoro in applicazioni Microsoft Windows, indipendentemente dal fatto che tali flussi di lavoro coordinano le interazioni tra software, interazioni tra persone o entrambi. Prevista per il rilascio a metà del 2006, Windows Workflow Foundation verrà eseguito nelle prossime versioni di Microsoft Windows Vista e sarà disponibile anche per Microsoft Windows XP e Microsoft Windows Server 2003.

Quali applicazioni flusso di lavoro richiedono

Per avere un'idea di ciò che è necessario da un framework del flusso di lavoro come Windows Workflow Foundation, è utile considerare diversi tipi di applicazioni che potrebbero usare flussi di lavoro. Di seguito sono riportati alcuni esempi:

• Un'applicazione microsoft ASP.NET che visualizza le pagine agli utenti potrebbe usare un flusso di lavoro per controllare l'ordine in cui vengono visualizzate tali pagine. In questo modo è possibile modificare più facilmente il flusso di pagina senza modificare le pagine stesse, nonché separare in modo pulito l'interfaccia utente dell'applicazione dalla logica di controllo.
• Un'applicazione composita in un ambiente orientato ai servizi potrebbe implementare il comportamento principale usando un flusso di lavoro. Man mano che sempre più applicazioni espongono la logica tramite i servizi Web, la creazione di processi aziendali basati su tali servizi diventa più semplice. Una tecnologia del flusso di lavoro, ad esempio Windows Workflow Foundation, fornisce una base per la logica che richiamerà tali servizi, lavorandoli insieme in un'applicazione composita.
• Un'applicazione destinata a un problema specifico, ad esempio crm (Customer Relationship Management) o un mercato verticale specifico, ad esempio i servizi finanziari, potrebbe essere basato su un flusso di lavoro. Questo tipo di applicazione implementa in genere diversi processi aziendali. La creazione della logica che guida tali processi in una base comune del flusso di lavoro, ad esempio Windows Workflow Foundation, può rendere l'applicazione più veloce da compilare, velocizzare la modifica e semplificare la personalizzazione.

Per comprendere meglio i requisiti che un framework del flusso di lavoro deve soddisfare, vale la pena esaminare un'applicazione del flusso di lavoro di esempio in modo più dettagliato. Si supponga che un fornitore di software indipendente (ISV) desideri creare un'applicazione basata sul flusso di lavoro per le compagnie assicurative. La figura 1 illustra un semplice esempio di come potrebbe apparire un'applicazione per la richiesta di un criterio assicurativo automobilistico, uno dei processi aziendali supportati da questo prodotto.

Figura 1. Semplice applicazione basata sul flusso di lavoro per le compagnie assicurative

Il processo inizia quando un mittente invia in un'applicazione. Questo richiedente potrebbe essere un dipendente in un call center, un agente assicurativo nel campo o anche un cliente che invia direttamente un'applicazione tramite Internet. Tuttavia, l'arrivo di una nuova applicazione crea una nuova istanza del flusso di lavoro. Il flusso di lavoro inizia controllando le informazioni fornite nella richiesta in base alle regole di questa società per l'emissione dei criteri. Se il richiedente non soddisfa i criteri di sottoscrizione dell'azienda, viene rifiutato. In caso contrario, il flusso di lavoro richiede la cronologia del credito del richiedente da un servizio di credito esterno. Un punteggio di credito soddisfacente comporta l'accettazione immediata, ma i candidati ad alto rischio con cronologie di credito non valido richiedono l'approvazione di un manager. Se l'approvazione viene concessa, il richiedente viene accettato. In caso contrario, il richiedente viene rifiutato.

Questo semplice esempio illustra molti dei requisiti presentati da un'applicazione tipica basata sul flusso di lavoro. Questi requisiti includono:

• Possibilità di prendere decisioni in base alle regole business. Sono incluse regole semplici, ad esempio una decisione di tipo sì o no in base al risultato di un assegno di credito e regole più complesse, ad esempio il set potenzialmente grande che deve essere valutato per prendere una decisione iniziale di sottoscrizione.
• Modalità di comunicazione con altri software e altri sistemi esterni al flusso di lavoro. In questo esempio, la richiesta iniziale viene ricevuta da un'altra parte dell'applicazione, mentre alcuni aspetti, ad esempio contattare il servizio di credito, richiedono la comunicazione tramite servizi Web o altre tecnologie.
• Modi per interagire con le persone. In questo caso, un responsabile deve approvare alcuni candidati e quindi il flusso di lavoro deve essere in grado di visualizzare un'interfaccia utente stessa o interagire con gli esseri umani tramite altri software.
• Possibilità di mantenere lo stato per tutta la durata del flusso di lavoro. Soprattutto quando le persone sono coinvolte, come con il manager in questo esempio, il completamento di un flusso di lavoro può richiedere molto tempo. (Cosa succede se il manager è rimasto per il giorno, o è in vacanza di due settimane?) La creazione di sistemi scalabili richiede un modo per disattivare il flusso di lavoro e archiviarne lo stato in modo permanente, quindi riattivarlo e caricarlo quando è possibile eseguire il passaggio successivo.

Tutti questi sono requisiti fondamentali per i flussi di lavoro. La maggior parte di esse è anche difficile da eseguire senza creare software progettato in modo esplicito per supportare i flussi di lavoro.

Anche un framework del flusso di lavoro può offrire più di questo. Potrebbe, ad esempio, offrire elementi come:

• Approccio simile a un componente per i flussi di lavoro, in cui ogni passaggio può essere implementato da un blocco specifico di software. Analogamente ad altre tecnologie dei componenti, è possibile specificare in modo dichiarativo i comportamenti per questi passaggi, ad esempio le transazioni, anziché scrivere codice per implementare tali comportamenti. Potrebbe anche essere possibile creare passaggi predefiniti per i flussi di lavoro utili in un particolare dominio, ad esempio applicazioni assicurative o gestione dei sistemi, e quindi usarli in molti flussi di lavoro diversi.
• Strumenti per creare e modificare i flussi di lavoro graficamente. Poiché un flusso di lavoro è costituito da un numero definito di passaggi, può essere compilato usando strumenti che illustrano tali passaggi e le relazioni tra di essi.
• Possibilità di monitorare un flusso di lavoro in esecuzione, esaminandone l'esecuzione in tempo reale.
• Un modo per modificare un'istanza del flusso di lavoro in esecuzione, ad esempio aggiungendo un passaggio. Anche se questo non è in genere necessario quando è coinvolto solo il software, questo tipo di flessibilità è un requisito comune per i flussi di lavoro che interagiscono con le persone.

Il flusso di lavoro è una tecnologia distinta, una con i propri vantaggi e requisiti unici. Anche se questo approccio viene applicato oggi in diverse aree diverse, una base disponibile a livello generale per la creazione di flussi di lavoro potrebbe renderlo ancora più diffuso. E l'ascesa di un mondo orientato ai servizi, guidato dall'accordo globale del fornitore sui servizi Web, è tutto, ma certo di dare questo approccio un ruolo più centrale.

La tecnologia del flusso di lavoro è stata in attesa nelle ali dello sviluppo di software mainstream, un giocatore di supporto ma mai un star. Le probabilità sono buone che questo sta per cambiare.

Elementi forniti da Windows Workflow Foundation

Come base generale per i flussi di lavoro, Windows Workflow Foundation è destinato a diversi obiettivi. Tre si distinguono, tuttavia, come più importanti: fornire una tecnologia di flusso di lavoro comune per Windows, offrendo un framework del flusso di lavoro per applicazioni diverse e unificando il sistema e il flusso di lavoro umano. Questa sezione esamina ognuna di queste.

Una tecnologia di flusso di lavoro comune per Windows

Indipendentemente dal fatto che vengano creati da Microsoft o da altri utenti, molte applicazioni Windows includono un certo tipo di supporto del flusso di lavoro. Esaminando solo i prodotti Microsoft, la tecnologia del flusso di lavoro è attualmente disponibile in Microsoft BizTalk Server, Microsoft Exchange Server e altri. Questo uso generale illustra certamente come può essere utile il flusso di lavoro, ma la presenza di più tecnologie del flusso di lavoro per Windows non ha molto senso. Analogamente ad altre tecnologie di sviluppo mainstream, il supporto del flusso di lavoro deve far parte della piattaforma Windows stessa.

Questo è esattamente ciò che Windows Workflow Foundation offre. Implementando il flusso di lavoro come parte di Microsoft .NET Framework 3.0, questo approccio alla creazione di software sarà disponibile per qualsiasi applicazione Windows necessaria. Sono incluse applicazioni in esecuzione su client o su server, nonché applicazioni create dagli utenti finali, dai fornitori di software indipendenti (ISV) e da Microsoft stesso. Anche se sarà necessario qualche tempo, Windows Workflow Foundation diventerà la base comune per il flusso di lavoro nei prodotti e nelle tecnologie Microsoft. Un esempio principale di questo è la prossima versione di Microsoft Windows SharePoint Services (WSS), che fornirà servizi di flusso di lavoro basati su Windows Workflow Foundation e la prossima versione delle tecnologie server da Microsoft Office System, che fornirà una varietà di soluzioni basate su tali servizi. Le versioni future di altri prodotti Microsoft, tra cui BizTalk Server e Microsoft Business Solutions, implementeranno anche i propri servizi di flusso di lavoro usando Windows Workflow Foundation. E poiché tutte queste applicazioni useranno la stessa tecnologia del flusso di lavoro, l'avvento di Windows Workflow Foundation dovrebbe semplificare l'implementazione di processi aziendali che si basano su più applicazioni Windows.

È importante comprendere che Windows Workflow Foundation è un framework destinato agli sviluppatori, non un'applicazione del flusso di lavoro destinata all'uso immediato da parte degli utenti finali. Di conseguenza, non fornisce strumenti per i lavoratori informativi per interagire con i flussi di lavoro (anche se la prossima versione di Microsoft Office, denominata Office "12", include strumenti per l'uso dei flussi di lavoro di Windows Workflow Foundation distribuiti nei siti di SharePoint, come descritto più avanti in questo documento). Windows Workflow Foundation non include anche strumenti di gestione e monitoraggio completi, anche se espone le informazioni necessarie per crearle. Lo scopo di Windows Workflow Foundation non è una soluzione completa del flusso di lavoro per Windows. L'obiettivo è invece semplificare la creazione di applicazioni Windows basate sul flusso di lavoro da parte degli sviluppatori software.

Framework del flusso di lavoro per applicazioni diverse

La creazione di una tecnologia di flusso di lavoro comune per Windows genera un problema ovvio e impegnativo: dato i diversi modi in cui le applicazioni Windows usano la tecnologia del flusso di lavoro, come è possibile risolvere correttamente tutte le soluzioni? I prodotti del flusso di lavoro tradizionali, che in genere implementano un unico linguaggio per esprimere i flussi di lavoro e un unico strumento grafico per definirli, non sono abbastanza generali per soddisfare questa ampia necessità. È necessario un altro approccio.

Anziché offrire una singola lingua e un singolo strumento, Windows Workflow Foundation fornisce invece un framework generale per la creazione e l'esecuzione di flussi di lavoro. In Windows Workflow Foundation un flusso di lavoro è costituito da un gruppo di attività, come illustrato nella figura 2, ognuna delle quali esegue un'azione nel flusso di lavoro.

Figura 2. Relazione di un flusso di lavoro a attività in Windows Workflow Foundation

Windows Workflow Foundation viene fornito con un set di attività di utilizzo generico per la definizione dei flussi di lavoro. Questa libreria di attività di base offre la possibilità di definire i flussi di controllo usando costrutti familiari, ad esempio IF/ELSE e i cicli WHILE. Include anche un motore regole, il supporto per la comunicazione con altri software usando servizi Web e altro ancora.

Tuttavia, anche se queste attività predefinite offrono una buona quantità di funzionalità del flusso di lavoro, gli sviluppatori sono liberi di implementare attività personalizzate incentrate su uno spazio di problemi specifico. In effetti, le attività forniscono un modello di componente molto simile a quello per i flussi di lavoro. I server "12" di Microsoft Office, ad esempio, forniscono un set di attività destinate alla creazione di flussi di lavoro orientati ai documenti. Altre applicazioni, indipendentemente dal fatto che siano compilate da Microsoft o da altri utenti, possano creare gruppi di attività personali. Un'applicazione del flusso di lavoro che supporta un processo di approvazione può includere attività come RequestApproval, Approva e Rifiuta, ad esempio, mentre una è incentrata sulle applicazioni sanitarie potrebbe fornire un set completamente diverso. I flussi di lavoro possono combinare attività personalizzate con quelle nella libreria attività di base, poiché le attività personalizzate usano le stesse interfacce pubbliche delle attività che vengono fornite con Windows Workflow Foundation. I creatori di attività personalizzate sono anche liberi di ignorare completamente la libreria di attività di base di Windows Workflow Foundation, senza alcun requisito di compilarli. L'obiettivo è consentire a un gruppo più ampio di sviluppatori di creare flussi di lavoro che usano attività specifiche del dominio create da un numero minore di sviluppatori più tecnici.

I flussi di lavoro di Windows Workflow Foundation possono essere scritti direttamente nel codice. I flussi di lavoro possono essere definiti graficamente, con il codice aggiunto se necessario. Per rendere possibile questa operazione, Windows Workflow Foundation fornisce il flusso di lavoro Designer, uno strumento che consente agli sviluppatori di creare e modificare i flussi di lavoro. Come illustrato nella figura seguente, il flusso di lavoro Designer può essere ospitato in Microsoft Visual Studio 2005. La casella degli strumenti a sinistra contiene icone per la libreria attività di base, che può essere trascinata e eliminata nell'area di progettazione per creare un flusso di lavoro. Ogni attività include proprietà ed eventi che possono essere impostati da uno sviluppatore in Visual Studio.

Figura 3. Flusso di lavoro Designer ospitato in Visual Studio 2005

Il flusso di lavoro Designer può essere ospitato anche in e personalizzato per altri ambienti. Un ISV che desidera includere il flusso di lavoro all'interno della propria offerta potrebbe ospitare questo strumento direttamente all'interno di tale prodotto, dandogli qualsiasi aspetto e sensazione sia appropriato. Analogamente, un'organizzazione che desiderava fornire un modo per i lavoratori delle informazioni di creare e modificare i flussi di lavoro potrebbe ospitare il flusso di lavoro Designer all'interno di un ambiente più aziendale rispetto a Visual Studio. Gli ISV sono anche liberi di creare altri strumenti di progettazione grafica per l'uso dei flussi di lavoro di Windows Workflow Foundation, usando l'Designer flusso di lavoro non è necessario.

Un'altra sfida per fornire una base generale del flusso di lavoro per Windows riguarda l'hosting: Quale tipo di applicazione deve essere in grado di eseguire un flusso di lavoro? La risposta fornita da Windows Workflow Foundation consiste nel consentire al motore di runtime che fornisce l'esecuzione di flussi di lavoro in praticamente in qualsiasi processo di Windows, a partire da semplici applicazioni console o Microsoft Windows Forms, fino a software server complessi di grandi dimensioni scritti all'interno di un'organizzazione o forniti da un ISV. La finalità consiste nell'consentire a Windows Workflow Foundation di essere usata in un ampio spettro di applicazioni.

Un obiettivo principale dei creatori di Windows Workflow Foundation è quello di promuovere un ecosistema intorno a questo framework del flusso di lavoro. Attività specializzate incentrate su domini di problema distinti, ambienti personalizzati che ospitano l'Designer flusso di lavoro e ambienti di hosting univoci per il runtime di Windows Workflow Foundation possono essere tutti creati per soddisfare requisiti specifici. Ma indipendentemente dal modo in cui viene usata Windows Workflow Foundation, il modello di programmazione principale e il motore di runtime rimangono invariati e il comportamento dello strumento di sviluppo grafico sarà simile. Sebbene l'esperienza utente di Windows Workflow Foundation diventi piuttosto diversificata nel tempo, la base su cui questa esperienza viene compilata rimarrà comune.

Sistema unificato e flusso di lavoro umano

Anche se i processi aziendali in genere coinvolgono sia persone che applicazioni, l'automazione delle interazioni tra software è piuttosto diversa dall'automazione delle interazioni tra le persone. Di conseguenza, le tecnologie del flusso di lavoro hanno in genere sottolineato uno o l'altro. Uno degli obiettivi principali di Windows Workflow Foundation è quello di terminare questa dicotomia fornendo una soluzione unificata che risolve entrambi i problemi.

Nota Il termine orchestrazione è spesso stato usato per fare riferimento al coordinamento del lavoro svolto puramente dal software, mentre il flusso di lavoro implica in genere che le persone sono coinvolte. Poiché i processi aziendali oggi coinvolgono sia software che persone, è consigliabile usare il flusso di lavoro nome più generale per fare riferimento all'intelligenza che coordina l'interazione di entrambi.

Per vedere perché si tratta di una sfida, considerare le caratteristiche tipiche delle interazioni automatizzate tra le applicazioni. Talvolta noto come flusso di lavoro di sistema , le interazioni dell'applicazione sono in genere prevedibili e relativamente statiche. La logica che indirizza questa interazione può essere definita una sola volta e quindi usata oltre e oltre senza modifiche. I flussi di lavoro di sistema scambiano anche dati strutturati, ben definiti, come documenti XML, che possono essere elaborati in modo efficace dal software senza intervento umano.

Contrasto con il flusso di lavoro umano , che coordina le interazioni tra le persone. Le applicazioni che interagiscono per conto delle persone tendono a richiedere molto più flessibilità rispetto a quelle che interagiscono puramente con altri software. Persone modificare le proprie menti, introdurre nuove idee ed eccezioni, decidere di annullare un processo in modo imprevisto e fare altre operazioni che rendono i flussi di lavoro umani efficaci significativamente più dinamici rispetto ai flussi di lavoro di sistema. Di conseguenza, il software che supporta i flussi di lavoro umani deve consentire un approccio più flessibile basato su eventi. I flussi di lavoro umani funzionano anche con dati meno strutturati e leggibili, ad esempio messaggi di posta elettronica e documenti di testo, anziché le informazioni strutturate usate nei flussi di lavoro di sistema.

Dato i diversi requisiti di questi due tipi di flusso di lavoro, non è sorprendente che l'indirizzamento sia in una singola tecnologia sia stato impegnativo. Windows Workflow Foundation è ancora incentrato in modo esplicito sull'indirizzamento di entrambi i tipi di flusso di lavoro in modo unificato. A tale scopo, fornisce approcci sequenziali e basati su eventi per definire i flussi di lavoro, la possibilità di aggiungere passaggi a o in caso contrario modificare, un flusso di lavoro in esecuzione e altre cose, tutte descritte più avanti in questo documento.

Uso di Windows Workflow Foundation

La figura 4 illustra i componenti fondamentali di Windows Workflow Foundation.

Figura 4. Componenti di Windows Workflow Foundation

Questi componenti sono:

• Attività: unità di lavoro. Il lavoro implementato da un'attività può variare da molto semplice a piuttosto complesso.
• Flusso di lavoro: un gruppo di attività che implementa tutto o parte di un processo aziendale.
• Finestre di progettazione di Windows Workflow Foundation: strumenti grafici che possono essere usati per creare e modificare flussi di lavoro e attività.
• Libreria attività di base di Windows Workflow Foundation: un gruppo fondamentale di attività che gli sviluppatori possono usare per creare flussi di lavoro.
• Motore di runtime di Windows Workflow Foundation: libreria che esegue flussi di lavoro. Il motore di runtime fornisce anche altri servizi, ad esempio meccanismi per comunicare con software all'esterno del flusso di lavoro.
• Processo host: un'applicazione Windows che ospita il motore di runtime di Windows Workflow Foundation e tutti i flussi di lavoro eseguiti. Il processo host fornisce il supporto dei servizi di runtime per rendere persistente lo stato di un flusso di lavoro, la gestione delle transazioni e altre funzioni.

Informazioni su Windows Workflow Foundation richiede una presa su tutti questi componenti. La posizione da avviare, tuttavia, è con il motivo per cui esiste tutto il resto: flussi di lavoro.

Informazioni sui flussi di lavoro

Ogni flusso di lavoro di Windows Workflow Foundation contiene un certo numero di attività, ognuna delle quali esegue alcuni aspetti della funzione del flusso di lavoro. Il flusso di lavoro funge da contenitore per queste attività, fornendo un modo per controllare i relativi cicli di vita e l'ordine di esecuzione. Windows Workflow Foundation aspira a supportare i flussi di lavoro di sistema e i flussi di lavoro umani in modo unificato, che presenta una sfida. Come descritto in precedenza, i flussi di lavoro di sistema tendono a eseguire attività in modi ben definiti e prevedibili, mentre i flussi di lavoro umani non sono. Per soddisfare entrambi questi requisiti, Windows Workflow Foundation offre due tipi di flusso di lavoro predefiniti: flussi di lavoro sequenziali , in grado di eseguire attività in un modello pre-definito e flussi di lavoro del computer di stato , in grado di rispondere agli eventi esterni durante la loro esecuzione. Entrambi si basano sullo stesso ambiente di runtime e entrambi possono usare le stesse attività personalizzate. L'approccio sequenziale è un approccio naturale per il flusso di lavoro di sistema, mentre le macchine statali offrono un modo per modellare la natura più liberamente definita del flusso di lavoro umano. Un singolo flusso di lavoro può combinare elementi di entrambi gli stili, consentendo una combinazione dei due. Se necessario, uno sviluppatore può anche creare tipi di flusso di lavoro personalizzati, ma la maggior parte delle applicazioni di Windows Workflow Foundation userà una di queste due opzioni standard. Questa sezione descrive entrambi, a partire da flussi di lavoro sequenziali.

Uso di flussi di lavoro sequenziali

La figura 5 illustra un semplice flusso di lavoro sequenziale creato usando il flusso di lavoro di Windows Workflow Foundation Designer. I flussi di lavoro sequenziali sono destinati alle applicazioni in cui le attività del flusso di lavoro vengono eseguite in un certo tipo di sequenza. Questa sequenza può includere cicli, rami e altri tipi di flusso di controllo, ma il flusso di lavoro ha comunque un percorso definito dall'inizio alla fine.

Figura 5. Flusso di lavoro sequenziale semplice

La libreria di attività di base fornita con Windows Workflow Foundation contiene un gruppo di attività che possono essere usate nei flussi di lavoro sequenziali. Tali attività includono:

• IfElse: esegue le attività contenute in due o più percorsi possibili, a seconda che venga soddisfatta una condizione.
• Mentre: esegue ripetutamente una o più attività purché una condizione sia true.
• Sequenza: esegue un gruppo di attività una alla volta, in un ordine definito.
• Parallel: esegue due o più sequenze di attività in parallelo, in attesa del completamento di tutte le sequenze prima di continuare.
• Codice: esegue un blocco di codice definito.
• Listen: attende un evento specifico e quindi esegue una o più attività quando l'evento viene ricevuto.
• Ritardo: sospende l'esecuzione di un flusso di lavoro per un periodo di tempo specificato.
• InvokeMethod: chiama un metodo in un oggetto che si trova in questa applicazione, ma all'esterno del flusso di lavoro.
• EventSink: attende una chiamata da un altro metodo presente in questa applicazione, ma all'esterno del flusso di lavoro.
• InvokeWorkflow: determina l'avvio dell'esecuzione di un altro flusso di lavoro.
• InvokeWebService: chiama un servizio Web.
• Terminate: termina l'esecuzione di un flusso di lavoro.

Un requisito comune del flusso di lavoro consiste nel raggruppare le attività e quindi definire alcune azioni che devono essere eseguite nell'intero gruppo. Un esempio di questo è costituito dalle transazioni, in cui tutte le operazioni eseguite dalle attività raggruppate devono avere esito positivo o completamente negativo. A tale scopo, la libreria di attività di base include un'attività TransactionalContext che può contenere altre attività. È possibile impostare un contesto di transazione per richiedere una transazione atomica , che esegue il wrapping di tutto il lavoro in questo contesto all'interno di una transazione ACID tradizionale. È anche possibile impostare un contesto per richiedere una transazione nota come transazione a esecuzione prolungata . Diversamente da una transazione ACID, una transazione a esecuzione prolungata non presuppone che tutti i dati modificati all'interno siano bloccati per la durata della transazione. Dato che i flussi di lavoro spesso coordinano processi aziendali a esecuzione prolungata, questo ha senso. Ad esempio, bloccare l'account di controllo per una settimana in attesa dell'approvazione di un gestore di ferie di un trasferimento di fondi non è un'interessante prospettiva. Poiché tutti i dati di una transazione a esecuzione prolungata non sono bloccati contemporaneamente, in genere non è possibile eseguire il rollback atomico di tutte le modifiche apportate all'interno di questa transazione. Viene invece usato un qualche tipo di compensazione che tenta di annullare il lavoro già completato. A tale scopo, un'attività TransactionalContext può contenere attività di compensazione che vengono eseguite in caso di errore di una transazione a esecuzione prolungata.

Chiunque abbia esperienza in questa area potrebbe aver notato che molte delle attività predefinite usate in un flusso di lavoro sequenziale sono simili alle istruzioni in un linguaggio convenzionale di flusso di lavoro/orchestrazione, ad esempio il linguaggio BPEL (Business Process Execution Language). Originariamente definito da Microsoft e IBM, BPEL è ora in fase di standardizzazione da parte dell'organizzazione per l'avanzamento degli standard di informazioni strutturate (OASIS). BPEL è un linguaggio per la definizione dei flussi di lavoro di sistema, che è un subset dell'approccio più generale adottato da Windows Workflow Foundation. Per gli sviluppatori che vogliono usare BPEL, Windows Workflow Foundation include una libreria di attività BPEL che implementa i costrutti definiti dalla versione 1.1 della specifica BPEL. Usando questa libreria, è possibile creare flussi di lavoro che possono essere esportati in BPEL o importare una definizione BPEL in Windows Workflow Foundation.

Uso dei flussi di lavoro della macchina a stati

A differenza di un flusso di lavoro sequenziale, che struttura le attività in un modello predefinito, un flusso di lavoro della macchina a stati organizza le attività in una macchina a stati finiti. La figura 6 mostra un flusso di lavoro semplice della macchina a stati creato usando il flusso di lavoro Windows Workflow Foundation Designer. Come suggerisce questa figura, lo sviluppatore definisce un gruppo di stati ed eventi, che attivano transizioni tra questi stati.

Figura 6. Flusso di lavoro della macchina a stati semplice

Organizzare le attività di un flusso di lavoro come questo è utile quando la sequenza esatta di eventi non è nota in anticipo, ad esempio per i processi aziendali basati su eventi o quando il numero di possibilità rende poco pratica la definizione di tutti i percorsi possibili. Un esempio principale di questo è un flusso di lavoro che coordina il lavoro delle persone anziché solo le applicazioni. I flussi di lavoro delle macchine a stati rendono più semplice ignorare i passaggi in tempo reale (ad esempio, un controllo del credito può essere ignorato per un cliente valido), passare a qualsiasi passaggio del processo aziendale (ad esempio, una richiesta ad alta priorità deve essere gestita al momento) o annullare il processo aziendale in qualsiasi momento (se, ad esempio, il cliente annulla la parte dell'ordine). Le macchine a stati possono anche fornire un modo per definire flussi di lavoro che corrispondano al modo in cui alcune organizzazioni pensano e documentano i processi aziendali. In questi casi, la modellazione dei flussi di lavoro in questo modo può aiutare gli sviluppatori e le persone aziendali a lavorare insieme in modo più efficace.

La libreria di attività di base include attività progettate in modo esplicito per la creazione di flussi di lavoro delle macchine a stati. ovvero:

• State: rappresenta uno stato nella macchina a stati di un flusso di lavoro.
• EventDriven: definisce una transizione contenente una o più attività che devono essere eseguite quando viene ricevuto un evento specifico in uno stato specifico.
• SetState: modifica lo stato della macchina a stati del flusso di lavoro. Una transizione potrebbe o non modificare lo stato del flusso di lavoro.
• StateInitialization: definisce una o più attività che devono essere eseguite per impostazione predefinita ogni volta che viene immesso uno stato specifico.

Anche se non è illustrato nell'esempio precedente, è anche possibile annidare gli stati. Un evento definito in uno stato esterno si applica sia a tale stato che a tutti gli stati in esso contenuti. In questo modo è possibile esprimere gli eventi che possono verificarsi in qualsiasi momento in uno di questi stati, ad esempio l'annullamento di un ordine.

Poiché un flusso di lavoro della macchina a stati può anche usare le attività descritte in precedenza per i flussi di lavoro sequenziali, le azioni eseguite all'interno di ogni transizione possono contenere sequenze di attività e altre logiche. Questa combinazione dei due stili di flusso di lavoro predefiniti di Windows Workflow Foundation offre un modo più unificato per soddisfare i diversi stili necessari per i flussi di lavoro umani e i flussi di lavoro di sistema.

Creazione e modifica di flussi di lavoro

Il modo più semplice per creare e modificare un flusso di lavoro di Windows Workflow Foundation consiste nell'usare il flusso di lavoro Designer. Come illustrato in precedenza, l'host predefinito del Designer è Visual Studio 2005, dove aggiunge modelli di progetto per la creazione di un flusso di lavoro sequenziale, un flusso di lavoro della macchina a stati e altro ancora. Trascinando e rilasciando varie attività nell'area di progettazione e impostandone le proprietà, gli sviluppatori possono creare nuovi flussi di lavoro e modificarne quelli esistenti. L'approccio è simile a Windows Forms, in cui uno sviluppatore rilascia i controlli in un modulo per creare un'interfaccia utente grafica. Con il flusso di lavoro Designer, le attività vengono eliminate in un flusso di lavoro per creare la logica di business. In entrambi i casi, l'obiettivo è lo stesso: maggiore produttività degli sviluppatori.

Il flusso di lavoro Designer supporta lo sviluppo solo in Microsoft C# e Microsoft Visual Basic. Uno sviluppatore che vuole usare i servizi di Windows Workflow Foundation, ma preferisce lavorare direttamente nel codice è libero di farlo, usando l'Designer del flusso di lavoro non è necessario. In questo caso, uno sviluppatore può usare qualsiasi linguaggio conforme alla specifica common language di Microsoft .NET Framework, tra cui C#, Visual Basic, Microsoft C++e altri.

Sotto le quinte, un flusso di lavoro è davvero solo una classe. Tre spazi dei nomi, System.Workflow.Activities, System.Workflow.ComponentModel e System.Workflow.Runtime, forniscono i tipi necessari per creare ed eseguire flussi di lavoro e le attività che contengono. Per creare un nuovo flusso di lavoro sequenziale, ad esempio, uno sviluppatore C# può usare uno scheletro come il seguente.

using System.Workflow.Activities;
public class ExampleWorkflow : SequentialWorkflow
{
    ...
}

Quando viene creata una nuova istanza di una classe del flusso di lavoro, il relativo costruttore crea e configura le attività in tale flusso di lavoro, in modo analogo al costruttore di un modulo definito utilizzando Windows Forms inizializza i controlli contenuti nel form.

I flussi di lavoro possono essere definiti anche tramite XML. Lo scheletro di base per una classe del flusso di lavoro è il seguente.

<?Mapping XmlNamespace="Activities"
   ClrNamespace="System.Workflow.Activities"
   Assembly="System.Workflow.Activities" ?>
<SequentialWorkflow x:Class="ExampleWorkflow" 
   xmlns="Activities" xmlns:x="Definition">
    ...
</SequentialWorkflow>

L'istruzione di elaborazione mapping che inizia questo semplice esempio è analoga all'istruzione using che inizia l'esempio di codice, poiché entrambi specificano uno spazio dei nomi che verrà usato. L'elemento SequentialWorkflow definisce quindi una classe denominata ExampleWorkflow che usa questo spazio dei nomi.

Perché fornire questa opzione basata su markup per la definizione dei flussi di lavoro? Uno dei motivi è che alcuni sviluppatori preferiscono lavorare in questo stile, almeno per determinati tipi di applicazioni. Un altro motivo è che molti generatori di strumenti trovano più facile creare strumenti che generano e analizzano XML anziché generare e analizzare codice. In realtà, flusso di lavoro di Windows Workflow Foundation Designer genera XML, in modo che gli sviluppatori possano sempre visualizzare la versione XML dei flussi di lavoro creati con questo strumento. Un flusso di lavoro può essere compilato da qualsiasi combinazione di flusso di lavoro Designer output, codice scritto dallo sviluppatore e XML e, tuttavia, viene creato, viene compilato in un assembly .NET standard.

Creazione di attività

Le attività sono i blocchi predefiniti dei flussi di lavoro. Un'attività può essere ridotta e tecnicamente mirata, ad esempio Delay e Terminate nella libreria di attività di base, oppure può essere più grande e più focalizzata sull'azienda, ad esempio un'attività ProcessHelpDeskRequest che potrebbe essere definita da un ISV basato su Windows Workflow Foundation. Indipendentemente dal fatto che sia semplice o complesso, creato da Microsoft o da altri utenti, ogni attività si basa sullo stesso set di interfacce di Windows Workflow Foundation.

Una nuova attività può essere compilata da zero oppure può estendere un'attività esistente. È anche possibile creare una nuova attività che raggruppa le attività esistenti per formare un'attività composita . Molte delle attività nella libreria di attività di base, ad esempio IfElse, Sequence e While, sono in realtà attività composite. Infatti, un flusso di lavoro stesso è solo un tipo speciale di attività composita.

Il modo più semplice per creare un'attività consiste nell'usare lo strumento grafico Activity Designer. Le attività possono anche essere create direttamente nel codice, poiché, come un flusso di lavoro, un'attività è solo una classe. Ogni attività può avere eventi a cui risponde e le proprietà contenenti lo stato e la relativa definizione C# ha un aspetto simile al seguente.

using System.Workflow.ComponentModel;
public class ExampleActivity : Activity
{
  ...
}

Tuttavia, viene compilato, l'autore di un'attività può controllare la quantità di elementi interni visibili ad altri sviluppatori che usano tale attività. In questo modo è possibile controllare la visibilità delle informazioni proprietarie. Gli autori di attività possono anche definire temi personalizzati che determinano l'aspetto delle attività, inclusa la relativa rappresentazione grafica nel flusso di lavoro Designer. In questo modo gli ISV possono semplificare la compilazione di Windows Workflow Foundation nelle applicazioni mantenendo comunque lo stile del proprio prodotto.

Utilizzo di condizioni e regole

I processi aziendali dipendono dalle regole dell'azienda che le usa. Forse un'organizzazione consente ai responsabili degli acquisti di approvare le PO solo fino a 50 mila euro, ad esempio, e offre ai clienti oltre 55 uno sconto del 10%; o forse gli hotel dipendenti rimangono in non possono costare più di $ 250 a notte. Queste semplici istruzioni sono espressioni di regole business. La gestione delle regole business è una parte importante della creazione di un flusso di lavoro, quindi Windows Workflow Foundation offre diversi approcci a questo problema.

Definizione di condizioni semplici

In un flusso di lavoro tipico, ogni condizione in un'attività IfElse o While è in realtà una regola business. Windows Workflow Foundation offre due opzioni per definire queste condizioni. Una scelta consiste nell'esprimere la condizione direttamente nel codice, creando una condizione di codice. A tale scopo, lo sviluppatore scrive un metodo che valuta i dati pertinenti e restituisce un valore booleano. Quando la condizione deve essere valutata, questo metodo viene chiamato e viene usato il risultato restituito.

L'altra opzione consiste nel definire una condizione della regola, direttamente nel codice o usando uno strumento denominato Editor condizione regola. Le condizioni delle regole vengono archiviate in un formato XML in un file separato. Quando un flusso di lavoro raggiunge una condizione della regola, l'espressione della condizione viene valutata e viene restituito un valore booleano. A differenza delle condizioni di codice, le condizioni delle regole possono essere modificate in tempo reale per un flusso di lavoro in esecuzione. La stessa condizione della regola può essere usata anche da più attività nello stesso flusso di lavoro, consentendo l'espressione della regola business (e quindi mantenuta) in un'unica posizione.

Raggruppamento di condizioni e attività: attività CAG

Attività come IfElse e While offrono un modo semplice per controllare le attività eseguite da un flusso di lavoro. Per scenari più dinamici, ad esempio flussi di lavoro che coinvolgono persone, l'attività del gruppo di attività condizionale di Windows Workflow Foundation può essere utile. Un'attività CAG contiene altre attività, ognuna delle quali è associata a ciò che è noto come condizione when. Ogni condizione quando può essere specificata usando una condizione di codice o una condizione della regola. Quando viene rilevata un'attività CAG in un flusso di lavoro, tutte le relative condizioni vengono valutate. Ogni condizione quando restituisce true ha l'attività associata eseguita. Poiché queste attività possono essere attività composite, questa esecuzione può essere arbitrariamente complessa.

Le attività di CAG vengono eseguite in parallelo e, una volta completate, le condizioni relative a tutte le attività del CAG attualmente in esecuzione vengono valutate di nuovo. Qualsiasi condizione in cui le condizioni che restituiscono true hanno di nuovo eseguito le attività associate. Questo ciclo continua, verificando quando le condizioni e eseguendo le attività associate a quelle che restituiscono true, fino a quando non si verifica una delle due cose seguenti: non più quando le condizioni sono vere o una condizione fino a quando non viene soddisfatta una condizione associata all'attività CAG stessa.

In alcuni modi, un'attività CAG può essere considerata come un mini-flusso di lavoro, una guidata dalle regole business. Consente l'esecuzione di un gruppo di attività in base alle condizioni vere. Questo è simile a , ma non esattamente come , usando un motore regole. Per le applicazioni che necessitano di un motore regole completo, tuttavia, Windows Workflow Foundation offre anche questa opzione, come descritto di seguito.

Uso di un motore regole: l'attività dei criteri

Per valutare set complessi di regole business, la creazione e la gestione di un gruppo complesso di condizioni possono essere problematici. Nel processo di domanda di assicurazione descritto in precedenza, ad esempio, ogni richiedente deve essere controllato in base al set di regole potenzialmente complesse che costituiscono le norme di sottoscrizione dell'azienda. Anche se l'espressione di queste regole usando le opzioni di Windows Workflow Foundation descritte finora è certamente possibile, non è sempre la scelta migliore. Al contrario, l'approccio corretto per la gestione di gruppi complessi di regole può talvolta essere quello di usare un motore regole.

Per rendere possibile questa operazione, Windows Workflow Foundation fornisce un motore regole a cui è possibile accedere tramite l'attività Criteri. Usando questa attività, uno sviluppatore può definire un gruppo di regole denominato set di regole. Ogni regola ha il formato CONDIZIONE IF> azione THEN <ACTION> ELSE><.< Ad esempio, una società assicurativa potrebbe creare un'attività di criteri con un set di regole contenente tutte le qualifiche di sottoscrizione. I conducenti sotto i 21 anni potrebbero essere classificati come ad alto rischio, ad esempio, a meno che non abbiano buoni voti a scuola, mentre ai conducenti sposati potrebbe essere assegnata una classificazione di rischio inferiore. Flusso di lavoro che deve determinare se un determinato richiedente conforme a queste regole potrebbe quindi richiamare questa attività di criteri. Il motore regole di Windows Workflow Foundation determina quali regole in questo set di regole sono vere e quindi eseguono tali regole. Questa esecuzione potrebbe modificare lo stato del flusso di lavoro in modo che altre regole nel set di regole siano ora vere. Per gestirlo, il motore regole esamina e, se necessario, esegue nuovamente le regole interessate nel set di regole, una tecnica nota come concatenamento di inoltro. Questo processo continua fino a quando non vengono soddisfatte nuove regole o viene raggiunto un limite predefinito.

L'uso dell'attività Policy richiede la scrittura di codice. Attualmente non esiste alcuna rappresentazione grafica predefinita per questa attività nella casella degli strumenti Flusso di lavoro Designer, ad esempio, e pertanto uno sviluppatore deve creare in modo esplicito un'attività policy specifica. Uno sviluppatore deve anche scrivere codice per definire le regole in un set di regole.

Hosting del motore di runtime

Ogni flusso di lavoro dipende dal motore di runtime di Windows Workflow Foundation. Il motore esegue ogni flusso di lavoro e gestisce lo stato del flusso di lavoro per tutta la durata del flusso di lavoro. Il runtime di Windows Workflow Foundation è tuttavia una libreria e quindi deve essere eseguito in un processo host. Invece di fornire un singolo host obbligatorio, Windows Workflow Foundation consente al runtime (e ai flussi di lavoro eseguiti) di essere ospitato in praticamente in qualsiasi processo di Windows, che va da una semplice console o applicazione Windows Forms, a un server complesso progettato tenendo presente il flusso di lavoro. Windows Workflow Foundation viene fornito con un set di servizi che consentono l'esecuzione del runtime all'interno di ASP.NET, ma gli ISV e gli utenti finali sono liberi di creare i propri host o di ospitare il runtime di Windows Workflow Foundation nelle applicazioni esistenti. Altri prodotti Microsoft ospiteranno anche Windows Workflow Foundation, tra cui BizTalk Server e Windows SharePoint Services.

Diversi host avranno caratteristiche diverse. Ad esempio, un flusso di lavoro in esecuzione in una semplice applicazione Windows Forms in un desktop sarà meno scalabile e meno affidabile di un flusso di lavoro ospitato in WSS o BizTalk Server. Poiché Windows Workflow Foundation è un framework del flusso di lavoro anziché un prodotto autonomo, il supporto di questo tipo di diversità è un obiettivo esplicito dei suoi creatori. Anche se ogni host usa lo stesso motore di runtime, ogni host deve fornire un set di servizi di runtime, come illustrato nella figura precedente. Questi servizi forniscono supporto per rendere persistente lo stato di un flusso di lavoro, il monitoraggio dell'esecuzione di un flusso di lavoro, l'uso di transazioni e altro ancora. Windows Workflow Foundation fornisce un'implementazione predefinita per tutti questi servizi che possono essere usati da qualsiasi host. Per personalizzare un host in modo da soddisfare requisiti univoci, tuttavia, l'autore dell'host può sostituire una o più di queste impostazioni predefinite, se necessario.

Per avere un'idea del funzionamento del runtime di Windows Workflow Foundation con i servizi forniti dall'host, considerare uno degli aspetti fondamentali di un flusso di lavoro: può essere a esecuzione prolungata. Poiché un flusso di lavoro può essere eseguito per ore, giorni o settimane, il runtime di Windows Workflow Foundation arresterà automaticamente un flusso di lavoro in esecuzione e archivierà in modo permanente lo stato se è stato inattivo per un periodo di tempo. La decisione di scaricare il flusso di lavoro (i flussi di lavoro scaricati a volte sono stati disidratati), forse perché è bloccata in attesa di un evento esterno, viene in genere eseguita dal runtime. Per scrivere effettivamente lo stato del flusso di lavoro su disco, tuttavia, il runtime dipende dal servizio di persistenza fornito dal processo host. L'host basato su ASP.NET fornito con Windows Workflow Foundation si basa su Microsoft SQL Server o su Microsoft SQL Express liberamente distribuibile per la persistenza. Un altro host potrebbe preferire rendere persistenti i flussi di lavoro usando altre tecnologie, ad esempio un database proprietario usato da un'applicazione ISV.

Indipendentemente dai servizi forniti dall'host, le nozioni di base dell'hosting del runtime di Windows Workflow Foundation sono semplici, come illustrato nell'esempio seguente.

using System.Workflow.Runtime;
   class ExampleHost
   {
    static void Main()
    {
      WorkflowRuntime runtime = new WorkflowRuntime();
      runtime.StartRuntime();
      runtime.StartWorkflow(typeof(ExampleWorkflow));
      ...           
    }
   }

Come illustrato in questo esempio, il runtime è solo un'altra classe. Dopo aver creato un'istanza di questa classe, può essere inizializzata chiamando il relativo metodo StartRuntime e quindi può essere assegnato un flusso di lavoro da eseguire tramite il relativo metodo StartWorkflow .

Il processo host è una parte fondamentale dell'ambiente in cui viene eseguito un flusso di lavoro. Poiché il runtime può essere ospitato in una serie di processi Di Windows, i flussi di lavoro di Windows Workflow Foundation possono essere usati in diversi scenari.

Comunicazione con il software all'esterno del flusso di lavoro

Dato che il ruolo di un flusso di lavoro tipico consiste nel coordinare il lavoro di persone e/o sistemi, Windows Workflow Foundation deve fornire un modo per comunicare con altri software. Tenere tuttavia presente che un flusso di lavoro inattiva verrà scaricato, con lo stato persistente su disco. Un flusso di lavoro in questa condizione non può ricevere direttamente alcuna comunicazione in ingresso, ma non è nemmeno in esecuzione. A causa di questa possibilità, il runtime di Windows Workflow Foundation funge da intermediario per tutte le comunicazioni con tutti i flussi di lavoro. Quando arriva una richiesta in ingresso, il runtime lo riceve e quindi determina l'istanza del flusso di lavoro destinata a questa richiesta, ovvero un processo noto come correlazione. Il runtime invia quindi la richiesta all'istanza di destinazione, ricaricando prima l'istanza in caso di disidratazione. In effetti, il runtime di Windows Workflow Foundation funge da proxy per tutte le comunicazioni con il software all'esterno del flusso di lavoro.

Per comunicare con altri oggetti nello stesso processo di Windows, un flusso di lavoro può usare due attività nella libreria di attività di base. L'attività InvokeMethod consente di chiamare un metodo in un oggetto all'esterno del flusso di lavoro, mentre l'attività EventSink consente di ricevere una chiamata da un oggetto all'esterno del flusso di lavoro. Uno sviluppatore definisce un'interfaccia per specificare i nomi e gli elenchi di parametri per ognuna di queste chiamate.

Windows Workflow Foundation offre anche attività predefinite per la comunicazione tramite i servizi Web. Basate su ASP.NET servizi Web, meglio noti come ASMX, queste attività sono:

• InvokeWebService: chiama un servizio Web e restituisce in modo sincrono la risposta.
• WebServiceReceive: accetta una chiamata al servizio Web in ingresso.
• WebServiceResponse: invia una risposta a una chiamata al servizio Web in ingresso ricevuta tramite WebServiceReceive.

Usando WebServiceReceive e WebServiceReponse, un flusso di lavoro può esporsi ai client tramite servizi Web. Ciò consente ai flussi di lavoro di pubblicare i servizi Web e di utilizzarli.

Rilevamento dell'esecuzione del flusso di lavoro

I flussi di lavoro vengono creati dalle attività, ognuna delle quali è un'unità di esecuzione ben definita. Questa struttura standard consente di tenere traccia dell'esecuzione di qualsiasi flusso di lavoro in modo standard. Windows Workflow Foundation può fornire informazioni di rilevamento per qualsiasi flusso di lavoro, ad esempio quando il flusso di lavoro inizia l'esecuzione e quando termina, quando ogni attività all'interno del flusso di lavoro viene immessa e chiusa e altro ancora. Ciò può essere utile per raccogliere statistiche sugli aspetti tecnici o aziendali dei flussi di lavoro, ad esempio le misurazioni del tempo di evasione degli ordini o la gestione di un database con informazioni su ogni flusso di lavoro in esecuzione, consentendo l'esecuzione di query in tempo reale di questi dati o altri elementi. Esattamente le informazioni di rilevamento generate dai profili definiti dallo sviluppatore e le informazioni vengono scritte per impostazione predefinita in un database SQL Server. Questa operazione può essere modificata, tuttavia, poiché il rilevamento viene parzialmente implementato da un servizio di runtime sostituibile nell'applicazione host di un flusso di lavoro.

La funzionalità di rilevamento di Windows Workflow Foundation è relativamente semplice. Sebbene fornisca le interfacce necessarie per definire e raccogliere dati di rilevamento, non vengono forniti strumenti per visualizzare queste informazioni. Non esiste anche alcun meccanismo standard per inviare notifiche in base ai dati di rilevamento. Invece di fornire un servizio completo simile al componente Business Activity Monitoring in BizTalk Server, Windows Workflow Foundation offre una base su cui possono essere compilati gli ISV e altri utenti.

Modifica dei flussi di lavoro in esecuzione

Se Windows Workflow Foundation era incentrato esclusivamente sui flussi di lavoro di sistema che coordinano le interazioni tra software, la possibilità di definire un flusso di lavoro ed eseguirlo invariato sarebbe probabilmente sufficiente. Persone tendono a volere che i processi aziendali siano più dinamici, tuttavia, e quindi il supporto del flusso di lavoro umano richiede la possibilità di apportare modifiche in tempo reale. Si supponga, ad esempio, che uno dei partecipanti di un flusso di lavoro attualmente in esecuzione decida di aggiungere un nuovo passaggio al processo aziendale. Forse il responsabile nel processo di applicazione assicurativa descritto in precedenza desidera ottenere un secondo parere su un determinato richiedente ad alto rischio, una modifica che richiede l'aggiunta di un altro passaggio a una particolare istanza del flusso di lavoro in esecuzione. Indipendentemente dal fatto che gli sviluppatori che creano un flusso di lavoro come questo, gli utenti che usano processi aziendali automatizzati si aspettano di poter apportare questi tipi di modifiche.

Per consentire questa operazione, Windows Workflow Foundation include l'aggiornamento dinamico. Usando questa opzione, un'istanza in esecuzione di qualsiasi flusso di lavoro può essere modificata all'interno di limiti sicuri, ben definiti specificati dal relativo autore e quindi potenzialmente salvati come nuovo flusso di lavoro. È possibile inserire una nuova attività nel flusso di lavoro, ad esempio oppure è possibile modificare una condizione della regola per un'attività IfElse o CAG. Anche se questo tipo di aggiornamento in anteprima non è tipico per flussi di lavoro puramente orientati al sistema, può essere essenziale per i flussi di lavoro che coordinano le attività degli esseri umani fittizi.

Supporto dei flussi di lavoro umani

Come già accennato, il supporto dei flussi di lavoro umani e dei flussi di lavoro di sistema è un obiettivo principale di Windows Workflow Foundation. La maggior parte dei componenti di Windows Workflow Foundation che gli sviluppatori possono usare per creare flussi di lavoro che coinvolgono persone sono già stati descritti. Tali tecnologie includono:

• Flussi di lavoro della macchina a stati, che consentono di definire i passaggi in un flusso di lavoro in modo più dinamico basato su eventi rispetto a flussi di lavoro sequenziali.
• L'attività CAG, che consente l'esecuzione basata su regole di un gruppo di attività.
• Aggiornamento dinamico, che consente a un utente di apportare modifiche a un flusso di lavoro in esecuzione.

L'attività Replicator, un altro membro della libreria di attività di base, vale anche la pena menzionare in questo contesto. Come suggerisce il nome, questa attività è in grado di replicare qualsiasi attività venga inserita in esso un numero specificato di volte. Un replicatore può essere usato, ad esempio, in un flusso di lavoro che consente a un responsabile di assegnare una determinata attività a tutti i report diretti, con l'attività Replicator che crea un'istanza dell'attività di tale attività per ognuno di essi. Consentendo di specificare il numero di repliche in fase di esecuzione, l'attività Replicator consente a un flusso di lavoro di assegnare il lavoro alle persone coinvolte in un processo aziendale.

Un altro aspetto di Windows Workflow Foundation rilevante per il modo in cui gli utenti usano i flussi di lavoro è il supporto per i ruoli. Windows Workflow Foundation implementa un'infrastruttura generale per controllare quali utenti sono autorizzati a eseguire una determinata attività, in base al ruolo dell'utente. L'autore di un flusso di lavoro può definire i ruoli usati nel flusso di lavoro e quindi determinare quali attività possono essere eseguite da quali ruoli. Ad esempio, un'applicazione assicurativa può essere inviata da chiunque sia nel ruolo Dipendente, ma tale rapporto può essere approvato solo da qualcuno nel ruolo Manager. E invece di implementare il proprio sistema per la gestione dei ruoli, Windows Workflow Foundation fornisce invece un meccanismo che consente ai flussi di lavoro di usare sistemi di gestione dei ruoli esterni. Windows Workflow Foundation include un supporto predefinito per i ruoli definiti usando account Windows, Microsoft Active Directory e ASP.NET, ma altri sistemi di gestione dei ruoli possono essere integrati anche in questo framework del flusso di lavoro.

Windows Workflow Foundation e altre tecnologie Microsoft

Windows Workflow Foundation offre un framework generale per il flusso di lavoro, uno che può essere usato in molti tipi diversi di applicazioni. Una volta fornito, sarà una parte standard della piattaforma Windows. Questo genera una domanda importante: in che modo Windows Workflow Foundation si adatta ad altre parti dell'ambiente Microsoft?

Questa sezione illustra come verrà usata questa nuova tecnologia in altre tre offerte Microsoft: BizTalk Server, Windows SharePoint Services e Microsoft Office System. Ognuno di essi applica Windows Workflow Foundation in modo specifico, usandolo per supportare i flussi di lavoro in un particolare dominio. Questa sezione descrive anche il modo in cui Windows Workflow Foundation si integra con Microsoft Windows Communication Foundation, un'altra parte della piattaforma per sviluppatori di Microsoft .NET Framework 3.0.

Windows Workflow Foundation e BizTalk Server

Forse l'implementazione microsoft più nota del flusso di lavoro è attualmente in BizTalk Server (anche se BizTalk Server usa il termine orchestrazione anziché flusso di lavoro). BizTalk Server consente agli sviluppatori di creare flussi di lavoro di sistema per la gestione dei processi aziendali (BPM), L'integrazione di applicazioni aziendali (EAI) e l'integrazione business-to-business (B2B). Il rilascio del prodotto che segue Microsoft BizTalk Server 2006 aggiungerà il supporto per la creazione di flussi di lavoro di Windows Workflow Foundation destinati a queste aree.

BizTalk Server e Windows Workflow Foundation presentano alcune ovvie analogie. Per uno sviluppatore, ad esempio, l'Designer orchestrazione BizTalk Server è simile alla Designer flusso di lavoro di Windows Workflow Foundation. Questa comunezza non è un incidente: lo stesso gruppo di Microsoft è responsabile di entrambe le tecnologie. Per la maggior parte, tuttavia, decidere quale usare per un particolare problema non è difficile. Di seguito sono riportate alcune linee guida utili per prendere questa decisione.

Usa Windows Workflow Foundation quando:

Un'applicazione ospiterà i flussi di lavoro. Windows Workflow Foundation consente di integrare il flusso di lavoro in un'applicazione, consentendo la distribuzione e la gestione del flusso di lavoro come parte nativa dell'applicazione. Poiché è incentrato sull'integrazione di applicazioni diverse anziché fornire un framework di flusso di lavoro generale, BizTalk Server esegue sempre orchestrazioni all'interno del processo di BizTalk Server.

• Il processo aziendale implementato richiede il flusso di lavoro umano. BizTalk Server indirizza il flusso di lavoro del sistema e pertanto manca il supporto di Windows Workflow Foundation per elementi quali flussi di lavoro macchina a stati e aggiornamento dinamico. Uno scenario che richiede sia il flusso di lavoro umano che i servizi di integrazione del sistema più complessi possono essere gestiti usando Windows Workflow Foundation e BizTalk Server insieme. Ad esempio, il supporto di Office "12" per i flussi di lavoro incentrati sui documenti, basato su Windows SharePoint Services, può essere usato per gli aspetti umani del problema, mentre BizTalk Server gestisce gli aspetti di integrazione del sistema. I due possono interagire usando l'adapter BizTalk Server per SharePoint.
• Il flusso di lavoro verrà eseguito in un sistema client. BizTalk Server è un prodotto incentrato sul server e quindi è meno adatto per l'esecuzione nei computer desktop.

Usare BizTalk Server quando:

• Risoluzione di un problema EAI che richiede la comunicazione con applicazioni diverse su piattaforme diverse. A causa del suo focus sull'integrazione multipiattaforma, è disponibile un ampio set di adattatori per BizTalk Server che consente la comunicazione con una gamma di altri software. Windows Workflow Foundation è incentrato esclusivamente sul flusso di lavoro, non su EAI e quindi non fornisce questi elementi.
• Sono necessari servizi B2B. Windows Workflow Foundation non si occupa di questa area, mentre BizTalk Server fornisce strumenti per lavorare con partner commerciali, acceleratori per RosettaNet, SWIFT e altri standard del settore e altro ancora.
• Sono necessari servizi BPM, ad esempio BAM (Business Activity Monitoring). Anche se l'infrastruttura di rilevamento di Windows Workflow Foundation può essere usata per creare questi servizi, BizTalk Server fornisce importanti funzionalità aggiuntive, ad esempio strumenti che consentono agli information worker di definire le proprie visualizzazioni BAM.
• Sono necessari un'infrastruttura di gestione completa e il supporto per una maggiore scalabilità. A differenza di Windows Workflow Foundation, BizTalk Server include un set completo di strumenti per l'amministrazione e il ridimensionamento di un ambiente di produzione.

Windows Workflow Foundation e Windows SharePoint Services

Windows SharePoint Services, una parte standard del sistema operativo Windows Server, mira ad aiutare le persone e il software a collaborare in modo più efficace. Questo rende il supporto per il flusso di lavoro un'estensione naturale alla tecnologia. Di conseguenza, la versione 3 di WSS, pianificata per il rilascio nel 2006, ospiterà il runtime di Windows Workflow Foundation. Usando gli strumenti standard di Windows Workflow Foundation, ad esempio l'Designer del flusso di lavoro, gli sviluppatori potranno creare applicazioni flusso di lavoro per la collaborazione di documenti e altri tipi di condivisione delle informazioni. L'hosting di Windows Workflow Foundation in WSS fornisce anche le basi per il supporto del flusso di lavoro in Microsoft Office System, come descritto di seguito.

Windows Workflow Foundation e Microsoft Office System

Nessuna applicazione Windows è più ampiamente usata oggi rispetto a Microsoft Office, quindi l'adozione di Office di Windows Workflow Foundation è un passaggio importante. Man mano che Office si è evoluto da un gruppo di applicazioni desktop alla combinazione più ampia di tecnologie client e server che costituiscono Microsoft Office System, i problemi affrontati si sono anche evoluti. Office "12", pianificato per il rilascio nel 2006, includerà il supporto per la creazione di flussi di lavoro incentrati sui documenti. Tale supporto dipenderà da Windows Workflow Foundation.

Il flusso di lavoro nei prodotti server e client di Office "12" si basa e estende il supporto del flusso di lavoro basato su Windows Workflow Foundation in Windows SharePoint Services. I flussi di lavoro di supporto per i processi di documento formali, la gestione dei contenuti Web e altro ancora, Office "12" consentirà anche alle persone meno orientate al livello tecnico di creare flussi di lavoro incentrati sui documenti. Usando Microsoft FrontPage, i progettisti Web e altri utenti potranno usare un approccio basato su regole anziché la tecnologia orientata graficamente al flusso di lavoro Designer. I server di Office "12" includeranno anche un set di attività di Windows Workflow Foundation specifiche di Office per l'uso di attività e documenti, oltre al supporto per la creazione di moduli tramite Microsoft InfoPath.

Come BizTalk Server e Windows SharePoint Services, Office "12" è specializzato nel supporto generico del flusso di lavoro di Windows Workflow Foundation per un particolare tipo di applicazione. L'obiettivo è semplificare per gli sviluppatori e altri sviluppatori la creazione di flussi di lavoro incentrati sui documenti per gli information worker. Data la popolarità dei prodotti desktop di Office, non è sorprendente che Microsoft voglia che i clienti si affidano alle sue interfacce familiari per interagire con i flussi di lavoro. L'incorporazione di Windows Workflow Foundation in Office "12" consente di rendere possibile questa operazione.

Windows Workflow Foundation e Windows Communication Foundation

Windows Communication Foundation (WCF) è il prossimo framework Microsoft per la creazione di applicazioni orientate ai servizi. L'implementazione di un ampio gruppo di specifiche di servizi Web standard del settore, WCF consente agli sviluppatori di creare applicazioni che comunicano in modo sicuro e affidabile sia all'interno del mondo Windows che attraverso i limiti dei fornitori. Dato questo, WCF e Windows Workflow Foundation sono una combinazione naturale. Mentre WCF è incentrato sulla creazione di servizi, Windows Workflow Foundation consente di creare flussi di lavoro che usano tali servizi per supportare i processi aziendali. Anche se il supporto dei servizi Web nella prima versione beta di Windows Workflow Foundation si basa su ASMX, le attività di Windows Workflow Foundation che consentono ai flussi di lavoro di usare questa nuova infrastruttura di comunicazione saranno disponibili in futuro.

Conclusione

Senza la giusta base, la scrittura dei flussi di lavoro è difficile. Soddisfare le esigenze di un processo aziendale a esecuzione prolungata, supportando il comportamento dinamico richiesto dalle persone e gestendo le altre sfide che i flussi di lavoro presentano richiedono più tempo e impegno rispetto alla maggior parte degli sviluppatori che possono investire. Tuttavia, se la giusta tecnologia di supporto è disponibile, la creazione di flussi di lavoro diventa semplice e questo tipo utile di software può essere molto più diffuso.

L'obiettivo di Windows Workflow Foundation è fornire questa base. Creando un framework generale che supporta sia il flusso di lavoro umano che il flusso di lavoro di sistema e rendendolo parte standard dell'ambiente Windows, Microsoft sta mettendo le basi per l'uso diffuso della tecnologia del flusso di lavoro. Dopo anni di essere retrocesso a usi e applicazioni specializzati, il flusso di lavoro sta per andare mainstream.

 

Informazioni sull'autore

David Chappell è principal di Chappell & Associates (www.davidchappell.com) a San Francisco, California. Attraverso la sua conversazione, la scrittura e la consulenza, aiuta i professionisti tecnologici di tutto il mondo a comprendere, usare, commercializzare e prendere decisioni migliori sul software aziendale.