A workflow service created with WF maintains state, gets input messages from and sends output messages to the outside world, and executes code that performs the service's work. This is the same as an ordinary stateful service, which preserves a shared state between different operations during its lifetime.

Figure 6-1 shows the anatomy of a simple workflow service. Every workflow service has an outermost activity, the workflow itself, which contains all other activities. This outer activity can take different shapes, and basically determines the way the execution flow goes through different inner activities. WF 4.0 ships with two built-in activities for modeling workflows: a sequence activity that flows from one activity to the next until the last activity is executed, and a flowchart activity that resembles the concepts that many analysts and application designers go through when creating solutions or designing business processes.

Figure 6.1. Anatomy of a workflow service

In this example, the workflow execution begins with a Receive Activity that receives an input message from the external world using a WCF endpoint. This is followed by a branch activity that evaluates a condition before executing one of the activities (named A1 and A2 in Figure 6-1) defined on each branch. The branch activity is followed by the execution of another custom activity (A3), and a message is finally sent to the world beyond this service by the Send Message Activity (which might represent a call to another service). Another Receive Message Activity appears which gets more input, and is followed by a final Send Message Activity that sends out the final service result.

As you can see, every activity in this example represents a piece of a typical service, with the main difference being that many of the built-in language elements found in a traditional program have been replaced by activity classes provided by the WF activity library.

You should also understand that the WF runtime does not know anything about the internal implementation of the activities it is executing, or the way it behaves.

It can only run one activity after another, until the last activity is reached. It can also persist the workflow state at certain points.

Now, you might wonder why you should go with a workflow service when the same service can be implemented manually with code? The answer is, to address some of the benefits that WF can give in this area:

One of the main problems of implementing workflow services in the .NET Framework 3.5 is that the integration between these technologies leaves something to be desired. You basically have to define all the WCF artifacts using the WCF programming and configuration model, and the workflow using a different model, resulting in a set of multiple artifacts that need to be deployed and managed separately.

However, with the .NET Framework 4.0, you can define all the WCF artifacts, such as contracts and operations, using XAML (eXtensible Application Markup Language) together with the workflow definition in the same language, resulting in a single artifact — a XAML-based service.

In other words, you essentially create a model of the service defining what the service should do, rather than writing code to specify how to do it — the traditional way to do things in .NET.

Listing 6-1 shows the XAML representation of a workflow service with a simple operation, GetData, that receives an input argument in the variable "data," and returns a string (data.ToString()). As you can see, all the activities have been represented as objects with properties using the XAML notation.

<WorkflowService ConfigurationName="Service1" Name="Service1" ....>

  <p:Sequence DisplayName="Sequential Service">
    <p:Sequence.Variables>
      <p:Variable x:TypeArguments="CorrelationHandle" Name="handle" />
      <p:Variable x:TypeArguments="x:Int32" Name="data" />
    </p:Sequence.Variables>

    <Receive x:Name="__ReferenceID0" DisplayName="ReceiveRequest"
      OperationName="GetData" ServiceContractName="contract:IService" >
      <Receive.CorrelationInitializers>
        <RequestReplyCorrelationInitializer CorrelationHandle="[handle]" />
      </Receive.CorrelationInitializers>
      <ReceiveMessageContent>
        <p:OutArgument x:TypeArguments="x:Int32">[data]</p:OutArgument>
      </ReceiveMessageContent>
    </Receive>

    <SendReply Request="{x:Reference Name=__ReferenceID0}"
      DisplayName="SendResponse" >
      <SendMessageContent>
        <p:InArgument x:TypeArguments="x:String">[data.ToString()]</p:InArgument>
      </SendMessageContent>
    </SendReply>

  </p:Sequence>

</WorkflowService>

In addition, the contract and operations for this service are automatically inferred from the Receive Activity definition.

A great advantage of having a fully declarative service is that you can store the complete definition in a service repository and take full control of the workflow's instances from a hosting environment such as Windows AppFabric.

private static WorkflowServiceImplementation CreateWorkflow()
{
    var result = new Sequence();
    var receivedInput = new Variable<string>();
    result.Variables.Add(receivedInput);

    var handle = new Variable<CorrelationHandle>();
    result.Variables.Add(handle);

    var receive = new Receive()
    {
      OperationName = "HelloWorld",
      ServiceContractName = "HelloWorldService",
      Content =
        ReceiveContent.Create(new OutArgument<string>
        (receivedInput)),
      CorrelatesWith = new InArgument<CorrelationHandle>(handle),
      CanCreateInstance = true
    };

    result.Activities.Add(receive);

    var write = new WriteLine()
    {
      Text = new InArgument<string>(env =>
        string.Format("Hello World!!! '{0}'.",

receivedInput.Get(env)))
    };
    result.Activities.Add(write);

    var reply = new SendReply()
    {
      Request = receive,
      Content = SendContent.Create(new InArgument<string>(env =>
        string.Format("Hello World!!! '{0}'.",
        receivedInput.Get(env))))
    };
    result.Activities.Add(reply);
    var service = new WorkflowServiceImplementation
    {
      Name = "HelloWorldService",
      Body = result
    };
  return service;
}

The .NET Framework 3.5 introduced two new activities, Send and Receive, to simplify the integration between WCF and WF. Using these activities, you can essentially enable WCF endpoints on your WF workflows to make it accessible from the external world. On the other hand, you can employ WF as the implementation technology for your WCF services. A workflow that uses these activities is usually known as a workflow service and that terminology is used throughout this chapter.

WF in the .NET Framework 4.0 still ships with these activities for sending and receiving one-way messages through WCF, but it also includes two new activities, SendAndReceiveReply and ReceiveAndSendReply, that represent a higher-level abstraction for request/response operations.

Next, we discuss these four activities in detail and how they can be used.

Receive Activity

The Receive Activity defines an entry point in a workflow that starts receiving messages from the outside world. This entry point takes the form of a WCF endpoint associated to a specific contract and operation. This activity has been improved in the .NET Framework 4.0 with the introduction of significant changes to simplify the service contract and operation definition, as well as other related aspects, such as message correlation.

Some of the properties that you will find in this activity are discussed in Table 6-1.

Table 6.1. Receive Activity Properties

PROPERTY	DESCRIPTION
DisplayName	The friendly name that identifies the activity within the workflow. This name is used to reference the activity from other activities, or relate this activity to a SendActivity, which sends the result of the operation execution to the outside world.
ServiceContractName	The name of the WCF contract that is associated with the activity. The name chosen for this contract matters because it represents the service contract that the clients will use to consume the service.
OperationName	The name of the WCF operation that is associated with the activity. This operation is added to the contract specified in the ServiceContractName property. The name of the operation is as important as the name of the contract for the same reasons previously discussed — it is one of the visible parts of the service.
Content	The input parameters or arguments that the operation expects to receive. This content is usually mapped to a workflow variable, so it can be used by other activities.
Action	The SOAP Action that will be used to route the messages to the WCF operation. This value is usually sent by the client in the To address header.
CanCreateInstance	This property specifies whether the activity can create a new instance of the workflow when a new message is received through the associated WCF endpoint. Every workflow service definition must have one Receive Activity that can create instances (CanCreateInstance = true), and that activity must be the first activity in the workflow.
KnownTypes	A collection of .NET types representing existing data contracts or primitive types that needs to be associated to the operation definition as known types. A known type is a type that should be included for consideration during the serialization/deserialization process of the send/received messages.
ProtectionLevel	The protection level requirement applied to the operation definition. As discussed in the security chapter, the only possible values for this property are None, Sign, and SignAndEncrypt.
SerializerOption	The message serializer associated to the operation. The possible values for this property are DataContractSerializer and XmlSerializer. These serialization engines were discussed earlier in this chapter.
CorrelatesOn/CorrelatesWith and CorrelationInitializers	These are properties for resolving and associating a correlation handler for the operation. Message correlation is discussed later in this chapter.

A single Receive Activity in a workflow service represents a one-way operation in the service contract unless you define a new SendReply Activity. It is tied to the Receive Activity to send a reply message with the results of the operation execution.

A SendReply Activity is not an activity that you can simply drag and drop from the toolbox to the workflow instance in the designer. It can only be created from an existing Receive Activity by selecting the option Create SendReply in the Receive Activity's context menu.

Figure 6-2 shows a SendReply Activity in action. It has been associated with a Receive Activity ApplyForJobReceive that represents an operation ApplyForJob and assigns the request message payload to the JobApp input variable. As you can see in the figure, the SendReplyToReceive Activity has been tied to the Receive Activity through the Request property, and the response message payload is a simple string value. In a real service implementation, you are also free to associate a variable to the Content property with a value computed during the workflow execution.

The equivalent WCF contract for the Receive Activity in Figure 6-2 should be the following:

Figure 6.2. SendReply Activity in action

[ServiceContract]
public interface IHRService
{
  [OperationContract]
  string ApplyForJob(JobApp application);
}

The content property also supports multiple parameters in case you do not want to assign the received message into a single variable. This is something that can be selected in the Content property window when using the workflow designer. Figure 6-3 illustrates a Receive operation with the input mapped to multiple arguments.

Figure 6.3. Receive operation with multiple arguments

Note

In case you are not familiar with the workflow model in WF 4.0, a variable represents a new way to pass values around in the workflow instance. As with any programming language, a variable is also associated to a scope, which basically determines where the variable can be read from and/or written to during its lifetime, or how long it stays in memory. Therefore, the sum of all variables in scope in a specific point of time determines the whole workflow state at that moment. This is a significant improvement in the way the workflows are persisted and loaded into memory from the persistence provider. The WF runtime engine can now perform some optimizations and only the variables in scope need to be considered for that purpose. In the past, the only way to share state between activities within a workflow was to define global variables with dependency properties in the workflow itself.

Send Activity

The Send Activity represents the flip side of the Receive Activity. The Receive Activity defines a WCF entry point for receiving messages, and the Send Activity allows workflows to send messages to the outside world to execute external WCF services, or send response messages with results of an operation execution to a service consumer when it is tied to a ReceiveReply Activity.

In the same way a single Receive Activity represents a one-way operation in the service contract by default, the Send Activity does not expect a response message unless it is associated with a ReceiveReply Activity.

The ReceiveReply Activity is another activity that cannot be directly referenced in an activity toolbox and must be created from an existing Send Activity. You do so by selecting the option Create ReceiveReply in the Send Activity's context menu.

Figure 6-4 shows a ReceiveReply Activity in action. It has been associated with the Send Activity Send that represents an operation SubmitOrder and that gets the request message payload from the Order variable. As you can see in the figure, the ReceiveReplyForSend Activity has been tied to the Send Activity through the Request property, and the response message payload is returned in the Result variable.

Figure 6.4. ReceiveReply Activity in action

Some of the properties that you find in the Send Activity are discussed in Table 6-2.

Table 6.2. Send Activity Properties

PROPERTY	DESCRIPTION
Endpoint	The definition of the endpoint that will be used to consume the service. This property is made of two parts, the endpoint address and the WCF binding. The endpoint address is a URI representing the address where the service is listening. The WCF binding is one of the built-in bindings used to set up the channel communication.
EndpointConfigurationName	The friendly name of an endpoint in the WCF configuration section. This property provides the flexibility of specifying all the endpoint settings such as address, binding, and behaviors in the file configuration section. You can either set the Endpoint or EndpointConfigurationName properties but not both.
EndpointAddress	A service endpoint address that overrides the address already defined in the Endpoint property or the WCF configuration section — if the EndpointConfigurationName property is used.
DisplayName	The friendly name that identifies the activity within the workflow. This name is also used to reference the activity from other activities, or relate this activity to a ReceiveReply to receive a service response.
ServiceContractName	The name of the WCF contract that is associated with the activity. The name chosen for this contract matters because it represents the service contract that the WF will use to consume the service. The contract name is made up of two parts, a namespace and the contract name, per se (e.g., http://wcfbook/}myServiceContract).
OperationName	The name of the WCF operation that is associated with the activity. The name of the operation is as important as the name of the contract for the same reasons discussed earlier — it is used to consume the service.
Content	A workflow variable that is mapped to the request message for executing the service's operation.
Action	The SOAP Action that is included in the To address header of the request message for executing the service's operation.
KnownTypes	A collection of .NET types representing existing data contracts or primitive types that needs to be associated with the operation definition as known types. A known type is a type that should be included for consideration during the serialization/deserialization process of the send/received messages.
ProtectionLevel	The protection level requirement that is applied to the operation definition. As was discussed in the security chapter, the only possible values for this property are None, Sign, and SignAndEncrypt.
SerializerOption	The message serializer associated with the operation. The possible values for this property are DataContractSerializer and XmlSerializer. Serialization engines were discussed earlier in this chapter.
CorrelatesWith and CorrelationInitializers	Properties for resolving and associating a correlation handler for the operation. Message correlation is discussed in detail later in this chapter.

The Assign Activity is useful for initializing a variable associated to the Content property of the Send Activity.

The Assign Activity is a new activity introduced in WF 4.0 to assign or initialize the value of a workflow variable. It is made up of two parts — a variable definition, which is assigned to the To property, and an expression to initialize that variable in the Value property.

The expressions for initializing the variable can be simple, such as a scalar value, or something more complex that involves functions or other variables already defined in the workflow. The complex expressions must be defined using VB, so you need to be familiar with that language to create them correctly.

For the example shown in Figure 6-4, the Send Activity uses an Order variable to execute the SubmitOrder operation. As that variable needs to be initialized before executing the operation, the Assign Activity can be used.

The following expression can be assigned to the Order variable:

Order  = New Order()
With {.ProductName = "foo", .Quantity = 10}

As you can see, the VB object initializer syntax has been used to create a new instance of the Order class, which represents a data contract in this example.

Note

Is C# supported for creating expressions? The answer is no, and the main reason is timing. The VB team provides an in-memory parser for creating expressions within the WF 4.0 RTM timeframe.

One of the limitations that you will find in the current version is a lack of support for specifying security client credentials through the Send Activity when the target service needs to authenticate the calling application/user. For most scenarios, you can do this through the WCF configuration section using bindings and behaviors. Windows, Certificates, and Issued token credentials can be configured that way, but unfortunately, username token credentials cannot. If that is the case, you will not able to consume the external service unless you create a custom extension or behavior to specify those credentials at runtime.

The Easy Way to Execute External Services

Another interesting feature in WF 4.0 that simplifies the development of workflow services significantly is the automatic generation of typed activities for consuming existing service references in the project. Whenever you add a new service reference in the workflow project, a set of new activities for consuming the service (one per operation) are automatically added to the Visual Studio toolbox. You can simply drag and drop one of those activities within a workflow and fill out all the required properties, such as input/output arguments, to execute service without worrying about the other details already discussed in the Send Activity. The benefits that you get for free by using this generated activity are evident:

• Typed properties for the input, and output parameters that the service operation associated to the activity is expecting and returning.

• All the details about the contracts exposed by the service are automatically inferred and included in the generated activities.

As recommended, you should always consider this alternative the easiest way to consume external services unless you need more granular control over the details of the WCF client contract or the endpoint settings.

The WCF contract and the XAML representation of activity generated for consuming the Notify operation in the contract are shown next:

[ServiceContract]
public interface IProductNotification
{

[OperationContract]
  bool Notify(string product, int quantity);
}

<psa:Notify NotifyResult="[NotifyResult]" product="[PurchaseOrder.Product]"
quantity="[PurchaseOrder.Quantity]" />

You have seen some introductory theories behind workflow services and the messaging activities that can be used in this kind of service to receive messages or invoke external services. It is now time to jump into a more concrete example to see a workflow service in action.

This example represents the implementation of a service for entering purchase orders into a system. For practical purposes, this service will also invoke an external service for every received order.

Let's start creating a C# class library for including the definition of the contract and implementation of the external service invoked within the workflow service. The implementation is simple enough: it receives the product that was ordered, the quantity associated to the order, and returns a Boolean value specifying the success of the operation. See Listing 6-2.

[ServiceContract]
public interface IProductNotification
{
  [OperationContract]
  bool Notify(string product, int quantity);
}

public class ProductNotification : IProductNotification
{
  public bool Notify(string product, int quantity)
  {
    return true;
  }
}

Now that you have the external service implementation, you can focus on the implementation of the first workflow service.

Visual Studio 2010 provides a template WCF Workflow Service Application under the Workflow category, which you can use to create workflow services from scratch. When that template is selected and executed, a new web project is generated with a sample workflow service definition that includes a pair of Receive/Send Activities. Start the implementation of your workflow service by removing those activities.

This service will initially receive a purchase order as it is defined in the PurchaseOrder data contract (see Listing 6-3) through a new Receive Activity that you need to create in the workflow. This activity basically represents the initial entry point for the service.

[DataContract]
public class PurchaseOrder
{
  [DataMember]
  public string Customer { get; set; }

  [DataMember]
  public string Product { get; set; }

  [DataMember]
  public int Quantity { get; set; }

  [DataMember]
  public decimal UnitPrice { get; set; }
}

You should set the Receive Activity properties with the values specified in Table 6-3.

Leave the rest of the properties with the default values. The designer will complain that the PurchaseOrder variable is not defined, and that is exactly what you do next.

The variables can be defined for a workflow instance in the Variables tab, which usually appears at the bottom margin of the designer. A variable definition is made of three parts: a name, a type, and a scope. The variables, as in any language, are referenced by name, and the type is any valid CLR type shipped as part of the framework or a type created for you. In this case, you define a variable called PurchaseOrder whose type is PurchaseOrder (a data contract defined in another project) and is scoped to the current workflow service (Sequential workflow service). As you can see, you have a single data contract parameter to receive all the information, so Message Data is just fine for that purpose. In case you want to support multiple arguments in the operation signature, you need to use parameters and assign them to the corresponding variables or use VB expressions to do more complex assignments.

The workflow is now ready to start receiving messages containing the purchase order information through the operation SubmitPO. As you haven't defined a SendReply Activity, this operation momentarily behaves as one-way.

The next step is to invoke the ProductNotification service for every receive order. The easy way to include that service call in the existing workflow is to use the automatic generated activity. The only thing to do is add a service reference for ProductNotification as illustrated in Figure 6-5.

Figure 6.5. Service Reference added

When the reference is added to the project, you should be able to see a new activity called Notify with a public interface that resembles the Notify operation in the IProductNotify contract. It has two public properties for setting the product and quantity respectively, and a third property for getting access to the operation return value.

You can drag and drop that activity after the Receive Activity and fill out the properties with the values in Table 6-4.

NotifyResult is a new Boolean variable that needs to be defined to receive the result of the operation. The Product and Quantity input arguments are initialized from the existing variable PurchaseOrder by using expressions.

Last but not least, you need to create a new SendReply Activity from the SubmitPOReceive Receive Activity to send the results back to the client. The only thing needed is to set up this activity in the Content property to use Message data and True as value, so it will basically return a value indicating the operation was executed successfully.

At this point, the workflow service is ready to use, and any client can access the service WSDL by browsing the POService.xamlx file directly in the corresponding web host (IIS virtual directory or Visual Studio web server). This means that the service behaves as any other WCF service from the point of view of a client application, and a tool such as svcutil can be used to generate the proxy classes to consume it. (See Listing 6-4.)

PurchaseOrderClient client = new PurchaseOrderClient();
bool? result = client.SubmitPO(new ServiceReference.PurchaseOrder
{
  Customer = "John BarFoo",
  Product = "myproduct",
  Quantity = 10,
  UnitPrice = 1
});

Console.WriteLine(result.GetValueOrDefault());

As with any traditional WCF service, you can separate the configuration of a workflow service from the service implementation by defining it either in an app.config for self-hosted services or a web.config for IIS-hosted services. The connection between the workflow service implementation and the corresponding service configuration in the configuration file is specified in the ConfigurationName attribute — which maps to the config's service element's name attribute. With this link in place, a workflow service is configured in exactly the same fashion as a traditional WCF service using the service model configuration section. The following text shows how the ConfigurationName "MyService" is mapped to the corresponding service configuration section:

<WorkflowService mc:Ignorable="sap" ConfigurationName="MyService"
Name="MyService"..>
</WorkflowService>

<system.serviceModel>
    <services>
      <service name="MyService" behaviorConfiguration="myService" >
        <endpoint binding="basicHttpBinding"
                  bindingConfiguration="myService"
                  contract="IService"></endpoint>
      </service>
    </services>
    <bindings>

<basicHttpBinding>
        <binding name="myService">
          <security mode="None"></security>
        </binding>
      </basicHttpBinding>
    </bindings>
    <behaviors>
      <serviceBehaviors>
        <behavior name="myService">
          <serviceMetadata httpGetEnabled="true"/>
        </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>

The contract name that you need to configure for the service endpoint must match one of the contract names specified in the workflow Receive Activities. For this example, one of the Receive Activities in the workflow has the value {[namespace]}IService for the ServiceContractName property.

You can still use the new configuration improvements in a workflow service. In fact, the Visual Studio template for workflow services automatically includes a configuration file that only overrides a few default WCF configuration settings to enable the service metadata endpoint and disable the includeExceptionDetailsInFault setting:

<system.serviceModel>
    <behaviors>
      <serviceBehaviors>
        <behavior>
          <!-- To avoid disclosing metadata information,
set the value below to false and remove the metadata endpoint
above before deployment -->
          <serviceMetadata httpGetEnabled="true"/>
          <!-- To receive exception details in faults for debugging purposes,
set the value below to true.  Set to false before deployment to avoid
disclosing exception information -->
          <serviceDebug includeExceptionDetailInFaults="false"/>
        </behavior>
      </serviceBehaviors>
    </behaviors>
</system.serviceModel>

<workflowIdle timeToPersist="00:00:10" timeToUnload="00:01:00"/>

<behaviors>
  <serviceBehaviors>
    <behavior name="ServiceBehavior">
      <sqlWorkflowInstanceStore
        connectionString="Data Source=.SQLExpress;Initial
        Catalog=WorkflowInstanceStore;Integrated Security=True">
        </sqlWorkflowInstanceStore>
      </behavior>
   </serviceBehaviors>
</behaviors>

<behaviors>
  <serviceBehaviors>
     <behavior name="ServiceBehavior">
        <workflowRuntime name="WorkflowServiceHostRuntime"
                       validateOnCreate="true"
                       enablePerformanceCounters="true">
           <services>
           </services>
        </workflowRuntime>
     </behavior>
  </serviceBehaviors>
</behaviors>

As discussed earlier in this chapter, long-running processes represent a common scenario for workflow services. In this kind of process, an execution is usually made up of multiple execution sequences which may last many days or even weeks. They might involve clients that connect to the service, perform work, transition the workflow to a new state, and then disconnect for an indeterminate amount of time before connecting again for workflow execution. This kind of execution generates questions that need to be addressed when a message leaves a workflow instance, and then another message returns later in the same flow. How does that message know which returning workflow instance to come back to? What if there are thousands of these workflow instances running at a single point in time? For this, WF has correlation, which means that you can specify a set of attributes for a given message that the runtime will use to route the message to the appropriate running workflow instance.

A correlation attribute in this context might be as simple as a unique identifier. It might be more complex, such as a composite key made up of business concepts — a customer identifier or a purchase order number.

The correlation story in WF 3.5 was solved by involving the client applications. Basically, when the first operation that created your workflow instance succeeded, a header or a cookie was attached to the outgoing message containing a workflow instance identifier (consider this the workflow instance primary key). It was the client's responsibility to keep this identifier around and attach it to the messages for executing successive operations in the same workflow instance. As you can see, this got a bit tricky, as the client needed to know some of the implementation details of the services. If the client did not know that an identifier must be obtained from the reply message and used again for the next call, nothing worked.

This is not a big deal if you were developing both the client and the service, but if the client was developed by a third party, it certainly becomes more complex.

Ideally you want the message in the second service operation to have a key value with which you can get the workflow instance back (a correlation attribute). Fortunately, the WF team has included a way to route messages to a workflow instance in a feature called content-based correlation.

In this section, the correlation techniques are addressed — the old technique based on the use of a unique identifier or context-based correlation, and the new one based on the use of keys in the message content itself.

[DataContract]
public class PurchaseOrder
{
  [DataMember]
  public string Customer { get; set; }

  [DataMember]
  public string Product { get; set; }

  [DataMember]
  public int Quantity { get; set; }

  [DataMember]
  public decimal UnitPrice { get; set; }
}

<services>
  <service name="Service">
    <endpoint binding="basicHttpContextBinding"
       bindingConfiguration="myService"
       contract="IService"></endpoint>
  </service>
</services>
<bindings>
  <basicHttpContextBinding>
    <binding name="myService" contextManagementEnabled="true"></binding>
  </basicHttpContextBinding>
</bindings>

static void Main(string[] args)
{
  string instanceId;

  string poNumber = SubmitPO(out instanceId);

  Console.WriteLine("The PO Number is {0}", poNumber);

string message = ConfirmPO(instanceId);

  Console.WriteLine(message);
}

private static string SubmitPO(out string instanceId)
{
  PurchaseOrder po = new PurchaseOrder
  {
    Customer = "Foo Bar",
    Product = "Product",
    Quantity = 10,
    UnitPrice = 5
  };

  ServiceClient client = new ServiceClient();

  string poNumber = client.SubmitPO(po);

  IContextManager contextManager =
    client.InnerChannel.GetProperty<IContextManager>();
  IDictionary<string, string> context = contextManager.GetContext();

  instanceId = context["instanceId"];

  return poNumber;
}

private static string ConfirmPO(string instanceId)
{
  ServiceClient client = new ServiceClient();

  Dictionary<string, string> context = new Dictionary<string, string>();

  context.Add("instanceId", instanceId);

  IContextManager contextManager =
    client.InnerChannel.GetProperty<IContextManager>();

  contextManager.SetContext(context);

  return client.ConfirmPO();
}

<client>
  <endpoint address="http://localhost:1219/Service.xamlx"
    binding="basicHttpContextBinding"
    bindingConfiguration="myService" contract="ServiceReference.IService"
    name="BasicHttpContextBinding_IService" />
 </client>
 <bindings>
   <basicHttpContextBinding>
     <binding name="myService" contextManagementEnabled="true" />
   </basicHttpContextBinding>
 </bindings>

[DataContract]
public class PurchaseOrder
{
  [DataMember]
  public string Customer { get; set; }

  [DataMember]
  public string Product { get; set; }

  [DataMember]
  public int Quantity { get; set; }

  [DataMember]
  public decimal UnitPrice { get; set; }
}

static void Main(string[] args)
{
  string purchaseOrderId = SubmitPO();

  Console.WriteLine("The PO Number {0} was submitted", purchaseOrderId);

  string message = ConfirmPO(purchaseOrderId);

  Console.WriteLine(message);

}

private static string SubmitPO()
{
  PurchaseOrder po = new PurchaseOrder
  {
    Customer = "Foo Bar",
    Product = "Product",
    Quantity = 10,
    UnitPrice = 5
  };

  ServiceClient client = new ServiceClient();

  SubmitPOResponse response = client.SubmitPO(po);

  return response.PurchaseOrderId;
}

private static string ConfirmPO(string purchaseOrderId)
{
  ServiceClient client = new ServiceClient();

  return client.ConfirmPO(new ConfirmPO { PurchaseOrderId = purchaseOrderId });
}

The hosting experience for workflow services has also been improved in WF 4.0 with the addition of a native ability to host, support, and maintain .xamlx files (the extension used by workflow services, which is equivalent to .svc for regular services) in IIS and the application server extensions known as Windows AppFabric.

A .xamlx file basically contains all the workflow implementation and configuration in terms of XAML. The experience of hosting a .xamlx is nearly identical to hosting a .svc, as the virtual directory only needs to contain this file, the service configuration in the web.config file, and a bin directory with all the assemblies that the service depends on.

As happens with any application that uses the ServiceHost class for hosting regular WCFs services in a standalone process outside of IIS, there is an equivalent class for doing the same with workflow services — the WorkflowServiceHost class. This class derives from the System.ServiceModel.ServiceHostBase and is responsible for extending the WCF runtime model with all the extensions that the workflow services depend on.

The WorkflowServiceHost provides three overloaded constructors for providing the definition of the workflow service that is hosted:

public WorkflowServiceHost(WorkflowService serviceDefinition,
params Uri[] baseAddresses);

public WorkflowServiceHost(Activity activity, params Uri[] baseAddresses);

public WorkflowServiceHost(object serviceObject, params Uri[] baseAddresses);

The first constructor receives an instance of a System.ServiceModel.Activities.WorkflowService class, which represents the workflow definition itself. Using this new class, you can create, configure, and gain access to all the properties of a workflow service. The other two constructors create and initialize a new WorkflowService instance using either a System.Activities.Activity (which represents the root activity in the service), or an object (which can be either a WorkflowService or Activity instance).

After you have the workflow definition, you can configure the WCF runtime just as you would with any other service using either code or configuration. This allows you to add endpoints or behaviors to the runtime or modify the service description. For example, for adding new service endpoints, you can use either the WorkflowService.Endpoints collection as it is shown in the following code or the AddServiceEndpoint method directly on the WorkflowServiceHost instance — the traditional way to do it with regular WCF services:

var service = new WorkflowService();
service.Name = "HelloWorldService";
service.Body = CreateWorkflow();

var endpoint = new Endpoint
{
  AddressUri = new Uri("HelloWorld", UriKind.Relative),
  Binding = new BasicHttpBinding(),
  Name = "HelloWorldService",
  ServiceContractName = "HelloWorldService",
};

service.Endpoints.Add(endpoint);

The WorkflowServiceHost class also provides a property DurableInstancingOptions for configuring the persistence provider that is used by the workflow runtime. Using this property you can change the default InstanceStore by the one that persists the workflow instances in a SQL server database (SqlWorkflowInstanceStore). This can be accomplished with a few lines of code as is shown here:

var host = new WorkflowServiceHost(workflow, baseAddress);
 var connStr =
@"Data Source=.;Initial Catalog=WorkflowInstanceStore;Integrated Security=True";
var instanceStore = new SqlWorkflowInstanceStore(connStr);
host.DurableInstancingOptions.InstanceStore = instanceStore;