17

I just wanna learn why I can't static web methods in web services ? Why is it restricted ?

Can some body give me concise explanation of this.

John Saunders
  • 160,644
  • 26
  • 247
  • 397
Tarik
  • 79,711
  • 83
  • 236
  • 349
  • BTW, are you aware that Microsoft now considers ASMX web services to be "legacy technology", and that they've stopped fixing bugs there? You should be using WCF. – John Saunders Aug 11 '09 at 22:49
  • 1
    Atarikg, WCF supports basic webservices in it's implementation as well as much more more (It is a huge, full framework). It is pretty slick. I'm not sure if static methods are allowed in a WCF service though off the top of my head. – Joshua Hudson Aug 11 '09 at 23:52
  • Thanks to you.I am actually searching for WCF and it looks pretty slick :) – Tarik Aug 12 '09 at 00:30
  • But I think it's not gonna be as much easy as Web Services. Since if it is a huge full framework, there will be so much things to consider about. – Tarik Aug 12 '09 at 00:34
  • 1
    @Aaron: Actually, you're mistaken about how hard it is. Create a new WCF service project and look at how simple the "Hello, world" application is. Not much more complicated than the ASMX version, and mostly because it has two operations. One is to demonstrate data contracts. Change the binding in the config file from wsHttpBinding to basicHttpBinding, and it will be just like ASMX, only not "legacy". – John Saunders Aug 12 '09 at 01:25
  • Thanks John :) I've just watched a video at http://msdn.microsoft.com/en-us/netframework/dd939784.aspx and there are videos for beginners and it's not that much hard to learn :) – Tarik Aug 12 '09 at 04:26
  • 1
    @Aaron. Just remember your ABC's of WCF and you are good to go (Address, Binding, Contract). The benefits FAR outweigh the learning. Also since you are writing contracts you think more about the data you are going to expose with your services, which is always a plus. Finally, the ability to expose a service with multiple bindings really is the slick part. – Joshua Hudson Aug 12 '09 at 04:37
  • Thanks Joshua,I'll keep ABC in my mind. – Tarik Aug 12 '09 at 04:54
  • and In case any other people may need it,I've found something pretty useful for beginners at wcf. http://msdn.microsoft.com/en-us/magazine/cc163647.aspx – Tarik Aug 12 '09 at 05:05

2 Answers2

23

The answer is: because you can't.

It's not designed that way. The design is that an instance of the web service class will be created, and then an instance method will be called.

I can only guess why Microsoft designed it that way. To know for sure, you'd have to ask them. Consider:

  1. There's no particular benefit to permitting static methods. Anything you can do with a static method, you can also do with an instance method.
  2. A [WebService] class is not meant to be some arbitrary class that happens to be used as a web service. It's meant to be a class that you created for the purpose of exposing web service operations. As such, there is no need to support classes that already exist and already have static methods.
  3. The SOAP Header implementation permits your class to contain an instance field of a type deriving from the SoapHeader class. This field will be filled with an incoming SOAP header and/or will contain the SOAP Header to be returned. You could not do this with a static field, as it would be overwritten with each request.

As I said, these are all guesses. The correct answer to the question is, "you can't because that's how Microsoft designed it. If you want to know why they designed it that way, you need to ask them".

FWIW, I just checked, and it does not appear that WCF permits static methods to be operations either.

John Saunders
  • 160,644
  • 26
  • 247
  • 397
  • 3
    But I am asking why ? They wouldn't simply say "Well guys we are not gonna design this thing in that way, instead, it is gonna be designed in this way. blah blah". What I am asking is the reason behind this. – Tarik Aug 11 '09 at 23:30
  • Thanks for clean and elaborate answer. – Tarik Aug 12 '09 at 04:31
3

When a client creates an object for your web service, what they are really creating is a proxy object to that web service. This proxy object handles things like opening and closing your connections for you as well as all the overhead of actually working with the web service. A static method call would be difficult to manage. The "static proxy" for lack of a better word would have to do all of things that the instance of the proxy object is doing each and every time a client called one of the static methods, thus adding massive overhead.

Joshua Hudson
  • 2,187
  • 2
  • 20
  • 24
  • I'm pretty sure he's talking about the server side, not the client side. – John Saunders Aug 11 '09 at 22:47
  • 1
    My answer answers his question in way I think helps explain why static methods on the server side would not work. Just saying that web services are designed so they can't does not say why they were designed that way in the first place. – Joshua Hudson Aug 11 '09 at 22:49
  • But that's not the reason. What happens on the server has little to do with what happens on the client. There is no correspondence between the client-side proxy and the server-side web service instance. The server side is not instantiated simply because the client proxy is. Based on this reasoning, I'm going to have to downvote. – John Saunders Aug 11 '09 at 22:53
  • 1
    "There is no correspondence between the client-side proxy and the server-side web service instance." If this is the case how do the two even speak to each other... – Joshua Hudson Aug 11 '09 at 23:01
  • Pretty nice answer. Thanks. So that means they were thinking of avoiding overhead and keep things simple and I think it makes each call independent from each other. – Tarik Aug 11 '09 at 23:32
  • 1
    I believe so atarikg. I don't work for Microsoft, nor am I a member of the .NET team, but I would think anything to keep web services simple while avoiding overhead would be a good reason to make this restriction. – Joshua Hudson Aug 11 '09 at 23:47
  • @Aaron: sorry, but it has nothing at all to do with that. Creating an instance of the client proxy does not create an instance of the service class. – John Saunders Aug 12 '09 at 01:20
  • @Joshua: An ASMX client proxy and an ASMX service instance speak via SOAP messages, exactly the same way a Java proxy instance would speak to the ASMX service instance. Surely you don't think that when a Java proxy instance is created, this creates a .NET instance on the server! It's not until the SOAP message is received that .NET creates the service instance. – John Saunders Aug 12 '09 at 01:22
  • @John Your final statement is correct. I see what you were saying now about the "There is no correspondence between the client-side proxy and the server-side web service" now with your further explanation. You are correct that the two speak via SOAP. However, I was merely making a suggestion that a possible reason the server side would not support this is in fact due to client implementation. – Joshua Hudson Aug 12 '09 at 04:26
  • I did some more looking on this topic and found some discussion here: http://weblogs.asp.net/jasonsalas/archive/2004/02/03/66595.aspx One of the comments states what I was trying to get at, though I was not as clear as I should of been. See final comment by Jason. Since Microsoft developed the entire stack (ASMX server side + the client implientation of the proxy), this is a guess but they could have put the restriction in on the server since the client could not handle it. I will agree to agree with you on that we can only base our answers on guesses and be done with it. – Joshua Hudson Aug 12 '09 at 04:29
  • @Joshua: That blog post is nonsense. Second, Microsoft would not have developed the server to be created when the client proxy is for the simple reason that they did not forget (as you may have done) the simple fact that the server code will be called by code not running .NET. Don't take this wrong, but you've made a novice mistake in your reasoning. The Microsoft team that developed ASMX were not novices at network software. – John Saunders Aug 12 '09 at 09:06