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.

Three years ago I did a presentation at Vermont.NET on Architecting Applications with Web Services. (Proof is at the past events page – check Feb 2003!) 

I clearly remember the question of overloaded web methods coming up in that session. I didn’t know the answer so I tried it right then and there and it didn’t work. Someone mentioned there was a way to get around it and we found that solution another day.

It’s still a question for a lot of people who are coming to Web Services as OO programmers (which Visual Studio lets us do) and that is because many are unfamiliar with the attributes that can be used for web services. Or they see them but have no idea what they are there for.

Thom Robbins recently had someone ask the same question and blogged how to use attributes to enable overloading when defining web methods in Visual Studio.NET.

Three years ago, it seemed like a good idea to me. I didn’t really grokWeb Services. I was just using them as a means to an end and I knew OO programming, not messaging.

However, now my perception has changed and it’s important to note (as Thom does (thanks Thom!)) that just because you can do it, doesn’t mean it’s a good thing. It’s the OO way, for sure, but it just does not jibe with messaging and contracts and it does not conform to WSI Basic profile which demands unique names for operations (web methods). So if you have any intentions of going outside of .NET with your messaging, don’t do it. A contract needs to be clearly defined and by providing overloads, that just blows the contract away.

If you are writing what the plumbers call "silo" apps, .NET all the way through and you are controlling the client and the service, there’s no harm outside of the damage you are doing to your brain. Still, it’s important for the WSDL that represents your web service identifies does not identify itself as conforming to WSI Basic profile. When you create a new web service in VS2005, by default, the service has attributes that claim to conform to the Basic Profile. Thom includes the caveat in there to set the services’ conformance claims to "none".

Here’s what a .Net web service class that shows what Conformance Claims  looks like. ConformsTo is the claim. Emit embeds the claim in the wsdl.

<WebServiceBinding(ConformsTo:=WsiProfiles.BasicProfile1_1, EmitConformanceClaims:=True)> _
<WebService()> _
Public Class ShowConformance
  <WebMethod> _
  Public Function HelloWorld() As String
   Return "Hello"
  End Function
End Class

If you look at the wsdl (eg http:\\localhost\myservice.asmx?wsdl) you can see that claim. Here is the appropriate section of the wsdl.

When you explicitly define that the service does NOT conform, there is no claim in the WSDL that says "I do not conform". In that case, no claim is made at all.

So by marking your service with

ConformsTo:=WsiProfiles.None

even if you have EmitConformanceClaims set to true, there will be no wsi:Claim in the wsdl.

If you forget to remove the conformance claims, you will get a big fat error message when you try to call the asmx.

Service ‘Service’ does not conform to WS-I Basic Profile v1.1. Please examine each of the normative statement violations below.

and the detail tells you:

To make service conformant please make sure that all web methods belonging to the same binding have unique names.

The more you start understanding these things today, the more prepared you will be for WCF.

Don’t Forget: www.acehaid.org