DE69636887T2

DE69636887T2 - System und Verfahren,um verschiedenen Anbietern von Namen zu ermöglichen,sich dynamisch einer Namensföderation anzuschliessen

Info

Publication number: DE69636887T2
Application number: DE69636887T
Authority: DE
Inventors: Rosanna K. Palo Alto Lee; Rangaswamy Los Altos Hills Vasudevan
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1995-07-05
Filing date: 1996-07-03
Publication date: 2007-12-06
Anticipated expiration: 2016-07-04
Also published as: DE69636887D1; EP0752674A1; JPH09171465A; US5745683A; EP0752674B1

Description

Die vorliegende Erfindung betrifft die Gebiete der verteilten Computersysteme, des Client-Server-Computing und der objektorientierten Systeme. Insbesondere betrifft die vorliegende Erfindung das Gebiet der Namensgebungsdienste und Verzeichnissysteme in verteilten Computersystemen.
Beim Client-Server-Computing gibt es normalerweise eine Gruppe von Computern, die miteinander durch ein Netzwerk, das die Computer verbindet, kommunizieren können. Einige dieser Computer fungieren als Anbieter von Diensten oder Funktionalität für andere Computer. Die Anbieter derartiger Dienste oder Funktionalität werden als „Server" bezeichnet und die Konsumenten derartiger Dienste oder Funktionalität werden als „Clients" bezeichnet. Das Client-Server-Modell wird auch auf den Fall verallgemeinert, dass distinkte Programme, die auf demselben Computer ausgeführt werden, durch einen geschützten Mechanismus miteinander kommunizieren und als Anbieter und Konsumenten von Funktionalität fungieren.
In einem objektorientierten System ist ein Objekt eine Komponente, die Daten und Operationen, die aufgerufen werden können, um die Daten zu manipulieren, umfasst. Die Operationen werden an dem Objekt aufgerufen, indem Aufrufe zu dem Objekt übertragen werden. Jedes Objekt weist einen Objekttyp auf. Der Objekttyp definiert die Operationen, die an Objekten dieses Typs ausgeführt werden können. Die Objektoperationen werden unabhängig von den Objekten selbst implementiert. Zusätzlich können einem Objekttyp die Objektoperationen vererbt werden, die für andere Objekttypen definiert und implementiert sind. Für eine weitere Beschreibung von objektorientierten Design- und Programmiertechniken siehe „Object-oriented Software Construction" von Bertrand Meyer, Prentice-Hall 1988.
In objektorientierten verteilten Systemen, die auf dem Client-Server-Modell beruhen, gibt es Server, die ihren Clients objektorientierte Schnittstellen bereitstellen. Diese Server unterstützen Objekte, die aus Daten und den assoziierten Programmbefehlen bestehen. Clients können Zugriff auf diese Objekte erhalten und können Aufrufe mit ihnen ausführen. Diese Aufrufe werden von dem Client an den Server übertragen. Am Server werden diese Aufrufe über die Software, die mit dem Objekt assoziiert ist, ausgeführt. Die Ergebnisse dieser Aufrufe werden dann zurück an den Client übertragen.
Client-Anwendungen oder -Programme verweisen mittels Objekt-Handles oder Objektnammen auf bestimmte Objekte. Ein Objektname wird verwendet, um ein Objekt (das „Zielobjekt") zu lokalisieren, so dass Aufrufe damit ausgeführt werden können. Clientprogramme werden von anderen Programmen normalerweise mit Objektnamen versehen oder erben sie beim Programmstart. Wenn ein gegebenes Clientprogramm einen Objektnamen für ein bestimmtes Objekt hat, kann dieses Clientprogramm eine Kopie dieses Objektnamens an ein anderes Clientprogramm übergeben. Das zweite Clientprogramm kann dann den Objektnamen verwenden, um auf das Objekt zuzugreifen. Clients haben keine Informationen über den Standort des Objekts oder die Implementierung des Objekts, die auf einem Computer irgendwo im verteilten Computersystem sein kann. Der Aufruf des Clients für das Objekt mittels des Namens des Objekts wird durch einen „Namensgebungs- oder Verzeichnisdienst" ermöglicht.
Ein Namensgebungs- oder Verzeichnisdienst ist eine grundlegende Einrichtung in jedem Computersystem. Er ist das Mittel, über das Namen mit Objekten assoziiert werden und über das Objekte gefunden werden, wenn ihre Namen gegeben sind. Der Namensgebungsdienst stellt Operationen für Folgendes bereit:

• Assoziieren (Binden) von Namen an Objekte
• Zergliedern (Nachschlagen) von Namen von Objekten
• Entfernen von Bindungen, Auflisten von Namen, Umbenennung usw.

Zusätzlich zu diesen grundlegenden Namensgebungsoperationen kann der Dienst auch Operationen zum Umgang mit Attributen bereitstellen:

• Untersuchen von Attributen, die mit benannten Objekten assoziiert sind
• Modifizieren von Attributen, die mit benannten Objekten assoziiert sind
• Suchen nach Objekten unter Verwendung von Attributen usw.

In traditionellen Systemen ist ein Namensgebungsdienst selten ein separater Dienst. Er ist gewöhnlich mit einem anderen Dienst wie ein Dateisystem, eine Datenbank, ein Desktop usw. integriert. Beispielsweise enthält ein Dateisystem einen Namensgebungsdienst für Dateien und Verzeichnisse; und eine Tabellenkalkulationsprogramm hat einen Namensgebungsdienst für Zellen und Makros.
In einer großen verteilten Computerumgebung gibt es normalerweise viele disparate Namensgebungssysteme, auf die entweder separat oder kooperativ zugegriffen werden kann, um zusammengesetzte Namen zu zergliedern. Ein „zusammengesetzter Name" ist ein Name, der mehrere Namensgebungssysteme umfasst. Er besteht aus einer geordneten Liste von null oder mehr Komponenten. Jede Komponente ist ein Zeichenfolgenname aus dem Namensraum eines einzelnen Namensgebungssystems. Weiterhin wurde ein System für ein Protokoll und einen Prozess zum Kombinieren von Namen von disparaten Namensgebungssystemen in einem „föderiertes Namensgebungssystem" entwickelt, das implementiert werden kann, um das Zergliedern von „zusammengesetzten Namen" zu erleichtern. Siehe US-Patent Nummer 5377323, ausgestellt am 27. Dezember 1994 an Rangaswamy Vasudevan mit dem Titel „Apparatus and Method for a Federated Naming System which Can Resolve a Composite Name Composed of Names from Any Number of Disparate Naming Systems". X/Open, eine unabhängige weltweite Organisation für offene Systeme, die von den meisten weltgrößten Anbietern von Informationssystemen, Benutzerorganisationen und Software-Unternehmen unterstützt wird, hat eine standardmäßige, definierte Weise zum Zugriff von Clients (Anwendungsprogrammen) auf das, was als „föderierte Namensgebungssysteme" bekannt ist, eingeführt. Siehe die Vorläufigen Spezifikationen mit dem Titel „Federated Naming: The XFN Specification", Juli 1994, X/Open Company Limited. ISBN: 1-85912-045-8. Föderierte Namensgebung besteht aus einer Reihe von Anwendungsprogrammschnittstellen, die Operationen zum Zergliedern von zusammengesetzten Namen zu Objektverweisen, Binden von zusammengesetzten Namen zu Objektverweisen und Auflisten von Namensgebungskontexten, die Bindungen von Namen zu Verweisen enthalten. Zusätzlich enthalten die Schnittstellen Operationen zum Manipulieren von zusammengesetzten Namen und Objektverweisen.
Es muss eine Weise für Anbieter von Namensgebungs- und Verzeichnisdiensten geben, ihre individuellen Namensgebungs- und Verzeichnisoperationen in die Operationen des föderierten Namensgebungssystems zu inkorporieren, und zu gestatten, dass neue und beliebige Namensgebungs- und Verzeichnissysteme für Anwendungen während der Laufzeit verfügbar gemacht werden, ohne dass Neukompilierung von Anwendungen oder Neuverknüpfung erforderlich sind oder die Anwendung angehalten werden muss.
Während beispielsweise die in der X/Open-XFN-Spezifikation definierte Schnittstelle Clientprogramme, die zusammengesetzten und individuellen Zugriff auf autonome Namensgebungs- und Verzeichnissysteme benötigen, stark vereinfachen, ist es immer noch schwierig für Namensgebungs- oder Verzeichnis-Dienstanbieterprogramme, ihre jeweiligen Dienste in die Namensgebungsföderation zu inkorporieren. Das heißt, dass die Operationen für das föderierte Namensgebungssystem es für das Clientprogramm relativ unkompliziert machen, einen Befehl des Typs „objectT = ctx->OpenLookup(name, &status)" zu verwenden, um einen Verweis auf das Objekt zu erhalten, das durch den zusammengesetzten Namen „name" relativ zum Kontext „ctx" benannt ist. Gegenwärtig ist es jedoch sehr schwierig, einen neuen Namensgebungs- oder Verzeichnisdienstanbieter (für die Zwecke der folgenden Diskussion wird der Begriff Namensgebungsdienstanbieter anstelle von Namensgebungs- oder Verzeichnisdienstanbieter ohne Verlust der Allgemeingültigkeit verwendet) in ein bestehendes System zu integrieren. Dies bringt häufig Ändern/Modifizieren/Vergrößern der individuell vorhandenen Namensgebungsdienstanbieter-Programme mit sich. Das heißt, die Modifikationen waren nicht eindeutig, um die Aufgaben auszuführen, die mit der Reaktion auf einen Befehl des Typs „objectT = ctx->OpenLookup(name, &status)" in Verbindung stehen, wobei das Namensgebungsdienstanbieter-Programm einen Objektverweis liefern muss, der an head(name) im Kontext ctx gebunden ist, wenn „name" ein atomischer Name ist, und anderenfalls einen Objektverweis auf einen nächsten Kontext (z. B. Kontext cty) liefern muss, indem head(cty) und ein tail(name-cty) geliefert wird. Dieses Problem ist noch schwerwiegender, wenn die Inkorporation dieser Modifikationen in den Namensgebungsdienstanbieter erfolgen muss, ohne dass es jedes Mal erforderlich ist, dass Clientanwendungen neu kompiliert werden, oder ohne dass es jedes Mal erforderlich ist, dass Clientanwendungen angehalten und neu gestartet werden, wenn ein Namensgebungsdienstanbieter-Programm für einen neuen Namensgebungsdienst als ein Ergebnis der Operationen, die erforderlich sind, um einen Befehl des Typs „objectT = ctx->OpenLookup(name, &status)" auszuführen, aufgerufen werden muss.
Nach dem Stand der Technik ist kein einheitliches Verfahren für Dienstanbieterprogramme zum Inkorporieren von beliebigen Namensgebungs- und Verzeichnissystemen, so dass Clients entweder individuell oder zusammengesetzt darauf zugreifen können, definiert. Eine CD-ROM mit dem Titel „The 1994 Solaris Developer Conference", erstellt von SunSoft, einem Unternehmen von Sun Microsystems, Inc., und datiert vom April 1994, wurde auf einer Sun Developers Conference in San Francisco, 5.-7. April 1994, verteilt. Diese CD-ROM enthielt eine Anzahl von binären Demonstrationsprogrammen und ein Papier in Postscript-Form mit dem Titel „Federated Naming Service" von SunSoft, datiert April 1994. Dieses Papier beschrieb das föderierte Namensgebungssystem und zugehörige Probleme, wie oben zusammengefasst, und zusätzlich beschrieb das Papier in Kapitel 5 ein Dienstanbieter-Rahmenwerk, das die Föderation von föderierten Namensgebungssystem-konformen Namensgebungsdiensten in Solaris unterstützt. Solaris ist das Betriebssystemumgebungs-Produkt, das von Sun Microsystems, Inc., produziert und vertrieben wird. Dieses Kapitel 5 beschreibt das Rahmenwerk, wie Implementierer das Rahmenwerk verwenden könnten, um bestehende und neue Namensgebungssysteme zu föderieren, und wie Implementierer ein darin beschriebenes Toolkit verwenden könnten, um die Aufgabe von föderierten Namensgebungsdiensten zu erleichtern. Leider sprachen die in diesem Papier definierten Mechanismen nicht die Tatsache an, dass Namensgebungssysteme innerhalb einer Föderation verschiedene Weisen zur Anzeige, wo die Grenzen zwischen Namensgebungssysteme sind, haben. Es gab keine Möglichkeit zur Anzeige, wie Namen von verschiedenen Namensgebungssystemen innerhalb einer Föderation syntaktisch in einem zusammengesetzten Namen getrennt sind, die wirksam identifizierte, wo die Grenzen des Namensgebungssystems liegen. Die Ausführungsform stellt einen verbesserten föderierten Namensgebungs-Rahmenmechanismus bereit, in dem starke und schwache Trennung definiert sind und Mechanismen bereitgestellt werden, um zu bestimmen, wo diese Namensgebungssystem-Grenzen sind.
Ein System und Verfahren werden beschrieben, die es einem Entwickler/Pfleger gestatten, disparate Namensgebungsdienstanbieter-Programme in ein bestehendes System zu integrieren, so dass Clients direkt und ohne unterbrochen werden zu müssen auf den neu integrierten Namensgebungs- oder Verzeichnisdienst zugreifen können.
Die Ausführungsform überwindet die Probleme der Implementierung von Namensgebungsdienstanbietern in ein bestehendes verteiltes Computersystem, wie es von föderierten Namensgebungssystemoperationen erfordert wird, in dem die Namensgebungssystem-Grenzen nicht definiert sind. Ein System und Verfahren werden offenbart zum

• Vereinfachen der Weise, in der Namensgebungsdienstanbieter ihre individuellen Namensgebungs- und Verzeichnisoperationen in die föderierten Namensgebungssystemoperationen implementieren; und
• Gestatten, dass neue und beliebige Namensgebungs- und Verzeichnisdienste Anwendungen zur Laufzeit verfügbar gemacht werden, ohne dass Neukompilierung, Neueinbindung oder Anhalten der Anwendung erforderlich sind, also ohne Unterbrechung; und
• Bereitstellen von Namensgebungssystemmechanismen, die konfiguriert sind, um Unterstützung für starke oder schwache Trennung in ihren jeweiligen Namensgebungssystemen anzuzeigen.

Die Ausführungsform gestattet die Inkorporation eines Namensgebungsdienstes auf der Ebene von zusammengesetzter Namensgebung oder atomischer Namensgebung, um die Anforderungen des Dienstanbieters zu erfüllen. Das Verfahren und die Vorrichtung enthalten auch eine Weise zum Identifizieren und Aufrufen der entsprechenden Namensgebungs- oder Verzeichnisdienstanbieter-Implementierung zur Laufzeit. Dies bedeutet, dass eine Anwendung den Vorteil haben kann, mehrere disparate Namensgebungsdienste zur Laufzeit ohne vorherige Kenntnis ihrer Existenz oder ihres Standorts zu durchlaufen. Die dynamische Fähigkeit der Vorrichtung gestattet weiterhin, dass beliebige Namensgebungsdienstanbieter inkorporiert und damit verfügbar gemacht werden, ohne dass die Anwendung unterbrochen werden muss.
Ein föderiertes Namensgebungs-Rahmensystem für Verwendung in einem verteilten Computersystem wird offenbart. Das föderierte Namensgebungs-Rahmensystem enthält einen föderierten Namensgebungs-Rahmenmechanismus, der als die Zwischenschicht zwischen der Clientanwendung und dem einen oder mehr Namensgebungsdiensten, die föderiert werden müssen, wirkt und der einen oder mehr Namensgebungsdienstmechanismen enthält, die konfiguriert sind, um Unterstützung für starke oder schwache Trennung in ihren jeweiligen Namensgebungssystemen anzuzeigen.
Das föderierte Namensgebungs-Rahmensystem enthält außerdem eine Namensgebungsdienstanbieter-Schnittstelle, die konfiguriert ist, um mit einem oder mehr Namensgebungsdienstanbietern zu kommunizieren.
Ein Verfahren zur Bereitstellung eines Mechanismus, der es gestattet, Namensgebungsdienstanbieter einem existierenden System ohne Unterbrechung der existierenden Clients hinzuzufügen, wird offenbart.
Ein Computerprogramm-Produkt, das ein computerverwendbares Medium hat, das darin ausgeführte computerlesbare Codemechanismen enthält, wird offenbart, wobei die computerlesbaren Codemechanismen ein föderiertes Namensgebungs-Rahmensystem enthalten, das einen föderierten Namensgebungs-Rahmenmechanismus enthält, der als die Zwischenschicht zwischen der Clientanwendung und dem einen oder mehr Namensgebungsdiensten, die föderiert werden müssen, wirkt und der einen oder mehr Namensgebungsdienstmechanismen enthält, die konfiguriert sind, um Unterstützung für starke oder schwache Trennung in ihren jeweiligen Namensgebungssystemen anzuzeigen.
Die Erfindung ist in den unabhängigen Patentansprüchen definiert.
Für ein besseres Verständnis der vorliegenden Erfindung werden jetzt spezifische Ausführungsformen als Beispiel beschrieben unter Bezugnahme auf die beigefügten Zeichnungen, von denen:
1 eine typische Computer-Workstation des Typs, der in Verbindung mit der gegenwärtigen Erfindung verwendet wird, zeigt.
2 eine typische Konfiguration eines verteilten Computersystems zur Verwendung in Verbindung mit der gegenwärtigen Erfindung zeigt.
3 ein typisches Client-Server-Verhältnis in einem verteilten System zeigt.
4 ein typisches Client-Server-Verhältnis in einem gemeinsamen Hostsystem zeigt.
5 ein Kontextobjekt zeigt.
6 eine alternative Ansicht eines Kontextobjekts zeigt.
7 ein funktionales Verhältnis eines typischen Namensgebungsdienstanbieters zu einem Client zeigt.
8 ein System zeigt, das mehrere Namensgebungsdienstanbieter hat.
9 eine Struktur für ein System zeigt, das mehrere Namensgebungsdienstanbieter nach der vorliegenden Erfindung hat.
10 eine andere Ansicht der vorliegenden Erfindung zeigt, die Beispiele von Kontextimplementierungen für mehrere verschiedene Namensgebungsdienste darstellt.
11 zeigt, wie das föderierte Namensgebungs-(FN)-Rahmenwerk die Kontextschnittstelle unter Verwendung der teilweise zusammengesetzten SPI implementiert.
12 die Verwendung von kombinierten Namen und des „Nächstes-Namensgebungssystem"-Zeigers zeigt.
13a, 13b und 13c ein Ablaufdiagramm zeigen, das die allgemeinen Operationen eines Systems, das das föderierte Namensgebungs-Rahmenwerk implementiert, darstellt.
Die folgenden ausführlichen Beschreibungen werden größtenteils als Algorithmen und symbolische Repräsentationen von Operationen auf Datenbits in einem Computerspeicher dargeboten. Diese algorithmischen Beschreibungen und Repräsentationen sind das Mittel, das von Fachleuten auf dem Gebiet der Datenverarbeitung verwendet wird, um die Substanz ihrer Arbeit wirkungsvoll anderen Fachleuten zu übermitteln.
Ein Algorithmus ist eine in sich widerspruchsfreie Sequenz von Schritten, die zu einem gewünschten Ergebnis führen. Diese Schritte sind diejenigen, die physikalische Manipulation von physikalischen Quantitäten erfordern. Gewöhnlich, aber nicht notwendigerweise, nehmen diese Quantitäten die Form von elektrischen oder magnetischen Signalen an, die gespeichert, übertragen, kombiniert, verglichen und in anderer Weise manipuliert werden können. Es ist manchmal praktisch, hauptsächlich aus Gründen der allgemeinen Gebräuchlichkeit, sich auf diese Signale als Bits, Werte, Elemente, Symbole, Zeichen, Terme, Zahlen oder dergleichen zu beziehen. Es darf jedoch nicht vergessen werden, dass alle diese und ähnliche Begriffe mit den entsprechenden physikalischen Quantitäten assoziiert werden müssen und lediglich praktische Etiketts sind, die auf diese Quantitäten angewandt werden.
Weiterhin werden die vorgenommenen Manipulationen oft mit Begriffen wie Hinzufügen oder Vergleichen bezeichnet, die gewöhnlich mit mentalen Operationen, die von einem menschlichen Operator durchgeführt werden, assoziiert werden. In den hierin beschriebenen Operationen, die einen Teil der vorliegenden Erfindung bilden, ist in den meisten Fällen keine derartige Fähigkeit eines menschlichen Operators erforderlich oder wünschenswert; die Operationen sind Maschinenoperationen. Nützliche Maschinen zum Durchführen der Operationen umfassen Allzweck-Digitalcomputer oder ähnliche Vorrichtungen. In allen Fällen muss die Unterscheidung zwischen den Verfahrensoperationen beim Betreiben eines Computers und dem Verfahren der Berechnungen selbst bedacht werden. Verfahrensschritte werden zum Betreiben eines Computers bei der Verarbeitung von elektrischen oder anderen (z. B. mechanischen, chemischen) physikalischen Signalen zur Erzeugung anderer gewünschter physikalischer Signale beschrieben.
Die vorliegende Erfindung betrifft außerdem eine Vorrichtung zum Ausführen dieser Operationen. Diese Vorrichtung kann speziell für die erforderlichen Zwecke gebaut sein oder sie kann einen Allzweck-Computer umfassen, der durch ein in dem Computer gespeichertes Computerprogramm selektiv aktiviert oder neu konfiguriert wird. Die hierin dargelegten Algorithmen stehen nicht inhärent mit einem bestimmten Computer oder einer anderen Vorrichtung in Zusammenhang. Insbesondere können verschiedene allgemeine Allzweckmaschinen mit Programmen verwendet werden, die gemäß den hierin enthaltenen Lehren geschrieben werden, oder es kann sich als praktischer erweisen, eine speziellere Vorrichtung zum Ausführen der erforderlichen Verfahrensschritte zu bauen. Die erforderliche Struktur für eine Reihe dieser Maschinen ist aus der gegebenen Beschreibung ersichtlich.
Ein System und Verfahren zum Inkorporieren von beliebigen Namensgebungsdiensten in eine Namensgebungs-Föderation in einem verteilten Computersystem werden offenbart. In der folgenden Beschreibung werden zu Zwecken der Erläuterung spezifische Daten und Konfigurationen dargelegt, um ein gründliches Verständnis der vorliegenden Erfindung zu bieten. Die hierin beschriebene bevorzugte Ausführungsform ist für Verwendung in dem von Sun Microsystems^®, Inc. hergestellten Solaris^TM-Betriebssystem implementiert. (Solaris ist eine Marke und Sun Microsystems ist eine eingetragene Marke von Sun Microsystems, Inc.) Fachleuten wird jedoch ersichtlich sein, dass die vorliegende Erfindung ohne die spezifischen Einzelheiten ausgeführt oder in verschiedenen Computersystemen und in verschiedenen Konfigurationen oder Herstellungsweisen oder Modellen von eng gekoppelten Prozessoren oder in verschiedenen Konfigurationen von lose gekoppelten Multiprozessorsystemen implementiert werden kann.
Ein System und Verfahren für ein föderiertes Namensgebungs-Rahmenwerk-(„FN-Rahmenwerk")-System werden beschrieben, das einen Satz von standardisierten föderierten Namensgebungsdienstanbieter-Schnittstellen („FN SPIs") enthält und das die Inkorporation eines Namensgebungsdienstes auf verschiedenen Ebenen gestattet, die von zusammengesetzter Namensgebung bis atomischer Namensgebung reichen, um die Anforderungen des Dienstanbieters zu erfüllen. Das Verfahren und die Vorrichtung enthalten außerdem eine Weise zum Identifizieren und Aufrufen der geeigneten Namensgebungsdienstanbieter-Implementierung zur Laufzeit. Dies bedeutet, dass eine Anwendung den Vorteil haben kann, mehrere disparate Namensgebungssysteme zur Laufzeit ohne vorherige Kenntnis ihrer Existenz oder ihres Standorts zu durchlaufen. Die dynamische Natur der Vorrichtung und des Verfahrens gestattet weiterhin, dass beliebige Namensgebungsdienstanbieter inkorporiert und damit verfügbar gemacht werden können, ohne dass die Anwendung unterbrochen werden muss.
Die Umgebung, in der die vorliegende Erfindung verwendet wird, umfasst das allgemeine verteilte Computersystem, in dem Allzweck-Computer, Workstations oder Personal-Computer über Kommunikationsverbindungen verschiedener Art verbunden sind, in einer Client-Server-Anordnung, in der Programme und Daten, viele in der Form von Objekten, durch verschiedene Mitglieder des Systems zur Ausführung und zum Zugriff durch andere Mitglieder des Systems verfügbar gemacht werden. Einige der Elemente eines Allzweck-Workstation-Computers sind in 1 dargestellt, in der ein Prozessor 1 gezeigt wird, der einen Eingangs/Ausgangs-(„E/A")-Abschnitt 2, eine Zentraleinheit („ZE") 3 und einen Speicherabschnitt 4 hat. Der E/A-Abschnitt 2 ist mit einer Tastatur 5, einer Anzeigeeinheit 6, einer Plattenspeichereinheit 9 und einer CD-ROM-Laufwerkseinheit 7 verbunden. Die CD-ROM-Einheit 7 kann ein CD-ROM-Medium 8 lesen, das normalerweise Programme 10 und Daten enthält. Die Computerprogramm-Produkte, die Mechanismen enthalten, um die Vorrichtung und die Verfahren der vorliegenden Erfindung auszuführen, können in dem Speicherabschnitt 4 oder in einer Plattenspeichereinheit 9 oder auf der CD-ROM 8 eines derartigen Systems vorhanden sein. 2 zeigt ein typisches verteiltes Mehrprozessor-Computersystem, in dem unabhängige Computer 20, 22 und 24 miteinander und möglicherweise mit einer gemeinsam genutzten Speichereinheit 28 über eine Kommunikationsverbindung 26 verbunden sind. 3 zeigt eine typische objektorientierte Client-Server-Anordnung, in dem ein Benutzer 30 eine Clientanwendung 34 auf einem ersten Computer 32 starten kann. Die Client-Anwendung 34 setzt einen Aufruf 40 auf einen Objektverweis 36, der auf eine Implementierung des Objekts (auch als „Zielobjekt" bezeichnet) 46 auf einem zweiten Computer (dem Server) 50 zeigt. Der Aufruf 40 wird an den Kommunikationssteuermechanismus 38 übergeben, der den Aufruf zu dem Server 50, in dem die Objektimplementierung 46 geladen ist, sendet. Dieser Objektimplementierungsmechanismus 46 erzeugt ursprünglich den Objektverweis 36 und macht ihn für Benutzer verfügbar, normalerweise bei der ersten Erzeugung der Objektimplementierung. Nach Abschluss der Aufrufverarbeitung liefert die Objektimplementierung 46 eine Meldung oder die Ergebnisse einer gewünschten Operation über die Kommunikationsverbindung 42 zu den Ursprungs-Clientanwendungen 34. Dieses Client-Server-Modell kann auch in einer Einzelprozessoreinheit funktionieren, in dem die Funktionen des Kommunikationsmechanismus von dem Betriebssystem (62 in 4) ausgeführt werden.
Die hervorstechenden Konzepte des föderierten Namensgebungssystems, die für diese Erfindung von Bedeutung sind, sind:
Jeder Name wird von einem Satz von syntaktischen Regeln erzeugt, die als Namensgebungskonvention bezeichnet werden. Ein atomischer Name ist eine unteilbare Komponentensequenz von einem oder mehr Zeichen, die durch eine Namensgebungskonvention definiert ist. Eine Namensgebungskonvention definiert alle möglichen atomischen Namen. Ein kombinierter Name ist eine Sequenz von einem oder mehr atomischen Namen. Ein zusammengesetzter Name ist eine Sequenz von einem oder mehr kombinierten Namen. Jeder kombinierte Name gehört zu einem verschiedenen Namensgebungssystem.
Ein Kontext ist ein Objekt, das einen Satz von Bindungen mit distinkten atomischen Namen enthält. Jeder Kontext hat eine assoziierte Namensgebungskonvention. Ein Kontext stellt eine Nachschlagungs-(Zergliederungs)-Operation bereit, die einen Verweis auf ein Objekt liefert. Er kann auch Operationen bereitstellen, die Namen binden, die Bindung von Namen aufheben, Namen ändern, gebundene Namen auflisten, Attribute, die mit benannten Objekten assoziiert sind, überprüfen und manipulieren usw.
Ein Namensgebungssystem ist ein zusammenhängender Satz von Kontexten desselben Typs (die dieselbe Namensgebungskonvention haben), die denselben Satz von Operationen mit identischen Semantiken bereitstellen.
Ein föderiertes Namensgebungssystem ist ein Satz von autonomen Namensgebungssystemen, die durch eine Standardschnittstelle kooperieren, um Namenszergliederung von zusammengesetzten Namen zu implementieren. Damit ist ein föderiertes Namensgebungssystem ein zusammenhängender Satz von Kontexten, die mehr als ein Namensgebungssystem umfassen. Die Verbindung zwischen zwei Namensgebungssystemen in einer Föderation kann unter Verwendung des Begriffs eines Nächstes-Namensgebungssystem-Zeigers ausgedrückt und implementiert werden. Ein Nächstes-Namensgebungssystem-Zeiger enthält Verweisinformationen darüber, wie das nächste Namensgebungssystem in der Föderation erreicht wird.
Namensgebungssysteme in einer Föderation sind durch Namensgebungssystemgrenzen getrennt. Zusammengesetzte Namen werden verwendet, um Objekte in einem föderierten Namensgebungssystem zu benennen. Die Begriffe starke Trennung und schwache Trennung werden verwendet, um zu beschreiben, wie Namen von verschiedenen Namensgebungssystemen in einer Föderation innerhalb eines zusammengesetzten Namens syntaktisch getrennt sind, d. h. sie geben an, wo die Namensgebungssystemgrenzen liegen. Bei starker Trennung wird das Trennzeichen von zusammengesetzten Komponentennamen verwendet, um die Namensgebungssystemgrenze anzugeben. Bei schwacher Trennung gibt das Trennzeichen von zusammengesetzten Komponentennamen nicht notwendigerweise eine Namensgebungssystemgrenze an; die Namensgebungssystemgrenze wird im Verlauf der Zergliederung dynamisch bestimmt (wobei von dynamischer schwacher Trennung gesprochen wird) oder statisch durch die Verwendung von syntaktischen Regeln, die zu einem Namensgebungssystem gehören (was als statische schwache Trennung bezeichnet wird). Starke oder schwache Trennung sind Eigenschaften eines bestimmten Namensgebungssystems. Starke und schwach getrennte Namensgebungssystems können innerhalb einer einzelnen Föderation zusammen existieren.
Da dieses Konzept eines Namensgebungs-Kontexts grundlegend für die allgemeine Vorstellung von Namensgebungssystemen ist, werden jetzt mehrere verschiedene Ansichten des Konzepts von Kontexten veranschaulicht. Jetzt Bezug nehmend auf 5, wird ein Kontextobjekt dargestellt. Gezeigt wird das Kontextobjekt 382, das verschiedene Verfahren 386 und einen Status 384, der eine Liste von Namen, die an Objektverweise gebunden sind, enthält. Die Objektverweise können auf ein Objekt wie das Objekt 394 zeigen oder sie können auf andere Kontextobjekte 388, 396 zeigen, die selbst ähnliche Operationen (Verfahren) und Status haben, die Namen enthalten, die an andere Verweise gebunden sind, wie beispielsweise diejenigen in Objekt 396, die auf Objekt 392 zeigen, und diejenigen in Kontextobjekt 388, die auf Objekt 390 zeigen. Es sollte verstanden werden, dass diese Objekte 394, 392 und 390 Implementierungen der Objekte sind, deren Standorte durch die Verweise, die an die Objektnamen gebunden sind, angegeben werden.
Jetzt Bezug nehmend auf 6, wird eine alternative Ansicht eines Kontextobjekts dargestellt 400. Das Kontextobjekt 400 enthält eine Tabelle 401, die einen Satz von Name-zu-Objektverweis-Assoziationen (auch als Namens-Bindungen bezeichnet) verwaltet. In der bevorzugten Ausführungsform haben Namen nur in dem Kontext, in dem sie verwendet werden, Bedeutung. Damit kann ein Objektverweis gleichzeitig an mehrere verschiedene Namen in mehreren verschiedenen Kontextobjekten gebunden sein. Ein Client eines typischen Namensgebungsdienstes führt Namengebungsoperationen durch Verfahren aus, die in einer Verfahrenstabelle 403 des Kontextobjekts 400 identifiziert sind. In der bevorzugten Ausführungsform hat ein Kontextobjekt beispielsweise Verfahren zum Nachschlagen 408 des Namens eines Objekts, das heißt zum Nachschlagen des Objektverweises, der an den gegebenen Namen innerhalb eines Kontexts gebunden ist; zum Binden 406 eines Namens an ein Objekt, wodurch ein Name mit dem Verweis auf ein Objekt assoziiert wird; zum Auflisten 405 der Namen und assoziierten Verweise; usw.
Wie in 5 angegeben, können Kontextobjekte auf andere Kontextobjekte zeigen; das heißt, ein Name in einem Kontextobjekt kann an den Verweis eines zweiten Kontextobjekts gebunden sein. Binden eines Kontextobjekts innerhalb eines anderen Kontextobjekts erzeugt einen Namensgebungsgraphen, der ein gerichteter Graph mit Knoten und bezeichneten Stecken ist, wobei die Knoten mit herausgehenden Strecken Kontexte sind. Wenn eine Strecke zu einem Kontext in einem anderen Namensgebungssystem führt, erzeugt dies einen Namensgebungsgraphen, der mehrere Namensgebungssysteme umfasst. Anders ausgedrückt, ist Namensraum-Zusammensetzung oder die Erzeugung eines föderierten Namensraums, in dem ein Namensraum an einem anderen Namensraum angefügt ist, erfolgt.
NAMENSGEBUNGSDIENSTANBIETER
Verschiedene Namensgebungssysteme verwenden verschiedene Mechanismen, um Kontextobjekte aneinander zu binden und um Objektnamen auf geeignete Objektimplementierungen abzubilden. Der Mechanismus, der verwendet werden, um die Schnittstelle zwischen einem Client und dieser Namensgebungsstruktur bereitzustellen, ist der Namensgebungsdienstanbieter. In 7 ist eine funktionale Beziehung 800 zwischen diesen Elementen dargestellt. Die Anwendung (der Client) 802 führt normalerweise einen Aufruf eines Kontextobjekts aus. Dieser Aufruf 804 enthält einen Namen, die durchzuführende Operation und einen oder mehr zusätzliche Parameter, die von der Operation benötigt werden, beispielsweise „name foo, operation A". Für dieses Beispiel wird angenommen, dass foo ein atomischer Name ist und dass die Operation auf dem durch foo benannte Kontextobjekt auszuführen ist. [Wenn die Operation auf dem vorletzten Objekt (wie es der Fall für Operationen wie Binden ist) und nicht auf dem durch foo benannten Kontext auszuführen ist, würde die folgende Beschreibung eine geringfügige Variation aufweisen. Nämlich dass die Operation A von Kontextobjekt 810 anstatt 820 ausgeführt würde.] Der Aufruf 804 wird normalerweise an den Namensgebungsdienstanbieter 806 gerichtet, der zuerst das gelieferte Kontextobjekt lokalisiert. Er übergibt dann „name foo, operation A" 808 an dieses Kontextobjekt 810. Das Kontextobjekt 810 versucht, den Objektnamen foo in den Standort der Implementierung des Objekts abzubilden. Das Kontextobjekt 810 findet den Namen foo in seiner Namenstabelle 812 gebunden an dem Verweis locn 814 und liefert ihn 816 an den Namensgebungsdienstanbieter 806. Der Namensgebungsdienstanbieter 806 verwendet dann den Verweis locn 814, um einen Zeiger auf die Adresse der Implementierung 820 des Objekts foo zu erzeugen, und übergibt ihn der Operation A 818. Die Kontextimplementierung 820 führt das Verfahren 824 korrespondierend mit der Operation A 822 aus und liefert ein Ergebnis 826 an den Namensgebungsdienstanbieter 806, der das Ergebnis 828 dem aufrufenden Client 802 übergibt, wodurch er die ursprüngliche Operationsaufrufanforderung abschließt. Andere Ausführungsformen sehen für die Kontextimplementierung 820 vor, Ergebnisse der aufgerufenen Operation direkt an die aufrufende Clientanwendung 802 zu liefern. Es wird von Fachleuten anerkannt werden, dass der Namensgebungsdienstanbieter 806 beträchtlich mehr Aktivitäten vollführen kann, wenn mehrere Kontextobjekte in der Abbildung des ursprünglichen Namens auf den Standort der Implementierung involviert sind.
Eine komplexere Situation entsteht, wenn mehrere Namensgebungsdienstanbieter involviert sind. Dies ist der Fall, wenn ein zusammengesetzter Name mehrere Namensgebungssysteme umfasst. Betrachtet werden soll das in 8 gezeigte Beispiel. Das in 8 dargestellte System 900 zeigt ein System, in dem die Clientanwendung 902 einen Aufruf eines Objekts, das einen zusammengesetzten Namen y.x/i:j 904 hat, an Namensgebungsdienstanbieter M 906 ausgibt. Der zusammengesetzte Name y.x/i:j besteht aus zwei Komponenten, y.x und i:j, wobei die erste Komponente y.x ein kombinierter Name aus einem Namensraum ist, der eine von rechts nach links verlaufende, durch Punkte getrennte Syntax hat, während die zweite Komponente i:j ein kombinierter Name aus einem Namensraum ist, der eine von links nach rechts verlaufende, durch Doppelpunkte getrennte Syntax hat.
Der Namensgebungsdienstanbieter M 906 versucht, den Namen y.x/i:j durch Kontextobjekt A 908 zu zergliedern, wobei der Abschnitt x 910 zu dem Verweis 912 zergliedert wird, der auf Kontextobjekt B 914 zeigt. In Kontextobjekt B 914 wird der Namensabschnitt y 916 zu einem Eintrag 918 zergliedert, der ein Verweis auf einen Kontext in einem anderen Namensgebungssystem ist. Da Namensgebungsdienstanbieter nur mit Kontexten innerhalb desselben Namensgebungssystems umgehen können, sendet Kontextobjekt B 914 eine Antwort 920 an Kontextobjekt A 908 und dann 922 an Namensgebungsdienstanbieter M 906, die besagt 924 „Ich kann den Rest des Namens (i:j) nicht zergliedern". In diesem Fall ist der Namensgebungsdienstanbieter N 930 dem Namensgebungsdienstanbieter M 906 nicht bekannt, daher muss dieser eine Meldung 926 an die Clientanwendung 902 zurücksenden, die besagt „Ich kann den angeforderten Namen des Objekts nicht zergliedern". Wenn der Client 902 weiß, wie der zweite Namensgebungsdienstanbieter N 930 aufzurufen ist, kann ein Aufruf vorgenommen werden, um den Rest des zusammengesetzten Namens i:j 928 zu zergliedern. In diesem Beispiel weiß der zweite Namensgebungsdienstanbieter N 930, wie der Rest des Namens zu zergliedern ist, und die aufgerufene Objektimplementierung 958 wird schließlich aufgerufen, und der Aufruf endet erfolgreich.
In dem oben in 8 beschriebenen Beispiel muss der Client 902 jedes Mal, wenn es erforderlich ist, einen weiteren Namensgebungsdienstanbieter zum System hinzuzufügen, modifiziert werden. Er musste wissen, wie der Namensgebungsdienstanbieter N 930 aufgerufen wird, um den Rest des Namens i:j zu zergliedern. Wenn weitere Namensgebungsdienstanbieter hinzugefügt werden, muss der Client modifiziert werden, damit sie ihm bekannt sind. Weiterhin verwaltet der Client 902 außerdem die Aufrufe an die verschiedenen Namensgebungsdienstanbieter. Es ist vorzuziehen, dass die Clientanwendungen und ihre Programmierer sich nicht mit der Handhabung und Verwaltung dieser verschiedenen Namensgebungsdienstanbieter befassen müssen. Es ist dieses Problem, auf das die vorliegende Erfindung gerichtet ist.
Folgend auf die Definitionen, die für die verschiedenen Formen von Namen – atomisch, kombiniert und zusammengesetzt – vorher im Abschnitt „Hintergrund" gegeben wurde, stellt die Erfindung eine föderierte Namensgebungsdienstanbieter-Schnittstelle (FN SPI) für vier (4) Typen (atomischer Name, kombinierter Name, teilweise zusammengesetzter Name und zusammengesetzter Name) bereit, zusammen mit einem Mechanismus, bezeichnet als das föderierte Namensgebungs-Rahmenwerk (FN-Rahmenwerk), das zwischen diesen Schnittstellen und Clients vorhanden ist, um die Übersetzung und Verwaltung von Aufrufen zur Zergliederung von zusammengesetzten Namen zu unterstützen. Dies gestattet es Clientanwendungen, die die föderierte Namensgebungs-API verwenden, die verfügbaren FN SPIs (in einem gegebenen System kann mehr als eine FN SPI vorhanden sein) in geeigneter Weise zu nutzen. Die Ausführungsform erlaubt Systemimplementierern, neue Namensgebungsdienste dynamisch ohne Unterbrechung der Clientanwendungen zu installieren.
Eine Ausführungsform nach der vorliegenden Erfindung ist in 9 dargestellt. 9 zeigt ein System 1000, das das System von 8 darstellt, wie es von dem FN-Rahmenwerk 1004 gehandhabt wird. In System 1000 befindet sich das FN-Rahmenwerk 1004 zwischen der Clientanwendung 1002 und den Namensgebungsdienstanbietern 1012, 1030 und führt sämtliche der Funktionen aus, die erforderlich sind, um zusammengesetzte Namen zu zergliedern, die teilweise Zergliederungen von beiden Namensgebungsdienstanbietern 1012, 1030 erfordern. Es wird Fachleuten dieses Fachgebiets klar sein, dass ein FN-Rahmenwerk 1004, das zur Anbindung mit mehreren Namensgebungsdienstanbietern durch FN SPIs imstande ist, einen beträchtlichen Nutzen für Systeme bieten würde, in denen ein föderiertes Namensgebungssystem implementiert ist, das mehrere disparate Namensgebungsdienste umfasst.
Die Ausführungsform nutzt die Tatsache, dass Namensgebungskontext das grundlegende Namensgebungskonzept ist. Mit jedem benannten Kontextobjekt ist eine Implementierung für es assoziiert – dies wird als die Kontextimplementierung bezeichnet. Jede Kontextimplementierung stellt Operationen (wie Nachschlagen, Binden, Assoziieren und Überprüfen von Attributen usw.) bereit, die funktional äquivalent zu denen in der Kontextschnittstelle sind (siehe das oben beschriebene US-Patent Nr. 5377323). Die Kontextimplementierung macht diese Operationen durch eine föderierte Namensgebungsdienstanbieter-Schnittstelle (FN SPI) verfügbar, die ein Vertrag zwischen dem FN-Rahmenwerk und der Kontextimplementierung ist. Es gibt, abhängig von den Fähigkeiten der Kontextimplementierung, vier Arten von FN SPIs, so dass unterschiedliche Anforderungen von Namensgebungsdiensten angemessen erfüllt werden. Diese vier Arten von FN SPIs sind:
SPI für zusammengesetzte Namen
SPI für teilweise zusammengesetzte Namen
SPI für kombinierte Namen
SPI für atomische Namen
Operationen, die zusammengesetzte Namen enthalten, erfordern die Zergliederung von zusammengesetzten Namen. Das FN-Rahmenwerk gestattet die Zergliederung von zusammengesetzten Namen durch verschiedene Kontexte, möglicherweise durch verschiedene Namensgebungssysteme, durch die Verwendung der Kontextimplementierungen, die mit den einzelnen beteiligten Kontexten assoziiert sind. Assoziation zwischen einem Namen und seinem Kontext-Handle erfolgt in der folgenden Weise. Die FN API stellt eine Operation (OpenLookup) bereit, die den an einen Namen gebundenen Verweis liefert. Jede FN SPI enthält eine Operation constructor(), die das FN-Rahmenwerk aufruft (für jede Kontextimplementierung), um einen Kontext-Handle zu dem Kontext zu erhalten (Objekt-Handles und Konstruktoren werden in dem vorher erwähnten Text „Object-oriented Software Construction" von Bertrand Meyer, Prentice-Hall 1988, beschrieben.) Unter Verwendung dieses Verweises lädt das FN-Rahmenwerk die mit dem Verweis assoziierte Kontextimplementierung und ruft die Operation constructor() daraus auf. An diesem Punkt hat das FN-Rahmenwerk einen Kontext-Handle zu einem Kontextobjekt. Das FN-Rahmenwerk verwaltet die Zergliederung zusammengesetzter Namen durch abwechselnde Zergliederung einer Komponente (von Komponenten) des zusammengesetzten Namens und anschließendem Erlangen eines Kontext-Handles zu dem durch die Komponente(n) benannten Kontextobjekt. Schließlich sind alle Komponenten des zusammengesetzten Namens verbraucht und der Zielkontext, mit dem die Zieloperation erfolgen soll, ist erreicht. Das FN-Rahmenwerk ruft dann die Zieloperation mit dem Zielkontext auf (mit für diese Operation geeigneten Argumenten) und liefert die Ergebnisse des Aufrufs an die Clientanwendung. In der bevorzugten Ausführungsform veranschaulicht das Folgende ein Codefragment davon, wie der Konstruktor aufgerufen werden könnte: ctx = constructor(reference)wobei
ctx ein Handle zu einem Kontextobjekt ist
reference ein Verweis ist, der durch Nachschlagen eines Namens erhalten wurde
(dies wird ausführlicher im nachstehenden Abschnitt „Kontextimplementierungs-Bindung" diskutiert).
Die folgende Diskussion beschreibt die drei wesentlichen Komponenten der Ausführungsform:

– die FN SPI,
– das FN-Rahmenwerk,
– Kontextimplementierungs-Bindung.

B. DIE FÖDERIERTE NAMENSGEBUNGSDIENSTANBIETER-SCHNITTSTELLE
Die föderierte Namensgebungsdienstanbieter-Schnittstelle (FN SPI) stellt eine vereinfachte Weise für Namensgebungs- und Verzeichnisdienstanbieter bereit, um ihre Namensgebungs- und Verzeichnisoperationen in die Operationen des föderierten Namensgebungssystems zu inkorporieren. Namensgebungsdienstanbieter sind von Kenntnissen über andere Namensgebungsdienstanbieter in demselben System isoliert und brauchen nur Operationen bereitzustellen, die in der SPI, die sie verwenden, definiert sind.
Wie oben beschrieben, enthält jede FN SPI eine Operation constructor(), die jede Kontextimplementierung bereitstellen muss.
Jede Operation in der FN SPI hat ein Argument status, das durch die Kontextimplementierung gesetzt wird. Alle Kontextimplementierungen setzen das Argument status in der folgenden Weise. Wenn die Operation von dem FN-Rahmenwerk fortzusetzen ist, muss die Kontextimplementierung status (oder den Statuscode) auf CONTINUE setzen und die folgenden zwei Felder des Statusobjekts wie folgt einstellen:
rref (das Feld für den zergliederten Verweis) ist ein Verweis auf den Kontext, in dem die Operation fortzusetzen ist.
rname (das Feld für den restlichen Namen) wird auf den Namen gesetzt, der in dem Kontext zu verarbeiten ist, auf den rref zeigt.
Diese Informationen gestatten es dem FN-Rahmenwerk, die Verarbeitung des zusammengesetzten Namens bis zum Abschluss fortzusetzen.
Nachfolgend werden die vier Arten von FN SPIs jeweils beschrieben.
SPI FÜR ZUSAMMENGESETZTE NAMEN
Namensgebungsdienstanbieter, die die Zergliederung vollständiger zusammengesetzter Namen handhaben wollen, sollten die SPI für zusammengesetzte Namen bereitstellen. Die Kontextimplementierung stellt eine Implementierung für die Kontextschnittstelle (ctx_lookup(), ctx_bind(), ctx_unbind() und so weiter) direkt bereit und muss imstande sein, die Zergliederung vollständiger zusammengesetzter Namen über jede Namensgebungssystemgrenze zu handhaben und die Antwort an den Client zu liefern.
SPI FÜR TEILWEISE ZUSAMMENGESETZTE NAMEN
Die SPI für zusammengesetzte Namen erforderte, dass der zugrunde liegende Kontextimplementierungsanbieter seine Operationen bis zu ihrem Abschluss ausführt, selbst wenn das rekursive Auswertung erfordert. Das rekursive Modell ist ein praktisches für den Client, aber rekursive Auswertung ist nicht immer wünschenswert oder möglich. Die SPI für teilweise zusammengesetzte Namen sollte Namensgebungsdienstanbieter bereitstellen, die einen zusammengesetzten Namen nur teilweise zergliedern wollen.
Kontextimplementierungen, die die SPI für teilweise zusammengesetzte Namen anbieten, stellen Implementierungen für Operationen an teilweise zusammengesetzten Namen bereit. Derartige Kontextimplementierungen müssen einen zusammengesetzten Namen nicht vollständig handhaben. Verbleibende unbenutzte Komponenten des zusammengesetzten Namens werden von der Kontextimplementierung zusammen mit Statusinformationen, die angeben, wie die Operation fortgeführt werden sollte, an das FN-Rahmenwerk zurückgegeben. Das FN-Rahmenwerk (nachstehend ausführlich beschrieben) interpretiert dann diese Statusinformationen und ruft den nächsten Namensgebungsdienstanbieter zur Fortsetzung der Operation auf.
Die SPI für teilweise zusammengesetzte Namen definiert einen Satz von Operationen (p_lookup(), p_list_names() usw.), die die Operationen in der von dem FN-Rahmenwerk zu benutzenden Kontextschnittstelle spiegeln. 11 zeigt eine beispielhafte Zergliederung eines teilweise zusammengesetzten Namens. Operationen mit dem Präfix „p_" (z. B. p_lookup()) werden für einen Kontext ctx aufgerufen und nehmen als Eingabe einen zusammengesetzten Namen, name, und liefern <operation results> und status. Wenn eine Operation p_ die Operation nicht abschließt und erfordert, dass die Operation in einem anderen Kontext fortgesetzt wird, stellt sie das Objekt status mit den folgenden Informationen ein:

– Statuscode auf CONTINUE setzen, um anzuzeigen, dass die Operation fortzusetzen ist
– den verbliebenen Namensteil (rname) in status als Teil von name einsetzen, der weitere Bearbeitung erfordert
– den zergliederten Verweisteil (rref) in status als Verweis des bis dahin zergliederten Namens einsetzen.

Die Statusinformation wird von der Kontextimplementierung an das FN-Rahmenwerk geliefert, die das Argument name als rname aktualisiert und ctx als Kontext-Handle des durch rref identifizierten Kontexts aktualisiert. Die aktualisierten Argumente name und ctx werden dann zur Fortsetzung der Operation p_ verwendet. (Dies wird nachstehend ausführlicher bei der Diskussion des FN-Rahmenwerks beschrieben.) Wenn die Operation p_ nicht fortgesetzt werden muss (weil sie entweder erfolgreich geendet oder fehlgeschlagen ist), werden die Ergebnisse an die Clientanwendung geliefert.
SPI FÜR KOMBINIERTE NAMEN
Die SPI für teilweise zusammengesetzte Namen erforderte, dass die zugrunde liegende Kontextimplementierung sich mit zusammengesetzten Namen befasst, die Namen von mehr als einem Namensgebungssystem umfassen. Namensgebungsdienstanbieter, die nur mit Namen von einem einzelnen Namensgebungssystem umgehen können, sollten die SPI für kombinierte Namen bereitstellen.
Die SPI für kombinierte Namen ist für Namensgebungsdienstanbieter vorgesehen, die sich nur mit Namen von einem einzelnen Namensgebungssystem befassen wollen. Wie die SPI für teilweise zusammengesetzte Namen definiert die SPI für kombinierte Namen einen Satz von Operationen (c_lookup(), c_listnames() usw.), die die Kontextoperationen spiegeln, außer dass die Operationen in der SPI für kombinierte Namen mit kombinierten Namen operieren.
Für Kontextimplementierungen, die statische schwache Trennung unterstützen, muss die Implementierung eine zusätzliche Operation zur Bestimmung, welche anfänglichen Komponenten des eingegebenen Namens zu dem Namensgebungssystem gehören, bereitstellen. Die restlichen Komponenten, die von dem Namensgebungssystem nicht verwendet werden, werden in einem anderen Parameter an die Operation zurückgegeben. In der bevorzugten Ausführungsform wird diese Operation als p_component_parser() bezeichnet. Das folgende Codefragment veranschaulicht, wie sie aufgerufen werden könnte. compound_name = ctx->p_component_parser(name, &rest; &pstatus):wobei

– name der kombinierte Name ist, der aufgetrennt werden soll,
– compound_name die anfänglichen Komponenten des kombinierten Namens, name, sind, die durch die Kontexte dieses Namensgebungssystems verarbeitet werden sollen,
– rest die Komponenten von name sind, die für das nächste Namensgebungssystem übrig gelassen werden, falls vorhanden, und
– pstatus ein Statusparameter ist, der den Ausführungsstatus der Implementierung p_component_parser() angibt.

Beispielsweise soll angenommen werden, dass ein Kontext statische schwache Trennung unter Verwendung einer syntaktischen Richtlinie unterstützt, dass jede Komponente, die zu seinem Namensraum gehört, ein Gleichheitszeichen („=") aufweisen muss. Diese Kontextimplementierung stellt eine Implementierung für p_component_parser() bereit, die, wenn ihr ein kombinierter Name wie a = b/c = d/e/f/g: compound_name = ctx->p_commponent_parser("a = b/c = d/e/f/g", &rest, &pstatus): zugeführt wird, „a = b/c = d" in compound_name und „e/f/g" in rest liefert.
Ein endständiges Namensgebungssystem kann nach sich kein nächstes Namensgebungssystem haben. Sobald eine Operation dieses Namensgebungssystem erreicht, tritt sie nicht in ein weiteres Namensgebungssystem in der Föderation ein. Wenn ein Namensgebungssystem zum Bestandteil einer Föderation von Namensgebungssystemen wird, muss es, außer wenn es ein endständiges Namensgebungssystem ist, die Vorstellung unterstützen, als ein zwischenliegendes Namensgebungssystem zur Zergliederung von zusammengesetzten Namen verwendet zu werden. Das heißt, es muss einen Mechanismus zum Binden und Nachschlagen der Wurzel von anderen Namensräumen bereitstellen. In der bevorzugten Ausführungsform dieser Erfindung wird dieser Mechanismus als der Nächstes-Namensgebungssystem-Zeiger bezeichnet. Verschiedene Namensgebungssysteme haben verschiedene Weisen zur Unterstützung des Nächstes-Namensgebungssystem-Zeigers. Beispielsweise kann ein Namensgebungssystem Nächstes-Namensgebungssystem-Zeiger unterstützen, indem es ihnen spezielle Namen gibt und sie innerhalb desselben Namensgebungssystems speichert, während ein anderes Komponenten-Namensgebungssystem einen separaten Dienst haben kann, der sich speziell mit Nächstes-Namensgebungssystem-Zeigern befasst.
Zusätzlich zu den Schnittstellen c definiert die SPI für kombinierte Namen einen zusätzlichen Satz von Operationen (c_lookup_nns(), c_listnames_nns() usw.), die die Kontextoperationen spiegeln, um den Nächstes-Namensgebungssystem-Zeiger zu manipulieren. Die Operationen „nns" nehmen einen kombinierten Namen als Argument, operieren aber mit dem Nächstes-Namensgebungssystem-Zeiger, der mit dem Namen assoziiert ist, anstatt mit dem Namen selbst. 12 veranschaulicht den Unterschied zwischen normalen Kontextoperationen der SPI für kombinierte Namen und nns-Operationen der SPI für kombinierte Namen. Ein Aufruf von

ctx->c_lookup("A/B",&status) resultiert in der Zurückgabe des Verweises, der an den kombinierten Namen "A/B" gebunden ist, während ein Aufruf von
ctx->c_lookup_nns("A/B", &status) in der Zurückgabe des Verweises resultiert, der an den Nächstes-Namensgebungssystem-Zeiger von "A/B" gebunden ist.

SPI FÜR ATOMISCHE NAMEN
Die SPI für kombinierte Namen erfordere Kontexte zum Umgang mit kombinierten Namen. Namensgebungsdienstanbieter, die nur mit atomischen Namen umgehen können, sollten die SPI für atomische Namen bereitstellen.
Die SPI für atomische Namen definiert einen Satz von Operationen (a_lookup(), a_listnames() usw.), die die Kontextoperationen für Operationen mit atomischen Namen spiegeln. Zusätzlich enthält die SPI für atomische Namen außerdem einen Satz von Operationen zum Umgang mit einem etwaigen Nächstes-Namensgebungssystem-Zeiger, der mit dem atomischen Namen assoziiert ist (a_lookup_nns(), a_listnames_nns() usw.).
Der Namensgebungsdienstanbieter, der eine atomische SPI enthält, befasst sich mit der Zergliederung innerhalb eines einzelnen Kontexts, der den grundlegenden Baustein für einen hierarchischen Namensgebungsdienst bildet. Eine Kontextimplementierung, die die SPI für atomische Namen vorsieht, stellt Implementierungen für Operationen mit atomischen Namen und etwaigen Nächstes-Namensgebungssystem-Zeigern, die mit dem atomischen Namen assoziiert sind, bereit.
Eine Kontextimplementierung, die die atomische SPI vorsieht, erwartet, dass ihr eingegebener Name eine einzelne Zeichenfolge ist, die den Namen repräsentiert, der zu zergliedern ist oder mit dem in dem Zielkontext eines Namensgebungssystems zu operieren ist. Anders ausgedrückt, kann der eingegebene Name nicht mehr als einen Kontext umfassen.
Eine Kontextimplementierung, die starke Trennung (siehe frühere Definitionen) unterstützt, muss eine zusätzliche Operation, c_component_parser(), zum Zergliedern eines kombinieren Namens in Kopf-/Schlusskomponenten unter Verwendung der Namensgebungskonvention für das jeweilige Namensgebungssystem bereitstellen. (Siehe US-Patent Nr. 5377323, das hierin vollständig durch Literaturhinweis eingefügt ist, für eine Beschreibung des Protokolls zum Zergliedern eines kombinierten Namens in Kopf-/Schlusskomponenten.) Die Eingabe für c_component_parser() ist der kombinierte Name, dessen erste Komponente in dem Zielkontext zu zergliedern ist. Die Ausgaben sind die erste Komponente, head, und der Rest der Komponenten, tail, die in separaten Argumenten zurückgegeben werden. Das folgende Codefragment veranschaulicht, wie sie aufgerufen werden könnte. head = ctx->c_component_parser(compound_name, &tail, &cstatus);wobei
compound_name der kombinierte Name ist, der zu zergliedern ist,
head der erste atomische Namen in compound_name nach der Namensgebungskonvention dieses Kontexts, ctx, ist,
tail der geordnete Rest der atomischen Namen in compound_name außer head ist, und
cstatus ein Status ist, der den Erfolg oder das Fehlschlagen der Operation c_component_parser() angibt.
Beispielsweise soll angenommen werden, dass i:j:k ein kombinierter Name aus einem Namensraum ist, der eine von links nach rechts verlaufende, durch Doppelpunkte getrennte Namenssyntax aufweist. Die Kontextimplementierung für dieses Namensgebungssystem stellt eine Implementierung für c_component_parser() bereit. Wenn Folgendes ausgeführt wird, head = ctx->c_component_parser("i:j:k", &tail, &cstatus);enthält head „i", während tail, „j:k" enthalten wird.
Eine Kontextimplementierung, die statische schwache Trennung unterstützt, muss eine Routine c_component_parser() (oben beschrieben) zum Zergliedern eines zusammengesetzten Namens in die Komponenten von zuerst compound_name und dann rest vorsehen.
Wie das FN-Rahmenwerk mit Kontexten interagiert, die die SPI für atomische Namen exportieren, ist ausführlich im Abschnitt „DAS FÖDERIERTE NAMENSGEBUNGS-RAHMENWERK" beschrieben.
ZUSAMMENFASSUNG VON SPIs
Zusammengefasst sind die Alternativen für einen Namensgebungsdienstanbieter zum Föderieren unter Verwendung der vorliegenden Erfindung:

(1) Bereitstellung von Implementierungen für die Operationen in der SPI für zusammengesetzte Namen für einen Namensgebungsdienst, der für zusammengesetzte Namen sensitiv ist, der imstande ist, mit jedem zusammengesetzten Namen in seiner Gesamtheit umzugehen.
(2) Bereitstellung von Implementierungen für die Operationen in der SPI für teilweise zusammengesetzte Namen für einen Namensgebungsdienst, der für zusammengesetzte Namen sensitiv ist, der imstande ist, mit Namen von möglicherweise mehr als einem Namensgebungssystem umzugehen, aber nicht notwendigerweise in ihrer Gesamtheit.
(3) Bereitstellung von Implementierungen für die Operationen in der SPI für kombinierte Namen für einen Namensgebungsdienst, der nicht für zusammengesetzte Namen sensitiv ist. Die Implementierung nimmt einen kombinierten Namen an und fuhrt die Kontextoperation mit ihm durch.
(4) Bereitstellung von Implementierungen für die Operationen in der SPI für atomische Namen für einen atomischen Namensgebungsdienst, der der Baustein eines hierarchischen Namensgebungsdienstes ist. Die Implementierung nimmt einen atomischen Namen an und führt die Kontextoperation mit ihm durch.

C. DAS FÖDERIERTE NAMENSGEBUNGS-RAHMENWERK
Das zweite wesentliche Element der Ausführungsform ist das FN-Rahmenwerk, das als Block 1108 in 10 dargestellt ist. Es ist dieses Element, das die Aufgabe hat, zuzulassen, dass neue und beliebige Namensgebungs- und Verzeichnissysteme Anwendungen zur Laufzeit verfügbar gemacht werden, ohne dass Neukompilierung, Neueinbindung oder Anhalten der Anwendungen erforderlich ist. Wie nachfolgend beschrieben, stellt das FN-Rahmenwerk die Infrastruktur bereit, in die die oben beschriebenen verschiedenen FN-SPI-kompatiblen Kontextimplementierungen integriert werden können, und stellt Clientanwendungen die Schnittstelle bereit, die die Hinzufügung eines neuen Namensgebungsdienstes für sie transparent machen kann.
Das FN-Rahmenwerk gestattet es, dass verschiedene Implementierungen, die verschiedene FN SPIs bereitstellen, gleichzeitig auf einer Client-Maschine existieren, und ermöglicht es dadurch einer Clientanwendung, auf verschiedene Mitglieder einer Föderation von Namensgebungsdiensten zuzugreifen. Ein Beispiel der Verwendung der Ausführungsform ist in 10 dargestellt. In 10 umfasst das System 1100 eine Clientanwendungen-Schicht 1104, die imstande ist, zusammengesetzte Namen 1102 zu handhaben, und die mit einer föderierten Namensgebungs-Anwendungsprogrammierungs-Schnittstellen-(„FN API")-Schicht 1106 angebunden ist, die sich an der Oberseite einer föderierten Namensgebungs-Rahmenwerk-Schicht 1108 befindet, an die verschiedene Kontextimplementierungen für spezifische Namensgebungsdienste 1110, 1112, 1114, von denen jede eine designierte FN SPI verwendet, angebunden werden können. Die Kontextimplementierung 1110 repräsentiert die Abbildung einer FN SPI auf XDS, einer Schnittstelle für exklusive Unterstützung des X.500-Verzeichnisdienstes 1116. Diese Kontextimplementierung 1110 unterstützt statische schwache Trennung und stellt die SPI für kombinierte Namen bereit. Gleichermaßen repräsentiert die Kontextimplementierung 1112 die Abbildung einer FN SPI auf die Internet-DNS-Zerlegungs-API, einer Schnittstelle für exklusive Unterstützung der Internet-DNS. Die Kontextimplementierung 1112 unterstützt starke Trennung und stellt die SPI für kombinierte Namen bereit. Und die Kontextimplementierung 1114 repräsentiert die Abbildung einer FN SPI auf die NIS + API, einer Schnittstelle für exklusive Unterstützung von NIS+. Die Kontextimplementierung 114 unterstützt starke Trennung und stellt die SPI für kombinierte Namen bereit.
13a veranschaulicht den Prozess, der von dem FN-Rahmenwerk eingesetzt wird, um Eingabe von der Clientanwendung zu übernehmen, und zur Interaktion mit den entsprechenden FN SPIs, um die von der Clientanwendung angeforderte Operation mit dem zusammengesetzten Namen durchzuführen.
Jetzt Bezug nehmend auf 13a, stellt die Clientanwendung dem FN-Rahmenwerk 1302 Eingabe bereit, die aus einem Kontext-Handle, einem zusammengesetzten Namen, der durchzuführenden Operation und einem oder mehr zusätzlichen Argumenten, die von der Operation (ctx, name, operation A. args) 1304 benötigt werden, bereit. Das FN-Rahmenwerk lädt zuerst die Kontextimplementierung, auf die der Kontext-Handle ctx weist, und ermittelt, welche FN SPI von ctx 1306, 1316, 1340 und 1346 unterstützt wird.
INTERAKTIONEN DES FN-RAHMENWERKS MIT DER SPI FÜR ZUSAMMENGESETZTE NAMEN
Wenn die Kontextimplementierung die SPI für zusammengesetzte Namen 1308 unterstützt, ruft das FN-Rahmenwerk die Operation (ctx_) in der Kontextimplementierung für ctx entsprechend für operation A. auf und versorgt sie mit den Argumenten für die Operation (name, args) 1310. Die Ergebnisse der Durchführung dieser Operation werden an die Clientanwendungen 1312 geliefert.
Betrachtet werden soll das folgende Beispiel für eine Kontextimplementierung, die die SPI für zusammengesetzte Namen bereitstellt.

name ist "a = b/c = d/e/f/g" (das zwei Namensgebungssysteme umfasst: "a = b/c = d" gehört zu einem Namensgebungssystem und "e/f/g" gehört zu einem anderen Namensgebungssystem),
operation A ist "lookup()"
args ist leer (weitere Argumente sind nicht vorhanden).

Das FN-Rahmenwerk stellt die Argumente ("a = b/c = d/e/f/g", "lookup()", {}) der Kontextimplementierung (CC1) von ctx bereit. CC1 führt die Operation ctx_lookup() für den zusammengesetzten Namen "a = b/c = d/e/f/g" wie folgt durch: ref = ctx->ctx_lookup("a = b/c = d/e/f/g", &status);und liefert das Ergebnis dieser Operation (ref) an das FN-Rahmenwerk, das das Ergebnis wiederum an die Clientanwendung liefert.
Das obige Beispiel veranschaulicht, wie das FN-Rahmenwerk eine Kontextimplementierung CC1 anwandte, um eine Operation mit einem zusammengesetzten Namen durchzuführen, der zwei Namensgebungssysteme umfasste. CC1 verwendete die SPI für zusammengesetzte Namen, daher wird von ihr erwartet, dass sie den zusammengesetzten Namen in seiner Gesamtheit verarbeitet, selbst wenn der zusammengesetzte Name mehrere Namensgebungssysteme umfasst. Weder die Clientanwendung, die das FN-Rahmenwerk verwendete, noch das FN-Rahmenwerk selbst verfügte über irgendwelche eingebauten Kenntnisse über CC1. Das FN-Rahmenwerk verwendete die SPI für zusammengesetzte Namen, um mit CC1 zu kommunizieren.
INTERAKTIONEN DES FN-RAHMENWERKS MIT DER SPI FÜR TEILWEISE ZUSAMMENGESETZTE NAMEN
Wenn die Kontextimplementierung die SPI für teilweise zusammengesetzte Namen 1318 unterstützt, ruft das FN-Rahmenwerk die Operation (p_) in der Kontextimplementierung für ctx entsprechend für operation A. auf und versorgt sie mit den Argumenten für die Operation (name, args) 1320. Die Kontextimplementierung liefert die Ergebnisse des Aufrufs der Operation p_ und status 1322 an das FN-Rahmenwerk. Wenn der Status der Operation 1324 nach der Rückkehr von der Operation p_ angibt, dass die Operation so weit verlaufen ist, wie sie konnte (entweder erfolgreich oder konnte nicht fortgesetzt werden) 1334, liefert das FN-Rahmenwerk die Ergebnisse der Operation an die Clientanwendung 1312. Wenn der Status angibt, dass die Operation fortgesetzt werden muss 1326, extrahiert das FN-Rahmenwerk Informationen von status 1328, um die Operation fortzusetzen. Das Objekt status enthält:

– rname: der restliche Teil von name, der noch nicht verarbeitet wurde, und
– rref: der Verweis des Kontexts zur Fortsetzung der Operation.

Das FN-Rahmenwerk verwendet rname zur Aktualisierung von name. Anders ausgedrückt, wird rname effektiv das neue Argument name, das in der nächsten Iteration durch das FN-Rahmenwerk zu verwenden ist. Das FN-Rahmenwerk verwendet außerdem rref von dem Statusobjekt, um einen neuen Kontext-Handle, ctx_new, zu konstruieren. ctx_new wird durch Aufrufen der Operation constructor(), die durch die mit rref 1330 assoziierte Kontextimplementierung bereitgestellt wird, erzeugt. ctx wird aktualisiert, um ctx_new zu sein, und wird effektiv das neue Argument ctx, das in der nächsten Iteration durch das FN-Rahmenwerk zu verwenden ist. Das FN-Rahmenwerk wiederholt dann die Prozedur zur Bestimmung, welche FN SPI die Kontextimplementierung des neuen ctx unterstützt 1332, und übergibt dann die neuen Argumente (name, operation A, args) an die neue Kontextimplementierung.
Zur Veranschaulichung des Obigen soll das folgende Beispiel für eine Kontextimplementierung (PC1), die die SPI für teilweise zusammengesetzte Namen bereitstellt, betrachtet werden.

Das FN-Rahmenwerk stellt die Argumente ("a = b/c = d/e/f/g", "lookup()", {}) der Kontextimplementierung (PC1) von ctx bereit. PC1 führt die Operation p_lookup() für den zusammengesetzten Namen "a = b/c = d/e/f/g" wie folgt durch: ref = ctx->p_lookup("a = b/c = d/e/f/g", &status);und liefert das Ergebnis dieser Operation (ref) an das FN-Rahmenwerk.
Für dieses Beispiel soll angenommen werden, dass PC1 "a = b/c = d" verarbeitet und einen Status CONTINUE an das FN-Rahmenwerk liefert. Zusätzlich liefert sie zwei Statusinformationen:

– rname – der restliche Name ("e/f/g")
– rref – der Verweis des Kontexts zur Fortsetzung der Operation (Verweis an "a = b/c = d" gebunden).

Das FN-Rahmenwerk verwendet rref, um die zu verwendende Kontextimplementierung (PC2) zu identifizieren, und ruft die Implementierung constructor() von PC2 auf, um einen neuen Kontext-Handle, ctx_new, zu konstruieren. Das FN-Rahmenwerk ersetzt den alten Wert von ctx durch ctx_new. Das FN-Rahmenwerk ersetzt außerdem den alten Wert von name durch rname. Das FN-Rahmenwerk verfügt jetzt über ausreichende Informationen, um den Prozess fortzusetzen.
Es soll angenommen werden, dass der neue ctx auch die SPI für teilweise zusammengesetzte Namen exportiert. Das FN-Rahmenwerk stellt ("e/f/g", "lookup()", {} für PC2 bereit. PC2 führt p_lookup() mit dem zusammengesetzten Namen "e/f/g" wie folgt durch: ref = ctx->p_lookup("e/f/g", &status);
Für dieses Beispiel soll angenommen werden, dass diese Operation an dieser Stelle erfolgreich endet. PC2 liefert den an "e/f/g" gebundenen Verweis (ref) an das FN-Rahmenwerk, das ihn an die Clientanwendung liefert.
Das obige Beispiel veranschaulicht, wie das FN-Rahmenwerk zwei Kontextimplementierungen, PC1 und PC2, die beide die SPI für teilweise zusammengesetzte Namen verwendeten, einsetzte, um eine Operation mit einem zusammengesetzten Namen durchzuführen, der zwei Namensgebungssysteme umfasste. Weder die Clientanwendung, die das FN-Rahmenwerk verwendete, noch das FN-Rahmenwerk selbst verfügte über irgendwelche eingebauten Kenntnisse über PC1 oder PC2. Das FN-Rahmenwerk verwendete die SPI für teilweise zusammengesetzte Namen, um sowohl mit PC1 als auch mit PC2 zu kommunizieren.
INTERAKTIONEN DES FN-RAHMENWERKS MIT DER SPI FÜR KOMBINIERTE NAMEN
Wenn die Kontextimplementierung die SPI für kombinierte Namen 1340 unterstützt, führt das FN-Rahmenwerk den von der Engine der SPI für kombinierte Namen 1342 beschriebenen Algorithmus aus (dieser ist detailliert in 13b dargestellt). Die Ausgabe der Engine sind das Ergebnis der Operation und status 1344. Wenn status gleich CONTINUE ist 1326, konstruiert das FN-Rahmenwert einen neuen Wert für name unter Verwendung des Felds mit dem restlichen Namen (rname) von status 1328. Dann extrahiert es rref von status, um einen Kontext-Handle new_ctx zu konstruieren, und ersetzt den alten Inhalt von ctx dadurch. Das FN-Rahmenwerk wiederholt den Prozess dann von Anfang an 1332 unter Verwendung des revidierten name und Kontext-Handles ctx. Wenn status nicht gleich CONTINUE ist 1334, kehrt das FN-Rahmenwerk zurück 1312.
Jetzt Bezug nehmend auf 13b, führt das FN-Rahmenwerk den Algorithmus, der durch die Engine der SPI für kombinierte Namen 1400 (Block 1342 in 13a) beschrieben wird, mit der Eingabe (ctx, name, operation A und args) aus 1404, wenn die Kontextimplementierung die SPI für kombinierte Namen unterstützt. In 13b muss das FN-Rahmenwerk zuerst bestimmen, welcher Teil der Eingabe, name, durch diesen Kontext zu verarbeiten ist. Das heißt, weil der Kontext eine SPI für kombinierte Namen unterstützt, muss das FN-Rahmenwerk den kombinierten Namen, compound_name, erhalten, mit dem der Kontext arbeiten kann. Der Rest von name, der von diesem Kontext nicht verwendet wird, wird in einer als rest bezeichneten Variablen behalten.
Wenn die Kontextimplementierung starke Trennung unterstützt 1420, ist compound_name einfach die erste Komponente in name und rest ist Sämtliches von name ohne die erste Komponente 1422.
Wenn der Kontext statische schwache Trennung unterstützt 1408, ruft das FN-Rahmenwerk die Funktion p_parse_component() auf, die von der Kontextimplementierung bereitgestellt wird, um die anfänglichen Komponenten (compound_name) des kombinierten Namens, name, der zu dem Namensgebungssystem dieses Kontexts gehört, zu extrahieren. p_parse_component() gibt einen etwaigen Rest, der nicht von diesem Namensgebungssystem verbraucht wurde, in rest zurück 1416.
Wenn die Kontextimplementierung dynamische schwache Trennung unterstützt 1414, verwendet das FN-Rahmenwerk den gesamten name als compound_name für die Kontextimplementierung. Dies beruht darauf dass die Kontextimplementierung dynamisch bestimmen wird, welcher Teil von compound_name verbraucht werden sollte, und das Feld für den restlichen Namen, rname, in status entsprechend einstellt. rest wird auf NULL gesetzt 1418.
An diesem Punkt hat das FN-Rahmenwerk für alle verschiedenen Arten der Trennung compound_name so eingestellt, dass es der kombinierte Name ist, der der Kontextimplementierung zuzuführen ist, und rest auf den nicht benutzten Teil von name gesetzt. Wenn rest gleich NULL ist 1426, ist compound_name die letzte Komponente in name, die zu verarbeiten ist. Für diesen Fall ruft das FN-Rahmenwerk die Operation c_ aus der mit operation A korrespondierenden Kontextimplementierung auf und versorgt sie mit den Argumenten ctx, compound_name und args 1428. Wenn rest nicht gleich NULL ist 1430, sondern die letzte Komponente in name ist und eine leere Zeichenfolge ist 1434, spezifiziert die Clientanwendung, dass sie mit dem mit compound_name assoziierten Nächstes-Namensgebungssystem-Zeiger operieren will. Für diesen Fall ruft das FN-Rahmenwerk die Operation c_nns aus der mit operation A korrespondierenden Kontextimplementierung auf und versorgt sie mit den Argumenten ctx, compound_name und args 1436. Wenn rest nicht die letzte Komponente in name ist oder die letzte ist, aber keine leere Zeichenfolge 1440, wirkt der von compound_name benannte Kontext als ein zwischenliegender Kontext. Für diesen Fall ruft das FN-Rahmenwerk die Operation c_lookup_nns() von der Kontextimplementierung mit ctx, compound_name und args auf 1442. Wenn das Ergebnis (ref2) von c_lookup_nns() erfolgreich ist 1448, würde es den Verweis auf das nächste Namensgebungssystem zur Fortsetzung der Operation enthalten; folglich ist der Status nach einer erfolgreichen Rückkehr von c_lookup_nns() zu CONTINUE geändert 1450, um anzugeben, dass die Operation fortgesetzt werden soll, und das Feld rref von Status ist auf ref2 gesetzt. An diesem Punkt führt das FN-Rahmenwerk die folgende Verwaltung des Statusobjekts vor dem Beenden der Engine der SPI für kombinierte Namen aus. Die Variable rest enthält den Teil von name, der noch zu verarbeiten ist. Unabhängig davon, ob die Operation erfolgreich war, muss rest an das Feld rname des Statusobjekts angefügt werden, um zu gewährleisten, dass rname den restlichen Teil von name richtig angibt, der weiter verarbeitet werden muss 1437. Das FN-Rahmenwerk beendet dann die Engine der SPI für kombinierte Namen und wird bei 1344 in 13a fortgesetzt (dies ist ausführlich oben im Abschnitt zu teilweise zusammengesetzte Namen beschrieben).
Zur Veranschaulichung des Obigen soll das folgende Beispiel für eine Kontextimplementierung (C1), die die SPI für kombinierte Namen bereitstellt, betrachtet werden.

Für dieses Beispiel soll angenommen werden, dass C1 statische schwache Trennung unterstützt.
Das FN-Rahmenwerk ruft p_component_parser() aus C1 auf, um die Argumente compound_name und rest zu extrahieren. compound_name = ctx->p_component_parser("a = b/c = d/e/f/g", &rest, &pstats);
Es soll angenommen werden, dass p_component_parser() in C1 das Gleichheitszeichen („=") verwendet, um zu bestimmen, welche Komponenten des Namens zu ihrem Namensgebungssystem gehören.
compound_name enthält dann "a = b/c = d", rest enthält "e/f/g". Da rest weder Null noch die letzte Kombinierte ist, ist der von "a = b/c = d" benannte Kontext ein zwischenliegendes Namensgebungssystem. Das FN-Rahmenwerk stellt die Eingabe ("a = b/c = d", "lookup_nns()", {}) für die Kontextimplementierung (C1) von ctx bereit. C1 führt die Operation c_lookup_nns() mit dem kombinierten Namen "a = b/c = d" aus, ref2 = ctx->c_lookup_nns("a = b/c = d", &status);und liefert das Ergebnis dieser Operation (ref2) an das FN-Rahmenwerk.
Für dieses Beispiel soll angenommen werden, dass diese Operation erfolgreich war. Das FN-Rahmenwerk setzt status dann auf CONTINUE und setzt das Feld für den zergliederten Verweis, rref, von status auf ref2. Es fügt rest an das Feld mit dem restlichen Namen, rname, von status an.

– rname ("e/f/g")
– rref (Ergebnis der Operation c_lookup_nns("a = b/c = d", ...))

Das FN-Rahmenwerk verwendet dann rref zur Identifizierung der zu verwendenden Kontextimplementierung (C2) und ruft die Implementierung constructor() aus C2 auf, um einen neuen Kontext-Handle, ctx_new, zu konstruieren. Das FN-Rahmenwerk ersetzt den alten Wert von ctx durch ctx_new. Das FN-Rahmenwerk ersetzt den alten Wert von name durch rname. Das FN-Rahmenwerk verfügt jetzt über ausreichende Informationen, um den Prozess fortzusetzen.
Es soll angenommen werden, dass C2 die SPI für kombinierte Namen bereitstellt und dynamische schwache Trennung unterstützt. Das FN-Rahmenwerk setzt rest auf NULL und stellt die Eingabe ("e/f/g", "lookup_up()", {}) für C2 bereit. C2 führt c_lookup() mit dem zusammengesetzten Namen "e/f/g" wie folgt durch: ref = ctx->c_lookup("e/f/g", &status);
Für dieses Beispiel soll angenommen werden, dass diese Operation an dieser Stelle erfolgreich endet. C2 liefert den an "e/f/g" gebundenen Verweis (ref) an das FN-Rahmenwerk. Da rest gleich NULL ist, ist keine Aktualisierung des Inhalts von status erforderlich. Das FN-Rahmenwerk liefert ref an die Clientanwendung.
Das obige Beispiel veranschaulicht, wie das FN-Rahmenwerk zwei Kontextimplementierungen, C1 und C2, die beide die SPI für kombinierte Namen verwendeten, einsetzte, um eine Operation mit einem zusammengesetzten Namen durchzuführen, der zwei Namensgebungssysteme umfasste. C1 unterstützte statische schwache Trennung, während C2 dynamische schwache Trennung unterstützte. Weder die Clientanwendung, die das FN-Rahmenwerk verwendete, noch das FN-Rahmenwerk selbst verfügte über irgendwelche eingebauten Kenntnisse über C1 oder C2. Das FN-Rahmenwerk verwendete die SPI für kombinierte Namen, um sowohl mit C1 als auch mit C2 zu kommunizieren.
INTERAKTIONEN DES FN-RAHMENWERKS MIT DER SPI FÜR ATOMISCHE NAMEN
Jetzt zurückkehrend zu 13a, führt das FN-Rahmenwerk, wenn die Kontextimplementierung die SPI für atomische Namen 1346 unterstützt, den von der Engine der SPI für atomische Namen 1348 beschriebenen Algorithmus aus (dieser ist detailliert in 13c dargestellt). Die Ausgabe der Engine sind das Ergebnis der Operation und status 1350. Wenn status gleich CONTINUE ist 1326, konstruiert das FN-Rahmenwert einen neuen Wert für name unter Verwendung des Felds mit dem restlichen Namen (rname) von status 1328. Dann extrahiert es rref von status, um einen Kontext-Handle new_ctx zu konstruieren, und ersetzt den alten Inhalt von ctx dadurch. Das FN-Rahmenwerk wiederholt den Prozess dann von Anfang an 1332 unter Verwendung des revidierten name und Kontext-Handles ctx. Wenn status nicht gleich continue ist 1334, kehrt das FN-Rahmenwerk zurück 1312.
Wenn die Kontextimplementierung die SPI für atomische Namen (1346 in 13a) unterstützt, führt das FN-Rahmenwerk den Algorithmus aus, der in der Engine der SPI für atomische Namen 1500 in 13c beschrieben wird. In 13c muss das FN-Rahmenwerk zuerst bestimmen, welcher Teil der Eingabe, name, durch diesen Kontext zu verarbeiten ist. Das heißt, weil der Kontext eine SPI für atomische Namen unterstützt, muss das FN-Rahmenwerk den atomischen Namen, head, erhalten, mit dem der Kontext arbeiten kann. Dies erfolgt in zwei Schritten. Zuerst muss es den kombinierten Namen, compound_name, von name erhalten und dann aus compound_name den atomischen Teil, head, zur Verarbeitung. Der Rest von name, der nicht Teil von compound_name ist, wird in einer als rest bezeichneten Variablen behalten. Der Rest von compound_name, der nicht Teil von head ist, wird in einer als tail bezeichneten Variablen behalten.
Wenn der Kontext starke Trennung unterstützt 1508, ist compound_name einfach die erste Komponente in name und rest ist Sämtliches von name ohne die erste Komponente 1510. Das FN-Rahmenwerk ruft die Funktion c_parse_component() (früher beschrieben) auf, die von der Kontextimplementierung bereitgestellt wird, um die atomische Komponente (head) zur Verarbeitung zu extrahieren. c_parse_component() gibt außerdem den Rest von compound_name ohne head in tail zurück 1512.
Wenn der Kontext statische schwache Trennung unterstützt 1514 1518, ruft das FN-Rahmenwerk die Funktion p_parse_component() (früher beschrieben) auf, die von der Kontextimplementierung bereitgestellt wird, um die anfänglichen Komponenten (compound_name) des zusammengesetzten Namens, name, der zu dem Namensgebungssystem dieses Kontexts gehört, zu extrahieren 1520. p_parse_component() gibt einen etwaigen Rest, der nicht von diesem Namensgebungssystem verbraucht wurde, als rest zurück 1522.
Wenn die Kontextimplementierung dynamische schwache Trennung unterstützt 1524, verwendet das FN-Rahmenwerk den gesamten name als compound_name für die Kontextimplementierung. Dies beruht darauf, dass die Kontextimplementierung dynamisch bestimmen wird, welcher Teil von compound_name verbraucht werden sollte, und den Rückgabestatus entsprechend einstellt. rest wird auf NULL gesetzt 1526.
Für beide Formen der schwachen Trennung ist head die erste Komponente in compound_name und tail der Rest von compound_name ohne head 1522.
An diesem Punkt hat das FN-Rahmenwerk für alle verschiedenen Arten der Trennung compound_name so eingestellt, dass es der kombinierte Name ist, der zum Namensgebungssystem dieses Kontexts, ctx, gehört, und rest auf den nicht benutzten Teil von name gesetzt. Weiterhin wird head auf den atomischen Namen von compound_name gesetzt, der von ctx zu verarbeiten ist, und tail wird auf den Rest von compound_name gesetzt.
Wenn tail nicht NULL ist 1560, sind mehr Atome in compound_name als nur head zu verarbeiten und ist der durch head benannte Kontext ein zwischenliegender Kontext innerhalb desselben Namensgebungssystems. Das FN-Rahmenwerk ruft a_lookup() von der Kontextimplementierung mit head auf, um den an head gebundenen Verweis (ref2) zu erhalten 1562. Nach dem Aufrufen von a_lookup() fügt das FN-Rahmenwerk den Inhalt von tail als die erste(n) Komponente(n) in rest ein, um die von dieser Kontextimplementierung noch nicht verarbeiteten Komponenten zu berücksichtigen 1564. rest wird an den Inhalt des Restfelds, rname, des Objekts status angefügt 1537. Wenn die Operation erfolgreich ist 1552, setzt das FN-Rahmenwerk den Status der Operation auf CONTINUE 1554, um anzuzeigen, dass die Operation fortgesetzt werden muss, und setzt das Feld für den zergliederten Verweis (rref) von status auf ref2. Dann beendet das FN-Rahmenwerk die Engine 1538.
Wenn tail gleich NULL ist 1530, ist head das letzte Atom das in dem mit ctx assoziierten Namensgebungssystem zu verarbeiten ist. Wenn rest gleich NULL ist 1534, wurde der Zielkontext erreicht; das FN-Rahmenwerk ruft a_operation von der Kontextimplementierung auf, die mit operation A korrespondiert 1536, und beendet die Engine 1538.
Wenn tail gleich NULL ist 1530, aber rest nicht die letzte und leere Komponente in name ist 1544, ist der durch head benannte Kontext ein zwischenliegender Kontext, der dieses Namensgebungssystem mit dem nächsten verbindet. Das FN-Rahmenwerk ruft die Operation a_lookup_nns() mit head auf, um den Verweis (ref2) auf den nächsten Kontext (in dem nächsten Namensgebungssystem) zu erhalten, um die Operation fortzusetzen 1546. Wenn die Operation erfolgreich ist 1552, setzt das FN-Rahmenwerk den Status auf CONTINUE 1554, um anzuzeigen, dass die Operation fortgesetzt werden soll, und setzt das Feld für den zergliederten Verweis (rref) in status auf (ref2) und beendet die Engine 1538.
Wenn tail gleich NULL ist 1530, aber rest die letzte und leere Komponente in name ist 1556, ist die Operation für das mit head assoziierte nächste Namensgebungssystem durchzuführen. Das FN-Rahmenwerk ruft die Operation a_nns von der Kontextimplementierung mit den Argumenten ctx, head und args auf 1558 und beendet dann die Engine 1538.
Nach dem Beenden der Engine der SPI für atomische Namen 1350 fährt das FN-Rahmenwerk fort, wie oben für den Abschnitt über teilweise zusammengesetzte Namen beschrieben (1324 in 13a).
Zur Veranschaulichung des Obigen soll das folgende Beispiel für eine Kontextimplementierung (A1), die die SPI für atomische Namen bereitstellt, betrachtet werden.

Für dieses Beispiel soll angenommen werden, dass A1 statische schwache Trennung unterstützt.
Das FN-Rahmenwerk ruft p_component_parser() aus A1 auf, um die Argumente compound_name und rest zu extrahieren. compound_name = ctx->p_component_parser("a = b/c = d/e/f/g", &rest, &pstats);
Es soll angenommen werden, dass p_component_parser() in A1 das Gleichheitszeichen („=") verwendet, um zu bestimmen, welche Komponenten des Namens zu ihrem Namensgebungssystem gehören. comapound_name enthält dann "a = b/c = d"; rest enthält "e/f/g". Das FN-Rahmenwerk extrahiert dann head und tail aus compound_name: head wird "a = b", tail wird "c = d". Da tail nicht NULL ist, ist der von "a = b" benannte Kontext ein zwischenliegender Kontext in demselben Namensgebungssystem. Das FN-Rahmenwerk stellt die Eingabe ("a = b", "lookup()", {}) für die Kontextimplementierung (A1) von ctx bereit. A1 führt die Operation a_lookup() mit dem atomischen Namen "a = b" wie folgt aus: ref2 = ctx->a_lookup("a = b", &status);und liefert das Ergebnis dieser Operation (ref2) an das FN-Rahmenwerk.
Für dieses Beispiel soll angenommen werden, dass diese Operation erfolgreich war. Das FN-Rahmenwerk setzt status dann auf CONTINUE und setzt das Feld für den zergliederten Verweis, rref, von status auf ref2. Es fügt dann tail ("c = d") vor rest ("e/f/g") ein; dieses ("c = d/e/f/g") wird das neue rest. Das FN-Rahmenwerk fügt dann rest an das Feld mit dem restlichen Namen, rname, von status an.

– rname ("c = d/e/f/g")
– rref (Ergebnis der Operation a_lookup("a = b", ...))

Das FN-Rahmenwerk setzt rest zurück auf NULL. Das FN-Rahmenwerk verwendet dann rref zur Konstruktion des Handles für das nächste Kontextobjekt. Das FN-Rahmenwerk liefert rref an die Implementierung construktor() von A1, um einen neuen Kontext-Handle, ctx_new, zu konstruieren. Das FN-Rahmenwerk ersetzt den alten Wert von ctx durch ctx_new. Das FN-Rahmenwerk ersetzt den alten Wert von name durch rname ("c = d/e/f/g"). Das FN-Rahmenwerk verfügt jetzt über ausreichende Informationen, um den Prozess fortzusetzen.
Das FN-Rahmenwerk liefert die Eingabe ("c = d/e/f/g", "lookup_up()", {}) an A1. Nach der Engine der SPI für atomische Namen während dieser Iteration ist head gleich "c = d" und tail ist NULL. rest ("e/f/g") ist die letzte und leere Komponente in name, was bedeutet, dass der durch "c = d" benannte Kontext der letzte Kontext in einem zwischenliegenden Namensgebungssystem ist. Das FN-Rahmenwerk ruft a_lookup_nns() für "c = d" auf, um einen Verweis auf das nächste Namensgebungssystem zu erhalten, um die Operation fortzusetzen.
A1 führt a_lookup_nns() für den atomischen Namen "c = d" wie folgt durch: ref2 = ctx->a_lookup_nns("c = d", &status);
Für dieses Beispiel soll angenommen werden, dass diese Operation an dieser Stelle erfolgreich endet. A1 liefert den an das nächste Namensgebungssystem von "c = d" gebundenen Verweis (ref2) an das FN-Rahmenwerk. Das FN-Rahmenwerk setzt dann den Status der Operation auf CONTINUE, setzt den Teil mit dem zergliederten Verweis (rref) auf den Status von ref2 und fügt rest ("e/f/g") an den Teil mit dem restlichen Namen (rname) in status an.
An diesem Punkt hat das FN-Rahmenwerk das nächste Namensgebungssystem, auf das von "a = b/c = d" gezeigt wird, zergliedert, und muss die Operation mit "e/f/g" fortsetzen. Für dieses Beispiel soll angenommen werden, dass die mit dem neuen rref assoziierte Kontextimplementierung C2 die SPI für kombinierte Namen unter Verwendung von dynamischer schwacher Trennung bereitstellt. Das FN- Rahmenwerk setzt rest auf NULL und stellt die Eingabe ("e/f/g", "lookup_up()", {}) für C2 bereit. C2 führt c_lookup() mit dem zusammengesetzten Namen "e/f/g" wie folgt aus: ref = ctx->c_lookup("e/f/g", &status);
Für dieses Beispiel soll angenommen werden, dass diese Operation an dieser Stelle erfolgreich endet. C2 liefert den an "e/f/g" gebundenen Verweis (ref) an das FN-Rahmenwerk. Da "e/f/g" die letzte Komponente in name war (d. h. rest gleich NULL ist), ist keine Aktualisierung des Inhalts von status erforderlich. Das FN-Rahmenwerk liefert ref an die Clientanwendung.
Das obige Beispiel veranschaulicht, wie das FN-Rahmenwerk zwei Kontextimplementierungen, A1 und C2, einsetzte, um eine Operation mit einem zusammengesetzten Namen durchzuführen, der zwei Namensgebungssysteme umfasste. A1 war eine Kontextimplementierung, die die SPI für kombinierte Namen verwendete und statische schwache Trennung unterstützte. C2 war eine Kontextimplementierung, die die SPI für zusammengesetzte Namen verwendete und dynamische schwache Trennung unterstützte. Weder die Clientanwendung, die das FN-Rahmenwerk verwendete, noch das FN-Rahmenwerk selbst verfügte über irgendwelche eingebauten Kenntnisse über A1 oder C2. Das FN-Rahmenwerk kommuniziere mit A1 unter Verwendung der SPI für atomische Namen und kommunizierte mit C2 unter Verwendung der SPI für kombinierte Namen.
Die obigen ausführlichen Beschreibungen stellen die bevorzugte Ausführungsform zu diesem Zeitpunkt dar. Fachleute werden jedoch erkennen, dass verschiedene ähnliche Implementierungen dieser Operationen möglich sind und innerhalb des Rahmens der vorliegenden Erfindung liegen.
D. KONTEXTIMPLEMENTIERUNGS-BINDUNG
Das dritte Element der Ausführungsform ist der Mechanismus, der vom FN-Rahmenwerk verwendet wird, um verschiedene Kontextimplementierungen aufzurufen.
In der bevorzugten Ausführungsform wird eine Kontextimplementierung durch die Verwendung von Konstuktoren an eine Anwendung gebunden. Sämtlicher Zugang zu einem Kontext erfolgt über seinen Kontext-Handle. Der Kontext-Handle wird durch Aufrufen eines Konstruktors erhalten und benannt unter Verwendung einer vordefinierten Anordnung, die nachstehend beschrieben ist, die andere interne Konstuktoren, die für die FN SPI spezifisch sind, aufrufen kann. Die Konstuktoren der FN SPI liefern Handles für Kontextobjekte, die die richtige FN SPI unter Verwendung einer ähnlichen Anordnung wie die in 6 beschriebene bereitstellen. Anschließende Operationen, die den Kontext-Handle umfassen, werden die korrespondierende Operation auslösen, die von der Kontextimplementierung über die FN SPI bereitgestellt wird.
10 veranschaulicht das Verhältnis zwischen den Kontextimplementierungen 1110, 1112, 1114, den Namensgebungsdiensten 1116, 1118, 1120 und dem FN-Rahmenwerk 1108. Code für eine bestimmte Kontextimplementierung wird eindeutig unter Verwendung des Verweises und der Adressart(en) des Kontexts identifiziert. Die Konstuktoren, die sich in Kontextimplementierungen befinden, werden auch eindeutig unter Verwendung des Verweises und der Adressart(en) des Kontexts identifiziert. Beispielsweise veranschaulicht das Folgende, wie früher dargestellt, ein Codefragment, wie der Konstruktor aufgerufen werden könnte: ctx = constructor(reference);wobei
ctx ein Handle zu einem Kontextobjekt ist
reference ein Verweis ist, der durch Nachschlagen eines Namens erhalten wurde.
Neue und beliebige Namensgebungs- und Verzeichnisdienste werden Anwendungen zugänglich gemacht, ohne dass diese neu kompiliert werden, aufgrund der Architektur des FN-Rahmenwerks und seiner Definition und der Verwendung der FN SPI. Das FN-Rahmenwerk weist keine Abhängigkeiten von bestimmten Kontextimplementierungen auf, nur von der Schnittstelle (FN SPI), die von den Kontextimplementierungen bereitgestellt wird. Daher ist das FN-Rahmenwerk in der Lage, ohne irgendwelche Änderungen an dem FN-Rahmenwerk oder der Clientanwendung durch die Verwendung von Konstruktoren auf Anforderung verschiedene Kontextimplementierungen zur Verwendung auszuwählen.
Wenn die Betriebsumgebung, in der das FN-Rahmenwerk und die Kontextimplementierungen eingesetzt werden, über Unterstützung für dynamisches Linken verfügt, erhält die Anwendung den weiteren Vorteil, dass sie nicht neu eingebunden oder angehalten werden muss. Wenn dynamisches Linken verfügbar ist, ist das FN-Rahmenwerk imstande, verschiedene Kontextimplementierungen dynamisch auf Anforderung durch die Verwendung von Konstuktoren einzubinden, so dass es dadurch nicht erforderlich ist, dass die Anwendung im Voraus mit allen möglichen Kontextimplementierungen, die sie unter Umständen benötigen wird, einzubinden.
Es wird für Fachleute ersichtlich sein, dass verschiedene Abwandlungen und Änderungen in der bevorzugten Ausführungsform der hierin offenbarten Erfindung vorgenommen werden können, ohne den Rahmen dieser Erfindung, wie durch die Patentansprüche definiert, zu verlassen.

Claims

Föderiertes Namensgebungs-Rahmensystem (1100) zur Verwendung in einem verteilten Computersystem, das mindestens einen Computer (20) mit einer Zentraleinheit, einem Speicher, einer Anzeige und einem Ein-/Ausgabemechanismus hat, um ein Schnittstellensystem zwischen einer Client-Anwendung (1104), das zur Verwendung eines zusammengesetzten Namens (1102) konfiguriert ist, und mindestens einem Namensgebungsdienst-Mechanismus (1116) zur Verwendung bei der Auflösung des zusammengesetzten Namens bereitzustellen, wobei das föderierte Namensgebungs-Rahmensystem umfasst: einen föderierten Namensgebungs-Rahmenmechanismus (1108) in dem Computerspeicher, der mit der Client-Anwendung (1104) gekoppelt ist und konfiguriert ist zum Auflösen eines von einer Client-Anwendung empfangenen zusammengesetzten Namens eines Objekts durch Verwendung eines Namensgebungsdienst-Mechanismus (1116); und einen oder mehrere Namensgebungsdienst-Mechanismen (1116, 1118, 1120), konfiguriert, um einer Schnittstelle eines föderierten Namensgebungsdienstanbieters zu entsprechen, und mit dem föderierten Namensgebungs-Rahmenmechanismus (1108) gekoppelt; und dadurch gekennzeichnet, dass der oder die Namensgebungsdienst-Mechanismen konfiguriert sind, um Unterstützung für starke oder schwache Trennung in einem oder mehreren jeweiligen Namensgebungssystemen anzuzeigen.
Föderiertes Namensgebungs-Rahmensystem nach Anspruch 1, wobei zusätzliche Namensgebungsdienst-Mechanismen einer Client-Anwendung ohne Unterbrechung des von den föderierten Namensgebungs-Rahmenmechanismen bereitgestellten Diensts verfügbar gemacht werden können und wobei der Namensgebungsdienst-Mechanismus unter Verwendung eines Konstrukteurmechanismus von dem föderierten Namensgebungs-Rahmenmechanismus lokalisiert wird.
Föderiertes Namensgebungs-Rahmensystem nach Anspruch 1 oder 2, wobei der föderierte Namensgebungs-Rahmenmechanismus einen von der Client-Anwendung bereitgestellten Kontext-Handle verwendet, um eine zugehörige Kontextimplementierung (1110) zu identifizieren und um zu bestimmen, welche föderierte Namensgebungsdienstanbieter-Schnittstelle diese Kontextimplementierung unterstützt.
Föderiertes Namensgebungs-Rahmensystem nach einem der Ansprüche 1 bis 3, wobei der zusammengesetzte Name zwei oder mehr Namensgebungssysteme umfasst.
Föderiertes Namensgebungs-Rahmensystem nach einem der Ansprüche 1 bis 4, wobei der Namensgebungsdienstanbieter-Schnittstellenmechanismus konfiguriert ist, um mit einem Dienstanbieter für atomische Namensgebung zu kommunizieren.
Föderiertes Namensgebungs-Rahmensystem nach einem der Ansprüche 1 bis 4, wobei der Namensgebungsdienstanbieter-Schnittstellenmechanismus konfiguriert ist, um mit einem Dienstanbieter für kombinierte Namensgebung zu kommunizieren.
Föderiertes Namensgebungs-Rahmensystem nach einem der Ansprüche 1 bis 4, wobei der Namensgebungsdienstanbieter-Schnittstellenmechanismus konfiguriert ist, um mit einem Dienstanbieter für teilweise zusammengesetzte Namensgebung zu kommunizieren.
Föderiertes Namensgebungs-Rahmensystem nach einem der Ansprüche 1 bis 4, wobei der Namensgebungsdienstanbieter-Schnittstellenmechanismus konfiguriert ist, um mit einem Dienstanbieter für zusammengesetzte Namensgebung zu kommunizieren.
Föderiertes Namensgebungs-Rahmensystem nach einem der Ansprüche 1 bis 4, wobei der Namensgebungsdienstanbieter-Schnittstellenmechanismus konfiguriert ist, um mit einem Dienstanbieter für kombinierte Namensgebung und einem Dienstanbieter für atomische Namensgebung zu kommunizieren.
Föderiertes Namensgebungs-Rahmensystem nach einem der Ansprüche 1 bis 4, wobei der Namensgebungsdienstanbieter-Schnittstellenmechanismus konfiguriert ist, um mit einem Dienstanbieter für teilweise zusammengesetzte Namensgebung und einem Dienstanbieter für kombinierte Namensgebung zu kommunizieren.
Föderiertes Namensgebungs-Rahmensystem nach einem der Ansprüche 1 bis 4, wobei der Namensgebungsdienstanbieter-Schnittstellenmechanismus konfiguriert ist, um mit einem Dienstanbieter für teilweise zusammengesetzte Namensgebung und einem Dienstanbieter für kombinierte Namensgebung und einem Dienstanbieter für atomische Namensgebung zu kommunizieren.
Computerprogramm-Produkt, umfassend: ein computernutzbares Medium mit darin ausgeführten computerlesbaren Programmcode-Mechanismen, konfiguriert zum Auflösen eines zusammengesetzten Namens (1102) eines von einer Client-Anwendung aufgerufenen Objekts, wobei die computerlesbaren Programmcode-Mechanismen in dem Computerprogramm-Produkt umfassen: computerlesbare Code-Mechanismen, konfiguriert zum Annehmen eines Aufrufs von der Client-Anwendung zum Auflösen des zusammengesetzten Namens durch einen föderierten Namensgebungs-Rahmenmechanismus (1108), konfiguriert zur weiteren Verwendung eines Namensgebungsdienst-Mechanismus (1116) zum Durchführen einer Namensauflösung; und computerlesbare Code-Mechanismen, konfiguriert zum Enthalten von einem oder mehreren Namensgebungsdienst-Mechanismen, die einer föderierten Namensgebungsdienstanbieter-Schnittstelle entsprechen; und dadurch gekennzeichnet, dass das Computerprogramm-Produkt weiter computerlesbare Code-Mechanismen enthält, die konfiguriert sind, um zu bewirken, dass der oder die Namensgebungsdienst-Mechanismen ihre Unterstützung für starke oder schwache Trennung in einem oder mehreren jeweiligen Namensgebungssystemen anzeigen.
Computerprogramm-Produkt nach Anspruch 12, wobei zusätzliche Namensgebungsdienst-Mechanismen einer Client-Anwendung ohne Unterbrechung des von den föderierten Namensgebungs-Rahmenmechanismen bereitgestellten Diensts verfügbar gemacht werden können und wobei ein Namensgebungsdienst-Mechanismus, der mit dem föderierten Namensgebungs-Rahmenmechanismus zu verbinden ist, unter Verwendung eines Konstrukteurmechanismus von dem föderierten Namensgebungs-Rahmenmechanismus lokalisiert wird.
Computerprogramm-Produkt nach Anspruch 12 bis 13, wobei der zusammengesetzte Name zwei oder mehr Namensgebungssysteme umfasst.
Computerprogramm-Produkt nach einem der Ansprüche 12, 13 oder 14, wobei der eine oder die mehreren Namensgebungsdienst-Mechanismen keine direkte Verbindung mit der Client-Anwendung haben.