Matt W's Windows Workflow Place : WCF

WF4, WCF and AppFabric Sessions @ PDC09

mwinkle — Mon, 23 Nov 2009 23:16:44 GMT

I’m taking this week off to catch up on everything I haven’t done the last two months and to celebrate the Thanksgiving holiday here in the US.

PDC was a blast! It was incredibly awesome to meet so many folks interested in WF and talking with others about how they are using (or plan to use) WF4. I’ll be following up with a more detailed post on my talk, including demos and code, but I wanted to give a summary of the talks that came from my team at this PDC. Below is the diagram that breaks down some of the “capabilities” of AppFabric and I have color coded them for the various talks that we gave. All of the PDC Sessions are available online here.

WF Talks

Spice Up Your Applications with Windows Workflow Foundation 4 – Matt Winkler
Windows Workflow Foundation 4 from the Inside Out – Bob Schmidt

WCF Talks

What’s New for Windows Communication Foundation 4 – Ed Pinto
Developing REST Applications with the .NET Framework – Henrik Nielsen

AppFabric Talks

Microsoft Application Server Technologies: Present and Future – Anil Nori
Microsoft BizTalk Server Futures and Roadmap – Balasubramanian Sriram
Workflow Services and Windows Server AppFabric – Mark Fussell
Application Server Extensibility with Microsoft .NET 4 and Windows Server AppFabric – Nicholas Allen

There’s a ton of great content up at the PDC site, plenty to sit back and enjoy!

Which WF/WCF Talks Should You Attend at PDC?

mwinkle — Fri, 03 Oct 2008 02:19:10 GMT

Just got the email the other day that PDC is less than 4 weeks away, and it got me thinking a bit about how I would think about these sessions as an attendee. Searching on the PDC site will yield 8 talks tagged with WF. Here's how I break some of these these down, the first few are about using WF, and the last 3 are about WF itself:

Hosting Workflows and Services

Dan Eshner

Hear about extensions being made to Windows Server to provide a feature-rich middle-tier execution and deployment environment for Windows Workflow Foundation (WF) and Windows Communication Foundation (WCF) applications. Learn about the architecture of this new extension, how it works, how to take advantage of it, and the features it provides that simplify deployment, management, and troubleshooting of workflows and services.

This talk is all about the host we're building for WF and WCF, which I mentioned earlier, we're calling "Dublin". If you're familiar with either technology, and have built a host of your own, this will be interesting both from the perspective of what is coming, as well as how we are thinking about solving some of the hosting problems.

A Lap around "Oslo"

Presenters: Douglas Purdy, Vijaye Raji

"Oslo" is the family of new technologies that enable data-driven development and execution of services and applications. Come and learn how to capture all aspects of an application schematized in the "Oslo" repository and use "Oslo" directly to drive the execution of deployed applications.

Building declarative or data driven apps is a "thing" in the Oslo world. This talk will give the big picture of all of the various pieces of Oslo, and how existing declarative technologies, like WF and WCF fit into it. Note, this talk is not primarily about WF or WCF, rather it is about Oslo, which you can read about in more detail here and here.

What about all of the things we are doing to WCF and WF in .NET 4? That's the remaining three talks:

Windows Workflow Foundation 4.0: A First Look

Presenter: Kenny Wolf

Programs coordinate work. The code for coordination and state management often obscures a program's purpose. Learn how programming with Windows Workflow Foundation (WF) 4.0 provides clarity of intent while preserving the functional richness of the .NET framework. See how easy it is to build workflows with the new Visual Studio workflow designer. Learn about text-based authoring options for WF. Hear how WF integrates well with other Microsoft technologies (WCF, WPF, ASP.NET). If you've looked at WF before, come and see the changes to data flow, composition, and new control flow styles. Significant improvements to usability, composability, and performance make Workflow a great fit for a broad range of solutions on both the client and the server.

Windows Workflow Foundation 4.0: Extending with Custom Activities

Presenter: Matt Winkler

Windows Workflow Foundation (WF) coordinates and manages individual units of work, encapsulated into activities. WF comes with a rich library of activities. Learn how to extend this library by encapsulating your own APIs with custom activities. See how to compose those basic activities into higher level units using rules, flowchart, and state machine control flow styles. Learn how to build your own WF control styles. Learn how to customize and re-host the workflow authoring experience using the new WF designer framework.

Windows Communication Foundation 4.0: Building WCF Services with Windows Workflow Foundation in Microsoft .NET 4.0

Presenter: Ed Pinto

Eliminate the tradeoff between ease of service authoring and performant, scalable services. Hear about significant enhancements in WCF and WF to deal with the ever increasing complexity of communication. Learn how to use WCF to correlate messages to service instances using transport, context, and application payloads. See how the new WF messaging activities enable the modeling of rich protocols. Learn how WCF provides a default host for workflows exposing features such as distributed compensation and discovery. See how service definition in XAML completes the union of WF and WCF with a unified authoring experience that simplifies configuration and is fully integrated with IIS activation and deployment.

Kenny's talk will be an introduction to all of the new features in WF. If you haven't used WF, or if you looked at WF before and decided it wasn't right for your solution, come to this talk to see how WF makes writing programs easier. If you are using WF today, and want to see what has changed, this will be a good talk for you.

My talk will be a very hands on, write some code, style talk focused on building activities and all of the aspects of WF that impact activity development. If you are using WF today, and want to see what the changes mean for the code you'll write, this is the talk for you. Also, if you attend Kenny's talk and think, "hey, I want to learn more" this will also be the talk for you. My talk won't focus on the "why" or the "where" of workflow, but more the "how to build" parts.

Finally, Ed's talk is the talk to go to if you are a WCF developer. If you are building programs that consume services, where service is very loosely defined integrating external information into your app, you should also make sure to go to this talk. This talk will highlight a number of the enhancements that have been made both to WCF and to the integration between WF and WCF. We believe very strongly that WF and WCF are tremendously complementary technologies.

To help, I've put together the following decision table to help you decide. There are three possible actions, "Must Attend" "Should attend" and "Would Enjoy". I think they are fairly explanatory actions, but if you have questions, let me know.

	Kenny's talk: A First look	Matt's Talk : Building Activities	Ed's talk: Building WCF Services with WF
Building WF today	Must attend	Must attend	Must attend
Building WCF today	Should attend	Should attend	Must attend
Looked at WF, but didn't use it	Must attend	Must attend	Should attend
Looked at WCF, but didn't use it	Should attend	Would enjoy	Must attend
Interested in Oslo	Must attend	Should attend	Should attend
Interested in the problem of coordination	Should attend	Should attend	Should attend
Building services, or apps that consume services	Would enjoy	Would enjoy	Must attend

Can't wait to see you in LA!

WCF Perf Talk @ PDC (or, the Doctor Teaches Fishing)

mwinkle — Thu, 02 Oct 2008 20:06:54 GMT

I'm probably not going to have too much time to attend talks at PDC, but one talk that would be high on my list is the one that Dr. Allen blogs about here, where he talks about the Zen of WCF Performance and Scale.

I like "Zen" style talks, especially for topics like performance and scale. Sure, I could go and listen for 75 minutes for tips and tricks that may be applicable to my scenario, but this is giving you a fish. Having a 75 minute conversation about how to think about perf and scale, how to think about achieving that in a distributed messaging system teaches you how to fish. This is going to equip you with a lot more knowledge about how to plan for and solve performance and scale issues down the road.

This is one lunch session, I wouldn't want to miss. As a plus, he's taking questions and suggestions on his blog, so fire away!

More Details On WF/WCF in .NET 4.0

mwinkle — Wed, 01 Oct 2008 23:15:27 GMT

Steve Martin, a director of product management for CSD, has a blog post containing more information on the work that we are doing for the next versions of WF and WCF that we will release as a CTP at PDC. He also introduces "Dublin," the name for our efforts around creating a manageable and scalable host for WF and WCF applications, something that I know a few customers would be interested in.

For you WF and WCF fans, there some more information about some of the features that you'll hear more about at PDC. I think for customers who are using either today, you'll see something on the list below that gets you interested. And, if you're not using WF or WCF today, I think there are a few things that might make you interested. We think that the features we're introducing (especially in WF, which is close to my heart) will make it easier to use WF, in more places, and by more people. Let us know what you think. What's exciting in the list below, what do you want to hear more about, is there something else you'd like to see on the list?

WF Features

Significant improvements in performance and scalability

· Ten-fold improvement in performance

New workflow flow-control models and pre-built activities

· Flowcharts, rules

· Expanded built-in activities – PowerShell, database, messaging, etc.

Enhancements in workflow modeling

· Persistence control, transaction flow, compensation support, data binding and scoping

· Rules composable and seamlessly integrated with workflow engine

Updated visual designer

· Easier to use by end-users

· Easier to rehost by ISVs

Ability to debug XAML

WCF Features

RESTful enhancements

· Simplifying the building of REST Singleton & Collection Services, ATOM Feed and Publishing Protocol Services, and HTTP Plain XML Services using WCF

· WCF REST Starter Kit to be released on Codeplex to get early feedback

Messaging enhancements

· Transports - UDP, MQ, Local in-process

· Protocols - SOAP over UDP, WS-Discovery, WS-BusinessActivity, WS-I BP 1.2

· Duplex durable messaging

Correlation enhancements

· Content and context driven, One-way support

Declarative Workflow Services

· Seamless integration between WF and WCF and unified XAML model

· Build entire application in XAML, from presentation to data to services to workflow

Advanced Workflow Service Talk (Demo 4 of 4)

mwinkle — Mon, 11 Aug 2008 18:52:10 GMT

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 activity works by creating a queue that the WorkflowServiceHost (specifically the WorkflowOperationInvoker) will use to send the message received off the wire into the workflow. Now, the Receive activity normally just creates a queue that is named the same as the operation the Receive activity is bound to. However, if we have two Receive activities listening for the same operation at the same time, no longer is a single queue useful to route responses back as we want to route to the correct Receive activity instance.

There is property on the Receive activity called ContextToken. Normally this is null in the simple case. However, when we want our Receive activity to operate in parallel, we need to indicate that it needs to be smarter when it creates a queue.

By setting this property (you can just type in a name, and then select the common owner all of the parallel receive's share. This will cause the Receive activity to create a queue named [OperationName] +[ConversationId], the conversation ID takes the form of a GUID, and is the second element inside a context token.

The sample that I show for this talk is simply the conversations sample inside the SDK. This is the sample to check out to understand all sorts of interesting ways to use the context tokens to model your processes.

Now, there are two conversation patterns here. One is the one shown above, which I refer to as an n-party conversation where n is fixed at design time. We can accomplish this with the parallel activity. The other is where n is arbitrary (imagine you send out to business partners stored in the database). The way to do this is to use the Replicator activity. The Replicator is a little known gem shipped in 3.0 that essentially gives you "ForEach" semantics. But, by flipping the ExecutionType switch to parallel, I now get the behavior of a parallel, but operating with an arbitrary n branches.

So, in order to enable conversations, we need to tell our receive activity to be a little smarter about how it generates its queue name, and then we simply follow the duplex pattern we discussed in the last two posts. Once we do that, we're in good shape to start modeling some more interesting communication patterns between multiple parties.

Where can we go from here?

We can just make the patterns more interesting. One interesting one would be the combination of the long running work with cancellation and a Voting activity in order to coordinate the responses and allow for progress to be made when some of the branches complete (if I have 3 yes votes, I can proceed). The power of building composite activities is that it gives me a uniform programming model (and a single threaded one to boot) in order to handle the coordination of different units of work. Get out there and write some workflows :-)

Advanced Workflow Services Talk (Demo 3 of 4)

mwinkle — Fri, 08 Aug 2008 00:17:30 GMT

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" in memory. What this means is that things like the asynchronous programming model (APM), can't be used, since there isn't a guarantee that there will be something to call back when we are done. What this means is that the send activity can not take advantage of the APM to be more thread friendly.

We may want to do things in parallel, like this

If each of these branches takes 3 seconds, the whole of this workflow will complete in about 9 seconds. The general expectation is that in parallel, this would happen at the length of the longest branch + some minor delta for overhead. The trouble is, APM programming is tricky, especially relative to the layout above.

In order to model APM style service calls, but allowing for the service operations to be extremely long running, where extremely is defined as "long enough to where I would want to be able to persist." The approach then is to model this as disjoint send and receive activities.

One intermediate step is to simply use one way messaging, but the problem there is that in a lot of cases, I'm looking for some information being sent back to me.

I'll hold off on the code for the above, the fact we are listening in parallel for the same operation requires us to be a little more clever.

Let's look first at our contract, and then our service implementation:

   1:  namespace Long_Running_Work

   2:  {

   3:      [ServiceContract]

   4:      public interface ILongRunningWork

   5:      {

   6:          [OperationContract]

   7:          string TakeAWhile(int i);

8:

   9:          [OperationContract(IsOneWay = true)]

  10:          void OneWayTakeAWhile( int i);

11:

  12:          [OperationContract(IsOneWay = true)]

  13:          void TakeAWhileAndTellMeLater(IDictionary<string,string> contextToken, int i);

  14:      }

15:

16:

  17:      [ServiceContract]

  18:      public interface IReverseContract

  19:      {

  20:          [OperationContract(IsOneWay = true)]

  21:          void TakeAWhileAndTellMeLaterDone(string s);

  22:      }

23:

  24:  }

And now for the implementation of these;

   1:  namespace Long_Running_Work

   2:  {

   3:     public class Service1 : ILongRunningWork

   4:      {

5:

   6:          public Service1()

   7:          {

8:

   9:          }

10:

  11:          #region ILongRunningWork Members

12:

  13:          public string TakeAWhile(int i)

  14:          {

  15:              Console.WriteLine("Starting TakeAWhile");

  16:              System.Threading.Thread.Sleep(new TimeSpan(0, 0, 3));

  17:              return i.ToString();

  18:          }

19:

20:

21:

  22:          public void OneWayTakeAWhile( int i)

  23:          {

  24:              Console.WriteLine("Starting One Way TakeAWhile");

  25:              System.Threading.Thread.Sleep(new TimeSpan(0, 0, 3));

  26:              Console.WriteLine("Ending One Way TakeAWhile");

27:

28:

  29:          }

30:

31:

  32:          public void TakeAWhileAndTellMeLater(IDictionary<string, string> context, int i)

  33:          {

  34:              Console.WriteLine("Received the context Token");

  35:              System.Threading.Thread.Sleep(new TimeSpan(0, 0, 3));

  36:              Console.WriteLine("Need to Message Back Now {0}", i.ToString());

  37:              // could investigate a more useful pooling of these if we

  38:              // really wanted to worry about perf

  39:              IReverseContractClient ircc = new IReverseContractClient(

  40:                  new NetTcpContextBinding(),

  41:                  new EndpointAddress("net.tcp://localhost:10003/ReverseContract")

  42:                  );

  43:              IContextManager icm = ircc.InnerChannel.GetProperty<IContextManager>();

  44:              icm.SetContext(context);

  45:              ircc.TakeAWhileAndTellMeLaterDone(i.ToString());

  46:          }

47:

48:

49:

  50:          #endregion

  51:      }

52:

  53:     public class IReverseContractClient : ClientBase<IReverseContract>, IReverseContract

  54:     {

  55:          public IReverseContractClient() : base(){}

  56:          public IReverseContractClient(System.ServiceModel.Channels.Binding binding, EndpointAddress address) : base(binding, address) { }

57:

  58:  #region IReverseContract Members

59:

60:

61:

  62:         public void TakeAWhileAndTellMeLaterDone(string s)

  63:         {

  64:             base.Channel.TakeAWhileAndTellMeLaterDone(s);

  65:         }

66:

  67:         #endregion

  68:     }

69:

  70:  }

Basically, we sit around and wait. You'll also note in the TakeAWhileAndTellMeLater, we take in a context token (similar to our previous approach), and we will use that to new up a client at the end and call back in after setting the context. Look at lines 39-44 above. The nice thing about this is that my above workflow client can actually go idle, persist, and react to a message being delivered later on.

One thing to note is that one should not place a delay between any of the Send and Receives. This could cause the workflow to go idle, which may allow you to miss messages. This is generally considered, a bad thing. The reason this occurs is that the WorkflowOperationInvoker will use EnqueueOnIdle which means that when teh workflow goes idle, the message will be enqueued. If the queue hasn't been created by the Receive activity, the message will not get delivered.

For the final workflow above (the TakeAWhileAndTellMeLater workflow), I will need to spin this up in a WorkflowServiceHost (a la the Duplex Sample in part 2).

using (WorkflowServiceHost wsh = new WorkflowServiceHost(typeof(CallLongRunningComponents.WorkflowWithmessaging)))
{
    wsh.AddServiceEndpoint(
            typeof(Long_Running_Work.IReverseContract),
            new NetTcpContextBinding(),
           "net.tcp://localhost:10003/ReverseContract"
            );
    // don't forget to open up the wsh
    WorkflowRuntime wr = wsh.Description.Behaviors.Find<WorkflowRuntimeBehavior>().WorkflowRuntime;

    wsh.Open();


    WorkflowInstance wi = wr.CreateWorkflow(
        typeof(CallLongRunningComponents.WorkflowWithmessaging));
    wr.WorkflowCompleted += ((o, e) => waitHandle.Set());
    wr.WorkflowIdled += ((o, e) => Console.WriteLine("We're idled"));
        

    wi.Start();




    waitHandle.WaitOne();

}

Why do I think this is cool?

Two reasons:

If I assume that I can modify the called service to callback to me (or put such a wrapper at a runtime service level), this is easier to model than the APM (that code included at the end of this post)
This gives me a natural way to start exposing more advanced control over a service call. Rather than just a send and receive, I can use a send and a listen, and in the listen have a receive, a cancel message receive, and a delay in order to expose more fine grained control points for my workflow, and model the way the process should work very explicitly and declaratively.

Code for APM approach:

call some services and wait:

   1:  Console.WriteLine("Press <enter> to execute APM approach");

   2:  Console.ReadLine();

   3:  waitHandle = new AutoResetEvent(false);

   4:  Stopwatch sw = new Stopwatch();

   5:  sw.Start();

   6:  lrwc = new WorkflowHost.ServiceReference1.LongRunningWorkClient();

   7:  lrwc.BeginTakeAWhile(1, HandleClientReturn, "one");

   8:  lrwc.BeginTakeAWhile(2, HandleClientReturn, "two");

   9:  lrwc.BeginTakeAWhile(3, HandleClientReturn, "three");

  10:  lrwc.BeginTakeAWhile(4, HandleClientReturn, "four");

  11:  while (!areDone)

  12:  {

  13:      System.Threading.Thread.Sleep(25);

  14:  }

  15:  Console.WriteLine("APM approach compelted in {0} milliseconds", sw.ElapsedMilliseconds);

  16:  Console.WriteLine("All Done, press <enter> to exit");

  17:  Console.ReadLine();

Ignore the busy wait on line 11, I should use a waithandle here but was having trouble getting it to work correctly (this is hard code).

The callback and respective state:

   1:  static ServiceReference1.LongRunningWorkClient lrwc;

   2:  static Int32 countOfFinished = 0;

3:

   4:  static void HandleClientReturn(IAsyncResult result)

   5:  {

   6:      string s = (string)result.AsyncState;

   7:      string resultString = lrwc.EndTakeAWhile(result);

   8:      Console.WriteLine("received {0}", resultString);

   9:      if (Interlocked.Increment(ref countOfFinished) == 4)

  10:      {

  11:          areDone = true;

  12:      }

  13:  }

I have had some people say that line 9 should use Interlocked.CompareExchange in order to do this correctly, but the point is that this is tricky code, that modeling in WF is pretty nice. [ignoring for the moment the work required to realize the assumption that we can make the service message back.]

Q & A on Advanced Workflow Services talk

mwinkle — Thu, 07 Aug 2008 22:13:30 GMT

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 we have this built into a custom binding? (or an extra binding element) So with every call from the client the (WF)context information is included. And the developer is not required to follow a (artificial) state machine.

Note, at the time, when the service calls back, the endpoint (and the binding) of the client may have changed... So we may need dynamic name-endpoint resolution (sounds like DNS?)

Martin

The question here is generally also asked as "wait, why do I need to explicitly provide a context token and change the contract to have this context thing?" This is a common question, as changing the contract to reflect implementation details is generally a no-no. There's one part I left out as well, so let me add that here:

In the real world, one may also wish to not change the contract (or may not have the ability to). In that case, we still need to explicitly provide the context token and endpoint information in order to allow me to call back. There are a few ways to do this, of varying complexity and implication:

Put this into the message header and have the other side extract this information and use it the same way.

There are two downsides to this approach:

It still requires management of the other side to agree upon where the context token is being place.
The WF Messaging activities don't give me an easy way to reach in and get to header information, but one could certainly look at some infrastructure level extensions to manage this. This idea of making duplex easier is one thing that Ed will be talking about in his Oslo workflow services talk at PDC

Create a custom binding element.

There is one downside with this approach:

You're creating a custom channel, custom binding element, and all the other stuff that goes along with creating a channel. This is very hard work. If the answer is "you've got to write a channel to do it," we need to do a better job making it easier (see earlier point about Ed's talk).

If that's the behavior that you want, you are certainly welcome do go down that path, it would be great to hear about your experiences doing it!
The upside to this approach:

You're creating a layer of near infinite extensibility, allowing you to handle simple things to the complex dynamic endpoint resolution behavior, once you invest the cost once to create the channel that would sit there and do that.

This is also the same approach one could take with using an implicit, or content based correlation scheme. In that case, you create an intermediary that is responsible for translating message contents into the "addressing" information for the instance. That intermediary can be a service, it could be a channel, and once you put that intermediary in place, you are free to do as sophisticated or as simple work as possible.

Advanced Workflow Services Talk (Demo 2 of 4)

mwinkle — Wed, 06 Aug 2008 21:30:04 GMT

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, let me know when it is done
[abstract] I ask you to start doing something, you update me on the status

One may ask the question, "But, what about the wsHttpDualBinding, or WCF duplex bindings." That's a valid question, but it's important to point out that those bindings are really used to describe the behavior of a given proxy instance (and associated service artifacts). When my proxy dies, or the underlying connection goes away, I lose the ability for the service to call back to me. Additionally, this binds me to listen in the same way that I sent out the initial message.

By modeling this at the application layer, we do lose some of the "automagicity" of the WCF duplex behavior, but I get more flexibility, and I get the ability to sustain potentially repeated recycling of the services and clients. Also, you could imagine a service that I call that turns around and calls a third party service. That third party service could call back directly to the client that made the initial call. Note, once we start doing duplex communication (and we'll encounter this in part 4, conversations), is that the definition of "client" and "service" become a bit muddier.

So, to the code:

Ingredients:

My service workflow, I listen for three different messages (start, add item, complete ), and then I will send the message back to the client:
- You'll note that there is a loop so that we can keep adding items until we eventually get the complete order message and we then exit the loop.
A "client" workflow, which will call this service:
- You'll note, some of the magic happens here. After I start, add and complete the order, you'll see that instead of sending messages, I'll now flip around and wait on the receive in order to receive the shipping cost from the service.

Details

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.

Let's look at the contract of the service:

[ServiceContract(Namespace ="http://microsoft.com/dpe/samples/duplex")]
public interface  IOrderProcessing
{
    [OperationContract()]
    void SubmitOrder(string customerName, IDictionary<string, string> context);

    [OperationContract(IsOneWay = true )]
    void AddItem(OrderItem orderItem);

    [OperationContract(IsOneWay = true )]
    void CompleteOrder();
}

You'll note that on the SubmitOrder method, I pass in a context token. This is my callback correlation identifier, this is how I will figure out what instance on the client side I want to talk to. Now, I need to do some work to get the context token in order to send, so let's look at how we do this:

On the client side, on the first Send activity, let's hook the BeforeSend event.

Let's look at the implementation of GrabToken:

   1:  private void GrabToken(object sender, SendActivityEventArgs e)

   2:  {

   3:      ContextToSend = receiveActivity1.Context;

   4:      Console.WriteLine("Received token to send along");

   5:  }

6:

   7:  public static DependencyProperty ContextToSendProperty = DependencyProperty.Register("ContextToSend", typeof(System.Collections.Generic.IDictionary<string, System.String>), typeof(OrderSubmitter.Workflow1));

8:

   9:  [DesignerSerializationVisibilityAttribute(DesignerSerializationVisibility.Visible)]

  10:  [BrowsableAttribute(true)]

  11:  [CategoryAttribute("Parameters")]

  12:  public System.Collections.Generic.IDictionary<string, String> ContextToSend

  13:  {

  14:      get

  15:      {

  16:          return ((System.Collections.Generic.IDictionary<string, string>)(base.GetValue(OrderSubmitter.Workflow1.ContextToSendProperty)));

  17:      }

  18:      set

  19:      {

  20:          base.SetValue(OrderSubmitter.Workflow1.ContextToSendProperty, value);

  21:      }

  22:  }

First, note that on lines 7-22 we declare a dependency property call ContextToSend. Think of this simply as a bindable storage space. On line 3, we go and assign to that the value of receiveActivity1.Context. "But Matt, couldn't I just build a context token off the workflow ID?" You could, but you're only going to be correct in the "simple scenario." You can see we then take that ContextToSend, and pass that into the context parameter for the service operation. Always walk up and ask a Receive activity for its context token, don't try to build one on your own.

Now, on the service side, we need to extract that, and we need to apply the value to the send activity in the service workflow that needs to call back. We basically can do the reverse:

private void codeActivity1_ExecuteCode(object sender, EventArgs e)
{
    //set callback context
    sendActivity1.Context = callbackContext;
}

This is inside a code activity in the first receive activity. callbackContext is a dependency property that is bound to the inbound context on the Receive activity.

The final trick is that both workflows have to be hosted inside a WorkflowServiceHost. This makes sense for the "service" workflow, since it will be message activated. On the client side, we have to do a little bit of work in order to get to the workflow runtime to spin up a workflow instance. In the early betas, we had an easy way to get to the runtime, WorkflowServiceHost.WorkflowRuntime. In order to conform more with the extensibility of WCF, this has been moved to the extensions of the service host. We get there by:

   1:  static void Main(string[] args)

   2:  {

   3:      using (WorkflowServiceHost wsh = new WorkflowServiceHost(typeof(Workflow1)))

   4:      {

   5:          Console.WriteLine("Press <ENTER> to start the workflow");

   6:          Console.ReadLine();

   7:          wsh.Open();

   8:          WorkflowRuntime wr = wsh.Description.Behaviors.Find<WorkflowRuntimeBehavior>().WorkflowRuntime;

   9:          WorkflowInstance wi = wr.CreateWorkflow(typeof(Workflow1));

  10:          AutoResetEvent waitHandle = new AutoResetEvent(false);

  11:          wr.WorkflowCompleted += delegate { waitHandle.Set(); };

  12:          wr.WorkflowTerminated += delegate(object sender, WorkflowTerminatedEventArgs e) { Console.WriteLine("error {0}", e); waitHandle.Set(); };

  13:          wi.Start();

  14:          waitHandle.WaitOne();

  15:          Console.WriteLine("Workflow Completed");

  16:          Console.ReadLine();

  17:      }

  18:  }

On line 3, you'll see we new up a WorkflowServiceHost based on the service type (it will do this to find and open the respective endpoints). On line 8, we reach in and grab the WorkflowRuntimeBehavior and get the WorkflowRuntime, and we use that to create an instance of the workflow.

So, here's what we have done:

Figure out how to grab the context token from a Receive activity
Modify the contract to explicitly send the "callback info" to the service
On the service side, figure out how to grab that and apply it to a Send activity
Finally, on the client side, how to manually kick off workflows, rather than waiting for them to be message activated (the usual path we have is the infrastructure creating the workflow instance).

Advanced Workflow Services Talk (Demo 1 of 4)

mwinkle — Tue, 05 Aug 2008 20:44:58 GMT

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 to post the code samples, so I want to do that here:

Sample 1, Basic Management of Context

The goal of this sample is to show the way that the context channel works, and how to interact with it from imperative code.

Ingredients:

One basic workflow service that simply has two Receive activities bound to the same operation inside of a sequence.
Inside each Receive, I have placed a Code Activity that simply outputs a little bit of info (the vars declared on lines 1 and 2 are used by the Receive activities:

   1:  public String returnValue = default(System.String);

   2:  public String inputMessage = default(System.String);

3:

   4:  private void codeActivity1_ExecuteCode(object sender, EventArgs e)

   5:  {

   6:      returnValue = string.Format("first activity {0}", inputMessage);

   7:      Output(inputMessage + " Activity 1");

   8:  }

9:

  10:  private void Output(string message)

  11:  {

  12:      Console.WriteLine("Workflow {0} : Message {1}", this.WorkflowInstanceId, message);

  13:  }

14:

  15:  private void codeActivity2_ExecuteCode(object sender, EventArgs e)

  16:  {

  17:      returnValue = string.Format("second activity {0}", inputMessage);

  18:      Output(inputMessage + " Activity 2");

  19:  }

Instructions:

Create a client type that will call the service for us
```
class IWorkflowClient : ClientBase<Intro1.IWorkflow1>, Intro1.IWorkflow1
{
    public IWorkflowClient() : base() { }
    public IWorkflowClient(Binding binding, EndpointAddress address) : base(binding, address) { }
    public string Hello(string message)
    {
        return base.Channel.Hello(message);
    }
}
```

Create a utility function CheckAndPrintContext()

private static void CheckAndPrintContext(IContextManager icm)
{
    if (null != icm) Console.WriteLine("Context contains {0} elements", icm.GetContext().Count);
    if (null != icm)
    {
        if (icm.GetContext().Count > 0)
        {
            foreach (string xmlName in icm.GetContext().Keys)
            {
                Console.WriteLine("key : {0}", xmlName);
                Console.WriteLine("value : {0}", icm.GetContext()[xmlName]);
            }
        }
    }
}

The thing to note here is that we need to traverse the dictionary, since there could be more than one key in here, although there won't be in this sample.

Now, let's run the three different bits of code, we want to first show the happy path, show how to break it, and then show how to explicitly manage the context token
Scenario 1: The Happy Path
```
   1:  private static void DemoOne()
```
```
   2:  {
```
```
   3:      Console.WriteLine("Press Enter to Send a Message and reuse proxy");
```
```
   4:      // Console.ReadLine();
```
```
   5:      Debugger.Break();
```
```
   6:      IWorkflowClient iwc = new IWorkflowClient(new NetTcpContextBinding(),
```
```
   7:          new EndpointAddress("net.tcp://localhost:10001/Intro1"));
```
```
   8:      IContextManager icm = iwc.InnerChannel.GetProperty<IContextManager>();
```
```
   9:      if (null != icm) Console.WriteLine("Context contains {0} elements", icm.GetContext().Count);
```
```
  10:      string s = iwc.Hello("message1");
```
```
  11:      Console.WriteLine("the service returned the message '{0}'", s);
```
```
  12:      CheckAndPrintContext(icm);
```
```
  13:      s = iwc.Hello("message2");
```
```
  14:      icm = iwc.InnerChannel.GetProperty<IContextManager>();
```
```
  15:      CheckAndPrintContext(icm);
```
```
  16:      Console.WriteLine("the service returned the message '{0}'", s);
```
```
  17:      Console.WriteLine("Press Enter to Continue");
```
```
  18:  }
```
- What's going on here?
  - Line 5, a more convenient way in demos to hit a breakpoint
  - Line 10: Call the service
  - Line 12: CheckAndPrint the Context Token. In this case, this will print the Guid of the initiated workflow that is contained in the token
  - Line 13: Call the service a second time
    - Look at the service window, you'll see that this message has been routed to the same instance of the workflow.
    - You can also see in Line 16 that the second activities return message is included.

Scenario 2: The Path Grows Darker

   1:  // show this not working using a second client

   2:  private static void DemoTwo()

   3:  {

   4:      Console.WriteLine("Press Enter to Send a Message (it will break this time)");

   5:      //Console.ReadLine();

   6:      Debugger.Break();

   7:      IWorkflowClient iwc = new IWorkflowClient(new NetTcpContextBinding(),

   8:          new EndpointAddress("net.tcp://localhost:10001/Intro1"));

   9:      IContextManager icm = iwc.InnerChannel.GetProperty<IContextManager>();

  10:      if (null != icm) Console.WriteLine("Context contains {0} elements", icm.GetContext().Count);

  11:      string s = iwc.Hello("message1");

  12:      Console.WriteLine("the service returned the message '{0}'", s);

  13:      CheckAndPrintContext(icm);

  14:      iwc = new IWorkflowClient(new NetTcpContextBinding(),

  15:         new EndpointAddress("net.tcp://localhost:10001/Intro1"));

  16:      s = iwc.Hello("message2");

  17:      Console.WriteLine("the service returned the message '{0}'", s);

  18:      icm = iwc.InnerChannel.GetProperty<IContextManager>();

  19:      CheckAndPrintContext(icm);

  20:      Console.WriteLine("Press Enter to Continue");

  21:  }

What's going on here? (Same until line 14)
- Line 14: Let's create a new proxy.
- Line 15: Call the service using the new proxy. You'll note on the server side that a second workflow instance has been created. This is where we break.
- Line 19: On the client side, you'll see that the second GUID being returned

Scenario 3: Finding the Light

   1:  // show this working with a second client by caching the context

   2:  private static void DemoThree()

   3:  {

   4:      Console.WriteLine("Press Enter to Send a Message (we'll cache the context and apply it to the new proxy)");

   5:      // Console.ReadLine();

   6:      Debugger.Break();

   7:      IWorkflowClient iwc = new IWorkflowClient(new NetTcpContextBinding(),

   8:          new EndpointAddress("net.tcp://localhost:10001/Intro1"));

   9:      IContextManager icm = iwc.InnerChannel.GetProperty<IContextManager>();

  10:      if (null != icm) Console.WriteLine("Context contains {0} elements", icm.GetContext().Count);

  11:      string s = iwc.Hello("message1");

  12:      Console.WriteLine("the service returned the message '{0}'", s);

  13:      CheckAndPrintContext(icm);

  14:      IDictionary<string, string> context = icm.GetContext();

  15:      icm = null;

  16:      iwc = new IWorkflowClient(new NetTcpContextBinding(),

  17:         new EndpointAddress("net.tcp://localhost:10001/Intro1"));

  18:      icm = iwc.InnerChannel.GetProperty<IContextManager>();

  19:      icm.SetContext(context);

  20:      s = iwc.Hello("message2");

  21:      Console.WriteLine("the service returned the message '{0}'", s);

  22:      icm = iwc.InnerChannel.GetProperty<IContextManager>();

  23:      CheckAndPrintContext(icm);

  24:      Console.WriteLine("Press Enter to Exit");

25:

  26:  }

Line 14 is where the magic happens, here' we grab the context token from the IContextManager.
Line 19 is where the magic completes, we apply this token to the new proxy. Note, this proxy could be running on different machine somewhere, but one I get the context token, I can use it to communicate with the same workflow instance that the first call did.

So, what have we shown:

Manipulating context in workflow and imperative code
- How to extract the context token
- How to explicitly set the context token
The caching behavior of the context channel (as seen in Scenario 1)
The behavior of the context channel to return the context token only on the activating message

Workflows that don't start with a Receive

mwinkle — Thu, 17 Jan 2008 22:13:56 GMT

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
myWorkflowServiceHost.Open();
// on some reason to start the workflow
WorkflowRuntime wr = myWorkflowServiceHost.Description.Behaviors.Find<WorkflowRuntimeBehavior>().WorkflowRuntime;
WorkflowInstance wi = wr.CreateWorkflow(typeof(Workflow1));
wi.Start();
// 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.

Regarding Re-use of Context-aware Proxies

mwinkle — Thu, 08 Nov 2007 10:56:57 GMT

Yesterday, following my "What's the context for this conversation" presentation, I was approached with the following question:

I am sharing a singleton client that I want to use to interact with multiple workflow instances, how do I change the context for each of them.

Completely unbeknownst to me, Wenlong, one of the product team's more prolific bloggers, addressed this very topic in his post here, conveniently posted yesterday :-)

Recent WF Content Summary

mwinkle — Tue, 11 Sep 2007 03:11:06 GMT

I've been having some fun playing around with Visual Studio 2008 and the .NET Framework 3.5, and wanted to summarize some of the content I've put up on channel9 and other places.

Samples

The Conversation Sample remixed -- if there is one sample in the SDK to help you understand what is going on with context passing and duplex messaging, this is the sample that helped me learn it. I had this sample reworked a little bit so that you don't have 5 console windows open.
Pageflow sample 1, live hosted -- watch this as pageflow is hosted "live" in the cloud. This lets you interact with a pageflow as well as dive into the code using some tools my team has built.
Pageflow sample 2, live hosted as above -- this is the sample that shows how we can leverage the navigator workflow type to be in multiple paths at the same time (a parallel state machine almost).

Screencasts

Intro demo -- a 10 minute walk through of building Workflow Services
0 to Workflow Service in 60 seconds -- a very quick tools walkthrough
Dynamically creating service contracts using Workflow Services in Net 3.5 -- the way to dynamically create a contract using a workflow first approach to building it.
BizTalk Server 2006 Extensions for WF -- A screencast from Jon Flanders walking through the work that has been done to host WF inside BizTalk.
Building WCF Services with WF -- A screen recording with the PM responsible for the WF-WCF integration
Introduction to the Windows Workflow Foundation Pageflow Sample -- A screen recording with the dev responsible for building pageflow.

Channel9 Videos

Programming JSON with WCF in .NET Framework 3.5 -- an interview with a Dev and PM from the WCF team talking about how and why talking JSON over WCF is interesting.
WF and WCF Integration In .NET Framework 3.5 -- meet the team that brought us the Workflow Service features in .NET 3.5

In the upcoming months, we've got more samples and content coming out about these features. If you've got questions, keep 'em coming.

Picture Services

mwinkle — Thu, 30 Aug 2007 02:27:17 GMT

As Justin announces here, my team recently released the picture services sample. This is a cool way to expose the pictures on a machine that are found via Windows Desktop Search out in a simple, easy to consume REST endpoint.

There are a few things here that I think are pretty cool

Pretty easily return POX and Syndication formatted data, and creating a URI hierarchy (here)
Querying Windows Desktop Search (here)
Adding Simple List Extensions (here)

Justin has a screencast here.

VS 2008 Beta 2 Shipped : 0 to Workflow Service in 60 seconds

mwinkle — Mon, 30 Jul 2007 23:03:19 GMT

So, per Soma's blog, this great Channel9 video, and a bunch of other places, VS 2008 Beta 2 is available for download (go here).

Others are covering their favorite feature in depth, I want to cover one of mine: the WCF test client, which I will show by way of creating a Workflow Service application.

Real quick, for those of you who didn't read the readme file, I know sometimes you just forget, there is an important note regarding how to get this to work (out of the box you will probably get an exception in svcutil.exe).

Running a WCF Service Library results in svcutil.exe crashing and the test form not working
Running a WCF Service Library starts the service in WcfSvcHost and opens a test form to debug operations on the service. On the Beta2 build this results in crash of svcutil.exe and the test form doesn’t work due to a signing problem.
To resolve this issue
Disable strong name signing for svcutil.exe by opening a Visual Studio 2008 Beta2 Command Prompt. At the command prompt run: sn –Vr “<program files>\Microsoft SDKs\Windows\v6.0A\Bin\SvcUtil.exe” (replace <program files> with your program files path – ex: c:\Program Files)

Fire up VS 2008, create a new Sequential Workflow Service Library project:

This creates a basic Sequential workflow with a Receive activity

It also creates an app.config and IWorkflow1.cs

IWorkflow1.cs contains the contract our service is going to implement:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.ServiceModel;

namespace WFServiceLibrary1
{
    // NOTE: If you change the interface name "IWorkflow1" here, 
    // you must also update the reference to "IWorkflow1" in App.config.
    [ServiceContract]
    public interface IWorkflow1
    {
        [OperationContract]
        string Hello(string message);
    }
}

Now, we can modify this as needed, or we can delete it and create the contract as part of the Receive activity, see my previous post here on the topic.

Return to the workflow and take a quick look at the properties of the Receive activity, and note that the parameters for the method (message and (returnValue)) have already been promoted and bound as properties on the workflow, that saves us a quick step or two:

Drop a code activity in the Receive shape, and double click to enter some code:

private void codeActivity1_ExecuteCode(object sender, EventArgs e)
{
    returnValue = String.Format("You entered '{0}'.", inputMessage);
}

Now, we're pretty much there, but let's take a quick look at the app.config

<service name="WFServiceLibrary1.Workflow1" behaviorConfiguration="WFServiceLibrary1.Workflow1Behavior">
  <host>
    <baseAddresses>
      <add baseAddress="http://localhost:8080/Workflow1" />
    </baseAddresses>
  </host>
  <endpoint address=""
            binding="wsHttpContextBinding"
            contract="WFServiceLibrary1.IWorkflow1" />
  <endpoint address="mex" 
            binding="mexHttpBinding" 
            contract="IMetadataExchange" />
</service>

We're going to use the wsHttpContextBinding, which you can think of as the standard wsHttpBinding with the addition of the Context channel to the channel stack. Also note, we can right click the config and open it in the WCF config editor, slick!

Let's hit F5. We build, do a little bit of processing and up pops the WCF test client. You may also note this little pop up from your task tray:

What's this, the "autohosting" of your service, just like you get with ASP.NET on a machine. This saves me the trouble of having to write a host as well as my service when I just want to play around a bit. The test client looks like this:

Double click on the hello operation and fill in a message to send to the service:

Clicking "Invoke" will invoke the service, which will soon return with the value we hope to see. Sure enough, after a bit of chugging along, this returns:

Finally, let's hit the XML tab to see what's in there, and we see it is the full XML of the request and the response. There's an interesting little tidbit in the header of the response:

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" 
xmlns:a="http://www.w3.org/2005/08/addressing" 
xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
  <s:Header>
    <a:Action s:mustUnderstand="1" u:Id="_2">
       http://tempuri.org/IWorkflow1/HelloResponse
     </a:Action>
    <a:RelatesTo u:Id="_3">urn:uuid:3f5b7eb5-cc35-4b01-b345-92f6edf728d7</a:RelatesTo>
    <Context u:Id="_4" xmlns="http://schemas.microsoft.com/ws/2006/05/context">
      <InstanceId>fc0f47fd-dd7b-4030-9883-acbf358583c3</InstanceId>
    </Context>

This is the context token that lets me know how to continue conversing with this workflow. In the test client, I can't find a way to attach it to a subsequent request, meaning we can't use the test client for testing multiple steps through a workflow, but this new feature lets me get up and running, verify connectivity, and be able to set breakpoints and debug my workflow service, which is pretty cool.

I've posted the following video on c9 as a screencast, which I will try to do with my subsequent blog postings.

Orcas Beta 1 Samples (WF, WCF)

mwinkle — Fri, 27 Apr 2007 22:17:42 GMT

Beta 1 samples have been posted. In this release there are separate installs for WF and WCF (and the workflow services are in the WCF one, go figure!)

From Laurence's blog:

This is the only version of the new samples that works at this time. The version that comes with the VS Orcas Beta1 offline Help does not work.
New samples in this release:
WF Samples\Technologies\Rules And Conditions\Order Processing Policy
WCF Technology Samples\Basic\Ajax
WCF Technology Samples\Basic\Syndication
WCF Technology Samples\Basic\WorkflowServices
You can download the zip files through any of the samples.
To setup and run the Orcas Beta1 samples:
1. Setup:
a. Check out the Setup Instructions for the Ajax, Syndication, and Workflow Services samples.
i. Use the Setup scripts under the “OrcasSetup” dir in the downloaded WCF zip file. In contrast, the “Setup” dir includes the scripts necessary for the samples already released with WCF 3.0
b. On Win2K3, if you see a plain text page when connecting to http://localhost/NetFx35Samples/service.svc, you need to run:
“%SystemDrive%\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe” -i –enable
"%WINDIR%\Microsoft.Net\Framework\v3.0\Windows Communication Foundation\ServiceModelReg.exe" -i
c. The WCF Samples setup script Setupvroot.bat will not run unless MSMQ is installed or the NetMsmqActivator service is disabled
2. Ajax samples:
a. For the Simple and Post Ajax service samples, you will need to completely refresh your session to be able to reload ClientPage.htm from one service to another as there is an issue with IE. Or simply rename ClientPage.htm in one of the samples
3. Workflow Services:
a. WorkflowServiceUtility is a reference necessary to the CalculatorClient and DuplexWorkflowServices samples
b. CalculatorClient is the client for both DurableService and StateMachineWorkflowService. Click on “C” to stop the session (it becomes red) before switching services
c. The Conversations client is the window that has “Press enter to submit order”
d. In DuplexWorkflowServices, only the ServiceHost and ClientHost projects need to be started

Technorati Tags: orcas, wf, wcf, samples

Matt W's Windows Workflow Place : WCF

WF4, WCF and AppFabric Sessions @ PDC09

WF Talks

WCF Talks

AppFabric Talks

Which WF/WCF Talks Should You Attend at PDC?

WCF Perf Talk @ PDC (or, the Doctor Teaches Fishing)

More Details On WF/WCF in .NET 4.0

WF Features

WCF Features

Advanced Workflow Service Talk (Demo 4 of 4)

Where can we go from here?

Advanced Workflow Services Talk (Demo 3 of 4)

Code for APM approach:

Q & A on Advanced Workflow Services talk

Advanced Workflow Services Talk (Demo 2 of 4)

Ingredients:

Details

Advanced Workflow Services Talk (Demo 1 of 4)

Sample 1, Basic Management of Context

Ingredients:

Instructions:

Scenario 1: The Happy Path

Scenario 2: The Path Grows Darker

Scenario 3: Finding the Light

Workflows that don't start with a Receive

Creating a Message Activated Workflow

Creating a Non-Message Activated Workflow

Regarding Re-use of Context-aware Proxies

Recent WF Content Summary

Samples

Screencasts

Channel9 Videos

Picture Services

VS 2008 Beta 2 Shipped : 0 to Workflow Service in 60 seconds

Orcas Beta 1 Samples (WF, WCF)