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.