Thanks again. Your blog is definitely on my greatest hits list.

The HttpContext/Session is available in standalone services too. You just need to add EnableSession=true in the [WebMethod] attribute:

[WebMethod(EnableSession=true)]
public string HelloWorld()
{
  return "Hello, " + HttpContext.Current.Session["Name"];
}

Excellent, you made my day! I’m going to plunge forward with the web methods then…

A megabyte of thank you’s for your input.

Kerminator

Just an afterthought – that session variable existence approach would not work in a web service, would it?

You’ll need to reference the Session explicitly though, since there’s no Page instance to shortcut it for you. HttpContext.Current.Session.

Similarly, you can use HttpContext.Current.Response.StatusCode to respond to unauthorized requests with the correct HTTP status code (401 or 403, probably).

However, our website has its own homegrown login/pw mechanism which, when successfully completed, places a customer number into a session variable. Could I not check for the existence of that session variable in my web method and if it isnt there, return a negative response of some sort and not do the SQL table add that the method was designed to do? So while not keeping intruders from calling the web method, it would prevent them from doing any damage.

Sorry if I sound like a dufus, but this Ajax/webservice/webmethod paradigm is all new to me.

Do static web methods have an advantage from that perspective? Is there existence not exposed to the world like a web service is?

I’m a little worried about the use of Static methods. In a multi-user environment (i.e. just about any web application), I thought that maybe each call to the method would be shared between all users, including any internally declared variables. To test, I created the following:

    [WebMethod(true)]
    public static string WebMethod(string passedString)
    {
      string localString = passedString;
      System.Threading.Thread.Sleep(5000);
      return localString;
    }

Called by:

 
    Click here for the test.

  $("#Result").click(function () {
    $.ajax({
      type: "POST",
      url: "Default.aspx/WebMethod",
      data: "{'passedString' : '" + $('#textboxTest').val() + "'}",
      contentType: "application/json; charset=utf-8",
      dataType: "json",
      success: function (msg) {
        $("#Result").text(msg.d);
      }
    });
  });

I open up two browsers, one Chrome, the other Firefox, just to make sure. In the textbox in each browser, I typed the browser name for clarity.

To my pleasant surprise, when I clicked on each “Result” div within the 5 seconds of the first click, the text updated in each respective browser/session was as hoped, namely “Chrome” in Chrome and “Firefox” in Firefox.

I’ve tested this to satisfy myself, but I was wondering if you could elaborate as to how this happens, and why the static WebMethod is not behaving like a static variable. OR, have I made a mistake in my testing, and not proved anything?

What I mean: of course the meanest and leanest web apps are the ones which do not keep state on the server, whether they are written in Java, ASP.Net, PHP or whatever. But there are apps which cannot be reasonably implemented without keeping state information on the server. However, ASP.Net does not provide a solution for such apps. ViewState provides a workaround, but isn’t really a solution for such apps. Why? Because if your state information is large, serialization and deserialization from ViewState is going to take a lot of time, enough so that your application is slow.

The only solution to developing fast, responsive, really web2 apps using ASP.Net is giving up server controls altogether, use a client-side only Javascript-based Ajax toolkit/framework and work with web services/web methods alone. Which of course have to be session/view state-unaware. But since MS does not provide such a toolkit integrated in ASP.Net, doing so is not quite happy coding. Until you get your toolkit of choice properly interfaced with an ASP.Net backend, it’s not really happy coding.

Web Methods do have an advantage over web services, though: they’re significantly easier and simpler to implement. However, they also have a drawback: if you don’t use them from ASP.Net, it’s not really easy to call them. But then again, JSON-based Web Services implemented using ASP.Net are also not quite straightforward to call from non-ASP.Net code.

IMO, web methods are always the better choice when you implement functionality which is not reusable. You implement web services whenever there’s a chance some other code than the one for which you write your web service will be able to make use of your web service. Whenever you need just a more or less calculation which needs to be performed server-side, but which is pertinent just to the form from which you call that code, a web service is just unnecesarily polluting the global namespace of web services exposed by an application/server/enterprise infrastructure.

A solution could be.. calling from the static PageMethods to external webservice project.
in this case you can use non static objects and method on the external ws.
You can also add “ip security” to the external ws.