My friend Jesus Rodriguez has published an excellent article about one the cool features that will be part of WCF 3.5 (Orcas timeframe), "Durable Services". If you want to know more about this feature, take a look at his post here.
As part of the integration between WCF and EntLib 3.0, this last one comes with a nice feature to redirect the WCF trace to the logging application block. This is done by Entlib through a custom trace listener (system.diagnostics) that captures the trace generated by WCF, and then, transfer that trace to any of the EntLib's trace listeners (Logging application block) configured in the application.
The image below illustrates the approach used by EntLib.
The fact of executing an extra component to transfer the trace messages and the logging application block itself will add some overhead to the overall solution by sure. On the other hand, we can use many of the available features in the logging application block, such as formatters, filters and trace listeners. Regarding the trace listeners, they will allow us to store the trace in different storages, like databases, msmq and files to name a few. Since we can actually do the same with a custom trace listener in system.diagnostics, the real benefit here is that we can leverage one of listeners provided in EntLib without needing to write one from the scratch or centralize the application trace and WCF trace just in one place.
If want to still use the trace viewer tool provided in WCF (svctraceviewer.exe), the bad news is that this tool only supports xml files (It would be great to have a plugging architecture here to read the trace information from any storage). Therefore, we will have to store the trace in a valid xml format, and then build something to dump the trace to a xml file. Entlib comes with a trace listener XmlTraceListener that generates a xml file with the format expected by the svctraceviewer.exe tool.
The EntLib's trace listener to redirect the trace messages the Logging application block can be configured as follow
<add name="EntLibListener" type="Microsoft.Practices.EnterpriseLibrary.Logging.TraceListeners.EntLibLoggingProxyTraceListener, Microsoft.Practices.EnterpriseLibrary.Logging"/>
<source name="System.ServiceModel" switchValue="Information, ActivityTracing" propagateActivity="true">
For this post, I will demostrate how to configure the XmlTraceListener that comes out of the box to generate the file expected by the trace viewer tool.
<loggingConfiguration name="Logging Application Block" tracingEnabled="true"
<add fileName="trace-xml.xml" listenerDataType="Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.XmlTraceListenerData, Microsoft.Practices.EnterpriseLibrary.Logging"
traceOutputOptions="None" type="Microsoft.Practices.EnterpriseLibrary.Logging.TraceListeners.XmlTraceListener, Microsoft.Practices.EnterpriseLibrary.Logging"
name="XML Trace Listener" />
<add switchValue="All" name="System.ServiceModel">
<add name="XML Trace Listener" />
<allEvents switchValue="All" name="All Events" />
<notProcessed switchValue="All" name="Unprocessed Category" />
<errors switchValue="All" name="Logging Errors & Warnings" />
My coleague Juan Wajnerman has written two interesting articles about "ASMX/WCF Migration" and "REST/POX". The first one describes an complete procedure to migrate a plain ASMX web service to a WCF service using an incremental approach.
In the second article about "REST/POX", he illustrates how to write a client in WCF for a "REST/POX" service (Clemens made an excellent job implementing this kind of service in WCF). REST/POX will be fully supported in the next version of WCF (Orcas timeframe), in the meantime, if you are interested in this topic, you can take a look to Juan's article.