-
HINTERGRUND DER ERFINDUNG
-
1. Gebiet der Erfindung
-
Die
Erfindung bezieht sich allgemein auf Computersysteme. Genauer werden
Verfahren und Vorrichtung zum Bereitstellen nach Bedarf von Netzanwendungsdownload
und Ausführungsfähigkeiten in
einem verteilten Computernetz offenbart.
-
2. Beschreibung des Standes
der Technik
-
Allgemein
gesagt ist ein Browser ein Anwendungsprogramm, das einen Weg bereitstellt,
um die gesamte Information in den verteilten Computernetzen, wie
etwa dem Internet, zu betrachten und mit ihr zu interagieren. Insbesondere
ist ein Webbrowser ein Clientprogramm, das das Hypertext-Transferprotokoll
(HTTP) verwendet, um Anforderungen zu Webservern überall in
dem Internet im Namen des Browserbenutzers durchzuführen. JavaTM, eine Programmiersprache, die durch Sun
Microsystems Inc. of Mountain View CA entwickelt wird, ist ausdrücklich zur
Verwendung in der verteilten Umgebung des Internet gestaltet. Sie
wurde gestaltet, das "Aussehen und
Gefühl" der Sprache C++
zu haben, ist aber einfacher als C++ zu verwenden und erzwingt eine
vollständig
objektorientierte Sicht der Programmierung. Auf diese Weise wird
Java verwendet, um vollständige
Anwendungen zu erstellen, die auf einem einzelnen Computer laufen
können
oder unter Servern und Clients in einem Netz verteilt werden.
-
Einer
der vielen Vorteile von Java besteht darin, dass es auch verwendet
werden kann, um kleine Anwendungsmodule, oder Applets (kleine Programme),
zur Verwendung als Teil einer Webseite aufzubauen. Ein Java-Applet
ist ein kleines Programm, das zusammen mit einer Webseite zu einem
Benutzer gesendet werden kann, das interaktive Animationen, unverzügliche Kalkulationen
oder andere einfache Aufgaben durchführen kann, ohne eine Benutzeranforderung
zurück
zu dem Server senden zu müssen. Als
ein Beispiel enthält,
wie in 1 gezeigt, ein verteiltes Computersysteme 100 einen
Clientcomputer 102, der mit einem Server-(Rost-)Computer 104 gekoppelt
ist. Der Computer 102 enthält eine Browseranwendung 106,
die wiederum eine angeforderte Webseite 108 mit einem darin
eingebetteten Applet 110 enthält, das zum Durchführen verschiedener Aufgaben
fähig ist.
In den meisten Situationen wird das Applet 110 durch eine
Java virtuelle Maschine (JVM) 112 ausgeführt, die
sich in diesem Beispiel auch in dem Browser 106 befindet.
-
Damit
die JVM 112 das Applet 110 ausführt, müssen die
erforderlichen Komponentendateien des Applet (wie etwa ".class files" ("Klassendateien"), Bilder und Töne), die
durch Dateien 114–118 dargestellt werden,
von dem Server 104 zu der JVM 112 heruntergeladen
werden. Typischerweise ist der Server 104 Teil eines verteilten
Netzes von Computern, wie etwa des Internet, oder könnte in
einigen Fällen
Teil einer Anordnung vom Intranettyp sein. In jedem Fall enthalten
die Dateien 114–118;
die für
die JVM 112 erforderlich sind, um das Applet 110 laufen
zu lassen, Java-Klassendateien ebenso wie Ressourcendateien, die
verwendet werden, um die Ausführung
des Applet 110 zu unterstützen. Derartige Klassendateien
enthalten eine Hauptklassendatei, main.class 114, die durch
die JVM 112 als ein Eintrittspunkt zur Ausführung des
Applet 110 verwendet wird. Der Server 104 speichert
auch andere Klassendateien, wie etwa b.class 116, die durch
die JVM 112 bei der För derung
der Ausführung
des Applet 110 verwendet werden. Verschiedene Bilder und
Klangkomponenten, die in der Ausführung des Applet 110 verwendet werden,
sind in Ressourcendateien gespeichert, wie etwa c.image 118.
-
Damit
die JVM 112 das Applet 110 ausführt, kann
es erforderlich sein, je nach Bedarf einige der Klassen- und Ressourcendateien
herunterzuladen. Dies wird typischerweise durch Senden einer Dateianforderung,
die die Form einer http-Anforderung annimmt, zu dem Server 104 bewerkstelligt,
der durch Bereitstellen einer http-Antwort, die den URL der angeforderten
Datei enthält,
antwortet. Auf dem Weg eines Beispiels erteilt die JVM 112 eine
Anforderung, die Hauptklassendatei main.class 114 abzurufen, worauf
der Server 104 durch Senden (d.h. Herunterladen) der angeforderten
Datei (d.h. main.class 114) antwortet. Diese Anforderungs-/Antwortprozedur folgt
für jede
Datei, für
die die JVM 112 fordert, das Applet 110 auszuführen.
-
Diese
Anordnung, obwohl ineffizient, ist zum Ausführen der meisten kleinen Applets
in kleinen lokalen Netzen ausreichend. Während sich jedoch die Komplexität des Applet
erhöht
(und dadurch sowohl die Größe als auch
die Zahl der angeforderten Dateien erhöht), verschlechtert sich das
Leistungsverhalten der JVM 112 beträchtlich, da die Zeit, die erforderlich
ist, um die zunehmend voluminösen
Anforderungen für
die zunehmend größeren Dateien
in einem zunehmend komplexeren Netz von Computern erforderlich ist, übermäßig wird.
-
Mit
der Einführung
dessen, was als eine Java-Archiv-(JAR) Datei genannt wird, verbessert
sich das Leistungsverhalten von Netz-Java-Anwendungen, wie etwa
Applets, etwas. Eine JAR-(Java-Archiv)
Datei hat ein plattformunabhängiges
Dateiformat, das viele Dateien in eine vereinigt. In jenen Anwendungen,
die JAR-Dateien verwenden, können viele
Java-Applets und ihre erforderlichen Komponenten (.class files,
Bilder und Töne
etc.) in einer JAR-Datei gebündelt
und anschließend
zu einem Browser in einer einzelnen HTTP-Transaktion heruntergeladen
werden, wobei dadurch die Downloadgeschwindigkeit stark verbessert
wird. Außerdem
unterstützt
das JAR-Format auch Komprimierung, was die Dateigröße reduziert,
wobei dadurch die Downloadzeit weiter verbessert wird. Mit Verweis
auf 2 sind die Applet-Komponentendateien 114–118 z.B.
in einer einzelnen JAR-Datei 120 gespeichert. Damit die
JVM 112 das Applet 110 ausführt, ist es bei Verwendung
dieser Anordnung nur erforderlich, dass eine einzelne HTTP-Dateianforderung 122 die
komprimierte JAR-Datei 120 herunterlädt, die alle Applet-Komponentendateien 114–118 enthält.
-
Wenn
ein Applet viele JAR-Dateien enthält, wird ein Klassen-Lader (class loader)
einen internen Besuchpfad für
JAR-Dateien aufbauen, und wann immer er versucht, eine Klassen-
oder Ressourcendatei zu laden, würde
er jede JAR-Datei in ihrem Suchpfad in dem Prozess zum Herunterladen
und Öffnen
jeder von ihnen linear suchen. Falls der Klassen-Lader versucht,
eine Ressourcendatei zu finden, die überhaupt nicht existiert, dann
werden alle JAR-Dateien heruntergeladen, selbst wenn die meisten
von ihnen für
die Abarbeitung des Applet nicht benötigt werden.
-
EP-A-0817031 offenbart
eine Vorrichtung und Verfahren, die die Erlangung von Applet-Ausführungscode
(eine Basisklasse) innerhalb eines verteilten Objektsystems unterstützen. Ein
Client, der die Applet-Klasse anfordert, befragt einen Namensgebungsdienst,
um den Server zu bestimmen, der die Basisklasse enthält. Der
Client verbindet sich dann mit dem Server, und fordert den Code
für die
Basisklasse von dem Server durch einen Objektanforderungsbroker
(ORB) an. Der Server ruft dann den Code durch entweder Lesen einer
Datei von seiner eigenen lokalen Dateimenge ab, oder falls der Code nicht lokal
ist, befragt den Namensgebungsdienst nach einem anderen Server,
der zu dem Code für
die Basisklasse Zugang hat. Der Server gibt bei diesen Code über den
Weg des ORB zu dem Client zurück.
-
Was
gewünscht
wird, ist deshalb ein Verfahren zum Bereitstellen effizienten Downloads
von Dateien nach Bedarf in einer verteilten Netzumgebung.
-
In
einem ersten Aspekt sieht die Erfindung ein Verfahren zum Ausführen eines
Applet vor, umfassend Bereitstellen einer Dateidownloadanforderung
nach einer Wurzeldatei zu einem bestimmten Servercomputer durch
eine virtuelle Maschine, die in einem Browser enthalten ist, der
verwendet wird, um das Applet auszuführen, wobei die angeforderte
Wurzeldatei Applet-Komponentendateien
enthält,
die durch die virtuelle Maschine verwendet werden, um das Applet
auszuführen,
wobei verwandte der Komponentendateien in ein entsprechendes Paket
gruppiert sind; Herunterladen der Wurzeldatei von dem Servercomputer
als Reaktion auf die Anforderung; Laden der Wurzeldatei; Bestimmen,
ob die Wurzeldatei eine Indexdatei enthält, die Information enthält, die
die Abbildung (mapping) des Paketes auf entsprechende verwandte
Java-Archivdateien bezieht; wenn die Wurzeldatei die Indexdatei
enthält,
Erstellen einer HASH-Tabelle
basierend auf dem Inhalt der Indexdatei, wobei die HASH-Tabelle
eine Abbildung aller Pakete und aller entsprechenden Java-Archivdateien
bereitstellt, die durch die virtuelle Maschine verwendet werden,
um das Applet auszuführen;
während
der Laufzeit der virtuellen Maschine, Befragen der HASH-Tabelle
nach einem Standort einer bestimmten Java-Archivdatei; und direktes
Herunterladen der bestimmten Java-Archivdatei basierend auf dem Standort,
der durch die HASH-Tabelle
bereitgestellt wird, zu der virtuellen Maschine.
-
In
einem zweiten Aspekt sieht die Erfindung einen Computer zum Ausführen eines
Applet vor, wobei der Computer umfasst eine Datenverarbeitungseinrichtung;
und eine Speichereinrichtung in Kommunikation mit der Datenverarbeitungseinrichtung
und Speichern des Computerprogrammcodes, der angepasst ist, eine
Dateidownloadanforderung nach einer Wurzeldatei zu einem bestimmten
Servercomputer durch eine virtuelle Maschine bereitzustellen, die
in einem Browser enthalten ist, der verwendet wird, um das Applet
auszuführen,
wobei die angeforderte Wurzeldatei Applet-Komponentendateien enthält, die durch
die virtuelle Maschine verwendet werden, um das Applet auszuführen, wobei
verwandte der Komponentendateien in ein entsprechendes Paket gruppiert
sind; Herunterladen der Wurzeldatei von dem Servercomputer als Reaktion
auf die Anforderung; Laden der Wurzeldatei; Bestimmen, ob die Wurzeldatei
eine Indexdatei enthält,
die die Abbildung des Paketes auf entsprechende verwandte Java-Archivdateien
bezieht; wenn die Wurzeldatei die Indexdatei enthält, Erstellen
einer HASH-Tabelle basierend auf dem Inhalt der Indexdatei, wobei
die HASH-Tabelle eine Abbildung aller Pakete und aller entsprechenden
Java-Archivdateien vorsieht, die durch die virtuelle Maschine verwendet
werden, um das Applet auszuführen;
während
der Laufzeit der virtuellen Maschine, Befragen der HASH-Tabelle
nach einem Standort einer bestimmten Java-Archivdatei; und direktes
Herunterladen der bestimmten Java-Archivdatei basierend auf dem
Standort, die durch die HASH-Tabelle bereitgestellt wird, zu der
virtuellen Maschine.
-
KURZE BESCHREIBUNG DER ZEICHNUNGEN
-
Die
Erfindung, zusammen mit ihren weiteren Vorteilen, kann am besten
durch Verweis auf die folgende Beschreibung verstanden werden, die
Verbindung mit den begleitenden Zeichnungen aufgenommen wird, in
denen:
-
1 ein
konventionelles verteiltes Computersystem zeigt, das zum Unterstützen einer
Java-basierten Browser-/Serverkonfiguration fähig ist;
-
2 das
verteilte Computersystem von 1 zeigt,
wobei die verschiedenen Applet-Komponenten in einer einzelnen JAR-Datei gespeichert sind;
-
3 ein
verteiltes Computersystem zeigt, das angeordnet ist, eine Java-basierte
Browser-/Serveranordnung in Übereinstimmung
mit einer Ausführungsform
der Erfindung zu unterstützen;
-
4a–4b ein
Flussdiagramm ist, das einen Prozess zum Abrufen und Herunterladen
von Komponentendateien durch eine virtuelle Maschine in Übereinstimmung
mit einer Ausführungsform
der Erfindung detailliert darstellt;
-
5 eine
Ausführungsform
einer Java virtuellen Maschine in Übereinstimmung mit einer Ausführungsform
der Erfindung veranschaulicht; und
-
6 ein
Computersystem veranschaulicht, das eingesetzt werden kann, um die
vorliegende Erfindung zu implementieren.
-
DETAILLIERTE BESCHREIBUNG
DER AUSFÜHRUNGSFORMEN
-
In
der folgenden Beschreibung werden Rahmenbedingungen und Verfahren
zum Bereitstellen nach Bedarf von Dateidownload und Ausführung von Dateien
innerhalb z.B. einer Browser-/Serverumgebung beschrieben. Obwohl
die Erfindung anfangs im Sinne einer auf Java basierten Anwendung
und/oder eines Applet, die/das sich in einem multithreaded objektorientierten
Berechnungssystem befindet, beschrieben wird, sollte vermerkt werden,
dass die vorliegende Erfindung in einem beliebigen System verwendet
werden kann, das zur Handhabung von http-Anforderungen und Antworten
fähig ist.
-
Wenn
ein Benutzer wünscht,
ein Applet laufen zu lassen, das in einem Java-basierten Browser eingebettet
ist, generiert eine Java virtuelle Maschine (JVM), die einen Klassen-Lader
enthält,
eine Dateidownloadanforderung in der Form einer HTTP-Anforderung
zu einem bestimmten Servercomputer, der die geeigneten Applet-Komponentendateien
enthält. Typischerweise
enthalten die Komponentendateien eine Hauptklassendatei, die als
ein Eintrittspunkt für eine
Ausführung
des Applet verwendet wird, ebenso wie andere Java-Klassendateien,
die bei Unterstützung
der Ausführung
des Applet verwendet werden. Außerdem
können
die Komponentendateien Bild- und Klangdateien enthalten, die allgemeiner
als Ressourcendateien bezeichnet werden, die eine Benutzerschnittstellen
für das
Applet bereitstellen. In einer bevorzugten Ausführungsform sind zugehörige Komponentendateien
in etwas gruppiert, was als ein Paket (package) bezeichnet wird.
Das Paket wiederum ist typischerweise komprimiert und in entsprechenden
JAR-Dateien innerhalb von, oder gekoppelt mit, dem Servercomputer
gespeichert. In einigen Fällen sind
viele Pakete innerhalb einer einzelnen Java-Archivdatei-(JAR) Datei
gespeichert, und in anderen Fällen
sind einzelne Klassendateien (ohne begleitendes Paket) in einem
geeignet komprimierten Zustand, falls so gewünscht, in einer entsprechenden JAR-Datei
gespeichert. In einigen Fällen
kann ein Paket unter mehr als einer JAR-Datei gespeichert sein.
-
In
einer Ausführungsform
der Erfindung steht eine erste JAR-Datei, die als die Wurzel-JAR-Datei bezeichnet
wird, mit einer Indexdatei in Verbindung, die Information enthält, die
sich auf die Abbildung verschiedener Pakete (oder einzelner Klassendateien)
und ihrer entsprechenden JAR-Dateien bezieht. Um das Applet auszuführen, befragt
der Klassen-Lader, der mit der Java virtuellen Maschine in Verbindung
steht, die Wurzel-JAR-Datei
und bestimmt, ob eine entsprechende Indexdatei vorhanden ist oder nicht.
Falls eine Indexdatei vorhanden ist, erstellt der Klassen-Lader
eine HASH-Tabelle, die auf dem Inhalt der Indexdatei beruht. In
einer bevorzugten Ausführungsform
sieht der HASH-Tabellenindex eine Abbildung aller Pakete und aller
entsprechenden JAR-Dateien vor, die erforderlich sind, um das Applet durch
die JVM auszuführen.
Während
der Laufzeit, wenn eine bestimmte Datei durch die JVM angefordert
wird, befragt der Klassen-Lader die HASH-Tabelle, um direkt auf
die geeignete JAR-Datei zuzugreifen, die herunterzuladen ist. Auf
diese Weise kann im wesentlichen eine Notwendigkeit vermieden werden,
eine lineare Suche nach allen JAR-Dateien und Komponentendateien,
die darin enthalten sind, durchzuführen.
-
Durch
Reduzieren, oder Eliminieren der linearen Suche nach allen Komponentendateien
während
der Laufzeit werden der Zeitaufwand und Netzressourcen, die erforderlich
sind, um ein gegebenes Applet auszuführen, beträchtlich reduziert. Auf diese Weise
wird es wirtschaftlich machbar, komplexere Applets und/oder Anwendungen
auszuführen
und dadurch anzuwenden, als es gegenwärtig möglich ist. Diese Erhöhung beim
Download einer Datei nach Bedarf und die resultierende Verbesserung
des JVM-Laufzeitleistungsverhaltens sieht eine größere Flexibilität bei Bereitstellung
komplexer Online-Dienste in Bezug auf z.B. interaktiven Aktienhandel,
Online-Angebote und viele andere Transaktionen von e-Commerce vor,
die intensive Echtzeit-Berechnungsfähigkeiten erfordern.
-
Die
Erfindung wird nun im Sinne einer Java virtuellen Maschine beschrieben,
die eingebettet ist innerhalb eines, oder gekoppelt ist mit einem,
Java-basierten Browser(s), der sich in einem Clientcomputer befindet
und typischerweise verwendet wird, um ein Applet auszuführen. Das
Applet wiederum hat eine Reihe von zugehörigen Komponentendateien, wie
etwa Klassen- und
Bilddateien, die gespeichert sind in, oder gekoppelt sind mit, einem
Server (Rost), der mit dem Clientcomputer verbunden ist. In den
meisten Fällen
ist der Server mit anderen miteinander verbundenen Computern gekoppelt,
um ein verteiltes Computersystem zu bilden, wie etwa durch das Internet
dargestellt. Es sollte jedoch vermerkt werden, dass die Erfindung
in einem beliebigen System implementiert werden kann, wo Bereitstellung
nach Bedarf von ressourceneffizientem Download und Ausführung von
Dateien, was z.B. verwendet wird, um eingebettete, oder von einem
anderen Typ, Anwendungen abzuarbeiten, wichtig ist.
-
Bezug
nehmend nun auf 3, wird ein Java-basiertes Browser-/Serversystem 300 in Übereinstimmung
mit einer Ausführungsform
der Erfindung gezeigt. Das System 300 enthält einen
Clientcomputer 302, der mit einem Server-(Rost-)Computer 304 gekoppelt
ist. Typischerweise ist der Hostcomputer 304 Teil eines
verteilten verbundenen Computernetzes (nicht gezeigt), wie etwa
des Internet, kann aber auch Teil eines Lokalbereichsnetzes sein,
was manchmal als ein Intranet bezeichnet wird. Um Kommunikation
zwischen verschiedenen Benutzern und/oder Computern, die das Netz
bilden, zu unterstützen,
nutzt der Clientcomputer 302 die grafischen Benutzerschnittstellen,
die durch eine Webseite 306 präsentiert werden, die sich in
einem Java-basierten Browser 308 befindet (manchmal als
eine HTTP-Seite bezeichnet). Die meisten Browser sind aus verschiedenen
HTTP-Statements gebildet. In einigen Fällen wird ein Applet 310 durch
selektives Einbetten gewisser HTTP-Statements innerhalb des HTTP-Rahmenwerkes
der Webseite 306 gebildet. Durch Einbetten verschiedener
Applets innerhalb des Browsers kann der Browserbenutzer verschiedene
Anwendungen von einem einzelnen Browser unabhängig laufen lassen, wobei dadurch
verschiedene interaktive Ereignisse zwischen dem Browserbenutzer
und dem Computernetz unterstützt
werden.
-
In
der beschriebenen Ausführungsform
führt eine
Java virtuelle Maschine (JVM) 312, die mit Verweis auf 5 detailliert
beschrieben wird, das Applet 310 in der beschriebenen Ausführungsform
durch Instanziieren eines Klassen-Laders 314 aus. Der Klassen-Lader 314 ist
dafür verantwortlich,
Dateien abzurufen, wie sie durch die JVM 312 in der Ausführung des
Applet 310 gerichtet sind. Um das Applet 310 auszuführen, müssen jedoch
verschiedene Komponentendateien, die in dem Server 304 gespeichert
sind, durch die JVM 312 identifiziert, durch den Klassen-Lader 314 abgerufen
und schließlich
zu der JVM 312 für
eine Ausführung
heruntergeladen werden. In der in 3 gezeigten
Ausführungsform
sind die Komponentendateien entsprechend dem Applet in verschiedenen
JAR-Dateien gespeichert. Es sollte vermerkt werden, dass um das
Applet 310 richtig auszuführen, Java-Klassendateien ebenso
wie Ressourcendateien, wie etwa Bild- und/oder Klangdateien, erforderlich
sein können.
In einer bevorzugten Ausführungsform
sind die verschiedenen verwandten Komponentendateien in etwas gruppiert,
was als Pakete bezeichnet wird. Auf dem Weg eines Beispiels enthält ein Paket
P1 verschiedene Klassendateien, a1.class, a2.class
und a3.class derart, dass a1.class
(gewöhnlich
als eine Hauptklassendatei bezeichnet) einen Eintrittspunkt für die JVM 312 bereitstellt,
um eine Ausführung
des Applet 310 zu starten. Typischerweise ist die Hauptklasse
die erste Anwendungsklasse, die durch die JVM 312 geladen
wird, die wenn durch die JVM 312 ausgeführt, Laden zusätzlicher
Klassen aufrufen wird.
-
In
Fortsetzung der Beschreibung des Systems 300 von 3 enthält ein Paket
P2, das in der JAR-Datei JAR2 gespeichert
ist, verschiedene zusätzliche
Klassendateien b1.class, b2.class
und b3.class, die in irgendeiner Form in
der Ausfüh rung des
Applet 310 verwendet werden. Ein wichtiger Aspekt, der
zu vermerken ist, ist dass in einigen Fällen eine einzelne Klassendatei,
wie etwa f00.class, nicht mit irgend einem
bestimmten Paket in Verbindung stehen kann. Auf dem Weg eines Beispiels
steht die Datei f00.class nicht mit irgend
einem bestimmten Paket in Verbindung, sondern ist auch in der JAR-Datei JAR2 gespeichert.
-
Es
ist auch wichtig zu vermerken, dass in einigen Fällen ein Paket in mehr als
einer JAR-Datei gespeichert sein kann, derart, dass ein bestimmtes Paket
mit einer Liste von JAR-Dateien in Verbindung stehen kann. Eine
derartige Situation wird in 3 mit Bezug
auf Paket P1 gezeigt, das in sowohl der JAR-Datei
JAR1 als auch der JAR-Datei JAR2 gespeichert
ist.
-
Wenn
die JVM 312 beginnt, das Applet 310 auszuführen, lädt der Klassen-Lader 314,
der mit der JVM 312 in Verbindung steht, die Wurzel-JAR-Datei, die
in diesem Beispiel die JAR-Datei
JAR1 ist. Der Klassen-Lader 314 wird
dann bestimmen, ob eine Indexdatei 316, die alle Pakete
zu entsprechenden JAR-Dateien
abbildet, in der Wurzel-JAR-Datei JAR1 enthalten
ist. Falls eine derartige Indexdatei existiert, verwendet der Klassen-Lader 314 Information,
die in der Indexdatei 316 enthalten ist, um eine HASH-Tabelle 318 zu
erstellen. In einer bevorzugten Ausführungsform sieht die HASH-Tabelle 318 eine
Abbildung zwischen allen Paketen, die mit dem Applet 310 in
Verbindung stehen, und den entsprechenden JAR-Dateien, in denen
jene Pakete gefunden werden können,
vor. Sobald die HASH-Tabelle 318 erstellt wurde,
liest der Klassen-Lader 314 dann die HASH-Tabelle 318,
um die JAR-Datei zu ermitteln, in der sich die Hauptklassendatei
befindet (JAR1).
-
Sobald
die Hauptklassendatei lokalisiert wurde, lädt der Klassen-Lader 314 die
geeignete JAR-Datei direkt herunter, wie durch die HASH-Tabelle 318 angezeigt,
und greift auf die gewünschte Hauptklassendatei
zu, die dann zu der JVM 312 geladen wird. Sobald die JVM 312 die
heruntergeladene Hauptklassendatei abgerufen hat, beginnt die JVM 312 die
Ausführung
des Applet 310. Während die
JVM 312 das Applet 310 ausführt, setzt der Klassen-Lader 314 fort,
die HASH-Tabelle 318 nach dem Standort von Klassen- und/oder
Ressourcendateien abzufragen, wie durch die JVM 312 angefordert,
um die Ausführung
des Applet 310 fortzusetzen. Auf diese Weise wird die Notwendigkeit,
lineare Suche der Klassen- und Ressourcendateien, die innerhalb
der verschiedenen JAR-Dateien gespeichert sind, die in dem Hostcomputer 304 gespeichert
sind, durchzuführen
beträchtlich
reduziert, oder in einigen Fällen beseitigt.
Schließlich
endet die Ausführung
des Applet 310. Es sollte vermerkt werden, dass die JVM 312 viele
Applets ausführen
kann.
-
4a und 4b veranschaulichen
ein Flussdiagramm, das einen Prozess 400 zum Herunterladen
und Ausführen
von Dateien in einer verteilten Netzumgebung in Übereinstimmung mit einer Ausführungsform
der Erfindung detailliert zeigt. Der Prozess 400 beginnt
in 4a in 402 durch den Browser, der sich
in einem Clientcomputer befindet, der ein Applet von einem Server-(Rost-)Computer anfordert
und herunterlädt.
Eine JVM, die sich in dem Clientcomputer befindet, interpretiert
die Hauptklassentags und Archivdateitags entsprechend dem heruntergeladenen
Applet in 404. Die Hauptklassentags und die Archivdateitags
versehen die JVM mit Dateiidentifikatoren, die anschließend verwendet
werden, um die verschiedenen Applet-Komponentendateien zu identifizieren,
die in Speichereinrichtungen gespeichert sind, die mit dem Hostcomputer
gekoppelt sind. In 406 lädt und öffnet die JVM unter Verwendung
der Hauptklassentags die Wurzel-JAR-Datei, die die Hauptklassendateien
enthalten kann, die mit dem Applet in Verbindung stehen. In 408 wird
dann eine Bestimmung durchgeführt,
ob eine Indexdatei mit der Wurzel-JAR-Datei in Verbindung steht
oder nicht. Falls bestimmt wird, dass es keine zugehörige Indexdatei
gibt, dann wird in 410 eine lineare Suche per Vorgabe aller
JAR-Dateien durchgeführt.
Anderenfalls baut in 412 der Klassen-Lader in der JVM eine
HASH-Tabelle basierend auf der Indexdatei auf, die alle Pakete und/oder
Klassendateien nicht in Paketen zu ihren jeweiligen JAR-Dateien
abbildet.
-
4b zugewandt
wird, sobald der Klassen-Lader die HASH-Tabelle gebildet hat, in 414 eine Bestimmung
des Paketnamen durchgeführt,
der mit einer angeforderten Klassendatei in Verbindung steht. Falls
in 416 bestimmt wird, dass der Paketname, der mit der angeforderten
Datei in Verbindung steht, nicht in der HASH-Tabelle ist, dann wird
der Name der angeforderten Datei selbst verwendet, um die HASH-Tabelle
in 418 abzufragen. Diese bestimmte Situation entsteht,
wenn sich z.B. eine einzelne Klassendatei nicht auf beliebige andere
Klassendateien bezieht und deshalb nicht mit einem bestimmten Paket
in Verbindung steht. Dieser Fall wird in 3 durch
die Datei f00.class veranschaulicht, die in
der JAR-Datei JAR2 gespeichert ist.
-
Falls
jedoch in 416 der Paketname gefunden wird, der in der HASH-Tabelle
enthalten sein muss, dann wird der Paketname auf die zugehörigen) JAR-Dateien)
unter Verwendung der HASH-Tabelle in 420 abgebildet. Es
sollte vermerkt werden, dass es eine beliebige Zahl von JAR-Dateien
geben kann, die einem bestimmten Paketnamen entsprechen, und dass
eine bestimmte JAR-Datei
mit mehr als einem Paketnamen in Verbindung stehen kann. Diese Fälle werden
in 3 angemessen veranschaulicht und ordnungsgemäß vermerkt.
Sobald die geeignete(n) JAR-Datei(en) identifiziert wurde(n), wird
der lineare Suchealgorithmus verwendet, um die JAR-Dateien auf der
Rückgabeliste
zu suchen, die in 422 eine nach der anderen heruntergeladen
und nach der angeforderten Klassendatei durchsucht werden.
-
(Es
sollte vermerkt werden, dass in einigen Fällen die Rückgabeliste leer sein könnte, was
einen Fehler anzeigt.) In einer Ausführungsform wird, sobald die
geeigneten JAR-Dateien auf der Rückgabeliste
identifiziert sind, die erste JAR-Datei heruntergeladen und durchsucht.
-
Falls
in 424 bestimmt wird, dass die heruntergeladene JAR-Datei
die angeforderte Datei enthält,
dann wird die angeforderte Klassendatei in 426 abgerufen
und in die JVM geladen. Falls jedoch die angeforderte Datei nicht
in der heruntergeladenen JAR-Datei ist, dann wird in 428 eine
Bestimmung durchgeführt,
ob es zusätzliche
JAR-Dateien auf der Rückgabeliste
gibt oder nicht. Falls es keine zusätzlichen JAR-Dateien gibt,
dann ist ein Fehler aufgetreten und es wird ein Fehlerflag in 430 geworfen.
Falls es andererseits zusätzliche
JAR-Dateien auf der Rückgabeliste
gibt, dann wird die nächste
JAR-Datei auf der Rückgabeliste
in 432 heruntergeladen und die Steuerung wird zu 424 weitergegeben
um zu bestimmen, ob die angeforderte Datei in der nächsten heruntergeladenen
JAR-Datei vorhanden
ist oder nicht.
-
5 ist
ein Blockdiagramm einer virtuellen Maschine 500, die zum
Implementieren der vorliegenden Erfindung geeignet ist. Wenn ein
Computerprogramm, z.B. ein Computerprogramm, das in der Programmiersprache
Java geschrieben ist, ausgeführt
wird, wird ein Quellcode 502 einem Compiler 504 innerhalb
einer Kompilierzeitumgebung 506 bereitgestellt. Der Compiler 504 übersetzt
den Quellcode 502 in Bytecodes 508. Im allgemeinen
wird der Quellcode 502 in Bytecodes zu der Zeit übersetzt, wenn
der Quellcode 502 durch einen Softwareentwickler erstellt
wird.
-
Bytecodes 508 können allgemein
reproduziert, heruntergeladen oder anderweitig durch ein Netz verteilt
oder in einer Speichereinrichtung gespeichert werden. In der beschriebenen
Aus führungsform
sind Bytecodes 508 plattformunabhängig. Das heißt Bytecodes 508 können in
einem im wesentlichen beliebigen Computersystem ausgeführt werden,
das in einer geeigneten virtuellen Maschine läuft.
-
Bytecodes 508 werden
einer Laufzeitumgebung 510 bereitgestellt, die eine virtuellen
Maschine 312 enthält.
Die Laufzeitumgebung 510 kann allgemein unter Verwendung
eines Prozessors oder Prozessoren ausgeführt werden, wie etwa Prozessor 602,
der nachstehend mit Verweis auf 6 beschrieben
wird. Die virtuelle Maschine 312 enthält einen Compiler 512,
einen Interpreter 514 und ein Laufzeitsystem 516.
Bytecodes 508 können
entweder dem Compiler 512 oder dem Interpreter 514 bereitgestellt
werden.
-
Wenn
Bytecodes 508 dem Compiler 512 bereitgestellt
werden, werden Methoden, die in Bytecodes 508 enthalten
sind, in Maschineninstruktionen kompiliert. In einer Ausführungsform
ist der Compiler 512 ein just-in-time Compiler, der die
Kompilierung von Methoden, die in Bytecodes 508 enthalten
sind, verzögert,
bis die Methoden fertig sind ausgeführt zu werden. Wenn Bytecodes 508 dem
Interpreter 514 bereitgestellt werden, werden Bytecodes 508 in
den Interpreter 514 ein Bytecode in einem Zeitpunkt gelesen.
Der Interpreter 514 führt
dann die Operation durch, die durch jeden Bytecode definiert ist,
wie jeder Bytecode in den Interpreter 514 gelesen wird. Das
heißt
der Interpreter 514 "interpretiert" Bytecodes 508,
wie durch einen Fachmann erkannt wird.
-
Wenn
eine Methode durch eine andere Methode aufgerufen wird, oder von
der Laufzeitumgebung 510 aufgerufen wird, kann, falls die
Methode interpretiert wird, das Laufzeitsystem 516 die
Methode von der Laufzeitumgebung 510 in der Form von Sequenzen
von Bytecodes 508 erhalten, die durch den Interpreter 514 direkt
ausgeführt
werden können. Falls
andererseits die Methode, die aufgerufen wird, eine kompilierte
Methode ist, die nicht kompiliert wurde, erhält das Laufzeitsystem 516 auch
die Methode von der Laufzeitumgebung 510 in der Form einer
Sequenz von Bytecodes 508, die dann gehen können, den
Compiler 512 zu aktivieren. Der Compiler 512 generiert
dann Maschineninstruktionen aus Bytecodes 508, und die
resultierenden Maschinenspracheninstruktionen können durch das Betriebssystem 518 direkt
ausgeführt
werden. Die Maschinenspracheninstruktionen werden verworfen, wenn
die virtuelle Maschine 312 terminiert. Die Operation virtueller Maschinen,
oder genauer von Java virtuellen Maschinen, wird detaillierter in
The Java Virtual Machine Specification von Tim Lindholm und Frank
Yellin (ISBN 0-201-63452-X) beschrieben, was hierin durch Verweis
einbezogen wird.
-
6 veranschaulicht
ein Computersystem 600, das eingesetzt werden kann, um
die vorliegende Erfindung zu implementieren. Das Computersystem 600,
oder genauer CPUs 602, kann angeordnet sein, eine virtuelle
Maschine zu unterstützen,
wie durch einen Fachmann erkannt wird. Wie in der Technik gut bekannt
ist, agiert der ROM, um Daten und Instruktionen unidirektional zu
den CPUs 602 zu transferieren, während RAM typischerweise verwendet
wird, um Daten und Instruktionen auf eine bidirektionale Art und
Weise zu transferieren. Die CPUs 602 können allgemein eine beliebige
Zahl von Prozessoren enthalten. Beide primären Speichereinrichtungen 604, 606 können beliebige
geeignete computerlesbare Medien enthalten. Ein sekundäres Speichermedium 608,
was typischerweise eine Massenspeichereinrichtung ist, ist auch
mit CPUs 602 bidirektional gekoppelt und stellt zusätzliche
Datenspeicherkapazität
bereit. Die Massenspeichereinrichtung 608 ist ein computerlesbares
Medium, das verwendet werden kann, um Programme zu speichern, einschließlich Computercode,
Daten und dergleichen. Typischerweise ist die Massenspeichereinrichtung 608 ein
Speichermedium, wie etwa eine Festplatte oder ein Band, welches
allgemein langsamer als die primären
Speichereinrichtungen 604, 606 ist. Die Massenspeichereinrichtung 608 kann
die Form eines magnetischen oder Papierband-Lesegerätes oder
irgend einer anderen gut bekannten Einrichtung annehmen. Es wird
erkannt, dass die Information, die innerhalb der Massenspeichereinrichtung 608 gehalten
wird, in geeigneten Fällen
auf eine standardmäßiger Weise
als Teil von RAM 606 als virtueller Speicher einbezogen
werden kann. Eine spezifische primäre Speichereinrichtung 604,
wie etwa eine CD-ROM, kann auch Daten zu den CPUs 602 unidirektional
weitergeben.
-
Die
CPUs 602 sind auch mit einer oder mehr Eingabe-/Ausgabeeinrichtungen 610 gekoppelt,
die enthalten können,
aber nicht darauf begrenzt sind, Einrichtungen, wie etwa Videomonitore,
Trackballs, Mäuse,
Tastaturen, Mikrofone, berührungsempfindliche
Displays, Umformerkartenlesegeräte,
magnetische oder Papierband-Lesegeräte, Tablets, Styluses, Sprach-
oder Handschrifterkennungseinrichtungen oder andere gut bekannten
Eingabeeinrichtungen, wie etwa natürlich andere Computer. Schließlich können die
CPUs 602 optional mit einem Computer oder Telekommunikationsnetz
gekoppelt sein, z.B. einem Internet-Netzwerk oder einem Intranet-Netzwerk,
unter Verwendung einer Netzverbindung, wie allgemein bei 612 gezeigt.
Mit einer derartigen Netzverbindung wird betrachtet, dass die CPUs 602 Information
aus dem Netz abrufen können,
oder Information zu dem Netz in dem Verlauf einer Durchführung der
oben beschriebenen Verfahrensschritte ausgeben können. Derartige Information,
die häufig
als eine Sequenz von Instruktionen dargestellt wird, um unter Verwendung
von CPUs 602 ausgeführt
zu werden, kann von/zu dem Netz empfangen und ausgegeben werden,
z.B. in der Form eines Computerdatensignals, das in einer Trägerwelle
verkörpert
ist. Die oben beschriebenen Einrichtungen und Materialien werden einem
Fachmann für
Computerhardware und Software vertraut sein.
-
Obwohl
nur einige wenige Ausführungsformen
der vorliegenden Erfindung beschrieben wurden, sollte verstanden
werden, dass die vorliegende Erfindung in vielen anderen spezifischen
Formen verkörpert
werden kann, ohne von dem Bereich der vorliegenden Erfindung abzuweichen.
-
Obwohl
die Verfahren zum Bereitstellen von effizientem Dateidownload und
Ausführung
in einer Browserumgebung in Übereinstimmung
mit der vorliegenden Erfindung für
eine Implementierung mit Bezug auf eine auf JavaTM-basierte
Umgebung besonders geeignet sind, können die Verfahren allgemein
in einer beliebigen geeigneten objektbasierten Umgebung angewendet
werden. Insbesondere sind die Verfahren für eine Verwendung in plattformunabhängigen objektbasierten
Umgebungen geeignet. Es sollte erkannt werden, dass die Verfahren
auch in einigen verteilten objektorientierten Systemen implementiert
werden können.
-
Während die
vorliegende Erfindung beschrieben wurde, mit einem Computersystem
verwendet zu werden, das einen zugehörigen Webbrowser und Webserver
hat, sollte erkannt werden, dass die vorliegende Erfindung allgemein
in einem beliebigen geeigneten objektorientierten Computersystem implementiert
werden kann. Deshalb sind die vorliegende Beispiele als veranschaulichend
und nicht beschränkend
zu betrachten, und die Erfindung ist nicht auf die hierin angegebenen
Details zu begrenzen, sondern kann innerhalb des Bereiches der angefügten Ansprüche modifiziert
werden.