The server side of the remote scripting is a little less cryptic. And, once you have successfully put the pieces together, incredibly repeatable. Below is a sample ASP page that would be called from the ExecuteRS function described in the previous section.

<% RSDispatch %>

<!--#INCLUDE FILE="_ScriptLibrary/rs.asp"-->
<SCRIPT RUNAT=SERVER LANGUAGE="JavaScript">

function MyServerMethods()
{
    this.TestRS = Function( 'parameter','return TestRS(parameter)' );
}

public_description = new MyServerMethods();
</SCRIPT>

<SCRIPT RUNAT=SERVER LANGUAGE="VBScript">

'-----
Function TestRS(sParm)
     TestRS = "Here I am - " & sParm
End Function

</SCRIPT>

The important elements of this sample are that the RSDispatch call and the #INCLUDE statement. The RSDispatch function (it is implemented in the rs.asp code) must be made as the first VBScript statement. Also, make sure that the #INCLUDE uses FILE, not VIRTUAL and that the statement itself is not imbedded in another <SCRIPT> block. This is a significant change from Windows NT where neither of these restrictions caused remote scripting to fail. In Windows 2000, they do.

The functions that are available to be called from the client side are listed in the MyServerMethods function. The first parameter(s) to the Function call represent the number of parameters that are being called from the client side. The last parameter is, in essence, the VBScript command that will be executed in order to generate the return value. For example, if the incoming call had three parameters, the Function call would look like
Function('parm1', 'parm2', 'parm3', 'return CallName(parm1, parm2, parm3)')

Also, the name of the parameters that you provide in the Function call are matched up to the parameter list that are in the call prototype (the last parameter). Once you have the structure in place, the code that gets executed in the function is standard VBScript. You have just as much flexibility as you would in a normal ASP page. And whatever value is assigned to the function will be sent back to the calling page in the return_value property of the 'co' object.

One of the trickier aspects to using remote scripting is debugging. If something goes wrong between the client and server side, it is difficult to trace the ultimate source of the problem. What I have taken to doing is to start by making sure that the connection works from the client side. Using the sample server-side code that I have provided, you should be able to implement a bare bones remote scripting function. That will let you determine whether a connection is being made to the server and a response received correctly. If there is a problem with this process, it is usually a type in the URL (it should include the http:// header) or a syntax error in the server-side ASP. Once that basic functionality has been confirmed, you can use the IIS log file to help with any errors that are generated on the server side. In my experience, any run-time error message can be found in place of the URL that is being called.