Applying behaviors on the client channel

When we need to modify or see the message before its sent or after its received, we generally use a Message inspector. However sometimes we want it to be a bit more granular. One such requirement was to perform some operations for 2-way calls and a different set of operations for one way calls. For this you can probably use extensibility points like the IParameterInspector and attach the required inspector to those appropriate operations.


public void ApplyClientBehavior(ServiceEndpoint endpoint, ClientRuntime clientRuntime){    foreach (ClientOperation operation in clientRuntime.Operations)    {        if (!operation.IsOneWay)        {            operation.ParameterInspectors.Add(new TwoWayBehavior());        }        else        {            operation.ParameterInspectors.Add(new OneWayBehavior());        }    }}


Here is the source.(3.13 kb)

WCF 4: AddDefaultEndpoints

Here is another little goodie we have which will help in reducing configuration. You can use the ServiceHostBase.AddDefaultEndpoints which will pretty much probe your service implementation for contracts and expose them as shown below. Notice that I don’t need to specify anything more than the base address and the type of the service and I have actually commented out the call to the API. You can find more details about the simplified configuration here.


ServiceHost host = new ServiceHost(typeof(Service1),                new Uri("net.tcp://localhost:8080/"),                new Uri("http://localhost:8081/"));//host.AddDefaultEndpoints();host.Open();



*NOTE: You will get these defaults only if you do not explicitly add an endpoint.

WF 4.0: Hello World Workflow Services

Building a workflow service using 4.0 gives a very neat set of capabilities from both WF and WCF. Similar to WCF we can fully define a workflow either in code or otherwise just using Xaml. Here I chose a fully code based approach. If you just want the source you can download it here. (2.20 kb)

The Service Contract

We can take a either a workflow first or a contract first approach. To keep things simple, I have a very bare service contract as shown below and proceed towards the workflow definition from that.

[ServiceContract]interface IService1{    [OperationContract]    void GetData();}
I also hold on to the contract description. This is just for convenience and to avoid some constants like service name etc.
ContractDescription description = ContractDescription.GetContract(typeof(IService1));

The Operation

The idea here is to build the service bottom up from operation. I can think of my workflow as composition of activities. The functionality of my service is quite simple here. All I do is write a message to the console. So the body of my operation will look something like this.

new WriteLine{    TextWriter = Console.Out,    Text ="Hello Workflow."},

The Implementation

Now I need to make this an operation. An operation has an associated message exchange pattern, commonly referred to as MEP. In my case it’s a simple receive reply pattern. This means I have to compose my work in between a Receive and a SendReply. I am also going to tie this all up in Sequence as shown below.

Sequence sequence = new Sequence{    Activities =    {        receive,        new WriteLine        {            TextWriter = Console.Out,            Text ="Hello Workflow."        },        reply    }};

The Message Exchange

The next thing is to lay out the Receive and Reply which will define the wire format of the messages.

The receive needs to know the operation that the client can invoke. Also I need to make sure that the workflow can be instantiated by this particular operation. For this I need to set the CanCreateInstance property. Also the serializer used by default is the DataContractSerializer.

Receive receive = new Receive{    OperationName = description.Operations[0].Name,    CanCreateInstance = true};

The Reply is send back to the client using my SendReply activity. This reply is a part of a conversation and it needs to know which request it would respond to. I can do this by pointing the SendReply to the instance of the corresponding Receive. Also I don’t have any data here so it is an empty parameter list. (the operation is not Messages contract based in my case but this is generally a better option for more control and performance.)

SendReply reply = new SendReply{    Request = receive,    Content = new SendParametersContent { }};

I now need to define the workflow service which would hold this Sequence and also need to specify the full name of the service definition. For this I can use the description object to get the name, namespace etc.

WorkflowService serviceDefinition = new WorkflowService{    Body = sequence,    Name = XName.Get(description.Name, description.Namespace)};

The Host

The next step is to give this definition to the workflow service host so that it can start the service. Here I self host the workflow as shown below.

WorkflowServiceHost host = new WorkflowServiceHost(serviceDefinition,                                        new Uri("http://localhost:8080"));host.AddServiceEndpoint(serviceDefinition.Name, new BasicHttpBinding(), "");host.Open();

The Test

Finally I can test the workflow using a simple proxy.

ChannelFactory cf = new ChannelFactory(new BasicHttpBinding(), "http://localhost:8080");IService1 proxy = cf.CreateChannel();proxy.GetData();((IChannel)proxy).Close();

The Amulet

Your picture smiles as first it smiled,The ring you gave is still the same,Your letter tells, O changing child,No tidings since it came.Give me an amuletThat keeps intelligence with you,Red when you love, and rosier red,And when you love not, pale and blue.Alas, that neither bonds nor vowsCan certify possession;Torments me still the fear that loveDied in its last expression.

by – Ralph Waldo Emerson

Channel9: Monitoring WF Services

  10-4 Episode 24: Monitoring Workflow Services

By Ron Jacobs -

One of the great advantages to building services with WCF and Windows Workflow 4 is that the environment is instrumented with loads of events that allow you to track what exactly is happening.  This is useful for health monitoring, troubleshooting and other scenarios like auditing and compliance.  In this episode I’ll take you through the monitoring lab from the Visual Studio 2010 training kit and show you how you can take advantage of these powerful capabilities.