DE60133648T2 - System und verfahren zum führen von laufzeitdaten in einem server-netzwerk - Google Patents

System und verfahren zum führen von laufzeitdaten in einem server-netzwerk Download PDF

Info

Publication number
DE60133648T2
DE60133648T2 DE60133648T DE60133648T DE60133648T2 DE 60133648 T2 DE60133648 T2 DE 60133648T2 DE 60133648 T DE60133648 T DE 60133648T DE 60133648 T DE60133648 T DE 60133648T DE 60133648 T2 DE60133648 T2 DE 60133648T2
Authority
DE
Germany
Prior art keywords
server
subsystem
event
data
zone
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE60133648T
Other languages
English (en)
Other versions
DE60133648D1 (de
Inventor
Thomas D. South Jordan FREEMAN
Bradley Jay Parkland PEDERSEN
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Citrix Systems Inc
Original Assignee
Citrix Systems Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Citrix Systems Inc filed Critical Citrix Systems Inc
Priority claimed from PCT/US2001/014319 external-priority patent/WO2001086414A2/en
Publication of DE60133648D1 publication Critical patent/DE60133648D1/de
Application granted granted Critical
Publication of DE60133648T2 publication Critical patent/DE60133648T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1008—Server selection for load balancing based on parameters of servers, e.g. available memory or workload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/101—Server selection for load balancing based on network conditions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1021—Server selection for load balancing based on client or server locations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1027—Persistence of sessions during load balancing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1034—Reaction to server failures by a load balancer
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/508—Monitor

Description

  • 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

Claims (39)

  1. Verfahren zum Verwalten von Laufzeitdaten in einem Computernetzwerk, das mehrere Server (180) in einer Server-Farm (110) enthält, wobei die Server-Farm eine als eine einzige Entität administrierte logische Gruppe von Servern umfaßt, wobei das Verfahren die folgenden Schritte umfaßt: Definieren einer ersten Zone (260), die eine erste Teilmenge (180', 180'', 180''') der mehreren Server enthält, wobei jeder Server ein Zonenmanager-Subsystem (358) aufweist; Identifizieren eines der Zonenmanager-Subsysteme (358) als einen Zonenmanager-Master; der Zonenmanager-Master bestimmt einen Server (180') in der ersten Teilmenge (180', 180'', 180''') 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.
  2. Verfahren nach Anspruch 1, bei dem der Zonenmanager-Master ferner bestimmt, daß der erste Kollektorpunkt nicht verfügbar ist, und einen neuen Kollektorpunkt auswählt, um den nicht verfügbaren ersten Kollektorpunkt zu ersetzen.
  3. Verfahren nach Anspruch 1, bei dem ferner der Zonenmanager-Master einen Server in der Server-Farm als einen ersten Netzwerkserver zum Bereitstellen eines ersten Netzwerkdienstes zuweist.
  4. Verfahren nach Anspruch 1, bei dem ferner ein Zonenmanager-Subsystem (358) 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.
  5. Verfahren nach Anspruch 1, bei dem ferner der Zonenmanager-Master einen Server (180') in der Server-Farm auf der Basis physischer Kenngrößen als den ersten Kollektorpunkt bestimmt.
  6. Verfahren nach Anspruch 5, wobei die physischen Kenngrößen verfügbarer Speicher oder Nähe zu einem die Daten des ersten Typs anfordernden Server sind.
  7. Verfahren nach Anspruch 1, ferner mit dem Schritt des Sendens einer Wahlanforderung für einen neuen Zonenmanager-Master für die erste Zone (260) durch das Zonenmanager-Subsystem (358) auf einem sendenden Server in der ersten Teilmenge von Servern.
  8. Verfahren nach Anspruch 7, wobei der sendende Server der erste Kollektorpunkt (180') ist.
  9. Verfahren nach Anspruch 7, ferner mit dem Schritt des Empfangens der Wahlanforderung durch einen empfangenden Server in der ersten Teilmenge von Servern in der ersten Zone.
  10. Verfahren nach Anspruch 9, wobei der empfangende Server der erste Kollektorpunkt (180') ist.
  11. Verfahren nach Anspruch 10, ferner mit dem Schritt des Vergleichens eines Wahlkriteriums zwischen dem sendenden Server und dem empfangenden Server, um den neuen Zonenmanager-Master der ersten Zone zu bestimmen.
  12. Verfahren nach Anspruch 11, wobei das Wahlkriterium ferner umfaßt, ob das Zonenmanager-Subsystem jedes Servers in der ersten Teilmenge von Servern als ein Zonenmanager-Master konfiguriert ist.
  13. Verfahren nach Anspruch 11, wobei das Wahlkriterium ferner umfaßt, ob der empfangende Server der am längsten laufende Server ist.
  14. Verfahren nach Anspruch 11, wobei das Wahlkriterium ferner umfaßt, ob das Zonenmanager-Subsystem (358) auf dem empfangenden Server einen lexikalisch niedrigeren Netzwerknamen aufweist.
  15. Computernetzwerk, umfassend: eine Server-Farm (110), die mehrere verbundene Server enthält, wobei die Server-Farm eine als eine einzige Entität administrierte logische Gruppe von Servern (180) umfaßt; einen Definierer, der eine Zone (260) definiert, die eine erste Teilmenge (180', 180'', 180''') der mehreren Server enthält, wobei jeder Server (180) ein Zonenmanager-Subsystem (358) aufweist, und wobei eines der Zonenmanager-Subsysteme (358) als Zonenmanager-Master identifiziert wird; der Zonenmanager-Master bestimmt einen Server in der ersten Teilmenge (180', 180'', 180''') als einen ersten Kollektorpunkt (180') 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.
  16. Vorrichtung nach Anspruch 15, bei der ferner der Zonenmanager-Master einen ersten Netzwerkserver zum Bereitstellen eines ersten Netzwerkdienstes zuweist.
  17. Verfahren nach Anspruch 1, bei dem ferner der Zonenmanager-Master einen Server in der Server-Farm als einen Netzwerkdienstserver zum Bereitstellen eines ersten Netzwerkdienstes bestimmt.
  18. Verfahren nach Anspruch 1, bei dem ferner der Zonenmanager-Master einen Server in der Server-Farm als einen dritten Kollektorpunkt (180) zum Sammeln von Daten des ersten Typs bestimmt.
  19. Verfahren nach Anspruch 18, ferner mit dem Schritt des Definierens einer zweiten Zone (270), die den dritten Kollektorpunkt (180) aufweist.
  20. Verfahren nach Anspruch 18, ferner mit dem Schritt des Leitens von Übermittlungen mit dem dritten Kollektorpunkt (180).
  21. Verfahren nach Anspruch 1, ferner mit den folgenden Schritten: Bestimmen eines zweiten Servers in der Server-Farm als einen weiteren Kollektorpunkt (180) zum Sammeln von Daten des ersten Typs; und Zuweisen einer ersten Teilmenge (180', 180'', 180''') der mehreren Server in der Server-Farm zum Senden von Daten des ersten Typs zu dem ersten Kollektorpunkt (180') und einer zweiten Teilmenge (180) der mehreren Server in der Server-Farm zum Senden von Daten des ersten Typs zu dem weiteren Kollektorpunkt (180).
  22. Verfahren nach Anspruch 21, ferner mit den folgenden Schritten: Definieren einer zweiten Zone (270), die eine zweite Teilmenge (180) der mehreren Server enthält, wobei die zweite Teilmenge den weiteren Kollektorpunkt (180) enthält; und logisches Zuweisen der ersten Teilmenge von Servern (180', 180'', 180''') in der ersten Zone (260) und der zweiten Teilmenge von Servern (180) in der zweiten Zone (270).
  23. Verfahren nach Anspruch 21, ferner mit dem Schritt des Bestimmens eines der Server in der ersten Zone (260), 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.
  24. Verfahren nach Anspruch 21, ferner mit dem Schritt des Bestimmens des ersten oder des weiteren Kollektorpunkts ebenfalls zum Sammeln von Daten eines zweiten Typs.
  25. Verfahren nach Anspruch 21, ferner mit dem Schritt des Definierens mindestens der ersten Teilmenge (180', 180'', 180''') und/oder der zweiten Teilmenge (180) auf der Basis geographischer Standorte der Server in der Server-Farm.
  26. Verfahren nach Anspruch 21, ferner mit dem Schritt des Kommunizierens mit dem ersten oder dem weiteren Kollektorpunkt beim Anfordern von Daten des ersten Typs.
  27. Verfahren nach Anspruch 21, ferner mit dem Schritt des Kommunizierens mit dem ersten oder dem weiteren Kollektorpunkt beim Speichern von Daten des ersten Typs.
  28. Verfahren nach Anspruch 21, wobei das Bestimmen mindestens eines der Server als ein Kollektorpunkt gemäß einem Kriterium erfolgt.
  29. Verfahren nach Anspruch 28, wobei das Bestimmen auf einer Boot-Reihenfolge der Server in der Server-Farm basiert.
  30. Verfahren nach Anspruch 21, ferner mit dem Schritt des Bestimmens, daß einer der Kollektorpunkte nicht verfügbar ist, und des Auswählens eines anderen Kollektorpunkts, um den nicht verfügbaren Kollektorpunkt zu ersetzen.
  31. Verfahren nach Anspruch 21, wobei die Daten des ersten Typs Serverstatusinformationen sind.
  32. Verfahren nach Anspruch 21, wobei die Daten des ersten Typs Client-Sitzungsdaten sind.
  33. Verfahren nach Anspruch 21, wobei die Daten des ersten Typs Lizenzierungsinformationen sind.
  34. Verfahren nach Anspruch 21, wobei die Daten des ersten Typs Ladeinformationen sind.
  35. Verfahren nach Anspruch 21, wobei die Daten des ersten Typs ein aktuelles Arbeitslastniveau jedes Servers in den mehreren Servern in der Server-Farm sind.
  36. Verfahren nach Anspruch 23, ferner mit dem Schritt des Bestimmens eines der Server (180) in der zweiten Zone (270) als einen Kollektorpunkt zum Sammeln von Daten des ersten Typs.
  37. Verfahren nach Anspruch 36, ferner mit dem Schritt des Sendens von Daten des ersten Typs zu der zweiten Zone.
  38. Verfahren nach Anspruch 22, ferner mit den folgenden Schritten: Senden von Daten von einem der ersten Zone (260) zugewiesenen Server zu dem ersten Kollektorpunkt (180'); Senden der Daten von dem ersten Kollektorpunkt (180') zu dem weiteren Kollektorpunkt (180); und Senden der Daten von dem weiteren Kollektorpunkt (180) zu jedem der zweiten Zone (270) zugewiesenen Server.
  39. Verfahren nach Anspruch 38, wobei sich der erste und der zweite Kollektorpunkt in derselben Zone befinden.
DE60133648T 2000-05-08 2001-05-03 System und verfahren zum führen von laufzeitdaten in einem server-netzwerk Expired - Lifetime DE60133648T2 (de)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US09/567,450 US6785713B1 (en) 2000-05-08 2000-05-08 Method and apparatus for communicating among a network of servers utilizing a transport mechanism
US567450 2000-05-08
US767774 2001-01-23
US09/768,110 US6826606B2 (en) 2000-05-08 2001-01-23 Method and apparatus for communicating among a network of servers
US768110 2001-01-23
US09/767,774 US6807580B2 (en) 2000-05-08 2001-01-23 Method and apparatus for communicating among a network of servers
PCT/US2001/014319 WO2001086414A2 (en) 2000-05-08 2001-05-03 A system and method for directing runtime data in a server network

Publications (2)

Publication Number Publication Date
DE60133648D1 DE60133648D1 (de) 2008-05-29
DE60133648T2 true DE60133648T2 (de) 2009-05-28

Family

ID=24267202

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60133648T Expired - Lifetime DE60133648T2 (de) 2000-05-08 2001-05-03 System und verfahren zum führen von laufzeitdaten in einem server-netzwerk

Country Status (4)

Country Link
US (3) US6785713B1 (de)
EP (1) EP2034406A1 (de)
DE (1) DE60133648T2 (de)
HK (1) HK1054604B (de)

Families Citing this family (362)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7228300B2 (en) * 1998-10-05 2007-06-05 Oracle International Corporation Caching the results of security policy functions
US7251826B1 (en) 1999-06-07 2007-07-31 Register.Com, Inc. Domain manager for plural domains and method of use
US6880007B1 (en) * 1999-06-07 2005-04-12 Register Com, Inc. Domain manager and method of use
AU2001253613A1 (en) 2000-04-17 2001-10-30 Circadence Corporation System and method for shifting functionality between multiple web servers
US20110128972A1 (en) 2000-04-17 2011-06-02 Randy Thornton Peer to peer dynamic network link acceleration
US8996705B2 (en) 2000-04-17 2015-03-31 Circadence Corporation Optimization of enhanced network links
US7680912B1 (en) * 2000-05-18 2010-03-16 thePlatform, Inc. System and method for managing and provisioning streamed data
ATE403323T1 (de) * 2000-05-24 2008-08-15 Voltaire Ltd Gefilterte kommunikation von anwendung zu anwendung
JP3561211B2 (ja) * 2000-06-27 2004-09-02 株式会社東芝 情報処理装置および不揮発性記憶装置の書き換え制御方法
JP4973899B2 (ja) 2000-07-06 2012-07-11 ソニー株式会社 送信装置、送信方法、受信装置、受信方法、記録媒体、および通信システム
US7117239B1 (en) 2000-07-28 2006-10-03 Axeda Corporation Reporting the state of an apparatus to a remote computer
US8108543B2 (en) 2000-09-22 2012-01-31 Axeda Corporation Retrieving data from a server
US7185014B1 (en) 2000-09-22 2007-02-27 Axeda Corporation Retrieving data from a server
US20020083163A1 (en) * 2000-10-26 2002-06-27 Metilinx Multi-platform optimization model
US7379994B2 (en) * 2000-10-26 2008-05-27 Metilinx Aggregate system resource analysis including correlation matrix and metric-based analysis
US7111059B1 (en) * 2000-11-10 2006-09-19 Microsoft Corporation System for gathering and aggregating operational metrics
US20040139145A1 (en) * 2000-12-21 2004-07-15 Bar-Or Gigy Method and apparatus for scalable distributed storage
US8095624B2 (en) * 2000-12-28 2012-01-10 CenterBeam Inc. Architecture for serving and managing independent access devices
US7174534B2 (en) * 2001-01-22 2007-02-06 Symbol Technologies, Inc. Efficient system and method for running and analyzing multi-channel, multi-modal applications
US20020147784A1 (en) * 2001-04-06 2002-10-10 Stephen Gold User account handling on aggregated group of multiple headless computer entities
US7035919B1 (en) * 2001-03-21 2006-04-25 Unisys Corporation Method for calculating user weights for thin client sizing tool
US7089309B2 (en) 2001-03-21 2006-08-08 Theplatform For Media, Inc. Method and system for managing and distributing digital media
US8095687B1 (en) * 2001-03-26 2012-01-10 Microsoft Corporation Systems and methods for managing state in a cluster of servers
EP1374476B1 (de) * 2001-03-29 2015-07-22 Panasonic Corporation Datenschutzsystem, das daten durch verschlüsselung schützt
US20020143857A1 (en) * 2001-03-30 2002-10-03 Bidarahalli Phani Kumar Method and system for event communication on a distributed scanner/workstation platform
US7120896B2 (en) * 2001-10-31 2006-10-10 Vitria Technology, Inc. Integrated business process modeling environment and models created thereby
JP3409117B2 (ja) * 2001-03-30 2003-05-26 オムロン株式会社 光学式反射形センサ
CA2349086C (en) * 2001-05-30 2011-02-01 Ibm Canada Limited-Ibm Canada Limitee Selection and configuration of servers
US7801967B1 (en) * 2001-06-19 2010-09-21 Microstrategy, Incorporated Method and system for implementing database connection mapping for reporting systems
US8086738B2 (en) * 2007-05-24 2011-12-27 Russell Fish Distributed means of organizing an arbitrarily large number of computers
US7409420B2 (en) * 2001-07-16 2008-08-05 Bea Systems, Inc. Method and apparatus for session replication and failover
US7702791B2 (en) * 2001-07-16 2010-04-20 Bea Systems, Inc. Hardware load-balancing apparatus for session replication
US7774492B2 (en) 2001-07-26 2010-08-10 Citrix Systems, Inc. System, method and computer program product to maximize server throughput while avoiding server overload by controlling the rate of establishing server-side net work connections
US7406524B2 (en) * 2001-07-26 2008-07-29 Avaya Communication Isael Ltd. Secret session supporting load balancer
JP2003051853A (ja) * 2001-08-07 2003-02-21 Matsushita Electric Ind Co Ltd 通信方法及び通信装置
US7219103B2 (en) * 2001-08-21 2007-05-15 Dell Products L.P. System and method for data replication in a computer system
US7856660B2 (en) 2001-08-21 2010-12-21 Telecommunication Systems, Inc. System for efficiently handling cryptographic messages containing nonce values
US7203719B2 (en) * 2001-08-22 2007-04-10 International Business Machines Corporation Method and system to measure distributed system's relative size
US7277945B1 (en) 2001-09-12 2007-10-02 Cisco Technology, Inc. System and method for maintaining seamless session operation
US7167918B2 (en) * 2001-10-29 2007-01-23 Sun Microsystems, Inc. Macro-based access control
US20030093562A1 (en) * 2001-11-13 2003-05-15 Padala Chandrashekar R. Efficient peer to peer discovery
US7418484B2 (en) * 2001-11-30 2008-08-26 Oracle International Corporation System and method for actively managing an enterprise of configurable components
US7039671B2 (en) * 2001-11-30 2006-05-02 Sonic Software Corporation Dynamically routing messages between software application programs using named routing nodes and named message queues
US7069448B2 (en) * 2001-12-05 2006-06-27 Tecsec, Inc. Context oriented crypto processing on a parallel processor array
US20050080682A1 (en) * 2001-12-10 2005-04-14 Eric Wilson System for secure distribution of electronic content and collection of fees
US8122118B2 (en) * 2001-12-14 2012-02-21 International Business Machines Corporation Selection of communication protocol for message transfer based on quality of service requirements
US7227864B2 (en) * 2001-12-17 2007-06-05 Microsoft Corporation Methods and systems for establishing communications through firewalls and network address translators
US7254601B2 (en) 2001-12-20 2007-08-07 Questra Corporation Method and apparatus for managing intelligent assets in a distributed environment
US20030126196A1 (en) * 2001-12-27 2003-07-03 Todd Lagimonier System for optimizing the invocation of computer-based services deployed in a distributed computing environment
JP4039195B2 (ja) * 2001-12-27 2008-01-30 富士ゼロックス株式会社 ネットワークシステム
US7181489B2 (en) * 2002-01-10 2007-02-20 International Business Machines Corporation Method, apparatus, and program for distributing a document object model in a web server cluster
US7219231B2 (en) * 2002-01-30 2007-05-15 Hewlett-Packard Development Company, L.P. Extensible authentication system and method
EP1470466B1 (de) 2002-02-01 2016-11-09 Panasonic Intellectual Property Corporation of America Lizenzinformationsaustauschsystem
US20030158942A1 (en) * 2002-02-15 2003-08-21 Exanet, Inc. Real-time reconfiguration of computer networks based on system measurements
US7403996B2 (en) * 2002-02-21 2008-07-22 Bea Systems, Inc. Systems and methods for migratable services
FR2836731B1 (fr) * 2002-03-01 2004-12-03 Abdulai Danso Procede pour la realisation et la mise en oeuvre d'un systeme de communication multifonctionnel et systeme obtenu conformement audit procede
US7373424B2 (en) * 2002-03-28 2008-05-13 Sap Ag Exactly once protocol for message-based collaboration
US20030184581A1 (en) * 2002-04-02 2003-10-02 Bawa Satvinder Singh Application level integration in support of a distributed network management and service provisioning solution
US7945652B2 (en) * 2002-08-06 2011-05-17 Sheng (Ted) Tai Tsao Display multi-layers list item in web-browser with supporting of concurrent multi-users
US7178149B2 (en) 2002-04-17 2007-02-13 Axeda Corporation XML scripting of soap commands
US7747730B1 (en) 2002-06-28 2010-06-29 Netfuel, Inc. Managing computer network resources
US7885896B2 (en) 2002-07-09 2011-02-08 Avaya Inc. Method for authorizing a substitute software license server
US8041642B2 (en) 2002-07-10 2011-10-18 Avaya Inc. Predictive software license balancing
US7512585B2 (en) 2002-07-11 2009-03-31 Oracle International Corporation Support for multiple mechanisms for accessing data stores
US7428523B2 (en) 2002-07-11 2008-09-23 Oracle International Corporation Portal bridge
US7206851B2 (en) 2002-07-11 2007-04-17 Oracle International Corporation Identifying dynamic groups
US7467142B2 (en) 2002-07-11 2008-12-16 Oracle International Corporation Rule based data management
US7447701B2 (en) * 2002-07-11 2008-11-04 Oracle International Corporation Automatic configuration of attribute sets
US7428592B2 (en) * 2002-07-11 2008-09-23 Oracle International Corporation Securely persisting network resource identifiers
US8375113B2 (en) 2002-07-11 2013-02-12 Oracle International Corporation Employing wrapper profiles
US7478407B2 (en) * 2002-07-11 2009-01-13 Oracle International Corporation Supporting multiple application program interfaces
US7000221B2 (en) * 2002-07-31 2006-02-14 International Business Machines Corporation Script evaluator
US8812640B2 (en) * 2002-08-06 2014-08-19 Sheng Tai (Ted) Tsao Method and system for providing multi-layers item list in browsers with supporting of concurrent multiple users
US20120079389A1 (en) * 2002-08-06 2012-03-29 Tsao Sheng Tai Ted Method and Apparatus For Information Exchange Over a Web Based Environment
US7216363B2 (en) 2002-08-30 2007-05-08 Avaya Technology Corp. Licensing duplicated systems
US7681245B2 (en) 2002-08-30 2010-03-16 Avaya Inc. Remote feature activator feature extraction
US7228567B2 (en) 2002-08-30 2007-06-05 Avaya Technology Corp. License file serial number tracking
US7698225B2 (en) * 2002-08-30 2010-04-13 Avaya Inc. License modes in call processing
US7966520B2 (en) 2002-08-30 2011-06-21 Avaya Inc. Software licensing for spare processors
US7707116B2 (en) 2002-08-30 2010-04-27 Avaya Inc. Flexible license file feature controls
US7349965B1 (en) * 2002-09-13 2008-03-25 Hewlett-Packard Development Company, L.P. Automated advertising and matching of data center resource capabilities
US7542471B2 (en) 2002-10-30 2009-06-02 Citrix Systems, Inc. Method of determining path maximum transmission unit
US8270423B2 (en) 2003-07-29 2012-09-18 Citrix Systems, Inc. Systems and methods of using packet boundaries for reduction in timeout prevention
US7630305B2 (en) 2003-07-29 2009-12-08 Orbital Data Corporation TCP selective acknowledgements for communicating delivered and missed data packets
US7616638B2 (en) 2003-07-29 2009-11-10 Orbital Data Corporation Wavefront detection and disambiguation of acknowledgments
US8233392B2 (en) 2003-07-29 2012-07-31 Citrix Systems, Inc. Transaction boundary detection for reduction in timeout penalties
US20040088563A1 (en) * 2002-11-01 2004-05-06 Hogan Dirk J. Computer access authorization
KR100494558B1 (ko) * 2002-11-13 2005-06-13 주식회사 케이티 공중 무선랜 서비스 시스템의 사용자 인증방법 및 시스템
US20040117350A1 (en) * 2002-12-12 2004-06-17 International Business Machines Corporation Apparatus and method for optimizing schema definitions for an LDAP directory
US7890997B2 (en) 2002-12-26 2011-02-15 Avaya Inc. Remote feature activation authentication file system
US7421492B1 (en) * 2003-01-24 2008-09-02 Unisys Corporation Control arrangement for operating multiple computer systems
US20040145605A1 (en) * 2003-01-28 2004-07-29 Sujoy Basu Access method and system for remote desktops
JP2004234555A (ja) 2003-01-31 2004-08-19 Hitachi Ltd ストレージシステムの制御方法、ストレージシステム、及びプログラム
JP4342804B2 (ja) * 2003-01-31 2009-10-14 株式会社日立製作所 ストレージシステムの制御方法、ストレージシステム、及びプログラム
JP2004234558A (ja) * 2003-01-31 2004-08-19 Hitachi Ltd 記憶デバイス制御装置、及びプログラム
US7103762B2 (en) * 2003-01-31 2006-09-05 International Business Machines Corporation Using a cache and data transfer methodology to control real-time process data in a PXE pre-boot manufacturing environment
US20040158637A1 (en) * 2003-02-12 2004-08-12 Lee Timothy Charles Gated-pull load balancer
US7966418B2 (en) 2003-02-21 2011-06-21 Axeda Corporation Establishing a virtual tunnel between two computer programs
US7370212B2 (en) 2003-02-25 2008-05-06 Microsoft Corporation Issuing a publisher use license off-line in a digital rights management (DRM) system
US7260557B2 (en) 2003-02-27 2007-08-21 Avaya Technology Corp. Method and apparatus for license distribution
US20040230679A1 (en) * 2003-02-28 2004-11-18 Bales Christopher E. Systems and methods for portal and web server administration
US7810036B2 (en) * 2003-02-28 2010-10-05 Bea Systems, Inc. Systems and methods for personalizing a portal
US7373657B2 (en) 2003-03-10 2008-05-13 Avaya Technology Corp. Method and apparatus for controlling data and software access
US7574406B2 (en) * 2003-03-31 2009-08-11 Satyam Computer Services Limited Of Mayfair Centre System and method maximizing video license utilization using billboard services
US20040215747A1 (en) * 2003-04-11 2004-10-28 Jonathan Maron System and method for a configuration repository
US7376671B2 (en) * 2003-04-15 2008-05-20 Bea Systems, Inc. Method for common management model for distributed server network
US7784047B2 (en) * 2003-04-15 2010-08-24 Bea Systems, Inc. Common management model for distributed server network
US7580976B2 (en) * 2003-04-18 2009-08-25 Microsoft Corporation Identifying an appropriate connection point for connecting to an application layer session
US20090299791A1 (en) * 2003-06-25 2009-12-03 Foundry Networks, Inc. Method and system for management of licenses
US20050027873A1 (en) * 2003-07-28 2005-02-03 Mayo Robert N. Directing client requests in an information system using client-side information
US7656799B2 (en) 2003-07-29 2010-02-02 Citrix Systems, Inc. Flow control system architecture
US8432800B2 (en) 2003-07-29 2013-04-30 Citrix Systems, Inc. Systems and methods for stochastic-based quality of service
US8437284B2 (en) 2003-07-29 2013-05-07 Citrix Systems, Inc. Systems and methods for additional retransmissions of dropped packets
US8238241B2 (en) 2003-07-29 2012-08-07 Citrix Systems, Inc. Automatic detection and window virtualization for flow control
KR100491541B1 (ko) * 2003-08-01 2005-05-25 니트젠테크놀러지스 주식회사 네트웍 환경에서의 컨텐츠 동기화 시스템 및 동기화 방법
US20050027657A1 (en) * 2003-08-01 2005-02-03 Yuri Leontiev Distinguishing legitimate hardware upgrades from unauthorized installations of software on additional computers
US8131803B2 (en) * 2003-08-19 2012-03-06 Research In Motion Limited System and method for integrating an address book with an instant messaging application in a mobile station
US7590643B2 (en) 2003-08-21 2009-09-15 Microsoft Corporation Systems and methods for extensions and inheritance for units of information manageable by a hardware/software interface system
US7401104B2 (en) 2003-08-21 2008-07-15 Microsoft Corporation Systems and methods for synchronizing computer systems through an intermediary file system share or device
US8166101B2 (en) 2003-08-21 2012-04-24 Microsoft Corporation Systems and methods for the implementation of a synchronization schemas for units of information manageable by a hardware/software interface system
US8238696B2 (en) 2003-08-21 2012-08-07 Microsoft Corporation Systems and methods for the implementation of a digital images schema for organizing units of information manageable by a hardware/software interface system
US20050080909A1 (en) * 2003-10-10 2005-04-14 Anatoliy Panasyuk Methods and apparatus for scalable secure remote desktop access
US7594018B2 (en) 2003-10-10 2009-09-22 Citrix Systems, Inc. Methods and apparatus for providing access to persistent application sessions
US7788480B2 (en) * 2003-11-05 2010-08-31 Cisco Technology, Inc. Protected dynamic provisioning of credentials
US8060619B1 (en) 2003-11-07 2011-11-15 Symantec Operating Corporation Direct connections to a plurality of storage object replicas in a computer network
US7978716B2 (en) 2003-11-24 2011-07-12 Citrix Systems, Inc. Systems and methods for providing a VPN solution
US7590713B2 (en) * 2003-11-24 2009-09-15 Microsoft Corporation Presenting a merged view of remote application shortcuts from multiple providers
US7720906B2 (en) * 2003-11-24 2010-05-18 Microsoft Corporation Web service for remote application discovery
US7873715B1 (en) * 2003-12-18 2011-01-18 Precise Software Solutions, Inc. Optimized instrumentation of web pages for performance management
US7562094B1 (en) 2003-12-31 2009-07-14 Precise Software Solutions, Inc. Object-level database performance management
US7353388B1 (en) 2004-02-09 2008-04-01 Avaya Technology Corp. Key server for securing IP telephony registration, control, and maintenance
US20050188295A1 (en) * 2004-02-25 2005-08-25 Loren Konkus Systems and methods for an extensible administration tool
US8224937B2 (en) * 2004-03-04 2012-07-17 International Business Machines Corporation Event ownership assigner with failover for multiple event server system
US7272500B1 (en) 2004-03-25 2007-09-18 Avaya Technology Corp. Global positioning system hardware key for software licenses
US8336040B2 (en) 2004-04-15 2012-12-18 Raytheon Company System and method for topology-aware job scheduling and backfilling in an HPC environment
US8335909B2 (en) * 2004-04-15 2012-12-18 Raytheon Company Coupling processors to each other for high performance computing (HPC)
US8190714B2 (en) * 2004-04-15 2012-05-29 Raytheon Company System and method for computer cluster virtualization using dynamic boot images and virtual disk
US20050235055A1 (en) * 2004-04-15 2005-10-20 Raytheon Company Graphical user interface for managing HPC clusters
US9178784B2 (en) * 2004-04-15 2015-11-03 Raytheon Company System and method for cluster management based on HPC architecture
US8060923B2 (en) 2004-04-23 2011-11-15 Microsoft Corporation Trusted license removal in a content protection system or the like
JP4500090B2 (ja) * 2004-04-22 2010-07-14 株式会社日立製作所 情報管理システムと情報管理方法
GB0409704D0 (en) * 2004-04-30 2004-06-02 Nokia Corp A method for verifying a first identity and a second identity of an entity
US8739274B2 (en) 2004-06-30 2014-05-27 Citrix Systems, Inc. Method and device for performing integrated caching in a data communication network
US7757074B2 (en) 2004-06-30 2010-07-13 Citrix Application Networking, Llc System and method for establishing a virtual private network
US8495305B2 (en) 2004-06-30 2013-07-23 Citrix Systems, Inc. Method and device for performing caching of dynamically generated objects in a data communication network
US8825832B2 (en) * 2004-07-21 2014-09-02 Hewlett-Packard Development Company, L.P. Method and system for managing connections
EP1771979B1 (de) 2004-07-23 2011-11-23 Citrix Systems, Inc. Verfahren und system zur sicherung von zugriff aus der ferne auf private netze
EP1771998B1 (de) 2004-07-23 2015-04-15 Citrix Systems, Inc. Systeme und verfahren zur kommunikationsoptimierung zwischen netzwerkknoten
US20060020555A1 (en) * 2004-07-26 2006-01-26 Septon Daven W Monitoring a license proxy
US7657657B2 (en) * 2004-08-13 2010-02-02 Citrix Systems, Inc. Method for maintaining transaction integrity across multiple remote access servers
US7849183B1 (en) 2004-08-31 2010-12-07 Precise Software Solutions, Inc. Method of monitoring network and application performance by analyzing web clients and web servers
US7603459B2 (en) * 2004-09-14 2009-10-13 International Business Machines Corporation System, method and program to troubleshoot a distributed computer system or determine application data flows
US7707405B1 (en) 2004-09-21 2010-04-27 Avaya Inc. Secure installation activation
US7965701B1 (en) 2004-09-30 2011-06-21 Avaya Inc. Method and system for secure communications with IP telephony appliance
US7747851B1 (en) 2004-09-30 2010-06-29 Avaya Inc. Certificate distribution via license files
US8229858B1 (en) 2004-09-30 2012-07-24 Avaya Inc. Generation of enterprise-wide licenses in a customer environment
US8347078B2 (en) 2004-10-18 2013-01-01 Microsoft Corporation Device certificate individualization
US7450128B2 (en) * 2004-11-15 2008-11-11 Hewlett-Packard Development Company, L.P. Systems and methods of providing image copy and modify commands to a receiver with an associated display
US8336085B2 (en) 2004-11-15 2012-12-18 Microsoft Corporation Tuning product policy using observed evidence of customer behavior
US8244882B2 (en) * 2004-11-17 2012-08-14 Raytheon Company On-demand instantiation in a high-performance computing (HPC) system
US7433931B2 (en) * 2004-11-17 2008-10-07 Raytheon Company Scheduling in a high-performance computing (HPC) system
US7487319B2 (en) * 2004-11-18 2009-02-03 International Business Machines Corporation Resource allocation unit queue
US8549149B2 (en) 2004-12-30 2013-10-01 Citrix Systems, Inc. Systems and methods for providing client-side accelerated access to remote applications via TCP multiplexing
US8954595B2 (en) 2004-12-30 2015-02-10 Citrix Systems, Inc. Systems and methods for providing client-side accelerated access to remote applications via TCP buffering
US8700695B2 (en) 2004-12-30 2014-04-15 Citrix Systems, Inc. Systems and methods for providing client-side accelerated access to remote applications via TCP pooling
US7810089B2 (en) 2004-12-30 2010-10-05 Citrix Systems, Inc. Systems and methods for automatic installation and execution of a client-side acceleration program
US8255456B2 (en) 2005-12-30 2012-08-28 Citrix Systems, Inc. System and method for performing flash caching of dynamically generated objects in a data communication network
JP5183214B2 (ja) 2005-01-24 2013-04-17 サイトリックス システムズ，インコーポレイテッド ネットワークにおいて動的に生成されたオブジェクトのキャッシングを実行するためのシステムおよび方法
US7257631B2 (en) 2005-01-31 2007-08-14 Register.Com, Inc. Domain manager and method of use
US7475281B2 (en) * 2005-03-10 2009-01-06 International Business Machines Corporation Method for synchronizing replicas of a database
US7624290B2 (en) * 2005-03-22 2009-11-24 Sony Corporation Power-save control for network master device
US8438645B2 (en) 2005-04-27 2013-05-07 Microsoft Corporation Secure clock with grace periods
US8725646B2 (en) 2005-04-15 2014-05-13 Microsoft Corporation Output protection levels
US9436804B2 (en) 2005-04-22 2016-09-06 Microsoft Technology Licensing, Llc Establishing a unique session key using a hardware functionality scan
US9363481B2 (en) 2005-04-22 2016-06-07 Microsoft Technology Licensing, Llc Protected media pipeline
JP4900891B2 (ja) 2005-04-27 2012-03-21 キヤノン株式会社 通信装置及び通信方法
US20060265758A1 (en) 2005-05-20 2006-11-23 Microsoft Corporation Extensible media rights
US7882176B2 (en) * 2005-05-27 2011-02-01 Microsoft Corporation Establishing a multiparty session by sending invitations in parallel
US7660850B2 (en) * 2005-05-27 2010-02-09 Microsoft Corporation Supporting a serial and a parallel invitation protocol
KR100717239B1 (ko) * 2005-06-22 2007-05-11 엔에이치엔(주) 동일한 멀티캐스트 그룹에 속하는 구성원 서버들 간의신뢰성 있는 통신을 제공하기 위한 방법 및 장치
US7747763B2 (en) * 2005-07-26 2010-06-29 Novell, Inc. System and method for ensuring a device uses the correct instance of a network service
US20140013449A1 (en) 2005-07-28 2014-01-09 Adobe Systems Incorporated Delayed validation for software licensing and activation
US7817849B2 (en) * 2005-08-18 2010-10-19 Hewlett-Packard Development Company, L.P. Method and apparatus for graphical data compression
US7434041B2 (en) * 2005-08-22 2008-10-07 Oracle International Corporation Infrastructure for verifying configuration and health of a multi-node computer system
US7814023B1 (en) 2005-09-08 2010-10-12 Avaya Inc. Secure download manager
JP2007102480A (ja) * 2005-10-04 2007-04-19 Fujitsu Ltd 通信制御プログラム、通信制御方法および通信制御装置
US7779157B2 (en) * 2005-10-28 2010-08-17 Yahoo! Inc. Recovering a blade in scalable software blade architecture
US7873696B2 (en) 2005-10-28 2011-01-18 Yahoo! Inc. Scalable software blade architecture
US7870288B2 (en) * 2005-10-28 2011-01-11 Yahoo! Inc. Sharing data in scalable software blade architecture
JP2007128331A (ja) * 2005-11-04 2007-05-24 Inter Net Inishiateibu:Kk ネットワーク接続機器の自動生成機構
US7702947B2 (en) * 2005-11-29 2010-04-20 Bea Systems, Inc. System and method for enabling site failover in an application server environment
TWI416901B (zh) * 2005-11-30 2013-11-21 Ibm 故障容忍之異動處理系統
US8805993B2 (en) * 2005-12-02 2014-08-12 At&T Intellectual Property I, L.P. System and method for bulk network data collection
US8301839B2 (en) 2005-12-30 2012-10-30 Citrix Systems, Inc. System and method for performing granular invalidation of cached dynamically generated objects in a data communication network
US7921184B2 (en) 2005-12-30 2011-04-05 Citrix Systems, Inc. System and method for performing flash crowd caching of dynamically generated objects in a data communication network
US7672269B2 (en) * 2006-02-14 2010-03-02 Motorola, Inc. Methods of distributing an installation program on a wireless link and supporting memory circuit and apparatus
US8122087B2 (en) * 2006-03-21 2012-02-21 Aol Inc. Matching engine for comparing data feeds with user profile criteria
US7904563B2 (en) * 2006-03-31 2011-03-08 Microsoft Corporation Establishing and utilizing terminal server dynamic virtual channels
US7801128B2 (en) 2006-03-31 2010-09-21 Amazon Technologies, Inc. Managing communications between computing nodes
US7792944B2 (en) * 2006-03-31 2010-09-07 Amazon Technologies, Inc. Executing programs based on user-specified constraints
US8190682B2 (en) * 2006-03-31 2012-05-29 Amazon Technologies, Inc. Managing execution of programs by multiple computing systems
US8370416B2 (en) * 2006-04-26 2013-02-05 Hewlett-Packard Development Company, L.P. Compatibility enforcement in clustered computing systems
US20070271315A1 (en) * 2006-05-02 2007-11-22 Mypoints.Com Inc. Robust silo based system architecture
US8612556B2 (en) 2006-05-03 2013-12-17 Comcast Cable Holdings, Llc Method of provisioning network elements
US8209405B1 (en) * 2006-06-12 2012-06-26 Juniper Networks, Inc. Failover scheme with service-based segregation
US8244883B2 (en) 2006-08-03 2012-08-14 Citrix Systems, Inc. Systems and methods of for providing multi-mode transport layer compression
US8116207B2 (en) 2006-08-21 2012-02-14 Citrix Systems, Inc. Systems and methods for weighted monitoring of network services
US8493858B2 (en) 2006-08-22 2013-07-23 Citrix Systems, Inc Systems and methods for providing dynamic connection spillover among virtual servers
US8312120B2 (en) 2006-08-22 2012-11-13 Citrix Systems, Inc. Systems and methods for providing dynamic spillover of virtual servers based on bandwidth
US20080077868A1 (en) * 2006-09-22 2008-03-27 Bartucca Francis M System and Method for Visually Representing Resource Usage in a Multi-Node Data Processing System
US8370479B2 (en) 2006-10-03 2013-02-05 Axeda Acquisition Corporation System and method for dynamically grouping devices based on present device conditions
US8065397B2 (en) 2006-12-26 2011-11-22 Axeda Acquisition Corporation Managing configurations of distributed devices
US8701010B2 (en) 2007-03-12 2014-04-15 Citrix Systems, Inc. Systems and methods of using the refresh button to determine freshness policy
US7584294B2 (en) 2007-03-12 2009-09-01 Citrix Systems, Inc. Systems and methods for prefetching objects for caching using QOS
US8037126B2 (en) 2007-03-12 2011-10-11 Citrix Systems, Inc. Systems and methods of dynamically checking freshness of cached objects based on link status
US7783757B2 (en) 2007-03-12 2010-08-24 Citrix Systems, Inc. Systems and methods of revalidating cached objects in parallel with request for object
US7809818B2 (en) 2007-03-12 2010-10-05 Citrix Systems, Inc. Systems and method of using HTTP head command for prefetching
US8504775B2 (en) 2007-03-12 2013-08-06 Citrix Systems, Inc Systems and methods of prefreshening cached objects based on user's current web page
US8103783B2 (en) 2007-03-12 2012-01-24 Citrix Systems, Inc. Systems and methods of providing security and reliability to proxy caches
US7720936B2 (en) 2007-03-12 2010-05-18 Citrix Systems, Inc. Systems and methods of freshening and prefreshening a DNS cache
US7706266B2 (en) 2007-03-12 2010-04-27 Citrix Systems, Inc. Systems and methods of providing proxy-based quality of service
US8307114B2 (en) * 2007-05-22 2012-11-06 International Business Machines Corporation High availability message transmission
US8127017B2 (en) * 2007-06-22 2012-02-28 Citrix Systems, Inc. Methods and servers for displaying and activating disconnected sessions
US8028090B2 (en) 2008-11-17 2011-09-27 Amazon Technologies, Inc. Request routing utilizing client location information
US7991910B2 (en) 2008-11-17 2011-08-02 Amazon Technologies, Inc. Updating routing information based on client location
TW200925984A (en) * 2007-12-04 2009-06-16 Sunplus Technology Co Ltd Screen adjustment method
US8051491B1 (en) * 2007-12-10 2011-11-01 Amazon Technologies, Inc. Controlling use of computing-related resources by multiple independent parties
US20110178619A1 (en) * 2007-12-21 2011-07-21 Searete Llc, A Limited Liability Corporation Of The State Of Delaware Security-activated robotic tasks
US7912986B2 (en) * 2008-02-25 2011-03-22 Simdesk Technologies Secure block read and write protocol for remotely stored files
US7885269B2 (en) * 2008-03-03 2011-02-08 Microsoft Corporation Network analysis with Steiner trees
US8321568B2 (en) 2008-03-31 2012-11-27 Amazon Technologies, Inc. Content management
US8447831B1 (en) 2008-03-31 2013-05-21 Amazon Technologies, Inc. Incentive driven content delivery
US8601090B1 (en) 2008-03-31 2013-12-03 Amazon Technologies, Inc. Network resource identification
US8606996B2 (en) 2008-03-31 2013-12-10 Amazon Technologies, Inc. Cache optimization
US7970820B1 (en) 2008-03-31 2011-06-28 Amazon Technologies, Inc. Locality based content distribution
US8156243B2 (en) 2008-03-31 2012-04-10 Amazon Technologies, Inc. Request routing
US8533293B1 (en) 2008-03-31 2013-09-10 Amazon Technologies, Inc. Client side cache management
US7962597B2 (en) 2008-03-31 2011-06-14 Amazon Technologies, Inc. Request routing based on class
US9146722B2 (en) * 2008-04-16 2015-09-29 International Business Machines Corporation Reinstalling a computer based on frequency of application utilization
US8202166B2 (en) * 2008-05-05 2012-06-19 Microsoft Corporation Multiple-player collaborative content editing
US7814140B2 (en) * 2008-06-19 2010-10-12 Unisys Corporation Method of monitoring and administrating distributed applications using access large information checking engine (ALICE)
US7836185B2 (en) * 2008-06-27 2010-11-16 International Business Machines Corporation Common resource management in a server cluster
US7925782B2 (en) 2008-06-30 2011-04-12 Amazon Technologies, Inc. Request routing using network computing components
US9912740B2 (en) 2008-06-30 2018-03-06 Amazon Technologies, Inc. Latency measurement in resource requests
US9407681B1 (en) 2010-09-28 2016-08-02 Amazon Technologies, Inc. Latency measurement in resource requests
TW201006175A (en) * 2008-07-31 2010-02-01 Ibm Method, apparatus, and computer program product for testing a network system
US7831682B2 (en) * 2008-08-08 2010-11-09 Amazon Technologies, Inc. Providing a reliable backing store for block data storage
US20100049694A1 (en) * 2008-08-20 2010-02-25 Ca, Inc. Method and system for extending a relational schema
US8954028B2 (en) * 2008-09-25 2015-02-10 Telecommunication Systems, Inc. Geo-redundant and high reliability commercial mobile alert system (CMAS)
US8239880B1 (en) * 2008-09-30 2012-08-07 Emc Corporation Orchestrating flow of event information to several event handling components
US8122098B1 (en) 2008-11-17 2012-02-21 Amazon Technologies, Inc. Managing content delivery network service providers by a content broker
US8060616B1 (en) 2008-11-17 2011-11-15 Amazon Technologies, Inc. Managing CDN registration by a storage provider
US8732309B1 (en) 2008-11-17 2014-05-20 Amazon Technologies, Inc. Request routing utilizing cost information
US8065417B1 (en) 2008-11-17 2011-11-22 Amazon Technologies, Inc. Service provider registration by a content broker
US8073940B1 (en) 2008-11-17 2011-12-06 Amazon Technologies, Inc. Managing content delivery network service providers
US8521880B1 (en) 2008-11-17 2013-08-27 Amazon Technologies, Inc. Managing content delivery network service providers
US8756341B1 (en) 2009-03-27 2014-06-17 Amazon Technologies, Inc. Request routing utilizing popularity information
US8412823B1 (en) 2009-03-27 2013-04-02 Amazon Technologies, Inc. Managing tracking information entries in resource cache components
US8688837B1 (en) 2009-03-27 2014-04-01 Amazon Technologies, Inc. Dynamically translating resource identifiers for request routing using popularity information
US8521851B1 (en) 2009-03-27 2013-08-27 Amazon Technologies, Inc. DNS query processing using resource identifiers specifying an application broker
US8782236B1 (en) 2009-06-16 2014-07-15 Amazon Technologies, Inc. Managing resources using resource expiration data
CN101583160B (zh) * 2009-06-19 2011-08-24 中兴通讯股份有限公司 一种实现分层服务质量业务的装置及方法
EP2446590B1 (de) 2009-06-22 2015-11-25 Citrix Systems, Inc. Systeme und verfahren zur begrenzung von plattformgeschwindigkeit
US20110035594A1 (en) * 2009-07-27 2011-02-10 Barbara Ann Fox Apparatus and method for providing elective message tagging
US8397073B1 (en) 2009-09-04 2013-03-12 Amazon Technologies, Inc. Managing secure content in a content delivery network
US20110072129A1 (en) * 2009-09-21 2011-03-24 At&T Intellectual Property I, L.P. Icmp proxy device
US8433771B1 (en) 2009-10-02 2013-04-30 Amazon Technologies, Inc. Distribution network with forward resource propagation
US20110126192A1 (en) * 2009-10-26 2011-05-26 Simon Frost Systems and methods for providing and updating a unified client
US9054913B1 (en) 2009-11-30 2015-06-09 Dell Software Inc. Network protocol proxy
US8832215B2 (en) * 2009-12-02 2014-09-09 International Business Machines Corporation Load-balancing in replication engine of directory server
US9495338B1 (en) 2010-01-28 2016-11-15 Amazon Technologies, Inc. Content distribution network
US8495193B2 (en) * 2010-02-23 2013-07-23 Microsoft Corporation Centralized management tool for remote presentation session server farms
US8775505B2 (en) * 2010-04-07 2014-07-08 Pivotal Software, Inc. Optimized event routing in distributed data management
US8676979B2 (en) * 2010-05-18 2014-03-18 Salesforce.Com, Inc. Methods and systems for efficient API integrated login in a multi-tenant database environment
US20120036263A1 (en) * 2010-05-21 2012-02-09 Open Subnet Inc. System and Method for Monitoring and Controlling Access to Web Content
US8756272B1 (en) 2010-08-26 2014-06-17 Amazon Technologies, Inc. Processing encoded content
US8468247B1 (en) 2010-09-28 2013-06-18 Amazon Technologies, Inc. Point of presence management in request routing
US9712484B1 (en) 2010-09-28 2017-07-18 Amazon Technologies, Inc. Managing request routing information utilizing client identifiers
US9003035B1 (en) 2010-09-28 2015-04-07 Amazon Technologies, Inc. Point of presence management in request routing
US10958501B1 (en) 2010-09-28 2021-03-23 Amazon Technologies, Inc. Request routing information based on client IP groupings
US8577992B1 (en) 2010-09-28 2013-11-05 Amazon Technologies, Inc. Request routing management based on network components
US8819283B2 (en) 2010-09-28 2014-08-26 Amazon Technologies, Inc. Request routing in a networked environment
US8938526B1 (en) 2010-09-28 2015-01-20 Amazon Technologies, Inc. Request routing management based on network components
US8930513B1 (en) 2010-09-28 2015-01-06 Amazon Technologies, Inc. Latency measurement in resource requests
US10097398B1 (en) 2010-09-28 2018-10-09 Amazon Technologies, Inc. Point of presence management in request routing
US8924528B1 (en) 2010-09-28 2014-12-30 Amazon Technologies, Inc. Latency measurement in resource requests
US20120096057A1 (en) * 2010-10-13 2012-04-19 Business Objects Software Ltd. Default object fragments
US8346921B1 (en) * 2010-11-19 2013-01-01 Amazon Technologies, Inc. Predictive governing of dynamic modification of program execution capacity
US8452874B2 (en) 2010-11-22 2013-05-28 Amazon Technologies, Inc. Request routing processing
US9391949B1 (en) 2010-12-03 2016-07-12 Amazon Technologies, Inc. Request routing processing
US8626950B1 (en) 2010-12-03 2014-01-07 Amazon Technologies, Inc. Request routing processing
US10108993B2 (en) 2010-12-15 2018-10-23 Red Hat, Inc. Data driven rules engine to dynamically change product business rules
US9224111B2 (en) * 2011-02-25 2015-12-29 Red Hat, Inc. Message queue based product asset management auditing system
TW201241642A (en) * 2011-04-01 2012-10-16 Acer Inc Method and system for managing controllers
US10467042B1 (en) 2011-04-27 2019-11-05 Amazon Technologies, Inc. Optimized deployment based upon customer locality
US8874960B1 (en) * 2011-12-08 2014-10-28 Google Inc. Preferred master election
US8904009B1 (en) 2012-02-10 2014-12-02 Amazon Technologies, Inc. Dynamic content delivery
US10021179B1 (en) 2012-02-21 2018-07-10 Amazon Technologies, Inc. Local resource delivery network
US10185822B2 (en) * 2012-03-14 2019-01-22 Carbon Black, Inc. Systems and methods for tracking and recording events in a network of computing systems
US9083743B1 (en) 2012-03-21 2015-07-14 Amazon Technologies, Inc. Managing request routing information utilizing performance information
US10623408B1 (en) 2012-04-02 2020-04-14 Amazon Technologies, Inc. Context sensitive object management
US10555145B1 (en) 2012-06-05 2020-02-04 Amazon Technologies, Inc. Learned configuration of modification policies for program execution capacity
US9154551B1 (en) 2012-06-11 2015-10-06 Amazon Technologies, Inc. Processing DNS queries to identify pre-processing information
US9207988B2 (en) 2012-06-29 2015-12-08 Intel Corporation Method, system, and device for managing server hardware resources in a cloud scheduling environment
US9525659B1 (en) 2012-09-04 2016-12-20 Amazon Technologies, Inc. Request routing utilizing point of presence load information
US9438499B2 (en) * 2012-09-06 2016-09-06 Intel Corporation Approximation of the physical location of devices and transitive device discovery through the sharing of neighborhood information using wireless or wired discovery mechanisms
US9323577B2 (en) 2012-09-20 2016-04-26 Amazon Technologies, Inc. Automated profiling of resource usage
US9135048B2 (en) 2012-09-20 2015-09-15 Amazon Technologies, Inc. Automated profiling of resource usage
US10205698B1 (en) 2012-12-19 2019-02-12 Amazon Technologies, Inc. Source-dependent address resolution
WO2014116201A1 (en) * 2013-01-22 2014-07-31 Empire Technology Development Llc Fail-safe licensing for software applications
US9294391B1 (en) 2013-06-04 2016-03-22 Amazon Technologies, Inc. Managing network computing components utilizing request routing
US9569515B2 (en) * 2014-11-13 2017-02-14 Dropbox, Inc. Facilitating distributed deletes in a replicated storage system
US10097448B1 (en) 2014-12-18 2018-10-09 Amazon Technologies, Inc. Routing mode and point-of-presence selection service
US10091096B1 (en) 2014-12-18 2018-10-02 Amazon Technologies, Inc. Routing mode and point-of-presence selection service
US10033627B1 (en) 2014-12-18 2018-07-24 Amazon Technologies, Inc. Routing mode and point-of-presence selection service
US10225326B1 (en) 2015-03-23 2019-03-05 Amazon Technologies, Inc. Point of presence based data uploading
US9887932B1 (en) 2015-03-30 2018-02-06 Amazon Technologies, Inc. Traffic surge management for points of presence
US9887931B1 (en) 2015-03-30 2018-02-06 Amazon Technologies, Inc. Traffic surge management for points of presence
US9819567B1 (en) 2015-03-30 2017-11-14 Amazon Technologies, Inc. Traffic surge management for points of presence
US10834065B1 (en) 2015-03-31 2020-11-10 F5 Networks, Inc. Methods for SSL protected NTLM re-authentication and devices thereof
US9832141B1 (en) 2015-05-13 2017-11-28 Amazon Technologies, Inc. Routing based request correlation
US10484385B2 (en) * 2015-06-04 2019-11-19 Sap Se Accessing an application through application clients and web browsers
US10616179B1 (en) 2015-06-25 2020-04-07 Amazon Technologies, Inc. Selective routing of domain name system (DNS) requests
US10097566B1 (en) 2015-07-31 2018-10-09 Amazon Technologies, Inc. Identifying targets of network attacks
US9774619B1 (en) 2015-09-24 2017-09-26 Amazon Technologies, Inc. Mitigating network attacks
US9742795B1 (en) 2015-09-24 2017-08-22 Amazon Technologies, Inc. Mitigating network attacks
US9794281B1 (en) 2015-09-24 2017-10-17 Amazon Technologies, Inc. Identifying sources of network attacks
US10270878B1 (en) 2015-11-10 2019-04-23 Amazon Technologies, Inc. Routing for origin-facing points of presence
US10257307B1 (en) 2015-12-11 2019-04-09 Amazon Technologies, Inc. Reserved cache space in content delivery networks
US10049051B1 (en) 2015-12-11 2018-08-14 Amazon Technologies, Inc. Reserved cache space in content delivery networks
US10348639B2 (en) 2015-12-18 2019-07-09 Amazon Technologies, Inc. Use of virtual endpoints to improve data transmission rates
US10404698B1 (en) 2016-01-15 2019-09-03 F5 Networks, Inc. Methods for adaptive organization of web application access points in webtops and devices thereof
US10075551B1 (en) 2016-06-06 2018-09-11 Amazon Technologies, Inc. Request management for hierarchical cache
US10110694B1 (en) 2016-06-29 2018-10-23 Amazon Technologies, Inc. Adaptive transfer rate for retrieving content from a server
US9992086B1 (en) 2016-08-23 2018-06-05 Amazon Technologies, Inc. External health checking of virtual private cloud network environments
US10033691B1 (en) 2016-08-24 2018-07-24 Amazon Technologies, Inc. Adaptive resolution of domain name requests in virtual private cloud network environments
US10616250B2 (en) 2016-10-05 2020-04-07 Amazon Technologies, Inc. Network addresses with encoded DNS-level information
US10997557B2 (en) 2016-10-14 2021-05-04 Slack Technologies, Inc. Method, apparatus, and computer program product for authorizing and authenticating user communication within an enterprise group-based communication platform
US10372499B1 (en) 2016-12-27 2019-08-06 Amazon Technologies, Inc. Efficient region selection system for executing request-driven code
US10831549B1 (en) 2016-12-27 2020-11-10 Amazon Technologies, Inc. Multi-region request-driven code execution system
US10841363B2 (en) * 2017-01-09 2020-11-17 International Business Machines Corporation Streaming API subscription without loss of events
US10637814B2 (en) * 2017-01-18 2020-04-28 Microsoft Technology Licensing, Llc Communication routing based on physical status
US10938884B1 (en) 2017-01-30 2021-03-02 Amazon Technologies, Inc. Origin server cloaking using virtual private cloud network environments
US9898347B1 (en) * 2017-03-15 2018-02-20 Sap Se Scaling computing resources in a cluster
US10503613B1 (en) 2017-04-21 2019-12-10 Amazon Technologies, Inc. Efficient serving of resources during server unavailability
US10715605B2 (en) * 2017-05-02 2020-07-14 Servicenow, Inc. System and method for limiting active sessions
US11075987B1 (en) 2017-06-12 2021-07-27 Amazon Technologies, Inc. Load estimating content delivery network
US10447648B2 (en) 2017-06-19 2019-10-15 Amazon Technologies, Inc. Assignment of a POP to a DNS resolver based on volume of communications over a link between client devices and the POP
US11405300B2 (en) * 2017-06-20 2022-08-02 Vmware, Inc. Methods and systems to adjust resources and monitoring configuration of objects in a distributed computing system
US10402371B2 (en) 2017-07-20 2019-09-03 Slack Technologies, Inc. Method, apparatus and computer program product for generating externally shared communication channels
US11341093B2 (en) 2017-07-20 2022-05-24 Slack Technologies, Llc Method, apparatus and computer program product for generating externally shared communication channels
US10541825B2 (en) 2017-07-20 2020-01-21 Slack Technologies, Inc. Method, apparatus and computer program product for generating externally shared communication channels
US10742593B1 (en) 2017-09-25 2020-08-11 Amazon Technologies, Inc. Hybrid content request routing system
US10592578B1 (en) 2018-03-07 2020-03-17 Amazon Technologies, Inc. Predictive content push-enabled content delivery network
US10506032B2 (en) * 2018-04-26 2019-12-10 Slack Technologies, Inc. Automated load distribution for a group-based communication platform
US10862852B1 (en) 2018-11-16 2020-12-08 Amazon Technologies, Inc. Resolution of domain name requests in heterogeneous network environments
US10346378B1 (en) 2018-11-30 2019-07-09 Slack Technologies, Inc. Data storage architecture for an enterprise communication system
US11025747B1 (en) 2018-12-12 2021-06-01 Amazon Technologies, Inc. Content request pattern-based routing system
US10862975B1 (en) 2019-06-04 2020-12-08 Citrix Systems, Inc. Computing system providing direct routing for desktop as a service (DaaS) sessions to a private network and related methods
AU2020444463A1 (en) 2020-08-01 2022-02-17 Citrix Systems, Inc. Desktop as a service system
US11245766B1 (en) * 2020-09-01 2022-02-08 Paypal, Inc. Determining processing weights of rule variables for rule processing optimization
CN112597408B (zh) * 2020-12-28 2023-08-04 恒生电子股份有限公司 一种系统融合方法、装置、设备和存储介质

Family Cites Families (168)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4387425A (en) 1980-05-19 1983-06-07 Data General Corporation Masterless and contentionless computer network
US4779189A (en) 1985-06-28 1988-10-18 International Business Machines Corporation Peripheral subsystem initialization method and apparatus
US4825354A (en) 1985-11-12 1989-04-25 American Telephone And Telegraph Company, At&T Bell Laboratories Method of file access in a distributed processing computer network
US4862392A (en) 1986-03-07 1989-08-29 Star Technologies, Inc. Geometry processor for graphics display system
US5481740A (en) 1986-04-14 1996-01-02 National Instruments Corporation Method and apparatus for providing autoprobe features in a graphical data flow diagram
JP2585535B2 (ja) 1986-06-02 1997-02-26 株式会社日立製作所 複合計算機システムにおけるプロセス結合方法
US4887204A (en) 1987-02-13 1989-12-12 International Business Machines Corporation System and method for accessing remote files in a distributed networking environment
US5202971A (en) 1987-02-13 1993-04-13 International Business Machines Corporation System for file and record locking between nodes in a distributed data processing environment maintaining one copy of each file lock
US5175852A (en) 1987-02-13 1992-12-29 International Business Machines Corporation Distributed file access structure lock
US5367688A (en) 1987-09-04 1994-11-22 Digital Equipment Corporation Boot system for distributed digital data processing system
US5014221A (en) 1988-01-29 1991-05-07 Digital Equipment Corporation Mechanism for arbitrating client access to a networked print server
US5155847A (en) 1988-08-03 1992-10-13 Minicom Data Corporation Method and apparatus for updating software at remote locations
US4905141A (en) 1988-10-25 1990-02-27 International Business Machines Corporation Partitioned cache memory with partition look-aside table (PLAT) for early partition assignment identification
US5031089A (en) 1988-12-30 1991-07-09 United States Of America As Represented By The Administrator, National Aeronautics And Space Administration Dynamic resource allocation scheme for distributed heterogeneous computer systems
EP0381645A3 (de) 1989-01-18 1992-08-05 International Business Machines Corporation Übertragungssystem und -verfahren zwischen einer Vielzahl von Prozessoren
US5341477A (en) 1989-02-24 1994-08-23 Digital Equipment Corporation Broker for computer network server selection
EP0384339B1 (de) 1989-02-24 1997-04-02 Digital Equipment Corporation Makler für die Auswahl von Rechnernetzwerkservern
US5142680A (en) 1989-04-26 1992-08-25 Sun Microsystems, Inc. Method for loading an operating system through a network
US5305440A (en) 1989-05-15 1994-04-19 International Business Machines Corporation File extension by clients in a distributed data processing system
US5187790A (en) 1989-06-29 1993-02-16 Digital Equipment Corporation Server impersonation of client processes in an object based computer operating system
DE69029441T2 (de) 1989-08-24 1997-06-12 Ibm System für den Aufruf von Prozeduren von einem Fernnetzwerkknotenpunkt
US5119319A (en) 1989-12-14 1992-06-02 Options Unlimited Research Corp. Full-duplex video communication system
EP0463251A1 (de) 1990-06-28 1992-01-02 International Business Machines Corporation Software-Installation
US5774642A (en) 1990-08-09 1998-06-30 Bull S.A. Architecture for dynamic service processor exchange providing multitasking environment where multiple processors have access to a system configuration table
EP0475581A3 (en) 1990-08-30 1993-06-23 Hewlett-Packard Company Method and apparatus for window sharing between computer displays
US5583992A (en) 1990-09-14 1996-12-10 Kabushiki Kaisha Toshiba Computer network system for detecting global deadlock
CA2048306A1 (en) * 1990-10-02 1992-04-03 Steven P. Miller Distributed configuration profile for computing system
US5241625A (en) 1990-11-27 1993-08-31 Farallon Computing, Inc. Screen image sharing among heterogeneous computers
US5249290A (en) 1991-02-22 1993-09-28 At&T Bell Laboratories Method of and apparatus for operating a client/server computer network
JPH04271454A (ja) 1991-02-27 1992-09-28 Toshiba Corp 疎結合計算機システム
US5265239A (en) 1991-04-08 1993-11-23 Ardolino Anthony A Method for remotely accessing service programs of a local processing system supporting multiple protocol stacks and multiple device drivers
US5204897A (en) 1991-06-28 1993-04-20 Digital Equipment Corporation Management interface for license management system
JPH0546568A (ja) 1991-08-08 1993-02-26 Internatl Business Mach Corp <Ibm> 分散アプリケーシヨン実行装置および方法
US5321806A (en) 1991-08-21 1994-06-14 Digital Equipment Corporation Method and apparatus for transmitting graphics command in a computer graphics system
IL99923A0 (en) 1991-10-31 1992-08-18 Ibm Israel Method of operating a computer in a network
US5619716A (en) 1991-11-05 1997-04-08 Hitachi, Ltd. Information processing system having a configuration management system for managing the software of the information processing system
JP3612652B2 (ja) 1992-06-18 2005-01-19 インターナシヨナル・ビジネス・マシーンズ・コーポレイシヨン ローカル・コンピュータ上で実行されるローカル・タスクによってリモート・コンピュータ上のリモート・タスクを実行する方法
US5440719A (en) 1992-10-27 1995-08-08 Cadence Design Systems, Inc. Method simulating data traffic on network in accordance with a client/sewer paradigm
US5329619A (en) 1992-10-30 1994-07-12 Software Ag Cooperative processing interface and communication broker for heterogeneous computing environments
JP3553987B2 (ja) 1992-11-13 2004-08-11 株式会社日立製作所 クライアント・サーバシステム
US5509070A (en) 1992-12-15 1996-04-16 Softlock Services Inc. Method for encouraging purchase of executable and non-executable software
US5566302A (en) 1992-12-21 1996-10-15 Sun Microsystems, Inc. Method for executing operation call from client application using shared memory region and establishing shared memory region when the shared memory region does not exist
US5572674A (en) 1993-01-07 1996-11-05 Bmc Software, Inc. Method of dynamically adjusting SNA network control program parameters
US5325527A (en) 1993-01-19 1994-06-28 Canon Information Systems, Inc. Client/server communication system utilizing a self-generating nodal network
US5548761A (en) 1993-03-09 1996-08-20 International Business Machines Corporation Compiler for target machine independent optimization of data movement, ownership transfer and device control
JPH06332782A (ja) 1993-03-22 1994-12-02 Hitachi Ltd ファイルサーバシステム及びそのファイルアクセス制御方法
US5548724A (en) * 1993-03-22 1996-08-20 Hitachi, Ltd. File server system and file access control method of the same
JP2576762B2 (ja) 1993-06-30 1997-01-29 日本電気株式会社 リング網のノード間情報収集方式
US5850540A (en) 1993-07-02 1998-12-15 Sony Corporation Method and apparatus for time-sharing CPU system bus in image generation system
EP0746816B1 (de) 1993-08-03 2001-10-24 Sun Microsystems, Inc. Flexible mehrfach-plattform-aufteilung für rechneranwendungen
US5359593A (en) 1993-08-26 1994-10-25 International Business Machines Corporation Dynamic bandwidth estimation and adaptation for packet communications networks
GB2281793A (en) 1993-09-11 1995-03-15 Ibm A data processing system for providing user load levelling in a network
US5553242A (en) 1993-11-03 1996-09-03 Wang Laboratories, Inc. Client/server connection sharing
US5455953A (en) 1993-11-03 1995-10-03 Wang Laboratories, Inc. Authorization system for obtaining in single step both identification and access rights of client to server directly from encrypted authorization ticket
US5592626A (en) 1994-02-07 1997-01-07 The Regents Of The University Of California System and method for selecting cache server based on transmission and storage factors for efficient delivery of multimedia information in a hierarchical network of servers
US5781743A (en) * 1994-02-18 1998-07-14 Hitachi, Ltd. System and method for distributed data processing using different server system specifications
US5526344A (en) 1994-04-15 1996-06-11 Dsc Communications Corporation Multi-service switch for a telecommunications network
US5473599A (en) 1994-04-22 1995-12-05 Cisco Systems, Incorporated Standby router protocol
CA2145921A1 (en) 1994-05-10 1995-11-11 Vijay Pochampalli Kumar Method and apparatus for executing a distributed algorithm or service on a simple network management protocol based computer network
US5596745A (en) 1994-05-16 1997-01-21 International Business Machines Corporation System and procedure for concurrent database access by multiple user applications through shared connection processes
US5594490A (en) 1994-05-23 1997-01-14 Cable Services Technologies, Inc. System for distributing video/audio files from central location to a plurality of cable headends
US5517617A (en) 1994-06-29 1996-05-14 Digital Equipment Corporation Automatic assignment of addresses in a computer communications network
TW252248B (en) 1994-08-23 1995-07-21 Ibm A semiconductor memory based server for providing multimedia information on demand over wide area networks
US5541927A (en) 1994-08-24 1996-07-30 At&T Corp. Method of multicasting
US5586312A (en) 1994-10-11 1996-12-17 Unisys Corporation Method and apparatus for using an independent transaction processing application as a service routine
FR2727540B1 (fr) 1994-11-30 1997-01-03 Bull Sa Outil d'aide a la repartition de la charge d'une application repartie
US5659685A (en) 1994-12-13 1997-08-19 Microsoft Corporation Method and apparatus for maintaining network communications on a computer capable of connecting to a WAN and LAN
US5680549A (en) 1994-12-30 1997-10-21 Compuserve Incorporated System for transferring network connections from first to second program where the first enters an inactive state and resumes control of connections when second terminates
US5583563A (en) 1995-01-12 1996-12-10 Us West Marketing Resources Group, Inc. Method and system for delivering an application in an interactive television network
US5682478A (en) 1995-01-19 1997-10-28 Microsoft Corporation Method and apparatus for supporting multiple, simultaneous services over multiple, simultaneous connections between a client and network server
US5557748A (en) 1995-02-03 1996-09-17 Intel Corporation Dynamic network configuration
US5819093A (en) 1995-03-03 1998-10-06 Sun Microsystems, Inc. System and method for a distributed debugger for debugging distributed application programs
US5857102A (en) 1995-03-14 1999-01-05 Sun Microsystems, Inc. System and method for determining and manipulating configuration information of servers in a distributed object environment
US5721876A (en) 1995-03-30 1998-02-24 Bull Hn Information Systems Inc. Sockets application program mechanism for proprietary based application programs running in an emulation environment
US6249800B1 (en) * 1995-06-07 2001-06-19 International Business Machines Corporartion Apparatus and accompanying method for assigning session requests in a multi-server sysplex environment
US5774668A (en) 1995-06-07 1998-06-30 Microsoft Corporation System for on-line service in which gateway computer uses service map which includes loading condition of servers broadcasted by application servers for load balancing
US5710918A (en) 1995-06-07 1998-01-20 International Business Machines Corporation Method for distributed task fulfillment of web browser requests
US5734865A (en) 1995-06-07 1998-03-31 Bull Hn Information Systems Inc. Virtual local area network well-known port routing mechanism for mult--emulators in an open system environment
US5737592A (en) 1995-06-19 1998-04-07 International Business Machines Corporation Accessing a relational database over the Internet using macro language files
US5692129B1 (en) 1995-07-07 1999-08-17 Novell Inc Managing application programs in a computer network by using a database of application objects
US6182074B1 (en) 1995-07-25 2001-01-30 British Telecommunications Public Limited Company Automated generation of control interface to controlled element of telecommunications network
US5644720A (en) 1995-07-31 1997-07-01 West Publishing Company Interprocess communications interface for managing transaction requests
US5758186A (en) 1995-10-06 1998-05-26 Sun Microsystems, Inc. Method and apparatus for generically handling diverse protocol method calls in a client/server computer system
US5913060A (en) 1995-10-11 1999-06-15 Citrix Systems, Inc. Method for deadlock avoidance in a distributed process system using a synchronous procedure call
US5826027A (en) 1995-10-11 1998-10-20 Citrix Systems, Inc. Method for supporting an extensible and dynamically bindable protocol stack in a distrubited process system
US5765034A (en) 1995-10-20 1998-06-09 International Business Machines Corporation Fencing system for standard interfaces for storage devices
US5745692A (en) 1995-10-23 1998-04-28 Ncr Corporation Automated systems administration of remote computer servers
US5802306A (en) 1995-10-31 1998-09-01 International Business Machines Corporation Supporting multiple client-server sessions from a protocol stack associated with a single physical adapter through use of a plurality of logical adapters
US5748896A (en) 1995-12-27 1998-05-05 Apple Computer, Inc. Remote network administration methods and apparatus
US5706437A (en) 1995-12-29 1998-01-06 Mci Communications Corporation System and method for accessing a service on a services network
US5862348A (en) 1996-02-09 1999-01-19 Citrix Systems, Inc. Method and apparatus for connecting a client node to a server node based on load levels
US6128657A (en) * 1996-02-14 2000-10-03 Fujitsu Limited Load sharing system
JPH09233467A (ja) 1996-02-21 1997-09-05 Fujitsu Ltd 画像データ通信装置及び画像データ通信システムにおける通信データ量調整方法
US5961588A (en) 1996-02-22 1999-10-05 Alcatel Usa Sourcing, L.P. Handling of commands passed between the server and client stations of a telecommunications system
US5761507A (en) 1996-03-05 1998-06-02 International Business Machines Corporation Client/server architecture supporting concurrent servers within a server with a transaction manager providing server/connection decoupling
US5764915A (en) 1996-03-08 1998-06-09 International Business Machines Corporation Object-oriented communication interface for network protocol access using the selected newly created protocol interface object and newly created protocol layer objects in the protocol stack
US5938733A (en) 1996-03-08 1999-08-17 International Business Machines Corporation Object oriented representation of network requests in a client server model
US5838910A (en) 1996-03-14 1998-11-17 Domenikos; Steven D. Systems and methods for executing application programs from a memory device linked to a server at an internet site
US5748892A (en) 1996-03-25 1998-05-05 Citrix Systems, Inc. Method and apparatus for client managed flow control on a limited memory computer system
US5754830A (en) 1996-04-01 1998-05-19 Openconnect Systems, Incorporated Server and web browser terminal emulator for persistent connection to a legacy host system and method of operation
US5802258A (en) 1996-05-03 1998-09-01 International Business Machines Corporation Loosely coupled system environment designed to handle a non-disruptive host connection switch after detection of an error condition or during a host outage or failure
US5864678A (en) 1996-05-08 1999-01-26 Apple Computer, Inc. System for detecting and reporting data flow imbalance between computers using grab rate outflow rate arrival rate and play rate
US5768528A (en) 1996-05-24 1998-06-16 V-Cast, Inc. Client-server system for delivery of online information
US6014133A (en) 1996-06-14 2000-01-11 Seiko Epson Corporation Data transmitter/receiver apparatus, data transmitter, data receiver, and data compression method
US5862346A (en) 1996-06-28 1999-01-19 Metadigm Distributed group activity data network system and corresponding method
KR100203266B1 (ko) 1996-07-09 1999-06-15 윤종용 윤곽선복호화장치
US5764908A (en) 1996-07-12 1998-06-09 Sofmap Future Design, Inc. Network system containing program modules residing in different computers and executing commands without return results to calling modules
US5828840A (en) 1996-08-06 1998-10-27 Verifone, Inc. Server for starting client application on client if client is network terminal and initiating client application on server if client is non network terminal
EP0853788A1 (de) 1996-08-08 1998-07-22 Agranat Systems, Inc. Eingebetteter web-server
US5832529A (en) 1996-10-11 1998-11-03 Sun Microsystems, Inc. Methods, apparatus, and product for distributed garbage collection
GB9623298D0 (en) 1996-11-08 1997-01-08 Int Computers Ltd Updating mechanism for software
US5870545A (en) 1996-12-05 1999-02-09 Hewlett-Packard Company System and method for performing flexible workflow process compensation in a distributed workflow management system
GB2320112B (en) * 1996-12-07 2001-07-25 Ibm High-availability computer server system
US5938732A (en) 1996-12-09 1999-08-17 Sun Microsystems, Inc. Load balancing and failover of network services
US5889942A (en) 1996-12-18 1999-03-30 Orenshteyn; Alexander S. Secured system for accessing application services from a remote station
US5941988A (en) 1997-01-27 1999-08-24 International Business Machines Corporation Session and transport layer proxies via TCP glue
GB2321729B (en) 1997-02-04 2001-06-13 Ibm Data processing system, method, and server
US6111858A (en) 1997-02-18 2000-08-29 Virata Limited Proxy-controlled ATM subnetwork
DE69735084T2 (de) 1997-02-18 2006-08-31 Matsushita Electric Industrial Co., Ltd., Kadoma Leitwegumlenkungsverfahren in hierarchischen strukturierten Netzwerken
US5951648A (en) 1997-03-03 1999-09-14 Mylex Corporation Reliable event delivery system
US5923842A (en) 1997-03-06 1999-07-13 Citrix Systems, Inc. Method and apparatus for simultaneously providing anonymous user login for multiple users
US5949975A (en) 1997-03-12 1999-09-07 Microsoft Corp. Method and system for negotiating capabilities when sharing an application program with multiple computer systems
GB2323946B (en) 1997-04-04 2002-04-17 Sony Uk Ltd Database accessing method and apparatus
JPH10301874A (ja) 1997-04-22 1998-11-13 Internatl Business Mach Corp <Ibm> 遠隔操作方法、ネットワークを介して端末から遠隔操作されるサーバ及びｈｔｍｌファイルを格納する記憶媒体
US6170017B1 (en) * 1997-05-08 2001-01-02 International Business Machines Corporation Method and system coordinating actions among a group of servers
US6408174B1 (en) 1997-05-13 2002-06-18 Telefonaktiebolaget Lm Ericsson (Publ) Communication method, system, and device for reducing processor load at tariff switch
US5961586A (en) 1997-05-14 1999-10-05 Citrix Systems, Inc. System and method for remotely executing an interpretive language application
US5941949A (en) 1997-05-14 1999-08-24 Citrix Systems, Inc. System and method for transmitting data from a server application to more than one client node
US6023721A (en) 1997-05-14 2000-02-08 Citrix Systems, Inc. Method and system for allowing a single-user application executing in a multi-user environment to create objects having both user-global and system global visibility
US6157944A (en) 1997-05-14 2000-12-05 Citrix Systems, Inc. System and method for replicating a client/server data exchange to additional client notes connecting to the server
US5983190A (en) 1997-05-19 1999-11-09 Microsoft Corporation Client server animation system for managing interactive user interface characters
US6263368B1 (en) * 1997-06-19 2001-07-17 Sun Microsystems, Inc. Network load balancing for multi-computer server by counting message packets to/from multi-computer server
WO1999012103A2 (en) 1997-09-05 1999-03-11 Sun Microsystems, Inc. Scalable shared memory multiprocessor system
CA2216901C (en) 1997-09-26 2000-12-26 Ibm Canada Limited-Ibm Canada Limitee Method and apparatus for discovery of databases in a client server network
US6470386B1 (en) 1997-09-26 2002-10-22 Worldcom, Inc. Integrated proxy interface for web based telecommunications management tools
US6078322A (en) 1997-09-30 2000-06-20 The United States Of America As Represented By The Secretary Of The Navy Methods permitting rapid generation of platform independent software applications executed on a universal client device
US6125387A (en) 1997-09-30 2000-09-26 The United States Of America Represented By The Secretary Of The Navy Operating methods for robust computer systems permitting autonomously switching between alternative/redundant
US6070191A (en) * 1997-10-17 2000-05-30 Lucent Technologies Inc. Data distribution techniques for load-balanced fault-tolerant web access
US6233609B1 (en) 1997-10-31 2001-05-15 Selectica, Inc Method and apparatus for remote interaction with and configuration of a wan-based knowledge base
US5999179A (en) 1997-11-17 1999-12-07 Fujitsu Limited Platform independent computer network management client
US6247052B1 (en) 1997-12-23 2001-06-12 Alcatel Usa Sourcing, L.P. Graphic user interface system for a telecommunications switch management system
EP0930758A3 (de) 1998-01-16 2003-10-15 Kabushiki Kaisha Toshiba Verteiltes Netzwerkrechnersystem
GB2334353B (en) * 1998-02-12 2002-08-07 Ibm An apparatus,method and computer program product for client/server computing with the ability to select which servers are capable of creating transaction stat
US6330591B1 (en) 1998-03-09 2001-12-11 Lsi Logic Corporation High speed serial line transceivers integrated into a cache controller to support coherent memory transactions in a loosely coupled network
US6108712A (en) 1998-05-05 2000-08-22 International Business Machines Corp. Client-server system with central application management and providing export agent capability for retrofitting existing hardware and applications into the system
US6279001B1 (en) * 1998-05-29 2001-08-21 Webspective Software, Inc. Web service
US6427163B1 (en) 1998-07-10 2002-07-30 International Business Machines Corporation Highly scalable and highly available cluster system management scheme
US6219700B1 (en) 1998-07-28 2001-04-17 Sun Microsystems, Inc. Method and apparatus for managing services in a computer network from a central console
US6477559B1 (en) 1998-08-21 2002-11-05 Aspect Communications Corporation Method and apparatus for remotely accessing an automatic transaction processing system
US6115743A (en) 1998-09-22 2000-09-05 Mci Worldcom, Inc. Interface system for integrated monitoring and management of network devices in a telecommunication network
US6327608B1 (en) 1998-09-25 2001-12-04 Microsoft Corporation Server administration tool using remote file browser
US6412079B1 (en) 1998-10-09 2002-06-25 Openwave Systems Inc. Server pool for clustered system
JP2003527763A (ja) * 1998-10-16 2003-09-16 シルバーストリーム・ソフトウェア・インコーポレーテッド 分散オブジェクト・システム用の接続集線装置
US6134568A (en) 1998-10-30 2000-10-17 Kinko's Ventures, Inc. Previewing an assembled document
US6571274B1 (en) 1998-11-05 2003-05-27 Beas Systems, Inc. Clustered enterprise Java™ in a secure distributed processing system
US6453348B1 (en) 1998-11-06 2002-09-17 Ameritech Corporation Extranet architecture
US6272522B1 (en) 1998-11-17 2001-08-07 Sun Microsystems, Incorporated Computer data packet switching and load balancing system using a general-purpose multiprocessor architecture
US6463460B1 (en) 1999-04-23 2002-10-08 The United States Of America As Represented By The Secretary Of The Navy Interactive communication system permitting increased collaboration between users
US6405266B1 (en) 1998-11-30 2002-06-11 Hewlett-Packard Company Unified publish and subscribe paradigm for local and remote publishing destinations
US6393484B1 (en) 1999-04-12 2002-05-21 International Business Machines Corp. System and method for controlled access to shared-medium public and semi-public internet protocol (IP) networks
US6374297B1 (en) 1999-08-16 2002-04-16 International Business Machines Corporation Method and apparatus for load balancing of web cluster farms
US6536000B1 (en) 1999-10-15 2003-03-18 Sun Microsystems, Inc. Communication error reporting mechanism in a multiprocessing computer system
US6535879B1 (en) 2000-02-18 2003-03-18 Netscape Communications Corporation Access control via properties system
US6377975B1 (en) * 2000-03-01 2002-04-23 Interactive Intelligence, Inc. Methods and systems to distribute client software tasks among a number of servers
US6553378B1 (en) 2000-03-31 2003-04-22 Network Associates, Inc. System and process for reporting network events with a plurality of hierarchically-structured databases in a distributed computing environment
FR2807533B1 (fr) 2000-04-05 2002-07-12 Inup Ferme d'ordinateur avec systeme de transfert de fichiers entre cartes processeurs
US20020065851A1 (en) 2000-06-02 2002-05-30 Watson Emerson C. System and method for creating a website
US7958185B2 (en) 2000-09-18 2011-06-07 Bentley Systems, Inc. Spatial data enabled engineering, construction, and operations computer-aided design (CAD) project system, method and computer program product

Also Published As

Publication number Publication date
HK1054604B (zh) 2008-07-25
US20010049717A1 (en) 2001-12-06
US6785713B1 (en) 2004-08-31
HK1054604A1 (en) 2003-12-05
US6807580B2 (en) 2004-10-19
US6826606B2 (en) 2004-11-30
US20020002613A1 (en) 2002-01-03
EP2034406A1 (de) 2009-03-11
DE60133648D1 (de) 2008-05-29

Similar Documents

Publication Publication Date Title
DE60133648T2 (de) System und verfahren zum führen von laufzeitdaten in einem server-netzwerk
DE69635469T2 (de) Synchronisierung zwischen verschiedenen Computeranbieterumgebungen
DE69814900T2 (de) Verfahren und system zur unterstützung verteilter software- entwicklung ohne bewusstsein der verteilten charakteristik der software
US6922724B1 (en) Method and apparatus for managing server load
US6785726B1 (en) Method and apparatus for delivering local and remote server events in a similar fashion
US6789112B1 (en) Method and apparatus for administering a server having a subsystem in communication with an event channel
DE69936818T2 (de) Protokoll zum Austausch von Konfigurationsdaten in einem Computernetzwerk
DE69921455T2 (de) System und verfahren zur zugriffssteuerung auf gespeicherte dokumente
DE60006451T2 (de) Verteilte Authentifizierungsmechanismen zur Behandlung von verschiedenen Authentifizierungssystemen in einem Betriebsrechnersystem
DE69531513T2 (de) Vervielfältigungssystem
DE60218069T2 (de) Bereitstellung von gekoppelten diensten in einer verteilten rechnerumgebung
DE69735348T2 (de) Skalierbare und erweiterbare Systemverwaltungsarchitektur mit datenlosen Endpunkten
DE69832946T2 (de) Verteiltes System und Verfahren zur Steuerung des Zugriffs auf Netzmittel und Ereignismeldungen
DE102009049674B4 (de) Segregieren von anonymem Zugriff auf dynamischen Inhalt auf einem Webserver mit gecachedten Anmeldungen
DE69833929T2 (de) Netzzugriffsauthentifizierungssystem
DE69532736T2 (de) Betriebsverfahren für Rechnernetz
DE60311396T2 (de) Verfahren zur Gestaltung eines Peer-to-Peer Netzwerks mit Hilfe eines gemeinsamen Gruppenetiketts
DE202018006346U1 (de) Gemeinsames Nutzen bzw. Teilen von Daten in einem mandantenfähigen Datenbanksystem
DE112011102073T5 (de) Dienstimplementierung von einem Dienstverzeichnis
DE10052313A1 (de) Verfahren und Vorrichtung zur Beschränkung des freien Verweisens (Hyperlinking) auf Webseiten der ursprünglichen Inhaltserzeuger (Content producers) durch Internet-Inhaltsverteiler (Content distributors)
DE60035348T2 (de) Verlängerbarer Bereitstellungsmechanismus für einen Diensten-gateway
DE69733918T2 (de) Verfahren und Vorrichtung zum Betrieb eines Benutzerkomputers ohne Anbietersoftware
DE102020114272A1 (de) Einsatz von virtuellen Node Clustern in einer mehrmittelbaren Umgebung
DE102019135064A1 (de) Verbessertes management der verfügbarkeit von lagerrepositorien in einer virtuellen umgebung
DE112011104020T5 (de) Validierung des Zugriffs auf einen gemeinsam genutzen Datensatz bei Lese- und Schreibzugriff mehrerer Anforderer

Legal Events

Date Code Title Description
8364 No opposition during term of opposition