Virtual Developer Workshop: Containerized Development with Docker
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.
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).
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
|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.
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
|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
How it works