AJ's blog

February 15, 2015

WCF Policy – Part 9: Making the Information Accessible on the Server

Filed under: .NET, .NET Framework, C#, SOA, Software Architecture, Software Development, WCF — ajdotnet @ 3:14 pm

On the client we can access the tracking information. On the server this would also come in handy, e.g. to add additional tracking entries, say for lengthy operations, such as database calls.

Whenever an application developer needs access to the current context during a service call, he does so via OperationContext. And OperationContext provides with its property Extensions exactly the extension point we need – if we can place an object in there, that implements our ITrackingInformation.

Operation extensions are classes implementing IExtension<OperationContext>. Providing a class that implements both, this interface and ITrackingInformation, is a simple exercise: Just deriving from TrackingInformation – the object we used to temporarily maintain the tracking information – and implementing the interface methods trivially is sufficient:

internal class TrackingOperationContextExtension : TrackingInformation, IExtension<OperationContext>
    void IExtension<OperationContext>.Attach(OperationContext owner) { }
    void IExtension<OperationContext>.Detach(OperationContext owner) { }

Now we need to change our message inspector to maintain the tracking information in an extension, rather than a temporary object. As on the client, due to some foresight, we only need to change one method:

private ITrackingInformation GetTrackingInformation()
    var extension = new TrackingOperationContextExtension();
    OperationContext.Current.Extensions.Add(extension); // register extension
    return extension;

And that’s it. Now the application developer can get hold of the incoming tracking information and add his own entries, as he likes:

var tracking = OperationContext.Current.Extensions.Find<ITrackingInformation>();
tracking.OutgoingHeaders.TrackingEntries.Add(new TrackingEntry(typeof(TestService).Name, "My tracking information..."));


After the first posts addressed the design time aspects, this post concludes the runtime aspects of our policy. The following image shows the related components at runtime:

And this screenshot shows the result generated from a sample application:


Our policy implementation is finished at this point, however, there is another post coming, looking at aspects we did not touch.


That’s all for now folks,

Blog at WordPress.com.