Download sample

This sample demonstrates two critical features within the workflow services:

• "Workflow first" method of authoring services
  
  You can author services using workflows in one of two ways. One is "contract first" authoring, where the contract already exists and the workflow implements the contract. The other is workflow first, which creates the contract as the workflow is authored. The workflow designer, in effect, acts like the contract designer. In this sample, the calculator contract is created as the workflow is authored.
  
  In this sample, the mark up for workflow first is implemented in the file SequentialCalculatorService.xoml. To understand the programming model behind workflow-first programming, compare this to the mark up for other workflow samples.
  
  The following sample code shows the mark up for the Receive activity in the sample.
  
  
  <ns0:ReceiveActivity x:Name="ReceiveAdd" OperationValidation="ValidateOwner" CanCreateInstance="True">
  <ns0:ReceiveActivity.ServiceOperationInfo>
          <ns0:OperationInfo PrincipalPermissionRole="Administrators" Name="Add" ContractName="ICalculator">
              <ns0:OperationInfo.Parameters>
                            <ns0:OperationParameterInfo Attributes="In" ParameterType="{x:Type p15:Int32}" Name="value" Position="0" 
                                     xmlns:p15="clr-namespace:System;Assembly=mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
                                     <ns0:OperationParameterInfo Attributes="Out" ParameterType="{x:Type p15:Int32}" Name="returnValue" Position="1" 
                                     xmlns:p15="clr-namespace:System;Assembly=mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
              </ns0:OperationInfo.Parameters>
          </ns0:OperationInfo>
  </ns0:ReceiveActivity.ServiceOperationInfo>
      <ns0:ReceiveActivity.ParameterBindings>
          <WorkflowParameterBinding ParameterName="value">
              <WorkflowParameterBinding.Value>
                  <ActivityBind Name="SequentialCalculatorService" Path="inputValue" />
              </WorkflowParameterBinding.Value>
          </WorkflowParameterBinding>
          <WorkflowParameterBinding ParameterName="returnValue">
              <WorkflowParameterBinding.Value>
                  <ActivityBind Name="SequentialCalculatorService" Path="currentValue" />
              </WorkflowParameterBinding.Value>
          </WorkflowParameterBinding>
      </ns0:ReceiveActivity.ParameterBindings>
      <CodeActivity x:Name="DoAdd" ExecuteCode="Add" />
  </ns0:ReceiveActivity>
  

  The Receive activity contains no reference to an external contract type and the contract is defined within the Receive activity itself. The OperationInfo block in the Receive activity describes both the contract name and the operation name. These are literal strings that contain no reference to a type that defines the contract.
  
  When you run the sample, the workflow service host uses this definition to create a service description. To create a service client for this, use the ServiceModel Metadata Utility Tool (Svcutil.exe).
  
  
• Security in workflow services
  
  Workflow services provides two levels of security for your service. In the first level you specify principle permission security on an operation. The service runtime checks the permission before delivering the message to the workflow. If the message does not meet the principle permission security, the message is not delivered to the workflow. The second level is the "operation validation condition," which you can assign to a Receive activity. The operation validation condition is executed when the Receive activity receives the message. If the message does not meet the operation validation condition, a fault is sent to the client, the message is deleted, and the workflow is faulted.
  
  The PrincipalPermissionRole attribute on the OperationInfo element specifies that only users in the Administrators group are allowed to call this operation.
  
  The OperationValidation attribute on the Receive activity points to the code handler to run as the validation condition. In this sample, only users in the Administrators group can invoke the first operation, because the PrincipalPermissionRole attribute is set on the first Receive activity. In this workflow, the ReceiveAdd Receive activity has the property CanCreateInstance set to true. This means that an instance of this service is created when the Add operation is called by a user in the Administrators group.
  
  In the subsequent Receive operations, the OperationValidation condition checks to ensure that the principal that invokes the operation is the same principal who created the instance. In this scenario, only the person who initiated the instance can send further messages. The following sample shows the code in the OperationValidation condition that performs this.
  
  
  private void ValidateOwner(object sender, OperationValidationEventArgs e)
  {
      if (string.IsNullOrEmpty(owner))
      {
          owner = ExtractCallerName(e.ClaimSets);
          e.IsValid = true;
          Console.WriteLine("Owner: " + owner);
      }
      if (owner.Equals(ExtractCallerName(e.ClaimSets)))
          e.IsValid = true;
  }
  private string ExtractCallerName(ReadOnlyCollection<ClaimSet> claimSets)
  {
      string owner = string.Empty;
      foreach (ClaimSet claims in claimSets)
      {
          foreach (Claim claim in claims)
          {
              if (claim.ClaimType.Equals(ClaimTypes.Name) && 
                   claim.Right.Equals(Rights.PossessProperty))
              {
                  owner = claim.Resource.ToString();
                  break;
              }
          }
      }
      return owner;
  }
  

  
  
  The ValidateOwner method shown provides claim sets as part of the OperationValidationEventArgs argument. Using these claim sets, it completes the message validation. Note that at this point, the actual message body parameters are not yet available. The ExtractCallerName method extracts the caller name from the Name claim and stores it. In subsequent requests, the caller name is checked against the Name claim of the incoming message to verify that the same person who sent the first message (and caused the instance creation) is the same person who sent the subsequent message.
  
  

Note:
This sample requires that .NET Framework version 3.5 is installed to build and run. Visual Studio 2008 is required to open the project and solution files.

To set up, build, and run the project

To run the sample on separate computers