Chapter 3 – Activity Execution

The chapter re-enforces the concepts already introduced and gives the process the name of Activity Automaton. There are a number of ideas/concepts introduced and a fair amount of example to code (I like to actually write and test the code myself). The chapter is good and in theory you could probably start the book here. It does suffer from an ordering problem, i.e. it will describe or show some code that is introduced later in the chapter. E.g. one sample shows an Activity using a TimerService. The TimeService is show a couple of pages later. Nothing terrible about that but there is no reason why the TimerService couldn’t have been show first. There was one example that annoyed me, where the authors ask you to implement  n workflow XOML using a property mechanism that won’t be introduced until chapter 7! Anyway these are tiny points in another excellent chapter.

Notes:

Scheduling – The schedule dispatches Work Items one at a time from a FIFI queue (not to be confused with the WF Program queues). A Work Item is a delegate pointing to a WF activity in a specific program instance.

The basic Activity Automaton consists of an activity going through the following phases – Inialized -> Executing -> Closed

The Scheduler moves an activity into Executing and the WF Program processes the activity.

ActivityExecutionContext – available to the "Events" or phases and can be considered as the provider/gateway to services. It is disposable between calls so don’t cache it!

Using base.Invoke to create a bookmark and ask for resumption. This yields control back to the Scheduler for continuation at some point (hopefully soon).

NB. If you queue an item in the program queue and the runtime finishes then the queue must be passiavated (persisted to store) or an exception is raised.

WF Program Queues are on a per program instance so a program queue called myQueue can exist multiple times but
the queue is not shared across program instances.

Wait Activity – An activity (using a TimerService) that creates a queue via a specific id. The activity then "waits"
for the service to queue (EnqueueItem) the timer tick and it wakes up, does what it needs to do and deletes the queue.

Passing the runtime into a service in order to hide more of the implementation, i.e. hiding the interaction with the
queue.

Phases/States:
Initialize –
CreateWorkflows calls the initialize of all the contained activities, only after all of them been called
(and returned) does the worflow start in earnest. Remember no ExecutionContext exists during Initialize.
A good use is to create workflow queues, and remove them in Unintialize.

Unitialize – clean up resources allocated in Initialize
OnClosed – clean up resources allocated during the running of the activity

Closed state – before the workflow delivers a work item to an activity it checks the state of the activity. If the activity is closed the item is simply discarded.

DataBound properties exist outside of a running activity, e.g. a bit like maintaining state even after an activity has closed.

Threads:
Assume that every work item is run on a different thread, i.e. don’t rely on TLS (Thread Local Storage).
One CLR thread per WF Program.

Synchronization – Synchronization of activities can be achieved using the SynchronizationScopeActivity which uses a common key (or SynchronizationHandles) to denote those activities that should be run one at a time. If any acivities share a handle (including their nested/child activities) then they will be considered as requiring synchronization and will not be run at the same time (pseudo concurrency).

WF Programs
Now we’re introduced to the WF programming model by implementing the more abstract examples in Chapter 1 into actual WF classes. The basic elements are explained including;

• Activity – the basic element, analogous to a program statement
• ActivityExecutionContext – a bit like a thread or transaction context, that spans the episodic(!) code. It allows the activity to access the workflow services relevant to it
• WorkflowQueuingService – Provides (so far) core services for communication with and shelving (or persisting) the activities
• Program Queue – the gateway where external code can put data into the queue that then influences or stimulates the activities to read from the queue and process the data
• Composite Activity – an activity that contains other activities, used to create control workflows, e.g. sequence analogous to a program block
• WF Program – hierarchy of activities, declaratively represented in XAML
• Binding – a way to declare the property of one element is the input to another
• How to host a WorkflowInstance via XmlTextReader-ing the XAML
• Passivation – (the words I’m learning) when WF program becomes inactive (waiting) the WF runtime can persist to a store. It can then be resumed – maybe on a different machine (hinting to the scalability) – via the instance Id.

The chapter is good but not without some minor issues. To re-enforce the concepts I decided to implement them, only the order of implementation is mixed up. Like I say, a minor point. It would also be nice to add a few comments to the code examples, maybe I’ll publish my code as a sample soon. I’ve go a feeling the next chapter is going to step up some with ‘Activity Automaton’.

I’ve been very interested in Windows Workflow Foundation (WF) for some time but I’ve not been able to devote any time to it. I really believe I could use it to solve a number of technical issues that I work with every day. So I’ve finally grabbed the WF bull by the horns and purchased, "Essential Windows Workflow Foundation – Dhama Shukla, Bob Schmidt". I chose this book because of the authors involvement in the product and that it promises to be a real in-depth view of the subject. Rather than wait until I’ve finished reading the book I thought I’d blog on per chapter basis, so here goes…

Chapter 1 – Deconstructing WF
This is easily the strangest introduction to a technical book I’ve seen in a while, but it is very clever. The chapter makes almost no reference to WF at all, if at all. The chapter introduces the idea of a reactive program – one that requires some outside stimulus to complete. It follows the progress of a very simple read/write console application through its evolution into a scalable, robust and thread/process agile application via a type of bookmark pattern. The chapter finished by explaining how the c# example can be represented in other declarative formats (obviously paving the way to the WF XAML) including graphical representations (obviously paving the way to the WF designer).

The chapter is very interesting and the example code is reminiscent of the transaction scope implementation, i.e. striving to remove the complexities of managing the underlying framework from the developer. I did find it difficult to read because I’m chomping at the bit to get started and I must admit I did use a dictionary on at least two occasions only to discover the words were not in there! But hey now I can use elide and isomorphic in everyday conversation, I know I need to get a new dictionary and I understand the basic pattern underlying WF – not bad for one chapter.