Glengamoi (Forum) · AspHeute · .NET Heute (RSS-Suche) · AspxFiles (Wiki) · .NET Blogs

RemoteScripting - Einführung, Tips und Tricks

Geschrieben von: Rene Drescher-Hackel
Kategorie: ASP Tricks

This printed page brought to you by AlphaSierraPapa

Mit der RemoteScripting (RS) - Technologie hat Microsoft dem ASP-Programmierer wieder eine Möglichkeit an die Hand gegeben, seine Webseiten aus der Sicht des Clients attraktiver zu gestalten. Um durch vom Client ausgelöste Aktionen auszuwerten, muß die entsprechende ASP-Seite nicht neu geladen werden.

Schön, dachte ich, als ich das gelesen hatte. Doch war meine erste Freude auf RemoteScripting genauso schnell wieder verflogen, als ich dann lesen konnte, daß doch irgendwie alles auf Jscript/JavaScript aufgesetzt war. Ich hatte aber keine Ambitionen meine ganzen ASP-Dateien - die durchweg ja in VBScript erstellt wurden - umzuschreiben, um dann letztlich die Vorzüge des RS nutzen zu können. Also machte ich mich daran, in die "Tiefen" des RS abzutauchen, um noch mehr über diese Technologie zu erfahren.

Einen guten Überblick über die dahinter stehende Technologie gibt der Artikel von Christian Strauch. Der heutige Artikel soll einen Überblick über die einzelnen Methoden des RemoteScripting geben, und wie diese zum Einsatz kommen (können). Weiterhin soll dieser Artikel deutlich machen, was bei der ScriptLibrary zu beachten ist. Die Beispiele sind dabei bewußt kurz gehalten. Sie dienen lediglich dazu zu zeigen, daß RS (RemoteScripting) funktioniert und insbesondere die "Serverfunktionen" korrekt angesprochen und abgearbeitet wurden. Des weiteren soll verdeutlicht werden, daß RS auch funktionieren kann, ohne alle bestehenden ASP-Seiten von VBScript nach Jscript/JavaScript zu konvertieren.

Übersicht der einzelnen RS-Methoden

Insgesamt stehen im RS vier Methoden zur Verfügung:

RSExecute()
RSGetASPObject()
RSEnableRemoteScripting()
RSDispatch()

Im nachfolgenden Abschnitt wollen wir uns die Methoden einmal näher betrachten.

1. Die RSExecute - Methode

Diese Methode kann man gewissermaßen als "ausführendes Bindeglied" verstehen, gleichwohl für die eigentliche Verbindung das über die RSEnableRemoteScripting()-Methode initialisierte Java-Applet in erster Linie "verantwortlich" ist. Anders ausgedrückt sorgt die Methode RSExecute() für die Ausführung unserer Serverfunktionen, die wir in einer separaten ASP-Seite definiert haben.

Die allgemeine Syntax zu dieser Methode lautet:

RSExecute(url, methode, [parameter 1,...,parameter n][,auswertung][,fehlerauswertung][,context])

Die Parameter sind wie folgt zu übergeben:

url - Hier wird die ASP-Seite angegeben, die die jeweiligen Prozeduren beinhaltet, welche durch den Aufruf ausgewertet werden sollen.

methode - Bezeichnet die Prozedur innerhalb der in url bezeichneten ASP-Seite, die mit dem RS-Aufruf ausgeführt werden soll.

parameter 1,...parameter n - Bezeichnen die einzelnen an die methode zu übergebenden Parameter, wenn diese mit entsprechenden Parametern aufzurufen ist. Die Angabe von Parametern ist daher optional und hängt im wesentlichen von der definierten Prozedur in unserer ASP-Seite (siehe oben url) ab.

auswertung - Bezeichnet die clientseitige (meist JavaScript) Funktion, die das Ergebnis des RS-Aufrufs ausgibt. Die Angabe ist optional und erfolgt, wenn die methode asynchron aufgerufen wird. Wird keine Angabe für auswertung gemacht, wird die methode synchron aufgerufen.

fehlerauswertung - Bezeichnet ebenfalls einen optionalen Parameter, der in Form einer JavaScript-Funktion aufgerufen wird, wenn der Aufruf der methode nicht vollständig war bzw. einen Fehler zurückgegeben hat.

context - ist ebenfalls ein optional anzugebender Wert. In der Regel wird hier dann die aufgerufene methode noch einmal benannt.

An einem kleinen Beispiel möchte ich nun verdeutlichen, wie die Methode RSExecute funktioniert.

Hierbei habe ich in der Datei remotecalljs.asp eine Function definiert, die lediglich eine Meldung zurückgibt. Auf den genauen Aufbau der remotecalljs.asp will ich weiter unten detaillierter eingehen.

Public Function VBGetMessage()
    VBGetMessage = "Diese Function wurde Remote aufgerufen."
End Function

Mit der Methode RSExecute wird die oben dargestellte Function in der remotecalljs.asp wie folgt dann aufgerufen: Für unser Beispiel habe ich dazu die remotecalljs.htm erstellt, in der der folgende JavaScript-Block eingefügt wird:

<SCRIPT LANGUAGE=javascript  event=onclick for=button1>
    var url = "remotecalljs.asp";
    var methode = "VBGetMessage";
    var co = RSExecute(url,methode);
    ... 
</SCRIPT>

Hierbei habe ich auf das onclick-event der Schaltfläche button1 eine JavaScript-Aktion ausführen lassen. Der Übersicht halber wird dann als erstes der Variablen url der Wert zugewiesen - im vorliegenden Beispiel der Name der ASP-Seite, die die aufzurufende Prozedur enthält, also remotecalljs.asp. Dann muß noch angegeben werden, welche Prozedur aus der remotecalljs.asp aufzurufen ist. Hier ist es die Funktion VBGetMessage. In unserem Beispiel wird die VBGetMessage Funktion synchron aufgerufen, sodaß die Angabe der oben beschriebenen optionalen Parameter entfallenkann.

Den Rückgabewert des Aufrufes der RSExecute-Methode weisen wir hier der Variablen co zu, die das Rückgabewertobjekt (!) speichert. Um letztlich das Ergebnis des Funktionsaufrufes zu erhalten, wird von co die Eigenschaft return_value ausgelesen. Ich habe hierzu eine alert()-Anweisung gewählt, die in diesem Beispiel ausreichen soll, um den Rückgabewert sichtbar zu machen. Der oben beschriebene JavaScript-Block komplettiert sich dann mit folgendem Eintrag:

alert(co.return_value);

Nachdem die Schaltfläche Button angeklickt wurde, erhalten wir dann folgende Meldung angezeigt:

Der eher häufiger vorkommende Fall ist jedoch der, daß durch die remote aufgerufene Prozedur das Ergebnis einer Datenbankanfrage zurückgegeben wird. Dann ist es immer interessant, die Ergebnisse der Datenbankabfrage in die bisherige HTML-Anzeige unterzubringen.

Das folgende Beispiel demonstriert, wie man die Ergebnisse des Aufrufes der RSExecute-Methode an einzelne HTML-Elemente übergeben kann.

Statt der alert()-Anweisung wird also das Ergebnis dem Value eines HTML-Elementes zugeordnet:

document.form1.text1.value = co.return_value;

Soll das Rückgabeergebnis statt dessen das gesamte HTML-Erscheinungsbild ändern, so würde man das mit folgendem Code erreichen:

document.all.IDX.innerHTML = co.return_value;

IDX ist dabei die id des HTML-Tags, in dessen Bereich das Ergebnis auszugeben ist. In unserem Beispiel habe ich das mit einem span-Tag realisiert:

<span id=IDX></span>

Die in der Praxis in Bezug auf das hier gezeigte Beispiel am häufigsten vorkommenden Tags werden <DIV>, <SPAN> und <TD> sein. Mit all diesen läßt sich die oben beschriebene Vorgehensweise unproblematisch realisieren.

Die zweite Methode, die ebenso die Funktionen der ASP-Seite aufruft und auswertet ist die RSGetASPObject - Methode.

2. Die RSGetASPObject - Methode

Bevorzugt man den objektorientierten Ansatz, kann man mit dieser Methode arbeiten. Die allgemeine Syntax zu dieser Methode lautet:

ObjName = RSGetASPObject(url)

ObjName - Bezeichnet hier eine Objektvariable, die die in der url definierten Prozeduren verwenden können.

url - entspricht den Ausführungen zur RSExecute-Methode. Hier wird die ASP-Seite angegeben, die die einzelnen Prozeduren beinhaltet, welche entsprechend aufgerufen werden sollen.

Wie sieht das in unserem Beispiel aus? Die oben beschriebene Syntax in der remotecalljs.htm ändert sich dann wie folgt:

<SCRIPT LANGUAGE=javascript  event=onclick for=button1>
    var url = "remotecalljs.asp";
    var aspObj = RSGetASPObject(url);
    var cv = aspObj.VBGetMessage4(5,3).return_value;
    alert(cv);
</SCRIPT>

Hier wird wieder zuerst der Variable url der Name der ASP-Seite zugewiesen. Befindet sich die ASP-Seite in einem andern Ordner als die Client-Seite, so kann hier auch der entsprechende Path angegeben werden, z.B.:

var url = "../remotesites/remotecalljs.asp";

Als nächstes wird eine Objektreferenz auf die in url angegebene ASP-Seite erstellt.

Da die erstellte Objektreferenz mit den Prozeduren der in der durch url angegebenen ASP-Seite arbeiten kann, erfolgt jetzt der Aufruf mit der entsprechenden Funktion, wobei die an die Funktion zu übergebenden Parameter hierbei gleich mit übergeben werden.

Die Objektreferenz aspObj übernimmt hier die Eigenschaften der RSGetASPObject-Methode, sodaß die Zuweisung des Rückgabeergebnisses an die Variable cv durch Angabe der Eigenschaft return_value direkt erfolgen kann.

var cv = aspObj.VBGetMessage4(5,3).return_value;

Die Funktion in der remotecalljs.asp hierzu sieht folgendermaßen aus:

Public Function VBGetMessage4(ByVal aa, ByVal bb)
    VBGetMessage4 = cint(aa)/cint(bb)
End Function

Hierbei fällt insbesondere auf, daß die übergebenen Werte in Integer-Werte explizit umgewandelt werden. Dies ist insoweit auch erforderlich, da standardmäßig die Werte als String an die jeweilige Funktion übergeben werden.

Das Ergebnis der Berechnung wird dann wieder mit einer alert()-Anweisung angezeigt.

Damit beide hier besprochenen Methoden fehlerfrei arbeiten, ist es erforderlich, daß auf der Client-Site innerhalb eines JavaScript-Scriptblockes eine Referenz auf die Datei RS.HTM erstellt wird. Dieser Scriptblock wird in der <HEAD> Sektion der Client-Seite definiert: (remotecalljs.htm)

<HTML>
<HEAD>
<META NAME="GENERATOR" Content="Microsoft Visual Studio 6.0">
<TITLE>RemoteScripting 1.Variante</TITLE>
<SCRIPT LANGUAGE=javascript  src=_ScriptLibrary/RS.HTM></SCRIPT>
</HEAD>
<BODY>

In der <BODY> Sektion ist dann die JavaScript-Function RSEnableRemoteScripting() aufzurufen, da mit dieser Funktion das JAVA-APPLET initialisiert wird, das seinerseits eine Referenz auf die Rsproxy.class erstellt.

<SCRIPT LANGUAGE=javascript>
    RSEnableRemoteScripting("_ScriptLibrary");
</SCRIPT>

In einigen Publikationen ist zu lesen, daß die Funktion RSEnableRemoteScripting() unter Angabe des Verzeichnisses erfolgt, welches die Datei RsProxy.class enhält (der Verzeichnisname selbst ist frei wählbar, für diesen Artikel habe ich mich für "_ScriptLibrary" entschieden). Sofern sich die Rsproxy.class im selben Verzeichnis wie die RS.HTM befindet, so bleibt diese Angabe hier entbehrlich. Hierbei ist jedoch zu ergänzen, daß nach der Installation des Windows Scripting Host Version 5.5 die Angabe des Verzeichnisses zwingend erforderlich wurde, da andernfalls eine Fehlermeldung zurückgegeben wird.

Die serverseitige Bereitstellung von Remote Scripting

Wie schon oben angesprochen, benötigen wir eine Datei - eine ASP-Seite - die die Funktionalität hinsichtlich der Kommunikation mit dem Server beinhaltet.

Ich habe hier die Datei remotecalljs.asp (und remotecallvbs.asp) erstellt. Folgende Voraussetzungen müssen zwingend in der ASP-Seite erfüllt sein:

Einschließen und Initialisierung der Server Scripting Library (des Verzeichnisses, welches die Dateien RS.ASP, RS.HTM und Rsproxy.class enthält)
Erstellen der Funktionen und Unterroutinen, die clientseitig über die Methoden RSExecute() oder RSGetASPObject() aufgerufen werden sollen
Veröffentlichen der einzelnen Funktionen und Unterroutinen

In den folgenden Abschnitten werde ich nun auf diese Punkte genauer eingehen.

Einschließen und Initialisierung der Scripting Library

Als erstes wird eine serverseitiges INCLUDE-Anweisung mit einer Referenz auf die Datei RS.ASP erstellt.

<!--#INCLUDE FILE="_ScriptLibrary/RS.ASP"-->

Dabei ist es auch möglich die INCLUDE-Anweisung folgendermaßen zu definieren:

<!--#INCLUDE Virtual="/_ScriptLibrary/RS.ASP"-->

Dann muß jedoch - im Gegensatz zu der zuvor genannten Variante - der Ordner "_ScriptLibrary" sich im wwwroot-Verzeichnis befinden.

Mit der Positionierung der folgenden Anweisung - dem Aufruf der RSDispatch-Methode - scheinen die Meinungen auseinanderzugehen. In der Dokumentation von Microsoft ist zu lesen, daß die RSDispatch-Methode als erster Eintrag in der ASP-Seite vorzunehmen ist. Andererseits findet man aber auch Hinweise, wonach der Aufruf der RSDispatch-Methode und die INCLUDE-Anweisung am Ende der ASP-Seite zu erfolgen haben.

In unserem Beispiel bliebe es gleich, an welcher Stelle die Methode RSDispatch aufgerufen wurde. Alle Methoden wurden in jedem Fall ordnungsgemäß abgearbeitet. Ich habe mich hier für das Ende der Datei entschieden, was den Aufruf der RSDispatch() und den Anfang der Datei, was die INCLUDE-Anweisung betrifft.

<!--#INCLUDE FILE="_ScriptLibrary/RS.ASP"-->
...
<% RSDispatch %>

Hinsichtlich des Verzeichnisses "_ScriptLibrary" sollte folgendes beachtet werden: Die Beispiele dieses Artikels, wo die Dateinamen mit "remotecalljs" beginnen, dürften auf allen Rechnern ohne Probleme laufen. Die Dateien, die mit "remotecallvbs" beginnen, setzen die neueste Version der ScriptLibrary zwingend voraus. Das Verzeichnis "_ScriptLibrary" dieses Artikels entspricht der Version 1.0b - der zur Zeit neusten Version. Die Downloadadresse finden Sie weiter unten im Text.

Erstellen der Funktionen und Unterroutinen

Im nächsten Schritt werden dann die einzelnen Funktionen erstellt. Hierbei ist zu beachten, daß SUB-Prozeduren nicht direkt möglich sind, da sie keine Werte zurückgeben können, sondern nur bestimmte Anweisungen ausführen. Das heißt aber nicht, daß auf SUB-Prozeduren ganz verzichtet werden muß. Diese können jederzeit aus einer Function heraus aufgerufen werden. Weiterhin ist zu beachten, daß die definierten Funktionen Public sein müssen: Zwar sind alle Funktionen in VBScript Public, soweit nichts anderes angegeben wurde - aber der Übersicht wegen habe ich in den Beispielen Public mit angegeben.

In unserem Beispiel haben wir folgende Funktionen erstellt:

Public Function VBGetMessage()
    VBGetMessage = "Diese Function wurde Remote aufgerufen."
End Function

Public Function VBGetMessage2(ByVal aa, ByVal bb)
    VBGetMessage2 = cint(aa) * cint(bb)
End Function

Public Function VBGetMessage3(ByVal aa, ByVal bb)
    VBGetMessage3 = cint(aa)-cint(bb)
End Function

Public Function VBGetMessage4(ByVal aa, ByVal bb)
    VBGetMessage4 = cint(aa)/cint(bb)
End Function

Zu den Besonderheiten bei der Konvertierung der übergebenen Funktionsparameter habe ich oben im Text entsprechende Ausführungen gemacht. Die Parameter werden standardmäßig als String übergeben. Sollen mit den Werten Berechnungen durchgeführt werden, ist es besser, diese entsprechend voher zu konvertieren.

Veröffentlichen der einzelnen Funktionen und Unterroutinen

Zum Schluß müßen die Funktionen "öffentlich" bekannt gemacht werden, also für RemoteScripting aufrufbar. Hierzu gibt es zwei Möglichkeiten:

1. Jscript

Die Variante entspricht den ursprünglichen Intentionen des RS, was ja - wie eingangs schon erwähnt - ursprünglich auf JavaScript/Jscript ausgerichtet war.

Hier wird also eine Funktion definiert, die ihrerseit die Verbindung zu unserer Funktion, die wir in unserer ASP-Seite definiert haben, herstellt.

Der entsprechende Code sieht hierzu wie folgt aus (remotecalljs.asp):

<SCRIPT LANGUAGE=JScript RUNAT=Server>
var public_description = new RemoteMethods();

function RemoteMethods()
{
    this.VBGetMessage = Function("return VBGetMessage()");
    this.VBGetMessage2 = Function("aa","bb","return VBGetMessage2(aa,bb)");
    this.VBGetMessage3 = Function("ac","bc","return VBGetMessage3(ac,bc)");
    this.VBGetMessage4 = Function("aa","bb","return VBGetMessage4(aa,bb)");
}
</SCRIPT>

2. VBScript

Mit der Version 1.0b der ScriptLibrary, die unter der Adresse http://msdn.microsoft.com/scripting/remotescripting/rsdown.htm heruntergeladen werden kann, ist es möglich über die Class-Anweisung die erstellten Funktionen öffentlich bekannt zu machen. Hierbei wird eine Objektinstanz über die Variable public_description (der Name ist zwingend durch die RS.ASP vorgegeben!) auf die Klasse erzeugt.

Der sich daraus ergebene Code sieht dann wie folgt aus (remotecallvbs.asp):

Class RemoteMethods
    Public Function VBGetMessage()
        VBGetMessage = "Diese Function wurde Remote aufgerufen."
    End Function
    
    Public Function VBGetMessage2(ByVal aa, ByVal bb)
        VBGetMessage2 = cint(aa) * cint(bb)
    End Function
    
    Public Function VBGetMessage3(ByVal aa, ByVal bb)
        VBGetMessage3 = cint(aa)-cint(bb)
    End Function
    
    Public Function VBGetMessage4(ByVal aa, ByVal bb)
        VBGetMessage4 = cint(aa)/cint(bb)
    End Function
End Class
set public_description = new RemoteMethods

In Anbetracht dessen, daß hier die gewohnte VBScript-Umgebung erst gar nicht verlassen wird und - soweit nicht schon in der Praxis bisher umgesetzt - die bislang definierten Funktionen nur noch durch das Class-Objekt umschlossen werden brauchen, ist dieser Ansatz der durchaus elegantere.

Zusammenfassung

Mit Remote Scripting ist es möglich, den Ablauf des Webangebotes so zu gestalten, daß ASP Seiten nicht immer wieder neu geladen werden müssen. Gerade wenn man viele aufwendige Grafiken schon einmal geladen hat, genügt es doch auf die sich durch die Clientanfrage ergebenden Änderungen einzugehen und lediglich das daraus resultierende Ergebnis dem Client anzuzeigen.

Ein weiterer und sehr wesentlicher Punkt ist die Sicherheit der Webanwendungen. Sicherheitsrelevante Daten müssen nicht mehr sichtbar für den Client über den URL übertragen werden. Mit Remote Scripting können diese Informationen für den Client verdeckt an den Server übermittelt werden.

Ebenso wird mit dem Einsatz von Remote Scripting auf mehr Struktur in der ASP-Programmierung geachtet. Durch das Zusammenspiel mit Function- und Sub-Prozeduren ist der einzelne dazu angehalten, übersichtlicher zu programmieren. Der Nebeneffekt, der sich daraus ergibt, ist, daß ASP-Logik und Design noch stärker getrennt werden und die ASP-Logik zentral administrierbar bleibt.