Harry Pierson blogged about his opinion that the WF persistence service is a toy and the WF web services implementation is a toy. He points out some specific issues that he has with these parts of WF but he hasn't given the full story and not all of his facts are right. Here's the areas where I disagree:

 

1. The WF Persistence Service Loading Instances on Startup

 

The WF runtime doesn't load all idle instances on startup, that would be crazy.

 

The WF persistence service has two flags that governs how it loads. One is the locked flag which is set when a WF runtime has a workflow instance loaded in memory. This prevents other WF runtimes potentially running on other servers from loading the same instance at the same time. The locked flag has a timeout associated with it just incase the WF runtime that has locked a WF instance and that timeout is set in the persistence service constructor. The second flag is the blocked flag which is set when the WF instance is waiting for a message or waiting on a delay timeout. When this flag is set it means that the WF instance is idle. When the persistence service starts up it only loads WF instances that are not locked and also not blocked. This subset represents all the WF instances that are ready to run and need the CPU to execute on right away. In the case where you have an existing web farm there is an existing WF runtime that is loading WF instances into RAM and executing them as messages arrive and timeouts occur. If you add a new WF runtime node to such a farm the only WF instances loaded on startup would be ones that have very recently experienced a timeout. This is very unlikely to represent the thousands of instances loaded in an overload condition.

 

2. The Web Services Wrapper Use of ASP.NET Sessions

 

The Web Services wrapper created by WF doesn't use ASP.NET Sessions to track a single WF instance across multiple web or web service calls.

 

This means that WF instances don't timeout after 20 minutes or whatever time is specified for that. Instead it uses client side cookies to track the WF instance. This is why you have to pass cookies back to a web service call that uses a WF instance if you want to interact with that same instance.

 

3. The Web Service TEMPUI.ORG Namespace

 

Yes, the generated web services always use tempui.org as the namespace.

 

The recommended work around for this is to write your own web service proxy class by deriving from WorkflowWebService. Here's a rough sample which we recommend. After talking to the dev team about this we're considering putting out a sample that helps you generate this more directly.

 

    [WebServiceBinding]

    [WebService(Namespace="http://www.customname.com")]

    public class myWFWebService : WorkflowWebService

    {

        public myWFWebService()

            : base(typeof(Workflow1))

        {

        }

 

        [WebMethod]

        public virtual string myMethod(string s)

        {

            return (string)base.Invoke(typeof(Interface1), "myMethod", true, new object[] { s })[0];

        }

 

    }

 

The above sample is for an interface that’s like this:

    interface Interface1

    {

        string myMethod(string s);

    }

 

Okay now here's my 10 reasons why WF isn't a toy

  1. Six Microsoft products are building on it. They would not choose a toy technology. These products include Microsoft Office SharePoint Server 2007, Microsoft BizTalk Server "vnext", Microsoft Speech Server 2007, Microsoft System Center "Service Desk", Microsoft Identity Integration Server "future version", and Microsoft Dynamics "future version".
  2. It will be supported including the persistence service by regular Microsoft support once it releases in November 2007. Got a problem we can help!
  3. WF has best practices like any programming model and following this guidance is important to be successful. Like any programming model If you try to work against the WF best practices you may hurt yourself. This wouldn't happen with a toy.
  4. The APIs for WF are carefully factored and aligned with the rest of the .NET Framework so as to be familiar to .NET developers and extensible.
  5. No development tool that uses CodeDom can be considered a Toy. For most people CodeDom isn't supposed to be fun.
  6. Respected software architects (the scary smart kind) at Microsoft working on future internal applications are spending considerable time working on it
  7. Performance is enterprise ready. We're publishing a performance whitepaper at release which will show the performance that can be achieved. You really want to think of WF as a set of services above managed code and perf is comparable to managed code. Check back on my blog for an annoucement of this in a few weeks.
  8. Toys don't drive busines process like WF does. WF is being used by many many early adopters and we're going to publish snippets of this information on the community site in a couple of weeks time.
  9. You can't buy WF at www.amazon.com/toys because it's free for installing on Windows XP, Windows Server 2003 and included with Windows Vista.
  10. WF wasn't featured in Toy Story :-)

By the way if anyone finds something in WF that they think needs improved, please let us know. We have some great community interaction and you can use the public MSDN Forum that we've set up or you can report a bug or feature suggestion at the workflow Microsoft Connect site. We'd really like to hear from you so that we can continue to build great software.