Starting work on SP2 of WSE2.0...and comparing the WSE Trace Tools out there

I have recently installed SP2 of _WSE_ 2.0 over my previous installed version of SP1.

From my first views of it, it seems that I would uninstall it and re-install the older copy of SP1 again. This has got nothing to do with SP2 itself BUT the WSE SOAP tracing utility that I used before with SP1 doesnt work with SP2. i-frown

I have been using Mike Taulty`s WSE 2.0 Tracing Utility for some time now and I have nothing BUT the best things to say about it. It really helps in my demos that I have done for the past year, including the very successful ones I have done in MS TechED Asia 2004. However, it doesnt work in this new SP2 version of WSE 2.0

To trace the WSE SOAP trails in SP2, I switched over to Simon Guest`s Trace Tool. Although it works well due to the difference in how they captured their traces, I dont really like Simon`s WSE 2.0 Trace Tool. Sorry, Simon. Love all your interoperability works and presentations plus all the efforts you have done revolving around interoperability, just not this tool. i-wink

Let me explain briefly what their differences are (performing my own dissection):

Mike`s WSE Tracing Utility, I believe, works based on filters and streams. It needs some configuration to set this utility up so that its own trace filters can intercept the _SOAP_ messages. It then outputs and writes the captured traces into its console and present it via log message style. I believe it does so using the System.IO.Stream classes. I dont even have to turn on the diagnostic properties of WSE 2.0. Very ingenious, to say the least. i-yes

Simon`s WSE Trace Tool works slightly differently. There is zero configuration on this Trace Tool. Only thing you need to do is to turn on the diagnostic properties of WSE 2.0. It works by reading the diagnostic files that are churned by WSE 2.0. Therefore, it can only output the results after the code has run. It uses either a Timer or a FileSystemWatcher basis to capture any new writes to the diagnostic files. Therefore, it is NOT as real-time as I would like it to be.

Therefore, from the looks of it, Simon`s WSE Trace Tool seems to offer the best chance in terms of integration with the new WSE 2.0 releases. However, it is just NOT as friendly and intuitive as I like it to be.

Mike`s WSE Tracing Utility also offers a quick one-glance understanding of what is the output and input of the traces are. With Simon, it doesnt. I have to figure out and remember the upper pane is the output trace while the lower pane belongs to the input trace.

And the main thing to me separating those two is that I dont have to turn on the diagnostic properties of WSE 2.0 for Mike`s tracing utility. If I turn that on, I have to remember to turn it off once I move it into a production system as the diagnostic files are kept, “logging style”, and it does bloat. What is worse, every write into it appends an entire brand new SOAP message into it and we all know how verbose SOAP can get, with all the new WS SOAP headings and such...and as the file gets bigger, the writes will take longer and it will directly impact on the run-time performance of the entire application.

It doesnt take much to google`d and newsgroup`d the web and you will find that some of the initial hiccups of WSE 2.0 is with regards to the run-time performance of it as the longer it runs. Turning off the diagnostic properties solves this issue right away.

Another thing that I dislike about these diagnostic files is that I cannot delete them right away. IIS has a timing lock on them and only when I reset IIS, then I can delete them. Although it is not directly linked to Simon`s Trace Tool, I can only delete them from the console after I reset IIS which means a toggling of windows. It is still a disadvantage to Simon`s way of capturing the traces. Since Mike uses a stream, there is no file lock to speak of. The only persistant traces are in his console, not in the files, which makes it much more efficient and cleaner.

Simon`s trace tool also has a pesky bug that frustrates me. You have to pick a project folder for him to scan for the trace files. Most times, we have many project folders in a solution directory (for example, SOAP Routing Projects). Therefore, it doesnt work well if I want to capture the trace diagnostics of all projects of a solution. Even if I set the solution folder to be the project folder, it doesnt seem to scan and pick out all the trace files found in all the project folders of the the root folder. It seems, to me, to only display the trace files found in the last-scanned project folder. i-frown. This has a big impact on the aesthetics, especially when I am doing WSE 2.0 demos to a large audience, which I do, quite a fair bit.

Mike`s trace utility, again, got into my good books for this. Because his is based on a stream approach, all “configured-properly” projects of the same solution will be written to the console and displayed very nicely and logically so that anyone can view and understand it right away.

Lastly, there is something about Mike`s trace utility that generates the trace outputs as the WSE 2.0 code runs on the fly that always...and I mean always, gets the WOW out of the audience and that to me, is the single most important factor that makes me swear by his trace utility anytime, anyday...

So, Mike, if you are reading this, this is a call for your action i-smile to fix the issues so it can work with WSE 2.0 SP2 as thousands of people like me are waiting and will Thank you for it. Even more so, many more people in the audiences will Thank you for it too as well because it does help them understand WSE 2.0 and all its related WS SOAP headings a little bit better.