Overloading in WebMethods, part II


OK, I lied.

In the prior article on overloading in webmethods I took the position that it is a dangerous thing to do.  BUT…, that’s not completely true. Just a wee bit false.  A tiny bit of dissembling. 

A good way to apply overloading to webmethods is to modify the generated client-side proxy.  Lots of people, I am not sure why, take the view that the proxies generated by Visual Studio’s “Add Web Reference…” or by the wsdl.exe utility, or any similar tool in any other web-service enabled toolset, are inviolable, unchangeable, as if handed down on stone tablets from heaven.  Ah…… No.

Look, people, they’re just tools.  Don’t worship your tools.   If you like what the tools produce, good for you.  If you want to change what the tools produce, that’s fine, too. 

SO, let’s suppose you have the situation described previously, and you want an overloaded webmethod.  We know from the prior article that this is a non-match – the webmethod is mapped to a message on the wire destined for an endpoint.  Overloading does not apply, if you look at it this way.  But overloading does apply if you consider the webmethod from the client (or sending) application, or from the view of the programmer who is building that client.

From that vantage point, the webservice is a proxy class, and the webmethod is simply a method on that class.  The class is generated, and when you use the MessageName property on the webmethod to implement “overloading”, the client-side proxy generated by wsdl.exe exposes a method with the same name as the MessageName.  In other words, the overloading disappears, once you run the WSDL through a tool.

But who’s stopping you from taking the generated client-side proxy, and modifying the name of the method, to produce overloaded methods in the proxy class?  Not me!

And, you can apply the same principle to proxy classes generated from just about any webservices toolkit.  It also works in Java, folks!

So, you want overloading on your webmethods?  It can be done.  Be sure you understand what’s really happening on the wire before you do it.

The Objections Start

I can hear you thinking (yeah, you!), “well, this is not a real solution!  I have an automated build and I can’t modify the generated proxy in the automated build.”  Or you’re thinking, “this is too much to ask!  Developers shouldn’t need to understand the wire-level protocol details in order to use overloading, come on!”

To the first bunch of you: No.  There are lots of build  automation tools that can be setup to allow in-stream editing of generated files.  Ever heard of sed.exe?  Perl?  And these things work in Nant, or even in makefiles.  You can produce a post-compile step in VS, stuff in in a .bat file.  Come on, there are lots of ways. Figure out a way that works for you.

To the second bunch: you’re right.  the mainstream developers should not need to know all this in order to take advantage of overloading in webservice interfaces.  However, the application architects DO.  So if you’re the architect, hide all the details you want.  What I am saying is somebody has to know what is going on. 

mmkay, that’s it for now.

-Dino

Comments (4)

  1. SuperJason says:

    Am I missing something here? Why couldn’t you just inherit the client side proxy code and create an overloaded function there? I would think that would make everyone happy.

  2. AndrewSeven says:

    This probably scare lots of people away 😉

    // Changes to this file may cause incorrect behavior and will be lost if

    // the code is regenerated.

  3. Dino says:

    > Why couldn’t you just inherit the client side proxy code and create an overloaded function there?

    SuperJason, That would make sense, wouldn’t it? The problem is, the wsdl.exe tool (or add web Ref in Visual Studio) generates code that is decorated with attributes that are used by .NET’s Web services runtime to decide what sort of messages to accept and return. For example, an attribute in our example uses the http://tempuri.org namespace for the generated XML document. These attributes are not inherited by subclasses, and attibutes on superclasses are not examined by the web services runtime. So. if you subclass, you need to cut-n-paste all the attributes on the class and on each and every webmethod.

    This is doubly error prone, because if you re-gen the proxy class, then you need to re-cut-n-paste. The good news is that this gets much much better in Whidbey. But for those of us who use software available TODAY, I recommend modifying the proxy code.

  4. Dino says:

    AndrewSeven remarks:

    > This probably scare lots of people away 😉

    Yes! you are correct. Care should be taken lest the careful mods you make are destroyed by the tool the next time you run it. Rename the file when you modify it!