From my own experience with Sam's well-written WSDL BDG I think I understand Jake's concern (and Userland's in general). While using Sam's guide made it fairly easy (not yet trivial) to build my own WSDL describing a service in Radio, that does not quite solve the whole problem - because I had to write it by hand. It is pretty easy to imagine a tool that automatically creates the same WSDL I wrote by hand. But there is a caveat. I did not define any complex types for my WSDL. In my example the Radio web service returned a complex type - well, just an array of structures, but that is complex enough. I could have created the WSDL type definitions to do that (if I had a BDG for that task)! Lacking those type definitions, my .NET client could only pick up the XML nodes in the response. Thus, my .NET client had to understand the XML structure being returned. Not a big deal; if a native type structure had been returned the client would require a similar understanding. Nevertheless, I suspect this is Jake's point. Languages with reflection capabilities can dynamically create those WSDL type definitions, putting their clients in a better position to consume a SOAP web service because the response is returned in native types (e.g. an ArrayList) rather than as an array of XmlNode objects. Dynamically typed languages appear to be at a disadvantage. It is not an unworkable disadvantage, just a difficult one.
3:58:09 PM  [Macro error: The file "" wasn't found.]     

Here is what I found. When calling the remote web service from my local copy of Radio, results are always returned in less than one second (actually, less than 1/2 second). Invoking the same service from a .NET client routinely takes five to seven seconds (this does not take into account loading the client assembly). That is a substantial difference, so I decided to find out where the time was being spent. I found that the call itself was taking just less than two seconds. Most of the remaining time was in creating an instance of the WSDL-generated wrapper class for the remote web service.

The generated class is fairly simple looking. I figured the extra time must be consumed in locating and loading the assembly containing the class - so I tried loading the assembly myself within the client. That appeared to shave off a little time (about two seconds), but not much. That seems to suggest that the underlying .NET framework (HTTPChannel, Sinks, SoapFormatter, etc.) is fairly costly to set up. This is verified, I believe, by the fact that subsequent invocations of the service ran comparatively quickly. The second call always ran in less than two seconds - including creation of a new wrapper instance.

Let me be clear in stating that these are not formal findings. Just interesting informal observations. I am sure more knowledgeable developers can point out ways to speed up my .NET code. I just find it interesting that the out of the box solution appears to be relatively slow. If multiple invocations of a remote service are involved, this probably does not matter much. For one-off invocations the delay is noticable. Given the choice, I would rather invoke from Radio.
2:48:47 PM  [Macro error: The file "" wasn't found.]