Order Fixation

One of my current tasks for a client has been to facilitate the integration between a Java client and a WCF service. The mechanism for doing this is JSON and I have been quite grateful that WCF makes it relatively easy to implement this type of communication. However, there is one area that has been causing some grief for me (and my Java colleagues) that I finally create a workaround for yesterday.

The source of my problem starts with the contract used by the WCF service. A number of the methods include parameters that are abstract data types. Consider the following class declaration.


public abstract class AbstractCommand

The AbstractCommand class is just a base class for a couple of concrete classes (ButtonCommand and MouseCommand). The WCF method is declared as accepting an AbstractCommand type, but the value passed into the method will be either a ButtonCommand or a MouseCommand.

   RequestFormat = WebMessageFormat.Json, ResponseFormat = WebMessageFormat.Json)]
StatusCode ExecuteCommand(AbstractCommand command);

Naturally, when the client invokes this method, the expectation is that a concrete class instance will be passed along. However, if all you do is pass in the JSON for one of the concrete classes in, you get an exception saying that an abstract class cannot be instantiate. The reason for the error can be found in how WCF dispatches message. When the request arrives, WCF examines the message to determine which method is to be invoked. Once identified, the parameters for the method (found in the JSON) are created. This creation involves instantiating an object using the default parameterless constructor for the type and then assigning property values as found in the JSON. However, the AbstractCommand type cannot be instantiated (it is abstract, after all). And there is no immediately apparent mechanism to determine which concrete type should be used.

To address this final problem, Microsoft introduced the idea of a type hint. The JSON for a concrete type passed into the ExecuteCommand method would look something like the following:

{"command":{"__type":"ButtonCommand:#Command.Library", "prop1":"value", "prop2":"value"}}

The name/value pair of “__type” is used by WCF to determine the type that should be instantiated before performing the property assignment. This is conceptually similar to how types are provided through SOAP. This mechanism does have the hard requirement that the “__type” value be the first pair in the JSON list.

Enter Java into the picture. In order to communicate with my WCF service, the client using the Java JSONObject class. This class takes a collection of name/value pairs and converts it into a JSON-formatted array. This array is then sent to my method, where it goes through the previously described process. However the JSONObject seems to take the portion of the JSON specification where it says the name/value pairs are ‘unordered’ to heart. There is (apparently) no way to force a particular name/value pair to be emitted as the first pair. In other words, the JSONObject cannot reliably produce JSON for a concrete type that is being passed into a parameter of an abstract type.


Well, it was actually stronger language than that once I figured this out.

The solution was not nearly as complicated as identifying the problem. I created a WCF endpoint behavior extension. In the AfterReceiveRequest event handler, I look at the body of the request (which has already been converted into XML, as it turns out..a surprise, albeit an easier choice format for the next step). If the “__type” property is the first pair in the JSON array, it is converted to a “__type” attribute in the XML element. Otherwise, it appears as a regular child node. So the transformation consists of finding the XML elements that have a name of “__type” and moving the value up into an attribute of the parent node. The modified message is then injected back into the WCF pipeline. And now the request is processed as desired.