Remote Scripting

Overview

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.

Combined with DHTML, this technology greatly simplifies all the applications that were previously forced to use cookies, hidden HTML input fields, or other dirty tricks to rebuild the new page as similar as possible to the previous one.

The Influence of JScript on Remote Scripting

Unfortunately for VBScript users, the current implementation of remote scripting was created for JScript (the Microsoft equivalent of JavaScript). Microsoft developed remote scripting as part of a larger project called the Microsoft Scripting Library. In fact, the current implementation is a library of functions to enable remote scripting features, plus a little something else-a Java applet. Many users are very surprised when they come across these files and think that they must be having the wrong files or that different files relate to them. Don't worry-you have the right files!

Three files constitute the implementation of the remote scripting technology:

• RS.HTM -a collection of JScript functions to be used on the client page
• RS.ASP -a collection of JScript functions to be used on the server ASP page
• RSPROXY.CLASS -a Java applet that plays the vital role

These files, along with the official documentation, can be downloaded from the Microsoft Scripting Technologies site ( www.microsoft.com/scripting/ ).

How Remote Scripting Works

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:

• Synchronously-The script calls the remote procedure and waits for it to return. This is useful if you need the results of the remote procedure before you proceed.
• Asynchronously-The script makes the call to a remote script, and then continues processing. The page remains available for users to work with. Asynchronous calls are very useful when a call might take a long time.

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:

• The Java applet RSPROXY.CLASS is inserted automatically in the client page during initialization by the RSEnableRemoteScripting function. The role of this Java applet is to send the HTTP request to the server and receive the response.
• The RS.HTM file implements functions that marshal the remote method name and parameters into a buffer to be sent 'over the net.'
• RS.ASP implements functions that unmarshall such data from the receiving buffer. In a complementary way the returned value is marshalled by RS.ASP function and unmarshalled by RS.HTM functions.

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.

Using VBScript for Remote Scripting

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:

• Install the remote scripting files
• Enable the remote scripting engine on the server side
• Enable the remote scripting engine on the client side
• Call a remote method from a client page using VBScript
• Fetch the data returned from the remote method call
• Transform an asp page into a VBScript remote object

To be able to use remote scripting, the remote script files need to be installed on the server.

Installing Remote Script 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.

Tip  

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:	c:inetpub wwwroot
The three remote scripting files ( rs.htm , rsreak .asp , rsproxy.class ) should be locatedreak in the directory:	c:inetpubwwwroot_ScriptLibrary
Any file in your project using remote scripting should be located in a directory like:	c:inetpubwwwrootYourScriptProject

Enabling Remote Scripting on the Server

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:

1. To invoke the function RSDispatch once in the lifetime of the ASP page to initialize the remote scripting engine
2. To include the file RS.ASP that contains the implementation of the RSDispatch function.

Enabling Remote Scripting on the Client Side

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.

...

...

This is the only place where we will use JavaScript in this chapter. It is necessary because the file RS.HTM is a file of JavaScript functions despite its .HTM extension. Furthermore, RSEnableRemoteScripting is an initializing function contained in that file.

Invoking a Remote Method

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:

• d:inetpub wwwroot s16 sclient01.htm
• d:inetpubwwwroot s16hello.asp

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




%>

A little bit of JavaScript code is used to build this sample and make it as simple as possible, for now. But we'll get rid of this need for JavaScript after introducing VBScript classes. JavaScript is needed to expose the HRW method as a remote function.

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.

We are now going to introduce a technique to get rid of the JavaScript public_description object using VBScript classes (after all, who wants JavaScript in a VBScript book!).

Transforming an ASP Page into a VBScript Object

In the previous code sample a little JavaScript was required. So, let's get rid of the JavaScript, introduce a fully VBScript sample, and then discuss the importance and benefits of this approach. We'll call the sample ' Hello (VBScript Remote) World! '

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.

• d:inetpubwwwroot s16 sclient02.htm
• d:inetpubwwwroot s16vbhello.asp

While the remote scripting library ( RS.HTM , RS.ASP , and RSPROXY.CLASS ) is still located in d:inetpubwwwroot s\_ScriptLibrary

Here's the server page, so you can immediately appreciate that there is no more JavaScript. The following is the VBHELLO.ASP code.

<%@ 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.

aspObj.aRemoteMethod

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!

Summary

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:

• Install the remote scripting files
• Enable the remote scripting engine on the server side
• Enable the remote scripting engine on the client side
• Call a remote method from a client page using VBScript
• Fetch the data returned from the remote method call
• Transform an asp page into a VBScript remote object

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.