Workflow Foundation: Migrazione da WF3 a WF4 - Note e Riferimenti

La versione 4.0 della .NET Framework definisce un nuovo object model per Workflow Foundation (WF). Questo nuovo object model, chiamato WF4, si aggiungerà all’object model iniziale di WF, introdotto nella .NET Framework 3.0 ed ampliato nella .NET Framework 3.5, chiamato in breve WF3. L’object model di WF3 usa i namespace System.Workflow.*, mentre l’object model di WF4 usa i namespace System.Activities.*.

Il Product Group di WF ha pubblicato un insieme di documenti denominato Migration Guidance, disponibili all’URL http://go.microsoft.com/fwlink/?LinkID=153313. Questi documenti analizzano le diverse opzioni di upgrade, identificandone, scenario per scenario, vantaggi e svantaggi. I documenti si riferiscono, attualmente, alla versione Beta1 della .NET Framework 4.0, che è disponibile per il download all’URL http://www.microsoft.com/downloads/details.aspx?FamilyID=ee2118cc-51cd-46ad-ab17-af6fff7538c9&displaylang=en. I documenti di Migration Guidance verranno aggiornati quando la Beta2 si renderà disponibile.

Chi ha già usato WF3 dovrebbe pianificare con attenzione la migrazione. I documenti di Migration Guidance sopra riportati, insieme al Blog del team di prodotto all’URL http://blogs.msdn.com/endpoint, sono risorse essenziali per una corretta pianificazione della migrazione. Nel seguito riporto alcuni aspetti essenziali, in parte contenuti nei documenti di Migration Guidance e in parte derivanti da domande che riceviamo dai clienti nella nostra attività di supporto. I documenti di Migration Guidance sono più dettagliati e approfonditi di queste brevi note, quindi in ogni caso ne suggerisco la lettura completa.

• .NET Framework e Ambiente di Sviluppo: un aspetto importante, non sempre ben compreso, è il fatto che WF3 è contenuto nella .NET Framework 4.0. In altre parole, è possibile far girare workflow scritti con WF3 sul CLR 4.0 e la .NET Framework 4.0 Class Library. Inoltre, il Workflow Designer di WF3 gira in Visual Studio 10. Di conseguenza non è necessario usare Visual Studio 9 (Visual Studio 2008) per scrivere/modificare/compilare applicazioni WF3: è possibile usare Visual Studio 10.

• Rules: il forward-chaining delle Rules non é disponibile nell’object model di WF4, almeno nella sua versione iniziale. Se la vostra applicazione richiede il forward-chaining delle Rules, si può continuare ad usare l’object model di WF3, anche per nuovi sviluppi. È anche possibile creare una activity WF4 che faccia da wrapper alle forward-chaining rules di WF3. L’esempio dell’ SDK Policy40 illustra questa tecnica.

• State Machine Workflows: nella mia attività di supporto mi é spesso capitato di gestire richieste relative ai workflow di tipo State Machine. Mi sembra, quindi, che nel modello ad oggetti di WF3 siano diventate un tipo di workflow piuttosto usato. In WF4 non esiste un equivalente degli State Machine Workflow di WF3. La Flowchart activity, nuova in WF4, puó sostituire lo State Machine Workflow nei casi in cui il workflow è prevalentemente sequenziale, con occasionali cambiamenti di stato non sequenziali. Per gli State Machine Workflow di WF3 che non ricadono in questa categoria, si puó valutare la possibilità di non migrare all’object model di WF4 e di mantenere invece l’object model di WF3.

• Workflow Services: con il termine "Workflow Services" si indicano i workflow che comunicano con il mondo esterno tramite WCF. In poche parole, essi implementano la logica di business di un servizio WCF. Nella.NET Framework 4.0 l’integrazione di WF e di WCF, con la logica di business implementata in un durable service WF e la comunicazione implementata tramite WCF, è ancora più stretta che nella versione 3.5 della .NET Framework. Mentre in WF3 i workflow services usavano la ReceiveActivity activity per gestire chiamate WCF, in WF4 la ReceiveActivity activity ha il ruolo di ricevere richieste SOAP. Di conseguenza, il parallelo di una ReceiveActivity di WF3 con il check box "One Way Operation" deselezionato (request-reply MEP), in WF4, è costituito da una coppia di activity: Receive and SendReply. L’object model di WF4, fornendo activity separate per richieste e risposte SOAP, permette una gestione più flessibile di MEP diversi da quello Request-Reply.

(tradotto, adattato ed espanso da http://blogs.msdn.com/carlos/archive/2009/08/27/workflow-foundation-migration-from-wf3-to-wf4-notes-and-references.aspx).

 

Carlo Colombo
Escalation Engineer
Developer Support Core

Comments

• Anonymous
  October 01, 2009
  Complimenti, un post molto esauriente e che illustra in maniera ottimale la migrazione del WF. Ottime indicazioni, molto utile. Grazie.

• Anonymous
  February 15, 2010
  Ho sviluppato interi progetti basati sui WF3 State Machine Workflows utilissimi per il mantenimento dello stato di una sequenza di pagamento ad esempo. Potresti chiarire meglio come i Flowchart activity sostituiscono lo State Machine Workflow ? Esistono sempre le State, SetState, InitiateState, ExternalEventHandler, CallExternalMethod activities ad esempio ? Saluti.

• Anonymous
  February 22, 2010
  Le activity State, SetState e InitiateState, che erano usate negli State Machine Workflow, non esistono più. Nei Flowchart workflow si usano le activity normalmente usate nei Sequential Workflow (Squence etc.), inoltre esistono un paio di activity specifiche dei Flowchart: FlowDecision e FlowSwitch, che permettono di eseguire "transizioni di stato" in modo condizionale. Al link sopra indicato, http://go.microsoft.com/fwlink/?LinkID=153313, il documento WF4 State Machine Guidance.doc riporta esempi di migrazione passo-passo da uno StateMachine workflow ad un Flowchart workflow. In generale, ci sono StateMachine workflow che possono essere migrati a Flowchart workflow in modo relativamente semplice, mentre per altri StateMachine workflow la migrazione è più complessa. In questi ultimi casi si può anche decidere di non eseguire la migrazione e di continuare a usare il modello a oggetti precedente (WF3) con la Framework 4.0 e il Visul Studio 10.