Con il Framework 3.0 esordisce in Windows una nuova infrastruttura che permette agli sviluppatori di creare, grazie ad un designer, una rappresentazione visuale di una logica applicativa. In questa introduzione vedremo come il ruolo di Workflow Foundation sia analogo a quello di un linguaggio che con i suoi statement provvede i mattoncini base per costruire un algoritmo. Una particolare attenzione verrà riposta nel prezioso meccanismo dei servizi del runtime di Workflow Foundation e naturalmente sulle Activity, il mattone fondamentale di questa infrastruttura.

2. Workflow Foundation
Email: malta@vevy.com
Blog: http://blogs.ugidotnet.org/raffaele
MVP Profile: http://mvp.support.microsoft.com/profile/raffaele
Visual Developer Security MVP
Raffaele Rialdi, Vevy Europe

4. Risposta istituzionale
• Una delle quattro tecnologie che formano il fx 3.0
– WPF, WCF, WF, Cardspace
• Una infrastruttura per modellare la logica di business
di una applicazione
• Una tecnologia che permette di gestire un processo
secondo un flusso sequenziale (workflow) oppure
una macchina a stati (state machine)
• È managed!

5. Risposta tecnologica
Workflow
Foundation
è un DSL
10 Print "Hello, world"
HW db 'Hello, world', 0dh, 0ah, 0
...
mov ah,9
mov dx, HW
int 21h
class MyApp {
static void Main(){
Console.WriteLine("Hello, world");
}
}
DSL
Domain
Specific
Language
GPL
Generic
Programming
Language

6. I concetti base di Workflow Foundation
• Le istruzioni di questo linguaggio si chiamano Activities
• Le Activities sono classi
– Si possono creare custom Activities da zero, per
inheritance o composition
• Le Activities sono soggette a diverse validazioni
– logica (email) e/o funzionale (collocazione)
• Alle Activities sono abbinabili una UI, un designer e un
tema
• Le Activities condizionali valutano delle regole definite
nel sistema

7. Due domini di lavoro preconfezionati di
Workflow Foundation
• Workflow sequenziale e Macchine a stati
– Logica differente, designer differente
– Sono loro stessi delle Activities (composite)
• Workflow sequenziale
– rappresenta una sequenza di istruzioni, cicli e
condizioni
– non è un flowchart classico, non prevede "goto"
– designer abbastanza intuitivo
• Macchine a stati
– rappresenta la logica che esplicita i possibili stati di un
problema ed il modo in cui avviene la transizione tra
gli stati

9. Una possibile architettura
ClientTest
(Winform)
ConsoleServiceHost
(Console)
SubscriptionService
(WCF Service)
SubscriptionWorkflowLibrary
(Workflow)
ExternalDataExchange
Windows
Service
IIS
worker
process
Asp.net
WebApp
WPF
Client
Proxy WSDL

11. Usare Workflow Foundation
• I Workflow hanno bisogno di uno speciale runtime
per lavorare
• Scegliere il Processo/AppDomain che hosta il runtime
e istanziarlo
• Creare il workflow desiderato
• Aggiungere al Runtime i servizi necessari (0+)
– funzionalità addizionali di Workflow
• Avviare una o più istanze di workflow
• Gestire l'evento di termine del workflow
– opzionale

12. Applicazione host
Architettura
Activities
Structured
Activity Framework
Workflow Runtime
Runtime Services
Custom
Activities
Visual Studio Workflow Designer Custom Designers
State Machine Rules
Loader Persistence Threads Transactions Tracking
Validation
Transactions
Compilation Serialization Visualization
Fault Handling Cancellation Compensation
Scheduling Instance Mgmt
…

13. Workflow Foundation e Visual Studio
27/08/2014 www.xedotnet.org 13

14. Gli strumenti forniti da WF
• Un runtime engine
– gestisce l'esecuzione, lo stato, il tracking, le update
• I servizi di base
– la comunicazione, la persistenza, il tracking, lo scheduling, le transazioni, ...
• Una API managed
– permette al developer di interagire con l'engine e i servizi
• Una libreria di Activity base
– Classi di Activity usabili "as is" oppure espandibili via ereditarietà o
composition
• Un designer integrato con VS2005
– Ogni azione sul designer ha una corrispondente porizione di codice o di
markup dichiarativi
• Un debugger integrato con VS2005
– Step-by-step debugging sul disegno del workflow

15. Due modi per scrivere un Workflow
• Descritti in codice
– Normali classi derivate da
SequentialWorkflowActivity oppure da
StateMachineWorkflowActivity
– Default per il wizard di VS2005
– Usa una partial class di C#2.0 / VB.net 2.0
• Espressi in XML
– Usano il nuovo XAML
– Si aggiunge con Add – New Item di VS2005

16. XAML e WF
• XAML non è WPF
– Esistono diversi formati di XAML:
WPF, WF, XPS, Silverlight, ... ognuno il suo!
• XAML è un linguaggio che permette di rappresentare
un grafo di oggetti
– I tag XML di XAML sono il risultato della serializzazione degli
oggetti in memoria
• WF usa l’estensione XOML ma il linguaggio è lo stesso

17. Dependency Properties e Binding
• WF usa in modo estensivo le Dependency Properties
– Crea una proprietà statica
– La associa alle istanze in un Dictionary statico
• Vantaggi:
– Notifica automatica al cambio di valore (ai subscribers)
– Binding via ActivityBind
– Default values
– … public string Name
{
get { return (string)GetValue(NameProperty); }
set { SetValue(NameProperty, value); }
}
public static readonly DependencyProperty NameProperty =
DependencyProperty.Register("Name", typeof(string), typeof(Add));

18. Markup e Code Workflow
.NET assembly
• ctor definisce
il workflow
Solo Markup
“Dichiarativo”
XAML
Mix di Markup
e Codice
C#/VB
Solo Codice Application
Generated
XAML C#/VB
XML definisce
la struttura logica
del workflow e
il flusso di dati
XML definisce il
Workflow
Code-beside
la logica restante
Codice crea il
workflow
nel costruttore XAML C#/VB
App crea le Activity
e le serializza
Compilatore Workflow
wfc.exe
Compilatore C#/VB

19. Quando conviene il modello dichiarativo?
• Vantaggi
– è xml e quindi modificabile a runtime
– è xml e quindi persistibile come risorsa
• dentro un db, in un file, etc.
• Svantaggi
– nel file xoml niente dichiarazione di proprietà
– nel file xoml niente codice
– si risolve usando una partial class (code beside)

20. Quando conviene il modello dichiarativo?
• Vantaggi
– può comunque essere usato con il 'code beside'
– è xml e quindi modificabile a runtime
– è xml e quindi persistibile come risorsa, dentro un db, in un file, etc.
– WorkflowRuntime.CreateWorkflow(XmlReader) salta lo step di
compilazione. La serializzazione di questo risultato è l'unico che
comprende l'intero workflow (children compresi)
• Esempio SerializeWF
• Svantaggi
– non permette la dichiarazione di proprietà nel file xoml
– non permette di scrivere / associare codice dentro il file xoml
– in entrambi i casi è possibile risolvere usando una partial class

21. Workflow sequenziale
• Tramite designer (opzionale) si definisce una sequenza di
Activities
– Questo passo definisce una nuova classe che rappresenta il workflow
vero e proprio
• Si istanzia il runtime di WF
– WorkflowRuntime workflowRuntime = new WorkflowRuntime();
• Si istanzia e si esegue il workflow
– WorkflowInstance instance1 = workflowRuntime.CreateWorkflow(
typeof(PersistenzaXoml.Workflow1));
– instance1.Start();

22. SimpleBinding: dependency property, debugger

23. Workflow come blackbox
WorkflowRuntime wr = new WorkflowRuntime();
wr.StartRuntime();
Dictionary<string, object> parameters =
new Dictionary<string, object>();
parameters.Add("FirstName", txtFirstName.Text);
parameters.Add("LastName", txtLastName.Text);
WorkflowInstance instance = wr.CreateWorkflow(
typeof(MyWF.Workflow1), parameters);
instance.Start();
Parametri in ingresso Parametri in uscita
wr.WorkflowCompleted += OnWfCompleted;
// ...
static void OnWfCompleted(object sender,
WorkflowCompletedEventArgs e)
{
string Status =
e.OutputParameters["Status"] as string;
Console.WriteLine("Status is " + Status);
}
(prima dell'esecuzione) (al termine dell'esecuzione)
Workflow
Elenco di tutte le proprietà
esposte dal nostro workflow

24. Punti di attenzione
• Il runtime / workflow condividono lo stesso AppDomain
dell'applicazione
– Un solo runtime per AppDomain
• Con lo scheduler di default ogni istanza di workflow gira in un
thread a se stante
– necessario per rispettare i tempi e gli eventi definiti nel workflow
– complica la comunicazione e la sincronia con l'applicazione host
• Con lo scheduler Manuale gira tutto nel thread da cui è stato
instanziato il runtime
– ManualWorkflowSchedulerService
• I parametri di ingresso e uscita al workflow sono sempre passati
come object

26. Workflow e servizi
• I servizi di WF sono pluggabili
– questa architettura permette l'espandibilità futura dell'infrastruttura di
Workflow
• Alcuni esempi:
– ExternalDataExchangeService (comunicazione tra host e workflow)
– WorkflowSchedulerService (scheduler di default)
– ManualWorkflowSchedulerService (scheduler su singolo thread)
– WorkflowPersistenceService
– TrackingService
– WorkflowTransactionService
– Custom (derivato da WorkflowRuntimeService)
– WorkflowCompilerOptionsService
– ToolboxService
– ......

27. Persistenza -
SqlWorkflowPersistenceService
• Il runtime può scaricare dalla memoria i workflow
– in automatico
• sull'evento di Idle entrando in una Delay Activity
• al completamento di ActivityExectionContext
• al completamento di TransactionScopeActivity
• al completamento di una Activity decorata con PersistOnClose
– in manuale, chiamando Unload (blocking) o TryUnload (non blocking)
• I workflow vengono ricaricati in memoria
– in automatico, anche come conseguenza di un timer (Delay Activity)
– in manuale, chiamando Load o runtime.GetWorkflow(InstanceId)
• Lo stato di persistenza è consistente
– È possibile riattivare un workflow anche da un processo differente
– È resistente ad un crash/recycle del processo

28. Persistenza -
SqlWorkflowPersistenceService
• Creare un db (o selezionarne uno già pronto)
• Eseguire gli script
– C:WINDOWSMicrosoft.NETFrameworkv3.0Windows Workflow FoundationSQLEN
• Aggiungere il servizio
WorkflowRuntime runtime = new WorkflowRuntime();
NameValueCollection pars = new NameValueCollection();
pars.Add("connectionString", ConnectionString);
pars.Add("unloadOnIdle", "true");
SqlWorkflowPersistenceService SqlPersistence =
new SqlWorkflowPersistenceService(pars);
runtime.AddService(SqlPersistence);

29. Persistenza

30. Tracking service
• Permette di registare una sorta di LOG su ciò
che accade nell'istanza del nostro workflow
– creazione, idle, custom, ...
• Si possono aggiungere annotazioni al log
• Si possono eliminare informazioni indesiderate
– TrackingProfile
• L'esempio WorkflowMonitor dell'SDK funge da
viewer su qualsiasi workflow leggendo il DB

31. Tracking - SqlTrackingService
• Creare un db (o selezionarne uno già pronto)
• Eseguire gli script
– C:WINDOWSMicrosoft.NETFrameworkv3.0Windows Workflow FoundationSQLEN
• Aggiungere il servizio
WorkflowRuntime runtime = new WorkflowRuntime();
SqlTrackingService tracking = new SqlTrackingService(CnnStr);
runtime.AddService(tracking);

32. Tracking – leggere le informazioni
• Non c'è bisogno di fare query sul DB
– WF espone un object model!!!
SqlTrackingQuery track = new SqlTrackingQuery(CnnString);
SqlTrackingWorkflowInstance WfInstance = null;
track.TryGetWorkflow(instanceId, out WfInstance);
// ...
foreach (ActivityTrackingRecord atr in WfInstance.ActivityEvents)
{
Console.WriteLine("Status: {0}", atr.ExecutionStatus);
Console.WriteLine("Date: {0}", atr.EventDateTime);
Console.WriteLine("Name: {0}", atr.QualifiedName);
}
// ...
Disp. anche
...WorkflowEvents
Oppure
GetWorkflows(...)

33. Tracking - Eventi utente
• La classe Activity espone il metodo TrackData
• La stringa/blob viene registrata nella tabella
UserEvent
• SqlTrackingWorkflowInstance espone anche la
proprietà UserEvents per recuperare queste
informazioni

34. Tracking – Manutenzione DB
• Il DB non è di dimensione infinita 
• Sistema 1
– Ricreare il DB ... decisamente drastico
• Sistema 2
– Partitioning delle informazioni:
• http://blogs.msdn.com/moustafa/archive/2006/03/23/559391.aspx
• http://msdn2.microsoft.com/en-us/library/aa349365.aspx

35. Tracking

36. ExternalDataExchangeService:
Interattività tra workflow e host
Thread 1 Thread 2
ExternalDataExchangeService ds = new
ExternalDataExchangeService();
_Runtime.AddService(ds);
MyService svc = new MyService();
// informiamo WF del nostro servizio
ds.AddService(svc);
public class MyService : IMyService
ExternalDataExchangeService è un contenitore dei servizi di comunicazione

37. Comunicazione con ExternalDataExchangeService

38. ExternalDataExchangeService: Interattività tra
workflow e host
1. Definire una Interfaccia e marcarla con [ExternalDataExchange]
– Dichiarare gli eventi per comunicare verso WF
event EventHandler<MyEventArgs> Foo;
– Dichiarare metodi per comunicare verso l'host
void FromWorkflow(string Message);
2. Implementare l'interfaccia in una classe
– la UI va aggiornata via Invoke
3. Scrivere una classe (marcata con Serializable) che deriva da
ExternalDataEventArgs per passare dei parametri
4. Gestire nel workflow i messaggi in ingresso con
HandleExternalEventActivity
5. Spedire messaggi verso l'host con CallExternalMethodActivity
6. Nel caso di invocazione parallela di eventi, i parametri possono essere
correlati tra loro tramite l'attributo CorrelationParameter

40. Le Activity
• Sono il "mattoncino" base di WF
– System.Workflow.ComponentModel.Activity
• Ci sono tre tipologie di Activity
– Basic: semplici nodi di un programma
• SendMail, call WebService, etc. etc.
– Composite: contenitori che consentono di
modellare e coordinare le activity base
• SequentialActivity. ParallelActivity, ...
– Root: Activity speciali che costituiscono una unità di
attivazione
• Microsoft ne fornisce due:
– SequentialWorkflowActivity
– StateMachineWorkflowActivity

41. Nozioni base sulle Activity
• Le Activity sono classi:
– Proprietà ed eventi sono definite dal suo autore e
programmabili dai workflow che le usano
– Espongono metodi that are scritti dal suo autore
ma invocati dal workflow runtime (per esempio
'Execute') o dal designer
– Possono far parte dello stesso assembly in cui è
definito il workflow oppure (meglio) redistribuite in
assembly a se stanti e riutilizzabili
• Per esempio la code activity …

42. CAG: Conditioned Activity Group
• Esegue un loop per tutte le Activity
contenute fino a che la UntilCondition
della CAG vale true (con true, termina)
• Ciascuna Activity contenuta riceve
una nuova WhenCondition
– Se la WhenCondition è usata, l'Activity sarà
eseguita ogni volta che questa vale true
– Se non c'è WhenCondition, l'Activity sarà
eseguita solo una volta
• Se non viene specificata una UntilCondition, la CAG termina
quando tutte le Activity valutano a false la loro WhenCondition

43. Replicator Activity
• Esegue n istanze delle Activity
contenute fino a che la UntilCondition
vale true (con true, termina)
• Se la UntilCondition viene omessa, le
Activity vengono eseguite una volta
• L'esecuzione può essere seriale o parallela (ExecutionType)
– Dentro ChildInitialize si popola la collection che determina il numero di
istanze che il replicator creerà
– ChildCompleted viene chiamato a conclusione di ciascuna istanza
– Completed viene eseguito al termine di tutte le istanze

44. Gli errori

45. Tipologie di errori
• Tramite la ThrowActivity
• Fallimento di una transazione
– timeout di una transazione atomica
– fallimento correlato alla transazione stessa
• Eccezione nel code-beside
• Eccezione dell'infrastruttura
– Servizi di persistenza, collegamento con un db
– Eccezione di sistema di dotnet

46. Gestire le eccezioni
• FaultHandlerActivity
– Corrisponde allo statement “catch”
– Una FaultHandlerActivity per ogni tipo di eccezione
da gestire
– Permette di eseguire una sequenza di Activity
• CancellationHandlerActivity
– Corrisponde allo statement “finally”

47. Rules

48. Le "Rules" (regole)
• Le regole in WF
– Permettono di modellare più facilmente la logica
– Rendono più semplice la comprensione della
logica del sistema
– Permettono di eseguire modifiche in modo
semplice e comprensibile
– Sono serializzate in XML
• È possibile cambiare le regole a runtime

49. Rule / Ruleset editor

50. RuleSet
• Due dialog usabili anche fuori da WF:
– RuleSetDialog
– RuleConditionDialog
• Sono in preparazione Dialog ancora più
specializzate
– Ad esempio BizTalk ha un suo custom editor

51. Policy Activity
• Applica le regole definite in un RuleSet
– Il RuleSet è una collection di regole (Rule)
– Logica: If <condizione> Then <Azione1> Else <Azione2>
– Ogni Rule ha una priorità (positive o negative).
La più alta viene eseguita per prima. Il default è zero.
• Ogni Azione
– può impostare una proprietà, un membro o chiamare un metodo
– eseguire un Halt (fermare la policy) o un Update (rivalutare le espressioni)
• Ogni regola
– può essere attivata / disattivata (proprietà Active)
– ha una proprietà ReevaluationBehavior (che vale Always o Never) che determina
se la regola può essere rivalutata (la regola precedente può aver modificato un
membro che fa parte della condizione di questa regola)
– Il Chaining determina la politica di rivalutazione delle condizioni delle regole. Ad esempio
Full Chaining implica l'autorivalutazione.

52. Activity base di "regole"
• IfElse: branch classico if/else
• While: esegue un loop
• Replicator: esegue più volte una stessa Activity
• CAG: Condition Activity Group. Esegue delle Activity in modo
condizionale
• Policy: esegue delle 'azioni' a fronte delle priorità delle regole
contenute nel ruleset
– può impostare una variabile membro o proprietà
– chiamare metodi
– Halt o Update del ruleset

54. Custom Activities: perché?
• Per costruire in modo visuale ed a blocchi la
logica dell'applicazione
• Per scomporre il problema in sottoproblemi
• Activity 'esecutive'
– Eseguono codice, query su db, chiamate a WS, etc.
etc.
• Activity di 'scambio dati'
– Derivando HandleExternalEventActivity
– Derivando CallExternalMethodActivity
– Tool WCA

55. Anatomia di una activity
• Definizione. L'insieme di proprietà ed eventi
che costituiscono lo stato dell'Activity
• Esecuzione. Il comportamento dell'activity, cioè
la "logica"
• Validazione. Le regole per il controllo dei
parametri
• Design. La classe che è responsabile del
rendering sulla superfice designer
• Toolbox. Il comportamento quando viene
inserita nel designer

56. Activity Component Model
• Alle Activity si associano dei componenti tramite attributi
• Questi componenti definiscono il comportamento:
– sul designer
– per la validazione dei dati
– durante la serializzazione (workflow di lunga durata)
Richiesto Opzionale
[Designer(typeof(MyDesigner))]
[Validator(typeof(MyValidator))]
public class MyActivity: Activity {...}
Activity
Designer
Validator
Serializer
Services

57. Modello di esecuzione della Activity
È possibile fare l’override di questi metodi
• Initialize()
• Execute()
• Cancel()
• Compensate() (se implementa ICompensatableActivity)
Transizioni possibili
Activity
Runtime
Initialized Executing Closed
Canceled Compensating

58. Esempio: la CodeActivity
// nel workflow ...
private void CodeActivity1_ExecuteCode(object sender, EventArgs e)
{
...
}
protected sealed override ActivityExecutionStatus Execute(ActivityExecutionContext ctx)
{
base.RaiseEvent(CodeActivity.ExecuteCodeEvent, this, EventArgs.Empty);
return ActivityExecutionStatus.Closed;
}

59. Esecuzione di una Composite Activity
Composite Activity
..
..
..
+= OnChildClosed
+= OnChildClosed
Execute()
Status.Closed()
Child
Activity
Child
Activity

60. Activity Execution Context
Template Activity
Context Owner Activities
Ad ogni loop viene creato un contesto
differente che consente l'eventuale rollback
Context 1
Context 2
Context 3
Default Workflow
Context

62. Validazione
• Ci sono diversi tipi di validazioni:
– Validazione dei parametri
• La più usata ovviamente
– Validazione della sequenza delle child Activity
• Usata dalle Activity composite
– Validazione della posizione del "SetState"
• Usata dalle macchine a stati
– Validazione delle CallExternalMethodActivity
• Utile per chi deriva questa classe
– Validazione delle HandleExternalEventActivity
• Utile per chi deriva questa classe

63. ActivityValidator, ActivityCompositeValidator
public class MyValidator : ActivityValidator
{
public override ValidationErrorCollection ValidateProperties(
ValidationManager manager, object obj)
{
ValidationErrorCollection errs = new ValidationErrorCollection(
base.ValidateProperties(manager, obj));
Activity1 act = obj as Activity1;
if(act.HisName != null && act.HisName.Length == 1)
errs.Add(new ValidationError("HisName cannot be 1 char", 1));
return errs;
}
}
[ActivityValidator(typeof(MyValidator))]
public partial class Activity1 : Activity
{
...
}
Activity da
validare

64. Quali proprietà validare?
• ValidationOption.None
– Nessuna validazione
• ValidationOption.Optional
– Sono accettati i null
• ValidationOption.Required
– Validazione obbligatoria
[ValidationOption(ValidationOption.Required)]
public string EmailAddress
{
get {...}
set {...}
}

66. Concetti base
• È composta da un
insieme di stati
• In ogni stato
attende degli eventi
• Abbinato a ciascun
evento si avviano
delle azioni e/o una
transizione ad un
nuovo stato
S1 S2 S3
S4
S5

67. Activity presenti solo nelle macchine a stati
• State: rappresenta uno degli stati in cui può
essere la macchina
• StateInitialization: permette di
inizializzare un particolare stato
• StateFinalization: permette di disporre
le risorse prima che lo stato venga
abbandonato
• SetState: esegue la transizione ad un altro
stato
(*) eda = Event Driven Activity

68. Macchine a stati o Workflow sequenziali
• Workflow Sequenziali sono preferibili quando
– le possibilità di passare da uno stato all'altro sono
limitate
– l'interazione con un essere umano è limitata
• Macchine a stati
– c'è una vasta scelta di possibili cambi di stato
– ci sono eventi comuni a tutti gli stati che
provocano la transizione allo stesso stato

69. Macchina a stati

71. Performance
• L'infrastruttura di Workflow Foundation fornisce
tanti vantaggi ma ha un costo
• Se l'interazione con l'essere umano è alta, il costo
in performance di WF diventa indifferente
• Paradossalmente, usare WF per un algoritmo
matematico sarebbe terribilmente oneroso
– parametri passati per object
– uso di reflection
• http://msdn2.microsoft.com/en-
us/library/aa973808.aspx

73. Scenario 1: Applicazione Winform / WPF
• Runtime nello stesso AppDomain
• DefaultWorkflowSchedulerService ok
– ExchangeDataService deve usare Invoke sulla form
• ManualWorkflowSchedulerService sconsigliato
– può bloccare inutilmente la UI
• Scenari di esempio:
– Macchina a stati per la gestione della UI
– Sequenziale per la business logic

74. Scenario Asp.net – elementi comuni
• Configurazione
• Runtime parte e si ferma insieme ad Application
– Global.asax oppure un HttpModule
<configuration>
<configSections>
<section name="WorkflowRuntime"
type="WorkflowRuntimeSection,
System.Workflow.Runtime" />
</configSections>
....

75. Scenario 2: Asp.net, durata inferiore alla
pagina, stesso AppDomain
• DefaultWorkflowSchedulerService sconsigliato
– Ciclo di vita della pagina è breve, WF è asincrono
– Asp.net ha un set di thread limitato
• ManualWorkflowSchedulerService ok
– Pagina e workflow sincroni
– 1 thread per ogni istanza di Workflow

76. Scenario 3: Asp.net, durata superiore alla
pagina, stesso AppDomain
• Runtime parte e si ferma insieme ad Application
– Global.asax oppure un HttpModule
• DefaultWorkflowSchedulerService
– Se l'istanza dei workflow è condivisa tra tutte le
richieste
• Usabile solo per poche istanze di workflow
• Scenario poco realistico
– Il riciclo + Idle timeout dei worker process
– ThreadAbortException sui thread che fanno lavorare il
workflow durante il riciclo o idle timeout (timer, ...)

77. Scenario 4: Asp.net, Workflow pubblicato
come WS
• Conseguenza del "Publish as a web service"
– Il Workflow deve essere compilato (no XOML
dinamico)
– AppDomain differente
– Servizi aggiunti via web.config
• DefaultWorkflowSchedulerService ok
• Problemi derivati dal riciclo + Idle timeout dei wp
• Poco controllo sul WS

78. Scenario 5: Workflow hostato manualmente in
IIS, espone servizio WCF / WS
• Come scenario 4 ma ...
– Richiede pubblicazione manuale
– Molto più versatile (controllo completo)
– Consente Workflow dinamici (XOML)
• Uso di HandleExternalEvent al posto delle WS
Activities
– Migliore riuso del Workflow!
• Posso usare WCF
– Scelta migliore e più semplice rispetto al WS
• Problemi derivati dal riciclo + Idle timeout dei wp

79. Scenario 6: Workflow hostato in WinService,
espone servizio WCF
• Richiede più codice
– Ma lo scheletro è standard
– Orcas ci aiuta molto nell'integrazione con WCF
(questa è la strada giusta)
• Non beneficiamo dell'Health Management di IIS

80. Una possibile architettura
ClientTest
(Winform)
ConsoleServiceHost
(Console)
SubscriptionService
(WCF Service)
SubscriptionWorkflowLibrary
(Workflow)
ExternalDataExchange
WSDL
Windows
Service
IIS
worker
process
Asp.net
WebApp
WPF
Client

82. Integrazione WCF + WF
• Si può esporre WF direttamente come servizio
• Non sono più necessarie HandleExternEvent e
CallExternalMethod tra WCF e WF
• Una montagna di codice in meno
• Il binding speciale wsHttpContextBinding consente di
indirizzare uno specifico servizio
– Utile ad esempio per indirizzare alla chiamata WCF l'ID del
Workflow già attivo all'interno del servizio
– Analogo del Correlation Token

83. Scenario semplificato
Asp.net
Host
WCF

84. Servizi WCF che espongono Workflow
• Supportati i workflow che durano di più della chiamata WCF
• Il contratto WCF viene gestito con 1+ ReceiveActivity
– Le sue child activity vengono chiamate prima del termine del metodo
del servizio
• Scambio dati: one-way e request-response
• Supportati gli scenari: workflow-first o contract-first

85. Workflow che usano servizi WCF
• SendActivity invoca un servizio WCF
WCF
SendActivity

86. DurableService
• Decorando un metodo di un servizio del Workflow
con [DurableServiceAttribute] il suo stato viene
persistito al termine dell'esecuzione
– Provider SQL pronto all'uso
– Ottima soluzione anche per WCF senza WF

87. Host di Servizi
• WCFWorkflowServiceHost (che deriva da
ServiceHost) gestisce l'hosting del servizio con
Workflow
• Visual Studio Orcas provvede l'auto-hosting!!!
WorkflowServiceHost wsh = new WorkflowServiceHost(typeof(MyWorkflow));
wsh.Open();
Console.WriteLine("Press <Enter> to Exit");
Console.ReadLine();
wsh.Close();