I saw this question in the newgroups and wanted to blog about it because it is a real gotcha that gotme too when I first started working with WSE 3.0.

If you set the WSE 3.0 diagnostics tab to output trace files, you can get a look at the messages going out of and coming into your client as well as going out of and coming into your webservice.

Tip #1 Remember to turn OFF this tracing when you send your client app or web service into production. Left to it’s own devices, the trace files will grow and grow and grow and one day you will be wondering why your web service is acting so slowly. That’s because of the effort of opening up a 60MB file to add some text to the bottom of it!

Tip #2 The default file names are TraceInput.webinfo and TraceOutput.webinfo. Those extensions suck because you can’t open them up in anything easily. I always change them to TraceInput.webinfo.xml and TraceOutput.webinfo.xml. Then I can double click on them and open them up in something like I.E. or an even more intelligent angle bracket reader. (Note:Nathan (a tester on the WSE team) makes a good point about this. If you forget to do #1, then #2 could very easily expose some super critical data for hackers on your production server! So you might be better off without this particular little trick of mine.)

Tip #3: Reading the trace files, remember that there is more than the header and body of the message in there. There is also processing info. That means that in an output file, the first thing you will see is the unprocessed message. Your app has created the message, but it hasn’t been through WSE yet to get all it’s protection before it’s sent out on the wire. This is very confusing and can even be a little frightening because if you have encrypted your message, the first thing you see is a message body with clear text! Notice,though, that it is surrounded by tags that say <processingStep description=”Unprocessed Message”>. Now at the bottom of that <outputMessage> and you will see the <processingStep description=”Processed message”>. That is the message that is going out on the wire and hopefully looks more like what you expected.

On the incoming message, the first thing in the door (again the Unprocessed Message) is what just came in off the wire. So that is the real soap message and should display all of the properties you expected – encryption and any thing else you demanded of the message. Then you can read through the processing steps and the last step has the fully processed message that is about to get passed to your application. All of the security goo is gone and you will see clear text again, even when the actual message was totally secured.

Tip #4: If you want to see only the soap that went over the wire, bag the built in tracing and use Mike Taulty’s sweet little WSE 3.0 Tracing Tool.

Tip #5: For even more detailed inspection and diagnostics of your web service messages, check out Mindreef’s SoapScope.

Don’t Forget: www.acehaid.org

  Sign up for my newsletter so you don't miss my conference & Pluralsight course announcements!