As blogged earlier, I have been crossing more and more into the Indigo realm and ripping the bits apart to see what it is made of. Some of my immediate work assigments will primarily revolve around Indigo-WSE-SOAP and as someone who works in an SI environment, interoperability is something I am very concerned about and I am therefore very particular on what goes out on the wire.

I had a chance to try out the message tracing, logging and activity management enchancements in WinFX and I must say I am impressed...and we are still at CTP-bits !

Now, I have been using external (SOAP and Tcp) tools to trace the messages on the wire. BUT those are external tools and those of you who have done real project work will know that in a real production environment in a client's site, these tools cannot be so easily installed at our own luxury. Sure, we can write our own SOAP Extensions and catch them in the pipeline but it takes a fair bit of grokking at the plumbings. So having a configuration-based message tracing and activity management as first class .NET features and tools is something that I have always wanted.

The below is taken from the WinFX SDK > Indigo Tools Documentation

The icons to the left of the Activity names tell you what kind of activity each is. The following table describes these icons.

Icon	Activity
	This Activity is a call out to a proxy.
	This Activity is a Helper message, meaning that it is not associated with sending or receiving a message.
	This Activity is a message from http.sys.
	This Activity is an Operation (method invocation).
	This Activity is an Operation Return (processing a response from an operation).
	The Activity type is unknown.

To view the traces in an activity, select that activity—or select multiple activities using the CTRL or Shift keys.

With the right configuration at the Indigo Service Endpoint, we could specify where we want to output our message traces. In the below case, we are telling it to spit it out into the c:\logs\messages\ folder

      [source name="IndigoMessageLogTraceSource" switchValue="Verbose"]
        [listeners]
          [add name="multifile"
               type="System.ServiceModel.Diagnostics.MessageWriterTraceListener, system.servicemodel, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
               initializeData="c:\logs\messages\"
               maxDiskSpace="1000" /]
        [/listeners]
      [/source]

If a trace source named "IndigoMessageLogTraceSource" is not configured, the message logging feature will create a MessageWriterTraceListener by default and output the message logs to %windir%\system32\logfiles\messages as shown by the configuration below:

   [!-- MessageLogging configuration --]
   [system.serviceModel]
      [diagnostics]
         [!-- log all messages received or sent at the transport level --]
         [messageLogging logEntireMessage="true"
                         maxMessagesToLog="300"
                         logMessagesAtServiceLevel="false"
                         logMalformedMessages="true"
                         logMessagesAtTransportLevel="true" /]
      [/diagnostics]
   [/system.serviceModel]

The saved output message is prefix-ed with the processID (1648(IndigoConsole1.exe)_632469155560884432_1.xml) which is great for file-parsing purposes. Since I am using the BasicProfileBinding of Indigo's ServiceModel.Binding, what goes on the wire is of SOAP 1.1 message format

  [s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"]
    [s:Header /]
    [s:Body]
      [ReturnSimpleGreetings xmlns="http://xmlns.softwaremaker.net/"]
        [yourname]Softwaremaker[/yourname]
      [/ReturnSimpleGreetings]
    [/s:Body]
  [/s:Envelope]

If time permits, I will be blogging more on the other formats with the other bindings as we move along. Besides tracing on what's on the wire, Indigo allows you to configure an end-to-end trace source using a XmlWriterTraceListener. The output is an xml-type file with an e2e extension that is consumed and readily parsed by the WinFX's TraceViewer Tool. The configuration looks something like this:

         [source name="E2e" switchValue="Verbose"]
            [listeners]
               [add name="xml" type="System.Diagnostics.XmlWriterTraceListener" initializeData="c:\logs\System.ServiceModel.e2e" /]
            [/listeners]
         [/source]

You can further configure the service to track related System.Net trace sources using a XmlWriterTraceListener as well with this configuration

         [source name="System.Net" switchValue="Verbose"]
            [listeners]
               [add name="xml" type="System.Diagnostics.XmlWriterTraceListener" initializeData="c:\logs\System.Net.e2e" /]
            [/listeners]
         [/source]
         [source name="System.Net.HttpListener" switchValue="Verbose"]
            [listeners]
               [add name="xml" type="System.Diagnostics.XmlWriterTraceListener" initializeData="c:\logs\System.Net.HttpListener.e2e" /]
            [/listeners]
         [/source]
         [source name="System.Net.Sockets" switchValue="Verbose"]
            [listeners]
               [add name="xml" type="System.Diagnostics.XmlWriterTraceListener" initializeData="c:\logs\System.Net.Sockets.e2e" /]
            [/listeners]
         [/source]
         [source name="System.Net.Cache" switchValue="Verbose"]
            [listeners]
               [add name="xml" type="System.Diagnostics.XmlWriterTraceListener" initializeData="c:\logs\System.Net.Cache.e2e" /]
            [/listeners]
         [/source]

This may be a lot to digest at one go. I will strive to write about what each means in my future posts and try to breakdown and dissect each of those items in the e2e file that is captured and displayed in the TraceViewer Tool.

The fact that these message tracing, logging and activity management are first-class features is great and places emphasis on the need to know what goes onto the wire so it interoperates well with the others.