locked
WF4 Maintenance in Production RRS feed

  • Question

  • Our current system has a requirement that long-running workflows must ALWAYS complete, even if a bug fix needs to be applied to that workflow in order for it to complete (this is a manufacturing environment, so this is absolutely essential).

    In addition to this, a new version of workflow (v2), must be installed while (v1) is still running, such that the client will complete its v1 calls, but new client calls will go to (v2). We are looking at WCF routing for this.

    If it matters, we are planning to use a WCF service with a flow chart, with content-correlation between calls from a website. This is the simplest approach, but could be changed if there was a better solution for versioning/bug-fixing.

    A few questions:

    1. Am I right in thinking that a bug fix can be applied to an existing mid-flow long running workflow as long as the xamlx is not changed?

    2. What should you incorporate into the workflow design to ensure that the xamlx will never need to be changed for a bug fix? I'm thinking:
            i.  Have the workflow only control flow and and do nothing else except invokemethods/codeactivities in order to minimise changes or potential for bugs, such that only a process change would result in a xamlx change.
            ii. Pass a final parameter of XElement to each invokemethod or codeactivity, such that any additional parameters for a bug fix can be put into this one parameter to stop a change in interface changing the xamlx. This is nasty, but effective.
           
        Any other suggestions how to code defensively against xamlx changes?

    3. When versioning your workflows, e.g. via WCF routing, how do you cope with changes to your supporting dlls through v1 and v2. Is everything strong named/versioned?

    4. Will v1 and v2 be able to be live in the same iis folder? (assuming the version name is appended to the xamlx file name) - does this mean the supporting dlls should live in the gac and be versioned?

    Workflow seemed like a good solution for our new system until we just started looking into bug-fixing and versioning of long running workflows in production. In our existing system we just use dlls and the database as a state machine, and for a bug fix or new release we can just globally replace all (non-versioned) dlls whenever we like and the client will keep running as if nothing had happened. Workflow doesn't seem to have this ability at all, and while it makes state machine/flowchart coding easier, it would seem to make deployment and maintenance a big headache. (Give me hard coding and easy maintenance any day, rather than the other way around!)

    We've only just started looking at this, so let me know your thoughts or if I've got anything wrong, and whether you think workflow is just the wrong technology given the requirements.

    Thanks.
     

    Friday, January 28, 2011 10:50 AM

Answers

  • Hi,

    I have run into similar issues on a WF 4 pre-study for a client, we dod not find a suitable way of solving it.

    The versioning issues in WF 4 are fairly well known, and Microsoft it working on a resolution for this in the next release of WF.

    Some details of the versioning story was announced ad PDC last November, the session "Windows Workflow Foundation Futures" gives details of this.

    http://player.microsoftpdc.com/schedule/sessions

    I'm not sure when the next version will be available in beta, but it should be worth looking at.

    Regards,

    Alan


    http://www.CloudCasts.net - Community Webcasts Powered by Azure
    • Marked as answer by Andrew_Zhu Wednesday, February 2, 2011 11:03 AM
    Friday, January 28, 2011 3:15 PM
  • Hi jimasp,

    Thanks for this question. First of all, keep on the mind, the WF4 is a Technology not an enterprise server solution like the BizTalk server. However, WF4 paradigm enables you to build your custom solution and hosted in the AppFabric. The WF4 and AppFabric have been release as version 1.0, there are still missing features to minimize your coding in the custom solution such as Versioning, Distributed Workflows, Enterprise Variables, etc.

    The following is my few inputs what should be have a robust enterprise application driven by metadata:  

    1.      Using an event driven and loosely decoupled distributed architecture.

    2.      The business model is logical centralized in the Repository and physical decentralized (pushed) to the targets for its runtime projecting based on the deployment model.

    3.      All metadata (xaml, config, xslt, etc.) for design time and runtime are stored in the Repository.

    4.      Repository represents a set of models such as

    a.       Contract model (schemas, endpoints, messages, etc.),

    b.      Application model (such as mediators, services, domains, applications, templates for artifacts, etc.),

    c.       Deployment model, etc.,

    - see my articles for concept and design Manageable Services and Contract Model for Manageable Services.

    Note, that the Contract Model can virtualize any contract in the Model-First manner; therefore the client can consume services based on needs.

    5.      The business model is decoupled into small distributed Workflows (Activities) stored in the Runtime Repository.

    6.      In the Runtime Repository are stored all Enterprise Variables (such as mediators, variables, expressions, activities, router tables, etc.) based on the environment and application (including their versions) scopes. Their values are pulled-up during the runtime time based on the physical location, etc.

    - see my article Enterprise Variables for WF4.

    Note, that the Enterprise Variables can be shareable across the workflows/activities.

    7.      Application is decomposed into small reusable and business oriented managers and workers (workflow services or services) during the design time and they are composited by router metadata (stored in the Runtime Repository) during the runtime

     – see my article for concept and design Routing Manager for WCF4.

    8.      Using the Master Router for mapping physical endpoints to the logical endpoints can virtualize application model connectivity and isolate its physical dependencies.

    9.      Using the Application Router for runtime business composition and virtualization.

    10.  All custom and 3rd party assemblies (including their versions) are stored in the Repository like other metadata.

    11.  Using a declaratively message mediation – see my article WF4 Custom activities for message mediation.

    Based on the Deployment Model, application can be deployed, re-deployed with overwriting resources or partly deployed, which can be used for versioning or extension features. Basically, new virtual folders can be created including \bin subfolder.

    Note, that there are two kinds of Repository. The first one is for pushing metadata to the target (deployment time) and the other one, such as Runtime Repository is for pulling metadata during the runtime. This strategy will allow balancing between the deployment time and administration/maintenance time.

    Thanks

    Roman


    Roman Kiss, MVP Connected System Developer
    • Marked as answer by Andrew_Zhu Wednesday, February 2, 2011 11:03 AM
    Saturday, January 29, 2011 5:09 AM

All replies

  • Hi,

    I have run into similar issues on a WF 4 pre-study for a client, we dod not find a suitable way of solving it.

    The versioning issues in WF 4 are fairly well known, and Microsoft it working on a resolution for this in the next release of WF.

    Some details of the versioning story was announced ad PDC last November, the session "Windows Workflow Foundation Futures" gives details of this.

    http://player.microsoftpdc.com/schedule/sessions

    I'm not sure when the next version will be available in beta, but it should be worth looking at.

    Regards,

    Alan


    http://www.CloudCasts.net - Community Webcasts Powered by Azure
    • Marked as answer by Andrew_Zhu Wednesday, February 2, 2011 11:03 AM
    Friday, January 28, 2011 3:15 PM
  • Hi jimasp,

    Thanks for this question. First of all, keep on the mind, the WF4 is a Technology not an enterprise server solution like the BizTalk server. However, WF4 paradigm enables you to build your custom solution and hosted in the AppFabric. The WF4 and AppFabric have been release as version 1.0, there are still missing features to minimize your coding in the custom solution such as Versioning, Distributed Workflows, Enterprise Variables, etc.

    The following is my few inputs what should be have a robust enterprise application driven by metadata:  

    1.      Using an event driven and loosely decoupled distributed architecture.

    2.      The business model is logical centralized in the Repository and physical decentralized (pushed) to the targets for its runtime projecting based on the deployment model.

    3.      All metadata (xaml, config, xslt, etc.) for design time and runtime are stored in the Repository.

    4.      Repository represents a set of models such as

    a.       Contract model (schemas, endpoints, messages, etc.),

    b.      Application model (such as mediators, services, domains, applications, templates for artifacts, etc.),

    c.       Deployment model, etc.,

    - see my articles for concept and design Manageable Services and Contract Model for Manageable Services.

    Note, that the Contract Model can virtualize any contract in the Model-First manner; therefore the client can consume services based on needs.

    5.      The business model is decoupled into small distributed Workflows (Activities) stored in the Runtime Repository.

    6.      In the Runtime Repository are stored all Enterprise Variables (such as mediators, variables, expressions, activities, router tables, etc.) based on the environment and application (including their versions) scopes. Their values are pulled-up during the runtime time based on the physical location, etc.

    - see my article Enterprise Variables for WF4.

    Note, that the Enterprise Variables can be shareable across the workflows/activities.

    7.      Application is decomposed into small reusable and business oriented managers and workers (workflow services or services) during the design time and they are composited by router metadata (stored in the Runtime Repository) during the runtime

     – see my article for concept and design Routing Manager for WCF4.

    8.      Using the Master Router for mapping physical endpoints to the logical endpoints can virtualize application model connectivity and isolate its physical dependencies.

    9.      Using the Application Router for runtime business composition and virtualization.

    10.  All custom and 3rd party assemblies (including their versions) are stored in the Repository like other metadata.

    11.  Using a declaratively message mediation – see my article WF4 Custom activities for message mediation.

    Based on the Deployment Model, application can be deployed, re-deployed with overwriting resources or partly deployed, which can be used for versioning or extension features. Basically, new virtual folders can be created including \bin subfolder.

    Note, that there are two kinds of Repository. The first one is for pushing metadata to the target (deployment time) and the other one, such as Runtime Repository is for pulling metadata during the runtime. This strategy will allow balancing between the deployment time and administration/maintenance time.

    Thanks

    Roman


    Roman Kiss, MVP Connected System Developer
    • Marked as answer by Andrew_Zhu Wednesday, February 2, 2011 11:03 AM
    Saturday, January 29, 2011 5:09 AM
  • Thanks guys.

    While I understand that WF4 is just a technology, it is being promoted as a solution to long-running human interaction processes. In fact, when people think of the word "workflow", that's generally what they take it to mean - i.e. the "flow of work" from one human to the next, and the stages it has to go through. Now whether those processes are in manufacturing, or just a car hire booking system, the requirement for full (and simple) bug fixing support in running instances will always be there, and MS needs to answer this shortcoming for people to take the technology seriously in real-world projects, otherwise we will just go back to the good ole' dlls and database solutions that we have been using happily for years.

    I'm glad to see MS is trying to address the long-running instance bugfix issue in a future release, but right now we need a workable non-beta alternative. So it looks like we'll be restricting workflow use to short-running processes for now, where there is no requirement to replace a running instance.

    Monday, January 31, 2011 12:53 PM