The remote scripting technology was created in order to make Web applications substantially more powerful and to make them more closely resemble client/server applications developed using languages like C++, Visual Basic, or Java. By doing this, programmers can overcome the inherent limitations of Web applications. Without remote scripting, a Web browser has only one way to request new information from the server-to load an entirely new page. With remote scripting it becomes possible for the client page to execute a method on an ASP page without navigating away from the current page. More importantly, the requested data is available as the return value of the remote method called by the client page.
Three files constitute the implementation of the remote scripting technology:
These files, along with the official documentation, can be downloaded from the Microsoft Scripting Technologies site ( www.microsoft.com/scripting/ ).
Remote scripting is implemented as a library of functions that you call from a client-side script when you want to run a server method. When a server method is called, the request is routed to a proxy process that runs asynchronously in the browser (in the current implementation of remote scripting, the proxy is implemented as a Java applet). The proxy process then sends a request to the server for the ASP page containing the method that has been called.
The server loads the ASP page, and a special routine on the ASP page sends the requests to the correct function. If the method returns a value, this is then sent back to the proxy process, which packages it as an object called a call object. This contains properties for the return value, as well as other useful information. A call is made with client-side script to a server method in one of two ways:
Security is a key factor nowadays. Remote scripting offers the same level of security as a Java applet or IFrames . To ensure remote scripting does not breach server security, you cannot pass structured data (which includes objects) as parameters to a server script for execution. In addition, the server to which remote scripting calls are made must be the same server that delivered the client page. What do the remote scripting files do?
Staying within the scope of this chapter (and the book) let's take a look at the role of the three files listed above so we can get a more clear idea of what's ˜under the hood' of remote scripting
Here is a look at what the three files are and how they fit into remote scripting:
These three files are everything that you need for remote scripting to work. In the remainder of this chapter we will look at how you use scripting to control these files and make remote scripting work for you.
Lucky for us, the major power and benefits of remote scripting are equally available to VBScript users as well as JScript users.
The remainder of this chapter provides a few guidelines to permit VBScript developers to make use of remote scripting, while at the same time avoiding features that have been shown to work with JScript only. The guidelines show you how to:
To be able to use remote scripting, the remote script files need to be installed on the server.
The default location for the remote scripting files is in a folder called _ScriptLibrary . This folder must be located in the root directory of your Web server.
All the samples in this section will assume that the files used for remote scripting are stored in a folder which is itself located in the root directory of your Web server.
The remote scripting files can be located elsewhere but if you choose to do this then you will have to specify the location while initializing the remote scripting engine both on the client and server side. To avoid any difficulties arising from this, follow the following format while building your first remote scripting project.
If the root directory of your Web server is:
The three remote scripting files ( rs.htm , rsreak .asp , rsproxy.class ) should be locatedreak in the directory:
Any file in your project using remote scripting should be located in a directory like:
On the server the code will be included inside an ASP page. We suggest you use the following skeleton to encapsulate your server-side scripting code and at the same time enable remote scripting.
<%@ language="VBSCRIPT" %> <% ' Write your VBScript remote methods in here... ' Remember to call RSDispatch to initialize the remote scripting engine RSDispatch %>
As you can see, two steps are required:
The remote scripting engine must be initialized on every client page that needs to call remote methods. In this case there is a standard header to be applied just after the < body > HTML element.
Once the remote scripting has been properly initialized we can start invoking VBScript remote methods , entering the sample 'Hello (Remote) World!'
The sample requires two files that should be located in the same directory on your Web server. For example they could be located at:
While the remote scripting library (RS.HTM, RS.ASP , and RSPROXY.CLASS) is located in d:inetpubwwwroot s\_ScriptLibrary
The ASP page that hosts the remote method is called HELLO.ASP . The following is its source code.
<%@ language="VBSCRIPT" %> <% Function HRW() HRW = "Hello Remote World!" End Function RSDispatch %>
VBScript cannot expose remote functions, but it can expose remote objects (with their methods), that give us more power and flexibility. By the way, the remote method is called HRW (and stands for ' Hello Remote World ').
...Function HRW() HRW = "Hello Remote World!" End Function ...
A client page named RSCLIENT01.HTM calls the remote method. The following is its source code.
The remote method is called by the VBScript function.
...Function InvokeHRW() Dim retObj Set retObj = RSExecute("http://me/rs/16/hello.asp", "HRW") MsgBox retObj.return_value End Function ...
The function RSExecute is implemented in the RS.HTM file and gives the developer the power to invoke remote methods on the server without leaving the current client page. It returns an object with an important property called the return_value . This property contains the data retrieved from the server without loading a new page.
The remote method HRW simply returns a constant string ' Hello Remote World ', but it could be attached to a database via ADO, or it could have retrieved data on the server by other means, returning more meaningful and critical information.
Changes are required in both the client and the server page. Using the model directory structure we introduced earlier, the two new files could be located in the directories.
While the remote scripting library ( RS.HTM , RS.ASP , and RSPROXY.CLASS ) is still located in d:inetpubwwwroot s\_ScriptLibrary
<%@ LANGUAGE= "VBSCRIPT" %> <% Class clsHello Public Function HRW() HRW = "Hello Remote World!" End Function End Class Set public_description = New clsHello RSDispatch %>
In this version, the HRW remote method has become a method of a VBScript class named clsHello . The nice issue is that VBScript classes can be used to define a working public_description object.
Modifications are required in the client page. Now we must invoke a VBScript object and not just a remote function. The RSCLIENT02.HTM code is as follows :
In this case we are no longer using RSExecute but a different function available in the remote scripting engine: RSGetASPObject , as you can see from the following line.
Set aspObj = RSGetASPObject("vbhello.asp")
The RSGetAspObject function takes only one parameter that is our ASP page. It actually converts an ASP page into a remote object; in fact, we can call the HRW remote method without using RSExecute .
Set retObj = aspObj.HRW()
All programmers familiar with implementing the object-oriented model will immediately understand the benefits arising from this technique.
The functionality of an ASP page can be divided into remote methods and encapsulated inside an object. On the client side, all the scripting code will invoke remote methods as if they were local.
The numbers of applications of this technique are then just limited by your imagination . Once again, experimentation is the mother of learning and invention. Enjoy!
In this chapter we discussed how to make Web applications using VBScript perform like applications developed using more complicated compiled languages. Specifically, we've looked at using remote scripting technologies and saw how to:
Again, remember that remote scripting is a massive subject. Whole volumes can (and have) been devoted to this topic. This chapter is but a brief taster of what you can do with it. We've covered the basics here, but if you want to learn more you will need to refer to more specialized sources.