Remote Script document (reprinted from Microsoft) (i) _ long-distance scripts

Documents: Remotely executing server scripts

Complex WEB applications call both client script and server script. Client scripts are often used to program the user interface of an application-for example, to dynamically change Web page text, react to user actions such as double-clicking, and perform client-facing tasks such as validation. Client scripts are executed locally in the browser, providing a vivid, responsive interface to the user.

In contrast, server scripts are used to program the last segment of an application. This often leads to access to a database or to the execution of intermediate-level business logic. Server scripts are also used to create a larger range of applications: that is, applications that can be accessed through many different types of browsers, each with different access capabilities.

However, client and server scripts are mutually exclusive. When a page is first requested, the server may run a server script and pass the page to the browser, and then the browser can run the client script. However, if the server script on the page is necessary to run again, the page must be submitted back to the server, and the server can effectively rerun the page. Maintenance of controls on the page and the values in the script may involve a complex scripting process of passing information back and forth between the browser and the server. In addition, the reentrant process between the client and the server involves displaying an overloaded procedure for an application.

A compromise is the remote scripting. Remote scripting allows users to work in client scripts, but to invoke methods (functions or routines) in an ASP page. In fact, users can invoke server scripts as they would call local routines, but they still run on the server and have all the access to the server's capabilities. Because the user never leaves the current page as the calling server script, the page state remains.

Users can use remote scripting in the following tasks:

Data checking and data validation on the server when the user continues to interact with a data entry form.


Update the information from the server's pages without refreshing the screen.
How Remote Scripting Works

Remote scripting is implemented as a library of functions that users call from client scripts when they want to run a server method. When a user invokes some kind of server method, the request is passed to an agent that runs asynchronously in the browser (the broker is implemented as a Java applet during the implementation process). The agent process sends a request to the server that contains the ASP page of the user invoke method.

The server loads the ASP page, and a special routine on the ASP page dispatches the user's request to the correct function. If the method has a return value, the value is sent back to the agent process, which wraps it as an object--a calling object--it contains the properties of the return value and other useful information.

When a user invokes a server method in a client script, you can choose one of two ways to do so:

The synchronization user script invokes the remote procedure and waits for it to return. If the user needs a remote process result before processing, then it is necessary to do so.


The asynchronous user script invokes a remote script and continues processing. The page remains in a valid state for the user to process. If a call is to last for a long time, it is necessary to use an asynchronous invocation.
Parts of Remote scripting
In order to achieve remote scripting, the following files are required in addition to the user's own client (. htm) file and server (. asp) files:

Rs.htm contains methods that users use to initialize remote scripting in their own. htm files, perform remote procedures, check remote invocation status, and obtain method results.


Rs.asp contains the methods that users will call to initialize the server-side remote scripting in an. asp file, and to dispatch to the appropriate function in their own pages.


Rsproxy.class Java class file (object code) that contains the applet when communicating between customer and server Pages.
These files act as a repository that users can use in their own files. In general, users simply need to include related files (rs.htm or rs.asp) in their own client or server Pages, and then follow the required invocation method. For more information, see Making remote scripting available on the customer page and making remote scripting effective on the server page.

In the user's customer page, the user references rs.htm, which makes the methods in the file valid for user server scripting. The call to the Rsproxy applet is in these methods. When a user creates a server page, the user adds a server-side include statement-the statement references the rs.asp file-included. Accompanying the rs.htm in the customer file, this makes the desired method available on the server page.

All files must be valid on the server. Users can place them wherever they are fit. However, for the user's client and server files, the path must be valid when the request is made from the server. By default, the remote scripting process assumes that these files are valid in a folder named _ScriptLibrary outside the virtual root directory of a user server or project. If users do not put them there, pay special attention to their paths, because the user needs to specify the client and server Pages when they are created.

Remote Scripting and Security
remote scripting  provides security at the same level as  Java applet  or  IFrames . To ensure that  remote scripting  does not violate server security, a user cannot pass structured data (including objects) as parameters to a server text for execution. In addition, the server that the user makes  remote scripting  calls must be the same server as the user requesting the client page that contains the request.