Windows Workflow Foundation (WF, or Workflow) is Microsoft’s technology platform for building workflow-enabled applications. The platform includes a set of tools for designing and managing workflows, a programming model for implementing workflow logic, a rules engine, and a workflow runtime execution engine. Workflow technology can be employed in a wide range of application scenarios, the most common of which are listed in Table 1.

>Table1: Common production application scenarios for Workflow.

This whitepaper summarizes the value proposition for scenarios that involve Workflow Services.

>Workflow Services

Within a service-oriented system, there are usually many business services that encapsulate a specific set of functionality, making that functionality available either behind the firewall or on the Internet. This is excellent for reuse, maintenance, isolation, fault tolerance, distribution, and scalability. Windows Communication Foundation (WCF) makes it easy to wrap business functionality behind a service boundary but does not make any assumptions about the order in which service operations will be called; coordination is up to the application. Workflow is a useful technology for the middle tier to coordinate complex business processes and automate the flow of messaging between users, applications and services. This includes enforcing the order in which service operations are called as they participate in a business process.

Visual Studio 2008 and .NET Framework 3.5 introduced new features to improve integration between Workflow and WCF—under the heading Workflow Services—to simplify the following scenarios:

• Exposing workflows as services to client applications. Calls to the Workflow Service automatically engage the Workflow Runtime for new or existing workflow instances.
• Coordinating calls across multiple services to complete a business process. Workflows can call out to WCF services with little to no coding effort.

The following sections will discuss these scenarios and the features that support them.

>>>>>Workflow Service Templates and Tools

The following templates and tools, new to Visual Studio 2008 and .NET Framework 3.5, support Workflow Services to enhance developer productivity:

• Visual Studio 2008 includes new Workflow project templates that create Workflow Services.
• ReceiveActivity simplifies exposing a workflow as a WCF service.
• SendActivity simplifies calling WCF services from a workflow.
• WorkflowServiceHost supports ReceiveActivity and SendActivity by facilitating communications between WCF and Workflow.

The following sections summarize these features.

>Visual Studio Features

Visual Studio 2008 includes two new templates for creating Workflow Service projects: Sequential Workflow Service Library and State Machine Workflow Service Library (templates shown in Figure 1).

These templates simplify the developer experience as follows:

• They each create a new project with a sample workflow design configured as a Workflow Service.
• A sample WCF service contract is provided for the Workflow Service.
• The workflow design includes a ReceiveActivity, which is mapped to the service operation in the sample contract.
• The project configuration file includes required WCF configuration settings to host the Workflow Service so that it can be reached by client applications. >
• The project is configured to use the new WCF test host and test client so that developers can immediately host and test the Workflow Service from within Visual Studio 2008.

Figure 1: Visual Studio templates for Workflow Services.

Essentially, these project templates give developers a working example of a Workflow Service that they can immediately test and then modify according to their own application requirements.

Workflow Services rely on two new Workflow activities, ReceiveActivity and SendActivity, to streamline how workflows communicate with WCF. These activities appear in the Windows Workflow v3.5 group in the Visual Studio 2008 Toolbox (see Figure 2). These activities remove the cumbersome steps previously required to call workflows from WCF services, and to call WCF services from within a workflow.

>Figure 2: SendActivity and ReceiveActivity.

>ReceiveActivity

The purpose of the ReceiveActivity is to expose service operations from a workflow, enabling client applications to initialize a workflow or otherwise interact with it by making calls to a WCF service. The activity is mapped to a specific operation from a WCF service contract. Clients call the service using a WCF proxy based on the same service contract used by the ReceiveActivity. Figure 3 illustrates how a specific operation, called through a proxy, initializes a workflow through its ReceiveActivity. In this example, the operation name is ReceiveOperation().

>Figure 3: WCF client calling a Workflow Service operation.

ReceiveActivity is essentially an implementation of a service operation. Activities placed inside the ReceiveActivity are executed synchronously and may contribute to building a response for the client, assuming the operation is not one-way. To avoid time-outs, the collective time required to execute the ReceiveActivity must be limited in duration. Activities that follow the ReceiveActivity are executed asynchronously, and thus can be long-running.

ReceiveActivity is an event-driven activity that, when encountered, puts the workflow into an idle state to await input. Multiple ReceiveActivity instances are supported in a single workflow, the first one likely to support workflow initialization, while others require that the workflow already be initialized before they can receive calls. Each ReceiveActivity can be associated with its own unique service contract and service operation, but it is natural to think of a single service contract for a Workflow Service, where each ReceiveActivity represents a different operation on that contract. In fact, using tools provided by the Workflow Designer developers can design the associated WCF service contract while designing the workflow.

>SendActivity

The SendActivity is used to call an operation exposed by a WCF service from an executing workflow instance. The call is made synchronously, but if the operation is one-way it will return immediately and advance the workflow to the next activity. The Workflow Service generates a proxy for the call according to properties of the SendActivity, including the selected service contract and associated WCF configuration settings. The response from a SendActivity can be stored and used by the running workflow instance, including reported exceptions. Figure 4 illustrates how two SendActivity instances are configured to call two service operations exposed by the same service contract and service.

>Figure 4: A Workflow Service calling two different WCF service operations

>WorkflowServiceHost

An important supporting feature of Workflow Services is the WorkflowServiceHost. This is an extension to the default ServiceHost responsible for initializing WCF communication channels. It facilitates communications between WCF and Workflow as follows:

• When a request is received to a service operation mapped to a ReceiveActivity, the WorkflowServiceHost ensures the Workflow Runtime is initialized, initializes a new workflow instance if necessary, and handles activating the workflow at the ReceiveActivity.
• When a SendActivity is encountered, it constructs a communication channel (or proxy) to call the associated service operation according to properties of the activity.

The developer experience for hosting a Workflow Service is similar to that of any WCF service. When a WorkflowService is hosted in a Windows Forms client, a WPF client, a Windows Service, or any other self-hosted environment, developers are responsible for initializing the WorkflowServiceHost. For IIS or WAS hosting environments, developers associate the appropriate factory class, in this case the WorkflowServiceHostFactory, with the .svc file that receives requests to the service. Figure 5 illustrates the two scenarios.

>Figure 5: WorkflowServiceHost and WorkflowServiceHostFactory architecture.

>>Exposing Workflow as a Service

WCF makes it easy to expose business functionality through services, whether they are for remote clients to consume over the Internet, or for applications behind the firewall. When a service operation encapsulates a complex business process, it is natural to express that as a workflow. In this case, Workflow Services can be useful to initialize that workflow, directly, when the service operation is invoked. This implementation has the following benefits:

• It significantly reduces the steps required to initialize a workflow from a WCF service operation.
• It streamlines communications between WCF and workflow instances.
• It provides a simple way to design a WCF service contract for a workflow directly from the Workflow Designer.

This section will explain the implementation characteristics of a Workflow Service.

>Workflow Design

Figure 6 illustrates the functionality provided by a WCF service to upload data and ultimately generate and distribute a document from the information provided.

>Figure 6: Document generation process implemented by a WCF service operation.

The WCF service, DataUploadService, exposes an operation called UploadData(). This operation executes the following steps:

• Calls the SaveData() method exposed by the DocumentManager assembly. This saves the data to the database and records the status of the document generation process as “In Process.”
• Calls the GenerateDocument() method exposed by the DocumentGeneration assembly. This generates a document from the data and saves it to the file system.
• Calls the Send() method exposed by the EmailUtility assembly. This e-mails the document to the intended party.
• Call the UpdateStatus() method exposed by the DocumentManager assembly. This updates the status of the document generation process to “Completed.”

This is a long-running process that can be easily expressed as a workflow for greater visibility into what happens when data is uploaded to the system. Exposing the workflow as a Workflow Service means that client applications can reach it directly, using communication protocols appropriate to the application. Figure 7  illustrates a workflow design that includes a single ReceiveActivity that contains the logic for UploadData() as described in Figure 6.

>Figure 7: Executing workflow functionality synchronously within a ReceiveActivity

Since the entire workflow is contained within the UploadData ReceiveActivity a response is not sent to the calling client until the entire workflow has completed. This can result in a time-out at the client since some of the workflow logic is long-running. For example, available system resources can affect how quickly documents can be generated and their e-mail deliveries sent.

Client applications can rely on the status of the document generation process, recorded in the database by the application, to confirm that data was received and later check the status of the entire process. Under this assumption, the workflow design can be restructured so that the ReceiveActivity is used to initialize the workflow and return, which allows activities related to the actual process to complete asynchronous to the initial call. Figure 8 illustrates this design.

>Figure 8: Executing workflow functionality asynchronously following a ReceiveActivity.

Since the ReceiveActivity does not complete any steps in the workflow before returning, the response to the calling client cannot carry any information confirming execution of some part of the workflow. A more appropriate approach would be to complete some initial step in the workflow to formulate a meaningful response to the client prior to asynchronously executing remaining steps. In this example, the ReceiveActivity could supply a response to clients based on the call to SaveData(),and subsequently execute long-running aspects of the workflow. This workflow design is illustrated in Figure 9.

>Figure 9: Allocating synchronous and asynchronous workflow functionality between ReceiveActivity and other activities that follow it.

This last approach is preferable since it makes better use of the capabilities of a Workflow Service:

• Use the ReceiveActivity to execute initialization steps for the long-running operation and send a response or report a fault (if there is an exception) to the calling client.
• Allow the remainder of the workflow to continue execution asynchronous to the immediate client call. This avoids time-outs on the service operation and allows the workflow to go idle and conserve resources while waiting for human or system interaction.

>Implementation Architecture

Figure 10 illustrates the logical architecture of a Windows client application calling the Workflow Service described in Figure 9.

>Figure 10: Windows client calling the data upload Workflow Service.

Any client application that supports .NET Framework 3.5 can call a Workflow Service; this includes Windows Forms, WPF, and ASP.NET clients. Likewise, Workflow Services can be hosted in any of the host environments supported by WCF including IIS, WAS, and Windows Services. Both HTTP and TCP communications are supported. Figure 10 illustrates a Workflow Service exposed to the Internet over HTTP, hosted in IIS 7, and called by a Windows client. In this case, the WorkflowService and associated WorkflowServiceHost, the Workflow Runtime, and any related assembly dependencies are all hosted within the same application domain in IIS 7.

The ReceiveActivity of the Workflow Service is mapped to the UploadData() operation defined in a service contract. WCF configuration settings include a service endpoint associated with this contract. When the Workflow Service is hosted, a Web Service Description Language (WSDL) document is generated so that the client can generate a proxy to call the service.

When the client calls UploadData() via proxy, the WorkflowServiceHost facilitates initializing the Workflow Runtime for the application domain (if needed) and then initializes the workflow instance for the service operation. Once the workflow instance is initialized, the ReceiveActivity executes. At the end of the ReceiveActivity, a response is sent to the client, in this case, reporting the results of SaveData(), which is a method call executed through an ExternalMethodCallActivity. The remainder of the workflow then executes asynchronous to the ReceiveActivity.

>WCF Contract Design

A Workflow Service associates each ReceiveActivity with a WCF service operation. Service operations for each ReceiveActivity can be defined in a single service contract, or spread across multiple contracts if such factoring is appropriate. The Workflow Designer includes tools to create service contracts while defining the workflow, or to import contracts that have already been defined. Figure 11 illustrates the logical flow for the former: creating a service contract, defining an operation, and associating it with a ReceiveActivity. This is known as workflow-first contract design. The steps are as follows:

• Select the ReceiveActivity and, from the Properties window, configure the ServiceOperationInfo property.
• From the Choose Operation dialog, select Add Contract to create a new contract. Provide a name for the contract.
• Add a new operation to the contract, provide a name, supply a return data type, and supply one or more parameters to the operation. While adding operation parameters, only serializable types (such as data contracts) can be selected. Custom types should be defined in advance, before configuring parameters, so that they appear in the Browse and Select a .NET Type dialog.

>

>Figure 11: Creating a new service contract using the Workflow Designer.

After completing these steps, the service contract is defined and the ReceiveActivity is associated with one of its operations.

From the same set of dialogs, developers can also do the following:

• Create additional contracts or add additional operations to an existing contract.
• Manage the signatures of each operation describing the appropriate return types and parameters; specifying whether operations are one-way; and setting any role-based security requirements for the operation.
• Import predefined service contracts and associating their operations with the ReceiveActivity.

Creating the service contract while defining a workflow not only simplifies the Workflow Service design process, it facilitates better contract factoring by guiding developers through designing a single contract for the Workflow Service, adding operations as needed for each ReceiveActivity.

>Hosting and Configuration

Workflow services can be hosted anywhere a WCF service can be hosted. This typically leads to the following choices:

• On a Windows Server 2003 machine, Internet services will be hosted in IIS 6; for other protocols, Windows Services are used.
• On a Windows Server 2008 machine, IIS 7 and WAS can be used to host Workflow Services for any protocol.
• For Workflow Services hosted on client machines (Windows XP SP2 or Windows Vista) the host may be the client application built with Windows Forms or WPF, or a Windows Service deployed to the client.

Configuration settings for Workflow Services are also set up like any other WCF service. Each service contract used by the Workflow Service (across all ReceiveActivity definitions) should have at least one endpoint configured to be accessible to client applications. Each endpoint is in turn associated with a particular set of protocols through its binding configuration. Workflow Services must use one of the context-aware bindings introduced with .NET Framework 3.5 because they are capable of passing information about the workflow instance using message headers. The bindings are BasicHttpContextBinding, WSHttpContextBinding, and NetTcpContextBinding.

Figure 12 illustrates a workflow with three ReceiveActivity sharing a single service contract, and a single endpoint configuration. That means that all three activities will share the same communication protocols.

>>Figure 12: Multiple ReceiveActivity instances associated with a single service contract and endpoint configuration.

>Security

Each ReceiveActivity in a Workflow Service is associated with a WCF endpoint configuration that defines the supported communication protocols, including security settings. Specifically, endpoint security settings can include the following:

• Security mode settings that govern how message protection is handled and how credentials are passed—using transport security, message security, or some combination of the two.
• What type of client credentials is required by the service.
• The level of message protection that will be used.
• For the context-aware bindings, an additional setting exists to control the protection level of the context headers passed with each call to a Workflow Service.

Client credentials can be sent in the transport or message headers of a message, and those credentials can be one of the following: Windows, username and password, certificate, or another form of issued or custom token. WCF services have a set of security behaviors that govern how those credentials are authenticated and authorized when a service operation is called. Figure 13 illustrates a client passing Windows credentials to authenticate to a Workflow Service. In this case, both endpoints require Windows credentials, and those credentials are authenticated according to the service authentication behavior, which by default will authenticate against the Windows domain. The authorization behavior indicates what type of security principal should be attached to the ReceiveActivity execution thread—in this case a WindowsPrincipal.

>Figure 13: Workflow Service authentication and authorization.

This security principal is valid only on the request thread for the currently executing ReceiveActivity. Each ReceiveActivity must independently authenticate and authorize caller credentials, and create a new security principal accordingly. Activities that follow the ReceiveActivity execute asynchronously, on another thread, and thus do not have access to the security principal that was available to the ReceiveActivity.

The security principal is used to authorize calls to a ReceiveActivity. The Workflow Designer provides a configuration dialog for developers to specify required users or roles (the latter preferred) for callers to the operation (see Figure 14). This works well for Windows or username and password credentials since they are usually role-based. The result is the equivalent of a PrincipalPermission demand check prior to executing the ReceiveActivity.

>Figure 14: Configuring required roles for authentication.

For more granular control over authorization, the ReceiveActivity also exposes an OperationValidation event. Developers can handle this event in lieu of or in addition to configuring permissions for the operation as in Figure 14.

>Common Questions

Q. Can a workflow service be called over named pipes or MSMQ?

Although WCF services support any protocol, the ReceiveActivity for a workflow service supports only context-aware bindings such as BasicHttpContextBinding, WSHttpContextBinding, and NetTcpContextBinding. A custom binding can be created to support protocols such as named pipes along with context, but MSMQ protocol cannot support context due to its asynchronous nature.

Q. Can a Workflow Service include multiple ReceiveActivity instances?

Multiple ReceiveActivity instances are supported, which means that the WSDL document that describes the Workflow Service may include several endpoints operations. Each ReceiveActivity can be associated with the same service contract, or can be factored across multiple service contracts. The workflow handles ReceiveActivity like other event-driven activities—it puts the workflow into an idle state waiting for input.

Q. Do Workflow Services require a separate WCF service contract?

Existing WCF service contracts can be imported and used by a Workflow Service. Developers can then associate individual service operations with a ReceiveActivity.

However, splitting the implementation of a service contract between a Workflow Service for the long-running operations and a WCF service for remaining operations complicates implementation and maintenance. In practice, isolating long-running operations to a separate service contract is best since they are likely to have different configuration requirements. The same school of thought applies to Workflow Services—it is best to isolate related long-running operations to a single contract where individual ReceiveActivity instances can be associated with each operation.

Q. Can pre-existing WCF contracts be edited by the workflow contract designer?

No. Only contracts created by the workflow designer can be modified from within the designer.

Q. How can a ReceiveActivity return a fault to the calling client?

If an exception occurs within the context of the ReceiveActivity, its FaultMessage property should be set to provide meaningful information to the calling client, and to avoid faulting the WCF service channel.

Q. Is there any reason to call a workflow directly from a WCF service operation without using Workflow Services?

Workflow Services greatly simplify the developer experience for initializing workflow from a WCF service operation, and thus it is the preferred approach. If a runtime decision must be made before deciding whether a workflow should be initialized at all, then traditional means of workflow initialization are still available.

Q. Can a Workflow Service be implemented as a state machine workflow?

Yes, state machine workflows also support ReceiveActivity.

Q. Can multiple proxies call the same Workflow Service instance?

Developers can save the context information associated with a Workflow Service proxy after the first call to a ReceiveActivity – and share this information with a different proxy to reach the same workflow instance. This is particularly useful when the proxy must be re-created after a fault.

Q. Are Workflow Services interoperable?

The context-aware bindings that Workflow Services depend on pass information about the workflow instance on each call in SOAP message headers. Requirements for these headers are articulated in the WSDL document for the Workflow Service, and most Web service platforms is fully capable of using this WSDL to generate a proxy that can work with these message headers. If one of the HTTP context bindings is used, this communication is interoperable. If the TCP context binding is used, WCF is required at the client.

Q. Can activities other than the ReceiveActivity perform role-based security checks?

HandleExternalEventActivity and WebServiceInputActivity have a similar role-based security mechanism to ReceiveActivity. The ReceiveActivity provides a built-in mechanism for implementing role-based security within a workflow. Workflows that are initialized through other event-driven activities do not have access to the immediate caller by default. In this case, the workflow is initialized by the Workflow Runtime in response to an event through Local Services or from a DelayActivity. Activities that follow a ReceiveActivity are likewise initialized on another thread and don’t have access to the ReceiveActivity thread’s security principal. Role-based security checks can still be introduced if the workflow is initialized with properties that contain username and related roles.

Q. How can ReceiveActivity authenticate and authorize certificate credentials?

When the configuration for a ReceiveActivity requires a certificate credential, role-based security settings from the dialog in Figure 14 will not be useful since the security principal will not include any roles for the authenticating certificate by default. By handling the ValidateCall event on the ReceiveActivity, developers can access the claim set passed by the certificate, and use this information to authorize the call. Other WCF extensibility points for security can also be used to supply a custom security principal for the ReceiveActivity.

>Calling Services from Workflow

In a service-oriented system, business functionality is likely to be exposed as services, even behind the firewall. Services promote encapsulation, reuse, distribution, and interoperability. They also provide a built-in threading and execution model and become a boundary for version control and security. Calls to individual service operations are traditionally coordinated by a client application or by a workflow that lives between the client and services tier. Workflows have the advantage of providing visibility into the business process and to the service operations that the process depends upon. This approach also makes it easier to reorganize the order of service calls, inject additional business rules around those calls, and simplify the necessary maintenance of the business logic associated with a long-running process.

Features of .NET Framework 3.5 make it easier to design Workflow Services that call out to WCF services at the appropriate execution points. This section will explain these implementation characteristics.

>Workflow Design

Figure 15 illustrates a refinement of the document generation process shown in Figure 6. The functionality is equivalent from a high level—to upload data, generate a document, and distribute that document via e-mail. The difference is that system functionality is now encapsulated by WCF services.

>Figure 15: Service-oriented document generation process.

The top-level DataUpload service exposes an operation called UploadData() that executes the same steps as shown in Figure 6, with the exception that all calls are now made to downstream WCF services instead of making direct calls to .NET assemblies. The business process is now executed calling the following service operations:

• The SaveData() operation exposed by the DocumentManager service.
• The GenerateDocument() operation exposed by the DocumentGeneration service.
• The Send() operation exposed by the Email service.
• The UpdateStatus() operation exposed by the DocumentManager service.

This entire business process is exposed as a Workflow Service as discussed in the section “Exposing Workflow as a Service” to simplify how the Workflow Runtime is engaged. How the workflow design will differ from that shown in Figure 9 is in the mechanism used to call to business functionality exposed by services, using the SendActivity instead of the CallExternalMethodActivity. Figure 16 illustrates this modified workflow design.

>Figure 16: Calling services from a workflow using SendActivity

The ReceiveActivity calls SaveData() before returning a response to the client, and the remainder of the sequence executes asynchronously. This allows the workflow to send a response to calling clients based on the results of the SaveData() call—to confirm that the initial data upload was received prior to beginning the long-running process.

Individual SendActivity execute synchronously, but, if the service operation being called is defined as one-way, the call will return immediately and the workflow continues to the next activity in the sequence.

>Implementation Architecture

Figure 17 illustrates the logical architecture of a Workflow Service that coordinates calls to several WCF services according to the workflow illustrated in Figure 16.

>Figure 17: A workflow service calling WCF services using SendActivity.

Using the SendActivity, a Workflow Service can call WCF services hosted by any legitimate WCF hosting environment, over any transport protocol including HTTP, named pipes, TCP, and MSMQ. Calls can be made in-process, out-of-process, or across machine boundaries depending on service configuration settings as well as the physical distribution of services.

Each SendActivity can call a service with different configuration requirements including those related to transport protocol and other communication protocols such as security requirements. This is controlled by the WCF configuration setting associated with the SendActivity. Configuration settings are used to initialize a proxy to call the WCF service.

>Proxies

Client applications rely on proxies to call WCF services. Typically proxies are generated ahead of time by adding a Service Reference through Visual Studio, or by using the command line utility svcutil.exe. Workflow Services dynamically generate a proxy for each WCF service contract associated with a SendActivity – based on the configuration of the SendActivity. Developers configure each SendActivity as follows:

• Import the WCF service contract type.
• Select a service operation for the SendActivity to call.
• Provide a WCF client configuration section for the service endpoint.

To import the service contract type developers can select from types in the Workflow Service project, or types in referenced assemblies (see Figure 18).

Figure 18: Importing WCF service contracts for a Workflow Service.

Once the contract is imported, its operations will appear in the list of operations to choose from in the Choose Operation dialog used to configure the SendActivity – shown in Figure 19. The selected operation is then associated with the ServiceOperationInfo property of the SendActivity, which is shown in Figure 20.

Figure 19: Selecting an operation for a SendActivity from the Choose Operation dialog.

Figure 20: SendActivity properties.

The SendActivity relies on the EndpointName property to find the correct WCF service configuration to initialize the proxy to call the service. The binding configuration must match that of the service endpoint associated with the operation.

>Security

When Workflow is employed in the middle tier, the workflow becomes the initial boundary through which callers are granted access to business functionality, including functionality exposed by other WCF services. Workflow Services can act as a gateway by authenticating and authorizing calls to each ReceiveActivity, as illustrated in Figure 13. Subsequent calls to WCF services using SendActivity are then secured according to the requirements of those individual services. Services accessed through middle-tier workflows typically do not need to authenticate and authorize access to the initial caller, because the workflow is responsible for this step. Instead, they use a trusted subsystem model whereby calls can be secured by authenticating and authorizing the calling process or application using Windows credentials or a trusted certificate.

Figure 21 illustrates security features of the DataUpload workflow, where the ReceiveActivity that initializes the workflow authenticates and authorizes the caller’s Windows credential, and calls to WCF services authenticate and authorize the process identity that hosts the Workflow Service.

Figure 21: Securing SendActivity calls using Windows credentials.

When a SendActivity calls a WCF service that requires Windows credentials, the proxy generated for the SendActivity automatically sends the Windows credential for the executing process—no coding required.

Figure 22 illustrates the same DataUpload workflow where calls to WCF services are secured using a trusted certificate.

Figure 22: Securing SendActivity calls using a trusted certificate

In this case, the SendActivity relies on a configuration setting that indicates the client certificate to be used to secure calls to each service. This configuration setting usually points to the certificate store for the local machine.

To call WCF services that require other credential types, or credentials that must be supplied at run time, additional code is required to initialize the client channel associated with the SendActivity proxy with appropriate credentials. The SendActivity does not provide developers with direct access to the generated proxy.

>Common Questions

Q. Is there an equivalent to Add Service Reference to configure the SendActivity?

No. But it is possible to generate a Service Reference for the Workflow Service project in order to import service contracts and configuration settings prior to configuring the SendActivity. A dynamic proxy is still created by the Workflow Service.

Q. How can faults be handled when SendActivity is used to call service operations?

After calling a service operation with SendActivity, faults can be handled using the FaultHandlerActivity. This activity contains a sequence to execute when a specific type of fault is thrown.

Q. Can the configuration settings for a SendActivity be dynamic?

A common requirement is to provide a dynamic endpoint address for the service. This can be done by setting the CustomAddress property of the SendActivity. To make the endpoint configuration completely dynamic, a custom ChannelManagerService type is required.