WCF Tracing with Activities

One of the nice features of Windows Communication Foundation (WCF) is that it can generate an excess of trace information that can help us identify issues with our services. All you need to do is turn the tracing on through the app.config like so....

name="System.ServiceModel"

switchValue="Information">

name="traceListener"

type="System.Diagnostics.XmlWriterTraceListener"

initializeData= "c:\log\Traces.svclog" />

Microsoft even provide a handy tool called Service Trace Viewer Tool (SvcTraceViewer.exe) that can be used to view the trace information that WCF produces.

However, if you have ever looked at one of these traces you will have noticed that it can be difficult to sieve through and find the service call(s) that you are interested in. It becomes especially difficult if the service calls other services. Wading through all this tracing information is time consuming and it can be very frustrating.

Fortunately WCF provides a mechanism called Activities that allow us to correlate related trace information.

Where these Activities start and stop are defined by the developer in code. They can also be propagated across service boundaries and can also be linked together with other related activities.

So, what do you need to do in order to use Activities in your tracing? They are quite simple to use, all you need to do is assign an activity id to the correlation manager. This is a GUID value and is assigned as follows:

Trace.CorrelationManager.ActivityId = Guid.NewGuid();

Now, all the trace messages that are fired after this will be included in this Activity. However, in order for this to appear in the trace log we need to add ActivityTracing to the switchValue of the diagnostics section of the app.config.

name="System.ServiceModel"

switchValue="Information ActivityTracing"

propagateActivity="true">

name="traceListener"

type="System.Diagnostics.XmlWriterTraceListener"

initializeData= "c:\log\Traces.svclog" />

Also, if we want the ActivityId to be passed from one service to another, we can set the propagateActivity attribute to True. This is useful if we are starting the activity in one service operations that is then calling other services operations to achieve it's goals. With propagateActivity set to true, all of the trace information from these services for this particular call would be grouped together.

UML Aggregation vs Composition

A colleague asked me a few weeks ago for some advice about their UML class diagram. One of the issues they were having was deciding on whether the link between two of the classes should have a "filled-in" or "non-filled-in" diamond.

You have probably already guessed that he was really asking about whether the two classes were linked by Aggregation ("non-filled-in") or Composition ("filled-in"). From my experience, this is a very confusing area of UML for some developers. I have reviewed may class diagrams where the developer seems to have just liked the look of one of the diamonds and just used it on all of their associations!

So, where should these notations be used? If you search on the internet you'll find a plethora of explanations, but I thought it might be useful to try and add a simplified explanation.

First off, this is the difficult part for developers, Aggregation and Composition are nothing to do with code. Both Aggregation and Composition are effectively talking about is one class contains another class. So, many explanations suggest it's Aggregation if it's public property and composition if it's a private field. But unfortunately it doesn't work like that.

The decision on whether a relationship is a Aggregate or Composite is based on how the classes are related in the real world. Take a classic UML example of a Car class. Your car class may have a engine class, a collection of wheel classes and a fluffy dice class. So, which of these are aggregates and which are composites?

Lets start with the engine class. This is quite a vital part of the car, you couldn't imagine a car without an engine. Likewise, the wheels are quite important too. In fact you could say that the car is composed of (among other things) an engine and wheels. So, these relationships are examples of Composition.

The remaining fluffy dice class is a bit of a looser relationship. A cars function does not depend on the tacky fluffy dice attached to the mirror. The car may not even have fluffy dice. So, this demonstrates quite nicely a Aggregation relationship.

So, our resulting class diagram looks something like this...