-
Gebiet der Erfindung
-
Die vorliegende Erfindung bezieht
sich auf die Gebiete der verteilten Rechnersysteme, der Client-Server-Datenverarbeitung
und der objekt-orientierten Programmierung. Insbesondere ist die
vorliegende Erfindung ein Verfahren und eine Einrichtung zum Bereitstellen
von Programmechanismen zum Behandeln einer Objekte einschließenden Zwischen-Client-Kommunikation,
welche unabhängig
von dem Betriebssystemkernel sind zu handhaben.
-
HINTERGRUND
-
Ein Schlüsselproblem bei der Betriebssystementwicklung
und -pflege ist das Ermöglichen
der Einführung
neuer Schnittstellen und Implementierungstechniken auf eine Weise,
welche Clients und Programmierern eine maximale Flexibilität gestattet,
ohne das Betriebssystem mit Implementierungsdetails herunterzuladen. Darüber hinaus
wird das Problem dringlicher, wenn objekt-orientierte Betriebssysteme
entwickelt werden, welche Mikro-Kernel-Architekturen aufweisen.
Mikro-Kernels ermöglichen
es typischerweise Clients, komplexe Subsysteme, wie beispielsweise
Dateisysteme, auf der Client-Ebene zu implementieren. Dennoch sind
grundlegende Systemprozesse, wie beispielsweise Zwischen-Client-
oder Zwischen-Computer-Kommunikationen, so komplex, daß Clients
und Objektimplementierer nicht mit diesen Problemen befaßt werden
sollten. D. h., diese Prozesse, die inhärent vom "System"-Typ sind,
werden effektiver von Standardmodulen ausgeführt, sollten aber auf eine
Weise gehandhabt werden, welche es nicht erfordert, daß das Basisbetriebssystem
durch diese Prozesse eingeschränkt
wird.
-
Diese Offenbarung beschreibt eine
Lösung
für dieses
grundlegende Problem für
Systeme, welche die Objektmetapher verwenden, um die Schnittstellen
zwischen verschiedenen Komponenten eines Systems zu definieren.
Eine elegante Lösung
wird beschrieben, welche es Standardmodulen gestattet, die Kommunikation von
Objektaufrufen zwischen entfernten Computern zu handhaben, welche
andere Objekte als Parameter der Aufrufe senden können.
-
Bei einem objekt-orientierten System
ist ein Objekt eine Komponente, die Daten und Operationen umfaßt, welche
aufgerufen werden können,
um die Daten zu bearbeiten. Die Operationen werden auf dem Objekt aufgerufen,
indem Aufrufe an das Objekt gesendet werden. Jedes Objekt weist
einen Objekttyp auf. Der Objekttyp definiert die Operationen, die
an den Objekten dieses Typs ausgeführt werden können. Die
Objektoperationen werden unabhängig
von den Objekten selbst implementiert. Darüber hinaus kann ein Objekttyp
die Objektoperationen erben, die für andere Objekttypen definiert
und implementiert sind. Für
eine weitergehende Beschreibung des objekt-orientierten Entwurfs
und der Programmiertechniken siehe "Object-oriented Software Construction"
von Bertrand Meyer, Prentice-Hall, 1988.
-
Bei der Client-Server-Datenverarbeitung
gibt es typischerweise einen Satz von Computern, die miteinander über ein
die Computer verbindendes Netzwerk kommunizieren können. Einige
dieser Computer dienen als Anbieter von Diensten oder von Funktionalität für andere
Computer. Die Anbieter derartiger Dienste oder einer derartigen
Funktionalität
sind als "Server" bekannt, und die Verbraucher derartiger Dienste
oder einer derartigen Funktionalität werden "Clients" genannt.
Das Client-Server-Modell umfaßt
allgemein auch den Fall, bei dem unterschiedliche Programme, die
auf dem gleichen Computer ablaufen, miteinander über irgendeinen geschützten Mechanismus
kommunizieren und als Bereitsteller und Verbraucher einer Funktionalität agieren.
-
Bei objekt-orientierten verteilten
Systemen, die auf dem Client-Server-Modell basieren, gibt es Server, die
objekt-orientierte Schnittstellen an ihre Clients bereitstellen.
Diese Server unterstützen
Objekte, die aus Daten und zugehöriger
Software bestehen. Clients können
einen Zugriff auf diese Objekte erlangen und Aufrufe auf diesen
ausführen.
Diese Aufrufe werden von dem Client an den Server gesendet. Beim
Server werden diese Aufrufe über
die dem Objekt zugeordnete Software ausgeführt. Die Ergebnisse dieser
Aufrufe werden dann zurück
zu dem Client übermittelt.
-
Die Objektmetapher ist eine nützliche
Technik, da sie eine Trennung zwischen der Schnittstelle eines Objekts
und seiner Implementierung bereitstellt, und weil sie mehrere Implementierungen
einer einzigen Schnittstelle ermöglicht,
welche sich in einem verteilten System auf unterschiedlichen Maschinen
aufhalten können.
Jedoch definiert bei vorhandenen objekt-orientierten Systemen das
Basissystem fundamentale Objekteigenschaften, wie beispielsweise,
was ein Objekt"aufruf" bedeutet, was es bedeutet, "ein Objekt als
Argument weiterzuleiten", etc.
-
Indem man es dem Basissystem überläßt zu definieren,
was die fundamentalen Eigenschaften sind, ist es unglücklicherweise
erforderlich, daß das
Basissystem all jene fundamentalen Eigenschaften unterstützt, von
denen wir wünschen,
daß die
Objekte sie aufweisen. Es sei beispielsweise angenommen, daß wir wünschen,
eine Objektreplikation so zu unterstützen, daß die Zuverlässigkeit
erhöht
wird. Es ist für
den Client-Anwendungscode nicht wünschenswert, daß er eine
zusätzliche
Arbeit ausführt,
um mit replizierten Objekten zu sprechen. Folglich wäre es vorzuziehen,
eine Replikation durch das System zu unterstützen. Aber es gibt eine Vielzahl
von Wegen zum Implementieren einer Replikation. Die Frage ist, ob
jemand einige dieser Wege in das Basissystem einbaut und die anderen
zurückweist.
Wenn ein Anwendungsentwickler einen effektiveren Weg der Verwaltung
replizierter Objekte innerhalb seiner Anwendung entdeckt, wäre es für ihn wünschenswert,
in der Lage zu sein, seinen neuen Mechanismus zu benutzen, ohne
den Basismechanismus ändern
zu müssen. Während das
Basissystem verwendet werden könnte,
um irgendwelche Standardbasismechanismen für bestimmte Eigenschaften,
wie beispielsweise Replikation, Beharrlichkeit, Absturz, Wiederherstellung
und Caching, zu unterstützen,
scheint dies zwei Gefahren hervorzurufen. Erstens kann es einen
einfachen Objektaufruf aufwendig machen, selbst für diejenigen
Objekte, die die aufwendigen Eigenschaften nicht wünschen. Zweitens
macht es es für
Dritte schwierig, neue Eigenschaften hinzuzufügen, die ihren speziellen Anforderungen
genügen.
-
Dementsprechend ist ein Verfahren
erforderlich, um die Kontrolle der Basismechanismen des Objektaufrufs
und der Argumentweiterleitung, die in verteilten Systemen am wichtigsten
sind, bereitzustellen, wobei das Verfahren durch irgendeine Anordnung
implementiert wird, welche getrennt von den Objektschnittstellen und
Objektimplementierungen ist.
-
Techniken zum Bereitsstellen einer
sprachlichen Auskleidung für
Fernoperationen (beispielsweise "Fernprozeduraufrufe") sind seit
vielen Jahren in Benutzung. Typischerweise nehmen diese die Form
an, daß eine
ferne Schnittstelle in irgendeine Sprache definiert ist. Dann wird
ein Paar von Stümpfen
(stubs) aus dieser Schnittstelle erzeugt. Der Client-Stumpf (client
stub) läuft
in einer Maschine und präsentiert
eine Schnittstelle auf Sprachebene, die aus der Fernschnittstelle
(remote interface) abgeleitet ist. Der Server-Stumpf (server stub)
läuft auf
irgendeiner anderen Maschine und ruft eine Schnittstelle auf Sprachebene
auf, die aus der Fernschnittstelle abgeleitet ist. Es wird jetzt
auf 1 Bezug genommen;
um eine Fernoperation durchzuführen, ruft
eine Client- Anwendung 12 auf
eine Maschine 10 den Client-Stumpf 14 auf, welcher
die dem Aufruf zugeordneten Argumente in Netzwerkpuffer arrangiert
oder einreiht (marshals) und sie an den Server-Stumpf 22 auf
der ferner Maschinen 18 übermittelt, welcher die Argumente
aus dem Netzwerkpuffer dearrangiert oder ausreiht (unmarshals) und
die Server-Anwendung 24 aufruft. In ähnlicher Weise werden dann,
wenn die Server-Anwendung 24 eine
Antwort zurückgibt,
die Ergebnisse durch den Server-Stumpf 22 eingereiht (marshaled up)
und an den Client-Stumpf 14 zurückgegeben, welcher die Ergebnisse
ausreiht (unmarshals) und sie an die Client-Anwendung 12 zurückgibt.
Die gesamte Mechanik der Argument- und Ergebnisübermittlung und des Fernobjektaufrufs
wird in den Stümpfen
ausgeführt.
Sowohl die Client-Anwendung als auch die Server-Anwendung befassen
sich damit bloß in
Form von herkömmlichen
Schnittstellen auf Sprachebene.
-
Wenn die Argumente oder Ergebnisse
einfache Werte, wie beispielsweise ganze Zahlen oder Zeichenketten,
sind, ist das Geschäft
des Arrangierens und Dearrangierens (marshaling and unmarshaling)
ziemlich einfach. Die Stümpfe
werden normalerweise einfach den wahren Wert des Arguments in den
Netzwerkpuffer eingeben. Bei Sprachen jedoch, die entweder abstrakte
Datentypen oder Objekte unterstützen,
wird das Arrangieren signifikant komplexer. Eine Lösung besteht
für die
Stümpfe
darin, die internen Datenstrukturen des Objekts zu arrangieren und
dann diese Daten zurück
in ein neues Objekt zu dearrangieren. Dies weist verschiedene schwerwiegende
Nachteile auf. Zunächst
ist es eine Verletzung des "Abstraktions"-Prinzips der objekt-orientierten
Programmierung, da die Stümpfe
keine geschäftsmäßige Kenntnis über die
Interna der Objekte haben. Zweitens erfordert dies, daß die Server-
und die Client-Implementierungen des Objekts das gleiche interne
Layout für
ihre Datenstrukturen verwenden. Drittens kann es das Arrangieren
großer
Mengen von nicht erforderlichen Daten umfassen, da nicht sämtliche der
internen Zustände
des Objekts tatsächlich
zu der anderen Maschine übermittelt
werden müssen.
Eine alternative Lösung
besteht darin, daß dann,
wenn ein Objekt arrangiert wird, keine seiner internen Zustände übermittelt
werden. Statt dessen wird ein identifizierendes Token für das Objekt
erzeugt und dieses Token wird übermittelt.
Beispielsweise werden bei dem Eden-System den Objekten Namen zugewiesen,
und, wenn ein Objekt arrangiert wird, dann wird sein Name statt
seiner tatsächlichen
Repräsentation
arrangiert. Wenn nachfolgend ferne Maschinen es wünschen,
an diesem Objekt zu arbeiten, so müssen sie den Namen verwenden,
um die ursprüngliche
Stelle des Objekts zu lokalisieren und ihre Aufrufe an diese Stelle
zu übermitteln.
Dieser Mechanismus ist für
schwergewichtige Objekte, wie beispielsweise Dateien oder Datenbanken,
geeignet, aber ist oftmals für
leichtgewichtige Abstraktionen ungeeignet, wie beispielsweise für ein Objekt,
das ein kartesisches Koordinatenpaar repräsentiert, bei dem es besser wäre, den
realen Zustand des Objekts zu arrangieren. Schließlich liefern
einige objekt-orientierte Programmiersysteme die Mittel für eine Objektimplementierung,
um zu steuern, wie seine Argumente arrangiert und dearrangiert werden.
Beispielsweise können
bei dem Argus-System Objektimplementierer Funktionen zum Abbilden
zwischen ihrer internen Darstellung und einer speziellen konkreten
externen Darstellung bereitstellen. Die Argus-Stümpfe rufen die richtigen Abbildungsfunktionen
auf, wenn sie Objekte arrangieren und dearrangieren, so daß statt
irgendeiner bestimmten internen Darstellung die externe Darstellung übermittelt
wird. Diese abweichenden Lösungen
erfordern entweder sämtlich
eine einzige Standardarrangierpolitik für sämtliche Objekte, oder sie erfordern,
daß einzelne
Objektimplementierer die Verantwortung für die Details des Arrangierens übernehmen.
-
Innerhalb der objekt-orientierten
Sprachen gestattet die Technik der Reflexion es Objektimplementierern,
die Kontrolle über
einige der fundamentalen Objektmechanismen zu erlangen. [siehe "Reflective
Facilities in Smalltalk-80" von Brian Foote & Ralph E. Johnson, 1989, OOPSLA '89
Proceedings, Seiten 327-335]. Einfach ausgedrückt, ist ein reflektives System
eines, welches Strukturen enthält,
die Aspekte des Systems selbst repräsentieren, und eine reflektive
Berechnung ist eine Berechnung des Systems über sich selbst.
-
In der 3-KRS-Sprache beispielsweise
können
Objekte Meta-Objekte aufweisen, die ihnen zugeordnet sind. Ein Meta-Objekt
stellt Methoden bereit, die angeben, wie ein Objekt Informationen
erbt, wie ein Objekt gedruckt wird, wie Objekte erzeugt werden,
wie eine Nachrichtenweiterleitung (d. h. ein Objektaufruf) implementiert
ist, etc.. 3-KRS stellt jedoch keine Kontrolle über die Argumenteweiterleitung
zur Verfügung.
-
Durch Bereitstellen des reflektiven
Objektaufrufs in Smalltalk-80 war es möglich, Objekte zu implementieren,
welche während
des Aufrufens automatisch gesperrt wurden, und Objekte, welche nur
einen Wert berechnen, wenn sie zuerst gelesen werden.
-
Während
jedoch die Reflexion innerhalb eines einzelnen Adreßraums verwendet
wurde, gab es keinen Versuch, sie speziell auf die Probleme der
verteilten Verarbeitung anzuwenden.
-
Demzufolge schafft die vorliegende
Erfindung eine Einrichtung und ein Verfahren, die bzw. das ein Logikmodul
aufweist, das ein Subkontrakt genannt wird, und das entworfen worden
ist, um die Kontrolle der Basismechanismen des Objektaufrufs und
der Argumentweiterleitung bereitzustellen, die in verteilten Systemen am
wichtigsten sind, und zwar auf eine Weise, welche es für die Objektimplementierer
einfach macht, einen vorhandenen Subkontrakt auszuwählen und
zu verwenden, und welches es den Anwendungsprogrammierern ermöglicht,
keine Kenntnis von den speziellen Subkon trakten zu haben, die für die bestimmten
Objekte verwendet werden.
-
ZUSAMMENFASSENDE
DARSTELLUNG DER ERFINDUNG
-
Die vorliegende Erfindung schafft
einen eleganten und einfachen Weg, um Mechanismen zum Aufrufen von
Objekten durch Client-Anwendungen und zur Argumentweiterleitung
zwischen Client-Anwendungen und Objekt-Implementierungen bereitzustellen,
ohne daß die
Client-Anwendung oder das Betriebssystem die Details kennen, wie
diese Mechanismen arbeiten. Darüber
hinaus funktionieren diese Mechanismen in einer Umgebung verteilter
Computer mit ähnlicher
Leichtigkeit und Effizienz, wobei die Client-Anwendungen auf einem
Computerknoten und die Objekt-Implementierungen auf einem anderen
sein können.
-
Die Erfindung umfaßt einen
neuen Typ eines Objekts, der ein "Spring-Objekt" genannt wird, welcher eine
Methodentabelle, einen Subkontraktmechanismus und eine Datenstruktur
umfaßt,
welche den lokalen privaten Zustand des Subkontrakts repräsentiert.
-
Der Subkontraktmechanismus ist das
Herz der voliegenden Erfindung, und jeder Subkontrakt enthält einen
clientseitigen Abschnitt und einen sich darauf beziehenden server-seitigen
Abschnitt. Jeder Objekttyp weist einen zugeordneten Subkontrakt
auf. Der client-seitige Abschnitt eines Subkontrakts hat die Fähigkeit, ein
neues Spring-Objekt
zu erzeugen, ein Spring-Objekt zu löschen, Informationen über das
ihm zugeordnete Objekt in einen Kommunikationspuffer einzureihen
(marshal), Daten aus einem Kommunikationspuffer auszureihen (unmarshal),
welche das ihm zugeordnete Objekt darstellen, einen Kommunikationspuffer
zu seinem zugeordneten server-seitigen Subkontrakt zu übermitteln,
was entweder die Übermittlung
eines Objekts von einem Ort zu einem anderen Ort oder die Übermittlung
einer Kopie eines Objekts von einem Ort zu einem anderen umfaßt. Der
server-seitige Abschnitt des Subkontraktmechanismus umfaßt, die
Fähigkeit
ein Spring-Objekt zu erzeugen, eine Unterstützung für eine Verarbeitung eingehender
Aufrufe und zugehöriger
Kommunikationspuffer bereitzustellen und eine Unterstützung für den Aufruf
eines Objekts bereitzustellen.
-
Die Erfindung umfaßt Verfahren
zum Verwenden von Subkontrakten, um Objektaufrufe zu verarbeiten, einschließlich der
Weiterleitung von Argumenten, wobei die Argumente selbst wiederum
Objekte sein können, in
einem verteilten Datenverarbeitungssystem, in dem die Client-Anwendungen
sich auf anderen Computern als die Objekt-Implementierungen aufhalten
können.
-
BESCHREIBUNG
DER ZEICHNUNGEN
-
Die Aufgaben, Merkmale und Vorteile
des Systems gemäß der vorliegenden
Erfindung werden aus der folgenden Beschreibung ersichtlich, in
welcher:
-
1 die
bekannte Beziehung von Client- und Server-Anwendungen zu Stümpfen und zur Netzwerksoftware
veranschaulicht.
-
2 veranschaulicht
die Hauptsystemkomponenten des SPRING-Betriebssystems.
-
3 veranschaulicht
die Beziehung zwischen Stumpfobjekten, Subkontraktobjekten und Server-Anwendungsobjekten.
-
4 veranschaulicht
einen Fernobjektaufruf unter Verwendung des Subkontrakts.
-
5 veranschaulicht
den Objektaufruf auf einer Einzelmaschine unter Verwendung eines
Subkontrakts.
-
6-9 veranschaulichen ein Ablaufdiagramm
einer beispielhaften Verwendung des erfindungsgemäßen Verfahrens
des Subkontrakts.
-
10a und lOb veranschaulichen die SPRING-Sicht von
Objekten gegenüber
der bekannten Sicht von Objekten.
-
BEZEICHNUNGEN
UND TERMINOLOGIE
-
Die folgenden detaillierten Beschreibungen
können
anhand von Programmprozeduren, die auf einen Computer oder einem
Netzwerk von Computern ausgeführt
werden, präsentiert
werden. Diese prozeduralen Beschreibungen und Darstellungen sind
diejenigen Mittel, die von Fachleuten auf diesem Gebiet verwendet werden,
um auf effektivste Weise die Substanz ihrer Arbeit anderen Fachleuten
zu übermitteln.
Unter einer Prozedur wird hier und im allgemeinen eine in sich konsistente
Sequenz von Schritten verstanden, die zu einem gewünschten
Ergebnis führt.
Diese Schritte sind solche, die physikalische Manipulationen physikalischer Größen erfordern. Überlicherweise,
jedoch nicht notwendigerweise, nehmen diese Größen die Form elektrischer oder
magnetischer Signale an, die gespeichert, übertragen, kombiniert, verglichen
oder auf andere weise manipuliert werden können. Hauptsächlich aus
Gründen
der allgemeinen Verwendung hat es sich gelegentlich als geeignet
erwiesen, auf diese Signale als Bits, Werte, Elemente, Symbole,
Zeichen, Terme, Zahlen o. dgl. Bezug zu nehmen. Es sei jedoch angemerkt,
daß all
diese und ähnliche
Begriffe den richtigen physikalischen Größen zugeordnet sein sollen
und bloß geeignete,
auf diese Größen angewendete
Bezeichnungen sind.
-
Darüber hinaus werden die ausgeführten Manipulationen
oftmals mit Begriffen, wie Addieren oder Vergleichen, bezeichnet,
welche üblicherweise
den durch einen menschlichen Bediener durchgeführten geistigen Operationen
zugeordnet werden. Keine derartige Fähigkeit eines menschlichen
Bedieners ist bei irgendwelchen der hier beschriebenen Operationen,
welche Teil der vorliegenden Erfindung bilden, erforderlich und
in den meisten Fällen
auch nicht erwünscht;
die Operationen sind Maschinenoperationen. Nützliche Maschinen zum Ausführen der
Operationen gemäß der vorliegenden
Erfindung umfassen digitale Mehrzweckcomputer oder ähnliche
Einrichtungen.
-
Die vorliegende Erfindung bezieht
sich darüber
hinaus auf eine Einrichtung zum Durchführen dieser Operationen. Diese
Einrichtung kann für
die geforderten Zwecke speziell konstruiert sein oder sie kann ein Mehrzweckcomputer
sein, der selektiv durch ein in dem Computer gespeichertes Computerprogramm
aktiviert oder umkonfiguriert ist. Die hier angegebenen Prozeduren
beziehen sich nicht inhärent
auf einen spezielllen Computer oder eine andere Einrichtung. Zahlreiche
Mehrzweckmaschinen können
mit den in Übereinstimmung
mit den hier angegebenen Lehren geschriebenen Programmen verwendet
werden, oder es kann sich als geeigneter herausstellen, spezialisiertere
Einrichtungen zum Durchführen
der erforderlichen Verfahrensschritte zu konstruieren. Die erforderliche
Struktur für
eine Vielzahl dieser Maschinen wird aus der angegebenen Beschreibung
ersichtlich.
-
BESCHREIBUNG
DES BEVORZUGTEN AUSFÜHRUNGSBEISPIELS
-
Die folgende Offenbarung beschreibt
Lösungen
für die
Probleme, welche von Konstrukteuren objekt-orientierter Systeme
angetroffen werden, wenn sie versuchen, Schemata für den Objektaufruf
und die Argumentweiterleitung in verteilten Systemen, bei denen
die Argumente Objekte sein können,
auf eine Art und Weise zu implementieren, welche das objekt-orientierte
Basissystem nicht auf Verfahren festlegt, welche zu einem späteren Zeitpunkt
schwierig zu ändern
sind. Die Erfindung umfaßt
einen neuen Objekttyp, der "Spring-Objekt" genannt wird, welcher
eine Methodentabelle, einen Subkontraktmechanismus und eine Datenstruktur,
welche den lokalen privaten Zustand des Subkontrakts repräsentiert,
umfaßt.
Es werden ein Verfahren und eine Einrichtung für einen Subkontraktmechanismus
offenbart, welcher jedem Objekt zugeordnet ist. Jeder Subkontrakt
enthält
einen client-seitigen Abschnitt und einen zugehörigen server-seitigen Abschnitt.
Jeder Objekttyp weist einen zugeordneten Subkontrakt auf. Der client-seitige
Abschnitt eines Subkontrakts hat die Fähigkeit, ein neues Spring-Objekt zu erzeugen,
ein Spring-Objekt zu löschen,
Informationen über
das ihm zugeordnete Objekt in einen Kommunikationspuffer einzureihen
oder zu arrangieren (marshal), Daten in einem Kommunikationspuffer,
welche das zugehörige
Objekt repräsentieren,
auszureihen oder zu dearrangieren (unmarshal), einen Kommunikationspuffer
zu seinem zugehörigen
server-seitigen Subkontrakt zu übermitteln, was
entweder die Übermittlung
eines Objekts von einem Ort zu einem anderen oder die Übermittlung
einer Kopie eines Objekts von einem Ort zu einem anderen umfaßt. Der
server-seitige Abschnitt des Subkontraktmechanismus umfaßt die Fähigkeit,
ein Spring-Objekt zu erzeugen, Unterstützung bei der Verarbeitung
eingehender Aufrufe und zugehöriger
Kommunikationspuffer bereitzustellen und Unterstützung für die Aufrufung eines Objekts
bereitszustellen.
-
In der folgenden Beschreibung werden
aus Gründen
der Erläuterung
spezielle Daten und Konfigurationen angegeben, um ein besseres Verständnis der
vorliegenden Erfindung zu erreichen. Das hier beschriebene bevorzugte
Ausführungsbeispiel
ist als Abschnitt des objekt-orientierten SPRING-Betriebssystems implementiert, das von
Sun Microsystems, Inc. (Sun Microsystems ist eine registrierte Handelsmarke
von Sun Microsystems, Inc.) hergestellt wird. Für einen Fachmann ist es jedoch
klar, daß die
vorliegende Erfindung auch ohne die speziellen Details ausgeführt und
in zahlreichen Computersystemen und verschiedenen Konfigurationen
oder Ausgaben und Modellen von eng gekoppelten Prozessoren oder
in verschiedenen Konfigurationen von lose gekoppelten Multiprozessorsystemen
implementiert werden kann.
-
Ein SPRING-Objekt ist eine Abstraktion,
die einen Zustand enthält
und einen Satz von Methoden bereitstellt, um diesen Zustand zu manipulieren.
Die Beschreibung des Objekts und seiner Methoden ist eine Schnittstelle,
die in der Schnittstellendefinitionssprache spezifiziert ist. Die
Schnittstelle ist ein streng typisierter Kontrakt zwischen dem Implementierer
(Server) und dem Client des Objekts.
-
Eine SPRING-Domäne ist ein Adreßraum mit
einer Sammlung von Threads. Eine gegebene Domäne kann als Server einiger
Objekte und als Clients anderer Objekte agieren. Der Implementierer
und der Client können
in derselben Domäne
oder in verschiedenen Domänen
sein.
-
Da SPRING objekt-orientiert ist,
unterstützt
es den Gedanken der Schnittstellen-Vererbung. Spring unterstützt sowohl
den Gedanken der einzelnen als auch der mehrfachen Schnittstellenvererbung.
Eine Schnittstelle, die ein Objekt des Typs "foo" akzeptiert, akzeptiert
auch eine Instanz einer Unterklasse von "foo". Beispielsweise weist
das Adreß raum-Objekt
eine Methode auf, die ein Speicher Objekt nimmt und es in den Adreßraum abbildet.
Dieselbe Methode akzeptiert auch Datei- und Einzelbild_puffer-Objekte,
solange diese aus der Speicher_Objekt-Schnittstelle erben.
-
Das SPRING-Kernel unterstützt grundlegende
Querdomänaufrufe
und -threads, eine maschinenabhängige
Behandlung auf niedriger Ebene ebenso wie grundlegende virtuelle
Speicherunterstützung
für die Speicherabbildung
und physikalische Speicherverwaltung. Ein SPRING-Kernel weiß nichts über andere SPRING-Kernels – sämtliche
Fernaufrufe werden durch einen Netzwerk-Proxy-Server behandelt.
Darüber
hinaus hängt
das virtuelle Speichersystem von externen Seitenwechslern (pagers)
ab, um die Speicher- und Netzwerkkohärenz zu handhaben.
-
Es wird auf 2 Bezug genommen; ein typischer SPRING-Knoten
läßt verschiedene
Server zusätzlich
zu dem Kernel 50 ablaufen. Diese umfassen den Domänenmanager 52; den
virtuellen Speichermanager ("VMM") 54; einen Benennungs-Server 56,
den CFS-Datei-Server 58; einen lokalen Datei-Server 60;
eine Verbinderdomäne 62,
die für
die Verwaltung und Cache-Speicherung dynamisch verbundener Bibliotheken
verantwortlich ist; einen Netzwerk-Proxy 64, der Fernaufrufe
behandelt; und einen tty-Server 66, der die grundlegende
Terminalbehandlung ebenso wie Einzelbildpuffer und Maus-Unterstützung handhabt.
Andere Haupt-SPRING-Systemkomponenten,
welche vorhanden sein könnten,
sind ein UNIX-Prozeß-Server 68,
ein Subkontraktregister 69 und eine beliebige Anzahl von
SPRING-Anwendungen 70.
-
SPRING ist eine experimentelle verteilte
Umgebung. Sie umfaßt
gegenwärtig
ein verteiltes Betriebssystem und ein Unterstützungsgerüst für verteilte Anwendungen. SPRING
ist vorgesehen, um Lösungen
für eine
Reihe von Problemen vorhandener Betriebssysteme zu erforschen, insbesondere
die Probleme der Entwicklung und der Erweiterung des Systems über der
Zeit.
-
SPRING ist darauf gerichtet, Schnittstellen
bereitzustellen statt einfach Implementierungen bereitzustellen.
SPRING ermutigt die Koexistenz von radikal verschiedenen Implementierungen
einer gegebenen Schnittstelle innerhalb eines einzigen Systems.
Es hat sich als geeignet herausgestellt, die Objektmetapher zu verwenden,
um diese Trennung von Schnittstellen und Implementierungen auszudrücken.
-
SPRING hilft dabei, es den Anwendungsprogrammierern
einfacher zu machen, neue fundamentale Eigenschaften dem System
hinzuzufügen,
ohne die Basismechanismen ändern
zu müssen.
Beispielsweise weist das aktuelle System keine Unterstützung für unteilbare
(atomic) Transaktionen auf. Es sollte möglich sein, langsam neue Eigenschaften
wie diese dem System hinzuzufügen.
-
Die Schnittstellendefinitionssprache
-
Das einigende Prinzip von SPRING
besteht darin, daß sämtliche
der Schlüsselschnittstellen
in einer Standardschnittstellendefinitionssprache definiert werden.
Diese Sprache ist objekt-orientiert und umfaßt die Unterstützung für eine mehrfache
Vererbung. Sie befaßt
sich lediglich mit Schnittstelleneigenschaften und stellt keinerlei
Implementierungsinformationen zur Verfügung.
-
Aus der Schnittstellendefinitionssprache
ist es möglich,
sprachspezifische Stümpfe
(stubs) zu erzeugen. Diese Stümpfe
stellen eine sprachspezifische Abbildung zu den SPRING-Schnittstellen
zur Verfügung.
In unserer Hauptimplementierungssprache C++ beispielsweise werden
Spring-Objekte durch C++-Objekte dargestellt. wenn eine Methode
an einem Stumpfobjekt aufgerufen wird, so führt sie entweder einen lokalen
Aufruf innerhalb des aktuellen Adreßraums durch oder leitet den
Aufruf an einen anderen Adreßraum
weiter, welcher sich auf einer anderen Maschinen befinden kann.
-
SPRING legt eine ungewöhnlich starke
Betonung auf die Trennung der Schnittstellen von Implementierungen.
Clients sind darauf beschränkt,
daran zu operieren, was sie als lokale Objekte wahrnehmen, und das
System erlegt keinerlei Beschränkungen
auf, wie diese Objekte implementiert werden. Beispielsweise könnte manchmal
der darunterliegende Zustand eines Objekts in dem gleichen Adreßraum wie
der Client sein, manchmal könnte
er an einem anderen Adreßraum
sein, manchmal könnte
er in dem Speicher sein, den sich der Client und der Server teilen,
oder manchmal könnte
er dynamisch zwischen verschiedenen dieser Zustände migrieren.
-
Das Spring-Objektmodell
-
SPRING weist eine geringfügig abweichende
Art der Sicht auf Objekte gegenüber
anderen verteilten objektorientierten Systemen auf, und es ist erforderlich,
dies zu klären,
bevor die Details des Subkontrakts erörtert werden.
-
Die meisten verteilten Systeme präsentieren
ein Modell, bei dem sich Objekte bei Server-Maschinen aufhalten
und Client-Maschinen Objekt-Handles besitzen, die auf das Objekt
bei dem Server zeigen (siehe 10a).
So beschäftigen
sich Clients mit Objekt-Handles statt mit Objekten.
-
SPRING präsentiert ein Modell, bei dem
die Clients direkt an Objekten arbeiten und nicht an Objekt-Handles
(siehe 10b). Bei einigen
dieser Objekten geschieht es, daß ihr gesamter interessierender
Zustand an irgendeiner fernen Stelle gehalten wird, so daß ihr lokaler
Zustand bloß aus
einem Handle zu diesem fernen Zustand besteht. Ein Objekt kann zu
einem Zeitpunkt nur an einem Platz vorhanden sein, so daß dann, wenn
wir ein Objekt zu irgendjemandem anderen übermitteln, wir das Objekt
nicht mehr selbst besitzen. Wir können jedoch auch das Objekt
kopieren, bevor wir es übermitteln,
was so implementiert werden könnte,
daß es
nunmehr zwei verschiedene Objekte gibt, die auf denselben fernen
Zustand verweisen.
-
Während
man somit bei Systemen, wie beispielsweise Eden, davon sprechen
könnte,
daß verschiedene
Clients Objekt-Handles aufweisen, die zu irgendeinem fernen Objekt
Bezug nehmen, würde
man bei SPRING davon sprechen, daß verschiedene Clients Objekte
aufweisen, die zu dem gleichen fernen Zustand verweisen.
-
Für
die meisten server-basierten Objekte ist dieser Unterschied hauptsächlich einer
der Terminologie. Jedoch unterstützt
SPRING darüber
hinaus Objekte, welche nicht server-basiert sind oder bei denen
der Zustand des Objekts zwischen dem Client und dem Server aufgeteilt
ist. Bei diesen Fällen
ist es viel geeigneter, den Client so zu betrachten, als ob er das
wahre Objekt besitzt, statt daß er
bloß einen
Zeiger besitzt.
-
Zum gegenwärtigen Zeitpunkt basiert das
SPRING-Betriebssystem
auf einem minimalen Kernel, welches eine grundlegende objekt-orientierte
Zwischen-Prozeß-Kommunika tion
und Speicherverwaltung bereitstellt. Die Funktionalität, wie beispielsweise
die Benennung, der Seitenwechsel, Dateisysteme, etc., werden als
Benutzermodus-Dienste an der Oberfläche des grundlegenden Kernels
zur Verfügung
gestellt. Das System ist inhärent
verteilt, und eine Anzahl von Cache-Speicherungstechniken wird verwendet,
um die Netzwerkleistung für
Schlüsselfunktionen
in die Höhe
zu treiben. Das System unterstützt
darüber
hinaus eine ausreichende UNIX-Emulation, um Standardwerkzeuge, wie
beispielsweise make, vi, csh, das X-Fenstersystem, etc., zu unterstützen.
-
Das Ziel von SPRING besteht darin,
eine große
Mannigfaltigkeit zu unterstützen.
Es wird als wichtig angesehen, daß einzelne Subsysteme ihre
eigenen Wege zur Ausführung
ihrer Aufgaben entwickeln können, welche
die allgemeinen Regeln und Konventionen umgehen können.
-
Der Subkontraktmechanismus
-
Bei moderneren Systemen spricht (kommuniziert)
die Anwendungssoftware nicht direkt mit der Netzwerksoftware. Statt
dessen spricht die Anwendungssoftware mit "Stümpfen" (14 in 1). Es gibt jeweils einen verschiedenen
Stumpf für
jede verschiedene Schnittstelle, die über das Netzwerk unterstützt wird.
Der Stumpfbefehlscode ist für
das Konvertieren zwischen einer speziellen Schnittstelle auf Sprachebene,
wie sie von der Anwendungssoftware gesehen wird, und den Standardkommunikationsstellen
auf niedriger Ebene, die von der Netzwerksoftware zur Verfügung gestellt
werden, verantwortlich. Beispielsweise sind die Stümpfe für das Aufnehmen
der Argumente an einen Fernaufruf und das Einbringen dieser Argumente
in eine Nachricht, die für die
Netzwerksoftware zum Übermitteln über das
Netzwerk geeignet ist, verantwortlich.
-
Es wird jetzt auf 4 Bezug genommen; bei der Umgebung gemäß der vorliegenden
Erfindung gibt die Client- Anwendung 12 auf
eine Maschine 10 Aufrufe an den geeigneten client-seitigen
Stumpf 14 aus, welcher bei einem clientseitigen Abschnitt
eines "Subkontrakts" 30 verspricht, welcher mit der Netzwerksoftware 16 kommuniziert,
welche mit ihrer im allgemeinen auf einer anderen Maschine 18 befindlichen
Gegenstücknetzwerksoftware 20 kommuniziert.
Diese server-seitige Netzwerksoftware 20 überträgt eingehende
Nachrichten an den server-seitigen Abschnitt des Subkontrakts 32,
welcher wiederum die Daten an die Server-Anwendung 24 liefert.
Wie angezeigt, paßt
der Subkontrakt sich zwischen den Stümpfen und der Netzwerksoftware ein.
Die Stümpfe
verwenden einen Subkontrakt, um Fernaufrufe durchzuführen, und
in ähnlicher
Weise verwendet dann der Subkontrakt die Netzwerksoftware, um den
tatsächlichen
Aufruf durchzuführen.
Verschiedene Subkontrakte implementieren verschiedene Arten von
Fernkommunikationsprotokollen (zur Replikation, zum Caching, etc.)
auf der Oberseite der Standardkommunikationssoftware.
-
Innerhalb eines Einzelcomputers können verschiedene
Anwendungen darüber
hinaus Subkontrakte verwenden, um zu kommunizieren. Es wird jetzt
auf 5 Bezug genommen;
die Client-Anwendung 12 ist in einem Anwendungsraum 38 und
gibt Aufrufe an den geeignete client-seitigen Stumpf 14 aus,
welcher wiederum den geeigneten Subkontrakt 30 aufruft.
Der Subkontrakt 30 überträgt dessen
Kommunikationen zu dem Betriebssystem 36, welches sie zu
dem server-seitigen Subkontrakt 32 vermittelt, welcher
wiederum die Daten an seinen server-seitigen Stumpf 22 abgibt,
der die Daten zu der Server-Anwendung 24 weiterleitet.
In diesem Fall ersetzen die von dem Betriebssystem 36 zur
Verfügung
gestellten Zwischen-Prozeß-Kommunikationsgrundelemente
den von der Netzwerksoftware (16 und 20 in 4) zur Verfügung gestellten
Zwischen-Maschinen-Kommunikationsmechanismus.
-
Selbst innerhalb einer einzigen Anwendung,
die in einem einzigen Adreßraum
abläuft,
kann der Subkontrakt verwendet werden, um zwischen verschiedenen
Komponenten der Anwendung zu kommunizieren.
-
Jetzt seien unter Bezugnahme auf 3 die Dinge aus einer objekt-orientierte
Perspektive betrachtet; die Client-Anwendung 1 wird in
Form von "Stumpfobjekten" 2 betrieben. Jedes dieser Stumpfobjekte 2 enthält ein Subkontraktobjekt 3,
dessen interner Zustand 4 (der als seine "Repräsentation"
bekannt ist) irgendeine Form eines Zeigers 6 auf den realen
darunterliegenden Zustand 5 enthalten kann, welcher sich
in dem gleichen Adreßraum,
in einem anderen Adreßraum
auf der gleichen Maschine oder vollständig auf einer anderen Maschine
aufhalten kann. Der darunterliegende Zustand wird typischerweise
selbst als Objekt 5 in dem Adreßraum der Server-Anwendung
dargestellt.
-
Wo der Subkontrakt hineinpaßt
-
Ein Spring-Objekt wird von einem
Client so wahrgenommen, als ob es aus drei Dingen besteht: einer Methodentabelle,
welche für
jede sich aus der Typdefinition des Objekts ergebene Operation einen
Eintrag enthält;
einer Subkontrakt-Beschreibung, welche die in dem nächsten Abschnitt
beschriebenen grundlegenden Subkontrakt-Operationen spezifiziert;
und irgendeinem lokalen privaten Zustand, welcher als Repräsentation des
Objekts bezeichnet wird.
-
Ein Client tritt mit einem Objekt
in Wechselwirkung, indem er Methoden an einem als C++-Objekt erscheinenden
Objekt aufruft. Der Befehlscode für dieses Objekt wurde tatsächlich automatisch
erzeugt, und er transformiert die Methodenaufrufe in Aufrufe entweder
der regulären
Methodentabelle des Objekts oder an seinem Subkontrakt-Operationenvektor.
Wie diese Methoden ihre Wirkung erreichen, ist gegenüber dem
Client versteckt.
-
Sofern das Objekt durch einen fernen
Server implementiert ist, so besteht eine typische Anordnung darin,
daß der
Subkontrakt die Mittel zum Kommunizieren mit dem ferner Server implementiert,
während
die Methodentabelle aus einem Zeiger auf Stumpfmethoden besteht,
deren einzige Aufgabe darin besteht, die Argumente in einen Puffer
einzureihen (to marshal), den Subkontrakt zum Ausführen des
Fernaufrufs aufzurufen und dann irgendwelche Ergebnisse aus dem
Erwiderungspuffer auszureihen (unmarshal). SPRING stellt einen automatischen
Stumpfgenerator bereit, um geeignete Stümpfe aus der Schnittstellendefinitionssprache
zu erzeugen.
-
Bei dem fernen Server gibt es typischerweise
irgendeinen Subkontraktbefehlscode zum Ausführen irgendeiner Subkontraktarbeit,
die eingehenden Aufrufen zugeordnet ist, und irgendeinen server-seitigen Stumpfbefehlscode,
der die Argumente für
jede Operation ausreiht (unmarshals) und in die Server-Anwendung aufruft.
(Dieser Server-Stumpfbefehlscode wird ebenfalls automatisch erzeugt).
-
Sofern ein Objekt vollständig lokal
implementiert ist, dann ist es möglich,
die Verwendung von Stumpfmethoden zu vermeiden und Implementierungsmethoden
bereitzustellen, die direkt in die Methodentabelle versetzt werden
können.
SPRING stellt eine Unterstützung
zum Erzeugen von Methodentabellen in diesem Fall zur Verfügung.
-
Grundlegende Subkontraktmechanismen
-
Die client-seitigen Subkontraktoperationen
sind:
-
- – Kopiere
(copy)
- – Konsumiere
(consume)
- – Reihe
aus (unmarshal)
- – Reihe
ein (marshal)
- – Reihe
ein und Kopie (marshal_copy)
- – Rufe
auf (invoke)
- – Rufe
Preamble auf (invoke preamble)
- – Enge
ein (narrow)
- – Objekt
Typ-ID
- – Objekt
Manager-ID
- – Ist
Null
-
Um die Subkontraktoperationen zu
veranschaulichen, werden wir als Beispiel einen Subkontrakt verwenden,
der Singleton genannt wird. Dieser Subkontrakt ist auf einer SPRING-Kernel-Kommunikationsmöglichkeit
aufgebaut, die Türen
genannt wird. Eine Tür
ist ein Kommunikationsendpunkt, zu welchem Threads adreßraumüberquerende
Aufrufe ausführen
können.
Eine Domäne,
die eine Tür
erzeugt, empfängt
einen Türidentifizierer,
welchen sie zu anderen Domänen
weiterleiten kann, so daß diese
Aufrufe zu der zugehörigen Tür ausgeben
können.
Das Kernel verwaltet sämtliche
Operationen an Türen
und Türidentifizierern,
einschließlich
ihrer Konstruktion, ihrer Zerstörrung,
ihres Kopierens und ihrer Übertragung.
-
Bei Singleton hält eine Server-Domäne den darunterliegenden
Zustand, der einem Objekt zugeordnet ist, und erzeugt eine Tür, um eingehende
Aufrufe zu akzeptieren. Die Client-Domänen besitzen bloß einen
Türidentifizierer,
den sie verwenden, um zu der Server-Domäne hindurch aufzurufen.
-
Somit besteht ein auf dem Singleton-Subkontrakt
aufgebautes SPRING-Objekt aus einer Methodentabelle, die vollständig aus
Stumpfmethoden besteht, einem Singleton-Subkontraktdeskriptor und
einer Repräsentation,
die aus einem Kernel-Türidentifizierer
besteht.
-
Kopiere
-
Die Subkontrakt-Kopiere-Operation
wird verwendet, um ein neues Spring-Objekt zu erzeugen, welches
in enger Beziehung zu einem vorhandenen Spring-Objekt steht. Die
exakte Beziehung der Kopie zu dem Original ist vollständig vom
Verhalten des Subkontrakts abhängig.
Manchmal kann der Subkontraktbefehlscode das Kopieren selbst durchführen, aber
manchmal kann er auswählen,
den Implementierungscode des Objekts einzuschließen.
-
Singleton implementiert das Kopieren,
indem er bei dem Kernel nachfragt, eine Kopie des aktuellen Türidentifizierers
herzustellen, und indem er dann ein neues Objekt erzeugt, dessen
Repräsentation
dieser neue Türidentifizierer
ist und welches denselben Subkontrakt und dieselbe Methodentabelle
wie das aktuelle Objekt referenziert. Somit sind nach dem Kopieren
jetzt zwei verschiedene Spring-Objekte
vorhanden, die jeweils den gleichen darunterliegenden Server-Zustand
referenzieren. (In diesem Falle ist die Semantik des Kopierens die
Semantik des Kopierens eines Zeigers).
-
Bei einem serverlosen Objekt könnte die
Implementierung des Kopierens das Kopieren des gesamten Zustands
des Objekts umfassen, so daß das
neue Objekt vollständig
von dem ursprünglichen
Objekt unterschieden ist.
-
Verbrauche (Consume)
-
Die Subkontrakt-Verbrauche-Operation
wird verwendet, um ein Spring-Objekt zu löschen.
-
Singleton implementiert das Verbrauchen,
indem der dem aktuellen Objekt zugeordnete Türidentifizierer gelöscht wird.
Dies beeinflußt
nicht direkt den Server-Zustand des Objekts, und dann, wenn es irgendwelche
weiteren Spring-Objekte
gibt, die den gleichen Server-Zustand referenzieren, bleiben diese
durch diese Operation unbeeinflußt.
-
Es sei angemerkt, daß in der
Praxis dann, wenn sämtiche
Türidentifizierer,
die eine Tür
referenzieren, gelöscht
worden sind, das Kernel den Server benachrichtigt, so daß er seinen
Server-Zustand freigeben kann, wenn er es auswählt.
-
Einreihen (marshal)
-
Die Subkontrakt-Einreih-Operation
wird verwendet, wenn ein Objekt an eine andere Maschine übermittelt
wird.
-
Sie nimmt das aktuelle Objekt und
bringt genügend
Informationen in einen Kommunikationspuffer, so daß ein im
wesentlichen identisches Objekt aus diesem Puffer in einer anderen
Domäne
ausgereiht (unmarshal) werden kann.
-
Da die gewünschte Semantik darin besteht,
das Objekt zu übermitteln,
ist es klar, daß wir,
nachdem wir das Objekt gesendet haben, es nicht mehr länger in
unserem Adreßraum
haben sollten. Somit ist ein impliziter Seiteneffekt des Einreihens
das Löschen
des gesamten dem Objekt zugeordneten lokalen Zustands.
-
Singleton implementiert das Einreihen,
indem er seinen Türidentifizierer
in den Einreihpuffer anordnet. Der Querdomänenaufrufmechanismus des Kernels
löscht
implizit den Türidentifizierer
aus dieser Domäne, wenn
er den Kommunikationspuffer zu einer anderen Domäne übermittelt.
-
Einreihen Kopieren (marshal
copy)
-
Unsere Schnittstellendefinitionssprache
unterstützt
einen Parameterweiterleitmodus des Kopierens. Dieser Modus impliziert,
daß eine
Kopie des Argumentobjekts übermittelt
wird, aber die aktuelle Domäne
das Originalobjekt behält.
Dieser Modus war ursprünglich
implementiert, indem zunächst
die Subkontrakt-Kopier-Operation und dann die Subkontrakt-Einreih-Operation
aufgerufen wurde. Es wurde jedoch beobachtet, daß dies häufig zu redundanter Arbeit
bei der Herstellung eines Spring-Objekts führt, das sofort gelöscht wurde.
Dies war insbesondere aufwendig für serverlose Objekte mit einem
zustandgroßen
Umfangs.
-
Somit wurde die Einreih Kopier-Operation
eingeführt.
Sie ist so definiert, daß sie
die Wirkung eines Kopierens gefolgt von einem Einreihen herstellt,
aber es wird gestattet, einige der Zwischenschritte herauszuoptimieren.
-
Im Falle von Singleton kopieren wir
einfach den aktuellen Türidentifizierer
und bringen den neuen Türidentifizierer
in den Kommunikationspuffer.
-
Im Falle eines serverlosen Objektes
könnte
Einreihen_Kopieren das Kopieren seiner Datenstrukturen in den Einreihpuffer
umfassen.
-
Ausreihen (unmarshal)
-
Die Ausreih-Operation wird verwendet,
wenn ein Objekt aus einer anderen Domäne empfangen wird. Ihre Aufgabe
besteht darin, ein vollständig
ausgestattetes Spring-Objekt herzustellen, das aus einer Methodentabelle,
einem Subkontraktvektor und einer Repräsentation besteht.
-
Wenn irgendeine Software (typischerweise
eine Stumpfmethode) entscheidet, ein Objekt aus einem Kommunikationspuffer
zu lesen, muß sie
sowohl einen anfänglichen
Subkontrakt als auch eine anfängliche Methodentabelle
auf der Grundlage des erwarteten Typs des Objekts auswählen. Sie
ruft dann den anfänglichen
Subkontrakt auf, leitet ihr die anfängliche Methodentabelle zu.
-
Der Subkontrakt muß dann versuchen,
ein Objekt auf der Grundlage der Informationen in dem Kommunikationspuffer
herzustellen. Dies umfaßt
typischerweise das Lesen ausreichender Informationen aus dem Kommuniationspuffer,
um in der Lage zu sein, eine Repräsentation zu erzeugen.
-
In dem Fall von Singleton umfaßt dies
normalerweise das Lesen eines Türidentifizierers
aus dem Puffer und das Erzeugen einer Repräsentation, um diesen Türidentifizierer
zu halten.
-
Schließlich steckt das Ausreihen
den Subkontraktzeiger, den Methodentabellenzeiger und die Repräsentation
zusammen, um ein neues Spring-Objekt zu erzeugen.
-
Aufrufen
-
Die Aufruf-Operation wird verwendet,
um einen Argumentpuffer an ein Ziel (destination) zu übermitteln und
einen Ergebnispuffer zu empfangen.
-
Im Falle von Singleton umfaßt dies
einfach ein Trap für
das Kernel, um den Querdomänenaufruf
an den Zieltüridentifizierer
durchzuführen.
-
Im Falle einer Subkontrakte unterstützenden
Replikation könnte
dies die Übermittlung
des Argumentpuffers zu einem (oder mehreren) eines Satzes möglicher
Server umfassen.
-
Aufruf Preamble
-
Die Subkontrakt-Aufruf-Operation
wird nur aufgerufen, nachdem das gesamte Argumenteinreihen bereits
erfolgt ist. In der Praxis wurde bemerkt, daß es Fälle gibt, bei denen ein Subkontrakt
eines Objekts es vorziehen würde,
früher
in dem Prozeß involviert
zu werden, so daß er
entweder einige Preamble-Informationen in den Kommunikationspuffer
einschreiben kann oder Flags setzen kann, um das zukünftige Einreihen
zu beeinflussen.
-
Um es dem Subkontrakt zu ermöglichen,
irgendwelche erforderlichen Zustände
einzurichten, weist SPRING eine neue Subkontraktoperation Aufruf
Prämbel
auf, welche aufgerufen wird, bevor irgendein Argumenteinreihen aufgetreten
ist.
-
Beispielsweise kann bei einigen Situationen
ein Subkontrakt einen geteilten Speicherbereich verwenden, um mit
einem Server zu kommunizieren. In diesem Fall kann dann, wenn Aufruf_Prämbel aufgerufen
wird, der Subkontrakt den Kommunikationspuffer so einstellen, daß er in
den geteilten Speicherbereich zeigt, so daß Argumente direkt in den Bereich
eingereiht werden und nicht kopiert zu werden brauchen, nachdem
das gesamte Einreihen abgeschlossen ist.
-
Objekt_Typ_ID
-
Spring unterstützt eine Laufzeittypisierung
in begrenztem Umfang. Diese wird während Operationen, wie beispielsweise
Objekt-Browsing, oder zum Validieren der Typ-Sicherheit bestimmter
Operationen (inbesondere Benennung) verwendet, welche nicht auf
der statischen Typüberprüfung vertrauen
können.
-
Die Objekt Typ-ID-Operation gibt
den wahren Typ-ID für
das aktuelle Objekt zurück.
-
Einige Subkontrakte implementieren
diese Operation, indem sie zu dem Server hindurch aufrufen, um den
Typ-ID zu erlangen. Andere Subkontrakte implementieren diese Operation,
indem sie den Typ_ID des Objekts als Teil ihrer Repräsentation
halten, was erfordert, daß er
als Teil der eingereihten (marshaled) Form des Objekts übermittelt
wird.
-
Einengen
-
Die Subkontrakt-Eineng-Operation
wird verwendet, um eine typ-überprüfte Typeinengung
auf einem Objekt von einem Basistyp zu einem abgeleiteten Typ zu
unterstützen.
Diese Operation verwendet den Typ-ID des Objekts, um zu Validieren,
daß die
Einengung gültig
ist, und um eine Ausnahme zu erzeugen, wenn sie es nicht ist.
-
Objekt Manager-ID
-
Diese Subkontrakt-Operation unterstützt die
Spring-Benennungsarchitektur.
Sie schafft einen zuverlässigen
Weg, um einen Namen für
einen darunterliegenden Server eines Objekts zu erlangen. Sie wird
typischerweise implementiert, indem zu dem darunterliegenden Server
hindurch aufgerufen wird, um den Namen zu erlangen.
-
Ist Null
-
Spring unterstützt den Gedanken von Null-Objekten.
Diese schaffen Platzhalterobjekte, die während einer Pro gramm- und Datenstrukturinitialisierung
verwendet werden können.
Vereinbarungsgemäß führen Null-Objekte
zu Ausnahmen bei sämtlichen
Methoden und bei den meisten Subkontrakt-Operationen.
-
SPRING unterstützt Null-Objekte, indem es
sie mit speziellen Null-Subkontrakten beliefert. Die Ist Null-Operation
eines Null-Subkontrakts gibt wahr zurück, wo normale Subkontrakte
falsch zurückgeben.
-
Null-Subkontrakte gestatten typischerweise,
daß ihre
Objekte eingereiht werden, aber führen zu Ausnahmen bei den meisten
anderen Subkontrakt-Operationen.
-
Ein Beispiel der Subkontrakt-Verwendung
-
Es ist nützlich, die Sequenz von Subkontrakt-Operationen
zu betrachten, die durchgeführt
werden, wenn ein fernes Objekt aufgerufen wird. Man beachte, daß dies nur
ein Beispiel ist, und daß Fachleute
erkennen werden, daß Subkontrakte,
wie sie bei der vorliegenden Erfindung definiert werden, dazu gebracht
werden können,
viel exotischere Dinge auszuführen,
als hier beschrieben werden. In der folgenden Erörterung soll auf die 6 bis 9 Bezug genommen werden.
-
Es sei angenommen, daß wir ein
Objekt A haben, welches eine Methode Fred unterstützt und
welches einen Subkontrakt SA verwendet.
-
fred:proc(copy x:wombat) returns
fruitbat
-
Von dem Rückgabetyp fruitbat ist bekannt,
daß er
irgendeinen Subkontrakt SF verwendet.
-
Sagen wir, daß wir ein Objekt X des Typs
wombat haben, welches einen Subkontrakt SX verwendet, und wir rufen
A's Methode Fred auf, wobei wir X als Argument einleiten 50:
-
- 1. Zunächst
geben wir die Stumpfmethode für
"Fred" ein 52, 54.
- 2. Der Stumpfbefehlscode ruft A's Aufruf_Preamble-Operation auf 56.
- 3. Der SA-Aufruf Preamble-Befehlscode führt irgendwelche erforderliche
Initialisierung durch und gibt zurück 58.
- 4. Der Stumpfbefehlscode versucht dann, das Argumentobjekt X
als Kopieargument einzureihen, indem die Einreih Kopier-Operation
von X aufgerufen wird. In 6 läuft dies
wie folgt ab: Stumpf Fred macht einen Test, um nachzusehen, ob es
irgendwelche einzureihenden Argumente gibt 60. Da die Antwort
ja ist, testet dann der Stumpf Fred die Argumente, um nachzusehen,
ob irgendwelche davon Objekte sind 62. Bei Auffinden des
Objekts X und Erlangen der Kenntnis darüber, daß X einen Subkontrakt SX hat,
ruft Stumpf Fred den Subkontrakt SX auf, um Objekt x einzureihen 64.
- 5. Der SX-Einreih Kopier-Befehlscode arrangiert, daß Informationen,
die eine Kopie von X beschreiben, in den Argumentpuffer eingegeben
werden, und gibt an Stumpf Fred zurück 64.
- 6. Der Stumpfbefehlscode hat jetzt sämtliche Argumente eingereiht
und ist nunmehr bereit, den Aufruf tatsächlich auszuführen. So
ruft er die Aufruf-Operation von A auf 70.
- 7. Die SA-Aufruf-Methode führt
die Arbeit durch, die erforderlich ist, um den Argumentpuffer an
den Ziel-Server zu übermitteln,
mit einer Anforderung, daß ein
Aufruf auf der Fred-Methode auf dem Server-Zustand für das Objekt
A auftritt, und wartet auf einen aus dem Server zurückkehrenden
Ergebnispuffer 72.
- 8. Es wird jetzt auf 7 Bezug
genommen; der Aufruf wird von dem Ziel-Server empfangen und die
Daten werden an den server-seitigen Subkontrakt SSA geliefert, der
den Puffer zum server-seitigen Stumpf S2 liefert 74, 76.
Stumpf S2 überprüft, um nachzusehen,
ob es Argumente gibt, die auszureihen sind 78, und dann,
um nachzusehen, ob irgendwelche der Argumente Objekte sind
80.
Wenn er auffindet, daß es
ein auszureihendes Objekt X gibt, ruft der Stumpf S2 die Ausreih-Operation
des SSA-Subkontrakts auf 82. Subkontrakt SSA überprüft den Subkontrakt-ID
des Objekts X, um zu finden, daß es
einen ihm zugeordneten Subkontrakt SX aufweist 84. Subkontrakt
SSA ruft dann die Ausreih-Operation auf Subkontrakt SX auf 84,
und der Subkontrakt SX reiht das Objekt X aus, um es an den Subkontrakt
SSA zurückzugeben,
welcher wiederum es an den Stumpf S2 zurückgibt 86. Stumpf
S2 leitet, sobald er das Ausreihen sämtlicher Argumente abgeschlossen
hat, den Aufruf und die Argumente an die angezielte Objektimplementierung
weiter 92 und wartet auf eine Erwiderung 94. Der
Objektimplementierer verarbeitet den Aufruf und erzeugt ein Objekt
fruitbat-1 mit Subkontrakt SF und einen serverseitigen Subkontrakt
SSF und instruiert den Subkontrakt SSF, als server-seitiger Subkontrakt
für den
Subkontrakt SF zu dienen 96. Subkontrakt SSF erzeugt einen internen
Zustand, um fruitbat-1 zu identifizieren, und gibt das Objekt fruitbat
zurück,
das auf diesen Zustand zeigt 98. Der Objektimplementierer
gibt jetzt das Objekt fruitbat an den server-seitigen Stumpf S2
zur Rückgabe
an den Client 100 zurück.
Es wird jetzt auf 8 Bezug
genommen, Stumpf S2 muß jetzt
die Einreih-Routine der Argumente erneut durchlaufen, um das Objekt
fruitbat einzureihen 104, 106, 108, 110 und 112,
wobei die eingereihten Argumente an Stumpf S2 zurückgegeben
werden, welcher die eingereihten Daten an den server-seitigen Subkontrakt
SSA für
eine erneute Übermittlung
an den client-seitigen Subkontrakt SA liefert 116, 114.
- 9. Der Stumpfbefehlscode empfängt jetzt den Ergebnispuffer
aus der SA-Aufruf-Methode 130 und wünscht, das Ausreihen der Ergebnisse
zu starten. In diesem Fall ist von dem Ergebnis bekannt, daß es ein
Objekt des Typs fruitbat ist, welches den Subkontrakt SF aufweist,
so daß Stumpf
Fred (SA) die Ausreih-Operation des SF-Subkontrakts aufruft, wobei die reguläre Methodentabelle
für den
Typ fruitbat eingeleitet wird. Die gesamten Aufrufschritte sind
in den Blöcken 142, 134, 136, 138 gezeigt
und werden vollständiger
unten in der Diskussion über
kompatible Objekte beschrieben.
- 10. Der SF-Ausreih-Befehlscode versucht jetzt, ein Objekt aus
dem Ergebnispuffer auszureihen (unmarshal). Er kombiniert die Informationen
aus dem Ergebnispuffer mit seiner eigenen Subkontraktmethodentabelle
und mit der regulären
Methodentabelle, die ihm zugeleitet wurde, um ein neues Spring-Objekt
zu bilden, welches er zurück
zu dem Stumpf leitet 140.
- 10. Der Fred-Stumpf hat jetzt seine Aufgabe beendet und kann
das Ergebnisobjekt an die Anwendungsebene zurückgeben 148.
-
Der Prozeß wurde durch den Stumpfbefehlscode
für die
Methode Fred von A angesteuert, aber schloß darüber hinaus die Subkontrakte
für das
Ziel-Objekt, für
das Argument-Objekt
und für
das Ergebnis-Objekt ein.
-
Kompatible Subkontrakte
-
Selbstverständlich ist es für unterschiedliche
Objekte wünschenswert,
unterschiedliche Subkontrakte zu haben. Insbesondere können zwei
Objekte, welche von der Client-Anwendung als solche vom gleichen
Typ wahrgenommen werden, tatsächlich
unterschiedliche Subkontrakte aufweisen. Beispielsweise kann eine
Instanz des "Datei"-Typs den Standard"-Singleton"-Subkontrakt verwenden,
während
eine andere Instanz von "Datei" den interessanteren "Cachable"-Subkontrakt
verwendet.
-
Für
jeden Typ kann ein Standardsubkontrakt spezifiziert werden, der
verwendet wird, wenn mit dem Typ gesprochen wird; was aber macht
SPRING, wenn ein abweichender Subkontrakt tatsächlich benötigt wird? Beispielsweise wird
der Standardtyp Datei spezifiziert, um einen einfachen Singleton
genannten Subkontrakt zu verwenden. Der Typ Cachable Datei ist ein
Untertyp von Datei, welcher statt dessen den Caching-Subkontrakt
verwendet. Was geschieht aber, wenn ein Objekt des Typs Cachable
Datei dort gesendet wird, wo ein Objekt des Typs Datei erwartet
wird? Selbstverständlich
wird der Empfänger,
wenn er darauf besteht, das Caching-Objekt so auszureihen, als wäre es ein
Singleton, dann enttäuscht
werden.
-
Dieses Problem wird durch Einführen des
Begriffs eines kompatiblen Subkontrakt gelöst. Ein Subkontrakt A wird
als kompatible mit einem Subkontrakt B angesehen, wenn der Ausreih-Befehlscode
für den
Subkontrakt B in richtiger Weise das Empfangen eines Objekts des
Subkontrakts A bewältigt.
-
Der normale, zum Implementieren kompatibler
Subkontrakte verwendete Mechanismus besteht darin, irgendeine Form
eines Subkontraktidentifzierers als Teil der eingereihten (marshaled)
Form jedes Objekts einzuschließen.
-
So beginnt eine typische Subkontrakt-Ausreih-Operation
damit, daß ein
flüchtiger
Blick auf den erwarteten Subkontraktidentifizierer in dem Kommunikationspuffer
geworfen wird. Wenn er den erwarteten Identifizierer für den aktuellen
Subkontrakt enthält,
fährt der
Subkontrakt mit einem regulären
Ausreihen fort. wenn sie jedoch irgendeinen anderen Wert sieht,
dann ruft sie in ein Register auf, um den richtige Code für diesen Subkontrakt
zu lokalisieren, und ruft dann diesen Subkontrakt auf, um das Ausreihen
durchzuführen.
-
Gegenwärtig sind sämliche unserer Subkontrakte
miteinander kompatibel, und sie verwenden ein einziges Schema, um
sich selbst zu identifizieren. Es wäre jedoch möglich, andere Sätze von
Subkontrakten hinzuzufügen,
welche abwei chende Schemata für
die gegenseitige Identifikation verwenden und welche inkompatibel
mit dem Standardsatz wären.
-
Entdecken neuer Subkontrakte
-
Ein Programm wird typischerweise
mit einem Satz von Bibliotheken verbunden, die einen Satz von Standard-Subkontrakten
bereitstellen. Zur Laufzeit jedoch kann es sein, daß es Objekte
antrifft, welche Subkontrakte verwenden, die sich nicht in seinen
Standardbibliotheken befinden.
-
Es wird ein Mechanismus bereitgestellt,
um von den Subkontraktidentifizierern auf Bibliotheksnamen abzubilden,
und ein dynamisches Verbinden von Bibliotheken zum Erlangen neuer
Subkontrakte wird unterstützt.
-
Sagen wir, daß eine Domäne erwartet, daß unter
Verwendung des Singleton-Subkontrakts ein Objekt vom Typ Datei empfangen
wird, wir aber statt dessen ihr ein Objekt vom Typ Replizierte Datei
unter Verwendung des Replicon-Subkontrakts senden. Die Singleton-Ausreih-Operation
entdeckt dann, daß sie
sich mit einem abweichenden Subkontrakt befaßt, und sie wird einen Aufruf
in das Subkontraktregieter der Domäne ausführen, um den richtigen Subkontraktcode
aufzufinden. Das Register wird entdecken, daß gegenwärtig kein geeigneter Subkontrakt
geladen ist, aber es wird dann einen Netzwerkdienst verwenden, um
den Subkontraktidentifizierer auf einen Bibliotheksnamen (sagen
wir replicon.so) abzubilden, und es wird dann versuchen, dynamisch
in dieser Bibliothek zu verbinden, um den Subkontrakt zu erlangen.
-
Obwohl das Programm kein Konzept
für replizierte
Objekte hatte und anfänglich
nicht mit irgendwelchen Bibliotheken verbunden war, die replizierte
Objekte verstanden, waren wir somit in der Lage, dynamisch den richtigen
Befehlscode zu erlangen, um mit einem replizierten Datei-Objekt
zu sprechen.
-
Dieser Mechanismus bedeutet, daß es möglich ist,
neue Subkontrakte hinzuzufügen
und sie zu verwenden, um mit alten Anwendungen zu sprechen, ohne
entweder die alten Anwendungen oder die Standardbibliotheken zu ändern, wobei
nur vorausgesetzt wird, daß wir
eine geeignete Subkontraktbibliothek während der Laufzeit des alten
Programms verfügbar
machen können.
Diese dynamische Verbindungsstrategie ist weit davon entfernt, unfehlbar
zu sein.
-
Vielen Domänen, insbesondere Servern des
Systems, widerstrebt es, einfach irgendwelchen beliebigen dynamischen
Bibliotheksbefehlscode ablaufen zu lassen, der von einem potentiell
bösartigen
Client benannt worden ist. So wird aus Sicherheitsgründen der
dynamische Verbinder nur dem Laden solcher Bibliotheken zustimmen,
die sich auf einem gekennzeichneten Verzeichnissuchpfad befinden.
So erfordert es typischerweise den Eingriff eines Systemadministrators,
um eine neue Subkontraktbibliothek in einem Standardverzeichnis
zu installieren, welches die meisten Domänen auf ihren Suchpfaden haben.
-
Die Server-Seite
-
Viele Subkontrakte unterstützen eine
Client-Server-Verarbeitung. Die client-seitige Sicht eines Subkontrakts
wurde beschrieben, aber für
server-basierte Objekte gibt es darüber hinaus eine bestimmte Menge von
Einrichtungen auf der Server-Seite.
-
Auf der Client-Seite ist die Subkontraktimplementierung
nicht für
Anwendungsprogrammierer verfügbar.
Auf der Server-Seite jedoch ist es Server-Implementierungen gestattet,
enger mit bestimmten Subkontrakten gekoppelt zu sein. Beispielsweise
kann ein replizierter Subkontrakt spezielle Schnittstellen zu der
Server-Anwendung erfordern, um die Replikation zu unterstützen.
-
Somit können die server-seitigen Schnittstellen
erheblich zwischen Subkontrakten variieren. Jedoch gibt es drei
Elemente, die typischerweise vorhanden sind: die Unterstützung für ein Erzeugen
eines Spring-Objekts aus einem Objekt auf Sprachebene, die Unterstützung für eine Verarbeitung
eingehender Aufrufe und die Unterstützung zum Aufrufen eines Objekts.
Ein Objekt "auf Sprachebene" ist eines, das nur einen Zustand und einen
Satz von Methoden enthält.
-
Erzeugen eines Spring-Objekts
-
Subkontrakte müssen einen Weg zum Erzeugen
von Spring-Objekten
aus Objekten auf Sprachebene bereitstellen. Dieser kann eine oder
zwei Formen annehmen.
-
Die einfachste Form besteht darin,
daß ein
Subkontrakt ein normales client-seitiges Spring-Objekt erzeugt.
Dies bedeutet, daß er
irgendeine Art eines Kommunikationsendpunkts (z. B. eine Kern-Tür (nucleus door))
erzeugen und ein client-seitiges Spring-Objekt herstellen muß, dessen
Repräsentation
diesen Endpunkt verwendet.
-
Einige Subkontrakte jedoch stellen
eine spezielle Unterstützung
für Spring-Objekte
zur Verfügung,
die sich in dem gleichen Adreßraum
wie ihr Server aufhalten. Beispielsweise der Singleton-Subkontrakt
stellt einen optimierten Aufrufmechanismus zur Verfügung, der
innerhalb eines einzigen Adreßraums
verwendet werden kann. Wenn ein Spring-Objekt unter Verwendung eines derartigen
Subkontrakts erzeugt wird, wird es typischerweise ein Objekt unter
Verwendung eines speziellen server-seitigen Operationsvektors herstellen
und es vermeiden, den Aufwand des Erzeugens von für eine domänenübergreifende
Kommunikation erforderlichen Ressourcen aufzuwenden. Wenn und sofern
das Objekt tatsächlich
zur Übertragung
zu einer anderen Domäne
eingereiht worden ist, wird der Subkontrakt schließlich diese
Ressourcen erzeugen.
-
Somit stellt der Singleton-Subkontrakt
anfänglich
ein Spring-Objekt unter Verwendung nur eines lokalen C++-Zeigers
auf den Server-Zustand her. Nur dann, wenn dieses Objekt für eine externe Übertragung
eingereiht wird, lei stet sich Singleton den Aufwand des Erzeugens
einer Kern-Tür und des
Einreihens des zugehörigen
Tür-ID.
-
Verarbeitung eingehender
Aufrufe
-
Gelegentlich wird ein Subkontrakt
einen Kommunikationsendpunkt erzeugen, der einen eingehenden Aufruf
direkt an die server-seitigen Stümpfe
liefert. Häufiger
jedoch wird der Subkontrakt arrangieren, daß der eingehende Anruf zunächst in
dem Subkontrakt eintrifft, und wird dann selbst den Aufruf an die
Stumpfebene weiterleiten.
-
Dies gestattet es dem server-seitigen
Subkontrakt, einen Dialog mit dem zugehörigen client-seitigen Befehlscode
aufrechtzuerhalten, indem zusätzliche
Informationen auf Aufrufe und Erwiderungen huckepack aufgesetzt
werden. Ein Subkontrakt beispielsweise, der eine Replikation unterstützt, könnte Informationen
auf Erwiderungen aufsetzen, um Clients über Änderungen in dem Satz der replizierten
Server zu informieren oder darüber,
auf welchem Server er es vorziehen würde, den Client zu verwenden.
-
Aufrufen eines Objekts
-
Gelegentlich wird ein Server entscheiden,
daß er
es wünscht,
ein Stück
des Zustands zu verwerfen, selbst wenn es Clients gibt, die gegenwärtig Objekte
aufweisen, die auf diesen Zustand verweisen. Dies ist insbesondere
wichtig für
Betriebssystemdienste, welche es wünschen können, Ressourcen zurückzufordern, ohne
darauf zu warten, daß sämtliche
ihrer Clients sich damit einverstanden erklären.
-
Somit stellen typische server-seitige
Subkontrakte einen Weg für
die Server-Anwendung zur Verfügung,
um ein ausstehendes Objekt aufzurufen. In dem Fall von Singleton
wird dies beispielsweise implementiert, indem die darunterliegende
Kern-Tür
(nucleus door) aufgerufen wird, welche effektiv weitere eingehende Kernel-Aufrufe
verhindert.
-
Beispiel-Subkontrakte
-
Das Folgende ist eine kurze Übersicht über einige
beispielhafte Subkontrakte. Für
einen Fachmann ist es klar, daß kein
bestimmter Typ dieser Typen für
die Ausführung
der vorliegenden Erfindung erforderlich ist und daß viele
andere Typen von Subkontrakten denkbar sind. Zur Verkürzung werden
vereinfachte Umrisse ihrer Kernmerkmale angegeben und Beschreibungen
von Fehlerbedingungen und speziellen Fällen fortgelassen.
-
Man beachte, daß in sämtlichen Fällen der Client-Anwendungscode
bloß einfache
Spring-Objekt-Aufrufe durchführt,
die Objekte als Argumente weiterleiten. Sämtliche beschriebenen Einrichtungen
sind in den Subkontrakten versteckt.
-
Der Cluster-Subkontrakt
-
Der Singleton-Subkontrakt verwendet
eine eigenständige
Kernel-Tür
für jedes
Stück des
Server-Zustands, der als separates Spring-Objekt aufgedeckt werden
könnte.
Da das Kernel eine Fähigkeit
wie ein Sicherheitsmodell auf Türidentifizierer
auferlegt, ist dies eine gute Implementierung für irgendwelche Objekte, die verwendet
werden, um den Zugriff auf selbständig geschützte Systemressourcen zu gewähren.
-
Einige Server jedoch exportieren
eine große
Anzahl von Objekten, wobei dann, wenn einem Client der Zugriff auf
irgendeines der Objekte gewährt
wird, diesem ebenso der Zugriff auf sämtliche Objekte gewährt werden
könnte.
In diesem Fall kann es den Systemmehraufwand reduzieren, wenn man
in der Lage ist, auf einen Satz von Objekten über eine einzige Tür zuzugreifen.
-
Der Cluster-Subkontrakt unterstützt diesen
Gedanken. Jedes Cluster-Objekt wird durch die Kombination eines
Türidentifizierers
und eines Ganzzahl-Tag repräsentiert.
Die Cluster-Aufruf Preamble- und -Aufruf-Operationen verabreden
sich, das Tag entlang zu dem Server zu verfrachten, wenn sie einen
domänenüberquerenden
Aufruf an der Tür
durchführen.
In ähnlicher
Weise senden und empfangen die Einreihund Ausreih-Methoden sowohl
den Türidentifizierer
als auch das Ganzzahl-Tag.
-
Der Caching-Subkontrakt
-
Wenn sich ein Server auf einer anderen
Maschine als seine Clients befinden, ist es oftmals nützlich, ein
Caching auf den Client-Maschinen durchzuführen. Wenn ein cache-speicherbares
Objekt zwischen den Maschinen übermittelt
wird, ist es somit erwünscht,
daß die
empfangende Maschine das empfangene Objekt bei einem lokalen Cache-Manager registriert
und auf das Objekt über
den Cache zugreift.
-
Der Caching-Subkontrakt stellt diese
Funktionalität
zur Verfügung.
Die Repräsentation
eines Caching-Objekts umfaßt
einen Türidentifizierer
(door identifier) DIl, der auf den Server zeigt, und einen Türidentifizierer
DI2, der auf einen lokalen Cache zeigt.
-
Wenn wir ein Caching-Objekt zwischen
Maschinen übermitteln, übermitteln
wir nur den DI1-Türidentifizierer.
Der Caching-Ausreih(unmarshal)-Befehlscode präsentiert den DI1-Türidentifizierer einem lokalen
Cache-Manager und empfängt
einen neuen DI2. Immer dann, wenn der Subkontrakt eine Aufruf-Operation
ausführt,
verwendet er den DI2-Türidentifizierer.
So gehen sämtliche
Aufrufe an einem cache-speicherbaren Objekt zu einem Cache-Manager
auf der lokalen Maschine. Die Verwendung eines Kontrakts dieses
Typs ist voll-ständiger beschrieben
in der parallel anhängigen
Anmeldung mit der Seriennummer / , angemeldet von Michael N. Nelson
und Yousef A. Khalidi für
"A Method and Apparatus for a Caching File Server", angemeldet am
gleichen Tag wie diese Anmeldung, wobei auf die Anmeldung hiermit
Bezug genommen wird.
-
Der wiederherstellbare (recoverable)
Subkontrakt Einige Server halten ihren Zustand in einem stabilen Speicher.
Wenn ein Client ein Objekt aufweist, dessen Zustand in einem derartigen
Server gehalten wird, würde
er es wünschen,
daß das
Objekt in der Lage ist, sich geräuschlos
aus Server-Abstürzen
wiederherzustellen. Normale Spring-Türidentifizierer werden ungültig, wenn
ein Server abstürzt,
so daß wir
irgendeinen neuen Mechanismus hinzufügen müssen, um es einem Client zu
gestatten, sich mit einem Server neu zu verbinden. Da normale Türidentifizierer
eine Fähigkeit
einer Eigenschaft besitzen, würden
wir auch gern einen Weg haben, den Server zu überzeugen, daß wir berechtigt
sind, ein vorgegebenes Stück
des Server-Zustands zu benutzen.
-
Der wiederherstellbare Subkontrakt
verwendet eine Repräsentation,
die aus einem normalen Türidentifizierer
plus dem Namen eines Wiederherstellungsmanagers plus einem kryptographisch
unterzeichneten Zertifikat besteht. Wenn ein Server ein wiederherstellbares
Objekt hinaus in die Welt leitet, erzeugt er ein Zertifikat, das
den Zugriff beschreibt, zu dem dieses Objekt berechtigt ist, und
unterzeichnet es unter Verwendung einer herkömmlichen kryptographischen
Signatur.
-
Normalerweise führt der wiederherstellbare
Aufrufcode einfach einen einfachen Türaufruf an dem Türidentifizierer
durch. Wenn dies jedoch fehlgeht, ruft der Subkontrakt statt dessen
in den Wiederherstellungsmanager, wobei er sein Zertifikat präsentiert
und anfordert, benachrichtigt zu werden, wenn der Server sich wieder
herstellt. Wenn der Server neu lädt,
kontaktiert er den Wiederherstellungsmanager und gibt unter Verwendung
der Zertifikate zum Gültig-Machen des Zugriffs
den Clients neue Türidentifizierer,
so daß sie
die Operationen wieder aufnehmen können.
-
Der Replicon-Subkontrakt
-
Der Replicon-Subkontrakt ist ein
extrem einfacher Subkontrakt, der sich mit replizierten Diensten
befaßt.
-
Ein Zustand eines Replicon-Objekts
besteht aus einem Vektor von Türidentifizierern.
Wenn er einen Aufruf durchführt,
versucht er, einen Aufruf über
Domänen
hinweg an jedem der Türidentifizierer
auszugeben, bis einer der Aufrufe Erfolg hat.
-
Es gibt viele zusätzliche Merkmale, die einfach
zu dem Replicon-Subkontrakt hinzugefügt werden könnten. Beispielsweise könnte man
zusätzlich
zu dem Vektor von Türidentifizierern
ein Konfigurations-Tag für die
aktuelle Server-Konfiguration verfolgen. Immer dann, wenn ein Server-Aufruf
ausgeführt
wird, könnte
dieses Konfigurations-Tag übermittelt
werden. Sofern der Server es wünscht,
die Konfiguration zu ändern
(weil Server neu geladen wurden oder wegen einer Lastausbalancierung),
kann er einen neuen Vektor von Türidentifizierern
und Konfiguration-ID auf den Ergebnispuffer huckepack aufsetzen.
-
Reflexionen an Subkontrakten
-
Einer der Gründe, weswegen ein Subkontrakt
effektiv ist, besteht darin, daß er
die Aufgabe des Implementierens von Objekten von dem Implementieren
von Objektmechanismen abtrennt. Subkontraktimplementierer stellen
einen Satz von interessierenden Subkontrakten zur Verfügung, die
Objektimplementierern ermöglichen,
aus einem Bereich unterschiedlicher Objektverfahrensweisen auszuwählen, ohne
zu erfordern, daß jeder
Objektimplementierer mit den Details der Objektimplementierungseinrichtungen
vertraut wird.
-
Der Satz von Operationen, die ein
Subkontrakt bereitstellt, erscheint der richtige Schlüssel zum
Erlangen der Steuerung innerhalb einer verteilten Umgebung zu sein.
Aufgrund der Konstruktion umfassen sämtliche Schlüsselaktio nen,
die an fernen Objekten vorgenommen werden, den Subkontrakt des Objekts
auf die eine oder andere Weise.
-
In der Praxis gelang es dem Subkontrakt,
die Funktionalität
zu reduzieren, die von dem Basissystem bereitgestellt werden muß. Eine
Reihe von interessierenden neuen Subkontrakten wurden implementiert,
ohne irgendwelche neuen Möglichkeiten
des Basissystems zu erfordern.
-
Der kompatible Subkontraktmechanismus
und das dynamische Verbinden von Subkontrakten bedeutet, daß neue Subkontrakte
in die Welt eingeführt
werden können
und auf alten SPRING-Systemen benutzt werden können, ohne irgendwelche Änderungen
an dem vorhandenen Betriebssystem.
-
Das bevorzugte Auführungsbeispiel
-
Bei einem bevorzugten Ausführungsbeispiel
kann der hier beschriebene Subkontraktmechanismus von Fachleuten
besser verstanden werden, indem auf das folgende Listing des Schnittstellendefinitionsbefehlscodes
Bezug genommen wird.
-
-
-
-
-
-
-
-
-
-
-
-
-
Während
die Erfindung anhand eines bevorzugten Ausführungsbeispiels in einer speziellen
Betriebssystemumgebung beschrieben worden ist, werden Fachleute
erkennen, daß die
Erfindung mit Modifikationen in anderen und unterschiedlichen Betriebssystemen
innerhalb des Umfangs der anhängigen
Ansprüche
ausgeführt
werden kann.
