Ten Reasons why WF is not a Toy


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.

Comments (12)

  1. Sam Gentile says:

    There is so much I want to say about important topics like Rocky’s well-written, thought provoking Semantic

  2. buj says:

    Try turning on FIPS and using WF…

  3. Since I´ve been working with Windows Workflow Foundation (Project BHAL), I´ve gathered quite a list of…

  4. Jon Flanders says:

    Paul – I feel compelled to come to Harry’s defense (not of his use of the word toy  necessarily ;-)) – but I was the one who gave him his information.  Please check out my most recent entry for clarification.  http://www.masteringbiztalk.com/blogs/jon/PermaLink,guid,5cc60ee3-38ce-4fcd-94d7-a8ca9b3b8d5d.aspx

  5. kcmarshall says:

    Um –

    "…once it releases in November 2007."

    Are you saying that WF (and .NET 3.0) will be officially released in 11/07?  Did I miss that elsewhere?  Or do you mean something else by "it"?

    Kevin

  6. Paul Andrew says:

    Hi Kevin,

    Windows Workflow Foundation will release with the .NET Framework 3.0. That’s scheduled to release at the same time as Windows Vista goes RTM. See: http://www.microsoft.com/presspass/press/2006/Oct06/10-13VistaReleasePR.mspx

    Regards,

    Paul

  7. Keith Woods says:

    Thanks for clarifying what exactly gets loaded, just wondering is there any particular reason you load the workflows that are not started when you start the runtime? Just noticed we may need to rethink our batch creation strategy. Currently we create and unload about 4000 workflows and intent to start them at a later time. They appear to get loaded when the runtime start as they are not locked and not blocked (this takes a while).

    If there is a good reason for loading them we wont mod the code/stored proc that loads unstarted runtimes, otherwise we’ll probably start them when we create them and put them into an intermittent state waiting for a later kick-off.

    Perhaps this is not the forum to discuss this but we’ve been trying to identify the best practices regarding how to use the SQL persistence service.

  8. Paul Andrew says:

    Hi Keith,

    The persistence service does not load the workflow instances that are not started. It only loades instances that are ready to run.

    I don’t know why you think you’re seeing that. You must have some other problem. I’d suggest you take it up on the MSDN Forums. http://www.windowsworkflow.net/forums.

    Also did you review the SDK documentation? http://windowssdk.msdn.microsoft.com/en-us/library/ms734764(VS.80).aspx

    Regards,

    Paul

  9. There’s been a bit of a heated debate on Workflow Foundation going on which Paul Andrew captured and…

  10. piers7 says:

    Sorry Paul, but I can’t let you off the hook on this one yet, because what you’re saying just doesn’t tally with the tests we’ve done.

    In the code in front of me I create and persist a non-started workflow. It goes into the database with a status of ‘4’. In the ‘RetrieveNonBlockingInstanceStateIds’ I can clearly see that statuses of 4 *are* loaded by this proc (which is called by the SqlWorkflowPersistenceService at runtime startup)

       SELECT uidInstanceID FROM [dbo].[InstanceState] WITH (TABLOCK,UPDLOCK,HOLDLOCK)

       WHERE blocked=0 AND status<>1 AND status<>3 AND status<>2 — not blocked and not completed and not terminated and not suspended

    …and sure enough when I start the runtime I see the ‘Workflows in Memory’ performance counter rise by the number of persited, non-started workflows I have in the database. I’m not sure how I can mis-interpret this.

    The only thing I wonder about is whether you’ve rev’d the stored procs after releasing the RC5 (.Net3 RC1) build, and you and I are looking at different code.

  11. Paul Andrew says:

    Hi Piers,

    I’m working with Doug Orange at Microsoft Australia on this. Let’s continue to discuss your debuging on that thread.

    Regards,

    Paul

  12. Hace ya bastante tiempo que llevo jugando con WF, puesto que lo necesitaba por exigencias de trabajo,

Skip to main content