• mwinkle.blog

    You say XAML, I say XOML, PoTAYto, PoTAHto, let's call the whole thing off


    With all due respect to George and Ira Gershwin, I have a quick question for the readers of this blog.  In V1, we have an interesting scenario is talked about frequently, and that's the file extension of our xml form of workflow. 

    When we debuted at PDC05, there existed an XML representation of the workflow which conformed to a schema that the WF team had built, and it was called XOML.  Realizing that WPF was doing the same thing to serialize objects nicely to XML, we moved to that (XAML), but the file extensions had been cast in stone due to VS project setups.  So, we had XAML contained in a XOML file.

    Is this a problem for you?  I could see three possible solutions in the future <insert usual disclaimer, just gathering feedback>:

    • XOML -- we have a legacy now, let's not change it
    • XAML -- it's XAML, so change the file extension to match it (and introduce an overload to the XAML extension, which for now is associated with WPF)
    • something else, say .WFXAML -- this reflects the purpose, is unique to declarative workflows and doesn't have any weird connotations (What does xoml stand for???).

    Is this an issue?  Is this something you would like to see changed?  Do any of these solutions sound like a good idea, bad idea, etc?

    Thanks, we appreciate your feedback :-)

  • mwinkle.blog

    Would you like to refactor workflows?


    One of the things I am working on now is the next release of the workflow designer.  One thing I have heard a number of requests for over the years is the ability to refactor workflows.  I'd love to get some feedback if this would be valuable (I'm pretty convinced it is), and if it is valuable, what kind of things would you like to be able to do?  One I have heard before is the selection of some subset of activities in a workflow and select "refactor to new activity" which would pull that out to a new custom activity.

    What other things make sense?  Please reply in comments, a blog post that pingbacks, or send me email at mwinkle_AtSign_Microsoft_dot_com.


    <Usual disclaimers apply, this is not something we have made any decisions about, I am just trying to gather some data>

  • mwinkle.blog

    Workflows that don't start with a Receive


    A question recently came up on an internal list about how to start a workflow to do some work and then have it accept a message via a Receive activity.  This led to an interesting discussion that provides some insight into how the WorkflowServiceHost instantiates workflows in conjunction with the ContextChannel.

    Creating a Message Activated Workflow

    By default, the WorkflowServiceHost will create a workflow when the following two conditions are true:

    • The message received is headed for an operation that is associated with a RecieveActivity that has the CanCreateInstance property set to true
    • The message contains no context information

    It is interesting to note that you don't even need to use a binding element collection that contains a ContextBindingElement.  The ContextBindingElement is responsible for creating the ContextChannel.  The job of the ContextChannel is to do two things on the Receive side

    • Extract the context information and pass that along up the stack (hand it off into the service model)
    • On the creation, and only on the creation, of a new instance, return the context information to the caller in the header of the response.

    So, if we want to create workflows based on messages dropped into an MSMQ queue, we can do that by not trying to add the ContextBindingElement into a custom binding on top of the netMsmqBinding, and associating the operation with a Receive activity with the CanCreateInstance equaling true. Note, that any subsequent communication with the workflow will have to occur with a communication channel over which we can pass context.

    Creating a Non-Message Activated Workflow

    In the case that this post is about, we do not want to activate off an inbound message.  The way to do this doesn't require much additional work.  We first need to make sure we don't have any of our Receive activities marked with CanCreateInstance to true.  This means that no message coming in can activate the workflow.  Our workflow will then do some work prior to executing the Receive activity and waiting for the next message.  Our workflow will look like this (pretty simple)


    When we want to start a workflow, we need to reach into the workflow service host and extract the workflow runtime and initiate the workflow:

    WorkflowServiceHost myWorkflowServiceHost = new WorkflowServiceHost(typeof(Workflow1), null);
    // do some work to set up workflow service host
    // on some reason to start the workflow
    WorkflowRuntime wr = myWorkflowServiceHost.Description.Behaviors.Find<WorkflowRuntimeBehavior>().WorkflowRuntime;
    WorkflowInstance wi = wr.CreateWorkflow(typeof(Workflow1));
    // need to send wi.InstanceId somewhere for others to communicate with it
    The last note is important.  In order for a client to eventually be able to communicate to the workflow, the workflow instance Id will need to be relayed to that client. 
  • mwinkle.blog

    .NET 3.5 Beta Exams


    Trika dropped me an email asking me to point out the nice fact that if you're interested in taking a beta certification exam for WPF, WCF or WF, they've extended the deadline out a few weeks.  This means you can take a beta version of the test (FOR FREE), and if you pass it counts as if you passed the actual test, but you can get an early jump on the certification train this way.

    Check it out here.

Page 1 of 1 (4 items)