Windows Workflow Foundation
Windows Workflow Foundation first shipped as part of .NET Framework 3.0, and allows you to add workflow capabilities to your applications. Workflow can be described as the ability to describe some set of coordinated work with minimal of fuss/description. In other words, declaratively. It is especially well suited to apps that are long-running and stop and start execution.
There is a runtime, programming model, and tools/designers for adding workflow capabilities to your applications. You can visually design and debug your workflow in Visual Studio and you can also re-host the workflow designer in a different application. Workflows themselves consist of a set - or tree - of activities defined either in terms of .a NET class or as XAML. Each activity can be thought of as a program statement similar to those you use in code. There is a built-in activity library that includes the IfElse, While, Throw, and Sequence activities, etc. but you can also define your own custom activities.
The WF runtime is in charge of workflow execution, creating and managing running instances of workflows. It is dependent upon a set of services, such as the persistence service, that can save workflow state when a workflow is idle, and the tracking service that enables you to track a running workflow. The runtime can be hosted in any .NET AppDomain, including IIS and WAS.
The .NET Services Workflow Service is yet another environment where you can host the WF runtime and execute workflows, only this is not running on-premise but in the cloud, on machines and data centers operated and maintained by Microsoft. Running your own servers gives you full control but it can be challenging. For example, how do you make sure no workflows are “lost” when doing machine maintenance. What the workflow service provides is a means to execute workflows with high availability and scalability with a very low bar to entry.
Service Bus Workflow
Service is a reliable and scalable host for workflows that runs in the cloud. Workflows run across a distributed overlay fabric in the Microsoft data centers and workflows are persisted using of SQL Services. You can upload and manage workflows using the workflow portal.
You can use a subset of the Windows Workflow activities available in .NET Framework 3.0 and 3.5 plus some new activities provided as part of the .NET Services SDK.
Besides the portal, there is a client API and a SOAP API that enable you to do all your maintenance of workflow types and instances programmatically as well.
Once you have a workflow in the cloud you can connect to it from anywhere on the Internet using the Service Bus. This can be from inside your enterprise but you can also allow your partners and customers to have access. Like the Service Bus, the Workflow Service is integrated with the Access Control Service so you can determine exactly who has access to the workflow.
There are new activities for the Azure Services Platform. In the current CTP there are 7 new activities. For example, there’s one for sending a message to the Service Bus. There is a subset of WF activities that you can use in cloud-based workflow. In the coming CTPs we will be adding to this set of activities. Note, however, that currently it’s not possible to create custom activities and run them in the cloud. We will be adding this ability later.
The workflow designer is the same as you use for WF - you use the same tools in Visual Studio and you create a sequential workflow the same way as you do for WF. There is not yet support for state machine workflows. You could also just create the XAML by hand or using some other tool.
Once you have built your workflow in the workflow designer, you can deploy, run and manage that workflow in Service Bus Workflow using Visual Studio, the portal and the management APIs.
Building Workflows (Activities)
Here is the complete list of workflow activities available in the current CTP, from the Microsoft.Workflow.Activities namespace:
- CloudDelay: This activity provides the logic to establish a timer and wait asynchronously for the timer expiration.
- CloudHttpReceive: This activity receives an HTTP request at the URI http://workflow.windows.net/workflowsHttp/<SolutionName>/workflows/<WorkflowTypeName>/instances/ <InstanceId>/<ActivityName> and returns a response. The HTTP listener uses Access Control Service and the operation name "Send".
- CloudHttpSend: This activity sends an HTTP request and returns the response.
- CloudServiceBusSend: This activity sends a message to the Service Bus and returns a response if appropriate.
- CloudServiceBusReceive: This activity subscribes to a Service Bus URI address. This causes all the messages sent to that topic to be forwarded to the activity.
- CloudXPathRead: This activity reads the result of executing an XPath expression on an XML string.
- CloudXPathUpdate: This activity updates an XML element's value in an XML string based on an XPath expression.
The reason there is a CloudDelay rather than using the WF Delay is that there are issues – to be corrected in WF 4.0 – in the scalability of the Delay activity and it is tied to the Timer service. This is in essence what we have to do for all the WF activities – make sure that when they run in the cloud they scale appropriately and work correctly in a multi-tenant environment.
The Xpath-based functions enable you to do message inspection and therefore content-based routing.
There is a CloudWorkflow project type added to Visual Studio when you install the .NET Services SDK. You use this to create a Cloud Sequential Workflow Root activity (in which all the other activities are contained) using the Visual Studio template. Workflows and rules are described in terms of XAML – not as a .NET type as is possible in WF – and it is this XAML that is deployed to Service Bus Workflow .
Deploying Workflows
There are three ways to deploy workflows:
- The Workflow Service portal
- Workflow client API installed with the .NET Services SDK
- Both of these use the SOAP API for the Workflow Service. The client API is a proxy for the web services.
- The third option is to use the Visual Studio one click (right) deploy (or deploy and run)
Scenarios
Let’s look at some scenarios to illustrate what we can do with the Workflow Service today.
Service Orchestration:
The first scenario is where we’re calling a collection of services, sending a message and getting results back. Currently, there are two activities you can use for this: CloudHttpSend and CloudServiceBusSend.
CloudHttpSend Activity
The CloudHttpSend activity sends an HTTP request and returns the response. It has 6 properties:
- Method: the HTTP method (GET or POST)
- Request: the request body content (ignored if the method is GET).
- RequestContentType: the request content type (ignored if the method is GET).
- URL: the URL for sending the HTTP request to.
- And when the activity completes the following properties are populated and you can bind the values to the next activity:
- StatusCode: the activity sets this value to the returned HTTP status code.
- Response: the activity sets this value to the returned HTTP content.
CloudServiceBusSend Activity
The CloudServiceBusSend activity sends a message to the Service Bus and returns a response if appropriate. It has 5 properties:
- Action: the Action SOAP header for the Service Bus message.
- Body: the XML content to include within the SOAP Body of the message.
- ConnectionMode: the connection mode to connect to the Service Bus. The connection mode can be either Multicast or Tcp.
- URL: the Service Bus URL to send the message to.
- Response: the activity sets this value to the returned SOAP response body, if any.
CloudServiceBusReceive Activity
The CloudServiceBusReceive activity subscribes to a Service Bus topic. Messages sent to that topic are forwarded to the activity.
- The message property contains the message received from the service bus.
- The queue name property contains the name of the queue to which the host will route messages
Message Content Inspection
The workflow service has a couple of activities that enable us to inspect the contents of a message and thus make decisions on how the workflow proceeds (content-based routing). For example, a workflow receives messages containing student test scores. We can search the message for a score and decide whether to pass or fail the student based upon that score. At that point we send a message to the Service Bus, using CloudServiceBusSend, saying whether student passed.
CloudHttpReceive Activity
For the workflow to receive a message we use the CloudHttpReceive activity. This activity receives an HTTP request at this unique URI and returns an HTTP status code and a response. The HTTP listener uses the Access Control Service and so the header of incoming messages needs to contain an Access Control Service authentication token.
The 3 properties on the activity are:
- Request: the content of the received HTTP request. This property is set by the activity when a request is received.
- StatusCode: the HTTP status code to return in response to the HTTP request.
- Response: the HTTP content to return in response to the HTTP request.
It is the Request property that contains the XML we need to parse to decide whether a student passes. We bind to this property using the standard activity binding in the next activity and process the contents…
The activity that parses the XML is the CloudXPathRead activity, which executes an Xpath expression on the incoming XML. Its properties are:
- InXml: the input XML to read a value from.
- InXPathExpression: the XPath expression to be used in querying the InXml property.
- OutReadValue: the result of executing the XPath expression. So we bind the request property of the CloudHttpReceive activity to the InXML property of the CloudXPathRead activity and then execute our Xpath expression against that, using the OutReadValue to determine whether the student passed.
Summary
Service Bus Workflow is a WF host that provides a simple, scalable cloud-based environment for running workflows. You use existing, familiar tools such as Visual Studio and the WF designer to create your workflows and then upload and manage those workflows using the Workflow Service portal or by using the underlying APIs.
References
Joel Reyes
