When we start doing this two way style of messaging, we now open up to start modeling some interesting business problems.  In the previous post, you'll note that I did not include the code, because I mentioned we needed to be more clever in scenarios where we listen in parallel.  First, a brief diversion into how the Receive activity works.  Everybody remembers the workflow queues, the technology that underlies all communication between a host and a workflow instance.  The Receive

So, we've seen in part 1 how to manage context, we saw in part 2 how we can take that basic knowledge to do duplex messaging.  Once we start doing duplex work, there are some interesting patterns, and the first one is one that we like to call "long running work".  Why are we interested in this?  Well, as you probably know, the execution of a workflow is single threaded (this is a feature, not a bug).  We also don't have a mechanism to force the workflow to be "pinned"

Martin posted an interesting question here on my last post: <quote> The first thing that we need to do in order to enable this duplex messaging to occur is that the "client" workflow has to explicitly provide its context token to the service so that the service can address the appropriate instance of the client workflow. Note, in the real world, you'll probably need to supply more than just the context token, you will need some address and binding information. </quote> Shouldn't

A continuation of my series of demos from my advanced workflow services talk.  Here we focus on duplex message exchange patterns. Duplex messaging is something that we model at the application level (as opposed to the infrastructure level) because we want to model that message exchange at the level of the application.  Here's some scenarios where I could use duplex messaging: [concrete] I submit an order, and you tell me when it ships [abstract] I ask you do to do some long running work,

So, last week I wrapped up a conversation at TechReady, our internal conference, where I was talking about the integration between WF and WCF in .NET 3.5.  This talk was somewhat bittersweet, it's the last conference where I'm scheduled to talk about WF 3.0/3.5, I'll start talking about WF 4.0 at PDC this fall.  There are a series of 4 demos that we'll talk about in this series: Basic Context Management Simple Duplex Long Running Work Pattern Conversations Pattern I've gotten a lot of requests

One of the things that my team is working on is the next version of the workflow designer.  In order to help us get real feedback, we engaged with our usability teams to design and execute a usability study.  For details on what the test looks like (when we did them 3 years ago for the first version of the WF designer, see this great channel9 video ).  The setup is still the same (one way glass mirror, cameras tracking the face, screen, posture of the subject), the only difference

My team is looking for people interested in building the next generation of the WF designer.  We've posted an opening here , please let me know if you're interested.  I can't really say too much about what we're building, but it's a great team that's committed to creating a great experience for building, editing, and viewing workflows.  Everyone on the team believes in the power of a declarative model of process, and believes that tools are the way that model is consumable by humans. 

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

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

I'm moving on from my role as the technical evangelist for WF, but not too far.  I've joined the product team, working as a program manager (PM) for the Connected Tools team.  The job of the connected tools team is to provide all of the tools for the technologies inside the Oslo effort, including the WF designer.  As such, I'll be focused on the programming model for activity designers to use when they create WF activities. Oslo is interesting, as it represents the first real chance