Mike Taulty's Blog
Bits and Bytes from Microsoft UK
WSE 3.0 Preview: Updated WSE 3.0 Tracing Tool
Mike Taulty's Blog

Mike's Badges

Follow on Twitter
View mike's profile on slideshare
Add to Technorati Favorites
CW Blog Awards

I've had a go at porting my WSE Tracing Tool (see here and here) to work with the June WSE 3.0 Community Technical Preview which, in turn, requires .NET Framework 2.0 Beta 2 and plugs in to Visual Studio 2005 Beta 2.

The download is here: http://mtaulty.com/downloads/Wse3Trace.zip - please feel free to try it out and let me know whether or not it works for you.

It's probably worth saying that the implementation has changed once again :-)

The way that I've done tracing with WSE 2.0 in the past has always been to create Filters in the pipeline and the filters simply copy the SOAP message and send it over soap.tcp to the tracing client which displays them in its UI. So, we're using WSE to trace WSE.

In creating filters to do tracing the ordering is important. I want my tracing filter to run nearest to the wire but, usually, WSE wants its Security (or tracing) filter to run in that place. I've gone through a couple of iterations on this for WSE 2.0 and then WSE 2.0 Service Pack 2 and now we have a new one which I'm hoping is a lot less hacky than what I did for WSE 2.0 Service Pack 2.

In this new version I implement tracing as a custom PolicyAssertion. This means that in order to get tracing you'll have to have a policy and you'll have to be using it from your service and/or your proxy. I don't think that's any big deal as I'd probably expect every service/proxy to be using policies in one way or another.

PolicyAssertions get to create input and/or output filters for the WSE pipeline on both client and service ends of the conversation. For the tracing tool, those filters are the same ones I had before so the only new bit is the use of PolicyAssertion. What's proved nice for me is that it looks like WSE honours the order of the assertions in the policy file when it comes to creating the filters. That works a treat for what I want to do!

As a quick sketch....If you had a service such as;

[WebMethod]

[Policy("MyPolicy")]

public void DoSomethingRevolutionary()

then you'd need to have a config file that looked something like this;

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <configSections>
        <section name="microsoft.web.services3" type="Microsoft.Web.Services3.Configuration.WebServicesConfiguration, Microsoft.Web.Services3,

            Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
    </configSections>
    <microsoft.web.services3>
        <policy fileName="../../wse3policyCache.config" />
    </microsoft.web.services3>
</configuration>

which just links across to your policy file. Then you'd have a policy file which looked something like this;

<policies>
    <extensions>
        <extension name="wse3Trace" type="WSETracingFilter.WSEFilterAssertion, WSETracingFilter, Version=3.0.0.0, Culture=neutral, PublicKeyToken=aa253a6b9020c4eb"/>
        </extensions>


    <policy name="MyPolicy">
        <wse3Trace traceInput="true" traceOutput="true"/>
    </policy>
</policies>

and that would set it up to trace for you. As I say, there's a sample installed to the Start menu so it should be a matter of copy-and-paste to get it working once you've got a hang of how Policy works in WSE 3.0


Posted Mon, Jun 27 2005 11:39 AM by mtaulty
(C) Mike Taulty, 2009. All rights reserved. The information in this weblog is provided "AS IS" with no warranties, and confers no rights. This weblog does not represent the thoughts, intentions, plans or strategies of my employer. It is solely my opinion. Inappropriate comments will be deleted at the authors discretion. All code samples are provided "AS IS" without warranty of any kind, either express or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.
Powered by Community Server (Non-Commercial Edition), by Telligent Systems