Deploying WF Workflows to Windows Server AppFabric

Introduction

Microsoft released Windows Server AppFabric this summer. AppFabric is a new service platform for .NET developers that helps them easily deploy and manage Windows Communication Foundation (WCF) based services and Windows Workflow Foundation (WF) based workflows, as well as handle high performance distributed caching.

Like a web service, WF based workflows must be hosted by a process. This host runs the WF engine, and processes the workflow you have designed. Until now most developers had a limited list of choices of how to host their workflows.

These were limited to hosting in a SharePoint portal, or in your own custom code (perhaps as a part of a desktop application or a server side service.) This made it challenging to provide all of the support services a running workflow needs in a real environment.

When you are running workflows you want to be able to track the instances of that workflow that is running, as well as the messages that are invariably flowing into and out of the workflow itself. You also have to figure out how to save the state of your workflow to recover from a failed server, and how to sleep your workflow when it will have to wait a long time between steps in the workflow so that it doesn't consume too many resources on your server.

Microsoft released Windows Server AppFabric to resolve a lot of these challenges. It provides a very simple to use and deploy hosting environment for your WCF and WF based services. AppFabric provides a lot of the services we discussed above. It includes diagnostics infrastructure, tracking each message and workflow as they are processed so you can see what is happening on your server. It provides mechanisms to cluster servers, allowing you to load balance the load on your workflow across the servers you have available. It can also recognize when a workflow has crashed (because of either the server, or a code issue) and can restart the workflow on an available server.

If you have ever worked with Microsoft BizTalk Server (which I have for years and love it) you will see that AppFabric is really a light-weight sibling that has many of the same core system features. BizTalk still rules for ecommerce, RFID, true system integrations, and so on. But if all you need is an enterprise grade place to run your workflows, AppFabric is the right tool for you. The great thing is that you can install it with the Web Platform Installer in minutes, and you administer it with the IIS management console you already know and love.

With the release of .NET framework 4 Microsoft has really completed the marriage between WCF and WF. Workflows tend to rely on message passing, and until now it was challenging to send and receive messages over the network with WCF from within WF. Now, sending and receiving messages over WCF are simple shapes provided by WF. The send and receive shapes create your data contacts for the service, and also your service endpoints. Developers consuming your workflow service would have no idea it is running in AppFabric, or as a workflow service. Now workflows are much more like their older cousins from BizTalk, Orchestrations.

Since this article is about how to deploy a WF service to AppFabric we are going to jump into an already developed workflow. It is important to note that there is a new term in the WF world, and that is "Workflow Service." This is a workflow that has a message receive shape as its first shape. This receive shape is an activation shape, which means when the code hosting the workflow receives a new message bound to that port, it will start up (or activate) a new instance of your workflow and pass in that message to get it started. This is differentiated from other receive shapes you might have later in your workflow that are waiting on a response to a message your workflow has sent.

You can still make normal workflows in .NET framework 4 and host them in your own way, but I think they will quickly become a minority. Workflow Services have a .xamlx extension to differentiate them from the more classic workflows.

Our sample workflow will receive a single integer. A random number will be selected between zero and the number passed into the workflow. The workflow will then delay as many seconds as the random number determines. Then the workflow will check if the random number is even or odd. If it is odd, a response message will be sent back to the client with the value of the random number. If it is even, the workflow will force an exception because in our business even numbers cause exceptions. We are forcing the exception as an example to show how AppFabric will handle the error.

The following figure shows what the workflow looks like in Microsoft Visual Studio 2010 Ultimate.

what the workflow looks like
Figure 1

Once you have your workflow running the way you want, we need to package it up for deployment to our AppFabric server. You might want to configure the publishing settings to suit your needs. To do this, right click on your Workflow Services project, and choose properties. Move down to the "Package/Publish Web" tab. In my case, I customized where the package (it is built as a zip file) is copied. I also set the default name of the web site the workflow service should be hosted under. You can see my selections in the following figure. You will need to save these settings. Once you have completed this, right click on your project and choose "Build Deployment Package" from the menu.

choose
Figure 2

The next step to deploying our workflow service is to open the IIS Management Console on the server you want to deploy to. Navigate through the server tree on the left to the web site you want to host the service. Right click on it, and choose "Deploy/Import Application...". You can see what this will look like in the following figure.

Right click on it, and choose
Figure 3

The Import Application wizard will start. You will have to browse to the deployment package you just built. Click next to move on to configuration.

Import Application wizard
Figure 4

In this next step you will be shown all of the moving parts of the service, including configuration changes, and confirm or modify them. The package will include everything that needs to be setup. AppFabric does provide a way for you to change these defaults.

change these defaults
Figure 5

Leave everything checked as is, and click next. Your next step will be to name the path the service will be deployed to. It will default to the value you set in the package options above. Just click next to move on. The wizard will deploy and wire everything up and then give you a final configuration.



Deploying WF Workflows to Windows Server AppFabric

Now that our service is deployed we can start sending messages to it. I will use the testing features of Microsoft Visual Studio 2010 to put a load on the system. I wrote a very simple unit test to call the service, which always submits 60 as a parameter. This will give us a wide range of random numbers, while keeping the test to a reasonable length of time.

[code6.jpg]
Figure 6

Once a Load Test is added to the solution in Microsoft Visual Studio 2010, we can start the test and watch the progress charts as the test is run. I started with a load of 200 users over a period of ten minutes.

[minutes7.jpg]
Figure 7

The goal for us isn't to watch these cool load performance charts, but to put a load on the system so we can explore the service management tools that AppFabric provides to us.

AppFabric will track the events that are happening in your services. This includes receiving and sending messages, and other behaviors in your workflows. You can tell AppFabric how much of this to track, and how to manage the data, in the AppFabric configuration.

When you open the IIS MMC, and select a service or workflow for the site list, you will see an icon for the AppFabric dashboard. If you open that dashboard you will get a high level view of the health and load on your service or workflow. This is really useful to easily spot if there are issues (both errors and performance) with your workflow. A sample screen shot is below. Notice that at this time our workflow has been called 588 times, but that there have been 282 failures of some kind.

[appfabric8.jpg]
Figure 8

If you click on the failures link you be shown a list of the failures. You can then drill into each failure and review the error message, and possibly fix and restart the workflow.

[tracked9.jpg]
Figure 9

If we double click on one of the failures listed we will get all of the details for that failed workflow. In this case we can see the workflow is suspended (it has been frozen due to the error, and is waiting for us to fix or repair something). We can also see that the error message is "Even numbers cause exceptions." While this is a trivial error in our case, this is critical information when you are trying to find out why the workflows keep failing on a particular order.

[wf10.jpg]
Figure 10

You can then drill into the actual event history of a particular workflow instance. In this case I drilled into one of the workflows that had an error. The screen will list all of the events that were processed during the entire lifecycle of the workflow, including how messages were sent and received. These events are automatically captured and logged for you by AppFabric for any hosted service or workflow.

[tracked11.jpg]
Figure 11

Conclusion

AppFabric provides a great hosting platform for our Windows Workflow Foundation 4 workflows. As companies move to adopt Service Oriented Architecture (SOA) our software will rely on families of orchestrated services. This orchestration will be performed by engines like WF and AppFabric, connecting smaller services into large more valuable business processes. Since SOA is so reliant on messaging, AppFabric makes it easy for us to manage our services, inspect the messages, and handle our related workflows. AppFabric is easy to install and manage because of how it plugs into IIS.





About the Author

Brian Prince

Brian H. Prince is an Architect Evangelist with Microsoft focused on building and educating the architect community in his district. Prior to joining Microsoft in March 2008, he was a Senior Director, Technology Strategy for a major mid-west partner.

Further, he is a co-founder of the non-profit organization CodeMash (www.codemash.org). He speaks at various regional and national technology events including TechEd.

Brian holds a Bachelor of Arts degree in Computer Science and Physics from Capital University, Columbus, Ohio. He is also an avid gamer.

Comments

  • There are no comments yet. Be the first to comment!

Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • On-demand Event Event Date: December 18, 2014 The Internet of Things (IoT) incorporates physical devices into business processes using predictive analytics. While it relies heavily on existing Internet technologies, it differs by including physical devices, specialized protocols, physical analytics, and a unique partner network. To capture the real business value of IoT, the industry must move beyond customized projects to general patterns and platforms. Check out this webcast and join industry experts as …

  • Today's agile organizations pose operations teams with a tremendous challenge: to deploy new releases to production immediately after development and testing is completed. To ensure that applications are deployed successfully, an automatic and transparent process is required. We refer to this process as Zero Touch Deployment™. This white paper reviews two approaches to Zero Touch Deployment--a script-based solution and a release automation platform. The article discusses how each can solve the key …

Most Popular Programming Stories

More for Developers

RSS Feeds