Publishing a Workflow As a Service?

WF enables workflows to interact with WCF and call methods that are exposed by a service. WF also enables you to host workflows in a service, which exposes workflow functionality to applications that run across a network or on the Internet and enables cross-platform invocation of workflow code.

For example, consider a movie ticket booking example. If you implement the ticket-booking process as a workflow in a WCF service, you can then write a client application for each of the form factors that you are targeting: wireless application protocol (WAP) browsers, Web sites, staff booking systems, and self-service ticket booths. The various form factors may process and display the information differently to maximize performance on the hardware, but the core business logic is stored in one place for ease of maintenance

Why Publish a Workflow As a Service?

By using WCF, you can host WF workflows as a service, which enables external applications to consume WF functionality.

You can create a workflow library and then reference the library from the service code, or you can embed the workflow into the service directly.

When you publish a workflow as a service, you enable external applications to implement workflow functionality.

You also enable cross-platform, language-independent implementation of your workflow without the need to reproduce a workflow instance for each of the architectures that may need to access it.

For example, an application for booking movie tickets may use a workflow to handle its core logic. You could embed the workflow in a WCF service and then expose the service to the booking staff on their legacy systems, the booking Web site for online customers, and other mobile devices to give the customers a broad range of options.

Without the workflow service, you may need to implement a different version of the workflow for each different booking model. This would cause issues with system distribution and maintenance.

When you publish a workflow as a service, the underlying service is similar to a normal WCF service.

You define interfaces to specify the communication channels and data that will pass between the client application and the service. Proxy objects are created at run time to handle communication between the participants.

The difference is that the OperationContract methods usually relate to a ReceiveActivity activity in a workflow. This activity executes the required functionality before passing any resultant data back to the calling method.

Defining a Service Contract

The process for defining a WF service is similar to the process for defining a WCF service. The difference when you implement a WF service is that you do not create a class that implements the interface as before; the workflow ReceiveActivity activity that implements the operation functionality in the workflow instance represents the implementation class. You mark up the service interface declaration by using the same attributes as you use in a normal WCF service.

To create a class library and define a WCF service:

  1. In Visual Studio, create a new Sequential Workflow Service Library project. You can find the template for the project in the New Project dialog box, in the WCF node under the language of your choice.

  2. In the new project, define a service interface and annotate the interface with the ServiceContract attribute.

  3. Annotate the interface methods with the OperationContract attribute.

  4. Annotate parameter and return data types with the DataContract attribute.

 

When you want to host a workflow as a service, you must define a service contract that determines the methods that external applications can invoke on the service. The following code examples show a service contract, ICustomerDataService, that contains two operation contracts that create a customer record and retrieve customer data from the service. The contract also defines the custom Customer object, which contains several member variables that contain the customer data.

 

namespace Contoso.CustomerServices

{

    [ServiceContract]

    public interface ICustomerDataService

    {

        [OperationContract]

        Customer retrieveCustomerData(int value);

    }

 

    [DataContract]

    public class Customer

    {

        public Customer(string firstName,

                        string lastName,

                        DateTime dateOfBirth)

        {

            _firstName = firstName;

            _lastName = lastName;

            _dateOfBirth = dateOfBirth;

            _age = DateTime.Now.Year - dateOfBirth.Year;

        }

 

        [DataMember]

        public string _firstName;

        [DataMember]

        public string _lastName;

        [DataMember]

        public DateTime _dateOfBirth;

 

        private int _age;                       

    }

}

 

 

For more information about defining service contracts, see Designing Service Contracts

Tags: