DE10050401A1

DE10050401A1 - System zum Aufnehmen von sprachunabhängigem Scripting in Anwendungen objektorientierter Programmiersprachen und Applets (Bean Scripting Framework)

Info

Publication number: DE10050401A1
Application number: DE10050401A
Authority: DE
Inventors: Sanjiva Weerawarana; Matthew J Duftler
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1999-10-22
Filing date: 2000-10-12
Publication date: 2001-05-10
Also published as: US6779172B1

Abstract

Diese Erfindung stellt ein System und Verfahren bereit, das objektorientierten (OOP) Anwendungen das einfache und einheitliche Einbeziehen von Scripting gestattet. Das Bean Scripting Framework (BSF) unterstützt Scripting auf der Seite der OOP-Programmiersprache, wobei die Programmiersprache Scripts ausführt und bewertet, und ebenso Fälle, in denen Scripts Objekte ausführen und steuern. Der BSF-Manager stellt sowohl Scripting-Services für das Anwendungsprogramm als auch Unterstützungs-Services für Scripting-Engines zur Interaktion mit der Laufzeitumgebung der OOP-Programmiersprache bereit. Das BSF hat auch ein Register bekannter Scriptingsprachen, mit denen das Anwendungsprogramm interagieren kann. Die Scripting-Architektur gestattet es, Anwendung von OOP-Programmiersprachen weitergehend als vorher möglich anzupassen und zu verwalten.

Description

Anwendungsgebiet der Erfindung

Die vorliegende Erfindung bezieht sich allgemein auf computerunterstützte Programmentwicklungstechnik (Computer Aided Software Engineering, CASE) und insbesondere auf ein Verfahren des Einbeziehens von Scripting in Anwendungen der objektorientierten Programmierung (object oriented programming, OOP) und kleine Programme, die Applets genannt werden.

Beschreibung der Vorgeschichte

OOP ist die bevorzugte Umgebung zur Entwicklung benutzerfreundlicher intelligenter Computersoftware.

Schlüsselelemente der OOP sind Datenkapselung, Vererbung und Polymorphie. Diese Elemente können zum Erzeugen einer grafischen Benutzerschnittstelle (graphical user interface, GUI) verwendet werden, die typischerweise durch eine Umgebung mit Fenstertechnik mit Symbolen, Mauscursor und Menüs gekennzeichnet ist. Obwohl diese drei Schlüsselelemente für OOP-Sprachen üblich sind, führen die meisten OOP-Sprachen die drei Schlüsselelemente unterschiedlich aus.

Beispiele für OOP-Sprachen sind SmallTalk, Object Pascal, C++ und Java. SmallTalk ist eigentlich mehr als eine Sprache; es könnte genauer als eine Programmierumgebung gekennzeichnet werden. SmallTalk wurde in der Learning Research Group des Xerox's Palo Alto Research Center (PARC) in den frühen 70er Jahren entwickelt. In SmallTalk wird eine Nachricht an ein Objekt geschickt, um das Objekt selbst auszuwerten. Nachrichten führen eine Aufgabe ähnlich der von Funktionsaufrufen in herkömmlichen Programmiersprachen aus. Der Programmierer braucht sich nicht mit dem Datentyp zu beschäftigen; stattdessen muss er sich nur mit dem Erzeugen der richtigen Reihenfolge einer Nachricht und der Verwendung der richtigen Nachricht beschäftigen. Object Pascal ist die für Apple Macintosh® Computer verwendete Sprache. Apple entwickelte Object Pascal in Zusammenarbeit mit Niklaus Wirth, dem Entwickler von Pascal. C++ wurde 1983 von Bjarne Stroustrup bei AT Bell Laboratories als eine Erweiterung von C entwickelt. Java, das nach dem Vorbild von C++ gestaltet wurde, wurde ursprünglich 1991 als eine Sprache für eingebettete Anwendungen entwickelt, wie z. B. in Set-top Boxen und anderen verbraucherorientierten Geräten. 1994 übertrug Sun Corp. Java in das World Wide Web (WWW). Das Schlüsselkonzept von Java und C++ ist die Klasse, die ein benutzerdefinierter Typ ist. Klassen ermöglichen objektorientierte Programmiermerkmale. C++-Module sind mit C-Modulen kompatibel und können frei verknüpft werden, so dass bestehende C- Bibliotheken mit C++-Programmen verwendet werden können. Die am weitesten verbreiteten objektbasierten und objektorientierten Programmiersprachen sind auf Simula zurückzuführen, das in den 60er Jahren von O.-J. Dahl, B. Myhrhaug und K. Nygard von Norwegen entwickelt wurde. Für weitere Informationen zum Thema OOP sei auf Object Oriented Design with Applications von Grady Booch, The Benjamin/Cummings Publishing Co., Inc., Redwood City, Calif. (1991) verwiesen.

Scripting ist ein Verfahren, ein Computer-"Programm" zu schreiben, das einfach ist und wirklich keine Programmierkenntnisse erfordert. Ein Script ist ein Programmtyp, der aus einer Gruppe von Instruktionen für ein Anwendungs- oder Dienstprogramm besteht. Ein Script besteht normalerweise aus Instruktionen, die unter Verwendung der Regeln und Syntax der Anwendung in Kombination mit einfachen Steuerstrukturen wie Schleifen und Wenn/dann-Ausdrücken ausgedrückt werden. Eine Scripting-Sprache ist eine Programmiersprache im Scripting-Stil, die in Java oder Nicht- Java ausgeführt ist. Scripting-Sprachen wie Netscape Rhino (JavaScript), VBScript, Perl, Tcl, Python, NetRexx und Rexx werden im Allgemeinen verwendet, um die Funktion einer Anwendung zu erweitern oder eine Gruppe von Anwendungskomponenten zusammenzuschreiben, um eine Anwendung zu bilden. Schnelle Entwicklung ist ein Grund, eine Scripting- Sprache zu verwenden.

Die Java-Plattform hat gegenwärtig keine klar definierte Scripting-Architektur, die Java-Anwendungen gestattet, Scripting einfach und einheitlich einzubeziehen. Die Verwendung von Scripting wird noch wichtiger werden, da Scripting schnell der nächste Software-Entwicklungsschritt wird. Eine Standard-Scripting-Architektur bietet viele Vorteile. Erstens gestatten das Einführen und Ermöglichen einer Scripting-Architektur statt eines speziellen Ansatzes zur Script-Integration Anwendungen, schnell und einfach viele Scripting-Sprachen zu unterstützen. Scriptermöglichende Produkte gestatten das Schreiben von Erweiterungen durch ein breiteres Publikum einschließlich Nichtprogrammierern. Zweitens ermöglicht eine einzige Scripting-Architektur für die Plattform Entwicklern von Scripting-Sprachen, sich einmal über die Architektur zu einigen und sie universell für alle Anwendungen bereitzustellen. Schließlich können gemeinsame Dienstleistungen, wie z. B. Fehlersuchdienste, entwickelt werden, die alle Scripting-Sprachen unterstützen.

Zusammenfassung der Erfindung

Es ist daher eine Aufgabe der vorliegenden Erfindung, ein Verfahren und System zum Einbeziehen von Scripting in Java- Anwendungen und Applets bereitzustellen.

Es ist noch eine andere Aufgabe der vorliegenden Erfindung, ein Verfahren und System bereitzustellen, die das Modifizieren oder Erweitern der Funktionalität einer Anwendung gestatten.

Das Bean Scripting Framework (BSF) ist eine Architektur zum Einbeziehen von Scripting in Java-Anwendungen und Applets. Das BSF liefert eine Gruppe von Schnittstellen, die Entwickler ihren Anwendungen sprachunabhängiges Scripting hinzufügen lassen. Die Erfindung bezieht Scripting in Java-Anwendungen durch Verwenden von zwei Hauptkomponenten, dem BSF-Manager und Scripting-Engines, ein.

Der BSF-Manager lässt Endbenutzer Scripts in den Scripting- Sprachen schreiben, die ihnen am besten gefallen, ohne die Anwendung mit sprachspezifischem Wissen zu belasten. Der BSF- Manager unterstützt beide Richtungen des Scripting. Das heißt, wenn die Java-Seite verantwortlich ist und nach Wunsch Scripts ausführt und bewertet, sowie in Fällen, bei denen das Script Java-Beans ausführt und steuert.

Eine Scripting-Engine ist eine Scripting-Sprache, die in das BSF aufgenommen wurde. Die Scripting-Engines behandeln deshalb alle sprachabhängigen Angelegenheiten. Eine Scripting-Engine muss für jede Scripting-Sprache geschrieben werden, die der BSF-Manager unterstützt, obwohl sie für den Scripting-Host alle gleich aussehen. So können Scripting-Engines für JavaScript, NetRexx, Jacl, JPython, VBScript, JScript, LotusXSL, LotusScript und andere Sprachen geliefert werden.

Das BSF arbeitet mit allen Java-Objekten und nicht nur einer echten Bean. Scriptermöglichende Java-Anwendungen ermöglichen das Anpassen und Verwalten dieser Anwendungen weitergehend als vorher möglich. Das heißt, sobald zur Zeit eine Java-Anwendung erstellt und an einen Endbenutzer oder ein ISV geliefert wurde, können sie die Funktionalität der Anwendung nicht einfach modifizieren oder ergänzen. Einige Anwendungen gestatten dies durch genaue Erweiterungs- Anwendungsprogrammierschnittstellen (Application Proramming Interfaces, APIs) die ISVs verwenden können. Jedoch müssen ISVs in diesem Fall auch Java benutzen, um die Anwendungen anzupassen. Falls die Anwendung BSF verwendet, kann sie die geeignete Funktionalität zur Erweiterbarkeit über BSF darstellen. ISVs und andere können dann die Anwendung unter Verwendung irgendeiner BSF-unterstützten Scripting-Sprache konfigurieren und modifizieren. Mit diesem Ansatz gibt es zwei bedeutende Vorteile. Erstens kann die Anpassung der Anwendung mit der Kundensprache nach Wahl erfolgen (vorausgesetzt, sie wird durch BSF unterstützt). Zweitens braucht die Anwendung keine zusätzliche Arbeit zum Unterstützen aller BSF- aktivierter Sprachen aufzuwenden. Das heißt, die Anwendung wird von allen BSF-Sprachen ohne irgendeine Anwendungsbelastung scriptfähig.

Kurze Beschreibung der Zeichnungen

Die obengenannten und anderen Merkmale, Aspekte und Vorteile werden besser aus der folgenden ausführlichen Beschreibung einer bevorzugten Ausführungsform der Erfindung mit Bezug auf die Zeichnungen verstanden, in denen:

Fig. 1 ein Blockdiagramm ist, das die wesentlichen Komponenten der bevorzugten Ausführungsform der vorliegenden Erfindung darstellt, wenn die Scripting-Engine in Java ausgeführt ist;

Fig. 2 ein Blockdiagramm ist, das die Interaktion zwischen der Ausführung der BSF-Engine-Schnittstelle und einer Scripting-Engine darstellt, wenn die Scripting-Sprache nicht in Java ausgeführt ist;

Fig. 3 ein logisches Flussdiagramm ist, das den Prozess des Einbeziehens einer neuen Scripting-Sprache in BSF darstellt;

Fig. 4 ein logisches Flussdiagramm ist, das den Prozess darstellt, wie Anwendungskomponenten für Scripting durch BSF- unterstützte Sprachen verfügbar gemacht werden;

Fig. 5 ein logisches Flussdiagramm ist, das den Prozess des Ladens einer Scripting-Sprache in das BSF darstellt;

Fig. 6 ein logisches Flussdiagramm ist, das den Prozess des Ausführens von Scripts von einer Anwendung durch Laden spezieller Engines darstellt;

Fig. 7 ein logisches Flussdiagramm ist, das den Prozess des Ausführens von Scripts von einer Anwendung über den BSF- Manager darstellt;

Fig. 8 ein logisches Flussdiagramm ist, das den Prozess der Interaktion mit Java von Scripts für javabasierte Scripting- Engines darstellt; und

Fig. 9 ein logisches Flussdiagramm ist, das den Prozess der Interaktion mit Java von Scripts für nichtjavabasierte Scripting-Engines darstellt.

Ausführliche Beschreibung einer bevorzugten Ausführungsform der Erfindung

Die ausführliche Beschreibung wird hinsichtlich einer Ausführung in der Programmiersprache Java gegeben. Jedoch kann die Erfindung auch unter Verwendung anderer geeigneter Programmiersprachen umgesetzt werden.

Fig. 1 ist ein Blockdiagramm, das die Hauptkomponenten der bevorzugten Ausführungsform der vorliegenden Erfindung darstellt, wenn die Scripting-Engine in Java ausgeführt ist. Wie in Fig. 1 gezeigt, finden sich alle Objekte der Anwendung innerhalb einer virtuellen Java-Maschine (Java Virtual Machine, JVM) 100 in diesem Fall. Wie für den Fachmann ersichtlich, ist eine JVM ein Java-Interpreter, der die Java- Zwischensprache (Bytecode) zeilenweise in Maschinensprache umwandelt und sie dann ausführt. Der BSF-Manager 102 ist ein Objekt, das Scripting-Dienste für die Anwendung 101 sowie Unterstützungsdienste für die Scripting-Engines 103 bereitstellt, die alle sprachabhängigen Angelegenheiten behandeln, um mit Anwendungsobjekten (107, 108, 109, 110, 111) und der Java-Laufzeitumgebung zu interagieren. Der BSF-Manager 102 hat ein Scripting-Engine-Register 105 der Scripting- Engines 103, welche die Anwendung 101 laden und mit denen sie interagieren kann. Zu Scripting-Engines 103 können zum Beispiel JavaScript, Perl und andere gehören. Der BSF-Manager 102 hat auch ein Objektregister von Anwendungsobjekten (107, 108, 110, 111), welche die Anwendung 101 ausgewählt hat, um sie für Scripting zur Verfügung zu stellen.

Scripting-Engines 103 müssen die BSF-Engine-Schnittstelle 104 implementieren, um Teil der BSF-Architektur zu werden. Die BSF-Engine-Schnittstelle 104 ist die Abstraktion, welche die BSF-Architektur verwendet, um mit den Scripting-Engines 103, 200 zu interagieren. Die Interaktion zwischen der Scripting- Engine und dem BSF-Manager 102 besteht aus Aufrufen vom BSF- Manager 102 zur BSF-Engine-Schnittstelle 104 zum Bewerten und Ausführen von Scripts und Aufrufen von der BSF-Engine- Schnittstelle 104 zum BSF-Manager 102 zum Überwachen, Registrieren und Zurücknehmen der Registrierung von Anwendungsobjekten. Falls die Scripting-Engine 200 selbst nicht in Java ausgeführt ist, interagiert die Ausführung der BSF-Engine-Schnittstelle 104 mit den Scripting-Engines 200 unter Verwendung der Java-Basisschnittstelle (Java Native Interface, JNI). Dieser Fall wird in Fig. 2 gezeigt.

Die Anwendung 101, die aus der Sammlung von Objekten (107, 108, 109, 110, 111) besteht, interagiert mit dem BSF-Manager 102 oder direkt mit den BSF-Engine-Objekten.

Fig. 2 ist ein Blockdiagramm, das die Hauptkomponenten der bevorzugten Ausführungsform der vorliegenden Erfindung zeigt, wenn die Scripting-Engine nicht in Java ausgeführt ist. Fig. 2 ist fast dieselbe wie Fig. 1, außer dass die Scripting- Engines 200 außerhalb der JVM 100 laufen.

Fig. 3 ist ein Blockdiagramm, das den Prozess des Einbeziehens einer neuen Scripting-Sprache in das BSF darstellt. Der erste Schritt ist, die BSF-Engine-Schnittstelle 104, wie in Block 301 gezeigt, auszuführen. Insbesondere ermöglicht die BSF-Engine-Schnittstelle 104 jeder Scripting- Engine 103, 200 mit dem BSF-Manager 102 und der Anwendung 101 zu interagieren. In Schritt 302 muss die BSF-Engine- Schnittstelle 104 in die Sprache Funktionalität einbinden, um mit Java interagieren zu können, hauptsächlich, um dem Script- Autor zu gestatten, auf das Objektregister 106 zuzugreifen und dann Operationen an Objekten (107, 108, 109, 110, 111) auszuführen, auf die über das Objektregister 106 zugegriffen wird. In Schritt 303 muss die Ausführung der BSF-Engine 104 im Scripting-Engine-Register 105 des BSF-Managers 102 registriert werden, wodurch der Prozess des Integrierens einer neuen Engine ins BSF abgeschlossen wird.

Fig. 4 ist ein Blockdiagramm, das den Prozess zeigt, Anwendungsobjekte (oder Komponenten) 107, 108, 109, 110, 111 für Scripting bereitzustellen. Wie in Block 401 gezeigt, ist der erste Schritt das Kennzeichnen von Anwendungskomponenten (Beans), die für Scripting bereitgestellt werden sollen. Die Komponenten werden typischerweise manuell gekennzeichnet, indem entschieden wird, welche Funktionalität der Anwendung für Scripting bereitgestellt werden soll. Dieser Prozess ist ähnlich dem Entwerfen der externen Anwendungsprogrammier schnittstellen (application programming interfaces, APIs) einer Anwendung. In Entscheidungsblock 402 erfolgt ein Test, um zu entscheiden, ob diese Bean in Scripting-Sprachen als eine vorausgeladene Bean zur Verfügung gestellt werden soll (d. h. eine, die der Benutzer nicht explizit laden muss) oder einfach als eine registrierte Bean. Falls die Bean noch nicht registriert ist, wird die Bean in Objektregister 106 registriert, wie in Block 403 gezeigt. Falls die Bean schon registriert ist, wird die Bean in den Vektor deklarierter Beans des BSF-Managers eingefügt, um an jede Scripting-Engine 103, 200 weitergeleitet zu werden, wenn sie geladen werden, wie in Block 404 gezeigt. In Schritt 405 endet der Prozess.

Fig. 5 ist ein Blockdiagramm, das den Prozess des Ladens einer Scripting-Sprache ins BSF darstellt. In Entscheidungsblock 501 erfolgt ein Test, um festzustellen, ob die Sprache schon in den Anforderer geladen wurde. Falls ja, wird diese Engine in Block 502 an den Anforderer zurückgegeben. Falls nicht, erfolgt in Entscheidungsblock 503 ein weiterer Test, um festzustellen, ob die Sprache im Scripting-Engine-Register 105 des BSF-Managers 102 registriert wurde. Falls nicht, wird in Block 508 ein Fehler zurückgegeben. Falls ja, wird in Schritt 504 die Scripting- Engine für diese Sprache geladen und nachfolgend in Block 505 initialisiert. Das Initialisieren einer Scripting-Engine besteht aus dem Informieren der Engine über alle deklarierten Anwendungsobjekte von Vektor 112. In Entscheidungsblock 506 erfolgt ein Test, um festzustellen, ob die Initialisierung erfolgreich war. Falls die Initialisierung nicht erfolgreich war, wird in 508 ein Fehler zurückgegeben. Falls ja, wird die Tatsache, dass die Engine geladen wurde, in das Scripting- Engine-Register 105 des BSF-Managers 102 in Block 507 aufgenommen. Dann wird in Block 502 diese Engine an das Anwendungsprogramm zurückgegeben.

Fig. 6 ist ein Blockdiagramm, das den Prozess des Ladens einer Scripting-Engine und des Ausführens eines Scripts von einer Anwendung darstellt. Zuerst wird in Block 601 eine Instanz eines BSF-Managers 102 erzeugt. In Block 602 werden alle Anwendungskomponenten (107, 108, 109, 110 und 111), die für Scripting bereitgestellt werden sollen, unter Verwendung des in Fig. 4 dargestellten Prozesses bereitgestellt. In Block 603 wird die gewünschte Scripting-Sprache unter Verwendung des in Fig. 5 gezeigten Prozesses in den BSF- Manager 120 geladen. In Block 604 werden die gewünschten Scripts unter Verwendung des passenden Verfahrens der BSF- Engine 104 ausgeführt. Schließlich wird in Block 605 das Ergebnis des Ausführens des Scripts, wenn vorhanden, an den Anforderer zurückgegeben.

Fig. 7 ist ein Blockdiagramm, das den Prozess des Ausführens von Scripts von einer Anwendung unter direkter Verwendung des BSF-Managers darstellt. Zuerst wird in Block 701 durch das Anwendungsprogramm eine Instanz eines BSF-Managers 102 erzeugt. In Block 702 werden alle Anwendungskomponenten (107, 108, 109, 110 und 111), die für Scripting bereitgestellt werden sollen, unter Verwendung des in Fig. 4 gezeigten Prozesses bereitgestellt. In Block 703 werden die gewünschten Scripts unter Verwendung des passenden Verfahrens des BSF- Managers 102 ausgeführt. In Entscheidungsblock 704 erfolgt ein Test, um festzustellen, ob die Scripting-Sprache angegeben wurde. Falls nicht, wird in 705 die Sprache festgestellt. Falls ja, bzw. nach Block 705, wird die Scripting-Engine 103, 200 in den BSF-Manager 102 geladen, wie in Block 706 gezeigt.

In Block 707 werden die gewünschten Scripts unter Verwendung des passenden Verfahrens der BSF-Engine-Schnittstelle 104 ausgeführt. Schließlich wird in Block 708, wenn vorhanden, das Ergebnis des Ausführens des Scripts zurückgegeben.

Fig. 8 ist ein Blockdiagramm, das den Prozess der Interaktion von Scripts für javabasierte Scripting-Engines mit Java darstellt. In Entscheidungsblock 801 erfolgt ein Test, um festzustellen, ob die Interaktion mit einem bestehenden Objekt (107, 108, 109, 110, 111) erfolgt. Falls ja, wird das Objekt im Objektregister 106 des BSF-Managers 102 nachgeschlagen, wie in Block 802 gezeigt. Falls nicht, wird in Block 803 ein neues Objekt erzeugt. Die geeignete Bean-Operation wird durch das Anwendungsprogramm in Block 804 ausgeführt, wobei die gültigen Operationen das Festlegen und Abrufen von Eigenschaften, Aufruf-Verfahren und Bindungsereignisse für Scripts sind. Das Ergebnis der Operation wird, falls vorhanden, in 805 zurückgegeben.

Fig. 9 ist ein Blockdiagramm, das den Prozess der Interaktion mit Java von Scripts für nichtjavabasierte Scripting-Engines darstellt. In Entscheidungsblock 901 erfolgt ein Test, um festzustellen, ob die Interaktion mit einem bestehenden Objekt (107, 108, 109, 110, 111) erfolgt. Falls ja, wird das Objekt im Objektregister 106 des BSF-Managers 102 nachgeschlagen, wie in Block 902 gezeigt, und an die Scripting-Engine 200 wird ein Verweis auf das Objekt zurückgegeben. Falls nicht, wird in Block 903 ein neues Objekt erzeugt und ein Verweis auf das neue Objekt an die Scripting-Engine 200 zurückgegeben. In einer bevorzugten Ausführungsform sind die Objekt-Verweise, die an Nicht-Java-Scripting-Engines 200 zurückgegeben werden, nichttransparente Kennzeichen, die einen gültigen Typ und Wert für die Scripting-Sprache haben und welche die Bean- Operationsfunktionen als Verweis auf tatsächliche Java-Objekte kennzeichnen können. Die geeignete Bean-Operation wird in Block 904 unter Verwendung des JNI ausgeführt, wobei die gültigen Operationen das Festlegen und Abrufen von Merkmalen, Aufruf-Verfahren und Bindungsereignisse für Scripts sind. Das Ergebnis der Operation wird, falls vorhanden, in einen Typ eingebettet, der für die Scripting-Engine 200 akzeptabel ist, wie in Block 905 gezeigt, und in Block 906 zurückgegeben.

Die folgenden Codebeispiele zeigen die Schritte, die beim Einbeziehen des BSF in eine Anwendung beteiligt sind:

1. import com.ibm.bsf.*;
2. class YourClass {
3. BSFManager mgr = new BSFManager();
4. . . .
5. }

Die Zeilen 1-5 oben deklarieren und erzeugen einen BSF- Manager.

1. Stringextensions-{"pos"}
2. mgr.registerScriptingEngine ("potatoscript",
3. edu.purdue.cs.bsf.Engines.potatoscript.
4. extensions);

Die Zeilen 6-9 oben registrieren irgendeine neue Scripting- Sprache.

1. mgr.registerBean("myFrame", myFrame);
2. mgr.registerBean("myOtherBean", myOtherBean);
3. mgr.declareBean("response",response,response.getCtass());

Die Zeilen 10-12 oben registrieren oder deklarieren alle Beans, die für Scripting-Engines mit geeigneten Namen zur Verfügung gestellt werden sollen. Zu beachten ist, dass jedes Java-Objekt (d. h. jede Bean) für Scripting zur Verfügung gestellt werden kann. Das Objekt muss nicht notwendigerweise irgendeine spezielle Schnittstelle implementieren.

1. BSFEngine rhinoEngine = mgr.loadScriptingEngine("javascript");

Zeile 13 kann zum Laden irgendeiner gewünschten Scripting- Engine verwendet werden.

1. object result = rhinoEngine.eval ("testString", 0, 0, "2 + 32");
2. result = rhinoEngine.call (null,"hello",null);
3. rhinoEngine.exec ("testString2", 0, 0, "hello()");

Die Zeilen 14-16 rufen Funktionen in dem Script auf oder bewerten beliebige Scripts bzw. führen sie aus.

1. object result - mgr.eval("javascript", "testString", 0, 0, "2 + 32");
2. mgr.exec("javascript", "testString", 0, 0, "hello()");

Die Zeilen 17-18 zeigen ein Beispiel, in dem der BSF-Manager irgendein Script direkt ausführen kann.

Obwohl die Erfindung in Hinsicht auf eine einzige bevorzugte Ausführungsform beschrieben wurde, wird der Fachmann erkennen, dass die Erfindung mit Modifikation innerhalb des Umfangs und Bereichs der anhängigen Ansprüche ausgeführt werden kann.

Claims

1. System zum Aufnehmen von sprachunabhängigem Scripting in Anwendungen objektorientierter Programmiersprachen und Applets, das Folgendes umfasst:
mindestens ein Anwendungsobjekt, das einem Anwendungsprogramm zugeordnet ist;
mindestens eine Scripting-Engine, wobei jede Scripting- Engine eine Scripting-Sprache in das System integriert;
Scripting-Engine-Verwaltungsmittel zum Registrieren des mindestens einen Anwendungsobjekts und zum Registrieren der mindestens einen Scripting-Engine; und
Schnittstellenmittel, das jeder der mindestens einen Scripting-Engine zum Implementieren einer Funktionalität in jeder der mindestens einen Scripting-Engine zugeordnet ist, welche die Interaktion jeder der Scripting-Engines mit der objektorientierten Programmiersprache ermöglicht.

2. System nach Anspruch 1, wobei das Schnittstellenmittel weiterhin einem Script gestattet, auf die registrierten Anwendungsobjekte zuzugreifen und dann Operationen an den Objekten auszuführen.

3. System nach Anspruch 1, wobei die Scripting-Engine in einer virtuellen Java-Maschine (Java Virtual Machine, JVM) implementiert ist.

4. System nach Anspruch 1, wobei die objektorientierte Programmiersprache Java ist.

5. System nach Anspruch 1, wobei die Scripting-Engine außerhalb einer JVM implementiert ist.

6. System nach Anspruch 5, wobei das Scripting-Engine-Mittel in einer Nicht-Java-Sprache implementiert ist und wobei das Mittel zum Verbinden mit dem Scripting-Engine-Mittel unter Verwendung einer Java-Basis-Schnittstelle (Java Native Interface, JNI) interagiert.

7. Verfahren zum Einbeziehen von sprachunabhängigem Scripting in Anwendungen objektorientierter Programmiersprachen und Applets, das die folgenden Schritte umfasst:
ein oder mehrere Anwendungsobjekte für Scripting zur Verfügung stellen;
eine oder mehrere Scripting-Sprachen in ein Scripting- Sprachen-Register laden; und
ein Script unter Verwendung einer im Scripting-Sprachen- Register registrierten Scripting-Sprache ausführen.

8. Verfahren nach Anspruch 7, wobei die Anwendungskomponenten für Scripting folgendermaßen zur Verfügung gestellt werden:
Kennzeichnen der Anwendungskomponenten, die für Scripting zur Verfügung gestellt werden sollen;
Registrieren der Anwendungskomponente, wenn sie nicht bereits registriert ist;
Weiterleiten der Anwendungskomponente an eine Scripting- Engine; und
Laden der Anwendungskomponente in die Scripting-Engine.

9. Verfahren nach Anspruch 7, wobei der Schritt des Ladens einer Scripting-Sprache in ein Scripting-Sprachen- Register die folgenden Schritte umfasst:
Feststellen, ob die Scripting-Sprache schon geladen ist, und Laden der Scripting-Sprache, wenn sie nicht geladen wurde, oder Zurücksenden der Scripting-Engine, wenn sie bereits geladen wurde;
Initialisieren der Scripting-Engine; und
Zurücksenden der Scripting-Engine.

10. Verfahren nach Anspruch 7, das weiterhin den Schritt des Feststellens umfasst, ob die Scripting-Sprache in einem Scripting-Engine-Register registriert wurde, und Laden der Scripting-Engine, falls sie registriert ist, und Zurücksenden eines Fehlers, wenn die Scripting-Engine nicht registriert ist.

11. Verfahren nach Anspruch 7, wobei das Script direkt von der Scripting-Engine ausgeführt wird.

12. Verfahren nach Anspruch 7, wobei das Script gemäß folgender Schritte ausgeführt wird:
Laden einer gewünschten Scriptsprache in eine Bean- Script-Framework-Engine (BSF-Engine), die ein Script- Register und ein Register von Anwendungsobjekten umfasst;
Ausführen eines gewünschten Scripts durch Nutzen eines passenden Verfahrens der BSF-Engine; und
Zurückgeben des Ergebnisses des ausgeführten Scripts.

13. Verfahren nach Anspruch 7, das weiterhin die folgenden Schritte umfasst:
Feststellen, ob ein Anwendungsobjekt schon vorhanden ist und falls ja, Nachschlagen des bestehenden Objekts in einem Objektregister oder anderenfalls Erzeugen eines neuen Objekts;
Ausführen einer Bean-Operation an dem Objekt; und
Zurücksenden eines Ergebnisses der Operation.

14. Verfahren nach Anspruch 13, wobei die Operationen mindestens eine der folgenden Operationen umfassen:
Festlegen und Abrufen von Eigenschaften, Aufrufen von Methoden und Zuordnen von Ereignissen zu Scripts.

15. Verfahren nach Anspruch 7, das weiterhin die folgenden Schritte umfasst:
Feststellen, ob ein Anwendungsobjekt bereits vorhanden ist und falls ja, Nachschlagen des bestehenden Objekts in einem Objektregister und Zurückgeben eines Objekts an die Scripting-Engine oder anderenfalls Erzeugen eines neuen Objekts und Zurückgeben eines Objekts an die Scripting- Engine;
Ausführen einer Bean-Operation an dem Objekt unter Verwendung der Java-Basisschnittstelle oder eines Äquivalents; und
Zurücksenden eines Ergebnisses der Operation.

16. Verfahren nach Anspruch 15, wobei die Objekt-Verweise nichttransparente Kennzeichen zurücksandten, die einen für die Scripting-Sprache gültigen Typ und Wert haben, und deren Bean-Operationsfunktionen als Verweise zu tatsächlichen Java-Objekten gekennzeichnet werden können.

17. Verfahren nach Anspruch 15, wobei die Operationen Festlegen und Abrufen von Eigenschaften, Aufrufen von Methoden und Zuordnen von Ereignissen zu Scripts umfassen.

18. Verfahren nach Anspruch 15, wobei das zurückgesendete Ergebnis in einen Typ eingebettet ist, der für die Scripting-Engine akzeptabel ist.