DE202014010938U1

DE202014010938U1 - Omega-Namen: Namenserzeugung und -ableitung

Info

Publication number: DE202014010938U1
Application number: DE202014010938.9U
Authority: DE
Original assignee: Google LLC
Current assignee: Google LLC
Priority date: 2013-06-28
Filing date: 2014-06-26
Publication date: 2017-01-24
Anticipated expiration: 2024-06-27
Also published as: WO2014210321A4; US20160357788A1; US20150006146A1; US20180129685A1; US10324909B2; WO2014210321A3; EP3014479B1; US9830341B2; EP3014479A2; WO2014210321A2

Abstract

System, das Folgendes umfasst: einem Prozessor, der in einer Computerressourcenumgebung mit mindestens zwei Ressourcen-Namensräumen bereitgestellt ist; und einem prozessorlesbaren Speicher, auf dem Anweisungen enthalten sind, die so konfiguriert sind, dass der Prozessor ein Verfahren zum Erzeugen eines vollständig qualifizierten Ressourcennamen für eine bestimmte Ressource auf der Grundlage eines kontextbasierten Namens dieser Ressource und einem bestimmten Nutzungskontext ausführt, wobei das Verfahren Folgendes umfasst: Empfangen, als Eingangsinformation, eines dem Ressourcennamen, dem kontextbasierten Namen und dem Nutzungskontext zugewiesenen Namensschemas; Vergleichen eines Eintrag im Namensschema und eines Eintrag im kontextbasierten Namen; Bestimmen, basierend auf einem Ergebnis dieses Vergleichs, ob das Schema einen Moniker enthält, der im kontextbasierten Namen fehlt; Bestimmen, als Reaktion auf eine Feststellung, dass das Schema einen Moniker enthält, der im kontextbasierten Name fehlt, ob der fehlende Moniker ein Attributraum-Moniker ist; Hinzufügen, als Reaktion auf die Feststellung, dass der fehlende Moniker ein Attributraum-Moniker ist, des Attributraum-Monikers zu einem vollständigen Namen, der den kontextbasierten Namen beinhaltet; als Reaktion auf die Feststellung, dass der fehlende Moniker kein Attributraum-Moniker ist, Bestimmen des Attributraums, der mit dem fehlenden Moniker verbunden ist; Durchsuchen des Nutzungskontexts nach Informationen, die eine Verbindung zwischen dem fehlenden Moniker, dem mit dem fehlenden Moniker verbundenen Attributraum und einem dem fehlenden Moniker zugewiesenen Wert darstellen; Anhängen des bei der Suche ermittelten Attributraums, des fehlenden Monikers und des dem fehlenden Moniker zugewiesenen Werts an den vollständigen Namen.

Description

Hintergrund:
Heute besteht eine komplexe Großrechnerumgebung zunehmend aus mehreren Systemen. Diese Systeme werden unabhängig voneinander entwickelt und interagieren miteinander, ebenso wie mit den Benutzern. Jedes dieser Systeme in der Umgebung verwaltet eine große Anzahl von Ressourcen, und diese Ressourcen haben Namen. Ein Name kann von einem menschlichen Benutzer verwendet werden, um auf die betreffende Ressource zu verweisen; er kann auch von Maschinen als Referenz und zur Auflösung in eine eindeutige Kennung verwendet werden, über die auf diese Ressource zugegriffen bzw. diese verwaltet werden kann. Unter Schutz gestellt werden und Gegenstand des Gebrauchsmusters sind dabei, entsprechend den Vorschriften des Gebrauchsmustergesetzes, lediglich Vorrichtungen wie in den beigefügten Schutzansprüchen definiert, jedoch keine Verfahren. Soweit nachfolgend in der Beschreibung gegebenenfalls auf Verfahren Bezug genommen wird, dienen diese Bezugnahmen lediglich der beispielhaften Erläuterung der in den beigefügten Schutzansprüchen unter Schutz gestellten Vorrichtung oder Vorrichtungen.
Eine Herausforderung in solchen Umgebungen ist die enorme Zunahme der Komplexität der Benennung, sowohl über die Systeme hinweg als auch für den Benutzer. Das Problem ergibt sich aus der Tatsache, dass jedem System, weil es unabhängig aufgebaut werden kann, freisteht, seine eigenen Benennungstechnik (Syntax + Semantik) für seine eigenen Ressourcen zu nutzen. Dies führt zu den folgenden Quellen der Komplexität:

a. Ein System ist möglicherweise nicht in der Lage, richtig oder genau auf Namen eines anderen Systems zu verweisen oder Namen eines anderen Systems in seine eigenen Namen oder Benennungskonventionen einzuschließen.
b. Aufgrund der Interaktion zwischen den Systemen muss jedes System in der Lage sein, Namen aus anderen Systemen zu verstehen und aufzulösen. Für eine solche Namensauflösung kann einer von zwei Ansätzen gewählt werden: i. es wird dafür gesorgt, dass jedes System die Benennungstechnik jedes anderen Systems versteht (dies ist ein Aufwand von O(N²) bei N Systemen), oder ii. es wird ein monolithisches, manuell codiertes Benennungssystem für die gesamte Umgebung geschaffen – das muss möglicherweise auf Einzelfallbasis für jedes System erfolgen und ist äußerst arbeitsaufwändig.
c. Ein Benutzer hat möglicherweise mit mehreren Benennungstechniken zu tun, eine für jedes System, und der Benutzer muss auch ein Bewusstsein für jedes System und die damit verbundenen Benennungstechnik aufrechthalten.
d. Die vollständig qualifizierten Namen aus jedem System (die durch das System zugewiesenen vollständig eindeutigen Namen der Systemressourcen), können sehr lang sein, sodass sie schwer zu lesen oder zu analysieren sind und in einigen Fällen Beschränkungen für Namenslängen oder Nachrichtengrößen durch sie überschritten werden.

Zusammenfassung
In manchen Ausführungsformen von Lösungen, die hierin erläutert werden, besteht ein komplexe Großrechnerumgebung aus mehreren Systemen. Eine solche Umgebung kann man sich daher in einigen Fällen als System von Systemen vorstellen.
Angesichts des Vorstehenden ist es erwünscht, eine systematische Möglichkeit zu schaffen oder zu definieren, die Folgendes ermöglicht:

a. Ein System kann Ressourcennamen erstellen und verwenden, in die Namen von Ressourcen aus anderen Systemen aufgenommen werden;
b. Die Benennung einzelner Systeme kann sich unabhängig voneinander entwickeln;
c. Systeme können der Umgebung hinzugefügt bzw. aus ihr entfernt werden;
d. Einem Benutzer ist es möglich, nur die Teile des gegebenen Resourcennamens zu sehen, die für seinen aktuellen Kontext relevant sind, und Computer können automatisch zwischen diesen Teilnamen und den vollständig qualifizierten Namen übersetzen;
e. Namen können zusätzliche Informationen über die Ressource enthalten, die nützliche Hinweise für Maschine und Mensch zur Verwendung des Namens liefern;
f. Kombinationen der oben genannten Funktionen werden unterstützt; und
g. solche Benennungs- und Namensauflösungsschemata für Ressourcen können für breite Sammlungen von Umgebungen generalisiert werden.

Es ist notwendig, dass jede Gruppe von Systemressourcen oder jeden Umgebungsressourcenpool die darin enthaltenen Ressourcenobjekte eindeutig identifizieren kann, sodass Ressourcenobjekte eindeutige Verweise auf einander enthalten und Informationen über ein Objekt abrufen können, wenn ein verwandtes Objekt gegeben ist (d. h. Objekte müssen durch ihre eindeutige Kennung abrufbar sein). Es gibt zwar einige bekannte Mechanismen zur Erzeugung eindeutiger Kennungen, aber diese Mechanismen sind rein maschinenorientiert und erzeugen lange Hexadezimalzahlenketten, die für einen menschlichen Benutzer nicht lesbar oder verständlich sind. Obwohl solche maschinengenerierten Namen (die vollständig qualifizierten Namen sein können) zur Präsentation in externen Oberflächen, die auf Endbenutzer abzielen, maskiert oder übersetzt werden können (z. B. durch Bereitstellen „einfacher Namen” oder durch Verbergen der Identität des Objekts in einer grafischen Benutzeroberfläche, beispielsweise einem Skizzierungssystem), verursacht ein solches Benennungsschema dennoch Schwierigkeiten für Benutzer, die innerhalb des Systems arbeiten, wie z. B. Systementwickler und/oder -bediener, die die Namen visuell oder manuell analysieren müssen. Teilweise kann dies auf die Tatsache zurückzuführen sein, dass vollständig qualifizierte Namen Informationen wie einen logischen oder physikalischen Speicherort der Ressource im System enthalten können und auf Informationen über eine Beziehung zwischen der benannte Ressource und anderen Systemressourcen basieren bzw. solche Informationen enthalten können. Auch Debugging- und/oder Logging-Tools leiden unter dem Problem der Lesbarkeit und Nutzbarkeit, da sie Namen enthalten, die für menschliche Benutzer nicht mühelos lesbar und verständlich sind.
Im Rahmen dieses Dokuments bedeutet der Term „Ressource” jede physische oder logische Komponente bzw. jedes Datenelement oder jede Datensammlung, die für Zwecke des Abrufens, Verarbeitens, Verfolgens oder für andere Verwendungszwecke in einem Systems spezifisch identifiziert werden kann. Eine „Ressource” kann zum Beispiel laufende Prozesse, Aufgabenanforderungen, physische Speicherorte, virtuelle Maschinen, Prozessoren, Datenbanken, Datenbankeinträge und andere Systemobjekte und/oder -komponenten umfassen.
Hierin beschriebene Ausführungsformen von Techniken, Lösungen und Systeme können in einer Computerressourcenumgebung mit mindestens zwei verschiedenen Ressourcennamensräumen anwendbar sein. In Ausführungsformen einer solchen Umgebung können die hierin beschriebenen Lösungen, Techniken und Systeme ein Verfahren zum Erzeugen eines vollständig qualifizierten Ressourcennamen für eine bestimmte Ressource auf der Grundlage eines kontextbasierten Namens dieser Ressource und einem bestimmten Nutzungskontext beinhalten, wobei das Verfahren Folgendes umfasst: Empfangen als Eingangsinformation eines Namensschemas, das mit dem Ressourcennamen, dem kontextbasierten Namen und dem Nutzungskontext verbunden ist; Vergleichen eines Eintrags in dem Namensschema und eines Eintrags im kontextbasierten Namen; Bestimmen, auf der Basis eines Ergebnisses dieses Vergleichs, ob das Schema einen Moniker enthält, die im kontextbasierten Namen fehlt; Bestimmen, als Reaktion auf die Feststellung, dass das Schema einen Moniker enthält, der im kontextbasierten Name fehlt, ob der fehlende Moniker ein Attributraum-Moniker ist; Hinzufügen, als Reaktion auf die Feststellung, dass der fehlende Moniker ein Attributraum-Moniker ist, des Attributraum-Monikers zu einem vollständigen Namen, der den kontextbasierten Namen enthält; Bestimmen, als Reaktion auf die Feststellung, dass der fehlende Name kein Attributraum-Moniker ist, des mit dem fehlenden Namen verbundenen Attributraums; Durchsuchen des Nutzungskontexts nach Informationen, die eine Verbindung zwischen dem fehlenden Moniker, dem mit dem fehlenden Moniker verbundenen Attributraum und einem dem fehlenden Moniker zugewiesenen Wert darstellen; und Anhängen des bei der Suche ermittelten Attributraums, des fehlenden Moniker und des dem fehlenden Monikers zugewiesenen Werts an den vollständigen Namen.
In manchen Ausführungsformen ist ein erster Eintrag in das Schema ein Attributraum-Moniker. In manchen Ausführungsformen beinhaltet der Kontext Informationen über ein Ursprungsattribut. In manchen Ausführungsformen ist das Ursprungsattribut in dem zurückgegebenen vollständigen Namen enthalten.
In manchen Ausführungsformen beinhaltet das Verfahren ferner einen Schritt, durch den als Reaktion auf die Feststellung, dass der fehlende Name ein Attributraum-Moniker ist, Daten, die den fehlenden Moniker repräsentieren, an die Spitze eines Attributraumstapels verschoben werden. In manchen Ausführungsformen beinhaltet die Ermittlung des mit dem fehlenden Moniker verbundenen Attributraums die Auswahl eines Monikers an der Spitze des Attributraumstapels als den Attributraum, der mit dem fehlenden Moniker verbunden ist.
In manchen Ausführungsformen beinhaltet der Schritt des Vergleichs eines Eintrags, dass ein erster Eintrag im Namensschema und ein erster Eintrag im kontextbasierten Namen miteinander verglichen werden. In manchen Ausführungsformen beinhaltet der Schritt des Hinzufügens des Attributraum-Monikers, dass ein nachfolgender Eintrag im Namensschema mit einem nachfolgenden Eintrag im kontextbasierten Namen verglichen wird. In manchen Ausführungsformen beinhaltet der Schritt des Anhängens des gesuchten Attributraums, dass ein nachfolgender Eintrag im Namensschema mit einem nachfolgenden Eintrag im kontextbasierten Namen verglichen wird.
In manchen Ausführungsformen beinhaltet das Verfahren ferner Schritte, mit denen festgestellt wird, ob alle Einträge in dem Schema bewertet wurden; und als Reaktion auf die Feststellung, dass alle Einträge im Schema bewertet wurden, die Ausgabe des vollständigen Namen als vollständig qualifizierten Ressourcennamen, wobei der vollständig qualifizierte Ressourcenname über alle Ressourcennamenräume hinweg eindeutig ist.
In manchen Ausführungsformen umfasst das Verfahren ferner Schritte zum Bestimmen, ob der nachfolgende Eintrag im Namensschema das Ende einer Attributraumdefinition angibt; und als Reaktion auf die Feststellung, dass der nachfolgende Eintrag im Namensschema das Ende einer Attributraumdefinition angibt, zum Stellen des Monikers an die Spitze des Attributraumstapels.
In manchen Ausführungsformen beinhaltet der jeweilige Nutzungskontext Metadaten, die einen bevorzugten Name-Resolver für den vollständigen Namen angeben. In manchen Ausführungsformen ist der kontextbasierte Name ein Name, der mit einer bestimmten Aufgabe verbunden ist, und der Kontext beinhaltet Metadaten, die einen aktuellen Computer darstellen, auf dem eine Aufgabe mit dem Kontextnamen geplant ist. In manchen Ausführungsformen ist der kontextbasierte Name ein vom Menschen lesbarer Name, der in Kombination mit dem bestimmten Nutzungskontext die bestimmte Ressource eindeutig innerhalb der Computerressourcenumgebung identifiziert. In manchen Ausführungsformen beinhaltet der bestimmte Nutzungskontext Metadaten, die einen mit der Ressource verbundenen Zeitstempel darstellen.
In manchen Ausführungsformen ist der vollständig qualifizierte Ressourcenname ein vom Menschen lesbarer Name, der die bestimmte Ressource innerhalb der Computerressourcenumgebung eindeutig identifiziert. In manchen Ausführungsformen sind sowohl der vollständig qualifizierte Ressourcenname als auch der kontextbasierte Name von Menschen lesbare Namen. In manchen Ausführungsformen beinhaltet der vollständig qualifizierte Ressourcenname eine Vielzahl von ersten Monikern, die mit einem ersten Attributraum verbunden sind, und einen zweiten Moniker, der mit einem zweiten Attributraum verbunden ist. In manchen Ausführungsformen beinhaltet ein Wert, der mit einem Namen der genannten Vielzahl von ersten Moniker verbunden ist, den zweiten Moniker.
Ausführungsformen von hierin beschriebenen Lösungen, Techniken und Systemen können ein Verfahren zur Überprüfung der Gültigkeit eines vollständig qualifizierten Ressourcennamen innerhalb einer Umgebung mit mindestens zwei verschiedene Ressourcennamenräume beinhalten, wobei das Verfahren Folgendes umfasst: Empfangen, als Eingangsinformation, eines vollständig qualifizierten Ressourcennamens, wobei der vollständig qualifizierte Ressourcenname eine Vielzahl von Token enthält; Lesen eines Token aus dem vollständig qualifizierten Ressourcennamen; Bestimmen, ob das gelesene Token den Beginn eines Ressourcennamensraums darstellt; als Reaktion auf die Feststellung, dass das gelesene Token den Beginn eines Ressourcennamensraums darstellt, Hinzufügen von Informationen, die den Ressourcennamensraum darstellen, zu einem Stapel; und Lesen eines nachfolgenden Tokens aus dem vollständig qualifizierten Ressourcennamen; als Reaktion auf die Feststellung, dass das gelesene Token nicht den Beginn eines Ressourcennamensraums darstellt, Bestimmen, ob das gelesene Token ein Ende des Ressourcennamensraums darstellt; als Reaktion auf die Feststellung, dass das gelesene Token das Ende des Ressourcennamensraums darstellt, Lesen einer Elementinformation von oben aus dem Stapel als nachfolgendes Token aus dem vollständig qualifizierten Ressourcennamen; als Reaktion auf die Feststellung, dass das gelesene Token nicht den Beginn eines Ressourcennamensraums darstellt und dass das gelesene Token nicht das Ende eines Ressourcennamensraums darstellt, Bestimmen, ob das gelesene Token einen gültigen Moniker für den Ressourcennamensraum darstellt; als Reaktion auf die Feststellung, dass das gelesene Token keinen gültigen Moniker für den Ressourcennamensraum darstellt, Ausgeben eines Fehlers; und als Reaktion auf die Feststellung, dass das gelesene Token einen gültigen Moniker für den Ressourcennamensraum darstellt, Lesens eines nachfolgenden Tokens aus dem vollständig qualifizierten Ressourcennamen.
In manchen Ausführungsformen beinhaltet der vollständig qualifizierte Ressourcenname Informationen über einen ersten Ressourcennamensraum und einen zweiten Ressourcennamensraum. In manchen Ausführungsformen sind die Informationen über den zweiten Ressourcennamensraum innerhalb der Informationen über den ersten Ressourcennamensraum verschachtelt, sodass das nachfolgende Token den Beginn des zweiten Ressourcennamensraums darstellen kann. In manchen Ausführungsformen haben der erste Ressourcennamensraum und der zweite Ressourcennamensraum voneinander unabhängige Benennungskonventionen.
In manchen Ausführungsformen beinhaltet der Schritt der Ausgabe eines Fehlers die Beendung eines Namensvalidierungsprozesses. In manchen Ausführungsformen beinhaltet das Verfahren ferner Schritte zur Ermittlung, ob alle Token in dem Ressourcenname gelesen wurden; und als Reaktion auf die Feststellung, dass alle Token in dem Ressourcenname gelesen wurden, die Ausgabe eines Hinweises, dass der vollständig qualifizierte Ressourcenname gültig ist.
In manchen Ausführungsformen beinhaltet der Schritt, in dem ermittelt wird, ob das gelesene Token einen gültigen Moniker für den Ressourcennamensraum darstellt, das Lesen eines Werts, der mit dem gelesenen Token verbunden ist, und das Ermitteln, ob der gelesene Wert ein gültiger Wert für den Moniker ist, der durch das gelesenen Token dargestellt wird.
In manchen Ausführungsformen wird der zweite Ressourcennamensraum als Teil eines Werts dargestellt, der mit einem innerhalb des ersten Ressourcennamensraum definierten Monikers des vollständig qualifizierten Ressourcennamen verbunden ist.
Ausführungsformen der hierin beschriebenen Lösungen, Techniken und Systeme können eine Datenstruktur umfassen, die ein Objekt in einem Attributnamensraum für die Benennung von Ressourcen darstellt, wobei die Datenstruktur Folgendes umfasst: eine Attributnamensraumkennung, die den Attributnamensraum bezogen auf andere Attributnamensräume eindeutig identifiziert; mindestens einen lokalen Moniker, der ein lokales Ressourcenattribut darstellt, wobei dieser lokale Name einen zugehörigen Wert aufweist, der das lokale Ressourcenattribut darstellt; und mindestens einen geerbten Moniker, der ein lokaler Moniker eines übergeordneten Namensraum ist, wobei dieser übergeordnete Namensraum mehrere untergeordnete Namensräume haben kann, und wobei jeder untergeordnete Namensraum alle lokalen Moniker eines übergeordneten Namensraum als geerbte Moniker erhält.
In manchen Ausführungsformen kann die Datenstruktur mindestens einen überladenen Moniker enthalten, wobei der überladene Moniker ein lokales Ressourcenattribut ist, das im Attributnamensraum definiert ist. In manchen Ausführungsformen kann der überladene Moniker einen Namen haben, der identisch mit einem lokalen Moniker des übergeordneten Namensraums ist. In manchen Ausführungsformen kann die überladene Moniker den geerbten Moniker aus dem übergeordneten Namensraum im Attributnamensraum ersetzen.
In manchen Ausführungsformen kann die Datenstruktur einen Moniker beinhalten, der ein Ursprungsattribut darstellt, wobei ein Wert des Ursprungsattributs mindestens einen von einem menschlichen Benutzer gelieferten Namen für das Objekt und einen Verweis auf ein Ursprungsattribut eines zweiten Objekts in einem zweiten Attributnamensraum darstellt, und der zweite Attributnamensraum sich vom Attributnamensraum unterscheidet.
In manchen Ausführungsformen kann die Datenstruktur einen zweiten geerbten Moniker umfassen, wobei der zweite geerbte Moniker ein lokaler Moniker eines zweiten übergeordneten Namensraums ist, sodass der Attributnamensraum des Objekts mindestens zwei übergeordnete Namensräume hat.
In manchen Ausführungsformen wird das Ursprungsattribut aus dem übergeordneten Namensraum geerbt. In manchen Ausführungsformen ist das Ursprungsattribut ein überladener Moniker.
Ausführungsformen der hierin beschriebenen Lösungen, Techniken und Systeme können ein Verfahren zur Ableitung eines vollständig qualifizierten Namens einer Zielressource in einem bestimmten System innerhalb einer Umgebung basierend auf einer Reihe von Ableitungsregeln, die mit dem jeweiligen System verbunden sind, beinhalten, wobei das Verfahren Folgendes umfasst: Empfangen als Eingangsinformationen eines Namens einer Quellressource der Zielressource, eines Attributwerts, der mit der Zielressource verbunden ist, und eines Namensschemas, das mit der Zielressource verbunden ist; Erzeugen eines Zielressourcennamens auf der Grundlage des Namens der Quellressource; und Umwandeln des erzeugten Namens in einen abgeleiteten Zielressourcennamen mittels Durchführen von zwei oder mehr Vorgängen, unter anderem Folgendem: Ändern eines Werts eines Attributs innerhalb des erzeugten Zielressourcennamens basierend auf Ableitungsregeln; Hinzufügen eines Attributs zu dem erzeugten Zielressourcennamen und Erzeugen eines Attributwerts für das hinzugefügte Attribut basierend auf den Ableitungsregeln; Löschen eines Attributs und eines zugehörigen Attributwerts aus dem erzeugten Zielressourcennamen basierend auf den Ableitungsregeln; Verschachteln eines Attributnamens in einem Attributwert des erzeugten Zielressourcennamens basierend auf den Ableitungsregeln; und Extrahieren eines verschachtelten Attributnamens aus einem Attributwert des erzeugten Zielressourcennamens basierend auf den Ableitungsregeln.
In manchen Ausführungsformen beinhaltet das Verschachteln das Löschen eines ersten Attributs und des zugehörigen ersten Attributwerts aus dem erzeugten Zielressourcennamen; und das Hinzufügen der gelöschten ersten Attributs und des zugehörigen ersten Attributwerts als zweiten Attributwert verbunden mit einem zweiten Attribut zum erzeugten Zielressourcennamen.
In manchen Ausführungsformen beinhaltet das Extrahieren das Löschen eines ersten Attributs und des zugehörigen ersten Attributwerts aus dem erzeugten Zielressourcennamen; und das Hinzufügen der gelöschten ersten Attributs als zweites Attribut und als zugehörigen zweiten Attributwert zum erzeugten Zielressourcennamen.
In manchen Ausführungsformen beinhaltet das Ändern die Änderung eines Schema-Attributs in dem erzeugten Zielressourcennamen, sodass der erzeugte Zielressourcenname mit einem anderen Schema verbunden wird, das sich von dem der Quellressource unterscheidet.
In manchen Ausführungsformen sind die Ableitungsregeln in dem mit der Quellressource verbundenen Namensschema enthalten. In manchen Ausführungsformen werden die Ableitungsregeln aus dem mit der Quellressource verbundenen Namensschema erzeugt.
In manchen Ausführungsformen ist die Quellressource mit einem System verbunden, das sich von dem speziellen System unterscheidet. In manchen Ausführungsformen ist die Quellressource mit einem ersten Ressourcentyp und die Zielressource mit einer zweiten Ressourcentyp verbunden, der sich vom ersten Ressourcentyp unterscheidet. In manchen Ausführungsformen erbt der zweite Ressourcentyp mindestens ein Attribut vom ersten Ressourcentyp.
In manchen Ausführungsformen ist das spezielle System mit einem ersten Namensraum verbunden, wobei die Quellressource mit einem zweiten Namensraum verbunden ist, der sich vom ersten Namensraum unterscheidet. In manchen Ausführungsformen erbt der zweite Namensraum mindestens ein Attribut vom ersten Namensraum.
Ausführungsformen der hierin beschriebenen Lösungen, Techniken und Systeme können ein System beinhalten, das Folgendes umfasst: einen Prozessor, der in einer Computerressourcenumgebung mit mindestens zwei Ressourcen-Namensräumen bereitgestellt ist; und einen prozessorlesbaren Speicher, auf dem Anweisungen enthalten sind, die so konfiguriert sind, dass der Prozessor ein Verfahren zum Erzeugen eines vollständig qualifizierten Ressourcennamen für eine bestimmte Ressource auf der Grundlage eines kontextbasierten Namens dieser Ressource und einem bestimmten Nutzungskontext ausführt, wobei das Verfahren Folgendes umfasst: Empfangen als Eingangsinformation eines Namensschemas, das mit dem Ressourcennamen, dem kontextbasierten Namen und dem Nutzungskontext verbunden ist; Vergleichen eines Eintrags in dem Namensschema und eines Eintrags im kontextbasierten Namen; Bestimmen, auf der Basis eines Ergebnisses dieses Vergleichs, ob das Schema einen Moniker enthält, die im kontextbasierten Namen fehlt; Bestimmen, als Reaktion auf die Feststellung, dass das Schema einen Moniker umfasst, der im kontextbasierten Namen fehlt, ob der fehlende Moniker ein Attributraum-Moniker ist; Hinzufügen, als Reaktion auf die Feststellung, dass der fehlende Moniker ein Attributraum-Moniker ist, des Attributraum-Monikers zu einem vollständigen Namen, der den kontextbasierten Namen beinhaltet; Bestimmen, als Reaktion auf die Feststellung, dass der fehlende Moniker kein Attributraum-Moniker ist, des Attributraums, der mit dem fehlenden Moniker verbunden ist; Durchsuchen des Nutzungskontexts nach Informationen, die eine Verbindung zwischen dem fehlenden Moniker, dem mit dem fehlenden Moniker verbundenen Attributraum und einem dem fehlenden Moniker zugewiesenen Wert darstellen; und Anhängen des bei der Suche ermittelten Attributraums, des fehlenden Monikers und des dem fehlenden Moniker zugewiesenen Werts zu dem vollständigen Namen.
Ausführungsformen von hierin beschriebenen Lösungen, Techniken und Systemen können ein System beinhalten, umfassend Folgendes: einen Prozessor, der in einer Computerressourcenumgebung mit mindestens zwei Ressourcen-Namensräumen bereitgestellt ist; und einen prozessorlesbaren Speicher, auf dem Anweisungen enthalten sind, die so konfiguriert sind, dass der Prozessor ein Verfahren zur Überprüfung der Gültigkeit eines vollständig qualifizierten Ressourcennamen innerhalb einer Umgebung beinhaltet, das Verfahren umfassend Folgendes: Empfangen, als Eingangsinformation, eines vollständig qualifizierten Ressourcennamens, der eine Vielzahl von Token enthält; Lesen eines Tokens aus dem vollständig qualifizierten Ressourcennamen; Bestimmen, ob das gelesene Token den Beginn eines Ressourcennamensraums darstellt; als Reaktion auf die Feststellung, dass das gelesene Token den Beginn eines Ressourcennamensraums darstellt, Hinzufügen von Informationen, die den Ressourcennamensraum darstellen, zu einem Stapel; und Lesen eines nachfolgenden Tokens aus dem vollständig qualifizierten Ressourcennamen; als Reaktion auf die Feststellung, dass das gelesene Token nicht den Beginn eines Ressourcennamensraums darstellt, Bestimmen, ob das gelesene Token ein Ende des Ressourcennamensraums darstellt; als Reaktion auf die Feststellung, dass das gelesene Token das Ende des Ressourcennamensraums darstellt, Lesen einer Elementinformation von oben aus dem Stapel als nachfolgendes Token aus dem vollständig qualifizierten Ressourcennamen; als Reaktion auf die Feststellung, dass das gelesene Token nicht den Beginn eines Ressourcennamensraums darstellt und dass das gelesene Token nicht das Ende eines Ressourcennamensraums darstellt, Bestimmen, ob das gelesene Token einen gültigen Moniker für den Ressourcennamensraum darstellt; als Reaktion auf die Feststellung, dass das gelesene Token keinen gültigen Moniker für den Ressourcennamensraum darstellt, Ausgeben eines Fehlers; und als Reaktion auf die Feststellung, dass das gelesene Token einen gültigen Moniker für den Ressourcennamensraum darstellt, Lesens eines nachfolgenden Tokens aus dem vollständig qualifizierten Ressourcennamen.
Ausführungsformen der hierin beschriebenen Lösungen, Techniken und Systeme können ein nicht-flüchtiges, computerlesbares Medium beinhalten, auf dem eine Datenstruktur enthalten ist, die ein Objekt in einem Attributnamensraum für die Benennung von Ressourcen darstellt, die Datenstruktur umfassend Folgendes: eine Attributnamensraumkennung, die den Attributnamensraum bezogen auf andere Attributnamensräume eindeutig identifiziert; mindestens einen lokalen Moniker, der ein lokales Ressourcenattribut darstellt, wobei dieser lokale Moniker einen zugehörigen Wert aufweist, der das lokale Ressourcenattribut darstellt; und mindestens einen geerbten Moniker, der ein lokaler Moniker eines übergeordneten Namensraum ist, wobei dieser übergeordnete Namensraum mehrere untergeordnete Namensräume haben kann, und wobei jeder untergeordnete Namensraum alle lokalen Moniker eines übergeordneten Namensraum als geerbte Moniker erhält.
Ausführungsformen der hierin beschriebenen Lösungen, Techniken und Systeme können ein System beinhalten, umfassend Folgendes: einen Prozessor, der in einer Computerressourcenumgebung mit mindestens einem ersten System bereitgestellt ist; und einen prozessorlesbaren Speicher, auf dem Anweisungen enthalten sind, die so konfiguriert sind, dass der Prozessor ein Verfahren zur Ableitung eines vollständig qualifizierten Namens einer Zielressource im ersten System innerhalb einer Umgebung basierend auf einer Reihe von Ableitungsregeln, die mit dem jeweiligen System verbunden sind, ausführt, das Verfahren umfassend Folgendes: Empfangen als Eingangsinformationen eines Namens einer Quellressource der Zielressource, eines Attributwerts, der mit der Zielressource verbunden ist, und eines Namensschemas, das mit der Zielressource verbunden ist; Erzeugen eines Zielressourcennamens auf der Grundlage des Namens der Quellressource; und Umwandeln des erzeugten Namens in einen abgeleiteten Zielressourcennamen mittels Durchführen von zwei oder mehr Vorgängen, unter anderem Folgendem: Ändern eines Werts eines Attributs innerhalb des erzeugten Zielressourcennamens basierend auf den Ableitungsregeln; Hinzufügen eines Attributs zu dem erzeugten Zielressourcennamen und Erzeugen eines Attributwerts für das hinzugefügte Attribut basierend auf den Ableitungsregeln; Löschen eines Attributs und eines zugehörigen Attributwerts aus dem erzeugten Zielressourcennamen basierend auf den Ableitungsregeln; Verschachteln eines Attributnamens in einem Attributwert des erzeugten Zielressourcennamens basierend auf den Ableitungsregeln; und Extrahieren eines verschachtelten Attributnamens aus einem Attributwert des erzeugten Zielressourcennamens basierend auf den Ableitungsregeln.
Ausführungsformen von einigen oder allen Prozessor und Speichersystemen, die hierin offengelegt werden, können auch so konfiguriert werden, um einige oder alle der oben offengelegten Darstellungen auszuführen. Ausführungsformen von einigen oder allen oben offengelegten Verfahren, können auch als Anweisungen dargestellt werden, die auf den vorübergehenden oder nicht-vorübergehenden, prozessorlesbaren Speichermedien enthalten sind, wie optische oder magnetische Speicher oder als ein fortgepflanztes Signal, das einem Prozessor oder Datenverarbeitungsgerät über ein Kommunikationsnetzwerk wie z. B. eine Internet- oder Telefonverbindung bereitgestellt wird.
Ein weiterer Anwendungsbereich der beschriebenen Systeme und Verfahren wird aus der nachfolgenden detaillierten Beschreibung ersichtlich. Es versteht sich jedoch, dass die detaillierte Beschreibung und die spezifischen Beispiele, während sie Ausführungsformen der Systeme und Verfahren angeben, nur zur Veranschaulichung gegeben werden, da verschiedene Änderungen und Modifikationen innerhalb des Geistes und des Umfangs der hierin offenbarten Konzepte dem Fachmann mit Blick auf diese detaillierte Beschreibung offensichtlich werden.
Kurzbeschreibung der Zeichnungen
Die erörterten Systeme und Verfahren werden aus der nachfolgenden detaillierten Beschreibung und den beigefügten Zeichnungen, die lediglich zur Veranschaulichung dienen und daher nicht einschränkend sind, vollständiger verständlich.
1 zeigt ein Blockdiagramm einer Ausführungsform eines Namensvalidierungsprozesses wie hierin beschrieben;
2a zeigt ein Waldmodell von Attributräumen einschließlich ungebundener Attributräume wie hierin beschrieben;
2b zeigt eine Ausführungsform einer Attributraumvererbung und -überladung wie hierin beschrieben;
3 zeigt eine Ausführungsform einer Namenswiederherstellung auf der Basis des Kontexts wie hierin beschrieben;
4 zeigt eine Ausführungsform von Namensschemata mit einem untypisierten Attribut wie hierin beschrieben; und
5 zeigt eine Ausführungsform eines Computersystems, das so konfiguriert ist, dass es einen Prozess zur Namensvalidierung, -erzeugung, -wiederherstellung und/oder Schemaverwaltung ganz oder teilweise wie hierin beschrieben durchführt.
Die Zeichnungen werden im Detail im Verlauf der detaillierten Beschreibung beschrieben.
Detaillierte Beschreibung
Die folgende detaillierte Beschreibung bezieht sich auf die begleitenden Zeichnungen. Die gleichen Bezugsziffern in verschiedenen Zeichnungen können die gleichen oder ähnliche Elemente identifizieren. Auch beschränkt sich die folgende detaillierte Beschreibung nicht auf die erläuterten Konzepte. Stattdessen wird der Umfang der hierin diskutierten Konzepte durch die beigefügten Ansprüche und Äquivalente davon definiert.
Angesichts des Vorstehenden beschreibt diese Offenbarung eine Möglichkeit zur Identifizierung von Objekten, die für menschliche Benutzer lesbar ist, während gleichzeitig auch Maschinen diese Objektkennungen bei der Laufzeit automatisch erstellen und verwenden können. Ein solches Verfahren und/oder ein System oder eine Umgebung, die ein solches Verfahren umsetzen oder verwenden, beinhaltet die folgenden Funktionen:

a. Namen, die als eindeutige Ressourcen- und/oder Objektkennungen über Ort und Zeit hinweg innerhalb des Systems und/oder der Umgebung dienen;
b. auf menschliche Benutzer ausgerichtete Namen, die bezogen auf den Ort eindeutig sind und sich dynamisch an die bezogen auf den Ort und die Zeit eindeutigen Namen im System binden;
c. Namen zur Erfassung arbiträrer Beziehungen von benannten Ressourcen zu anderen Objekten;
d. eine Möglichkeit zur Strukturierung eines Namens in einer Weise, die es für Benutzer einfach macht, Dinge so zu benennen, wie sie über die Objektbeziehungen denken (z. B. wenn eine Gruppe von Objekten einem Dienst zugeordnet ist, sollten die Objektnamen dies widerspiegeln);
e. eine Möglichkeit für Maschinen und Laufzeitsoftware, Namen aus verbundenen Objekten voneinander abzuleiten, sodass der für die Aufrechterhaltung von Objektzeigern benötigte Speicher-Overhead sowie der Speicher-, Netzwerk- und Berechnungs-Overhead für das Abrufen der Objekte selbst, um diese verbundenen Objekte zu extrahieren, eingespart wird;
f. Plattformunabhängigkeit;
g. Code, damit solche Namensableitungen automatisch erzeugt werden;
h. die Möglichkeit, dass durch menschliche Benutzer angegebene Namen durch das System wie vorhanden hindurchgeführt werden (und für menschliche Benutzer erneut sichtbar gemacht werden, z. B. in der Benutzeroberfläche).

Diese Offenbarung beinhaltet die folgenden Ideen:

a. Aspaces (Attributräume), die Namensräumen für Attribute ähneln; z. B. jedes System kann seinen eigenen Aspace haben;
b. kontextsensitive Namen: Erstellen von leicht zu lesenden Teilnamen aus längeren Namen durch Verwenden eines Kontexts, und der umgekehrte Vorgang des Erstellens eines vollständigen Namens aus dem Teilnamen – einschließlich Regeln, die beschreiben, was wann hinzuzufügen ist;
c. Verfahren für das Verbinden von Metadaten mit Namen – einschließlich Hinweise über Auflösung, Kontextsensitivität und andere Möglichkeiten der Verwendung des Namens;
d. Kombinationen der oben genannten Techniken.

Ein Ziel dieser Offenbarung ist es, das Erstellen von Namen zu ermöglichen, die sowohl der menschliche Benutzer lesen kann als auch Systemressourcen eindeutig identifizieren. Solche Namen sind für die Verwendung durch Maschinen und durch Menschen geeignet und minimieren gleichzeitig die Möglichkeiten potentieller Verwirrung und den zusätzliche Verarbeitungsaufwand, der erforderlich ist, um einen Namen zwischen maschinenlesbaren und menschenlesbaren Formaten zu „übersetzen”.
Aspaces
Ein Attributraum (Attribute Space oder Aspace) ist eine Familie von Attributnamen. In manchen Ausführungsformen können Attributnamen als Moniker bekannt sein oder bezeichnet werden. In manchen Ausführungsformen kann jedes System seinen eigenen Aspace haben. Jeder Aspace kann einen global eindeutigen Namen haben, der als Aspace-Moniker bezeichnet wird. Eine Paarung des Aspace-Monikers und des Attributnamens ermöglicht eine eindeutige, umgebungsweite Definition (über alle beteiligten Systeme hinweg) jedes gegebenen Attributs aus einem beliebigen Benennungssystem. So hat beispielsweise ein Attribut-Moniker <foo> bei der Paarung mit einem Aspace-Moniker A eine einzige Bedeutung. Das bedeutet, dass ein anderer Aspace B ein Attribut <foo> definierten kann, das nicht das gleiche wie das Attribut <foo> von A ist. So hat beispielsweise der Moniker <Nachname> in _aspace=US die Bedeutung Familiennamen, während in Patronym-Kulturen (wie _aspace=Island) <Nachname> eine andere Bedeutung hat. Jedem System in der Umgebung ist ein eindeutiger Name zugewiesen, der als System-Moniker bezeichnet wird (dies könnte eine Zeichenkette sein). Der Aspace, der einem System mit dem System-Moniker S entspricht, hat einen Aspace-Namen, der gleich S ist oder davon abgeleitet ist.
Verwendung von Aspaces innerhalb von Namen
Zur Qualifizierung eines gegebenen Attribut-Monikers innerhalb eines Ressourcen- oder Objektnamens kann der Aspace-Moniker getrennt als Wert eines speziellen <apace>-Attributs geschrieben werden, auf den der Attribut-Moniker später folgt. Beispiel: [_aspace=USA Nachname=Smith]. In manchen Ausführungsformen können die Lese-/Analysier-Regeln (später diskutiert) auch zeigen, wie eine Folge von Attributen einem einzigen Aspace-Term zugeordnet werden kann. Eine solche Zuordnung von Attributen zu einem Aspace-Term kann für ein System ein Verfahren bereitstellen, um Attribute aus einem anderen System innerhalb seiner eigenen Namen zu verwenden. Das ist möglich, weil externe Attribute durch Verwendung des Aspace-Monikers des anderen Systems qualifiziert werden. Ein Beispiel für einen solchen Namen, der verschachtelte Namen beinhaltet, kann geschrieben werden als [_aspace=Space1 space1attributel=green space2attribute2= [_aspace=Space2 space2attribute1 =round]]
In manchen Ausführungsformen kann für verschachtelte Namen zulässig sein, dass sie entweder typisiert (wenn das globale Schema des verschachtelten Namens bekannt ist) oder untypisiert sind. Dieser untypisierte Aspekt wird später in diesem Dokument hinsichtlich der Namensableitung aus Ursprungsattributen diskutiert.
In manchen Ausführungsformen kann sie die Benennung eines Systems unabhängig von anderen Systemen entwickeln, weil keine Attribut-Moniker-Konflikte bestehen. Dies gilt beispielsweise für eine Ausführungsform, bei der eine Umgebung zwei Systeme S1 und S2 enthält, wobei R1 in S1 eine Instanziierung einer Ressource R2 ist, die in S2 enthalten ist. Der Name von R1 kann dann geschrieben werden, indem der Namen von R2 darin verschachtelt wird: [_aspace=S1 ... Name für R1 in der Benennungskonvention von S1 ... Quelle =[_aspace=S2 ... Name für R2 in der Benennungskonvention von S2 ...].
Manche Ausführungsformen können auch angeben, wie solche Namen zur Überprüfung der Gültigkeit der Attribute darin zu lesen oder zu analysieren sind. Manche Ausführungsformen eines Benennungs- oder Namensanalyseverfahrens können die Paarung einer Folge von Attribut-Monikern mit einem Aspace-Term erlauben (anstatt einen gesonderten Aspace-Term zu erfordern, sodass die Namen kürzer werden). Eine Ausführungsform eines solchen Verfahrens, wie in 1 dargestellt, sieht folgendermaßen ist:

Eingabe: Vollständig qualifizierte Name N
Ausgabe: Boolesch; ob die Attribute von N in ihren Aspaces gültig sind
Interne Daten: Aspace-Stapel, dessen Elemente Aspace-Moniker sind
Während (es sind Token im Namen N übrig) {
a. Nächstes Token aus N lesen (Reihenfolge von links nach rechts)
b. wenn Treffen auf ”[”, dann
i. folgt diesem ein Term [_aspace=a];
ii. auf einen Aspace-Stapel schieben; fortfahren;
c. wenn Treffen auf ”]”
i. den Stapel nehmen; fortfahren
d. wenn Treffen auf ein Attribut mit einem Moniker, der innerhalb des Aspace nicht deklariert/gültig ist, dessen Aspace-Moniker oben im Aspace-Stapel ist
i. Fehler zurückgeben
}

Wie im Flussdiagramm in 1 sichtbar kann ein vollständig qualifizierter Name 1001 einer Ressource durch ein System oder eine Systemkomponente oder einen Prozess empfangen werden, das/die/der in einem Rechenzentrum oder in einer Datenverarbeitungsumgebung ausgeführt wird, das/die so konfiguriert ist oder in anderer Weise darauf ausgelegt ist, einen Validierungsvorgang für einen Ressourcennamen durchzuführen. Der vollständig qualifizierte Name 1001 der Ressource kann Informationen über das System beinhalten, in dem sich die Ressource befindet, sowie Informationen über die Aspaces, die alle der Ressource zugeordneten Attribute beinhalten. Ein solcher vollständig qualifizierter Name 1001 kann als eine Reihe von Token betrachtet werden. Solche Token können einzelne Zeichen, Wörter, Sonderzeichen, Bit-Zeichenketten unterschiedlicher Länge, Hexadezimalzahlen oder Kombinationen davon sein. Ein Beispiel für einen vollständig qualifizierten Namen für ein Datenspeichergerät, das mit einer virtuellen Maschine verbunden ist, die einem Cluster C1 in einem Rechenzentrum D1 zugeordnet ist, kann lauten: [_aspace=StorageDevice device=sda machine=[_aspace=VirtualMachine vm=V1 location=[_aspace=Cluster cluster=C1 datacenter=D1]]].
Zur Validierung eines solchen vollständig qualifizierten Namens der Validierung kann ein Token-Traversal-Verfahren eingesetzt werden. Bei einem solchen Prozess wird jedes Token des voll qualifizierten Namens gelesen und untersucht, um zu ermitteln, ob es ein Attribut, einen Attributwert oder einen Anfang oder ein Ende eines Attributraums oder Namensraums (Aspace) definiert. Dies kann durch sequenzielles Lesen des nächste Tokens 1020 im Namen erfolgen (solange ungelesene Token 1010 im Namen vorhanden sind) und durch Beurteilen des gelesenen Tokens im Hinblick darauf, ob dieser den Anfang eines Attributraums (Aspace) oder Namensraums 1030 definiert. Eine solche Definition kann durch ein Sonderzeichen oder ein Wort mit einer Kombination daraus ermittelt werden. So ist beispielsweise der Standort der VM V1 im obigen Beispiel [_aspace=Cluster cluster=C1 datacenter=D1], geschrieben unter Verwendung des Namensraums Cluster, der die Attribute cluster und datacenter definiert. In einer anderen Bereitstellung des Systems könnte [_aspace=Colo provider=Foo region=Europe] als andere Möglichkeit zur Identifizierung des Standorts verwendet werden, ohne eine Änderung am System zu erfordern, das virtuelle Maschinen (oder Speichergeräte dafür) identifiziert.
Wenn die gelesene Token, das den Beginn eines Aspace oder Namensraums 1030 definiert, wird der nächste Term im Namen, der ein nachfolgendes Token sein kann, welches einen Namen oder anderen indikativen Wert des Aspace oder Namensraums definiert, in einen Aspace- oder Namensraum-Stapel 1040 verschoben. Ein solcher Stapel kann eine Datenstruktur sein, die verwendet wird, um Werte von Namensräumen zu speichern, sodass ein vollständig qualifizierter Name mit mehreren verschachtelten Namensräumen mittels Durchqueren jedes verschachtelte Namensraums hin zur Tiefe bewertet werden kann.
Wenn das gelesene Token stattdessen das Ende eines Aspace oder Namensraum 1060 definiert, wird der Term an der Spitze des Stapels genommen und so gelesen, als wäre das nächste Token im Namen 1050. Aufgrund der Organisation des Stapels muss der Term an der Spitze immer der Name oder sonstige indikative Wert sein, der anzeigt, dass der Aspace beendet ist. Wenn das gelesene Token nicht den Beginn oder das Ende eines Aspace oder Namensraums definiert, wird es im Hinblick darauf bewertet zu ermitteln, ob das Token einen gültigen Moniker oder Attributwert 1090 repräsentiert. Eine solche Bewertung kann in Bezug auf den Aspace oder Namensraum durchgeführt werden, der momentan durchquert wird. In manchen Ausführungsformen kann das System oder Teilsystem oder der Prozess, das/der eine Namensvalidierung durchführt, Zugriff auf ein mit dem Aspace verknüpftes Schema oder auf Informationen darüber haben. In manchen solcher Ausführungsformen kann das gelesene Token im Hinblick darauf bewertet werden zu ermitteln, ob es einen gültigen Moniker 1090 innerhalb des Schemas der Aspace definiert, der momentan oben im Stapel ist. Wenn kein Aspace im Stapel vorhanden ist, kann die Validierung in Bezug auf einen oder beide der Aspaces erfolgen, die lokal für das System, Teilsystem oder den Prozess vorhanden sind, das/der die Namensvalidierung durchführt, oder in Bezug auf einen oder mehrere global definierte Aspaces, die Sätze oder Teilsätze von Attributen für alle Objekte über mehrere Systeme hinweg definieren.
Wenn ermittelt wird, dass das gelesene Token ein ungültiger Moniker ist, kann eine Fehlermeldung 1080 ausgegeben werden. In manchen Fällen kann die Namensvalidierung trotz Ausgabe einer Fehlermeldung 1080 fortgesetzt werden, sodass mehrere Fehlermeldungen während einer Validierung zugelassen werden. In anderen Ausführungsformen können akkumulierte Fehlermeldungen am Ende eines Validierungsprozess ausgegeben werden. In wiederum anderen Ausführungsformen kann ein Fehler den Validierungsprozess vollständig anhalten. Wenn alle Moniker in einem Namen gültig zu sein bestimmt sind, kann ein Indikator zurückgegeben werden signalisiert, dass der Name gültig 1070 ist.
In manchen Ausführungsformen können die Verarbeitung und Analyse vereinfacht werden, wenn das _aspace-Attribut als erstes stehen muss, aber eine etwas komplexere Technik kann verwendet werden, auch wenn das nicht der Fall ist, solange die Syntax von Namen analysiert werden kann. Ein Beispiel für eine etwas komplexere Technik kann in das Analysieren in zwei Phasen beinhalten, wobei in der ersten Phase das _aspace-Attribut identifiziert wird und die zweite Phase wie in 1 beschrieben abläuft.
Aspace-Organisation
In machen Ausführungsformen können Aspaces in Bezug aufeinander unter Verwendung verschiedener Modelle organisiert werden. Eine Ausführungsform kann ein Kamm-Modell verwenden. Ein Kamm-Modell ist gegeben, wenn es eine Eins-zu-eins-Übereinstimmung zwischen Aspaces und Systemen in der Umgebung gibt. In einer solchen Ausführungsform ist jeder Aspace an ein einziges System gebunden.
In einer anderen Ausführungsform kann ein Wald-Modell verwendet werden. In manchen Ausführungsformen kann ein Wald-Modell als Erweiterung des Kamm-Modells betrachtet werden. Ein Wald-Modell kann nützlich sein, wenn es erwünscht ist, dass bestimmte Attribute systemübergreifend gemeinsam genutzt werden. Dieser Ansatz definiert einen globalen Wald (Sammlung von Bäumen), wobei jeder Aspace aus der Umgebung als ein Knoten im Wald erscheint. Zusätzlich können in manchen Ausführungsformen einige Aspaces in diesem Wald ungebunden sein (nicht an ein System gebunden) – dies ermöglicht die gemeinsame Nutzung von Attributen über Aspaces hinweg auf folgende Weise. Wenn Aspace A einen untergeordneten Aspace A_child hat, dann wird ein Moniker M in Aspace A mit gleicher Bedeutung und gleichen Einschränkungen von A_child geerbt, es sei denn A_child deklariert einen neuen Moniker M neu, um den Moniker M von A zu überschreiben. In wiederum einer anderen Ausführungsform kann ein Diagrammmodell verwendet werden, das eine Verallgemeinerung des Wald-Modells, bei dem ein Aspace mehrere übergeordnete Räume sowie mehrere untergeordnete Räume haben kann. Ein Beispiel für ein Diagrammmodell ist in 2a abgebildet.
In der dargestellten Ausführungsform kann System 1 einen Aspace 2200 auf oberster Ebene und zwei Aspaces 2220, 2240 auf niedrigerer Ebene haben. Die zwei Aspaces 2220, 2240 auf niedrigerer Ebene können untergeordnete Räume des auf oberster Ebene befindlichen Aspace 2200 sein. Manche Ausführungsformen eines Diagrammmodells können auch einen oder mehrere ungebundene Aspaces 2210, 2230 beinhalten, die nicht an ein bestimmtes System gebunden sind. In der dargestellten Ausführungsform können der ungebundene Aspace 1 2210 und der ungebundene Aspace 2 2230 jeder Attribute für System 1 Aspace 2 2240 bereitstellen, sodass System Aspace 2 2240, trotzdem dieses ein untergeordneter Aspace von System 1 Top Aspace 2200 ist, Attributinformationen aus seinem übergeordneten Aspace 2200 und den zwei ungebundenen Aspaces 2210, 2230 empfängt. Im Gegensatz dazu empfängt System 1 Aspace 1 2200 nur Attribute von dem ihm übergeordneten Aspace 2200.
System 2 Aspace 1 2250 ist der einzige Aspace, der für System 2 in der dargestellten Ausführungsform definiert ist. Dieser Aspace empfängt Attribute aus beiden ungebundenen Aspaces 2210, 2230. System 3 Aspace 1 2260 empfängt nur Attribute aus dem ungebundenen Aspace 2 2230. In einer anderen Ausführungsform können System 2 Aspace 1 2250 und System 3 Aspace 1 2260 als untergeordnete Elemente des ungebundenen Aspace 2 2230 betrachtet werden, weil sie beide einen gemeinsamen Satz von Attributen aus diesem ungebundenen Aspace empfangen.
In manchen solcher Ausführungsformen wäre es möglich, wenn mehrere Systeme „ähnliche” Benennungstechniken verwenden, d. h. gemeinsame Attribute verwenden, dass ihre Benennungstechniken Attribute explizit gemeinsam nutzen, indem sie einen Baum ungebundener Aspaces erstellen, die übergeordnete Elemente/Vorfahren der gebundenen Aspaces sind. Damit beispielsweise zwei Systeme S1 und S2 Attribute gemeinsam nutzen, ist es möglich, 1) einen ungebundenen Aspace U12 zu erstellen, 2) die Aspaces von S1 und S2 als untergeordnete Elemente von U12 festzulegen, 3) gemeinsame Attribute von S1 und S2 zu U hinzufügen, und 4) diese gemeinsam genutzten Attribute aus den Aspaces von S1 und S2 zu entfernen. Wenn beispielsweise System S1 das menschliche Benennungssystem US verwendet, während S2 das menschliche Benennungssystem Island verwendet, würde ihr ungebundener übergeordneter Aspace das Attribut <Vorname> (S1 und S2 gemeinsam) enthalten, während S1 und S2 <Nachname> jeweils getrennt voneinander definieren würden.
Eine Ausführungsform eines solchen Namensraumkonfigurationsschemas ist in 2b dargestellt. In der dargestellten Ausführungsform ist in einem ungebundenen Attributraum (Aspace) 2010 Moniker_1 20100 und Moniker_2 20110 definiert. Zwei systemspezifische Attributräume, System 1 2020 und System 2 2030, sind untergeordnete Aspaces des ungebundenen Aspace 2010. Innerhalb von System 1 Attributraum 2020 sind S1 Moniker_3 20120 und S1 Moniker_4 20130 definiert. Ein Objekt im System 1 Attributraum 2040 wäre daher als Objekt definiert, das Instanzen von Moniker_1 20200 und von Moniker_2 20120 vom ungebundenen Attributraum 2010 sowie auch Moniker_3 20220 und Moniker_4 20230 vom System 1 Attributraum 2020 geerbt hat.
Eine Ausführungsform des Diagrammmodells kann vorhanden sein, wenn sich ein System selbst in mehreren Aspaces abbildet. Das kann für große Systeme (z. B. bestehend aus einer großen, verteilten Entwicklergruppe) nützlich sein und hilft, die Weiterentwicklung von Schemata und Namen in Subsystemen zu entkoppeln. Im Laufe der Zeit, während sich das System entwickelt, können diese Aspaces verschmolzen oder weiter aufgeteilt werden. Das Diagrammmodell erlaubt auch eine unabhängige Weiterentwicklung von Benennungssystemen. Um beispielsweise in einer solchen Ausführungsform ein neues System S* einzufügen, das seine Benennungen im Wesentlichen mit einem bestehenden System S gemeinsam nutzt, kann es möglich sein, dass der Aspace von S* ein untergeordnetes Element des Aspace von S ist – der Aspace von S* kann dann Attribute überschreiben, die nicht gemeinsam genutzt werden.
Eine solche Ausführungsform wird in der Definition von System 2 Attributraum 2030 gezeigt. In System 2 Attributraum 2030 ist S2 Moniker_3 20140 definiert. Außerdem ist Moniker_2 20150 innerhalb des System 2 Attributraums 2030 erneut definiert, und diese Definition überschreibt die Definition von Moniker_2 20110 aus dem ungebundenen Attributraum 2010, der dem System 2 Attributraum übergeordnet ist. Ein Objekt im System 2 Attributraum 2050 wäre daher als Objekt definiert, das Instanzen von Moniker_1 20240 vom ungebundenen Attributraum 2010 sowie auch S3 Moniker_3 20260 und Moniker_2 20250 vom System 2 Attributraum 2030 geerbt hat.
Ausführungsformen einer solchen Namensraumorganisation können realisiert werden, indem Regeln oder Datenstrukturen oder Kombinationen davon innerhalb von einem oder mehreren Systemen oder über mehrere Systeme hinweg erstellt oder anderweitig festgelegt werden. Solche Regeln und/oder Datenstrukturen können Datenbanken oder Datenbankbeschränkungen wie z. B. relationale Beschränkungen beinhalten. Andere Ausführungsformen können eine solche Namensraumorganisation realisieren, indem eine domänenspezifische Sprache definiert wird, um Aspace-Elternbeziehungen zu deklarieren oder auch durch Ad-hoc-Codierung solcher Beziehungen in einer Allzwecksprache (z. B. C++, Java oder Ruby).
Ähnliche Systeme (und somit Aspaces) können entfernt werden, indem einfach ihre Aspace-Knoten aus dem Wald/Kamm entfernt werden. Wenn die Aspace-Moniker durch andere Aspaces (Kind/Nachfahre) geerbt wurden, werden die Definitionen für diese Moniker nach „unten” im Baum repliziert, sodass sie nach Entfernen des Aspace-Knotens weiterhin existieren. In manchen Ausführungsformen wird der Wald in eine Sammlung von DAGs (Direct Acyclic Graphs; gerichtete azyklische Graphen) verallgemeinert. In solchen Ausführungsformen kann ein Aspace mehrere übergeordnete Elemente haben. Solche Ausführungsformen können ähnlich wie die mehrfache Vererbung in objektorientierten Programmiersprachen realisiert werden.
Kontextsensitive Benennung
Dieses Dokument offenbart auch Techniken, die es menschlichen Benutzern erlauben können, kurze Namen zu lesen und mit kurzen Namen umzugehen (z. B. in der Benutzeroberfläche oder Befehlszeile), während Maschinen längere vollständig qualifizierte (auch als voll bezeichnete) Namen verwenden können. Ausführungsformen dieser Techniken basieren auf dem Konzept kontextsensitiver Namen. Ein kontextsensitiver Name ist ein Teilname und/oder eine Kurzversion des vollen Namens. Intuitiv ist ein voller Namen = kontextsensitiver Name „+” Informationen aus dem Kontext. In manchen Ausführungsformen kann ein Kontext mit einer Benutzersitzung, Nutzungsumgebung oder einer Anwendung oder Oberfläche verknüpft sein (z. B. einer Reihe von UI-Seiten, einer Befehlseingabe, einem Unix-Verzeichnis, einem Perforce/SVS-Client usw.).
In manchen Ausführungsformen kann ein Kontext als ungeordnete Sammlung von Triples (Aspace-Moniker-Wert) definiert sein. In manchen Ausführungsformen eines Kontext kann jede Aspace-Moniker-Kombination höchstens einmal erscheinen. Ein voller Name (oder kontextfreier Name) kann global eindeutig sein und genau mit einem gegebenen Schema übereinstimmen. Wenn ein Triple (Kontext, voller Name, Schema) gegeben ist, kann eine Ausführungsform eines kontextsensitiven Namens erstellt werden, indem alle Aspace-Moniker-Wert-Triples aus dem vollen Namen entfernt werden, die bereits im Kontext erscheinen (zur Erinnerung: der Aspace-Moniker in einem Namen wird über den Aspace-Stapel ermittelt). So kann beispielsweise der volle Name eines Amerikaners lauten [_aspace=US Vorname=John Nachname=Smith]. Wenn der Kontext der Familie Smith gegeben ist, d. h. der durch das Triple ausgedrückte Kontext (aspace=US, moniker=_aspace, Wert=US) (aspace=US, moniker=Nachname, Wert=Smith), können wir den kontextsensitiven Namen produzieren [Vorname=John]. Das kann durch einen Algorithmus automatisiert werden, der alle Ausdrücke moniker=Wert in einem Namensraum Aspace aus den vollständig qualifizierten Namen entfernt, die mit einem im Kontext definierten Triple (aspace, moniker, Wert) übereinstimmen.
In manchen Ausführungsformen ist es auch möglich, den vollen Namen aus dem Triple (Kontext, kontextsensitiver Name, Kontext) zu rekonstruieren. In manchen Ausführungsformen, beginnend mit dem kontextsensitiven Namen, wird der kontextsensitive Name an das Schema angepasst, indem angemessene Attribute aus dem Kontext hinzugefügt werden. Eine Ausführungsform einer solchen Technik zur Rekonstruktion eines vollen Namens, wie in 3 gezeigt, ist Folgendes:

Eingabe: Schema S, kontextsensitiver Name N und Kontext C:
Ausgabe: N als vollständig qualifizierte Name
während (nicht am Ende von S) {
a. S und N zusammen von links nach rechts lesen, unter Aufrechterhaltung eines Aspace-Stapels, gefüllt von S (unter Verwendung des im Aspace-Abschnitt beschriebenen Algorithmus);
b. den nächsten fehlenden Moniker m=<beliebiger Wert> in S, aber nicht in N finden;
c. wenn m ein Aspace-Moniker ist, diesen von S nach N kopieren und fortfahren;
d. a zum Aspace-Moniker oben im Aspace-Stapel machen;
e. in C nach dem Triple suchen, das Aspace a und Moniker m beinhaltet und <a=N> an N anhängen;
f. fortfahren;
}

Solche Erzeugungs- und Wiederherstellungstechniken für kontextsensitive Namen können die Interaktion des Benutzers mit Namen in einem komplexen Umfeld verbessern. In einer Ausführungsform kann eine Cluster-Verwaltungsumgebung aus mehreren Scheduler-Systemen bestehen. In einer solchen Ausführungsform kann ein Benutzer foo einen Job namens „bar” an Scheduler 1 senden. Der Job kann dann gestoppt werden und eine andere Instanz des gleichen Jobs kann an Scheduler 2 gesendet werden. In einer Ausführungsform, die die Fähigkeit zur Erzeugung und Wiederherstellung kontextsensitiver Namen hat, ist ein kontextsensitiver Name für beide Jobs, wie ihn der Benutzer in der Benutzeroberfläche und Befehlszeile sieht, einfach nur „bar” – kurz, gut lesbar und einprägsam. Dieser kontextsensitive Name beinhaltet nicht „foo” oder Informationen über die Scheduler – in manchen Ausführungsformen können jedoch die vollen Namen für jeden der Jobs diese Informationen beinhalten. Die Erzeugungs- und Wiederherstellungstechniken für kontextsensitive Namen können verwendet werden, um zwischen den vollen und den kontextsensitiven Namen auf der Benutzeroberfläche oder auf Agent-/Scheduler-Seite oder in beidem zu übersetzen.
Bezugnehmend auf das obenstehende Beispiel, einem mit einem oder mehreren Schedulern verknüpften Schema 3001, können der Kontextname „bar” 3020 und ein Kontext 3030 innerhalb eines Rechenzentrums oder Datenprozessors, die zur Durchführung eines Wiederherstellung des vollen Namens aus Kontextnamen bestimmt sind, für ein System, Subsystem oder einen Prozess zur Verfügung gestellt werden. Der Kontext 3030 kann Informationen über einen Job, eine Ressource oder eine Anforderung enthalten, die mit dem Kontextnamen 3020 verbunden sind, einschließlich Herkunfts- und/oder Zielinformationen.
Wenn man das Schema 3001 und den Kontextnamen 3020 zusammen liest 3040, kann ein fehlender Moniker M identifiziert werden 3050, der im Schema 3001 gefunden wurde, jedoch nicht im Kontextnamen 3020. Wenn der Moniker, M, ein Aspace-Moniker 3060 (d. h. ein Moniker, das einen Namen- oder Wertindikator eines Aspace oder Namensraums definiert) ist, kann der Moniker aus dem Schema in den Namen 3080 kopiert und auf den Stapel geschoben werden (nicht gezeigt). Wenn ein Token, das ein Ende eines Aspace angibt, beim Lesen des Schemas angetroffen wird, kann der Wert oben im Stapel genommen werden (nicht gezeigt). Ein solcher Vorgang kann beim Lesen 3040 des Kontextnamens und des Schemas vorkommen.
Wenn der Moniker, M, kein Aspace-Moniker 3060 ist, wird der Aspace-Moniker, A, oben im Stapel gelesen und der Kontext 3030 wird nach einem Triple durchsucht (3100), das den Aspace-Moniker A, den fehlenden Moniker M und einen mit diesem fehlenden Moniker verknüpften Wert beinhaltet. Wenn das Triple gefunden wird 3110, werden der fehlende Moniker und der damit verknüpfte Werte an den Namen 3090 in Verbindung mit dem Aspace-Moniker A angehängt, der bereits an den Namen basierend auf der Organisation des Schemas 3001 angefügt wurde. Wenn der Aspace-Moniker noch nicht Teil des Namens ist, kann er zu diesem Zeitpunkt auch hinzugefügt werden. Wenn das Triple nicht gefunden wird, kann eine Fehlermeldung ausgegeben oder in anderer Weise erzeugt werden 3120, die darauf hinweist, dass das Triple nicht gefunden wurde.
Wenn das gesamte Schema auf diese Weise gelesen wurde 3010, können für den Kontextnamen 3020 mehrere Hinzufügen- und/oder Anhängen-Vorgänge vorgenommen wurden sein, um einen vollständig qualifizierten Namen 3070 (manchmal auch als voller Name bezeichnet) zu erzeugen, der dann an eine wie auch immer geartete Einheit, einen Prozess oder ein System oder Subsystem zurückgegeben oder weitergeleitet werden kann, die/der die vollen Namensinformationen benötigt, um den Job oder die Anforderung zu erfüllen oder in anderer Weise auf die im vollen Namen angegebene Ressource einzuwirken.
Manche Ausführungsformen von Erzeugungs- und Wiederherstellungstechniken von kontextsensitiven Namen können für die Verwendung in grafischen Benutzeroberflächen geeignet sein. Eine Ausführungsform kann die Navigation durch eine Reihe von Seiten bewirken, wie z. B.: Alle Benutzerjobs -> Job-Bar -> Aufgabe 0 von Job-Bar. In einer solchen Ausführungsform können alle Aufgaben das Schema [Aspace, Aufgabennummer, Jobname] haben, und alle Benutzeroberflächenseiten listen alle Aufgaben des Benutzers auf. Auf der ersten Seite (alle Benutzerjobs) können alle Aufgabennamen mit ihren vollen Namen präsentiert werden. Wenn der Benutzer zur zweiten Seite (Job-Bar) navigiert, kann nur die Aufgabennummer der Job-Bar erscheinen und so wird der kontextsensitive Name dargestellt als [Aufgabennummer=_] (Aspace und Jobname sind jetzt Teil des Kontexts). Auf der dritten Seite (Aufgabe 0) kann der kontextsensitive Name leer sein, weil der gesamte Name im Kontext ist.
Metadaten
Metadaten bezieht sich auf Informationen, die einen Namen enthalten, aber nicht wesentlich sein können, um die Ressource zu identifizieren, die benannt wird. In manchen Ausführungsformen können solche Informationen als Hinweise von menschlichen Benutzern und Maschinen verwendet werden. In manchen solcher Ausführungsformen können Metadaten ein ungeordneter Satz von Elementen sein, die mit einem oder mehreren Eigenschaften eines Namens verbunden sind und somit transitiv zu denen der benannten Ressource. Metadatenelemente können individuelle Triple Aspace-Moniker-Wert oder Namen beinhalten. Ausführungsformen eines Metadatenelements können entweder instanzspezifisch (für eine Ressource, die benannt wird) oder artspezifisch (zu allen Ressourcen einer gegebenen Art gehörend) sein. In manchen Ausführungsformen könnte jedes Metadatenelement als entweder „Namensmetadaten” oder „Ressourcenmetadaten” oder beides bezeichnet sein.
In manchen Ausführungsformen können Metadaten Informationen über Folgendes beinhalten (müssen aber nicht notwendigerweise darauf beschränkt sein): einen Resolver (z. B. Resolver-Standort oder Latenzen für verschiedene Resolver); einen Typ von Adresse, der vom Resolver gewünscht wird (z. B. AAAA-Datensatz, MX-Datensatz); Kontext(e) (für einen kontextsensitiven Namen) – es ist zu beachten, dass ein kontextsensitiver Name mehrere Kontexte haben kann, die jeder potenziell einen anderen vollen Namen erzeugen; ACLs (Access Control Lists, Zugriffssteuerungslisten) für den Namen (d. h. wer diesen Namen lesen oder auflösen kann); sowie andere Information (z. B. aktuelle Maschine, auf der eine Aufgabe mit dem Namen geplant ist).
In manchen Ausführungsformen können Metadaten an einer oder mehreren der folgenden Stellen gespeichert werden: angehängt an den Namen, im Resolver (z. B. ACLs in einem Verzeichnis), in einem Kontext oder in anderen Datenspeichern (z. B. indiziert durch Namen oder Fragmente von diesen). Sie können zum Namen bei der Auflösung hinzugefügt werden, z. B. bisher aufgewendete Zeit, Anzahl der Sprünge, Hinweise für nächste Phasen usw. (hinsichtlich des Auflösungsprozesses). In manchen Ausführungsformen können Metadaten als Hinweise für menschliche Benutzer und Maschinen nützlich sein – sie können durch andere Systeme (z. B. Resolver), durch den Client oder die Benutzeroberfläche (z. B. Kontext) oder durch Resolver (z. B. Adressentyp) verwendet werden.
Hinsichtlich der Namensauflösung kann ein Name, der Namen aus mehreren Systemen enthält, in manchen Ausführungsformen über eine Reihe von Auflösungspunkten aufgelöst werden, die jeder einen Teil des Namens konsumieren und nachschlagen, bevor sie ihn an die nächste Phase im Prozess weiterleiten. (Das Nachschlagen von UNIX-Dateinamen ist ein Beispiel für diese Form: jeder Schritt konsumiert einen Verzeichnisnamen.) Metadaten können diesen Prozess unterstützen, indem sie beispielsweise einen Hinweis darauf geben, wie viele Attribute Moniker=Wert durch einen gegebenen Resolver gelöst werden sollten, bevor der Namen an den nächsten Resolver weitergeleitet wird.
In manchen dieser Ausführungsformen können die Metadaten angeben, welche Attribute in welchem Schritt des Auflösungsprozesses konsumiert werden sollen. In manchen Ausführungsformen können die Metadaten auch die Latenzen bei jedem Schritt des Auflösungsprozesses angeben – diese werden mit dem Namen kumuliert, damit die effizientesten Auflösungspfade gewählt werden können. In weiteren Ausführungsformen kann der vom Resolver zurückgegebene Wert typgeprüft werden, wenn die Metadaten angeben, dass ein MX-Datensatz von einem Resolver erwartet wird. Die Fähigkeit des Clients des Resolvers, den erwarteten Adressentyps geltend zu machen, kann die Richtigkeit der Auflösung verbessern.
In manchen Ausführungsformen kann ein kontextsensitiver Name Kontext oder Kontexte in seinen Metadaten beinhalten (potenziell mehrere Kontexte). Terminierungsinformationen wie Maschinen können nützlich als Hinweise (für menschliche Benutzer oder für Maschinen) für den Versuch der Kommunikation mit der Aufgabe sein – wenn die Aufgabe verschoben wurde, schlägt der Versuch einfach fehl und dieser Teil von Metadaten kann annulliert werden.
In manchen Ausführungsformen kann es Fragen zur Richtigkeit oder Gültigkeit von Metadaten geben (z. B. ACL widerrufen, Resolver verschoben usw.). In manchen solcher Ausführungsformen besteht ein Ansatz, dieses Problem anzugehen, darin, Metadaten als zwischengespeicherte Informationen und nicht als verbindliche Informationen zu behandeln. In manchen Ausführungsformen können solche zwischengespeicherten Informationen nach einem angegebenen Zeitraum, wie einem Timeout-Zeitraum, verfallen.
Namensschemata und Add-ons
In manchen Ausführungsformen eines Benennungsschemas wie hierin diskutiert kann die Idee der Verwendung eines maschinenlesbaren Schemas zur Beschreibung des Inhalts und Formats von Namen (z. B. eine Liste von Attributen) in folgender Weise erweitert werden:

a. durch Bereitstellen von Validierungsfunktionen pro Attribut im Schema – z. B. zur Prüfung, ob die Werte des Attributs richtig oder akzeptabel sind (z. B. hinsichtlich Typ, Länge (Min. und Max.), Inhalt (z. B. Bereich zwischen 0 und 100) usw.). So könnte beispielsweise ein Benutzernamen-Attribut die Beschränkung gelten, dass seine Werte mindestens 6 Zeichen lang müssen und nur Buchstaben und Ziffern enthalten dürfen.
b. durch Bereitstellen von Validierungsfunktionen für mehrere Attribute im Schema: Prüfungen, bei denen mehrere Attribute auf einmal geprüft werden (z. B. wenn der Wert einen Attributs A eine numerische Zeichenfolge ist, dann ist der Wert eines Attributs B eine Folge alphabetischer Zeichen).

In manchen Ausführungsformen können diese Validierungsfunktionen oder Varianten oder Kombinationen davon aufgerufen werden, wenn ein Name bereitgestellt oder aufgebaut wird oder auf Anforderung, um die Gültigkeit zu prüfen. Unter erneuter Bezugnahme auf 1 kann in einer Ausführungsform die Bestimmung der Gültigkeit des Moniker 1090 so erweitert werden, dass sie eine Prüfung des Attributs selbst beinhaltet.
Ursprungsattribute
Manche Ausführungsformen eines Schemas zur Namensvalidierung und/oder Ableitung wie hierin diskutiert können die Idee eines speziellen untypisierten Namensattributs beinhalten, das in einem Namensschema verwendet werden kann. In manchen Ausführungsformen kann ein solches Attribut „origin” oder „_origin” genannt werden. In manchen Ausführungsformen eines Namensschemas kann ein untypisiertes Namensattribut wie „origin” als Wert einen vollständig qualifizierten Ressourcennamen annehmen, der einem beliebigen Schema entspricht. In manchen Ausführungsformen kann das Attribut „origin” mit einer rekursiven Verwendung kompatibel sein, d. h. es kann eine arbiträre Anzahl von verschachtelten „origins” in sich selbst (und/oder in anderen Ressourcennamen) enthalten. In manchen Ausführungsformen kann eine solche rekursive Verwendung (d. h. Verschachtelung) ursprünglich gelieferte Ressourcennamen rekursiv erhalten. In manchen Ausführungsformen können die ursprünglich gelieferten Ressourcennamen aus einer internen Komponente oder von einem menschlichen Benutzer oder Administrator kommen. Insbesondere im Fall von durch menschliche Benutzer festgelegten Namen bleiben bei dieser rekursiven Verwendung die ursprünglichen durch den menschlichen Benutzer festgelegten Namen erhalten.
In manchen Ausführungsformen liefert diese rekursive Verschachtelung eine Technik für das Durchführen von durch menschliche Benutzer festgelegten Namen, indem der ursprüngliche, durch den menschlichen Benutzer festgelegte Name als Attribut in dem durch das System verwendeten Namen codiert wird. In manchen Ausführungsformen kann auf der Benutzeroberfläche und in Berichten (z. B. Fehlerprotokollen) der ursprüngliche Name genannt werden, und Benutzeroberflächen-Abfragen können den ursprünglichen Namen unter Verwendung eines solchen „origin”-Attributs verwenden. In manchen Ausführungsformen beinhalten alle internen Namen ein „origin”-Attribut. In manchen Ausführungsformen können alle abgeleiteten Namen so konfiguriert werden, dass sie ein „origin”-Attribut übergeben. In manchen Ausführungsformen ist auch möglich, einem „origin”-Attribut Metadaten zuzuweisen, die erklären, wie es darzustellen ist (z. B. ein Minischema, das angibt, wie es zu analysieren oder anzuzeigen ist – d. h. durch Weglassen von Teilen, die nicht notwendig sind).
In manchen Ausführungsformen kann es mehrere Syntaxformen zur Darstellung von „origin”-bezogenen Ableitungen geben. Eine Syntax-Ausführungsform kann die Verschachtelung beinhalten. In manchen Verschachtelungs-Ausführungsformen kann die Syntax das Hinzufügen eines „origin”-Attributs bewirken, dessen Wert der Ursprungsname ist [_schema=derived attr1=... _origin=[_schema=original attr2= ...]] Eine andere Syntax-Ausführungsform kann die Sequenzierung beinhalten. In manchen Sequenzierungs-Ausführungsformen kann die Syntax bewirken, dass der Ursprungsname rechts von den neuen Teilen geschrieben wird, mit einem „join”-Operator wie „+” oder „I” (dies wird manchmal als „Wurstform” bezeichnet): [_schema=derived attr1=... ] + [_schema=original attr2= ...] Eine solche Ausführungsform des Ursprungsattributes ist in 4 dargestellt.
In 4 kann einem Objekt ein durch einen menschlichen Benutzer eingegebener oder durch einen menschlichen Benutzer erzeugte Name 4110 gegeben werden. Dieses Objekt kann dann als Objekt in ein erstes Schema 4000 oder einen Namensraum eingeschlossen werden. Dieses Schema kann dem Objekt bestimmte Moniker oder Attribute zuweisen. Ein Objekt im Schema 4000 kann beispielsweise einen ersten Moniker 4010 und einen zweiten Moniker 4010 haben. Das Objekt 4000 kann auch ein Ursprungsattribut 4030 beinhalten, das den durch den menschlichen Benutzer erzeugten Objektnamen aufbewahrt.
Auf die durch das erste Schemaobjekt 4000 identifizierte Ressource kann in einem zweiten Schema (Schema 1-1) als Objekt dieses Schemas 4040 verwiesen werden. Das Schema 1-1 kann in manchen Ausführungsformen ein untergeordnetes Element des ersten Schemas sein. In einer solchen Ausführungsform kann das Schema-1-1-Objekt 4040 den ersten Moniker 4060 und den zweiten Moniker 4070 aus dem vorherigen Schema sowie ein Ursprungsattribut 4100 erben. In anderen Ausführungsformen kann eine solche Vererbung nicht stattfinden, weil entweder der Attribute überladen sind oder weil ein Schema nicht das untergeordnete Element eines anderen Schemas ist. In diesen Ausführungsformen kann das Schema 1-1 ein gesondertes oder überladenes Attribut 4090 statt des geerbten Attributs 4100 haben. Das Schema 1-1 kann auch seine eigenen Objektattribute definieren, z. B. S11_Moniker_3 4050 und S11_Moniker_4 4080. In Ausführungsformen, in denen das Schema 1-1 nicht ein untergeordnetes Element des ersten Schemas ist oder in denen das Ursprungsattribut 4090 des Schemas 1-1 überladen ist, kann das Ursprungsattribut 4090 des Schema-1-1-Objekts in manchen Ausführungsformen zurück auf das Ursprungsattribut 4030 des Schema-1-Objekts 4000 verweisen. In anderen Ausführungsformen kann das Schema-1-1-Objekt 4040 auch auf den durch einen menschlichen Benutzer erzeugten Objektnamen 4110 im Ursprungsattribut verweisen. In Ausführungsformen, in denen das Schema-1-1-Objekt 4040 auf das Schema-1-Objekt 4000 in seinem Ursprungsattribut verweist, kann der Wert des Ursprungsattributs 4030 aus dem Schema-1-Objekt 4000 als in den Wert des Ursprungsattributs 4090 des Schema-1-1-Objekts 4040 verschachtelt bezeichnet werden.
Regeln zur Beschreibung von Namensableitungen
Manche Ausführungsformen von Namensschema- und Namensableitungstechniken können auch Techniken betreffen, die es erlauben, dass ein Zielressourcennamen entsprechend einem gegebenen Schema von einem oder mehreren Quellnamen und zusätzlichen Informationen (z. B. Attributwerten) abgeleitet wird. Solche Techniken können in Form von Ableitungsregeln oder Transformationsregeln ausgedrückt werden. Ausführungsformen dieser Regeln können einige oder alle der Folgenden beinhalten:

a. Ändern eines Werts eines Schemaattributs (z. B. von X in XStatus), wobei der Rest der Attribute jedoch unverändert bleibt.
b. Ändern von einem oder mehreren anderen Attributwerten (z. B. wenn Zelle=IA, dann kann ein Backup immer in Zelle=IB sein).
c. Hinzufügen von Attributen (z. B. Aufgabennamenschema = Jobnamenschema + Aufgabenattribut).
d. Löschen von Attributen (z. B. Jobnamenschema = Aufgabennamenschema – Aufgabenattribut).
e. Verschachteln von Namen: Ein Ressourcenname gemäß dem hierin beschriebenen Benennungsschema kann andere Ressourcennamen als Werte von Attributen (basierend auf dem Schema) enthalten („verschachteln”).
i. In manchen Ausführungsformen können die verschachtelten Namen entweder typisiert (entsprechend einem bestimmten Schema) oder untypisiert (kann jedem Schema entsprechen) sein.
ii. In manchen Ausführungsformen können solche verschachtelten Namen verwendet werden, um den Namen eines „Eltern-Objekts” und/oder von „Quellobjekten” des benannten Objekts aufzuzeichnen.
iii. In manchen Ausführungsformen können durch den Benutzer angegebene Jobanfrageobjekts wie Zuweisungen (Allocs) und Aufgaben gebundene Instanziierungen auf Maschinen haben. Ein BoundX-Schemaname kann einen verschachtelten X-Schemanamen enthalten.
iv. In manchen Ausführungsformen kann ein verschachteltes Attribut _origin, dessen Wert ein durch den Benutzer angegebener Jobname ist, hinzugefügt werden, um den Namen des Jobs im System abzuleiten.
f. Extrahieren eines Attributs aus einem verschachtelten Namen (z. B. Extrahieren des X-Namens aus dem BoundX-Namen, Extrahieren des durch den Benutzer angegebenen Jobnamens aus dem Systemjobnamen).
g. Einzelnes Auswählen nur einiger Teile eines oder mehrerer Quellnamen, möglicherweise mit zusätzlichen Attributen, um einen Zielnamen abzuleiten. Beispielsweise bei der Umplanung eines Jobs von einer Zelle in eine andere, Verwenden der Benutzer- und Jobattribute aus dem Namen einer Jobinstanz, zusammen mit dem Namen der neuen Zelle, um einen neuen Namen für die nächste Instanz des Jobs abzuleiten.
h. Allgemeinere Transformationen, die sich auf mehrere Attribute auswirken, oder Kombinieren der Werte mehrerer Attribute in einem neuen (z. B. bei der Übersetzung eines Aufgabennamens in einen Namen, der eine einzelne DNS-Zeichenkette enthält, Kombinieren der Zellen-, Benutzer-, Job- und Aufgabenattribute aus dem früheren in einer Zeichenkette für das letztere).

Einige Ausführungsformen können auch die Idee betreffen, diese Transformationen als Zusatzinformationen in einem Schema zu beschreiben, entweder in einer speziellen Sprache, die die Regeln ausdrückt, oder als eingebetteten (interpretierbaren) Code. Andere Ausführungsformen können die Idee betreffen, diese Transformationen als eigenständigen Code zu beschreiben (z. B. C++-Code in einem System, möglicherweise der Implementierung der Objekte zugewiesen, die benannt werden). In manchen dieser Ausführungsformen können die Schema-Spezifikationen verwendet werden, um automatisch Code für Namensableitungen für die gegebenen Schema-Spezifikationen zu erzeugen, d. h. das bzw. die Quellschemata und das Zielschema.
So übersetzt beispielsweise die unten gezeigte exemplarische Anweisungsfolge einen Aufgabennamen (Schema, das Job-, Aufgaben-, Inkarnationsattribute enthält) in den entsprechenden TaskStatus-Namen (Schema mit den gleichen Attributen, die sich nur im Aspace unterscheiden):

a. def GenTaskStatusName(task_name):
i. task_status_name = task_status_name.TaskStatusName
ii. task_status_name.aspace = ”TaskStatus”
iii. task_status_name.job = task_name.job
iv. task_status_name.task = task_name.task
v. task_status_name.incarnation = task_name.incarnation
vi. return_task_status_name

Eine solche Namensableitung kann es Software, die den Namen einer Aufgabe kennt, erlauben, automatisch auf den Namen des entsprechenden TaskStatus-Objekt zu „schließen”. Darüber hinaus kann man in Ausführungsformen, in denen alle ONames eindeutig sind, wenn man die Namen der TaskStatus-Objekte hat, in der Lage sein, die zugewiesenen Aufgaben unter Verwendung von geeigneten Resolvern abzurufen.
Objektgruppen
Einige Ausführungsformen der Namensableitung wie hierin beschrieben können verwendet werden, um Namen-Gruppen zu liefern, mit einigen nützlichen Eigenschaft, wie zum Beispiel „alle diese Objekte müssen gleichzeitig gelöscht werden oder dürfen gar nicht gelöscht werden”. Eine solche Ausführungsform kann in Situationen nützlich sein, in denen ein bestimmter Ressourcennamen beispielsweise Mitglied mehrerer Gruppen ist.
In einigen Ausführungsformen können die Regeln, die verwendet werden, um zu bestimmen, ob Namen Teil einer Gruppe sind, in einem Schema angegeben werden: z. B. „alle Namen, in denen diese Attribute die gleichen Werte haben, können als Gruppe betrachtet werden”, oder „alle Namen mit dem Attribut foo=X müssen als Gruppe betrachtet werden”; in einigen Ausführungsformen können arbiträre zusätzliche Ausdrücke für die Gruppenmitgliedschaft verwendet werden. Manche dieser Schema-Ausführungsformen können auch eine Möglichkeit liefern, den Namen selbst zu verwenden, um eine Mitgliedschaft in mehreren Gruppen anzugeben. Ein Name BoundX kann beispielsweise in der gleichen Gruppe wie der Name BoundXAutomaton und der NameUnknownBoundXAutomaton sein. Alle diese drei Schemata enthalten die gleichen Attribute und somit ist jeder Name von jedem anderen in der Gruppe ableitbar.
In einigen weiteren Ausführungsformen können unterschiedliche Namenstypen in einer Gruppe versammelt werden, indem zusätzliche Verknüpfungs-Metadaten in Schemata geliefert werden, beispielsweise explizite Liste von verwandten Schemata oder eine baumähnliche Struktur zur Verbindung von Schemata (ein Schema kann eine Verknüpfung zu einem oder mehreren übergeordneten oder untergeordneten Schemata aufzeichnen, und alle Schemata mit der gleichen Wurzel können als eine Gruppe behandelt werden). Der Schema-Verknüpfungsbaum könnte perfekt auf den Baum der Namensableitungsregeln abgestimmt sein, völlig davon getrennt sein oder eine Mischung aus beiden sein. Die Regeln für die Schema-Verknüpfungsgruppenbildung können mit den Namenswertgruppenregeln kombiniert werden. In einigen weiteren Ausführungsformen können unterschiedliche Namenstypen in einer Gruppe versammelt werden, indem zusätzliche Verknüpfungs-Metadaten in Schemata geliefert werden, beispielsweise explizite Listen von verwandten Schemata und Ableitungscode, durch die Namen von einem Schema in Namen eines anderen Schemas konvertiert werden.
Automatische in der Zeit eindeutige Namen
Einige Ausführungsformen von Namensschemata und Namensableitungen können eine Technik beinhalten, um einen Namen in der Zeit und/oder bezogen auf den Ort eindeutig zu machen. In manchen Ausführungsformen kann dies durch Hinzufügen von zusätzlichen Informationen (z. B. zusätzliche Attribute) zum Quellschema realisiert werden, um sicherzustellen, dass ein Name auf genau ein Objekt innerhalb der Domäne von Interesse oder auf ein Objekt über alle Zeit hinweg verweist. In einer Ausführungsform kann dies durch Hinzufügen eines „Nonce”, eines eindeutigen zusätzlichen Werts realisiert werden. Nonce-Ausführungsformen können eine oder mehrere des im Folgenden genannten und/oder Kombinationen davon beinhalten:

a. universell eindeutige Kennungen (universally unique identifiers, UUIDs) – UUIDs können lange Strings beinhalten, die mit sehr hoher Wahrscheinlichkeit eindeutig sind
b. Generationsnummern – kurze Ganzzahlen, die zur Unterscheidung von Instanzen verwendet werden können, welche ansonsten gleich sein könnten
c. Zeitstempel oder Kurzformen von Zeitstempeln – wie die Erstellungszeit eines Namens, oder, in Ausführungsformen, in denen nicht mehr als ein Name pro Tag vorhanden sein kann, der Tag, an dem ein Name erstellt wurde

In einigen Ausführungsformen können die Form und der Typ von Nonce, die im Schema spezifiziert werden können, hinzugefügt werden. Wenn der Name der Quelle bereits eindeutig ist, besteht möglicherweise keine Notwendigkeit, zusätzliche Informationen hinzuzufügen. In manchen Ausführungsformen kann ein „Nonce”-Attribut, das die Eindeutigkeit sicherstellt, ein Attribut wie jedes andere sein. In einigen Ausführungsformen kann es folgendermaßen aussehen: nonce=047d7beb-91269947-21a90000-516d9alc. In manchen Ausführungsformen, wenn der Ursprung bereits ein Nonce hat, kann es sich empfehlen, dieses Nonce zu verwenden, um die Eindeutigkeit sicherzustellen, sodass kein weiteres Nonce eingeführt werden muss.
Manche Ausführungsformen von Namenschema und Namensableitung können eine Technik beinhalten, durch die eine spezielle Instanz eines Satzes von Objekten benannt werden kann. Eine solche spezielle Instanz eines Satzes kann beispielsweise das neueste Objekt in einem Satz von Objekten oder das erste nicht-vollendete Objekt sein (bei Objekten, die Anfragen darstellen). Manche Ausführungsformen dieser Technik können die Verwendung eines bezogen auf den Ort eindeutigen Namens (manchmal als fester Name bezeichnet) für einige Objekte (z. B. einen Job) ermöglichen, die das System dann in die neueste Version des Objekts auflösen kann (z. B. die neueste aktive Instanz des Jobs) – dies kann die Wiederverwendung der gleichen Jobnamen für mehrere Instanzen dieser Jobs zulassen.
In manchen Ausführungsformen kann eine solche Benennung von speziellen Instanzen mithilfe eines „locator”-Objekts durchgeführt werden, das den Namen des Zielobjekts enthält. In manchen Ausführungsformen kann der Locator als symbolische Verbindung zu dem bezogen auf die Zeit eindeutigen Namen fungieren, den er abbildet. In manchen dieser Ausführungsformen kann der Locator eine auf den Ort bezogen eindeutiger Name sein. Zur Ableitung des Locator-Namens aus dem bezogen auf die Zeit eindeutigen Namen kann eine Ausführungsform der Namensableitung verwendet werden (z. B. durch Entfernen des Nonce). In anderen Ausführungsformen kann der Name des Zielobjekts dynamisch (unter Verwendung der Namensableitung) aus dem Namen des Locator-Objekts und in einigen Fällen zusätzlichen Statusinformationen von außerhalb des Benennungssystem erzeugt werden (z. B. um das „größte” oder „nächste” Zielobjekt zu finden). In manchen Ausführungsformen kann der Locator aktualisiert oder ersetzt werden, wenn sich das Ziel ändert.
In manchen Ausführungsformen kann aus Leistungsgründen das Löschen eines Systemobjekts schnell und richtig realisiert werden, indem der Locator, nicht jedoch das Objekt selbst gelöscht wird. Eine solche Löschtechnik kann auch die Durchführung die Speicherbereinigung des Systemobjekts im Hintergrund und/oder in anderer Weise asynchron ermöglichen. Diese Ausführungsformen der Objektlöschung können die Schnelligkeit eines asynchronen Löschen und die Semantik eines synchronen Löschens bieten.
5 ist ein Blockdiagramm, das ein exemplarisches Computergerät 500 darstellt, welches für die Durchführung von Techniken zur Namenserzeugung und Namensableitung wie hierin beschrieben eingerichtet ist. In einer sehr grundlegenden Konfiguration 501 umfasst das Rechengerät 500 typischerweise einen oder mehrere Prozessoren 510 und einen Systemspeicher 520. Ein Speicherbus 530 kann für die Kommunikation zwischen dem Prozessor 510 und dem Systemspeicher 520 verwendet werden.
Abhängig von der gewünschten Konfiguration kann der Prozessor 510 von beliebigem Typ sein, einschließlich, jedoch nicht beschränkt auf einen Mikroprozessor (μp), einen Mikrocontroller (μct), einen digitalen Signalprozessor (DSP) oder eine beliebigen Kombination davon. Der Prozessor 510 kann einen weiteren Cachepegel, wie einen Cache 511 einer Ebene 1 und einen Cache 512 einer Ebene 2, einen Prozessorkern 513 und Registers 514, umfassen. Der Prozessorkern 513 kann eine arithmetische Logikeinheit (ALU), eine Gleitkommaeinheit (FPU), einen digitalen Signalverarbeitungskern (DSP Core) oder eine beliebige Kombination davon umfassen. Eine Speichersteuerung 515 kann auch mit dem Prozessor 510 verwendet werden, oder in einigen Implementierungen kann die Speichersteuerung 515 ein interner Teil des Prozessors 510 sein.
Abhängig von der gewünschten Konfiguration kann der Systemspeicher 520 von beliebigem Typ sein, einschließlich, jedoch nicht beschränkt auf flüchtigen Speicher (wie RAM), nichtflüchtigen Speicher (wie ROM, Flash-Speicher usw.) oder eine beliebige Kombination davon. Der Systemspeicher 520 enthält typischerweise ein Betriebssystem 521, eine oder mehrere Anwendungen 522 und Programmdaten 524. Anwendung 522 kann eine Durchsetzungsfunktion für Namensverwaltung, Namenserzeugung, Namensableitung und/oder Namensschema wie hierin diskutiert beinhalten. Die Programmdaten 524 umfassen Ortsdaten, wie beispielsweise eine oder mehrere Abhängigkeitslisten oder Objektnamenslisten 525, die nützlich zur Durchführung der gewünschten Operationen wie oben beschrieben sind. In einigen Ausführungsformen kann die Anwendung 522 so eingerichtet sein, dass sie mit Programmdaten 524 auf einem Betriebssystem 521 arbeitet, so dass das Gesamtsystem eine oder mehrere spezifische Variationen von Techniken ausführt, wie hierin diskutiert. Dies wird konzeptionell in 4 von den Komponenten innerhalb der gestrichelte Linie 501.
Computergerät 500 kann zusätzliche Funktionen oder Funktionalität sowie zusätzliche Schnittstellen für die Kommunikation zwischen der Basiskonfiguration 501 und allen erforderlichen Geräten und Schnittstellen aufweisen. Beispielsweise kann eine Bus-/Schnittstellensteuerung 540 verwendet werden, um die Kommunikation zwischen der Basiskonfiguration 501 und einer oder mehreren Datenspeichergeräte 550 über einen Speicherschnittstellenbus 541 zu erleichtern. Die Datenspeichergeräte 550 können entfernbare Speichergeräte 551, nicht-entfernbare Speichergerät 552 oder eine Kombination davon sein. Beispiele für Wechselspeicher- und Nicht-Wechselspeichergeräte sind z Magnetplattengeräte, wie z. B. Floppy-Disk-Laufwerke und Festplattenlaufwerke (HDD), optische Plattenlaufwerke, wie beispielsweise Compact Disc(CD)-Laufwerke oder Digital Versatile Disk(DVD)-Laufwerke, Solid State-Laufwerke (SSD) und Bandlaufwerke, um nur ein paar zu nennen. Beispielhafte Computerspeichermedien können flüchtige und nichtflüchtige, entfernbare und nicht entfernbare Medien enthalten, die in irgendeinem Verfahren oder einer Technologie zum Speichern von Informationen implementiert sind, wie zum Beispiel computerlesbare Anweisungen, Datenstrukturen, Programmmodule oder andere Daten.
Systemspeicher 520, Wechselspeicher 551 und Nicht-Wechselspeichergeräte 552 sind Beispiele für Computerspeichermedien. Computerspeichermedien enthalten, sind aber nicht beschränkt auf RAM, ROM, EEPROM, Flash-Speicher oder andere Speichertechnologie, CD-ROM, Digital Versatile Disks (DVD) oder andere optische Speichermedien, Magnetkassetten, Magnetbänder, Magnetplattenspeicher oder andere magnetische Speichervorrichtungen oder jedes andere Medium, das verwendet werden kann, um die gewünschte Information zu speichern, und auf die durch Computergerät 500 zugegriffen werden kann. Jedes derartige Computerspeichermedium kann ein Teil der Gerät 500 sein.
Computergerät 500 kann auch einen Schnittstellenbus 542 für die Kommunikation verschiedener Schnittstellengeräte (z. B. Ausgabeschnittstellen, Peripherieschnittstellen und Kommunikationsschnittstellen) mit der Basiskonfiguration 501 über den Bus/Schnittstellen-Controller 540 beinhalten. Beispielhafte Ausgabegeräte 560 umfassen eine Graphikverarbeitungseinheit 561 und eine Audioverarbeitungseinheit 562, die so konfiguriert werden können, dass sie über einen oder mehrere A/V-Anschlüsse 563 mit verschiedenen externen Geräte, wie beispielsweise einem Display oder Sprechern, kommunizieren können. Beispiele für Peripherieschnittstellen 570 beinhalten einen seriellen Schnittstellen-Controller 571 oder einen parallelen Schnittstellen-Controller 572, die für die Kommunikation mit externen Geräten, wie beispielsweise Eingabegeräten (z. B. Tastatur, Maus, Stift, Spracheingabegerät, Kamera, Touch-Eingabegerät usw.) oder anderen Peripheriegeräten (z. B. Drucker, Scanner usw.) über einen oder mehrere I/O-Ports 573 konfiguriert werden können. Ein Beispiel Kommunikationsgerät 580 Schließt einen Netzwerkkontrolleur 581 mit ein, welcher eingerichtet werden kann, um die Kommunikation mit einem oder mehreren Computergeräten zu unterstützen 590 über einer Netzwerkkommunikation über einen oder mehrere Kommunikationsports 582.
Die Kommunikationsverbindung ist ein Beispiel für Kommunikationsmedien. Kommunikationsmedien können typisch sein für die Darstellung von Computer lesbaren Anweisungen, Datenstrukturen, Programmmodulen oder anderen Daten mit einem angepassten Datensignal wie einer Trägerschwingung oder anderen Transportmechanismue und schließt jede Information der gelieferten Medien mit ein. Ein „angepasstes Datensignal” kann ein Signal sein, für das eines oder mehrere seiner Merkmale so festgelegt oder geändert sind, dass Informationen in dem Signal codiert sind. Zum Beispiel, und nicht begrenzt, Kommunikationsmedien können kabelgebundene Medien miteinschließen wie kabelgebundene Netzwerke oder direkt verkabelte Verbindung und kabellose Medien wie Akustik, Radiofrequenzen (RF), Infrarot (IR) und andere kabellose Medien. Das Computerprogramm lesbarer Medien wie es hier benutzt wird, kann beides miteinschließen, Speichermedien und Kommunikationsmedien.
Computergerät 500 kann als Teil eines kleinformatigen tragbaren (oder mobilen) elektronischen Gerät sein (z. B. ein Mobiltelefon, ein persönlicher Datenassistent (PDA), ein Personal-Media-Player-Gerät, ein drahtloses Web-Watch-Gerät, ein persönliches Headset-Gerät, ein anwendungsspezifisches Gerät oder einem Hybridgerät) das eine der oben genannten Funktionen beinhaltet. Computergerät 500 kann auch als ein Computer implementiert werden einschließlich Laptop- und Standcomputer-Konfigurationen.
In einigen Fällen besteht nur ein geringer Unterschied zwischen Hardware- und Software-Implementierungen von Aspekte der Systeme; die Verwendung von Hardware oder Software ist in der Regel (aber nicht immer, da in bestimmten Zusammenhängen die Wahl zwischen Hardware und Software kann bedeutsam werden kann) eine Designauswahl, die Kosten/Effizienz-Abwägungen darstellt. Es gibt dabei verschiedene Fahrzeuge, welche die Verfahren und Systeme und/oder andere Technologien beschreiben, die durchgeführt werden können (zum Beispiel Hardware, Software und/oder Firmware) und dass das bevorzugte Fahrzeug sich in dem Zusammenhang unterscheiden wird, in dem die Verfahren und/oder Systeme und/oder andere Technologien entwickelt werden. Zum Beispiel, wenn ein implementiertes bestimmt, dass die Geschwindigkeit und Genauigkeit entscheidend sind, der Überträger kann für eine Haupthardware und/oder Firmware-Fahrzeuge optieren; wenn er flexibel ist, kann er eine Hauptsoftware implementieren oder, wiederum, alternativ, der Überträger kann für eine Kombination optieren von Hardware, Software und/oder Firmware.
Die vorstehende detaillierte Beschreibung hat verschiedene Ausführungsformen der Geräte und/oder Prozesse mittels Blockdiagrammen, Flussdiagrammen und/oder Beispielen dargelegt. Insoweit wie solche Blockdiagramme, Flußcharts und/oder Beispiele eine oder mehrere Funktionen und/oder Operation beinhalten, werden sie verstanden von denen in der Wissenschaft, das jede Funktion und/oder Operation mit solchen Blockdiagrammen, Flußcharts oder Beispielen implementiert werden können, indviduell und/oder kollektiv, durch ein weites Angebot von Hardware, Software, Firmware der irgendeiner virtuellen Kombination davon. In einer Ausführungsform können einige Teile des hier beschriebenen Gegenstands über anwendungsspezifische integrierte Schaltungen (ASICs), Field Programmable Gate Arrays (FPGAs), digitale Signalprozessoren (DSPs) oder andere integrierte Formate implementiert werden. Wie auch immer, diese in der Wissenschaft eingerichteten werden erkennen, dass einige Aspekte der Verkörperung miteingeschlossen sind, im Ganzen oder in Teilen, können äquivalent implementiert im integrierten Kreislauf, als ein oder mehrere Computerprogramme laufen auf einem oder mehreren Computer (beispielsweise als ein oder mehrere Programme auf einem oder mehreren Computersystemen) wie auf einem oder mehreren Programmen laufen auf einem oder mehreren Prozessoren (beispielsweise als ein oder mehrere Programme laufen auf einem oder mehreren Mikroprozessoren) als Firmware oder virtuelle Kombinationen und dass die gestalteten Schaltkreise und/oder für die Software geschriebenen Codes und/oder Firmware würde gut mit den Fähigkeiten eines oder den Fähigkeiten in der Beleuchtungskunst zusammenpassen. In Ergänzung wird diese Kunst zu schätzen wissen, dass die Mechanismen der Subjekte, die hier beschrieben werden, hauptsächlich dazu dienen als ein Programm in verschiedenen Formen und dass ein illustrierter Inbegriff der Subjekte, die hier beschrieben werden, die einzelnen Arten von Signalen, die das Medium tragen, zur aktuellen Übertragung dienen. Beispiele von Signal übertragenden Medien eingeschlossen, aber nicht begrenzt, das Folgende: ein tragbarer Medientyp wie eine Floppydisk, eine Harddisk, eine Compactdisk (CD), eine Digitale Video Disk (DVD), ein digitales Band, ein Computer Memory etc; und ein Übertragungsmedium wie digitale und/oder analoge Kommunikationsmedien (beispielsweise einen Lichtwellenleiter, einen Wellenführer, eine verkabelte Kommunikationsverbindung, eine kabellose Kommunikationsverbindung etc).
Fachleute auf dem Gebiet werden anerkennen, dass es in der Branche üblich ist, Geräte und/oder Prozesse in der hier dargelegten Art und Weise zu beschreiben und anschließend praktische Techniken zu verwenden, um die derart beschriebenen Geräte und/oder Prozesse in Datenverarbeitungssysteme zu integrieren. Das ist wenigstens eine Menge der Geräte und/oder Prozesse, die beschrieben wurden, können integriert werden in das Datensystem über eine begründeten Betrag von Experimenten. Diese, die in der Wissenschaft befähigt sind, werden erkennen, dass ein typisches Datenprozesssystem gewöhnlich eine oder mehrere Systemeinheiten beinhaltet, ein Videodisplay-Gerät, ein Memory wie flüchtige und nichtflüchtige Memory, Prozessoren wie Mikroprozessoren und digitale Signalprozessoren, computerbasierte Einheiten, wie Operatorren, Treiber, graphische Nutzerkarten, und App-Programme, eine oder mehrere Interaktionsgeräte wie ein Touchpad oder Screen und/oder Kontrollsysteme einschließlich Rückkopplungsschleifen und Kontrollmotoren (beispielsweise Rückkopplung für Abtastpositionen und/oder Geschwindigkeit; Kontrollmotoren für Bewegung und/oder Ausrichtungskomponenten und/oder Mengen). Ein typisches Datenprozesssystem kann gewöhnliche kommerziell erhältliche Komponenten implementieren wie typische Datencomputerkommunikation und/oder Netzwerkcomputerkommunikationssysteme.
In Bezug auf die Verwendung von im Wesentlichen jedem Plural- und/oder Singularbegriff hierin, können Fachleute auf dem Gebiet je nach Kontext und/oder Anwendung passend Plural in Singular und/oder Singular in Plural übersetzen. Die verschiedenen Singular-/Plural-Permutationen können hierin ausdrücklich aus Gründen der Klarheit dargelegt.
Nur exemplarische Ausführungsformen der hierin diskutierten Systeme und Lösungen werden in der vorliegenden Offenbarung gezeigt und beschrieben. Es muss verstanden werden, dass die Systeme und Lösungen, die hier diskutiert wurden, in verschiedenen anderen Kombinationen und Umgebungen verwendet werden und Wechsel oder Modifikationen mit einer Reihe von Konzepten, die hier vorgestellt wurden, übernehmen können. Einige Variationen können in Kombinationen von Hardware, Firmware und/oder Software verkörpert sein. Einige Variationen können zumindest teilweise auf computerlesbaren Speichermedien wie Speicherchips, Festplatten, Flash-Speicher, optische Speichermedien oder als vollständige oder teilweise kompilierte Programme, die für die Übertragung an/den Download durch/Installation auf verschiedenen Hardware-Geräten und/oder Kombinationen/Sammlungen von Hardwaregeräten geeignet sind, ausgeführt sein. Solche Variationen sind nicht abhängig von der Abfahrt aus dem Geist und der Anordnung der Systeme und Lösungen, die hier diskutiert wurden und solchen Modifikationen wie sie ein in der Wissenschaft Befähigter beabsichtigt, eingeschlossen die Reihe der folgenden Forderungen.

Claims

System, das Folgendes umfasst: einem Prozessor, der in einer Computerressourcenumgebung mit mindestens zwei Ressourcen-Namensräumen bereitgestellt ist; und einem prozessorlesbaren Speicher, auf dem Anweisungen enthalten sind, die so konfiguriert sind, dass der Prozessor ein Verfahren zum Erzeugen eines vollständig qualifizierten Ressourcennamen für eine bestimmte Ressource auf der Grundlage eines kontextbasierten Namens dieser Ressource und einem bestimmten Nutzungskontext ausführt, wobei das Verfahren Folgendes umfasst: Empfangen, als Eingangsinformation, eines dem Ressourcennamen, dem kontextbasierten Namen und dem Nutzungskontext zugewiesenen Namensschemas; Vergleichen eines Eintrag im Namensschema und eines Eintrag im kontextbasierten Namen; Bestimmen, basierend auf einem Ergebnis dieses Vergleichs, ob das Schema einen Moniker enthält, der im kontextbasierten Namen fehlt; Bestimmen, als Reaktion auf eine Feststellung, dass das Schema einen Moniker enthält, der im kontextbasierten Name fehlt, ob der fehlende Moniker ein Attributraum-Moniker ist; Hinzufügen, als Reaktion auf die Feststellung, dass der fehlende Moniker ein Attributraum-Moniker ist, des Attributraum-Monikers zu einem vollständigen Namen, der den kontextbasierten Namen beinhaltet; als Reaktion auf die Feststellung, dass der fehlende Moniker kein Attributraum-Moniker ist, Bestimmen des Attributraums, der mit dem fehlenden Moniker verbunden ist; Durchsuchen des Nutzungskontexts nach Informationen, die eine Verbindung zwischen dem fehlenden Moniker, dem mit dem fehlenden Moniker verbundenen Attributraum und einem dem fehlenden Moniker zugewiesenen Wert darstellen; Anhängen des bei der Suche ermittelten Attributraums, des fehlenden Monikers und des dem fehlenden Moniker zugewiesenen Werts an den vollständigen Namen.
System nach Anspruch 1, wobei ein erster Eintrag in das Schema ein Attributraum-Moniker ist.
System nach Anspruch 1 oder 2, wobei der Kontext Informationen zu einem Ursprungsattribut beinhaltet; und wobei das Ursprungsattribut in dem zurückgegebenen vollständigen Namen beinhaltet ist.
System nach irgendeinem der vorherigen Ansprüche, weiterhin umfassend: als Reaktion auf die Feststellung, dass der fehlende Name ein Attributraum-Moniker ist, Verschieben von Daten, die den fehlenden Moniker repräsentieren, an die Spitze eines Attributraumstapels; und wobei die Bestimmung des dem fehlenden Moniker zugeordneten Attributraums die Auswahl eines Monikers an der Spitze des Attributraumstapels als den Attributraum, der dem fehlenden Moniker zugeordnet ist, beinhaltet.
System nach irgendeinem der vorherigen Ansprüche, wobei der genannte Vergleich eines Eintrags den Vergleich des ersten Eintrags im Namensschema mit einem ersten Eintrag im kontextbasierten Namen beinhaltet; das genannte Hinzufügen des Attributraum-Monikers den Vergleich eines nachfolgenden Eintrags im Namensschema mit einem nachfolgenden Eintrag im kontextbasierten Namen beinhaltet; und das genannte Anhängen des gesuchten Attributraums den Vergleich eines nachfolgenden Eintrags im Namensschema mit einem nachfolgenden Eintrag im kontextbasierten Namen beinhaltet.
System nach Anspruch 5, das System weiterhin umfassend: Bestimmen, ob alle Einträge im Schema bewertet wurden; und als Reaktion auf die Feststellung, dass alle Einträge im Schema bewertet wurden, Ausgeben des vollständigen Namen als vollständig qualifizierten Ressourcennamen, wobei der vollständig qualifizierte Ressourcenname über alle Ressourcennamenräume hinweg eindeutig ist.
System nach Anspruch 4, das System weiterhin umfassend: Bestimmen, ob der nachfolgende Eintrag im Namensschema das Ende einer Attributraumdefinition angibt; und als Reaktion auf die Feststellung, dass der nachfolgende Eintrag im Namensschema das Ende einer Attributraumdefinition angibt, Stellen des Monikers an die Spitze des Attributraumstapels.
System nach irgendeinem der vorhergehenden Ansprüche, wobei der jeweilige Nutzungskontext Metadaten beinhaltet, die einen bevorzugten Name-Resolver für den vollständigen Namen angeben.
System nach irgendeinem der vorhergehenden Ansprüche, wobei der kontextbasierte Name ein Name ist, der mit einer bestimmten Aufgabe verbunden ist, und wobei der Kontext Metadaten beinhaltet, die einen aktuellen Computer darstellen, auf dem eine Aufgabe mit dem Kontextnamen geplant ist.
System nach irgendeinem der vorhergehenden Ansprüche, wobei der kontextbasierte Name ein vom Menschen lesbarer Name ist, der in Kombination mit dem bestimmten Nutzungskontext die bestimmte Ressource eindeutig innerhalb der Computerressourcenumgebung identifiziert.
System nach irgendeinem der vorhergehenden Ansprüche, wobei der vollständig qualifizierte Ressourcenname ein vom Menschen lesbarer Name ist, der die bestimmte Ressource innerhalb der Computerressourcenumgebung eindeutig identifiziert.
System nach irgendeinem der vorhergehenden Ansprüche, wobei sowohl der vollständig qualifizierte Ressourcenname als auch der kontextbasierte Name von Menschen lesbare Namen sind.
System nach irgendeinem der vorhergehenden Ansprüche, wobei der vollständig qualifizierte Ressourcenname eine Vielzahl von ersten Monikern, die mit einem ersten Attributraum verbunden sind, und einen zweiten Moniker, der mit einem zweiten Attributraum verbunden ist, beinhaltet; und wobei ein Wert, der mit einem Namen der genannten Vielzahl von ersten Monikern verbunden ist, den zweiten Moniker beinhaltet.
System nach irgendeinem der vorhergehenden Ansprüche, wobei der bestimmte Nutzungskontext Metadaten beinhaltet, die einen mit der Ressource verbundenen Zeitstempel darstellen.