Matt W's Windows Workflow Place : Orcas

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.

VS 2008 RTM's!

mwinkle — Mon, 19 Nov 2007 21:53:53 GMT

As widely reported on blogs far and wide, Visual Studio 2008 has been released to manufacturing (or shipped, available, ready to get, etc). MSDN subscribers can do their part to degrade the global bandwidth supply and get in the download queue via the subscription center, trial editions are available here. One can also simply get the updated version of the .NET Framework, .NET 3.5 here, and I'd strongly recommend the web setup to only get the bits you need on the machine, and not ones you may already have.

While you're waiting for those bits to get downloaded, you might find yourself with some free time watching the status bar slowly move in the direction of completion. Maybe I can interest you in some quality work that has been done by my former team (more on that in the next day or two).

First, I would grab the VS 2008 Training Kit, which consists of a metric boatload of labs, content, presentations and sample code to get you excited. This is something my colleague, David Aiken, has been hard at work putting together. In David's words:

The Visual Studio 2008 and .NET Framework 3.5 Training Kit includes presentations, hands-on labs, and demos. This content is designed to help you learn how to utilize the Visual Studio 2008 features and a variety of framework technologies including: LINQ, C# 3.0, Visual Basic 9, WCF, WF, WPF, ASP.NET AJAX, VSTO, CardSpace, SilverLight, Mobile and Application Lifecycle Management.

This content was developed over the last few months. As part of the development process, we presented many of the topics to real people we invited to Redmond. In September we recorded these sessions and are making these available on Channel 9. There will be several videos posted each Monday for the next few weeks. Today I posted:

Lap around Visual Studio 2008 & .NET Framework 3.5 presented by James Conard

What's new in C# 3.0? presented by Luke Hoban

What's new in Visual Basic 9.0? presented by Amanda Silver

.NET Framework 3.5 Enhancements presented by Jack Gudenkauf

.NET Language Integrated Query (LINQ) presented by Luca Bolognese

Using LINQ with Relational Data presented by Mike Pizzo

ADO Synchronization Services presented by Steve Lasker

The Channel9 videos are especially good, these are all various Microsoft folks from the product teams presenting about their individual area of expertise. I especially recommend the What's new in VB9 and intro to LINQ talk. There are some pretty cool things in VB9, and I think the XML support is something really cool. For those of you from the WF world, inside the training kit is a presentation on the WF-WCF integration, as well as a set of labs and demos that walk through simple to complex use cases.

That should be enough to get you through a few hours of downloading :-)

Congrats to all the product teams involved in shipping, it's always incredible to me to see how we actually ship software out of this place (and to get to take part in bits and pieces of it).

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 :-)

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.

Paste XML as Serializable Type

mwinkle — Tue, 15 May 2007 00:45:24 GMT

Every now and then, there's a really cool feature that's buried somewhere that just hits you and makes you say "Wow, that's insanely helpful, why didn't somebody think of this sooner."

I was playing around with the BizTalk Services SDK, specifically the different web programming bits and pieces and stumbled up on the Paste As Serializable visual studio add in (navigate to BizTalk Services SDK\Samples\Web\Tooling).

Let's say you're interested in programming against some services that return normal, plain XML. Well, nobody likes writing code to query XML, Linq to XML is fun, but I'd just really like to mess around with some objects and not really deal with how it looks over the wire or under the hood.

This great little utility lets you select some snippet of XML (say I get it from here, because I am working on a Twitter mashup). Copy the XML to the clipboard (here's a snippet of what the XML looks like).

<statuses>
  <status>
    <created_at>Wed May 02 16:54:45 +0000 2007</created_at>
    <id>47434042</id>
    <text>has advil &amp; beineigts in the back of Steve and Don's talk in 4101B.  Anybody needing either is welcome to some, the pastries will go fast.</text>
    <user>
      <id>5440022</id>
      <name>Matt Winkler</name>
      <screen_name>mwinkle</screen_name>
      <location>Seattle</location>
      <description>workflow technical evangelist</description>
      <profile_image_url>http://assets2.twitter.com/system/user/profile_image/5440022/normal/Matt_Winkler-72dpi.jpg?1177350091</profile_image_url>
      <url>http://blogs.msdn.com/mwinkle</url>
      <protected>false</protected>
    </user>
  </status>

Go into Visual Studio into a code file and open up the edit menu.

There, clearly indicated by the "this is just an alpha icon," is the option to "Paste XML as Serializable Type". Here's what it outputs:

   [System.Xml.Serialization.XmlRootAttribute(Namespace = "", ElementName = "statuses")]
    public class StatusesClass
    {

        private System.Collections.Generic.List<StatusClass> statusField;

        [System.Xml.Serialization.XmlElementAttribute(Namespace = "", ElementName = "status")]
        public virtual System.Collections.Generic.List<StatusClass> Status
        {
            get
            {
                return this.statusField;
            }
            set
            {
                this.statusField = value;
            }
        }

        [System.Xml.Serialization.XmlRootAttribute(Namespace = "", ElementName = "status")]
        public class StatusClass
        {

            private string created_atField;
            private string idField;
            private string textField;
            private UserClass userField;
            [System.Xml.Serialization.XmlElementAttribute(Namespace = "", ElementName = "created_at")]
            public virtual string Created_at
            {
                get
                {
                    return this.created_atField;
                }
                set
                {
                    this.created_atField = value;
                }
            }

...

Remainder of code truncated for the sake of the readers.

This lets me do some cool stuff like this:

static void Main(string[] args)
{
    WebHttpClient twc = new WebHttpClient();
    twc.UriTemplate = "http://twitter.com/statuses/user_timeline/mwinkle.xml";
    StatusesClass sc = twc.Get().GetBody<StatusesClass>();
    Console.WriteLine("Got {0}", sc.Status.Count);
    
}

And get my result back in a nice typed object that I can then use elsewhere in my code (or at least debug)

Steve, thanks, this thing rocks!

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

Dynamically Generating an Operation Contract in Orcas using WF

mwinkle — Fri, 27 Apr 2007 19:45:00 GMT

This kicks off a set of posts where I'll be discussing some of the interesting features coming out in Orcas.

I want to focus on this post on the Receive Activity, and a nice little feature in the designer that lets you create a contract on the fly, without having to drop into code and write a decorated interface. This allows us to divide the world into two approaches:

One where I design my contract first, and then start creating a workflow to implement the operations on the contract.
Design my workflow first, and have it figure out the contract for me (this is what I will focus on in more detail)

Designing a Contract First

This is what most WCF folks will be familiar with:

[ServiceContract]
public interface IOrderProcessing
{

    [OperationContract]
    bool SubmitOrder(Order order);

    [OperationContract]
    Order[] GetOrders(int customerId);
}

When I drop a receive activity onto a workflow, I can now import this contract:

This will bring up a type chooser that lets me pick my service contract:

This imports all of the details and we can see the the operation picker

If we look at the activity properties we now see the parameters to the method. The (ReturnValue) is the object that we need to return in the operation. The order parameter is the message that is going to be passed when the method is called. I can take that and bind that to values in my workflow or whatever I want to do with it.

Designing a Workflow First

The other approach we can take is to create the contract as we create the workflow. That's right, we don't need to create the contract explicitly in code. To do that, drop a receive activity onto the designer and double click. Instead of selecting "Import Contract" select "Add Contract". This will create a new contract with a basic operation. By selecting the contract or the operation we can name it something a little nicer.

By selecting the operation, I can customize all of its behavior. I can create parameters to be passed in, I can set the types of those parameters (as well as the return type of the operation).

It's relevent to point out that I can select any type that would be valid in a WCF contract. The drop down list displays the basic types, but by selecting "Browse Type" I am brought into a type picker where I can select custom types. As you can see below I have created a "CancelOrder" operation that takes in an order, the reason and who authorized the cancellation.

When I click ok, my activity has had new dependency properties added to it, as can be seen in the property grid for the activity.

So what's happening here?

In the workflow I created, I used a code separation workflow, so I have an .xoml file which contains the workflow definition. Let's take a quick peek at how the receive activity is defined (note, some of the xml is truncated, if you view in an rss reader or copy and past you can see all the details, I'll work on updating the blog layout):

    <ns0:ReceiveActivity x:Name="receiveActivity2">
        <ns0:ReceiveActivity.ServiceOperationInfo>
            <ns0:OperationInfo PrincipalPermissionRole="administrators" Name="CancelOrder" ContractName="MyContract">
                <ns0:OperationInfo.Parameters>
                    <ns0:OperationParameterInfo Attributes="Out, Retval" ParameterType="{x:Type p9:Boolean}" Name="(ReturnValue)" Position="-1" xmlns:p9="clr-namespace:System;Assembly=mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
                    <ns0:OperationParameterInfo Attributes="In" ParameterType="{x:Type p9:Order}" Name="order" Position="0" xmlns:p9="clr-namespace:WcfServiceLibrary1;Assembly=WcfServiceLibrary1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
                    <ns0:OperationParameterInfo Attributes="In" ParameterType="{x:Type p9:String}" Name="reason" Position="1" xmlns:p9="clr-namespace:System;Assembly=mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
                    <ns0:OperationParameterInfo Attributes="In" ParameterType="{x:Type p9:String}" Name="authorizedBy" Position="2" xmlns:p9="clr-namespace:System;Assembly=mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
                </ns0:OperationInfo.Parameters>
            </ns0:OperationInfo>
        </ns0:ReceiveActivity.ServiceOperationInfo>
    </ns0:ReceiveActivity>

Here you can see that within the metadata of the activity, we have the definition for the contract and the operation that I defined. When we spin up a WorkflowServiceHost to host this workflow as a service, the host will inspect the metadata for the workflow, looking for all of the endpoints and will create them. You can also see within the OperationInfo element that I am able to define the PrincipalPermissionRole defining the role of allowed callers, taking advantage of the static security checks which I will talk about in another post. So, defined declaratively in the XAML is the contract for the operations. I didn't need to write the interface or the contract explicitly, I was able to write a workflow, specifiy in the workflow how it will communicate and then let the WorkflowServiceHost figure out the nitty gritty details of how create the endpoints. The other part here that is important to mention is that the config will play a part determining what the transport channel and other such details will be. Within the config, when we set up an endpoint we need to specify the contract is "MyContract", or the name that we assigned when we created it.

Summary

We talked about the way that we can implement contracts that already exist in a receive activity, as well as how we can use the designer to actually create our contract while we are designing the workflow. The WorkflowServiceHost does the heavy lifting here in order to enable this little bit of nifty-ness.

WCF and WF in "Orcas"

mwinkle — Thu, 01 Mar 2007 01:55:00 GMT

The wheels of evangelism never stop rolling. Just a few months ago I was blogging that .NET 3.0 was released. I've been busy since then, and now I can talk about some of that. Today, the March CTP of Visual Studio "Orcas" was released to the web. You can get your fresh hot bits here. Samples will be coming shortly. Thom has a high level summary here.

UPDATE: Wendesday, 2/28/2007 @ 11pm. The readme file is posted here, a few minor corrections have been made to the caveats below.

More updates... corrections to another caveat (a post-build event is required to get the config to be read).

A Couple of Minor Caveats

Since this is a CTP, it's possible that sometimes the wrong bits end up in the right place at the wrong time. Here are a few things to be aware of (not intended to be a comprehensive list):

Declarative Rules in Workflows: There is an issue right now where the .rules file does not get hooked into the build process correctly.
- Solution: Use code conditions, or load declarative rules for policy activiites using the RulesFromFile activity available at the community site
WF Project templates are set to target the wrong version: As a result, trying to add assemblies that are 3.0.0.0 or greater will not be allowed.
- Solution: Right click the project, select properties, and change the targeted version of the framework to 3.0.0.0 or 3.5.0.0
A ServiceHost may not read config settings because the app config does not get copied to the bin (update: only on server 2003): You will get an exception that "no application endpoints can be found"

Add the following Post Build Event "copy “$(ProjectDir)\app.config” $(TargetName).config "
~~Solution: For the time being, configure the WorkflowServiceHost in code (using AddServiceEndpoint() and referencing the WorkflowRuntime property to configure any services on the workflow runtime~~
This also means that a number of the workflow enabled services samples will not work out of the box. Replace the config based approach with the code based approach and you will be fine. I will try to post modified versions of these to the community site shortly.

~~Workflow~~ServiceHost exception on closing: You will get an exception that "~~Application image file could not be loaded...~~ System.BadImageFormatException: An attempt was made to load the program with an incorrect format"
- Solution: Use the typical "These are not the exceptions you are looking for" jedi mind trick. Catch the exception and move along in your application, as if there is nothing to see here.
Tools from the Windows SDK that you've come to know and love, like SvcConfigEditor and SvcTraceViewer are not available on the VPC.
- Solution: Copy these in from somewhere else and they will work fine. The SvcConfigEditor will even pick up the new bindings and behaviors to configure the services for some of the new functionality.

The CTP is not something that is designed for you to go into production with, it's designed to let you explore the technology. There is no go-live license associated with this, it's for you to learn more about the technology. Since most of these issues have some work around, this shouldn't prevent you from checking these things out (because they are some kind of neat).

New Features In WF and WCF in "Orcas"

Workflow Enabled Services

We've been talking about this since we launched at PDC 2005. There was a session at TechEd 2006 in the US and Beijing that mentioned bits and pieces of this. One of the key focus areas is the unification of WCF and WF. Not only have the product teams joined internally, the two technologies are very complementary. So complementary that everyone usually asks "so how do I use WCF services here?" when I show a workflow demo. That's fixed now!

Workflow enabled services allow two key things:

Easily consume WCF services inside of a workflow
Expose a workflow as a WCF service

This is accomplished by the following additions built on top of v1:

Messaging Activities (Send and Receive)
- With designer support to import or create contracts
WorkflowServiceHost, a derivation of ServiceHost
Behavior extensions that handles message routing and instantiation of workflows exposed via services.
Channel extensions for managing conversation context.

The Send and Receive activites live inside of the workflow that we define. The cool part of the Receive activity is that we have a contract designer, so you don't have to dive in and create an interface for the contract, you can just specifiy it right on the Receive activity, allowing you a "workflow-first" approach to building services.

Once we've built a workflow, we need a place to expose it as a service. We use the WorkflowServiceHost which is a subclass of ServiceHost in order to host these workflow enabled services. The WorkflowServiceHost takes care of the nitty-gritty details of managine workflow instances, routing incoming messages to the appropriate workflow and performing security checks as well. This means that the code required to host a workflow as a WCF service is now reduced to four lines of code or so. In the sample below, we are not setting the endpoint info in code due to the issue mentioned above.

   1:  WorkflowServiceHost wsh = new WorkflowServiceHost(typeof(MyWorkflow));

   2:  wsh.Open();

   3:  Console.WriteLine("Press <Enter> to Exit");

   4:  Console.ReadLine();

   5:  wsh.Close();

To support some of the more sophisticated behavior, such as routing messages to a running workflow, we introduce a new channel extension responsible for managing context. In the simple case, this context just contains the workflowId, but in a more complicated case, it can contain information similar to the correlation token in v1 that allows the message to be delivered to the right activity (think three receives in parallel, all listing on the same operation). Out of the box there is the wsHttpContextBinding and the netTcpContextBinding which implicitly support the idea of maintaining this context token. You can also roll your own binding and attach a Context element into the binding definition.

The Send activity allows the consumption of a service, and relies on configuraiton to detemrine exactly how we will call that service. If the service we are calling is another workflow, the Send activity and the Receive activity are aware of the context extensions and will take advantage of them.

With the Send and Receive actiivty, it gets a lot easier to do workflow to workflow communicaiton, as well as more complicated messaging patterns.

Another nice feature of the work that was done to enable this is that we know have the ability to easily support durable services. These are "normal" WCF services written in code that utilize an infrastructure similar to the workflow persistence store in order to provide a durable storing of state between method calls.

As you can imagine, I'll be blogging about this a lot more in the future.

JSON / AJAX Support

While there has been a lot of focus on the UI side of AJAX, there still remains the task of creating the sources for the UI to consume. One can return POX (Plain Old Xml) and then manipulate it in the javascript, but that can get messy. JavaScript Object Notation (JSON) is a compact, text-based serialization of a JavaScript object. This lets me do something like:

var stuff = {"foo" : 78, "bar" : "Forty-two"};
document.write("The meaning of life is " + stuff.bar);

In WCF, we can now return JSON with a few switches of config. The following config:

   1:  <service name="CustomerService">

   2:      <endpoint contract="ICustomers"

   3:        binding="webHttpBinding"

   4:        bindingConfiguration="jsonBinding"

   5:        address="" behaviorConfiguration="jsonBehavior" />

   6:  </service>

7:

   8:  <webHttpBinding>

   9:          <binding name="jsonBinding" messageEncoding="Json" />

  10:  </webHttpBinding>

11:

  12:  <behaviors>

  13:     <endpointBehaviors>

  14:          <behavior name ="jsonBehavior">

  15:            <webScriptEnable />

  16:          </behavior>

  17:      </endpointBehaviors>

  18:   </behaviors>

will allow a function like this:

   1:  public Customer[] GetCustomers(SearchCriteria criteria)

   2:  {

   3:     // do some work here

   4:     return customerListing;

   5:  }

to return JSON when called. In JavaScript, I would then have an instance of a CustomerOrder object to manipulate. We can also serialize from JavaScript to JSON so this provides a nice way to send parameters to a method. So, in the above method, we can send in the complex object SearchCriteria from our JavaScript. There is an extension to the behavior that creates a JavaScript proxy. So, by referencing /js as the source of the script, you can get IntelliSense in the IDE, and we can call our services directly from our AJAX UI.

We can also use the JSON support in other languages like Ruby to quickly call our service and manipulate the object that is returned.

I think that's pretty cool.

Syndication Support

While we have the RSS Toolkit in V1, we wanted to make syndication part of the toolset out of the box. This allows a developer to quickly return a feed from a service. Think of using this as another way to expose your data for consumption. We have introduced a SyndicationFeed object that is an abstraction of the idea of a feed that you program against. We then leave it up to config to determine if that is an ATOM or RSS feed (and, would it be WCF if we didn't give you a way to implement a custom encoding as well?) So this is cool if you just want to create a simple feed, but it also allows you to create a more complicated feed that has content that is not just plain text. For instance, the digg feed has information about the submission, the flickr feed has info about the photos. Your customer feed may want to have an extension that contains the customer info that you will allow your consumers to have access to. The SyndicationFeed object allows you to create these extensions and then the work of encoding it to the specific format is taken care of for you. So, let's seem some of that code (note, this is from the samples above):

   1:  public SyndicationFeed GetProcesses()

   2:  {

   3:      Process[] processes = Process.GetProcesses();

4:

   5:      //SyndicationFeed also has convenience constructors

   6:      //that take in common elements like Title and Content.

   7:      SyndicationFeed f = new SyndicationFeed();

8:

   9:      //Create a title for the feed

  10:      f.Title = SyndicationContent.CreatePlaintextTextSyndicationContent("Currently running processes");

  11:      f.Links.Add(SyndicationLink.CreateSelfLink(OperationContext.Current.IncomingMessageHeaders.To));

12:

  13:      //Create a new RSS/Atom item for each running process

  14:      foreach (Process p in processes)

  15:      {

  16:          //SyndicationItem also has convenience constructors

  17:          //that take in common elements such as Title and Content

  18:          SyndicationItem i = new SyndicationItem();

19:

  20:          //Add an item title.

  21:          i.Title = SyndicationContent.CreatePlaintextTextSyndicationContent(p.ProcessName);

22:

  23:          //Add some HTML content in the summary

  24:          i.Summary = new TextSyndicationContent(String.Format("<b>{0}</b>", p.MainWindowTitle), TextSyndicationContentKind.Html);

25:

  26:          //Add some machine-readable XML in the item content.

  27:          i.Content = SyndicationContent.CreateXmlSyndicationContent(new ProcessData(p));

28:

  29:          f.Items.Add(i);

  30:      }

31:

  32:      return f;

  33:  }

And the config associated with this would be:

   1:  <system.serviceModel>

   2:    <services>

   3:      <service name="ProcessInfo">

   4:         <endpoint address="rss"

   5:             behaviorConfiguration="rssBehavior" binding="webHttpBinding"

   6:             contract="HelloSyndication.IDiagnosticsService" />

   7:        <endpoint address="atom"

   8:             behaviorConfiguration="atomBehavior" binding="webHttpBinding"

   9:             contract="HelloSyndication.IDiagnosticsService" />

  10:      </service>

  11:    </services>

  12:    <behaviors>

  13:      <endpointBehaviors>

  14:        <behavior name="rssBehavior">

  15:          <syndication version="Rss20"/>

  16:        </behavior>

  17:        <behavior name="atomBehavior">

  18:          <syndication version="Atom10"/>

  19:        </behavior>

  20:      </endpointBehaviors>

  21:    </behaviors>

  22:  </system.serviceModel>

This config will actually create an RSS and an ATOM endpoint. The feed returned would have the process information embedded as: (in this case in ATOM)

   1:  <entry>

   2:    <id>fe1f1d2e-d676-417d-85bf-b7969dd07661</id>

   3:    <title type="text">devenv</title>

   4:     <summary type="html">&lt;b&gt;Conversations - Microsoft Visual Studio&lt;/b&gt;</summary>

   5:     <content type="text/xml">

   6:       <ProcessData xmlns="http://schemas.datacontract.org/2004/07/HelloSyndication"

   7:              xmlns:i="http://www.w3.org/2001/XMLSchema-instance">

   8:              <PeakVirtualMemorySize>552157184</PeakVirtualMemorySize>

   9:              <PeakWorkingSetSize>146124800</PeakWorkingSetSize>

  10:              <VirtualMemorySize>456237056</VirtualMemorySize>

  11:        </ProcessData>

  12:     </content>

  13:  </entry>

We can also use the Syndication support to consume feeds!

   1:  SyndicationFeed feed = new SyndicationFeed();

   2:  feed.Load(new Uri("http://blogs.msdn.com/mwinkle/atom.xml"));

   3:  foreach (SyndicationItem item in feed.Items)

   4:  {

   5:     // process the feed here

   6:  }

In the case where there have been extensions to the feed, we can access those as the raw XML or we can attempt to deserialize into an object. This is accomplished in the reverse of the above:

   1:  foreach (SyndicationItem i in feed.Items)

   2:  {

   3:      XmlSyndicationContent content = i.Content as XmlSyndicationContent;

   4:      ProcessData pd = content.ReadContent<ProcessData>();

5:

   6:      Console.WriteLine(i.Title.Text);

   7:      Console.WriteLine(pd.ToString());

   8:  }

HTTP Programming Support

In order to enable both of the above scenarios (Syndication and JSON), there has been work done to create the webHttpBinding to make it easier to do POX and HTTP programming.

Here's an example of how we can influence this behavior and return POX. First the config:

   1:  <service name="GetCustomers">

   2:    <endpoint address="pox"

   3:              binding="webHttpBinding"

   4:              contract="Sample.IGetCustomers" />

   5:  </service>

Now the code for the interface:

   1:  public interface IRestaurantOrdersService

   2:  {

   3:     [OperationContract(Name="GetOrdersByRestaurant")]

   4:     [HttpTransferContract(Method = "GET")]

   5:     CustomerOrder[] GetOrdersByRestaurant();

   6:  }

The implementation of this interface does the work to get the CustomerOrder objects (a datacontract defined elsewhere). And the returned XML is the datacontract serialization of CustomerOrder (omitted here for some brevity). With parameters this gets more interesting as these are things we can pass in via the query string or via a POST, allowing arbitrary clients that can form URL's and receive XML to consume our services.

Partial Trust for WCF

I'm not fully up to date on all of the details here, but there has been some work done to enable some of the WCF functionality to operate in a partial trust environment. This is especially important for situations where you want to use WCF to expose a service in a hosted situation (like creating a service that generates an rss feed off of some of your data). I'll follow up with more details on this one later.

WCF Tooling

You now get a WCF project template that also includes a self hosting option (similar to the magic Visual Studion ASP.NET hosting). This means that you can create a WCF project, hit F5 and have your service available. This is another are where I will follow up later on.

Wrap Up

So, what now?

Grab the bits
Explore the new features
Give us feedback (through my blog or a channel9 wiki I am putting together now)! What works, doesn't work, what do you like, not like, etc.
Look forward to more posts, c9 videos and screencasts on the features in Orcas.

Matt W's Windows Workflow Place : Orcas

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

VS 2008 RTM's!

Regarding Re-use of Context-aware Proxies

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

Paste XML as Serializable Type

Orcas Beta 1 Samples (WF, WCF)

Dynamically Generating an Operation Contract in Orcas using WF

Designing a Contract First

Designing a Workflow First

So what's happening here?

Summary

WCF and WF in "Orcas"

A Couple of Minor Caveats

New Features In WF and WCF in "Orcas"

Workflow Enabled Services

JSON / AJAX Support

Syndication Support

HTTP Programming Support

Partial Trust for WCF

WCF Tooling

Wrap Up