views:

594

answers:

2

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.

+4  A: 

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
+1 Good answer! :-)
REA_ANDREW
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.
Braveyard
Thanks for clean and elaborate answer.
Braveyard
+1  A: 

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
I'm pretty sure he's talking about the server side, not the client side.
John Saunders
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
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
"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
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.
Braveyard
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
Thanks for you help.
Braveyard
@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
@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
@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
I did some more looking on this topic and found some discussion here: http://weblogs.asp.net/jasonsalas/archive/2004/02/03/66595.aspxOne 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
@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
Then we must agree to disagree and be done with it.
Joshua Hudson