WCF Extensibility – IParameterInspector

Article
04/25/2011

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 = "https://" + 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]