DE60125068T2

DE60125068T2 - Verfahren und vorrichtung zur elementenorganisation einer serverapplikation in einem client-server system

Info

Publication number: DE60125068T2
Application number: DE60125068T
Authority: DE
Inventors: Keith Palo Alto DEUTSCH; Pallavi Mountain View SHAH; Gerardo Mountain View FERNANDO
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 2000-10-17
Filing date: 2001-10-17
Publication date: 2007-06-28
Anticipated expiration: 2021-10-18
Also published as: EP1428117A2; AU2002213302A1; WO2002033546A2; WO2002033546A3; EP1428117B1; DE60125068D1

Description

HINTERGRUND DER ERFINDUNG
1. GEBIET DER ERFINDUNG
Die vorliegende Erfindung bezieht sich auf das Gebiet der Computeranwendungen und genauer gesagt auf objektorientierte Client-Server-Anwendungen.
Sun, Sun Microsystems, das Sun-Logo, Java, Java 3D und alle Marken und Logos auf Java-Basis sind Marken oder registrierte Marken von Sun Microsystems, Inc., in den Vereinigten Staaten und anderen Ländern. Alle SPARC-Marken werden unter Lizenz verwendet und sind Marken von SPARC-International, Inc., in den Vereinigten Staaten und anderen Ländern. Produkte, welche SPARC-Marken tragen, beruhen auf einer Architektur, die von Sun Microsystems, Inc., entwickelt wurde.
2. TECHNISCHER HINTERGRUND
In monolithisch entworfenen, objektorientierten Computeranwendungen wird Programmcode als eine Sammlung von Objekten entwickelt, die als ein "Objektnetz" verknüpft sind. Jedes Objekt umhüllt bzw. umfaßt seine eigenen Daten, ebenso wie Methoden zum Arbeiten mit diesen Daten. In der Ausführung der Anwendung werden Nachrichten zwischen Objekten gesendet, welche die verschiedenen Methoden aufrufen, um die Anwendung zu implementieren. Immer häufiger werden jedoch Anwendungen in einer der Natur nach verteilten Weise entworfen. Das heißt, Elemente der Anwendung können in getrennten Ausführungsumgebungen existieren, manchmal innerhalb desselben Computersystems residieren, jedoch häufiger in mehreren Computersystemen ausgeführt werden, die über ein Netzwerk miteinander verbunden sind. Ein Beispiel eines solchen verteilten Schemas ist das Client-Server-Paradigma. Unglücklicherweise ist es, wie nachstehend beschrieben wird, für monolithische, verteilte Anwendungen schwierig, eine effiziente Kommunikation zwischen den verteilten Elementen der Anwendung bereitzustellen.
In einer Client-Server-Anwendung wird die Funktionalität der Anwendung zwischen zwei primären Stellen aufgeteilt, d.h. dem "Client" und dem "Server". In vielen Fällen bildet derselbe Server eine Schnittstelle zu mehreren Klienten, beispielsweise für einen gemeinsamen Zugriff auf eine Datenbank oder gemeinsam verwendete Dienste. In dieser Art von Umgebung wird für eine monolithisch entworfene Anwendung die Kommunikation zu einfachen Client-Server-Nachrichten verallgemeinert, die über einen gemeinsamen Kommunikationskanal gesendet werden.
Typischerweise fordert ein Kommunikationsobjekt oder -komponente des Client alle ausgehenden Nachrichtenanforderungen von den Anwendungsobjekten an, die für den Client lokal sind. Diese ausgehenden Nachrichtenanforderungen werden verpackt (beispielsweise als ein Netzwerkpaket) und über den gemeinsamen Kanal an den Server gesendet. Beim Server empfängt ein anderes Kommunikationsobjekt die verpackte Nachricht. Das Kommunikationsobjekt oder ein anderes auf dem Server residierendes Objekt muß dann bestimmen, worauf die Nachricht sich bezieht (d.h. was ist der Kontext der Nachricht) und welches Objekt auf dem Server die Nachricht handhaben sollte. Es ist möglich, daß die Nachricht auf diese Weise von mehreren Objekten verarbeitet wird, bevor sie an das gewünschte Zielobjekt auf dem Server weitergeleitet wird. Derselbe Kommunikationsvorgang wird über den gemeinsamen Kommunikationskanal für Kommunikationen, die von dem Server stammen, für die Verarbeitung durch den Client wiederholt. Der Vorgang des Bestimmens des Nachrichtenkontextes und der Identifizierung des geeigneten Zielobjektes ist womöglich nicht trivial, insbesondere für große Anwendungen. Da die Anwendung von monolithischer Natur ist, ist es womöglich nicht offensichtlich, welches Objekt eine Nachricht handhaben sollte, die einen bestimmten Kontext hat. Zusätzlicher Aufwand ist erforderlich, um vorab zu bestimmen, welche Arten von Nachrichtenkontexten jedes Objekt handhaben kann und diese vorab bestimmte Information in einem nutzbaren Format zu organisieren. Die Anwendungsstruktur muß dann festbleiben, damit diese vorbestimmte Information gültig bleibt. Das Einschränken der Anwendung auf eine statische Konfigurierung beseitigt so in unerwünschter Weise jede dynamische Flexibilität in der Anwendung, was Verbesserungen und Änderungen an der Anwendung komplizierter macht. Es sind deshalb Bemühungen zur Verbesserung der Effizienz der Kommunikation in verteilten Anwendungen ohne Einschränkung der Flexibilität dieser Anwendungen erforderlich.
Der Aufwand in der Organisation der Anwendungen umfaßt die Entwicklung von hierarchischen Werkzeugen, die als Szenekurven (Scenegraphs) bezeichnet werden, welche verwendet werden, um das Herstellen der Anwendungen als gerichtete, nicht zyklische Graphen zu organisieren. Eine Beschreibung der Scenegraph-Techniken wird nachstehend gegeben.
Scenegraph-Techniken
Ein Scenegraph ist eine Baumstruktur, die eine Mehrzahl von Knoten aufweist, die in hierarchischer Weise miteinander verbunden sind. Diese hierarchische Struktur stellt ein wohl organisiertes Grundgerüst für Softwareanwendungen bereit, und eines, in welchem Funktionalität in einfacher Weise durch Hinzufügen von einem oder mehreren Knoten zu einem existierenden Scenegraph erweitert werden kann. Individuelle funktionelle Anwendungselemente werden aufgebaut als getrennte Knotenobjekte und miteinander in einer baumartigen Struktur verbunden. Diese Knotenobjekte werden dann unter Verwendung ihrer vordefinierten Zugriffs- (Accessor), Veränderer- (Mutator) und Knotenverknüpfungsmethoden manipuliert.
Für die (weitere) Bezugnahme ist ein Objekt eine Programmiereinheit, welche eine Datenstruktur (eine oder mehrere Instanzenvariable) miteinander gruppiert, zusammen mit den Operationen (Methoden), die diese Daten verwenden oder beeinflussen können. Ein Objekt besteht also aus Daten und einer oder mehreren Operationen und Vorgängen, die mit diesen Daten ausgeführt werden können. Ein Objekt kann angewiesen werden, eine seiner Methoden durchzuführen, wenn es eine "Nachricht" empfängt. Eine Nachricht ist ein Befehl oder eine Anweisung, die an das Objekt gesendet wird, um eine gewisse Methode auszuführen. Eine Nachricht besteht aus einer Methodenauswahl (z.B. dem Methodennamen) und Null oder mehreren Argumenten. Eine Nachricht sagt dem empfangenden Objekt, welche Operationen ausgeführt werden sollen.
Jegliches gegebene Objekt ist eine "Instanz" einer bestimmten Klasse. Eine Klasse stellt eine Definition für ein Objekt bereit, welches typischerweise beide Felder (z.B. Variable) und Methoden umfaßt. (Der Begriff "Object" wird für sich selbst oftmals austauschbar verwendet, um auf eine bestimmte Klasse oder eine bestimmte Instanz Bezug zu nehmen.) Eine Instanz einer Klasse umfaßt die Variablen und Methoden, die für diese Klasse definiert sind. Mehrere Instanzen können aus derselben Klasse erzeugt werden.
In dem Aufbau eines Scenegraph wird ein Tochterknotenobjekt an einem Eltern- bzw. Mutterknotenobjekt angebracht, indem die Methode "addChild" (Tochter hinzufügen) des Mutterknotenobjektes angebracht und das Tochterknotenobjekt in dem Eingangsfeld spezifiziert wird. Eine Referenz zu dem bzw. ein Aufruf des Tochterknotenobjektes wird dann in dem Mutterknotenobjekt gespeichert, was den allgemeinen Scenegraph-Mechanismus, wie z.B. Durchlaufmethoden, dafür freigibt, zwischen den Mutter- und Tochterknotenobjekten implementiert zu werden. Andere spezielle Mechanismen für das Verknüpfen von Tochterknoten können für spezifische Knotenobjekttypen implementiert werden. Außerdem können Einschränkungen dahingehend auferlegt werden, welche Typen von Knotenobjekten als Töchter mit anderen speziellen Knotentypen verknüpft (verlinkt) werden dürfen, um bestimmte Knotenbeziehungen von Scenegraph-Implementierungen in Kraft zu setzen.
Scenegraphs werden derzeit bei der Anwendung zur Erzeugung von Grafiken verwendet. Der Scenegraph enthält eine vollständige Beschreibung der gesamten Szene oder eines virtuellen Universums. Dies umfaßt die geometrischen Daten, die Attributinformation und die Sichtinformation, die benötigt wird, um die Szene von einem bestimmten Blickpunkt aus zu erzeugen. Im Fall einer 3D-Szene unterstützt die Scenegraph-Hierarchie eine räumliche Gruppierung geometrischer Objekte, die man an den "Blättern" (d.h. den Endknoten) des Scenegraph findet. Interne Knoten wirken so, daß sie ihre Töchter zu einer Gruppe zusammenfassen. Ein Gruppenknoten kann auch eine räumliche Grenze definieren, welche die gesamte Geometrie enthält, welche durch ihre Abkömmlinge definiert werden. Eine räumliche Gruppierung ermöglicht eine effiziente Implementierung von Operationen, wie z.B. Erfassung der Nähe, Kollisionserfassung, Kegelstumpfauslese des Sichtfeldes und Verdeckungswegschnitt.
Knotenobjekte eines Scenegraph können in "Gruppenknoten"-Objekte und "Blattknoten"-Objekte getrennt werden. Gruppenknotenobjekte gruppieren einen oder mehrere Töchterknoten zusammen und sie können verwendet werden, um das Verhalten von Tochterknoten oder Beziehungen, welche diese Tochterknoten gemeinsam haben, zu definieren. Ein Blattknoten hat keine Töchter und hat nur eine Mutter (ein Elternteil). Der Zustand eines Blattknotens umfaßt jeden Zustand auf einem direkten Pfad zwischen dem Blattknoten und der Quelle oder dem "Wurzel"-Knoten des Scenegraph. Im Kontext einer graphischen Szene enthalten Blattknotenobjekte die eigentlichen Definitionen der Formen (Geometrie), des Lichtes, Nebels, Klangs, etc. Wenn eine Szene hergestellt wird, umfaßt die Herstellungsmaschine (Renderer) eine Zustandsveränderung, die auf einem direkten Weg von dem Wurzelknoten des Scenegraph zu einem Blattknotenabjekt in der Zeichnung dieses Blattknotenobjektes vorgenommen werden.
1 veranschaulicht eine allgemeine Scenegraph-Struktur, die verwendet wird, um eine 3D-Szene beispielsweise gemäß der Scenegraph-Strategie wiederzugeben, wie sie in der von Sun Microsystems Inc. verfügbaren Spezifikation von Java 3D^TM-API beschrieben wird. Der Scenegraph nach 1 weist einen einzelnen Wurzelknoten, der als virtuelles Universum (VU) 100 bezeichnet wird, einen oder mehrere lokale Knoten (LO) 101, einen oder mehrere Zweig- bzw. Verzweigungsgruppenknoten (BG) 102, einen oder mehrere Gruppenknoten (GN) 103 und einen oder mehrere Blattknoten (LN) 104 auf.
Das virtuelle Universum 100 repräsentiert das Zentrum der Szene, wobei alle Tochterknoten relativ zu dieser positioniert sind. Einer oder mehrere hochauflösende lokale Knoten 101 sind mit dem virtuellen Universum 100 verbunden. Jeder derartige lokale Knoten 101 spezifiziert eine relative Verschiebe- bzw. Offsetposition bezüglich des virtuellen Universums 100. Dieser relative Versatz bzw. diese relative Verschiebung wird in einem hochauflösenden Format wie dergegeben, um Abstandsbeziehungen aufzufangen, welche mit den kleinsten und den größten Distanzen vergleichbar sind, die man sich in der realen Welt vorstellt. Jeder lokale Knoten 101 kann verwendet werden, um einen oder mehrere Verzweigungsgruppenknoten 102 daran anzubringen, und deren Herstellungspositionen relativ zu dem gegebenen lokalen Knoten 101 interpretiert werden.
Verzweigungsgruppenknoten 102 wirken allgemein als ein Wurzelknoten bzw. Ursprungsknoten einer Teilkurve bzw. eines Teilgraphen, der zu dem gegebenen lokalen Mutter- bzw. Elternknoten 101 gehört. Wenn ein Verzweigungsgruppenknoten 102 an einem lokalen Knoten 101 angebracht wird und damit an einem virtuellen Universum 100, werden der Verzweigungsgruppenknoten und seine Abkömmlinge als "lebend" (d.h. bereit, etwas zu tun) bezüglich der Szene betrachtet. Einer oder mehrere allgemeine Gruppenknoten 103 können als Tochterknoten an jedem Verzweigungsgruppenknoten 102 angebracht werden. Jeder Gruppenknoten 103 kann keinen oder einen oder mehrere Tochterknoten in Form weiterer Gruppenknoten 103 oder Blattknoten 104 unterstützen.
Ein Beispiel einer Implementierung eines Gruppenknotens 103 ist ein Transformationsknoten, welcher eine Transformationsmatrix enthält, die verwendet wird, um ihre Abkömmlinge zu skalieren, zu drehen und zu positionieren. Andere Gruppenknoten, die als "Verhaltens"-Knoten implementiert werden, können verwendet werden, um Algorithmen zur Modifizierung der Transformationsmatrizen speziell angegebener Transformationsobjekte zu verkörpern. Gewisse Blattknotenobjekte können auch Referenzen auf Komponentenobjekte (nicht dargestellt) haben, welche spezielle Attribute des gegebenen Blattknotenobjektes spezifizieren (z.B. kann ein Formblattknoten als zugehörige Komponentenobjekte ein Geometriekomponentenobjekt haben, welches eine geometrische Form des Formblattknotens beschreibt, sowie ein Erscheinungskomponentenobjekt der Form hinsichtlich Farbe, Textur, etc. beschreibt). Ein Blattknoten wird typischerweise verwendet, um die Betrachtungsplattform für Herstellungszwecke mit zugehörigen Komponentenobjekten zur Beschreibung von Attributen des Blickpunktes der Herstellung, ebenso wie die Leinwand oder den Bildschirm, auf welcher die erzeugte Ausgangsgröße dargestellt werden soll, wiederzugeben.
Die US 6115549 offenbart eine Vorrichtung, die Verzeichnisdienste eines Netzwerkes implementiert, um Daten zur Steuerung der Verteilung von Software bereitzustellen. Die Vorrichtung pflegt einen Datenspeicher von miteinander in Beziehung stehenden logischen Einheiten und speichert ein Verteilungsobjekt, welches alle Verteilungsinformation enthält, die zu einer Verteilung gehört. Ein Client kann die Information in dem Verteilungsobjekt lesen und die Software zu sich heranziehen.
US 6115646 offenbart eine dynamische und generische objektorientierte Prozeßautomatisierungsmaschine, die Workflow-Managementdienste in einer verteilten Rechnerumgebung bereitstellt. Ein Aufbauzeitteil wird verwendet, um Prozeßdefinitionen aufzunehmen und zu speichern und um einen Prozeß anzufordern. Ein Laufzeitteil wird verwendet, um den angeforderten Prozeß zu planen, auszuführen und zu überwachen. Ein CORBA-Bus wird verwendet, um Softwareanwendungen aufzupfropfen, die für die Ausführung eines Prozesses benötigt werden.
ZUSAMMENFASSUNG DER ERFINDUNG
Ein Verfahren und eine Vorrichtung, wie sie in den anhängenden Ansprüchen definiert werden, können verwendet werden, um Elemente einer Client-Server-Anwendung in einem Client-Server-System zu organisieren. Client- und Serverkomponenten einer Anwendung sind als komplementäre hierarchische Graphen organisiert, wie z.B. Bäume oder gerichtete azyklische Graphen. Einer oder mehrere Knoten in dem Servergraph sind über eine verteilte Kommunikationsschnittstelle mit den entsprechenden Peerknoten in jedem der Clientgraphen verknüpft. Der Servergraph weist Serverknoten auf, welche der Vereinigung aller Clientknoten (d.h. der verfügbaren Clientknoten) entspricht, während jeder Clientgraph einem Teilsatz der zugehörigen Serverknoten entspricht.
In sich abgeschlossene Objektgraphen, die als Aktoren bezeichnet werden, können zusammengebracht werden, um zusammengesetzte Objektgraphen auf dem Client und dem Server zu bilden. Client-Server-Anwendungen können damit zur Laufzeit aus Ansammlungen von Aktoren gebildet werden, die in einer hierarchischen Weise organisiert sind. Jeder Aktor ist bezüglich seiner Peers sicher, und eine sichere Schnittstelle wird bereitgestellt für den Fernzugriff und das Aktualisieren von Aktoren durch entsprechende Besitzer, wie z.B. Aktoren-Verteiler eines externen Servers.
KURZE BESCHREIBUNG DER FIGUREN
1 ist ein Blockdiagramm in der allgemeinen Ausführungsform eines Scenegraph für die Wiedergabe von 3D-Szenen.
2 ist ein Blockdiagramm eines hierarchischen Graphen gemäß einer Ausführungsform der Erfindung.
3 ist ein Blockdiagramm einer beispielhaften Client-Server-Anwendung gemäß einer Ausführungsform der Erfindung, die komplementäre Graphen von Aktoren aufweist.
4 ist ein Blockdiagramm eines Client-Server-Systems mit externen Quellen gemäß einer Ausführungsform der Erfindung.
5 ist ein Blockdiagramm einer Graphenarchitektur einer Quellenverteilung gemäß einer Ausführungsform der Erfindung.
6 ist ein Blockdiagramm einer Verarbeitungsumgebung, welche eine objektorientierte Laufzeitumgebung aufweist, die in der Lage ist, eine geeignete Softwareausführungsumgebung für eine Ausführungsform der Erfindung bereitzustellen.
7 ist ein Blockdiagramm einer Ausführungsform eines Computersystems, welches in der Lage ist, eine geeignete Hardwareausführungsumgebung für eine Ausführungsform der Erfindung bereitzustellen.
GENAUE BESCHREIBUNG DER ERFINDUNG
Die Erfindung ist ein Verfahren oder eine Vorrichtung zum Organisieren von Elementen einer Serveranwendung in einem Client-Serversystem. In der folgenden Beschreibung sind viele spezielle Einzelheiten dargelegt für die Bereitstellung einer gründlicheren Beschreibung von Ausführungsformen der Erfindung. Es liegt jedoch für Fachleute auf der Hand, daß die Erfindung ohne diese speziellen Einzelheiten ausgeführt werden kann. In anderen Fällen sind wohlbekannte Merkmale nicht im einzelnen beschrieben worden, um die Erfindung nicht zu verschleiern.
Ausführungsformen der Erfindung sind auf Anwendungen gerichtet, die komplementäre Client- und Serverkomponenten haben, die als hierarchische Graphen oder Bäume organisiert sind. Beispielhafte Mechanismen zum Transportieren von Grapheninformation über ein Netzwerk für den Aufbau einer solchen Anwendung werden in der gleichzeitig anhängenden US-Patentanmeldung mit der Seriennummer 551522 und dem Titel "Method and Apparatus for Transport of Scenegraph Information Across a Network", eingereicht am 18. April 2000, die derselben Anmelderin gehört (nunmehr US 6,751,655 , welche der europäischen Patentanmeldung 01927223.6 entspricht), beschrieben.
In Ausführungsformen der Erfindung verwendet die Serveranwendungsarchitektur Objektgraphenorganisation, um die Struktur des Client wiederzugeben und eine engere Verbindung mit den internen Knoten des Client herzustellen. Aktoren werden verwendet als Aufbaublöcke für Anwendungen, wobei jeder Aktor ein in sich abgeschlossener hierarchischer Graph von Objekten ist. Genauer gesagt sind eine Serveranwendung und eine oder mehrere zugehörige Clientanwendungen als komplementäre hierarchische Graphen von Aktoren organisiert, wobei jeder Aktorknoten auf dem Client einen entsprechenden Peer-Aktorknoten auf dem Server hat. Diejenigen Aspekte der Anwendung, die serverspezifisch sind, werden in dem Server-Aktorknoten implementiert und werden als der Quellenaktor bezeichnet. Die clientspezifischen Aspekte der Anwendung werden in dem Peer-Aktorknoten des Client implementiert und werden als der Mitgliedsaktor bezeichnet. Kommunikation zwischen den Clients und dem Server wird durchgeführt zwischen Peerknoten, so daß das Kommunikationsprotokoll und der Kontext wohldefiniert sind.
Wenn ein hierarchischer Graph mit Aktoren implementiert ist, sind die Teilbäume von Knoten innerhalb eines Aktors in einer Ausführungsform im Verhältnis zueinander privat. Separat gesicherte Laufzeitumgebungen (die manchmal auch als Sicherheits-"Sandkästen" bezeichnet werden) können verwendet werden, um die Ausführung von Objektcode zu unterstützen, der zu Aktorteilbäumen gehört, und dadurch beispielsweise verhindern, daß ein Teilbaum den Speicherraum eines anderen verletzt. Objektknoten und Daten werden deshalb privat gehalten, mit Ausnahme dort, wo durch eine geeignete Schnittstelle ein autorisierter Zugriff gewährt wird.
Zu externen und oftmals fernliegenden Anwendungen können einer oder mehrere Quellenaktoren in dem Client-Serversystem gehören. Ein Verteilungsmanager-Aktor stellt eine sichere Schnittstelle zwischen einer externen Anwendung und den entsprechenden Quellenaktoren in dem Server bereit. Die sichere Schnittstelle weist Mechanismen für das Anbringen der externen Anwendung an dem Quellenaktor (den Aktoren) in dem Server und für das Lösen von diesen, ebenso wie für das Aktualisieren und Wiedergewinnen von Daten von dem Quellenaktor (den Quellenaktoren).
In einer Ausführungsform ist der hierarchische Graph ein gerichteter azyklischer Graph, wie z.B. ein Scenegraph. Knoten der Client- und Servergraphen können aktive Knoten umfassen, die wie Scenegraphelemente funktionieren (z.B. Verzweigungsgruppenknoten), jedoch mit weiteren Kontrollfunktionen. Jeder aktive Knoten in dem Servergraphen ist mit seinem Peer in dem kleinen Graphen verbunden und kann auch mit anderen Ressourcen verbunden werden, wie z.B. einer externen Medienquelle. Zum Beispiel sind Zugriffssteuerknoten Verzweigungsgruppenknoten, die festlegen, ob und unter welchen Bedingungen der Teilgraph unter ihnen in der Hierarchie sichtbar oder auf andere Weise für den Benutzer zugänglich ist. Im Verlauf dieser Feststellung kann ein Zugriffssteuerknoten über den auf dem Server residierenden Peerknoten mit Datenbanken oder anderen Ressourcen auf der Serverseite in Wechselwirkung treten. Im allgemeinen befassen aktive Knoten sich selbst mit dem Abschnitt des Aktorgraphen an oder unterhalb ihres Anbringungspunktes. Während aktive Knoten auf dem Client typischerweise Informationen und Funktionen enthalten, die allein dem Client und seinem Benutzer gewidmet sind, enthalten aktive Knoten auf dem Server Informationen und Funktionen, die an alle Clients gerichtet sind, für welche ein entsprechender Peerknoten implementiert ist.
Beispiel eines Medienanwendungsgraphen
2 ist ein Blockdiagramm eines hierarchischen Graphen gemäß einer Ausführungsform der Erfindung. Auch wenn dies nachstehend unter Bezug auf Anwendungsbeispiele auf Medienbasis beschrieben wird, ist es offensichtlich, daß die beschriebenen Techniken in ähnlicher Weise auf jegliches Client-Server-Anwendungsmodell angewendet werden können. Der Graph nach 2 kann eine vollständige Anwendung von der Server- oder Clientseite wiedergeben oder kann einen einzelnen Aktor repräsentieren. Jeder Knoten in dem Graph kann eines oder mehrere Objekte aufweisen. Links zwischen Knoten werden beispielsweise mit einem oder mehreren Zeigern oder Referenzen auf Objekte innerhalb der jeweiligen Knoten implementiert, ebenso wie eine definierte Schnittstelle oder ein Protokoll, durch welches die verknüpften Knoten kommunizieren können. Ein möglicher Mechanismus für die Bereitstellung eines Link besteht darin, eine "addChild()"-Methode ("Tochter()hinzufügen") aufzurufen, wie es zuvor für Scenegraphs beschrieben wurde, obwohl Ausführungsformen der Erfindung nicht auf diesen Mechanismus beschränkt sind.
Soweit verknüpfte Knoten in getrennten Laufzeitumgebungen existieren, kann ein entfernter Prozedurenaufruf (RPC), wie z.B. ein Fernmethodenaufruf-Mechanismus von Java^TM oder ein anderes Nachrichtentransportschema verwendet werden, einschließlich der Übermittlung von Nachrichten als Objekte (beispielsweise unter Verwendung der JavaSpaces^TM-Technologie, welche von Sun Microsystems^TM, Inc., entwickelt wurde). Die JavaSpaces-Technologien stellen einen Objektregistrierungsmechanismus bereit, durch welchen Nachrichten, die innerhalb von seriellen Objekten eingekapselt sind, durch den Client (oder Server) vorgebracht werden können und auf welche durch den Server (oder Client) zugegriffen werden kann und die durch diesen (diese) gelesen werden können. Ausführungsformen der Erfindung können den Vorteil aus vorhandenen Middleware-Systemen für entfernte Kommunikationen ziehen.
In 2 weist der hierarchische Graph der Anwendung den Wurzelknoten 200 auf, der mit dem Gruppenzugriffssteuerknoten 201 verknüpft ist, welcher seinerseits mit Gruppenpositionssteuerknoten 202 und 203 verknüpft ist. Der Gruppenpositionssteuerknoten 202 ist mit den Gruppenressourcenmanagerknoten 204 und 205 verknüpft. Der Gruppenressourcenmanagerknoten 204 ist mit dem Formblatt 206, dem interaktiven Verhaltensblatt 207 und dem Medienzugriffsblatt 208 verknüpft, während der Gruppenressourcenmanagerknoten 205 mit dem Audioblatt 209 und dem Medienzugriffsblatt 210 verknüpft ist. Der Gruppenpositionssteuerknoten 203 ist mit dem Gruppenzugriffssteuerknoten 211 verbunden, welcher seinerseits mit einem Fensterblatt 212 und dem interaktiven Verhaltensblatt 213 verknüpft ist. Wie dargestellt, repräsentiert der Wurzelknoten 200 die höchste Ebene oder Spitze des hierarchischen Graphen, wobei die Blattknoten (z.B. 206–210, 212–213) den Boden bzw. unteren Teil repräsentieren. Ein Durchlaufen des Baumes wird ausgelöst von der Ebene des Wurzelknotens.
Die Gruppenzugriffssteuerknoten 201 und 211 repräsentieren Sicherheitspunkte in dem Graphen, wo ein Zugriff auf die Knoten unterhalb des jeweiligen Zugriffsknotens nur unter speziell angegebenen Bedingungen zulässig ist. Beispielsweise könnte in einer Kabelprogrammieranwendung der Gruppenzugriffsknoten 201 verwendet werden, um den Zugriff auf die allgemeine Kabelprogrammierung zu bestimmen, wie z.B. eine lokale Netzwerkprogrammierung, etc. Der Gruppenzugriffsknoten 211 könnte dann verwendet werden, um Zugriff auf eine mehr privilegierte Programmierung zu gewähren, wie z.B. auf Pay-per-view- oder Premiumkanäle. Zugriff auf die darunterliegenden Knoten ist nur für diejenigen Clients erlaubt, welche die Zugriffsbedingungen für diesen Zugriffsknoten erfüllen. Mit dieser Konfiguration müssen für den Zugriff auf die Knoten 202–210 die Bedingungen des Zugriffsknotens 201 erfüllt werden, während für den Zugriff auf die Knoten 211–213 die Bedingungen sowohl für den Zugriffsknoten 201 als auch für den Zugriffsknoten 211 erfüllt sein müssen. Demnach können verschiedene Niveaus des sicheren Zugriffs implementiert werden.
In einer möglichen Ausführungsform enthalten die Serverabschnitte der Gruppenzugriffsknoten 201 und 211 die Bedingungen, unter welchen der jeweilige Zugriff zu den darunterliegenden Knoten gewährt wird, während jeder entsprechende Clientbereich die notwendige Information oder den Eingangsmechanismus zum Erfüllen der Bedingung enthält. In diesem Fall könnte der Serverabschnitt eine Liste von Clientkennungen enthalten, welche diejenigen Clients angeben, für welche ein allgemeiner Kabelzugriffsanschluß gewährt worden ist (Knoten 201), oder für welche ein Premiumzugriff bestätigt worden ist (211). Der Clientbereich könnte die Clientkennung enthalten, die zu der Liste des Servers paßt (Knoten 201 und 211), oder im Fall des Pay-per-view (Bezahlen für das jeweils Gesehene) den Clientcode für das Bereitstellen einer Benutzerschnittstelle für die Eingabe eines Paßworts und von Kreditkarteninformation (Knoten 211).
Die Gruppenpositionssteuerknoten 202 und 203 weisen Objekte zum Verwalten der Basisposition von Medieneinheiten (z.B. Fenster, 2D- oder 3D-Objekte, Avatars, etc.) auf, deren Eigenschaften in den darunterliegenden Knoten verkörpert sind. Jegliche weiteren darunterliegenden Positionieraktivitäten oder Positionssteuerknoten würden zu der Position (beispielsweise im 3D-Raum) aufgerufen werden, welche durch den Gruppenpositionssteuerknoten der höheren Ebene spezifiziert wird. Auf der Serverseite könnte ein Positionssteuerknoten mit einem Positionierprogramm ausgestaltet sein, welches Positionsaktualisierungen auf Zeitbasis beschreibt, die an den Positionssteuerknoten auf der Seite des Client gesendet werden, um einen Anzeigeherstellungsvorgang zu modifizieren, oder sie könnte mit Methoden zum Reagieren auf Positionssteuersignale ausgestattet sein, welche von der Seite des Client, beispielsweise in Reaktion auf eine Benutzereingabe, gesendet werden.
Die Gruppenressourcenmanagerknoten 204 und 205 stellen gemeinsame Punkte bereit, von welchen aus die darunterliegenden Medienblattknoten verknüpft bzw. verlinkt sind. Die Knoten 204 und 205 können Medienfunktionen implementieren, die sich auf die darunterliegenden Knoten beziehen, oder die Knoten 204 und 205 können einfach grundlegende Graphendurchlauffunktionen bereitstellen.
Die Blattknoten 206–210 und 212–213 repräsentieren die unterste Schicht bzw. Ebene des Anwendungsgraphen. Für das beschriebene Beispiel der Medienanwendung spezifiziert der Formblattknoten 206 die geometrische Form des Medienelementes, welches zu dem Gruppenmanager 204 der "Mutter" (bzw. der "Eltern") gehört. Das Medienzugangsblatt 208 (und ebenso das Blatt 210) enthält beispielsweise Objekte für die Bereitstellung der Eingabe oder Ausgabe von Medien, wie z.B. eines Videostroms. Das Blatt 207 für interaktives Verhalten (und in ähnlicher Weise auch der Blattknoten 213) kapselt Objekte ein für die Schnittstellenbildung zu dem Benutzer und für das Reagieren auf Benutzereingaben bezüglich der zu dem Knoten 204 gehörigen Medienelemente. Das Audioblatt 209 kapselt Objekte ein, um die Eingabe und/oder die Ausgabe von Audioinhalten in den Kontext des Mutterknotens 205 zu verwalten. Das Fensterblatt 212 kapselt in ähnlicher Weise Objekte ein für das Verwalten eines Fensterelementes des Kontextes des Mutterknotens 211.
Wie oben erläutert, stellt die hierarchische Organisation von Anwendungselementen oder "Aktoren" einen klaren Kontext für jeden Aktor auf der Basis der jeweiligen Position in dem Baum bereit. Es ist auch möglich, Anwendungen durch Hinzufügung von Knoten oder Teilbäu men zu dem Graphen an geeigneten Verbindungsknoten zu erweitern, beruhend auf dem gewünschten Kontext des Teilbaumes. Da der Kontext durch die Position in dem Baum bereitgestellt wird, können Knoten zu jeder Zeit, auch zur Laufzeit, hinzugefügt werden, ohne die aktuellen Knoten zu stören und ohne eine getrennte Bestimmung eines neuen Kontextes für den bzw. die hinzugefügten Knoten zu erfordern. In Ausführungsformen der Erfindung werden die Kontextvorteile einer hierarchischen Organisation weiterhin auf den Client-Server-Aufbau und die Kommunikation angewendet.
Komplementäre Server- und Clientgraphen
3 ist ein Blockdiagramm einer beispielhaften Client-Server-Anwendung, welche komplementäre Graphen von Aktoren gemäß einer oder mehreren Ausführungsformen der Erfindung aufweist. Die Anwendung weist eine Serverkomponente 300 und eine oder mehrere Clientkomponenten (z.B. 301A und 301B) auf. Die Server- und Clientkomponenten weisen jeweils einen hierarchischen Graphen von Aktoren auf, wobei jede Clientkomponente zu einem Teilbaum der Serverkomponente komplementär ist.
In 3 weist die Serverkomponente 300 den Serverwurzelknoten 302S auf, welcher mit dem Gruppenaktor 303S verlinkt ist. Der Gruppenaktor 303S wirkt als der Gruppenressourcenknoten, von welchem die primären Medienquellen dieses Beispiels (d.h. der Aktor 304S der Quelle A, der Aktor 305S der Quelle C und der Aktor 306S der Quelle B) verknüpft (verlinkt) sind. Der Aktor 304S der Quelle A und der Aktor 306S der Quelle B sind mit dem Aktor 307S einer Teilquelle A bzw. dem Aktor 308S einer Teilquelle B verknüpft.
In diesem Beispiel befaßt sich der Client 301A nur mit den Medien, die durch die Quelle A, die Teilquelle A und die Quelle C bereitgestellt werden. Aktoren, die zu der Quelle B und der Teilquelle B gehören, sind daher nicht notwendig für die Funktion des Client 301A und können fortgelassen werden. Ansonsten spiegelt der Client 301A den Baum von Aktoren wieder, welcher durch den Server 300 präsentiert wird. Die Clientkomponente 301A weist einen Client-Wurzelknoten 302A auf, der mit dem Gruppenaktor 303A verknüpft ist. Der Gruppenaktor 303A ist mit dem Aktor 304A des Mitgliedes A und dem Aktor 305A des Mitgliedes C verknüpft. Der Aktor 304A des Mitgliedes A ist weiterhin mit dem Aktor 307A des Teilmitgliedes A verknüpft. Wie zuvor erwähnt, ist ein Mitgliedsaktor die Version der Aktorkomponente, die auf dem Client residiert und der Sourceaktor (Quellaktor) ist die Version der Aktorkomponente, die auf dem Server residiert, so daß die Baumaktoren auf dem Client die Baumaktoren auf dem Server wiederspiegeln.
Anders als der Client 301A ist der Client 301B mit der Quelle B, der Teilquelle B und der Quelle C befaßt, jedoch nicht mit der Quelle A oder der Teilquelle A. Daher weist der Aktorenbaum der Clientkomponente 301B den Client-Wurzelknoten 302B auf, der mit dem Gruppenaktor 303B verknüpft ist. Der Gruppenaktor 303B ist mit dem Aktor 306B des Mitgliedes B und dem Aktor 305B des Mitgliedes C verknüpft. Der Aktor 306B des Mitgliedes B ist weiterhin mit dem Aktor 308B des Teilmitgliedes B verknüpft.
In einer Ausführungsform ist jeder Aktor innerhalb einer Clientkomponente mit seinem entsprechenden komplementären Aktor in der Serverkomponente verknüpft. Durch Verteilen der Client-Server-Kommunikationsschnittstelle auf Aktorenniveau erreicht man eine besser gerichtete bzw. direktere Kommunikation. Es ist nicht erforderlich, das Zielobjekt oder den Kontext für Nachrichten zu bestimmen, die zwischen dem Client und dem Server gesendet werden. Alle Nachrichten werden direkt an den Teil des Objektknotens bereitgestellt, der dafür ausgelegt ist, die Kommunikation zu handhaben bzw. zu bearbeiten. Beispielsweise kann in der beschriebenen Medienanwendung ein Quellenaktor bei dem Server so ausgestaltet sein, daß er Medieninhalt erhält und den Medieninhalt direkt an den entsprechenden Aktor bei dem Client weiterleitet, welcher dann in der Lage ist, in effektiver Weise den Medieninhalt zu erstellen. Dadurch erzielt man eine effizientere Client-Server-Interaktion.
Wie in 3 dargestellt, können Beispiele möglicher Aktoren Quell- und Teilquellenaktoren umfassen. Diese können Inhalt oder Medieneingabe- und/oder Ausgabeelemente enthalten, die Inhalt von anderen ferngelegenen Anwendungseinheiten erhalten oder an diese senden, welche als "Verteilungsquellen" und "Verteilungsteilquellen" bezeichnet werden, die mit der Serveranwendungskomponente verknüpft sind. Ein Beispiel einer Verteilungsquelle kann eine Netzwerkeinheit sein, die Medieninhalt, wie z.B. Video- oder Audiodaten für die Serverkomponente eines Kabelprogramms oder für eine Pay-per-view-Anwendung bereitstellt. Eine Verteilungsteilquelle kann daher beispielsweise die Quelle einer Sponsoranzeige sein, die zu der primären Quelle gehört, mit welcher sie verknüpft ist.
Entfernte Verteilungsquellen und -teilquellen
4 ist ein Blockdiagramm einer Client-Server-Umgebung mit Verteilungsquellen und -teilquellen gemäß einer oder mehreren Ausführungsformen der Erfindung. Wie dargestellt, ist eine Serverkomponente 400 mit einer oder mehreren (1–N) Clientkomponenten 401 und einer oder mehreren (1–M) Verteilungsquellen 402 verknüpft. Jede Verteilungsquelle kann auch durch eine oder mehrere (1–K) Teilquellen 403 bedient werden (die hier mit der Verteilungsquelle 1 verknüpft dargestellt sind).
Der von jeder Verfeilungsteilquelle bereitgestellte Inhalt wird mit dem Inhalt ihrer jeweiligen Mutterverteilungsquelle zusammengesetzt, so daß eine Versorgung bzw. eine Quelle mit eingebettetem Inhalt in transparenter Weise für die Serverkomponente 400 implementiert werden kann, ebenso wie irgendwelche weiteren Verteilungsquellen, die in der Verteilungshierarchie höher angeordnet sind. Das heißt, eine Mutterverteilungsquelle weiß von ihrer Tochterverteilungsteilquelle, jedoch weiß für einige Ausführungsformen die Mutter nichts von der Existenz irgendwelcher "Enkel"-Verteilungsteilquellen unterhalb des Niveaus ihrer Tochterteilquelle.
In einer oder mehreren Ausführungsformen werden Anwendungssicherheitsregeln und Betriebsgrenzen, die manchmal auch als Sicherheits"sandkästen" bezeichnet werden, auf jeder Ebene in der Verteilungsquellenhierarchie definiert, so daß jede Mutterverteilungsquelle/Teilquelle (ebenso wie die Serverkomponente 400) daran gehindert wird, den speziellen Inhalt, der von den Verteilungsteilquellen, die in der Verteilungshierarchie weiter unten angeordnet sind, absichtlich oder unabsichtlich zu stören oder mit dem Betrieb der weiter unten liegenden Verteilungsquellen/Teilquellen in Konflikt zu geraten. Verteilungsquellen und -teilquellen können deshalb hinsichtlich der Qualität und Genauigkeit ihres jeweiligen Inhaltes sicher sein, wenn dieser Inhalt schließlich über die Serverkomponente 400 an einen oder mehrere Clients 401 bereitgestellt wird.
Es wird ein komplementärer Mechanismus bereitgestellt, durch welchen die Verteilungsquelle 402 der obersten Ebene mit dem entsprechenden Aktor der Verteilungsquelle in der Serverkomponente 400 in Wechselwirkung treten kann. Derselbe oder ein ähnlicher Mechanismus kann verwendet werden durch Verteilungsteilquellen, um mit einem entsprechenden Aktor in einer entsprechenden Mutterverteilungsquelle zu agieren.
5 ist ein Blockdiagramm, welches eine beispielhafte Verteilungshierarchie veranschaulicht, die einen komplementären Verknüpfungsmechanismus gemäß einer oder mehrerer Ausführungsformen der Erfindung verwendet. Zur Vereinfachung der Diskussion weist die Server-Client-Anwendung einen einzelnen Provideraktor auf, von welchem aus die Verteilungshierarchie an die Anwendung angeschlossen ist. Es liegt auf der Hand, daß wesentlich komplexere Anwendungen unter Verwendung der selben oder ähnlicher Techniken, wie sie in dem Beispiel der 5 dargestellt sind, konstruiert werden können.
Gemäß 5 besteht die Verteilungshierarchie aus einer Verteilungsquelle 501, die mit einer Serverkomponente 500 und Verteilungsteilquellen A und B (502A bzw. 502B) verknüpft sind. Die Serverkomponente 500 weist einen Serverwurzelknoten 503 auf, der mit dem Provideraktor 504 verbunden ist. Der Provideraktor 504 ist mit dem Quellenaktor 505A verbunden, welcher seinerseits mit einem Aktor 506 der Teilquelle A und einem Aktor 507A der Teilquelle B verbunden ist. Ein weiterer Aktor in dem Baum der Serverkomponente ist der Verteilungsmanageraktor 508, der eine sichere Schnittstelle zu dem Quellenaktor 505A und dessen Töchtern (Aktoren 506A und 507A) bereitstellt, und der als ein Verteilungswurzelknoten in dem Teilbaum der Server-Client-Anwendung wirkt, die dem von der primären Verteilungsquelle 501 verteilten Inhalt gewidmet ist.
Die Verteilungsquelle 501 weist einen Aktorenbaum auf, der dem Verteilungsteilbaum in der Serverkomponente 500 entspricht. Insbesondere ist ein Verteilerwurzelknoten 509 mit dem Quellenaktor 505B verbunden, welcher seinerseits mit dem Aktor 506B der Teilquelle A und dem Aktor 507B der Teilquelle B verknüpft ist. Der Verteilerwurzelknoten 509 ist außerdem mit dem Verteilungsmanageraktor 508 der Serverkomponente 500 verknüpft. Um als ein Verteilungswurzelknoten für die Teilbäume zu wirken, welche die nächste Schicht bzw. Ebene in der Verteilungsquellenhierarchie repräsentieren (in diesem Beispiel die unterste Schicht), und um eine sichere Schnittstelle für den Aktor 506B der Teilquelle A und den Aktor 507B der Teilquelle B bereitzustellen, ist in der Verteilungsquelle 501 ein Verteilungsmanageraktor 510 vorhanden.
Die Verteilungsteilquelle A (502A) weist einen Verteilungswurzelknoten 511 auf, der mit dem Verteilungsmanageraktor 510 verbunden ist, ebenso wie einen Aktor 506C der Teilquelle A, der als ein Tochterknoten mit dem Verteilungswurzelknoten 511 verbunden ist. In ähnlicher Weise weist die Verteilungsteilquelle B (502B) einen Verteilerwurzelknoten 512 auf, der mit dem Verteilungsmanageraktor 510 verknüpft ist, ebenso wie einen Aktor 507C der Teilquelle B, der als ein Tochterknoten mit dem Verteilerwurzelknoten 512 verknüpft ist.
Auf jeder Ebene in der Verteilungskette ist ein entsprechender Verteilungsmanager (z.B. der Manager 510) so ausgestaltet, daß er eine sichere Schnittstelle mit Mechanismen zum Anbringen und Abtrennen lokaler Teilquellen-/Quellen-Aktoren (beispielsweise dem Teilquellenaktor 507B) von dem Mutterbaum bereitstellt, ebenso wie er das Aktualisieren und Holen von Daten zwischen der dem entfernten Teilquellen-/Quellen-Aktor (beispielsweise dem Teilaktor 507C der Teilquelle B) und dem entsprechenden lokalen Teilquellen-/Quellen-Aktor (z.B. Aktor 507B) ermöglicht bzw. erleichtert. Im Verein mit lokalen Verteilungsmanagern werden also komplementäre Aktorenbäume innerhalb des Verteilungsschemas auf jedem Quellenniveau verwendet, um das Senden/Aktualisieren von Medieninhalten zu implementieren, ebenso wie die entfernte Verwaltung der lokalen Verteilungsquellenaktoren bereitzustellen.
Ausführungsform einer Verarbeitungsumgebung
Eine Ausführungsform der Erfindung ist auf verteilte Anwendungen gerichtet, wenn auch nicht darauf beschränkt, wie z.B. diejenigen, in welchen eine Serveranwendung eine oder mehrere Clientanwendungen bedient. Derartige Systeme können unter Verwendung von objektorientierten Programmierumgebungen implementiert werden, welche ausführbare Softwareobjekte erzeugen. Um eine Objektkompatibilität zwischen dem Client und dem Server zu ermöglichen, können die Softwareobjekte in einer plattformunabhängigen Weise implementiert sein, oder die Client- und Serversysteme können gemeinsame oder kompatible Betriebssystemplattformen gemeinsam verwenden. Die Clients und Server können in Laufzeitumgebungen einer getrennten Maschine oder virtuellen Maschine ausgeführt werden. Die folgende Beschreibung bezieht sich auf eine Ausführungsform einer Laufzeitumgebung auf Basis einer virtuellen Maschine, obwohl es auf der Hand liegt, daß die Erfindung nicht darauf beschränkt ist.
Anwendungen weisen typischerweise einen oder mehrere Objektklassen auf. Klassen, die in höheren Programmiersprachen geschrieben sind, wie z.B. der Java^TM-Programmiersprache, können in maschinenunabhängige Klassendateien in Bytecode kompiliert werden. Alternativ können Klassen in maschinenabhängigen, ausführbaren Programmcode umgewandelt werden durch eine gegebene Art der Plattform. Im maschinenunabhängigen Fall enthält jede Klassendatei Code und Daten in einem plattformunabhängigen Format, welches als das Klassendateiformat bezeichnet wird. Das Computersystem, welches als das Ausführungsmittel wirkt, enthält ein Programm, welches eine virtuelle Maschine genannt wird, die für das Ausführen des Codes in jeder Klassendatei verantwortlich ist. (Ein Hardwaresystem könnte ebenfalls verwendet werden, welches Bytecode direkt aus Klassendateien ausführt.)
In der Umgebung einer virtuellen Maschine werden die Klassen einer Anwendung auf Anforderung von dem Netzwerk geladen (auf einem Server gespeichert) oder von einem lokalen Dateisystem geladen, wenn sie erstmalig während der Ausführung der Anwendung aufgerufen werden. Die virtuelle Maschine lokalisiert und lädt jede Klassendatei, analysiert das Format der Klassendatei, weist Speicher für die verschiedenen Komponenten der Klasse zu und verknüpft die Klasse mit anderen, bereits geladenen Klassen. Dieser Prozeß macht den Code in der Klasse in einfacher Weise durch die virtuelle Maschine ausführbar.
6 veranschaulicht die Kompilierungs- und Laufzeitumgebungen für ein beispielhaftes Verarbeitungssystem. In der Kompilierungsumgebung erzeugt ein Softwareentwickler Quelldateien 600, die für einen Programmierer lesbare Klassendefinitionen enthalten, die in der Sprache der Quellprogrammierung geschrieben sind, einschließlich Datenstrukturen, Methoden implementierungen und Hinweisen auf bzw. Aufrufe von anderen Klassen. Quelldateien 600 werden für den Vorcompiler 601 bereitgestellt, welcher die Quelldateien 600 in "Klassen"-Dateien 602 kompiliert, die Bytecodes enthalten, welche durch eine virtuelle Maschine ausführbar sind. Die Bytecode-Klassendateien 602 werden auf einem Server gespeichert (beispielsweise in einem temporären oder dauerhaften Speicher) und sind für das Herunterladen über ein Netzwerk verfügbar. Alternativ können die Bytecode-Klassendateien 602 lokal in einem Verzeichnis auf der Clientplattform gespeichert werden.
Die Laufzeitumgebung enthält eine virtuelle Maschine (VM) 605, die in der Lage ist, Bytecode-Klassendateien auszuführen und native Betriebssystem- ("O/S") Aufrufe an das Betriebssystem 609 auszuführen, wenn dies während der Ausführung notwendig ist. Die virtuelle Maschine 605 stellt ein Abstraktionsniveau zwischen der Maschinenunabhängigkeit der Bytecodeklassen und dem maschinenabhängigen Befehlssatz der darunterliegenden Computerhardware 610 bereit, ebenso wie zu den plattformabhängigen Aufrufen des Betriebssystems 609.
Der Klassenlader und Bytecodeverifizierer ("Klassenlader") 603 ist für das Laden der Bytecodeklassendateien 602 und für das Unterstützen von Klassenbibliotheken 604 in der virtuellen Maschine 605 verantwortlich, soweit dies erforderlich ist. Der Klassenlader 603 verifiziert auch die Bytecodes jeder Klassendatei, um eine ordnungsgemäße Ausführung und Durchsetzung von Sicherheitsregeln zu gewährleisten. Innerhalb des Kontextes des Laufzeitsystems 608 führt entweder ein Übersetzer 606 die Bytecodes direkt aus, oder ein "just-in-time"- (JIT) Compiler 607 transformiert die Bytecodes in Maschinencode, so daß sie durch den Prozessor (oder Prozessoren) in der Hardware 610 ausgeführt werden können.
Das Laufzeitsystem 608 der virtuellen Maschine 605 unterstützt eine allgemeine Stapelarchitektur. Die Art und Weise, in welcher diese allgemeine Stapelarchitektur durch die zugrundeliegende Hardware 610 unterstützt wird, wird durch die spezielle Implementierung der virtuellen Maschine festgelegt und in der Art und Weise reflektiert, wie die Bytecodes interpretiert oder JIT-kompiliert werden. Andere Elemente des Laufzeitsystems umfassen "Thread"-Verwaltung (z.B. Planung) und Abfallsammelmechanismen.
Ausführungsform einer Comguterausführunosumgebung (Hardware)
Eine Ausführungsform der Erfindung kann als Computersoftware in Form von computerlesbarem Code implementiert werden, der auf irgendeiner Computerverarbeitungsplattform ausgeführt wird oder in Form von Software (z.B. Bytecodeklassendateien), der in einer Lauf zeitumgebung ausführbar ist, die auf einer derartigen Verarbeitungsplattform abläuft. Eine Ausführungsform der Erfindung kann in irgendeiner Art von Computersystem oder Programmierung oder Verarbeitungsumgebung einschließlich eingebetteter Einrichtungen (z.B. Web-Telefone, Set-Top-Boxen, etc.) und "abgespeckten" bzw. "dünnen" Client-Verarbeitungsumgebungen (z.B. Netzwerkcomputern (NCs), etc.) implementiert werden. Ein Beispiel eines allgemeinen Computersystems ist in 7 dargestellt. Das nachstehend beschriebene Computersystem dient hier lediglich als Beispiel.
In 7 sind eine Tastatur 710 und eine Maus 711 mit einem Systembus 718 verbunden. Die Tastatur und die Maus dienen der Einbringung von Benutzereingaben in das Computersystem und der Kommunikation der Benutzereingabe in den Prozessor 713. Zusätzlich zu oder anstelle der Maus 711 und der Tastatur 710 können auch andere geeignete Eingabeeinrichtungen verwendet werden. Die I/O- (Eingabe-/Ausgabe-) Einheit 719, die mit dem Systembus 718 verbunden ist, repräsentiert solche I/O-Elemente wie z.B. einen Drucker, AN (Audio/Video), I/O, etc.
Der Computer 700 enthält einen Videospeicher 714, einen Hauptspeicher 715 und einen Massenspeicher 712, die allesamt gemeinsam mit der Tastatur 710, der Maus 711 und dem Prozessor 713, mit dem Systembus 718 verbunden sind. Der Massenspeicher 712 kann sowohl feste als auch herausnehmbare Medien, wie z.B. magnetische, optische oder magnetooptische Speichersysteme oder andere verfügbare Massenspeichertechnologie aufweisen. Der Bus 718 kann beispielsweise Adreßleitungen zum Adressieren des Videospeichers 714 und des Hauptspeichers 715 enthalten. Der Systembus 718 enthält beispielsweise auch einen Datenbus zum Übertragen von Daten zwischen den Komponenten und über die Komponenten, wie z.B. den Prozessor 713, den Hauptspeicher 715, den Videospeicher 714 und den Massenspeicher 712. Alternativ können Daten/Adreß-Leitungen auch im Multiplexbetrieb verwendet werden in Form von getrennten Daten- und Adreß-Leitungen.
In einer Ausführungsform der Erfindung ist der Prozessor 713 ein SPARC^TM-Mikroprozessor von Sun Microsystems, Inc., oder ein von Intel hergestellter Mikroprozessor, wie z.B. der 80X86, oder ein Pentium-Prozessor oder ein von Motorola hergestellter Mikroprozessor, wie z.B. der 680X0-Prozessor. Es kann jedoch auch jeglicher andere geeignete Mikroprozessor oder Mikrocomputer verwendet werden. Der Hauptspeicher 715 besteht aus einem dynamischen Speicher mit wahlfreiem Zugriff (DRAM). Der Videospeicher 714 ist ein Videospeicher mit wahlfreiem Zugriff mit zwei Anschlüssen (Ports). Ein Anschluß des Videospeichers 714 ist mit dem Videoverstärker 716 verbunden. Der Videoverstärker 716 wird verwendet, um die Kathodenstrahlröhre (CRT) eines Rastermonitors 717 anzusteuern. Der Videoverstärker ist im Stand der Technik wohlbekannt und kann durch irgendeine geeignete Vorrichtung implementiert werden. Diese Schaltung wandelt Pixeldaten, die in dem Videospeicher 714 gespeichert sind, in ein Rastersignal um, welches für die Verwendung durch den Monitor 717 geeignet ist. Der Monitor 717 ist eine Art von Monitor, der für die Darstellung von graphischen Bildern geeignet ist. Alternativ könnte der Videospeicher auch verwendet werden, um eine flache Anzeigetafel oder ein Flüssigkristalldisplay (LCD) oder irgendeine andere geeignete Datenpräsentationseinrichtung anzusteuern.
Der Computer 700 kann auch eine Kommunikationsschnittstelle 720 aufweisen, die mit dem Bus 718 verbunden ist. Die Kommunikationsschnittstelle 720 bietet eine 2-Wege-Datenkommunikationsverbindung über eine Netzwerkverbindung 721 zu einem lokalen Netzwerk 722. Wenn beispielsweise die Kommunikationsschnittstelle 720 eine ISDN-Karte (Integrated Services Digital Network) oder ein Modem ist, stellt die Kommunikationsschnittstelle 720 eine Datenkommunikationsverbindung zu dem entsprechenden Typ einer Telefonleitung bereit, die einen Teil der Netzwerkverbindung 721 aufweist bzw. bildet. Wenn die Kommunikationsschnittstelle 720 die Karte eines lokalen Netzwerkes (LAN) ist, stellt die Kommunikationsschnittstelle 720 eine Datenkommunikationsverbindung über die Netzwerkverbindung 721 mit einem kompatiblen LAN bereit. Die Kommunikationsschnittstelle 720 könnte auch ein Kabelmodem oder eine drahtlose Schnittstelle sein. In jeder derartigen Implementierung sendet die Kommunikationsschnittstelle 720 elektrische, elektromagnetische oder optische Signale oder empfängt diese, welche digitale Datenströme tragen, die verschiedene Typen von Information repräsentieren.
Die Netzwerkverbindung 721 stellt typischerweise eine Datenkommunikation über eines oder mehrere Netzwerke zu anderen Datengeräten bzw. Dateneinrichtungen bereit. Beispielsweise kann die Netzwerkverbindung 721 eine Verbindung über ein lokales Netzwerk 722 zu einem lokalen Servercomputer 723 oder zu einer Datenausrüstung herstellen, welche durch einen Internetserviceprovider (ISP) 724 betrieben wird. Der ISP 724 stellt seinerseits Datenverbindungsdienste über das weltweite Kommunikationsnetzwerk mit Paketdaten bereit, welches inzwischen üblicherweise als das "Internet" 725 bezeichnet wird. Das lokale Netzwerk 722 und das Internet 725 verwenden beide elektrische, elektromagnetische oder optische Signale, die digitale Datenströme tragen. Die Signale durch die verschiedenen Netzwerke und die Signale auf der Netzwerkverbindung 721 und durch die Kommunikationsschnittstelle 720, welche die digitalen Daten zu und von dem Computer 700 tragen, sind beispielhafte Formen von Trägerwellen, welche die Information transportieren.
Der Computer 700 kann Nachrichten senden und Daten empfangen, einschließlich Programmcode, und zwar durch das Netzwerk (die Netzwerke), die Netzwerkverbindung 721 und die Kommunikationsschnittstelle 720. In dem Beispiel des Internets könnte ein entfernter Servercomputer 726 einen angeforderten Code für ein Anwendungsprogramm durch das Internet 725, den ISP 724, das lokale Netzwerk 722 und die Kommunikationsschnittstelle 720 übermitteln.
Der empfangene Code kann durch den Prozessor 713 ausgeführt werden, wenn er empfangen wird, und/oder er könnte im Massenspeicher 712 oder einem anderen nichtflüchtigen Speicher für eine spätere Ausführung gespeichert werden. Auf diese Weise kann der Computer 700 Anwendungscode in Form von Trägerwellen erhalten. Anwendungscode kann in irgendeiner Form eines Computerprogrammproduktes verkörpert sein. Ein Computerprogrammprodukt weist ein Medium auf, welches dafür ausgestaltet ist, computerlesbaren Code oder Daten zu speichern oder zu transportieren, oder in welchem computerlesbarer Code oder Daten eingebettet sein können. Einige Beispiele von Computerprogrammprodukten sind CD-ROM-Platten, ROM-Karten, Disketten, Magnetbänder, Computerfestlaufwerk, Server auf einem Netzwerk und Trägerwellen.
Es ist demnach ein Verfahren und eine Vorrichtung zum Organisieren von Elementen einer Serveranwendung in einem Client-Serversystem in Verbindung mit einer oder mehreren speziellen Ausführungsformen beschrieben worden. Die Erfindung wird durch die Ansprüche definiert.

Claims

Verfahren zur Verwendung in einem Computersystem, wobei das Verfahren aufweist: Erhalten von einem oder mehreren Serveraktoren (303S, 306S, 308S, 308S), wobei ein Aktor ein unabhängiger Graph ist, Verbinden der Serveraktoren in einem ersten hierarchischen Baum (300), Erhalten von einem oder mehreren Clientaktoren (303B, 306B, 308B), welche einer Untergruppe der Serveraktoren entsprechen, und Verbinden der Clientaktoren in einem zweiten hierarchischen Baum (301B), der komplementär zu einem Unterbaum des ersten hierarchischen Baumes ist, dadurch gekennzeichnet, daß eine Serverkomponente einer Client-Server-Anwendung während der Laufzeit von den Serveraktoren gebildet wird, die in dem ersten hierarchischen Baum verbunden sind, und eine Clientkomponente der Client-Server-Anwendung während der Laufzeit von den Clientaktoren gebildet wird, die mit dem zweiten hierarchischen Baum verbunden sind.
Verfahren nach Anspruch 1, das weiterhin aufweist: Bereitstellen einer Kommunikationsschnittstelle zwischen jedem Clientaktor und jedem entsprechenden Serveraktor.
Verfahren nach Anspruch 1, bei dem jeder Aktor einen Baum aus hierarchisch verknüpften Knoten aufweist, wobei die Knoten einen oder mehrere Objekte aufweisen.
Verfahren nach Anspruch 3, bei dem die Knoten weiterhin einen oder mehrere geschachtelte Aktoren aufweisen.
Verfahren nach Anspruch 1, das weiterhin aufweist: Bereitstellen einer Schnittstelle zwischen einer Verteilungsquelle und einem der Serveraktoren für den entfernten Zugriff durch die Verteilungsquellen auf einen entsprechenden Verteilungsquellaktor innerhalb des einen Serveraktors.
Verfahren nach Anspruch 5, das weiterhin aufweist: Bereitstellen einer sicheren Laufzeitumgebung für die Verteilungsquelle.
Verfahren nach Anspruch 5, das weiterhin aufweist: die Verteilungsquelle aktualisiert den Verteilungsquellenaktor über die Schnittstelle.
Verfahren nach Anspruch 5, das weiterhin aufweist: Bereitstellen einer Schnittstelle zwischen einer Verteilungsunterquelle und der Verteilungsquelle für den entfernten Zugriff von der Verteilungsunterquelle auf einen entsprechenden Verteilungsunterquellenaktor innerhalb der Verteilungsquelle.
Computerprogrammprodukt, das aufweist: ein computerlesbares Medium mit einem Computerprogrammcode, der darin verkörpert ist, für das Organisieren von Elementen einer Client-Server-Anwendung, wobei das computerlesbare Medium einen Computerprogrammcode aufweist, der derart konfiguriert ist, daß er veranlaßt, daß ein Computer: einen oder mehrere Serveraktoren erhält, wobei ein Aktor ein unabhängiger Graph ist, die Serveraktoren in einem ersten hierarchischen Baum verknüpft, einen oder mehrere Clientaktoren entsprechend einer Untergruppe der Serveraktoren erhält und die Clientaktoren in einem zweiten hierarchischen Baum verknüpft, der komplementär zu einem Unterbaum des ersten hierarchischen Baumes ist, wobei eine Serverkomponente einer Client-Server-Anwendung während der Laufzeit von den Serveraktoren, die in dem ersten hierarchischen Baum verbunden sind, gebildet wird, und eine Clientkomponente der Client-Server-Anwendung während der Laufzeit von den Clientaktoren, die mit dem zweiten hierarchischen Baum verknüpft sind, gebildet wird.
Computerprogrammprodukt nach Anspruch 9, bei dem der Computerprogrammcode weiterhin konfiguriert ist, um einen Computer dazu zu veranlassen, eine Kommunikationsschnittstelle zwischen jedem Clientaktor und jedem entsprechenden Serveraktor bereitzustellen.
Computerprogrammprodukt nach Anspruch 9, bei dem jeder Aktor ein Baum von hierarchisch verbundenen Knoten aufweist, wobei die Knoten ein oder mehrere Objekte aufweisen.
Computerprogrammprodukt nach Anspruch 11, bei dem die Knoten weiterhin einen oder mehrere verschachtelte Aktoren aufweisen.
Computerprogrammprodukt nach Anspruch 9, bei dem der Computerprogrammcode weiterhin so konfiguriert ist, daß er einen Computer dazu veranlasst, eine Schnittstelle bereitzustellen zwischen einer Verteilungsquelle und einem der Serveraktoren für den entfernten Zugriff durch die Verteilungsquelle auf einen entsprechenden Verteilungsquellenaktor innerhalb des einen Serveraktors.
Computerprogrammprodukt nach Anspruch 13, bei dem der Computerprogrammcode weiterhin konfiguriert ist, um einen Computer dazu zu veranlassen, eine sichere Laufzeitumgebung für die Verteilungsquelle bereitzustellen.
Computerprogrammprodukt nach Anspruch 13, bei dem der Computerprogrammcode weiterhin konfiguriert ist, um einen Computer dazu zu veranlassen, der Verteilungsquelle zu ermöglichen, den Verteilungsquellenaktor über die Schnittstelle zu aktualisieren.
Computerprogrammprodukt nach Anspruch 13, bei dem der Computerprogrammcode weiter konfiguriert ist, um einen Computer dazu zu veranlassen, eine Schnittstelle bereitzustellen zwischen einer Verteilungsunterquelle und der Verteilungsquelle für den entfernten Zugriff durch die Verteilungsunterquelle auf einen entsprechenden Verteilungsunterquellenaktor innerhalb der Verteilungsquelle.
Vorrichtung, die aufweist: einen Server (726), der einen oder mehrere Serveraktoren (303S, 306S, 308S), die mit einem ersten hierarchischen Baum (300) verknüpft sind, aufweist, einen Client, der einen oder mehrere Clientaktoren (303B, 306B, 308B) aufweist, wobei ein Aktor ein unabhängiger Graph ist, welche in einem zweiten hierarchischen Baum verknüpft sind, wobei der zweite hierarchische Baum (301B) komplementär zu einer Untergruppe des ersten hierarchischen Baumes ist, und eine Kommunikationsschnittstelle, die mit einem oder mehreren der Clientaktoren verbunden ist, wobei die Kommunikationsschnittstelle jeden von dem einen oder der mehreren Clientaktoren mit einem komplementären Serveraktor verbindet, dadurch gekennzeichnet, daß eine Serverkomponente einer Client-Server-Anwendung während der Laufzeit gebildet wird aus den Serveraktoren, die mit dem ersten hierarchischen Baum verbunden sind, und eine Clientkomponente der Client-Server-Anwendung während der Laufzeit gebildet wird aus den Clientaktoren, die mit dem zweiten hierarchischen Baum verbunden sind.
Vorrichtung nach Anspruch 17, bei der jeder Aktor einen Baum aus hierarchisch verknüpften Knoten aufweist, wobei die Knoten ein oder mehrere Objekte aufweisen.
Vorrichtung nach Anspruch 18, bei der die Knoten weiterhin einen oder mehrere verschachtelte Aktoren aufweisen.
Vorrichtung nach Anspruch 17, bei der einer der Serveraktoren einen Verteilungsquellaktor aufweist, und bei der die Vorrichtung weiterhin aufweist eine entfernte Verteilungsquelle, die mit dem einen der Serveraktoren verbunden ist für den Zugriff auf den Verteilungsquellaktor.
Vorrichtung nach Anspruch 20, bei der die Verteilungsquelle innerhalb einer sicheren Laufzeitumgebung in Bezug auf den Server ausgeführt wird.
Vorrichtung nach Anspruch 20, bei der die Verteilungsquelle konfiguriert ist, so daß sie den Verteilungsquellenaktor aktualisiert.
Vorrichtung nach Anspruch 20, bei der die Verteilungsquelle weiterhin aufweist einen Verteilungsunterquellenaktor und bei der die Vorrichtung weiterhin aufweist eine entfernte Verteilungsunterquelle, die mit der Verteilungsquelle verbunden ist für den Zugriff auf den Verteilungsunterquellenaktor.
Vorrichtung nach Anspruch 23, bei der die Verteilungsunterquelle innerhalb einer sicheren Laufzeitumgebung in Bezug auf die Verteilungsquelle ausgeführt wird.
Vorrichtung nach Anspruch 23, bei der die Verteilungsunterquelle so konfiguriert ist, daß sie den Verteilungsunterquellenaktor aktualisiert.
Vorrichtung nach Anspruch 17, bei der die Aktoren so konfiguriert sind, daß sie während der Laufzeit verknüpft sind.