Q: There is a Windows Workflow Foundation (WF)workflow service which contains only one pair of Receive and SendReply. Data will be sent through the Receive activity and how do I get the workflow service to return the GUID of the workflow instance in SendReply activity.

A: Write a custom activity to retrieve it (See below). Bind that to a variable and bind that variable to the SendReply.Content

    public sealed class GetWorkflowInstanceId : CodeActivity<Guid>
    {
        protected override Guid Execute(CodeActivityContext context)
        {
            return context.WorkflowInstanceId;
        }
    }

I remember back in 2005/2006 when I was still touring the APAC circuits such as Sydney (Australia) and Kuala Lumpur (Malaysia) doing training and consulting gigs for customers, partners about Windows Workflow Foundation (WF) and Windows Communication Foundation (WCF, previously - Indigo) and some of the initial Windows Workflow questions came up regarding the use of Parallel Activities. It came as a surprise to many people that parallel activities are not independently asynchronous.

I explained that a WF instance gets only one instance from the runtime. There are reasons for this single-threaded execution model so each activity have to work with this single thread efficiently. There are ways to spin off differents thread when real parallelism activities are reqquired but because documentation was scare at that time, I had some trouble articulating how to do so.

I just read "Multithreaded Parallelism in Windows Workflow Foundation" on MSDN and while it is a definite deep technical article, if you can grok it, you will understand how "MultiThreaded Parallelism" can be done in WF using both the (rather hard-to-use) "Call External Method Activity (CEMA)" and the "Handle External Event Activity (HEMA)". Not only that, the authors (whom actually implemented such a system for their own use) also shared how to pair those 2 activities up using correlation and how to create wrappers aoround them so that it can be reused and therefore "not require talented software developer use of call-external-method and handle-external-event activities along with the CLR thread-pool"

A gem of a read.

I have been involved in a couple of pretty good competitive bids in some public tenders recently and am thoroughly enjoying it. I have come head-to-head with the usual suspects of heavy hitters in the areas of collaboration, SOA / ESB and portal plays such as IBM, Oracle and the likes.

On another related note: Since I am in the compete space recently, I have been keeping watch on what is coming out of the standards body and I think that WS-BPEL (which was BPEL4WS ...) should have their specifications ready by next month (March 2007). Having said that, one of the points that will make Microsoft a even stronger challenger in the enterprise space is what I believe will come out of the pipelines next month is that the next version of Windows Workflow Foundation (WF) (CTP) will support BPEL 1.1.

Moving forward, I believe that the v.Next of Orcas will support BPEL 2.0 as well as BPEL 1.1 and that will be very important in the BizTalk roadmap as well.

I dont think the world has seen so much emphasis on a feature of product even before pre-launched. In this context, I am talking about Windows Workflow Foundation (WF) and the emphasis on a non-feature, actually - that it is a non-product and it doesnt come with batteries host included.

Windows Workflow consists of an activity library and a framework, a runtime engine, and a runtime services components. Most of these will work out-of-the-box and some of them comes with extensibility mechanisms which you can further enhance or customize on.

All of those must run within a host application process - which you have to build.

In other words, Windows Workflow is just a framework with managed APIs and not a designed as a product. It would be a lot of work to build your own host, which is why I wouldnt recommend it. You can implement workflows in existing hosts such as IIS6 or a Windows NT Service or soon-to-be-shipped - WAS in IIS7.

That said, if you want ready hosts of domain-specific workflows with user-customizability, you can always look at Windows Sharepoint Services v3.0. I believe BizTalk 2008 will be a host for Windows Workflows when it ships as well.

Anyways, one of the key points that confuse many developers is how workflow instances are scheduled by the workflow runtime engine. There are 2 ways - via a Synchronous and an Asynchronous approach. Both of them are implemented via the ManualWorkflowSchedulerService and DefaultWorkflowSchedulerService respectively.

Obviously, if you dont tinker with the WorkflowRuntime with regards to the Scheduling Services, it will use the DefaultWorkflowSchedulerService service. It creates and manages the threads that run workflow instances in an asynchronous manner on the runtime engine and it supports multiple workflow instances queued in the runtime thread pool. In other words, this default scheduler will automatically queue the workflow to run on a thread from the process-wide CLR thread pool. With this default setting on the WorkflowRuntime, the workflow will always execute asynchronously on a different background thread which, in turn, explains why so many of the SDK samples waits for the workflow to finish by blocking the main thread with an AutoResetEvent.

However, you can use the ManualWorkflowSchedulerService if you crave for synchronous execution of workflow instances. The workflow instances are executed on the calling thread from the host application, thus blocking the execution of the host application until the workflow instance becomes idle. To do so, the host must donate threads to the workflow runtime, which will then use this donated thread to execute a workflow.

Running a workflow with the ManualWorkflowSchedulerServic is slightly different as well. It involves a two-step process. First, you call Start on the workflow instance. But that is not enough as it only prepares the runtime for this instance and does not actually run the workflow. We have to be more explicit by calling RunWorkflow and passing the Workflow's Instance ID. This is how a thread is donated by the host. The WorkflowRuntime will then use this calling thread to execute the workflow synchronously. In other words, the workflow instance will execute on the same thread as the calling program.

Subtle differences, but understanding it will enable the use of the right tool to do the right job.

Fellow Microsoft Regional Director and well-known distributed systems expert Matevz Gacnik has a great blog to add on top of mine called: Windows Workflow Foundation: Exposing Workflows as Services. Trust me, Matevz is a lot more than Request-Response or what his blog suggested .

In it, he explains some of the ways you can do so and the pitfalls to watch out for. Of course, you can get around the "workflow runtime can only get loaded once per appdomain" issues by having it static to the service implementation class OR if you want only one instance of each - Windows Communication Foundation (WCF, previously - Indigo) also gives you a singleton-like instancing mode as well - InstanceContextMode:=InstanceContextMode.Single.

(I would be interested to find out the naming convention to call it Single in the latest CTP instead of Singleton)

My tip highlighted here is not really about exposing workflows as services. It is more about how you can hook a workflow into a already-hosted WCF service as part of its configured behavior, if need be. For example, you may want to have a non-intrusive workflow for you to raise an event that calls into your defined HandleExternalMethod (called EventSink before) and then you may just terminate that activity. The reason is because the workflow thread doesnt return unless you called a WaitHandle.Set, which you can call when a workflow is completed or terminated.

Having said all that - Remember that most of the current implementations of Web Services today work on a Request-Response model and many more are betting on that it will remain like that for a long time. Isnt this one of the reasons we have long arguments of POX/REST ? Workflows, on the other hand, are made to handle long running work and therefore, you need to design and handle both properly as its design principles and most-used implementations do conflict.

Now, if you forsake the Request-Response model and think about the wonderful partnership and the options abound once you hit <OperationContract(IsOneWay:=True)> on top of the MSMQ transport, Windows Workflow Foundation (WF) + Windows Communication Foundation (WCF, previously - Indigo) does look very delicious and promising indeed.

One of the common questions I came across my Windows Workflow Foundation (WF) and Windows Communication Foundation (WCF, previously - Indigo) consultancy tour is how do we logically use WF inside a WCF-hosted service.

I had spent some time talking about how we can host a WF in a WCF:ServiceHost and how we can create a channel to invoke a workflow inside a WCF Service.

Of course, we can always bring up a Workflow runtime and create a new workflow instance within the ServiceHost. However, some of us may prefer a more non-intrusive mode of a workflow invocation style.

There are actually many extensible points at the Service Dispatcher which you can hook into that is part of a service behavior. There is the IServiceBehavior, IOperationBehavior and one of my favourite extensible behavior points I like to hook into is at the IEndpointBehavior.

For instance, you may want to inspect a message in its raw glory and depending on its headers or the request properties, you may choose to invoke an appropriate action or workflow. You would need to implement the ApplyDispatchBehavior routine which gives you acccess to an EndpointDispatcher, which in turn, gives you a chance to implement a IDispatchMessageInspector. The IDispatchMessageInspector exposes some very useful routines which allows you to hook into the request message just after it has been received as well as before sending the reply message back.

I would probably inspect the messages at this point and invoke the appropriate workflow and send the appropriate values into the ExternalDataEventArgs of the workflow based on the message values.

Of course, this is not a hard and fast rule. How and when you do it is totally up to you. You may want to do it at the IOperationBehaviour and have the message dispatched to another entirely different operation if you want to (or if you dont agree with how WCF dispatches its messages).

Below are some snippets that will help you along. I will be going more in-depth into these details in TechED Asia 2006 in Malaysia where I will show some really cool never-seen-before demos that is a mixture of WF and WCF. If you havent planned to be be there at TechED Asia 2006, do so now !

Namespace Softwaremaker.NET.Wcf.Demos
PublicClass WcfMessageInspectorWorkflowInvoker : Implements IDispatchMessageInspector

PublicSubNew()
MyBase.New()
EndSub

PublicFunction AfterReceiveRequest(ByRef request As Message, ByVal channel As IClientChannel, ByVal instanceContext As InstanceContext) AsObjectImplements IDispatchMessageInspector.AfterReceiveRequest
Try
'Inspecting Message Request ...
'Invoking appropriate Workflows based on values found in request message
Catch e As Exception
ThrowNew FaultException(e.Message)
EndTry
ReturnNothing
EndFunction

PublicSub BeforeSendReply(ByRef reply As Message, ByVal correlationState AsObject) Implements IDispatchMessageInspector.BeforeSendReply
Try
'Inspecting Message Reply ...
'Invoking appropriate Workflows based on values found in reply message
Catch e As Exception
ThrowNew FaultException(e.Message)
EndTry
EndSub
EndClass

What I have described above is a good way to abstract how and when you invoke a workflow away from your WCF-Hosting or business code. How do I add this behavior into my serviceHost ? Easy. Just call the below before your serviceHost.Open

serviceHost.Description.Endpoints(0).Behaviors.Add(New Softwaremaker.NET.Wcf.Demos.WcfMessageInspectorWorkflowInvokerBehavior)

Now, if you decide that the above code sentence intrudes into your hosting code and you would like it to be configured in your config file for flexibility as well, I will show in a later blog post how to add your own custom-defined behaviorExtension into your configuration file. Think: BehaviorExtensionSection.

... OR you can always go to TechED Asia 2006 in Malaysia where you sure would derive more value than a single non-interactive blog post.

Enjoy.

Microsoft announced Go Live licenses this morning for Windows Communication Foundation (WCF, previously - Indigo) and Windows Workflow Foundation (WF) , which lets customers use the January Go Live releases of WCF and WWF in their deployment environments. Do note that these are unsupported Go Lives.) 

More information about the Go Live program is at http://msdn.microsoft.com/winfx/getthebeta/golive/default.aspx.

There are also a couple of community sites for WCF and WWF here:
http://windowscommunication.net
http://windowsworkflow.net

The community sites give users everything they need to start using WWF and WF today.  If you have some great samples, do post them to the sites;  The WCF sample gallery and WF activity gallery allow you to host the samples/activities on your own site and create links to your own site from the galleries.

As mentioned, I will be introducing more WWF Blogging to this site. Do stay tuned.

Besides being deeply involved in Windows Communication Foundation (WCF, previously - Indigo), I have also been very engaged with the technologies of Windows Workflow Foundation (WF) and Windows Presentation Foundation (WPF).

I will be blogging actively on these 2 technologies as we move towards Vista