Last time around in Part 3, I promised to return for a part 4 on Services and Hosting. One of the best features of WF is that the runtime is very lightweight and simple. WF was designed to be hosted by your application. It's host can be as simple or complex as you want (or need). It just needs to be hosted in an AppDomain. The better part of that, in my opinion, was the decision to keep the keep the preloaded services to an absolute minimum. Instead, the WF Runtime allows you to optionally register services with the runtime. You develop custom services that matter for your app and and add them to the runtime. This provides an extensible way to modify the behavior of the runtime. WF defines a core set of services that handle persistence, thread scheduling, workflow tracking, and transactions (some are optional). Everything is plugabble and you are in control.

Note that this is completely different than Local Services, which I talked about in Part 2. By the way, I have learned a lot since then, including not to use them/EDS and use the WorkflowQueuingService instead but that is a story for another day. In essence, the WF runtime is a container of Services and activities get the services they need by reaching up into the ApplicationExecutionContext via the GetService method. Services are simply added using the AddService method available on the WorkflowRuntime class:

using (WorkflowRuntime workflowRuntime = new WorkflowRuntime()) { ManualWorkflowSchedulerService schedulerService = new ManualWorkflowSchedulerService(true); workflowRuntime.AddService(schedulerService); workflowRuntime.StartRuntime(); ManualWorkflowSchedulerService schedulerService = workflowRuntime.GetService<ManualWorkflowSchedulerService>(); if (schedulerService != null) { schedulerService.RunWorkflow(id); } }
  

The WF Runtime does have a standard set of services to help it manage workflow instances, which are sometimes known as the WF Runtime Services:

• WorkflowLoaderService
• WorkflowSchedulerService
• WorkflowPeristenceService

These are abstract clases which allow multiple concrete implementations to be written and interchanged without affecting the WF Runtime. There is a DefaultWorkflowLoaderService and a DefaultWorkflowSchedulerService. There is no default for Persistence and only a SqlWorkflowPersistenceService in the box. My teammate,Steve Eichert, talks about our work that we are doing for an Oracle persistence service as well as some good links.

The WorkflowRuntime class has a whole bunch of methods to deal with creating and managing WF instances. The most important of these is the CreateWorkflow method which returns to you a in-memory handle to the actual WF instance. Some of the overloads of this method take in an XmlReader, to read the workflow definition in XAML. Some take a Type representing the .NET type of the workflow. In either case, they use the WF program loader service which takes either form and produces an activity tree of the workflow. Shulka and Schmidt call this activity tree the "WF program prototype." The following code, from a Microsoft sample shows an implementation of loading in XAML into memory:

protected override void PerformLoad(IDesignerSerializationManager serializationManager) { base.PerformLoad(serializationManager); IDesignerHost designerHost = (IDesignerHost)GetService(typeof(IDesignerHost)); // get the root activity and add the corresponding object graph to the designer host XmlReader reader = new XmlTextReader(this.xoml); Activity rootActivity = null; try { WorkflowMarkupSerializer xomlSerializer = new WorkflowMarkupSerializer(); rootActivity = xomlSerializer.Deserialize(reader) as Activity; } finally { reader.Close(); } if (rootActivity != null && designerHost != null) { AddObjectGraphToDesignerHost(designerHost, rootActivity); Type companionType = rootActivity.GetValue(WorkflowMarkupSerializer.XClassProperty) as Type; if (companionType != null) SetBaseComponentClassName(companionType.FullName); } designerHost.Activate(); // Read from rules file if one exists string rulesFile = Path.Combine(Path.GetDirectoryName(this.xoml), Path.GetFileNameWithoutExtension(this.xoml) + ".rules"); if (File.Exists(rulesFile)) { StreamReader rulesReader = new StreamReader(rulesFile); this.tempRulesStream = new StringBuilder(rulesReader.ReadToEnd()); rulesReader.Close(); } }
  

 You usually don't need anything as complicated as this as you can just pass your workflow type into CreateWorkflow and be done with it:

public WorkflowInstanceWrapper StartWorkflow(Type workflowType, Dictionary<string, object> parameters, Guid id) { Guid g = id; WorkflowInstance instance = null; WorkflowInstanceWrapper wrapper = null; try { instance = workflowRuntime.CreateWorkflow(workflowType, parameters, id); } catch (WorkflowValidationFailedException ex) { StringBuilder sb = new StringBuilder("The workflow failed validation:\r\n"); foreach (ValidationError ve in ex.Errors) sb.AppendLine(ve.ErrorText); LogStatus(g, sb.ToString()); } catch (Exception ex) { LogStatus(g, "An exception occurred when creating the workflow:{0}" + ex.Message); } if (instance != null) { Activity a = instance.GetWorkflowDefinition(); LookupService(a); wrapper = AddWorkflowInstance(instance); instance.Start(); this.RunWorkflow(wrapper.Id); } else g = Guid.Empty; return wrapper; }

Once the "WF program protoype" is in-memory, the WF Runtime makes instances of it from CreatwWorkflow calls. These instances run until Idle, at which point the Persistance service can passivate the instance to durable storage. That and more in Part 5 next time.

I'm rocking out to Concrete Jungle by Bob Marley from the album Babylon By Bus