The .NET Endpoint

Goodbye .NET Endpoint, Hello AppFabric Team Blog

Ron Jacobs — Mon, 16 May 2011 13:09:00 GMT

Over the last year you’ve heard us talking about both Windows Azure AppFabric and Windows Server AppFabric. Today we are adding our final post to the .NET endpoint team blog and announcing the new AppFabric Team blog. This blog will be the home of content about all things AppFabric from Service Bus to Caching to WCF and WF.

If you’ve been following us here on the .NET Endpoint please be sure to follow the AppFabric Team Blog.

endpoint.tv becomes AppFabric.tv

As part of this change, endpoint.tv will now become AppFabric.tv. We will continue to bring you the best content about WF and WCF as well as the rest of the AppFabric world.

Using DataContracts with WCF Web API

Glenn Block MSFT — Sun, 15 May 2011 02:55:34 GMT

A few folks have been asking if it is possible to serialize/deserialize using the DataContractSerializer. Rest assured, yes it is possible. Now whether or not it is the easiest/most intuitive model well that it is a different question.

If you read to the end the post you will see a bunch of extensions which have been pushed to webapicontrib and make this all MUCH easier (at least I think). If you don’t jump you’ll read below what you need to do if you do it yourself.

It stars with the SetSerializer<T> method which is expose on the XmlMediaTypeFormatter. You can call this method and pass a DataContractSerializer for T. That tells the formatter use this serializer not the default. You need to give it the exact information, for example if you are returning List<Contact> then make T List<Contact> NOT T. If you want to support both, you need to register both.

To allow you to get to the formatter, the MediaTypeFormatterCollection exposes an XmlFormatter property. You might now be thinking, “Oh that’s easy, but how do I get a hold of the formatter collection?”

Good question. It depends on whether you are on the server or on the client.

On the Server

The easiest way to configure things on the server is to annotate your service/resource with a [DataContractFormat] attribute. Once you do then we will automatically use the DataContractSerializer.

If you do not want to annotate your service, the alternative option is to do it in code. If you are using HttpHostConfiguration you can get to the formatters by accessing the OperationHandlerFactory property on the config class. If you are using the fluent API, you’ll want to cast to HttpHostConfiguration in order to access it. For example see the code below

var config = new HttpHostConfiguration();
var formatter = OperationHandlerFactory.XmlFormatter;
formatter.SetSerializer<Contact>(
  new DataContractSerializer(typeof(Contact)));
formatter.SetSerializer<List<Contact>>(
  new DataContractSerializer(typeof(List<Contact>)));

The code above is setting the formatter to use the DCS for Contact and List<Contact> both for reading and writing.

On the client

On the client side how you configure depends on if you are reading or writing. In either case both steps involve calling SetSerializer<T> on the XmlMediaTypeFormatter.

For reading you will create the formatter and pass it to the ReadAs<T> method of the HttpContent which is accessed off of the Content property on HttpResponseMessage.

var formatter = new XmlMediaTypeFormatter();
formatter.SetSerializer<List<Contact>>>(
  new DataContractSerializer(typeof(List<Contact>))));
var contact = response.Content.ReadAs<T>(
  new List<MediaTypeFormatter> { formatter });

If you are writing to the request, you will access the formatters collection on the ObjectContent<T> instance.

var content = new ObjectContent<Contact>();
content.Formatters.SetSerializer<Contact>(
  new DataContractSerializer(typeof(Contact)));
client.Post(content);

New extension methods in webapicontrib to make life easier

Now that we’ve seen how you can do it, we can wrap this up in a bunch of helper extension methods and life gets a whole lot easier. I did that and pushed them to webapicontrib

Check the code below from the new DataContractExample in webapicontrib.

var config = HttpHostConfiguration.Create();
config.UseDataContractSerializer<Contact>();
var host = new HttpConfigurableServiceHost<ContactsResource>(
  config, new Uri("http://localhost:8080/"));
host.Open();
var client = new HttpClient("http://localhost:8080/");
var newContact = new Contact {FirstName = "Brad", LastName = "Abrams"};
var content = new ObjectContent<Contact>(newContact,
  "application/xml").UseDataContractSerializer();
var response = client.Post("contacts", content);
response = client.Get("contacts");
var contacts = response.Content.ReadAsDataContract<Contact[]>();
foreach (var contact in contacts)
{
  Console.WriteLine(string.Format(
    "Contact: FirstName={0}, LastName={1}", 
    contact.FirstName, contact.LastName));
}
Console.ReadLine();

I’ve highlighted the important parts

UseDataContractSerializer<T> on the config will set the formatter to serialize T using DCS. In order to make life easier the extension method also registers for List<T> and T[].
For reading on the client call the ReadAsDataContract<T> extension method on HttpContent.
For writing on the client create an ObjectContent<T> instance and call the UseDataContractSerializer() extension metho

Download the bits in wcfwebapi contrib here

How to eliminate tempuri.org from your service WSDL

Ron Jacobs — Thu, 12 May 2011 19:34:45 GMT

tempuri.org is the default namespace applied to WCF Services and Workflow Services. You can and should specify your service namespace.

It is recommended that you explicitly specify a name and namespace for the service contract, and an action for each operation to avoid using "http://tempuri.org" and to prevent interface and method names from being exposed in the service’s contract
MSDN Library - Service Contract Versioning

Where is tempuri.org in the WSDL?

If you browse the service WSDL you will see tempuri.org all over the place. Here is a default WCF service WSDL.

     <wsdl:definitions name="Service1" targetNamespace="http://tempuri.org/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/" xmlns:tns="http://tempuri.org/" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wsap="http://schemas.xmlsoap.org/ws/2004/08/addressing/policy" xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl" xmlns:msc="http://schemas.microsoft.com/ws/2005/12/wsdl/contract" xmlns:wsa10="http://www.w3.org/2005/08/addressing" xmlns:wsx="http://schemas.xmlsoap.org/ws/2004/09/mex" xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata">

      <wsdl:types>

        <xsd:schema targetNamespace="http://tempuri.org/Imports">

          <xsd:import schemaLocation="http://localhost:63720/Service1.svc?xsd=xsd0" namespace="http://tempuri.org/"/>

        </xsd:schema>

      </wsdl:types>

      <wsdl:message name="IService1_DoWork_InputMessage">

        <wsdl:part name="parameters" element="tns:DoWork"/>

      </wsdl:message>

      <wsdl:message name="IService1_DoWork_OutputMessage">

        <wsdl:part name="parameters" element="tns:DoWorkResponse"/>

      </wsdl:message>

      <wsdl:portType name="IService1">

        <wsdl:operation name="DoWork">

          <wsdl:input wsaw:Action="http://tempuri.org/IService1/DoWork" message="tns:IService1_DoWork_InputMessage"/>

          <wsdl:output wsaw:Action="http://tempuri.org/IService1/DoWorkResponse" message="tns:IService1_DoWork_OutputMessage"/>

        </wsdl:operation>

      </wsdl:portType>

      <wsdl:binding name="BasicHttpBinding_IService1" type="tns:IService1">

        <soap:binding transport="http://schemas.xmlsoap.org/soap/http"/>

        <wsdl:operation name="DoWork">

          <soap:operation soapAction="http://tempuri.org/IService1/DoWork" style="document"/>

          <wsdl:input>

            <soap:body use="literal"/>

          </wsdl:input>

          <wsdl:output>

            <soap:body use="literal"/>

          </wsdl:output>

        </wsdl:operation>

      </wsdl:binding>

      <wsdl:service name="Service1">

        <wsdl:port name="BasicHttpBinding_IService1" binding="tns:BasicHttpBinding_IService1">

          <soap:address location="http://localhost:63720/Service1.svc"/>

        </wsdl:port>

      </wsdl:service>

    </wsdl:definitions>

Tip: Use a constant to ensure consistency

I like to use a constant to provide a consistent namespace across my services

    public class Constants

    {

        // Ensures consistency in the namespace declarations across services

        public const string Namespace = "http://contoso.com/services/";

    }

How to eliminate tempuri.org from WCF Services WSDL

Step 1: Declare a namespace on your service contract

The namespace can be anything. People typically use a URI of some form but it does not have to point to an actual web page. Often people will use a version identifier in the namsepace but there are no rules about what you should do.

    // Eliminate tempuri.org from the contract

    // If you don't want to us a constant, put the URI here

    // [ServiceContract(Namespace = "http://contoso.com/services")]

    [ServiceContract(Namespace = Constants.Namespace)]

    public interface IService1

    {

        [OperationContract]

        void DoWork();

    }

Step 2: Declare a namespace on your service

The service namespace is added with a ServiceBehavior attribute. Using the constant ensures that the namespace is the same for the contract and the service.

    // If you don't want to us a constant, put the URI here

    // [ServiceBehavior(Namespace = "http://contoso.com/services")]

    [ServiceBehavior(Namespace = Constants.Namespace)]

    public class Service1 : IService1

    {

        public void DoWork()

        {

        }

    }

Step 3: Set the binding namespace

    <system.serviceModel>

        <services>

          <service name="EliminateTempUri.Service1">

            <!-- Use a bindingNamespace to eliminate tempuri.org -->

            <endpoint address=""

                      binding ="basicHttpBinding" 

                      bindingNamespace="http://contoso.com/services"

                      contract="EliminateTempUri.IService1"

            />

          </service>

        </services>

        <behaviors>

          <serviceBehaviors>

            <behavior name="">

              <serviceMetadata httpGetEnabled="true" />

              <serviceDebug includeExceptionDetailInFaults="false" />

            </behavior>

          </serviceBehaviors>

        </behaviors>

        <serviceHostingEnvironment multipleSiteBindingsEnabled="true" />

      </system.serviceModel>

How to eliminate tempuri.org from Workflow Services WSDL

For workflow services the process is slightly different. Workflow services do not have a contract (it is inferred from the activities) so here is the process.

Step 1: Declare a namespace on each receive activity

I wish it were possible to use a constant here but sadly it is not. For each receive activity you must declare the namespace and contract name using a special syntax of {namespace}IContractName. In this example I’ve set the ServiceContractName property to {http://contoso.com/services}IService

Step 2: Declare a namespace for the Workflow Service

Open the Workflow Service and click in the designer outside of an activity. This will allow you to set the properties of the service itself.
Set the Name property to use the same namespace as you see below.

Step 3: Set the binding namespace

Many people do not declare a <service> tag for their Workflow Services but if you want to eliminate tempuri.org you will need to declare it.

For a Workflow Service the A,B,Cs of WCF configuration are a little different.

Service Name – use the ConfigurationName property from the WorkflowService
A – Address – should be blank when hosted in IIS / AppFabric
B – Binding – use the binding of your choice. Typically basicHttpBinding
C – Contract – use the interface name from the ServiceContractName property (without the namespace)

    <!-- For Workflow Services name is the ConfigurationName property -->

    <service name="Service2">

      <!-- contract must match the receive activity -->

      <!-- Use a bindingNamespace to eliminate tempuri.org -->

      <endpoint address=""

                binding ="basicHttpBinding"

                bindingNamespace="http://contoso.com/services"

                contract="IService"

      />

    </service>

Test It Out

Right click on your WCF or Workflow Service in Visual Studio and select View In Browser.
Click on the link to view the WSDL
Search in the browser for tempuri.org – there should be no matches

Happy Coding!

Ron Jacobs
http://blogs.msdn.com/rjacobs
Twitter: @ronljacobs http://twitter.com/ronljacobs

WCF Extensibility – Operation Selectors

CarlosFigueira — Tue, 10 May 2011 16:48:38 GMT

This post is part of a series about WCF extensibility points. For a list of all previous posts and planned future ones, go to the index page.

We’re now entering the realm of the less used extensibility points for the WCF runtime. Operation selectors could well be left as an internal implementation detail for WCF, but for some reason the designers decided to make them public (I think the guideline back then was if anyone can come up with a scenario where a user would use it, then WCF would expose a hook for that). The server selector (IDispatchOperationSelector) is actually interesting to have as a public hook, as the whole UriTemplate model for REST services was built on top of it – basically, the selector knows about the HTTP method and URI templates for each service operation, and based on those properties of incoming messages it can call the appropriate operation. For “normal” (i.e., SOAP) endpoints, the operation selector implementation (which happens to be internal) is based on the addressing of the binding – in most of the cases it simply matches the Action header of the message with a map of action to the operation names.

The client operation selector (IClientOperationSelector) is another story. The client selector receives the method invoked by the client (the System.Reflection.MethodBase object) and it must return an operation name which will be used by the WCF runtime to retrieve the actual client operation from the client runtime. I’ve tried for a while to think of any scenario where one would actually want to call one method in the proxy and have another operation be executed (besides some practical joke scenario where one would swap Add for Subtract in a calculator), but I just can’t think of any. Even searching on Bing or Google doesn’t show any real scenarios where a client selector is used. But well, WCF is extensible, so let’s let people choose their client operations as well .

Public implementations in WCF

WebHttpDispatchOperationSelector (server): The dispatch implementation where the UriTemplate magic happens for WCF REST endpoints.

There are no public implementations for IClientOperationSelector, only an internal one which simply returns the operation name of the method being called.

Interface declaration

 public interface IDispatchOperationSelector
{
    string SelectOperation(ref Message message);
}
 
public interface IClientOperationSelector
{
    bool AreParametersRequiredForSelection { get; }
    string SelectOperation(MethodBase method, object[] parameters);
}
 

The dispatch operation selector is quite simple – on SelectOperation you get the message, you return the operation name. In most cases the operation can be selected based on information on the message header (e.g., the Action header for SOAP endpoints) or the message properties (e.g., the HTTP request property attached to the message). There are scenarios, however, where the routing to the operation needs to be done based on the message contents, so the message is passed by reference – if it needs to be consumed by the operation selector, it can recreated it to hand it back to the WCF pipeline.

On the client side the AreParametersRequiredForSelection is used to determine whether the response to SelectOperation can be cached or not – if the parameters are not required, the WCF runtime will only call SelectOperation once per method in the proxy, otherwise every time a proxy call is made the selector will be invoked again.

How to add operation selectors

At the server side: the operation selector is a property of the DispatchRuntime object. It’s typically accessed via the endpoint dispatcher in a call to IEndpointBehavior.ApplyDispatchBehavior.

 public class MyEndpointBehavior : IEndpointBehavior
{
    public void ApplyDispatchBehavior(ServiceEndpoint endpoint, EndpointDispatcher endpointDispatcher)
    {
        endpointDispatcher.DispatchRuntime.OperationSelector = new MyOperationSelector();
    }
}
 
public class MyOperationSelector : IDispatchOperationSelector
{
    public string SelectOperation(ref Message message)
    {
        string action = message.Headers.Action;
        return action.Substring(action.LastIndexOf('/') + 1);
    }
}
 

At the client side: the operation selector is a property of the ClientRuntime object, and is typically accessed via the implementation of IEndpointBehavior.ApplyClientBehavior.

 public class MyEndpointBehavior : IEndpointBehavior
{
    public void ApplyClientBehavior(ServiceEndpoint endpoint, ClientRuntime clientRuntime)
    {
        clientRuntime.OperationSelector = new MyClientOperationSelector();
    }
}
 
public class MyClientOperationSelector : IClientOperationSelector
{
    public bool AreParametersRequiredForSelection
    {
        get { return false; }
    }
 
    public string SelectOperation(MethodBase method, object[] parameters)
    {
        return method.Name;
    }
}
 

Real world scenario: Support for X-HTTP-Method-Override in REST endpoints

This issue came from the forum. REST services we use HTTP verbs (methods) to determine the action to be applied to the resource. For example, a GET request to /Contacts/1 would return the contact with id 1, while DELETE /Contacts/1 would remove that same contact from the repository. This is a great – and simple – model, but there are some browsers, proxies, firewalls or even some web service platforms which don’t support the full set of verbs (rejecting anything other than GET and POST). In order to overcome this problem, some platforms (such as ASP.NET MVC and Google Data) started supporting a new HTTP header or field, called X-HTTP-Method-Override, which contain the actual method which should be used by the service to access the resource. The WCF REST API doesn’t support this override natively, but that doesn’t preclude us from using an extensibility point to enable it.

Implementing the support for X-HTTP-Method-Override is nothing but a matter of replacing the operation selector (based on methods and URI templates) used by REST endpoints with our own, which is aware of this new header. When the IDispatchOperationSelector.SelectOperation method is called, we can check if the incoming request contained the override header, and if so, we can update the incoming message properties to let the original selector chose the appropriate operation.

For this example I’ll reuse the contact manager service from the message inspectors post – it contains the different operations which differ based on the HTTP verb of the incoming request, so it’s perfect for this issue. And before I start, the usual disclaimer – this is a sample for illustrating the topic of this post, this is not production-ready code. I tested it for a few contracts and it worked, but I cannot guarantee that it will work for all scenarios (please let me know if you find a bug or something missing). Also, for simplicity sake it doesn’t have a lot of error handling which a production-level code would. Also, the contact manager is all stored in memory, a “real” one would have a backing database or something more “persistent”.

One small parenthesis: the link below for the code in this post contains the version shown here in C# and also a version in VB.NET which does the same thing; if you’re a VB developer, you can check the MSDN code samples out.

The contracts and service implementation are exactly the same as the one from before (I removed the version for Text, as it didn’t add any value to this topic):

 [DataContract]
public class Contact
{
    [DataMember]
    public string Id { get; set; }
    [DataMember]
    public string Name { get; set; }
    [DataMember]
    public string Email { get; set; }
    [DataMember]
    public string[] Telephones { get; set; }
}
 
[ServiceContract]
public interface IContactManager
{
    [WebInvoke(
        Method = "POST",
        UriTemplate = "/Contacts",
        ResponseFormat = WebMessageFormat.Json)]
    string AddContact(Contact contact);
 
    [WebInvoke(
        Method = "PUT",
        UriTemplate = "/Contacts/{id}",
        ResponseFormat = WebMessageFormat.Json)]
    void UpdateContact(string id, Contact contact);
 
    [WebInvoke(
        Method = "DELETE",
        UriTemplate = "/Contacts/{id}",
        ResponseFormat = WebMessageFormat.Json)]
    void DeleteContact(string id);
 
    [WebGet(UriTemplate = "/Contacts", ResponseFormat = WebMessageFormat.Json)]
    List<Contact> GetAllContacts();
 
    [WebGet(UriTemplate = "/Contacts/{id}", ResponseFormat = WebMessageFormat.Json)]
    Contact GetContact(string id);
}
 
public class ContactManagerService : IContactManager
{
    static List<Contact> AllContacts = new List<Contact>();
    static int currentId = 0;
    static object syncRoot = new object();
 
    public string AddContact(Contact contact)
    {
        int contactId = Interlocked.Increment(ref currentId);
        contact.Id = contactId.ToString(CultureInfo.InvariantCulture);
        lock (syncRoot)
        {
            AllContacts.Add(contact);
            WebOperationContext.Current.OutgoingResponse.StatusCode = HttpStatusCode.Created;
        }
 
        return contact.Id;
    }
 
    public void UpdateContact(string id, Contact contact)
    {
        contact.Id = id;
        lock (syncRoot)
        {
            int index = this.FetchContact(id);
            if (index >= 0)
            {
                AllContacts[index] = contact;
            }
        }
    }
 
    public void DeleteContact(string id)
    {
        lock (syncRoot)
        {
            int index = this.FetchContact(id);
            if (index >= 0)
            {
                AllContacts.RemoveAt(index);
            }
        }
    }
 
    public List<Contact> GetAllContacts()
    {
        List<Contact> result;
        lock (syncRoot)
        {
            result = AllContacts.ToList();
        }
 
        return result;
    }
 
    public Contact GetContact(string id)
    {
        Contact result;
        lock (syncRoot)
        {
            int index = this.FetchContact(id);
            result = index < 0 ? null : AllContacts[index];
        }
 
        return result;
    }
 
    private int FetchContact(string id)
    {
        int result = -1;
        for (int i = 0; i < AllContacts.Count; i++)
        {
            if (AllContacts[i].Id == id)
            {
                result = i;
                break;
            }
        }
 
        if (result < 0)
        {
            WebOperationContext.Current.OutgoingResponse.StatusCode = HttpStatusCode.NotFound;
        }
 
        return result;
    }
}
 

Now for the behavior used to set up the operation selector. The behavior wraps the original operation selector from the endpoint, so it needs to be added after the WebHttpBehavior (which will add the first selector to the runtime) – see the discussion about wrapping internal objects at the post about formatters).

 public class HttpOverrideBehavior : IEndpointBehavior
{
    public const string HttpMethodOverrideHeaderName = "X-HTTP-Method-Override";
    public const string OriginalHttpMethodPropertyName = "OriginalHttpMethod";
 
    public void AddBindingParameters(ServiceEndpoint endpoint, BindingParameterCollection bindingParameters)
    {
    }
 
    public void ApplyClientBehavior(ServiceEndpoint endpoint, ClientRuntime clientRuntime)
    {
    }
 
    public void ApplyDispatchBehavior(ServiceEndpoint endpoint, EndpointDispatcher endpointDispatcher)
    {
        endpointDispatcher.DispatchRuntime.OperationSelector = new HttpOverrideOperationSelector(endpointDispatcher.DispatchRuntime.OperationSelector);
    }
 
    public void Validate(ServiceEndpoint endpoint)
    {
    }
}
 

And the selector itself. As I mentioned before, The first thing the selector will do is to try to fetch the HttpRequestMessageProperty from the message properties – if the message was received using HTTP, it will contain information about the HTTP verb and headers in the request. It will then try to find the X-HTTP-Method-Override header, and if it’s present, it will update the message property with the method override. For completeness sake, this selector also adds a new property to the message with the original HTTP verb from the request (if the service needs this information somehow). Finally, the selector delegates the selection to the original selector, which will then use that information to route the incoming request to the appropriate method.

 class HttpOverrideOperationSelector : IDispatchOperationSelector
{
    private IDispatchOperationSelector originalSelector;
 
    public HttpOverrideOperationSelector(IDispatchOperationSelector originalSelector)
    {
        this.originalSelector = originalSelector;
    }
 
    public string SelectOperation(ref Message message)
    {
        if (message.Properties.ContainsKey(HttpRequestMessageProperty.Name))
        {
            HttpRequestMessageProperty reqProp;
            reqProp = (HttpRequestMessageProperty)message.Properties[HttpRequestMessageProperty.Name];
            string httpMethodOverride = reqProp.Headers[HttpOverrideBehavior.HttpMethodOverrideHeaderName];
            if (!String.IsNullOrEmpty(httpMethodOverride))
            {
                message.Properties[HttpOverrideBehavior.OriginalHttpMethodPropertyName] = reqProp.Method;
                reqProp.Method = httpMethodOverride;
            }
        }
 
        return this.originalSelector.SelectOperation(ref message);
    }
}
 

Finally, the test code to wrap it all together. The code is very similar to the one for the message inspectors post, with a few differences: the new behavior (HttpOverrideBehavior) is added after the REST ((WebHttp) behavior, and after sending requests with the “real” HTTP verb it will send some additional requests using POST, but using the HTTP override method to route it to different operations.

 static void Main(string[] args)
{
    string baseAddress = "http://" + Environment.MachineName + ":8000/Service";
    ServiceHost host = new ServiceHost(typeof(ContactManagerService), new Uri(baseAddress));
    ServiceEndpoint endpoint = host.AddServiceEndpoint(typeof(IContactManager), new WebHttpBinding(), "");
    endpoint.Behaviors.Add(new WebHttpBehavior());
    endpoint.Behaviors.Add(new HttpOverrideBehavior());
    host.Open();
    Console.WriteLine("Host opened");
 
    string johnId = SendRequest(
        "POST",
        baseAddress + "/Contacts",
        "application/json",
        CreateJsonContact(null, "John Doe", "john@doe.com", "206-555-3333"));
    string janeId = SendRequest(
        "POST",
        baseAddress + "/Contacts",
        "application/json",
        CreateJsonContact(null, "Jane Roe", "jane@roe.com", "202-555-4444 202-555-8888"));
 
    Console.WriteLine("All contacts");
    SendRequest("GET", baseAddress + "/Contacts", null, null);
 
    Console.WriteLine("Updating Jane");
    SendRequest(
        "PUT",
        baseAddress + "/Contacts/" + janeId,
        "application/json",
        CreateJsonContact(janeId, "Jane Roe", "jane@roe.org", "202-555-4444 202-555-8888"));
 
    Console.WriteLine("All contacts");
    SendRequest("GET", baseAddress + "/Contacts", null, null);
 
    Console.WriteLine("Deleting John");
    SendRequest("DELETE", baseAddress + "/Contacts/" + johnId, null, null);
 
    Console.WriteLine("Is John still here?");
    SendRequest("GET", baseAddress + "/Contacts/" + johnId, null, null);
 
    Console.WriteLine("Adding John again");
    johnId = SendRequest(
        "POST",
        baseAddress + "/Contacts",
        "application/json",
        CreateJsonContact(null, "John Doe", "john@doe.com", "206-555-3333"));
 
    Console.WriteLine("Updating John, now using X-HTTP-Method-Override");
    Dictionary<string, string> overrideWithPut = new Dictionary<string, string>();
    overrideWithPut.Add("X-HTTP-Method-Override", "PUT");
    SendRequest(
        "POST",
        baseAddress + "/Contacts/" + johnId,
        "application/json",
        CreateJsonContact(johnId, "John Doe Updated", "john@doe.com", "206-555-3333"),
        overrideWithPut);
 
    Console.WriteLine("All contacts");
    SendRequest("GET", baseAddress + "/Contacts", null, null);
 
    Console.WriteLine("Deleting Jane, using X-HTTP-Method-Override");
    Dictionary<string, string> overrideWithDelete = new Dictionary<string, string>();
    overrideWithDelete.Add("X-HTTP-Method-Override", "DELETE");
    SendRequest("POST", baseAddress + "/Contacts/" + janeId, "application/json", "", overrideWithDelete);
 
    Console.WriteLine("All contacts");
    SendRequest("GET", baseAddress + "/Contacts", null, null);
 
    Console.WriteLine("Press ENTER to close");
    Console.ReadLine();
    host.Close();
}
 

Coming up

Operation invokers, for both synchronous and asynchronous operations.

[Code in this post]

[Back to the index]

Carlos Figueira
http://blogs.msdn.com/carlosfigueira
Twitter: @carlos_figueira http://twitter.com/carlos_figuei

Constraining what activities can be dropped on a custom activity designer in Windows Workflow Foundation 4

Patrick D. Fletcher [MSFT] — Mon, 09 May 2011 22:34:00 GMT

When designing a custom activity that can be used as a container for other activities, you may want to restrict the activity user to a certain set of activities.

If the custom activity can only accept a single type, this can be implemented quite simply by setting the WorkflowItemPresenter.AllowedItemType or WorkflowItemsPresenter.AllowedItemType property. In this example, I allow only a WriteLine activity to be dropped:

<sap:WorkflowItemsPresenter HintText="Drop Activities Here" 

Margin="5" MinHeight="100"

Items="{Binding Path=ModelItem.Activities}"

AllowedItemType="{x:Type TypeName=sa:WriteLine}">

Note that to use the above code, you'll need to add a namespace declaration to your designer:

xmlns:sa="clr-namespace:System.Activities.Statements;assembly=System.Activities"

If you need to restrict to a set of allowed activity types, rather than a single type, this can be done by adding a validation error to the validation errors collection during the CacheMetadata phase. Note that this will create a runtime error (though technically the user will experience it in the design phase), which will cause an error icon to be displayed, rather than preventing the activity to be dropped in the first place. In this example, I allow only a WriteLine or Assign activity to be dropped:

protected override void CacheMetadata(NativeActivityMetadata metadata)

{

    base.CacheMetadata(metadata);

    foreach (Activity a in Activities)

    {

        if ((a.GetType() != typeof(System.Activities.Statements.WriteLine)) && (a.GetType() != typeof(System.Activities.Statements.Assign)))

        {

            metadata.AddValidationError("Child activity is not of type WriteLine or Assign");

        }

    }

}

Microsoft.Activities and Microsoft.Activities.UnitTesting now available via NuGet

Ron Jacobs — Mon, 09 May 2011 17:31:48 GMT

When I first saw NuGet I knew I had to find a way to take advantage of this great new way to deliver code to you. It took a few months but finally the other day I decided to spend an afternoon working on a NuGet package for Microsoft.Activities. Two and a half days later (isn’t that how it always goes) I produced packages for Microsoft.Activities and Microsoft.Activities.UnitTesting

How To Get Microsoft.Activities or Microsoft.Activities.UnitTesting with NuGet

Step 0: Install NuGet

If you don’t already have NuGet, install it now (you will have to restart Visual Studio if it is already running)

Step 1: Create a project

Your project can be any kind of project. NuGet will automatically add references that are required. For this example, I’m going to create a Class Library project.

Step 2a: Install the Microsoft.Activities Package (Using the Package Manager Console)

Select View / Other Windows / Package Manager Console
Type Install-Package Microsoft.Activities

Step 2b: Install the Microsoft.Activities Package (Using Library Package Reference)

If you would rather have a UI to browse packages,

Right click on the references folder
Select Add Library Package Reference…
In the search box type Microsoft.Activities
Click the Install button to add a library package reference

What Happens to my Project / Visual Studio when I install this?

Your Project

Add reference to System.Activities
Add reference to ($SolutionDir)packages\Microsoft.Activities.1.8.1.506\lib\Net40\Microsoft.Activities.dll) with copy local = true so the assembly will be in your bin directory when you build.

Visual Studio

Added toolbox icons for the activities in Microsoft.Activities to your toolbox pointing to the last installation location for Microsoft.Activities.dll
Add a new Workflow to your project to see the two groups (Dictionary and Microsoft.Activities)

What if I want to use .NET 4 Platform Update 1 so I can create a State Machine workflow?

The Microsoft.Activities package includes a version built for .NET 4 Platform Update 1. As you see in the folder structure there are Net40 and Net401 folders. NuGet automatically detects which version of the .NET Framework your project is targeting and will add a reference to the appropriate version

What if I change my target framework to .NET 4 Platform Update 1 after installing the Microsoft.Activities Package?

If you change your target framework after installing your project will continue to reference the .NET 4 version of Microsoft.Activities. You can update the reference manually by browsing the packages folder and adding a reference or you can uninstall / reinstall the package.

What if I create a new project and drag an activity from Microsoft.Activities onto a workflow without first installing Microsoft.Activities?

Toolbox activities remain in the toolbox across projects. When you create a new project and open the workflow designer you will see the Microsoft.Activities and Dictionary tabs. When you drag one of these activities onto the workflow designer, Visual Studio will add a reference to the assembly that the toolbox icon is associated with.

If you installed the Microsoft.Activities package to a project named ClassLibary1 and then created another project named WorkflowConsoleApplication1 as soon as you start dragging an activity onto a workflow from WorkflowConsoleApplication1 you will see an assembly reference added to the Microsoft.Activities package installed under the ClassLibrary1 solution.

What if I delete the solution where Microsoft.Activities was installed?

If you try to delete it while Visual Studio is open you will get an error because Visual Studio has the assembly loaded. If you close Visual Studio and delete the solution, the next time you run Visual Studio and open the Workflow Designer you will see the icons are still in the toolbox. However when you try to drop an activity from the missing assembly, Visual Studio won’t allow it because it is unable to locate the assembly to add a reference.

How do I fix the toolbox icons if they refer to an assembly that no longer exists?

Each time install the Microsoft.Activities package, if the toolbox icons exist, they are removed and replaced with a toolbox icon that refers to the Microsoft.Activities assembly that is installed with the package in current project.

What if I want to store the Microsoft.Activities assembly in some other location? How do I keep the NuGet package from updating my toolbox icons?

If you change the name of the Tab group from Microsoft.Activities to something else, the package installation script won’t find the activities and won’t update them. However it will add a new activity group.

How do I uninstall the Microsoft.Activities package?

Open the Package Manager console
Type Uninstall-Package Microsoft.Activities
In the toolbox, right click on the Microsoft.Activities tab group and select Delete Tab
Repeat for the Dictionary Group

Sometimes you will get an error when trying to uninstall because Visual Studio has one of the assemblies open. In this case you will have to manually delete the package.

PM> Uninstall-Package Microsoft.Activities
Successfully removed 'Microsoft.Activities 1.8.1.506' from WorkflowConsoleApplication10. 
Access to the path 'd:\ngt\WorkflowConsoleApplication10\packages\Microsoft.Activities.1.8.1.506\lib\Net40\Microsoft.Activities.dll' is denied. 
Access to the path 'd:\ngt\WorkflowConsoleApplication10\packages\Microsoft.Activities.1.8.1.506\tools\Microsoft.Activities.NuGet.dll' is denied. 
The directory is not empty.

What if I install Microsoft.Activities.UnitTesting and I don’t have Microsoft.Activities?

Not to worry. Microsoft.Activities.UnitTesting has a dependency on the Microsoft.Activities package so NuGet will automatically deploy it as well.

PM> Install-Package Microsoft.Activities.UnitTesting 
'Microsoft.Activities (≥ 1.8.1)' not installed. Attempting to retrieve dependency from source... 
Done. 
Successfully installed 'Microsoft.Activities 1.8.1.509'. 
Successfully installed 'Microsoft.Activities.UnitTesting 1.8.1.509'. 
Successfully added 'Microsoft.Activities 1.8.1.509' to WorkflowConsoleApplication14. 
Successfully added 'Microsoft.Activities.UnitTesting 1.8.1.509' to WorkflowConsoleApplication14.

What if I install Microsoft.Activities.UnitTesting and then try to Uninstall Microsoft.Activities

PM> Uninstall-Package Microsoft.Activities
Uninstall-Package : Unable to uninstall 'Microsoft.Activities 1.8.1.509' because 'Microsoft.Activities.UnitTesting 1.8.1.509' depends on it.
At line:1 char:18
+ Uninstall-Package <<<<  Microsoft.Activities
    + CategoryInfo          : NotSpecified: (:) [Uninstall-Package], InvalidOperationException
    + FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.PowerShell.Commands.UninstallPackageCommand

What do you think?

I’m really happy with NuGet so far. I just updated the uninstall scripts so that they will remove the toolbox tabs (Microsoft.Activities, Dictionary and Unit Testing) created by the install scripts. Of all the things these packages do the interaction with the toolbox is the one area that I’m not sure about. Hopefully what I’ve done here will work for you. If not, tell me how we can do it better.

Ron Jacobs
http://blogs.msdn.com/rjacobs
Twitter: @ronljacobs http://twitter.com/ronljacobs

WCF scales up slowly with bursts of work

Dustin Metzgar — Thu, 05 May 2011 01:30:00 GMT

A few customers have noticed an issue with WCF scaling up when handling a burst of requests. Fortunately, there is a very simple workaround for this problem that is covered in KB2538826 (thanks to David Lamb for the investigation and write up). The KB article provides a lot of good information about when this would apply to your application and what to do to fix it. In this post, I want to explore exactly what's happening.

The best part is that there is an easy way to reproduce the problem. To do this, create a new WCF service application with the .NET 4 framework:

Then trim the default service contract down to only the GetData method:

using System.ServiceModel;

[ServiceContract]
public interface IService1
{
    [OperationContract]
    string GetData(int value);
}

And fill out the GetData method in the service code:

using System;
using System.Threading;

public class Service1 : IService1
{
    public string GetData(int value)
    {
        Thread.Sleep(TimeSpan.FromSeconds(2));
        return string.Format("You entered: {0}", value);
    }
}

The two second sleep is the most important part of this repro. We'll explore why after we create the client and observe the effects. But first, make sure to set the throttle in the web.config:

<configuration>
  <system.web>
    <compilation debug="true" targetFramework="4.0" />
  </system.web>
  <system.serviceModel>
    <behaviors>
      <serviceBehaviors>
        <behavior>
          <serviceMetadata httpGetEnabled="true"/>
          <serviceDebug includeExceptionDetailInFaults="false"/>
          <serviceThrottling maxConcurrentCalls="100"/>
        </behavior>
      </serviceBehaviors>
    </behaviors>
    <serviceHostingEnvironment multipleSiteBindingsEnabled="true" />
  </system.serviceModel>
  <system.webServer>
    <modules runAllManagedModulesForAllRequests="true"/>
  </system.webServer>
</configuration>

The Visual Studio web server would probably suffice, but I changed my web project to use IIS instead. This makes it more of a realistic situation. To do this go to the project properties, select the Web tab, and switch to IIS.

Be sure to hit the Create Virtual Directory button. In my case, I have SharePoint installed and it's taking up port 80, so I put the default web server on port 8080. Once this is done, build all and browse to the service to make sure it's working correctly.

To create the test client, add a new command prompt executable to the solution and add a service reference to Service1. Change the client code to the following:

using System;
using System.Threading;
using ServiceReference1;

class Program
{
    private const int numThreads = 100;
    private static CountdownEvent countdown;
    private static ManualResetEvent mre = new ManualResetEvent(false);

    static void Main(string[] args)
    {
        string s = null;
        Console.WriteLine("Press enter to start test.");
        while ((s = Console.ReadLine()) == string.Empty)
        {
            RunTest();
            Console.WriteLine("Allow a few seconds for threads to die.");
            Console.WriteLine("Press enter to run again.");
            Console.WriteLine();
        }
    }

    static void RunTest()
    {
        mre.Reset();
        Console.WriteLine("Starting {0} threads.", numThreads);
        countdown = new CountdownEvent(numThreads);
        for (int i = 0; i < numThreads; i++)
        {
            Thread t = new Thread(ThreadProc);
            t.Name = "Thread_" + i;
            t.Start();
        }
        // Wait for all threads to signal.
        countdown.Wait();
        Console.Write("Press enter to release threads.");
        Console.ReadLine();
        Console.WriteLine("Releasing threads.");
        DateTime startTime = DateTime.Now;
        countdown = new CountdownEvent(numThreads);
        // Release all the threads.
        mre.Set();
        // Wait for all the threads to finish.
        countdown.Wait();
        TimeSpan ts = DateTime.Now - startTime;
        Console.WriteLine("Total time to run threads: {0}.{1:0}s.",
            ts.Seconds, ts.Milliseconds / 100);
    }

    private static void ThreadProc()
    {
        Service1Client client = new Service1Client();
        client.Open();
        // Signal that this thread is ready.
        countdown.Signal();
        // Wait for all the other threads before making service call.
        mre.WaitOne();
        client.GetData(1337);
        // Signal that this thread is finished.
        countdown.Signal();
        client.Close();
    }
}

The code above uses a combination of a ManualResetEvent and a CountdownEvent to coordinate the calls to all happen at the same time. It then waits for all the calls to finish and determines how long it took. When I run this on a dual core machine, I get the following:

Press enter to start test.

Starting 100 threads.
Releasing threads.
Total time to run threads: 14.0s.
Allow a few seconds for threads to die.
Press enter to run again.

If each individual request only sleeps for 2 seconds, why would it take 100 simultaneous requests 14 seconds to complete? It should only take 2 seconds if they're all executing at the same time. To understand what's happening, let's look at the thread count in perfmon. First, open Administrative Tools -> Performance Monitor. In the tree view on the left, pick Monitoring Tools -> Performance Monitor. It should have the % Processor counter in there by default. We don't need that counter so select it in the bottom and press the delete key. Now click the add button to add a new counter:

In the Add Counters dialog, expand the Process node:

Under this locate the Thread Count counter and then find the w3wp instance and press the Add >> button.

If you don't see the w3wp instance, it is most likely because it wasn't running when you opened the Add Counters dialog. To correct this, close the dialog, ping the Service1.svc service, and then click the Add button again in perfmon.

Now you can run the test and you should see results similar to the following:

In this test, I had pinged the service to get the metadata to warm everything up. When the test ran, you can see it took several seconds to add another 21 threads. The reason these threads are added is because when WCF runs your service code, it uses a thread from the IO thread pool. Your service code is then expected to do some work that is either quick or CPU intensive or takes up a database connection. But in the case of the test, the Thread.Sleep means that no work is being done and the thread is being held. A real world scenario where this pattern could occur is if you have a WCF middle tier that has to make calls into lower layers and then return the results.

For the most part, server load is assumed to change slowly. This means you would have a fairly constant load and the thread pool manager would pick the appropriate size for the thread pool to keep the CPU load high but without too much context switching. However, in the case of a sudden burst of requests with long-running, non-CPU-intensive work like this, the thread pool adapts too slowly. You can see in the graph above that the number of threads drops back down to 30 after some time. The thread pool has recognized that a thread has not been used for 15 seconds and therefore kills it because it is not needed.

To understand the thread pool a bit more, you can profile this and see what's happening. To get a profile, go to the Performance Explorer, usually pinned on the left side in Visual Studio, and click the button to create a new performance session:

Right click on the new performance session and select properties. In the properties window change the profiling type to Concurrency and uncheck the "Collect resource contention data" option.

Before we start profiling, let's first go to the Tools->Options menu in Visual Studio. Under Debugging, enable the Microsoft public symbol server.

Also, turn off the Just My Code option under Performance Tools:

The next step is to make the test client the startup project. You may need to ping the Service1.svc service again to make sure the w3wp process is running. Now, attach to the w3wp process with the profiler. There is an attach button at the top of the performance explorer window or you can right click on the performance session and choose attach.

Give the profiler a few seconds to warmup and then hit ctrl+F5 to execute the test client. After the test client finishes a single run pause and detach the profiler from the w3wp process. You can also hit the "Stop profiling" option but it will kill the process.

After you've finished profiling, it will take some time to process the data. Once it's up, switch to the thread view. In the figure below, I've rearranged the threads to make it easier to see the relationships:

Blue represents sleep time. This matches what we expect to see, which is a lot of new threads all sleeping for 2 seconds. At the top of the sleeping threads is the gate thread. It checks every 500ms to see if the number of threads in the thread pool is appropriate to handle the outstanding work. If not, it creates a new thread. You can see in the beginning that it creates 2 threads and then 1 thread at a time in 500ms increments. This is why it takes 14 seconds to process all 100 requests. So why are there two threads that look like they're created at the same time? If you look more closely, that's actually not the case. Let's zoom in on that part:

Here again the highlighted thread is the gate thread. Before it finishes its 500ms sleep, a new thread is created to handle one of the WCF service calls which sleeps for 2 seconds. Then when the gate thread does its check, it realizes that there is a lot of work currently backed up and creates another new thread. On a dual core machine like this, the default minimum IO thread pool setting is 2: 1 per core. One of those threads is always taken up by WCF and functions as the timer thread. You can see that there are other threads created up top. This is most likely ASP.Net creating some worker threads to handle the incoming requests. You can see that they don't sleep because they're passing off work to WCF and getting ready to handle the next batch of work.

The most obvious thing to do then would be to increase the minimum number of IO threads. You can do this in two ways: use ThreadPool.SetMinThreads or use the <processModel> tag in the machine.config. Here is how to do the latter:

<system.web>
  <!--<processModel autoConfig="true"/>-->
  <processModel 
    autoConfig="false" 
    minIoThreads="101" 
    minWorkerThreads="2" 
    maxIoThreads="200" 
    maxWorkerThreads="40" 
    />

Be sure to turn off the autoConfig setting or the other options will be ignored. If we run this test again, we get a much better result. Compare the previous snapshot of permon with this one:

And the resulting output of the run is:

Starting 100 threads.
Press enter to release threads.
Releasing threads.
Total time to run threads: 2.2s.
Allow a few seconds for threads to die.
Press enter to run again.

This is an excellent result. It is exactly what you would want to happen if a sudden burst of work comes in. But customers were saying that this wasn't happening for them. David Lamb told me that if you run this for a long time, like 2 hours, it would eventually stop quickly adding threads and behave as if the min IO threads was not set.

One of the things we can do is modify the test code to give enough time for the threads to have their 15 second timeout and just take out all the Console.ReadLine calls:

using System;
using System.Threading;
using ServiceReference1;

class Program
{
    private const int numThreads = 100;
    private static CountdownEvent countdown;
    private static ManualResetEvent mre = new ManualResetEvent(false);

    static void Main(string[] args)
    {
        while (true)
        {
            RunTest();
            Thread.Sleep(TimeSpan.FromSeconds(25));
            Console.WriteLine();
        }
    }

    static void RunTest()
    {
        mre.Reset();
        Console.WriteLine("Starting {0} threads.", numThreads);
        countdown = new CountdownEvent(numThreads);
        for (int i = 0; i < numThreads; i++)
        {
            Thread t = new Thread(ThreadProc);
            t.Name = "Thread_" + i;
            t.Start();
        }
        // Wait for all threads to signal.
        countdown.Wait();
        Console.WriteLine("Releasing threads.");
        DateTime startTime = DateTime.Now;
        countdown = new CountdownEvent(numThreads);
        // Release all the threads.
        mre.Set();
        // Wait for all the threads to finish.
        countdown.Wait();
        TimeSpan ts = DateTime.Now - startTime;
        Console.WriteLine("Total time to run threads: {0}.{1:0}s.",
            ts.Seconds, ts.Milliseconds / 100);
    }

    private static void ThreadProc()
    {
        Service1Client client = new Service1Client();
        client.Open();
        // Signal that this thread is ready.
        countdown.Signal();
        // Wait for all the other threads before making service call.
        mre.WaitOne();
        client.GetData(1337);
        // Signal that this thread is finished.
        countdown.Signal();
        client.Close();
    }
}

Then just let it run for a couple hours and see what happens. Luckily, it doesn't take 2 hours and we can reproduce the weird behavior pretty quickly. Here is a perfmon graph showing several runs:

You can see that the first two bursts had quick scale up with the thread count. After that, it went back to being slow. After working with the CLR team, they determined that there is a bug in the IO thread pool. This bug causes the internal count of IO threads to get out-of-sync with reality. Some of you may be asking the question as to what min really means in terms of the thread pool. Because if you specify you want a minimum of 100 threads, why wouldn't there just always be 100 threads? For the purposes of the thread pool, the min is supposed to be the threshold that the pool can scale up to before it starts to be metered. The default working set cost for one thread is a half MB. So that is one reason to keep the thread count down.

Some customers have found that Juval Lowy's thread pool doesn't have the same problem and handles these bursts of work much better. Here is a link to his article: http://msdn.microsoft.com/en-us/magazine/cc163321.aspx

Notice that Juval has created a custom thread pool and relies on the SynchronizationContext to switch from the IO thread that WCF uses to the custom thread pool. Using a custom thread pool in your production environment is not advisable. Most developers do not have the resources to properly test a custom thread pool for their applications. Thankfully, there is an alternative and that is the recommendation made in the KB article. The alternative is to use the worker thread pool. Juval has some code for a custom attribute that you can put on your service to set the SynchronizationContext to use his custom thread pool and we can just modify that to put the work into the worker thread pool. The code for this change is all in the KB article, but I'll reiterate here along with with the changes to the service itself.

using System;
using System.Threading;
using System.ServiceModel.Description;
using System.ServiceModel.Channels;
using System.ServiceModel.Dispatcher;

[WorkerThreadPoolBehavior]
public class Service1 : IService1
{
    public string GetData(int value)
    {
        Thread.Sleep(TimeSpan.FromSeconds(2));
        return string.Format("You entered: {0}", value);
    }
}

public class WorkerThreadPoolSynchronizer : SynchronizationContext
{
    public override void Post(SendOrPostCallback d, object state)
    {
        // WCF almost always uses Post
        ThreadPool.QueueUserWorkItem(new WaitCallback(d), state);
    }

    public override void Send(SendOrPostCallback d, object state)
    {
        // Only the peer channel in WCF uses Send
        d(state);
    }
}

[AttributeUsage(AttributeTargets.Class)]
public class WorkerThreadPoolBehaviorAttribute : Attribute, IContractBehavior
{
    private static WorkerThreadPoolSynchronizer synchronizer = new WorkerThreadPoolSynchronizer();

    void IContractBehavior.AddBindingParameters(
        ContractDescription contractDescription,
        ServiceEndpoint endpoint,
        BindingParameterCollection bindingParameters)
    {
    }

    void IContractBehavior.ApplyClientBehavior(
        ContractDescription contractDescription,
        ServiceEndpoint endpoint,
        ClientRuntime clientRuntime)
    {
    }

    void IContractBehavior.ApplyDispatchBehavior(
        ContractDescription contractDescription,
        ServiceEndpoint endpoint,
        DispatchRuntime dispatchRuntime)
    {
        dispatchRuntime.SynchronizationContext = synchronizer;
    }

    void IContractBehavior.Validate(
        ContractDescription contractDescription,
        ServiceEndpoint endpoint)
    {
    }
}

The areas highlighted above show the most important bits for this change. There really isn't that much code to this. With this change essentially what is happening is that WCF recognizes that when it's time to execute the service code, there is an ambient SynchronizationContext. That context then pushes the work into the worker thread pool with QueueUserWorkItem. The only other change to make is to the <processModel> node in the machine.config to configure the worker thread pool for a higher min and max.

<system.web>
  <!--<processModel autoConfig="true"/>-->
  <processModel 
    autoConfig="false" 
    minWorkerThreads="100" 
    maxWorkerThreads="200" 
    />

Running the test again, you will see a much better result:

All of the test runs finished in under 2.5 seconds.

We cannot make a recommendation on this alone though. There are other questions like how does this affect performance and does it continue to work this way for hours, days, weeks, etc. Our testing showed that for at least 72 hours, this worked without a problem. The performance runs showed some caveats though. These are also pointed out in the KB article. There is a cost for switching from one thread to another. This would be the same with the worker thread pool or a custom thread pool. That overhead can be negligible for large amounts of work. In the case that applies here with 2 seconds of blocking work, the context switch is definitely not a factor. But if you've got small messages and fast work, then it's likely to hurt your performance.

The test project is included with this post.

Originally posted on Dustin Metzgar's blog

WCF Extensibility – Message Formatters

CarlosFigueira — Tue, 03 May 2011 17:38:00 GMT

This post is part of a series about WCF extensibility points. For a list of all previous posts and planned future ones, go to the index page.

Message formatters are the component which do the translation between CLR operations and the WCF Message object – their role is to convert all the operation parameters and return values (possibly via serialization) into a Message on output, and deconstruct the message into parameter and return values on input. Anytime a new format is to be used (be it a new serialization format for currently supported CLR types, or supporting a new CLR type altogether), a message formatter is the interface you’d implement to enable this scenario. For example, even though the type System.IO.Stream is not serializable (it’s even abstract), WCF allows it to be used as the input or return values for methods (for example, in the WCF REST Raw programming model) and a formatter deals with converting it into messages. Like the message inspectors, there are two versions, one for the server side (IDispatchMessageFormatter), and one for the client side (IClientMessageFormatter).

Among the extensibility points listed in this series, the message formatters are the first kind to be required in the WCF pipeline – a service does not need to have any service / endpoint / contract / operation behavior, nor any message / parameter inspector. If the user doesn’t add any of those, the client / service will just work (some behaviors are automatically added to the operations when one adds an endpoint, but that’s an implementation detail for WCF – they aren’t strictly necessary). Formatters, on the other hand, are required (to bridge the gap between the message world and the operations using CLR types). If we don’t add any behaviors to the service / endpoint / contract / operation that sets a formatter, WCF will add one formatter to the operation (usually via the DataContractSerializerOperationBehavior, which is added by default in all operation contracts).

Public implementations in WCF

None. As with most of the runtime extensibility points, there are no public implementations of either the dispatch or the client message formatter. There are a lot of internal implementations, though, such as a formatter which converts operation parameters into a message (both using the DataContractSerializer and the XmlSerializer), formatters which map parameters to the HTTP URI (used in REST operations with UriTemplate), among others.

Interface declaration

 public interface IDispatchMessageFormatter
{
    void DeserializeRequest(Message message, object[] parameters);
    Message SerializeReply(MessageVersion messageVersion, object[] parameters, object result);
}
 
public interface IClientMessageFormatter
{
    Message SerializeRequest(MessageVersion messageVersion, object[] parameters);
    object DeserializeReply(Message message, object[] parameters);
}
 

The formatter interfaces each have two methods, one to convert between input outgoing CLR objects into the Message object (serialize), and one to take the incoming message object apart and break it down into incoming CLR objects (deserialize).

At the server side, after the the message was decoded, passed through the channel stack and other extensibility points and is about to be dispatched to the service operation, the method DeserializeRequest is called to deserialize the message object into an array of parameters to be passed to the operation. The object argument “parameters” will have been allocated, so the implementation of the formatter only needs to read the message and set the operation parameters in their correct order in the array passed to it. After the operation is invoked (and any parameter inspector has a chance to change the operation outputs), SerializeReply is called, to take the operation return, plus the final value of any out/ref parameters which the operation may have, and package them into a Message object to be sent down the WCF channel stack.

At the client side the mirror happens: when the operation is called (and after the parameter inspector has a chance to change the inputs), SerializeRequest is called to package all the input parameters into the outgoing message object. After the message is sent to the server and the response is decoded by the client’s encoder, DeserializeReply is called to open the message object and populate the return value and any possible out/ref parameters.

One small parenthesis about out/ref parameters: all parameters in WCF calls are passed by value – a copy of the value is sent across the wire. If an operation declares a parameter with a ref modifier (ByRef in Visual Basic), the service will receive a copy (i.e., by value) of that parameter, and then return another copy of the value of the parameter at the end of the method. This second copy will be deserialized at the client into a new instance of that type. So even if you pass an instance of your type by reference to a WCF service, and the service doesn’t change it at all, the value at the end of the call at the client side the reference will point to a different object.

 [ServiceContract]
public interface ITest
{
    [OperationContract]
    void UpdatePerson(ref Person person);
    [OperationContract]
    void InOutRef(int x, ref int y, out int z, out int w);
}
public class Client
{
    public static void Main()
    {
        ChannelFactory<ITest> factory = new ChannelFactory<ITest>();
        ITest proxy = factory.CreateChannel();
        Person p1 = new Person();
        Person p2 = p1;
        Console.WriteLine(object.ReferenceEquals(p1, p2)); // true
        proxy.UpdatePerson(ref p2);
        Console.WriteLine(object.ReferenceEquals(p1, p2)); // false, even if service doesn't change reference
    }
}
 

Going back to the formatters, the list of “input” parameters (those in the *Request) operations are either the input (ByVal) parameters or reference (ByRef without <Out>). The list of “output” parameters are ones marked with ref (ByRef) and out (<Out> ByRef). In the operation InOutRef above, the parameters x and y are considered to be input parameters, so the parameters array in the *Request operations will have two objects). The parameters y, z and w are considered to be output parameters, so the parameters array in the *Reply operations will have three elements.

How to add message formatters

At the server side: the formatter is a property of the operation runtime, so at the server side it’s available at the DispatchOperation object. This object is typically accessed via an operation behavior, or by traversing the operation list from an endpoint behavior. both in the ApplyDispatchBehavior method. Another way is if you’re creating a REST endpoints (i.e., one with a behavior which inherits from WebHttpBehavior). WebHttpBehavior exposes two protected methods, GetRequestDispatchFormatter and GetReplyDispatchFormatter, which can be overridden to to return the formatter to be used by the operation.

 public class MyDispatchMessageFormatter : IDispatchMessageFormatter
{
    OperationDescription operation;
    public MyDispatchMessageFormatter(OperationDescription operation) { ... }
}
public class MyRestBehavior : WebHttpBehavior
{
    protected override IDispatchMessageFormatter GetReplyDispatchFormatter(OperationDescription operationDescription, ServiceEndpoint endpoint)
    {
        return new MyDispatchMessageFormatter(operationDescription);
    }
}
 

At the client side: Similarly, the operation formatter at the client side is available at the ClientOperation object, typically accessed via an operation or endpoint behavior. And for behaviors inheriting from WebHttpBehavior, there are two protected methods, GetRequestClientFormatter and GetReplyClientFormatter, which can be used to return the operation formatter as well.

 public class MyClientFormatter : IClientMessageFormatter
{
}
public class MyOperationBehavior : IOperationBehavior
{
    public void ApplyClientBehavior(OperationDescription operationDescription, ClientOperation clientOperation)
    {
        clientOperation.Formatter = new MyClientFormatter();
    }
}
 

A quick note about wrapping the default WCF formatter. As I mentioned before, the default formatter is usually added by the DataContractSerializerOperationBehavior when it’s executed. If we want to use that default formatter, and wrap it in our own formatter, we need to make sure that the DataContractSerializerOperationBehavior is a position in the operation behavior list which is executed before our own operation behavior is. Take this seemingly problem-free example:

 [ServiceContract]
public interface ITest
{
    [OperationContract]
    [MyOperationBehavior]
    int Add(int x, int y);
}
public class Service : ITest
{
    public int Add(int x, int y) { return x + y; }
}
public class MyClientFormatter : IClientMessageFormatter
{
    IClientMessageFormatter inner;
    public MyClientFormatter(IClientMessageFormatter inner)
    {
        if (inner == null) throw new ArgumentNullException("inner");
        this.inner = inner;
    }
 
    public object DeserializeReply(Message message, object[] parameters)
    {
        return this.inner.DeserializeReply(message, parameters);
    }
 
    public Message SerializeRequest(MessageVersion messageVersion, object[] parameters)
    {
        return this.inner.SerializeRequest(messageVersion, parameters);
    }
}
public class MyOperationBehaviorAttribute : Attribute, IOperationBehavior
{
    public void AddBindingParameters(OperationDescription operationDescription, BindingParameterCollection bindingParameters)
    {
    }
 
    public void ApplyClientBehavior(OperationDescription operationDescription, ClientOperation clientOperation)
    {
        clientOperation.Formatter = new MyClientFormatter(clientOperation.Formatter);
    }
 
    public void ApplyDispatchBehavior(OperationDescription operationDescription, DispatchOperation dispatchOperation)
    {
    }
 
    public void Validate(OperationDescription operationDescription)
    {
    }
}
 
class Program
{
    static void Main(string[] args)
    {
        string baseAddress = "http://" + Environment.MachineName + ":8000/Service";
        ServiceHost host = new ServiceHost(typeof(Service), new Uri(baseAddress));
        host.AddServiceEndpoint(typeof(ITest), new BasicHttpBinding(), "");
        host.Open();
 
        ChannelFactory<ITest> factory = new ChannelFactory<ITest>(new BasicHttpBinding(), new EndpointAddress(baseAddress));
        foreach (var opBehavior in factory.Endpoint.Contract.Operations[0].Behaviors)
        {
            Console.WriteLine(opBehavior);
        }
 
        ITest proxy = factory.CreateChannel();
        Console.WriteLine(proxy.Add(3, 4));
    }
}
 

The call to CreateChannel in the channel factory will fail – the constructor of MyClientFormatter will throw. That’s because the order of the operation behaviors (printed in the code) is the following:

System.ServiceModel.Dispatcher.OperationInvokerBehavior
MyOperationBehaviorAttribute
System.ServiceModel.OperationBehaviorAttribute
System.ServiceModel.Description.DataContractSerializerOperationBehavior
System.ServiceModel.Description.DataContractSerializerOperationGenerator

I have no idea why attribute-based operation behaviors are added in this position, but the fact is that this doesn’t work. So for this scenario we cannot use attribute-based behaviors, we need to add it “manually”, as shown below.

 [ServiceContract]
public interface ITest
{
    [OperationContract]
    //[MyOperationBehavior]
    int Add(int x, int y);
}
 
class Program
{
    static void Main(string[] args)
    {
        string baseAddress = "http://" + Environment.MachineName + ":8000/Service";
        ServiceHost host = new ServiceHost(typeof(Service), new Uri(baseAddress));
        ServiceEndpoint endpoint = host.AddServiceEndpoint(typeof(ITest), new BasicHttpBinding(), "");
        endpoint.Contract.Operations.Find("Add").Behaviors.Add(new MyOperationBehaviorAttribute());
        host.Open();
 
        ChannelFactory<ITest> factory = new ChannelFactory<ITest>(new BasicHttpBinding(), new EndpointAddress(baseAddress));
        ITest proxy = factory.CreateChannel();
        Console.WriteLine(proxy.Add(3, 4));
    }
}
 

After doing that, the code runs and works fine.

Real world scenario: supporting different data and serialization formats

The first version of WCF (.NET Framework 3.0) supported essentially SOAP endpoints – an XML payload following some rules defined in the SOAP specification (you actually could do POX/REST, but it was awfully hard). On the next version (.NET Framework 3.5), the REST programming model was added and that started supporting a whole new set of formats, mostly notably POX (plain-old XML, no SOAP involved), JSON (based on the DataContractJsonSerializer) and a special “raw” mode, where one could declare a single Stream parameter in an operation for receiving arbitrary data, or returning a Stream value for returning arbitrary data. The raw mode can be used to support essentially all data and serialization formats, but that comes at a price that the operation itself has to deal with serializing / deserializing the parameters. Also, there are scenarios (from the forums) where the user needs to expose the same operation in non-REST endpoints (or even non-HTTP, as in the scenario described in the forum post), where the Stream trick won’t work. This example will expand on the answer to the forum question and provide formatters which will use a custom serializer (in this case, the JSON.NET one, available from codeplex at http://json.codeplex.com).

And the usual disclaimer: this is a sample for illustrating the topic of this post, this is not production-ready code. I tested it for a few contracts and it worked, but I cannot guarantee that it will work for all scenarios (please let me know if you find a bug or something missing). Also, for simplicity sake it doesn’t have a lot of error handling which a production-level code would, and it isn’t fully integrated with the WCF REST pipeline (i.e., it doesn’t support UriTemplates, it doesn’t integrate with the REST help page, doesn’t support out/ref parameters,, etc.).

First, some data contracts to set up the scenario. The service will process people and their pets. The data contracts are decorated both with WCF serialization attributes (DataContract, DataMember), and with the JSON.NET serialization attributes (JsonObejct, JsonProperty, JsonConverter) so that it can be mapped according to both formats.

 [DataContract]
[Newtonsoft.Json.JsonObject(MemberSerialization = Newtonsoft.Json.MemberSerialization.OptIn)]
public class Person
{
    [DataMember(Order = 1), Newtonsoft.Json.JsonProperty]
    public string FirstName;
    [DataMember(Order = 2), Newtonsoft.Json.JsonProperty]
    public string LastName;
    [DataMember(Order = 3),
        Newtonsoft.Json.JsonProperty,
        Newtonsoft.Json.JsonConverter(typeof(Newtonsoft.Json.Converters.IsoDateTimeConverter))]
    public DateTime BirthDate;
    [DataMember(Order = 4), Newtonsoft.Json.JsonProperty]
    public List<Pet> Pets;
    [DataMember(Order = 5), Newtonsoft.Json.JsonProperty]
    public int Id;
}
 
[DataContract, Newtonsoft.Json.JsonObject(MemberSerialization = Newtonsoft.Json.MemberSerialization.OptIn)]
public class Pet
{
    [DataMember(Order = 1), Newtonsoft.Json.JsonProperty]
    public string Name;
    [DataMember(Order = 2), Newtonsoft.Json.JsonProperty]
    public string Color;
    [DataMember(Order = 3), Newtonsoft.Json.JsonProperty]
    public string Markings;
    [DataMember(Order = 4), Newtonsoft.Json.JsonProperty]
    public int Id;
}
 

Next the interface definition, and the service implementation. It’s not very interesting, but I added operations using both GET and POST methods, and operations with single and multiple parameters (the goal of this sample is to demonstrate the formatter, not a specific service, so I think I can slack off on the service example a little ).

 [ServiceContract]
public interface ITestService
{
    [WebGet, OperationContract]
    Person GetPerson();
    [WebInvoke, OperationContract]
    Pet EchoPet(Pet pet);
    [WebInvoke(BodyStyle = WebMessageBodyStyle.WrappedRequest), OperationContract]
    int Add(int x, int y);
}
 
public class Service : ITestService
{
    public Person GetPerson()
    {
        return new Person
        {
            FirstName = "First",
            LastName = "Last",
            BirthDate = new DateTime(1993, 4, 17, 2, 51, 37, 47, DateTimeKind.Local),
            Id = 0,
            Pets = new List<Pet>
            {
                new Pet { Name= "Generic Pet 1", Color = "Beige", Id = 0, Markings = "Some markings" },
                new Pet { Name= "Generic Pet 2", Color = "Gold", Id = 0, Markings = "Other markings" },
            },
        };
    }
 
    public Pet EchoPet(Pet pet)
    {
        return pet;
    }
 
    public int Add(int x, int y)
    {
        return x + y;
    }
}
 

Now the behavior which will set everything together. Since this is a REST endpoint, instead of writing a new endpoint, I’ll simply inherit from WebHttpBehavior, and override the protected methods to return the client and server formatters. Notice that in some cases when there are no parameters or for GET requests (where the parameters are in the query string, not in the request body), so in those cases I’ll simply reuse the default formatter from the base class. Another logic which is implemented at the behavior is validation – we know what our formatter doesn’t support, so we’ll simply throw while the service (or the client channel) is being opened, giving the user a clear message explaining why the behavior failed the validation (some of the validation code is not in the snippet below, but it can be found in the source code for this post).

 public class NewtonsoftJsonBehavior : WebHttpBehavior
{
    public override void Validate(ServiceEndpoint endpoint)
    {
        base.Validate(endpoint);
 
        BindingElementCollection elements = endpoint.Binding.CreateBindingElements();
        WebMessageEncodingBindingElement webEncoder = elements.Find<WebMessageEncodingBindingElement>();
        if (webEncoder == null)
        {
            throw new InvalidOperationException("This behavior must be used in an endpoint with the WebHttpBinding (or a custom binding with the WebMessageEncodingBindingElement).");
        }
 
        foreach (OperationDescription operation in endpoint.Contract.Operations)
        {
            this.ValidateOperation(operation);
        }
    }
 
    protected override IDispatchMessageFormatter GetRequestDispatchFormatter(OperationDescription operationDescription, ServiceEndpoint endpoint)
    {
        if (this.IsGetOperation(operationDescription))
        {
            // no change for GET operations
            return base.GetRequestDispatchFormatter(operationDescription, endpoint);
        }
 
        if (operationDescription.Messages[0].Body.Parts.Count == 0)
        {
            // nothing in the body, still use the default
            return base.GetRequestDispatchFormatter(operationDescription, endpoint);
        }
 
        return new NewtonsoftJsonDispatchFormatter(operationDescription, true);
    }
 
    protected override IDispatchMessageFormatter GetReplyDispatchFormatter(OperationDescription operationDescription, ServiceEndpoint endpoint)
    {
        if (operationDescription.Messages.Count == 1 || operationDescription.Messages[1].Body.ReturnValue.Type == typeof(void))
        {
            return base.GetReplyDispatchFormatter(operationDescription, endpoint);
        }
        else
        {
            return new NewtonsoftJsonDispatchFormatter(operationDescription, false);
        }
    }
 
    protected override IClientMessageFormatter GetRequestClientFormatter(OperationDescription operationDescription, ServiceEndpoint endpoint)
    {
        if (operationDescription.Behaviors.Find<WebGetAttribute>() != null)
        {
            // no change for GET operations
            return base.GetRequestClientFormatter(operationDescription, endpoint);
        }
        else
        {
            WebInvokeAttribute wia = operationDescription.Behaviors.Find<WebInvokeAttribute>();
            if (wia != null)
            {
                if (wia.Method == "HEAD")
                {
                    // essentially a GET operation
                    return base.GetRequestClientFormatter(operationDescription, endpoint);
                }
            }
        }
 
        if (operationDescription.Messages[0].Body.Parts.Count == 0)
        {
            // nothing in the body, still use the default
            return base.GetRequestClientFormatter(operationDescription, endpoint);
        }
 
        return new NewtonsoftJsonClientFormatter(operationDescription, endpoint);
    }
 
    protected override IClientMessageFormatter GetReplyClientFormatter(OperationDescription operationDescription, ServiceEndpoint endpoint)
    {
        if (operationDescription.Messages.Count == 1 || operationDescription.Messages[1].Body.ReturnValue.Type == typeof(void))
        {
            return base.GetReplyClientFormatter(operationDescription, endpoint);
        }
        else
        {
            return new NewtonsoftJsonClientFormatter(operationDescription, endpoint);
        }
    }
}
 

On to the formatters. I’ll start with the dispatch formatter. As the new formatter was only added for POST operations with at least one parameter, we can safely assume that the messages will not be empty, and the request will be stored in the message body. But the message body is always represented in XML, so in order to support a custom format, we need to either define a mapping between that format and XML (which is what was done internally for supporting JSON in 3.5) – and implement XML readers and writers to support this mapping – or reuse one of the existing formats for which we already have a mapping for. And as in the raw programming model, the raw format (described in the post about message inspectors) is a great candidate for it – we can get the raw bytes from the request (and write raw bytes in the response) and parse them using our custom format. We must ensure, however, that the incoming message actually was read with the raw encoder (by default messages with JSON content type are read with the JSON encoder, we need a custom content type mapper to ensure that they are read as raw messages).

 class NewtonsoftJsonDispatchFormatter : IDispatchMessageFormatter
{
    OperationDescription operation;
    Dictionary<string, int> parameterNames;
    public NewtonsoftJsonDispatchFormatter(OperationDescription operation, bool isRequest)
    {
        this.operation = operation;
        if (isRequest)
        {
            int operationParameterCount = operation.Messages[0].Body.Parts.Count;
            if (operationParameterCount > 1)
            {
                this.parameterNames = new Dictionary<string, int>();
                for (int i = 0; i < operationParameterCount; i++)
                {
                    this.parameterNames.Add(operation.Messages[0].Body.Parts[i].Name, i);
                }
            }
        }
    }
 
    public void DeserializeRequest(Message message, object[] parameters)
    {
        object bodyFormatProperty;
        if (!message.Properties.TryGetValue(WebBodyFormatMessageProperty.Name, out bodyFormatProperty) ||
            (bodyFormatProperty as WebBodyFormatMessageProperty).Format != WebContentFormat.Raw)
        {
            throw new InvalidOperationException("Incoming messages must have a body format of Raw. Is a ContentTypeMapper set on the WebHttpBinding?");
        }
 
        XmlDictionaryReader bodyReader = message.GetReaderAtBodyContents();
        bodyReader.ReadStartElement("Binary");
        byte[] rawBody = bodyReader.ReadContentAsBase64();
        MemoryStream ms = new MemoryStream(rawBody);
 
        StreamReader sr = new StreamReader(ms);
        Newtonsoft.Json.JsonSerializer serializer = new Newtonsoft.Json.JsonSerializer();
        if (parameters.Length == 1)
        {
            // single parameter, assuming bare
            parameters[0] = serializer.Deserialize(sr, operation.Messages[0].Body.Parts[0].Type);
        }
        else
        {
            // multiple parameter, needs to be wrapped
            Newtonsoft.Json.JsonReader reader = new Newtonsoft.Json.JsonTextReader(sr);
            reader.Read();
            if (reader.TokenType != Newtonsoft.Json.JsonToken.StartObject)
            {
                throw new InvalidOperationException("Input needs to be wrapped in an object");
            }
 
            reader.Read();
            while (reader.TokenType == Newtonsoft.Json.JsonToken.PropertyName)
            {
                string parameterName = reader.Value as string;
                reader.Read();
                if (this.parameterNames.ContainsKey(parameterName))
                {
                    int parameterIndex = this.parameterNames[parameterName];
                    parameters[parameterIndex] = serializer.Deserialize(reader, this.operation.Messages[0].Body.Parts[parameterIndex].Type);
                }
                else
                {
                    reader.Skip();
                }
 
                reader.Read();
            }
 
            reader.Close();
        }
 
        sr.Close();
        ms.Close();
    }
 
    public Message SerializeReply(MessageVersion messageVersion, object[] parameters, object result)
    {
        byte[] body;
        Newtonsoft.Json.JsonSerializer serializer = new Newtonsoft.Json.JsonSerializer();
        using (MemoryStream ms = new MemoryStream())
        {
            using (StreamWriter sw = new StreamWriter(ms, Encoding.UTF8))
            {
                using (Newtonsoft.Json.JsonWriter writer = new Newtonsoft.Json.JsonTextWriter(sw))
                {
                    writer.Formatting = Newtonsoft.Json.Formatting.Indented;
                    serializer.Serialize(writer, result);
                    sw.Flush();
                    body = ms.ToArray();
                }
            }
        }
 
        Message replyMessage = Message.CreateMessage(messageVersion, operation.Messages[1].Action, new RawBodyWriter(body));
        replyMessage.Properties.Add(WebBodyFormatMessageProperty.Name, new WebBodyFormatMessageProperty(WebContentFormat.Raw));
        HttpResponseMessageProperty respProp = new HttpResponseMessageProperty();
        respProp.Headers[HttpResponseHeader.ContentType] = "application/json";
        replyMessage.Properties.Add(HttpResponseMessageProperty.Name, respProp);
        return replyMessage;
    }
}
 

When the formatter is serializing the reply of the message , it will create a new message using a “raw” body writer, which is a simple implementation of the BodyWriter class. It will then set the body format property to ensure that the raw encoder will be used when converting that message into bytes on the wire.

 class RawBodyWriter : BodyWriter
{
    byte[] content;
    public RawBodyWriter(byte[] content)
        : base(true)
    {
        this.content = content;
    }
 
    protected override void OnWriteBodyContents(XmlDictionaryWriter writer)
    {
        writer.WriteStartElement("Binary");
        writer.WriteBase64(content, 0, content.Length);
        writer.WriteEndElement();
    }
}
 

The client formatter is similar to the service one. On reply, since it doesn’t support multiple return values (no out/ref support implemented), it simply gets the bytes from the message and feeds them to the JSON.NET deserializer. When serializing the request, the formatter will either simply serialize a single parameter if it’s the only one, or it will wrap it in a JSON object with properties named by the operation parameter name. The last thing it does on serialization is to again set the body format property (to ensure that the raw encoder will be used for that message) and also set the “To” header of the message (which is required for REST messages, since it uses manual addressing on the transport).

 class NewtonsoftJsonClientFormatter : IClientMessageFormatter
{
    OperationDescription operation;
    Uri operationUri;
    public NewtonsoftJsonClientFormatter(OperationDescription operation, ServiceEndpoint endpoint)
    {
        this.operation = operation;
        string endpointAddress = endpoint.Address.Uri.ToString();
        if (!endpointAddress.EndsWith("/"))
        {
            endpointAddress = endpointAddress + "/";
        }
 
        this.operationUri = new Uri(endpointAddress + operation.Name);
    }
 
    public object DeserializeReply(Message message, object[] parameters)
    {
        object bodyFormatProperty;
        if (!message.Properties.TryGetValue(WebBodyFormatMessageProperty.Name, out bodyFormatProperty) ||
            (bodyFormatProperty as WebBodyFormatMessageProperty).Format != WebContentFormat.Raw)
        {
            throw new InvalidOperationException("Incoming messages must have a body format of Raw. Is a ContentTypeMapper set on the WebHttpBinding?");
        }
 
        XmlDictionaryReader bodyReader = message.GetReaderAtBodyContents();
        Newtonsoft.Json.JsonSerializer serializer = new Newtonsoft.Json.JsonSerializer();
        bodyReader.ReadStartElement("Binary");
        byte[] body = bodyReader.ReadContentAsBase64();
        using (MemoryStream ms = new MemoryStream(body))
        {
            using (StreamReader sr = new StreamReader(ms))
            {
                Type returnType = this.operation.Messages[1].Body.ReturnValue.Type;
                return serializer.Deserialize(sr, returnType);
            }
        }
    }
 
    public Message SerializeRequest(MessageVersion messageVersion, object[] parameters)
    {
        byte[] body;
        Newtonsoft.Json.JsonSerializer serializer = new Newtonsoft.Json.JsonSerializer();
        using (MemoryStream ms = new MemoryStream())
        {
            using (StreamWriter sw = new StreamWriter(ms, Encoding.UTF8))
            {
                using (Newtonsoft.Json.JsonWriter writer = new Newtonsoft.Json.JsonTextWriter(sw))
                {
                    writer.Formatting = Newtonsoft.Json.Formatting.Indented;
                    if (parameters.Length == 1)
                    {
                        // Single parameter, assuming bare
                        serializer.Serialize(sw, parameters[0]);
                    }
                    else
                    {
                        writer.WriteStartObject();
                        for (int i = 0; i < this.operation.Messages[0].Body.Parts.Count; i++)
                        {
                            writer.WritePropertyName(this.operation.Messages[0].Body.Parts[i].Name);
                            serializer.Serialize(writer, parameters[0]);
                        }
 
                        writer.WriteEndObject();
                    }
 
                    writer.Flush();
                    sw.Flush();
                    body = ms.ToArray();
                }
            }
        }
 
        Message requestMessage = Message.CreateMessage(messageVersion, operation.Messages[0].Action, new RawBodyWriter(body));
        requestMessage.Headers.To = operationUri;
        requestMessage.Properties.Add(WebBodyFormatMessageProperty.Name, new WebBodyFormatMessageProperty(WebContentFormat.Raw));
        HttpRequestMessageProperty reqProp = new HttpRequestMessageProperty();
        reqProp.Headers[HttpRequestHeader.ContentType] = "application/json";
        requestMessage.Properties.Add(HttpRequestMessageProperty.Name, reqProp);
        return requestMessage;
    }
}
 

Now for testing the formatters. The first thing we need is the content type mapper, to ensure that all incoming requests will be read by the raw encoder. Its implementation is quite simple.

 class MyRawMapper : WebContentTypeMapper
{
    public override WebContentFormat GetMessageFormatForContentType(string contentType)
    {
        return WebContentFormat.Raw;
    }
}
 

Now for the test itself. I’m using a helper method (SendRequest) to send arbitrary HTTP requests to the server, but I’ll skip it here (it’s just setting up HttpWebRequest and displaying the results from HttpWebResponse). The test code sets up a service and adds two endpoints, one “normal” (SOAP) and one JSON.NET enabled

 static void Main(string[] args)
{
    string baseAddress = "http://" + Environment.MachineName + ":8000/Service";
    ServiceHost host = new ServiceHost(typeof(Service), new Uri(baseAddress));
    host.AddServiceEndpoint(typeof(ITestService), new BasicHttpBinding(), "soap");
    WebHttpBinding webBinding = new WebHttpBinding();
    webBinding.ContentTypeMapper = new MyRawMapper();
    host.AddServiceEndpoint(typeof(ITestService), webBinding, "json").Behaviors.Add(new NewtonsoftJsonBehavior());
    Console.WriteLine("Opening the host");
    host.Open();
 
    ChannelFactory<ITestService> factory = new ChannelFactory<ITestService>(new BasicHttpBinding(), new EndpointAddress(baseAddress + "/soap"));
    ITestService proxy = factory.CreateChannel();
    Console.WriteLine(proxy.GetPerson());
 
    SendRequest(baseAddress + "/json/GetPerson", "GET", null, null);
    SendRequest(baseAddress + "/json/EchoPet", "POST", "application/json", "{\"Name\":\"Fido\",\"Color\":\"Black and white\",\"Markings\":\"None\",\"Id\":1}");
    SendRequest(baseAddress + "/json/Add", "POST", "application/json", "{\"x\":111,\"z\":null,\"w\":[1,2],\"v\":{\"a\":1},\"y\":222}");
 
    Console.WriteLine("Now using the client formatter");
    ChannelFactory<ITestService> newFactory = new ChannelFactory<ITestService>(webBinding, new EndpointAddress(baseAddress + "/json"));
    newFactory.Endpoint.Behaviors.Add(new NewtonsoftJsonBehavior());
    ITestService newProxy = newFactory.CreateChannel();
    Console.WriteLine(newProxy.Add(444, 555));
    Console.WriteLine(newProxy.EchoPet(new Pet { Color = "gold", Id = 2, Markings = "Collie", Name = "Lassie" }));
    Console.WriteLine(newProxy.GetPerson());
 
    Console.WriteLine("Press ENTER to close");
    Console.ReadLine();
    host.Close();
    Console.WriteLine("Host closed");
}
 

And that’s it for the formatter example!

New WCF Web API

One note that I want to leave here is that it’s not too easy to integrate any new formats in the existing WCF REST pipeline. In the example above I had to deal with formatters, Message objects, take a dependency on a content type mapper, just to be able to use this different serializer. And even after all of this, it’s not completely integrated with the pipeline – UriTemplates aren’t supported, for example. In an upcoming release, however, the WCF team is working hard to make WCF really a great platform for hosting HTTP services, and that includes a new platform (built on top of the current one) for HTTP services specifically. In the new WCF Web API (you can preview the bits on the Codeplex site) implementing such a scenario is a lot simpler, and other features (such as UriTemplate) will just continue to work after the new formatter is plugged in. Glenn Block has posted a formatter that does exactly that on the thread http://wcf.codeplex.com/discussions/255873, you decide which one is easier :)

Coming up

Operation selectors.

[Code for this post]

[Back to the index]

Carlos Figueira
http://blogs.msdn.com/carlosfigueira
Twitter: @carlos_figueira http://twitter.com/carlos_figueira

How to detect if the .NET Framework Platform Update 1 is installed

Ron Jacobs — Fri, 29 Apr 2011 20:42:00 GMT

Humans

Go to Control Panel / Programs / Programs and Features / View Installed Updates

Use the Search Box to search the updates for

Or if you prefer, search the list your self

Microsoft .NET Framework 4 Platform Update 1 - Runtime Update

Look for .NET Framework 4 Extended
Look for Update for Microsoft .NET Framework 4 Extended (KB2478063)
Click on the Help Link to see what you get with this update

Microsoft .NET Framework 4 Platform Update 1 – Design-time Package for Visual Studio 2010 SP1 (KB2495593)

Look for Microsoft Visual Studio 2010 (<Your Edition) – (<Language>) (KB2495593)
Click on the Help Link to see what this update contains

Programs

Look in the registry for the following keys

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NET Framework\v4.0.30319\SKUs\

.NETFramework, Version=v4.0.1

.NETFramework, Version-v4.0.1, Profile=Client

Ron Jacobs
http://blogs.msdn.com/rjacobs
Twitter: @ronljacobs http://twitter.com/ronljacobs

WCF Extensibility – IParameterInspector

CarlosFigueira — Thu, 28 Apr 2011 15:05:53 GMT

This post is part of a series about WCF extensibility points. For a list of all previous posts and planned future ones, go to the index page.

The message inspectors, described in the previous post of this series, allows you complete control over the message going through the WCF stack. They’re very powerful, but you have to know how to deal with the Message object, which is not the most desirable way of programming. If the service model in WCF hides all the messaging framework by allowing us to define our services in terms of strongly-typed operations (i.e., using nice primitive and user defined types), there should be a way of intercepting requests / responses after all the processing to extract those parameters from incoming messages (or before they’re packaged in outgoing messages) is done. The IParameterInspector is exactly that – before and after each call, the inspector gets a chance to inspect the operation inputs, outputs and return value, in the same types as defined by the operation contract, no conversion needed (the only thing needed is a cast, since the parameters are passed as objects).

Public implementations in WCF

None. There aren’t also any internal implementations of this interface in WCF, this is really a user (as opposed to system) extensibility point.

Interface declaration

 public interface IParameterInspector
{
    void AfterCall(string operationName, object[] outputs, object returnValue, object correlationState);
    object BeforeCall(string operationName, object[] inputs);
}
 

Unlike the message inspector, the parameter inspector interface is the same for both client and server side. At the server side, right before the call is dispatched to the user code, BeforeCall is invoked, where the inspector can look at the inputs to the operation. When the operation returns, AfterCall is invoked to let the inspector look at the return value of the operation, and any out/ref parameters which the operation may have set. At the client side, right after the call on the proxy is made, and before it’s handed down to the WCF stack, BeforeCall is invoked to let the inspector look at the outgoing parameters before they’re packaged into a message object. Finally, when the call returns from the server and the result is about to be returned to the client (either by returning the synchronous invocation or in an asynchronous callback), AfterCall is called at the client side.

Like in the message inspector case, if the operation contract being called by the client is marked with IsOneWay=true, the call to AfterCall on a client inspector does not happen (it does happen at the server, though). And unlike the message inspector case, if an exception is thrown during the processing of the call (e.g., the server returned a fault), AfterCall will also not be called on the client – it makes sense, since there is no guarantees that the return value or any out/ref parameters have valid values at that point.

How to add parameter inspectors

At the server side: the list of parameter inspectors is available at the DispatchOperation object – each operation has its own list of parameter inspectors. It is typically accessed via an operation behavior in a call to ApplyDispatchBehavior:

 public class MyOperationBehavior : Attribute
{
    public void ApplyDispatchBehavior(OperationDescription operationDescription, DispatchOperation dispatchOperation)
    {
        dispatchOperation.ParameterInspectors.Add(new MyParameterInspector());
    }
}
 

At the client side: the list of client parameter inspectors is available at the ClientOperation object, and typically accessed via an operation behavior’s ApplyClientBehavior method..

 public class MyOperationBehavior : IOperationBehavior
{
    public void ApplyClientBehavior(OperationDescription operationDescription, ClientOperation clientOperation)
    {
        clientOperation.ParameterInspectors.Add(new MyParameterInspector());
    }
}
 

Real world scenario: simple profiler

One usage which I’ve seen a couple of times for the parameter inspector is to create a simple profiler / statistics page for WCF services. The parameter inspector interface methods are called really close to the actual method invocation (as can be seen in the example of the WCF Runtime post), both on the client and on the server, so they can fairly accurately record starting and ending times of arbitrary method calls. The example below is implemented as an endpoint behavior which adds the statistic collection logic for all the operations in the endpoint. In this example, we need to call a method on a class to show the statistics, but a more realistic scenario would save the profiling information in a file or database for further analysis.

And here comes the usual disclaimer: this is a sample for illustrating the topic of this post, this is not production-ready code. I tested it for a few contracts and it worked, but I cannot guarantee that it will work for all scenarios (please let me know if you find a bug or something missing). Also, for simplicity sake it doesn’t have a lot of error handling which a production-level code would. Also, as I mentioned before, the statistics are all stored in memory, a better profiler would save the profiling information in a file or database, and possibly even expose it as a service itself.

As with all of the runtime examples, it starts with a behavior. I’ll use an endpoint behavior here, but a contract (or even service) behavior would do.

 public class OperationProfilerEndpointBehavior : IEndpointBehavior
{
    private OperationProfilerManager manager;
    public OperationProfilerEndpointBehavior(OperationProfilerManager manager)
    {
        this.manager = manager;
    }
 
    public void AddBindingParameters(ServiceEndpoint endpoint, BindingParameterCollection bindingParameters)
    {
    }
 
    public void ApplyClientBehavior(ServiceEndpoint endpoint, ClientRuntime clientRuntime)
    {
        foreach (ClientOperation operation in clientRuntime.Operations)
        {
            operation.ParameterInspectors.Add(new OperationProfilerParameterInspector(this.manager, operation.IsOneWay));
        }
    }
 
    public void ApplyDispatchBehavior(ServiceEndpoint endpoint, EndpointDispatcher endpointDispatcher)
    {
        foreach (DispatchOperation operation in endpointDispatcher.DispatchRuntime.Operations)
        {
            operation.ParameterInspectors.Add(new OperationProfilerParameterInspector(this.manager, operation.IsOneWay));
        }
    }
 
    public void Validate(ServiceEndpoint endpoint)
    {
    }
}
 

The behavior takes a “manager” as a parameter. The manager is the entity which will, in this example, store the call information for all the operations in the contract. It can then be invoked to display a summary of the statistics for the calls (I’ll omit most of the formatting methods here, you can find them in the code for this post, linked below).

 public class OperationProfilerManager
{
    Dictionary<string, List<double>> callsPerOperation;
    public OperationProfilerManager()
    {
        this.callsPerOperation = new Dictionary<string, List<double>>();
    }
 
    public void AddOneWayCall(string operationName)
    {
        List<double> callTimes;
        if (this.callsPerOperation.ContainsKey(operationName))
        {
            callTimes = this.callsPerOperation[operationName];
        }
        else
        {
            callTimes = new List<double>();
            this.callsPerOperation.Add(operationName, callTimes);
        }
 
        callTimes.Add(-1);
    }
 
    public void AddCall(string operationName, double duration)
    {
        List<double> callTimes;
        if (this.callsPerOperation.ContainsKey(operationName))
        {
            callTimes = this.callsPerOperation[operationName];
        }
        else
        {
            callTimes = new List<double>();
            this.callsPerOperation.Add(operationName, callTimes);
        }
 
        callTimes.Add(duration);
    }
}
 

Notice that there are two methods to add information about an operation call. For “normal” operations, we provide the duration of the call, but for one-way operations, this information cannot be retrieved (esp. at the client side, since the control will return to the caller almost as if the call was made asynchronously). Next we’ll get to the inspector itself. It’s implementation is actually fairly simple, as it registers the time in which BeforeCall was invoked, and returns it as the correlation state to be passed to the AfterCall method (unless the operation is one-way, in which case we simply register such a call in the manager). There, we again register the time and take the difference between the two times to calculate the duration of the method, then store it in the manager.

And that’s it – this nothing else needed. Now for testing I’ll define a service with some operations which take a certain amount of time (simulated using a random generator), and some “fast” ones (again I’ll skip the definition of the data contracts used in the service, as they’re not relevant to the topic, but they can be found in the code for this post, linked below).

 [ServiceContract]
public interface ITest
{
    [OperationContract]
    int Add(int x, int y);
    [OperationContract]
    int ProcessOrder(Order order);
    [OperationContract(IsOneWay = true)]
    void ProcessOneWay(Order order);
}
 
public class Service : ITest
{
    static Random rndGen = new Random(1);
    public int Add(int x, int y)
    {
        return x + y;
    }
 
    public int ProcessOrder(Order order)
    {
        Thread.Sleep(rndGen.Next(1, 100));
        return order.Id;
    }
 
    public void ProcessOneWay(Order order)
    {
        Thread.Sleep(rndGen.Next(1, 100));
    }
}
 

And finally, hosting the program to see the simple profiler in action:

 static void Main(string[] args)
{
    string baseAddress = "http://" + Environment.MachineName + ":8000/Service";
    ServiceHost host = new ServiceHost(typeof(Service), new Uri(baseAddress));
    ServiceEndpoint endpoint = host.AddServiceEndpoint(typeof(ITest), new BasicHttpBinding(), "");
    OperationProfilerManager serverProfilerManager = new OperationProfilerManager();
    endpoint.Behaviors.Add(new OperationProfilerEndpointBehavior(serverProfilerManager));
    Console.WriteLine("Opening the host");
    host.Open();
 
    ChannelFactory<ITest> factory = new ChannelFactory<ITest>(new BasicHttpBinding(), new EndpointAddress(baseAddress));
    OperationProfilerManager clientProfilerManager = new OperationProfilerManager();
    factory.Endpoint.Behaviors.Add(new OperationProfilerEndpointBehavior(clientProfilerManager));
    ITest proxy = factory.CreateChannel();
 
    Order oneOrder = new Order
    {
        Id = 1,
        Client = new Person
        {
            Name = "John Doe",
            Address = "111 223th Ave",
        },
        Items = new List<OrderItem>
        {
            new OrderItem { Name = "bread", Unit = "un", UnitPrice = 0.56, Amount = 3 },
            new OrderItem { Name = "milk", Unit = "gal", UnitPrice = 2.79, Amount = 1 },
            new OrderItem { Name = "eggs", Unit = "doz", UnitPrice = 2.23, Amount = 1 },
        }
    };
 
    Console.WriteLine("Calling some operations...");
 
    for (int i = 0; i < 200; i++)
    {
        proxy.Add(i, i * i);
        if ((i % 3) == 0)
        {
            proxy.ProcessOneWay(oneOrder);
        }
        else
        {
            proxy.ProcessOrder(oneOrder);
        }
    }
 
    Console.WriteLine("Now printing statistics (server)");
    serverProfilerManager.PrintSummary();
 
    Console.WriteLine();
 
    Console.WriteLine("Now printing statistics (client)");
    clientProfilerManager.PrintSummary();
 
    Console.WriteLine("Press ENTER to close");
    Console.ReadLine();
    host.Close();
    Console.WriteLine("Host closed");
}
 

Coming up

Client and server (dispatch) message formatters, with an example showing how to send / receive arbitrary data without using the WCF REST Raw programming model – this issue came up at the forums a few weeks back.

[Code for this post]

[Back to the index]

Carlos Figueira
http://blogs.msdn.com/carlosfigueira
Twitter: @carlos_figueira http://twitter.com/carlos_figueira

Programmatically calling validation in a rehosted Workflow 4 designer

Patrick D. Fletcher [MSFT] — Wed, 27 Apr 2011 21:11:03 GMT

The workflow designer has a rich programming model that supports communication with the host. A rehosted workflow designer will automatically validate a workflow when it is changed; in order to programmatically call validation on demand on a rehosted designer, use the following method:

designer.Context.Services.GetService<ValidationService>().ValidateWorkflow();

To handle resulting validation errors, publish an implementation of IValidationErrorService, which will expose the set of errors through ValidationService.NavigateTo(). For information on how to do this, see the following topic:

How to: Display Validation Errors in a Rehosted Designer

How to create a WF4 WorkflowServiceHostFactory for AppFabric Auto-Start

Ron Jacobs — Wed, 27 Apr 2011 20:08:00 GMT

Sometimes when using Windows Workflow Foundation (WF4) you need to create a custom WorkflowServiceHostFactory. There are a couple of main reasons why you would want to do this.

To configure the WorklfowServiceHost in some way like adding an extension
To do some other type of initialization work when auto starting a service

This morning I was working on the WF4 Batch Processing Example (now Workflow Services and Auto-Start sample) to update it with things I’ve learned in the past few months. I decided to create a custom WorkflowServiceHostFactory in order to take advantage of the Windows Server AppFabric Auto-Start capability.

Step 1: Create a class that inherits from WorkflowServiceHostFactory

This sounds like a simple step right? The question is… which WorkflowServiceHostFactory? That’s right… beware because there is more than one in the .NET Framework

I use Resharper because it is an amazing time saving tool but in this case it led me down the path to disaster because it works so well. When Resharper sees a class it doesn’t understand it quite helpfully gives you some options.

Because I was in a hurry I quickly selected the first option and then spent the next 2 hours struggling to understand why it didn’t work. Had I looked carefully I would have noticed the problem right away. System.WorkflowServices.WorkflowServiceHostFactory is from WF 3.5. What I should be using is System.ServiceModel.Activities.Activation.WorkflowServiceHostFactory from WF4.

Typically when you get confused about things between WF3 and WF4 you will find that they simply won’t compile but in this case the WF3 WorkflowServiceHost factory will happily compile even in the very strange case where you “use” the namespace from WF4 and reference the assembly from WF3.

Why does this work? Because the two classes do the same thing. They both inherit from ServiceHostBase and override the CreateServiceHost method.

However, if you use the wrong one you will get this exception

The service '/BatchWeb/BWS2.xamlx' cannot be activated due to an exception during compilation. The exception message is: The file '/BatchWeb/BWS2.xamlx' does not exist..

Make sure you reference System.ServiceModel.Activation and use System.ServiceModel.Activities.Activation.WorkflowServiceHostFactory

Then you can implement your factory class. In my case I needed to update the WF4 Batch Job example because it relied on code in the Application_Start method to read the config file and start a batch job. At the time I thought this would be invoked when the system booted and automatically start a job.

When I tested the app it appeared to work but only because there were already persisted jobs with durable timers pending. At boot time the Workflow Management Service would activate the app by sending a message to activate the jobs because of the timer. So it had the illusion of working but actually if there were no jobs with persisted timers the AppPool would never start the app.

When I dug deep into how AutoStart actually works I wrote WCF and AppFabric Auto-Start and said that the only way you can run code that is triggered by the AppFabric Service Auto-Start function is to use a custom service host factory.

In my code what I want to do is on the first start read the configuration file and send a request to submit a new batch job. This is done every time a new instance of the AppPool starts up. This means at boot time but also any time the AppPool recycles. This ensures that there is always at least one of the workflows running and for short periods of time more than one during a recycle.

In my factory I need to send a message to the service that will be hosted. Obviously I can’t send the message before returning the host so I’m using Task.Factory.StartNew to dispatch the work to a different thread.

public override ServiceHostBase CreateServiceHost(string constructorString, Uri[] baseAddresses)

{

    // Run the auto start check on another thread.

    Task.Factory.StartNew(CheckAutoStartJobs);

  

    return base.CreateServiceHost(constructorString, baseAddresses);

}

Then on the other thread, I wait a few seconds, read the config entries and then send a message to the service over a named pipe

private static void CheckAutoStartJobs()

{

    if (autoStarted)

    {

        return;

    }

    else

    {

        autoStarted = true;

    }

  

    // Wait a few seconds for the host to spin up

    Thread.Sleep(TimeSpan.FromSeconds(5));

  

    // Check for autostart

    var autoCount = ConfigurationManager.AppSettings["AutoCount"];

  

    if (string.IsNullOrWhiteSpace(autoCount))

    {

        return;

    }

  

    var values = autoCount.Split('|');

  

    // Check for valid value

    if (values.Length != 2)

    {

        return;

    }

  

    int count;

    if (!Int32.TryParse(values[0], out count))

    {

        return;

    }

  

    int delay;

    if (!Int32.TryParse(values[1], out delay))

    {

        return;

    }

  

    var request = new BatchRequest

        {

            CountTo = count, 

            Delay = TimeSpan.FromSeconds(delay), 

            StartAt = DateTime.Now, 

            AutoStart = true

        };

  

    var proxy = new BatchWorkerClient(

        new NetNamedPipeBinding(), 

        new EndpointAddress("net.pipe://localhost/BatchWeb/BatchWorker.xamlx"));

    try

    {

        var response = proxy.SubmitJob(request);

        proxy.Close();

    }

    catch

    {

        proxy.Abort();

        throw;

    }

}

Step 2: Add ServiceActivation in web.config

With a WCF Service you can add a ServiceHostFactory entry in the .SVC file. Workflow Services don’t have an SVC file so you will need to edit your web.config to add support for a factory

<system.serviceModel>

<!-- Other stuff deleted -->

    <serviceHostingEnvironment>

      <serviceActivations>

        <!-- Use a Custom WorkflowServiceHostFactory to automatically start the batch jobs-->

        <add relativeAddress="BatchWorker.xamlx" service="BatchWorker.xamlx" factory="BatchWeb.BatchAutoStartFactory" />

      </serviceActivations>

    </serviceHostingEnvironment>

</system.serviceModel>



Step 3: Configure Auto-Start

Open IIS Manager and right click on your web app.
Select Manage WCF and WF Services / Configure
Select the Auto-Start tab and choose Enabled

Step 4: Test It

To test your service, I recommend you get my AppFabricDBReset script.

Stop the AppPool that your web site is hosted in
Run the AppFabricDBReset Script to eliminate any persisted instances
Start the AppPool
In a few seconds browse to the site and you will see that an instance of the batch job has been auto started

Step 5: Get It

Download the Windows Workflow Foundation (WF4) - Workflow Services and Auto-Start Sample

Ron Jacobs
http://blogs.msdn.com/rjacobs
Twitter: @ronljacobs http://twitter.com/ronljacobs

WebSockets, RIA/JS and WCF Web API at MIX, a whole lotta love for the web

Glenn Block MSFT — Sun, 24 Apr 2011 11:27:00 GMT

MIX was indeed a busy time for the WCF Team. We delivered several talks, and released several shiny new toys to the community for folks that are building web-based systems.

WebSockets

Craig Kitterman of our Interoperability group, and Paul Batum, whom you might know of from his work on Fluent NHibernate gave a talk: Hot from the Labs: HTML5 WebSockets

In the talk they spoke about new explorations we are doing into supporting WebSockets in the Microsoft Stack. WebSockets is basically sockets for the web, i.e. a way to have a much more responsive in-browser experience. In the talk you’ll learn about the work going on in the W3C/IETF around WebSockets and you’ll see the exploratory work we’ve been doing both at the browser level and on the server to enable a WebSockets experience. I highly recommend this talk, as you’ll see is a pattern for the other talks I mention below.

Here’s a sneak peak of what the coding experience looks like, which I hope you agree is pretty clean.

On the client you have code such as the following:

conn.onopen = function () {

  state.className = 'success';

  state.innerHTML = 'Socket open';

};


conn.onmessage = function (event) {

  var message = JSON.parse(event.data);

  if (typeof message == 'string') {

    log.innerHTML = '<li class="them">' + 

    message.replace(/[<>&]/g, function (m) 

    { return entities[m]; }) + '</li>' + log.innerHTML; 

  } else {

    connected.innerHTML = message;

  }

};


conn.onclose = function (event) {

  state.className = 'fail';

  state.innerHTML = 'Socket closed';

};

The on the server you have a WebSocket service:

[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerSession, 

  ConcurrencyMode = ConcurrencyMode.Multiple)]

public class ChatService : WebSocketsService

{

  ...

  

  public override void OnMessage(string value)

  {

    ChatService.sessions.RelayMessage(this, value);

  }


  public override int GetHashCode()

  {

    return this.id; 

  }


  protected override void OnClose(object sender, EventArgs e)

  {

    ChatService.sessions.Remove(this);

  }

}

You can download the latest bits of the WebSockets work at the HTML 5 labs WebSockets page.

RIA/JS

Brad Olenick of the RIA team delivered a talk: Building Data-centric N-tier Applications with jQuery.

In the talk he unveiled new work the RIA team is doing is to allow consuming RIA services in jQuery! Watch the talk. Brad demonstrates how you can build a rich jQuery front end that dynamically pulls down all of it’s data to the client using RIA. RIA/JS then integrates all the state-tracking/validation richness and such using jQuery validators. If you are building data-centric jQuery based applications then RIA can take care of a lot of the dirty work for you making your job easier*. This also highlights the value of RIA in that I can reuse my existing domain services now both across Silverlight and Javascript! I know my previous boss (who is deeply missed) Brad Abrams must be very happy seeing that this is being developed!

*We’re not saying RIA/JS is the panacea for all evils, but it certainly is for some :-)

Here are some of the key scenarios being supported in the first preview.

Query support with sorting, paging, filtering
Changeset submission with two edit modes:
1. “Implicit Commit” or “write-thru edits” where updates to field values are automatically submitted to your DomainService. This can enable a Netflix.com or Mint.com experience where field changes are submitted to the server as soon as the user tabs out of the field.
2. “Buffered Changes” mode, where your code must call commitChanges() to submit your changeset to the DomainService. Those that have used the Silverlight client will be most familiar with this mode - a submit button is often used to trigger the commit.
Data change events including collection changes
Client-side change tracking with an entity state API for determining what entities and properties have been edited
Entity data model support that allows you to navigate through associated entity properties and collections
Client-side validation by exposing your server-side validation metadata in jQuery validation format

And here is a snippet of the new RIA/JS syntax. This is a great example of how we are looking to take advantage of awesome OSS solutions for delivering value. It’s about time!

<script type="text/javascript">

  $(function () {

	var serviceUrl = "/CustomerApp-CustomerService.svc";

	var customers = [];


	var render = function (loadedCustomers) {

	  $("#customerForm input[name='CustomerName']").

	    val(loadedCustomers[0].CustomerName);

	  $("#customerForm").link(loadedCustomers[0]);

	};


	$([customers]).dataSource({

	  serviceUrl: serviceUrl,

	  queryName: "GetCustomers",

	  refresh: render

	}).refresh();

  });

</script>

<div id="customerForm">

    Name: <input type="text" name="CustomerName" />

</div>

After the talk, the RIA team shipped new bits (as in js files) to Codeplex and a new RIA Service jQuery Nuget package! allowing you to start to play with the RIA/JS stuff now. Go get-em here.

WCF Web API and Preview 4

Continuing along the path web goodness, I delivered a talk: WCF Web APIs: There’s a URI for that.

In the talk I covered the evolution of systems that are now making their capabilities directly available over HTTP including social sites and line of business / enterprise apps. I showed progress we’ve made since PDC on our new WCF addition. The advances have been significant including greatly improving the out of the box experience, enhancing the fidelity you can have when working with HTTP, improving the configuration story and improving testability.

For example I demonstrated how using our new nuget package, you quickly you can build a simple service that can return and consume xml, json as well as consume form url encoding content. I then throw an existing jQuery front end on top without having to touch the server side configuration. I then demonstrated how I could easily take my existing service and quickly refactor it to use an IoC container, in this case Autofac, by taking advantage of a new fluent api (which is still a work in progress).

In the second part of my talk, I demonstrated how having rich control of formats/media types can benefit you. This includes showing my resource returning OData, as well a vcard implementation which I use to import contacts directly into gmail. Try that with SOAP, or plain-old XML/JSON, I dare you!

Here’s a snippet of some of the HTTP fidelity I am talking about. Below my service takes advantage of our new HttpResponseMessage<T> and HttpResponseException to return a model AND work with HTTP at the same time.

[WebGet(UriTemplate = "{id}")]

public HttpResponseMessage<Contact> Get(int id)

{

  var contact = this.repository.Get(id);

  if (contact == null)

  {

    var response = new HttpResponseMessage();

    response.StatusCode = HttpStatusCode.NotFound;

    response.Content = new StringContent("Contact not found");

    throw new HttpResponseException(response);

   }

   var contactResponse = 

     new HttpResponseMessage<Contact>(contact);


   //set it to expire in 5 minutes

   contactResponse.Content.Headers.Expires = 

     new DateTimeOffset(DateTime.Now.AddSeconds(30));

   return contactResponse;

}

The Get method returns a contact and sets caching headers. If the contact is not found however it throws an HttpResponseException passing in an HttpResponseMessage. In this case I am just returning a string, but you have full access to set the response headers/content to whatever you want. Also you might not have caught it, but the id parameter is now passed in as integer. In previous drops as well as in WCF HTTP you had to use a string. Well now we do automatic type conversion. You asked for it, and you got it!

Nuget and Preview 4

After my talk, I am happy to announce that we pushed our next release of WCF Web API (yes drop the s) to Codeplex along with a new set of Nuget packages (webapi.all will get all of ours). You’ll notice a 6th package, WebApi.CrudHttpSample from Steve Michelotti. Rock on Steve! Here’s a link to more on that package.

Preview 4 is loaded with new features much of which is based on your feedback! We’ve been developing them for a while and finally are able to get them out there. All of our apis have been significantly evolved in this release.

Here is a summary of the major things you will find:

New message classes HttpResponseMessage<T> / HttpRequestMessage<T> allows accessing headers and using a strongly typed model.
Uri parameters can now autocast to primtiive types, i.e. a uri template of "{id}" can map to an integer parameter of id.
Matching of parameters is now by type if there is no match on name, ie. HttpRequestMessage req will work.
New Operation Handlers which replace processors and dramatically improve the authoring
New Formatters for plugging in custom media types
New Message Handlers for low level control over HTTP
Newer HttpClient
Support for Form Url Encoding / Json and Xml out of the box.
Support for HTTPs
IQueryable support with IQueryable<T> and without requiring attributes
Overhauled fluent API for configuration !!!!
Unit tests
New samples
ContactManager is now a fully client based AJAX / JQuery application
- New ContactManager_Simple illustrates the bare basics.
new HelloResource sample
Acceptance and Unit tests for some of the samples

I am planning to do some follow up posting detailing all these changes, but this should be enough to keep you guys happy for a while

Go road test this stuff and give us your feedback. We want it, we’re not done yet!

WCF Extensibility – Message Inspectors

CarlosFigueira — Sat, 23 Apr 2011 16:08:52 GMT

This post is part of a series about WCF extensibility points. For a list of all previous posts and planned future ones, go to the index page.

The message inspectors are probably the most used extensibility points of the WCF runtime. Anytime you need to log, inspect, modify or completely replace a message, the two inspector interfaces (IClientMessageInspector for the client side; IDispatchMessageInspector for the server side) are likely to be perfect candidates for the solution. There are so many examples of the dispatch inspector (and also many more examples using client inspectors) being used as solution for problems in the forums that it’s actually hard to pick one scenario to show in this post. I’ll then show one full scenario and briefly mention others.

Public implementations in WCF

None. Most of the runtime extensibility points don’t have any public implementations, although there are a few internal ones for the message inspectors.

Interface declarations

 public interface IDispatchMessageInspector
{
    object AfterReceiveRequest(ref Message request, IClientChannel channel, InstanceContext instanceContext);
    void BeforeSendReply(ref Message reply, object correlationState);
}
 
public interface IClientMessageInspector
{
    void AfterReceiveReply(ref Message reply, object correlationState);
    object BeforeSendRequest(ref Message request, IClientChannel channel);
}
 

The inspector interfaces have two methods: one after the incoming message is received on the wire and before it’s dispatched to the application (AfterReceive), and one after the outgoing message is received from the application and before it’s encoded to be sent on the wire (BeforeSend). Let’s talk about them individually.

At the server side, implementations of IDispatchMessageInspector get a chance to inspect the incoming message right after the request is received via the AfterReceiveRequest method. Besides the message, the method is also passed the channel through which the message arrived (which contains information about any current sessions, local and remote address, and so on), and the instance context associated with the service (with references to the host, and any extensions associated with it). After the user code on the service operation processed the request, and the reply is created into a Message object, BeforeSendReply is called on the inspector code, with the message object and the correlation state, which is whatever AfterReceiveRequest returned – this way the code can correlate the two parts of the message inspection for a single client request.

One thing that deserves mention is that the Message object to both methods is passed by reference. WCF Message objects can only be “consumed” once – and “consumed” can mean read, written or copied. The message body is essentially a read-once stream, so once it’s consumed it cannot be used again. So if, in the inspector code, one were to read the message, the WCF runtime wouldn’t be able to reuse that message in the rest of its pipeline (i.e., to encode it to send as a reply or to parse it into operation parameters). So if the inspector code needs to read the message, it’s the responsibility of the inspector to recreate the message. The code below shows one way of recreating the message object.

 public object AfterReceiveRequest(ref Message request, IClientChannel channel, InstanceContext instanceContext)
{
    Console.WriteLine("Message:");
    Console.WriteLine(request);
    Console.WriteLine();
    MemoryStream ms = new MemoryStream();
    XmlWriter writer = XmlWriter.Create(ms);
    request.WriteMessage(writer); // the message was consumed here
    writer.Flush();
    ms.Position = 0;
    XmlDocument xmlDoc = new XmlDocument();
    xmlDoc.Load(ms);
    this.ChangeMessage(xmlDoc);
 
    //Now recreating the message
    ms = new MemoryStream();
    xmlDoc.Save(ms);
    ms.Position = 0;
    XmlReader reader = XmlReader.Create(ms);
    Message newMessage = Message.CreateMessage(reader, int.MaxValue, request.Version);
    newMessage.Properties.CopyProperties(request.Properties);
    request = newMessage;
    
    return null;
 

The list of method calls which would cause a message to be consumed are the following: CreateBufferedCopy, GetBody, GetReaderAtBodyContents, WriteBody, WriteBodyContents and WriteMessage. All others are fine: accessing the message headers is ok, since they’re always buffered, so that doesn’t “invalidate” the message. Accessing the message properties is also safe, as they’re just a named dictionary (buffered). Finally, calling Message.ToString in the message is also safe – if the message body is indeed a read-once stream, it will be represented simply as “... stream ...”. If the message is buffered it’s actually possible that the value returned by ToString will display the whole message body.

At the client side, IClientMessageInspector implementations get a chance to inspect the message after it’s been created based on the operation call, and right before it’s encoded. BeforeSendRequest receives the message (again, passed by reference) and the channel through which the message is being sent. When the response from the server arrives and is decoded (by the message encoder) into a Message object, it’s passed to the client inspector in its AfterReceiveReply method. Like in the server version, the method receives the message object (again, by reference) and the correlation state returned by the BeforeSendRequest method. Notice that if the operation contract is defined as one way, the call to AfterReceiveReply is not made at the client inspector, which makes sense, since one way operations do not have a reply message. Weirdly enough, for dispatch message inspectors, BeforeSendReply is actually called for HTTP, but the reply message passed to it is null.

How to add message inspectors

At the server side: the list of dispatch message inspectors is available at the DispatchRuntime object. The object is typically accessed via the endpoint dispatcher in a call to IEndpointBehavior.ApplyDispatchBehavior, or directly passed to an implementation of IContractBehavior.ApplyDispatchBehavior.

 public class MyContractBehavior : IContractBehavior
{
    public void ApplyDispatchBehavior(ContractDescription contractDescription, ServiceEndpoint endpoint, DispatchRuntime dispatchRuntime)
    {
        dispatchRuntime.MessageInspectors.Add(new MyInspector());
    }
}
public class MyEndpointBehavior : IEndpointBehavior
{
    public void ApplyDispatchBehavior(ServiceEndpoint endpoint, EndpointDispatcher endpointDispatcher)
    {
        endpointDispatcher.DispatchRuntime.MessageInspectors.Add(new MyInspector());
    }
}
 

At the client side: the list of client message inspectors is available at the ClientRuntime object.

 public class MyContractBehavior : IContractBehavior
{
    public void ApplyClientBehavior(ContractDescription contractDescription, ServiceEndpoint endpoint, ClientRuntime clientRuntime)
    {
        clientRuntime.MessageInspectors.Add(new MyClientInspector());
    }
}
public class MyEndpointBehavior : IEndpointBehavior
{
    public void ApplyClientBehavior(ServiceEndpoint endpoint, ClientRuntime clientRuntime)
    {
        clientRuntime.MessageInspectors.Add(new MyClientInspector());
    }
}
 

Real world scenario: Inspecting non-XML messages

As I mentioned before, all WCF messages are XML-based – the message envelope is an XML Infoset represented in memory, with the (optional) header and the body as child XML elements of the envelope. A message can be directly written to a XML writer, and created based on a XML reader. This works quite well in the XML (including SOAP and POX) world. However, with the introduction of the WCF HTTP programming model in .NET Framework 3.5, WCF started accepting out-of-the-box more types of content (most notably JSON and binary content). But since the whole WCF stack is XML-based, sometimes the behavior of the messages can be counter-intuitive.

Take, for example, a simple message logger, which is typically implemented using the message inspectors described in this post. Let’s say that we have a contact manager, which is implemented as a bunch of operations used primarily by web pages (thus using JSON as the primary message format):

 [DataContract]
public class Contact
{
    [DataMember]
    public string Id { get; set; }
    [DataMember]
    public string Name { get; set; }
    [DataMember]
    public string Email { get; set; }
    [DataMember]
    public string[] Telephones { get; set; }
}
 
[ServiceContract]
public interface IContactManager
{
    [WebInvoke(
        Method = "POST",
        UriTemplate = "/Contacts",
        ResponseFormat = WebMessageFormat.Json)]
    string AddContact(Contact contact);
 
    [WebInvoke(
        Method = "PUT",
        UriTemplate = "/Contacts/{id}",
        ResponseFormat = WebMessageFormat.Json)]
    void UpdateContact(string id, Contact contact);
 
    [WebInvoke(
        Method = "DELETE",
        UriTemplate = "/Contacts/{id}",
        ResponseFormat = WebMessageFormat.Json)]
    void DeleteContact(string id);
    
    [WebGet(UriTemplate = "/Contacts", ResponseFormat = WebMessageFormat.Json)]
    List<Contact> GetAllContacts();
    
    [WebGet(UriTemplate = "/Contacts/{id}", ResponseFormat = WebMessageFormat.Json)]
    Contact GetContact(string id);
 
    [WebGet(UriTemplate = "/ContactsAsText")]
    Stream GetContactsAsText();
}
 

Now let’s say we send the following request to the service:

POST /Contacts HTTP/1.1
Content-Type: application/json
Host: my.host.name.com
Content-Length: 90
Expect: 100-continue

{"Name":"Jane Roe", "Email":"jane@roe.com", "Telephones":["202-555-4444", "202-555-8888"]}

Inside the message inspector, we have a simple implementation which prints the message content:

 public object AfterReceiveRequest(ref Message request, IClientChannel channel, InstanceContext instanceContext)
{
    if (!request.IsEmpty)
    {
        Console.ForegroundColor = ConsoleColor.Green;
        Console.WriteLine("Incoming message:");
        Console.WriteLine(request);
        Console.ResetColor();
    }
 
    return null;
}
 

Easy, right? However, we’re in the Message world, and that means XML, so instead of seeing the nice JSON request which was sent to the server, what ends up being printed is the message below:

<root type="object">
<Name type="string">Jane Roe</Name>
<Email type="string">jane@roe.com</Email>
<Telephones type="array">
<item type="string">202-555-4444</item>
<item type="string">202-555-8888</item>
</Telephones>
</root>

This throws quite a few people off-balance. What is being printed out is actually equivalent to the incoming JSON, by following the mapping between JSON and XML used in WCF. But that doesn’t help for all the scenarios where one needs to log incoming messages, or even change the JSON in the message. The same would happen if the message was a “raw” message, for operations in which the return type or the operation parameter was of type Stream – see more information on the WCF raw programming model for returning or receiving raw data – what would be printed would be the XML mapping of raw data (the base64binary data wrapped around a <Binary> XML element).

This example will show then how to read such content in a way that can be easily manipulated (the example simply logs it to a file, but it can easily be modified to change the message on the fly as well). And before I go further, the usual disclaimer – this is a sample for illustrating the topic of this post, this is not production-ready code. I tested it for a few contracts and it worked, but I cannot guarantee that it will work for all scenarios (please let me know if you find a bug or something missing). Also, for simplicity sake it doesn’t have a lot of error handling which a production-level code would. Also, the contact manager is all stored in memory, a “real” one would have a backing database or something more “persistent”.

First, for completeness sake, the service which implements the contract shown before, which is shown below. The implementation is simple (all in memory), with a lock around operations with the “repository”.

 public class ContactManagerService : IContactManager
{
    static List<Contact> AllContacts = new List<Contact>();
    static int currentId = 0;
    static object syncRoot = new object();
 
    public string AddContact(Contact contact)
    {
        int contactId = Interlocked.Increment(ref currentId);
        contact.Id = contactId.ToString(CultureInfo.InvariantCulture);
        lock (syncRoot)
        {
            AllContacts.Add(contact);
            WebOperationContext.Current.OutgoingResponse.StatusCode = HttpStatusCode.Created;
        }
 
        return contact.Id;
    }
 
    public void UpdateContact(string id, Contact contact)
    {
        contact.Id = id;
        lock (syncRoot)
        {
            int index = this.FetchContact(id);
            if (index >= 0)
            {
                AllContacts[index] = contact;
            }
        }
    }
 
    public void DeleteContact(string id)
    {
        lock (syncRoot)
        {
            int index = this.FetchContact(id);
            if (index >= 0)
            {
                AllContacts.RemoveAt(index);
            }
        }
    }
 
    public List<Contact> GetAllContacts()
    {
        List<Contact> result;
        lock (syncRoot)
        {
            result = AllContacts.ToList();
        }
 
        return result;
    }
 
    public Contact GetContact(string id)
    {
        Contact result;
        lock (syncRoot)
        {
            int index = this.FetchContact(id);
            result = index < 0 ? null : AllContacts[index];
        }
 
        return result;
    }
 
    public Stream GetContactsAsText()
    {
        StringBuilder sb = new StringBuilder();
        WebOperationContext.Current.OutgoingResponse.ContentType = "text/plain";
        lock (syncRoot)
        {
            foreach (var contact in AllContacts)
            {
                sb.AppendLine("Contact " + contact.Id + ":");
                sb.AppendLine("  Name: " + contact.Name);
                sb.AppendLine("  Email: " + contact.Email);
                sb.AppendLine("  Telephones:");
                foreach (var phone in contact.Telephones)
                {
                    sb.AppendLine("    " + phone);
                }
            }
        }
 
        WebOperationContext.Current.OutgoingResponse.ContentType = "text/plain; charset=utf-8";
        MemoryStream ms = new MemoryStream(Encoding.UTF8.GetBytes(sb.ToString()));
        return ms;
    }
 
    private int FetchContact(string id)
    {
        int result = -1;
        for (int i = 0; i < AllContacts.Count; i++)
        {
            if (AllContacts[i].Id == id)
            {
                result = i;
                break;
            }
        }
 
        if (result < 0)
        {
            WebOperationContext.Current.OutgoingResponse.StatusCode = HttpStatusCode.NotFound;
        }
 
        return result;
    }
}
 

Now for the inspector itself. I’ll implement it as both an IDispatchMessageInspector and an IEndpointBehavior to make it easier for adding it to the endpoint I’m interested in logging the messages for. It will contain a folder where to log the messages, plus a counter to create the file name where the messages will be logged. The IEndpointBehavior implementation is simple, only using the ApplyDispatchBehavior method to add that instance to the list of message inspectors in the dispatch runtime.

 public class IncomingMessageLogger : IDispatchMessageInspector, IEndpointBehavior
{
    const string MessageLogFolder = @"c:\temp\";
    static int messageLogFileIndex = 0;
 
    public void AddBindingParameters(ServiceEndpoint endpoint, BindingParameterCollection bindingParameters)
    {
    }
 
    public void ApplyClientBehavior(ServiceEndpoint endpoint, ClientRuntime clientRuntime)
    {
    }
 
    public void ApplyDispatchBehavior(ServiceEndpoint endpoint, EndpointDispatcher endpointDispatcher)
    {
        endpointDispatcher.DispatchRuntime.MessageInspectors.Add(this);
    }
 
    public void Validate(ServiceEndpoint endpoint)
    {
    }
}
 

Now for the message inspector implementation. For every incoming or outgoing message, we’ll create a new file in the folder defined in the const field for the class.

 public object AfterReceiveRequest(ref Message request, IClientChannel channel, InstanceContext instanceContext)
{
    string messageFileName = string.Format("{0}Log{1:000}_Incoming.txt", MessageLogFolder, Interlocked.Increment(ref messageLogFileIndex));
    Uri requestUri = request.Headers.To;
    using (StreamWriter sw = File.CreateText(messageFileName))
    {
        HttpRequestMessageProperty httpReq = (HttpRequestMessageProperty)request.Properties[HttpRequestMessageProperty.Name];
 
        sw.WriteLine("{0} {1}", httpReq.Method, requestUri);
        foreach (var header in httpReq.Headers.AllKeys)
        {
            sw.WriteLine("{0}: {1}", header, httpReq.Headers[header]);
        }
 
        if (!request.IsEmpty)
        {
            sw.WriteLine();
            sw.WriteLine(this.MessageToString(ref request));
        }
    }
 
    return requestUri;
}
 
public void BeforeSendReply(ref Message reply, object correlationState)
{
    string messageFileName = string.Format("{0}Log{1:000}_Outgoing.txt", MessageLogFolder, Interlocked.Increment(ref messageLogFileIndex));
 
    using (StreamWriter sw = File.CreateText(messageFileName))
    {
        sw.WriteLine("Response to request to {0}:", (Uri)correlationState);
        HttpResponseMessageProperty httpResp = (HttpResponseMessageProperty)reply.Properties[HttpResponseMessageProperty.Name];
        sw.WriteLine("{0} {1}", (int)httpResp.StatusCode, httpResp.StatusCode);
 
        if (!reply.IsEmpty)
        {
            sw.WriteLine();
            sw.WriteLine(this.MessageToString(ref reply));
        }
    }
}
 

Now for the interesting part – the implementation of MessageToString. Incoming messages from the encoder used in the WebHttpBinding are tagged with a property of type WebBodyFormatMessageProperty, which defines which of the inner encoders was used to decode the message (the encoder from that binding is actually composed of three encoders: one for XML content, one for JSON, and one for everything else). That property is also used on outgoing messages to tell the web encoder which of the inner encoders should be used to write the message to the wire. So we’ll define a small helper method to retrieve the format from the message object.

 private WebContentFormat GetMessageContentFormat(Message message)
{
    WebContentFormat format = WebContentFormat.Default;
    if (message.Properties.ContainsKey(WebBodyFormatMessageProperty.Name))
    {
        WebBodyFormatMessageProperty bodyFormat;
        bodyFormat = (WebBodyFormatMessageProperty)message.Properties[WebBodyFormatMessageProperty.Name];
        format = bodyFormat.Format;
    }
 
    return format;
}
 

And now for MessageToString (really this time). For XML and JSON messages, the implementation will write the message into a XmlWriter of the appropriate type. The writer created by the class JsonReaderWriterFactory implements the mapping between JSON and XML I mentioned before, so we’ll use it for JSON messages; for XML messages (or for messages which don’t have the body format property) we’ll use the “normal” XML writer from WCF; for raw messages we’ll deal with them specifically in a separate method. After the message is written, it has been consumed, so we need to recreate it to pass it along the channel stack. Using a reader of the same type and creating a new message using the Message.CreateMessage(XmlDictionaryReader, int, MessageVersion) overload and copying the original message properties (which are not serialized when the message is written out).

For the raw messages, since the format is relatively simple (the binary data, written as base64Binary data, wrapped in a single <Binary> element), we can consume it directly – read the message body, skip the wrapping element then read the whole body at once. In this case I’m always converting the binary data to text, in the general case that may not work (if the binary data is an image, for example), but that’s beyond the scope for this post.

 private string MessageToString(ref Message message)
{
    WebContentFormat messageFormat = this.GetMessageContentFormat(message);
    MemoryStream ms = new MemoryStream();
    XmlDictionaryWriter writer = null;
    switch (messageFormat)
    {
        case WebContentFormat.Default:
        case WebContentFormat.Xml:
            writer = XmlDictionaryWriter.CreateTextWriter(ms);
            break;
        case WebContentFormat.Json:
            writer = JsonReaderWriterFactory.CreateJsonWriter(ms);
            break;
        case WebContentFormat.Raw:
            // special case for raw, easier implemented separately
            return this.ReadRawBody(ref message);
    }
 
    message.WriteMessage(writer);
    writer.Flush();
    string messageBody = Encoding.UTF8.GetString(ms.ToArray());
 
    // Here would be a good place to change the message body, if so desired.
 
    // now that the message was read, it needs to be recreated.
    ms.Position = 0;
 
    // if the message body was modified, needs to reencode it, as show below
    // ms = new MemoryStream(Encoding.UTF8.GetBytes(messageBody));
 
    XmlDictionaryReader reader;
    if (messageFormat == WebContentFormat.Json)
    {
        reader = JsonReaderWriterFactory.CreateJsonReader(ms, XmlDictionaryReaderQuotas.Max);
    }
    else
    {
        reader = XmlDictionaryReader.CreateTextReader(ms, XmlDictionaryReaderQuotas.Max);
    }
 
    Message newMessage = Message.CreateMessage(reader, int.MaxValue, message.Version);
    newMessage.Properties.CopyProperties(message.Properties);
    message = newMessage;
 
    return messageBody;
}
 
private string ReadRawBody(ref Message message)
{
    XmlDictionaryReader bodyReader = message.GetReaderAtBodyContents();
    bodyReader.ReadStartElement("Binary");
    byte[] bodyBytes = bodyReader.ReadContentAsBase64();
    string messageBody = Encoding.UTF8.GetString(bodyBytes);
 
    // Now to recreate the message
    MemoryStream ms = new MemoryStream();
    XmlDictionaryWriter writer = XmlDictionaryWriter.CreateBinaryWriter(ms);
    writer.WriteStartElement("Binary");
    writer.WriteBase64(bodyBytes, 0, bodyBytes.Length);
    writer.WriteEndElement();
    writer.Flush();
    ms.Position = 0;
    XmlDictionaryReader reader = XmlDictionaryReader.CreateBinaryReader(ms, XmlDictionaryReaderQuotas.Max);
    Message newMessage = Message.CreateMessage(reader, int.MaxValue, message.Version);
    newMessage.Properties.CopyProperties(message.Properties);
    message = newMessage;
 
    return messageBody;
}
 

That’s it. With this inspector we can log messages of all types for REST services, in their original format. Another way to implement it would be in a custom message encoder (coming up in this series), in which you can have access to the raw bytes coming from the wire, as well as the content-type of the HTTP request.

Now for some test code which sets up the service with that inspector, and sends some messages to it.

     public class Program
    {
        public static void Main(string[] args)
        {
            string baseAddress = "http://" + Environment.MachineName + ":8000/Service";
            ServiceHost host = new ServiceHost(typeof(ContactManagerService), new Uri(baseAddress));
            ServiceEndpoint endpoint = host.AddServiceEndpoint(typeof(IContactManager), new WebHttpBinding(), "");
            endpoint.Behaviors.Add(new WebHttpBehavior());
            endpoint.Behaviors.Add(new IncomingMessageLogger());
            host.Open();
            Console.WriteLine("Host opened");
 
            string johnId = SendRequest(
                "POST",
                baseAddress + "/Contacts",
                "application/json",
                CreateJsonContact(null, "John Doe", "john@doe.com", "206-555-3333"));
            string janeId = SendRequest(
                "POST",
                baseAddress + "/Contacts",
                "application/json",
                CreateJsonContact(null, "Jane Roe", "jane@roe.com", "202-555-4444 202-555-8888"));
 
            Console.WriteLine("All contacts");
            SendRequest("GET", baseAddress + "/Contacts", null, null);
 
            Console.WriteLine("Updating Jane");
            SendRequest(
                "PUT",
                baseAddress + "/Contacts/" + janeId,
                "application/json",
                CreateJsonContact(janeId, "Jane Roe", "jane@roe.org", "202-555-4444 202-555-8888"));
 
            Console.WriteLine("All contacts, text format");
            SendRequest("GET", baseAddress + "/ContactsAsText", null, null);
 
            Console.WriteLine("Deleting John");
            SendRequest("DELETE", baseAddress + "/Contacts/" + johnId, null, null);
 
            Console.WriteLine("Is John still here?");
            SendRequest("GET", baseAddress + "/Contacts/" + johnId, null, null);
 
            Console.WriteLine("It also works with XML payloads:");
            string xmlPayload = @"<Contact>
  <Email>johnjr@doe.com</Email>
  <Name>John Doe Jr</Name>
  <Telephones xmlns:a=""http://schemas.microsoft.com/2003/10/Serialization/Arrays"">
    <a:string>333-333-3333</a:string>
  </Telephones>
</Contact>";
            SendRequest(
                "POST",
                baseAddress + "/Contacts",
                "text/xml",
                xmlPayload);
 
            Console.WriteLine("All contacts:");
            SendRequest("GET", baseAddress + "/Contacts", null, null);
        }
 
        static string SendRequest(string method, string uri, string contentType, string body)
        {
            HttpWebRequest req = (HttpWebRequest)HttpWebRequest.Create(uri);
            req.Method = method;
            if (contentType != null)
            {
                req.ContentType = contentType;
            }
 
            if (body != null)
            {
                byte[] bodyBytes = Encoding.UTF8.GetBytes(body);
                Stream reqStream = req.GetRequestStream();
                reqStream.Write(bodyBytes, 0, bodyBytes.Length);
                reqStream.Close();
            }
 
            HttpWebResponse resp;
            try
            {
                resp = (HttpWebResponse)req.GetResponse();
            }
            catch (WebException e)
            {
                resp = (HttpWebResponse)e.Response;
            }
 
            Console.ForegroundColor = ConsoleColor.Cyan;
            Console.WriteLine("Response to request to {0} - {1}", method, uri);
            Console.WriteLine("HTTP/{0} {1} {2}", resp.ProtocolVersion, (int)resp.StatusCode, resp.StatusDescription);
            foreach (var headerName in resp.Headers.AllKeys)
            {
                Console.WriteLine("{0}: {1}", headerName, resp.Headers[headerName]);
            }
 
            Stream respStream = resp.GetResponseStream();
            string result = null;
            if (respStream != null)
            {
                result = new StreamReader(respStream).ReadToEnd();
                Console.WriteLine(result);
            }
 
            Console.WriteLine();
            Console.WriteLine("  -*-*-*-*-*-*-*-*");
            Console.WriteLine();
 
            Console.ResetColor();
 
            // Removing the string markers from results (for contact ids)
            if (result.StartsWith("\"") && result.EndsWith("\""))
            {
                result = result.Substring(1, result.Length - 2);
            }
 
            return result;
        }
 
        static string CreateJsonContact(string id, string name, string email, string telephones)
        {
            string[] phoneNumbers = telephones.Split(new char[] { ' ' }, StringSplitOptions.RemoveEmptyEntries);
            StringBuilder sb = new StringBuilder();
            sb.Append('{');
            if (id != null)
            {
                sb.AppendFormat("\"Id\":\"{0}\", ", id);
            }
 
            sb.AppendFormat("\"Name\":\"{0}\", ", name);
            sb.AppendFormat("\"Email\":\"{0}\", ", email);
            sb.Append("\"Telephones\":[");
            for (int i = 0; i < phoneNumbers.Length; i++)
            {
                if (i > 0) sb.Append(", ");
                sb.AppendFormat("\"{0}\"", phoneNumbers[i]);
            }
 
            sb.Append(']');
            sb.Append('}');
            return sb.ToString();
        }
    }
 

One more thing: we had to deal with lots of different formats and translation between a “XML” message into its own format, which is not something very natural. Some good news is that among the new features coming in an upcoming version of WCF is a new HTTP pipeline, which will make it easier to implement a scenario such as this. And you can actually start using them right now, as there is a preview of the feature in the WCF Codeplex site at http://wcf.codeplex.com.

Coming up

The other inspector interface: IParameterInspector.

[Code in this post]

[Back to the index]

Carlos Figueira
http://blogs.msdn.com/carlosfigueira
Twitter: @carlos_figueira http://twitter.com/carlos_figueira

WF4 State Machine User Experience

.NET Connected Framework Team — Wed, 20 Apr 2011 07:38:00 GMT

State machine is a well-known model for event-driven workflows and a highly requested feature from our WF4 users, especially those looking to move their WF3 State Machine workflows to WF4. We are very pleased to provide a new, fully-supported, WF4 State Machine including runtime and designer in the .Net Framework Platform Update 1 release (KB2495593). This release enables customers to model their event-driven processes as a state machine using a simplified API and designer experience. Thanks to all who evaluated the CodePlex preview of the WF4 State Machine. We incorporated much of your feedback in this final release.

State Machine User experience Overview

State Machine Activity in WF4 is the encapsulating entity for a state machine execution model. The basic elements of a state machine are:

· States – A finite list of the possible states the state machine can be in

· Transitions – A list of a possible state changes

· Final State – A State which upon reaching it will terminate the StateMachine

A state machine can have multiple states. It must have only one initial state but can have zero to multiple final states.

A very basic scenario that can demonstrate a state machine is a stop watch, as described in the WF4 StateMachine modeled in the State Machine Activity Designer below:

This state machine has four possible states:

On- initial state of the stopwatch, no data is displayed

Started - the stopwatch internal clock is started and the display is updated every 10 milliseconds.

Stopped - the stopwatch internal clock is stopped and the display shows its last value.

Off - the stopwatch is powered off. It is a final state in this stop watch model.

State

Each State supports execution of Activities modeled as Entry and Exit actions which allow Activities to be scheduled upon entering or exiting the state. It should be noted that, State itself in WF4 is not an Activity.

Let’s look at the State designer for “On” State.

The user can drag and drop any activity into the Entry and/or Exit action.

To improve navigation, the State designer also provides an aggregated view of all the Transitions originating from the State as well as the destination State for that Transition.

Transition

States include a collection of Transitions. A Transition defines the movement from a source State to a destination State. Each Transition is configured with a Trigger Activity, typically an event driven Activity such as Receive Message or Delay. A user can also specify an expression as the condition of a transition. Additionally, an optional Transition Activity may be included. The Transition designer below shows the “Start Clock” Transition.

In the example here, the Transition event is “StartTheWatch” Activity. The Stop Watch will only transition to “Started” State after “StartTheWatch” Activity completes representing the Transition Trigger event reflecting the watch has started successfully.

Upon the StartTheWatch event, the StartedSuccessful condition is evaluated. If false, the Transition won’t be executed and the Trigger Activity will be rescheduled.

A transition can contain a Transition Action which will be executed after exiting the source State and before entering the destination State.

Null and Shared Trigger

Many States simply need to automatically transition after the Entry Action is completed. In WF4, we support a default Trigger using a “Null” Trigger Action. A Trigger configured without a Trigger Activity will be fired by default upon entering the State, after the State’s Entry Action has been completed. Transition Conditions will still be evaluated.

You can also have multiple Transitions share the same Trigger. This type Trigger is called Shared Trigger. In the case of a shared Trigger, all the Transitions must have a condition specified.

In the Stop Watch example, when the user presses the “start” button, the stopwatch first checks the status of the battery. If there is power remaining, the state machine will transition to the Started State. If there’s insufficient power, then the State Machine will transition to the Off State. Now let us modify the Stop Watch to add a Shared Trigger Transition “OutofBattery”.

To create a Shared Trigger Transition “OutOfBattery”, we drag a Transition line from the same source State connector used by the “Start clock” Transition.

Here is the Transition designer view of “OutOfBattery” Shared Trigger Transition.

These two Transitions, “Start clock” and “OutOfBattery”, are sharing the same Trigger event “StartTheWatch” Activity.

A Shared Trigger allows for the conditional progression to a next state based on the evaluation of expressions configured for multiple Transitions which share a common Trigger event.

In this example here, if Stop Watch isn’t started successfully, it will proceed down the “OutOfBattery” Transition and then move to state “Off”.

Additional WF4 State Machine features

Auto Insert and connect In WF3, it takes several steps to insert a new state and a transition. The user will need to manually create transitions when introducing a new State. Adding a new State to existing StateMachine in WF4 becomes much easier with “auto insert” and “auto connect” designer enhancements.

Tracking WF4 provides the State level tracking ability to enable tracking when a WF instance enters each state. In StateMachine library, there is a public member “StateMachineStateRecord”, which is built on top of CustomTrackingRecord. Users can write a custom TrackingParticipant to track StateMachine events to get the history of States.

Debugging Users can set breakpoints on any Activity in a State or Transition.

State Variable Users can specify variables in the scope of a StateMachine or a State in WF4.

Additional references

To learn more about the object model for WF4 State Machine and its usage, please refer to the following MSDN documents: Getting Started Tutorial: How to Create a State Machine Workflow, State Machine Activity Designers, State Machine Workflows. Also, please check out our great new Hands on Lab for State Machine. It should be very helpful to get you started on using WF4 State Machine.

WCF Extensibility – Runtime

CarlosFigueira — Tue, 19 Apr 2011 18:29:37 GMT

This post is part of a series about WCF extensibility points. For a list of all previous posts and planned future ones, go to the index page.

Before starting on the actual extensibility points for the WCF runtime (first post should be online tomorrow), I decided to write this quick introduction to the runtime itself. Unlike the behaviors, which are invoked when the WCF stack is being created, the runtime extensions are invoked when actual messages are being sent / received by WCF. As could be seen in the usage examples for the behaviors, they were merely used to set up some extension points in the runtime, and those are the ones which did the “real work”.

The majority of the next posts in this series will talk about these runtime extensions. Their interfaces are defined under the System.ServiceModel.Dispatcher namespace, and unlike the behaviors they don’t follow any common pattern – they’re tailored for their specific task. Some of those interfaces apply to both client and server side of communication (parameter inspector, channel initializer, etc.), some apply to the server only (instance provider, dispatch message inspector, etc.), and some to the client only (client message inspector, interactive context initializer, etc.). The interfaces section of the namespace page has a brief description of each one of the interfaces, and their blog entries will have a more detailed description for them.

Adding runtime extensions to WCF

In many cases (again, as seen in the examples for the behaviors), more than one of those extensions are needed to accomplish a task for a specific scenario. One thing that I didn’t know until a couple of days ago was exactly the order in which each of these extensibility points are called, so I decided to write a simple program, adding hooks to all of the runtime extensibility points to see what would come out. This actually helped me to understand their role in the whole message stack, and it can be used as a simple one-stop place if you’re ever wondering where to add a hook to one of the extensibility points listed in here.

 class MyDispatchMessageInspector : IDispatchMessageInspector
{
    public MyDispatchMessageInspector()
    {
    }
 
    public object AfterReceiveRequest(ref Message request, IClientChannel channel, InstanceContext instanceContext)
    {
        ColorConsole.WriteLine(ConsoleColor.Cyan, "{0}.{1}", this.GetType().Name, ReflectionUtil.GetMethodSignature(MethodBase.GetCurrentMethod()));
        return null;
    }
 
    public void BeforeSendReply(ref Message reply, object correlationState)
    {
        ColorConsole.WriteLine(ConsoleColor.Cyan, "{0}.{1}", this.GetType().Name, ReflectionUtil.GetMethodSignature(MethodBase.GetCurrentMethod()));
    }
}
 
class MyDispatchMessageFormatter : IDispatchMessageFormatter
{
    IDispatchMessageFormatter inner;
    public MyDispatchMessageFormatter(IDispatchMessageFormatter inner)
    {
        this.inner = inner;
    }
 
    public void DeserializeRequest(Message message, object[] parameters)
    {
        ColorConsole.WriteLine(ConsoleColor.Cyan, "{0}.{1}", this.GetType().Name, ReflectionUtil.GetMethodSignature(MethodBase.GetCurrentMethod()));
        this.inner.DeserializeRequest(message, parameters);
    }
 
    public Message SerializeReply(MessageVersion messageVersion, object[] parameters, object result)
    {
        ColorConsole.WriteLine(ConsoleColor.Cyan, "{0}.{1}", this.GetType().Name, ReflectionUtil.GetMethodSignature(MethodBase.GetCurrentMethod()));
        return this.inner.SerializeReply(messageVersion, parameters, result);
    }
}
 
class MyClientMessageInspector : IClientMessageInspector
{
    public MyClientMessageInspector()
    {
    }
 
    public void AfterReceiveReply(ref Message reply, object correlationState)
    {
        ColorConsole.WriteLine(ConsoleColor.Yellow, "{0}.{1}", this.GetType().Name, ReflectionUtil.GetMethodSignature(MethodBase.GetCurrentMethod()));
    }
 
    public object BeforeSendRequest(ref Message request, IClientChannel channel)
    {
        ColorConsole.WriteLine(ConsoleColor.Yellow, "{0}.{1}", this.GetType().Name, ReflectionUtil.GetMethodSignature(MethodBase.GetCurrentMethod()));
        return null;
    }
}
 
class MyClientMessageFormatter : IClientMessageFormatter
{
    IClientMessageFormatter inner;
    public MyClientMessageFormatter(IClientMessageFormatter inner)
    {
        this.inner = inner;
    }
 
    public object DeserializeReply(Message message, object[] parameters)
    {
        ColorConsole.WriteLine(ConsoleColor.Yellow, "{0}.{1}", this.GetType().Name, ReflectionUtil.GetMethodSignature(MethodBase.GetCurrentMethod()));
        return this.inner.DeserializeReply(message, parameters);
    }
 
    public Message SerializeRequest(MessageVersion messageVersion, object[] parameters)
    {
        ColorConsole.WriteLine(ConsoleColor.Yellow, "{0}.{1}", this.GetType().Name, ReflectionUtil.GetMethodSignature(MethodBase.GetCurrentMethod()));
        return this.inner.SerializeRequest(messageVersion, parameters);
    }
}
 
class MyDispatchOperationSelector : IDispatchOperationSelector
{
    public string SelectOperation(ref Message message)
    {
        ColorConsole.WriteLine(ConsoleColor.Cyan, "{0}.{1}", this.GetType().Name, ReflectionUtil.GetMethodSignature(MethodBase.GetCurrentMethod()));
        string action = message.Headers.Action;
        string method = action.Substring(action.LastIndexOf('/') + 1);
        return method;
    }
}
 
class MyParameterInspector : IParameterInspector
{
    ConsoleColor consoleColor;
    bool isServer;
    public MyParameterInspector(bool isServer)
    {
        this.isServer = isServer;
        this.consoleColor = isServer ? ConsoleColor.Cyan : ConsoleColor.Yellow;
    }
 
    public void AfterCall(string operationName, object[] outputs, object returnValue, object correlationState)
    {
        ColorConsole.WriteLine(this.consoleColor, "{0}.{1}", this.GetType().Name, ReflectionUtil.GetMethodSignature(MethodBase.GetCurrentMethod()));
    }
 
    public object BeforeCall(string operationName, object[] inputs)
    {
        ColorConsole.WriteLine(this.consoleColor, "{0}.{1}", this.GetType().Name, ReflectionUtil.GetMethodSignature(MethodBase.GetCurrentMethod()));
        return null;
    }
}
 
class MyCallContextInitializer : ICallContextInitializer
{
    public void AfterInvoke(object correlationState)
    {
        ColorConsole.WriteLine(ConsoleColor.Cyan, "{0}.{1}", this.GetType().Name, ReflectionUtil.GetMethodSignature(MethodBase.GetCurrentMethod()));
    }
 
    public object BeforeInvoke(InstanceContext instanceContext, IClientChannel channel, Message message)
    {
        ColorConsole.WriteLine(ConsoleColor.Cyan, "{0}.{1}", this.GetType().Name, ReflectionUtil.GetMethodSignature(MethodBase.GetCurrentMethod()));
        return null;
    }
}
 
class MyOperationInvoker : IOperationInvoker
{
    IOperationInvoker inner;
    public MyOperationInvoker(IOperationInvoker inner)
    {
        this.inner = inner;
    }
 
    public object[] AllocateInputs()
    {
        ColorConsole.WriteLine(ConsoleColor.Cyan, "{0}.{1}", this.GetType().Name, ReflectionUtil.GetMethodSignature(MethodBase.GetCurrentMethod()));
        return this.inner.AllocateInputs();
    }
 
    public object Invoke(object instance, object[] inputs, out object[] outputs)
    {
        ColorConsole.WriteLine(ConsoleColor.Cyan, "{0}.{1}", this.GetType().Name, ReflectionUtil.GetMethodSignature(MethodBase.GetCurrentMethod()));
        return this.inner.Invoke(instance, inputs, out outputs);
    }
 
    public IAsyncResult InvokeBegin(object instance, object[] inputs, AsyncCallback callback, object state)
    {
        ColorConsole.WriteLine(ConsoleColor.Cyan, "{0}.{1}", this.GetType().Name, ReflectionUtil.GetMethodSignature(MethodBase.GetCurrentMethod()));
        return this.inner.InvokeBegin(instance, inputs, callback, state);
    }
 
    public object InvokeEnd(object instance, out object[] outputs, IAsyncResult result)
    {
        ColorConsole.WriteLine(ConsoleColor.Cyan, "{0}.{1}", this.GetType().Name, ReflectionUtil.GetMethodSignature(MethodBase.GetCurrentMethod()));
        return this.inner.InvokeEnd(instance, out outputs, result);
    }
 
    public bool IsSynchronous
    {
        get
        {
            ColorConsole.WriteLine(ConsoleColor.Cyan, "{0}.{1}", this.GetType().Name, ReflectionUtil.GetMethodSignature(MethodBase.GetCurrentMethod()));
            return this.inner.IsSynchronous;
        }
    }
}
 
class MyInstanceProvider : IInstanceProvider
{
    Type serviceType;
    public MyInstanceProvider(Type serviceType)
    {
        this.serviceType = serviceType;
    }
 
    public object GetInstance(InstanceContext instanceContext, Message message)
    {
        ColorConsole.WriteLine(ConsoleColor.Cyan, "{0}.{1}", this.GetType().Name, ReflectionUtil.GetMethodSignature(MethodBase.GetCurrentMethod()));
        return Activator.CreateInstance(this.serviceType);
    }
 
    public object GetInstance(InstanceContext instanceContext)
    {
        ColorConsole.WriteLine(ConsoleColor.Cyan, "{0}.{1}", this.GetType().Name, ReflectionUtil.GetMethodSignature(MethodBase.GetCurrentMethod()));
        return Activator.CreateInstance(this.serviceType);
    }
 
    public void ReleaseInstance(InstanceContext instanceContext, object instance)
    {
        ColorConsole.WriteLine(ConsoleColor.Cyan, "{0}.{1}", this.GetType().Name, ReflectionUtil.GetMethodSignature(MethodBase.GetCurrentMethod()));
    }
}
 
class MyInstanceContextProvider : IInstanceContextProvider
{
    IInstanceContextProvider inner;
    public MyInstanceContextProvider(IInstanceContextProvider inner)
    {
        this.inner = inner;
    }
 
    public InstanceContext GetExistingInstanceContext(Message message, IContextChannel channel)
    {
        ColorConsole.WriteLine(ConsoleColor.Cyan, "{0}.{1}", this.GetType().Name, ReflectionUtil.GetMethodSignature(MethodBase.GetCurrentMethod()));
        return this.inner.GetExistingInstanceContext(message, channel);
    }
 
    public void InitializeInstanceContext(InstanceContext instanceContext, Message message, IContextChannel channel)
    {
        ColorConsole.WriteLine(ConsoleColor.Cyan, "{0}.{1}", this.GetType().Name, ReflectionUtil.GetMethodSignature(MethodBase.GetCurrentMethod()));
        this.inner.InitializeInstanceContext(instanceContext, message, channel);
    }
 
    public bool IsIdle(InstanceContext instanceContext)
    {
        ColorConsole.WriteLine(ConsoleColor.Cyan, "{0}.{1}", this.GetType().Name, ReflectionUtil.GetMethodSignature(MethodBase.GetCurrentMethod()));
        return this.inner.IsIdle(instanceContext);
    }
 
    public void NotifyIdle(InstanceContextIdleCallback callback, InstanceContext instanceContext)
    {
        ColorConsole.WriteLine(ConsoleColor.Cyan, "{0}.{1}", this.GetType().Name, ReflectionUtil.GetMethodSignature(MethodBase.GetCurrentMethod()));
        this.inner.NotifyIdle(callback, instanceContext);
    }
}
 
class MyInstanceContextInitializer : IInstanceContextInitializer
{
    public void Initialize(InstanceContext instanceContext, Message message)
    {
        ColorConsole.WriteLine(ConsoleColor.Cyan, "{0}.{1}", this.GetType().Name, ReflectionUtil.GetMethodSignature(MethodBase.GetCurrentMethod()));
    }
}
 
class MyChannelInitializer : IChannelInitializer
{
    ConsoleColor consoleColor;
    public MyChannelInitializer(bool isServer)
    {
        this.consoleColor = isServer ? ConsoleColor.Cyan : ConsoleColor.Yellow;
    }
    public void Initialize(IClientChannel channel)
    {
        ColorConsole.WriteLine(this.consoleColor, "{0}.{1}", this.GetType().Name, ReflectionUtil.GetMethodSignature(MethodBase.GetCurrentMethod()));
    }
}
 
class MyClientOperationSelector : IClientOperationSelector
{
    public bool AreParametersRequiredForSelection
    {
        get
        {
            ColorConsole.WriteLine(ConsoleColor.Yellow, "{0}.{1}", this.GetType().Name, ReflectionUtil.GetMethodSignature(MethodBase.GetCurrentMethod()));
            return false;
        }
    }
 
    public string SelectOperation(MethodBase method, object[] parameters)
    {
        ColorConsole.WriteLine(ConsoleColor.Yellow, "{0}.{1}", this.GetType().Name, ReflectionUtil.GetMethodSignature(MethodBase.GetCurrentMethod()));
        return method.Name;
    }
}
 
class MyInteractiveChannelInitializer : IInteractiveChannelInitializer
{
    public IAsyncResult BeginDisplayInitializationUI(IClientChannel channel, AsyncCallback callback, object state)
    {
        ColorConsole.WriteLine(ConsoleColor.Yellow, "{0}.{1}", this.GetType().Name, ReflectionUtil.GetMethodSignature(MethodBase.GetCurrentMethod()));
        Action act = new Action(this.DoNothing);
        return act.BeginInvoke(callback, state);
    }
 
    public void EndDisplayInitializationUI(IAsyncResult result)
    {
        ColorConsole.WriteLine(ConsoleColor.Yellow, "{0}.{1}", this.GetType().Name, ReflectionUtil.GetMethodSignature(MethodBase.GetCurrentMethod()));
    }
 
    private void DoNothing() { }
}
 
class MyErrorHandler : IErrorHandler
{
    public bool HandleError(Exception error)
    {
        ColorConsole.WriteLine(ConsoleColor.Cyan, "{0}.{1}", this.GetType().Name, ReflectionUtil.GetMethodSignature(MethodBase.GetCurrentMethod()));
        return error is ArgumentException;
    }
 
    public void ProvideFault(Exception error, MessageVersion version, ref Message fault)
    {
        ColorConsole.WriteLine(ConsoleColor.Cyan, "{0}.{1}", this.GetType().Name, ReflectionUtil.GetMethodSignature(MethodBase.GetCurrentMethod()));
        MessageFault messageFault = MessageFault.CreateFault(new FaultCode("FaultCode"), new FaultReason(error.Message));
        fault = Message.CreateMessage(version, messageFault, "FaultAction");
    }
}
 
[ServiceContract]
public interface ITest
{
    [OperationContract]
    int Add(int x, int y);
    [OperationContract(IsOneWay = true)]
    void Process(string text);
}
 
[ServiceBehavior(IncludeExceptionDetailInFaults = true)]
public class Service : ITest
{
    public int Add(int x, int y)
    {
        ColorConsole.WriteLine(ConsoleColor.Green, "In service operation '{0}'", MethodBase.GetCurrentMethod().Name);
 
        if (x == 0 && y == 0)
        {
            throw new ArgumentException("This will cause IErrorHandler to be called");
        }
        else
        {
            return x + y;
        }
    }
 
    public void Process(string text)
    {
        ColorConsole.WriteLine(ConsoleColor.Green, "In service operation '{0}'", MethodBase.GetCurrentMethod().Name);
    }
}
 
class MyBehavior : IOperationBehavior, IContractBehavior
{
    public void AddBindingParameters(OperationDescription operationDescription, BindingParameterCollection bindingParameters)
    {
    }
 
    public void ApplyClientBehavior(OperationDescription operationDescription, ClientOperation clientOperation)
    {
        clientOperation.Formatter = new MyClientMessageFormatter(clientOperation.Formatter);
        clientOperation.ParameterInspectors.Add(new MyParameterInspector(false));
    }
 
    public void ApplyDispatchBehavior(OperationDescription operationDescription, DispatchOperation dispatchOperation)
    {
        dispatchOperation.CallContextInitializers.Add(new MyCallContextInitializer());
        dispatchOperation.Formatter = new MyDispatchMessageFormatter(dispatchOperation.Formatter);
        dispatchOperation.Invoker = new MyOperationInvoker(dispatchOperation.Invoker);
        dispatchOperation.ParameterInspectors.Add(new MyParameterInspector(true));
    }
 
    public void Validate(OperationDescription operationDescription)
    {
    }
 
    public void AddBindingParameters(ContractDescription contractDescription, ServiceEndpoint endpoint, BindingParameterCollection bindingParameters)
    {
    }
 
    public void ApplyClientBehavior(ContractDescription contractDescription, ServiceEndpoint endpoint, ClientRuntime clientRuntime)
    {
        clientRuntime.ChannelInitializers.Add(new MyChannelInitializer(false));
        clientRuntime.InteractiveChannelInitializers.Add(new MyInteractiveChannelInitializer());
        clientRuntime.MessageInspectors.Add(new MyClientMessageInspector());
        clientRuntime.OperationSelector = new MyClientOperationSelector();
    }
 
    public void ApplyDispatchBehavior(ContractDescription contractDescription, ServiceEndpoint endpoint, DispatchRuntime dispatchRuntime)
    {
        dispatchRuntime.ChannelDispatcher.ChannelInitializers.Add(new MyChannelInitializer(true));
        dispatchRuntime.ChannelDispatcher.ErrorHandlers.Add(new MyErrorHandler());
        dispatchRuntime.InstanceContextInitializers.Add(new MyInstanceContextInitializer());
        dispatchRuntime.InstanceContextProvider = new MyInstanceContextProvider(dispatchRuntime.InstanceContextProvider);
        dispatchRuntime.InstanceProvider = new MyInstanceProvider(dispatchRuntime.ChannelDispatcher.Host.Description.ServiceType);
        dispatchRuntime.MessageInspectors.Add(new MyDispatchMessageInspector());
        dispatchRuntime.OperationSelector = new MyDispatchOperationSelector();
    }
 
    public void Validate(ContractDescription contractDescription, ServiceEndpoint endpoint)
    {
    }
}
 
static class ColorConsole
{
    static object syncRoot = new object();
 
    public static void WriteLine(ConsoleColor color, string text, params object[] args)
    {
        if (args != null && args.Length > 0)
        {
            text = string.Format(CultureInfo.InvariantCulture, text, args);
        }
 
        lock (syncRoot)
        {
            Console.ForegroundColor = color;
            Console.WriteLine("[{0}] {1}", DateTime.Now.ToString("HH:mm:ss.fff", CultureInfo.InvariantCulture), text);
            Console.ResetColor();
        }
 
        Thread.Sleep(50);
    }
 
    public static void WriteLine(string text, params object[] args)
    {
        Console.WriteLine(text, args);
    }
 
    public static void WriteLine(object obj)
    {
        Console.WriteLine(obj);
    }
}
 
static class ReflectionUtil
{
    public static string GetMethodSignature(MethodBase method)
    {
        StringBuilder sb = new StringBuilder();
        sb.Append(method.Name);
        sb.Append("(");
        ParameterInfo[] parameters = method.GetParameters();
        for (int i = 0; i < parameters.Length; i++)
        {
            if (i > 0) sb.Append(", ");
            sb.Append(parameters[i].ParameterType.Name);
        }
        sb.Append(")");
        return sb.ToString();
    }
}
 
class Program
{
    static void Main(string[] args)
    {
        string baseAddress = "http://" + Environment.MachineName + ":8000/Service";
        using (ServiceHost host = new ServiceHost(typeof(Service), new Uri(baseAddress)))
        {
            ServiceEndpoint endpoint = host.AddServiceEndpoint(typeof(ITest), new BasicHttpBinding(), "");
            endpoint.Contract.Behaviors.Add(new MyBehavior());
            foreach (OperationDescription operation in endpoint.Contract.Operations)
            {
                operation.Behaviors.Add(new MyBehavior());
            }
 
            host.Open();
            ColorConsole.WriteLine("Host opened");
 
            using (ChannelFactory<ITest> factory = new ChannelFactory<ITest>(new BasicHttpBinding(), new EndpointAddress(baseAddress)))
            {
                factory.Endpoint.Contract.Behaviors.Add(new MyBehavior());
                foreach (OperationDescription operation in factory.Endpoint.Contract.Operations)
                {
                    operation.Behaviors.Add(new MyBehavior());
                }
 
                ITest proxy = factory.CreateChannel();
                ColorConsole.WriteLine("Calling operation");
                ColorConsole.WriteLine(proxy.Add(3, 4));
 
                ColorConsole.WriteLine("Called operation, calling it again, this time it the service will throw");
                try
                {
                    ColorConsole.WriteLine(proxy.Add(0, 0));
                }
                catch (Exception e)
                {
                    ColorConsole.WriteLine(ConsoleColor.Red, "{0}: {1}", e.GetType().Name, e.Message);
                }
 
                ColorConsole.WriteLine("Now calling an OneWay operation");
                proxy.Process("hello");
 
                ((IClientChannel)proxy).Close();
            }
        }
 
        ColorConsole.WriteLine("Done");
    }
}
 

When run, the program will show when each method of the extension interfaces are called. The server ones are written in blue, while the ones from the client side are written in yellow, to make it easier to differentiate where each trace is coming from.

Coming up

The inspection interfaces, starting with the message inspectors, then the parameter inspectors.

[Code in this post]

[Back to the index]

Carlos Figueira
http://blogs.msdn.com/carlosfigueira
Twitter: @carlos_figueira http://twitter.com/carlos_figueira

Microsoft .NET Framework 4 Platform Update 1

Steve Danielson — Mon, 18 Apr 2011 21:44:00 GMT

The Microsoft .NET Framework 4 Platform Update 1 released today, 4/18/2011.

The Microsoft .NET Framework 4 Platform Update 1 is a platform update that is a set of new features that provides additional functionality for top customer requests and important scenarios.

The features that are enabled in this update are:

Windows Workflow Foundation (WF)

State machine workflows
SqlWorkflowInstanceStore support for SQL Azure
- The scripts that create the persistence database are modified to be compatible with Sql Azure
- Retry semantics have been added and new error codes added that are specific to SQL Azure scenarios
- For more information, see the More Information section of KB2478063
CompensationExtension class, which enables custom workflow hosts to use WF4 compensation

The Microsoft .NET Platform Update 1 consists of three packages:

Microsoft .NET Framework 4 Platform Update 1 (KB2478063)
- This package contains the runtime files for the platform update. This package must be deployed on systems where applications that target the platform update are deployed.
Multi-Targeting Pack for Microsoft .NET Framework 4 Platform Update 1 (KB2495638)
- This package contains reference assemblies and intellisense files for the platform update. This package is installed as part of the next package.
Microsoft .NET Framework 4 Platform Update 1 – Design-time Package for Visual Studio 2010 SP1 (KB2495593)
- This package installs the previous two packages and configures Visual Studio 2010 SP1 with new .NET Framework targeting profiles, intellisense, and adds the state machine activities to the toolbox.

To develop workflow applications in Visual Studio 2010 SP1 that target the new Platform Update 1 functionality, the Microsoft .NET Framework 4 Platform Update 1 – Design-time Package for Visual Studio 2010 SP1 (KB2495593) must be installed. Once it is installed, the .NET Framework 4 Platform Update 1 (KB2478063) profile can be chosen when creating a new .NET application.

There are two new profiles added to Visual Studio when the Design-time Package for Visual Studio 2010 SP1 (KB2495593) is installed.

.NET Framework 4 Platform Update 1 (KB2478063)
.NET Framework 4 Client Profile Platform Update 1 (KB2478063)

When a new project is created with the platform update profile selected, the .NET Framework 4 Client Profile Platform Update 1 (KB2478063) is used. The .NET Framework 4 Platform Update 1 (KB2478063) profile builds on the .NET Framework 4 profile, and the .NET Framework 4 Client Profile Platform Update 1 (KB2478063) profile builds on the .NET Framework 4 Client Profile. The .NET Framework 4 Client Profile is a subset of the .NET Framework 4 that is optimized for client applications. For more information, see .NET Framework Client Profile.

To choose either profile or change the profile after a project has been created, right-click the project in Solution Explorer, choose Properties, and select the desired profile from the Target framework drop-down.

When either of these profiles is selected, the features in the platform update are available and the State Machine activities are available in the Toolbox.

To configure .NET Framework 4 Platform Update 1 on computers with Visual Studio 2010 SP1 that are going to be used to develop applications that target the functionality in the platform update, install Microsoft .NET Framework 4 Platform Update 1 – Design-time Package for Visual Studio 2010 SP1 (KB2495593).

Note: Microsoft Visual Studio 2010 Service Pack 1 is required to install the Design-time Package for Visual Studio 2010 SP1 (KB2495593)

To configure a computer on which applications that target the .NET Framework 4 Platform Update 1 are to be deployed, deploy Microsoft .NET Framework 4 Platform Update 1 (KB2478063) and the appropriate version of the .NET Framework 4.

If the application targets .NET Framework 4 Client Profile Platform Update 1 (KB2478063), you must also deploy either:
- Microsoft .NET Framework 4
- Microsoft .NET Framework 4 Client Profile
If the application targets .NET Framework 4 Platform Update 1 (KB2478063), you must also deploy:
- Microsoft .NET Framework 4

For information on how to use the new state machine functionality in .NET Framework 4 Platform Update 1, see:

WF 4 hosting options: IIS, AppFabric, and Windows Service

Patrick D. Fletcher [MSFT] — Mon, 18 Apr 2011 20:29:33 GMT

Most of the Windows Workflow Foundation samples use workflows that are hosted in a console application, but this isn't a realistic scenario for real-world workflows. Workflows in actual business applications will be hosted in persistent processes- either a Windows service authored by the developer, or a server application such as IIS or AppFabric. The differences between these approaches are as follows.

Hosting workflows in IIS with Windows AppFabric

Using IIS with AppFabric is the preferred host for workflows. The host application for workflows using AppFabric is Windows Activation Service, which removes the dependency on HTTP over IIS alone.

Hosting workflows in IIS

Using IIS alone is not recommended, as there are management and monitoring tools available with AppFabric that facilitate maintenance of running applications. Workflows should only be hosted in IIS alone if there are infrastructure concerns with moving to AppFabric.

Hosting a workflow in a custom Windows Service

Creating a custom workflow service to host the workflow will require the developer to duplicate a lot of the functionality provided out-of-box by AppFabric, but will allow for more flexibility with custom functionality. This option should only be considered if AppFabric proves to not be an option.

WF4 Versioning Spike: Planning for Change

Ron Jacobs — Wed, 13 Apr 2011 14:20:03 GMT

In my investigation of versioning issues with Windows Workflow Foundation I’ve come to one important conclusion. This isn’t something new, in fact at TechEd 2008 when I gave my very first “chalk talk” about WF3.5 I said that this issue (versioning) was going to be something that you must plan for.

As architects and developers, we are often so focused on getting to Version 1 we rarely think about what will happen when we need to move to Version 2. Of course, we know version 2 is going to happen (Unless version 1 is so bad that nobody wants version 2). So let’s think about this for a moment…

What is this versioning problem?

Let’s think about this problem outside of the context of workflow for a moment. Remember when you first learned about objects? They told you that objects consist of three elements identity, state and behavior.

Over time you learned that you could make a copy of the state and save it somewhere else (like a database) and then at some later point, load the state back into your object. When you did this you opened the door to the problem of versioning.

Your object (v1) creates state which we could think of as (s1).

Then at some later time you load the state (s1) back into your object (v1) and everything is great. But then change happens…
You change your class definition in some way and when you load your state…

Ok – well maybe it doesn’t go boom but it could. Of course it depends on the kind of change you made to the behavior of your object. State is not just data, it is data with meaning and the meaning it has depends (to some degree) on your intention as the designer of the behavior. And obviously if you changed the behavior in a very significant way, the state might go boom when you try to load it.

Now let’s consider a Workflow in the same situation. The biggest difference is that with a workflow you don’t create the instance. In fact, the only thing you create is the Workflow Definition and you hand that to the Workflow Runtime which creates the Workflow Instance (which you never actually see because it is hidden inside the Workflow Runtime).

What happens when you change your workflow runtime and load a persisted instance?

Yes.. things go boom. And unlike the object example there is very little you can do about this one. The state is created and managed by the workflow runtime. You don’t have the same opportunity to get in the middle of this and fix it as you do when you write the code that manages the state.

In the next release of .NET we are adding a feature called Dynamic Update which offers one path to fixing up the state so that it does not go boom but here today I’m speaking only of how .NET 4 behaves.

Planning for Change

Now that we know what the problem is we can come up with a way to think about change and the first truth we must consider is that we must plan for change. We know that change will happen and I am asserting that planned change is always better than unplanned change (at least when it comes to software).

In my previous post on this versioning spike I described two scenarios for change. The first question we want to ask will help us decide which scenario we are facing.

Can we allow persisted instances to complete?

Side By Side Version Aware Routing

Suppose we have 1000 persisted workflow instances which were created with V1. We need to decide if these workflow instances can complete using the V1 definition. I we can allow them to complete then our versioning problem becomes a message routing problem. What we must do is figure out a way to route messages meant for V1 instances to be routed to V1 instances and all other messages will route to V2 instances. If you want to see an example of doing this check out the AppFabric Reference Implementation: Managing the LifeCycle of a WorkFlow Service

If that solves your problem then GoTo(EndOfBlog) Else ReadOn()

Are the changes breaking?

Maybe we decide that we can’t allow our persisted instances to complete because of a policy change or perhaps there is a bug in our workflow. If that is the case we need to figure out if there is a way we can make the necessary change without causing the workflow to go boom when we load it.

A Change Is Breaking If…

It causes the workflow to go boom when you load it
It produces an incorrect result

Our official position on the Workflow team is that any change is a breaking change. Why? Because the truth is that there are so many ways your change could break things that we can’t possibly say that any given change is safe. However as you saw in my previous post there are some changes which might work but you can’t know for sure until you test them. You do have tests don’t you?

Sometimes the change is breaking when the logic of the workflow is broken by the change. Imagine a workflow which loops and accumulates a result. I can look in the Instance Store and see that I have a persisted instance which is in the middle of that loop. If I make a change to the way the result is accumulated is that a breaking change?

The answer depends on which iteration of the loop we are in. If it is the first iteration then the change is not breaking because we have not accumulated a result yet. If it is any other value then it is not safe to change the expression which calculates the result because part of the accumulated result will have been accumulated under the old behavior and part from the new behavior. There is no way we can produce a correct result in this scenario.

If The Change Is Breaking

If the change is breaking then there is no safe means to upgrade persisted instances. That leaves us only one option… Delete and Resubmit.

How do we delete a persisted instance?

First you have to find it. If you look in the InstancesTable (if you are using SqlWorkflowInstanceStore) you will see a lot of Guids and Binary data. It is difficult to know which Instance you are looking for unless you have planned for it. You need to store a human readable identifier of some kind that you can link to the InstanceId. That way you can find and delete the correct record.

Where should you store this identifier?

You can store it in the InstanceStore or you can store it in another database. SqlWorkflowInstanceStore provides a mechanism for doing this called PromotedProperties. This is the good news. The bad news is that using PromotedProperties is not as easy or simple as it should be. Fortunately we do have sample code in the WF4 Samples which includes a Property Promotion activity.

If you use this technique you can get the InstanceId and whatever other values you need to make a decision and these values will end up in the InstancePromotedProperties table. Then when the workflow completes these values will get cleaned up like the rest of the instance data.

Of course, you can always store these values in some other database if you like. Then you have to come up with a way to clear out the values as workflows complete. I tried both ways and once I got comfortable with PromotedProperties I think I would say that I prefer that approach.

How do you resubmit?

In order to resubmit you have to save the data that started your workflow somewhere. Once again using PromotedProperties is a pretty good approach for doing this. If you decide you need to resubmit you simply grab the values that started the workflow and send them in to start a new instance.

But.. be careful. Your workflow may have already done some work under the old (V1) definition. Now that work will be repeated under (V2) unless you take some action to prevent it. Ideally you should make your work idempotent then it won’t matter if it gets done more than once.

To see how I worked through this problem, watch the following video.

Happy Coding!
Ron Jacobs
http://blogs.msdn.com/rjacobs
Twitter: @ronljacobs http://twitter.com/ronljacobs

WCF Extensibility - IOperationBehavior

CarlosFigueira — Tue, 12 Apr 2011 15:40:00 GMT

This post is part of a series about WCF extensibility points. For a list of all previous posts and planned future ones, go to the index page.

The last of the behavior interfaces in WCF is the IOperationBehavior. The scope of this one is limited to an individual operation, so one can have different operations in the same contract. For example, the OperationBehaviorAttribute can define that some specific operations in the contract will auto-complete transactions (if the operation returns successfully, i.e., does not throw an exception). Operation behaviors are typically used for those scenarios, when one wants fine-grained control over the operations in a service contract.

Public implementations in WCF

DataContractSerializerOperationBehavior: Defines the runtime behavior for the DataContractSerializer used to serialize the parameters to the operation.
XmlSerializerOperationBehavior: Defines the runtime behavior for the XmlSerializer used to serialize the parameters to the operation.
OperationBehaviorAttribute: Defines some attributes which apply to the operation, such as transaction parameters or impersonation options.
ReceiveContextEnabledAttribute: Defines that the operation controls the acknowledgement that the message was completely received. Used in queue scenarios.
TransactionFlowAttribute: Defines whether the operation accepts incoming transactions from a client.
AspNetCacheProfileAttribute: Defines the ASP.NET output cache profile for the operation.
WebGetAttribute: Indicates that the operation (in REST services) is a retrieval operation, to be consumed via HTTP GET requests.
WebInvokeAttribute: Indicates that the operation (in REST services) is an invoke operation, to be consumed via HTTP verbs other than GET.

Interface declaration

 public interface IOperationBehavior
{
    void AddBindingParameters(OperationDescription operationDescription, BindingParameterCollection bindingParameters);
    void ApplyClientBehavior(OperationDescription operationDescription, ClientOperation clientOperation);
    void ApplyDispatchBehavior(OperationDescription operationDescription, DispatchOperation dispatchOperation);
    void Validate(OperationDescription operationDescription);
}
 

Again, like in the previous behavior interfaces, Validate is called first, with the operation description passed as a parameter. If the behavior finds the description violating some of its logic, it should throw an exception to abort the host (or the client) from opening. AddBindingParameters is called next, and again this is not commonly used.

ApplyDispatchBehavior and ApplyClientBehavior are called last, and they receive the operation description and the operation runtime (DispatchOperation for the server side, ClientOperation for client side). Among the properties in the operation runtime which are commonly used are the list of parameter inspectors (client / server) and the message formatter (client / server), which will be covered later in this series.

How to add an operation behavior

Via service / endpoint / contract description (server): You can obtain a reference to the operation description via the contract description, and from there you can get a reference to the list of operation behaviors:

 string baseAddress = "http://" + Environment.MachineName + ":8000/Service";
ServiceHost host = new ServiceHost(typeof(Service), new Uri(baseAddress));
ServiceEndpoint endpoint = host.AddServiceEndpoint(typeof(ITest), new WSHttpBinding(), "");
foreach (OperationDescription od in endpoint.Contract.Operations)
{
    od.Behaviors.Add(new MyOperationBehavior());
}
 

Via channel factory / generated proxy (client): Like on the server side, once you get a reference to the endpoint, you can reference the contract, then the operation description collection. Notice that (just like in the service) you don’t need to enumerate all the operations, you can select by name to apply the behavior to specific operations.

 ChannelFactory<ITest> factory = new ChannelFactory<ITest>(binding, new EndpointAddress(address));
factory.Endpoint.Contract.Operations.Find("Add").Behaviors.Add(new MyOperationBehavior());
 

Via attributes: If the operation behavior is derived from System.Attribute, it can be applied to the operation, either at the contract interface or at the actual implementation of the operation in the service code, and it will be added to the operation description by WCF. Adding it to both places is the same as adding it to a single one (the list of behaviors is a dictionary keyed by the behavior type, so a behavior collection cannot have more than one instance of each type).

 public class MyOperationBehaviorAttribute : Attribute, IOperationBehavior
{
    // IOperationBehavior implementation
}
[ServiceContract]
public interface ICalculator
{
    [OperationContract]
    [MyOperationBehavior]
    int Add(int x, int y);
    [OperationContract]
    int Multiply(int x, int y);
}
public class CalculatorService : ICalculator
{
    public int Add(int x, int y)
    {
        return x + y;
    }
 
    [MyOperationBehavior]
    public int Multiply(int x, int y)
    {
        return x * y;
    }
}
 

Using configuration: Configuration is not an option for adding operation behaviors.

Real world scenario: a better parameter inspector

The IParameterInspector interface is a great way to analyze the inputs and outputs to operations in WCF services – it provides a callback where one can look, log, change, etc. the input and output parameters. It also lets the users see the return value of the operation, but doesn’t let the inspector change it. A few posts from the forums needed to actually change the return value as well. In one of them, the user Antonello Tesoro offered a great, simple suggestion on how to implement such inspector (wrapping an operation invoker), and I’ll implement his idea to show a real usage of operation behaviors.

And here goes the usual disclaimer – this is a sample for illustrating the topic of this post, this is not production-ready code. I tested it for a few contracts and it worked, but I cannot guarantee that it will work for all scenarios (please let me know if you find a bug or something missing). Also, for simplicity sake it doesn’t have a lot of error handling which a production-level code would, and doesn’t support all contract types (asynchronous operations, for example, are only partially supported). Finally, this sample (as well as most other samples in this series) uses extensibility points other than the one for this post (e.g., operation invoker) which are necessary to get a realistic scenario going. I’ll briefly describe what they do, and leave to their specific entries a more detailed description of their behavior.

First, let’s define the new inspector interface. It’s almost a copy of IParameterInspector, with the only difference being the returnValue parameter to AfterCall being passed as reference:

 public interface IBetterParameterInspector
{
    object BeforeCall(string operationName, object[] inputs);
    void AfterCall(string operationName, object[] outputs, ref object returnValue, object correlationState);
}
 

On to the behavior. On the call to ApplyDispatchBehavior, the DispatchOperation object is already created and populated. We’ll then replace the existing operation invoker with our own implementation, passing the existing one to it:

 public class BetterParameterInspectorOperationBehavior : IOperationBehavior
{
    IBetterParameterInspector inspector;
    public BetterParameterInspectorOperationBehavior(IBetterParameterInspector inspector)
    {
        if (inspector == null)
        {
            throw new ArgumentNullException("inspector");
        }
 
        this.inspector = inspector;
    }
 
    public void AddBindingParameters(OperationDescription operationDescription, BindingParameterCollection bindingParameters)
    {
    }
 
    public void ApplyClientBehavior(OperationDescription operationDescription, ClientOperation clientOperation)
    {
    }
 
    public void ApplyDispatchBehavior(OperationDescription operationDescription, DispatchOperation dispatchOperation)
    {
        dispatchOperation.Invoker = new BetterParameterInspectorOperationInvoker(operationDescription.Name, dispatchOperation.Invoker, this.inspector);
    }
 
    public void Validate(OperationDescription operationDescription)
    {
    }
}
 

The new operation invoker will simply delegate all the calls to the original invoker, calling the inspector before and after completing each call. On synchronous method implementations, the implementation of the correlation state is trivial – simply store the return value of BeforeCall in a local variable, invoke the operation, then use that variable as the correlationState parameter to AfterCall. On asynchronous operations, however, it isn’t as simple. For this sample, the code throws if an inspector to an asynchronous operation returns anything other than null on BeforeCall. To fully implement correlation state for such operations, we’d need to chain the asynchronous operation as described in http://blogs.msdn.com/b/carlosfigueira/archive/2009/07/23/chaining-async-calls-in-wcf-or-in-net-in-general.aspx – too complex for this sample.

 class BetterParameterInspectorOperationInvoker : IOperationInvoker
{
    string operationName;
    IOperationInvoker originalInvoker;
    IBetterParameterInspector inspector;
    public BetterParameterInspectorOperationInvoker(string operationName, IOperationInvoker originalInvoker, IBetterParameterInspector inspector)
    {
        this.operationName = operationName;
        this.originalInvoker = originalInvoker;
        this.inspector = inspector;
    }
 
    public object[] AllocateInputs()
    {
        return this.originalInvoker.AllocateInputs();
    }
 
    public object Invoke(object instance, object[] inputs, out object[] outputs)
    {
        object correlationState = this.inspector.BeforeCall(this.operationName, inputs);
        object result = this.originalInvoker.Invoke(instance, inputs, out outputs);
        this.inspector.AfterCall(this.operationName, outputs, ref result, correlationState);
        return result;
    }
 
    public IAsyncResult InvokeBegin(object instance, object[] inputs, AsyncCallback callback, object state)
    {
        object correlationState = this.inspector.BeforeCall(this.operationName, inputs);
        if (correlationState != null)
        {
            throw new InvalidOperationException("Correlation not implemented yet for asynchronous methods");
        }
 
        return this.originalInvoker.InvokeBegin(instance, inputs, callback, state);
    }
 
    public object InvokeEnd(object instance, out object[] outputs, IAsyncResult result)
    {
        object operationResult = this.originalInvoker.InvokeEnd(instance, out outputs, result);
        this.inspector.AfterCall(this.operationName, outputs, ref operationResult, null);
        return operationResult;
    }
 
    public bool IsSynchronous
    {
        get { return this.originalInvoker.IsSynchronous; }
    }
}
 

And that’s it. Now let’s put them to use. To test this scenario, I’ll define two service contract interfaces, one with synchronous operations, one with asynchronous ones.

 [ServiceContract]
public interface ITest
{
    [OperationContract]
    int Add(int x, int y);
    [OperationContract]
    int Subtract(int x, int y);
    [OperationContract]
    int Divide(int x, int y);
    [OperationContract]
    int Multiply(int x, int y);
}
 
[ServiceContract]
public interface ITestWithAsyncOperation
{
    [OperationContract(AsyncPattern = true)]
    IAsyncResult BeginEchoString(string text, AsyncCallback callback, object userState);
    string EndEchoString(IAsyncResult asyncResult);
}
 

Their implementations are trivial (for the asynchronous one we delegate to the Func<T,TResult> delegate and let it handle the asynchronous behavior for us).

 public class Service : ITest, ITestWithAsyncOperation
{
    public int Add(int x, int y)
    {
        int result = x + y;
        Console.WriteLine("{0} + {1} = {2}", x, y, result);
        return result;
    }
 
    public int Subtract(int x, int y)
    {
        int result = x - y;
        Console.WriteLine("{0} - {1} = {2}", x, y, result);
        return result;
    }
 
    public int Divide(int x, int y)
    {
        int result = x / y;
        Console.WriteLine("{0} / {1} = {2}", x, y, result);
        return result;
    }
 
    public int Multiply(int x, int y)
    {
        int result = x * y;
        Console.WriteLine("{0} * {1} = {2}", x, y, result);
        return result;
    }
 
    public IAsyncResult BeginEchoString(string text, AsyncCallback callback, object userState)
    {
        Func<string, string> func = this.EchoStringDoWork;
        return func.BeginInvoke(text, callback, userState);
    }
 
    public string EndEchoString(IAsyncResult asyncResult)
    {
        Func<string, string> func = ((System.Runtime.Remoting.Messaging.AsyncResult)asyncResult).AsyncDelegate as Func<string, string>;
        return func.EndInvoke(asyncResult);
    }
 
    private string EchoStringDoWork(string input) { return input; }
}
 

Now for setting up the service. This operation behavior needs an instance of an inspector, so it cannot be defined as an attribute (attribute arguments cannot be user-defined objects). We’ll define two inspectors, one for the calculator (no negative numbers) and one for the asynchronous operations (no null return values):

 class NoNegativesInspector : IBetterParameterInspector
{
    public object BeforeCall(string operationName, object[] inputs)
    {
        for (int i = 0; i < inputs.Length; i++)
        {
            inputs[i] = Math.Abs((int)inputs[i]);
        }
 
        return null;
    }
 
    public void AfterCall(string operationName, object[] outputs, ref object returnValue, object correlationState)
    {
        returnValue = Math.Abs((int)returnValue);
        if (outputs != null)
        {
            for (int i = 0; i < outputs.Length; i++)
            {
                outputs[i] = Math.Abs((int)outputs[i]);
            }
        }
    }
}
 
class NoNullReturnValue : IBetterParameterInspector
{
    public object BeforeCall(string operationName, object[] inputs)
    {
        return null;
    }
 
    public void AfterCall(string operationName, object[] outputs, ref object returnValue, object correlationState)
    {
        if (returnValue == null)
        {
            returnValue = "<<null>>";
        }
    }
}
 

Now for setting up the service itself (and calling it). In one of the endpoints the behavior is applied to all operations; in the other, the behavior is applied to one operation explicitly.

 static void Main(string[] args)
{
    string baseAddress = "http://" + Environment.MachineName + ":8000/Service";
    ServiceHost host = new ServiceHost(typeof(Service), new Uri(baseAddress));
    ServiceEndpoint endpoint = host.AddServiceEndpoint(typeof(ITest), new BasicHttpBinding(), "");
    ServiceEndpoint asyncEndpoint = host.AddServiceEndpoint(typeof(ITestWithAsyncOperation), new BasicHttpBinding(), "async");
 
    foreach (OperationDescription od in endpoint.Contract.Operations)
    {
        od.Behaviors.Add(new BetterParameterInspectorOperationBehavior(new NoNegativesInspector()));
    }
 
    asyncEndpoint.Contract.Operations.Find("EchoString").Behaviors.Add(
        new BetterParameterInspectorOperationBehavior(new NoNullReturnValue()));
    host.Open();
 
    ChannelFactory<ITest> factory = new ChannelFactory<ITest>(new BasicHttpBinding(), new EndpointAddress(baseAddress));
    ITest proxy = factory.CreateChannel();
    Console.WriteLine("Abs(Abs(33) + Abs(-44)) = {0}", proxy.Add(33, -44));
    Console.WriteLine("Abs(Abs(33) - Abs(-44)) = {0}", proxy.Subtract(33, -44));
    Console.WriteLine("Abs(Abs(33) * Abs(-44)) = {0}", proxy.Multiply(33, -44));
    ((IClientChannel)proxy).Close();
    factory.Close();
 
    ChannelFactory<ITestWithAsyncOperation> asyncFactory = new ChannelFactory<ITestWithAsyncOperation>(new BasicHttpBinding(), new EndpointAddress(baseAddress + "/async"));
    ITestWithAsyncOperation asyncProxy = asyncFactory.CreateChannel();
    Console.WriteLine(asyncProxy.EndEchoString(asyncProxy.BeginEchoString("hello", null, null)));
    Console.WriteLine(asyncProxy.EndEchoString(asyncProxy.BeginEchoString(null, null, null)));
    ((IClientChannel)asyncProxy).Close();
    asyncFactory.Close();
}
 

That is it. This is an example on how an operation behavior can be used to implement this scenario. Notice that it only works for the server side, as there’s no invoker at the client side (for that side I think I’d use an IClientMessageFormatter). If there is enough demand I’ll expand that scenario in the upcoming post for that interface.

Coming up

We’ll look at the interfaces for the runtime, starting at the inspection interfaces (IClientMessageInspector / IDispatchMessageInspector / IParameterInspector).

[Code for this post]

[Back to the index]

Carlos Figueira
http://blogs.msdn.com/carlosfigueira
Twitter: @carlos_figueira http://twitter.com/carlos_figueira

The .NET 4 Platform Update and WF4 State Machine

Ron Jacobs — Tue, 12 Apr 2011 00:09:00 GMT

Update: This went live 4/18/2011, and there are more details here: Microsoft .NET Framework 4 Platform Update 1

On March 25^th at his Tech-Ed India keynote Jason Zander announced some great new resources for developers. Our team has been working hard on these releases and I’m happy to share with you that on April 25^{th 18th} (released early!) the Multi-Targeting Pack for Microsoft .NET Framework 4 Platform Update 1 (KB2495638) will be available for download.

There are two options for downloading the platform update.

Microsoft .NET Framework 4 Platform Update 1 – Design-time Update for Visual Studio 2010 SP1 (KB2495593) which includes Visual Studio updates and framework updates
Multi-Targeting Pack for Microsoft .NET Framework 4 Platform Update 1 (KB2495638) which includes just the framework updates

Windows Workflow Foundation - State Machine (.NET Framework Platform Update 1)

New State Machine workflow model - builds upon WF runtime and add in new workflow style for event-driven processes - Events (or "Triggers") cause "Transitions" between known "States"
New API and Visual Studio-based designer - enables simplified authoring of State Machine styled flow control
Fully supported on .NET Framework 4 (replaces CodePlex based solution available today)
New enhancements over existing CodePlex solution
- Entry/Exit actions on State, Conditional and default Transitions with Transition action, scoped variables in StateMachine, and improved Tracking support
- Designer enhancements ease the authoring experience with Auto Connect , Auto Insert and aggregated State and Transition views that aid configuration and navigation

We also have a great new Hands on Lab for State Machine to get you started so why not take an afternoon to learn how you can add the State Machine activity to your solutions. Also if you plan on using extensions from Microsoft.Activities or our unit testing framework Microsoft.Activities.UnitTesting be sure to download version 1.8 which includes binaries built for Platform Update 1.

How to Create a State Machine Workflow

After installing .NET Framework Platform Update 1, you will see new Target Framework available in Visual Studio in your project properties. Just select one of the Platform Update 1 target framework profiles.

Then create a workflow and you will be happy to see some new activities in your WF4 toolbox.

Windows Communication Foundation - RIA 1.1 (Included in .NET Framework 4 SP1)

And in case you missed it, the WCF RIA team shipped a great new release last month as well.

Enhanced support for Windows Azure and SQL Azure - Simplified building cloud RIA applications thru new Business Application Template for Windows Azure Platform. DomainService also now supports both SQL Azure and Windows Azure Tables.
Custom code-generator extensibility and T4-based code generator - code generation is now abstracted away and implemented via a MEF-based mechanism for you to bring your own code generator; plus a new Text Template (T4) based code generator.
End-to-end support for complex types - now allows entity members and invoke operation parameters of complex types. Support for complex types covers serialization/deserialization, code generation, metadata addition, edit sessions, change tracking and deep validation.
Additional customer-requested enhancements including sharing entity types across multiple DomainServices and ViewModel-friendly DataSource.
Localization - now localized into 9 additional languages, matching the same list of languages supported by Visual Studio 2010

And of course, we have more great new releases on the way so keep watching this space for more details.

WCF Extensibility – IEndpointBehavior

CarlosFigueira — Tue, 05 Apr 2011 14:14:55 GMT

This post is part of a series about WCF extensibility points. For a list of all previous posts and planned future ones, go to the index page.

The next behavior in the list is the IEndpointBehavior. Like the other ones, it can be used to inspect and change the endpoint description (which includes the contract description) and its runtime. Unlike the other behaviors, Endpoint behaviors cannot be applied to endpoints as attributes (unless the attribute is applied to an implementation of a callback contract in a duplex pattern – see more details below). Endpoint behaviors are typically used to change the behavior of endpoints in a way which doesn’t interfere with other endpoints (which can potentially be using the same contract) in a service. For example, the WebHttpBehavior changes the runtime to understand the WCF REST attributes (WebGet/WebInvoke).

Public implementations in WCF

CallbackBehaviorAttribute: A client callback (for duplex scenarios) equivalent to the [ServiceBehavior]. On a duplex service. the client side acts both as a “normal” client and as a service, receiving callbacks initiated at the server side. This behavior allows the definition of parameters such as concurrency mode, transaction isolation level, among others.
CallbackDebugBehavior: The client callback equivalent to the ServiceDebugBehavior, defining whether the client should respond with unknown exceptions as faults.
ClientCredentials: The client equivalent to the ServiceCredentials, where the user can configure the client credentials as well as service authentication settings.
ClientViaBehavior: Defines the address used by the transport when sending a message, which may be different than the endpoint address (a.k.a. the final destination). Useful in proxying / multi-hop conversations.
DispatcherSynchronizationBehavior (new in 4.0): Defines the ability of the endpoint to send asynchronous replies. Sajay has a great post about when this can be useful.
MustUnderstandBehavior: Defines whether the endpoint must obey the mustUnderstand attribute in message headers. Normally, if an endpoint receives a message with a header marked with mustUnderstand=”1” (or “true”) then it must process the header, or generate a fault. For routing scenarios, however, we can disable this validation and relay the message to the entity which is supposed to process the headers.Q
SynchronousReceiveBehavior: Defines that the channel listener in the endpoint must use a synchronous receive call, instead of the default asynchronous mode.
TransactedBatchingBehavior: Instructs the endpoint to optimize transfer operations for transports which supports transacted receives. Essentially, it enables the batching of messages for MSMQ services. This port from Nick Allen has a good description of the scenario.
WebHttpBehavior (new in 3.5): Enables the WCF web programming model for this endpoint.
WebScriptEnablingBehavior (new in 3.5): Enables the endpoint to receive requests from an ASP.NET AJAX client. It provides a JavaScript proxy for the client to call the service in a strongly-typed way.
EndpointDiscoveryBehavior (new in 4.0): Controls the content of the discovery metadata returned by a discovery endpoint.
SoapProcessingBehavior (new in 4.0): Defines rules for translating messages between different SOAP versions in a routing scenario.

Interface declaration

 public interface IEndpointBehavior
{
    void Validate(ServiceEndpoint endpoint);
    void AddBindingParameters(ServiceEndpoint endpoint, BindingParameterCollection bindingParameters);
    void ApplyDispatchBehavior(ServiceEndpoint endpoint, EndpointDispatcher endpointDispatcher);
    void ApplyClientBehavior(ServiceEndpoint endpoint, ClientRuntime clientRuntime);
}
 

The pattern continues like the previous posts: Validate is called first, letting the behavior throw if something does not comply with the behavior rules. For example, the WebHttpBehavior (and the WebScriptEnablingBehavior) both throw during validation if the binding does not use HTTP (or HTTPS), or if it is a SOAP binding (i.e., if its message version is not None). AddBuindingParameters is the second one to be called, and it’s not commonly used.

ApplyDispatchBehavior and ApplyClientBehavior are the last ones to be called, after the runtime has been initialized. At that point, the behaviors can update the runtime, updating listeners / dispatchers and other runtime objects according to its logic. The example below will use an endpoint behavior to add a new listener for the endpoint to create a “help page” similar to the WCF Web HTTP Service Help Page.

How to add an endpoint behavior

Via service / endpoint description (server): On the server side, the list of the behaviors for the endpoint can be accessed via the Behaviors property of the endpoint description, which can be obtained once you add an endpoint to the service.

 string baseAddress = "http://" + Environment.MachineName + ":8000/Service";
ServiceHost host = new ServiceHost(typeof(Service), new Uri(baseAddress));
ServiceEndpoint endpoint = host.AddServiceEndpoint(typeof(ITest), new BasicHttpBinding(), "");
endpoint.Behaviors.Add(new MyEndpointBehavior());
 

 TestClient client = new TestClient();
client.Endpoint.Behaviors.Add(new MyEndpointBehavior());
int result = client.Add(4, 5);
 

Using attributes: Endpoint behaviors for “normal” clients / server cannot be applied as attributes – if you define an attribute class and apply it to either the service class, the contract interface or any operations, it will simply be ignored. For duplex endpoints, however, attribute-based endpoint behaviors can be applied to the class which implements the callback contract.

 public class MyEndpointBehaviorAttribute : Attribute, IEndpointBehavior
{
    public void AddBindingParameters(ServiceEndpoint endpoint, BindingParameterCollection bindingParameters)
    {
        Console.WriteLine("In {0}.{1}", this.GetType().Name, MethodBase.GetCurrentMethod().Name);
    }
 
    public void ApplyClientBehavior(ServiceEndpoint endpoint, ClientRuntime clientRuntime)
    {
        Console.WriteLine("In {0}.{1}", this.GetType().Name, MethodBase.GetCurrentMethod().Name);
    }
 
    public void ApplyDispatchBehavior(ServiceEndpoint endpoint, EndpointDispatcher endpointDispatcher)
    {
        Console.WriteLine("In {0}.{1}", this.GetType().Name, MethodBase.GetCurrentMethod().Name);
    }
 
    public void Validate(ServiceEndpoint endpoint)
    {
        Console.WriteLine("In {0}.{1}", this.GetType().Name, MethodBase.GetCurrentMethod().Name);
    }
}
 
[ServiceContract(CallbackContract = typeof(ITestCallback))]
public interface ITest
{
    [OperationContract]
    void Ping(string text);
}
 
[ServiceContract]
public interface ITestCallback
{
    [OperationContract(IsOneWay = true)]
    void Pong(string text);
}
 
public class Service : ITest
{
    public void Ping(string text)
    {
        OperationContext.Current.GetCallbackChannel<ITestCallback>().Pong(text);
    }
}
 
[MyEndpointBehavior]
public class MyCallback : global::ITestCallback
{
    public void Pong(string text)
    {
        Console.WriteLine("Received on client: {0}", text);
    }
}
 
public class Program
{
    public static void Main(string[] args)
    {
        string baseAddress = "http://" + Environment.MachineName + ":8000/Service";
        WSDualHttpBinding dualBinding = new WSDualHttpBinding(WSDualHttpSecurityMode.None);
        ServiceHost host = new ServiceHost(typeof(Service), new Uri(baseAddress));
        host.AddServiceEndpoint(typeof(ITest), dualBinding, "");
        host.Description.Behaviors.Add(new ServiceMetadataBehavior { HttpGetEnabled = true });
        Console.WriteLine("Opening the host");
        host.Open();
 
        InstanceContext callbackInstance = new InstanceContext(new MyCallback());
        TestClient client = new TestClient(callbackInstance, dualBinding, new EndpointAddress(baseAddress));
        client.Ping("hello");
 
        Console.WriteLine("Press ENTER to close");
        Console.ReadLine();
        host.Close();
        Console.WriteLine("Host closed");
    }
}
 

Using configuration: If the endpoint behavior has a configuration extension, then it can be applied directly in the configuration. This works for both service endpoints, and for client endpoints:

 <system.serviceModel>
  <extensions>
    <behaviorExtensions>
      <add name="myEndpointBehavior"
           type="assembly-qualified-name-of-extension-class"/>
    </behaviorExtensions>
  </extensions>
  <behaviors>
    <endpointBehaviors>
      <behavior name="UsingMyEndpointBehavior">
        <myEndpointBehavior/>
      </behavior>
    </endpointBehaviors>
  </behaviors>
  <services>
    <service name="MyNamespace.MyService">
      <endpoint address=""
                behaviorConfiguration="UsingMyEndpointBehavior"
                binding="basicHttpBinding"
                contract="MyNamespace.IMyContract" />
    </service>
  </services>
  <client>
    <endpoint address="http://contoso.com/service"
              behaviorConfiguration="UsingMyBehavior"
              binding="basicHttpBinding"
              contract="MyNamespace.IMyClientContract" />
  </client>
</system.serviceModel>
 

Real-world scenario: an endpoint help page

One of the nice features added in .NET Framework 4 was a help page for REST endpoints. It described all the operations on the endpoint, as well as the schema for parameters. A few posts on the forums asked about how to customize that page (or the “service” help page), so this is a generic help page implementation (not only for REST endpoints, but for SOAP ones as well). The implementation idea is similar to the one for the POCO Service Host (described in the post about service behaviors): during the call to ApplyDispatchBehavior, the behavior will add a new dispatcher which can handle requests for the help page. Browser clients will then be able to point to that help page, and get a human-readable description of the endpoint.

And before I go any further, here goes the usual disclaimer – this is a sample for illustrating the topic of this post, this is not production-ready code. I tested it for a few contracts and it worked, but I cannot guarantee that it will work for all scenarios (please let me know if you find a bug or something missing). Also, for simplicity sake it doesn’t have a lot of error handling which a production-level code would, and doesn’t support all contract types (asynchronous operations, for example). Finally, this sample (as well as most other samples in this series) uses extensibility points other than the one for this post (e.g., operation invoker, instance providers, etc.) which are necessary to get a realistic scenario going. I’ll briefly describe what they do, and leave to their specific entries a more detailed description of their behavior.

This behavior will also have a customized part of the help page. For this sample, it’s a simple string (the “name of the company” which provides the services), but it can be easily extended to more complex information. Here’s the implementation of IEndpointBehavior. Only ApplyDispatchBehavior will be used here, where we’ll add the new dispatcher to the service. And only if the endpoint address is HTTP – it doesn’t make sense to add a help page for browsers for TCP or named pipes:

 public class HelpPageEndpointBehavior : IEndpointBehavior
{
    string companyName;
    public HelpPageEndpointBehavior(string companyName)
    {
        this.companyName = companyName;
    }
 
    public void AddBindingParameters(ServiceEndpoint endpoint, BindingParameterCollection bindingParameters)
    {
    }
 
    public void ApplyClientBehavior(ServiceEndpoint endpoint, ClientRuntime clientRuntime)
    {
    }
 
    public void ApplyDispatchBehavior(ServiceEndpoint endpoint, EndpointDispatcher endpointDispatcher)
    {
        Uri endpointAddress = endpoint.Address.Uri;
        if (endpointAddress.Scheme == Uri.UriSchemeHttp || endpointAddress.Scheme == Uri.UriSchemeHttps)
        {
            string address = endpointAddress.ToString();
            if (!address.EndsWith("/"))
            {
                address = address + "/";
            }
 
            Uri helpPageUri = new Uri(address + "help");
            ServiceHostBase host = endpointDispatcher.ChannelDispatcher.Host;
            ChannelDispatcher helpDispatcher = this.CreateChannelDispatcher(host, endpoint, helpPageUri);
            host.ChannelDispatchers.Add(helpDispatcher);
        }
    }
 
    public void Validate(ServiceEndpoint endpoint)
    {
    }
}
 

CreateChannelDispatcher will create the listener (based on WebHttpBinding, which can handle GET requests natively). The help page will be created by an internal class (HelpPageService) which can handle requests for the help page, and an object of that class will be used as a singleton instance for this dispatcher (since the class is thread-safe, we can share the same instance). Unlike in the service behavior, in which we used the operation behaviors to set up the operation dispatcher properties, this time we need to set them ourselves. So we need to define our invoker and message formatter as well.

 private ChannelDispatcher CreateChannelDispatcher(ServiceHostBase host, ServiceEndpoint endpoint, Uri helpPageUri)
{
    Binding binding = new WebHttpBinding();
    EndpointAddress address = new EndpointAddress(helpPageUri);
    BindingParameterCollection bindingParameters = new BindingParameterCollection();
    IChannelListener channelListener = binding.BuildChannelListener<IReplyChannel>(helpPageUri, bindingParameters);
    ChannelDispatcher channelDispatcher = new ChannelDispatcher(channelListener, "HelpPageBinding", binding);
    channelDispatcher.MessageVersion = MessageVersion.None;
 
    HelpPageService service = new HelpPageService(endpoint, this.companyName);
 
    EndpointDispatcher endpointDispatcher = new EndpointDispatcher(address, "HelpPageContract", "", true);
    DispatchOperation operationDispatcher = new DispatchOperation(endpointDispatcher.DispatchRuntime, "GetHelpPage", "*", "*");
    operationDispatcher.Formatter = new PassthroughMessageFormatter();
    operationDispatcher.Invoker = new HelpPageInvoker(service);
    operationDispatcher.SerializeReply = false;
    operationDispatcher.DeserializeRequest = false;
 
    endpointDispatcher.DispatchRuntime.InstanceProvider = new SingletonInstanceProvider(service);
    endpointDispatcher.DispatchRuntime.Operations.Add(operationDispatcher);
    endpointDispatcher.DispatchRuntime.InstanceContextProvider = new SimpleInstanceContextProvider();
    endpointDispatcher.DispatchRuntime.SingletonInstanceContext = new InstanceContext(host, service);
    endpointDispatcher.ContractFilter = new MatchAllMessageFilter();
    endpointDispatcher.FilterPriority = 0;
 
    channelDispatcher.Endpoints.Add(endpointDispatcher);
    return channelDispatcher;
}
 

Now for the implementation of the helper classes. First the HelpPageService. It’s a very, very simple class which only receives requests for the help page, then returns an instance of a custom Message class.

 class HelpPageService
{
    ServiceEndpoint endpoint;
    string companyName;
    public HelpPageService(ServiceEndpoint endpoint, string companyName)
    {
        this.endpoint = endpoint;
        this.companyName = companyName;
    }
    public Message Process(Message input)
    {
        return new HelpPageMessage(this.endpoint, this.companyName);
    }
}
 

The HelpPageMessage implements the abstract Message class by overriding the OnWriteBodyContents method. Since WCF messages are XML-based, we’ll use the XML writer passed to the method to write the HTML (as well-formatted XML). The HTML page generated contains a few tables with information about the endpoint obtained from the description, but it’s plain HTML, not too interesting – although it’s useful to notice that the logic to print the operation signature is too simple, as it doesn’t handle out/ref/array/generic parameters correctly (to handle them all this sample would get too big). The interesting item in the message class is the InitializeMessageProperties method. By default, WCF will use the encoder’s ContentType property to determine the Content-Type header of the response, which is usually some XML (or SOAP) type. By adding a HttpResponseMessageProperty to the message, we change the response content type to text/html.

 class HelpPageMessage : Message
{
    MessageHeaders headers;
    MessageProperties properties;
    ServiceEndpoint endpoint;
    string companyName;
 
    public HelpPageMessage(ServiceEndpoint endpoint, string companyName)
    {
        this.headers = new MessageHeaders(MessageVersion.None);
        this.properties = InitializeMessageProperties();
        this.endpoint = endpoint;
        this.companyName = companyName;
    }
 
    public override MessageHeaders Headers
    {
        get { return this.headers; }
    }
 
    public override MessageProperties Properties
    {
        get { return this.properties; }
    }
 
    public override MessageVersion Version
    {
        get { return MessageVersion.None; }
    }
 
    protected override void OnWriteBodyContents(XmlDictionaryWriter writer)
    {
        writer.WriteStartElement("html");
        writer.WriteStartElement("head");
        writer.WriteElementString("title", "Better help page, presented by " + this.companyName);
        writer.WriteElementString("style", this.CreateStyleValue());
        writer.WriteEndElement();
        writer.WriteStartElement("body");
        writer.WriteElementString("h1", "Endpoint help page, by " + this.companyName);
 
        this.WriteEndpointDetails(writer);
        this.WriteEndpointBehaviors(writer);
        this.WriteContractOperations(writer);
 
        writer.WriteEndElement(); // body
        writer.WriteEndElement(); // html
    }
 
    private string CreateStyleValue()
    {
        return "table { border-collapse: collapse; border-spacing: 0px; font-family: Verdana;} " +
            "table th { border-right: 2px white solid; border-bottom: 1.5px white solid; font-weight: bold; background-color: #cecf9c;} " +
            "table td { border-right: 2px white solid; border-bottom: 1.5px white solid; background-color: #e5e5cc;} " +
            "h1 { background-color: #003366; border-bottom: #336699 6px solid; color: #ffffff; font-family: Tahoma; font-size: 26px; font-weight: normal;margin: 0em 0em 10px -20px; padding-bottom: 8px; padding-left: 30px;padding-top: 16px;} " +
            "h2 { background-color: #003366; border-bottom: #336699 6px solid; color: #ffffff; font-family: Tahoma; font-size: 20px; font-weight: normal;margin: 0em 0em 10px -20px; padding-bottom: 8px; padding-left: 30px;padding-top: 16px;} " +
            ".signature { font-family: Consolas; font-size: 12px; }";
    }
 
    private void WriteEndpointDetails(XmlDictionaryWriter writer)
    {
        writer.WriteElementString("h2", "Endpoint details");
 
        writer.WriteStartElement("table");
 
        writer.WriteStartElement("tr");
        writer.WriteElementString("th", "Element");
        writer.WriteElementString("th", "Value");
        writer.WriteEndElement();
 
        writer.WriteStartElement("tr");
        writer.WriteElementString("th", "Address");
        writer.WriteElementString("td", this.endpoint.Address.ToString());
        writer.WriteEndElement();
 
        writer.WriteStartElement("tr");
        writer.WriteElementString("th", "Binding");
        writer.WriteElementString("td", this.endpoint.Binding.ToString());
        writer.WriteEndElement();
 
        writer.WriteStartElement("tr");
        writer.WriteElementString("th", "Contract Type");
        writer.WriteElementString("td", this.endpoint.Contract.ContractType.FullName);
        writer.WriteEndElement();
 
        writer.WriteEndElement(); // </table>
    }
 
    private void WriteEndpointBehaviors(XmlDictionaryWriter writer)
    {
        writer.WriteElementString("h2", "Endpoint behaviors");
 
        writer.WriteStartElement("table");
 
        writer.WriteStartElement("tr");
        writer.WriteElementString("th", "Index");
        writer.WriteElementString("th", "Type");
        writer.WriteEndElement();
 
        for (int i = 0; i < this.endpoint.Behaviors.Count; i++)
        {
            IEndpointBehavior behavior = this.endpoint.Behaviors[i];
            writer.WriteStartElement("tr");
            writer.WriteElementString("td", i.ToString(CultureInfo.InvariantCulture));
            writer.WriteElementString("td", behavior.GetType().FullName);
            writer.WriteEndElement();
        }
 
        writer.WriteEndElement(); // </table>
    }
 
    private void WriteContractOperations(XmlDictionaryWriter writer)
    {
        writer.WriteElementString("h2", "Operations");
 
        writer.WriteStartElement("table");
 
        writer.WriteStartElement("tr");
        writer.WriteElementString("th", "Name");
        writer.WriteElementString("th", "Signature");
        writer.WriteElementString("th", "Description");
        writer.WriteEndElement();
 
        foreach (OperationDescription operation in this.endpoint.Contract.Operations)
        {
            writer.WriteStartElement("tr");
            writer.WriteElementString("td", operation.Name);
            writer.WriteStartElement("td");
            writer.WriteAttributeString("class", "signature");
            writer.WriteString(this.GetOperationSignature(operation));
            writer.WriteEndElement();
            writer.WriteElementString("td", this.GetOperationDescription(operation));
            writer.WriteEndElement();
        }
 
        writer.WriteEndElement(); // </table>
    }
 
    private string GetOperationDescription(OperationDescription operation)
    {
        DescriptionAttribute[] description = (DescriptionAttribute[])operation.SyncMethod.GetCustomAttributes(typeof(DescriptionAttribute), false);
        if (description == null || description.Length == 0 || string.IsNullOrEmpty(description[0].Description))
        {
            return "Operation " + operation.SyncMethod.Name;
        }
        else
        {
            return description[0].Description;
        }
    }
 
    private string GetOperationSignature(OperationDescription operation)
    {
        StringBuilder sb = new StringBuilder();
        if (operation.SyncMethod != null)
        {
            MethodInfo method = operation.SyncMethod;
            if (method.ReturnType == null || method.ReturnType == typeof(void))
            {
                sb.Append("void");
            }
            else
            {
                sb.Append(method.ReturnType.Name);
            }
 
            sb.Append(' ');
            sb.Append(method.Name);
            sb.Append('(');
            ParameterInfo[] parameters = method.GetParameters();
            for (int i = 0; i < parameters.Length; i++)
            {
                if (i > 0)
                {
                    sb.Append(", ");
                }
 
                sb.AppendFormat("{0} {1}", parameters[i].ParameterType.Name, parameters[i].Name);
            }
 
            sb.Append(')');
        }
        else
        {
            throw new NotImplementedException("Behavior not yet implemented for async operations");
        }
 
        return sb.ToString();
    }
 
    private MessageProperties InitializeMessageProperties()
    {
        MessageProperties result = new MessageProperties();
        HttpResponseMessageProperty httpResponse = new HttpResponseMessageProperty();
        httpResponse.StatusCode = HttpStatusCode.OK;
        httpResponse.Headers[HttpResponseHeader.ContentType] = "text/html";
        result.Add(HttpResponseMessageProperty.Name, httpResponse);
        return result;
    }
}
 

The instance provider will always return the singleton instance of the HelpPageService class – nothing too fancy here. The operation invoker implementation is simple – it will always deliver the incoming Message object to the singleton HelpPageService instance.

 class SingletonInstanceProvider : IInstanceProvider
{
    object instance;
    public SingletonInstanceProvider(object instance)
    {
        this.instance = instance;
    }
    public object GetInstance(InstanceContext instanceContext, Message message)
    {
        return instance;
    }
 
    public object GetInstance(InstanceContext instanceContext)
    {
        return instance;
    }
 
    public void ReleaseInstance(InstanceContext instanceContext, object instance)
    {
    }
}
 
class HelpPageInvoker : IOperationInvoker
{
    HelpPageService service;
    public HelpPageInvoker(HelpPageService service)
    {
        this.service = service;
    }
 
    public object[] AllocateInputs()
    {
        return new object[1];
    }
 
    public object Invoke(object instance, object[] inputs, out object[] outputs)
    {
        outputs = new object[0];
        return this.service.Process((Message)inputs[0]);
    }
 
    public IAsyncResult InvokeBegin(object instance, object[] inputs, AsyncCallback callback, object state)
    {
        throw new NotSupportedException();
    }
 
    public object InvokeEnd(object instance, out object[] outputs, IAsyncResult result)
    {
        throw new NotSupportedException();
    }
 
    public bool IsSynchronous
    {
        get { return true; }
    }
}
 

Finally, the instance context provider is the same as the one used in the service behavior sample. And the message formatter (converting between Message objects and operation parameters) is trivial, since the operation in the service takes a parameter of that type and returns a value of the same type, so it simply passes them through.

 class SimpleInstanceContextProvider : IInstanceContextProvider
{
    public InstanceContext GetExistingInstanceContext(Message message, IContextChannel channel)
    {
        return null;
    }
 
    public void InitializeInstanceContext(InstanceContext instanceContext, Message message, IContextChannel channel)
    {
    }
 
    public bool IsIdle(InstanceContext instanceContext)
    {
        return false;
    }
 
    public void NotifyIdle(InstanceContextIdleCallback callback, InstanceContext instanceContext)
    {
    }
}
 
class PassthroughMessageFormatter : IDispatchMessageFormatter
{
    public void DeserializeRequest(Message message, object[] parameters)
    {
        parameters[0] = message;
    }
 
    public Message SerializeReply(MessageVersion messageVersion, object[] parameters, object result)
    {
        return (Message)result;
    }
}
 

And that’s it. The help page for REST endpoints also contains links to help pages for specific operations and operations schema. To to the same with this example one would need to simply create (one for each new page to be retrieved), or return a different message depending on the request URI.

Coming up

The last behavior interface (IOperationBehavior).

[Code in this post]

[Back to the index]

Carlos Figueira
http://blogs.msdn.com/carlosfigueira
Twitter: @carlos_figueira http://twitter.com/carlos_figueira

(WF4) Why can’t I change the TypeArgument of Switch<> or FlowSwitch<> using the property grid?

tilovell09 — Thu, 31 Mar 2011 19:07:03 GMT

I don’t remember anyone ever actually asking me this, but I found myself wondering the question while rustling up a quick rehosting app.

Foreach<> activity lets you change the TypeArgument dynamically via the property grid. But FlowSwitch<> doesn’t. Why?

As usual, although it take a while, I like investigating issues like this in a practical way. Is it possible for us to ‘Add’ the TypeArgument property in the property grid for FlowSwitch<> in the same way that ForEach<> does? Starting off with disassembly diving, we can figure out that there is a bunch of internal classes like FeatureAttribute, UpdatableGenericArgumentsFeature and GenericArgumentUpdaterService which are involved in the addition of the TypeArgument property to the ForEach<> activity’s property grid. We can also figure out that none of that really matters. Because GenericArgumentUpdaterService is really just a helper class for using a regular public API which is AttachedPropertiesService.

What is AttachedPropertiesService, and what is it being used for here?

For a quick and abstract intro on AttachedPropertiesService, see Matt’s old post. In short, what it allows you to do is add ‘extra properties’ on any type which you want to display in WorfklowDesigner. This is pretty awesome in its flexibility and power. Want to add a new, fake property on a built-in framework type? You can!

So, how would we go about adding the updatable TypeArgument property to FlowSwitch<>?

Step 1: Register the Attached Property

public static void MakeGenericArgumentUpdatable(EditingContext context)

{

AttachedPropertiesService aps;

AttachedProperty property;

aps = context.Services.GetService<AttachedPropertiesService>();

property = new AttachedProperty<Type>()

{

IsBrowsable = true,

Name = "TypeArgument",

Getter = GetTypeArgument,

Setter = SetTypeArgument,

OwnerType = typeof(FlowSwitch<>),

};

aps.AddProperty(property);

}

We passed in an EditingContext from the WorkflowDesigner where we want this attached property to be registered in. The generic type of our attached property is AttachedProperty<Type>, because the type of the virtual property we are creating should be System.Type.

Step 2: Implement the Getter

private static Type GetTypeArgument(ModelItem mi)

{

object value = mi.GetCurrentValue();

Type ret = value.GetType().GetGenericArguments()[0]; // Should be first generic argument of FlowSwitch<T>

return ret;

}

Just pull apart the ModelItem assuming it is a FlowSwitch<X>, and figure out what X is.

Step 3: Implement the Setter

private static void SetTypeArgument(ModelItem oldModelItem, Type value)

{

Type newItemType = typeof(FlowSwitch<>).MakeGenericType(value);

object newItem = Activator.CreateInstance(newItemType);

ModelItem newModelItem = WrapAsModelItem(oldModelItem.GetEditingContext(), newItem);

// use the somewhat magical MorphHelper

MorphHelper.MorphObject(oldModelItem, newModelItem);

return;

}

private static ModelItem WrapAsModelItem(EditingContext context, object obj)

{

return context.Services.GetService<ModelTreeManager>().CreateModelItem(null, obj);

}

This bit is the weirdest. MorphHelper.MorphObject is being used to replace one ModelItem in the Model Tree with another, and simultaneously updates all references to the old model item. This is a generally useful trick for ‘swapping in’ one object to replace another in the model tree.

There’s some remaining wrinkles… none of the properties of the old FlowSwitch<> got copied over the new one, ack! Also, the viewstate which tracks the FlowSwitch<>’s position in the designer is lost. Ideally we would also implement that copying behavior in our SetTypeArgument function, so that we don’t unexpected lose flowchart connections whenever someone changes their TypeArgument in the property grid…

You can use MorphHelper.MorphProperties as a best-effort implementation of automatic property cloning. But in this case it’s kind of hard not to lose data, because the type data on the FlowSwitch links is dependent on the type of FlowSwitch<>.

Which is probably the real reason that FlowSwitch<> doesn’t (currently) show a TypeArgument property.

PDC10–WF4 Session “Windows Workflow Futures”

Ron Jacobs — Thu, 31 Mar 2011 16:41:00 GMT

Last year we at PDC10 we gave you a preview of the next release of Windows Workflow Foundation. The video has just been posted to Channel 9.

Windows Workflow Futures
Speaker: Ron Jacobs

Learn about the key investments we’re making in Windows Workflow Foundation (WF). See the WF improvements we’re working on for workflow authoring, hosting and management. Learn how we’re bringing WF to the cloud, and how WF and Windows Azure AppFabric will provide a great middle-tier platform for building, deploying, running and managing scalable workflow solutions in Windows Azure.

WCF Extensibility – IContractBehavior

CarlosFigueira — Wed, 30 Mar 2011 16:18:00 GMT

This post is part of a series about WCF extensibility points. For a list of all previous posts and planned future ones, go to the index page.

Going down the list of behaviors, the second one to be covered is the IContractBehavior. Like the other ones, it can be used to inspect or change the contract description and its runtime for all endpoints which have that contract. For example, the behavior can validate the contract against the binding to ensure that the it’s used the contract is only used with appropriate, or it can modify the runtime for all its operations in a centralized location. Unlike IServiceBehavior mentioned in the previous post, the IContractBehavior is also used to change the client runtime.

Public implementations in WCF

DeliveryRequirementsAttribute: Defines ordering requirements for the binding which uses the contract, such as whether the contract requires ordered or queued delivery.
ServiceMetadataContractBehavior (new in 4.0): Determines whether endpoints with the given contract should be exposed in the service metadata.
JavascriptCallbackBehaviorAttribute: For REST/JSON endpoints, defines the URL query string parameter name which needs to be passed to change the response from “normal” JSON to JSONP.

Interface declaration

 public interface IContractBehavior
{
    void Validate(ContractDescription contractDescription, ServiceEndpoint endpoint);
    void ApplyDispatchBehavior(ContractDescription contractDescription, ServiceEndpoint endpoint, DispatchRuntime dispatchRuntime);
    void ApplyClientBehavior(ContractDescription contractDescription, ServiceEndpoint endpoint, ClientRuntime clientRuntime);
    void AddBindingParameters(ContractDescription contractDescription, ServiceEndpoint endpoint, BindingParameterCollection bindingParameters);
}
 

As was mentioned in the post about Behaviors, you can use the Validate method to ensure that the contract doesn’t violate the validation logic on the behavior. One example is the DeliveryRequirementsAttribute, which throws if the behavior requires ordered message delivery but it’s not there (i.e., using HTTP, MSMQ), or if the behavior says that it cannot have queued delivery but the binding provides that.

AddBindingParameters is used to pass information to the binding elements themselves. It’s not used as often, but one (not too common) example would be for a contract, after validating that the binding does not contain any message encoding binding elements, to add one in the binding parameters at this method, thus guaranteeing that it would always use that encoding type.

ApplyDispatchBehavior is the method which is most used in the server side. It’s called right after the runtime was initialized, so at that point the code has access to the listeners / dispatchers / runtime objects for the server, and can add / remove / modify those. The example below will use an endpoint behavior to change the serializer used by all of the operations in the contract.

ApplyClientBehavior is the counterpart to ApplyDispatchBehavior for the client side. After the client runtime is initialized, the method is called so that the code can update the client runtime objects.

How to add a contract behavior

Via the service / endpoint description (server): On the server side, once you add an endpoint you can get a reference to it, then you can access its Contract property, and from there you can access the behavior collection.

 string baseAddress = "http://" + Environment.MachineName + ":8000/Service";
ServiceHost host = new ServiceHost(typeof(Service), new Uri(baseAddress));
ServiceEndpoint endpoint = host.AddServiceEndpoint(typeof(ITest), new BasicHttpBinding(), "");
endpoint.Contract.Behaviors.Add(new MyContractBehavior());
 

Via the channel factory / generated proxy (client): The ChannelFactory class has an Endpoint property which is of the same type as the one on the server. Likewise, generated proxies (using svcutil / add service reference) are subclasses of ClientBase<T>, which also has an Endpoint property which contains a reference to the contract description, and from there to the behavior collection. Just remember that, once the endpoint has been opened (for channel factories, when it’s been explicitly opened or a channel created; for generated clients when it’s been explicitly opened or an operation called), modifying the description will have no effect on the runtime, since it’s already been created).

 ChannelFactory<ITest> factory = new ChannelFactory<ITest>(binding, new EndpointAddress(address));
factory.Endpoint.Contract.Behaviors.Add(new MyContractBehavior());
ITest proxy = factory.CreateChannel();
 

Using attributes: if the contract behavior is derived from System.Attribute, it can be applied to either the contract interface or the service class, and it will be added to the contract description by WCF. If it’s applied to the contract interface, it will be added to the contract description in all endpoints which use that contract (both server and client). If the attribute is applied to the service implementation, it will be applied to all contracts implemented by the service (unless the attribute also implements the IContractBehaviorAttribute interface, in which case it can be restricted to a single contract type – see more information in the remarks section of the documentation for IContractBehavior.

 public class MyContractBehaviorAttribute : Attribute, IContractBehavior
{
    // IContractBehavior implementation
}
[ServiceContract]
[MyContractBehavior]
public interface ICalculator
{
    [OperationContract]
    int Add(int x, int y);
}
 

Using configuration: Configuration is not an option for adding endpoint behaviors.

Real world scenario: using a new serializer

This has come up a few times in the forums (1, 2, 3, …). Most of the time it’s about forcing WCF to use XmlSerializer, or replace the default DataContractSerializer with the NetDataContractSerializer (to avoid having to deal with known types in inheritance-heavy scenarios). Other times people really need a new way of serializing / deserializing objects – for performance or size reasons, for example. In this example I have a custom serializer which knows how to serialize very compactly some data types which are tagged with a specific interface. The interface is a simple one with two methods: one for the object to serialize itself into a stream, and another for an object to initialize itself from a stream.

 public interface ICustomSerializable
{
    void WriteTo(Stream stream);
    void InitializeFrom(Stream stream);
}
 

And before I go any further, here goes the usual disclaimer – this is a sample for illustrating the topic of this post, this is not production-ready code. I tested it for a few inputs and it worked, but I cannot guarantee that it will work for all types (please let me know if you find a bug or something missing). Also, for simplicity sake it doesn’t have a lot of error handling which a production-level code would. Finally, this sample (as well as most other samples in this series) uses extensibility points other than the one for this post (e.g., operation behavior, custom serializers, etc.) which are necessary to get a realistic scenario going. I’ll briefly describe what they do, and leave to their specific entries a more detailed description of their behavior.

Below are a few types which implement this interface. They use some helper functions to read/write data in a compact binary format (the code for the helper can be found in the [Code for this post] link at the end). This is a format similar to the one used by the .NET XML Binary Format (the one used by the binary encoding in WCF).

 public class Product : ICustomSerializable
{
    public string Name;
    public string Unit;
    public int UnitPrice;
 
    public void WriteTo(Stream stream)
    {
        FormatHelper.WriteString(stream, this.Name);
        FormatHelper.WriteString(stream, this.Unit);
        FormatHelper.WriteInt(stream, this.UnitPrice);
    }
 
    public void InitializeFrom(Stream stream)
    {
        this.Name = FormatHelper.ReadString(stream);
        this.Unit = FormatHelper.ReadString(stream);
        this.UnitPrice = FormatHelper.ReadInt(stream);
    }
}
 
public class Order : ICustomSerializable
{
    public int Id;
    public Product[] Items;
    public DateTime Date;
 
    public void WriteTo(Stream stream)
    {
        FormatHelper.WriteInt(stream, this.Id);
        FormatHelper.WriteInt(stream, this.Items.Length);
        for (int i = 0; i < this.Items.Length; i++)
        {
            this.Items[i].WriteTo(stream);
        }
 
        FormatHelper.WriteLong(stream, this.Date.ToBinary());
    }
 
    public void InitializeFrom(Stream stream)
    {
        this.Id = FormatHelper.ReadInt(stream);
        int itemCount = FormatHelper.ReadInt(stream);
        this.Items = new Product[itemCount];
        for (int i = 0; i < itemCount; i++)
        {
            this.Items[i] = new Product();
            this.Items[i].InitializeFrom(stream);
        }
 
        this.Date = DateTime.FromBinary(FormatHelper.ReadLong(stream));
    }
}
 

Now to the behavior. In order to easily share the behavior between client and server (after all, both sides need to agree on the serialization format), I’m implementing it as an attribute, so we can share the contract definition between the parties and it will be decorated with the behavior. The behavior will do two things: validate that all types which will use the new serializer can be created (i.e., they’re public types with a public, parameter-less constructor), and replace a behavior in all of the contract operations. The behavior which selects the serializer in WCF is the DataContractSerializerOperationBehavior (DCSOB), whose task is to add a formatter to the runtime which knows how to convert between the incoming / outgoing message and the parameters in the operations. We could create a new formatter to do that, but inheriting from DCSOB (even though we won’t be using the DataContractSerializer for our custom serialization) will save us time, as it exposes two helper virtual methods that makes it easier to replace the serializer).

 public class MyNewSerializerContractBehaviorAttribute : Attribute, IContractBehavior
{
    public void AddBindingParameters(ContractDescription contractDescription, ServiceEndpoint endpoint, BindingParameterCollection bindingParameters)
    {
    }
 
    public void ApplyClientBehavior(ContractDescription contractDescription, ServiceEndpoint endpoint, ClientRuntime clientRuntime)
    {
        this.ReplaceSerializerOperationBehavior(contractDescription);
    }
 
    public void ApplyDispatchBehavior(ContractDescription contractDescription, ServiceEndpoint endpoint, DispatchRuntime dispatchRuntime)
    {
        this.ReplaceSerializerOperationBehavior(contractDescription);
    }
 
    public void Validate(ContractDescription contractDescription, ServiceEndpoint endpoint)
    {
        foreach (OperationDescription operation in contractDescription.Operations)
        {
            foreach (MessageDescription message in operation.Messages)
            {
                this.ValidateMessagePartDescription(message.Body.ReturnValue);
                foreach (MessagePartDescription part in message.Body.Parts)
                {
                    this.ValidateMessagePartDescription(part);
                }
 
                foreach (MessageHeaderDescription header in message.Headers)
                {
                    this.ValidateCustomSerializableType(header.Type);
                }
            }
        }
    }
 
    private void ValidateMessagePartDescription(MessagePartDescription part)
    {
        if (part != null)
        {
            this.ValidateCustomSerializableType(part.Type);
        }
    }
 
    private void ValidateCustomSerializableType(Type type)
    {
        if (typeof(ICustomSerializable).IsAssignableFrom(type))
        {
            if (!type.IsPublic)
            {
                throw new InvalidOperationException("Custom serialization is supported in public types only");
            }
 
            ConstructorInfo defaultConstructor = type.GetConstructor(new Type[0]);
            if (defaultConstructor == null)
            {
                throw new InvalidOperationException("Custom serializable types must have a public, parameterless constructor");
            }
        }
    }
 
    private void ReplaceSerializerOperationBehavior(ContractDescription contract)
    {
        foreach (OperationDescription od in contract.Operations)
        {
            for (int i = 0; i < od.Behaviors.Count; i++)
            {
                DataContractSerializerOperationBehavior dcsob = od.Behaviors[i] as DataContractSerializerOperationBehavior;
                if (dcsob != null)
                {
                    od.Behaviors[i] = new MyNewSerializerOperationBehavior(od);
                }
            }
        }
    }
 
    class MyNewSerializerOperationBehavior : DataContractSerializerOperationBehavior
    {
        public MyNewSerializerOperationBehavior(OperationDescription operation) : base(operation) { }
        public override XmlObjectSerializer CreateSerializer(Type type, string name, string ns, IList<Type> knownTypes)
        {
            return new MyNewSerializer(type, base.CreateSerializer(type, name, ns, knownTypes));
        }
 
        public override XmlObjectSerializer CreateSerializer(Type type, XmlDictionaryString name, XmlDictionaryString ns, IList<Type> knownTypes)
        {
            return new MyNewSerializer(type, base.CreateSerializer(type, name, ns, knownTypes));
        }
    }
}
 

Finally, the serializer. Implementing a new WCF serializer is a matter of finding a mapping between XML (the internal format used by WCF messages) and the format you want. For this optimized serialization, I’ll use a very simple mapping which writes the serialized object as binary data, wrapped inside a XML element. The mapping is done by subclassing XmlObjectSerializer, by overriding a few methods about reading / writing the object from / to XML reader / writers. Also, since there are types which can be used in the operation but aren’t ready for optimized serialization, the serializer is holding on to a reference to the original serializer from WCF, so that they can be used as well. So the implementation checks whether the type being serialized supports custom serialization; if it does, the new logic is used; otherwise it delegates the call to the original serializer for that type.

 public class MyNewSerializer : XmlObjectSerializer
{
    const string MyPrefix = "new";
    Type type;
    bool isCustomSerialization;
    XmlObjectSerializer fallbackSerializer;
    public MyNewSerializer(Type type, XmlObjectSerializer fallbackSerializer)
    {
        this.type = type;
        this.isCustomSerialization = typeof(ICustomSerializable).IsAssignableFrom(type);
        this.fallbackSerializer = fallbackSerializer;
    }
 
    public override bool IsStartObject(XmlDictionaryReader reader)
    {
        if (this.isCustomSerialization)
        {
            return reader.LocalName == MyPrefix;
        }
        else
        {
            return this.fallbackSerializer.IsStartObject(reader);
        }
    }
 
    public override object ReadObject(XmlDictionaryReader reader, bool verifyObjectName)
    {
        if (this.isCustomSerialization)
        {
            object result = Activator.CreateInstance(this.type);
            MemoryStream ms = new MemoryStream(reader.ReadElementContentAsBase64());
            ((ICustomSerializable)result).InitializeFrom(ms);
            return result;
        }
        else
        {
            return this.fallbackSerializer.ReadObject(reader, verifyObjectName);
        }
    }
 
    public override void WriteEndObject(XmlDictionaryWriter writer)
    {
        if (this.isCustomSerialization)
        {
            writer.WriteEndElement();
        }
        else
        {
            this.fallbackSerializer.WriteEndObject(writer);
        }
    }
 
    public override void WriteObjectContent(XmlDictionaryWriter writer, object graph)
    {
        if (this.isCustomSerialization)
        {
            MemoryStream ms = new MemoryStream();
            ((ICustomSerializable)graph).WriteTo(ms);
            byte[] bytes = ms.ToArray();
            writer.WriteBase64(bytes, 0, bytes.Length);
        }
        else
        {
            this.fallbackSerializer.WriteObjectContent(writer, graph);
        }
    }
 
    public override void WriteStartObject(XmlDictionaryWriter writer, object graph)
    {
        if (this.isCustomSerialization)
        {
            writer.WriteStartElement(MyPrefix);
        }
        else
        {
            this.fallbackSerializer.WriteStartObject(writer, graph);
        }
    }
}
 

Coming up

The remaining 2 behavior interfaces.

[Code in this post]

[Back to the index]

Carlos Figueira
http://blogs.msdn.com/carlosfigueira
Twitter: @carlos_figueira http://twitter.com/carlos_figueira