This project is read-only.

Comparison of this library vs. WF 4.0

Feb 8, 2011 at 4:47 PM

How does this project is different from Microsoft offering of WF 4.0?  I would love to hear some opinions as i am researching whether to use this or go with native implementation.

Mar 11, 2011 at 2:02 PM

I second that request for a comparison.  Can this be used in tandem with WF 4.0?

May 11, 2011 at 5:41 PM
Edited May 11, 2011 at 5:49 PM

Sorry for the late reply - I though I was getting emails to new discussion topics, but apparently that is not the case.

Here is a mind map of the difference - I am working on a blog post for this now.   If you see topics you would like expanded upon, I'd love to incorporate them

-Steve

As a general statement, I believe that WF is incredibly useful in the cases that call for it.   FluentWorkflow's focus is very different - it is a developer tool at heart that allows you to create distinct workflow steps that are easily testable and deployable.  As such it is very lightweight - you do not have to buy into a framework and runtime engine. Both tools have their places depending on project requirements.

  • Comparing Windows Workflow Foundation (WF) and Fluent Workflow (FW)
    • Similarities
      • Task Definitions
        • WF has WorkflowActivity instances that do the work
          • can be authored in code or in XAML (which is compiled to WorkflowActivity types)
        • FW has IStateTask instances that do the work
          • can be authored in code, no plans to support XAML definitions at this stage
      • Task Composition/Aggregation
        • WF Created through the use of Composite Activities
        • FW Created by using the DependsOn<> declarative syntax of the fluent interface
      • Control Flow Options
        • State Machine Workflow
          • WF Achieved through the combined execution of WorkflowActivity objects
          • FW Acheived through the combined execution of IStateTask<> objects
        • Conditional Workflow
          • WF uses simple conditions
          • FW uses StateTasks that implement IMutatingStateTask<>
            • Allow for simple or complex conditions
            • Even allows for decisions that rely on interaction with external services
        • Sequential Workflow
          • This is called out as a feature of WF
          • This is a function of the workflow definition easily achieved with FW, not viewed as a feature - it just is
    • Differences
      • Task Definitions
        • WF supports definitions written in XAML
        • FW does not directly support definitions written in XAML - no current plans to add support for it
      • Runtime Requirements
        • WF requires full trust
        • FW does not impose any trust restrictions
      • Host->Workflow Communication
        • WF relies on custom local communication services (typically via Events and methods)
          • a product of the runtime
        • FW's lightweight instantiation model allows workflows to be instantiated and initiated on the fly.
          • FW uses a 'functional' programming model in passing state
      • Authoring Differences
        • FW uses a fluent style configuration in-code
          • The 0.9.4 release
            • will allow runtime modifications to the workflow (foundation built in 0.9.0)
            • will allow for an import ability of workflow definition
          • The 0.9.2 release
            • Will focus on emiting graph notation that can be rendered in graphical tools
        • WF has graphical tools for composing workflows
          • This provides an nice, refined design surface
    • Runtime Differences
      • Core Difference
        • WF has runtime services that you wire into
          • customization happens by changing the configuration of those services
        • FW's runtime is IoC
          • this means scoping for things like transactions can be handled by lifetime management
          • adding history/tracing is handled by external service injection
          • FW utilizes functional programming concepts
            • state is handed to each task discretely
            • this means that the user can control the runtime
      • Operational Redundancy (workflows running on multiple boxes)
        • WF - I haven't seen a scenario where this works duplicate state is a problem.
        • FW: functional approach means FW imposes no constraints on this front
      • Machine Driven workflows (evented or timed)
        • WF handles this quite well - it's built into the runtime
        • FW does not support this out of the box - requires a service (app, service (topshelf/quartz works well here)