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

Articolo
07/30/2007

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="https://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="https://www.w3.org/2003/05/soap-envelope" 
xmlns:a="https://www.w3.org/2005/08/addressing" 
xmlns:u="https://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">
       https://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="https://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.

Comments

Anonymous
August 13, 2007
So, I am totally thrilled in my new role at Neudesic , where today, I got to spend quite a bit of time
Anonymous
September 05, 2007
Sounds like a game? One of the goals for the WCF/WF teams was to integrate WCF and WF more closely in

Condividi tramite

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

Comments

Risorse aggiuntive