Feedback on state machine migration

Question

Hi folks,

In order to help migrate WF customers from .Net 3.X to .Net 4 Beta1, our team has posted a set of migration documents over here. Please give them a read and provide any feedback you have on state machine migration over on this thread.

Thanks in advance for trying .Net 4, and we're looking forward to your feedback.

-Yavor Georgiev
Program Manager, Connected Framework

Answer 1

Thank you for this document.  I really appreciate you taking the time to give this deeper insight into the rationale for the omission of a built in state machine activity.  I had previously evaluated using the WF3 state machine workflow for some of my application scenarios and in my cases it was not a good fit - it was hard for me to model a single set of finite states that mapped well to the conceptual workflow that involved multiple parties and multiple values all part of one big workflow.  For me the new flowchart activites feel like a much better fit for what I am trying to model.  For example I will likely use the technique described in the document of having the currentState variable and a unique place that listens for every possible event.  When I was modeling my process using WF3 state machine I found myself adding event handlers to the root activity or the same event handler to multiple states anyway so in my case the single place to switch on an event is more natural anyway.  Plus in the {flowchart switch/current state} technique I can have a richer expression of current state beyond a single value - for example I may have 3 independent variables each of which may have n values and I think it will be more clear to have a switch with an expression of something like {(currentStateA=x or currentStateB = y) and currentStateC =0} than it would be if I had to model that using a single state for each combination in WF3.

Plus in my case my workflows are intended to model some real world business processes that have been defined by human users, and in most cases the way those users will communicate their processes will be via a flowchart anyway - so the use of a flowchart is just going to map more naturally to what my users are trying to express.  In all of the workflow scenarios that my users have proposed so far no one has ever provided me with a state machine diagram.  I know that the state machine migration document offers the stopwatch example as a case where maybe the state machine does map more naturally - but to me WF is not about implementing stopwatch logic (or even something like the automated touch tone phone response like in the WF3 SDK samples that uses a state machine).  My general purpose .Net languages give me plenty of ways to implement those simple scenarios - the thing I look to WF for is specifically for those human workflow solutions involving multiple steps with multiple parties executing over a long time.  And I'm not sure that the state machine workflow was a good fit for those anyway.

I have to say that the more I read about WF4 the more excited I become about what this is going to let me accomplish in my applications.  Frankly I've been scratching my head at WF3 and having a very hard time buying into it's implemenation - but with WF4 I'm having the exact opposite reaction.  Please keep the documentation, migration guides, and samples coming.

Answer 2

Hi PaulG, I'm glad to hear about your positive experience with WF4 and our migration doc.

Cheers,
-Yavor

Answer 3

Hi,

We are using WF3 state machine workflows extensively (about 200 workflows are defined so far) in order to represent the natural states of a transaction (created -> checked for risk, approved, executed, batched, settled, etc.). On the eventing side, I can say that we have both events which are applicable only for a certain state or for a set of states (then we have to configure the event several times) and that we always check if a certain "action" is applicable for a certain transaction state (this is exposed even over the service interface as a separate method). The workflow designer is used by non-developers to configure new or modify existing state machine workflows, as well as for documentation/presentation purposes.

Having mentioned that, I seem to be very much surprised and disappointed by the news that there is no State Workflow activity in WF4. It seems that some specific cases can be covered with the FlowChart activity or with nested while/pick/switch activities and global handling of states, but if we take this for a normal transaction state machine it will result in an extremely messed-up graphical presentation which can be "sold" neither to developer nor to non-technical people.

In case I need to implement custom StateMachineWorkflowActivity, StateActivity, StateInitializationActivity, EventDrivenActivity and SetStateActivity - will there be ***any*** guidance on that from Microsoft or I am left on my own?

I have to read the document on again because I have the feeling I have missed the answer to the question - "Why was StateMachineWorkflow dropped out of WF4 even though it was recognized that some processes ***much more*** naturally map to a state machine?" ...


Thanks in advance and br,
Deyan Petrov

Answer 4

Deyan-

First of all, you should definitely not interpret the planned lack of a StateMachine Activity in .NET 4.0 as a long term value judgement on the StateMachine or a long term plan to not support such an orchestration style.  We plan to provide a rich eco-system of activities in the years to come and State Machine is at the top of the list.  The lack of StateMachine in .NET 4.0 is only a statement on that release.

To specifically answer your question, "Why was StateMachineWorkflow dropped out of WF4 .... ".  When you release any very large product like .NET 4 there is a trade off between getting the new product to customers so they can start using it, and waiting to add more features in.   We feel that the value we are adding with the new WF runtime and the modeling styles we have is very compelling and we wanted to get this to customers as soon as possible so they could start taking advantage of this value prop.  It was a very hard decsion but it was determined that the earlier time to market for the product out-weighed the StateMachine activity.  That said, we have gotten strong feedback on the value of the StateMachine activity from a number of customers. 

Thanks
Bob-- WF Team.

Answer 5

I have found the WF 4 migration guidance very helpful. Having backwards runtime support for WF 3/3.5 w/o breaking changes seems to be the most understated point for state machine questions. I think the default understanding is that since WF 4 does not include an activity for a state machine it must be a breaking change. I guess the development communtiy has got used to the idea that each new major version usually means breaking changes backwards. I am glad the WF 4 migration doc clearly outlines that not all is lost by using WF 3/3.5 on WF 4.

Conceptually, the WF 4 Interop activity actually feels alot like the WPF WindowsFormsHost so I am glad there is something to relate to. The WF 4 doc could draw this out more as a similar migration path.

I would like to see tooling support like a .NET upgrade project wizard - this would alleviate a lot of the anxiety about breaking changes. 

Thanks,

 

---

If this answers your question, please use the "Answer" button to say so | Ben Cline

Answer 6

Will there be a migration path for long running state machine i.e. if I have a bunch of state machines that run in .NET 3.5 and then later one day I would like to upgrade to .NET 4.0.
- What do I need to concern in term of binary compatibility since they must be persisted in DB?
- How do I manage the transition to make it as painless as possible? 
- I'm going to start using WF in my project. Should I wait for .NET 4.0 or start with .NET 3.5 for this WF?
- When will Microsoft start supporting .NET 4.0? Any plan for go-live support?

- In the document, you mentioned "2. Waiting: You can wait for a subsequent WF release that contains a StateMachine implementation out of the box. ". Is there any specific timeline or version for that?

Answer 7

Our business proccess requires multiple active states at the moment.
Do you think to provide such kind functionality in the WF 4.0 StateMachine of Flowchart?

Answer 8

Will there be a migration path for long running state machine i.e. if I have a bunch of state machines that run in .NET 3.5 and then later one day I would like to upgrade to .NET 4.0.
- What do I need to concern in term of binary compatibility since they must be persisted in DB?
- How do I manage the transition to make it as painless as possible? 
- I'm going to start using WF in my project. Should I wait for .NET 4.0 or start with .NET 3.5 for this WF?
- When will Microsoft start supporting .NET 4.0? Any plan for go-live support?

- In the document, you mentioned "2. Waiting: You can wait for a subsequent WF release that contains a StateMachine implementation out of the box. ". Is there any specific timeline or version for that?

Hi Nat - regarding your questions:
Transition: You also have the option of running your WF3 workflows and WF4 workflows side-by-side. This would allow your workflow instances to be hydrated and executed in the workflow definition/runtime that they were designed to run in.

Which version to use: Particularly because this is being asked in a state machine thread, I would urge you to look at the capabilities and features of WF3 and WF4 and decide which one best fits your needs - and start with that version of WF. I hope that you find WF4 compelling to adopt, but completely understand if timing or the need for a full state machine is a requirement for your project.

Go Live support: Typically, you can get a Go Live license with the release of a product's Beta 2. I would predict that is the same case for .NET 4, but I will defer to someone more in the know on that point. In the meantime, Microsoft is currently supporting .NET 4 via more informal channels (these forums, on blogs, and via your local DPE rep).

State Machine timeline: Bob's comment above is probably your best guide for that. As Bob says (and Bob is the Product Unit Manager for WCF and WF), "The lack of StateMachine in .NET 4.0 is only a statement on that release." It's a high priority feature.

Answer 9

Hi Yavor,

I was disappointed by the clumsy design of WF 3.5 etc. and had decided not to recommend it to my company. A new start with WF 4.0 had me eager to try it.  

I have been looking high and low for books on WF 4.0 but they are just not available. I am beginning to see why.

You just don't do Business Process Modelling without state machines.  Also, state machines are easiest way to program reactive systems by a country mile.

What a disappointment that thay are not in WF 4.0, especially as they are fully specified by UML.

Flowcharts are fine for systems but you need state machines for objects/classes.


Tony Rogan

ps my company needed to model the states of a pinpad and I have a nice UML statechart for this which I would loved to have used WF4 for. Pity I can't seem to attach a document to the forum as I would really have liked to know how I go about programming this in WF4 especially the super states and concurrent states.

Answer 10

Hi Trogan,

Expect to see books on WF 4 next calendar year as start coming up on RTM. There are a WF 4 books in the pipeline with several publishers, but folks are very hesitent to publish books on beta technologies - they typically don't sell well enough to recoup costs and it typically leaves excess copies in circulation long after the final bits are released (for example, the original WF Beta 2 book still shows up among the top 15 WF books sold by Amazon even today!).

As for state machines, we definitely value your feedback on features that didn't make it into .NET 4 - as it helps us prioritize features post-release; thanks for posting on the topic! For attaching documents, you can always post the document up to a website (or some place like the Live SkyDrive) and link to it from here. It's always helpful to know more about the processes that folks want to use WF to model.

Again - thanks,
Cliff