Hosting a WF 4.0 workflow service in “Dublin”

I did a post a couple of months back where I showed you how to take a WCF service and host it on the Azure service platform. I thought that was pretty cool, but wanted to take it to the next level. So, why not call that from a .NET 4.0 workflow, and host that workflow in “Dublin” (the set of WCF/WF hosting capabilities being added to the Windows Server application server)?

I heard it was Ron Jacobs that said that with .NET 3.0, WF and WCF “had just met”, in .NET 3.5 they “were dating”, and in .NET 4.0, “they’re married”. It’s a great way to think of it. The integration between WF and WCF now is really tight, and makes it really easy to create, host and expose a WF service using WCF.

I did this using the Community Technology Preview of the .NET 4.0 framework, using the virtual machine that was made available to PDC2008 attendees. Note that as with almost any CTP, it’s a pretty sure thing that there will be changes to the framework between that point in time and the ultimate release, so some of these screenshots, shapes and even steps may become obsolete. As always when working with pre-release software: expect change! I’m not going to say it was quick, but this post could save anyone trying to do the same a lot of time.

First step was to create a new project using the Windows Application Server template in Visual Studio 2010 PDC CTP (this will not be required in the release, it will just be workflow project).

I added a ServiceOperation step, which is how I will expose the service to the outside world. The collapse sequence inside the “after receiving message” is where we will consume the service.






With the PDC08 CTP VM, you need to define the operation contracts for both consumed and exposed service.


This first operation contract is the contract we will expose to the outside world. As you can see, we accept two string parameters on the way in, and return a string value.



The inside the collapsed sequence here’s where we call the service:



OK, so far this is pretty cool, but what could make it cooler? Take a look at the URI… That’s a WCF service that I wrote that’s hosted in the cloud, on the Azure Services Platform.

And next is the operation contract definition of the service we are calling (the client operation). Hard lesson learned: you need to be REALLY careful with names you enter in the consumed service operation contract, or you’ll end up with a mismatch with the service WSDL, and invoking it will fail. This can be challenging to troubleshoot. This is after all a CTP, so, there are bound to be some areas that are opportunities for improvement.


For completeness and to close the loop in this post, I invoke my workflow service using the WCF test client application:



I thought it would be nice to echo out information to the debugger as the service was executing, so I created a custom workflow element to do that, which is the “DebugWriteActivity” you see above. I wanted to pass in a string from the host workflow, the technique is shown below.



So there you have it. With virtually no code I created a workflow service (hosted in “Dublin”), which was exposed as a WCF service, and in turn consumed a WCF service that was hosted in Azure.

I’d like to thank Cliff Simpkins (Microsoft) and Zoiner Tejada (Hershey Technologies) for their assistance as I went down this path. I’d also like to thank the people staying on my floor at the Hyatt for not calling security when I first saw this work calling an Azure-based service, my reaction was somewhat errr…. “non-subdued” ;)

PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>