-
Technisches Gebiet
-
Die
Erfindung betrifft Serversysteme zur Verwendung in einem Netzwerk
von Computern und insbesondere die Kommunikation zwischen Servern.
-
Stand der Technik
-
Client/Server-Systeme,
bei denen der Server eine oder mehrere Anwendungen für einen
Client ausführt,
sind traditionellen Mehrbenutzersystemem wie etwa UNIX ähnlich.
Graphisch verhalten sich diese Systeme ähnlich wie X-WINDOWS, ein Benutzeroberflächenstandard
für UNIX-Systeme.
Ein Client/Server-System wie etwa das von Citrix Systems, Inc. in
Ft. Lauderdale, Florida, hergestellte, kommerziell erhältliche WIN-FRAME-System
kann eine Anzahl von Anwendungsservern enthalten. Jeder Anwendungsserver
kann Multitasking mehrerer Anwendungen unterstützen, die von einem Benutzer
an einer abgesetzt angeordneten Workstation angefordert werden können.
-
Um
die Ansprechzeit zu minimieren, den Systemdurchsatz zu maximieren
und im allgemeinen den Anschein zu geben, daß das Anwendungsprogramm des
Benutzers im Client ausgeführt
wird, gibt ein Administrator einem Benutzer oft Zugang zu einer
Anzahl von Anwendungssservern, die Host für die gewünschten Anwendungen sind und
die Anforderungen des Benutzers versorgen können. Damit ein solches System
effizient betrieben wird, müssen
die Anwendungsserver jedoch den Zugang zu gemeinsam zwischen den
Anwendungsservern benutzten Systembetriebsmitteln koordinieren und
auch den Zugang zu den Anwendungsservern durch den Benutzer koordinieren.
Eine Methode hierfür
ist das Auswählen
eines Servers aus der Gruppe, der als der "Master-Server" wirkt. Der Master-Server ist dafür verantwortlich, die Betriebsmittelbenutzung
sowohl durch Benutzer als auch Anwendungsserver zu verfolgen. Mit
zunehmender Anzahl von Anwendungsservern wird die administrative
Last jedoch signifikant und begrenzt effektiv die Größe dieser
Netzwerke.
-
Die
vorliegende Erfindung vermeidet dieses potentielle Problem.
-
Evans
D. J und Butt W. U. N. in "Load
Balancing with Network Partitioning using Host Groups", Parallel Computing,
Elsevier Publishers, Amsterdam, NL, 1.3.1994, Seiten 325–345, XP433507,
beschreibt ein Lastausgleichssystem, bei dem Hosts jeweils Lastausgleichstabellen
führen,
indem sie untereinander Lastausgleichsstatistik multicasten. Mit
zunehmender Anzahl der Hosts und der Größe des Kommunikationsnetzwerks muß jeder
Host seinen Tabellenplatz für
das Führen
von Lastinformationen vergrößern.
-
US 5938732 beschreibt ein
Lastausgleichs- und Failover-System,
bei dem mehrere Dienstgruppen eingerichtet werden. Jede Dienstgruppe
besteht aus mehreren Hosts; jeder Host in der Dienstgruppe ist dafür verfügbar, die
Datenverarbeitungsdienste durchzuführen, für die die Gruppe als Ganzes
verantwortlich ist. Jeder betriebsfähige Host in einer Dienstgruppe
sendet periodische Nachrichten zu dem anderen Host in der Dienstgruppe,
die den Status des sendenden Hosts mitteilen. Ein Anführerhost
evaluiert die periodischen Nachrichten und weist gegebenenfalls
dynamisch die Verantwortlichkeit für bestimmte Datenverarbeitungsdienste
einem Host in der Gruppe neu zu. Die Neuzuweisung kann entweder
auf Failover oder Lastneuausgleich zurückzuführen sein.
-
Kurzfassung der Erfindung
-
Gemäß der Erfindung
wird ein Verfahren zum Verwalten von Laufzeitdaten in einem Computernetzwerk,
das mehrere Server in einer Server-Farm enthält, geschaffen, wobei das Verfahren
die folgenden Schritte umfaßt:
Definieren einer ersten Zone, die eine erste Teilmenge der mehreren
Server enthält,
wobei jeder Server ein Zonenmanager-Subsystem aufweist; Identifizieren
eines der Zonenmanager-Subsysteme als einen Zonenmanager-Master;
der Zonenmanager-Master bestimmt einen Server in der ersten Teilmenge
als ersten Kollektorpunkt zum Sammeln von Daten eines ersten Typs;
der Zonenmanager-Master bestimmt einen Server in der ersten Teilmenge
als einen zweiten Kollektorpunkt zum Sammeln von Daten eines zweiten
Typs, wobei der erste Datentyp von dem zweiten Datentyp verschieden
ist; Leiten der Laufzeitdaten des ersten Typs zu dem ersten Kollektorpunkt
zur Speicherung und Leiten der Laufzeitdaten des zweiten Typs zu
dem zweiten Kollektorpunkt zur Speicherung.
-
Bei
einer Ausführungsform
umfaßt
das Verfahren ferner, daß der
Zonenmanager-Master einen Server in der Server-Farm als einen ersten Netzwerkserver
zur Bereitstellung eines ersten Netzwerkdienstes zuweist.
-
Bei
einer Ausführungsform
umfaßt
das Verfahren ferner, daß ein
Zonenmanager-Subsystem bestimmt, daß der Zonenmanager-Master nicht
verfügbar
ist und einen neuen Zonenmanager-Master auswählt, um den nicht verfügbaren Zonenmanager-Master
zu ersetzen.
-
Der
Zonenmanager-Master kann einen Server in der Server-Farm auf der
Basis von physischen Kenngrößen als
einen Kollektorpunkt bestimmen. Die physischen Kenngrößen können verfügbarer Speicher
oder Nähe
zu einem die Daten des ersten Typs anfordernden Server sein.
-
Das
Verfahren kann ferner umfassen, eine Wahlanforderung für einen
neuen Zonenmanager-Master für
die erste Zone durch das Zonenmanager-Subsystem auf einem sendenden
Server in der ersten Teilmenge von Servern zu senden.
-
Der
sendende Server kann der erste Kollektorpunkt sein. Das Verfahren
kann ferner umfassen, die Wahlanforderung durch einen empfangenden
Server in der ersten Teilmenge von Servern in der ersten Zone zu
empfangen, wobei in diesem Fall der empfangende Server der erste
Kollektorpunkt sein kann.
-
Vorzugsweise
umfaßt
das Verfahren ferner das Vergleichen eines Wahlkriteriums zwischen
dem sendenden Server und dem empfangenden Server, um den neuen Zonenmanager-Master
der ersten Zone zu bestimmen.
-
Das
Wahlkriterium kann umfassen, ob das Zonenmanager-Subsystem jedes Servers in der ersten
Teilmenge von Servern als ein Zonenmanager-Master konfiguriert ist,
ob der empfangende Server der am längsten laufende Server ist
oder ob das Zonenmanager-Subsystem auf dem empfangenden Server einen
physikalisch niedrigeren Netzwerknamen aufweist.
-
Bei
einer Ausführungsform
kann der Zonenmanager-Master einen Server in der Server-Farm als
einen Netzwerkdienstserver zum Bereitstellen eines ersten Netzwerkdienstes
bestimmen.
-
Bei
einer Ausführungsform
kann der Zonenmanager-Master einen Server in der Server-Farm als
einen dritten Kollektorpunkt zum Sammeln von Daten des ersten Typs
bestimmen, wobei in diesem Fall das Verfahren umfassen kann, eine
zweite Zone zu definieren, die den dritten Kollektorpunkt aufweist.
Bei der Ausführungsform
kann das Verfahren ferner den Schritt des Anleitens der Kommunikation
mit dem dritten Kollektorpunkt umfassen.
-
Bei
einer Ausführungsform
umfaßt
das Verfahren ferner die folgenden Schritte: Bestimmen eines zweiten
Servers in der Server-Farm als einen weiteren Kollektorpunkt zum
Sammeln von Daten des ersten Typs; und Zuweisen einer ersten Teilmenge
der mehreren Server in der Server-Farm zum Senden von Daten des ersten
Typs zu dem ersten Kollektorpunkt und einer zweiten Teilmenge der
mehreren Server in der Server-Farm zum Senden von Daten des ersten
Typs zu dem weiteren Kollektorpunkt.
-
Das
Verfahren kann ferner die folgenden Schritte umfassen: Definieren
einer zweiten Zone, die eine zweite Teilmenge der mehreren Server
enthält,
wobei die zweite Teilmenge den weiteren Kollektorpunkt enthält; und
logisches Zuweisen der ersten Teilmenge von Servern in der ersten
Zone und der zweiten Teilmenge von Servern in der zweiten Zone.
-
Das
Verfahren kann ferner den Schritt des Bestimmens eines der Server
in der ersten Zone, der von dem Server verschieden ist, der als
der erste oder weitere Kollektorpunkt für den ersten Datentyp bestimmt
ist, als Kollektorpunkt zum Sammeln von Daten eines zweiten Typs
umfassen.
-
Das
Verfahren kann ferner den Schritt des Bestimmens des ersten oder
des weiteren Kollektorpunkts ebenfalls zum Sammeln von Daten eines
zweiten Typs umfassen.
-
Bei
einer Ausführungsform
umfaßt
das Verfahren den Schritt des Definierens der ersten Teilmenge und/oder
der zweiten Teilmenge auf der Basis geographischer Standorte der
Server in der Server-Farm.
-
Vorzugsweise
umfaßt
das Verfahren den Schritt des Kommunizierens mit dem ersten oder
dem weiteren Kollektorpunkt beim Anfordern von Daten des ersten
Typs. Besonders bevorzugt umfaßt
das Verfahren den Schritt des Kommunizierens mit dem ersten oder
dem weiteren Kollektorpunkt beim Speichern von Daten des ersten
Typs.
-
Die
Bestimmung mindestens eines der Server als einen Kollektorpunkt
kann in Abhängigkeit
von einer Boot-Reihenfolge
der Server in der Server-Farm erfolgen.
-
Bei
einer Ausführungsform
umfaßt
das Verfahren ferner, daß der
Zonenmanager-Master bestimmt, daß ein Kollektorpunkt nicht
verfügbar
ist und einen neuen Kollektorpunkt auswählt, um den nicht verfügbaren Kollektorpunkt
zu ersetzen.
-
Daten
des ersten Typs können
beliebige von Serverstatusinformationen, Client-Sitzungsdaten, Lizensierungsinformationen,
Ladeinformationen und das aktuelle Arbeitslastniveau jedes Servers
in den mehreren Servern der Server-Farm sein.
-
Das
Verfahren kann ferner umfassen, einen der Server in der zweiten
Zone als einen Kollektorpunkt zum Sammeln von Daten des ersten Typs
zu bestimmen, wobei in diesem Fall das Verfahren ferner den Schritt umfassen
kann, Daten des ersten Typs zu der zweiten Zone zu senden.
-
Bei
einer Ausführungsform
kann das Verfahren ferner die folgenden Schritte umfassen: Senden
von Daten von einem der ersten Zone zugewiesenen Server zu dem ersten
Kollektorpunkt; Senden der Daten von dem ersten Kollektorpunkt zu
dem weiteren Kollektorpunkt; und Senden der Daten von dem weiteren
Kollektorpunkt zu jedem der zweiten Zone zugewiesenen Server.
-
Gemäß einem
weiteren Aspekt der Erfindung wird ein Computernetzwerk bereitgestellt,
umfassend: eine Server-Farm, die mehrere verbundene Server enthält, wobei
die Server-Farm eine als eine einzige Entität administrierte logische Gruppe
von Servern umfaßt;
einen Definierer, der eine Zone definiert, die eine erste Teilmenge
der mehreren Server enthält,
wobei jeder Server ein Zonenmanager-Subsystem aufweist, und wobei
eines der Zonenmanager-Subsysteme als Zonenmanager-Master identifiziert
wird; der Zonenmanager-Master bestimmt einen Server in der ersten
Teilmenge als einen ersten Kollektorpunkt zum Sammeln von Daten
eines ersten Typs und bestimmt einen Server in der ersten Teilmenge
als einen zweiten Kollektorpunkt zum Sammeln von Daten eines zweiten
Typs, wobei der erste Datentyp von dem zweiten Datentyp verschieden
ist; und Mittel zum Verwalten der Daten des ersten Typs und des
zweiten Typs durch Leiten von Daten des ersten Typs zu dem ersten
Kollektorpunkt und Leiten von Daten des zweiten Typs zu dem zweiten
Kollektorpunkt.
-
Bei
einer Ausführungsform
ist der Zonenmanager-Master dafür
ausgelegt, einen ersten Netzwerkserver zuzuweisen, um einen ersten
Netzwerkdienst bereitzustellen.
-
Kurze Beschreibung der Zeichnungen
-
Die
Erfindung wird im einzelnen in den angefügten Ansprüchen dargelegt. Die oben beschriebenen Vorteile
der Erfindung sowie weitere Vorteile der Erfindung werden durch
Bezugnahme auf die folgende Beschreibung in Verbindung mit den beigefügten Zeichnungen
besser verständlich.
Es zeigen:
-
1 ein
Blockdiagramm einer Ausführungsform
einer Unternehmenssystemarchitektur mit mehreren Server-Farmen;
-
2A ein Blockdiagramm einer Ausführungsform
einer Server-Farm, die die Erfindung verwendet;
-
2B ein Diagramm einer Ausführungsform der Server-Farm vom 2A logisch zu mehreren Zonen von Servern organisiert;
-
3 ein
Blockdiagramm einer Ausführungsform
eines Servers in der Server-Farm von 2A,
wobei der Server mehrere Subsysteme enthält, die über einen Ereignisbus miteinander
kommunizieren;
-
4A ein Diagramm einer Ausführungsform einer von dem Ereignis-Bus
verwendeten Dispatch-Tabelle zum Routen von Ereignissen zu Subsystemen
auf dem Server von 3;
-
4B ein Diagramm einer Ausführungsform einer von dem Server
von 3 verwendeten Subskriptionstabelle zum Routen
von Ereignissen zu Subsystemen auf demselben Server;
-
4C ein Diagramm einer Ausführungsform einer von dem Server
von 3 verwendeten Subskriptionstabelle zum Routen
von Ereignissen zu Subsystemen auf anderen Servern in einer Farm;
-
5A ein Flußdiagramm
einer Ausführungsform
eines zum Antworten auf Subskriptionsanforderungen verwendeten Prozesses;
-
5B ein Flußdiagramm
einer Ausführungsform
eines zum Antworten auf Benachrichtigungsereignisse verwendeten
Prozesses;
-
6 ein
Flußdiagramm
einer Ausführungsform
eines zum Initialisieren von Servern und Subsystemen auf jedem Server
der Server-Farm verwendeten Prozesses;
-
7A–7B Diagrammansichten
einer Ausführungsform
eines Ereignisses, das gemäß der Erfindung
gesendet werden kann;
-
8A–8B Blockdiagramme
einer Ausführungsform
eines zum Ausgeben eines Ereignisses an ein Zielsubsystem unter
Verwendung eines PostEvent-Befehls verwendeten Prozesses;
-
9A–9D Fluß- und Blockdiagramme
einer Ausführungsform
eines zum Ausgeben eines Ereignisses an ein abgesetztes Zielsubsystem
unter Verwendung eines SendEventandWait-Befehls verwendeten Prozesses;
-
10 ein Blockdiagramm einer Ausführungsform
eines zur Verwaltung von Laufzeitdaten verwendeten Prozesses;
-
11 ein Blockdiagramm einer Ausführungsform
eines Servers mit einem Lizenzverwaltungs-Subsystems;
-
12 ein Flußdiagramm
einer Ausführungsform
eines während
der Lizenzverwaltungs-Subsystem-Initialisierung verwendeten Prozesses;
-
13 ein Flußdiagramm
einer Ausführungsform
eines von dem Lizenzverwaltungs-Subsystem als Reaktion auf eine
Lizenzanforderung verwendeten Prozesses;
-
14A–14B Blockdiagramme von Ausführungsformen eines Servers
mit einem Benutzerverwaltungs-Subsystems;
-
15 ein Flußdiagramm
einer Ausführungsform
eines von einem spezialisierten Serversubsystem zum Verarbeiten
einer Anwendungsstartanforderung verwendeten Prozesses;
-
16 ein Flußdiagramm
einer Ausführungsform
eines von einem Administrationswerkzeugs zum Erhalten von Daten
zur Verwaltung der Server-Farm verwendeten Prozesses; und
-
17–20 beispielhafte
Bildschirmkopien von durch das Administrationswerkzeug produzierten graphischen
Benutzeroberflächendisplays.
-
Index
-
Der
nachfolgende Index sollte dem Leser dabei helfen, der Besprechung
der Erfindung zu folgen:
- 1.0 Systemübersicht
- 2.0 Server-Farm-Übersicht
- 2.1 persistenter Speicher
- 2.2 dynamischer Speicher
- 2.3 Kollektorpunkte
- 2.4 Server-Zonen
- 3.0 Server-Übersicht
- 3.1 Modul gemeinsamer Einrichtungen
- 3.2 Subsystem-Kommunikation unter Verwendung des Ereignisbusses
- 3.2.1 Ereignisbus-API
- 3.2.2 Subsystem-API
- 3.2.3 Dispatch-Tabelle
- 3.3 Direkt-Subsystem-Kommunikation
- 3.4 Service-Modul des persistenten Speichersystems
- 3.5 Service-Modul des dynamischen Speichersystems
- 3.6 Service-Modul des Service-Lokalisierersystems
- 3.7 Service-Modul des Subskriptionsmanagersystems
- 3.7.1 Lokal-Subskriptionstabelle
- 3.7.2 abgesetzt-Subskriptionstabelle
- 3.7.3 Die Funktion Subscribe
- 3.7.4 Die Funktion Unsubscribe
- 3.7.5 PostNotificationEvent
- 3.8 Dienstmodul des Hostauflösungssystems
- 3.9 Dienstmodul des Zonenmanagersystems
- 3.9.1 Zuweisung der Eigentümerschaft
verteilter Betriebsmittel
- 3.9.2 Zuweisung der Eigentümerschaft
von Netzwerkdiensten
- 3.10 Systemmodul
- 3.11 Lader
- 4.0 Server- und Subsystemspezialisierung
- 5.0 Ereignisse
- 5.1 Ereignistypen
- 5.1.1 gerichtete Ereignisse
- 5.1.1.1 Anforderungs und -Antwort-Ereignisse
- 5.1.1.2 Benachrichtigungsereignisse
- 5.2 Ereignisablieferungsbefehle
- 6.0 einfache Beispiele
- 6.1 PostEvent-Befehl
- 6.2 SendEventAndWait-Befehl
- 6.3 Verwaltung dynamischer Daten
- 7.0 Subsysteme
- 7.1 Transportschicht
- 7.2 Gruppensubsystem
- 7.3 Beziehungs-Subsystem
- 7.4 Lastverwaltungs-Subsystem
- 7.5 Lizenzverwaltungs-Subsystem
- 7.6 Benutzerverwaltungs-Subsystem
- 7.7 ICA-Browser-Subsystem
- 7.8 Programmnachbarschafts-Subsystem
- 7.9 Anwendungs- und Server-Subsysteme
- 7.9.1 Anwendungs-Subsysteme
- 7.9.1.1 Subsystem gemeinsamer Anwendungen
- 7.9.1.2 Subsystem spezialisierter Anwendungen
- 7.9.2 Server-Subsysteme
- 7.9.2.1 Subsystem gemeinsamer Server
- 7.9.2.2 Subsystem spezialisierter Server
- 7.9.3 Anwendungsnamenauflösung
- 7.9.4 Anwendungsaufzählung
- 7.9.5 Server-Aufzählung
- 7.10 Subsystem des gemeinsamen Zugangspunkts (CAP)
- 7.11 Administrations-Subsystem
- 8.0 Administrationswerkzeug
-
Detaillierte Beschreibung der Erfindung
-
1.0 Systemübersicht
-
Nunmehr
mit Bezug auf 1 ist eine Ausführungsform
einer gemäß der Erfindung
konstruierten Systemarchitektur 100 abgebildet, die vier
Server-Farmen 110, 110', 110'', 110''' (allgemein 110),
mindestens einen mit einer der Server-Farmen 110 kommunizierenden
Client 120 und ein Administrationswerkzeug 140 enthält. Obwohl in 1 nur
vier Server-Farmen 110 und ein Client 120 gezeigt
sind, ist keine Beschränkung
der Prinzipien der Erfindung beabsichtigt. Eine solche Systemarchitektur 100 kann
eine beliebige Anzahl von Server-Farmen 110 enthalten und
eine beliebige Anzahl von Client-Knoten 120 in Kommunikation
mit diesen Farmen 110 aufweisen. Jede Server-Farm 110 ist
eine logische Gruppe eines oder mehrerer Server (im folgenden allgemein
als Server 180 oder Server 180 bezeichnet), die
als eine einzige Entität
administriert werden. Die Server 180 in jeder Farm 110 können heterogen
sein. Das heißt,
ein oder mehrere der Server 180 kann oder können gemäß einer
Art von Betriebssystemplattform (z. B. WINDOWS NT, hergestellt von
der Microsoft Corp. in Redmond, Washington) arbeiten, während einer
oder mehrere der anderen Server 180 gemäß einer anderen Art von Betriebssystemplattform
arbeiten können
(z. B. Unix oder Linux). Die Server 180, aus denen jede Server-Farm 110 besteht,
müssen
nicht physisch nahe bei jedem anderen Server 180 in seiner
Farm 110 liegen. Die logisch als Server-Farm 110 gruppierte
Gruppe von Servern 180 kann somit unter Verwendung einer Verbindung
durch ein großflächiges Netzwerk
(WAN) oder eine Verbindung durch ein mittelflächiges Netzwerk (MAN) verbunden
werden. Zum Beispiel kann eine Server-Farm 110 Server 180 enthalten,
die sich physisch in verschiedenen Regionen eines Staats, einer
Stadt, eines Campus oder eines Raums befinden. Datenübertragungsgeschwindigkeiten
zwischen den Servern 180 in der Server-Farm 110 können vergrößert werden, wenn
die Server 180 unter Verwendung einer Verbindung eines
lokalen Netzwerks (LAN) oder einer bestimmten Form von Direktverbindung
verbunden werden.
-
Als
Beispiel kommuniziert der Client-Knoten 120 durch eine
Kommunikationsstrecke 150 mit einem Server 180 in
der Server-Farm 110. Über
die Kommunikationsstrecke 150 kann der Client-Knoten 120 zum Beispiel
die Ausführung
verschiedener durch die Server 180, 180', 180'' und 180''' in der Server-Farm 110 gehosteten
Anwendungen anfordern und die Ausgabe der Ergebnisse der Anwendungsausführung zur
Anzeige empfangen. Die Kommunikationsstrecke 150 kann synchron
oder asynchron sein und kann eine LAN-Verbindung, eine MAN-Verbindung
oder eine WAN-Verbindung sein. Zusätzlich kann die Kommunikationsstrecke 150 eine
drahtlose Strecke sein, wie zum Beispiel ein Infrarotkanal oder
ein Satellitenband.
-
Als
repräsentatives
Beispiel für
Client-Knoten 120 und Server 180 im allgemeinen
können
die Client-Knoten 120 und der Server 180 miteinander
unter Verwendung vielfältiger
Verbindungen kommunizieren, darunter Standard-Telefonleitungen,
LAN- oder WAN-Strecken (z. B. T1, T3, 56 kb, X.25), Breitbandverbindungen
(ISDN, Frame Relay, ATM) und drahtlose Verbindungen. Verbindungen
können
unter Verwendung vielfältiger
Kommunikationsprotokolle der unteren Schichten hergestellt werden
(z. B. TCP/IP, IPX, SPX, NetBIOS, Ethernet, RS232, direkt asynchrone
Verbindungen). Protokolle höherer
Schichten, wie etwa das ICA-Protokoll (Independent
Computing Architecture) von Citrix Systems, Inc. in Ft. Lauderdale,
Florida, oder das von der Microsoft Corporation in Redmond, Washington,
hergestellte RDP (Remote Display Protocol) können verwendet werden, um es
dem Client 120 zu erlauben, auf eine Server-Farm 110 zuzugreifen,
wie etwa auf Anwendungen zuzugreifen, die auf den Servern 180 residiert
sind.
-
2.0 Server-Farm-Übersicht
-
Nunmehr
mit Bezug auf 2A enthalten die Server 180,
aus denen eine Server-Farm 110 besteht, jeweils eine netzwerkseitige
Schnittstelle 202 und eine Server-Farmseitige Schnittstelle 204.
Die netzwerkseitigen Schnittstellen 202 des Servers 180 können mit
einem oder mehreren Clients 120 oder einem Netzwerk 210 kommunizieren.
Das Netzwerk 210 kann ein WAN-, LAN- oder internationales Netzwerk sein,
wie etwa das Internet oder das World Wide Web. Clients 120 können unter
Verwendung des Netzwerks 210 Verbindungen mit den Servern 180 herstellen.
-
Die
Server-Farm-seitigen Schnittstellen 204 der Server 180 sind
jeweils über
Kommunikationsstrecken 200 miteinander verbunden, so daß die Server
gemäß den Prinzipien
der Erfindung miteinander kommunizieren können. Auf jedem Server 180 kommuniziert
die Server-Farm-seitige
Schnittstelle 204 mit der netzwerkseitigen Schnittstelle 202.
Die Server-Farm-seitigen Schnittstellen 204 kommunizieren
außerdem
(gekennzeichnet durch Pfeile 220) mit einem persistenten
Speicher 230 und bei bestimmten Ausführungsformen mit einem dynamischen
Speicher 240. Die Kombination der Server 180,
des persistenten Speichers 230 und des dynamischen Speichers 240 wird,
wenn vorgesehen, kollektiv als eine Server-Farm 110 bezeichnet.
-
2.1 Persistenter Speicher
-
Der
persistente Speicher 230 kann physisch auf einem Datenträger, einer
Datenträger-Farm,
einem RAID (redundant array of independent disks), beschreibbarer
Compact Disc oder einer beliebigen anderen Einrichtung implementiert
werden, die das Lesen und Schreiben von Daten erlaubt und die geschriebene
Daten behält,
wenn die Stromversorgung von der Speichereinrichtung genommen wird.
Eine einzige physische Einrichtung kann Speicherung für mehrere
persistente Speicher bereitstellen, d. h. es kann eine einzige physische
Einrichtung verwendet werden, um den persistenten Speicher 230 für mehr als
eine Server-Farm 110 bereitzustellen. Der persistente Speicher 230 führt mit
jedem Server 180 in der Server-Farm 110 assoziierte statische
Daten und von allen Servern 180 in der Server-Farm 110 verwendete
globale Daten. Bei einer Ausführungsform
kann der persistente Speicher 230 die Serverdaten in einem
LDAP-Datenmodell (Lightweight Directory Access Protocol) führen. Bei
anderen Ausführungsformen
speichert der persistente Speicher 230 Serverdaten in einer
ODBC-kompatiblen Datenbank. Für
die Zwecke der vorliegenden Beschreibung bedeutet der Ausdruck "statische Daten" Daten, die sich
nicht häufig ändern, d.
h. Daten, die sich nur stündlich,
täglich
oder wöchentlich ändern, oder
Daten, die sich niemals ändern.
Jeder Server verwendet ein Subsystem 300 der persistenten
Speicherung, das in dem nachfolgenden Abschnitt 7.1 ausführlich beschrieben
wird, um Daten aus dem persistenten Speicher 230 zu lesen
und Daten in diesen zu schreiben.
-
Die
von dem persistenten Speicher 230 gespeicherten Daten können für Zuverlässigkeitszwecke
physisch oder logisch dupliziert werden. Zum Beispiel kann durch
Verwendung einer Menge redundanter gespiegelter Datenträger, die
jeweils eine Kopie der Daten bereitstellen, physische Redundanz
bereitgestellt werden. Bei anderen Ausführungsformen kann die Datenbank
selbst unter Verwendung von standardmäßigen Datenbanktechniken dupliziert
werden, um mehrere Kopien der Datenbank bereitzustellen. Bei weiteren
Ausführungsformen
können
physische und logische Duplikation zusammen benutzt werden.
-
2.2 Dynamischer Speicher
-
Wie
oben beschrieben, speichern die Server 180'' statische" Daten, d. h. Daten,
die über
Client-Sitzungen
hinweg persistieren, in den persistenten Speicher 230.
Das Schreiben in den persistenten Speicher 230 kann relativ
lange Zeiträume
in Anspruch nehmen. Um Zugriffe auf den persistenten Speicher 230 zu
minimieren, können
die Server 180 eine logische gemeinsame Datenbank (d. h.
den dynamischen Speicher 240) entwickeln, die allen Servern 180 in
der Farm 110 zugänglich
ist, um auf bestimmte Arten von Daten zuzugreifen und diese zu speichern.
Der dynamische Speicher 240 kann physisch in dem lokalen
Speicher eines einzelnen oder mehrerer Server 180 in der
Server-Farm 110 implementiert
werden, wie nachfolgend ausführlicher beschrieben
wird. Der lokale Speicher kann Direktzugriffsspeicher, ein Datenträger, eine
Datenträger-Farm, ein
RAID (redundant array for independent disk) oder eine beliebige
andere Speichereinrichtung sein, die das Lesen und Schreiben von
Daten erlaubt.
-
Im
allgemeinen sind in dem dynamischen Speicher 240 gespeicherte
Daten Daten, die in der Regel häufig
während
der Laufzeit abgefragt oder geändert
werden. Beispiele für
solche Daten (die im folgenden als Laufzeitdaten bezeichnet werden)
sind das aktuelle Arbeitslastniveau für jeden der Server 180 in
der Server-Farm 110, der Status der Server 180 in
der Server-Farm 110, Client-Sitzungsdaten und Lizensierungsinformationen.
-
Bei
einer Ausführungsform
umfaßt
der dynamische Speicher 230 eine oder mehrere Tabellen,
die jeweils Aufzeichnungen von Attributwertpaaren speichern. Es
kann eine beliebige Anzahl von Tabellen existieren, aber jede Tabelle
speichert Aufzeichnungen nur eines Typs. Tabellen werden bei bestimmten
Ausführungsformen
durch Namen identifiziert. Bei dieser Ausführungsform beziehen sich somit
zwei Server 180, die denselben Namen zum Öffnen einer
Tabelle verwenden, auf dieselbe logische Tabelle.
-
Bei
weiteren Ausführungsformen
wird jeder Tabellendatensatz eindeutig durch einen Namen identifiziert.
Der Name eines Datensatzes kann eines der Attribute des Datensatzes
sein. Datensätze
können
auch ein Attribut "Typ" enthalten, das für den Typ
des Datensatzes einzigartig ist. Datensätze können durch einen beliebigen
Server 180 erzeugt, aktualisiert, abgefragt oder gelöscht werden.
Ein Beispiel für
eine Datensatztabelle dynamischen Speichers in bezug auf aktive
Client-Sitzungen erscheint nachfolgend:
Tabelle "Client-Sitzungen"
ID_TYPE = "AppName Session"
ID_USER = "MarktT"
ID_XXXX = ...
-
2.3 Kollektorpunkte
-
Der
dynamische Speicher 240 (d. h. die Sammlung aller Datensatztabellen)
kann auf verschiedene Weisen realisiert werden. Bei einer Ausführungsform
ist der dynamische Speicher 240 zentralisiert; das heißt, alle
Laufzeitdaten werden in dem Speicher eines Servers 180 in
der Server-Farm 110 gespeichert. Dieser Server arbeitet
als Master-Netzwerkknoten, mit dem alle anderen Server 180 in
der Farm 110 beim Ersuchen des Zugriffs auf diese Laufzeitdaten
kommunizieren. Bei einer anderen Ausführungsform behält jeder
Server 180 in der Server-Farm 110 eine volle Kopie
des dynamischen Speichers 240. Hierbei kommuniziert jeder
Server 180 mit jedem anderen Server 180, um seine
Kopie des dynamischen Speichers 240 auf dem neuesten Stand zu
halten.
-
Bei
einer anderen Ausführungsform
führt jeder
Server 180 seine eigenen Laufzeitdaten und kommuniziert
mit jedem anderen Server 180, wenn er Laufzeitdaten von
ihnen erhalten möchte.
Zum Beispiel kann somit ein Server 180, der versucht, ein
von dem Client 120 angefordertes Anwendungsprogramm zu
finden, direkt mit jedem anderen Server 180 in der Farm 110 kommunizieren,
um einen oder mehrere Server zu finden, die die angeforderte Anwendung
hosten.
-
Bei
Server-Farmen 110 mit einer großen Anzahl von Servern 180 kann
der durch diese Ausführungsformen
produzierte Netzwerkverkehr groß werden.
Eine Ausführungsform
reduziert den großen
Netzwerkverkehr durch Bestimmen einer Teilmenge der Server 180 in
einer Farm 110 (in der Regel zwei oder mehr) als "Kollektorpunkte". Ein Kollektorpunkt
ist im allgemeinen ein Server, der Laufzeitdaten sammelt. Jeder
Kollektorpunkt speichert Laufzeitdaten, die von bestimmten anderen
Servern 180 in der Server-Farm 110 gesammelt wurden.
Jeder Server 180 in der Server-Farm 110 kann als
ein Kollektorpunkt arbeiten und folglich als solcher bestimmt werden.
Bei einer Ausführungsform
speichert jeder Kollektorpunkt eine Kopie des gesamten dynamischen
Speichers 240. Bei einer anderen Ausführungsform speichert jeder
Kollektorpunkt einen Teil des dynamischen Speichers 240,
d. h. er führt
Laufzeitdaten eines bestimmten Datentyps. Der Typ der von einem Server 180 gespeicherten
Daten kann gemäß einem
oder mehreren Kriterien vorbestimmt sein. Zum Beispiel können die
Server 180 verschiedene Typen von Daten auf der Basis ihrer
Boot-Reihenfolge speichern. Als Alternative kann der von einem Server 180 gespeicherte
Typ von Daten von einem Administrator unter Verwendung des Administrationswerkzeugs 140 konfiguriert
werden. Bei diesen Ausführungsformen
wird der dynamische Speicher 240 auf zwei oder mehr Server 180 in
der Farm 110 verteilt.
-
Die
Server 180, die nicht als Kollektorpunkte bestimmt sind,
kennen die Server 180 in einer Farm 110, die als
Kollektorpunkte bestimmt sind. Wie später ausführlicher beschrieben werden
wird, kommuniziert ein Server 180, der nicht als Kollektorpunkt
bestimmt ist, beim Abliefern und Anfordern von Laufzeitdaten mit
einem bestimmten Kollektorpunkt. Folglich vermindern Kollektorpunkte
den Netzwerkverkehr, weil jeder Server 180 in der Farm 110 nicht
mit jedem anderen Server 180, sondern mit einem einzigen
Kollektorpunkt-Server 180 kommuniziert, wenn er versucht,
auf die Laufzeitdaten zuzugreifen.
-
2.4 Serverzonen
-
2B zeigt eine beispielhafte Server-Farm 110 mit
Servern 180, 180', 180'' und 180''', die zu zwei separaten
Zonen 260 und 270 organisiert sind. Eine Zone
ist eine logische Gruppierung von Servern 180 in einer
Server-Farm 110. Bei einer Ausführungsform enthält jede
Zone 260, 270 ihren eigenen dynamischen Speicher 240,
d. h. die Server in jeder Zone führen
eine gemeinsame Datenbank von Laufzeitdaten. Eine Zone 260, 270 enthält eine
Teilmenge der Server 180 in der Server-Farm 110.
Bei der in 2B gezeigten Ausführungsform
enthält
die Zone 260 die Server 180', 180'' und 180''',
und die Zone 270 enthält
den Server 180.
-
Die
Bildung jeder Zone 260, 270 in einer Server-Farm 110 kann
auf Netzwerktopologie basieren. Zum Beispiel können Zonendefinitionen von
den geographischen Standorten der Server 180 abhängen. Jeder
Server 180 bestimmt die Zone 260, 270,
zu der dieser Server 180 gehört. Bei einer Ausführungsform
bestimmt jeder Server 180 seine Zone 260, 270,
wenn er das erste Mal zu der Server-Farm 110 hinzugefügt wird.
Bei anderen Ausführungsformen
kann ein Server 180 wählen,
sich einer anderen existierenden Zone 260, 270 anzuschließen oder
während
der Laufzeit eine neue Zone 260, 270 zu starten.
Bei einer anderen Ausführungsform
kann ein Administrator die Einrichtung von Zonen 260, 270 sowie
Zuweisungen von Servern 180 zu Zonen 260, 270 durch
das Administrationswerkzeug 140 einrichten und steuern.
Bei weiteren Ausführungsformen
können
Server 180 logisch auf der Basis eines oder mehrerer Kriterien,
wie etwa IP-Adresse oder lexikalischer Netzwerkname, zu Zonen gruppiert
werden.
-
Bei
einer Ausführungsform
enthält
jede Zone 260, 270 einen Server 180,
der als Kollektorpunkt zum dynamischen Sammeln eines vorbestimmten
Typs von Daten von den andern Servern 180 in dieser Zone 260, 270 arbeitet.
Beispiele für
Typen von Daten wären
die Lizensierungsinformationen, Ladeinformationen auf diesem Server,
Ladeverwaltungsdaten, Serveridentifikation und -status, Leistungsmetriken,
Gesamtspeicher, verfügbarer
Speicher, Subskriptionsdaten (im Abschnitt 3.5 besprochen) und Client-Sitzungsdaten.
Bei der in 2B gezeigten Ausführungsform
sind die Server 180'' und 180 die
Kollektorpunkte für
die Zonen 260 bzw. 270. In der Zone 260 empfängt zum
Beispiel der Kollektorpunkt 180'' Laufzeitdaten
von den Servern 180''' und 180'. Die gesammelten Daten werden
lokal in einen Speicher in dem Kollektorpunkt 180'' gespeichert.
-
Jeder
Server 180 kann als Kollektorpunkt für mehr als einen Typ von Daten
arbeiten. Zum Beispiel kann der Server 180'' als
Kollektorpunkt für
die Lizensierungsinformationen und für Ladeinformationen arbeiten.
Außerdem
können
mehrere Server 180 gleichzeitig als Kollektorpunkte in
einer gegebenen Zone 260, 270 arbeiten. Bei diesen
Ausführungsformen
kann jeder Kollektorpunkt eine verschiedene Art von Laufzeitdaten ansammeln.
Um zum Beispiel diesen Fall zu veranschaulichen, kann der Server 180''' die
Lizensierungsinformationen sammeln, während der Server 180'' Ladeinformationen sammelt.
-
Bei
bestimmten Ausführungsformen
speichert jeder Kollektorpunkt Daten, die gemeinsam zwischen allen
Servern 180 in einer Form benutzt werden. Bei diesen Ausführungsformen
tauscht jeder Kollektorpunkt eines bestimmten Typs von Daten von
diesem Kollektorpunkt gesammelte Daten mit jedem anderen Kollektorpunkt
für diesen
Typ von Daten in der Server-Farm 110 aus. Nach dem Abschluß des Austauschs
solcher Daten besitzt jeder Kollektorpunkt 180'' und 180 somit dieselben
Daten.
-
Außerdem hält bei diesen
Ausführungsformen
jeder Kollektorpunkt 180 und 180'' auch
jeden anderen Kollektorpunkt auf dem neuesten Stand etwaiger Aktualisierungen
der Laufzeitdaten. Bei bestimmten Ausführungsformen fungieren mehrere
Server 180 in einer Zone 260, 270 als
Kollektorpunkte für
eine bestimmte Art von Daten. Bei dieser Ausführungsform sendet ein Server 180 jede Änderung
der gesammelten Daten zu jedem anderen Kollektorpunkt der Farm 110 rund.
-
Bei
anderen Ausführungsformen
speichert jeder Kollektor Informationen, die gemeinsam zwischen den
Servern 180 benutzt werden, in einer bestimmten Zone 260, 270 einer
Server-Farm 110. Weil nur ein Kollektorpunkt pro Zone 260, 270 notwendig
ist, erfolgt bei diesen Ausführungsformen
kein Austausch gesammelter Daten. Beispiele für gesammelte Daten, die nicht
gemeinsam außerhalb
einer bestimmten Zone 260, 270 benutzt werden,
wären Informationen
in bezug auf gepoolte Zonenlizensen oder Client-Sitzungsdaten, die
abgetrennten Sitzungen entsprechen.
-
3.0 Server-Übersicht
-
Als
kurze Übersicht
zeigt 3 eine Ausführungsform eines der Server 180 in
der Server-Farm 110. Der Server 180 enthält einen
Ereignisbus 310, ein Systemmodul 320, ein Ladermodul 330,
ein Modul gemeinsamer Einrichtungen 340, mehrere Systemdienstmodule 350 und
eines oder mehrere Personalitäts-Subsysteme 300.
Bei der in 3 gezeigten Ausführungsform
sind die Systemdienstmodule 350 als Subsysteme vorgesehen
und enthalten folgendes: ein Dienstmodul 352 des persistenten
Speichersystems; ein Dienstmodul des Dienstlokalisierersystems (im
folgenden "Dienstlokalisierer") 354; ein
Dienstmodul 356 des dynamischen Speichersystems; ein Dienstmodul
des Zonenmanagersystems (im folgenden "Zonenmanager") 358; ein Dienstmodul des
Hostauflösungssystems
(im folgenden "Hostauflöser") 360; und
ein Dienstmodul des Subskriptionsmanagersystems (im folgenden "Subskriptionsmanager") 362, die
alle nachfolgend ausführlicher
beschrieben werden. Bei anderen Ausführungsformen können Systemdienstmodule
als Dienste oder Dämons von
WINDOWS NT bereitgestellt werden. Der Server 180 ist ein
repräsentatives
Beispiel für
die anderen Server in der Server-Farm 110 und für andere
Server in den Server-Farmen 110', 110'' und 110'''.
-
Jedes
Personalitäts-Subsystem 300 ist
ein Softwaremodul, das ein bestimmtes Verhalten oder bestimmte Funktionalität für den Server 180 bereitstellt,
wie etwa Lastverwaltungsdienste. Die bestimmte Menge von auf jedem
der Server 180 installierten Subsysteme 300 definiert
das Verhalten jedes Servers 180 und folglich der Server-Farm 110.
Beispiele für
Personalitäts-Subsysteme, die gemäß der vorliegenden
Erfindung nützlich
sind, wären:
ein (nachfolgend im Abschnitt 7.3 beschriebenes) Gruppensubsystem,
ein (nachfolgend im Abschnitt 7.4 beschriebenes) Beziehungssubsystem,
ein (nachfolgend im Abschnitt 7.5 beschriebenes) Lastverwaltungssubsystem,
ein (nachfolgend im Abschnitt 7.6 beschriebenes) Lizenzverwaltungs-Subsystem,
ein (nachfolgend im Abschnitt 7.7 beschriebenes) Benutzerverwaltungssubsystem,
ein (nachfolgend im Abschnitt 7.8 beschriebenes) ICA-Browser-Subsystem,
ein (nachfolgend im Abschnitt 7.3 beschriebenes) Programmnachbarschafts-Subsystem,
ein (nachfolgend im Abschnitt 7.10 beschriebenes) Subsystem spezialisierter
Anwendungen, ein (nachfolgend im Abschnitt 7.10 beschriebenes) Subsystem
spezialisierter Server, ein (nachfolgend im Abschnitt 7.10 beschriebenes)
Subsystem gemeinsamer Anwendungen und ein (nachfolgend im Abschnitt
7.10 beschriebenes) Subsystem gemeinsamer Server, ein (nachfolgend
im Abschnitt 7.11 beschriebenes) Subsystem gemeinsamer Zugangspunkte
und ein (nachfolgend im Abschnitt 7.12 beschriebenes) Administrations-Subsystem.
Die Funktionalität
verschiedener Subsysteme 300 wird bei einer anderen Ausführungsform
in einem einzigen Subsystem kombiniert. Außerdem soll die Funktionalität des Servers 180 nicht auf
die aufgeführten
Subsysteme 300 beschränkt
werden.
-
Im
allgemeinen kommunizieren die Subsysteme 300 miteinander
und mit den Systemdienstmodulen 350, wenn sie als Subsysteme
vorgesehen sind, durch Erzeugen und Senden von Ereignisnachrichten,
die in der gesamten vorliegenden Beschreibung auch als Ereignisse
bezeichnet werden, über
den Ereignisbus 310. In der vorliegenden Beschreibung ist
der Ausdruck "Ereignis" allgemein genug,
um eine beliebige Art von Nachricht oder Paket mit Steuerinformationen
(wie zum Beispiel der Identität
des Quellensubsystems und des Zielsubsystems) und mit Daten einzuschließen. Ereignisse
werden in Verbindung mit 7A–7B ausführlicher
beschrieben. Die Subsysteme 300 können auch ohne Verwendung des
Ereignisbusses 310 unter Verwendung einer durch die Systemdienstmodule
bereitgestellten internen API 302 mit den Systemdienstmodulen 350 kommunizieren.
Bei einer Ausführungsform
ist jedes Subsystem 300 entweder ein Ein-Thread- oder eine Mehrfach-Thread-Subsystem.
Ein Thread ist ein unabhängiger,
in einer Multitasking-Umgebung ausgeführter Ausführungs-Stream. Ein Ein-Thread-Subsystem 300 kann
nur einen Thread auf einmal ausführen.
Ein Mehrfach-Thread-Subsystem 300 kann mehrere gleichzeitig
ausgeführte
Threads unterstützen,
d. h. ein Mehrfach-Thread-Subsystem 300 kann
mehrere Aufgaben gleichzeitig ausführen.
-
3.1 Das Modul der gemeinsamen Einrichtungen
-
Das
Modul 340 der gemeinsamen Einrichtungen stellt gemeinsame
grundlegende Funktionalität
bereit, die für
alle Subsysteme 300 und Systemdienstmodule 350 nützlich ist,
darunter, aber ohne Einschränkung, Pufferverwaltung,
Mehrfach-Thread-Rahmendienste, Verwaltung eindeutiger Kennungen
und Datenstrukturverwaltung. Eine Mehrfach-Thread-Rahmeneinrichtung
stellt Dienste zur Verwaltung von Semaphoren und zum Synchronisieren
mit folgendem bereit: Semaphoren; Betriebssystemereignisse; und
kritische Abschnitte. Ein Mehrfach-Thread-Rahmen stellt außerdem Dienste
zum Erzeugen, Starten und Stoppen von Threads bereit. Bei einer
Ausführungsform
wird die Mehrfach-Thread-Rahmeneinrichtung als Klasse von C++ oder
Java bereitgestellt. Das Modul 340 gemeinsamer Einrichtungen
stellt außerdem
Funktionen bereit, die es den Subsystemen 300 erlauben,
gemeinsame Datenstrukturen zu konstruieren, zu vernichten und zu
verwalten, darunter Warteschlangen, Hash-Tabellen, Verbundlisten,
Tabellen, Sicherheitsobjekte und andere Standard-Datenobjekte.
-
Eine
Pufferverwaltungseinrichtung 345 stellt gleichförmige Datenpufferdienste
bereit, mit denen jedes Subsystem 300 Ereignisse in den
Ereignispuffern 380, 380' (allgemein 380) speichert.
Bei einer Ausführungsform
wird die Pufferverwaltungseinrichtung 345 als Basisklasse
von C++ bereitgestellt. Bei einer anderen Ausführungsform wird die Pufferverwaltungseinrichtung 345 als
eine Java-Klasse bereitgestellt. Beispiele für Dienste, die durch die Pufferverwaltungseinrichtung 345 bereitgestellt
werden können,
wären Initialisierung, Zuteilung,
Rückgängigmachen
einer Zuteilung, Umbemessung und Duplikation von Puffern.
-
Bei
einer Ausführungsform
ist die Implementierung des Ereignispuffers 380 im lokalen
Speicher 325 des Servers 180, der jedem der Subsysteme 300 und
den Systemdienstmodulen 350 des Servers 180 zugänglich ist.
Bei dieser Ausführungsform
wird, wenn ein Subsystem 300 ein Ereignis erzeugt, dynamisch
ein Ereignispuffer 380 spezifisch zum Speichern dieses
Ereignisses erzeugt. Obwohl in 3 nur
zwei Ereignispuffer 380 gezeigt sind, versteht sich, daß die Anzahl
der bereitgestellten Ereignispuffer 380 nur durch die Menge
an zum Speichern von Ereignispuffern 380 verfügbarem lokalem
Speicher begrenzt wird. Jedes Subsystem 300, das das Ereignis
benutzt, führt
einen Refenzzeiger auf den Ereignispuffer 380, der das
Ereignis speichert. Zeiger auf einen Ereignispuffer 380,
statt das Ereignis selbst, werden von einem Subsystem 300 an
ein anderes Subsystem 300 abgeliefert, um die Menge an über den
Ereignisbus 310 geführten
Informationen zu minimieren. Bei dieser Ausführungsform führt der
Ereignispuffer 380 einen Refenzzählwert, der es jedem empfangenden
Subsystem 300 erlaubt, zu bestimmen, ob kein anderes Subsystem 300 das
in dem Ereignispuffer 380 gespeicherte Ereignis referenziert.
Der Empfänger
eines Ereignisses kann es aus dem Ereignispuffer 380 löschen, wenn
kein anderes Subsystem dieses Ereignis referenziert.
-
Bei
anderen Ausführungsformen
führt jedes
Subsystem 300 seine eigene Kopie eines Ereignisses. Der
Ereignispuffer 380 ermöglicht
es seinen jeweiligen Subsystemen 300, die Daten bezüglich des
Ereignisses in den Ereignispuffer 380 zu schreiben und
anderen Subsystemen 300, solche Daten zu lesen. Wenn ein
Subsystem 300 ein Ereignis erzeugt, wird ein Ereignispuffer 380 dynamisch
spezifisch dafür
erzeugt, dieses Ereignis zu speichern. Bei diesen Ausführungsformen
löscht
jedes Subsystem 300 ein Ereignis aus dem Ereignispuffer 380,
nachdem es das Ereignis gelesen hat oder wenn das Ereignis oder
ein Zeiger auf das Ereignis zu einem abgesetzten Server gesendet
wird. Diese Ausführungsform
ermöglicht
es im wesentlichen mehreren Subsystemen 300 gleichzeitig,
auf dieselben Ereignisinformationen zuzugreifen.
-
3.2 Subsystem-Kommunikation unter Verwendung
des Ereignisbusses
-
Der
Ereignisbus 310 stellt einen Kommunikationspfad zum Übermitteln
von Ereignissen zwischen den Subsystemen 300 des Servers 180 und
zum Übermitteln
von Ereignissen zu Subsystemen 300, die auf anderen Servern 180', 180'', 180''' in der Server-Farm 100 residiert
sind. Der Ereignisbus 310 enthält bei einer Ausführungsform
ein Ereignisablieferungsobjekt 312 und eine Transportschicht 318.
Ereignisablieferungsobjekt 312 liefert Ereignisse zwischen
Subsystemen 300 auf demselben Server 180 (d. h.
lokalen Subsystemen) ab, und die Transportschicht 318 liefert
Ereignisse an andere Server 180', 180'', 180''' (d.
h. abgesetzte Subsysteme) ab. Die Transportschicht 318 verwendet
einen Transportmechanismus wie etwa TCP/IP, UDP/IP, HTTP, Ethernet
oder ein beliebiges anderes Netzwerktransportprotokoll zum Senden
oder Empfangen von Ereignissen zu und von den Transportschichten
der anderen Server 180', 180'', 180'''. Bei einer
anderen Ausführungsform
wird die Transportschicht 318 als ein weiteres Subsystem 300 implementiert,
das über
den Ereignisbus 310 mit den anderen Subsystemen 300 des
Servers 180 kommuniziert.
-
Bei
einer Ausführungsform
wird jedem Subsystem-"Typ" eine vorbestimmte
Kennung zugewiesen. Bei anderen Ausführungsformen erzeugt jedes
Subsystem eine globale eindeutige Kennung, die dieses Subsystem
zonenweit, farmweit, unternehmensweit oder weltweit identifiziert,
oder sie wird ihm zugewiesen.
-
Bei
bestimmten Ausführungsformen
besitzt jedes Subsystem 300 eine eindeutige Subsystemkennung.
Bei diesen Ausführungsformen
enthält
das Ereignisablieferobjekt 312 eine Dispatch-Tabelle 316,
die jede Subsystemkennung an einen jeweiligen mit dem Subsystem 300 assoziierten
Eingangspunkt anbindet. Das Ereignisablieferobjekt 312 sendet
Ereignisse unter Verwendung des Eingangspunkts an die Subsysteme 300 aus.
Bei einer Ausführungsform
ist der Eingangspunkt eine (nicht gezeigte) mit dem Subsystem assoziierte
Ereigniswarteschlange. Bei anderen Ausführungsformen ist der Eingangspunkt
ein Zeiger auf eine durch ein Subsystem 300 bereitgestellte
API, wie im Abschnitt 3.2.2 beschrieben. Im allgemeinen leitet das
Ereignisablieferobjekt 312 einen Ereigniszeiger zwischen
den Subsystemen 300 auf demselben Server 180 weiter,
so daß das
empfangene Subsystem bzw. die empfangenen Subsysteme auf die Speicherstelle
in dem lokalen Speicher 325 (d. h. dem Ereignispuffer 380)
zugreifen können,
an der das Ereignis gespeichert ist.
-
Bei
Ausführungsformen,
bei denen Ereigniswarteschlangen verwendet werden, werden durch
das Ereignisablieferobjekt 312 an das entsprechende Subsystem 300 abgelieferte
Ereignisse in der Reihenfolge in der Ereigniswarteschlange gespeichert,
in der diese Ereignisse aus dem Ereignisablieferobjekt 312 empfangen
werden. Um Ereignisse in die Ereigniswarteschlangen einzureihen,
ruft das Ereignisablieferobjekt 312 eine "QueueEvent"-Funktion auf. Bei
einer Ausführungsform
akzeptiert die QueueEvent-Funktion als Eingangsparameter einen Zeiger
auf den Ereignispuffer 380, der das in die Ereigniswarteschlange
einzureihende Ereignis repräsentiert.
Bei einer Ausführungsform
hält jede
Ereigniswarteschlange Zeiger auf die Ereignispuffer 380,
die die Ereignisse speichern. Ereignisse (oder die Zeiger auf die
jeweiligen Ereignispuffer 380) verbleiben in der Ereigniswarteschlange,
bis sie von dem Ereignisablieferobjekt 312 an das entsprechende
Subsystem 300 ausgesendet werden. Ereigniswarteschlangen
erlauben eine Änderung
der Identität
des für
die Ablieferung des Ereignisses verantwortlichen Threads. Das heißt, die
Identität
des Threads, der das Ereignis aus der Ereigniswarteschlange an das
Subsystem 300 aussendet, kann von der Identität des Threads
verschieden sein, der das Ereignis ursprünglich in die Ereigniswarteschlange
eingereiht hat.
-
Bei
einer alternativen Menge von Ausführungsformen können mit
jedem Subsystem 300 zwei Ereigniswarteschlangen (in 3 nicht
gezeigt) assoziiert werden.
-
Bei
diesen Ausführungsformen
empfängt
eine Ereigniswarteschlange ankommende Ereignisse von dem Ereignisablieferobjekt 312,
und die andere empfängt
abgehende Ereignisse aus dem Subsystem 300 zu dem Ereignisablieferobjekt 312.
Bei diesen Ausführungsformen
ruft das Ereignisablieferobjekt 312 ein Ereignis aus einer
mit einem ersten Subsystem assoziierten abgehenden Ereigniswarteschlange
ab und reiht das Ereignis in die mit einem durch das Ereignisablieferobjekt 312 identifizierten
zielsubsystemassoziierte ankommende Ereigniswarteschlange ein.
-
Das
Ereignisablieferobjekt 312 stellt eine Schnittstelle (im
folgenden Ereignisbus API) 392 (siehe Abschnitt 3.2.1)
bereit, durch die jedes Subsystem 300 unter Verwendung
eines Standardprotokolls mit dem Ereignisablieferobjekt 312 kommuniziert.
Jedes Subsystem 300 kann sich in den Ereignisbus 310 „einstecken", weil solche Subsysteme 300 das
Standardprotokoll einhalten. Ferner wird es durch dieses Standardprotokoll möglich, andere
Subsysteme 300, die möglicherweise
erst nach dem Einsatz des Servers 180 in dem Netzwerk entwickelt
werden, ohne weiteres zu dem Server 180 hinzuzufügen, solange
diese später
entwickelten Subsysteme 300 das Standardprotokoll des Ereignisbusses
API 392 einhalten. Der Ereignisbus API 392 kann als
Klasse von C++, als JAVA-Klasse
oder gemeinsam benutzte Bibliothek bereitgestellt werden.
-
Jedes
Subsystem 300 stellt eine DLL (dynamically linked library)
bereit, die eine SAL (subsystem access layer) 304, 304', 304'', 304''' (allgemein 304)
implementiert. Jedes SAL 304 definiert Befehle der Anwendungsprogrammschnittstelle
(API), die von anderen Subsystemen 300 benutzt werden können, um
Ereignisse an das Subsystem 300 auszugeben, das die SAL
bereitstellt. SAL-API-Funktionen
verwenden den Ereignisbus API 392 zum Erzeugen und Senden
von Ereignissen zu anderen Subsystemen 300 und Systemdienstmodulen 350,
die das Ereignisablieferobjekt 312 benutzen. Die SAL 304 anderer
Subsysteme in dem Server 180 werden z. B. unter Verwendung
von "include"- und "library"-Dateien (d. h. ".h"-Dateien, ".dll"-Dateien und ".lib"-Dateien) in das
Subsystem 300 eingebunden, so daß das Subsystem 300 die
für die
Interaktion mit diesen anderen Subsystemen 300 notwendigen
Ereignisse "kennt".
-
Jedes
Subsystem 300 enthält
außerdem
jeweils eine Ereignis-Handler-Tabelle 308, 308', 308'', 308''' (allgemein 308).
Jede Ereignis-Handler-Tabelle 308 bildet an dieses Subsystem 300 gerichtete
Ereignisse auf eine Ereignis-Handler-Routine ab, die dieses empfangene
Ereignis verarbeiten kann. Diese Ereignis-Handler-Routinen stellen die Kernfunktionalität des Subsystems 300 bereit
und werden in der Software des jeweiligen Subsystems 300 implementiert.
Beim Aussenden eines Ereignisses zu dem Subsystem 300 (z.
B. durch die SAL 304 oder durch das Ereignisablieferobjekt 312)
wird eine der Ereignis-Handler-Routinen aufgerufen.
-
Es
folgen Pseudocodebeispiele für
genannte Ereignis-Handler-Routinen,
die beim Auftreten bestimmter Ereignisse aufgerufen werden. Wie
später
ausführlicher
beschrieben werden wird, erhalten Ereignis-Handler-Routinen beim Aufruf
immer einen Zeiger auf einen Ereignispuffer 380, der das
abgelieferte Ereignis speichert. In diesen Beispielen ist der Name
jeder Handler-Routine willkürlich,
suggeriert aber die von dieser Handler-Routine ausgeführte Funktion.
OnGetSampleData(EventBuffer*
pEvent);
OnGetSystemData(EventBuffer* pEvent);
OnSetSampleData(EventBuffer*
pEvent);
OnEnumerateAdminToolObjects(EventBuffer* pEvent);
OnHostUp(EventBuffer*
pEvent);
OnHostUpReply(EventBuffer* pEvent);
-
Es
folgt ein Pseudocodebeispiel für
eine Ausführungsform
einer Handler-Tabelle 308, die Ereignisse auf die obige
Liste von Beispiel-Handler-Routinen abbildet. Jeder Eintrag der
Ereignis-Handler-Tabelle 308 wird durch ein "EVENT_ENTRY"-Makro bereitgestellt.
Das EVENT_ENTRY-Makro nimmt als Parameter eine Kennung des Quellensubsystems,
eine Kennung des durch das Quellensubsystem gesendeten Ereignisses an
und identifiziert die Ereignis-Handler-Routine, die auf das Ereignis
reagiert. Bei einer Ausführungsform
sind Ereigniskennungen Integer, die in einer Header-Datei (z. B.
EventID_Defs.h"),
die zum Zeitpunkt des Kompilierens der Anwendung bereitgestellt
wird, konstante Werte zugewiesen bekommen.
BEGIN EREIGNIS-HANDLER-TABELLE
EVENT_ENTRY
(SourceSubsystem, Event_GetSampleData, OnGetSampleData);
EVENT_ENTRY
(SourceSubsystem, Event_GetSystemData, OnGetSystemData);
EVENT_ENTRY
(SourceSubsystem, Event_GetSampleData, OnGetSampleData);
EVENT_ENTRY
(Administration Tool, Event_EnumerateAdminToolObjects, OnEnumerateAdminToolObjects);
EVENT_ENTRY
(SourceSubsystem, Event_HostUp On-, On-HostUp);
EVENT_ENTRY ((SourceSubsystem,
Event_HostUpReply, On-HostUpReply);
END
EREIGNIS-HANDLER-TABELLE
-
3.2.1 Ereignisbus-API
-
Das
Ereignisablieferobjekt 312 stellt eine Ereignisbus-API 392 bereit,
die es den Subsystemen 300 ermöglicht, Ereignisse zu dem Ereignisablieferobjekt 312 zu
lenken. Die Ereignisbus-API 392 enthält eine "PostEvent"-Funktion.
Die PostEvent-Funktion erlaubt es einem Quellensubsystem 300,
ein Ereignis zur nachfolgenden Ablieferung an ein Zielsubsystem 300 auf
dem Server 180 zu dem Ereignisablieferobjekt 312 zu
senden. Als Eingangsparameter enthält die PostEvent-Funktion einen
Zeiger auf den Ereignispuffer 380, der dafür erzeugt
wurde, dieses Ereignis zu speichern. Bei anderen Ausführungsformen
enthält
die PostEvent-Funktion als weitere Eingangsparameter eine Quellenhostkennung
und eine Zielhostkennung. Bei bestimmten Ausführungsformen fügt das Ereignisablieferobjekt
einen Ereigniszähler
zu der Ereigniswarteschlange des Zielsubsystems hinzu. Bei anderen
Ausführungsformen
umgeht der Ereigniszeiger die Ereigniswarteschlange und wird direkt
zu dem Zielsubsystem 300 ausgesendet. Bei einer Ausführungsform
kehrt die PostEvent-Funktion sofort zurück, sobald das Ereignis zu
einem Zielsubsystem 300 ausgesendet wurde (d. h. die PostEvent-Funktion "blockiert" nicht).
-
Die
PostEvent-Funktion kann einen Statuswert zurückgeben, der den Status der
Ereignisaussendung angibt. Bei Ausführungsformen, bei denen das
Ereignis zu einer Ereigniswarteschlange ausgesendet wird, kann der
Statuswert einen Fehlschlag des Aussendens des Ereignisses, weil
die mit dem Zielsubsystem 300 assoziierte Ereigniswarteschlange
voll ist, abgeben. Bei anderen Ausführungsformen kann die PostEvent-Funktion als Eingabe
einen Zeitgrenzenwert annehmen. Der Zeitgrenzenwert spezifiziert
einen Zeitraum dergestalt, daß,
wenn er ohne erfolgreiche Ereignisablieferung vergeht, die PostEvent-Funktion
angibt, daß sie fehlgeschlagen
ist. Zum Beispiel ist das Ereignisablieferobjekt 312 möglicherweise
nicht in der Lage, ein Ereignis zu einer Ereigniswarteschlange auszusenden,
oder das Ereignisablieferobjekt 312 sendet das Ereignis möglicherweise
zur Fernübertragung
zu der Transportschicht 318 aus. Bei diesen Ausführungsformen
suspendiert der für
das Aussenden des Ereignis verantwortliche Ausführungs-Thread die Ausführung für einen
assoziierten Zeitraum, sobald das Ereignis ausgesendet ist. Das
Betriebssystem benachrichtigt den Thread, wenn die Zeitgrenzenperiode
vergeht. Wenn der Thread nicht vor dem Ablauf der Zeitgrenzenperiode
benachrichtigt wurde, daß das
Ereignis erfolgreich ausgesendet wurde, ist die Aussendung des Ereignisses
fehlgeschlagen.
-
Bei
weiteren Ausführungsformen
kann die PostEvent-Funktion
als Eingabe mehrere Adressen annehmen, die mehrere Ziele für das Ereignis
identifizieren, wie zum Beispiel mehrere Subsysteme 300 auf
demselben Server 180 oder Subsysteme 300, die
auf mehrere Server 180 in der Server-Farm 110 verteilt
sind.
-
Bei
anderen Ausführungsformen
stellt das Ereignisablieferobjekt 312 eine API-Funktion
bereit, die es einem Subsystem erlaubt, Ereignisse von einer mit
diesem Subsystem 300 assoziierten Ereigniswarteschlange "wegzuziehen". Bei diesen Ausführungsformen
werden Ereignisse durch das Ereignisablieferobjekt 312 zur letztendlichen
Verarbeitung durch das assoziierte Subsystem 300 an eine
Ereigniswarteschlange abgeliefert.
-
3.2.2 Subsystem-API
-
Jedes
Subsystem 300 stellt eine Schnittstelle 306 bereit,
mit der das Ereignisablieferobjekt 312 Ereignisse zu diesem
Subsystem 300 aussendet. Die Subsystem-API 306 für jedes
Subsystem 300 enthält
eine "DispatchEvent"-Funktion. Unter
Verwendung der DispatchEvent-Funktion "schiebt" das Ereignisablieferobjekt 312 ein
Ereignis zu dem Subsystem 300, d. h. das Ereignisablieferobjekt 312 leitet
zur Verarbeitung durch eine Ereignis-Handler-Routine einen Ereigniszeiger
zu dem Subsystem 300. Bei Ausführungsformen, bei denen eine
Ereigniswarteschlange mit dem Subsystem 300 assoziiert
ist, schiebt die DispatchEvent-Funktion das Ereignis an den Kopf
der Warteschlange zu dem Subsystem 300 zur Verarbeitung
durch eine Ereignis-Handler-Routine.
-
3.2.3 Dispatch-Tabelle
-
Die
Dispatch-Tabelle 316 stellt einen Routingmechanismus für das Ereignisablieferobjekt 312 zum
Abliefern von Ereignissen an die beabsichtigten Subsysteme 300 des
Servers 180 bereit. Mit Bezug auf 4A und
genauer gesagt enthält
die Dispatch-Tabelle 316 einen Eintrag 420 für das Systemmodul 320 und
jedes Systemdienstmodul oder Subsystem 300. Jeder Eintrag 420 enthält ein Zielsubsystemfeld 424 und
ein Dispatch-Adressenfeld 428 zur
Abbildung eines der Subsysteme 300, eines der Systemdienstmodule 350 oder des
Systemmoduls 320 auch eine mit diesem Subsystem assoziierte
Dispatch-Adresse. Bei einer Ausführungsform
ist die Dispatch-Adresse die Adresse einer mit dem Systemmodul 320,
einem der Subsysteme 300 oder einem der Systemdienstmodule 350 assoziierten
Ereigniswarteschlange. Bei bestimmten Ausführungsformen enthält die Dispatch-Tabelle 316 weitere
Informationen, wie etwa ein Flag, das angibt, ob das entsprechende
Subsystem dafür
implementiert wurde, Mehrfach-Thread-Ausführung
(nicht gezeigt) auszunutzen. Eine beispielhafte Abbildung von Subsystemen 300,
Systemmodul 320 und Systemdienstmodulen 350 auf Dispatch-Adressen
ist in 4A dargestellt.
-
Zur
Veranschaulichung dieser Abbildung erscheinen in dem Zielsubsystemfeld 424 Namen,
die jeweils den Subsystemen 300, dem Systemmodul 320 und
den Systemdienstmodulen 350 entsprechen, und in dem Dispatch-Adressenfeld 428 erscheinen
Namen, die ihren assoziierten Dispatch-Adressen entsprechen. Es
versteht sich, daß die
Implementierung der Dispatch-Tabelle 316 Zeiger auf die
Adressen der Zielsubsysteme 300, das Systemmodul 320,
die Systemdienstmodule 350 und entsprechende Dispatch-Adressen
verwenden kann. Das Ereignisablieferobjekt 312 füllt die
Einträge 420 der
Dispatch-Tabelle 316 während
der Initialisierung des Servers 180 mit Abbildungsinformationen.
-
3.3 Direkte Subsystem-Kommunikation
-
Bei
bestimmten Ausführungsformen
kommunizieren die Subsysteme 300 direkt mit den Systemdienstmodulen 350,
ohne den Ereignisbus 310 zu verwenden. Bei diesen Ausführungsformen
stellen die Systemdienstmodule 350 eine interne API 302 bereit,
die direkt von lokal, d. h. auf demselben Server 180, residenten Subsystemen 300 aufgerufen
werden kann. Die interne API 302 kann dieselben Funktionsaufrufe
wie die oben beschriebene Ereignisbus-API 392 bereitstellen.
Als Alternative kann die interne API 302 eine Teilmenge
oder eine Übermenge
der durch die Ereignisbus-API 392 bereitgestellten Funktionen
bereitstellen.
-
3.4 Dienstmodul des persistenten Speichersystems
-
Wie
oben in Verbindung mit 2A und 3 beschrieben,
verwenden die Server 180 einen persistenten Speicher 230,
um statische Daten zu führen.
Ein Dienstmodul 352 des persistenten Speichersystems dient
als der Mechanismus, der es anderen Subsystemen 300 erlaubt,
auf Informationen aus dem persistenten Speicher 230 zuzugreifen.
Das Dienstmodul 352 des persistenten Speichersystems übersetzt
Subsystemanforderungen in Datenbankanforderungen. Bei einer Ausführungsform
führt die
Datenbank mehrere verteilte Speichersysteme zusammen, um den persistenten.
Speicher 230 zu bilden. Zum Beispiel kann die Datenbank als
eine von Oracle Corporation in Redwood City, Kalifornien, hergestellte
ORACLE-Datenbak bereitgestellt werden. Bei anderen Ausführungsformen
kann die Datenbank eine Mikrosoft-ACCESS-Datenbank oder eine Microsoft-SQL-Serverdatenbank sein.
-
Das
Dienstmodul 352 des persistenten Speichersystems versorgt
Datenanforderungen oder -schreiboperationen in den persistenten
Speicher 230, die von vielfältigen potentiell ungleichen
anfordernden Entitäten
empfangen werden. Die anfordernden Entitäten residieren auf Servern 180,
die Teil derselben Server-Farm wie der persistente Speicher 230 sind.
Die anfordernden Entitäten
können
auch auf Plattformen residieren, die normalerweise nicht mit der
der Datenbank kompatibel sind, die den persistenten Speicher 230 bereitstellt.
-
Um
Datenanforderungen von ungleichen Entitäten zu versorgen, übersetzt
das Dienstmodul 352 des persistenten Speichersystems unter
Verwendung eines externen Datenmodells gestellte Anforderungen in eine
Datenbankanforderung unter Verwendung des internen Datenmodells,
das von der den persistenten Speicher 230 bereitstellenden
Datenbank benutzt wird. Jede der anfordernden Entitäten integriert
ihr konkretes externes Datenmodell in ein Ereignis, das zu dem Dienstmodul 352 des
persistenten Speichersystems gesendet wird. Bei bestimmten Ausführungsformen
approximiert das interne Datenmodell die externen Datenmodelle gut,
so daß Elemente
des internen Datenmodells als primitive Blöcke beim Aufbau des externen
Datenmodells verwendet werden können,
wenn auf eine Anforderung geantwortet wird.
-
Das
Dienstmodul 352 des persistenten Speichersystems setzt
im wesentlichen eine von der anfordernden Entität in einem externen Datenmodellformat überreichte
Ereignisnachricht in ein lokal verstandenes internes Datenmodellformat
um und umgekehrt, um die Anforderung zu versorgen. Die von dem Dienstmodul 352 des
persistenten Speichersystems unterstützten internen und externen
Datenmodelle können
zum Beispiel dem LDAP-Datenmodell
(lightweight directory access protocol) oder anderem Protokoll oder
Datenbankformaten entsprechen. Die Möglichkeit, externe Datenmodelle
von einer Anzahl verschiedener anfordernder Entitäten in ein
einziges internes Datenmodell umzusetzen (und umgekehrt) ermöglicht es
dem Dienstmodul 352 des persistenten Speichersystems, gleichförmigen Zugang
zu in dem persistenten Speicher 230 gespeicherten Daten
bereitzustellen.
-
Die
typischerweise in der persistenten Speicherung 230 gespeicherten
Informationen sind zum Beispiel Systemkonfigurationsinformationen,
Sicherheitsinformationen, einer bestimmten Server-Farm 110 gemeinsame
Anwendungseinstellungen, Anwendungshierarchie, gemeinsame Anwendungsobjekte
und eindeutige Kennungen für
jedes gespeicherte Objekt. Bei einer Ausführungsform können die
gespeicherten Informationen als Einträge organisiert werden, die
bestimmte Objekte repräsentieren,
wie zum Beispiel einen Server 180, ein Subsystem 300 oder
einen Benutzer. Jeder Eintrag enthält eine Sammlung von Attributen,
die Informationen über
das Objekt enthalten. Jedes Attribut weist einen Typ und einen oder
mehrere Werte auf. Der Attributtyp ist mit einer bestimmten Syntax
assoziiert, die die Art von Werten spezifiziert, die für dieses
Attribut gespeichert werden können.
-
Bei
einer Ausführungsform
können
die Objekte in dem persistenten Speicher
230 in einer Datenbankdatei
gespeichert werden, und bei dieser Ausführungsform kann der persistente
Speicher
230 unter Verwendung traditioneller Datenbankanforderungen
durchsucht werden. Bei einer anderen Ausführungsform wird der besondere
Name der angeforderten Daten, der durch das externe Datenmodell
spezifiziert wird, auf das in dem persistenten Speicher
230 gespeicherte
implizite oder vordefinierte Schema abgebildet. Das vordefinierte Schema
kann ein oder mehrere Felder enthalten, die eine Anordnung der Objekte
in der Datenbank als eine Baumdatenstruktur (z. B. als binären Baum)
erlauben. Zum Beispiel kann jeder Eintrag in dem persistenten Speicher
230 ein
Feld "ParentID", ein Feld "NodeID" und ein Feld "NodeName" enthalten, wie in
der nachfolgenden Tabelle 1 gezeigt, wodurch der persistente Speicher
230 als
eine Baumdatenstruktur durchsucht werden kann. Bei dieser Ausführungsform
kann jedes in dem persistenten Speicher
230 gespeicherte
Objekt ein Attribut aufweisen, das den Ort des Objekts in dem Baum
spezifiziert. Dieser Ort kann eine absolute Position in dem Baum
in bezug auf den Wurzelknoten oder relativ zu den Orten anderer
Objekte in dem Baum (z. B. relativ zu einem übergeordneten Knoten) sein.
Tabelle 1 zeigt eine beispielhafte Anordnung von Objekten in dem
persistenten Speicher
230, die wie ein Baum durchquert
werden kann: TABELLE 1
Parent
Node ID | Node
ID | Node
Name |
Keine | 0 | Root
(impliziert) |
0 | 1 | farm_1 |
0 | 2 | farm_2 |
1 | 3 | Authorized_users |
2 | 4 | Authorized_users |
3 | 5 | user_1 |
4 | 6 | user_1 |
-
Damit
nicht bei jedem Zugriff auf ein Objekt in den persistenten Speicher 230 der
gesamte Baum durchquert werden muß, kann sich ein anforderndes
Subsystem 300 dynamisch an einen bestimmten Knoten in dem
Baum anbinden, um als Ausgangspunkt für die Durchquerung des Baums
zu dienen. Der bestimmte Knoten in dem Baum hängt von der Art des Subsystems
ab. Im allgemeinen gehört
jedem Subsystem 300 ein Teil des Baums, das heißt, dem
Subsystem gehören
diejenigen Objekte, die es in dem Baum gespeichert hat. Der bestimmte
Knoten kann somit als Wurzelknoten für Objekte, die dem Subsystem
gehören,
und als Ausgangspunkt wirken, von dem aus diese Objekte durchquert
werden. Zum Beispiel kann sich unter Verwendung von Tabelle 1 ein
Subsystem 300 an den Knoten authorized_users anbinden,
um als Ausgangspunkt für
die Suche nach einem bestimmten Benutzer zu dienen.
-
Als
Anschauungsbeispiel betrachte man, daß das Administrationswerkzeug 140 authentifizieren möchte, ob
ein abgesetzter Benutzer der Server-Farm 110 dafür authorisiert
ist, auf ein Anwendungsprogramm auf einem bestimmten Server 180,
der Teil dieser Server-Farm 110 ist, zuzugreifen. Das Administrationswerkzeug 140 leitet
ein (nicht gezeigtes) Administrations-Subsystem an, eine Ereignisnachricht über den
Dienstlokalisierer 354 und das Ereignisablieferobjekt 312 zu
dem Dienstmodul 352 des persistenten Speichersystems zu
senden, um die gewünschten
Informationen zu erhalten. Das Dienstmodul 352 des persistenten
Speichersystems empfängt
und analysiert die Ereignisnachricht, um den (nachfolgend beschriebenen)
besonderen Namen des Eintrags und Attribute, die gerade angefordert
werden, zu erhalten.
-
Das
Format des besonderen Namens entspricht dem von dem Administrations-Subsystem
beim Bilden der Ereignisnachricht verwendeten externen Modell. Ein
Beispiel für
einen solchen besonderen Namen ist "root/farm_name/authorized_users/user_1." Vorausgesetzt, daß die Inhalte
des persistenten Speichers 230 zu einem einzigen Baum organisiert
sind, durchquert das Dienstmodul 352 des persistenten Speichersystems den
Baum, um Informationen über
die authorisierten Benutzer dieser bestimmten Anwendung zu erhalten.
Das Dienstmodul 352 des persistenten Speichersystems durchquert
den Baum "nach unten", um zu bestimmen, ob
der letzte durchquerte Knoten mit dem besonderen Namen übereinstimmt
(in diesem Fall, ob user_1 als authorisierter Benutzer enthalten
ist). Solange der besondere Name in dem externen Modell eine hierarchische Reihenfolge
aufrechterhält,
die einer Baumstruktur (internes Modell) in dem persistenten Speicher 230 entspricht,
müssen
auf diese Weise nicht die individuellen/willkürlichen Formate jedes Elements
des besondere Namens analysiert werden.
-
Dateneigentümerschaft
und Sicherheitsfragen sind auch wichtige Gesichtspunkte beim gemeinsamen Benutzen
einer gemeinsamen persistenten Speicherungsumgebung über mehrere
Subsysteme (anfordernde Entitäten)
hinweg. Das Subsystem 300, das die Quelle der Daten ist,
setzt die Zugangsbeschränkungen über die
SAL API des Dienstmoduls 352 des persistenten Speichersystems,
die die Exponierung der Daten über die
SAL API auf eine authorisierte Teilmenge anfordernder Entitäten begrenzt.
-
3.5 Das Dienstmodul des dynamischen Speichersystems
-
Der
dynamische Speicher 240 wirkt als globale Datenbank, die
jedem Server 180 in einer Zone 260, 270 zugängliche
Datensätze
speichert. Bei einer Ausführungsform
ist jeder gespeicherte Datensatz ein Attributwertpaar. Ein Beispiel
für ein
Attribut ist eine Subsystemkennung; ein Beispiel für einen
Wert ist die tatsächliche
Subsystem-ID-Nummer. Jedes Subsystem 300, das den dynamischen
Speicher 240 benutzt, definiert das Schema der Datensätze, die
für diesen
Subsystemtyp erzeugt und gespeichert werden. Verschiedene Subsysteme
besitzen im allgemeinen verschiedene Schemata. Der erste Aufruf
eines Subsystems 300 an den dynamischen Speicher 240 registriert
das Schema, das ein Subsystem verwenden wird. Danach können alle Subsysteme 300 desselben
Subsystemtyps, die sich bei dem dynamischen Speicher 240 registrieren,
auf die gemäß diesem
registrierten Schema erzeugten Datensätze zugreifen. Als Teil des
Registrierens des Schemas kann ein Subsystem 300 spezifizieren,
welche Attribute zum Suchen verwendet werden können. Bei einer Ausführungsform
identifiziert ein Subsystem 300 ein oder mehrere Attribute,
die häufig
zum Durchsuchen der Datensatztabelle verwendet werden.
-
Bei
einer Ausführungsform
wird jeder Datensatz sowohl durch den Server 180, der den
Datensatz erzeugt, als auch den für das Speichern von Datensätzen dieses
Typs verantwortlichen Server 180 gespeichert. Bei Ausführungsformen,
bei denen mehr als eine Zone 260, 270 in einer
Farm 110 existiert, wird ein Datensatz auf einem Server 180 in
jeder Zone 260, 270 gespeichert, der durch den
Zonen-Master jeder Zone als der Server 180 identifiziert
wird, der Datensätze
dieses Typs speichert. Der Server 180, der den Datensatz
erzeugt, handelt im wesentlichen als redundante Speicherung für den Tabellendatensatz.
Bei bestimmten Ausführungsformen
aktualisiert der Tabelleneigentümer
den Server 180, der den Datensatz erzeugt, mit nachfolgenden Änderungen
an dem Datensatz. In einer Zone 260, 270 ist die
definitive Autorität
bezüglich
des korrekten Werts eines Tabellendatensatzes der Tabelleneigentümer, d.
h. der Server 180, der durch den Zonen-Master für das Speichern
von Datensätzen
dieses Typs gewählt
wird. Zwischenzonen ist die definitive Autorität bezüglich des korrekten Werts eines
Tabellendatensatzes der Tabelleneigentümer in der Zone, woraus der
Datensatz kam. Obwohl es definitive Autoritäten bezüglich des korrekten Werts für einen
Tabellendatensatz gibt, existiert keine definitive Autorität bezüglich der
Inhalte einer Tabelle – die
Inhalte einer Tabelle sind die Vereinigungsmenge aller in der gesamten
Farm 110 gespeicherten Tabellendatensätze.
-
Der
anfordernde Server 180 verwendet seine lokale Kopie des
Datensatzes, wenn sich der Tabelleneigentümer unerwartet ändert, zum
Beispiel wenn der Tabelleneigentümer
abstürzt.
Wenn der Zonenmanager dieses Problem erkennt und einen neuen Tabelleneigentümer bestimmt,
laden die Server 180 in der Server-Farm 110 lokal gespeicherte
Tabellendatensätze
zu dem neuen Eigentümer
herauf.
-
Datensätze können auf
der Basis des Attributs abgefragt werden, und es kann eine beliebige
Anzahl von Datensätzen
aus einer Abfrage zurückgegeben
werden. Wenn ein Server 180 eine Anfrageanforderung empfängt, leitet
er die Anforderung zu dem Tabelleneigentümer weiter, der die Suche ausführt und
die Ergebnisse zurückgibt.
Der Server, aus dem die Anfrage stammte, kann die Suchergebnisse
abhängig
von verschiedenen Kriterien, wie zum Beispiel Konfiguration oder
Datensatzeinheitlichkeitsparametern, cachespeichern.
-
Die
Löschoperation
ist insofern einer Anfrage ähnlich,
als beliebige gültige
Suchparameter verwendet werden können,
um zu spezifizieren, welche Datensätze zu löschen sind. Dies erlaubt Operationen
wie etwa "Löschen aller
Datensätze
von Host ABC".
-
Genau
wie bei einer Anfrageanforderung wird die Löschanforderung zu dem entsprechenden
Tabelleneigentümer
weitergeleitet. Da möglicherweise
bestimmte der gelöschten
Datensätze
auf dem anfordernden Server erzeugt worden sind, gibt der Tabelleneigentümer eine
Liste der Datensätze
zurück,
die tatsächlich
gelöscht
wurden. Dadurch kann der lokale Server 180 lokal gespeicherte
Datensätze
löschen.
-
Wenn
ein Subsystem 300 sein Schema bei dem dynamischen Speicher 240 registriert
(d. h. die Datenstruktur definiert), liefert bei einer Ausführungsform
dieses Subsystem 300 auch einen oder mehrere Parameter,
die Benutzungsinformationen über
Datensätze
spezifizieren. Ein solcher Parameter steuert "Aktualisierungslatenz", das heißt die Häufigkeit,
mit der die Datensätze
aktualisiert werden. Jedes Subsystem 300 auf jedem Server 180 kann
unabhängig
diese Häufigkeit
bestimmen und deshalb kann jeder Server 180 in der Server-Farm 110 dieselben
Informationen in den Datensätzen
sehen, die mit diesem Subsystem 300 assoziiert sind.
-
Ein
weiterer Parameter ist die "Lebenszeit,
nachdem der Ursprungshost nicht mehr anwesend ist". Dieser Parameter
ist dafür
nützlich,
den Datensatz zu führen,
obwohl der Verfasser des Datensatzes nicht mehr aktiv ist. Wenn
die Lebenszeit auf null gesetzt wird, wird der Datensatz sofort
gelöscht,
nachdem der Datensatzeigentümer,
d. h. der für
das Sammeln von Datensätzen
dieses Typs verantwortliche Kollektorpunkt, die Abwesenheit des
Ursprungshosts detektiert hat. Der Datensatzeigentümer ist
das einzige Subsystem, das berechtigt ist, diesen Datensatz zu löschen. Ein
weiterer Parameter ist ein "Lebenszeit"-Parameter, der zu
einer automatischen Löschung
eines Datensatzes durch das Dienstmodul 356 des dynamischen
Speichersystems führt,
wenn die "Lebenszeit" überschritten wird. Die Zeit
beginnt bei der Einfügung
dieses Datensatzes in den dynamischen Speicher 240.
-
Durch
Kommunikation unter den Servern in der Server-Farm 110 besteht eine dynamische
Wahl eines Master-Servers
in jeder in der Server-Farm 110 definierten Zone. Nachdem
der Master-Server gewählt
ist, kennen alle anderen Server in der Zone die Identität des Master-Servers,
wie nachfolgend ausführlicher
beschrieben werden wird.
-
In
jeder Zone existiert mindestens eine Kopie jedes Datensatzes in
dem dynamischen Speicher 240. Bei einer Ausführungsform
speichert der Master-Server der Zone jeden Datensatz im lokalen
Speicher dieses Master-Servers.
Bei einer anderen Ausführungsform
verteilt der Master-Server den dynamischen Speicher 240 in
dem lokalen Speicher 325 bestimmter oder aller der Server 180 in
der Zone auf der Basis des Datensatztyps. Der bestimmte Server ist
somit als der Kollektorpunkt für
diesen Datensatztyp bestimmt.
-
Falls
einer der Server in der Server-Farm ausfällt, wählt der Master-Server einen
neuen Server in der Zone zum Halten den Art von Datensätzen, die
der ausgefallene Server zuvor gehalten hat. Dieser neue Server fordert
eine Aktualisierung dieser Datensätze von jedem anderen Server
in dieser Zone an, um die Datensätze
zu ersetzen, die unzugänglich
wurden, als der Server ausgefallen ist. Da jeder Server eine Kopie
der diesen Server betreffenden Datensätze behält, stellt die Aktualisierung
den Inhalt des dynamischen Speichers 240 wieder her. Wenn
der Master-Server ausfällt,
leitet jeder Server in der Zone, der die Abwesenheit des Master-Servers
detektiert, eine Wahl eines neuen Master-Servers ein.
-
Bei
einer Ausführungsform
sind Master-Server die einzigen Server, die die Master-Server der
anderen Zonen 260, 270 kennen. Um diese Informationen
zu erhalten, fragt jeder Master-Server jeden Server in jeder anderen
Zone 260, 270 ab und ersucht eine Antwort, die
den Master-Server dieser Zone 260, 270 identifiziert. Zonen
werden vorkonfiguriert und die Identität von mit Zonen 260, 270 assoziierten
Servern wird in dem persistenten Speicher 230 gespeichert.
Jeder Master-Server einer Zone 260, 270 sendet
periodisch die Datensätze
in den dynamischen Speicher 240 für diese Zone 260, 270 zu
den Master-Servern in den anderen Zonen 260, 270.
Bei einer anderen Ausführungsform
sendet jeder Server, der die Datensätze hält, eine Kopie dieser Datensätze zu entsprechenden
Servern in den anderen Zonen 260, 270. Diese Server
bestimmen, welches die entsprechenden Server in den anderen Zonen 260, 270 sind,
aus durch den Master-Server
ihre eigenen Zone 260, 270 gesammelten Informationen.
-
3.6 Dienstmodul des Dienstlokalisierersystems
-
Wieder
mit Bezug auf 3 kommuniziert der Dienstlokalisierer 354 über den
Ereignisbus 310 (oder über
seine interne API) mit jedem Subsystem 300. Der Dienstlokalisierer 354 identifiziert
einen Server 180 für die
Versorgung von an andere Subsysteme 300 ausgegebenen Ereignissen.
Der identifizierte Server 180 kann lokal oder abgesetzt
sein. Als kurze Übersicht
kann ein Quellensubsystem 300 ein Ereignis erzeugen oder
ausgeben, für
das der Host des Zielsubsystems erst bestimmt ist, wenn das Quellensubsystem 300 das
Ereignis ausgibt. In diesen Fällen
verwendet das Quellensubsystem 300 entweder einen Aufruf
der SALAPI oder einen Aufruf der internen API, der durch den Dienstlokalisierer 354 bereitgestellt
wird, um entweder (1) die Adresse des Servers 180 zu erhalten,
der das Zielsubsystem 300 hostet, oder (2) anzufordern,
daß der
Dienstlokalisierer 354 im Namen des Quellensubsystems 300 ein
Ereignis an das Zielsubsystem 300 abliefert.
-
Der
Dienstlokalisierer 354 identifiziert einen Zielhost durch
Zugreifen auf in dem dynamischen Speicher 240 geführte Informationen
durch das Dienstmodul 356 des dynamischen Speichersystems
(siehe Abschnitt 3.5). Diese Informationen geben ein zonenweites
Inventar der Serverkomponenten in der Server-Farm 110;
das heißt,
die Informationen geben an, welche Subsysteme (und die Versionen
dieser Subsysteme) auf jedem Server 180 in der Serverzone 260, 270 installiert
sind. Diese Informationen geben außerdem an, welcher dieser Server 180 in
der Zone 260, 270 gerade arbeitet. Durch diese
Informationen kennt der Dienstlokalisierer 154 somit alle
verfügbaren
Subsysteme 300 in der Zone 260, 270.
-
Jeder
Server
180 in der Server-Farm
110 besitzt einen
Dienstlokalisierer
354, der zu den zonenweiten Informationen
in dem dynamischen Speicher
240 beiträgt. Wenn zum Beispiel ein Server
180 betriebsfähig wird,
registriert sich jedes auf dem Server
180 installierte
Subsystem
300 bei dem Dienstlokalisierer
354.
Bei einer Ausführungsform
stellt der Dienstlokalisierer
354 eine "RegisterService"-Funktion bereit, die von einem Subsystem
(entweder durch die SAL API oder die interne API des Dienstlokalisierers
354)
aufgerufen werden kann, um Dienste zu registrieren, die es anderen
Subsystemen bereitstellen kann. Bei einer Ausführungsform registrieren die
Subsysteme
300 bei dem Dienstlokalisierer
354 jede
Version jedes Ereignisses, das das Subsystem
300 verarbeiten
wird. Bei einer anderen Ausführungsform
nimmt die RegisterService-Funktion
als Parameter auch einen Rangwert an, der die relative Wichtigkeit
des Subsystems
300 angibt. Beim Empfang der Registrationsnachricht
erstellt der Dienstlokalisierer
354 einen Eintrag in den
dynamischen Speicher
240 für diese Subsystem
300.
Der Eintrag enthält
die von dem Subsystem bereitgestellten Informationen, wie zum Beispiel
seine Kennung und gegebenenfalls seinen Rang. Die nachfolgende Tabelle
2 zeigt eine Ausführungsform einer
in dem dynamischen Speicher
240 gespeicherten Tabelle. Tabelle 2
Subsystem-ID | Rang | Zone | Host-ID |
FFFF | 1 | A | 0015 |
AAAA | 0 | A | 0012 |
FFFF | 1 | A | 0009 |
AAAA | 0 | A | 0006 |
-
Wenn
ein Server 180 auf kontrollierte Weise herunterfährt, wird
er aus der Zone 260, 270 entfernt und es erfolgt
ein "UnregisterService"-Aufruf an den Dienstlokalisierer 354 durch
jedes Subsystem 300, das auf diesem Server 180 resident
ist. Dieser Aufruf informiert den Dienstlokalisierer 354,
daß diese
Subsysteme nicht mehr in der Zone 260, 270 präsent sind.
Bei bestimmten Ausführungsformen
weist der Dienstlokalisierer 354 den dynamischen Speicher 240 an,
Datensätze
zu verwerfen, die mit einem Server 180 assoziiert sind, der
die Ausführung
auf unnatürliche
Weise beendet, z. B. abstürzt.
-
Um
den Zielhost für
die Versorgung eines Ereignisses zu bestimmen, bestimmt der Dienstlokalisierer 354 bestimmte
Informationen: (1) welche Server 180 die Art von in dem
Ereignis als das Zielsubsystem identifizierten Subsystem hostet,
und (2) welcher dieser Server 180 der Zielhost für die Handhabung
des Ereignisses ist. Nach der Bestimmung des Zielhosts gibt der
Dienstlokalisierer 354 entweder die bestimmte Adresse an
das anfordernde Subsystem 300 zurück oder modifiziert ein empfangenes
Ereignis, um die bestimmte Adresse als Adressierungsinformationen
für das
Ereignis aufzunehmen, und liefert das modifizierte Ereignis zur
Ablieferung an diesen Host an den Ereignisbus 310 ab.
-
Wieder
mit Bezug auf Tabelle 2 ist eine Ausführungsform einer in dem dynamischen
Speicher 240 durch Dienstlokalisierer 354 gespeicherten
Tabelle gezeigt, die Einträge
für zwei
Subsysteme (mit den Kennungen FFFF und AAAA) enthält. Jeder
Eintrag enthält
eine Subsystemkennung, einen Subsystemrang, eine Zonenkennung und
eine Hostkennung. Der Dienstlokalisierer 354 empfängt eine
Anforderung einer Adresse (oder einer Anforderung, ein Ereignis
an einen Host abzuliefern) und greift auf die in dem dynamischen
Speicher 240 gespeicherte Tabelle zu. Bei bestimmten Ausführungsformen
stellt der Dienstlokalisierer 354 zwei Funktionsaufrufe
bereit, die dem anfordenden Subsystem 300 eine Zielhostkennung
zurückgeben: "GetBestHost", der die mit einem
Host, der eine bestimmte Art von Ereignis handhaben kann, assoziierte
Hostkennung zurückgibt;
und "GetBestHostFromList", der eine aus einer
Eingangsliste von Hosts ausgewählte
Zielhostkennung zurückgibt.
Wenn die Tabelle nur einen Eintrag aufweist, für den die Subsystemkennung
mit der in dem API-Aufruf angegebenen Systemkennung übereinstimmt,
wird die Hostkennung aus diesem Tabelleneintrag an das anfordernde
Subsystem 300 zurückgegeben.
Wenn mehr als ein Tabelleneintrag eine übereinstimmende Subsystemkennung
aufweist, d. h. es mehr als einen Host in der Zone gibt, der das
betreffende Ereignis verarbeiten kann, wird auf der Basis einer
vorbestimmten Regel oder Menge von Regeln eine Hostkennung ausgewählt. Zum
Beispiel kann eine Hostkennung zufällig, im Reigenverfahren auf
der Basis des mit dem Tabelleneintrag assoziierten Rangs oder auf
der Basis anderer Informationen, die in der Tabelle gespeichert
werden können,
wie zum Beispiel Netzwerklazenz zum Host, verfügbare Bandbreite des Kanals
zwischen dem anfordernden Subsystem 300 und dem Zielhost
oder geographische Nähe
zu dem anfordernden Subsystem 300, ausgewählt werden.
-
Der
Dienstlokalisierer 354 kann außerdem API-Aufrufe zum Senden
eines Ereignisses zu dem Zielhost im Namen des anfordernden Subsystems 300 bereitstellen.
Bei diesen Ausführungsformen
fügt der Dienstlokalisierer 354,
wenn nur einer der anderen Server in der Zone die identifizierte
Nachricht verarbeiten kann, d. h. es nur einen Eintrag in der Tabelle
gibt, die Hostidentifikation dieses Servers in das Ereignis ein
und sendet das modifizierte Ereignis zur Ablieferung an den Zielhost
zu dem Ereignisbus 310. Wenn mehr als ein anderer Server
in der Zone das Zielsubsystem aufweist, wählt der Dienstlokalisierer 354 einen
der Server unter Verwendung eines beliebigen von vielfältigen Kriterien
wie oben beschrieben, modifiziert das Ereignis wie oben beschrieben
und sendet das modifizierte Ereignis zu dem Zielhost.
-
Unter
Verwendung von Tabelle 2 als spezifisches Beispiel kann ein Subsystem 300 einen
GetBestHost-Aufruf
für ein
Subsystem mit einer Kennung "FFFF" ausgeben. Zwei Server
hosten dieses Subsystem, die durch eine Kennung von 9 und 15 identifiziert
werden. Die Kennung, die einem dieser Hosts entspricht, kann an das
anfordernde Subsystem zurückgegeben
werden. Bei einer Ausführungsform
kann der Systemadministrator erzwingen, daß eines der beiden Subsysteme
gewählt
wird, indem er die "Rang-Werte" in der Tabelle ändert. Wenn
zum Beispiel der mit dem Host "15" assoziierte Eintrag
einen höheren
Rang als der mit dem Host "9" assoziierte Eintrag
aufweist, kann immer Host "15" als der Zielhost
gewählt
werden.
-
3.7 Subskriptionsmanager-Systemdienstmodul
-
Der
Subskriptionsmanager 362 verwaltet Subskriptionen für einen
Server 180. Eine Subskription ist eine stehende Anforderung,
durch die ein subskribierendes Subsystem 300 dem Subskriptionsmanager 362 des
lokalen Servers und/oder den Subskriptionsmanagern abgesetzter Server
publiziert, daß das
subskribierendes Subsystem beim Auftreten eines Ereignisses benachrichtigt
werden möchte.
Die registrierte Subskription identifiziert das Ereignis und das
subskribierte Subsystem, das das Ereignis produziert. Beim Auftreten dieses
Ereignisses sendet der Subskriptionsmanager 362 das Ereignis
zu jedem Subsystem, das eine Subskription dieses Ereignisses registriert
hat, mittels des Ereignisablieferobjekts 312.
-
Der
Subskriptionsmanager 362 verwendet zwei Tabellen zur Verwaltung
von Subskriptionen: (1) eine Lokal-Subskriptionstabelle 450 und
(2) eine Abgesetzt-Subskriptionstabelle 418.
-
3.7.1 Lokale-Subskriptionstabelle
-
Die
Lokal-Subskriptionstabelle 450 residiert in dem lokalen
Serverspeicher 325 und speichert Subskriptionen, für die der
spezifizierte Umfang lokal ist. Unter Verwendung der Lokal-Subskriptionstabelle 450 kann
der Subskriptionsmanager 362 lokale Subsysteme 300 auf
das Auftreten bestimmter Ereignisse auf dem Server 180 hinweisen.
Jedes lokale Subsystem 300 auf einem beleibigen Server 180 kann
anfordern, benachrichtigt zu werden, wenn ein bestimmtes Subsystem
ein bestimmtes Ereignis ausgibt, indem es eine Subskription für dieses
Auftreten in der Lokal-Subskriptionstabelle 450 aufgibt.
-
Mit
Bezug auf 4B und ausführlicher enthält die Lokal-Subskriptionstabelle 450 einen
Eintrag 460 für
jede aufgegebene Subskription. Bei einer Ausführungsform enthält jeder
Eintrag 460 der Lokal-Subskriptionstabelle 450 ein
Ereignisfeld 462, das ein eindeutiges Ereignis identifiziert,
ein Subsystemfeld 464, das das Subsystem identifiziert,
das das eindeutige Ereignis besitzt (d. h. erzeugt) und ein Zielsubsystemfeld 468,
das das Subsystem 300 identifiziert, das das eindeutige
Ereignis subskribiert. 4B zeigt
eine beispielhafte Lokal-Subskription,
bei der das Subsystem 300 ersucht, benachrichtigt zu werden,
wenn das Subsystem 300' ein "I'm Up"-Ereignis
an das Ereignisablieferobjekt 312 aufgibt. Zur Veranschaulichung
dieser Subskription erscheinen in den Feldern 464 bzw. 468 dem
Subsystem 300' und
dem Dienstlokalisierer 354 entsprechende Namen, aber die
tatsächliche
Implementierung dieser Subskription kann Zeiger auf ein solches
Subsystem 300' und
einen solchen Dienstlokalisierer 354 verwenden.
-
3.7.2 Abgesetzt-Subskriptionstabelle
-
In
dem dynamischen Speicher 240 wird eine Abgesetzt-Subskriptionstabelle 480 gespeichert,
die Subskriptionen speichert, die durch spezifische abgesetzte Server
registriert werden oder die einen als zonen- oder farmweit spezifizierten
Umfang aufweisen. Das Plazieren solcher Subskriptionen in dem dynamischen Speicher 240 macht
die Subskriptionen farmweit durch Subskriptionsmanager 362 jedes
zweiten Servers 180 in der Server-Farm 110 zugänglich.
Bei einer Ausführungsform,
die in 4C gezeigt ist, wird die Abgesetzt-Subskriptionstabelle 480 als
drei separate Tabellen implementiert: eine erste Tabelle 480' speichert Subskriptionen
von Ereignissen, die in derselben "Zone" auftreten
können,
eine zweite Tabelle 480'' speichert Subskriptionen
von Ereignissen, die an einer beliebigen Stelle in der Server-Farm 110 auftreten
können,
und eine dritte Tabelle 480''' speichert Subskriptionen von Ereignissen,
die auf einem spezifisch identifizierten abgesetzten Host auftreten
können.
-
Ausführlicher
enthält
jede Tabelle 480', 480'' und 480''' (allgemein 480)
einen Eintrag 484 für
jede aufgegebene Subskription. Bei einer Ausführungsform enthält jeder
Eintrag 484 ein Ereignisfeld 492, das ein eindeutiges
Ereignis identifiziert, ein Subsystemfeld 494, das das
Subsystem identifiziert, das das eindeutige Ereignis besitzt (d.
h. erzeugt), ein Zielsubsystemfeld 496, das das Subsystem 300 identifiziert,
das das eindeutige Ereignis subskribiert, und Subskriptionshostfeld 498,
das den Host des subskribierenden Subsystems identifiziert. Die
Tabelle 480''' enthält ferner eine Quellenhostkennung 488 zum
Identifizieren des spezifischen abgesetzten Hosts, auf dem das subskribierte
Subsystem residiert. 4C zeigt eine beispielhafte
Subskription, bei der das Subsystem 300 ersucht, benachrichtigt
zu werden, wenn das Subsystem 300' eines bestimmten abgesetzten Hostservers 180' ein "I'm Up"-Ereignis
aufgibt. Zur Veranschaulichung dieser Subskription, die in der spezifischen
Abgesetzt-Tabelle 480''' der Abgesetzt-Subskriptionstabelle 480 abgelegt
wird, erscheinen in dem Eintrag 484 den Servern 180, 180' und den Subsystemen 300', 300 entsprechende
Namen, aber die tatsächliche
Implementierung dieser Subskription kann Zeiger auf solche Server 180, 180' und solche
Subsysteme 300', 300 verwenden.
-
Der
Subskriptionsmanager 362 stellt drei Funktionen bereit,
die von anderen Subsystemen 300 aufgerufen werden können: (1)
Subscribe, (2) Unsubscribe und (3) PostNotificationEvent. Bei einer
Ausführungsform
werden diese Funktionen durch die mit dem Subskriptionsmanager 362 assoziierte
SAL aufgerufen. Bei einer anderen Ausführungsform werden die Funktionen
durch die von jedem Subskriptionsmanager 362 bereitgestellte
interne API aufgerufen.
-
3.7.3 Die Funktion Subscribe
-
Wenn
ein Subsystem 300 ein Ereignis eines anderen Subsystems 300 subskribieren
möchte,
ruft das subskribierende Subsystem 300 die Subcribe-Funktion
(entweder über
einen SAL-API-Aufruf oder einen Intern-API-Aufruf) auf, die durch den Subskriptionsmanager 362 bereitgestellt
wird. Die Subcribe-Funktion weist den Subskriptionsmanager 362 an,
eine Subskription entweder in der Lokal-Subskriptionstabelle 450 oder
in der Abgesetzt-Subskriptionstabelle 480 zu registrieren,
die in dem dynamischen Speicher 240 gehalten wird. Das
subskribierende Subsystem 300 spezifiziert den Umfang der
Subskription: lokal, zonen- oder farmweit. Bei einer Ausführungsform
bestimmt der von dem subskribierenden Subsystem 300 verwendete
spezifische SAL-Aufruf den Umfang der Subskription. Bei einer anderen
Ausführungsform
ist. der Umfang ein Eingangsparameter des SAL-Aufrufs. Das Ereignisablieferobjekt 312 des
Ereignisbusses 310 sendet das Subcribe-Ereignis zu dem
Subskriptionsmanager 362 aus.
-
In
der Regel rufen diejenigen Subsysteme 300, die initialisiert
werden, nachdem der Subskriptionsmanager 362 initialisiert
ist, die Subcribe-Funktion während
der Initialisierung solcher Subsysteme 300 auf. Die Subcribe-Funktion
kann auch zu einem beliebigen Zeitpunkt während des Serverbetriebs durch
ein beliebiges Subsystem aufgerufen werden. Eingangspara meter für die Subcribe-Funktion
identifizieren eindeutig das subskribierende Subsystem, das Ereignis,
für das
das subskribierende Subsystem Benachrichtigung anfordert, das zu überwachende
subskribierte Subsystem und wahlweise den Umfang der Subskription.
-
Bei
einer Ausführungsform
können
die Parameter, die das subskribierende und subskribierte Subsystem
eindeutig identifizieren, jeweils als zwei separate Entitäten implementiert
werden: als ein Wert, der das Subsystem 300 identifiziert,
und als ein Wert, der den Host identifiziert, auf dem das Subsystem 300 residiert. Bei
anderen Ausführungsformen
gibt die Subcribe-Funktion einen Ausgangswert zurück, der
den Status der Subskriptionsanforderung, wie zum Beispiel erfolgreich
registriert, repräsentiert.
-
Nach
Empfang des Subcribe-Funktionsaufrufs bestimmt der Subskriptionsmanager 362 den
Umfang der Subskription aus dem Typ des zum Abliefern des Subcribe-Ereignisses
verwendeten SAL-Aufrufs 304. Wenn der Umfang der Subskription
für ein
lokales Subsystem ist, speichert der Subskriptionsmanager 362 einen
entsprechenden Subskriptionseintrag in der Lokal-Subskriptionstabelle 450.
Wenn der Umfang der Subskription abgesetzt ist, kommuniziert der
Subskriptionsmanager 362 über den Ereignisbus 310 mit
dem dynamischen Speichersubsystem 370, um die Subskription
in dem entsprechenden Teil der Abgesetzt-Subskriptionstabelle 480 in
dem dynamischen Speicher 240 zu registrieren.
-
3.7.4 Die Funktion Unsubscribe
-
Ein
subskribierendes System 300 kann eine zuvor registrierte
Subskription aus der Lokal- und der Abgesetzt-Subskriptionstabelle 450, 480 durch
Ausgeben einer Unsubscribe-Funktion an den Subskriptionsmanager 362 entfernen.
Ein solches subskribierendes Subsystem kann die Subskription nur
derjenigen Subskriptionen entfernen, die das Subsystem 300 zuvor
registriert hat. Eingangsparameter für die Unsubscribe-Funktion
identifizieren eindeutig, daß die
Entfernung der Subskription anfordernde Subsysteme, das Ereignis,
für das
subskribierende Subsystem keine Benachrichtigung mehr anfordert,
und das Subsystem, von dem die Subskription entfernt wird. Die Eingangsparameter,
die das subskribierende und das subskribierte Subsystem eindeutig
identifzieren, werden bei einer Ausführungsform als zwei separate
Entitäten
implementiert: als ein Wert, der das Subsystem identifiziert, und
als ein Wert, der den Host identifiziert, auf dem dieses Subsystem residiert.
-
Als
Reaktion auf einen Unsubscribe-Funktionsaufruf durchsucht der Subskriptionsmanager 362 die Lokal-Subskriptionstabelle 450 und
die Abgesetzt-Subskriptionstabellen 480 und entfernt jeden
Eintrag, der der zu entfernenden Subskription entspricht. Um die
Subskription aus den Abgesetzt-Subskriptionstabellen 480 zu
entfernen, sendet der Subskriptionsmanager 362 eine Löschanforderung
zu dem Dienstmodul 356 des dynamischen Speichersystems,
um die Einträge
aus dem dynamischen Speicher 240 zu entfernen. Die Unsubscribe-Funktion gibt einen
Ausgangswert zurück,
der den Status der Entfernung der Subskription, wie zum Beispiel
erfolgreich abgeschlossen, repräsentiert.
-
3.7.5 PostNotificationEvent
-
Bestimmte
Subsysteme 300 produzieren Ereignisse, die von anderen
Subsystemen subskribiert werden können, die für diese Subsysteme lokal und/oder
abgesetzt sind. Nach Ausgabe eines solchen Ereignisses rufen solche
Subsysteme 300 außerdem
eine PostNotificationEvent-Funktion
auf, um eine Kopie dieses Ereignisses zu dem Subskriptionsmanager 362 zu
senden. Der Subskriptionsmanager 362 gibt eine Kopie dieses
Ereignisses an die lokalen oder abgesetzten subskribierenden Subsysteme 300 aus.
Die Subsysteme 300 rufen die PostNotificationEvent-Funktion
gleichgültig,
ob irgendein Subsystem tatsächlich
eine Subskription dieses Ereignisses registriert hat, auf, weil
nur der Subskriptionsmanager weiß, ob ein Ereignis von einem
anderen Subsystem subskribiert wurde.
-
5A zeigt eine Ausführungsform eines von dem Subskriptionsmanager 362 beim
Empfang (Schritt 510) eines Subcribe-Funktionsbefehls verwendeten
Prozesses. Aus dem Ereignistyp bestimmt der Subskriptionsmanager 362 (Schritt 512),
ob der Umfang des Subskriptionsereignisses abgesetzt ist. Wenn die
Subskription keinen abgesetzten Umfang aufweist, speichert der Subskriptionsmanager 362 (Schritt 518)
die Subskription in der Lokal-Subskriptionstabelle 450.
Wenn der Umfang der Subskription abgesetzt ist, bestimmt der Subskriptionsmanager 362 (Schritt 522),
ob das subskribierte Ereignis in der Zone, farmweit oder für einen spezifischen
angesetzten Host ist. Dann fügt
der Subskriptionsmanager 362 (Schritt 526) die
Subskription in die entsprechende Tabelle 480', 480'', 480''' ein. Die eingefügte Subskription
(im folgenden ein Subskriptionsdatensatz) folgt dem durch den Subskriptionsmanager 362 definierten
bestimmten Schema. Zum Entfernen von Subskriptionen aus den Subskriptionstabellen 450 und 580 beim
Empfang eines Unsubcribe-Aufrufs wird ein ähnlicher Prozeß verwendet.
-
5B zeigt eine Ausführungsform eines Prozesses,
der von dem Subscriptionsmananger 362 für jedes durch den Subscriptionsmananger 362 empfangene
PostNotificationEvent (Schritt 550) verwendet wird. Der
Subscriptionsmananger 362 bestimmt (Schritt 554),
ob das Ereignis in der Lokal-Subskriptionstabelle 450 existiert.
Wenn ein oder mehrere lokale Subsysteme das Ereignis subskribiert
haben, erzeugt der Subscriptionsmananger 362 (Schritt 558)
eine an jedes subskribierende lokale Subsystem abzuliefernde Kopie des
Ereignisses. Jede Kopie des Ereignisses wird in ihrem eigenen Ereignispuffer 380 abgelegt.
-
Dann
prüft der
Subscriptionsmananger 362 (Schritt 562) die Zonentabelle 480' auf etwaige
subskribierende Server in derselben Zone. Ähnlich fordert der Subscriptionsmananger 362 Suchen
(Schritte 566 und 570) nach Subskriptionen in
dem farmweiten Teil 480'' bzw. dem spezifischen
Teil 480''' für abgesetzte Hosts in der Abgesetzt-Subskriptionstabelle 480 an.
Bei einer Ausführungsform
gibt der Subscriptionsmananger 362 für jeden Zugriff auf die Abgesetzt-Subskriptionstabellen 480 ein
Ereignis an das Dienstmodul 356 des dynamischen Speichersystems
aus, das die gewünschte
Suche verursacht.
-
Bei
einer Ausführungsform
sendet der Subscriptionsmananger 362, statt den lokalen
dynamischen Speicher 240 direkt zu durchsuchen, eine Kopie
des Ereignisses zu einem Subskriptions-Dispatcher. Der Subskriptions-Dispatcher ist einer
der Server 180 in der Server-Farm 110, der fest
für das
Aussenden von Ereignissen an abgesetzte Subskribierer (d. h. einen
anderen Server in derselben oder einer anderen Zone) zugeordnet
ist. Der Subskriptions-Dispatcher wird als der Zielhost in der Zone
zum Handhaben von subskribierten Ereignissen identifiziert.
-
Für jedes
empfangene Ereignis führt
der Subskriptions-Dispatcher
eine Suchoperation an den Abgesetzt-Subskriptionstabellen 480 in
den dynamischen Speicher 240 aus und ruft alle Subskriptionsdatensätze ab,
die Subskribierern dieses Ereignisses entsprechen. Jeder abgerufene
Subskriptionsdatensatz entspricht einer Subskription. Der Subscriptionsmananger 362 produziert
dann für
jeden abgerufenen Datensatz ein Ereignis, wobei die Identifikation
des subskribierenden Subsystems in das entsprechende Feld in dieses
Ereignis eingefügt
wird.
-
3.8 Das Dienstmodul des Hostauflösungssystems
-
Ein
Subsystem 300 kann Ereignisse auf ein anderes Subsystem,
das auf einem abgesetzten Server residiert, abzielen. Mit dem Ausgeben
solcher Ereignisse assoziierte Parameter wären eine dem abgesetzten Server
entsprechende eindeutige Hostkennung. Der Hostauflöser 360 empfängt solche
Ereignisse von diesen Quellensubsystemen 300 (und bei anderen
Ausführungsformen
von anderen Systemdienstmodulen 350), die anfordern, daß ein besonderer
Name für
den abgesetzten Server erhalten werden soll. Um den besonderen Namen
zu erhalten, sendet der Hostauflöser 360 ein
Ereignis, das die eindeutige Hostkennung enthält, zu dem Dienstmodul 352 des
persistenten Speichersystems. Das Dienstmodul 352 des persistenten
Speichersystems verwendet die eindeutige Hostkennung zum Durchsuchen
des persistenten Speichers 230 nach einem entsprechenden
besonderen Namen und gibt den besonderen Namen und die Portadresse
an den Hostauflöser 360 zurück. Der
Hostauflöser 360 kann
den besonderen Namen und die Portadresse an das Quellensystem 300 zurückgeben
oder das aus dem Quellensystem 300 empfangene Ereignis
zu dem durch den besonderen Namen identifizierten Host im Namen
des Quellensubsystems 300 weiterleiten.
-
3.9 Das Dienstmodul des Zonenmanagersystems
-
Jeder
Server 180 in der Server-Farm 110 enthält einen
Zonenmanager 358, der Zugriffe auf den dynamischen Speicher 240 durch
das Dienstmodul 356 des dynamischen Speichersystems zu
dem Server 180 lenkt, der für das Sammeln von Daten des
in dem Zugriff identifizierten Typs verantwortlich ist. Einer der
Zonenmanager 358 in einer Server-Farm 110 wird
von seinen Peers als Master der Server-Farm 180 gewählt. Wenn
er als Master handelt, bestimmt ein Zonenmanager 358 (1),
welcher Server 180 jeden Typ von Daten sammelt, (2) bestimmt, welche
Server 180 jeden Typ von Daten sammelt, bestimmt, welche
Server 180 in der Farm 110 für die Bereitstellung verschiedener
Netzwerkdienste verantwortlich sind, und (3) identifiziert den Zonen-Master anderer Zonen 260, 270 in
der Farm 110. Wie oben beschrieben, kann der dynamische
Speicher 240 auf mehr als einen Server 180 in
einer Server-Farm 110 verteilt werden.
-
3.9.1 Zuweisung der Eigentümerschaft
verteilter Betriebsmittel
-
Der
dynamische Speicher 240 umfaßt bei einer Ausführungsform
eine oder mehrere durch das Dienstmodul 356 des dynamischen
Speichersystems verwaltete Datensatztabellen. Datensatztabellen
speichern Informationen bezüglich
Server-Farm-Laufzeitdaten, wie zum Beispiel dynamische Subskriptionstabellen
und abgetrennte Sitzungen. Das Dienstmodul 356 des dynamischen
Speichersystems fragt den Zonenmaster ab, um zu bestimmen, welcher
Server 180 in der Zone 260, 270 die verschiedenen
Datensatztabellen speichert.
-
Das
Dienstmodul 356 des dynamischen Speichersystems kann die
Dienste des Zonenmasters durch eine Zonenmasterschnittstelle nutzen,
die bei einer Ausführungsform
einen Dienst mit dem Namen GetZoneResourceOwner bereitstellt. Dieser
Dienst nimmt als Eingabe eine eindeutige Zeichenkettenkennung eines
beliebigen Betriebsmittels an und gibt die Identität des Servers 180 zurück, der
ein gegebenes Betriebsmittel besitzen sollte. Der dynamische Speicher 230 kann
somit GetZoneResourceOwner aufrufen, den Namen der Datensatztabelle
des dynamischen Speichers, dessen Eigentümer gewünscht wird, weiterleiten, und
der Zonenmaster gibt die Identität
des Servers 180 zurück,
der dieses Betriebsmittel besitzt, d. h. der die Datensätze des dynamischen
Speichers 230 für
dieses Betriebsmittel speichert.
-
Bei
weiteren Ausführungsformen
wählt der
Zonenmaster aus, welcher Server 180 in einer Server-Farm 110 Datensatztabellen
des dynamischen Speichers speichert. Bei diesen Ausführungsformen
kann der Zonenmanager einen Server 180 auf der Basis physischer
Kenngrößen auswählen, wie
zum Beispiel des verfügbaren
Speichers oder anderer Kriterien, wie etwa (entweder logische oder
physische) Nähe
zu den Entitäten,
die die Datensätze
des dynamischen Speichers anfordern. Bei anderen dieser Ausführungsformen kann
der Zonenmaster während
des Server-Farmbetriebs ändern,
welcher Server 180 die Datensatztabelle speichert.
-
3.9.2 Zuweisung der Eigentümerschaft
von Netzwerkdiensten
-
Bei
bestimmten Ausführungsformen
können
bestimmte von Dienstmodulen bereitgestellte Dienste zentralisiert
werden, um es allen Servern 180 in einer Zone 260, 270 zu
erlauben, eine Dienstanforderung direkt an denselben Zonenserver
zu stellen. Ein Beispiel hierfür
wäre ein
Lizensierungsserver. In diesem Beispiel würden alle Anforderungen einer
Lizenz zu einem einzigen Server 180 in der Zone 180 geleitet.
-
Das
Dienstmodul 354 des Dienstlokalisierersystems verfolgt,
welche Dienste auf welchen Servern 180 in der Zone 260, 270 verfügbar sind.
Obwohl bei einer Ausführungsform
der Hauptzweck des Dienstmoduls 354 des Dienstlokalisierersystems
darin besteht, den "besten" Host für einen
gegebenen Dienst zu finden, der auf vielen Servern 180 in
der Zone 260 verfügbar
sein kann, ist es auch für
das Senden von Nachrichten zu zentralisierten Dienstmodulen verantwortlich.
Die Bestimmung, welcher der Mitgliederserver der Zone für die Handhabung
eines gegebenen zentralisierten Dienstes verantwortlich sein soll,
erfolgt durch den Zonenmaster ähnlich
wie er die Eigentümerschaft
von Zonenbetriebsmittels zuweist. Das Dienstmodul 354 des
Dienstlokalisierersystems somit den Zonenmaster zum Bestimmen, wohin
Anforderungen solcher Dienste geleitet werden sollen.
-
Eine
Master-Wahl kann erfolgen, wenn ein neuer Server zu einer Zone 260, 270 hinzugefügt wird.
Als Alternative kann jeder Zonenmanager 358 eine Wahl einleiten,
wenn der Master nicht auf eine Anfrage antwortet, d. h. der Master
ausgefallen ist.
-
Bei
einer Ausführungsform
kann jeder Zonenmanager 358 eine Wahl zu jedem Zeitpunkt
erzwingen, indem er ein Wahlanforderungsereignis rundsendet. Die
Wahlergebnisse werden durch einen Vergleich der Menge von Wahlkriterien
bestimmt, die in dem Wahlanforderungsereignis gesendet werden, das
von dem anfordernden Zonenmanager 358 mit der Menge von
Wahlkriterien gesendet wird, die auf jedem empfangenden Zonenmanager 358 geführt werden.
Das heißt,
das erste Wahlkriterium aus dem Ereignis des anfordernden Zonenmanagers 358 wird
von dem empfangenden Zonenmanager 358 mit dem ersten Kriterium
des empfangenden Zonenmanagers 358 verglichen. Die höchste Einstufung
der beiden Kriterien, die verglichen werden, gewinnt den Vergleich
und der Zonenmanager 358 mit diesem Kriterium gewinnt die
Wahl. Wenn die beiden Kriterien gleichziehen, werden dann die nächsten Kriterien
sequentiell verglichen, bis der Gleichstand aufgelöst ist.
-
Die
Auswahlkriterien können
darin bestehen, ob der Zonenmanager 358 statisch als Master
konfiguriert ist; ob der Zonenmanager 358 auf dem am nächsten laufenden
Server resident ist; und ob der Server, auf dem der Zonenmanager 358 resident
ist, einen lexikalisch niedrigeren Netzwerknamen aufweist.
-
Die
Interaktion des Zonenmanagersystemdienstes und der Dienstmodule 358, 356 des
dynamischen Speichersystems zum Verwalten des dynamischen Speichers 240 und
zum Zugreifen auf diesen wird nachfolgend ausführlicher besprochen (siehe
Abschnitt 6.3).
-
3.10 Systemmodul
-
Das
Systemmodul 320 ist ein ausführbares Programm (.exe), das
das Booten des Servers 180 verwaltet. Wie jedes Subsystem 300 ist
das Systemmodul 320 adressierbar (d. h. kann das Ziel eines
Ereignisses sein) und enthält
eine Ereigniswarteschlange 324 zum Empfangen von Ereignissen,
wie etwa „SetListeningPort", das die Transportprotokoll-Portadresse
setzt, auf der die Transportschicht 260 nach Kommunikationsereignissen „horcht". Ein weiteres Beispiel
für ein
Ereignis, das zu dem Systemmodul 320 gelenkt werden kann,
ist „LoadSubsystem", das das Systemmodul 320 anweist,
ein Subsystem zu laden. Bei der Ausführung initialisiert das Systemmodul 320 das
Ereignisablieferobjekt 312, die Transportschicht 318 und
das Ladermodul 330. Das Systemmodul 320 bindet
außerdem
die Transportschicht 318 an das Ereignisablieferobjekt 312 an.
Bei einer Ausführungsform
wird das Systemmodul als Dienst von WINDOWS NT bereitgestellt. Bei
einer anderen Ausführungsform
wird das Systemmodul 320 als Unixdaemon bereitgestellt.
-
3.11 Der Lader
-
Das
Ladermodul 330 ermöglicht
eine Anpassung des Ereignisbusses 310 für verschiedene Platformen und
Anwendungen. Der Lader 330 kann als Klasse von C++, als
statischer Code oder als DLL implementiert werden. Als kurze Übersicht
verwendet das Ladermodul 330 mehrere Funktionen zur Verwaltung
der Subsysteme 300. Im allgemeinen erzeugen und vernichten
die durch das Ladermodul 330 ausgeführten Funktionen Subsysteme 300.
die Funktionsweise des Ladermoduls 330 wird in Verbindung
mit 4 ausführlicher beschrieben.
-
Das
Ladermodul 330 verwendet eine Erzeugungsfunktion mit einer
Subsystemkennung als Eingabe, um eine Instanz jedes Subsystems 300 zu
erzeugen. Bei Ausführungsformen,
bei denen eine Ereigniswarteschlange mit dem Subsystem 300 assoziiert
ist, ruft die Erzeugungsfunktion eine Instanziierung einer Ereigniswarteschlange
in dem Ereignisablieferobjekt 312 auf, und der Lader 330 bindet
die Ereigniswarteschlange an das entdeckte Subsystem 300 an.
Bei andere Ausführungsformen
wird das Subsystem 300 durch einen Zeiger identifiziert,
der in die Dispatch-Tabelle 316 eingegeben wird, um das
Subsystem 300 zu identifizieren.
-
Das
Ereignisablieferobjekt 312 verwendet den in dem Ereignisablieferobjekt 312 gespeicherten
Zeiger (bei bestimmten Ausführungsformen
identifiziert der Zeiger eine Ereigniswarteschlange), um Ereignisse
zu dem Subsystem zu senden. Das Subsystem 300 verwendet
einen Zeiger auf das Ereignisablieferobjekt 312, um das
Ereignis an den Ereignisbus 310 abzuliefern. Bei Ausführungsformen,
bei denen die Schnittstellen als Klassen von C++ bereitgestellt
werden, identifizieren die Zeiger also zum Beispiel die gewünschten
Klassen. Bei bestimmten Ausführungsformen
kann diese Funktion einen Statuswert zurückgehen. Das Ladermodul 330 verwendet
eine Vernichtungsfunktion zum Löschen
einer Instanz des Subsystems 300 (gegebenenfalls zusammen
mit einer Ereigniswarteschlange, die mit diesem gelöschten Subsystem
assoziiert ist) und den entsprechenden Eintrag in der Dispatch-Tabelle 316.
-
4.0 Server- und Subsysteminitialisierung
-
6 zeigt
eine Ausführungsform
eines Prozesses zum Initialisieren eines Servers 180, einschließlich der
Systemdienstmodule 350 und der Personalitätssubsysteme 300.
Ein Server 180 führt
Boot-Dienst-Code aus (d. h. daß Systemmodul 320),
der den Ereignisbus 310 erzeugt. Bei der in 6 gezeigten
Ausführungsform
umfaßt
die Erzeugung des Ereignisbusses 310 die folgenden Schritte:
Erzeugen eines Ereignisablieferobjekts 312 (Schritt 604),
Erzeugen eines Transportmechanismus 318 (Schritt 608)
und Anbinden des Ereignisablieferobjekts 312 an die Transportschicht 318 (Schritt 612).
-
Das
Systemmodul 320 instantiiert ein Ladermodul 330 (Schritt 616)
und startet (Schritt 620) die Ausführung des Lasermoduls 330.
Das Ladermodul 330 erzeugt und lädt (Schritt 624) ein
durch ein Initialisierungsbetriebsmittel identifiziertes spezialisiertes
Subsystem. Bei bestimmten Ausführungsformen
wird das spezialisierte Subsystem durch einen Eintrag in einer Registrierdatenbank-Datei
identifiziert. Bei Ausführungsformen, bei
denen die Systemdienstmodule 350 als Subsysteme bereitgestellt
werden, weist das spezialiserte Subsystem das Ladermodul 330 an,
alle erforderlichen Systemdienstmodule 350 zu erzeugen
und zu laden (Schritt 628). Das spezialisierte Subsystem
bestimmt außerdem,
welche Personalitäts-Subsysteme 300 für den Server 180 geladen
werden sollen (Schritt 632). Bei einer Ausführungsform
greift das spezialisierte Subsystem auf eine Registrierdatenbank-Datei
zu, um zu bestimmen, welche Personalitäts-Subsysteme 300 geladen
werden sollen, und die Registrierdatenbank-Datei spezifiziert eine
Reihenfolge, in der die Personalitäts-Subsysteme geladen werden.
Bei Ausführungsformen,
bei denen die Systemdienstmodule 350 als Subsysteme bereitgestellt
werden, spezifiziert die Registrierdatenbank-Datei außerdem die
Reihenfolge, in der sie initialisiert werden. Bei einer konkreten
Ausführungsform
spezifiziert die Registrierdatenbank-Datei die folgende Reihenfolge: das
Dienstmodul 352 des persistenten Speicherungssystems, das
Dienstmodul 356 des dynamischen Speichersystems, der Zonenmanager 358,
der Hostauflöser 360,
der Dienstlokalisierer 354, der Subskriptionsmanager 362.
-
Bei
einer anderen Ausführungsform
greift das spezialisierte Subsystem auf eine Initialisierungsdatei zu,
um zu bestimmen, welche Subsysteme geladen werden sollen. Bei weiteren
Ausführungsformen
greift das spezialisierte Subsystem auf den persistenten Speicher 230 zu,
um zu bestimmen, welche Subsysteme geladen werden sollen. Als Teil
des Ladens der Subsysteme 300 füllt das Ladermodul 330 (Schritt 636)
die Dispatch-Tabelle 316 mit
Einträgen 420,
die Subsystem-Eintrittspunkte
auf mit den geladenenen Subsystemen 300 assoziierte Subsystemkennung
abbildet, wie oben in 4A gezeigt.
-
Jedes
Subsystem 300 kann durch einen Eintrag in den Initialisierungsbetriebsmittel
repräsentiert,
d. h. auf dem Server 180 installiert werden, weil (1) das
Subsystem für
den Betrieb des Servers 180 notwendig ist oder (2) erwartet
wird, daß das
Subsystem nützlich
sein wird. Bei einer Ausführungsform
besteht ein anderer Grund für
das Installieren eines Subsystems 300 darin, daß das Subsystem 300 durch
die Ankunft eines an dieses Subsystem gerichteten Ereignisses (d.
h. auf Bedarf) angefordert wird. Bei solchen Ausführungsformen,
Laden bei Bedarf implementieren, wartet das Ladermodul 330,
bis ein Ereignis empfangen wird, das an dieses Subsystem gerichtet
ist, bevor dieses Subsystem erzeugt wird. Bei diesen Ausführungsformen
stellt das Ladermodul 330 eine API bereit, die ein Aufrufen
des Ladermoduls 330 während
der Laufzeit erlaubt, um ein Personalitäts-subsystem 300 zu
erzeugen und zu initialisieren.
-
5.0 Ereignisse
-
7A zeigt eine Ausführungsform eines Ereignisses 700,
das einen Ereigniskopfteil 710 und Ereignisdaten 730 enthält. Der
Ereigniskopfteil 710 wird manchmal als „Steuerdaten” bezeichnet,
und die Ereignisdaten 730 können als „Nutzdaten" bezeichnet werden.
-
Nunmehr
mit Bezug auf 7B enthält der Ereigniskopfteil 710 ein
oder mehrere Datenfelder, die verschiedene mit dem Ereignis 700 assoziierte
Attribute angeben. Zum Beispiel kann der Ereigniskopfteil 710 folgendes
enthalten: eine eindeutige Ereigniskennung (Ereignis-UID) 712;
eine Ereignis-Kopfteilversionskennung 714; eine Ereignisdaten-Versionskennung 716;
einen Ereignisdaten-Größenindikator 718;
eine Ereignisdaten-Offsetkennung 720; eine eindeutige Kennung
(UID) 720, die ein Quellensuchsystem identifiziert; eine Zielsubsysstem-UID 724,
die ein Zielsubsystem identifiziert; und eine nachfolgend ausführlicher
beschriebene Kanalkennung 726.
-
Ausführlicher
identifiziert die Ereignis-UID 712 eindeutig jedes von
den Subsystemen 300 und den Systemdienstmodulen 350 produzierte
Ereignis. Jedes Subsystem und Systemdienstmodul 350 definiert
die Ereignis-ID der Ereignisse, die es annimmt, vor. Die Ereignis-ID
werden fest codiert und sind für
jeden Server 180 eindeutig. Die Eindeutigkeit eines Ereignisses 700 in
einem Server 180 wird durch die Kombination der Quellensubsystem-UID 722 und
der Ereignis-ID 712 hergestellt und werden in Kombination
verwendet, um Ereignisse wie oben beschrieben auf Handler-Routinen
abzubilden.
-
Kennungen
des Quellenhosts und des Zielhosts können als Parameter in den zum
Ausgeben von Ereignissen 700 benutzten SAL-Befehlen weitergeleitet
werden. In solchen Fällen
identifizieren die Quellenhostkennung und die Quellen-Subsystem-UID 722 zusammen
den Absender (d. h. den Quellenserver und das Quellen-Subsystem)
des Ereignisses 700 eindeutig. Die Zielhostkennung und
die Ziel-Subsystem-UID 724 identifizieren das Subsystem
oder Systemdienstmodul 350, das das Ereignis empfangen soll,
eindeutig.
-
Bei
einer Ausführungsform
ist das Bit höchster
Ordnung der Ereignis-UID 712 ein „Anforderungsbit" und gibt dem anfordernden
Subsystem an, wie das Ereignis auf die richtige Handler-Routine
abzubilden ist. Alle Subsysteme können wahlweise wählen, Ereignisse
eines anderen Subsystems durch Mechanismen wie etwa Subskriptionen
abzuwickeln. Die Ereignis-Handler-Routinen werden gemäß der Subsystem-UID und Ereignis-UID 712 abgebildet.
Da das verarbeitete Ereignis entweder gerichtet oder subskribiert
werden kann, gibt das Anforderungsbit an, ob die Quellen- oder Ziel-Subsystem-UID zum
Abbilden des Ereignisses auf die richtige Handler-Routine verwendet
werden soll.
-
Die
Ereignis-Kopfteilversionskennung 714 definiert das Layout
des Ereignis-Kopfteils 710, wie etwa die Größe und Reihenfolge
der Felder in dem Kopfteil 710. Die Ereignisdaten-Versionskennung 1416 definiert implizit
das Layout der in dem Ereignis 700 enthaltenden Ereignisdaten 730.
Die Ereignisdaten-Offsetkennung 720 gibt das Offset von
dem Ereigniskopfteil 710 an, an dem die Ereignisdaten 730 beginnen.
Das Ereignisdaten-Offset 720 ist
gleich der Größe des Ereignis-Kopfteils 710.
Die Kanalkennung 726 dient zum Vergleichen eines Antwortereignisses
mit einem Anforderungsereignis.
-
5.1 Ereignistypen
-
Ereignisse
können
einen von mehreren Typen aufweisen, darunter gerichtete und Benachrichtigungsereignisse.
-
5.1.1 Gerichtete Ereignisse
-
Gerichtete
Ereignisse sind Ereignisse, die ein spezifiziertes Zielsubsystem 300 aufweisen,
wenn sie zu dem Ereignisablieferobjekt 512 gesendet werden.
Das spezifizierte Ziel enthält
eine eindeutige Kennung (UID) des Zielsubsystems 300 und
eine Kennung des Servers 180, der das Ziel-Subsystem hostet.
Beispiele für
gerichtete Ereignisse wären
Benachrichtigungsereignisse und die oben beschriebenen Anforderungs-
und Antwortereignisse.
-
5.1.1.1 Anforderungs- und -Anwort-Ereignisse
-
Anforderungsereignisse
sind subsystemspezifische gerichtete Ereignisse, die eine Dienst-
oder Funktionalitätsanforderung
zu einem anderen Subsystem auf demselben Server 180 oder
zu einem abgesetzten Server in der Server-Farm 110 senden.
Solche Anforderungsereignisse enthalten Codes, die das Zielsubsystem
auf bekannte Schnittstellen (d. h. Ereignis-Handler-Routinen) abbilden
kann, um diesen Dienst oder diese Funktionalität bereitzustellen. Jedes Anforderungsereignis
enthält
eine eindeutige Kanal-ID zur Verwendung durch das Zielsubsystem
beim Erzeugen eines entsprechenden Antwortereignisses.
-
Antwortereignisse
treten als Reaktion auf Anforderungsereignisse auf. Jedes Antwortereignis
wird als ein gerichtetes Ereignis an das Subsystem abgeliefert,
aus dem das entsprechende Anforderungsereignis kam. Das Antwortereignis
spezifiziert dieselbe Kanal-ID und denselben Ereignispuffer 380,
die bzw. der von dem entsprechenden Anforderungsereignis benutzt
wurde. Das Subsystem, das das Anforderungsereignis gesendet hat,
wartet auf das Antwortereignis von dem Ereignisablieferobjekt 312.
Dieselbe Kanal-ID gibt dem Ereignisablieferobjekt 312 an,
daß das
Antwortereignis direkt zu dem Zielsuchsystem geleitet werden soll,
statt in eine mit dem Zielsuchsystem assoziierte Ereigniswarteschlange
eingereiht zu werden.
-
Der
folgende Pseudocode realisiert ein Beispiel für eine Antwort-Ereignis-Handler-Routine,
die als Reaktion auf den Empfang eines Anforderungsereignisses aufgerufen
wird. Insbesondere besitzt für
das folgende Beispiel das Zielsubsystem eine Ereignis-Handler-Routine mit dem Namen
OnGetSampleData(Event-Buffer* pEvent), die als Reaktion auf ein
GetSampleData-Ereignis
aufgerufen wird. Diese Ereignis-Handler-Routine legt Daten in dem Antwortereignispuffer
ab, auf den der Zeiger „pReplyEvent" zeigt.
ERGEBNIS
Sample::OnGETSampleData(EventBuffer* pEvent)
{
if (SUCCESS==Create
Reply Event(&pReplyEvent,
SetSampleDataReply, event version, subsystem, size))
{
put_data_in_event_buffer;
res=PostEvent(pReplyEvent);//send
event to the Event bus
}
delete(pEvent);//
return
res;
}
-
Die
OnGetSampleData-Antwortereignis-Handler-Routine ruft ein CreateReplyEvent,
das ein Antwortereignis für
das ursprüngliche
Anforderungsereignis erzeugt. Wie oben erwähnt, wird das Antwortereignis
in dem Ereignispuffer abgelegt, der zum Halten des ursprünglichen
Anforderungsereignisses verwendet wird (d. h. worauf pEvent zeigt),
wodurch das Anforderungsereignis überschrieben wird. Ein neuer
Zeiger pReplyEvent zeigt auf das Antwortereignis in dem Ereignispuffer,
und der alte Zeiger pEvent wird gelöscht.
-
Das
Create_Reply_Event erzeugt, wie der Name sagt, das Antwortereignis
gemäß mitgegebenen
Eingangsparametern. Ein Eingangsparameter ist die Identifikation
des Antwortereignisses (hier SetSampleDataReply) und die Version
des Antwortereignisses (hier 1). Alle Ereignisse sind mit einer
Ereignis-ID 712 assoziiert, wodurch zusammen mit der Subsystem-ID 722 des
Quellensubsystems eine eindeutige Kennung für dieses Ereignis produziert
wird.
-
Ein
weiteres Merkmal des Create_Reply_Event ist, daß diese Funktion automatisch
das Zielsubsystem des Antwortereignisses, nämlich des Subsystems, aus dem
das Anforderungsereignis stammt, spezifiziert. Der PostEvent-Befehl
ist eine der durch die Ereignisbus-API 392 für die Kommunikation
mit dem Ereignisbus 310 bereitgestellten Funktionen. Da
die Create_Reply_Event-Funktion
das Zielsubsystem des Ereignisses setzt, gibt der PostEvent-Befehl
an, wohin das Antwortereignis abzuliefern ist (d. h. unter Verwendung der
Dispatch-Tabelle).
-
5.1.1.2 Das Benachrichtigungsereignis
-
Ein
Benachrichtigungsereignis ist ein Ereignis, das an den Subskriptionsmanager 362 gerichtet
ist. Ein solches Ereignis wird von dem Subskriptionsmanager 362 abgeworfen
(d. h. ignoriert) wenn nicht ein Eintrag in der Lokal-Subskriptionstabelle 450 oder
der Abgesetz-Subskriptionstabelle 418 vorliegt,
der angibt, daß mindestens
ein Subsystem 300 daran interessiert ist, von dem Auftreten
dieses Ereignisses benachrichtigt zu werden. Jedes Subsystem führt eine
Liste von Ereignissen, die andere Subsysteme subskribieren können, und produziert
folglich nach dem Ausgeben eines dieser potentiell subskribierten
Ereignisse ein Benachrichtigungsereignis.
-
5.2 Ereignisablieferbefehl
-
Im
allgemeinen gibt jedes Subsystem 300 fünf Arten von Befehlen zum Abliefern
von Ereignissen an den Ereignisbus 310 aus: PostNotificationEvent,
PostEvent, SendEventAndWait, Subscribe und Unsubscribe. Als kurze Übersicht
sendet ein PostNotivicationEvent-Befehl ein gerichtetes Ereignis
wie oben erwähnt
zu dem Subskriptionsmanager 362. Ein PostEvent-Befehl sendet
ein gerichtetes Ereignis zu einem Zielsubsystem und ermöglicht es
dem Quellensubsystem, unmittelbar die Verarbeitung anderer Tasks
fortzusetzen (das heißt,
der PostEvent-Befehl „kehrt" unmittelbar „zurück"). Ein SendEventAndWait-Befehl
sendet ein gerichtetes Ereignis zu einem Zielsubsystem und wartet
auf eine Antwort, wodurch bewirkt wird, daß das Quellensubsystem blockiert
ist, bis die Antwort empfangen wird. Ein Subskribe-Befehl sendet
ein Benachrichtigungsereignis zum Registrieren einer Subskription
bei der Lokal-Subskriptionstabelle 450 und/oder
der Abgesetzt-Subskriptionstabelle 418.
Ein Unsubscribe-Befehl sendet ein Benachrichtigungsereignis zum
Entfernen einer zuvor registrierten Subskription aus der Lokal-Subskriptionstabelle 450 und/oder
der Abgesetz-Subskriptionstabelle 418.
-
6.0 Einfache Beispiele
-
Wieder
mit Bezug auf 3 verwenden die folgenden Beispiele
eine konkrete Ausführungsform
zur Veranschaulichung der Prinzipien der obenbeschriebenen Angelegenheiten
und sollen den Gegenstand der Erfindung auf keinerlei Weise einschränken.
-
6.1 Der PostEvent-Befehl
-
Wenn
ein Quellensubsystem 300 mit einem Zielsubsystem 300' auf demselben
oder einem anderen Server kommunizieren möchte, besteht außerdem mit
Bezugnahme auf 8A ein Verfahren zur Kommunikation
darin, daß das
Quellensubsystem 300 durch die Ereignisbus-API 392 einen
PostEvent-Befehl an das Ereignisablieferobjekt 312 ausgibt.
Das Quellensubsystem 300 bestimmt (Schritt 800),
ob die Identität
eines das Zielsubsystem 300' hostenden
Zielserver benötigt
wird. Zum Beispiel müßte ein
Subsystem 300, das sich dafür vorbereitet, ein Ereignis
an ein Peer-Subsystem 300 auf einem anderen Server 180 auszugeben,
die Identität
des das Peer-Subsystem
hostenden Zielservers 180 bestimmen.
-
Wenn
die Identität
eines Zielservers benötigt
wird, kommuniziert das Quellensubsystem 300 (Schritt 802)
mit dem Dienslokalisierer 354. Bei einer Ausführungsform
erfolgt eine solche Kommunikation als ein gerichtetes Ereignis zu
dem Dienstlokalisierer 354, das über den Ereignisbus 310 abgeliefert
wird. Das gerichtete Ereignis kann die Identität des Zielservers anfordern
oder anfordern, daß der
Dienstlokalisierer 354 das Ereignis 700 zu dem
Zielsubsystem 300' auf
dem Zielserver weiterleitet. Im letzteren Fall enthält das durch
den Dienstlokalisierer 354 aus dem Quellensubsystem empfangene
Ereignis das Ereignis 700, das weiterzuleiten ist. Der
Dienstlokalisierer 354 liefert dieses enthaltene Ereignis 700 an
das Ereignisablieferobjekt 312 ab, wobei der Zielserver
als einer Parameter spezifiziert wird.
-
Bei
der in 8A gezeigten Ausführungsform
liefert das Quellensubsystem 300 kein Ereignis ab, sondern
ruft eine Funktion der internen API 302 des Dienstlokalisierers 354 auf.
Der Dienstlokalisierer 354 bestimmt dann (Schritt 804)
den Zielserver. Bei einer Ausführungsform
gibt der Dienstlokalisierer 354 (Schritt 806)
die Identität
des Zielservers an das Quellensubsystem 300 zurück, so daß das Quellensubsystem 300 den
PostEvent-Befehl zum Senden dieses Ereignisses 700 zu dem
Zielsubsystem 300' ausgeben
kann (Schritt 810). Als Alternative gibt der Dienstlokalisierer 354 (Schritt 808)
den PostEvent-Befehl
zum Senden des Ereignisses 700 im Namen des Quellensubsystems 300 über den
Ereignisbus 310 an das Zielsubsystem 300' aus. Für diesen
Fall enthält
der Aufruf der internen API 302 das zu dem Zielsubsystem 300' auf dem Zielserver
weiterzuleitende Ereignis 700.
-
Nach
dem Empfang des Ereignisses 700 bestimmt der Ereignisbus 310 (Schritt 812)
aus einem etwaigen in dem PostEvent-Befehl enthaltenen Zielhostparameter,
ob das Ereignis 700 lokal oder abgesetzt ist. Wenn das
Zielsubsystem 300' abgesetzt
ist, wird das Ereignis zur nachfolgenden Übertragung zu dem abgesetzten
Server 180',
der das Zielsubsystem 300' hostet,
an die Transportschicht 318 des Ereignisbusses 310 abgeliefert
(Schritt 814). Die Transportschicht 318 sendet
(Schritt 816) das Ereignis 700 dann über die
Netzwerkverbindung 200 zu der Transportschicht 310' auf dem abgesetzten
Server 180'.
Die Funktionsweise der Transportschichten 318, 318' wird im Abschnitt
7.2 ausführlicher
beschrieben.
-
Wenn
das Zielsubsystem 300' lokal
ist, bestimmt das Ereignisablieferobjekt 312 des Ereignisbusses 310 (Schritt 818)
den mit dem Zielsubsystem 300' assoziierten Eingangspunkt und
bestimmt (Schritt 820), ob das Zielsubsystem 300' ein Ein-Thread-
oder Mehrfach-Thread-Subsystem ist. Um den Eingangspunkt zu bestimmen,
untersucht das Ereignisablieferobjekt 312 die Dispatch-Tabelle 316 unter
Verwendung der Zielsubsystem-UID 724 des Ereignisses 700 als
Index in die Tabelle 316. Bei Ausführungsformen mit Ereigniswarteschlangen
identifiziert die Dispatch-Tabelle 316 die
mit dem Zielsubsystem 300' assoziierte
Ereigniswarteschlange. Bei einer Ausführungsform gibt die Ereigniswarteschlange
an, ob das Zielsubsystem 300' ein
Mehfach-Thread-System ist.
-
Wenn
die Ereigniswarteschlange angibt, daß das Zielsubsystem 300' ein Mehrfach-Thread-System ist,
wird das Ereignis 700 nicht in eine Warteschlange eingereiht.
Das Ereignisablieferobjekt 312 ruft (im Schritt 822)
das DispatchEvent das Subsystem-API 306 des Zielsubsystems 300' auf, wodurch
die Ausführung (Schritt 824)
der entsprechenden Handler-Routine des Zielsubsystems 300' zum Antworten
auf das Ereignis 700 bewirkt wird. Bei einer alternativen
Ausführungsform
ruft ein durch das Zielsubsystem 300' ausgeführter Thread das Anforderungsereignis 700 aus
den Ereignisablieferobjekten 312' ab.
-
Wenn
die Ereigniswarteschlange angibt, daß das Zielsubsystem 300' ein Ein-Thread-System
ist, legt das Ereignisablieferobjekt 302 (Schritt 826)
den Zeiger auf den das Ereignis 700 haltenden Ereignispuffer 380 in
der mit dem Zielsubsystem 300' assoziierten Ereigniswarteschlange
ab. Das Ereignisablieferobjekt 312 startet dann (Schritt 828)
einen neuen Ausführungs-Thread, der dem Zielsubsystem 300' unter Verwendung
der DispatchEvent-Funktion der Subsystem-API 306 signalisiert,
und liefert das Ereignis 700 aus der Ereigniswarteschlange
an das Zielsubsystem 300' ab.
Dieser neue Thread führt
die für
das Ereignis 700 geeignete Handler-Routine aus (Schritt 824).
Bei einer Ausführungsform
sendet das Ereignisablieferobjekt 312 das Ereignis 700 (unter
Verwendung von DispatchEvent) an das Zielsubsystem 300' aus, ohne daß Ereignis 700 in
der Ereigniswarteschlange abzulegen, wenn die Ereigniswarteschlange
leer ist, wenn das Ereignisablieferobjekt 312 gerade dabei
ist, das Ereignis 700 in der Ereigniswarteschlange abzulegen.
Wieder ruft bei einer alternativen Ausführungsform ein durch das Zielsubsystem 300' ausgeführter Thread
das Ereignis 700 aus der Ereigniswarteschlange ab, statt
daß das
Ereignisablieferobjekt 312 das Ereignis 700 auf
das Zielsubsystem 300' schiebt.
-
Bei
einer Ausführungsform
gibt die Dispatch-Tabelle 316 an, ob das Zielsubsystem 300' Mehrfach-Thread-Fähigkeit
aufweist. Wenn die Dispatch-Tabelle 316 abgibt, daß das Zielsubsystem 300' ein Mehrfach-Thread-System
ist, ruft das Ereignisablieferobjekt 312' die DispatchEvent-Funktion der Subsystem-API 306' des Zielsubsystems 300' wie oben beschrieben
auf. Die Verwendung der Dispatch- Tabelle 316 zum
Speichern von Informationen bezüglich
Mehrfach-Thread-Fähigkeit
des Subsystems macht die Verwendung einer Ereigniswarteschlange
für ein
Subsystem mit Mehfach-Thread-Fähigkeit
unnötig.
-
6.2 Der SendEventandWait-Befehl
-
Mit
Bezug auf 9A–9D besteht
ein weiteres Verfahren, durch das das Quellensubsystem 300 mit
dem Zielsubsystem 300' kommunizieren
kann, darin, daß das
Quellensubsystem 300 durch die Ereignisbus-API 392 einen
SendEventandWait-Befehl an das Ereignisablieferobjekt 312 ausgibt.
Um diesen Prozeß zu
starten, gibt das Subsystem 300 unter Verwendung des SendEventandWait-Befehls
der SAL 304 des Zielsubsystems 300' ein Anforderungsereignis 700 aus
(Schritt 902). Dieses Anforderungsereignis 700 verwendet eine
Kanalidentifikation und spezifiziert das Zielsubsystem 300' in der Ziel-UID 724.
Da das Anforderungsereignis 700 ein Ereignis ist, für das nachfolgend
eine Antwort erwartet wird, blockiert das Quellensubsystem 300 die
weitere Ausführung
des Threads, der das Anforderungsereignis 700 erzeugt hat,
bis die Antwort von dem Zielsubsystem 300' empfangen wird. Während dieser
Thread blockiert ist, kann das Quellensubsystem 300 durch
andere Threads mit anderen Subsystemen kommunizieren.
-
In
diesem Beispiel ersucht (Schritt 904) dieses Quellensubsystem 300 einen
Zielserver von dem Dienstlokalisierer 354. Man beachte,
daß nicht
jedes Ereignis zur Bestimmung eines Zielservers zu dem Dienstlokalisierer 354 gesendet
wird; bei bestimmten Ereignissen, wie etwa Antwortereignissen, muß das Quellensubsystem 300 den
Dienstlokalisierer 354 nicht benutzen, weil der Zielserver
aus dem Anforderungsereignis 700 bestimmt wird. Wie oben
beschrieben, bestimmt der Dienstlokalisierer 354 (Schritt 906)
den Zielserver und gibt die Identität des Zielservers an das Quellensubsystem 300 zurück (Schritt 908),
und das Quellensubsystem 300 sendet das Anforderungsereignis 700 zu
dem Ereignisbus 310. Als Alternative gibt der Dienstlokalisierer 354 (Schritt 910') das Anforderungsereignis 700 im
Namen des Quellensubsystems 300 auf den Ereignisbus 310 aus.
Die spezifische von dem Dienstlokalisierer 354 unternommene
Aktion hängt
von der tatsächlichen
Anforderung von dem Quellensubsystem 300 ab.
-
Das
Anforderungsereignis 700 wird zu dem Ereignisablieferobjekt 312 des
Ereignisbusses 310 geleitet. Man nehme an, daß der Dienstlokalisierer 354 bestimmt,
daß der
Zielserver der abgesetzte Server 180' ist. Das Ereignisablieferobjekt 312 bestimmt
dann (Schritt 912) aus dem Zielhostparameter des SendEventandWait-Befehls,
daß das
Zielsubsystem 300' sich
auf dem abgesetzten Server 180' befindet. Da das Zielsubsystem 300' von dem Quellensubsystem 300 abgesetzt
ist, wird das Anforderungsereignis 700 zu der Transportschicht 318 auf
dem Server 180 geleitet (Schritt 914). Die Transportschicht 318 sendet
dann (Schritt 916) das Anforderungsereignis über die
Netzwerkverbindung 200 zu der Transportschicht 318' auf dem Server 180'.
-
Die
Transportschicht 318' leitet
das Anforderungsereignis 700 zu dem Ereignisablieferobjekt 312' des Ereignisbusses 310' weiter (Schritt 918).
Das Ereignisablieferobjekt 312' des Ereignisbusses 310' bestimmt dann
(Schritt 920) den mit dem Zielsubsystem 300' assoziierten
Eingangspunkt und bestimmte (Schritt 922), wie oben beschrieben,
ob das Zielsubsystem 300' ein
Ein-Thread- oder ein Mehrfach-Thread-Subsystem ist.
-
Wenn
das Zielsubsystem 300' ein
Mehrfach-Thread-System ist, wird das Anforderungsereignis 700 nicht
in eine Warteschlange eingereiht. Das Ereignisablieferobjekt 312' ruft (Schritt 924)
das DispatchEvent der Subsystem-API 306 des Zielsubsystems 300' auf, wodurch
die Ausführung
(Schritt 926) der entsprechenden Handler-Routine des Zielsubsystems 300' zum Antworten
auf das Anforderungsereignis 700 bewirkt wird.
-
Wenn
das Zielsubsystem 300' ein
Ein-Thread-System ist, legt das Ereignisablieferobjekt 312' (Schritt 924)
den Zeiger auf den Ereignispuffer 380, der das Anforderungsereignis 700 hält, in der
mit dem Zielsubsystem 300' assoziierten
Ereigniswarteschlange ab. Das Ereignisablieferobjekt 312 startet
dann (Schritt 930) einen neuen Ausführungs-Thread, der dem Zielsubsystem 300' unter Verwendung
der DispatchEvent-Funktion
der Subsystem-API 306 signalisiert und das Anforderungsereignis 700 aus
der Ereigniswarteschlange an das Zielsubsystem 300' abliefert (Schritt 932).
Dieser neue Thread führt
die für
das Anforderungsereignis 700 geeignete Handler-Routine
aus (Schritt 926). Bei einer Ausführungsform sendet das Ereignisablieferobjekt 312' das Anforderungsereignis 700 zu
dem Zielsubsystem 300' aus
und umgeht dabei die Ereigniswarteschlange, wenn die Ereigniswarteschlange
leer ist, wenn das Ereignisablieferobjekt 312' gerade dabei
ist, das Anforderungsereignis 700 in der Ereigniswarteschlange
abzulegen.
-
Die
Handler-Routine produziert (Schritt 934) ein Anforderungsereignis 700', das durch
das Zielsubsystem 300' zu
dem Ereignisablieferobjekt 312' des Ereignisbusses 310' aufgegeben
wird (Schritt 936). Das Anforderungsereignis 700' verwendet dieselbe
Kanalkennung, die durch das Quellensubsystem 300 bereitgestellt
wurde, als es das Anforderungsereignis 700 ausgegeben hat.
Nach der Bestimmung, daß das
Antwortereignis 700' für einen
abgesetzten Server (hier den Server 180) bestimmt ist,
leitet das Ereignisablieferobjekt 312 dann (Schritt 938)
das Antwortereignis 700' zu
der Transportschicht 318' auf
dem Server 180'.
Die Transportschicht 318' sendet (Schritt 940)
das Antwortereignis 700' über die
Netzwerkverbindung 200 zu der Transportschicht 318 auf
dem Server 180.
-
Das
Ereignisablieferobjekt 312 des Ereignisbusses 310 empfängt (Schritt 942)
das Antwortereignis 700' durch
die Transportschicht 318 des Servers 180 und liefert
(Schritt 944) das Antwortereignis 700' an den wartenden
Thread (d. h. den Thread, der das Anforderungsereignis 700 produziert
hat) ab. Da das Antwortereignis 700' dieselbe Kanalidentifikation verwendet,
die von dem Quellensubsystem 300 zum anfänglichen
Ausgeben des Anforderungsereignisses 700 verwendet wird,
kehrt das Antwortereignis 700' zu dem wartenden Thread zurück (d. h.
der wartende Thread wird entblockiert), und umgeht dabei die (etwaige)
mit dem Quellensubsystem 300 assoziierte Ereigniswarteschlange.
Wenn das Antwortereignis 700' nicht
innerhalb einer spezifizierten Zeitgrenzenperiode, die in dem Befehl
spezifiziert wird, zurückkehrt,
wird der wartende Thread freigegeben. Das Ereignisablieferobjekt 312 ignoriert
die Antwort, wenn das Antwortereignis 700' nach dem Ablaufen der Zeitgrenzenperiode
ankommt. Das Quellensubsystem 300 führt die entsprechende Handler-Routine für das Antwortereignis 700' aus.
-
Bei
einer alternativen Ausführungsform
ruft ein durch das Zielsubsystem 300' ausgeführter Thread das Anforderungsereignis 700 aus
dem Ereignisablieferobjekt 312' ab und ein durch das Quellensubsystem 300 ausgeführter Thread
ruft das Antwortereignis 700' aus
dem Ereignisablieferobjekt 312 ab. Somit „ziehen" bei dieser Ausführungsform
die Subsysteme 300, 300' das Ereignis 700' im Gegensatz
zu den obenbeschriebenen Ausführungsformen,
bei denen die jeweiligen Ereignisablieferobjekte 312', 312 das
Anforderungsereignis und die Antwortereignisse 700, 700' auf die Zielsubsysteme 300' bzw. das Quellensubsystem 300 „schieben".
-
6.3 Verwaltung dynamischer Daten
-
Mit
Bezug auf 10 sendet, wenn ein Subsystem 300 eines
Servers 180 in dem dynamischen Speicher 240 gespeicherte
Kollektorpunktdaten speichern oder abrufen muß, dieses Subsystem 300 ein
Ereignis zu dem auf dem Server 180 residenten Dienstmodul 356 des
dynamischen Speichersystems (Schritt 1002). Das Dienstmodul 356 des
dynamischen Speichersystems bestimmt, ob es weiß, welcher Server 180 in
der Server-Farm 180' der
Kollektorpunkt des von dem Subsystem 300 gewünschten
Datensatztyps ist (Schritt 1004). Zum Beispiel kann das
Dienstmodul 356 des dynamischen Speichersystems Assoziationen
zwischen dem Datensatztyp und dem Kollektorpunkt Cash-speichern
und beim Empfang des Ereignisses von dem Subsystem 300 auf
diesen Cash zugreifen.
-
Wenn
das Dienstmodul 356 des dynamischen Speichersystems den
Server bestimmten kann, der Datensätze des in dem Ereignis identifizierten
Typs sammelt, sendet das Dienstmodul 356 des dynamischen Speichersystems
ein Ereignis zu dem Server 180, der für das Sammeln solcher Datensätze verantwortlich
ist (Schritt 1006). Wenn der Kollektorpunkt nicht bestimmt
werden kann, sendet das Dienstmodul 356 des dynamischen
Speichersystems ein Ereignis zu dem Zonenmanager 358, das
um die Adresse des Servers ersucht, der diesen Datensatztyp sammelt
(Schritt 1008). Nach Empfang dieses Ereignisses (Schritt 1100)
bestimmt der Zonenmanager 358 (Schritt 1012),
ob er der Master-Zonenmanager 358 für die Zone
ist. Wenn der Zonenmanager 358 der Zonenmaster ist, sendet
der Zonenmanager 358 die Identifikation des für das Sammeln
von Ereignissen des identifizierten Typs verantwortlichen Servers
zu dem Dienstmodul 356 des dynamischen Speichersystems
(Schritt 1014).
-
Wenn
der Zonenmanager 358 nicht der Master ist, sendet der Zonenmanager 358 (Schritt 1016)
ein Ereignis zu dem Zonenmaster, der als Ergebnis der Master-Wahl
bekannt ist. Der Zonenmanager 358 empfängt die Serveridentifikation
des Zonenmasters (Schritt 1018) und sendet (Schritt 1014)
die Serveridentifikation zu dem Dienstmodul 356 des dynamischen
Speichersystems. Nach Empfang dieser Serveridentifikation greift
das Dienstmodul 356 des dynamischen Speichersystems gemäß dem anfänglich von
dem Subsystem 300 empfangenen Ereignis auf den dynamischen
Speicher 240 zu. Falls der Zonenmaster nicht antwortet, nachdem
eine vorbestimmte Anzahl von Anforderungen gesendet wurde, leitet
der Zonenmanager 358 eine Wahl eines neuen Zonenmasters
wie oben beschrieben ein.
-
7.0 Subsysteme
-
Immer
dann, wenn ein Server 180 zum ersten Mal eine Tabelle des
dynamischen Speichers öffnet, kontaktiert
der dynamische Speicher den Zonenmaster, um den Tabelleneigentümer zu bestimmen.
Eine Anforderung des Tabelleneigentümers von dem Zonenmaster ist
immer erfolgreich, vorausgesetzt, daß der angeforderte Tabellenname
gültig
ist. Auch wenn die Tabelle dem Zonenmaster nicht bekannt ist, wird
zum Zeitpunkt der Anforderung ein Eigentümer für sie bestimmt. Jeder Fehlschlag
beim Bestimmen des Tabelleneigentümers (mit Ausnahme eines ungültigen Tabellennamens)
ist katastrophal und führt
dazu, daß ein
Fehler zu der Komponente zurückgesendet
wird, die die Verbindungsanforderung eingeleitet hat.
-
Nachdem
der Zonenmaster die Identität
des Servers zurückgegeben
hat, der die fragliche Tabelle besitzt, muß der anfordernde Server den
Eigentümer
kontaktieren. Wenn der Verbindungsversuch nach einer vorbestimmten
Anzahl von Versuchen fehlschlägt,
setzt der anfordernde Server seinen Zustand zurück und fordert den Zonenmaster
erneut auf, den Tabelleneigentümer
zu identifizieren. Dies sollte letztendlich dazu führen, daß ein neuer
Tabelleneiqentümer
bestimmt wird.
-
Nachdem
die Datensatztabelle durch Kontaktieren des Tabelleneigentümers erfolgreich
geöffnet
wurde, legt sich die Kommunikation zwischen dem anfordernden Server
und dem Eigentümerserver
zu einer Menge von Einfüge-,
Lösch-,
Aktualisierungs- und Anfrageanforderungen. Wenn ein Versuch, eine
dieser Operationen nach einer vorbestimmten Anzahl von Versuchen
fehlschlägt,
kontaktiert der anfordernde Server den Zonenmaster, um einen neuen
Eigentümer
anzufordern. Dieser Prozeß wird
wie oben ausgeführt.
Wenn der Zonenmaster einen neuen Tabelleneigentümer auswählt, aktualisiert der anfordernde
Server zuerst den neuen Eigentümer
mit allen lokalen Datensätzen.
Da der neue Eigentümer
etwas Zeit benötigt,
um Aktualisierungen von den anderen Hosts in der Zone zu empfangen,
bevor er ordnungsgemäß in der
Lage ist, mit der ankommenden Anforderung umzugehen, wird bei bestimmten
Ausführungsformen
der anfordernde Server einige Zeit warten müssen, bevor er die Anforderung überreicht.
-
Wie
oben im Abschnitt 350 beschrieben, enthält jedes Subsystem 300 eine
Subsystemzugangsschicht (SAL) 304, die die Befehle der
Anwendungsprogrammschnittstelle (API) definiert, auf die das Subsystem 300 ansprechen
kann. Wenn ein Subsystem 300 die Funktionalität eines
anderen Subsystems 300' benutzen
muß, ruft
dieses eine Subsystem 300 den durch die SAL 304 dieses
anderen Subsystems 300' bereitgestellten
entsprechenden API-Befehl
auf. Bei einer Ausführungsform
wird jede SAL 304 als eine Objektklasse mit Datenfeldern
und Methoden implementiert. Die Methoden verwenden das Ereignis
als Parameter in einem Befehl. Zu diesen Befehlsfunktionen gehört eine
PostSALEEvent-Funktion (äquivalent
mit einer PostEvent-Funktion) und eine SendSALEvent-Funktion (äquivalent
mit einer SendEventAndWait- Funktion).
Zu den Datenfeldern gehören
(1) ein Verweis auf das Subsystem, das die SAL erzeugt hat, (2)
eine Identifikation des Subsystems, das die Methoden unter Verwendung
des Ereignisses als Parameter aufruft, und (3) eine Identifikation
des Zielsubsystems für
das Ereignis.
-
Wenn
das Quellensubsystem 300 die Funktionalität eines
anderen Subsystems 300' benutzen
muß, erzeugt
das Quellensubsystem 300 eine Instanz der SAL-Klasse für dieses
andere Subsystem 300' und
ruft die von dieser SAL-Instanz bereitgestellten Methoden auf. Bei
Aufruf verschiebt eine SAL-Methode das Ereignis in einen Ereignispuffer 380 und
gibt den entsprechenden Zeiger auf das Ereignis an das Ereignisablieferobjekt 312 auf.
Zum Beispiel setzt die aufgerufene SAL-Methode das „Anforderungsbit" in der Ereignis-ID 712 und
gibt einen SendSALEvent-Aufruf aus, um das Ereignis aufzugeben,
und wartet auf ein Antwortereignis. Wie bereits besprochen, erzeugt
der SendSALEvent-Aufruf eine eindeutige Kanal-ID 726, mit
der das Zielsubsystem eine Antwort für dieses Ereignis zu dem Quellensubsystem
sendet. Nach dem Empfang einer Antwort auf dem spezifizierten Kanal
extrahiert die SAL 380 des Quellensubsystems die Daten
aus Parametern in dem Antwortereignis und kehrt zu dem blockierten
Thread zurück,
der die SAL-Methode aufgerufen hat.
-
Wenn
das Quellensubsystem und das Zielsubsystem dieselbe Art von Subsystem
sind, aber auf verschiedenen Hosts residieren, muß das Quellensubsystem
nicht die SAL 304 des empfangenen Subsystems (z. B. das
Dienstmodul 352 des persistenten Speichersystems auf einem
Server 180 zu dem Dienstmodul 253' des persistenten Speichersystems
des anderen Servers 180')
verwenden. In solchen Fällen
kennt das Quellensubsystem bereits die zur Kommunikation mit dem
Zielsubsystem zu verwendenden Ereignisse, ohne auf die SAL des Zielsubsystems
verweisen zu müssen.
Bei diesen Ausführungsformen
kann das Quellensubsystem ein Ereignis direkt auf dem Ereignisbus
aufgeben, der zu seinem auf einem anderen Host residierenden Peer
gerichtet ist.
-
7.1 Transportschicht
-
Die
Transportschicht 318 dient als der Mechanismus, der es
Subsystemen 300 auf verschiedenen Servern 180 erlaubt,
miteinander zu kommunizieren. Die Transportschicht 318 entspricht
insofern der Sitzungs- und
Darstellungsschicht von OSI (Open Systems Interconnection), als
sie Ereignisnachrichten 700 über die Netzwerkschnittstelle
des Servers sendet und empfängt,
Verschlüsselung/Entschlüsselung
und Komprimierung ausführt
und Verbindungen verwaltet. Verbindungsverwaltung umfaßt das Bilden
einer Verbindung zu anderen Servern in seiner Serverform, wenn eine
Ereignisnachricht 700 zu senden ist, und das Abwerfen der
Verbindung nach einer Periode mit Inaktivität. Die Transportschicht 318 geht
mit zwei Arten von Nachrichten um – Steuer- und Ereignisnachrichten.
-
Steuernachrichten
werden von der Transportschicht 318 zum Bestimmen der Kompatibilität von Verschlüsselungs- und Komprimierungsfähigkeiten
(d. h. Filtern) für
Server 180 auf jeder Seite der Verbindung verwendet. Zusätzlich zu
der Auflösung
der Transportfähigkeiten
des empfangenen Servers während
des Aushandlungszyklus und der Herstellung einer Verbindung wenden
sich die Steuernachrichten auch an das Herunterfahren der Verbindung.
Bei der Vorbereitung zum Schließen
der Verbindung sendet der Server 180 eine Nachricht zu
dem abgesetzten Server auf der anderen Seite der Verbindung, die
den abgesetzten Server über das
anstehende Herunterfahren und dem Grund für dieses Herunterfahren benachrichtigt.
Wenn die Verbindung jedoch aufgrund unkontrollierter Unterbrechungen abgeworfen
wird, wie etwa aufgrund von Hardwareausfällen oder eines Neubootens
von Servern, wird das Grundfeld nicht gesendet, weil die Verbindung
bereits abgeworfen wurde. Wenn ein kontrolliertes Herunterfahren
erfolgt, wird in einem Grundfeld in der Nachricht ein Grund spezifiziert,
der angibt, daß das
Herunterfahren auf einem der folgenden Gründe zurückzuführen ist: der Server 180 fährt herunter,
Inaktivität über die
Verbindung hat zu einer Zeitgrenzenüberschreitung geführt, die
Aushandlung von Filtern war nicht erfolgreich, die Verbindung wurde
verweigert (z. B. falsches Paßwort),
Fehler beim Instanziieren eines Filters usw.
-
Ereignisnachrichten
dienen zum Transport von Ereignisnachrichtendaten von der Transportschicht 318 auf
einen Server 180 zu der Transportschicht 318' auf einem anderen
Server 180'.
Diese Nachrichten werden durch die höheren Schichten (z. B. Subsystemschicht)
auf dem ersten Server 180 erzeugt und zu einer der höheren Schichten
in dem Zielserver 180' geliefert.
-
Verbindungsverwaltungscode
in der Transportschicht 318 stellt eine Menge von Routinen
zur Verwaltung einer Global-Host-Bindetabelle 366 bereit.
Die Global-Host-Bindetabelle 366 enthält Hostkennungen
zusammen mit entsprechenden Hostnamen, Netzwerkadressen und Zeigern
auf Serverstrukturen. Die Transportschicht 318 bildet und
unterhält
eine Serverstruktur für
jeden Server, der mit der Transportschicht 318 verbunden
ist. Die Serverstruktur unterhält
Zustandsinformationen bezüglich
der Verbindung dieses Servers. Der Verbindungsverwaltungscode erlaubt
es der Transportschicht 318, Einträge in der Global-Host-Bindetabelle 366 abzufragen,
hinzuzufügen,
zu modifizieren oder zu löschen.
-
Ein
neuer Eintrag in der Global-Host-Bindetabelle 366 wird
erzeugt, wenn ein Subsystem 300 ein Ereignis 700 erzeugt,
das auf einem Server 180' abgezielt
ist, der zuvor noch nicht kontaktiert wurde, oder wenn ein Ereignis 700 zum
ersten Mal von einem abgesetzten Server empfangen wird. In diesem
ersten Fall weist, wenn ein Subsystem 300 ein Ereignis 700 erzeugt,
das Subsystem 300 zuerst eine Kennung für den abgesetzten Server 180' zu und speichert
dann die Kennung als neuen Eintrag in der Global-Host-Bindetabelle 366. Wenn
die Transportschicht 318 das Ereignis 700 empfängt, bildet
die Transportschicht 318 die Serverstruktur für diesen
Server 180' und
fügt einen
Zeiger darauf in die Global-Host-Bindetabelle 366 ein.
Die Transportschicht 318 erhält dann den Namen des Servers 180' aus dem Ereignis 700 und
verwendet den Namen zum Nachschlagen der entsprechenden Netzwerkadresse
des Servers 180' aus
einem Domänennamenserver (DNS).
Danach speichert die Transportschicht 318 die Netzwerkadresse
des Servers 180' als
ein Feld in der Global-Host-Bindetabelle 366. Da nun die
Global-Host-Bindetabelle erfolgreich aufgefüllt wurde, um die Übertragung
des Ereignisses 700 zu unterstützen, versucht die Transportschicht 318 nun,
die Verbindung mit dem Server 180' herzustellen.
-
In
dem zweiten Fall ist, wenn ein abgesetzter Server 180' den lokalen
Server 180 kontaktiert, die Netzwerkadresse des abgesetzten
Servers 180' bekannt
und der Verbindungsverwaltungscode der Transportschicht 318 schlägt die Netzwerkadresse
in dem DNS nach, um den Namen des abgesetzten Servers zu erhalten.
Wenn der Name des abgesetzten Servers 180' nicht bereits als Eintrag in der
Global-Host-Bindetabelle 366 existiert, erzeugt die Transportschicht 318 den
Namen zusammen mit einer assoziierten Serverstruktur und fügt ihn in
die Global-Host-Bindetabelle ein. Danach liefert die Transportschicht 318 das
Ereignis 700 in dem empfangenen Paket zum weiteren Routen
an das Ereignisablieferobjekt 312 ab.
-
Eingangs-/Ausgangsblockierung
wird bis zu dem vernünftigen
Maß vermieden,
indem empfangene Pakete zum Einreihen der Pakete in Warteschlangen
zu dem Kernel gesendet werden. Es können jedoch nicht alle Operationen
ohne Blockierung ausgeführt
werden. Zum Beispiel müssen
mehrere blockierende Operationen ausgeführt werden, wenn eine Serverstruktur
für einen
bestimmten Server 180' nicht
existiert, wie zum Beispiel die Abfrage des DNS nach der Netzwerkadresse
des Servers 180'.
-
Die
Verbindung zu einem bestimmten Server 180' kann fallengelassen werden, wenn
für einen
Zeitraum kein Verkehr über
die Strecke geflossen ist. Wenn eine Verbindung aufgrund einer Zeitgrenzenbedingung neu
hergestellt werden muß,
reiht deshalb die Transportschicht 318 die Pakete in Warteschlangen
ein, verbindet wieder mit dem abgesetzten Server 180' und sendet
die Pakete über
die Kommunikationsstrecke. Wenn die Verbindung dagegen fallengelassen
wurde, weil der abgesetzte Server 180' heruntergefahren wurde, werden
die Pakete nicht in Warteschlangen eingereiht, sondern verworfen.
-
7.2 Gruppen-Subsystem
-
Jeder
Server 180 in der Server-Farm 110 enthält ein Gruppen-Subsystem 300 zum
Verwalten und Speichern homogener und heterogener Gruppen von Objekten
(z. B. Gruppen von Servern, Gruppen von Benutzern, Gruppen von Anwendungen,
Gruppen von Gruppen, Gruppen mit einer beliebigen Kombination von Servern,
Benutzern, Anwendungen und Gruppen). Die Gruppierung von Objekten
vereinfacht bestimmte Aufgaben zum Administrieren der Server-Farm 110,
wie zum Beispiel das Authorisieren von Anwendungen für Benutzer,
das Verteilen und Verfolgen von Lizenzen und das Ausgleichen von
Serverlasten. Zum Beispiel kann eine Gruppe die authorisierten Benutzer
eines Servers 180 umfassen, der ein bestimmtes Anwendungsprogramm
hostet. Diese Gruppeninformationen sind nützlich bei der Bestimmung,
ob eine zusätzliche
Last auf dem Anwendungsprogramm in die Lizensierungseinschränkungen
für dieses
bestimmte Anwendungsprogramm eingreift.
-
Das
Gruppen-Suchsystem 300 stellt eine zentralisierte Menge
gemeinsamer Funktionen zur Verwendung durch Subsysteme beim Ausführen von
Operationen an Gruppen bereit. Die durch das Gruppen-Subsystem 300 bereitgestellten
gemeinsamen Funktionen operieren unabhängig von der Art der Gruppe.
Die Bedeutung oder Nützlichkeit
einer bestimmten Gruppe wird durch das bestimmte Subsystem bestimmt,
das an der Gruppe operiert.
-
Zu
der durch das Gruppen-Subsystem 300 bereitgestellten Funktionalität gehört das Erzeugen
und Löschen
von Gruppen und das Hinzufügen,
Löschen
und Aufzählen
von Mitgliedern einer Gruppe. Jedes beliebige der Subsysteme 300 kann
Ereignisse zu dem Gruppen-Subsystem 300 lenken, um Gruppen
zu bilden, zu vernichten oder zu modifizieren, Gruppeninformationen
für ein
bestimmtes betreffendes Mitglied anzufordern, alle verfügbaren Gruppen
aufzuzählen,
Gruppen nach Typ aufzuzählen,
den Namen einer Gruppe durch eine eindeutige Kennung anzufordern
und umgekehrt. Zusätzlich
zu der Verwaltung der Gruppen, die es erzeugt, wickelt das Gruppen-Subsystem 300 auch
die Speicherung dieser Gruppen in dem persistenten Speicher 230 durch
Bilden einer Schnittstelle mit dem Dienstmodul 352 des
persistenten Speichersystems ab.
-
Das
Gruppen-Subsystem 300 verwendet eindeutige Kennungen, die
beim Herstellen von Beziehungen innerhalb der Gruppe und beim Bilden
der Gruppe selbst mit jedem gruppierten Objekt assoziiert werden. Da
jedes Objekt eine eindeutige Kennung aufweist, kann das Gruppen-Subsystem 300 die
Kennung in die Gruppe integrieren, die es bildet, statt das Objekt
selbst zu duplizieren.
-
Das
Gruppen-Subsystem 300 stellt außerdem eine Anzahl von API
bereit, mit denen andere Subsysteme 300 Gruppen manipulieren
können.
Einige der bereitgestellten API sind die folgenden:
Erzeugen
einer Gruppe und Zurückgeben
ihrer eindeutigen Kennung;
Umbenennen einer Gruppe;
Löschen einer
Gruppe;
Erhalten der Informationen einer Gruppe durch ihre
eindeutige Kennung;
Erhalten aller Gruppen, die ein spezifisches
Objektmitglied enthalten;
Modifizieren der Informationen einer
Gruppe unter Verwendung ihrer eindeutigen Kennung;
Aufzählen aller
Objektmitglieder in einer Gruppe;
Hinzufügen eines Objektmitglieds zu
einer Gruppe;
Löschen
eines Objektmitglieds aus einer Gruppe;
Aufzählen aller
Gruppen eines spezifischen Typs;
Bestimmen, ob ein Objektmitglied
in einer Gruppe enthalten ist;
Erhalten des Namens einer Gruppe
durch ihre eindeutige Kennung oder der eindeutigen Kennung durch
Spezifizieren des Gruppennamens; und
Freigeben von zugeteiltem
Speicher.
-
Als
beispielhafte Ausführungsform
der Funktionsweise des Gruppen-Subsystems 300 betrachte
man, daß ein
Administrator ein Softwareprodukt auf mehreren Servern 180 in
der Server-Farm 180 installieren möchte. Um diese Aufgabe zu lösen, wird
ein Installationsprogramm auf einem der Server 180 in der
Server-Farm 110 ausgeführt.
Das Installationsprogramm weist das Gruppen-Subsystem 300 an,
eine Gruppe zu erzeugen und jeden Server als Mitglied zu der erzeugten
Gruppe hinzuzufügen.
Diese Servergruppe wird in dem persistenten Speicher 230 gespeichert,
der durch das Dienstmodul des persistenten Speichersystems allen
Gruppen-Subsystemen 300 auf jedem anderen Server 180 zugänglich ist.
-
Die
Installation des Softwareprodukts beginnt dann auf jedem Server 180.
Wenn die Installation auf einem Server abgeschlossen wird, weist
das Installationsprogramm das Gruppen-Subsystem 300 an,
das diesem Server entsprechende Mitglied aus der Servergruppe zu
löschen.
Während
jeder Server die Installation abschließt, werden Mitglieder aus der
Servergruppe entfernt. Wenn die Servergruppe keine Mitglieder enthält, zeigt
dies an, daß der
Installationsprozeß für jeden
Server 180 abgeschlossen ist.
-
7.3 Das Beziehungs-Subsystem
-
Das
Beziehungs-Subsystem 300 verwaltet Beziehungen (d. h. Assoziationen)
zwischen Objekten als Reaktion auf von anderen Subsystemen 300 empfangene
Ereignisnachrichten 700. Der Verfasser/Eigentümer der
Beziehung (z. B. ein Subsystem 300) spezifiziert, ob die
Beziehung zwischen Objekten oder Gruppen von Objekten besteht, und
die Art der Beziehung. Die Bedeutung der Beziehung wird nur durch
das Subsystem, das sie erzeugt, definiert und verstanden. Das Beziehungs-Subsystem 300 verwaltet
und speichert hauptsächlich
die Beziehung ohne Verständnis
der Bedeutung der durch ein Subsystem 300 erzeugten Beziehung.
-
Das
Beziehungs-Subsystem 300 weist jeder Beziehung, die es
erzeugt, eine eindeutige Kennung zu und speichert die Beziehungen
als persistente Objekte in dem persistenten Speicher 230.
Außerdem
stellt das Beziehungs-Subsystem 300 einen Mechanismus zum
Umgang mit Änderungen
in den eine Beziehung bildenden Objekten bereit. Wenn zum Beispiel
ein Server aus einer Server-Farm 110 entfernt
wird, benachrichtigen die Subsysteme 300, denen eine definierte
Beziehung gehört,
an der der entfernte Server beteiligt ist, das Beziehungs-Subsystem 300 über die Änderung
und das Beziehungs-Subsystem 300 löscht oder
modifiziert danach die Beziehung.
-
Zu
den Datenfeldern eines Beziehungs-Objekts gehören die folgenden:
eine
Beziehungskennung, die das Beziehungs-Objekt eindeutig identifiziert;
ein
Typ, der die tatsächliche
Bedeutung einer Beziehung repräsentiert
(z. B. repräsentiert
ein Typ „Authorisierung", das ein Benutzer
administrative Zugangsprivilegien besitzt);
eine Attributobjektkennung,
die Informationen über
einen bestimmten Typ von Beziehung enthält (z. B. kann für einen
Typ „Ausführungsserver", was bedeutet, daß eine Anwendung
auf einem bestimmten Server 180 Last ausgeglichen wurde,
ein Attributobjekt den Netzwerkort dieser Anwendung auf dem Server 180 spezifizieren); und
Daten
zum Repräsentieren
der eindeutigen Kennungen und/oder bestimmten Namen jedes an der
Beziehung beteiligten Objekts.
-
Das
Beziehungs-Subsystem 300 stellt außerdem API bereit, die es anderen
Subystemen 300 erlauben, die Funktionalität des Beziehungs-Subsystems 300 zu
verwenden, obwohl nur ihre Eigentümer-Subsysteme auf die Beziehungen
selbst zugreifen können.
Die durch die SAL bereitgestellte Funktionalität umfaßt folgendes:
Erzeugen
einer Beziehung;
Löschen
einer gegebenen Beziehung;
Löschen aller Beziehungen mit
einer gegebenen Menge von Datenfeldern;
Aufzählen aller
Beziehungen, die eine gemeinsame Menge/Teilmenge von Mitgliedern
aufweisen; und
Holen und Setzen der eindeutigen Kennung eines
Attributs für
eine gegebene Beziehung.
-
Als
Beispiel betrachte man einen Administrator der Server-Farm 110,
der einen Lastevaluierer auf zwei oder mehr Server 180 der
Server-Farm 110 anwenden möchte. Als erstes kommuniziert
das Lastverwaltungs-Subsystem mit dem Gruppen-Subsystem 300,
um eine Gruppe zu bilden, die eine Menge von Regeln für den Lastevaluierer
umfaßt.
Dann kommuniziert das Lastverwaltungs-Subsystem über den Ereignisbus 310 mit
dem Beziehungs-Subsystem 300, um eine Assoziation zwischen
dem Lastevaluierer und jedem Server 180 zu erzeugen. Wenn
eines dieser Server 180 Lastausgleich anfordert, fragt
das Lastverwaltungs-Subsystem das Beziehungs-Subsystem 300 ab,
um den mit diesem Server assoziierten Lastevaluierer zu bestimmen,
und wendet jede der Regeln unter dem Lastevaluierer an, um die Last
des Servers zu bestimmen.
-
7.4. Das Lastverwaltungs-Subsystem
-
Das
Lastverwaltungs-Subsystem (LMS) stellt eine Lastverwaltungsfähigkeit
bereit, die auswählt,
welcher Server 180 in der Server-Farm 110 eine
Client-Anforderung
versorgen wird, d. h. welcher Server 180 eine Anwendung
für einen
Client 120 ausführen
wird. Im allgemeinen verwaltet das LMS die Gesamtserver- und -netzwerklast
zur Minimierung der Ansprechzeit auf Client-Anforderungen.
-
Bei
einer Ausführungsform
basiert das LMS auf Regeln, und es kann ein Administrationswerkzeug 140 verwendet
werden, um Regeln für
die Verwaltung der Serverlast zu modifizieren oder zu erzeugen.
Bei einer Regel handelt es sich um eines oder mehrere Kriterien,
die beeinflussen, wie ein LMS Anforderungen leiten wird. Regeln
können
auf einen spezifischen Server 180 individualisiert werden.
Regeln können
auch serverweise auf eine spezifische Anwendung individualisiert
werden. Das heißt,
es können
eine oder mehrere Regeln mit einer Kopie einer auf einem ersten
Server 180 in der Farm 110 residierenden Anwendung
assoziiert werden und mit einer Kopie derselben Anwendung, die auf
einem zweiten Server 180 in einer Farm 110 residiert,
andere Regeln assoziiert werden. Die Ausgabe von auf eine spezifische
Anwendung individualisierten Regeln kann mit der Ausgabe allgemeiner
Serverregeln zum Lenken einer Client-Anforderung kombiniert werden.
-
Regeln
verwenden die Ausgabe eines oder mehrerer Betriebszähler. Betriebszähler können einen
beliebigen Aspekt der Server-Leistungsfähigkeit messen, und das Ergebnis
wird von Regeln benutzt, um dabei zu helfen, zu bestimmen, welcher
Server 180 am besten für
die Versorgung einer Client-Anforderung geeignet ist. Zum Beispiel
können
Betriebszähler
folgendes messen: Prozessorlast; Kontextwechsel; Speicherbenutzung;
Seitenfehler; Seiten-Swaps; Übertragungsrate
von Eingangs-/Ausgangsleseoperationen oder -Schreiboperationen;
Anzahl der durchgeführten
Eingangs-/Ausgangsoperationen.
Bei einer Ausführungsform
verwendet ein LMS Betriebszähler
zur Messung der Server-Leistungsfähigkeit während des Auftretens bestimmter
Ereignisse, wie etwa einer Anforderung einer Client-Verbindung.
Bei einer anderen Ausführungsform
verwendet ein LMS Betriebszähler
zur Messung der Server-Leistungsfähigkeit in vorbestimmten Intervallen,
die von einem Administrator konfiguriert werden können. Ein
LMS auf jedem Server 180 in der Farm 110 evaluiert verschiedene
Leistungsmetriken für
den Server 180 für
jeden vorbestimmten Zeitraum und speichert diese Informationen in
dem dynamischen Speicher 240, indem eine Ereignisnachricht
zu dem Dienstmodul 356 des dynamischen Speichersystems
gesendet wird. Zum Beispiel kann alle 30 Sekunden eine Evaluierung
der Serverlast eine Abfrage von Betriebszählern bezüglich der CPU-Auslastung und Speicherauslastung
des Servers umfassen. Die Ergebnisse der Abfrage werden in Verbindung
mit anderen relevanten Lastfaktoren zur Berechnung einer Lastzahl
für diese
Serverlast verwendet. Die neue Lastzahl wird dann zu dem dynamischen
Speicher gesendet.
-
Bei
diesen Ausführungsformen
kann das LMS ein Ereignis „Intervall ändern" subskribieren, das
von den Administrationswerkzeug-Subsystem ausgegeben wird, um über das
richtige zu verwendende vorbestimmte Intervall benachrichtigt zu
werden. Das heißt,
das Ereignis „Intervall ändern" informiert ein LMS,
daß ein
neuer Wert für
das Intervall in dem persistenten Speicher gespeichert wurde. Als
Alternative kann das Administrationswerkzeug 140 ein Ereignis „Intervall ändern" zu einem in der
Server-Farm 110 anwesenden LMS senden. Dieses LMS aktualisiert
den in dem persistenten Speicher 230 gespeicherten Intervallwert
und sendet auch ein Ereignis zu allen anderen in der Server-Farm 110 anwesenden
LMS, wodurch diese informiert werden, den neuen Intervallwert aus
dem persistenten Speicher 230 abzurufen. Bei weiteren Ausführungsformen kann
jedes LMS den persistenten Speicher 230 auf eine Änderung
des Intervallwerts überwachen.
-
Bei
einer Ausführungsform
gibt es zwei verschiedene Intervalleinstellungen: eine für Resourcenlastabtastung
und eine andere für
die LMS-Überwachungs-Hilfssoftware.
Bei einer weiteren Ausführungsform
kann jeder mit einem Server 180 assoziierte Betriebszähler ein
separates Intervall verwenden. Betriebszähler können durch eine DLL bereitgestellt
werden, wie zum Beispiel die von der Microsoft Corporation Redmond,
Washington, hergestellte pdh.dll-Bibliothek.
-
Regeln
und Betriebszähler
sind bei einer Ausführungsform
ausführbare
Codemodule, die spezifische Systemzustände, Ressourcen und Leistungsmetriken
für Server 180 in
der Server-Farm 110 abfragen. Bestimmte der Regeln nehmen
benutzerkonfigurierbare Parameter an, die vom Administrator über das
Administrationswerkzeug 140 eingegeben werden. Regeln können dem
LMS unter Verwendung einer DLL („Dynamic Link Library") gegeben werden,
und die für
einen spezifischen Server geltenden Regeln und Regelparameter können in
dem persistenten Speicher 230 gespeichert werden. Das heißt, die
Auswahl von Regeln des Administrators wird zusammen mit einem Gewichtungsfaktor
und relevanten mit diesen Regeln assoziierten Einstellungen in dem
persistenten Speicher gespeichert. Zum Beispiel können bestimmte
Betriebszähler
die Last in einem vorbestimmten Intervall messen; das vorbestimmte
Intervall kann vom Administrator eingestellt werden.
-
Beispiele
für Konditionalregeln,
die das LMS verwenden kann, um zu bestimmen, zu welchen Server 180 eine Anforderung
zu leiten ist, wären:
ob die Anzahl der Clients 120, die sich mit einem Server 180 verbinden
können,
begrenzt ist; ob die Anzahl der Client-Sitzungen, die von einem Server 180 versorgt
werden können,
begrenzt ist; die Anzahl der einem Server 180 zur Verfügung stehenden
Anwendungs- oder Verbindungsgrenzen; ob ein Server 180 Mitglied
einer bestimmten Zone ist; ob die von dem Client 120 angeforderte
Anwendung gerade auf dem Server 180 ausgeführt wird;
ob sich ein Client physisch in der Nähe eines Servers befindet oder
durch eine Strecke mit hoher Bandbreite mit ihm verbunden wird;
und ob während
eines Zeitraums, für
den der Server 180 für
die Versorgung von Client-Anforderungen verfügbar ist, eine Client-Anforderung
gestellt wird.
-
Eine
Menge von Regeln kann durch das Gruppen-Subsystem 300 gruppiert
werden, um einen Lastevaluierer zu bilden, der mit einem bestimmten
Server oder mit einer bestimmten Anwendung assoziiert ist. Ein Serverlast-Evaluierer ist ein
Lastevaluierer, der für
alle auf dem Server publizierten Anwendungen gilt. Ein Anwendungslast-Evaluierer
ist ein Lastevaluierer, der für
bestimmte Anwendungen spezifische Regeln einkapselt. Bei einer Ausführungsform
sind Lasten für
publizierte Anwendungsprogramme die Summe eines Serverlast-Evaluierers
und eines Anwendungslast-Evaluierers.
Der mit einem bestimmten Server assoziierte Lastevaluierer kann
in den persistenten Speicher 230 gespeichert werden. Wenn
sich ein LMS initialisiert, fragt es den persistenten Speicher 230 ab,
um zu bestimmen, ob ein Lastevaluierer mit dem Server 180 assoziiert
ist, auf dem das LMS residiert. Wenn dies der Fall ist, werden die
Regeln und Betriebsparameter geladen und das LMS beginnt mit der
Verwendung dieser Elemente des Lastevaluierers. Die Ausgaben der
Bestandteile des Lastevaluierers werden kombiniert, um zusammengesetzte
Indicia der Lasts auf bestimmten Servern zu berechnen, und jedes
LMS speichert die Ergebnisse seines Lastevaluierers im dynaamischen
Speicher. Jede in einem Lastevaluierer eingekapselte Regel kann
einen konfigurierbaren Gewichtungsfaktor aufweisen. Viele Regeln
weisen benutzerkonfigurierbarer Parameter auf, die steuern, wie
LMS-Lasten berechnet werden. Zum Beispiel weist bei einer Ausführungsform
eine CPU-Auslastungsregel zwei Parameter auf: Melde-Vollast, wenn
die Prozessorauslastung größer als
X Prozent ist; Melde keine Last, wenn die Prozessorauslastung kleiner
als X Prozent ist. Bei einer konkreten Ausführungsform ist die von einem
Lastevaluierer gemeldete Last gleich der Summe der Last jeder Regel
mal dem Gewicht jeder Regel.
-
Bei
einem anderen Beispiel kann ein Server 180, der Host für vier Anwendungen
ist, drei Lastevaluierer aufweisen, mit denen er assoziiert ist.
Der Server selbst und eine erste Anwendung können mit einem ersten Lastevaluierer
assoziiert sein, die zweite und dritte Anwendung können mit
einem zweiten Lastevaluierer assoziiert sein und die vierte Anwendung
kann mit einem dritten Lastevaluierer assoziiert sein. Wenn der
Server 180 bootet, liest er den ersten, zweiten und dritten
Lastevaluierer aus dem persistenten Speicher 230. Periodisch
(oder vielleicht nach bestimmten Ereignissen) berechnet der Server 180 die
Ausgabe für
jeden der Lastevaluierer und sendet diese Werte zu dem dynamischen
Speicher. Wenn eine Verbindungsanforderung empfangen wird, werden
diese Werte verwendet, um zu bestimmen, ob der Server 180 eine
Client-Anforderung versorgen soll.
-
Unter
Verwendung von Betriebszählern
kann das LMS zum Beispiel Informationen über die Prozessorlast auf einem
bestimmten Server 180, die Speicherlast auf diesem Server 180 und
die Netzwerklast dieses Servers 180 erhalten. Das LMS kombiniert
diese Ergebnisse, um eine Gesamt-Lastzahl zu erhalten, die die gesamte
aggregierte Last auf diesem Server 180 angibt. Bei der Bestimmung
der aggregierten Last kann der Lastevaluierer jedes Informationselements
verschieden gewichten. Bei Ausführungsformen,
bei denen eine Regel mit einem Server 180 assoziiert ist,
kann die Regel einen Server 180 von der Versorgung einer
Client-Anforderung
disqualifizieren. Zum Beispiel kann eine Regel die Anzahl der Client-Sitzungen
begrenzen, die ein Server 180 einleiten kann. Bei dieser
Ausführungsform
wird, wenn ein Server 180 gerade die maximale Anzahl von
Client-Sitzungen versorgt, die von der Regel erlaubt wird, er von
dem LMS nicht für
die Versorgung einer neuen Client-Anforderung ausgewählt, auch
wenn die Ausgaben seiner Betriebszähler anzeigen, daß er der
günstigste
Server 180 ist, zu dem die Client-Anforderung geroutet
werden kann.
-
Bei
einer konkreten Ausführungsform
liegen Lastausgleichslasten im Bereich zwischen 0–10.000,
wobei 0 die geringste Belastung und 10.0000 volle Belastung repräsentiert.
Das LMS spawned alle 30 Sekunden mit der aktualisierten Last aller
von diesem Server 180 verwendeten Lastevaluierer eine Thread-Aktualisierungslast-Evaluiererinformation
in dem dynamischen Speicher.
-
Im
Betrieb empfängt
das LMS eine Ereignisnachricht, die eine Server-ID anfordert, zu
der eine Client-Anforderung
geleitet werden soll. Das LMS fragt mit der angeforderten Anwendung
assoziierte Lastevaluierer-Informationen
ab. Gegebenenfalls können
Berechnungen auf der Basis von Komponentengewichtungen erfolgen.
Bei einer konkreten Ausführungsform
erzwingen bestimmte Regeln eine Berechnung des Lastevaluierers zum
Zeitpunkt der Anforderung. Bei dieser Art von Regel werden die Ergebnisse
der Lastevaluierung nicht in einem rechtzeitigen Intervall in dem
dynamischen Speicher aktualisiert, sondern wenn eine Client-Anforderung hereinkommt.
Eine Regel dieses Typs kann verwendet werden, um es Servern zu erlauben,
nur Clients in einer bestimmten Zone 260, 270 zu
versorgen. Das LMS gibt über
eine Ereignisnachricht eine Server-ID an das anfordernde Suchsystem
zurück.
-
Bei
einer konkreten Ausführungsform
sendet das LMS jedesmal, wenn eine Client-Verbindung angefordert
wird, ein Ereignis zu dem Administrationswerkzeug-Subsystem, und
eine weitere Nachricht, die angibt, zu welchen Server 180 die
Client-Verbindung gelenkt wurde. Dadurch kann das Administrationswerkzeug
eine Protokollierung von Client-Verbindungen zur späteren Bezugnahme
führen.
-
Mit
einem Administrationswerkzeug 140 kann man Regeln modifizieren
oder erzeugen, Regeln zu Lastevaluierern gruppieren oder die Ergebnisse
einer Lastevaluierung für
einen bestimmten Server 180 anzeigen. Bei einer konkreten
Ausführungsform
zeigt das Administrationswerkzeug 140 dem Administrator
eine grafische Darstellung der Ausgabe des Lastevaluierers zusammen
mit einer grafischen Darstellung der Ausgabe der den Lastevaluierer
umfassenden Betriebszähler
an.
-
Ähnlich kann
ein Administrator mit dem Administrationswerkzeug 140 die
Lastinformationen für
jeden Server 180 abfragen und diese Lastinformationen gemäß einer
bestimmten angeforderten Ansicht anzeigen. Zum Beispiel kann der
Administrator die Gesamt-Serverlast,
den Wert eines bestimmten Betriebszählers oder einer Regel zu einem
bestimmten Zeitpunkt oder eine bestimmte Kombination dieser Ansichten
anzeigen. Bei einer Ausführungsform
kann der Administrator das LMS „testen", indem von dem LMS angefordert wird,
eine Serverlastberechnung auszuführen
und den Server 180 anzuzeigen, mit dem ein Client verbunden
worden wäre,
wenn ein Client eine Anforderung gestellt hätte. Die von dem Überwachungssystem
angezeigten Lastinformationen können
aktuelle sowie Vorgeschichtedaten (z. B. Prozessor- und Speicherauslastung,
Vorkommnisse von Seitenfehlern) für einen bestimmten Server 180 oder
eine bestimmte Anwendung enthalten.
-
7.5 Das Lizenzverwaltungs-Subsystem
-
Jeder
Server 180 in der Server-Farm 110 enthält ein Lizenzverwaltungs-Subsystem
zum Konfigurieren und Unterhalten von Lizenzen für diejenigen Subsysteme 300,
die eine Lizenz für
den Betrieb benötigen,
und zum Steuern der Anzahl der Verbindungen mit solchen Subsystemen 300.
Das Lizenzverwaltungs-Subsystem verwaltet zwei Arten von Lizenzen
(1) Merkmallizenzen und (2) Verbindungslizenzen. Als kurze Übersicht
verwendet das Lizenzverwaltungs-Subsystem Merkmallizenzen zum Regeln
des Zugangs zu „Merkmalen" lizenzierter Softwareprodukte,
wie etwa Lastverwaltung, und Verbindungslizenzen zum Regeln der
Anzahl der Benutzerverbindungen, die diese lizenzierten Softwareprodukte
erlauben. Ein Merkmal kann ein bestimmter Aspekt oder eine bestimmte
Funktionalität
des Softwareprodukts sein, oder das Merkmal kann das gesamte Produkt
sein, das ohne Merkmallizenz nicht funktionieren wird.
-
Nicht
jedes Subsystem 300 in einem Server 180' benötigt eine
Merkmallizenz zum Betrieb. Diejenigen Subsysteme 300, die
eine Merkmallizenz benötigen
(z. B. ein spezialisiertes Server-Subsystem des Softwareprodukts
MetaFrame 2.0) kann die lizenzierte Fähigkeit nicht ausführen oder
Client-Verbindungen gewähren, ohne
die Merkmallizenz von dem Lizenzverwaltungs-Subsystem zu erhalten.
-
11 zeigt eine Ausführungsform des Servers 180 in
der Server-Farm 110, bei der die Subsysteme 300 folgendes
umfassen: ein Lizenzverwaltungs-Subsystem 1110, ein Gruppen-Subsystem 1120,
das Dienstmodul 352 des persistenten Speichersystems, das
Dienstmodul 356 des dynamischen Speichersystems, ein Beziehungs- Subsystem 1130,
ein spezialisiertes Server-Subsystem 1140 und ein Gemeinschaftszugangspunkt-Subsystem 345 in
Kommunikation mit dem Ereignisbus 310. Die in 11 gezeigten Subsysteme dienen zur Beschreibung
des Verhaltens des Lizenzverwaltungs-Subsystems 1100. Der
Server 180 kann andere Arten von Subsystemen 300 enthalten.
-
Das
Lizenzverwaltungs-Subsystem 1110 kommuniziert über den
Ereignisbus 310 mit dem Gruppen-Subsystem 1120,
um eine logische Gruppierung von Lizenzen (im folgenden „Lizenzgruppen") zur Ermöglichung
von Lizenz-Pools, Zuweisungen und Gruppen zu bilden und zu unterhalten.
Eine Lizenzgruppe enthält eine
Ansammlung von Lizenz-Zeichenketten,
die nachfolgend beschrieben werden wird, und/oder andere Lizenzgruppen.
Lizenzgruppen sammeln Lizenzen ähnlicher
Merkmale und ermöglichen
folglich ein Pooling von Lizenzen. Eine gepoolte Lizenz ist eine
Lizenz, die für
die Verwendung durch einen beliebigen Server 180 in Server-Farm 110 verfügbar ist.
Jede Lizenzgruppe hält
die kollektiven Fähigkeiten
der Lizenzen in der Lizenzgruppe und in den anderen Lizenzgruppen
(d. h. anderen Lizenzgruppen in einer Lizenzgruppe). Informationen bezüglich Lizenz-Pools
werden bei einer Ausführungsform
in dem dynamischen Speicher 240 geführt. Bei dieser Ausführungsform
speichert jedes Lizenzverwaltungs-Subsystem 1110 lokal
die Gesamtzahl der Lizenzen und die Anzahl der Lizenzen, die einen
Server 180 in der Server-Farm 110 zugewiesen sind.
Nach der Gewährung
einer gepoolten Lizenz erstellt das gewährende Lizenzverwaltungs-Subsystem 1110 einen
Eintrag in den dynamischen Speicher 240, der angibt, daß eine gepoolte
Lizenz „gerade
genutzt" wird. Jedes
andere Lizenzverwaltungs-Subsystem 1110 erkennt,
daß eine
solche gepoolte Lizenz nicht für
Gewährung
verfügbar
ist. Bei einer konkreten Ausführungsform
speichert der dynamische Speicher 240 mit jeder Lizenzgruppe
assoziierte Paare von Server- ID/Client-ID,
um gepoolte Lizenzen zu identifizieren, die gerade genutzt werden.
-
Das
Beziehungs-Subsystem 1130 unterhält Assoziationen zwischen den
Lizenzen und Servern und zwischen Lizenzgruppen und Servern. Die
Assoziationen definieren die Anzahl der Lizenzen für jede Lizenz und
Lizenzgruppe, die nur der assoziierte Server 180 erhalten
kann (d. h. „lokale
Lizenzen"). Eine
lokale Lizenz ist eine Lizenz, die einem Server in der Server-Farm 180 zugewiesen
ist und nicht von anderen Servern 180 gemeinsam benutzt
wird. Das Lizenzverwaltungs-Subsystem 1110 kommuniziert
mit dem Beziehungs-Subsystem 1130,
um solche Assoziationen zu erzeugen, zu löschen, abzufragen und zu aktualisieren.
Das Gemeinschaftszugangspunkt-Subsystem 645, das in dem
nachfolgenden Abschnitt 7.11 beschrieben wird, stellt RPC (Remote
Procedure Calls) für
die Verwendung durch auf dem Server 180 residierende Softwareprodukte bereit.
Diese RPC-Schnittstellen ermöglichen
es solchen Softwareprodukten, durch das Gemeinschaftszugangspunkt-Subsystem 645 zu
kommunizieren, um auf Lizenzierungsinformationen zuzugreifen.
-
Mit
Bezug auf 11 kommuniziert ein in dem
nachfolgenden Abschnitt 7.10 beschriebenes spezialisiertes Server-Subsystem 1140 mit
dem Lizenzverwaltungs-Subsystem 1110, um eine Merkmallizenz
für jede Fähigkeit
des spezialisierten Server-Subsystems 1140 zu
erhalten, für
die eine Lizenz erforderlich ist. Dies erfolgt bei der Initialisierung
des spezialisierten Server-Subsystems 1140 und nach jedem
Lizenzereignis (nachfolgend beschrieben). Wenn die Merkmallizenz
nicht erhalten werden kann, schränkt
das spezialisierte Server-Subsystem 1140 die Funktionalität, die das
Subsystem bereitstellen würde,
mit einer Lizenz ein. Außerdem verwendet
das spezialisierte Server-Subsystem 1140 das Lizenzverwaltungs-Subsytem 1110,
um immer dann, wenn eine Client-Sitzung mit dem Server 180 eingeleitet
wird, Client-Verbindungslizenzen zu erhalten.
-
Das
Lizenzverwaltungs-Subsystem 1110 kommuniziert mit dem Dienstmodul 352 des
persistenten Speichersystems, um Merkmal- und Verbindungslizenzen
als gemäß einer
Benennungskonvention gebildete Lizenzzeichenkette in einem Lizenzdepot 1150 zu
speichern. Das Lizenzdepot 1150 residiert in dem persistenten
Speicher 230. CRC-Prüfungen (Cyclical
Redundancy Checks) verhindern eine Manipulation der Lizenzen, während solche
Lizenzen in dem Lizenzdepot 1150 gespeichert sind. Das
Lizenzverwaltungs-Subsystem 1110 speichert außerdem Informationen
bezüglich
der Lizenzzeichenketten in dem Lizenzdepot 1150. Zum Beispiel können die
Informationen angeben, welche Lizenzen welchen Servern 180 der
Server-Farm 110 zugewiesen sind, und bei bestimmten Ausführungsformen,
den Aktivierungsstatus der Lizenz. Bei einer Ausführungsform speichert
eine Verbindungslizenztabelle 670 Kennungen der Clients,
die eine Verbindungslizenz erhalten haben.
-
Das
Lizenzverwaltungs-Subsystem 1110 unterstützt drei
Kategorien von Ereignissen. Eine Kategorie enthält Ereignisse 700,
die andere Subsysteme 300 zu dem Lizenzverwaltungs-Subsystem 1110 senden.
Zum Beispiel kann das Gemeinschaftszugangspunkt-Subsystem 645 ein
Ereignis zu dem Lizenzverwaltungs-Subsystem 1110 senden,
das eine Merkmallizenz anfordert. Eine zweite Kategorie enthält Ereignisse 700,
die das Administrationswerkzeug 140 zu dem Lizenzverwaltungs-Subsystem 1110 sendet.
Zum Beispiel kann ein Administrator mit dem Administrationswerkzeug 140 Lizenzen
aus dem Lizenzdepot 1150 hinzufügen oder löschen. Eine dritte Kategorie
enthält
Ereignisse 700, die das Lizenzverwaltungs-Subsystem 1110 zu
anderen Subsystemen sendet. Zum Beispiel kann das Lizenzverwaltungs-Subsystem 1110 ein
Ereignis zu dem Dienstmodul 352 des persistenten Speichersystems sendenden,
das eine Aufzählung
von dem Server 180 zugewiesenen Lizenzen oder eine Liste
aller Arten von Lizenzen und Lizenzzeichenketten, die verfügbar sind,
anfordert.
-
Das
Lizenzverwaltungs-Subsystem 1110 unterstützt außerdem Konfigurations-Task,
die von dem Administrationswerkzeug 140 oder Befehlszeilen-Hilfssoftwareen (d.
h. einem Softwareprodukt, das durch das Gemeinschaftszugangs-Subsystem
kommuniziert) für
die Unterhaltung von Lizenzzeichenketten und Lizenzgruppen benötigt werden.
Eine Konfigurations-Task ist das Hinzufügen einer Lizenzzeichenkette
zu dem Lizenzdepot 1150. Wenn zum Beispiel eine Merkmallizenz
zu der Tabelle 160 hinzugefügt wird, stellt das Lizenzverwaltungs-Subsystem
sicher, daß die
entsprechende Lizenzzeichenkette eindeutig ist (durch Vergleichen der
hinzugefügten
Lizenz mit der in dem persistenten Speicher 230 gespeicherten
Lizenz) und korrekt ist (unter Verwendung einer CRC). Bei einer
Ausführungsform
verzeichnet das Lizenzverwaltungs-Subsystem 1110 die Zeit des
Speicherns der Lizenzzeichenkette, die als Installationszeit bezeichnet
wird. Wenn der Benutzer die Lizenzzeichenkette vor der Aktivierung
der Lizenz entfernt und die Lizenz später wiederherstellt, verwendet das
Lizenzverwaltungs-Subsystem 1110 die anfängliche
Installationszeit und nicht die aktuelle Zeit der Neuinstallation
für diese
Lizenzzeichenkette. Dies verhindert, daß der Benutzer eine Lizenzzeichenkette
entfernt und wieder installiert, um eine neue Gratisperiode (d.
h. eine Versuchsperiode für
die Benutzung der lizenzierten Fähigkeit)
zu erneuern. Nach dem Abschluß des
Hinzufügens
der Lizenzzeichenkette zu dem Lizenzdepot 1150 gibt das
Lizenzverwaltungs-Subsystem 1110 ein Lizenzänderungsereignis 700 aus.
-
Eine
andere Konfigurations-Task ist das Entfernen einer Lizenzzeichenkette
aus dem Lizenzdepot 1150. Bei einer Ausführungsform
markiert das Lizenzverwaltungs-Subsystem 1110 die
Lizenzzeichenkette als entfernt, entfernt sie aber nicht tatsächlich.
Dies ermöglicht
Wiederherstellungen der Lizenzzeichenkette mit der ursprünglichen
Installationszeit wie oben beschrieben, wenn die Lizenz später neu
installiert wird. Wenn die betreffende Lizenzzeichenkette vor der
Entfernung nicht aktiviert wurde, wird die Lizenzzeichenkette tatsächlich aus
dem Depot entfernt.
-
Eine
weitere Konfigurations-Task ist das Aktivieren einer Lizenzzeichenkette.
Um eine Lizenzzeichenkette zu aktivieren, verbindet sich der Benutzer
mit einem Webserver, gibt durch eine dargestellte Webseite die Lizenzzeichenkette
ein und empfängt
einen Aktivierungscode von dem Webserver. Der Aktivierungscode wird
dem Administrator der Farm 1110 unterreicht und durch den
Administrator unter Verwendung des Administrationswerkzeugs oder
der Befehlszeilen-Hilfssoftware eingegeben, um die Lizenzzeichenkette
zu aktivieren. Das Lizenzverwaltungs-Subsystem 1110 verifiziert,
daß die
CRC für
die Lizenzzeichenkette gültig
ist und markiert die Lizenz in dem persistenten Speicher 230 als
aktiviert. Das Aktivieren der Lizenzzeichenkette verhindert ein
Ablaufen der Lizenz und verhindert eine mehrfache Benutzung dieser
Lizenzzeichenkette.
-
Zu
anderen Konfigurations-Tasks gehört,
Servern Lizenzgruppen zuzuweisen und ältere (d. h. Legacy-)Lizenzzeichenketten
zu der von dem Protokoll der Server-Farm 110 benutzten
Benennungskonvention zu migrieren. Ein Beispiel für eine solche
Lizenzmigration ist das Integrieren von Papierlizenzen in das Lizenzdepot 1150 während der
Installation eines Basisprodukts auf dem Server 110. Die
Installation nimmt alte Lizenzen aus der Registrierdatenbank heraus und
speichert diese durch das Gemeinschaftszugangspunkt-Subsystem 645 in
dem persistenten Speicher 230.
-
Bei
einer Ausführungsform
unterstützt
das Lizenzverwaltungs-Subsystem 1110 Ereignisse aus Subsystemen 300,
die die Verwendung einer lizenzierten Fähigkeit anfordern, wie zum
Beispiel eine Anforderung einer verfügbaren gepoolten Lizenz. Das
Ereignis enthält
die UID des Subsystems 300, das die Lizenz anfordert, und
die UID des Servers 180, auf dem dieses Subsystem 300 residiert.
Außerdem
enthält
das Ereignis den angeforderten Lizenztyp (d. h. Merkmals- oder Verbindungslizenz)
in Form einer Lizenzgruppen-ID. Die tatsächliche in dem persistenten
Speicher 230 gespeicherte Lizenzgruppen-ID ist beliebig,
eine Einhaltung der Benennungskonvention ermöglicht jedoch Flexibilität für die zukünftige Hinzufügung neuer
Softwareprodukte (d. h. Subsysteme) zu dem Server 180.
-
Wie
oben beschrieben, stellt das Ereignis außerdem eine eindeutige Kennung
der lizenzierten Fähigkeit
bereit. Zum Beispiel kann bei einer Merkmallizenz die eindeutige
Kennung eine vom Ausgeber des Ereignisses (z. B. einem externen
Softwareprodukt) erzeugte Zufallszahl sein, vorausgesetzt, daß die Zufallszahl aus
einem geeignet großen
Zahlenraum ausgewählt
wird. Bei einer anderen Ausführungsform
ist die eindeutige Kennung die ID des anfordernden Subsystems 300.
Bei dieser Ausführungsform
weisen die UID des anfordernden Subsystems und die eindeutige Kennung
dieselben Informationen auf. Bei einer Verbindungslizenz kann die
eindeutige Kennung die Client-ID sein. Die UID des anfordernden
Subsystems und die eindeutige Kennung können somit verschieden sein.
-
Das
Ereignis, das ein anforderndes Subsystem 300 sendet, das
eine Lizenz ersucht, enthält
(1) eine Angabe des Lizenzgruppentyps, die Identität des Clients und
Servers, der die Lizenz anfordert, und ein Flag „Beschaffung erzwingen". Eine Angabe des
Lizenzgruppentyps kann eine Identifikation einer Merkmallizenz, wie
etwa einer Lastverwaltung, oder eine Verbindungstyplizenz, wie etwa
ein Softwareanwendungsprodukt, enthalten. Das Feld, das den Client
und den Server identifiziert, der die Lizenz ersucht, kann die mit
dem Server und dem Client assoziierte eindeutige Kennung enthalten.
Das Flag Beschaffung erzwingen kann zum Beispiel verwendet werden,
um Verbindungslizenzen nach einem Lizenzänderungsereignis neu zu beschaffen. Ein
Lizenzänderungsereignis
gibt an, daß sich
Lizensierungsinformationen in dem persistenten Speicher 230 geändert haben;
zum Beispiel wurde eine Lizenz gelöscht, hinzugefügt oder
zugewiesen. Bei einem Lizenzänderungsereignis
versucht jeder Server 180, alle Verbindungslizenzen, die
er vor dem Lizenzänderungsereignis besaß, neu zu
beschaffen, weil die konkrete Ursache des Lizenzänderungsereignisses diesem
Server unbekannt ist. Wenn es gesetzt ist, zeigt dieses Flag an,
daß eine
Verbindungslizenz beschafft werden muß, auch wenn dies die Anzahl
der Verbindungen zu dem Server 180 über die vorbestimmte maximal
zulässige
Anzahl von Verbindungen hinaus vergrößert. Nachfolgend werden keine
neuen Verbindungslizenzen gewährt,
bis die Anzahl der im Gebrauch befindlichen Verbindungslizenzen
unter diese vorbestimmte maximale Anzahl abfällt. Auf diese Weise wird eine
Client-Verbindung
nicht aufgrund eines Lizenzänderungsereignisses
in der Mitte der Sitzung beendet.
-
Bei
einer Ausführungsform
unterstützt
das Lizenzverwaltungs-Subsystem 1110 die Operation, daß ein anderes
Subsystem 300 eine Lizenz an den Pool zurückgibt.
Das Subsystem 300 spezifiziert dieselbe eindeutige Kennung,
die beim Anfordern dieser Lizenz benutzt wurde. Die Lizenz wird
danach an den Pool zurückgegeben,
wenn die Lizenz nicht anderenorts im Gebrauch ist (d. h. derselbe
Client, der in eine andere Maschine eingelockt ist).
-
Nunmehr
mit Bezug auf 12 sind die Schritte gezeigt,
die ein Lizenzverwaltungs-Subsystem bei der Initialisierung unternimmt.
Das Lizenzverwaltungs-Subsystem 1110 sendet
eine Ereignisnachricht zu dem Gruppen-Subsystem 1120 (Schritt 1202),
um zu bestimmen, welche etwaige Gruppen von Lizenzen den Server 180 zugewiesen
sind, auf dem das Lizenzverwaltungssubsystem 1110 resident
ist. Das Gruppen-Subsystem 1120 sendet eine Nachricht zu
dem persistenten Speicher 320 (Schritt 1204),
um zu bestimmen, ob etwaige Lizenzen dem Server 180 permanent
zugewiesen wurden. Das Dienstmodul 352 des persistenten
Speichersystems greift auf den persistenten Speicher 230 zu
und sendet eine Nachricht, die dem Gruppen-Subsystem 1120 antwortet,
die Zuweisungsinformationen und Lizenzgruppeninformationen enthält (Schritt 1206). Die
zurückgegebenen
Informationen enthalten die Gesamtzahl verfügbarer Lizenzen und welche
(etwaigen) permanent dem Server 180 zugewiesen sind. Das
Gruppen-Subsystem 1120 sendet ein Antwortereignis mit den
aus dem persistenten Speicher 230 zurückgegebenen Informationen zu
dem Lizenzverwaltungs-Subsystem 1110 (Schritt 1208).
Das Lizenzverwaltungs-Subsystem 1110 speichert Informationen über die
Lizenzen, die dem Server 180 permanent zugewiesen sind
(Schritt 1210) und verwendet mit der Gesamtzahl der Lizenzen
assoziierte Informationen zum Berechnen der Anzahl verfügbarer gepoolter
Lizenzen (Schritt 1212). Bei einer Ausführungsform ist die Anzahl der
verfügbaren
gepoolten Lizenzen gleich der Anzahl der Gesamtlizenzen minus der
Anzahl der permanent einem Server 180 in der Server-Farm 110 zugewiesenen
Lizenzen. Das Lizenzverwaltungs-Subsystem 1110 unternimmt
diese Schritte auch nach dem Empfang eines Ereignisses „Lizenzänderung".
-
Nunmehr
mit Bezug auf 13 sind die Schritte gezeigt,
die das Lizenzverwaltungs-Subsystem 1110 unternimmt, um
auf eine Lizenzanforderung zu antworten. Das Lizenzverwaltungs-Subsystem 1110 empfängt eine
Lizenzanforderung (Schritt 1302) im allgemeinen von dem
spezialisierten Server-Subsystem 1140. Die Anforderung
kann eine Merkmallizenz oder eine Verbindungslizenz anfordern. Das
Lizenzverwaltungs-Subsystem 1110 bestimmt, ob die Lizenz
bereits gewährt
wurde (Schritt 1304), d. h. das Merkmal (wie etwa Lastausgleich)
bereits gestartet wurde oder eine Verbindung für einen Client bereits existiert.
Wenn die Lizenz bereits gewährt
ist, sendet das Lizenzverwaltungs-Subsystem 1110 ein Ereignis „Gewährung" zu dem Lizenzanforderer
(Schritt 1306). Wenn die Lizenz noch nicht zuvor gewährt wurde,
bestimmt das Lizenzverwaltungs-Subsystem 1110, ob eine
lokale Lizenz, d. h. eine Lizenz, die dem Server 180 permanent
zugewiesen wurde, verfügbar
ist. Bei bestimmten Ausführungsformen
führt das
Lizenzverwaltungs-Subsystem 1110 diese Bestimmung aus,
indem es lokalen Speicher überprüft. Wenn
eine lokale Lizenz verfügbar
ist, d. h. der Server 180 mehr permanent zugewiesene Lizenzen
als gerade gewährt
aufweist, sendet das Lizenzverwaltungs-Subsystem 1110 ein
Ereignis „Gewähren" zu dem Lizenzanforderer
(Schritt 1306). Wenn keine lokalen Lizenzen verfügbar sind,
weil entweder alle lokalen Lizenzen gewährt wurden oder weil der Server 180 keine
zugewiesenen Lizenzen aufweist, sendet das Lizenzverwaltungs-Subsystem 1110 ein
Ereignis zu dem Dienstmodul 356 des dynamischen Speichersystems,
um zu bestimmen, ob bereits eine gepoolte Lizenz zugewiesen wurde (Schritt 1310).
Das Dienstmodul 356 des dynamischen Speichersystems prüft den dynamischen
Speicher 240 (Schritt 1312) und gibt ein Ereignis
an das Lizenzverwaltungs-Subsystem 1110 zurück, das
angibt, ob bereits eine gepoolte Lizenz mit dem Merkmal oder mit
dem die Verbindungslizenz ersuchenden Client assoziiert ist (Schritt 1314).
Wenn bereits eine gepoolte Lizenz gewährt wurde, sendet das Lizenzverwaltungs-Subsystem 1110 ein
Ereignis „Gewähren" (Schritt 1306)
zu dem Lizenzanforderer. Wenn nicht, sendet das Lizenzverwaltungs-Subsystem 1110 eine
Nachricht zu dem Dienstmodul 356 des dynamischen Speichersystems,
um zu bestimmen, ob eine gepoolte Lizenz verfügbar ist (Schritt 1316).
Das Dienstmodul 356 des dynamischen Speichersystems schlägt in dem
dynamischen Speicher 240 die Anzahl gerade in Gebrauch
befindlicher gepoolter Lizenzen nach und gibt dieses Ergebnis an
das Lizenzverwaltungs-Subsystem 1110 zurück (Schritt 1318).
Das Lizenzverwaltungs-Subsystem 1110 verwendet diese Informationen
zusammen mit den Informationen, die die Gesamtzahl verfügbarer gepoolter
Lizenzen angibt, die es bei der Initialisierung berechnet hat, um
zu bestimmen, ob eine gepoolte Lizenz verfügbar ist (Schritt 1320).
Wenn nicht, gibt das Lizenzverwaltungs-Subsystem 1110 ein Ereignis „Fehlgeschlagen" an den Lizenzanforderer
zurück
(Schritt 1322).
-
Wenn
dagegen eine gepoolte Lizenz verfügbar ist, sendet das Lizenzverwaltungs-Subsystem 1110 ein Ereignis
zu dem Dienstmodul 356 des dynamischen Speichersystems,
das angibt, daß es
eine der verfügbaren gepoolten
Lizenzen zuweist (Schritt 1324), und das Dienstmodul 356 des
dynamischen Speichersystems erstellt einen entsprechenden Eintrag
in dem dynamischen Speicher 240 (Schritt 1326).
Außerdem
sendet das Lizenzverwaltungs-Subsystem 1110 ein
Ereignis „Gewähren" zu dem Lizenzanforderer
(Schritt 1306).
-
7.6 Das Benutzerverwaltungs-Subsystem
-
Mit
Bezug auf 14A enthält jeder Server 180 in
der Server-Farm 110 ein Benutzerverwaltungs-Subsystem 1400 zum
Verwalten von Benutzern von Clients, Benutzergruppen und Assoziationsgruppen
gemäß den Prinzipien
der Erfindung. Eine Benutzergruppe ist eine Ansammlung von Benutzern,
die zusammen unter einem Namen identifiziert wird, um die Verwaltung
von Benutzern (z. B. Authorisierung einer Benutzergruppe für die Verwendung
eines Anwendungsprogramms und nachfolgend jedes Benutzers, der zu
dieser Benutzergruppe gehört,
statt jede Benutzung individuell authorisieren zu müssen) zu
erleichtern. Eine Assoziationsgruppe, die später ausführlicher beschrieben wird,
assoziiert Benutzerkonten und Benutzergruppen, so daß Server 180 dem
Client 120 eine vollständige
Ansicht von Ressourcen (d. h. Anwendungen und Servern) bereitstellen
können,
die diesen Client 120 in einer Server-Farm, die eine heterogene
Menge von Servern 180 (z. B. Windows-NT-Server und Unix-Server)
aufweist, zur Verfügung
stehen.
-
Assoziationsgruppen
schaffen eine Lösung
für die
potentielle Inkompatibilität
von Subsystemen, die auf Windows NT basieren, mit Unix-Servern in
der Server-Farm 110,
wenn der Client versucht, alle Ressourcen der Farm zu bestimmen,
die diesem Client verfügbar
sind. Man betrachte einen Client 120, der ein Konto auf
einem Windows-NT-Server und ein anderes Konto auf einem Unix-Server besitzt, wobei
der Kontoname für
den Benutzer (z. B. „Benutzer
1) für
beide Konten gleich ist. Wenn der Benutzer des Client 120 versucht, alle
Anwendungen auf dem Windows-NT-Server und auf dem Unix-Server zu
bestimmen, die der Benutzer ausführen
kann, ermöglichen
es vorbekannte Techniken zum Aufzahlen von Anwendungen im allgemeinen dem
Benutzer nicht, beide Mengen von Anwendungen gleichzeitig zu sehen.
Wenn sich der Benutzer in die Windows-NT-Domäne einlogt, sieht der Benutzer
die Anwendungen auf dem Windows-NT-Server. Wenn sich der Benutzer
auf dem Unix-Server einlogged, sieht der Benutzer die Anwendungen
auf dem Unix-Server.
-
Gemäß den Prinzipien
der Erfindung assoziiert eine Assoziationsgruppe beide Kontennamen
mit einem einzigen Benutzer. Wenn sich der Benutzer entweder auf
dem NT- Server oder
auf dem Unix-Server einlogt, kann der Benutzer folglich Anwendungen
sowohl auf dem NT-Server als auch auf dem Unix-Server mit einzigen
Anforderung sehen.
-
Assoziationsgruppen
weisen zwei Typen auf: (1) Konten-Assoziationsgruppen und (2) Kontoautorithätsassoziationsgruppen.
Alle Mitglieder einer Konto-Assoziationsgruppe
werden als derselbe Benutzer betrachtet.
-
Konto-Authoritäts-Assoziationsgruppen
vereinfachen die Aufgabe des Administrators zum Herstellen einer
Kontoassoziation für
jeden Benutzernamen. Wenn ein Benutzer zum Beispiel ein Benutzerkonto
in einer Kontoauthorität „Domäne 1" und ein Benutzerkonto
in einer Kontoauthorität „Domäne 2" besitzt und eine
Konto-Authoritätsassoziationsgruppe
sowohl DOMÄNE
1 als auch DOMÄNE
2 enthält.
Wenn sich der Benutzer auf eine der Domänen einlogged, z. B. DOMAIN1\user1,
verwendet das Benutzerverwaltungs-Subsystem 1400 die Konto-Authoritätsassoziationsgruppe,
um auf eine Konto-Assoziationsgruppe
zu schließen,
die DOMAIN1\user1 und DOMAIN2\user1 enthält. Um Mehrdeutigkeit bei der
Auflösung
der Mitgliederschaft zu vermeiden, kann ein Benutzerkonto ein Mitglied
von mehr als einer Assoziationsgruppe sein, und die Konto-Authorität, auf der
dieses Benutzerkonto residiert, muß nicht zu irgendeiner Konto-Authoritätsassoziationsgruppe
gehören.
-
Als
kurze Übersicht
stellt das Benutzerverwaltungs-Subsystem 1400 eine
Schnittstelle zwischen Subsystemen 300 und Konto-Authoritäten 1440 bereit.
Eine Konto-Authorität ist eine
Datenbank außerhalb
der Server-Farm 110, die gewöhnlich eine Komponente eines
Betriebssystems ist oder durch Dritte bereitgestellt wird. Die Konto-Authorität bestimmt
im allgemeinen, ob Benutzer Erlaubnis haben, sich auf dem Server 180 einzuloggen.
Beispiele für
Arten von Konto-Authoritäten
wären die
von der Microsoft Corp. In Redmond, Washington, produzierten Konto-Authoritäten NTDOMAIN
und ACTIVE DIRECTORY, der von Novell in Provo, Utah produzierte
NOVELL DIRECTORY SERVICE (NDS) und Varianten von Unix.
-
Der
Server 180 vertraut der Konto-Authorität; das heißt, der Server 180 akzeptiert,
daß die
Konto-Authorität die Funktionen
des Identifizierens und Authentifizierens von Benutzern, die sich
auf dem Server 180 einloggen möchten, korrekt ausführt. Wenn
ein Benutzer versucht, sich auf dem Server 180 einzuloggen,
bestimmt die Konto-Authorität
somit, ob dem Benutzer Zugang zu diesem Server 180 gewährt oder
verweigert wird. Zusätzlich
zu der Konto-Authorität 1440 kann
der Server 180 anderen Konto-Authoritäten vertrauen.
-
In 14A enthält
eine Ausführungsform
des Servers 180 in der Server-Farm 110 das Benutzerverwaltungs-Subsystem 1400,
ein spezialisiertes Anwendungs-Subsystem 1416 und
ein Gemeinschaftszugangspunkt-Subsystem 645 in
Kommunikation mit dem Ereignisbus 310. Die in 14A gezeigten Subsysteme dienen zur Beschreibung
des Verhaltens des Benutzerverwaltungs-Subsystems 1400. Der Server 180 kann
andere Arten von Subsystemen 300 enthalten.
-
Das
Benutzerverwaltungs-Subsystem 1400 kommuniziert mit einer
Konto-Authorität 1440.
Die Konto-Authorität 1440 unterhält Benutzerkonten.
Ein Benutzerkonto enthält
die Informationen, die erforderlich sind, damit sich ein Benutzer
auf dem Server 180 einloggen kann (z. B. ein Paßwort).
Das Benutzerkonto spezifiziert auch die Zugangsrechte oder Berechtigungen
(z. B. Lesen, Schreiben, Löschen
usw.), die der Benutzer besitzt, nachdem sich der Benutzer erfolgreich
eingeloggt hat. Die Konto-Authorität 1440 unterhält auch Benutzergruppenkonten,
die Konten sind, die Benutzerkonten logisch in Gruppen legen, um
administrative Aufgaben zu minimieren.
-
Ein
Deskriptor, der den Konto-Authoritätstyp beschreibt, und ein Deskriptor,
der eine Konto-Authoritäts-Instanz
(z. B. „Technik") beschreibt, identifizieren
zusammen eindeutig jede Konto-Authorität 1440, der die Server 180 der
Server-Farm 110 vertrauen. Diese Deskriptoren werden in
Ereignissen oder in Einträgen
des persistenten Speichers 230 präsentiert, in denen die Identität einer
Konto-Authorität 1440 erwartet
wird.
-
Das
allgemeine Format der Identität
der Konto-Authorität kann folgendermaßen dargestellt
werden:
\Konto-Authoritätsyp\Konto-Authoritäts-Instanz'
wobei die linksseitigen
Schrägstriche
(„\") als Abgrenzungen
wirken.
-
Wenn
zum Beispiel der Konto-Authoritätstyp
NT-DOMAIN und die Konto-Authoritäts-Instanz „Technik" ist, ist die eindeutige
Kennung für
die Konto-Authorität „\NTDOMAIN\Technik”
-
Benutzer
und Benutzergruppen werden bei einer Ausführungsform als Objekte dargestellt.
Jedes Objekt besitzt einen besonderen Namen, der dieses Objekt jedem
Server 180 in der Server-Farm 110 eindeutig identifiziert.
Der besondere Name eines Objekts wird beim Zugriff auf das Objekt
in dem persistenten Speicher 230 oder beim Speichern dieses
oder bei der Kommunikation zwischen den Subsystemen 300,
um Operationen an diesem Objekt auszuführen, benutzt.
-
Der
besondere Name für
ein Benutzerkonto oder ein Benutzergruppenkontoobjekt enthält eine
Konto-Kennung und den besonderen Namen für die Konto-Authorität, auf der
dieses Benutzerkonto oder Benutzergruppenkonto residiert. Die Konto-Instanz-Kennung
ist eine konkrete Instanz des Benutzer-Kontos oder Benutzergruppen-Kontos
und hängt
von der Art der Konto-Authorität
ab. Zum Beispiel sind Konto-Instanz-Kennungen für Benutzer-Konto-Objekte in einer NT-Domaine Zeichenkettendarstellungen
einer Binär-Sicherheitskennung
(SID). Das allgemeine Format kann folgendermaßen dargestellt werden: \Objekttyp\Konto-Authoritätstyp\Konto-Authoritäts-Instanz\Konto-Instanz-Kennung,
wobei der Objekttyp die Art des Objekts identifiziert, die entweder
ein Benutzerkonto-Objekt oder ein Benutzergruppenkonto-Objekt ist.
Bei bestimmten Arten von Konto-Authoritäten (z. B. in NT-Domänen) wird
die Konto-Authoritäts-Instanz
mit der Konto-Kennung (z. B. einer SID) codiert. Anhand der Konto-Kennung
kann die Konto-Authoritäts-Instanz
abgeleitet werden.
-
Als
Beispiel für
einen besonderen Namen für
ein Benutzer-Konto-Objekt ist, wenn der besondere Name für den Konto-Authoritätstyp „NTDOMAIN" ist, die Konto-Authoritäts-Instanz „DEVELOP" ist und die Konto-Instanz-Kennung „security_ID" ist, dann der besondere
Name für
das Benutzer-Konto-Objekt „\USER\INTDOMAIN\DEVELOP\security_ID".
-
Als
Beispiel für
einen besonderen Namen eines Benutzergruppen-Konto-Objekts ist,
wenn der besondere Name für
den Konto-Authoritätstyp „NTDOMAIN", die Konto-Authoritäts-Instanz „DEVELOP" und die Konto-Instanz-Kennung „group_security_ID" ist, dann der besondere
Name für
das Benutzergruppen-Konto-Objekt „\GROUP\INTDOMAIN\DEVELOP\group_security_ID".
-
Die
Verwendung besonderer Namen wie oben beschrieben produziert ein
Benennungsformat, das vielfältigen
Betriebssystemplattformen trotz der unähnlichen von diesen Plattformen
verwendeten Benennungsverfahren gerecht wird. Wenn zum Beispiel
ein Server 180 in der Server-Farm 110 auf einer
Windows/NT-Plattform operiert und ein anderer Server 180' in der Server-Farm 110 auf
einer Unix-Plattform operiert, ist das Benennungsschema zum Identifizieren
von Windows/NT-Benutzern nicht mit dem Benennungsschema für Unix-Benutzer
kompatibel. Die Verwendung besonderer Namen schafft eine gemeinsame
Repräsentation
für Benutzer
beider Betriebssysteme.
-
Desweiteren
schaffen besondere Namen eine Benennungskonvention, die von den
Konto-Authoritäten
geführte
Daten eindeutig identifiziert und indirekt referenziert. Besondere
Namen sind somit Verweise auf diese Daten. Diese Verweise, und nicht
die eigentlichen von den Konto-Authoritäten 1140 geführten Daten, werden
in dem persistenten Speicher 230 gespeichert und/oder unter
den Subsystemen 300 weitergeleitet. Im allgemeinen modifizieren
die Server 180 und Subsysteme 300 keine solchen
auf den Konto-Authoritäten
gespeicherten Daten und diese Server 180 und Subsysteme 300 werden
auch nicht über
etwaige Modifikationen an den Daten durch externe Hilfsprogramme
benachrichtigt. Die eigentlichen Konto-Authoritäts-Daten werden dementsprechend
nicht in den persistenten Speicher 230 importiert, um das
Produzieren redundanter Kopien der Daten, die ohne Benachrichtigung
veralten können,
zu vermeiden.
-
Wieder
mit Bezug auf 14A enthält das Benutzerverwaltungs-Subsystem 1400 bei
einer Ausführungsform
eines oder mehrere Konto-Authoritäts-Zugangstreiber-Subsysteme 1404, 1404' (allgemein 1404) und
ein Konto-Authoritäts-Verwaltungs-Subsystem 1408.
Für jede
Art von Konto-Authorität 1440,
der der Server 180 vertraut, gibt ein Konto-Authoritäts-Zugangstreiber-Subsystem 1404.
Jedes Konto-Authoritäts-Zugangstreiber-Subsystem 1404 setzt
Daten (z. B. ein Array von SIDs) die aus der jeweiligen Konto-Authorität empfangen
werden (im folgenden als externe Daten bezeichnet) in die Datenrepräsentation
(z. B. besondere Namen) um, die die Subsysteme 300 verstehen
(im folgenden als interne Daten bezeichnet).
-
Externe
Daten sind betriebssystemplattformspezifisch (d. h. hängen von
der Art der Konto-Authorität ab).
Externe Daten werden im allgemeinen von den Subsystemen 300 nicht
verstanden und werden nicht über den
Ereignisbus 310 geleitet. Beispiele für externe Daten sind SIDs und
ACLs (Access Control Lists). Interne Daten sind Daten, die als Ereignisparameter
zu und von den Subsystemen 300 über den Ereignisbus 310 geleitet
werden.
-
Das
Konto-Authoritäts-Verwaltungs-Subsystem 1408 stellt
einen zentralen Verwaltungspunkt für alle Konto-Authoritäts-Zugangstreiber-Subsysteme 1404 bereit.
Bei der Initialisierung des Servers 180 registrieren sich
alle Konto-Authoritäts-Zugangstreiber-Subsysteme 1404 bei
dem Konto-Authoritäts-Verwaltungs-Subsystem 1408.
Nach der Registration erzeugt das Konto-Authoritäts-Verwaltungs-Subsystem 1408 eine
Registrationsliste. Das Konto-Authoritäts-Verwaltungs-Subsystem 1408 stellt
die Registrationsliste für
alle unterstützten Konto-Authoritäten den
Subsystemen 300 des Servers 180 zur Verfügung. Das
Konto-Authoritäts-Verwaltungs-Subsystem 1408 geht
mit Ereignissen um, um aufzulösen,
welche Konto-Authoritäts-Zugangstreiber-Subsysteme 1404 eine
bestimmte Konto-Authorität
unterstützen.
Außerdem
führt das
Konto-Authoritäts-Verwaltungs-Subsystem 1408 Informationen über die
Vertrauensbeziehungen, die jeder Server 180 in der Farm 110 mit
Konto-Authoritäten
aufweisen. Das Konto-Authoritäts-Verwaltungs-Subsystem 1408 stellt
eine Schnittstelle zur Steuerung und Abfrage der Assoziationsgruppen
in der Farm bereit.
-
Andere
Subsysteme 300 kommunizieren mit den Konto-Authoritäts-Zugangstreiber-Subsystemen 1404,
indem sie zuerst das Konto-Authoritäts-Verwaltungs-Subsystem 1408 aufrufen,
um die Subsystem-ID eines spezifischen Konto-Authoritäts-Zugangstreiber-Subsystem 1404 abzurufen.
Nach dem Erhalten dieser Subsystem-ID erfolgt die nachfolgende Kommunikation
direkt mit diesem spezifischen Konto-Authoritäts-Zugangstreiber-Subsystem 1404.
Die nachfolgende Kommunikation vermeidet folglich den „Doppelsprung", der auftreten würde, wenn
das Konto-Authoritäts-Verwaltungs-Subsystem 1408 in
der Mitte aller nachfolgenden Kommunikation mit dem Konto-Authoritäts-Zugangstreiber-Subsystem 1404 geblieben
wäre.
-
Um
eine Liste von Konto-Authoritäts-Instanzen,
denen vertraut wird, herzustellen, fordert das Konto-Authoritäts-Verwaltungs-Subsystem 1408 periodisch
eine Liste von Konto-Authoritäts-Instanzen,
denen vertraut wird, von jedem Konto-Authoritäts-Zugangstreiber-Subsystem 1404,
das sich bei dem Konto-Authoritäts-Verwaltungs-Subsystem 1408 registriert
hat, an und erhält
diese von ihnen. Das Konto-Authoritäts-Verwaltungs-Subsystem 1408 liefert
die erhaltenen Informationen zur Ablegung in einer Server-Vertrauenstabelle (siehe 14B) an den persistenten Speicher 230 ab.
Die Konto-Authoritätsverwaltung 1408 verwendet
diese Informationen über
die Vertrauensbeziehungen zum Routen von Ereignissen zu einem Server 180 mit
einem Konto-Authoritäts-Zugangstreiber-Subsystem 1404,
das der Konto-Authorität
vertraut, auf der die Operation ausgeführt werden muß.
-
Mit
Bezug auf 14B ist nun der Prozeß des Authorisierens
eines Benutzers des Clients 120 beispielhaft dargestellt.
Als kurze Übersicht
kommuniziert der Client 120 (Pfeil 1) mit Terminal-Server-Logon-Software 1414 auf
dem Server 180, um eine Verbindung mit dem Server 180 herzustellen.
Aus durch den Client 120 bereitgestellten Login-Informationen,
nämlich
den Berechtigungsnachweisen des Benutzers (d. h. dem Benutzernamen
und dem Paßwort)
und der Identität der
Konto-Authorität
(d. h. dem Konto-Authoritätstyp-Deskriptor und dem
Instanz-Deskriptor) authorisiert die Terminal-Server-Logon-Software 1414 die
Client-Verbindung.
-
Während des
Logon-Prozesses sendet die Terminal-Server-Logon-Software 1414 (Pfeil
2) ein Handle zu einem Sicherheits-Token (im folgenden Login-Informationen)
des Benutzers, der sich auf das Gemeinschaftszugangspunkt-Subsystem 645 einloggen
möchte.
Das Gemeinschaftszugangspunkt-Subsystem 645 leitet die
durch das Handle referenzierten Daten auf den Ereignisbus 310 weiter,
damit das Benutzerverwaltungs-Subsystem 1400 sie in eine
Liste besonderer Namen von Konten umsetzen kann, die den Sicherheitszugang
des Benutzers repräsentieren.
Diese Liste besonderer Namen wird dann von dem spezialisierten Anwendungs-Subsystem 1416 verwendet,
um zu bestimmen, ob es dem Benutzer erlaubt ist, auf eine angeforderte
Anwendung zuzugreifen.
-
Insbesondere
stellt Software 1418 (als „WSXICA" bezeichnet) eine Schnittstelle zwischen
der Terminal-Server-Login-Software 1414 und
dem Gemeinschaftszugangspunkt-Subsystem 654 bereit. Die
WSXICA 1418 enthält
Gemeinschaftszugangspunkt-Client-Software 1422,
die einen RPC-Aufruf an das Gemeinschaftszugangspunkt-Subsystem 645 ausgibt.
Das Gemeinschaftszugangspunkt-Subsystem 645 sendet die Login-Informations-Durchgänge (Pfeil
3) zu dem spezialisierten Anwendungs-Subsystem 1416 des
Servers 180. Das spezialisierte Anwendungs-Subsystem 1416 leitet
(Pfeil 4) die empfangenen Login-Informationen zu dem Konto-Authoritäts-Verwaltungs-Subsystem 1408 des
Benutzerverwaltungs-Subsystem 1400 weiter.
-
Das
Konto-Authoritäts-Verwaltungs-Subsystem 1408 sendet
(Pfeil 5) die Login-Informationen zu dem Konto-Authoritäts-Zugangstreiber-Subsystem 1404.
Das Konto- Authoritäts-Zugangstreiber-Subsystem 1404 greift
mit den Benutzer-Berechtigungsnachweisen auf die Konto-Authorität 1440 zu
(Pfeil 6). Aus den Benutzer-Berechtigungsnachweisen
bestimmt die Konto-Authorität 1440 (Pfeil
7), ob dem Benutzer des Clients 120 Authorisierung zu gewähren ist.
Das Konto-Authoritäts-Zugangstreiber-Subsystem 1404 gibt
das Authorisierungsergebnis an das spezialisierte Anwendungs-Subsystem 1416 zurück (Pfeil
8), das das Ergebnis an das Gemeinschaftszugangspunkt-Subsystem 645 zurückgibt (Pfeil),
das das Ergebnis durch Terminal-Server-Logon-Software 1414, 1418, 1422 an
den Client 120 zurückgibt
(Pfeil 10).
-
14B zeigt einen weiteren zum Authorisieren eines
Clients als Reaktion auf eine Client-Anforderung verwendeten beispielhaften
Prozeß.
Wie gezeigt, enthält
eine Ausführungsform
der Server-Farm 110 einen NT-Domänenserver 180 und
einen Unix-Server 180'.
Der Unix-Server 180' enthält ein ICA-Browser-Subsystem 720,
ein Programmnachbarschafts-Subsystem 760 und ein Benutzerverwaltungs-Subsystem 1400'. Das Benutzerverwaltungs-Subsystem 1400' enthält ein Konto-Authoritäts-Verwaltungs-Subsystem 1408' und ein Unix-Konto-Authoritäts-Zugangstreiber-Subsystem 1404', das mit einer
Konto-Authorität 1440 des Unix-Typs
kommuniziert.
-
Der
NT-Domänenserver 180 enthält ein Benutzerverwaltungs-Subsystem 1400 mit
zwei Konto-Authoritäts-Zugangstreiber-Subsystemen 1404 und 1404''. Eines der Konto-Authoritäts-Zugangstreiber-Subsysteme 1404' ist ein NT-Domänentreiber,
der mit einer Konto-Authorität 790 des
NT-Domänentyps
kommuniziert. Das andere Konto-Authoritäts-Zugangstreiber-Subsystem 1404'' ist ein Active-Directory-Treiber,
der mit einer Konto-Authorität 795 des
Active-Directory-Typs kommuniziert.
-
Das
Beziehungs-Subsystem 1130 führt farmweite Vertrauensinformationen
zwischen Servern und Konto-Authoritäten. Das
Konto-Authoritäts-Verwaltungs-Subsystem 1408 bestimmt
die Identität
der Konto-Authorität, der der
Server 180 vertraut, und gibt diese Identität an das
spezialisierte Anwendungssubsystem 1416 zurück (Pfeil
4). Das Dienstmodul 352 des persistenten Speichersystems
kommuniziert mit einer Tabelle 750 von Zeigern (im folgenden „Server-Vertrauenstabelle"), die in dem persistenten
Speicher 230 residiert. Die Server-Vertrauenstabelle 750 ist
global zugänglich,
das heißt,
jedes Server 180 in der Server-Farm 110 kann die Einträge der Server-Vertrauenstabelle 750 lesen.
Die Einträge
der Tabelle 750 assoziieren die Server 180 in der
Server-Farm 110 mit den Konto-Authoritäten, denen diese Server 180 vertrauen.
Jeder Eintrag enthält
drei Felder: einen Servernamen, den Deskriptor des Typs der Konto-Authorität, der vertraut
wird, und einen Deskriptor der Instanz der Konto-Authorität. Jeder
Server 180 in der Server-Farm 110 kann deshalb
Kenntnis aller Vertrauensbeziehungen zwischen jedem anderen Server 180 in
der Server-Farm 110 und den bekannten Konto-Authoritäten erhalten.
-
Um
die Identität
der Konto-Authorität,
der vertraut wird, zu bestimmen, kommuniziert das Konto-Authoritäts-Verwaltungs-Subsystem 1408 durch
das Dienstmodul 352 des persistenten Speichersystems mit
dem persistenten Speicher 230, um eine Liste der Server
zu erhalten, die der spezifizierten Art von Konto-Authorität vertrauen.
Der persistente Speicher 230 speichert eine Liste von Konto-Authoritäten, denen
vertraut wird, für jeden
Server 180 in der Server-Farm 110.
-
Das
Konto-Authoritäts-Zugangstreiber-Subsystem 1404 sendet
dann (Pfeil 6) den Konto-Authoritätstyp zu dem Dienstmodul 352 des
persistenten Speichersystems. Das Dienstmodul 352 des persistenten
Speichersystems greift mit dem Konto-Authoritätstyp auf den persistenten
Speicher 230 zu (Pfeil 7), um einen Zeiger auf die Konto-Authorität 1440 zu
erhalten (Pfeil 8). Das Dienstmodul 352 des persistenten
Speichersystems gibt den Konto-Authoritätszeiger an das Konto-Authoritäts-Zugangstreiber-Subsystem 1404 zurück.
-
Man
betrachte, daß der
Client 120 einen virtuellen Kanal startet, der den Client
mit dem Unix-Server 180' in
der Server-Farm 110 verbindet. Die Verbindungsanforderung
enthält
die Berechtigungsnachweise des Benutzers (d. h. den Benutzernamen
und das Paßwort)
und identifiziert die Konto-Authorität (d. h. den Konto-Authoritätstyp-Deskriptor
und Instanz-Deskriptor). Zur Veranschaulichung entspricht hierbei
die Art von Konto-Authorität der NT-Domäne. Die
Verbindungsinformationen werden zu dem Programmnachbarschafts-Subsystem 760 des
Unix-Servers 180' geleitet.
-
Das
spezialisierte Anwendungs-Subsystem 1416 leitet die empfangenen
Informationen zu dem Konto-Authoritäts-Verwaltungs-Subsystem 1408' des Unix-Servers 180' weiter. Das
Konto-Authoritäts-Verwaltungs-Subsystem 1408 bestimmt,
daß der
Unix-Server 180' nicht
mit der Anforderung umgehen kann, weil die Anforderung nicht der
Typ der spezifizierten Konto-Authorität (hier NT-Domäne)
ist. Folglich kommuniziert das Konto-Authoritäts-Verwaltungs-Subsystem 1408 (Pfeil
6) mit dem persistenten Speicher 230, um eine Liste der Server
zu erhalten (Pfeil 7), die der spezifizierten Art von Konto-Authorität vertrauen.
Man beachte, daß der persistente
Speicher 230 für
jeden Server 180 in der Server-Farm 110 eine Liste
von Konto-Authoritäten,
denen vertraut wird, speichert. Aus der Liste möglicher Server trifft das Konto-Authoritäts-Verwaltungs-Subsystem 1408 eine
Routing-Entscheidung. Die Routing-Entscheidung basiert bei einer Ausführungsform
auf der Latenz (d. h. Ansprechzeit) dieser Server.
-
Das
Konto-Authoritäts-Verwaltungs-Subsystem 1408 sendet
dann (Pfeil 8) die Anforderung zu dem NT-Domänen-Konto-Authoritäts-Zugangstreiber-Subsystem 1404'. Das NT-Domänen-Konto-Authoritäts-Zugangstreiber-Subsystem 1404' kommuniziert
dann mit der NT-Domäne-Konto-Authorität 750,
um zu bestimmen, daß der
Benutzer des Clients 120 dafür authorisiert ist, die in
der ursprünglichen
Anforderung an den Unix-Server 180' identifizierte Aktion auszuführen. Die
Ergebnisse kehren zu dem Programmnachbarschafts-Subsystem 760 des
Unix-Servers 180' zurück, der
die Aktion ausführen
und die Ergebnisse an den Client zurückgeben kann.
-
Die
Benutzerauthorisierung erfolgt in der Regel auf eine von zwei Weisen.
Eine Möglichkeit
ist durch das ICA-Browser-Subsystem 720. Eine zweite Möglichkeit
ist durch das Programmnachbarschafts-Subsystem 760.
-
7.7 Das ICA-Browser-Subsystem
-
Browsen
ermöglicht
dem Client 120, Farmen, Server und Anwendungen in der Server-Farm 110 zu betrachten
und auf verfügbare
Informationen, wie etwa abgetrennte Sitzungen, in der gesamten Farm 110 zuzugreifen.
Jeder Server 180 enthält
ein ICA-Browsing-Subsystem 720, um dem Client 120 Browsing-Fähigkeit zu
geben. Nachdem der Client 120 eine Verbindung mit dem ICA-Browser-Subsystem 720 irgendeines
der Server 180 hergestellt hat, unterstützt dieses Browser-Subsystem
vielfältige
Client-Anforderungen. Solche Client-Anforderungen wären zum
Beispiel: (1) Aufzählung
von Namen von Servern in der Farm, (2) Aufzählen von Namen von Anwendungen,
die in der Farm publiziert sind, (3) Auflösen eines Servernamens und/oder
Anwendungsnamen auf eine Serveradresse, die dem Client 120 nützlich ist.
Das ICA-Browser-Subsystem 720 unterstützt auch Anforderungen, die
von Clients gestellt werden, die die im folgenden ausführlicher
beschriebene „Programmnachbarschafts-Anwendung" ausführen.
-
Programmnachbarschaft
ist im allgemeinen eine Anwendung, die den Benutzer des Clients 120 auf Anforderung
eine Ansicht der Anwendungen in der Server-Farm 110 gibt, für die der
Benutzer authorisiert ist. Das ICA-Browser-Subsystem 720 leitet
alle obenerwähnten
Client-Anforderungen zu dem entsprechenden Subsystem in dem Server 180 weiter.
-
7.8 Das Programmnachbarschafts-Subsystem
-
Jeder
Server 180 in der Server-Farm 110, der ein Programmnachbarschafts-Subsystem 760 aufweist, kann
dem Benutzer des Clients 120 eine Ansicht von Anwendungen
in der Server-Farm 110 bereitstellen. Das Programmnachbarschafts-Subsystem 760 begrenzt
die Ansicht auf diejenigen Anwendungen, für die der Benutzer authorisiert
ist. In der Regel stellt dieser Programmnachbarschaftsdienst die
Anwendungen dem Benutzer als eine Liste oder Gruppe von Symbolen
dar.
-
Die
durch das Programmnachbarschafts-Subsystem 760 bereitgestellte
Funktionalität
ist zwei Arten von Clients verfügbar:
(1) programmnachbarschaftsbefähigten
Clients, die direkt von einem Client-Desktop aus auf die Funktionalität zugreifen
können,
und (2) nicht-programmnachbarschaftsbefähigte Clients (z. B. Legacy-Clients),
die auf die Funktionalität
zugreifen können,
indem sie ein programmnachbarschaftsbefähigtes Desktop auf dem Server
ausführen.
-
Die
Kommunikation zwischen einem programmnachbarschaftsbefähigten Client
und dem Programmnachbarschafts-Subsystem 760 erfolgt über einen
eigenen virtuellen Kanal, der über
einem virtuellen ICA-Kanal hergestellt wird. Bei einer Ausführungsform
besitzt der programmnachbarschaftsbefähigte Client keine Verbindung
mit dem Server mit einem Programmnachbarschafts-Subsystem 760.
Bei dieser Ausführungsform sendet
der Client 120 eine Anforderung zu dem ICA-Browser-Subsystem 720,
um eine ICA-Verbindung
mit Server 180 herzustellen, um dem Client 120 verfügbare Anwendungen
zu bestimmen. Der Client führt
dann einen clientseitigen Dialog aus, der die Berechtigungsnachweise
des Benutzers erfordert. Die Berechtigungsnachweise werden durch
das ICA-Browser-Subsystem 720 empfangen
und zu dem Programmnachbarschafts-Subsystem 760 gesendet.
Das Programmnachbarschafts-Subsystem 760 sendet die Berechtigungsnachweise
wie oben beschrieben zur Authentifizierung zum dem Benuzterverwaltungs-Subsystem 1400.
Das Benutzerverwaltungs-Subsystem 1400 gibt eine Menge
besonderer Namen zurück,
die die Liste von Konten repräsentiert,
zu der der Benutzer gehört.
Nach Authentifizierung stellt das Programmnachbarschafts-Subsystem 760 den
virtuellen Programmnachbarschaftskanal her. Dieser Kanal bleibt
offen, bis die Anwendungsfilterung abgeschlossen ist.
-
Das
Programmnachbarschafts-Subsystem 760 fordert dann die Programmnachbarschaftsinformationen
von dem mit diesen Konten assoziierten Gemeinschaftsanwendungs-Subsystem (Abschnitt
7.10) an. Das Gemeinschaftsanwendungs-Subsystem erhält die Programmnachbarschaftsinformationen
aus dem persistenten Speicher 230. Nach dem Empfang der
Programmnachbarschaftsinformationen formatiert das Programmnachbarschafts-Subsystem 760 die
Programmnachbarschaftsinformationen und gibt sie über den
virtuellen Programmnachbarschaftskanal an den Client zurück. Dann
wird die partielle ICA-Verbindung geschlossen.
-
Als
ein weiteres Beispiel, bei dem der programmnachbarschaftsbefähigte Client
eine partielle ICA-Verbindung mit einem Server herstellt, betrachte
man den Benutzer des Clients 120, der eine Server-Farm
auswählt.
Die Auswahl der Server-Farm sendet eine Anforderung von dem Client 120 zu
dem ICA-Browser-Subsystem 720,
um eine ICA-Verbindung mit einem der Server 180 in der
ausgewählten
Server-Farm herzustellen. Das ICA-Browser-Subsystem 720 sendet
die Anforderung zu dem Programmnachbarschafts-Subsystem 760, das
einen Server in der Server-Farm auswählt. Das Programmnachbarschafts-Subsystem 760 sendet
dann den Servernamen zu dem Gemeinschaftsserver-Subsystem (Abschnitt
7.10) zur Servernamenauflösung.
Das Gemeinschaftsserver-Subsystem löst den Servernamen wie nachfolgend
beschrieben auf und gibt eine Adresse an das Programmnachbarschafts-Subsystem 760 zurück. Die
Adresse wird mittels des ICA-Browser-Subsystems 720 an
den Client 120 zurückgegeben.
Der Client 120 kann sich dann nachfolgend mit dem Server 180 verbinden,
der der Adresse entspricht.
-
Bei
einer anderen Ausführungsform
besitzt der programmnachbarschaftsbefähigte Client eine ICA-Verbindung, auf der
der virtuelle Programmnachbarschaftskanal hergestellt wird und solange
offenbleibt, wie die ICA-Verbindung persistiert. Über diesen
virtuellen Programmnachbarschaftskanal schiebt das Programmnachbarschafts-Subsystem 760 Programmnachbarschafts-Informationsaktualisierungen
auf den Client 120. Um Aktualisierungen zu erhalten, subskribiert
das Programmnachbarschafts-Subsystem 760 Ereignisse aus
dem Gemeinschaftsanwendungs-Subsystem, um es dem Programmnachbarschafts-Subsystem 760 zu erlauben, Änderungen
an publizierten Anwendungen zu detektieren.
-
7.9 Anwendungs- und Server-Subsysteme
-
Bei
bestimmten Ausführungsformen
besitzt jeder Server 180 in der Server-Farm 110 eines
oder mehrere Gemeinschaftsanwendungs-Subsysteme, die Dienste für eines
oder mehrere spezialisierte Anwendungssubsteme 1416 bereitstellen.
Diese Server 180 können
auch ein oder mehrere Gemeinschaftsserver-Subsysteme zur Bereitstellung
von Diensten für
eines oder mehrere spezialisierte Serversubsysteme 1140 aufweisen. Bei anderen
Ausführungsformen
werden keine Gemeinschafts-Subsysteme
bereitgestellt, und jedes spezialisierte Anwendungs- und Server-Subystem
implementiert alle erforderliche Funktionalität.
-
7.9.1 Anwendungs-Subsysteme
-
7.9.1.1
Gemeinschaftsanwendungs-Subsysteme Jeder Server 180 in
der Server-Farm 110 kann ein oder mehrere Gemeinschaftsanwendungs-Subsysteme
enthalten, die gemeinsame Funktionalität für eines oder mehrere spezialisierte
Anwendungssubsysteme 1416 (z. B. Metaframe für Windows,
hergestellt von Citrix Systems, Inc. in Ft. Lauderdale, Florida)
auf dem Server 180 bereitstellen. Bei spezifischen Ausführungsformen
kann ein Server 180 nur ein Gemeinschaftsanwendungs-Subsystem aufweisen,
das eine gemeinsame Menge von Funktionen für alle spezialisierten Anwendungs-Subsysteme 1416 bereitstellt.
-
Ein
Gemeinschaftsanwendungs-Subsystem 300 kann Anwendungen
auf die Server-Farm 110 „publizieren", wodurch jede Anwendung
für Aufzählung und
Start durch Clients 120 verfügbar wird. Im allgemeinen wird
eine Anwendung auf jedem Server 180 installiert, wenn Verfügbarkeit
dieser Anwendung gewünscht
wird. Bei einer Ausführungsform
führt ein
Administrator, um die Anwendung zu publizieren, das Administrationswerkzeug 140 aus,
wobei Informationen wie etwa die die Anwendung hostenden Server 180,
der Name der ausführbaren
Datei auf jedem Server, die erforderlichen Fähigkeiten eines Clients für die Ausführung der
Anwendung (z. B. Audio, Video, Verschlüsselung usw.) und eine Liste
von Benutzern, die die Anwendung benutzen können, spezifiziert werden.
Diese spezifizierten Informationen werden zu anwendungsspezifischen
Informationen und gemeinsamen Informationen kategoriesiert. Beispiele
für anwendungsspezifische
Informationen sind: der Pfadname für den Zugriff auf die Anwendung
und der Name der ausführbaren
Datei zum Ausführen der
Anwendung. Gemeinsame Informationen (d. h. gemeinsame Anwendungsdaten)
wären zum
Beispiel der benutzerfreundliche Name der Anwendung (z. B. „Microsoft
WORD 2000"), eine
eindeutige Identifikation der Anwendung und die Benutzer der Anwendung.
-
Die
anwendungsspezifischen Informationen und gemeinsamen Informationen
werden zur Steuerung der Anwendung auf jedem die Anwendung hostenden
Server zu jedem entsprechenden spezialisierten Anwendungs-Subsystem 1416 gesendet.
Das spezialisierte Anwendungs-Subsystem 1416 kann
die anwendungsspezifischen Informationen und die gemeinsamen Informationen
in den persistenten Speicher 230 schreiben und eine Kopie
der gemeinsamen Informationen zu dem Gemeinschaftsanwendungs-Subsystem 300 weiterleiten.
Bei einer Ausführungsform
speichert das Gemeinschaftsanwendungs-Subsystem 300 die gemeinsamen
Informationen in den persistenten Speicher 230. Bei einer
anderen Ausführungsform
speichert das Gemeinschaftsanwendungs-Subsystem 300 die gemeinsamen
Informationen nicht. Bei dieser Ausführungsform werden die gemeinsamen
Informationen durch ein spezialisiertes Anwendungs-Subsystem auf Bedarfsbasis
dem Gemeinschaftsanwendungs-Subsystem
zugeführt.
Die Unterscheidung zwischen gemeinsamen Informationen und anwendungspezifischen
Informationen ermöglicht
es, neue spezialisierte Anwendungs-Subsysteme 1416 ungeachtet
des Anwendungs-Subsystemtyps
(d. h. Windows, Video, Unix, Java usw.) ohne weiteres zu dem Server 180 hinzuzufügen.
-
Gegebenenfalls
kann ein Gemeinschaftsanwendungs-Subsystem 300 auch
eine Vorrichtung zur Verwaltung der publizierten Anwendungen in
der Server-Farm 110 bereitstellen. Durch ein Gemeinschaftsanwendungs-Subsystem 300 kann
der Administrator die Anwendungen der Server-Farm 110 unter
Verwendung des Administrationswerkzeugs 140 verwalten,
indem Anwendungsgruppen konfiguriert werden und eine Anwendungsbaumhierarchie
dieser Anwendungsgruppen produziert wird. Jede Anwendungsgruppe
wird als ein Ordner in dem Anwendungsbaum repräsentiert. Jeder Anwendungsordner
in dem Anwendungsbaum kann einen oder mehrere andere Anwendungsordner
und spezifische Instanzen von Servern enthalten. Das Gemeinschaftsanwendungs-Subsystem 300 stellt
Funktionen zum Erzeugen, Verschieben, Umbenennen, Löschen und
Aufzählen
von Anwendungsordnern bereit.
-
7.9.1.2 Das spezialisierte Anwendungs-Subsystem
-
Das
spezialisierte Anwendungs-Subsystem 1416 implementiert
die Funktionalität
publizierter Anwendungen. Wie oben beschrieben, definiert ein Administrator
publizierte Anwendungen, wobei die Server der Server-Farm, die jede
publizierte Anwendung hasten, und die Benutzer, die jede Anwendung
ausführen
können,
spezifiziert werden. Eine publizierte Anwendung umfaßt eine
ausführbare
Datei der Anwendung, eine Menge von Servern und eine Menge von Benutzern.
-
Das
spezialisierte Anwendungs-Subsystem 1416 stellt eine SAL
bereit, die anderen Subsystemen und dem Administrationswerkzeug 140 zum
Beispiel folgendes erlaubt: (1) Konfigurieren publizierter Anwendungen,
(2) Ausführen
der Namenauflösung,
(3) Verarbeitung von Benutzer-Logons, (4) Zurücksetzen laufender Anwendungen
zum Beenden jeglicher die Anwendung ausführender Sitzungen, (5) Neuzuweisen
einer aktiven Sitzung zu einem anderen Server, (6) Identifizieren
der Ziel-Clients
für ein
Multicast-Multimedia-Strom oder (7) andere Funktionen, die in Verbindung
mit einer bestimmten Anwendung nützlich
oder notwendig sind. Die SAL-Aufrufe zum Konfigurieren publizierter
Anwendungen umfassen Aufrufe zum Erzeugen, Lesen, Schreiben und
Löschen
publizierter Anwendungen. Ein anderer SAL- Aufruf zählt publizierte Anwendungen
auf. Andere SAL-Aufrufe
können
Benutzer hinzufügen,
entfernen und aufzählen;
weitere können
Server hinzufügen,
entfernen und aufzählen.
-
7.9.2 Server-Subsysteme
-
7.9.2.1 Gemeinschaftsserver-Subsystem
-
Jeder
Server 180 in der Server-Farm 110 kann eines oder
mehrere Gemeinschaftsserver-Subsysteme enthalten, die gemeinsame
Funktionalität
für eines
oder mehrere spezialisierte Server-Subsysteme 1140 bereitstellen.
Jedes spezialisierte Server-Subsystem 1140 stellt einen
spezifischen Typ von Serverfunktionalität für den Client 120 bereit.
Bei spezifischen Ausführungsformen
kann ein Server 180 nur ein Gemeinschaftserver-Subsystem aufweisen,
das eine gemeinsame Menge von Funktionen für alle spezialisierten Server-Subsysteme
bereitstellt.
-
Das
Gemeinschaftsserver-Subsystem kann gemeinsame Serverfunktionalität bereitstellen,
die von dem Typ bzw. den Typen spezialisierter Server-Subsysteme,
die auf dem Server 180 mit dem Gemeinschaftsserver-Subsytem
residieren, unabhängig
ist. Diese gemeinsame Funktionalität kann zum Beispiel folgendes umfassen:
(1) Registrieren spezialisierter Server-Subsysteme, (2) Verwalten
von Servergruppen, (3) Unterstützen
der Servernamenauflösung
und (4) Unterstützen
der Aufzählung
abgetrennter Sitzungen. Obwohl das Gemeinschaftsserver-Subsystem
möglicherweise
keine Servernamen oder abgetrennte Sitzungen auflöst oder aufzählt, kann
das Gemeinschaftsserver-Subsystem als anfänglicher Zugangspunkt für solche
Anforderungen wirken. Gegebenenfalls leitet das Gemeinschaftsserver-Subsystem solche
Anforderungen zu dem entsprechenden spezialisierten Server-Subsytem 1140 weiter.
-
Ein
Gemeinschaftsserver-Subsystem empfängt Registrationsinformationen
aus jedem auf dem Server 180 installierten spezialisierten
Server-Subsystem 1140. Die Registrationsinformationen umfassen
den Server-Typ und die Subsystem-ID dieses spezialisierten Server-Subsystems 1140.
Zusätzlich
geben die Registrationsinformationen die Fähigkeiten des spezialisierten
Server-Subsystems 1140 an. Zu registrierten Fähigkeiten
gehört
das Auflösen
von Servernamen und abgetrennte Sitzungen, das Aufzählen von
Servern und das Aufzählen
abgetrennter Sitzungen. Das Gemeinschaftsserver-Subsystem speichert
diese Registrationsinformationen in den persistenten Speicher 230 und
bezieht sich bei Empfang einer Anforderung, einen Servernamen aufzulösen oder
abgetrennte Sitzungen aufzuzählen,
auf die Informationen. Aus den gespeicherten Registrationsinformationen
bestimmt das Gemeinschaftsserver-Subsystem, wohin (d. h. zu welchem
spezialisierten Server-Subsystem 1140) die empfangene Anforderung
weiterzuleiten ist.
-
Bei
einer Ausführungsform
stellt das Gemeinschaftsserver-Subsystem eine Vorrichtung zur Verwaltung
der Server 180 in der Server-Farm 110 bereit.
Durch das Gemeinschaftsserver-Subsystem kann der Administrator die
Server 180 der Server-Farm 110 unter Verwendung
des Administrationswerkzeugs 140 durch Konfigurieren von
Servergruppen und Produzieren einer Serverbaumhierarchie dieser
Servergruppen verwalten. Jede Servergruppe wird als ein Ordner in
dem Baum repräsentiert.
Jeder Server-Ordner in dem Baum kann einen oder mehrere weitere
Server-Ordner und spezifische Instanzen von Servern enthalten. Das
Gemeinschaftsserver-Subsystem stellt Funktionen zum Erzeugen, Verschieben,
Umbenennen, Löschen
und Aufzählen
von Server-Ordnern bereit.
-
7.9.2.2 Das spezialisierte Server-Subsystem
-
Jeder
Server 180 in der Server-Farm 110 enthält mindestens
ein spezialisiertes Server-Subsystem 1140. Beispiele für spezialisierte
Server-Subsysteme 1140 wären ein Windows-NT-Server-Subsystem,
ein Unix-Server-Subsystem
und ein Windows-2000-Server-Subsystem. Jedes spezialisierte Server-Subsystem 1140 stellt
spezifische Server-Funktionalität
bereit. Zum Beispiel kann solche Funktionalität umfassen, allgemeine Serverinformationen
zu führen,
Verbindungskonfiguration, wie etwa Verbindungsgrenzen und -zeitgrenzen,
zu verwalten, dynamische Informationen (z. B. für lokale Sitzungen und Prozesse)
zu führen
und Informationen über
abgetrennte Sitzungen zu führen.
-
Das
spezialisierte Server-Subsystem 1140 stellt die folgenden
Anwendungsprogrammschnittstellen (API) bereit, um die obenbeschriebene
Server-Subsystem-Funktionalität zu erzielen:
- (1) API zum Abrufen von Informationen über das
spezialisierte Server-Subsystem 1140, wie zum Beispiel Erhalten
der Version des Subsystems und Umsetzen zwischen der eindeutigen
Kennung, dem besonderen Namen und der Host-Kennung des Subsystems;
- (2) API zum Ausführen
der Servernamenauflösung
und zum Aufzählen
abegetrennter Sitzungen;
- (3) API zum Verwalten des Servers, wie zum Beispiel Erhalten
der Fähigkeit
des Servers, Herunterfahren des Servers, Neubooten des Servers,
Ermöglichen
des Logons auf dem Server; und
- (4) API zur Verwaltung von Prozessen wie zum Beispiel Aufzählung von
Prozessen, Erhalten von Prozeßinformationen
und Beenden von Prozessen.
-
Diese
API können
als eine SAL-Schnittstelle wie obenbeschrieben bereitgestellt werden.
-
Bei
einer Ausführungsform
stellt das spezialisierte Server-Subsystem 1140 auch API
zum Aufzählen von
Sitzungen, Erhalten von Sitzungsinformationen, Abtrennen von Sitzungen,
Zurücksetzen
von Sitzungen, Begrenzen der Anzahl von Sitzungen, Senden von Nachrichten
zu Sitzungen, Einstellen von Schwellen für Sitzungslasten und Ausgeben
eines Ereignisses, wenn die Sitzungslast eine Schwelle erreicht
oder zum Normalzustand zurückkehrt,
bereit.
-
Das
spezialiserte Server-Subsystem 1140 verwaltet Informationen
bezüglich
abgetrennter Sitzungen. Eine abgetrennte Sitzung ist eine Sitzung,
die aktiv ist, aber ohne Eingabe und Ausgabe. Es existiert keine ICA-Verbindung zwischen
dem Client 120 und dem abgetrennten Server. Sitzungen werden
durch eine Kombination aus einer Host-ID und einer Sitzungs-ID eindeutig
identifiziert. Die Host-ID ist in der Server-Farm 110 eindeutig
und die Sitzungs-ID ist für
einen bestimmten Server eindeutig. Mit einem Server 180 assoziierte
Sitzungen werden auch durch den Client-Namen identifiziert. Mit
einer Anwendung (aktiv und abgetrennt) assoziierte Sitzungen werden
auch durch den Namen des Clients (d. h. den Maschinen- oder „NETBIOS"-Namen0 identifiziert, der mit der Anwendung
verbunden ist, und durch den Namen der Anwendung (z. B. <Anwendungsname>:<Client-Name>). Bei einer Ausführungsform werden aktive Sitzungen
eindeutig durch Host-ID und Sitzungs-ID identifiziert. Wenn eine
Sitzung endet, kann die zuvor mit der beendeten Sitzung assoziierte Sitzungs-ID
für eine
Sitzung wiederverwendet werden.
-
Das
spezialisierte Server-Subsystem 1140 verzeichnet abgetrennte
Sitzungen in dem dynamischen Speicher 240. Jeder Datensatz
einer abgetrennten Sitzung enthält
eine Host-ID, eine Sitzungs-ID, einen Client-Namen, den Namen der
Anwendung und andere Informationen, wie zum Beispiel Benutzername
und Domäne
des Clients. Das spezialisierte Server-Subsystem 1140 fügt einen
abgetrennte-Sitzung-Datensatz zu dem dynamischen Speicher 240 hinzu,
wenn jede Sitzung abgetrennt wird, und löscht den abgetrennte-Sitzung-Datensatz,
wenn sich der Client 120 wieder mit der Sitzung verbindet.
-
15 zeigt eine Ausführungsform eines von dem spezialisierten
Server-Subsystem 1140 verwendeten Prozesses zum Wiederverbinden
des Clients 120 mit einer abgetrennten Sitzung dieses Clients.
Der Client 120 sendet (Schritt 1502) zu dem ICA-Browser-Subsystem 720,
das versucht, ein Anwendungsprogramm zu starten. Die Anforderung
enthält
den Client-Namen und den Anwendungs-Namen. Das ICA-Browser-Subsytem 720 sendet
(Schritt 1504) solche Informationen zu dem Gemeinschaftsanwendungs-Subsystem 300,
um Anwendungsnamenauflösung
auszuführen,
wie später
ausführlicher
beschrieben werden wird. Das Gemeinschaftsanwendungs-Subsystem 300 leitet
die Anforderung zu einem spezialisierten Server-Subsystem 1140 weiter
(Schritt 1506), das den dynamischen Speicher 240 auf
der Suche nach einem Datensatz einer abgetrennten Sitzung, die mit
dem Client- und Anwendungsnamen übereinstimmt,
abfragt (Schritt 1508).
-
Die
Durchsuchung des dynamischen Speichers 240 produziert (Schritt 1510)
einen Erfolg oder Mißerfolg.
Wenn die Suche erfolgreich ist, weil der Client eine abgetrennte
Sitzung für
gewünschte
Anwendung aufweist, erhält
(Schritt 1512) das spezialisierte Server-System 1140 die
Adresse des Servers, der durch die Host-ID in dem Datensatz der
abgetrennte Sitzung identifiziert wird, aus dem Dienstmodul 356 des
dynamischen Speicherssystems und gibt die Adresse an das ICA-Browser-Subsystem 720 zurück. Das
ICA-Browser-Subsystem 720 gibt die Adresse des abgetrennten
Servers an den Client 120 zurück (Schritt 1516).
Das Format der Adresse hängt
von dem zugrundeliegenden Transportmechanismus (z. B. IPX oder TCP)
für die Kommunikation
mit dem abgetrennte Server von dem Client 120 ab. Dieser
Transportmechanismus kann von dem während der abgetrennten Sitzung
verwendeten Transportmechanismus verschieden sein. Der Client 120 stellt
dann (Schritt 1518) eine ICA-Verbindung zu dem durch die
Adresse identifizierten abgetrennten Server her. Nachdem der Benutzer
des Clients 120 authentifiziert ist, führt der wiederverbundene Server
die Anwendung aus und gibt über
die ICA-Verbindung Ergebnisse an den Client zurück.
-
Wenn
die Suche nach einer abgetrennten Sitzung erfolglos ist, löst das spezialisiert
Server-Subsystem 1140 den Anwendungsnamen auf, indem eine
Adresse eines Servers bestimmt wird, der die angeforderte Anwendung
hostet und mit dem wie nachfolgend beschrieben der Client eine Verbindung
herstellen kann.
-
7.9.3 Anwendungsnamenauflösung
-
Nachdem
eine Anwendung publiziert wurde, können Clients diese Anwendung
starten. Um die Anwendung auszuführen,
muß der
Server 180 zuerst den Anwendungsnamen auflösen. Bei
der Namenauflösung wird
eine Adresse bestimmt, die verwendet werden kann, um von dem benutzerfreundlichen
Namen des gewünschten
Anwendungsnamens aus auf die Anwendung zuzugreifen. Genauer gesagt,
sendet der Client 120, wenn der Client 120 die
Anwendung startet, eine Anforderung über eine Strecke zu dem Server 180 in
der Server-Farm 110. Bei einer Ausführungsform ist diese Anforderung
ein UDP-Datagramm. Das UDP-Datagramm enthält den Namen der Anwendung.
Der Client 120 ersucht um Auflösung dieses Anwendungsnamen
in einer Adresse (z. B. eine TCP/IP-Adresse). Das ICA-Browser-Substystem 720 des
Servers 180 empfängt
das UDP-Datagramm. An diesem Punkt nimmt das ICA-Browser-Substystem 720 an, daß der Name
in dem UDP-Datagramm mit einer Anwendung assoziiert ist, obwohl
für einen
Server sein kann.
-
Die
Funktion des ICA-Browser-Subsystem 720 besteht darin, daß empfangene
UDP-Datagramm zu decodieren und die decodierten Informationen zu
dem entsprechenden Subsystem weiterzuleiten. Bei einer Ausführungsform
dient das Gemeinschaftsanwendungs-Subsystem 300 als anfänglicher
Zugangspunkt der Kommunikation für
das ICA-Browser-Subsystem 720 zum Auflösen des Anwendungsnamens. Das
ICA-Browser-Subsystem 720 sendet über den Ereignisbus 310 ein
Ereignis zu dem Gemeinschaftsanwendungs-Subsystem 300 mit
einer Anforderung der TCP/IP-Adresse, die einem Server entspricht,
der die gewünschte
Anwendung hostet.
-
Im
allgemeinen stellt das Gemeinschaftsanwendungs-Subsystem 300 eine anfängliche
Bestimmung der Verfügbarkeit
der gesuchten Anwendung bereit. Durch das Dienstmodul 352 des
persistenten Speichersystems hat das Gemeinschaftsanwendungs-Subsystem 300 Zugang
zu Informationen über
alle durch das spezialisierte Server-Subsystem 1140 publizierten
Anwendungen. Das Gemeinschaftsanwendungs-Subsystem 300 sendet
ein Ereignis zu dem Dientsmodul 352 des persistenten Speichersystems,
um den persistenten Speicher 230 unter Verwendung des benutzerfreundlichen
Namens (z. B. „Microsoft
Word 2000") der
Anwendung nach der gewünschten
Anwendung zu durchsuchen. Wenn die gewünschte Anwendung publiziert
ist, gibt die Suche durch den persistenten Speicher 230 eine
mit der Anwendung assoziierte eindeutige Kennung zurück. Eine
erfolglose Suche zeigt an, daß die
gesuchte Anwendung nicht verfügbar
ist.
-
Teil
der Pulblizierung einer Anwendung ist das Speichern von Informationen,
die das Subsystem (im folgenden „Auflösendes Subsystem") angeben, daß Namenauflösung für diese
Anwendung ausführt.
Nachdem gefunden wurde, daß die
Anwendung publiziert ist, bestimmt das Gemeinschaftsanwendungs-Subsystem 300 auch
das auflösende
Subsystem. Insbesondere bestimmt das Gemeinschaftsanwendungs-Subsystem 300 den
Typ des auflösenden
Subsystems (z. B. den Typ des spezialisierten Server-Subsystems 1140,
des spezialisierten Anwendungs-Subsystems 1416 usw.) und
kommuniziert dann mit dem Dienstlokalisierer 354, um den
Server zu bestimmen, der diese Art von auflösendem Subsystem aufweist.
Ein solcher Server kann derselbe Server 180 oder ein abgesetzter
Server in der Server-Farm 110 sein.
Ein der Anwendungsanforderung entsprechendes Ereignis wird dann
zu dem auflösenden
Subsystem auf diesem Server weitergeleitet. Das Ereignis enthält die eindeutige
Kennung der gesuchten Anwendung.
-
Der
Typ des auflösenden
Subsystems ist implementierungsabhängig. Wenn der Server 180 abgegtrennte
Sitzungen unterstützt,
bedingt die Namenauflösung
ferner eine Prüfung
nach abgetrennten Sitzungen, die mit der Identifikation des Clients übereinstimmen.
Wie oben beschrieben, verwaltet das spezialisierte Server-Subsystem 1140 Sitzungen
und operiert deshalb aus Effizienzgründen bei einer Ausführungsform
als das auflösende
Subsystem. Somit führt
das spezialisierte Server-Subsystem 1140 des Servers 180 wie
oben beschrieben die Suche nach einer abgetrennten Sitzung aus.
Wenn keine abgetrennte Sitzung mit der Client-Identifikation übereinstimmt,
fragt das spezializierte Server-Subsystem 1140 das Lastverwaltungs-Subsystem
ab, um die Anwendung lastauszugleichen.
-
Das
Lastverwaltungs-Subsystem gibt die eindeutige Kennung des die Anwendung
hostenden Servers an das spezialisierte Server-Subsystem 1140 zurück. Die
Identfikation des Hostservers wird aus der eindeutigen Kennung bestimmt.
Das spezialisierte Server-Subsystem 1140 gibt dann eine
der Hostserver-Identifikation entsprechende TCP-Adresse an das ICA-Browser-Subystem 720 zurück, um die
Namenauflösung
abzuschließen.
Bei einer Ausführungsform
kann das spezialisierte Anwendungs-Subsystem 1416 als das
auflösende Subsystem
operieren. Wenn der Anwendungsname nicht aufgelöst werden kann, wird ein Fehler
zurückgegeben.
-
Wenn
das Gemeinschaftsanwendungs-Subsystem 300 bestimmt, daß die Anwendung
nicht in den persistenten Speicher 230 publiziert ist,
entspricht der Name des UDP-Datagramms nicht einer Anwendung. Das
Gemeinschaftsanwendungs-Subsystem 300 antwortet dem ICA-Browser-Subsystem 720 mit
der Angabe, daß der
Name, für
die Auflösung
gewünscht
wird, nicht für
eine Anwendung ist. Als Antwort sendet das ICA-Browser-Subsystem 720 ein
Ereignis zu dem Gemeinschaftsserver-Subsystem 300, das versucht,
zu bestimmen, ob der Name einem Server in der Farm entspricht.
-
Das
Gemeinschaftsserver-Subsystem 300 durchsucht alle Serverobjekte
in dem persistenten Speicher 230 (durch das Dienstmodul 352 des
persistenten Speichersystems) und sucht nach dem Namen, der gerade
aufgelöst
wird. Wenn der Name lokalisiert wird, bestimmt das Gemeinschaftsserver-Subsystem 300 das
auflösende
Subsystem auf der Basis des spezialisierten Typs des Servers und
leitet die Namenauflösungsanforderung
zu dem spezialisierten Server-Subsystem 1140 weiter. Dieses
spezialisierte Server-Subsystem 1140 gibt seine eigene
Adresse an das Gemeinschaftsserver-Subsystem 300 zurück. Das
Gemeinschaftsserver-Subsystem 300 leitet die Adresse zu
dem ICA-Browser-Subsystem 720 weiter, und das ICA-Browser-Subsystem 720 gibt
die Adresse an den Client 120 zurück. Mit diesser Adresse kann
sich der Client 120 direkt mit dem entsprechenden Server 180 verbinden.
-
7.9.4 Anwendungs-Aufzählung
-
Der
Client 120 kann auch eine Anwendungs-Aufzählung anfordern.
Anwendungs-Aufzählung
ermöglicht
es einem Benutzter des Clients 120, die Namen jeder publizierten
Anwendung zu betrachten. Bei einer Ausführungsform kann der Benutzer
des Clients 120 die Anwendung ungeachtet, ob der Benutzer
diese Anwendung tatsächlich
starten kann, betrachten. Bei einer anderen Ausführungsform sieht der Benutzer
nur die Anwendungsnamen, für
deren Start der Betrachter authorisiert ist.
-
Anforderungen
einer Anwendungs-Aufzählung
werden abhängig
von dem bestimmten von dem Client 120 ausgeführten Prozeß zu dem
ICA-Browser-Subsystem 720, zu dem Programmnachbarschafts-Subsystem 760 oder
zu dem Gemeinschaftszugangspunkt-Subsystem 645 geleitet.
Wenn der Client 120 zum Beispiel eine Programmnachbarschafts-Anwendung
ausführt,
werden die Anforderungen einer Anwendungs-Aufzählung zu dem Programmnachbarschafts-Subsystem 760 gesendet.
Wenn der Client 120 die Aufzählungsanforderung durch eine
Webseite unterreicht, werden die Anforderungen zu dem Gemeinschaftszugangspunkt-Subsystem 645 geleitet.
Bei diesen Ausführungsformen
dient das Gemeinschaftsanwendungs-Subsystem 300 als anfänglicher
Zugangspunkt für
das Programmnachbarschafts-Subsystem 760, das ICA-Browser-Subystem 720 und
das Subsystem des Gemeinschaftszugangspunkts 645, wenn
der Client 120 Anwendungen aufzählen möchte.
-
Nach
dem Empfang der Aufzählungsanforderungen
fragt das Gemeinschaftsanwendungs-Subsystem 300 den persistenten
Speicher 230 nach einer Liste aller Anwendungen ab. Für aus dem
Programmnachbarschafts-Subsystem 760 und dem Subsystem
des Gemeinschaftszugangspunkts 645 empfangene Anforderungen
wird diese Liste von Anwendungen gemäß dem Berechtigungsnachweis-Benutzers
des Clients 120 gefiltert (d. h. der Benutzer sieht nur
die Anwendungen, für
die der Benutzer authorisiert ist).
-
7.9.5 Server-Aufzählung
-
Der
Client 120 kann auch Server-Aufzählung anfordern. Server-Aufzählung ermöglicht es
einem Benutzer des Clients 120, eine Liste der Server in
der Server-Farm zu betrachten. Bei einer Ausführungsform kann die Liste der
Server gemäß dem Typ
des Servers, bestimmt durch das spezialisierte Server-Subsystem 1140 auf
diesem Server, gefiltert werden.
-
Anforderungen
einer Server-Aufzählung
werden abhängig
von dem bestimmten von dem Client 120 ausgeführten Prozeß zu dem
ICA-Browser-Subsystem 720 oder zu dem Gemeinschaftszugangspunkt-Subsystem 645 geleitet.
Wenn der Client 120 zum Beispiel die Server-Aufzählungsanforderung
durch eine Webseite unterreicht, werden die Anforderungen zu dem
Gemeinschaftszugangspunkt-Subsystem 645 geleitet. Bei diesen
Ausführungsformen
dient das Gemeinschaftsserver-Subsystem 300 als
anfänglicher
Zugangspunkt für das
ICA-Browser-Subsystem 720 und Subsysteme des Gemeinschaftszugangspunkts 645.
Nach dem Empfang von Server-Aufzählungsanforderungen
fragt das Gemeinschaftsserver-Subsystem 300 den persistenten Speicher 230 nach
einer Liste aller Server ab. Wahlweise wird die Liste der Server
gemäß dem Servertyp
gefiltert.
-
7.10 Das Subsystem des Gemeinschaftszugangspunks
(CAP)
-
Ein
Administrator kann Software auf dem Server 180 installieren,
die nicht in den Ereignisbus 310 „eingesteckt" werden kann; das
heißt,
solche Nicht-Einsteck-Software
führt Prozesse
aus und verwendet Datentypen, die nicht Teil des von den Subsystemen 300 während der
Intraserver-Kommunikation verwendeten Ereignisnachrichtenübermittlungsprotokolls
sind. Jeder Server 180 in der Server-Farm 110 enthält eine Gemeinschaftszugangspunkt-Subsystem 645,
um es solcher Nicht-Einsteck-Software zu ermöglichen, über den Ereignisbus 310 mit
den Subsystemen 300 zu kommunzieren. Um mit den Subsystemen 300 zu
kommunzieren, verwendet die Nicht-Einsteck-Software die API der
Subsystemzugangsschicht (SAL) 304, die durch das Gemeinschaftszugangspunkt-Subsystem 645 bereitgestellt
wird, um Ereignisse auf den Ereignisbus 310 zu legen. Ein
Beispiel für
solche Software ist der Terminal-Server-Logon-Prozeß, der als „"Termserv" bezeichnet wird
und oben im Abschnitt 7.7 beschrieben wurde.
-
7.11 Das Administrations-Subsystem
-
Jeder
Server 180 in der Server-Farm 110 enthält ein Administrations-Subsystem 300.
Das Administrations-Subsystem 300 stellt
eine SAL 304 bereit, die es den anderen Subsystemen 300 ermöglicht,
ihre Daten auf das Administrationswerkzeug 140 oder einen
Client 120 zu publizieren und somit diese Daten einem Administrator
der Server-Farm 110 sichtbar zu machen. Das Administrations-Subsystem 300 arbeitet
mit dem nachfolgend beschriebenen Administrationswerkzeug 140 zusammen,
wenn das Administrationswerkzeug 140 die durch das Administrations-Subsystem
bereitgestellten Daten verwaltet und betrachtet.
-
8.0 Das Administrationswerkzeug
-
Das
Administrationswerkzeug 140 stellt eine grafische Benutzeroberfläche bereit,
die Menüs,
Werkzeugleisten und Daten, die mit Subsystemen 300 auf
dem Server 180 der Server-Farm 110 assoziiert
sind, definiert und verwaltet. Das Standardlayout des Administrationswerkzeugs 140 ist
ein Desktop-Fenster, in das zusätzliche
Komponenten (z. B. eine Betrachtungsinstanz eines Administrations-Plug-In)
plaziert werden können.
Jedes der Plug-Ins für
das Administrationswerkzeug 140 kann Menüelemente
und Werkzeugleisten je nach Fall einfügen, entfernen und modifizieren.
Das Administrationswerkzeug 140 zeigt verschiedene Ressourcen
an, die, wenn der Administrator auf sei browset, zusätzliche
Informationen in dem Desktop-Fenster aktivieren und anzeigt.
-
16 zeigt eine Ausführungsform eines Prozesses
zum Starten des Administrationswerkzeugs 140. Während seiner
Herauffahrsequenz bildet das Administrationswerkzeug 140 ein
Rahmenfenster, eine Menüleiste
und eine Werkzeugleiste. Dann bildet es eine Desktop-Ansicht und
legt sie in den Inhaltsbereich des Rahmenfensters. Dann verbindet
sich das Administrationswerkzeug 140 (Schritt 1602)
mit einer oder mehreren Server-Farmen 110, indem es einem
bevorzugten Server 180 in jeder Server-Farm 110 Authentifikations-Berechtigungsnachweise
zuführt.
Bei einer Ausführungsform
umfassen Authentifikations-Berechtigungsnachweise
Benutzername-Paßwort-Paar.
Bei anderen Ausführungsformen
können
die Authentifikations-Berechtigungsnachweise
einen privaten Schlüssel
oder ein digitales Zertifikat umfassen. Falls die Verbindung zu
dem bevorzugten Server fehlschlägt,
versucht das Administrationswerkzeug 140 bei einer Ausführungsform,
sich mit anderen Servern 180 in dieser Server-Farm 110 zu
verbinden. Bei bestimmten Ausführungsformen
präsentiert
das Administrationswerkzeug Authentifikations-Berechtigungsnachweise,
nachdem eine erfolgreiche Verbindung hergestellt wurde. Als Teil
der Logon-Sequenz gibt das Administrationswerkzeug 140 (Schritt 1604) ein
Farm-Logon-Ereignis auf das Administrations-Subsystem auf und wartet
auf eine Antwort. Zu den Arten von Antworten, die angetroffen werden
können,
gehören
eine Zeitgrenze, ein erfolgreiches Login, ein Fehlschlag aufgrund
des Angebens ungültiger
oder nicht anerkannter Authentifikations-Berechtigungsnachweise oder
ein Fehlschlag aufgrund des Angebens einer ungültigen Farm-Kennung oder Server-Kennung.
-
Wenn
ein Logon erfolgreich ist, sendet eine Ausführungsform eines Initialisierungsprozesses
des Administrationswerkzeugs 140 Ereignisnachrichten 700,
die (1) den angeschlossenen Server nach einer Liste aller Server
in der Server-Farm 110 abfragen (Schritt 1606);
(2) Administrationswerkzeug-Plug-Ins auflöst (Schritt 1608);
(3) die Plug-Ins des Administrationswerkzeugs 140 mit denen
der Server-Farm 110 vergleicht (Schritt 1610)
und etwaige neue oder aktualisierte Administrationswerkzeug-Plug-Ins
je nach Bedarf herunterlädt
und installiert (Schritt 1612); (4) die Administrationswerkzeug-Plug-Ins
lädt und
initialisiert (Schritt 1614); (5) die Objekte der Server-Farm 110 lädt (Schritt 1616);
und (6) Objektinformationen der Server-Farm 110 in dem
Desktop-Fenster
anzeigt (Schritt 1618).
-
17 zeigt ein beispielhaftes Desktop-Fenster 1700,
das Objektinformationen einer Server-Farm 110 anzeigt.
Bei dieser Ausführungsform
repräsentiert
das Symbol JasonFarm3-9 1715 die Server-Farm 110. Das
Desktop-Fenster 1700 zeigt
Informationen in zwei Feldern an: einem linken Feld 1705 und
einem rechten Feld 1710. Das linke Feld 1705 zeigt
eine Baumansicht der Server-Farm 110, mit der das Administrationswerkzeug 140 verbunden
ist. Das rechte Feld 1710 zeigt eine „Reiter"-Informationsansicht über und
Steuerelemente für
das Symbol an, das in dem linken Feld 1705 hervorgehoben
ist (in diesem Fall serverweite Richtlinien in bezug auf die als
JasonFarm3-9 1715 identifizierte Server-Farm 110).
-
Zum
Administrieren des Lizenzierungs-Subsystems zeigt das Administrationswerkzeug 140 Lizensierungsinformationen
in zwei Feldern an: einem linken Feld 1705 und einem rechten
Feld 1710. 18 zeigt eine beispielhafte
Anzeige, die in Verbindung mit dem Administrieren von Lizenzen erscheint.
Das linke Feld 1705 zeigt eine Baumansicht von Lizenzzeichenketten
und Lizenzgruppen. Entsprechende Lizensierungsinformationen und
Steuerelemente erscheinen in dem rechten Feld 1710 der
GUI des Administrationswerkzeug-Desktop-Fensters 1700.
Das Lizenzensymbol 1805 kann weiter in individuelle Gruppen
von Lizenzen expandiert werden. Da der Baum nicht expandiert ist,
zeigt das rechte Feld 1710 alle Lizenzzeichenketten in
allen Gruppen an.
-
Bei
einer anderen Ausführungsform
enthält
die Lizenzierungs-Benutzeroberfläche
drei Anzeigen mit Reitern: einen Verbindungslizenz-Gruppen-Reiter,
einen Produktlizenz-Reiter und einen Lizenzgruppen-Reiter. Der Verbindungslizenz-Gruppen-Reiter
zeigt ein Schirmbild an, das es einem Administrator erlaubt, an spezifischen
Gruppen von Verbindungslizenzen zu operieren. Der Produktgruppen-Reiter
zeigt ein Schirmbild an, das es einem Administrator erlaubt, an
spezifischen Gruppen von Produktlizenzen zu operieren. Der Lizenzzeichenketten-Reiter
zeigt ein Schirmbild an, das es einem Administrator ermöglicht,
Lizenz-Seriennummern
einzugeben, zu entfernen oder zu ändern.
-
Die
folgenden Operationen können
an einer Lizenzgruppe ausgeführt
werden:
- (1) Gruppe löschen – der Administrator kann alle
Lizenzzeichenketten aus einer Lizenzgruppe löschen und löscht dann die Gruppe selbst.
Zum Beispiel kann der Administrator alle RNS-Lizenzen aus dieser
Server-Farm entfernen, indem er die RNS-Lizenzgruppe löscht. Eine Lizenzgruppe kann
nicht gelöscht
werden, wenn irgendwelche der in dieser Gruppe enthaltenen Lizenzzeichenketten
auch in einer anderen Lizenzgruppe enthalten sind, da dies einen
Teil der Funktionalität
dieser Lizenzen verweisen würde.
(Beispiel: eine Serverbasislizenz-Zeichenkette, die auch einen Verbindungslizenz-Zählwert enthält, erscheint
in zwei Lizenzgruppen. Während
diese Lizenz installiert ist, kann die Verbindungslizenzgruppe deshalb
nicht gelöscht
werden).
- (2) Eine Lizenzgruppe dem Server zuweisen – der Administrator erreicht
die Zuweisung einer Lizenzgruppe zu einem Server durch Ziehen einer
Lizenzgruppe auf einem entweder in dem linken Feld 1705 oder
in dem rechten Feld 1710 der Anzeige des Administrationswerkzeug-Desktop-Fensters 1700 erscheinenden
Server. Wenn die Lizenzgruppe zugewiesen wird, fragt ein Popup-Fenster
den Benutzer, wieviele der Lizenzen aus der Lizenzgruppe dem Server
zuzuweisen sind, wobei das Maximum die Gesamtzahl nichtzugewiesener
Lizenzen in der Lizenzgruppe ist. Es unterliegt der Verantwortung
des Administrators, einen Server, der die Lizenzen in der Gruppe
verwenden kann, eine Lizenzgruppe zuzuweisen, und nicht dem Server
mehr Lizenzen zuzuweisen, als der Server benötigt (d. h. mehr als eine Serverbasislizenz).
Bei bestimmten Ausführungsformen
kann dieser Prozeß durch
einen „Wizard" erleichtert werden,
das heißt,
ein Programm, das bestimmte Informationen direkt vom Administrator
ablistet.
- (3) Rückgängigmachen
einer Zuweisung einer Lizenzgruppe zu einem Server – der Administrator
erreicht das Rückgängigmachen
der Zuweisung durch Anklicken der Lizenzgruppe und anschließendes Auswählen des
in dem rechten Feld erscheinenden Lizenzzuweisungsreiters 1815 und
Löschen
der dann gezeigten Zuweisungen.
-
Mit
Bezug auf 18 zeigt das rechte Feld 1710 der
GUI des Administrationswerkzeugs eine „Reiter"-Ansicht von Informationen und Steuerelementen
bezüglich
der in dem linken Feld 1705 ausgewählten Lizenzgruppe (in diesem
Fall das Symbol 1805 der Lizenzen der obersten Ebene, das
alle Lizenzgruppen in der Server-Farm 110 repräsentiert).
Ein beispielhafter „Reiter" ist die Lizenzzeichenketten 1810.
Anklicken dieses Reiters zeigt eine Liste der Lizenzzeichenketten
in der gerade ausgelegten Lizenzgruppe, den Status jeder Lizenz
(z. B. aktiviert, nichtaktiviert, abgelaufen und Evaluierung), die
Anzahl der für
diese Lizenzzeichenkette verfügbaren
Lizenzen. Der Lizenzzeichenketten-Reiter 1810 erlaubt die
folgenden Operationen:
- (1) Hinzufügen einer
Lizenzzeichenkette. Wenn eine Lizenzzeichenkette hinzugefügt wird,
wird diese Zeichenkette automatisch der Lizenzgruppe bzw. den Lizenzgruppen
zugewiesen, für
die sie relevant ist. Dies kann eine neue Lizenzgruppe erzeugen.
Die erste Lizenzgruppe, zu der die Lizenzzeichenkette hinzugefügt wird,
wird in dem linken Feld 1705 des Administrationswerkzeugs
ausgewählt.
Bei bestimmten Ausführungsformen
kann eine Lizenzzeichenkette von jeder beliebigen Ansicht aus hinzugefügt werden.
- (2) Entfernen einer Lizenzzeichenkette. Bevor sie entfernt wird,
wird eine Lizenzzeichenkette aus den Gruppen herausgenommen, in
denen sie residiert. Wenn das Entfernen der Lizenzzeichenkette die
Lizenzgruppe leert, wird die Lizenzgruppe entfernt. Bei bestimmten
Ausführungsformen
wird die Zuweisung der entfernten Lizenzen und Lizenzgruppen auch „rückgängig" gemacht, das heißt, die
Zuweisung dieser Lizenz oder Lizenzgruppe zu einem Server wird aus
dem persistenten Speicher entfernt.
-
Andere
Operationen wären
das Aktivieren einer Lizenzzeichenkette, das Ausdrucken nichtaktivierter Lizenzzeichenketten,
das Zeigen eines Kulanzzeitraums (z. B. Tage), der für das Aktivbleiben
dieser Lizenzzeichenkette verbleibt.
-
Ein
weiterer beispielhafter Reiter ist „Lizenzzuweisungen" 1815. Durch
Auswählen
dieses Reiters kann der Administrator die Gesamtzahl der durch eine
Lizenzgruppe bereitgestellten Lizenzen, die Gesamtzahl der Servern
zugewiesenen Lizenzen und die Gesamtzahl jeder dieser Lizenzen,
die gerade benutzt werden, ansehen.
-
Zur
Verwaltung von Anwendungen ermöglicht
das Administrationswerkzeug 140 dem Administrator das Setzen
einer farmweiten Richtlinie. 19 zeigt
eine beispielhaften Anzeige, die in Verbindung mit dem Administrieren
von Anwendungen erscheint. Das linke Feld 1705 zeigt eine
Baumansicht verfügbarer
Anwendungen. Entsprechende Anwendungsinformationen und Steuerelemente
erscheinen in dem rechten Feld 1710 der GUI des Administrationswerkzeug-Desktop-Fensters 1700.
Das Anwendungssymbol 1905 ist weiter zu der verfügbaren Anwendung
Excel 1910 und Word 1915 expandiert gezeigt. Wie
gezeigt, ist das Excel-Anwendungssymbol 1910 hervorgehoben,
und somit zeigt das rechte Feld 1710 Informationen und
Steuerelemente für
diese Anwendung an.
-
Mit
Bezug auf 19 zeigt das rechte Feld 1710 der
GUI des Administrationswerkzeugs eine „Reiter"-Ansicht von Informationen und Steuerelementen
bezüglich
der Excel-Anwendung 1910, die in dem linken Feld 1705 ausgewählt ist,
an. Ein beispielhafter „Reiter" ist „Server" 1920. Ein
Anklicken dieses Reiters zeigt eine Liste der Server, die dafür konfiguriert
sind, die gerade ausgewählte
Anwendung zu hosten. Wie gezeigt, ist der Server JASONK3-9 dafür konfiguriert,
die Excel-Anwendung
zu hosten. Bei einer anderen Ausführungsform ist ein Reiter „Verbindungen" vorgesehen, der
ein Schirmbild anzeigt, das alle aktiven Verbindungen mit einer
Anwendung zeigt.
-
Zur
Verwaltung von Servern der Server-Farm ermöglicht es das Administrationswerkzeug 140 dem Administrator,
farmweite Richtlinien zu setzen. 20 zeigt
eine beispielhaften Anzeige, die in Verbindung mit dem Administrieren
von Servern erscheint. Das linke Feld 1705 zeigt eine Baumansicht
verfügbarer
Server. Entsprechende Serverinformationen und Steuerelemente erscheinen
in dem rechten Feld 1710 der GUI des Administrationswerkzeug-Desktop-Fensters 1700.
Das Server-Symbol 2005 ist weiter zu dem verfügbaren Server
JASONK3-9 2010 expandiert gezeigt. Wie gezeigt, ist das
Serversymbol JASONK3-9 2010 hervorgehoben, und somit zeigt
das rechte Feld 1710 Informationen und Steuerelemente für diesen
Server an.
-
Mit
Bezug auf 20 zeigt das rechte Feld 1710 der
GUI des Administrationswerkzeugs eine „Reiter"-Ansicht von Informationen und Steuerelementen-Ansicht
von Informationen und Steuerelementen bezüglich des in dem linken Feld 1705 ausgewählten Servers
JASONK3-9 an. Ein beispielhafter „Reiter" ist „Informationen" 2015. Ein
Anklicken dieses Reiters zeigt eine Liste von Konfigurationsdaten über den
gerade ausgewählten
Server. Wie gezeigt, enthält
die Liste Betriebssysteminformationen, wie etwa Versionen, Installationsdatum
und Spezialmerkmale über
den Server JASONK3-9. Außerdem
enthält
die Liste die diesem Server zugewiesenen Netzwerkinformationen.
-
Zur
Verwaltung von Benutzern und Benutzergruppen ermöglicht es das Administrationswerkzeug 140 dem
Administrator, farmweite Richtlinien zu setzen. Für eine solche
Benutzerverwaltung stellt das Administrationswerkzeug 140 ein
Verfahren zum Setzen des „Server-Vertrauens-Anfrageintervalls" bereit, um die Häufigkeit
zu steuern, mit der die Server 180 sich selbst abfragen,
um die Konto-Authoritäten
zu bestimmen, denen sie vertrauen. Das Administrationswerkzeug 140 zeigt
außerdem
die Konto-Authoritätsinformationen
in Form eines Baums. Bei einer Ausführungsform zeigt der Baum in
absteigender Reihenfolge folgendes an:
- 1. Eine
Aufzählung
aller Konto-Authoritäts-Objekt-Typ-Deskriptoren,
wobei jedes Element einen registrierten Konto-Authoritäts-Typ repräsentiert
(z. B. „Authoritäten von
NTDOMAIN", „Authoritäten von
ACTIVE DIRECTORY" usw.).
- 2. Eine Expansion des Konto-Authoritätstyps zeigt alle Instanzen
der ausgewählten
Konto-Authorität
(z. B. „DEVELOP" oder „TEST" für NT-Domänen).
- 3. Die Hierarchie der Organisationseinheit (OU) der Kontoauthorität kann an
diesem Punkt durchquert werden, wenn die Konto-Authorität diese
Fähigkeit
unterstützt.
- 4. Eine Expansion einer Authoritäts-Instanz oder eines OU-Knotens
zeigt alle Unterstützungsobjektetypen der
gewählten
Konto-Authorität
(z. B. „Benutzerkonten" oder „Gruppenkonten").
-
Bei
einer Ausführungsform
umfaßt
jedes Plug-In für
das Administrationswerkzeug ein oder mehrere ladbare Module, die
einem oder mehreren Server-Subsytemen entsprechen. Ladbare Module
können
als Java-Beans, ActiveX-Steuerelemente oder CCM-Objekte bereitgestellt
werden.
-
Äquivalente
-
Die
vorliegende Erfindung kann als eines oder mehrere computerlesbare
Programme bereitgestellt werden, die auf oder in einem mehreren
Herstellungsartikeln realisiert sind. Der Herstellungsartikel kann
eine Diskette, eine Festplatte, ein CD-ROM, eine Flash-Speicherkarte, ein
PROM, ein RAM, ein ROM oder ein Magnetband sein. Im allgemeinen
können
die computerlesbaren Programme in einer beliebigen Programmiersprache
implementiert werden (LISP, PERL, C, C++, PROLOG) oder in einer
beliebigen Byte-Code-Sprache, wie
etwa JAVA. Die Softwareprogramme können auf oder in einem oder
mehreren Herstellungsartikeln als Objektcode gespeichert werden.
-
Nachdem
bestimmte Ausführungsformen
der Erfindung beschrieben wurden, ist nun für Fachleute erkennbar, daß andere
Ausführungsformen
verwendet werden können,
die die Konzepte der Erfindung umfassen. Die Erfindung sollte deshalb
nicht auf bestimmte Ausführungsformen
beschränkt
werden, sondern ihr Schutzumfang soll nur durch die folgenden Ansprüche begrenzt
werden.
-
1
- 110'''
- SERVER-FARM
SEATTLE
- 100
- SERVER-FARM
BOSTON
- 140
- ADMIN.-WERKZEUG
- 110''
- SERVER-FARM
DALLAS
- 110
- SERVER-FARM
MIAMI
-
2A
- 210
- NETZWERK
- 202
- NETZWERKSEITIGE
SCHNITTSTELLE
- 204
- FARM-VERWALTUNGSSCHNITTSTELLE
- 230
- PERSISTENTER
SPEICHER
- 240
- DYNAMISCHER
SPEICHER
-
2B
- 240
- DYNAMISCHER
SPEICHER
- 240'
- DYNAMISCHER
SPEICHER
- 230
- PERSISTENTER
SPEICHER
-
3
-
- ZUM
PERSISTENTEN SPEICHER 230
- 330
- LAGER
- 320
- SYSTEM
- 306''
- SS
DYNAMISCHER SPEICHER
- 306IV
- DIENSTLOKALISIERER
- 306V
- SUBSCRIPTIONSMANAGER
- 240
- DYNAMISCHER
SPEICHER
- 480
- ABGESETZT-SUBSKRIPTIONSTABELLE
- 380
- EREIGNISPUFFER
- 450
- LOKAL-SUBSKRIPTIONSTABELLE
- 325
- LOKALER
SPEICHER
- 306'
- SS
PERSISTENTER SPEICHER
- 316
- DISPATCH-TABELLE
- 306'''
- SS
HOST-AUFLÖSER
- 312
- EREIGNISABLIEFEROBJEKT
- 318
- TRANSPORTSCHICHT
- 345
- PUFFER-VERWALTUNG
- 340
- GEMEINSCHAFTSEINRICHTUNGS-MOD.
- 310
- EREIGNISBUS
-
4A
- 316
- DISPATCH-TABELLE
- 424
- ZIELE-SUBSYSTEM
- 428
- DISPATCH-ADRESSENFELD
-
4B
- 325
- LOKALER
SPEICHER
- 450
- LOKAL-SUBSKRIPTIONSTABELLE
- 462
- EREIGNIS
- 464
- EIGENTÜMER DES
EREIGNISSES
- 468
- ZIELE-SUBSYSTEM
-
4C
- 480
- ABGESETZT-SUBSKIPTIONSTABELLE
- 492
- EREIGNIS-ID
- 494
- EREIGNIS-EIGENTÜMER
- 498
- ID
SUBSKRIBIERENDER HOST
- 406
- ID
SUBSKRIBIERENDES SUBSYSTEM
-
- ZONENTABELLE
-
- GLOBAL-TABELLE
-
- QUELLEN-HOST-ID
-
- SPEZIFISCHE
ABGESETZT-TABELLE
-
5A
-
- SS
SUBSKRIPTIONSMANAGER DES SUBSKRIBIERENDEN SUBSYSTEMS
- 510
- AUFRUF „SUBSCRIBE" EMPFANGEN
- 514
- SUBSKRIBIERTES
EREIGNIS LOKAL ODER ABGESETZT?
-
- LOKAL
-
- ABGESETZT
- 518
- SUBSKRIPTION
IN LOKAL-TABELLE REGISTRIEREN
- 522
- BESTIMMEN,
OB SUBSKRIBIERTES EREIGNIS IN ZONE, FARMWEIT ODER EIN SPEZIFISCHER SERVER
IST
- 526
- SUBSKRIPTION
IN ENTSPRECHENDER TABELLE SPEICHERN
-
5B
-
- S.S.-MODUL
DES SUBSKRIPTIONSMANAGERS DES SERVERS, DER SUBSYSTEM SUBSKRIBIERT
HAT
- 550
- BENACHRICHTIGUNG-AUFGEBEN-EREIGNIS
EMPFANGEN
- 554
- LOKAL-SUBSKRIPTIONSTABELLE
NACH EINEM LOKALEN SUBSKRIBIERENDEN SUBSYSTEM PRÜFEN
- 558
- WENN
LOKAL-SUBSKRIBIERER GEFUNDEN, EREIGNIS KOPIEREN UND AUF DIESES SUBSYSTEM
AUFGEBEN
- 562
- „ZONE"-TABELLE DES DYNAMISCHEN
SPEICHERS PRÜFEN
UND KOPIE DES EREIGNISSES AN JEDEN SUBSKRIBIERER IN DER ZONE ABLIEFERN
- 566
- „FARMWEITE" TABELLE DES DYNAMISCHEN
SPEICHERS PRÜFEN
UND KOPIE DES EREIGNISSES AN JEDEN GEFUNDENEN SUBSKRIBIERER ABLIEFERN
- 570
- SPEZIFISCHE
ABGESETZT-HOST-SUBSKRIPTIONEN PRÜFEN
UND KOPIE DES EREIGNISSES AN JEDEM GEFUNDENEN SUBSKRIBIERER ABLIEFERN
-
6
-
- EREIGNISABLIEFEROBJEKT
(EDO) ERZEUGEN
-
- TRANSPORTMECHANISMUS
ERZEUGEN
-
- EDO
AN TRANSPORTMECHANISMUS BINDEN
-
- LADERMODUL
INSTANZIIEREN
-
- LADERMODUL
AUSFÜHREN
-
- SPEZIALISIERTES
SUBSYSTEM ERZEUGEN UND LADEN
-
- NOTWENDIGE
SYSTEMDIENSTMODULE ERZEUGEN UND LADEN
-
- PERSONALITÄTS-SUBSYSTEME
BESTIMMEN UND LADEN
-
- DISPATCH-TABELLE
FÜLLEN
-
7A
-
- EREIGNIS-KOPFTEIL
-
- EREIGNIS-DATEN
-
7B
-
- EREIGNIS-KOPFTEIL
-
- EREIGNIS-ID
-
- KOPFTEIL-VERSION
-
- EREIGNIS-VERSION
-
- DATENGRÖSSE
-
- DATEN-OFFSET
-
- UID
QUELLEN-SUB.
-
- UID
ZIEL-SUB.
-
- KANAL-NR.
(SER. NR.)
-
8A
- 300
- QUELLEN-SUBSYSTEM
- 800
- ZIEL-SERVER
BENÖTIGT?
- Y
- J
- 802
- ZIEL-SERVER
ANFORDERN
- 810
- EREIGNIS
ZU ZIEL-S.S. SENDEN
- 804
- ZIEL-SERVER
BESTIMMEN
- 354
- DIENST-LOKALISIERER
- 806
- ZIEL-SERVER
ZURÜCKGEBEN
- 808
- EREIGNIS
AN ZIEL-S.S. AUSGEBEN
-
- LOKAL
- 812
- EREIGNIS
LOKAL ODER ABGESETZT?
-
- ABGESETZT
- 814
- EREIGNIS
AN TRANSPORTSCHICHT ABLIEFERN
- 816
- SENDET
EREIGNIS ZU ZIEL-S.S.
- 310
- EREIGNISBUS
- 300'
- ZIEL-SUBSYSTEM
-
8B
- 300
- QUELLEN-SUBSYSTEM
- 354
- DIENST-LOKALISIERER
- 310
- EREIGNISBUS
- 300'
- ZIEL-S.-SYSTEM
-
- VON 8A
- 818
- EINGANGSPUNKT
BESTIMMEN
- 820
- BESTIMMEN,
OB D.S. 300' EIN-
ODER MEHR-THREAD IST
-
- MEHRFACH-THREAD
-
- EINFACH-THREAD
- 822
- DISPATCH-EREIGNIS
AUFRUFEN
- 824
- EREIGNIS
IN WARTESCHLANGE SPEICHERN
- 826
- NEUEN
THREAD STARTEN
- 828
- DISPATCH-EREIGNIS
AUFRUFEN
- 824
- HANDLER-ROUTINE
AUSFÜHREN
-
9A
- 300
- QUELLEN-SUBSYSTEM
- 354
- DIENST-LOKALISIERER
- 310
- EREIGNISBUS
- 310'
- EREIGNSISBUS
- 300'
- ZIEL-SUBSYSTEM
- 902
- ANFORDERUNGSEREIGNIS
AUSGEBEN
- 904
- ZIEL-SERVER
ANFORDERN
- 906
- ZIEL-SERVER
BESTIMMEN
- 908
- ZIEL-SERVER
ZURÜCKGEBEN
- 910'
- ANFORDERUNGSEREIGNIS
ZU EREIGNISBUS SENDEN
- 910
- ANFORDERUNGSEREIGNIS
ZU EREIGNISBUS SENDEN
- 912
- BESTIMMEN,
DASS ZIEL-SS ABGESETZT IST
- 914
- EREIGNIS
ZU TRANSPORTSCHICHT LEITEN
- 916
- ANF.-EREIGNIS
ZU TRANSPORTSCHICHT DES ABGESETZTEN SERVERS SENDEN
-
- ZU 9B
-
9B
- 300
- QUELLEN-SUBSYSTEM
- 310
- EREIGNISBUS
- 310'
- EREIGNISBUS
- 300'
- ZIEL-SUBSYSTEM
-
- VON 9A
- 918
- ANF.-EREIGNIS
ZU EREIGNIS-ABLIEFEROBJEKT LEITEN
- 920
- EINGANGSPUNKT
BESTIMMEN
-
- MEHRFACH-THREAD
- 922
- BESTIMMEN,
OB D. S. S. (300')
EINFACH- ODER MEHRFACH-THREAD IST
-
- EINFACH-THREAD
- 924
- DISPATCH-EREIGNIS
AUFRUFEN
- 928
- ANFORDERUNGSEREIGNIS
EINREIHEN
- 930
- NEUEN
THREAD STARTEN
- 932
- DISPATCH-EREIGNIS
AUFRUFEN
- 926
- HANDLER-ROUTINE
AUSFÜHREN
-
- ZU 9C
-
9C
- 300
- QUELLEN-SUBSYSTEM
- 310
- EREIGNISBUS
- 310'
- EREIGNISBUS
- 300'
- ZIEL-SUBSYSTEM
-
- VON 9B
- 934
- ANTWORTEREIGNIS
PRODUZIEREN
- 938
- ANTWORTEREIGNIS
ZUR TRANSPORTSCHICHT (318')
SENDEN
- 936
- ANTWORTEREIGNIS
AUF EREIGNISBUS AUFGEBEN
- 942
- TRANSPORTSCHICHT
EMPFÄNGT
ANTWORTEREIGNIS
- 940
- ANTWORTEREIGNIS ÜBER NETZWERKVERBINDUNG
SENDEN
- 946
- HANDLER-ROUTINE
AUSFÜHREN
- 944
- ANTWORTEREIGNIS
AN WARTENDEN THREAD ABLIEFERN
-
9D
-
- EREIGNIS-WARTESCHLANGE
- 310
- EREIGNISABLIEFEROBJEKT
- 318
- TRANSPORTSCHICHT
-
10
- 300
- SUBSYSTEM
- 356
- DIENSTMODUL
DES DYNAMISCHEN SPEICHERSYSTEMS
- 358
- ZONENMANANGER
- 1002
- EREIGNIS
SENDEN
- 1004
- EIGENTÜMER DES
IM EREIGNIS GEWÜNSCHTEN
AUFZEICHNUNGSTYPS BEKANNT?
- YES
- JA
- NO
- NEIN
- 1008
- EREIGNIS
ZUM ZONENMANAGER SENDEN
- 1010
- BESTIMMEN,
WER DIE DATENSÄTZE
DES IDENTIFIZIERTEN TYPS SAMMELT
- 1012
- IST
ZONENMANAGER DER MASTER?
- 1006
- EREIGNIS
ZU DEM SAMMLER VON DATENSÄTZEN
DES IM EREIGNIS IDENTIFIZIERTEN TYPS SENDEN
- 1014
- SERVER-ID
ZU S.S.-MODUL DES DYNAMISCHEN SPEICHERS SENDEN
- 1016
- MASTER
NACH ID DES DEN AUFZEICHNUNGSTYP BESITZENDEN SERVERS ABFRAGEN
- 1018
- ADR.
DES SERVERS VOM MASTER EMPFANGEN
-
11
- 240
- DYN.
SPEICHER
-
- PERSISTENTER
SPEICHER
- 1150
- LIZENZ-DEPOT
- 1110
- S.S.
LIZENZVERWALTUNG
- 1120
- GRUPPEN-S.S.
- 1130
- BEZIEHUNGS-S.S.
- 1140
- S.S.
SPEZIALISIERTER SERVER
- 356
- S.S.-MODUL
DES DYNAMISCHEN SPEICHERS
- 371
- S.S.-MODUL
DES PERSISTENTEN SPEICHERS
- 356
- GEMEINSCHAFTSZUGANGSPUNKT-S.S.
-
- SOFTWAREPRODUKT
- 310
- EREIGNISBUS
-
12
- 1202
- EREIGNIS
ZUM GRUPPEN-SUBSYSTEM SENDEN GRUPPEN-SS
- 1204
- EREIGNIS
ZU SUBSYSTEM DES PERSISTENTEN SPEICHERS SENDEN
- 1206
- LIZENZ-INFO
ZURÜCKGEBEN
- 1208
- LIZENZ-INFO
ZURÜCKGEBEN
- 1210
- VERFÜGBARE LIZENZEN
BERECHNEN
- 1212
- LIZENZ-INFO
SPEICHERN
-
13
-
- LIZ.-SS
-
- SS
DYNAMISCHER SPEICHER
- 1302
- LIZENZANFORDERUNG
EMPFANGEN
- 1306
- GEWÄHRUNGSEREIGNIS
SENDEN
- 1304
- BEREITS
LIZENSIERT?
- YES
- JA
- NO
- NEIN
- 1308
- LOKALE
(ZUGEWIESENE) LIZENZEN VERFÜGBAR?
- 1310
- EREIGNIS
ZU DYNAMISCHEM SPEICHERMODUL SENDEN
- 1312
- DYNAMISCHEN
SPEICHER PRÜFEN
-
- OBJ.
IN DS?
- 1314
- ANTWORT
- 1316
- UM
GEPOOLTE LIZENZ ERSUCHENDES EREIGNIS SENDEN
- 1318
- ANZ.
BENUTZTER LIZENZEN ZURÜCKGEBEN
- 1322
- ERGEBNIS „FEHLGESCHLAGEN" ZURÜCKGEBEN
- 1320
- GEPOOLTE
LIZENZ VERFÜGBAR?
- 1324
- ZUWEISUNGSEREIGNIS
SENDEN
- 1326
- EINTRAG
IN DYNAMISCHEN SPEICHER VORNEHMEN
-
- ZU 1306
-
14A
- 1414
- TERM.-SERV.
- 1422
- GEMEINSCHAFTSANWENDUNGS-CLIENT
- 1400
- BENUTZER-VERWALTUNGS-SUBSYSTEM
- 645
- GEMEINSCHAFTSZUGANGSPUNKT-SUBSYSTEM
(CAP)
- 1416
- SPEZIALISIERTES
ANWENDUNGS-SUBSYSTEM
- 1408
- KONTO-AUTHORITÄTS-VERWALTUNGS-SUBSYSTEM
(AAM)
- 1404
- KONTO-AUTHORITÄTS-ZUGANGSTREIBER-SUBSYSTEM
(AAAD)
- 1440
- KONTO-AUTHORITAT
- 7
- DOMÄNENNAMEN-KONTO-NAME
(BESONDERER NAME)
-
- ERGEBNIS
-
- BESONDERER
NAME
- 310
- EREIGNISBUS
-
14B
- 1422'
- CAP-CLIENT
- 1440'
- UNIX-KONTO-AUTHORITÄT
- 180'
- (UNIX-SERVER)
- 180
- (NT-SERVER)
- 1440
- KONTO-AUTHORITÄT
- 1440''
- KONTO-AUTHORITÄT (AD)
- 720
- ICA-BROWSER-SUBSYSTEM
- 645'
- GEMEINSCHAFTSZUGANGSPUNKT-SUBSYSTEM
- 760'
- PROGRAMMNACHBARSCHAFTS-SUBSYSTEM
- 1408'
- KONTO-AUTHORITÄTS-VERWALTUNGS-SUBSYSTEM
AAM
- 1404'
- KONTO-AUTHORITÄTS-ZUGANGSTREIBER
- 352'
- SUBSYSTEM
DES PERSISTENTEN SPEICHERS
- 318
- TRANSPORTSCHICHT
-
- KONTO-AUTHORITÄTS-VERWALTUNG
-
- KONTO-AUTHORITÄTS-ZUGANGSTREIBER
(NT)
- 1404''
- KONTO-AUTHORITÄTS-ZUGANGSTREIBER
(ACTIVE DIRECTORY)
- 318'
- TRANSPORTSCHICHT
-
15
- 180
- SERVER
- 120
- CLIENT
- 720
- ICA-BROWSER-SS
-
- GEMEINSCHAFTSANWENDUNGS-SS
-
- SPEZIALISIERTES
SERVER-SS
-
- SS-MODUL 356 DES
DYNAMISCHEN SPEICHERS
- 1502
- ANWENDUNG
STARTEN
- 1504
- ANFORDERUNG
EINER ANWENDUNGSNAMENAUFLÖSUNG
SENDEN
- 1506
- ANFORDERUNG
WEITERLEITEN
- 1508
- NACH
ABGETRENNTEN SITZUNGEN ABFRAGEN
- 1510
- DYNAMISCHEN
SPEICHER DURCHSUCHEN
- 1512
- ERFOLG
ODER FEHLSCHLAG BEI DER SUCHE NACH ABGETRENNTEN SITZUNGEN EMPFANGEN
- 1514
- ADR.
DES HOSTS FÜR
DIE VERBINDUNG MIT DEM ABGETRENNTEN SERVER AUFLÖSEN
- 1316
- ADR.
AN CLIENT ZURÜCKGEBEN
- 1518
- UNTER
VERWENDUNG DER ADRESSE MIT ABGETRENNTEN SERVER VERBINDEN
-
16
- 1602
- MIT
SERVER IN FARM VERBINDEN
- 1604
- IN
SERVER-FARM EINLOGGEN (LOGON-EREIGNIS AUFGEBEN)
- 1606
- NACH
LISTE VON SERVERN IN FARM ABFRAGEN
- 1608
- PLUG-INS
DES ADMINISTRATIONSWERKZEUGS AUFLÖSEN
- 1610
- VERGLEICH
ADMINISTRATIONSWERKZEUG-PLUG-INS M. SUBSYSTEMEN DER SERVER
- 1612
- INSTALLIERT
GEGEBENENFALLS NEUE ADMINISTRATIONSWERKZEUG-PLUG-INS
- 1614
- ADMINISTRATIONSWERKZEUG-PLUG-INS
LADEN UND INITIALISIEREN
- 1616
- OBJEKTE
DER SERVER-FARM LADEN
- 1618
- OBJEKTINFORMATIONEN
ANZEIGEN
-
17
-
- Citrix-Administrationswerkzeug-JasonFarm3-9
-
- Aktionen
-
- Ansicht
-
- Hilfe
-
- Anwendungen
Citrix
-
- Administratoren
-
- Lizenzen
-
- Drucker
-
- Server
-
- ICA-Browser
-
- Lizenzen
-
- Dateitransfer
-
- Allgemeine
Konfiguration
-
- Kollektorpunkt-Server
antworten auf Client-Rundsendenachrichten
-
- RAS-Server
antworten auf Client-Rundsendenachricht
-
- Anwendung
-
- Mit
Prä-MetaFrame
2.0 kompatible Anwendungs-IDs benutzen
-
- Eindeutige
Anwendungs-IDs erzeugen
-
- Anwenden
-
- Zurücksetzen
-
- Hilfe
-
18
-
- Citrix-Administrationswerkzeug-JasonFarm3-9
-
- Aktionen
-
- Ansicht
-
- Hilfe
-
- Anwendungen
Citrix
-
- Administratoren
-
- Lizenzen
-
- Drucker
-
- Server
-
- Lizenzzeichenketten
-
- Lizenzzuweisungen
-
- Beschreibung
-
- Status
-
- Lizenzzeichenketten
-
- Zählwert
-
- Gratis-Tage
-
- MetaFrame
2.0 für
TSE
-
- Nichtaktiviert
-
- Gesamt-Lizenzen
in allen Gruppen-11
-
- Hilfe
-
19
-
- Citrix-Administrationswerkzeug-JasonFarm3-9
-
- ICA-Datei
erzeugen
-
- HTML-Datei
erzeugen
-
- Publizierte
Anwendung löschen
-
- Aktionen
-
- Ansicht
-
- Hilfe
-
- Anwendungen
-
- Citrix-Administration
-
- Lizenzen
-
- Drucker
-
- Server
-
- Anwendungseinstellungen
-
- Client-Einstellungen
-
- Aussehen
der Anwendung
-
- Client-Anforderungen
-
- Server
-
- Benutzer
-
- Diese
Server sind dafür
konfiguriert, diese Anwendung zu hosten
-
- Konfigurierte
Server
-
- Eigenschaften
-
- Hilfe
-
20
-
- Citrix-Administrationswerkzeug-JasonFarm3–9
-
- Aktionen
-
- Ansicht
-
- Hilfe
-
- Anwendungen
-
- Citrix-Administratoren
-
- Lizenzen
-
- Drucker
-
- Server
-
- Publizierte
Anwendungen
-
- Lizenzen
-
- Einstellungen
-
- Drucker
-
- Druck-Treiber
-
- Benutzer
-
- Sitzungen
-
- Prozesse
-
- Informationen
-
- Hot-Fixes
-
- Windows-NT-Informationen
-
- Installationsdatum,
Neue Logons
-
- 31.12.1969,
gesperrt
-
- Citrix-MetaFrame-Informationen
-
- Installationsdatum
-
- Netzwerk-Informationen
-
- TCP-Adresse
-
- IPX-Adresse
-
- NetBIOS-Adresse
-
- Eigenschaften
-
- Hilfe