Paolo Pialorsi : WF

WF Security Pack CTP 1

paolo — Wed, 14 Jul 2010 00:51:27 GMT

Pochi giorni fa è stato rilasciato su CodePlex un aggiornamento delle estensioni di WF prodotte direttamente dal team di prodotto.

In particolare ci tengo a segnalare il WF Security Pack attualmente in CTP 1 perché mi sembra molto interessante l’idea di avere delle activity dentro WF 4 che consentano di integrarsi con WIF, con la Claim based authentication e con scenari complessi di ActAs via WS-Trust.

Migrare da WF3 a WF4

paolo — Tue, 06 Apr 2010 11:30:00 GMT

Come abbiamo iniziato ad evidenziare ormai quasi 2 anni fa ad una delle nostre DevCon la ormai imminente (è questione di giorni) versione di WF presente in .NET 4.0 sarà molto (possiamo dire “radicalmente”?) diversa da WF3.

Il problema non è solo imparare ad usare un nuovo motore di workflow, ma soprattutto decidere se e come migrare le soluzioni esistenti e basate su WF3 verso il nuovo WF4.

In questo nuovo progetto su CodePlex, gestito direttamente dal team di WF di Microsoft, ci sono alcune risposte. Sicuramente è degno di nota il fatto che, essendo su CodePlex, ci sono anche i sorgenti del progetto, molto utili per uno studio individuale e una personalizzazione su progetti specifici del modello di upgrade del codice da WF3 a WF4.

Microsoft SharePoint 2010: prodotto svelato e nuovo corso DevLeap

paolo — Tue, 20 Oct 2009 00:56:39 GMT

Oggi, durante la keynote della Microsoft SharePoint Conference 2009 in Las Vegas, è stato pubblicamente svelato Microsoft SharePoint Server 2010.

Ci sono da oggi diversi siti e aree online dedicati all’argomento, come segnalato dal team di prodotto nel suo blog ufficiale.

Per quanto riguarda noi di DevLeap, oltre a dare appuntamento alla SharePoint Future della prossima settimana (per chi ce l’ha fatta ad iscriversi prima del sold out), segnalo che da oggi (nel rispetto delle NDA non potevamo pubblicarlo prima) è stato ufficializzato un nuovo corso dal titolo “Microsoft SharePoint 2010 Development”.

Workflow 4.0

paolo — Thu, 11 Jun 2009 08:03:20 GMT

Come molti di voi avranno notato, nella CTP di VS2010 uscita il mese scorso manca il template di workflow di tipo State Machine. Con .NET 4.0 il motore di WF4 è stato praticamente riscritto, il prodotto è stato completamente integrato con WCF4 (i due team di prodotto infatti si sono fusi, forse dovremmo parlare di “fusione per incorporazione” di WF :-) …). Ora in WF4 i workflow saranno orientati solo al markup e non dovrebbe più esistere il concetto di code beside di un workflow. Anche il set di activity di base (vedi qui per averne un’idea) e il modello di estendibilità delle activity personalizzate sono cambiati. Ora le activity non sono più classi derivate dalla classe base Activity, ma classi di una delle seguenti tipologie:

WorkflowElement: classe base astratta per tutte le tipologie di activity
Activity: definite come markup e frutto della composizione di altre activity, come i workflow stessi
CodeActivity: classe base per le activity definite come codice, con l’override del metodo di Execute
NativeActivity: classe base per le activity definite come codice, che devono interfacciarsi con il motore di base di WF4, con il sistema di messaggi a code (ora ribattezzate bookmark), ecc.

In questo contesto sono stati inseriti dei nuovi modelli di workflow. Nello specifico esiste ancora, seppur ridefinito con nuove activity e con un nuovo designer, il modello di Sequential workflow. Esiste un nuovo modello di workflow chiamato Flowchart, che può anche essere una parte di un workflow Sequential. Come citavo all’inizio del post poi non esiste più il modello di tipo State Machine. Mentre inizialmente (lo scorso anno) si ipotizzava che la causa di questa assenza fosse un porting non ancora completato del motore, ora è chiaro che lo State Machine non sarà supportato, almeno inizialmente. Infatti come spiegato in questa serie di documenti sulla migrazione da WF3 a WF4 con un modello di tipo Flowchart è possibile riprodurre il comportamento di uno State Machine.

Ovviamente, per quella che è la natura di .NET Framework, in .NET 4.0 sarà possibile avere comunque il supporto ai workflow definiti con il motore di .NET 3.0 e di WF3, come è spiegato anche qui, quindi non dobbiamo necessariamente buttare tutto il lavoro già svolto in WF3, soprattutto se abbiamo lavorato con le State Machine. Tuttavia è consigliabile iniziare a pensare ad un percorso di migrazione.

SharePoint Workflow: due articoli utili

paolo — Fri, 13 Jun 2008 12:24:15 GMT

Per chi vuole "avviarsi" allo sviluppo di Workflow per SharePoint, segnalo due articoli utili scritti da David Man e pubblicati su MSDN:

http://msdn.microsoft.com/en-us/library/cc546557.aspx
http://msdn.microsoft.com/en-us/library/cc546558.aspx

SharePoint Designer, Code Access Security e Folder Redirection

paolo — Thu, 10 Jan 2008 15:36:20 GMT

Un titolo complicato :-) per un post semplice!

Oggi ho riscontrato un problema con SharePoint Designer 2007. Da un PC del dominio del mio ufficio, con i profili e i folder salvati su Distributed File System via Group Policy, non riuscivo a creare workflow su un site MOSS2007.
Il problema era in realtà molto semplice: il folder che contiene gli Application Data degli utenti, viene utilizzato da SD2007 per salvare in una cache temporane degli assembly, tra cui quelli con le activity offerte dai vari portali MOSS2007/WSS3 a cui ci si collega.

In pratica in <User Folder>\Application Data\Microsoft\SharePoint Designer\ProxyAssemblyCache\12.x.y.z vengono salvati gli assembly scaricati dai vari server MOSS2007/WSS3. SD2007 poi carica questi assembly per metterceli a disposizione durante la definizione dei workflow. Ora dal momento che nel mio caso il folder <User Folder>\Application Data\ risiedeva su di una share raggiunta via DFS, la Code Access Security di .NET - giustamente - non dava un livello di trust adeguato agli assembly, quindi SD2007 falliva durante il loro caricamento.

L'errore restituito era un criptico po': "Failed to load the workflow". Guardando però cosa SD2007 tentava di caricare, ho capito l'arcano mistero. Sono dovuto andare in "Microsoft .NET Framework 2.0 Configuration" dagli strumenti amministrativi della macchina, per definire un code group (a livello di macchina nel mio caso) che corrispondesse alla URL \\dominio\DFSRoot\* (attenzione al \* in fondo che è necessario) per dire poi che volevo dare ai file provenienti da quella URL un livello di trust pari a quello che ho su "My Computer", simulando il fatto che i file provengano dal mio disco locale anziché dal profilo sul server, cioè in questo caso "Full Trust". Ora tutto funziona regolarmente.

Probabilmente se non avessi saputo come funziona la Code Access Security di .NET ... sarei ancora lì :-) a cercare la causa del problema. Per questo insisto sempre sul fatto che anche i sistemisti dovrebbero conoscere almeno di massima il funzionamento di .NET!

Acropolis sarà incluso in versioni future di .NET Framework

paolo — Tue, 30 Oct 2007 13:20:18 GMT

Di Acropolis ne avevamo già parlato durante TechEd 2007. Dopo alcuni mesi di silenzio, successivi alla presentazione a TechEd 2007, il team del prodotto ha annunciato che Acropolis farà parte di una delle versioni future di .NET Framework. Nel frattempo però non avremo nuove CTP ma solo un documento di Patterns & Practices, prima o poi disponibile, intanto teniamo d'occhio qui. Questa è una notizia importante per tutti coloro i quali devono scegliere se e come implementare la gestione della UI nelle loro applicazioni. Infatti se ad oggi si sviluppa su Windows Forms, si può decidere di valutare CAB (ma anche no :-) ...) mentre nell'ambito di WPF potrebbe essere Acropolis la linea guida da seguire. Mi auguro che resti valida anche l'idea, mostrata in fase di presentazione del progetto, di rendere utilizzabili dei workflow di WF per il controllo della UI. Staremo a vedere ...

Rules di WF senza Workflow

paolo — Sun, 27 May 2007 19:07:45 GMT

Questa settimana, durante un corso su WF, ho mostrato come sia possibile utilizzare le rule di WF anche senza avere necessariamente un workflow alle spalle. L'infrastruttura di WF infatti consente di valutare RuleSet anche senza che ci sia un workflow collegato. Dal momento poi che le rule di un workflow sono persistite all'interno di un file .rules (pur sempre XOML) differente da quello che rappresenta il flusso ... facendo 1 + 1 possiamo definire regole esterne da usare in qualsisi programma che abbia bisogno di un motore di regole e poi valutarle con gli oggetti del framework di WF.

Ecco un esempio di codice che carica un file .rules da disco, lo deserializza usando il WorkflowMarkupSerializer, e ne valuta il risultato tramite la classe RuleEngine:

XmlTextReader reader = new XmlTextReader(@"..\..\DiscountCouponWorkflow.rules");
WorkflowMarkupSerializer serializer = new WorkflowMarkupSerializer();
RuleDefinitions rules = serializer.Deserialize(reader) as RuleDefinitions;
RuleSet ruleSet = rules.RuleSets["PriceRuleSet"];
RuleEngine ruleEngine = new RuleEngine(ruleSet, typeof(Customer));
ruleEngine.Execute(c);

Si noti il fatto che passo al motore di rule (l'istanza di RuleEngine) anche un oggetto come input del metodo Execute. Si tratta di un oggetto il cui tipo .NET è stato dichiarato nel costruttore della classe RuleEngine e rappresenta l'input su cui verranno applicate le regole. Ora, utilizzando un'interfaccia che descriva un comportamento comune a N diverse tipologie di oggetti, potremmo avere uno stesso file di regole applicabile sia ad un workflow, che implementa l'interfaccia nella definizione della sua classe, sia ad un nostro oggetto custom.

Xceed Activities for WF

paolo — Thu, 26 Apr 2007 21:45:00 GMT

Segnalo il rilascio di una serie di Activity "interessanti" per WF, utili per avere il supporto per ZIP, TAR, FTP e Secure-FTP. Trovo che Xceed sia un ottimo produttore di componenti e add-on, quindi segnalo volentieri questo loro nuovo prodotto in cui mi sono imbattuto oggi.

Orcas March CTP: non solo LINQ, AJAX e WPF, ma anche WorkflowServices

paolo — Sat, 03 Mar 2007 16:32:56 GMT

Da pochi giorni è disponibile la March CTP di Visual Studio codename Orcas. Si parla molto e per lo più di LINQ, AJAX e miglior supporto a WPF. Personalmente credo molto in LINQ e mi appassiona vedere come è stato realizzato. AJAX non mi "scalda" :-) più di tanto e WPF ... lo sapete sono solo palle che rimbalzano! (ovviamente scherzo ... ma non sono un uomo che si occupa di UI con WPF, per questo ci sono Luka e RoB nel nostro gruppo). In ogni caso, come segnalato anche in questo post, le nuove funzionalità introdotto nella Orcas CTP di Marzo riguardano diversi e numerosi altri ambiti.

Ad esempio ci sono alcune classi e assembly che consentono di ospitare workflow definiti con WF in ServiceHost di WCF. Esiste infatti un assembly di nome System.WorkflowServices che espone una classe di nome System.ServiceModel.Activation.WorkflowServiceHostFactory, che non fa altro che creare una istanza di una classe System.ServiceModel.WorkflowServiceHost, che a sua volta rende accessibile un workflow di WF tramite chiamate SOAP via WCF.

A tale scopo è stata anche definita una coppia di nuovi binding NetTcpContextBinding e WSHttpContextBinding per meglio gestire l'associazione (context) tra le istanze dei flussi e l'infrastruttura di comunicazione. Proprio per questo, sfruttando le caratteristiche dell'architettura estendibile e personalizzabile di WF, è stato definito un nuovo runtime scheduler (System.Workflow.Runtime.Hosting.SynchronizationContextWorkflowSchedulerService) che internamente utilizza il SynchronizationContext di System.Threading e il System.Threading.ThreadPool).

Le potenzialità di questo nuovo "mattoncino" sono evidenti: avere logica di business implementata tramite WF ed esposta in modo rapido tramite WCF, senza richiedere a noi poveri sviluppatori di scrivere "quintali" di codice per gestire le istanze dei workflow, la loro persistenza, il loro stato, ecc.

Se avessi avuto queste opportunità nel progetto che usa WF per la gestione della produzione in stabilimento che ho concluso insieme a RoB il mese scorso e che sta andando on-line in questi giorni ... beh avrei scritto cordi almeno 15gg di meno ...

Avremo modo di tornare più approfonditamente su questi temi sia in post futuri che magari a DevCon.

Rientranza delle chiamate in WF

paolo — Tue, 06 Feb 2007 23:23:27 GMT

In questi giorni, a seguito di una consulenza su WF, ho potutoverificare in dettaglio alcuni aspetti relativi alla gestione dei thread e delle code in WF. Il motore del WF Runtime utilizza, per default, uno scheduler (DefaultWorkflowSchedulerService) che fornisce al runtime, come impostazione predefinita, un pool di 5 thread, nel caso di macchine mono-processore, oppure un pool di 4 thread per ciascun processore, nel caso di macchine multi-processore. Si tratta di impostazioni modificabili, ma questi numeri hanno un senso, soprattutto rispetto alla scalabilità delle applicazioni server-side, quindi non alzateli "a manetta" perché potrebbe dare effetti peggiori. Ricordate sempre che i thread non sono infiniti e se c'è in mezzo ASP.NET, già lui utilizza il ThreadPool di .NET.

Ciascuna istanza di workflow è eseguita da uno e uno solo di questi thread. Significa che non c'è la possibilità, se non cambiando lo scheduler di default, di eseguire passi di un singolo workflow in parallelo. Se vi state chiedendo come sia possibile allora avere una activity di tipo ParallelActivity o di tipo ListenActivity in un workflow ... ecco una brillante ed esaustiva risposta da parte del team di WF. In generale vi consiglio di leggere e monitorare l'intero blog.

Ora provate ad immaginare un workflow che utilizza una CallExternalMethodActivity per chiamare l'host e il codice dell'host, relativo alla CallExternalMethodActivity, che a sua volta utilizza un evento per richiamare il workflow, che ha una HandleExternalEventActivity definita.

Pensiamo al caso sequenziale:

Vi ricordo che il thread che esegue il workflow invoca l'host senza preoccuparsi della thread safety, quindi può chiamare ad esempio un'applicazione Windows Forms che faccia da host, senza utilizzare il thread di UI. Per questa ragione dobbiamo sempre preoccuparci di verificare se siamo o meno sul thread di UI prima di utilizzare eventuali informazioni ottenute dal workflow.

Pensate quindi che si crei un deadlock? Il workflow chiama l'host, l'host chiama il workflow, ma il workflow sta aspettando il "rientro" della chiamata verso l'host. Ovviamente no! La richiesta di far scattare un evento nel workflow, sbloccando la HandleExternalEventActivity, è intercettata dall'ExchangeDataService (servizio di WF Runtime preposto a gestire la comunicazione tra l'host e il workflow) ed è accodata su una coda che verrà gestita solo nel momento in cui il workflow sarà "pronto". In pratica mettendo un po' di tracing nel codice avremo una sequenza di questo tipo:

Pre-Method Invoke - Thread Id: 6 - Physical Thread Id 1128
Method Invoking - Thread Id: 6 - Physical Thread Id 1128
Method Invoked - Thread Id: 6 - Physical Thread Id 1128
Event Invoking - Thread Id: 6 - Physical Thread Id 1128
OnTestEvent Invoked - Thread Id: 6 - Physical Thread Id 1128
Post-Method Invoke - Thread Id: 6 - Physical Thread Id 1128
Event Invoked - Thread Id: 6 - Physical Thread Id 1128
Post-Event Invoke - Thread Id: 6 - Physical Thread Id 1128

In rosso sono i trace da dentro il workflow, mentre in blu i trace nell'host. Notate che tutte le righe sono relative allo stesso thread e che l'evento scatta (penultima riga) nel workflow, solo dopo che l'esecuzione del metodo dell'host è stata completata.

Questo comportamento "sincrono" è appunto dovuto al fatto che lo scheduler utilizza un unico thread per l'esecuzione del workflow.

Vediamo ora che succede con un workflow a stati, anziché sequenziale. Immaginiamo di avere il seguente flusso a stati:

La StateInitializationActivity dello stato iniziale si limita, per brevità, a rimandare il flusso nello stato successivo.

Da qui la StateInitializationActivity dello stato "IntermediateState" chiama l'host del flusso con una CallExternalMethodActivity, oltre a tracciare alcune informazioni a fini di debug.

Da qui il codice che viene invocato nell'host richiama il flusso, come spiegavo all'inizio del post. L'evento richiamato dall'host è proprio quello per cui sta in attesa l'evento eventDrivenActivity1 all'interno dello stato "IntermediateState".

Qui arriva il bello! Ci aspetteremmo un comportamento analogo a quello del flusso sequenziale: la coda prende in carico l'evento e quando il controllo torna al flusso la gestione riprende, proprio dall'evento. Invece no! Siamo nello fase di inizializzazione dello stato "IntermediateState" e le code dei suoi eventi non sono ancora state attivate, perchè potrebbe essere prematuro ricevere eventi senza che lo stato sia completamente inizializzato. Infatti in questo caso ecco il tracing estratto dal log.

Pre-Method Invoking - Thread Id: 7 - Physical Thread Id 4964
Method Invoking - Thread Id: 7 - Physical Thread Id 4964
Method Invoked - Thread Id: 7 - Physical Thread Id 4964
Event Invoking - Thread Id: 7 - Physical Thread Id 4964
OnTestEvent Invoked - Thread Id: 7 - Physical Thread Id 4964
A first chance exception of type 'System.Workflow.Activities.EventDeliveryFailedException' occurred in System.Workflow.Activities.dll
Exception - Thread Id: 7 - Physical Thread Id 4964
Event "TestEvent" on interface type "Test_WF_Events.ICommunication" for instance id "53b2d8c4-2cd0-4f66-a6b8-07b9b963332b" cannot be delivered.
A first chance exception of type 'System.Workflow.Activities.EventDeliveryFailedException' occurred in Use-Test-WF-Events.exe

Al solito il log rosso proviene dal workflow, mentre il log blu riguarda l'host. Come si vede ci prendiamo un bel EventDeliveryFailedException!
La InnerException ci spiega che si tratta in realtà di un errore di comunicazione perché l'evento TestEvent non può essere notificato (cannot be delivered).

Cercando con Google potreste trovare suggerimenti che consigliano di utilizzare un bel QueueUserWorkItem del ThreadPool per far scattare l'evento nel workflow. In pratica:

ThreadPool.QueueUserWorkItem(delegate(Object args) { OnTestEvent((ExternalDataEventArgs)args); }, e);

invece di:

OnTestEvent(e);

A prima vista sembrerebbe corretto, perché accodando l'invocazione dell'evento sul ThreadPool diamo un po' di "respiro" al thread che sta eseguendo l'istanza di workflow, così da consentirgli di uscire dall'host e rientrare nel flusso. Purtroppo però si tratta di una soluzione non corretta! Infatti mettere la notifica dell'evento nel ThreadPool sposta solo il problema. In alcuni casi infatti tutto funzionerà a meraviglia, in altri avremo comunque un errore, ma di natura diversa. Dipende dal carico della CPU o delle CPU. Infatti su sistemi multiprocessore il problema si enfatizza, perché abbiamo più cicli macchina a disposizione ed è più facile che il ThreadPool evada la richiesta di notifica dell'evento _prima_ che il thread rientri nel workflow. Per verificare sistematicamente il problema è sufficiente mettere una bella Thread.Sleep dopo l'accodamento dell'evento nel ThreadPool, per prolungare la permanenza del thread del workflow nel codice host.

ThreadPool.QueueUserWorkItem(delegate(Object args) { OnTestEvent((ExternalDataEventArgs)args); }, e);
Thread.Sleep(TimeSpan.FromSeconds(15));

Eccoci! A questo punto abbiamo creato un mostro :-) ! Ad ogni giro il workflow ci dirà che non è in grado di evadere l'evento e capiremo che la vera ragione è che le code sono appunto "disabled" come spiegavo alcune righe più sopra. Ecco l'errore:

Queue 'Message Properties Interface Type:Test_WF_Events.ICommunication Method Name:TestEvent CorrelationValues:' is not enabled.

Il ragionamento fila. Infatti se guardiamo con .NET Reflector possiamo notare che ad un certo punto il metodo SafeEnqueueEvent della classe WorkflowQueuingService verifica se le code sono enabled e se non lo sono scatena proprio questo tipo di eccezione.

// [... omissis ...]

if (!queueState.Enabled)
{

throw new InvalidOperationException(string.Format(CultureInfo.CurrentCulture, ExecutionStringManager.QueueNotEnabled, new object[] { queueName }));

}
queueState.Messages.Enqueue(item);

// [... omissis ...]

Come fare quindi? Possiamo osservare che tutti gli eventi che scattano dall'host verso il workflow richiedono un EventArgs particolare, di tipo ExternalDataEventArgs o da esso derivato. Questa classe prevede una proprietà WaitForIdle che fa proprio al caso nostro. Infatti sempre con .NET Reflector possiamo notare che l'evento EventHandler della classe WorkflowMessageHandler al suo interno verifica questa proprietà:

// [... omissis ...]

if (eventArgs.WaitForIdle)
{
wfInstance.EnqueueItemOnIdle(queueName, message, pendingWork, obj);
}
else
{
wfInstance.EnqueueItem(queueName, message, pendingWork, obj);
}

// [... omissis ...]

Nel caso in cui sia asserita, anziché evadere subito l'evento, lo accoderà in attesa che il flusso diventi Idle. In questo modo il flusso avrà tutto il tempo di concludere la chiamata all'host, qualunque sia il tempo richiesto, per poi passare la palla all'evento. Ecco il log delle fasi, nel caso in cui impostiamo correttamente il flag WaitOnIdle a true.

Pre-Method Invoking - Thread Id: 10 - Physical Thread Id 3248
Method Invoking - Thread Id: 10 - Physical Thread Id 3248
Method Invoked - Thread Id: 10 - Physical Thread Id 3248
Event Invoking - Thread Id: 10 - Physical Thread Id 3248
OnTestEvent Invoked - Thread Id: 12 - Physical Thread Id 3176
Post-Method Invoked - Thread Id: 10 - Physical Thread Id 3248
Event Invoked - Thread Id: 12 - Physical Thread Id 3176
Post-Event Invoked - Thread Id: 12 - Physical Thread Id 3176

Notate che in questo caso c'è il cambio di thread (a causa dell'accodamento nel ThreadPool) e che il giro si chiude correttamente. Rimane comunque consigliabile accodare nel ThreadPool l'evento di callback per non bloccare il codice chiamante, anche perché senza questo passaggio avremmo comunque un errore di delivery verso il nostro evento, in quanto andremmo a creare un deadlock. Infatti la situazione diventerebbe la seguente:

Il thread corrente accoda un evento, in sincrono, che aspetta che il flusso sia Idle prima di scattare
Il flusso, con quello stesso thread, sta aspettando che il metodo che esegue il codice precedente finisca, per poi completare l'inizializzazione dello stato e mettersi Idle

Risultato: deadlock! Quindi avremmo una EventDeliveryFailedException.

Ok quindi in questi casi occorre:

Definire WaitOnIdle = true
Chiamare l'evento in un thread secondario, ad esempio usando il ThreadPool

Nessuno dei due step precedenti risolve, da solo, il problema. Servono entrambi.

L'unica altra alternativa che abbiamo, ma non cambia il risultato finale, è definire nello stato "IntermediateState" un evento ad inizio immediato, tramite una DelayActivity con TimeoutDuration impostata a 0 (zero), anziché una StateInitializationActivity. In questo modo infatti le code del flusso, relative agli eventi dello stato, verrebbero attivate prima della chiamata all'host. In questo caso non è strettamente necessario impostare WaitOnIdle a true perché comunque il thread che evade i messaggi in coda è uno solo, quindi comunque dovremmo aspettare la fine del primo evento per poter proseguire.

Ecco lo schema dell'ultimo caso.

Direi comunque che la soluzione più idonea è quella di utilizzare il ThreadPool o comunque un thread secondario e il WaitOnIdle impostato a true, sfruttando - se serve - lo StateInitialization.

Per chi volesse "divertirsi" con queste cose rendo disponibile il progettino "grezzo" che ho usato per approfondire l'argomento. C'è da giocare un po' con i commenti nel codice per abilitare e verificare il comportamento di WF nei vari casi... se non torna qualcosa potete mandarmi una email.

Spero di aver dato una fotografia della situazione utile ad altri e vi rimando alle sessioni su WF che terrò alla nostra DevCon 2007 per ulteriori dettagli sul funzionamento di Windows Workflow Foundation, anche in progetti reali.