Introduction
I am going to discuss one of the important but less used features in a real-world scenario: the capability of calling a server method from a client script. But, before you start looking at this article’s topics, it will be better if you ask what happens when you send a request for a page from a browser so that you can understand what happens behind the scenes and why the same is not straightforward.
However, I am not going to explain how the request maps of IIS or how server-side code and client-side code differs. If you are looking for this, first you must be sure that the client script is not run at the server from which you request your page through the URL and that it runs on your browser and the server code runs at the server). Thus, what happens when you send a request for a specific URL from your browser is that you send a command to the target URL or IP address, asking it to give you the requested page. The browser opens a socket to the target URL or IP address and waits for the response; upon receiving the response, it displays according to the content type.
Therefore, every time you get a new page even though you are posting to the same page (ASP.NET). This is what called the stateless architecture of HTTP. To make the client talk to the server but yet not have the page postback or refresh, some sort of secret or behind-the-scenes request is required from the client script; later, the same needs to be mixed with the current contents of the browser.
People often ask how they can invoke/validate their data from the server without a post back because they need to invoke the same from a client script. A practical example of this is that you need to validate some 10–15 fields in a Web form from the client side, without a page refresh, or perhaps you need to call a server function without submitting the page. There are many pros and cons with these approaches of invoking a server method from client script or calling a Web service from a script as well as quite a few methods/techniques have evolved and been adopted successfully. The three primitives are remote scripting, Web service behavior, and script callback.
Although there are other alternative practices to adopting good caching (the page still gets refreshed although data will come from the cache here) or using hidden field transfer, the data from and to the server and client or preloading all the possible alternatives in client memory through XML or any other format. All of these work fine, but there are times when the amount of data is just too overwhelming for all the possible combinations.
I know that by giving such power to a client script, there are a lot of security concerns but there are workarounds and, for intranet applications, adapting such techniques is much better and essential sometimes. I will discuss the pros and cons of each technology; also, I’ll discuss the working of Remote scripting, Web service behaviors (with an example), and script callback (in detail with an example).
Remote Scripting
This is one of the first and earliest technologies used for calling the server method from a client script. In remote scripting, a hidden request is made to the server to execute a method to return the data required; the plus is the entire page is not required to be processed in the server. There were two popular remote scripting techniques used in past: Microsoft provided the client- and server-side include files for carrying the task in a Scriptlibrary directory, and the Java Version of JSRS in JSP; it created a hidden element on the page that submitted the request to the server which then respond back to it based on the browser. However, the Microsoft model was the only version that supported both Synchronous and Asynchronous mode (the Java version only supported Asynchronous mode).
The workings of remote scripting
Remote scripting uses HTTP requests to the server over port 80; this is helpful for firewall negotiation. It provides the mechanism to call code on the server using three components (client-side Microsoft Java Script, Client-Side Java Applet, and Server-Side script). To implement the same, you add a script block to the page and call the RSEnableRemoteScripting function. This function will load the Java applet onto the page, based on the browser. The applet provides the communication mechanism through HTTP to the server. Please refer the References section if you need the details regarding the same.
Pros and cons of remote scripting
Pros | Cons |
---|---|
Protocol is lightweight—it uses HTTP GET | Remote scripting uses its own non-standard, XML-based protocol |
Can work with IE, Mozilla, Netscape | Hard to debug |
Limit of only 4 Kb of data transport. Not restricted to doing HTTP GET |
Web Service Behavior
By using Web service behavior, you can invoke the remote method exposed by the Web service or other Web server that supports SOAP and WSDL from the client script. The Web service behavior supports a large number of data types, including intrinsic SOAP data types, arrays, objects, and XML data. The Web service behavior is implemented with an HTML Component (HTC) as an attached behavior; thus, it can be used with IE5.0 and later.
How it works
By using the Web service behavior, you can call a Web service method from the client script in both modes: synchronous or asynchronous. To invoke the method, first you need to attach the webservice.htc to the page.
The next step is to call the Web service in sync or async mode. The syntax is:
service.useService("WSDL path of websvc","servicename"); service.Service1.callService(callbackfunc,"webmethod name", parameter value);
The asynchronous mode of method invocation is the default mode of the Web service behavior. For the Sync mode, you need to set the async=false of the callObj and pass the same.
Example
var callObj = new Object(); callObj.funcName = " webmethod name "; callObj.portName = "Port1"; callObj.async = false; service.useService("WSDL path of websvc"," servicename"); service.Service1.callService(callbackfunc, callObj , parameter value);
For a detailed example, download the accompanying code.
Pros and Cons of Web Service Behaviors
Pros | Cons |
---|---|
Not restricted to doing HTTP GET for server requests. Remote Scripting is limited to 2 Kb of data when making a request to a server. The Web service behavior uses HTTP POST, so it doesn’t suffer from this restriction | Limited to a specific browser (IE 5.0 or above) |
Allows you to take advantage of .NET functionality from within a browser | Memory leak (see References) |
Works great with ASP.NET so that you can take advantage of all the enhancements (speed, compiled languages, .NET Framework) that ASP.NET offers |
Script Callback in ASP.NET 2.0
Overview
The idea behind script callback features is not different from remote scripting or Web service behavior; it serves the same purpose, but this time there is no applet and it is already implemented as part of the script model for ASP.NET 2.0 together with many other important and wonderful features. To make the script callback work, you need to define a trigger element that retrieves input data from the current page and binds the same to some JavaScript code. This will prepare a call to a built-in script, webform_docallback, which will open an HTTP connection to the remote ASP.NET page from which you’ll retrieve the required values. Now, the ASP.NET runtime detects the callback and executes a particular method (server side) and returns the executed value back to the client. As a response on the client side, the response is passed to a user-defined callback JavaScript and then mixed with the client contents thru DHTML. The same features are built in with many controls with ASP.NET 2.0.
How it works
When a call made thru webform_docallback (rather, the connection is established), how does ASP.NET know that this is a normal request or callback one? The HTTP handler decides by looking into the request header and body for the _CALLBACKID that was generated by the docallback process. If it finds that it is a callback, it sets page.iscallback=true. Further, the requested page and controller should implement the ICallbackEventHandler interface so that it could be differentiated from a postback. If a page implements the ICallbackEventHandler, it has the <%@implements Interface=system.web.ui.ICallbackEventHandler %> directive. If a control implements the Icallbackhandler interfacen the ASP.NET runtime invokes the RaiseCallbackEvent method on the interface and prepares the response from the results of the call. The ICallbackEventHandler interface has one method with a string parameter and a string return type. The parameter is taken from the request collection. The point to remember is that the GetCallbackEventReference method returns a string that represents the JavaScript function that invokes the Remote method. This string is bound to a client-side event.