DE69616329T2

DE69616329T2 - Verfahren zur steuerung von anwendungsprogrammen in einem netzwerk

Info

Publication number: DE69616329T2
Application number: DE69616329T
Authority: DE
Inventors: G. Brooks; K. Dayton; L. Hopton; Damon Janis; Andy Lawrence; B. Oldroyd; Kelly Sonderegger
Original assignee: Novell Inc
Current assignee: Micro Focus Software Inc
Priority date: 1995-07-07
Filing date: 1996-07-03
Publication date: 2002-05-23
Anticipated expiration: 2016-07-04
Also published as: US5692129A; JPH10511201A; WO1997003399A1; CA2226360C; CA2226360A1; US5859978A; US5692129B1; EP0838055A1; DE69616329D1; EP0838055B1

Description

GEBIET DER ERFINDUNG

Die vorliegende Erfindung betrifft die Verwaltung von Anwendungsprogrammen in einem Computernetzwerk, und insbesondere ein Verfahren zur Verwaltung von Anwendungen in einem Multiserver-Netzwerk unter Verwendung von Anwendungsobjekten in einer hierarchischen Verzeichnisdienstdatenbank.

TECHNISCHER HINTERGRUND DER ERFINDUNG

Bei einem Computernetzwerk ist es nicht ungewöhnlich, wenn es mehrere Servermaschinen als auch zahlreiche Klientenmaschinen enthält. Die Server stellen typischerweise Dateizugriff, Druckerzugriff und andere Dienste Benutzern zur Verfügung, die sich an den Klientenmaschinen befinden. Einige grosse Netzwerke enthalten Dutzende von Servern und Hunderte von Klienten. Jede Person, die für die Administration des Netzwerks verantwortlich ist, ist als der "Netzwerkadministrator" oder "Administrator" bekannt. Personen, die das Netzwerk benutzen, sind als "Benutzer" bekannt. Administratoren sind ebenfalls Benutzer.
Viele verschiedene Anwendungsprogramme wie beispielsweise Wordprozessoren, Kalkulationstabellen, Datenbankverwaltungen, Programmentwicklungswerkzeuge und dergleichen (zusammen als "Anwendungen" bezeichnet) finden sich typischerweise auf einem oder mehreren Servern in dem Netzwerk. Allerdings werden Anwendungen häufig zu wenig genutzt. Manchmal weiss ein potentieller Benutzer nicht, ob eine bestimmte Anwendung hilfreich sein würde, da der Benutzer mit dieser Anwendung nicht vertraut ist. Manchmal könnten Anwendungen jenen verfügbar gemacht werden, die von ihrer Benutzung profitieren, jedoch wurden die erforderlichen Zeitzugriffsrechte und die Ausführungsumgebung nicht von dem Administrator zur Verfügung gestellt. Manchmal bemerkt ein mit einer Anwendung vertrauter Benutzer nicht, dass die Anwendung vor kurzem in dem Netzwerk vorgesehen wurde.
Selbst wenn ein Benutzer eine bestimmte Anwendung ausführen möchte, und glaubt, dass der ausführbare Code für diese Anwendung irgendwo auf dem Netzwerk vorhanden ist, muss der Benutzer immer noch diesen Code auffinden und auf diesen zugreifen, um die Anwendung zu nutzen. Unglücklicherweise sind die ausführbaren Codes für Anwendungen häufig unter zahlreichen Servern verstreut, was es manchmal sogar für Administratoren schwierig macht, bestimmte ausführbare Codes aufzufinden. Die Situation ist für Benutzer erheblich schlimmer, die nicht mit den technischen Aspekten der Organisation und Administration des Netzwerks vertraut sind. Da derartige Benutzer häufig nicht dazu fähig sind, die gewünschten ausführbaren Codes aufzufinden, und/oder geeignete Ausführungsumgebungen zu schaffen, werden sie in unnötiger Weise an der Benutzung hilfreicher Anwendungen gehindert.
Erfahrenere Benutzer halten häufig von Hand Datensätze der Orte bestimmter ausführbarer Anwendungen fest, jedoch bringt diese Vorgehensweise verschiedene Nachteile mit sich. Häufig weiss ein Benutzer am Anfang nicht, wo sich eine bestimmte ausführbare Anwendung befindet. Die Abtastung der Verzeichnisse zahlreicher Server zur Auffindung einer ausführbaren Anwendung stellt eine mögliche Vorgehensweise dar. Die Abtastung von Verzeichnissen ist jedoch potentiell äusserst zeitaufwendig, insbesondere falls es erforderlich wird, die Klientenmaschine des Benutzers an zahlreiche Server anzuschliessen, um auf ihre Verzeichnisse zuzugreifen. Es ist ebenfalls möglich, einen Netzwerkadministrator zu fragen, wo man ein bestimmtes Programm findet, jedoch kann die wiederholte Beantwortung derartiger Anfragen von zahlreichen Benutzern ein signifikantes Ausmass an Zeit von anderen Aufgabe wegnehmen, welche die Beachtung und Erfahrung des Administrators benötigen. Die Aufrechterhaltung von Datensätzen von Hand erfordert jedesmal dann eine Wartung, wenn der Ort eines ausführbaren Codes geändert wird, so dass Zeit geopfert wird, welche der Benutzer und/oder der Administrator anderen Aufgaben zuwenden könnte.
Zusätzlich zu einem ausführbaren Code sind typischerweise andere Ressourcen für eine Anwendung erforderlich, bevor sie erfolgreich ausgeführt werden kann. In einigen Fällen ist es erforderlich, Laufwerke zuzuordnen, Druckerports zu erfassen, oder ein Arbeitsverzeichnis für Dateien festzulegen, welche endgültige Daten oder Zwischendaten enthalten, die durch die Anwendung erzeugt werden. Der Zugriff auf Dateien oder Verzeichnisse kann erfordern, dass den Benutzern Rechte in Bezug auf Lesen, Schreiben oder in anderer Hinsicht verliehen wurden. In einigen Netzwerkumgebungen läuft eine bestimmte Anwendung effizienter oder wirksamer, wenn ihrer Ausführung eine Gruppe von Befehlen vorausgeht, die sich in einem Anfahrskript befinden, oder wenn auf ihre Ausführung eine Gruppe von Befehlen folgt, die sich in einem Herunterfahrskript befinden. Viele Anwendungen ermöglichen oder erfordern die Übergabe von Parametern an den ausführbaren Code der Anwendung in derselben Befehlszeile wie jener, welche diesen Code aufruft.
Zusätzlich zur Aufrechterhaltung des Orts des ausführbaren Codes finden es Benutzer und Administratoren, die von Hand Datensätze in Bezug auf Anwendungen aufrechterhalten, häufig hilfreich oder erforderlich, zusätzliche Information in Bezug auf die Ausführungsumgebung jeder Anwendung aufrechtzuerhalten, beispielsweise Laufwerkzuordnungen, Printerportanforderungen, Arbeitsverzeichnisnamen, Zugriffsrechte, Skripte, und Befehlszeilenparameter. In der Praxis ist diese zusätzliche Information zumindest soweit verstreut wie die ausführbaren Codes, und wird häufig in unterschiedlichen Formaten von unterschiedlichen. Personen gespeichert. Viele Benutzer haben nicht die Erfahrung, die Zeit, oder beides, um derartige Information von Hand zu verwalten. Nachdem eine Anwendung für eine gewisse Zeit auf dem Netzwerk gewesen ist, ist es nicht ungewöhnlich, dass sich nicht miteinander konsistente Versionen von Ausführungsumgebungsinformation mit unterschiedlichen Formaten auf unterschiedlichen Maschinen in dem gesamten Netzwerk finden lassen.
Daher wäre es ein Fortschritt auf diesem Gebiet, ein Computerimplementiertes Verfahren und eine Einrichtung zur konsistenten Verfolgung des Orts ausführbarer Codes von Anwendungsprogrammen in einem Netzwerk zur Verfügung zu stellen.
Es wäre ein weiterer Fortschritt, ein derartiges Verfahren und eine derartige Einrichtung zur Verfügung zu stellen, welche die administrativen Aufwendungen verringern, die bei Änderungen der Orte ausführbarer Codes von Anwendungsprogrammen auftreten, oder bei Änderungen anderer Information, die zur Ausführung einer Anwendung erforderlich ist.
Ein weiterer Fortschritt würde in der Bereitstellung eines derartigen Verfahrens und einer derartigen Einrichtung zur konsistenten Verfolgung und zur Verwendung von Zusatzinformation bestehen, die zur Ausführung eines Anwendungsprogramms verwendet wird, beispielsweise Laufwerkzuordnungen, Druckerportanforderungen, Arbeitsverzeichnisnamen, Skripte, und/oder Befehlszeilenparameter.
Ein derartiges Verfahren und eine derartige Einrichtung werden hier beschrieben.

KURZE ZUSAMMENFASSUNG DER ERFINDUNG

Die vorliegende Erfindung stellt ein Verfahren und ein Computerprogrammprodukt zum Betreiben eines Datenverarbeitungssystems zum Starten eines Anwendungsprogramms in einem Computernetzwerk mit Ressourcen zur Verfügung, die zentral von einem Verzeichnisdienst verwaltet werden, entsprechend den nachstehenden Patentansprüchen. Eine Zielrichtung der vorliegenden Erfindung stellt ein abgeändertes Datenbankschema zur Verfügung. Das Datenbankschema legt fest, welche Art von Ressourcen in der Datenbank repräsentiert werden können. Die Datenbank stellt Netzwerkadministratoren eine wirksame und effiziente Art und Weise dafür zur Verfügung, zu bestimmen, welche Ressourcen auf dem Netzwerk verfügbar sind, eine Fehlertoleranz zur Verfügung zu stellen, indem Ressourcen verfügbar gemacht werden, selbst wenn ein Server auf dem Netzwerk nicht verfügbar wird, und den Zugriff bestimmter Netzwerkbenutzer oder Gruppen von Benutzern auf bestimmte Netzwerkressourcen zu kontrollieren.
Die in der modifizierten Datenbank repräsentierten Ressourcen umfassen Anwendungsprogramme, beispielsweise Wordprozessoren und Kalkulationstabellen, die auf dem Netzwerk liegen. Die Abänderungen des Schemas, die durch die vorliegende Erfindung zur Verfügung gestellt werden, unterstützen die Erzeugung, Löschung, und Änderung von Anwendungsobjekten in der Datenbank. Bei einer Ausführungsform werden administrative Routinen zur Verwaltung von Anwendungsobjekten durch ein "Einschnapp-"Modul zur Verfügung gestellt, welches das vertraute NWAdmin tool erweitert, das momentan bei Netzwerken des Typs Novell NetWare® verwendet wird.
Jedes Anwendungsobjekt repräsentiert ein Anwendungsprogramm und dessen Ausführungsumgebung. Bei einer Ausführungsform enthält jedes Anwendungsobjekt den Ort zumindest eines ausführbaren Codes für die betreffende Anwendung, einen kurzen Namen, der textlich die Anwendung identifiziert, ein Symbol, das die Anwendung graphisch identifiziert, den Ort des Arbeitsverzeichnisses der Anwendung, die Antriebszuordnungen und Druckerporterfassungen, die von der Anwendung benötigt werden, und die Befehlszeilenparameter (falls überhaupt), die an die Anwendung übertragen werden sollen, wenn sie mit der Ausführung beginnt. Bei alternativen Ausführungsformen umfassen Anwendungsobjekte zusätzliche nützliche Information, beispielsweise eine kurze Textbeschreibung ("Werbetext"), welche potentiellen neuen Benutzern die Anwendung beschreibt, eine Liste anderer Benutzer, mit denen Kontakt aufgenommen werden kann, damit sie Fragen über die Anwendung beantworten, Lizensierungsinformation, und Skripte, die vor und/oder nach der Ausführung der Anwendung ablaufen sollen.
Das Sammeln derartiger Information in Bezug auf jede Anwendung in einem Anwendungsobjekt in der Datenbank unterstützt erheblich die Verhinderung der Erzeugung oder Verwendung nicht konsistenter oder obsoleter Information bezüglich der Anwendung. Darüber hinaus empfangen Anwendungsobjekte die vorteilhaften Eigenschaften der Datenbank, beispielsweise eine hierarchische Organisation, Zugriffskontrolle, Replizierung von Datenbankobjekten, um Fehlertoleranz zu erzielen, und Zugriff durch vertraute Schnittstellenwerkzeuge.
Die vorliegende Erfindung stellt auch in der Auswirkung einen Anwendungsstarter zur Verfügung. Bei einer Ausführungsform gestattet der Anwendungsstarter es einem Benutzer, die Anwendungsobjekte zu durchsuchen, welche die Anwendungen repräsentieren, die für diesen Benützer verfügbar sind, und die, momentan in den Objekten gespeicherte Information zu betrachten. Der Starter startet darüber hinaus bestimmte "Autostart-"Anwendungen, wenn ein Benutzer den Starter ablaufen lässt. Zusätzlich aktualisiert der Starter eine Liste verfügbarer Anwendungen, die dem Desktop des Benutzers zugeordnet ist, durch Abfrage der Datenbank. Die Aktualisierungsfähigkeit des Starters befreit Administratoren von dem Erfordernis, den Desktop jedes Benutzers von Hand zu aktualisieren, wenn eine neue Anwendung dem Netzwerk hinzugefügt wird, oder eine eingerichtete Anwendung bewegt wird.
Wenn eine Anwendung gestartet werden soll, verwendet der Starter die Information in dem Datenbankobjekt der Anwendung zum Einrichten von Ausführungsumgebungsressourcen, die von der Anwendung benötigt werden, um dann einen Prozess zu erzeugen, welcher die Anwendung ausführt, und schliesslich nach Beendigung der Anwendung aufzuräumen. Das Einrichten einer Ressource umfasst typischerweise die Zuordnung von Laufwerken und die Erfassung von Druckerports je nach Erfordernis das Einrichten kann auch das Ablaufenlassen eines Anfahrskripts umfassen. Nachdem die Anwendung beendet ist, räumt der Starter auf, durch Lösung der Zuordnung von Laufwerken, Freigabe erfasster Ports, und Entfernen von Servern je nach Erfordernis. Das Aufräumen umfasst auch das Ablaufenlassen eines Herunterfahrskripts, falls eines vorgesehen ist.
Daher stellt die vorliegende Erfindung ein Computerimplementiertes Verfahren zur konsistenten Verfolgung und Verwendung von Information über Anwendungsprogramme und ihre Ausführungsumgebungen in einem Netzwerk zur Verfügung. Konsistenz wird durch Sammeln der Information in einer zentralen Datenbank erreicht, auf welche durch bestimmte Administratorwerkzeuge und Benutzerschnittstellen zugegriffen wird. Datenbankaktualisierungen werden einfach mit den Werkzeugen des Administrators oder durch den Anwendungsstarter durchgeführt, wodurch der Aufwand verringert wird, der bei Änderungen des Orts ausführbarer Codes oder anderer Information auftritt, die zur Ausführung einer Anwendung benötigt werden.
Die Merkmale und Vorteile der vorliegenden Erfindung werden aus der folgenden Beschreibung und den beigefügten Patentansprüchen zusammen mit den beigefügten Zeichnungen noch deutlicher.
Das IBM Technical Disclosure Bulletin Vol. 37 No. 4B, April 1994, Seite 33-34 beschreibt ein Verfahren nach dem Stand der Technik zum Administrieren von Domain- Anwendungseinstellungen.
Der Administrator darf die Einstellungen einer Anwendung ändern, während er die Definition der Anwendung einstellt, und dann diese Einstellungen in der Domain-Steuerdatenbank (DCDB) speichern. Wenn dann das Programm gestartet wird, oder die Programmeinstellungen auf einer entfernten Workstation geöffnet werden, werden diese Domain-Anwendungseinstellungen zurückgeholt, und bei dieser Workstation eingesetzt.
Das Verfahren läuft folgendermassen ab: Eine neue Datenbankdatei DCDB.S wird in dem Verzeichnis \IBMLAN\DCDB\DATA erzeugt, welches sämtliche Einstellinformationen in Bezug auf jede Anwendung enthält, die nicht in der Datenbankdatei DCDB.A gespeichert ist. DCDB.A enthält Definitionen von Netzwerkanwendungen und einige Einstellinformationen, beispielsweise den Programmnamen und das Arbeitsverzeichnis, enthält jedoch nicht Information in Bezug auf sämtliche Einstellungen, die einem Programmobjekt zugeordnet sind. Wenn ein LAN- Administrator ein Anwendungsobjekt dem Ordner "Anwendungen verwalten" (Manage Applications) hinzufügt, wird die Information für die Einstellungen für dieses Anwendungsobjekt der Datei DCDB.S hinzugefügt.
Wenn der LAN-Administrator eine Abwärtspegel-Domainsteuerung administriert, so holt sich, während der Ordner "Anwendung verwalten" bevölkert wird, der Überlauf für das Verfahren wpPopulate die Einstellinformationen für jedes Anwendungsobjekt zurück, das in der Datei DCDB.A definiert ist, und schreibt diese Information in die Datei DCDB.S ein. Auf diese Weise können neue Benutzerschnittstellen die zusätzlichen Einstellinformationen von der Datei DCDB.S benutzen, und werden die alten Benutzerschnittstellen, beispielsweise die Schnittstelle für den vollen Bildschirm, nicht gestört, da sie von der neuen Datei DCDB.S nichts wissen.
Wenn ein Benutzer, der sich bei einer entfernten Workstation angemeldet hat, den Ordner Netzwerkanwendungen öffnet, holt sich das Überlaufverfahren wpPopulate die Einstellinformationen für jedes Programmobjekt aus der Datei DCDB.S. und aktualisiert die Einstellseiten auf diesem Programmobjekt unter der Verwendung der Funktion WinSetObjectData. Auf diese Weise erhalten Serverbenutzer automatisch die korrekten Einstellungen für die Programmobjekte in dem Ordner Netzwerkanwendungen. Sie können daher Anwendungen aufrufen, die spezielle Einstellungen erfordern, ohne von Hand die Programmeinstellungen zu ändern.

KURZBESCHREIBUNG DER ZEICHNUNGEN

Zur Erläuterung der Art und Weise, auf welche die Vorteile und Merkmale der Erfindung erhalten werden, erfolgt nunmehr eine detailliertere Beschreibung der voranstehend summarisch dargestellten Erfindung unter Bezugnahme auf die beigefügten Zeichnungen. Unter dem Hinweis, dass diese Zeichnungen nur ausgewählte Ausführungsformen der Erfindung darstellen, und daher deren Umfang nicht einschränken sollen, wird die Erfindung mit zusätzlichen Einzelheiten und Details unter Verwendung der beigefügten Zeichnungen beschrieben und erläutert. Es zeigt:
Fig. 1 eine Darstellung eines Computernetzwerks;
Fig. 2 eine Darstellung von Bauteilen des Computernetzwerks von Fig. 1, zusammen mit Administrator-Werkzeugen und Benutzer-Werkzeugen, die bei dem Computernetzwerk verwendet werden;
Fig. 3 ein Flussdiagramm zur Erläuterung einer durch Ereignisse ausgelösten Ausführungsform von Anwendungsverwaltungsroutinen gemäss der vorliegenden Erfindung zur Ergänzung der Administrator-Werkzeuge und des Netzwerks, die in Fig. 2 gezeigt sind;
Fig. 4 ein Flussdiagramm zur Erläuterung einer alternativen, durch Ereignisse ausgelösten Ausführungsform der Anwendungsverwaltungsroutinen gemäss der vorliegenden Erfindung;
Fig. 5 ein Flussdiagramm zur Erläuterung einer Anwendungsverwaltungsroutine zur Abänderung eines Netzwerkdatenbankschemas gemäss der vorliegenden Erfindung;
Fig. 6 ein Flussdiagramm zur Erläuterung von Attributdefinitions- und Additionsschritten der in Fig. 6 gezeigten Routine;
Fig. 7 ein Flussdiagramm zur Erläuterung von Klassendefinitions- und Additionsschritten der in Fig. 5 gezeigten Routine;
Fig. 8 ein Flussdiagramm zur Erläuterung eines Anwendungsstarters gemäss der vorliegenden Erfindung;
Fig. 9 ein Flussdiagramm zur Erläuterung eines in Fig. 8 dargestellten Anwendungsstartschritts;
Fig. 10 ein Flussdiagramm zur Erläuterung eines in Fig. 9 dargestellten Ressourceneinrichtungsschrittes; und
Fig. 11 ein Flussdiagramm zur Erläuterung von in Fig. 10 gezeigten Schritten zur Laufwerkszuordnung, Porterfassung und für den Serveranschluss.

DETAILLIERTE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORMEN

Die vorliegende Erfindung betrifft ein Verfahren zur Verwaltung von ein in einem Computernetzwerk, wobei das Verfahren Software- und Datenkomponenten enthält. Zur Beschreibung der vorliegenden Erfindung und ihres Kontextes werden die Begriffe "Programm", "Modul", "Routine", "Subroutine", "Funktion" und "Prozedur" austauschbar verwendet, da die technischen Unterschiede zwischen diesen Softwarekomponenten nicht den Umfang der vorliegenden Erfindung ändern. Auch die Begriffe "Objektcode", "ausführbarer Code" und "ausführbar" werden austauschbar eingesetzt. Der hier verwendete Begriff "Ausführungsform" umfasst spezielle Verfahren sowie spezielle Programmspeichergeräte oder Netzwerkanwendungsobjekte, die durch die vorliegende Erfindung zur Verfügung gestellt werden.
Nunmehr wird auf die Figuren Bezug genommen, in denen gleiche Teile mit gleichen Bezugszeichen bezeichnet sind. Eins der zahlreichen Netzwerke, die zum Einsatz bei der vorliegenden Erfindung geeignet sind, ist allgemein mit 10 in Fig. 1 bezeichnet. Bei einer Ausführungsform weist das Netzwerk 10 Novell NetWare® Software, Version 4.x auf (NetWare ist eine eingetragene Marke von Novell, Inc.). Das dargestellte Netzwerk 10 umfasst verschiedene verbundene lokale Netzwerke 12. Jedes lokale Netzwerk 12 weist einen Dateiserver 14 und eine oder mehrere Benutzerstationen 16 auf. Ein Drucker 18 und eine Gruppe von Laufwerken 20 sind ebenfalls an das Netzwerk 10 angeschlossen. Obwohl ein bestimmtes Netzwerk 10 dargestellt ist, ist die vorliegende Erfindung auch bei verschiedenen anderen Netzwerken einsetzbar, die Fachleuten auf diesem Gebiet bekannt sind.
Wie aus den Fig. 1 und 2 hervorgeht, werden die Administration und die Nutzung des Netzwerks 10 durch Netzwerksoftware- und Hardwareelemente unterstützt, durch Administrator-Werkzeuge, und durch Benutzer-Werkzeuge. Fig. 2 erläutert die Beziehung zwischen diesen Komponenten. Das Netzwerk 10 enthält verschiedene Ressourcen 22, beispielsweise die Drucker 18, die Laufwerksgruppe 20 und andere Speichergeräte, sowie Anwendungen 23 und Daten, die in einem oder mehreren der Dateiserver 14 und Benutzerstationen 16 gespeichert sind.
Die Administration der Netzwerkressourcen 22 erfolgt durch bestimmte Verzeichnisdienste 24. Die Art und Weise der Verzeichnisdienste 24 ist bei unterschiedlichen Netzwerken verschieden, jedoch führen im allgemeinen die Verzeichnisdienste 24 die Administration sowohl der Orte der Ressourcen 22 als auch der Rechte von Netzwerkbenutzern in Bezug auf die Nutzung der Ressourcen 22 durch.
Bei einer momentan bevorzugten Ausführungsform umfassen die Verzeichnisdienste 24 Dienste, die von Software 26 des Typs NetWare Directory Services ("NDS") zur Verfügung gestellt werden, die im Handel von Novell, Inc. in Orem, Utah erhältlich ist (NetWare Directory Services ist eine Marke von Novell, Inc.). Die Komponente der Verzeichnisdienste 24 enthält ein Schema 28. Vor der vorliegenden Erfindung war das Schema 28 ein Standardschema 30, welches keine Anwendungsobjekte unterstützte. Das Schema 28 gemäss der vorliegenden Erfindung ist ein erweitertes Schema 32, das Anwendungsobjekte unterstützt.
Die Schemata 28, 30 und 32 umfassen jeweils eine Gruppe von Definitionen "Attributsyntax", eine Gruppe von Definitionen "Attribut", und eine Gruppe von Definitionen "Objektklasse" (auch bekannt als "Klasse"). Die NDS-Software 26 und das Standard-NDS-Schema 30 sind in den Kapiteln 6 bis 8 von NetWare 4 for Professionals von Bierer et al ("Bierer") beschrieben, das durch Bezugnahme in die vorliegende Anmeldung eingeschlossen wird. Bestimmte Ideen, die in Bierer erläutert werden, werden hier wiederholt. Die Begriffe "Attribut" und "Eigenschaft" werden in Bierer und in der vorliegenden Anmeldung austauschbar verwendet, ebenso wie die Begriffe "Attributsyntax" und "Eigenschaftssyntax". Unterschiede zwischen dem Standardschema 30 und dem erweiterten Schema 32 gemäss der vorliegenden Erfindung werden nachstehend genauer erläutert, nach einer allgemeinen Diskussion des allgemeinen Schemas 28.
Jede Attributsyntax in dem Schema 28 wird durch einen Attributsyntaxnamen festgelegt, und durch die Art und/oder den Bereich von Werten, die Attributen des vorgegebenen Attributsyntaxtyps zugeordnet werden können. Attributsyntaxen entsprechen daher ungefähr Datentypen wie beispielsweise Ganzzahlig, Gleitkomma, Zeichenkette, oder Boole'sche Variable in herkömmlichen Programmiersprachen.
Jedem Attribut in dem Schema 28 ist eine bestimmte Information zugeordnet. Jedes Attribut weist einen Attributnamen und einen Attributsyntaxtyp auf. Der Attributname identifiziert das Attribut, wogegen die Attributsyntax die Werte begrenzt, die von dem Attribut angenommen werden. So umfasst beispielsweise das Standardschema 30 ein Attribut des Syntaxtyps Ganzzahlig, welches den Namen "unterstützte Verbindungen" aufweist, welcher die Anzahl an gleichzeitigen Verbindungen festlegt, die ein Dateiserver zulässt.
Jedem Attribut können auch eine oder mehrere der folgenden Flags zugeordnet werden: nicht-entfernbar, verborgen, öffentliches Lesen, Nur-Lesen, einzelwertig, Grösse, und Zeichenkette. Die allgemeine Bedeutung dieser Flags ist Fachleuten auf diesem Gebiet bekannt. Wenn die Flag "Grösse" für ein bestimmtes Attribut eingestellt ist, werden eine obere und eine untere Grenze (möglicherweise unter Einschluss von "unbegrenzt") für Werte festgelegt, die momentan von diesem Attribut gehalten werden.
Jeder Objektklasse in dem Schema 28 ist auch bestimmte Information zugeordnet. Jede Klasse weist einen Namen auf, der diese Klasse identifiziert, eine Gruppe übergeordneter Klassen, welche die anderen Klassen identifiziert, von denen diese Klasse Attribute erbt, und eine Gruppe von Einschliessungsklassen, welche die Klassen identifiziert, die Erscheinungsformen dieser Klassen einschliessen dürfen. Obwohl die. Themen des Erbens, des Einschliessens, und der Erscheinungsform von Klassen Fachleuten auf diesem Gebiet bekannt sind, ist ihr Einsatz in Verbindung mit Anwendungsobjektklassen gemäss der vorliegenden Erfindung neu.
Jede Objektklasse weist auch eine Container-Flag und eine effektive Flag auf. Die Container-Flag gibt an, ob die Klasse eine Containerklasse ist, also ob sie Erscheinungsformen anderer Klassen enthalten kann. Die effektive Flag gibt an, ob Erscheinungsformen der Klasse definiert werden können. Nicht-effektive Klassen werden nur zur Definition von Attributen verwendet, die von anderen Klassen geerbt werden, wogegen effektive Klassen zur Definition von Attributen, die geerbt werden können, verwendet werden, zum Definieren von Erscheinungsformen, oder zur Definition von beiden.
Weiterhin gruppiert jede Objektklasse bestimmte Attribute. Die Namensattribute einer Klasse sind jene Attribute, die zum Benennen von Erscheinungsformen der Klasse verwendet werden können. Die vorgeschriebenen Attribute einer Klasse sind jene Attribute, die bei jeder gültigen Erscheinungsform der Klasse vorhanden sein müssen, und/oder vorgeschriebene Attribute von Klassen werden, die von der Klasse erben. Die optionalen Attribute einer Klasse sind jene Attribute, die bei jeder gültigen Erscheinungsform der Klasse vorhanden sein können, dies jedoch nicht müssen. Optionale Attribute einer Mutterklasse werden zu optionalen Attributen einer Tochterklasse, welche von der Mutterklasse erbt, es sei denn, dass die Attribute in einer anderen Mutterklasse vorgeschrieben sind, von welcher die Tochter erbt, wobei sie in diesem Fall auch bei der Tochter vorgeschrieben sind.
Ein Objekt ist eine Erscheinungsform einer Objektklasse. Unterschiedliche Objekte derselben Klasse weisen dieselben vorgeschriebenen Attribute auf, können jedoch unterschiedliche, momentane Werte bei ihren entsprechenden vorgeschriebenen Attributen aufweisen. Unterschiedliche Objekte derselben Klasse können unterschiedliche optionale Attribute aufweisen, und/oder unterschiedliche momentane Werte in ihren entsprechenden optionalen Attributen.
Die Verzeichnisdienste 24 weisen weiterhin eine Schnittstellenbibliothek 34 auf, welche Zugriff auf das Schema 28 und auf eine Datenbank 38 zur Verfügung stellt. Das Schema 28 ist ein API-erweiterbares Schema in der Hinsicht, dass die Attribute und Objektklassen, die sich in dem Schema finden, durch eine Anwendungsprogrammierschnittstelle (Application Programmers' Interface: "API") geändert werden können, ohne direkten Zugriff auf den Quellencode, der das Schema 28 implementiert. Bei einigen Ausführungsformen enthält die Schnittstellenbibliothek 34 Tabellen oder Befehle, die in einer Datei gespeichert sind, die von dem Schema 28 während seiner Initialisierung und bei der Erzeugung von Objekten gelesen wird, wodurch die verfügbaren Attribute und Klassen definiert werden.
Zusätzlich oder alternativ weist die Schnittstellenbibliothek .Gruppen von Routinen auf, die für andere Codes verfügbar sind, um auf das Schema 28 zuzugreifen und dieses zu modifizieren. Bei einer Ausführungsform enthält die Schnittstellenbibliothek 34 eine API, die eine Schnittstelle zu einer NWDSxxx()-Bibliothek 36 definiert, die im Handel von Novell, Inc. in Orem, Utah erhältlich ist. Die NWDSxxx()-Bibliothek 36 wird deswegen so bezeichnet, da die Namen von Funktionen und Datentypen, die in der Bibliothek 36 definiert sind, typischerweise mit "NWDS" beginnen, einem Acronym für "NetWare Directory Services" (NetWare- Verzeichnisdienste). Die Verwendung bestimmter Elemente der NWDSxxx()-Bibliothek 36 im Zusammenhang mit der vorliegenden Erfindung wird nachstehend erläutert.
Die Datenbank 38 enthält Objekte 49 und 51, die entsprechend dem Schema 28 und den Gegebenheiten des Netzwerks 10 definiert werden. Die Objekte 49 und 51 repräsentieren Ressourcen 22 des Netzwerks 10. Die Datenbank 38 ist eine "hierarchische" Datenbank 38, da die Objekte 49 und 51 in der Datenbank 38 nach Art einer hierarchischen Baumstruktur miteinander verbunden sind. Objekte in dem Baum, die andere Objekte enthalten können, werden als "Container-Objekte" bezeichnet, und müssen Erscheinungsformen einer Container-Objektklasse sein.
Die Datenbank 38 ist auch eine Datenbank 38 mit "synchronisierter Partition". Die Datenbank 38 ist typischerweise in zwei oder mehr, einander nicht überlappende Partitionen unterteilt. Um die Reaktionszeit auf Abfragen der Datenbank 38 zu verbessern, und Fehlertoleranz zur Verfügung zu stellen, wird eine Kopie jeder Partition physikalisch in einem oder mehreren Dateiservern 14 in dem Netzwerk 10 gespeichert. Die Kopien einer bestimmten Partition werden regelmässig durch die Verzeichnisdienste 24 aktualisiert, durch einen automatischen Synchronisationsprozess, wodurch die Unterschiede zwischen Kopien verringert werden, die durch Aktivität im Netzwerk 10 hervorgerufen werden. Bei einer Ausführungsform enthält die Datenbank 38 eine Datenbank des Typs Novell NetWare Directory Services ("NDS-Datenbank") 40.
Die Administration und Verwendung der Ressourcen 22 wird durch die Verzeichnisdienste 24 unterstützt, durch Administrator-Werkzeuge 42, und durch Benutzer-Werkzeuge 44. Typische Administrator-Werkzeuge 42 umfassen Partitionsverwaltungsroutinen 46 zum Verwalten der Partitionen der Datenbank 38.
Die vorliegende Erfindung ergänzt die bislang verfügbaren Administrator-Werkzeuge 42 durch Bereitstellung von Anwendungsverwaltungsroutinen 48 zur Erzeugung, Löschung, und Modifizierung von Anwendungsobjekten 49 und/oder Desktop-Attributen in Bezug auf Benutzer-, Gruppen- und Container-Objekte 51 in der Datenbank 38. Das Hinzufügen von Anwendungsobjekten 49 zu der Datenbank 38 und andere Merkmale der vorliegenden Erfindung führen dazu, dass Anwendungsprogramme 23 für Netzwerk-Administratoren und Benutzer auf eine vorher nicht bekannte, gleichmässige, bequeme und wirksame Art und Weise verfügbar werden.
Die vorliegende Erfindung stellt Benutzern ebenfalls einen Anwendungsstarter 50 zur Verfügung, zum Initiieren der Ausführung von Anwendungen 23 über ihre entsprechenden Anwendungsobjekte 49. Zusätzlich stellt die vorliegende Erfindung Desktopattribute für Benutzer-, Gruppen- und Containerobjekte 51 zur Verfügung, die vorher bekannte Desktop-Umgebungen 52 abändern, um den Einsatz der Anwendungsobjekte 49 zu erleichtern. Benutzer-, Gruppen-, Container- und/oder andere Objekte 51, die ein Desktop- Attribut aufweisen, werden hier als "Desktop-Objekte" bezeichnet.
Wie aus den Fig. 1, 2 und 3 hervorgeht, weisen die Anwendungsverwaltungsroutinen 48, ebenso wie das Schema 28 und die Datenbank 38, eine greifbare Ausführungsform auf, die in einem oder mehreren Programmspeichergeräten gespeichert ist. Geeignete Speichergeräte umfassen Floppy-Disks, Festplatten, Bänder, CD-ROMs, und andere, von Computern nutzbare Medien. Jedes Programmspeichergerät kann von einem oder mehreren der Dateiserver 14 und Benutzerstationen 16 gelesen werden. Jedes Programmspeichergerät verwirklicht greifbar ein Programm, Funktionen, oder Befehle, die von den Maschinen 14 und/oder 16 ausführbar sind, um die hier beschriebenen Anwendungsverwaltungsschritte der vorliegenden Erfindung auszuführen.
Bei einer Ausführungsform befinden sich die Anwendungsverwaltungsroutinen 48 in einem "Einschnapp-"Modul 54, das in einer DLL-Datei auf einer Platte in der Microsoft® WindowsTM-Umgebung gespeichert ist ("Microsoft" ist eine registrierte Marke, und "Windows" ist eine Marke der Microsoft Corporation). Fig. 3 erläutert Schritte, die von dem Einschnapp-Modul 54 unternommen werden, um die Verzeichnisdienste 24 abzuändern, damit die Anwendungsverwaltungsroutinen 48 unterstützt werden. Einige dieser Schritte ändern das Verzeichnisdienstschema 28 ab. Abänderungen beim Schema 28 umfassen die Hinzufügung zumindest einer Klasse, welche Anwendungsobjekte 49 definiert, und die Hinzufügung von Attributen, welche die Sichtbarkeit und leichte Benutzbarkeit dieser Anwendungsobjekte 49 verbessern. Andere Schritte, die von dem Einschnapp-Modul 54 vorgenommen werden, geben Netzwerk- Administratoren eine Kontrolle über Anwendungsobjekte 49, durch Hinzufügung von Routinen, die es Administratoren gestatten, die Anwendungsobjekte 49 zu erzeugen, abzuändern und zu löschen, die für einen bestimmten Benutzer, eine bestimmte Gruppe, oder eine bestimmte Container-Klasse verfügbar sind.
Eine Ausführungsform macht die neuen Routinen 48 über die bekannte NWAdmin-Werkzeugschnittstelle verfügbar, jedoch werden Fachleute auf diesem Gebiet merken, dass die Routinen 48 auch im Zusammenhang mit anderen Programmen als NWAdmin zur Verfügung gestellt werden können. NWAdmin ist ein im Handel erhältliches, erweiterbares Werkzeug, das von Netzwerk-Administratoren dazu verwendet wird, Objekte in der Datenbank 38 zu verwalten. Das Modul 54 erweitert NWAdmin so, dass Anwendungsobjekte 49 unterstützt werden.
Wie in den Fig. 2 und 3 gezeigt ist, ist der Anfangsschritt, der von dem Einschnapp-Modul 54 unternommen wird, ein Registrierungsschritt 60, der das Einschnapp-Modul 54 bei NWAdmin registriert. Bei alternativen Ausführungsformen werden die Routinen 48 bei anderen Administrationsprogrammen registriert, damit sie für den Einsatz durch einen Administrator verfügbar sind. Während des Registrierungsschrittes 60 werden Menueposten und Prozeduren entsprechend Operationen bei Anwendungsobjekten 49 und Desktop-Objekten 51 bei NWAdmin registriert, durch geeignete Aufrufe zur Standardfunktion NWARegisterObject-Proc().
Bei einer Ausführungsform des Einschnapp-Moduls 54 ist die erste registrierte Anwendungsobjektprozedur SnapinApplicationProc(), eine Funktion, die Nachrichten von NWAdmin empfängt, und sie verarbeitet. In Reaktion auf die Nachricht NWA_MSG_INITSNAPIN initialisiert SnapinApplicationProc() NWAPageStruct-
Schnittstellenseitenstrukturen mit dem Titel "Identifizierungen", "Kontakte", "Umgebung", "Optionen", "Skripte", "Lizensieren", und "Ansicht von Zuordnungen", und registriert entsprechende Menuepostenschnittstellenseiten bei NWAdmin. Geeignete Titel für diese Strukturen, und geeignete Gruppierungen der Attribute und Klassen gemäss der vorliegenden Erfindung unter jedem Titel, werden von Fachleuten auf diesem Gebiet leicht bestimmt. SnapinApplicationProc() verwaltet auch Gerätekontextinformation in Windows-Umgebungen und entsprechende Information in anderen Umgebungen. Zusätzlich ruft SnapinApplicationProc() NWAAddClassData() auf, um bei NWAdmin die Bitmap- und andere Schnittstelleninformation zu registrieren, welche neuen Anwendungsobjektklassen zugeordnet sind, die durch das Einschnapp-Modul 54 hinzugefügt wurden.
In Reaktion auf die NWA_MSG_CREATEOBJECT-Nachricht registriert SnapinApplicationProc() einen Dialogkasten, der es Administratoren gestattet, ausführbare Dateien auf dem Netzwerk 10 zu durchsuchen, sowie vorhandene Anwendungsobjekte 49, oder beide, und je nach Wahl die erforderlichen Routinen 48 aufzurufen, um ein neues Anwendungsobjekt 49 zu erzeugen. Das Durchsuchen kann mit einem Standard-Suchwerkzeug durchgeführt werden.
In Reaktion auf die Nachricht NWA_MSG_GETVALIDOPERATIONS registriert SnapinApplicationProc() die folgende Gruppe von Bit-Flags: NWA_OP_DETAILS, NWA_OP_RENAME, NWA_OP_DELETE, NWA_OP_DSTYPE, NWA_OP_CREATE. Fachleuten auf diesem Gebiet wird auffallen, dass unterschiedliche Operationen bei anderen Ausführungsformen des Einschnapp-Moduls 54 gemäss der vorliegenden Erfindung gültig sein können.
In Reaktion auf die Nachricht NWA_MSG_GETPAGECOUNT ruft zuerst SnapinApplicationProc() eine Einschnappfunktion DSGetAliasedObjectName() auf, welche den Namen des Objekts 49 oder 51 zurückschickt, das durch einen Aliasnamen bezeichnet wird, wenn ein Aliasname eingegeben wird, und den eingegebenen Namen zurückschickt, wenn dieser Name kein Aliasname ist. SnapinApplicationProc() erzeugt dann eine lokale Kopie der Information in dem Objekt 49, um einen Datensatz der Abänderungen bei dem Objekt 49 durch den Administrator aufrechtzuerhalten, bis zu einem derartigen Zeitpunkt, falls überhaupt, wenn der Administrator das Einschnapp-Modul 54 anweist, die Modifikationen in die Datenbank 38 einzugeben. Schliesslich schickt SnapinApplicationProc() die Anzahl an Schnittstellenseiten an NWAdmin zurück.
In Reaktion auf aufeinanderfolgende Nachrichten NWA_MSG_REGISTERPAGE (eine für jede Schnittstellenseite) registriert SnapinApplicationProc() die nächste Schnittstellenseite bei NWAdmin. Fachleuten auf diesem Gebiet wird auffallen, dass alternative Ausführungsformen der vorliegenden Erfindung die Reihenfolge abändern, in welcher die Seiten registriert werden, und ebenso die spezielle Art und Weise, auf welche Information und Operationen in Bezug auf Objekte 49 und 51 zwischen den Schnittstellenseiten aufgeteilt werden. Benutzerschnittstellenmechanismen, die anders als Schnittstellenseiten sind, werden bei alternativen Ausführungsformen eingesetzt.
In Reaktion auf die Nachricht NWA_MSG_MODIFY ruft SnapinApplicationProc() eine Einschnappfunktion ModifyApplicationData() auf, um das angegebene Anwendungsobjekt 49 zu modifizieren. Hier und anderswo, durch das gesamte Einschnapp-Modul 54, werden dem Administrator geeignete Fehlernachrichten zur Verfügung gestellt, wenn eine angeforderte Operation fehlschlägt.
In Reaktion auf die Nachricht NWA_MSG_RENAME schickt SnapinApplicationProc() einfach NWA_RET_DODEFAULT zurück. In Reaktion auf die Nachricht NWA_MSG_QUERYDELETE entfernt SnapinApplicationProc() jedes relevante Lizenzzertifikat, und löscht das angegebene Anwendungsobjekt 49. Schliesslich gibt in Reaktion auf die Nachricht NWA_MSG_CLOSESNAPIN SnapinApplicationProc() den Speicher frei, den es zugeordnet hat, schliesst Dateien (falls überhaupt), welche es geöffnet hat, und räumt anderenfalls auf. Einige Ausführungsformen von SnapinApplicationProc() rufen auch NWARemoveClassData() auf, um die Bitmaps zu entfernen, die vorher den Klassentabellen von NWAdmin hinzugefügt wurden. Einige Ausführungsformen entfernen die neuen Anwendungsobjektklassen aus dem Schema 28; alternative Ausführungsformen lassen die Modifikationen des Schemas an ihrem Ort, nach Beendigung des Einschnapp- Moduls 54.
Bei dieser Ausführungsform des Registrierungsschrittes 60 des Einschnapp-Moduls 54 ist die nächste registrierte Anwendungsobjektprozedur SnapinDesktopProc(), welche Nachrichten von NWAdmin in Bezug auf Desktopattribute für Desktop-Objekte 51 empfängt und verarbeitet, auf analoge Weise zu jener, auf welche SnapinApplicationProc() Nachrichten in Bezug auf Anwendungsobjekte 49 empfängt und verarbeitet. In Reaktionen auf Nachricht NWA_MSG_INITSNAPIN, NWA_MSG_GETPAGECOUNT, und NWA_MSG_REGISTERPAGE, erzeugt SnapinDesktopProc() eine Schnittstellenseite mit dem Titel "Desktop-Objekte", und registriert sie bei NWAdmin. Entsprechend sorgt SnapinDesktopProc() dafür, Aliasnamen zu identifzieren, und Änderungen bei Desktop-Attributen von Desktop-Objekten 51 in der Datenbank 38 nur nach Bestätigung durch den Administrator zuzulassen. Andere Schritte von SnapinDesktopProc(), beispielsweise Abänderungs- oder Schliessschritte, werden leicht von Fachleuten auf diesem Gebiet entsprechend der hier vermittelten Lehre bestimmt.
Wie wiederum aus Fig. 3 hervorgeht, folgt auf den Registrierungsschritt 60 ein Abfrageschritt 62 und möglicherweise ein Abänderungsschritt 64. Der Abfrageschritt 62 bestimmt, ob zusätzliche Abänderungen bei dem Schema 38 vorgenommen werden müssen, um die vorliegende Erfindung zu verwirklichen. Geeignete Abänderungen umfassen die Definition neuer Attribute und/oder neuer Objektklassen. Bei einigen Ausführungsformen fragt der Abfrageschritt 62 den Benutzer ab, um Erlaubnis zu erhalten, die angegebenen Abänderungen bei dem Schema 28 durchzuführen; bei anderen wird die Erlaubnis vorausgesetzt. Wenn eine zusätzliche Abänderung festgestellt und erlaubt wird, wird sie während des Abänderungsschrittes 64 auf eine Art und Weise durchgeführt, die nachstehend unter Bezugnahme auf die Fig. 5 bis 7 erläutert wird. Der Abfrageschritt 62 wird dann solange wiederholt, bis keine weiteren Abänderungen festgestellt werden.
Nachdem die Abänderungen bei dem Schema 28 beendet sind, führt das Einschnapp-Modul 54 einen Contexterfassungsschritt 66 durch. Bei einer Ausführungsform wird der Context durch die folgende Folge von Aufrufen erfasst:
Context = CreateContext();
NWDSSetContext(Context, DCK_NAME_CONTEXT, DS_ROOT_NAME);
NWDSWhoAml(Context,UserName);
Die Variable Context ist vom Typ NWDSContextHandle, und ist ein Puffer, der von Aufrufen des Typs NWDSxxx() verwendet wird. Die Variable Benutzernamen ist ein Feld von Zeichen, das den Namen des Benutzers enthält, der momentan NWAdmin ablaufen lässt. CreateContext() ist eine Funktion des Einschnapp-Moduls 54, welche NWDSGetContext() aufruft, um eine lokale Kopie des Contexts zu erzeugen, NWDSGetContext() aufruft, um diese lokale Kopie zu initialisieren, und dann die folgenden Bit-Flags in dem Context einstellt, unter Verwendung von NWDSSetContext(): DCV_TYPELESS_NAMES, DCV_XLATE_STRINGS, DCV_DEREF_ALIASES, DCV_DEREF_BASE_CLASS.
Bei der Abänderung der Datenbank 38 wird dafür gesorgt, dass Benutzern von Anwendungsobjekten 49 und Desktop-Objekten 51 Datenbankrechte verliehen werden, welche sowohl die momentanen Rechte des Objekts als auch die Rechte umfassen, die explizit oder implizit von dem Netzwerk-Administrator während des Einsatzes des Einschnapp-Moduls 54 festgelegt werden.
Nach dem Contexterfassungsschritt 66 geht das Einschnapp- Modul 54 in eine Ereignishandhabungsschleife über, die einen Nachrichtempfangsschritt 68 und einen Nachrichtenhandhabungsschritt 70 umfasst. Die Ereignishandhabungsschleife geht so vor, wie dies voranstehend im Zusammenhang mit den registrierten Objektprozeduren SnapinApplicationProc() und SnapinDesktopProc() geschildert wurde, welche die Nachrichten von NWAdmin empfangen, und diese entsprechend behandeln. Die Ereignishandhabungsschleife unterstützt auch herkömmliche Schritte, beispielsweise die Beendigung des Einschnapp-Moduls 54.
Obwohl in Fig. 3 ein durch Ereignisse getriebenes Administrator-Werkzeug 54 gezeigt ist, werden Fachleute auf diesem Gebiet erkennen, dass andere Programmierschemata bei alternativen Ausführungsformen der vorliegenden Erfindung verwendet werden. Fig. 4 erläutert eine alternative Ausführungsform der Routinen 48 von Fig. 2 in Form eines durch Befehle getriebenen Administrator-Werkzeugs 72. Das Ereignis-getriebene Werkzeug 54 und das Befehls-getriebene Werkzeug 72 enthalten entsprechende Komponenten, die gleiche Ergebnisse erzielen. Zusätzliche Schemata werden bei anderen Ausführungsformen der vorliegenden Erfindung eingesetzt.
Wie aus den Fig. 2, 3 und 4 hervorgeht, reagiert das Befehls-getriebene Werkzeug 72 auf einen Befehl "Initialisieren" mit einem Initialisierungsschritt 74, welcher Bitmaps, Schnittstellenseiten, Menues und andere Benutzerschnittstellenelemente initialisiert, auf eine Art und Weise analog zum Registrierungsschritt 60 des Ereignisgetriebenen Werkzeugs 54. Bei der in Fig. 4 dargestellten Ausführungsform modifiziert der Initialisierungsschritt 74 auch das Schema 28, um neue Attribute und Klassen hinzufügen, und zwar im wesentlichen ebenso, wie dies im Zusammenhang mit den Fig. 5 bis 7 beschrieben wurde. Wenn andere Software in der Umgebung des Befehls-getriebenen Werkzeugs 72 Seitenzählwerte, Seitenregistrierung, eine Identifizierung gültiger Operationen bei den Objekten 49 und 51, oder entsprechende Benutzerschnittstelleninformation benötigt, wird auch diese Information von dem Werkzeug 72 während des Initialisierungsschritts 74 zur Verfügung gestellt.
Das Befehls-getriebene Werkzeug 72 reagiert auf einen Befehl "Browser konfigurieren" mit einem
Browserkonfigurationsschritt 76, der Standardfiltereigenschaften eines Browsers einstellt. Geeignete Browserfiltereigenschaften umfassen den Namen einer Objektklasse, eine Flag, die angibt, ob Volumina während des Durchsuchens vergrössert werden sollen, sowie eine Flag, die angibt, ob Auswahlen auf ein einzelnes Objekt 49 oder 51 eingeschränkt werden sollen. Geeignete Browserfiltereigenschaften umfassen auch Contextinformation, beispielsweise den Namen des Benutzers und den Ort in der Hierarchie des Netzwerks 10.
Das Befehls-getriebene Werkzeug 72 reagiert auf einen Befehl "Objekt erzeugen" mit einem Browserfreischaltschritt 78, an den sich ein Objekterzeugungsfreischaltschritt 80 anschliesst. Der Browserfreischaltschritt 78 initialisiert die Ausführung des Browsers oder setzt diese fort, und gestattet so dem Administrator, die vorhandenen Objekte 49 und 51, Dateien, und/oder momentane Attributwerte durchzuscannen. Das Durchsuchen ermöglicht es dem Administrator, zu bestimmen, ob ein Objekt 49 oder 51 mit einigen oder sämtlichen Attributen und Attributwerten bereits vorhanden ist. Bei einer Ausführungsform leitet der Browserfreischaltschritt 78 die Ausführung eines ebenen (nicht-hierarchischen) Browsers ein, durch Aufruf von "NWALaunchFSFlatBrowser().
Der Objekterzeugungsfreischaltschritt 80 erhält den Pfadnamen eines neuen Objekts 49 oder 51 von dem Administrator. Eine Ausführungsform wandelt den Pfadnamen in den Pfadnamen einer universellen Benennungsübereinkunft ("UNC") um, falls erforderlich. Der Objekterzeugungsfreischaltschritt 80 erzeugt ein Objekt 49 oder 51, welches den gegebenen Namen und andere Attributwerte aufweist, die von dem Administrator oder standardmässig angegeben werden.
Zur Erzeugung eines Anwendungsobjekts 49 erzeugt eine Ausführungsform des Schrittes 80 zuerst eine lokale Kopie des Contextes durch Aufruf von NWDSDuplicateContext(). NWDSSetContext() wird dann aufgerufen, um den DCK_NAME_CONTEXT in der lokalen Kopie des Contextes gleich dem Namen des Containerobjekts in der Datenbank 38 einzustellen, welche das neue Anwendungsobjekt 49 enthalten wird. Ein Puffer zum Halten der Attributwerte des neuen Anwendungsobjekts 49 wird zugeordnet durch Aufruf von NWDSAllocBuf(), und initialisiert durch Aufruf von NWDSlnitBuf(). Vorgeschriebene Attribute des neuen Anwendungsobjekts 49 werden initialisiert durch Aufruf von NWDSPutAttrName() und NWDSPutAttrVal() für jedes Attribut. Dann wird NWDSAddObject() aufgerufen, mit den Context- und momentan vorgeschriebenen Attributwerten als Parameter, um das Objekt 49 in der Datenbank 40 zu erzeugen. Die Symboldaten des neuen Anwendungsobjekts 49 werden in einer Datei gespeichert, durch Aufruf von NWDSOpenStream(), _lwrite(), und close(). Schliesslich werden der Puffer und die lokale Kopie des Contextes freigegeben durch Aufruf von NWDSFreeßuf() und NWDSFreeContext(). Ähnliche Schritte werden bei Desktop-Attributen 51 unternommen.
Ein Abänderungsschritt 82, der in Reaktion auf einen Befehl "Abändern" durchgeführt wird, arbeitet auf analoge Weise wie der Nachrichtenhandhabungsschritt 70 des Ereignisgetriebenen Werkzeugs 54, um die Attributwerte eines Anwendungsobjekts 49 abzuändern. Bei einer Ausführungsform ruft der Abänderungsschritt 82 NWDSGetSyntaxID() auf, NWDSPutChange() und NWDSPutAttrVal(), um die Attribute des Anwendungsobjekts 49 nach Aktualisierung eines lokalen Puffers abzuändern. Der lokale Puffer wird zugeordnet und initialisiert im wesentlichen wie bei dem Objekterzeugungsschritt 80, und dann mit den Abänderungswerten überschrieben. Der Abänderungsschritt 82 ruft dann NWDSModifyObject() auf, um die erforderlichen Änderungen durchzuführen.
Ein Lizenzentfernungsschritt 84 wird in Reaktion auf einen Löschbefehl durchgeführt. Der Lizenzentfernungsschritt 84 kommuniziert mit dem lizensierenden Server, und/oder unternimmt andere Schritte, die einfach von Fachleuten auf diesem Gebiet ermittelt werden, um die Lizenzrechte für die Anwendung 23 zu entfernen. Ein Anwendungsobjektlöschschritt 86 ruft dann Standardroutinen des Typs NWDSxxx() oder äquivalente Routinen auf, um das ausgewählte Anwendungsobjekt 49 zu löschen.
Ein Schliess- und Aufräumschritt 88 schliesst geöffnete Dateien, löst sich von dem Verzeichnisdienst 24, gibt zugeordnete Speicher frei, und führt entsprechende Schritte in Reaktion auf einen Befehl "Schliessen" durch. Bei einer Ausführungsform gibt der Schritt 88 dem Administrator die Option, die Datenbank 38 und/oder das Schema 28 in deren ursprünglichen Zustand vor der Ausführung des Werkzeugs 72 zurückzustellen.
Wie in den Fig. 2, 5 und 6 gezeigt ist, umfasst der Schemaabänderungsschritt 64 einen Attributdefinitions- und Additionsschritt 90, der wiederum getrennte Definitions- and Additionsschritte 91 bis 120 für neue Attribute aufweist, die dem Schema 28 gemäss der vorliegenden Erfindung hinzugefügt werden. Eine Beschreibung der in Fig. 6 gezeigten, neuen Attribute erfolgt nachstehend.
Der Schritt 91 definiert ein "Desktop-"Attribut und fügt dieses hinzu, welches eine unterscheidbare Namensattributsyntax und keine Flags aufweist. Das Desktop- Attribut nimmt als seinen Wert eine Liste von Anwendungsobjekten 49 an, die für ein vorgegebenes Desktop- Objekt 51 angezeigt werden sollten. Bei einer Ausführungsform, welche die NDS-Datenbank 40 verwendet, wird das Desktop-Attribut zu den Klassen Benutzer, Organisationsrolle, Gruppe, Organisationseinheit und Organisation hinzugefügt. Bei einer momentan bevorzugten Ausführungsform wird das Desktop-Attribut nicht der Organisationsrollenklasse hinzugefügt, da dies die Leistung beeinträchtigt.
Der hier verwendete Begriff "Desktop-Objekt" umfasst jedes Objekt 51 in der Datenbank 38, das eine Erscheinungsform einer Klasse darstellt, welche das Desktop-Attribut enthält. Die Zuordnung von Desktop-Attributen zu Containerklassen führt dazu, dass Anwendungsobjekte 49 auf Desktops 52 liegen können, auf die von mehr als einem Benutzer zugegriffen werden kann. Bei alternativen Ausführungsformen wird das Desktop-Attribut einer Untergruppe dieser Klassen und/oder anderen Containerklassen hinzugefügt, beispielsweise Land.
Wenn ein Anwendungsobjekt 49 dem Desktop-Attribut hinzugefügt wird, sollte dafür gesorgt werden, dass das Desktop-Objekt 51 Lese- und Vergleichsrechte für alle Attribute des Anwendungsobjekts 49 erhält, sowie irgendwelche anderen Rechte, die der Datei des ausführbaren Codes der Anwendung 23 von dem Dateisystem verliehen wurden. Anderenfalls kann es möglich sein, dass Benutzer eine Anwendung 73 nicht starten und erfolgreich ausführen können, obwohl der Netzwerkadministrator versuchte, ihnen dieses zu ermöglichen, durch Anordnen des Anwendungsobjekts 49 in einem Desktop- Objekt 51.
Zum Definieren und Hinzufügen des Desktop-Attributs ruft eine Ausführungsform des Schrittes 91 memset() auf, um eine Struktur im RAM zu initialisieren, um die Werte des neuen Attributs zu halten, und stellt dann den Syntaxtyp in dieser Struktur ein, um anzugeben, dass das neue Desktop-Attribut den Syntaxtyp des unterscheidbaren Namens hat. Diese Ausführungsform ruft dann nacheinander auf: NWDSDefineAttr(), NWDSAllocBuf(), NWDSSInitBuf(), NWDSPutAttrName(), NWDSModifyClassDef() und NWDSFreeBuf(), und zwar mit Parametern, die leicht von solchen Personen bestimmt werden, die mit diesen Funktionen vertraut sind. Die anderen hier beschriebenen Attribute werden durch analoge Funktionsaufrufe definiert und hinzugefügt, mit unterschiedlichen Parametern, die leicht von Fachleuten auf diesem Gebiet bestimmt werden.
Der Schritt 93 definiert ein Attribut "Autostart" und fügt dieses hinzu, welches eine Attributsyntax eines getippten Namens und keine Flags aufweist. Das Autostart-Attribut nimmt als seinen Wert eine Liste von Anwendungsobjekten 49 an, die automatisch auf dem Desktop 52 ablaufen sollen, wenn der Anwendungsstarter 50 von dem Desktop 52 gestartet wird.
Wenn das Autostart-Attribut erzeugt oder abgeändert wird, sollte dafür gesorgt werden, dass jedes Desktop-Objekt 51 Lese- und Vergleichsrechte für alle Attribute des Anwendungsobjekts 49 hat, sowie irgendwelche anderen Rechte, die der Anwendung 23 von dem Dateisystem verliehen wurden. Anderenfalls kann es geschehen, dass eine Anwendung 23 nicht starten und erfolgreich ausgeführt werden kann, obwohl der Netzwerkadministrator das Anwendungsobjekt 49 in der Autostartliste angeordnet hat.
Das Autostart-Attribut wird den Desktopklassen hinzugefügt. Bei einer Ausführungsform umfassen diese Klassen die Klassen Benutzer, Organisationsrolle, Gruppe, Organisationseinheit, und Organisation. Bei alternativen Ausführungsformen wird das Autostart-Attribut einer Untergruppe dieser Klassen und/oder anderen Containerklassen hinzugefügt, beispielsweise Land. Bei einer momentan bevorzugten Ausführungsform wird das Autostart-Attribut nicht der Organisationsrollenklasse hinzugefügt, da dies zu einer Beeinträchtigung der Leistung führt.
Der Schritt 96 definiert ein Attribut "Starterkonfiguration" und fügt dieses hinzu, welches eine Stromattributsyntax und eine einwertige Flag aufweist. Bei einer Ausführungsform nimmt das Starterkonfigurationsattribut als seinen Wert einen Strom an. Bei alternativen Ausführungsformen wird eine Ganzzahl-Attributsyntax verwendet, und werden die Werte des Attributs als Bitflags und/oder Bitfelder behandelt.
Das Starterkonfigurationsattribut enthält verschiedene Angaben in Bezug auf das gewünschte Verhalten des Starters 50. Geeignete Angaben umfassen eine Angabe, ob der Anwendungsstarter 50 seine Standardeinstellungen verwenden sollte, Angaben in Bezug auf Symbolauffrischung, eine Angabe, ob ein Benutzer die Grösse des Fensters ändern darf, welches die Anwendungsobjektsymbole anzeigt, eine Angabe, ob die Anwendungssymbole automatisch vor ihrer Anzeige sortiert werden sollen, eine Angabe, ob die Fenstergrösse des Starters 50 und die Position auf dem lokalen Plattenlaufwerk gespeichert werden sollen, die Anzahl an Containerniveaus zwischen dem Objekt des Benutzers und dem Grund der hierarchischen Datenbank 38, die zur Anzeige von Symbolen von Anwendungsobjekten 49 durchgescannt werden sollen, und eine Angabe, ob es dem Benutzer gestattet ist, Symbole aus dem Starter 50 herauszuziehen und auf dem Desktop 52 abzulegen.
Geeignete Auffrischungsangaben umfassen eine Angabe, ob es dem Benutzer gestattet ist, von Hand die Symbole des Anwendungsobjekts 49 aufzufrischen, die auf dem Desktop 52 angezeigt werden, sowie eine Angabe, ob die Symbole des Anwendungsobjekts 49 automatisch nach Ablauf jedes Zeitintervalls mit festgelegter Länge aufgefrischt werden sollen. Die Auffrischung von Symbolen wird genauer im Zusammenhang mit Fig. 8 erläutert. Andere Ausführungsformen enthalten unterschiedliche Angaben für die Starterkonfiguration.
Wenn das Starterkonfigurationsattribut eines Benutzers oder Containerobjekts abgeändert wird, sollte dafür gesorgt werden, dass das Objekt Lese- und Vergleichsrechte für das Starterkonfigurationsattribut erhält. Bei einer Ausführungsform wird das Starterkonfigurationsattribut den Klassen Benutzer, Organisationseinheit und Organisation hinzugefügt. Bei alternativen Ausführungsformen wird das Starterkonfigurationsattribut unterschiedlichen oder zusätzlichen Desktopklassen hinzugefügt.
Der Schritt 98 definiert ein Attribut "Symbol" und fügt dieses hinzu, welches eine Stromattributsyntax und eine einwertige Flag enthält. Bei einer bevorzugten Ausführungsform nimmt das Symbolattribut als seinen Wert einen Strom an, der eine Liste von Symbolen des Anwendungsobjekts 49 in dem Dateiformat *ICO enthält. Das Symbolattribut wird zu einer Klasse generischer Anwendungsobjekte in dem Schema 28 hinzugefügt.
Bei herkömmlichen Systemen werden Symboldaten, die ein oder mehrere Symbole für eine Anwendung 23 definieren, in der ausführbaren Datei der Anwendung 23 gespeichert. Die Symbole, die auf dem Desktop 52 angezeigt werden können, sind daher typischerweise auf zahlreiche Dateiserver 14 verstreut (Fig. 1). Unter Verwendung des Symbolattributs gemäss der vorliegenden Erfindung zum Halten einer zusätzlichen Kopie einiger oder sämtlicher dieser Symboldaten können Symbole für sämtliche Anwendungsobjekte 49, die für den Benutzer sichtbar sind, von der zentralen Datenbank 38 erhalten werden. Daher ist es nicht erforderlich, sich an einen Server 14 anzuschliessen, der eine verfügbare Anwendung 23 hält, es sei denn, dass der Benutzer diese Anwendung 23 starten möchte, und bis zu diesem Zeitpunkt.
Der Schritt 100 definiert ein Attribut "Dateipfad" und fügt dieses hinzu, welches eine Fallignorierungskettenattributsyntax und eine einwertige Flag aufweist. Bei einer Ausführungsform nimmt das Dateipfadattribut als seinen Wert den vollständigen Pfad (einschliesslich des Servernamens) zur Datei *.EXE, *.COM, *BAT des Anwendungsobjekts an, oder zu einer anderen ausführbaren Datei. Bei alternativen Ausführungsformen wird der Servername in einem getrennten einwertigen "Server-"Attribut einer Fallignorierungskette oder in einem konfigurierbaren Standardformat gehalten. Bei einigen Ausführungsformen ist das Dateipfadattribut mehrwertig anstelle von einwertig, und enthält einen oder mehrere ausführbare Dateipfade. Das Auflisten mehrerer Dateipfade erhöht die Möglichkeit des Startens einer Anwendung 23 in einem Fall, in welchem ein bestimmter Server 14 nicht mehr verfügbar wird. Das Dateipfadattribut wird zur generischen Anwendungsobjektklasse hinzugefügt. Bei einigen Ausführungsformen wird Fehlertoleranz auf einem höheren Niveau durch ein Anwendungsfehlertoleranzobjekt 53 (Fig. 2) zur Verfügung gestellt. Das Anwendungsfehlertoleranzobjekt 53 enthält eine Liste, die auf mehrere Anwendungsobjekte 49 zugreift. Eine geeignete Ausführungsform der Liste verwendet ein Attribut "alternative Anwendungsobjekte", welches eine Syntax mit einem unterscheidbaren Namensattribut und keine Flags aufweist. Alternativ kann das alternative Anwendungsobjektattribut der generischen Anwendungsobjektklasse hinzugefügt werden.
Bei einem Betriebsverfahren ordnet der Netzwerkadministrator Anwendungsobjekte 49 in derselben Liste an, wenn sie sich nur dahingehend unterscheiden, welcher Server 14 (Fig. 1) den ausführbaren Code hält. Daher kann der Anwendungsstarter 50 einfach ein Ersatz-Anwendungsobjekt 49 zum Starten auffinden, wenn ein Server 14 herunterfährt. Alternativ kann die "beste" (also neueste, schnellste, physikalisch nächste, auf dem am wenigsten belasteten Server befindliche, oder verlässlichste) Version einer Anwendung 23 zuerst gelistet werden, wobei weniger wünschenswerte Versionen in der Reihenfolge abnehmender Wünschbarkeit folgen.
Der Schritt 102 definiert ein Attribut "Arbeitsverzeichnis" und fügt dieses hinzu, welches eine Fallignorierungskettenattributsyntax und die einwertige Flag aufweist. Bei einer Ausführungsform nimmt das Arbeitsverzeichnisattribut als seinen Wert den vollständigen Pfad (einschliesslich des Servernamens) zu dem Arbeitsverzeichnis der Anwendung an. Das Arbeitsverzeichnisattribut wird zu der generischen Anwendungsobjektklasse hinzugefügt.
Der Schritt 104 definiert ein Attribut "Flag" und fügt dieses hinzu, welches eine Ganzzahl-Attributsyntax und die einwertige Flag aufweist. Bei einer alternativen Ausführungsform ist das Flag-Attribut mehrwertig. Der Flag- Attributwert wird als Bitset behandelt. Bei einer Ausführungsform geben die Bits an, ob automatisch das Anwendungsfenster minimiert werden soll, und ob die ursprünglichen Laufwerkzuordnungen oder Druckerportzuordnungen wiederhergestellt werden sollen, nachdem eine Anwendung 23 beendet ist. Das Flag-Attribut wird der generischen Anwendungsobjektklasse hinzugefügt.
Der Schritt 106 definiert ein Attribut "Werbetext" und fügt dieses hinzu, welches eine Fallignorierungskettenattributsyntax und die einwertige Flag aufweist. Der Werbetextwert ist eine kurze Beschreibung der Anwendung 23, die einem Benutzer, der mit der Anwendung 23 nicht vertraut ist, mitteilt, was die Anwendung 23 zur Verfügung stellt, und warum der Benutzer möglicherweise die Anwendung 23 zu benutzen wünscht. Wie das Symbolattribut kann das Werbetextattribut als kurze Identifizierung zum Zugriff auf das Anwendungsobjekt 49 in der Datenbank 38 verwendet erden. Das Werbetextattribut wird der generischen Anwendungsobjektklasse hinzugefügt.
Die Schritte 108 und 110 definieren ein Attribut "Anfahrskript" bzw. "Herunterfahrskript". Jedes Skriptattribut weist eine Stromattributsyntax und die einwertige Flag auf. Der Anfahrskriptattributwert ist ein Skript, das ablaufen soll, bevor die Anwendung 23 ausgeführt wird, während der Herunterfahrskriptattributwert ein Skript ist, das ablaufen soll, nachdem die Anwendung 23 beendet ist. Bei einer Ausführungsform liegt jedes Skript in dem Format NetWare Login Skript vor. Die Skriptattribute werden der generischen Anwendungsobjektklasse hinzugefügt.
Der Schritt 112 definiert ein Attribut "Lizensierung" und fügt dieses hinzu, welches eine Stromattributsyntax und die einwertige Flag aufweist. Bei einer Ausführungsform enthält der Lizensierungswert Information, die von dem NetWare Lizenzserver dazu benötigt wird, den Umfang und die Gültigkeit der Lizenz der Anwendung 23 zu überprüfen. Das Lizensierungsattribut wird zur generischen Anwendungsobjektklasse hinzugefügt.
Der Schritt 114 definiert ein Attribut "Parameter" und fügt dieses hinzu, welches eine Fallignorierungskettenattributsyntax und die einwertige Flag aufweist. Bei einer alternativen Ausführungsform weist das Parameterattribut eine Stromattributsyntax auf. Der Parameterattributwert enthält Befehlszeilenparameter, die an die Anwendung 23 übergeben werden sollen, wenn sie gestartet wird. Das Parameterattribut wird zur generischen Anwendungsobjektklasse hinzugefügt.
Der Schritt 116 definiert ein Attribut "Laufwerkszuordnungen" und fügt dieses hinzu, welches eine Fallignorierungskettenattributsyntax aufweist. Der Laufwerkzuordnungsattributwert enthält eine Liste von Laufwerken, die durch den Anwendungsstarter 50 vor der Ausführung der Anwendung 23 zugeordnet werden müssen. Ein geeignetes Format ist "Laufwerk 1: = Pfad 1; Laufwerk 2: = Pfad 2 usw. Andere geeignete Formate entsprechen der Standardsyntax für die Einrichtung NetWare MAP.EXE. Das Laufwerkzuordnungsattribut wird zur generischen Anwendungsobjektklasse hinzugefügt.
Der Schritt 118 definiert ein Attribut "Printerports" und fügt dieses hinzu, welches eine Fallignorierungskettenattributsyntax aufweist. Der Druckerportattributwert enthält eine Liste von Druckerports, die von dem Anwendungsstarter 50 vor der Ausführung der Anwendung 23 erfasst werden müssen. Ein geeignetes Format ist: Port 1: = Warteschlange 1; Port 2: = Warteschlange 2, usw. Andere geeignete Formate entsprechen der Standardsyntax für die NetWare CAPTURE.EXE-Einrichtung. Das Druckerportattribut wird zu der generischen Anwendungsobjektklasse hinzugefügt.
Der Schritt 120 definiert ein Attribut "Kontakte" und fügt dieses hinzu, welches eine Attributsyntax mit einem unterscheidbaren Namen hat. Der Kontaktattributwert enthält eine Liste anderer Netzwerkbenutzer, die Hilfe leisten können, wenn dieser Benutzer ein Problem mit der Anwendung 23 hat. Im allgemeinen sollten daher der Öffentlichkeit Leserechte für das Kontaktattribut in jedem Anwendungsobjekt verliehen werden. Das Kontaktattribut wird der generischen Anwendungsobjektklasse hinzugefügt.
Alternative Ausführungsformen der vorliegenden Erfindung wählen unterschiedliche Attribute zur Definition von Anwendungsobjekten aus. Beispielsweise, und ohne dass dies einschränkend verstanden wird, lassen einige Ausführungsformen eine oder mehrere der wahlweisen Attribute und Attributdefinitionsschritte weg, die voranstehend beschrieben wurden. Andere Ausführungsformen lassen nur ein oder mehrere der folgenden Attribute weg: Flags, Werbetext, Anfahrskript, Herunterfahrskript, Lizensierung, und Kontakte. Die Benutzerschnittstelle und andere Abschnitte dieser alternativen Ausführungsformen enthalten entsprechende Änderungen, die leicht von Fachleuten auf diesem Gebiet bestimmt werden. Andere Ausführungsformen der Erfindung definieren ein oder mehrere der Attribute anders als bei der voranstehenden erläuternden Beschreibung. Beispielsweise, und ohne dies einschränkend zu verstehen, stellen bei alternativen Ausführungsformen ein oder mehrere der Attribute die nicht-entfernbare Flag ein, und/oder verwenden eine unterschiedliche Attributsyntax.
Bei einer alternativen Ausführungsform definiert der Schritt 90 ein Attribut "Handhabung" und fügt dieses hinzu, welches eine Syntax mit unterscheidbaren Namen und keine Flags aufweist. Der Handhabungsattributwert enthält eine Liste von Handhabungsvorrichtungen, beispielsweise Handhabungsvorrichtungen des Typs *INI für die Anwendung 23. Das Handhabungsattribut wird der generischen Anwendungsobjektklasse hinzugefügt.
Bei einer alternativen Ausführungsform definiert der Schritt 90 ein Attribut "Suchzuordnungspfad" und fügt dieses hinzu, welches eine Syntax mit unterscheidbarem Namen und keine Flags aufweist. Der Suchzuordnungspfadattributwert enthält eine Liste von Verzeichnissen, für die Suche nach Dateien, die von der Anwendung 23 angegeben werden, auf analoge Weise wie bei dem vertrauten DOS-Suchpfad. Das Suchzuordnungspfadattribut wird der generischen Anwendungsobjektklasse hinzugefügt.
Bei einer alternativen Ausführungsform definiert der Schritt 90 ein Attribut "Alles erfassen" und fügt dieses hinzu, welches eine Stromsyntax und keine Flags aufweist. Der Wert des Attributs für alles erfassen enthält Anwendungsdefinierte Werte, beispielsweise Werte in einem generischen Datenfeld, um vorgegebene Anförderungen zu erfüllen, oder Optionen zur Ausführung der Anwendung 23 aufzurufen. Das Attribut für alles erfassen wird der generischen Anwendungsobjektklasse hinzugefügt.
Bei einer alternativen Ausführungsform fügt ein Schritt der vorliegenden Erfindung ein Attribut "Siehe auch" hinzu, welches eine Syntax mit einem unterscheidbaren Namen und · keine Flags aufweist. Der Wert des Attributs "Siehe auch" enthält eine Liste von Desktop-Objekten, die ein Desktop- Attribut aufweisen, dessen Wert den Namen des Anwendungsobjekts 49 enthält. Das Attribut "Siehe auch" wird der generischen Anwendungsobjektklasse hinzugefügt.
Wie aus den Fig. 2 und 5 hervorgeht, schliesst sich an den Schritt 90 der Definition und Hinzufügung neuer Attribute der Schritt 92 der Definition und Hinzufügung der generischen Anwendungsobjektklasse an. Auf die Erzeugung der generischen Klasse folgt ein Schritt 94, der eine oder mehrere Plattformspezifische Anwendungsobjektklassen definiert und hinzufügt, die von der generischen Anwendungsobjektklasse geerbt werden. Die Schritte 92 und 94 sind genauer in Fig. 7 erläutert.
Die Definition und Hinzufügung einer Klasse in dem Schema 28 umfasst einen Schritt 122 der Zuordnung und Initialisierung eines Puffers zum Halten von Information in Bezug auf die neue Klasse. Bei einer Ausführungsform umfasst der Schritt 122 Aufrufe von NWDSAllocBuf() und NWDSInitBuf(). Während eines Schritts 124 werden die Oberklassen der neuen Klasse durch aufeinanderfolgende Aufrufe von NWDSBeginClassItem() und NWDSPutClassItem() oder äquivalente Vorrichtungen definiert. Während eines Schrittes 126 werden die Einschliessungsklassen der neuen Klasse durch ähnliche aufeinanderfolgende aufrufe von NWDSBeginClassItem() Und NWDSPutClassItem() oder äquivalente Vorrichtungen definiert.
Während zusätzlicher Schritte 128, 130 und 132 werden die Benennungsattribute, vorgeschriebenen Attribute, bzw. wahlweisen Attribute der neuen Klasse definiert. Bei einer Ausführungsform jedes der Schritte 128,130 und 132 ist ein anfänglicher Aufruf von NWDSBeginClassItem() vorgesehen, gefolgt von Aufrufen von NWDSPutClassItem() für jedes der Benennungsattribute, jedes der vorgeschriebenen Attribute, bzw. jedes der wahlweisen Attribute. Schliesslich wird NWDSDefineClass() aufgerufen, um die neue Klasse in dem Schema 28 zu erzeugen.
Wie aus den Fig. 2, 5 und 7 hervorgeht, führt bei einer Ausführungsform der vorliegenden Erfindung der Schritt 92 eine Definition und Hinzufügung zum Schema 28 einer generischen Anwendungsobjektklasse durch, welche Top als Oberklasse aufweist, und Organisation und Organisationseinheit als Einschliessungsklassen. Die generische Anwendungsobjektklasse ist eine unwirksame Containerklasse, welche das vertraute gemeinsame Namensattribut als ihr Benennungsattribut aufweist, und Attribute aufweist, welche den Dateipfad, die Beschreibung, und den gemeinsamen Namen enthalten. Der Wert des Beschreibungsattributs ist ein Name, der unterhalb des Symbols der Anwendung 23 auf dem Desktop 52 erscheint.
Die optionalen Attribute der generischen Klasse umfassen die folgenden Attribute, die im Schritt 90 (Fig. 6) definiert werden: Symbol, Arbeitsverzeichnis, Flags, Werbetext, Anfahrskript, Herunterfahrskript, Lizensierung, Parameter, Laufwerkszuordnungen, Druckerports, und Kontakte. Andere Ausführungsformen definieren die generische Klasse unterschiedlich, oder lassen die generische Klasse vollständig weg, und verwenden nur Plattform-spezifische Klassen.
Eine Ausführungsform des Schrittes 94 führt eine Definition und Hinzufügung zum Schema 28 einer Plattform-spezifischen Anwendungsobjektklasse von Windows (Version 3.x und/oder Windows 95) durch, welche die im Schritt 92 definierte generische Klasse als ihre Oberklasse aufweist. Die Windows- Anwendungsklasse ist eine wirksame Nicht-Containerklasse, welche die Benennungsattribute, die vorgeschriebenen Attribute, und die wahlweisen Attribute der generischen Klasse erbt. Andere Ausführungsformen der vorliegenden Erfindung definieren entsprechend andere Plattformspezifischen Klassen für die Umgebungen DOS, Macintosh, OS/2, UNIX®, und/oder NT® (OS/2 ist eine Marke der International Business Machines Corporation; UNIX ist eine registrierte Marke von Novell, Inc. NT ist eine registrierte Marke der Microsoft Corporation).
Wie aus den Fig. 2 und 8 hervorgeht, ist der Anwendungsstarter 50 der Desktopumgebung 52 zugeordnet. Bei einigen Ausführungsformen der vorliegenden Erfindung werden der Anwendungsstarter 50 und die Anwendungsverwaltungsroutinen 48 zu einem einzigen Werkzeug vereinigt, ähnlich NWAdmin. Diese Ausführungsformen gestatten es einem Benutzer, einfach eine Durchsuchung nach Anwendungsobjekten 49 durchzuführen, und/oder eine Suche des Typs "Gelbe Seiten" der Datenbank 98 für ein bestimmtes Anwendungsobjekt 49 durchzuführen, und dann dieses Anwendungsobjekt 49 zu starten. Bei anderen Ausführungsformen führt der Anwendungsstarter 50 eine Suche innerhalb der Datenbank 38 dadurch durch, dass nach dem Desktop-Attribut in einem oder mehreren Desktop-Objekten 51 gesucht wird.
Bei "Bootstrap-"Ausführungsformen der vorliegenden Erfindung liest ein kleines Codestück bei dem Klienten 16 ein Containerobjekt eines Benutzerobjekts in der Datenbank 38, wenn sich ein Benutzer anmeldet. Das Containerobjekt weist ein Stromsyntaxattribut "Anwendungstarter-Bootstrap" auf, welches den ausführbaren Code für den Anwendungsstarter 50 enthält. Ein Verfahren gemäss der vorliegenden Erfindung umfasst den Schritt des Lesens von ausführbaren Startercode aus dem Anwendungsstarter-Bootstrap-Attribut in der Datenbank 38. Nachdem der Bootstrap-Attributwert von dem Klienten 16 gelesen wurde, wird der Anwendungsstarter 50 ausgeführt. Das Speichern des Anwendungsstarters 50 in einem Stromattribut stellt die Vorteile wie Replizieren und Verteilung von Speichern in der Datenbank 38 zur Verfügung.
Wie aus Fig. 8 hervorgeht, führt der Starter 50 einen Leseschritt 139 durch. Während des Leseschritts 139 liest der Starter 50 den momentanen Wert des Starterkonfigurationsattributs aus der Schemadatenbank 38 und speichert diese Information in einem lokalen Puffer.
Bei einer Ausführungsform werden der Wert des Starterkonfigurationsattributs, und ebenso die Werte anderer Attribute, aus der Schemadatenbank 38 im wesentlichen folgendermassen gelesen. Zwei Puffer werden in dem Schema 38 durch Aufruf von NWDSAllocBuf() zugeordnet. Ein Puffer hält die Werte sämtlicher Attribute eines Objekts 49 oder 51, und der andere hält jene Werte, die von Interesse sind. Der erste Puffer wird durch Aufruf von NWDSInitBuf() initialisiert. Dann erfolgen Aufruf von NWDSRead(), NWDSGetAttrCount(), NWDSGetAttrName(), und NWDSPutAttrName(), um die interessierenden Werte aus dem ersten Puffer in den zweiten Puffer zu kopieren. Schliesslich wird ein Aufruf von NWDSGetAttrCount() und die entsprechende Anzahl von Aufrufen von NWDSGetAttrName() durchgeführt, um die Werte von dem Schema 28 in den Speicher des Starters 50 zu kopieren. Es wird NWDSComputAttrValSize() aufgerufen, um die Grösse des Speichers zu bestimmen, die von dem Starter 50 benötigt wird, um den Attributwert oder die Attributwerte zu halten, die interessieren. Dann wird zweimal NWDSFreeßuf() aufgerufen, um die beiden Puffer der Datenbank 38 freizugeben.
Der Starter 50 führt auch einen Autostart-Startschritt 140 durch, um jede der Anwendungen 23 zu starten, die in dem Autostart-Attribut des Desktop-Objekts 51 angegeben sind. Ausführungsformen, welche den Autostartdefinitionsschritt 93 (Fig. 6) weglassen, lassen auch den Autostart-Startschritt 140 weg. Wie auch sonst werden Fehlernachrichten dem Benutzer und/oder dem Netzwerkadministrator zur Verfügung gestellt, wenn ein versuchter Schritt fehlschlägt.
Wie erläutert wird das Symbol für eine Anwendung 23 vorzugsweise in dem Symbolattribut gespeichert, zusätzlich zu seiner normalen Speicherung in der ausführbaren Datei der Anwendung 23. Daher führt der Anwendungsstarter 50 einen Schritt 142 zum Erlangen von Symbolen durch, um aus der Verzeichnisdienstdatenbank 38 die Symbole sämtlicher Anwendungen 23 zu erhalten, die in dem Desktop-Attribut angegeben wird.
Bei einer Ausführungsform wird der Schritt 142 zum Erlangen von Symbolen unter Verwendung von Software erzielt, die im wesentlichen auf der icon.c-Datei in der Microsoft Development Library CD-ROM vom Oktober 1994 beruht, die als Teil des Microsoft Developer Networks verteilt wird. Bei einer Ausführungsform wird die Datei icon.c so abgeändert, wie dies leicht von Fachleuten auf diesem Gebiet ermittelt wird, damit sie mit der Borland Object Windows Library ("OWL) arbeiten kann, anstatt mit der Standard-Windows-API. Die Funktion MarkIcon() in icon.c wird daher so abgeändert, dass ein Zeiger zu einer OWL-Ticon-Struktur zurückgegeben wird, statt zu einer Windows-HICON-Struktur. Die Funktion ReadIcon() in icon.c wird abgeändert, um das Symbol zurückzuführen, das am besten zur verfügbaren Bildschirmauflösung passt, zur Anzahl an Farben und zur Systemmetrik für die Symbolgrösse, anstatt einfach das erste Symbol zu lesen. Alternative Ausführungsformen verwenden anderen Code zum Lesen der Symboldaten aus dem Symbolattribut und/oder zur Erzeugung eines entsprechenden Symbols zur Anzeige auf dem Desktop 52.
Während eines Durchsuchungs/Suchschrittes 143 führt der Starter 50 eine Durchsuchung und/oder eine Suche durch, wie dies vom Benutzer angefordert wird. Geeignete Browser zur Durchführung des Schritts 143 umfassen, ohne Einschränkung, bekannte ebene Browser, andere bekannte Browser, sowie Browser des Typs, der in dem NWAdmin-Werkzeug zur Verfügung gestellt wird. Die Suche während des Schrittes 143 kann bestimmte Suchparameter umfassen, oder die Verwendung vorher festgelegter Suchparameter. Die Suche kann auch eine Festlegung enthalten, wieviel von dem Baum der hierarchischen Datenbank 38 durchsucht werden soll. Geeignete Suchalgorithmen werden einfach von Fachleuten auf diesem Gebiet festgelegt, und umfassen ohne Einschränkung Algorithmen für Suchvorgänge des Typs "Gelbe Seiten" jener Art, wie sie von NWAdmin durchgeführt wird.
Nachdem die Symbole auf dem Desktop 52 angezeigt wurden, reagiert der Starter 50 auf Befehle oder Ereignisse, die von dem Benutzer zur Verfügung gestellt werden. Ein derartiger Befehl weist den Starter 50 an, einen Symbolauffrischungsschritt 144 von Hand durchzuführen. Eine Symbolauffrischung ist deswegen nützlich, da der Netzwerkadministrator neue Anwendungsobjekte 49 jenen hinzugefügt haben kann, die für den Benutzer verfügbar sind, andere Anwendungsobjekte 49 gelöscht haben kann, und/oder die momentanen Attributwerte wiederum anderer Anwendungsobjekte 49 geändert haben kann, nachdem der Starter 50 zuletzt diese Werte gelesen hat.
Der Starter 50 hält eine interne Liste von Anwendungsobjekten 49 aufrecht, für welche momentan Symbole angezeigt werden. Der Auffrischungsschritt 144 von Hand veranlaßt den Starter 50 dazu, einen Abschnitt der Datenbank 38 zu durchscannen, um zu bestimmen, ob sich die interne Liste des Starters 50 von den Attributen unterscheidet, die in dem Desktop-Attribut des Desktops 52 in der Datenbank 38 aufgelistet sind. Der Abschnitt der Hierarchie der Datenbank 38, der durchsucht wird, wird durch den Containerniveauwert festgelegt, der in dem Starterkonfigurationsattribut des Benutzers und Containerobjekten gespeichert ist. Bei einer Ausführungsform werden Zeitstempel dazu verwendet, Änderungen der Datenbank 38 festzustellen. Bei einer anderen Ausführungsform wird ein Zeichenkettenvergleich, ähnlich jenem, der durch stremp() durchgeführt wird, zur Erfassung von Namensänderungen durchgeführt. Irgendwelche festgestellten Unterschiede wirken sich auf die interne Liste und andere interne Daten des Starters 50 und auf die Symbole aus, die auf dem Bildschirm des Endgeräts dargestellt werden.
Der Benutzer kann auch den Starter 50 anweisen, einen Betrachtungsschritt 146 durchzuführen. Der Betrachtungsschritt 146 zeigt die momentanen Werte vorbestimmter Attribute an. Eine Ausführungsform zeigt sämtliche Attribute von Anwendungsobjekten 49 an, deren Symbole momentan für den Benutzer dargestellt werden. Die in Fig. 8 dargestellte Ausführungsform zeigt die Attributwerte an, erlaubt es jedoch Benutzern nicht, diese Werte zu ändern. Eine alternative Ausführungsform erlaubt Benutzern, die Werte ausgewählter Attribute zu ändern, beispielsweise des Parameterattributs und/oder des Kontaktattributs.
Im Zusammenhang mit dem Betrachtungsschritt 146 kann der Benutzer einen Kontakt für Hilfe während eines Frageschrittes 148 anfordern. Bei einer Ausführungsform umfaßt der Frageschritt 148 die Betrachtung des momentanen Wertes des Kontaktattributs, die Auswahl einer bestimmten Kontaktperson, und nachfolgende Auswahl der e-mail-Adresse oder Telefonnummer dieser Kontaktperson. In Reaktion hierauf leitet der Starter 50 eine e-mail-Korrespondenz mit der Kontaktperson ein, bzw. wählt die Telefonnummer der Kontaktperson, durch Aufruf von Standardkommunikationssoftware. Beispielsweise wird e-mail- Korrespondenz einfach durch den Starter 50 durch das Nachrichten-API-Protokoll eingeleitet, das von Microsoft verbreitet wird, oder durch andere Standardkommunikationsschnittstellen.
Selbstverständlich kann der Benutzer auch eine bestimmte Anwendung 23 auswählen, und den Starter 50 anweisen, einen Anwendungsstartschritt 150 durchzuführen. In einer Ausführungsform, die an die Windows-Umgebung angepaßt ist, wird die Anwendung 23 für den Start dadurch ausgewählt, daß ein Doppelklick mit einem Mausknopf erfolgt, nachdem ein Desktop-Cursor über dem angezeigten Symbol der Anwendung 23 angeordnet wurde. Der Startschritt 150 wird nachstehend im Zusammenhang mit den Fig. 9 bis 11 erläutert.
Wie wiederum aus den Fig. 2 und 8 hervorgeht, führt der Starter 50 auch bestimmte Schritte durch, die nicht direkt von dem Benutzer angefordert werden. Beispielsweise hält der Starter 50 eine interne Struktur aufrecht, welche den momentanen Status jeder Anwendung 23 widerspiegelt, die von dem Starter 50 gestartet wird. Diese Statusinformation enthält Benutzerschnittstelleninformation, beispielsweise Laufwerkzuordnungen, Druckerporterfassungen, und Serveranschlüsse, die von dem Starter 50 vordem Starten der Anwendung 23 durchgeführt werden; sowie eine Anzeige, ob die Anwendung 23 beendet ist. Der Starter 50 stellt die Beendigung einer Anwendung 23 dadurch fest, daß er eine Abfrage durchführt, durch einen Interrupt, oder eine Ereignismitteilung, oder durch eine andere vertraute Vorrichtung. Änderungen des Status der Anwendung 23 wirken sich auf die interne Struktur des Starters 50 während eines Statusaktualisierungsschrittes 152 aus.
Wenn eine von dem Starter 50 gestartete Anwendung 23 beendet ist, aktualisiert der Starter 50 die Statusinformation, und räumt dann während eines Aufräumungsschrittes 154 auf. Der Aufräumschritt 154, der entsprechend den Einstellungen in dem Flag-Attribut des Anwendungsobjekts durchgeführt wird, umfasst möglicherweise die Aufhebung der Zuordnung von Laufwerken, die Freigabe erfasster Druckports, die Abtrennung von Servern 14 (Fig. 1), und die Freigabe von Speicher, der intern von dem Starter 50 verwendet wird, um die Statusinformation der Anwendung zu halten.
Wenn das Starterkonfigurationsattribut angibt, dass Symbole automatisch aufgefrischt werden sollen, dann wird ein Symbolaktualisierungsschritt 156 ebenfalls ohne eine direkte Benutzeranforderung durchgeführt. Abgesehen von der Initialisierung durch den Starter 50 ist der Symbolaktualisierungsschritt 156 im wesentlichen gleich dem vom Benutzer eingeleiteten Symbolauffrischungsschritt 144 von Hand. Die Schritte 144 und 156 werden beide zu dem Zweck durchgeführt, die Arbeitsbelastung des Netzwerkadministrators zu verringern, durch Verringerung oder Ausschaltung des Erfordernisses, dass der Administrator von Hand Benutzer- Desktops 52 aktualisieren muss, nachdem die Anwendungsobjekte 49 in der Schemadatenbank 38 geändert wurden.
Wie aus den Fig. 2, 8 und 9 hervorgeht, umfasst der Schritt 140 des Startens der Autostartanwendungen 23 die wiederholte Ausführung eines Startschritts 158, wobei eine Wiederholung für jede Anwendung 23 durchgeführt wird, die in dem Autostartattribut des Desktops 52 angegeben ist. Der Schritt 150 des Startens einer vom Benutzer ausgewählten Anwendung 23 umfasst einen einzelnen Durchlauf des Startschritts 158.
Bei der dargestellten Ausführungsform umfaßt der Startschritt 158 einen Sperrschritt 160, der sowohl den Anwendungsstatusaktualisierungsschritt 152 als auch den automatischen Symbolaktualisierungsschritt 156 sperrt. Die Sperrung der Aktualisierungsschritte 152 und 156 vereinfacht nachfolgende Schritte des Startschritts 158 dadurch, daß eine Inkonsistenz der Statusinformation des Starters 50 verhindert wird.
Während eines Einrichtungsschrittes 162 richtet dann eine Ressourceneinrichtungsroutine Ressourcen ein, die von der Anwendung 23 benötigt werden, die gestartet wird. Der Einrichtungsschritt 162 stellt auch Standard-Flags ein, die mit Betriebssystemprozesserzeugungsroutinen kommunizieren. Der Einrichtungsschritt 162 wird nachstehend genauer im Zusammenhang mit Fig. 10 erläutert.
Ein Prozessinitialisierungsschritt 164 ruft eine Betriebssystemroutine oder eine andere Prozessinitialisierungseinrichtung auf, um einen Prozesssteuerblock oder eine entsprechende Prozesssteuerstruktur zu initialisieren, der bzw. die von dem Betriebssystem verwendet wird. Der Schritt 164 ordnet auch einen Prozessor einem Prozess, einem Task, oder einem Thread entsprechend der Anwendung 23 zu. Bei einer Ausführungsform, die an die Windows-Umgebung angepasst ist, umfasst der Schritt 164 einen Aufruf von ShellExecute() oder CreateProcess().
Ein Aktualisierungsstatusschritt 166 aktualisiert dann die interne Anwendungsstatusinformation des Starters 50, um anzugeben, daß die Anwendung 23 gestartet wurde. Bei einer Ausführungsform zeichnet der Schritt 166 auch eine Prozess-ID auf, eine Ereignishandhabung, eine Task-Handhabung, oder eine andere Prozessidentifizierungseinrichtung, die durch erfolgreiche Beendigung des Prozessinitialisiereraufrufs im Schritt 164 geliefert wird.
Ein Freischaltschritt 168 kehrt dann die Sperreffekte des Schrittes 160 um. Hierdurch können die Aktualisierungsschritte 152 und 156 erneut durchgeführt werden. Wurde die Benutzerschnittstelle während des Schrittes 160 geändert, um anzuzeigen, dass ein Start erfolgt, beispielsweise durch Anzeige eines Eieruhr-Cursors, dann wird diese Änderung ebenfalls durch den Schritt 168 umgekehrt.
Während eines Übergabeschrittes 170 überträgt eine Steuerübertragungsvorrichtung die Steuerung eines Prozessors in dem Netzwerk auf den Prozess, der während des Schrittes 164 initialisiert wurde. Der Starter 50 hält sich selbst an, ruft eine Ruhefunktion auf, oder gibt auf ändere Weise die Steuerung des Prozessors über an den neu gestarteten Prozess der Anwendung 23, um die Ausführung des Anwendungsprogramms zuzulassen. Bei einer an die Windows-Umgebung angepassten Ausführungsform umfasst der Schritt 170 einen Aufruf von Yield ().
Fachleute auf diesem Gebiet werden erkennen, dass andere Ausführungsformen der Erfindung unterschiedliche Schritte enthalten können, welche im wesentlichen dieselben Ergebnisse erzielen wie die Schritte 160 bis 170. Beispielsweise kann der Schritt 164 mit dem Schritt 170 in Umgebungen kombiniert werden, die einen einzelnen Systemaufruf zur Erzeugung eines neuen Prozesses und zur Übergabe der Steuerung an diesen Prozess zur Verfügung stellen. Bei einigen derartigen Ausführungsformen wird die relative Reihenfolge der Schritte 162 und 166 umgekehrt. Darüber hinaus werden der Sperrschritt 160 und der Freischaltschritt 168 bei Ausführungsformen weggelassen, welche keine Interrupt- oder Ereignis-Schemata verwenden. Die Schritte 160 und 168 werden daher dann weggelassen, wenn kein Risiko dafür besteht, inkonsistente Statusinformation in dem Starter 50 während des Schrittes 158 hervorzurufen.
Wie aus den Fig. 2, 10 und 11 hervorgeht, liest ein Leseschritt 174 den Wert des Flag-Attributs. Wenn die Minimierungs-Flag gesetzt ist, startet der Starter 50 die Anwendung 23 so, daß er ihr mitteilt, unter Minimierung abzulaufen.
Ein Laufwerkzuordnungsschritt 176 schliesst sich an die in Fig. 11 dargestellte Schrittreihenfolge an. In dem Laufwerkzuordnungsschritt 176 sind die in Fig. 11 angegebenen "Ressourcen" Plattenlaufwerke, und umfasst der Schritt "Beanspruchung" die Zuordnung eines Laufwerks. Ein Porterfassungsschritt 178 folgt auf entsprechende Weise der in Fig. 11 dargestellten Schrittfolge, jedoch sind im Schritt 178 die Ressourcen Druckerports, und umfasst der Schritt der Beanspruchung die Erfassung eines Druckerports zur Verwendung durch die Anwendung 23. Nach einem Schritt 180, welcher den Ort des ausführbaren Codes für die Anwendung 23 bestimmt, schliesst sich ein Anschlussschritt 182 an die in Fig. 11 angegebenen Schrittreihenfolge an. In dem Anschlussschritt 182 sind die Ressourcen-Server 14 (Fig. 1), und umfasst der Schritt der Beanspruchung den Anschluss des Desktops 52 an einen Server 14, der den ausführbaren Code der Anwendung 23 enthält.
Bei einer Ausführungsform verwendet der Schritt 180 der Bestimmung des Ortes des ausführbaren Codes sowohl den Wert des Dateipfad-Attributs des Anwendungsobjekts als auch das Ergebnis der Verarbeitungsbezugnahmen auf Attribute oder Umgebungsvariablen. Ein geeignetes Format ist das gleiche wie jenes, das beim Anmelden oder bei anderen Skripten verwendet wird, möglicherweise mit einem Prefix in Form eines unterscheidbaren Namens. Bei anderen Ausführungsformen greift der Schritt 180 nicht auf Umgebungsvariablen zu. Bei Umgebungen, welche UNC-Namen unterstützen, enthält der Schritt 180 vorzugsweise Zeichenkettenmanipulationen zur Erzeugung eines UNC-Namens.
Bei einer Ausführungsform verwendet ein Schritt 184 der Bestimmung des Ortes des Arbeitsverzeichnisses der Anwendung sowohl den Wert des Arbeitsverzeichnisattributs des Anwendungsobjekts als auch das Ergebnis der Verarbeitung von Attributen oder Umgebungsvariablen. Bei anderen Ausführungsformen wird nicht auf Umgebungsvariablen zugegriffen. Der Schritt 184 kann auch eine Umwandlung in das UNC-Format enthalten.
Entsprechend kann ein Schritt 186 der Bestimmung der Befehlszeilenparameter sowohl den Wert des Parameterattributs des Anwendungsobjekts als auch das Ergebnis der Verarbeitung von Attributen oder Umgebungsvariablen nutzen. Alternativ können Umgebungsvariable ignoriert werden.
Fig. 11 erläutert die Struktur jedes der Schritte 176, 178 und 182 von Fig. 10. Ein Abfrageschritt 188 stellt fest, ob zusätzliche Ressourcenbeanspruchungen, die durch die Anwendung 23 erfolgten, noch nicht behandelt wurden. Daher stellt in dem Laufwerkzuordnungsschritt 176 der Abfrageschritt 188 fest, ob irgendwelche zusätzlichen Laufwerke zugeordnet werden müssen, durch Überprüfung, um festzustellen, ob alle in dem Laufwerkzuordnungsattribut aufgelisteten Zuordnungen von dem Starter 50 durchgeführt wurden. In dem Porterfassungsschritt 178 stellt der Abfrageschritt 188 entsprechend fest, ob irgendwelche zusätzlichen Druckerports erfasst werden müssen, durch Überprüfung des Druckerportattributs, und in dem Serveranschlussschritt 182 stellt der Abfrageschritt 188 fest, ob irgendwelche zusätzlichen Server 14 (Fig. 1) angeschlossen werden müssen, durch Überprüfung des Dateipfad- Attributs.
Wenn eine andere Ressource (Laufwerk, Port, oder Server) von der Anwendung 23 beansprucht werden muss, die gestartet wird, und ein zweiter Abfrageschritt 190 feststellt, dass die Ressource nicht durch irgendeinen Prozess beansprucht wurde, dann beansprucht ein Beanspruchungsschritt 192 die Ressource für die Anwendung 23. Um seine Festlegungen durchzuführen untersucht der zweite Abfrageschritt 190 die interne Statusinformation des Starters 50 während des Laufwerkzuordnungsschrittes 176 und des Porterfassungsschrittes 178, und ruft NWGetConnectionStatus() während des Anschlussschrittes 182 auf.
In dem Laufwerkzuordnungsschritt 176 stellt der Beanspruchungsschritt 192 im wesentlichen dieselben Funktionen zur Verfügung wie der vertraute DOS-Zuordnungsbefehl. In dem Porterfassungsschritt 178 stellt der Beanspruchungsschritt 192 im wesentlichen dieselben Funktionen zur Verfügung wie der bekannte DOS-Erfassungsbefehl. Bei einer Ausführungsform des Serveranschlussschrittes 182 ruft der Beanspruchungsschritt 192 NWAttachToFileServer() auf, um den Anschluss eines Servers 14 zu erzeugen.
Wenn der zweite Abfrageschritt 190 feststellt, dass die Ressource bereits durch die Anwendung 23, die gestartet wird, oder durch einen anderen Prozess beansprucht wurde, wird ein dritter Abfrageschritt 194 durchgeführt. Der Schritt 194 stellt fest, ob die vorherige Beanspruchung und die von der Anwendung 23 versuchte Beanspruchung konsistent sind. In dem Laufwerkzuordnungsschritt 176 übergibt der dritte Abfrageschritt 194 die Steuerung an einen Fehlerbenachrichtigungsschritt 196, wenn die bereits vorgenommenen Laufwerkzuordnungen sich von jenen unterscheiden, die auf eine Weise angefordert wurden, die verhindert, dass irgendein Laufwerk, das in dem Laufwerkzuordnungsattribut aufgelistet ist, zugeordnet wird. In dem Porterfassungsschritt 178 vergleicht entsprechend der dritte Abfrageschritt 194 vorher erfolgte Portzuordnungen mit jenen, die in dem Druckerportattribut der Anwendung aufgelistet sind. In dem Serveranschlussschritt 182 findet allerdings typischerweise der dritte Abfrageschritt 194 keinen Fehler, da Desktops 52 gleichzeitig an mehr als einen Server 14 angeschlossen sein können.
Wenn die Ressource vorher beansprucht wurde, und die vorherige Beanspruchung mit den Anforderungen der nunmehr gestarteten Anwendung 23 verträglich ist, inkrementiert ein Inkrementierungsschritt 198 einen Benutzungszähler, der innerhalb des Starters 50 aufrechterhalten wird. Daher werden Ressourcen nur so häufig wie nötig von dem Starter 50 in Bezug auf Anwendungen 23 beansprucht. Insbesondere werden unnötige, mehrfache Anschlüsse an demselben Server 14 vermieden. Während des Aufräumschrittes 154 (Fig. 8) wird der Benutzungszählwert dekrementiert, es sei denn, daß das Flag-Attribut etwas anderes anzeigt. Die Ressource wird nur dann freigegeben, wenn der Benutzungszählwert den Wert Null erreicht.
In Bezug auf sämtliche Figuren umfasst die vorliegende Erfindung ebenfalls ein computerlesbares Speichermedium in Kombination mit der speziellen physikalischen Konfiguration eines Substrats des computerlesbaren Speichermediums. Die Substratkonfiguration repräsentiert Daten und Befehle, welche die Computer 14 und 16 dazu veranlassen, auf die hier beschriebene, spezifische und vorbestimmte Art und Weise zu arbeiten. Geeignete Speichergeräte umfassen Floppy-Disks, Festplatten, Bänder, CD-ROMs, RAM, und andere Medien 11 (Fig. 1), die von einem oder mehreren der Computer 14, 16 gelesen werden können. Jedes derartige Medium verwirklicht fühlbar ein Programm, Funktionen, und/oder Befehle, die von den Maschinen 14 und/oder 16 ausführbar sind, um Anwendungsverwaltungsschritte gemäß der vorliegenden Erfindung durchzuführen, im wesentlichen wie hier beschrieben.
Zusammengefaßt, wie in Fig. 2 dargestellt, stellt die vorliegende Erfindung ein computerimplementiertes Verfahren zum Starten von Anwendungsprogrammen in einem Netzwerk zur Verfügung, und zur konsistenten Verfolgung und Verwendung von Information über Anwendungsprogramme 23 und ihre Ausführungsumgebungen in dem Netzwerk 10. Konsistenz wird dadurch erzielt, dass die Ausführungsumgebungsinformation in den Anwendungsobjekten 49 und den Desktop-Objekten 51 in der Datenbank 38 gesammelt wird, und durch Routing von Zugriffen auf die Datenbank 38 durch speziell ausgebildete Werkzeuge, beispielsweise die NWAdmin-Einschnappeinrichtung 54, die Schnittstelle des Desktops 52, und den Anwendungsstarter 50. Aktualisierungen und Auffrischungen der Datenbank 38 und des Desktops 52 werden mit den Anwendungsverwaltungsroutinen 58 und dem Anwendungsstarter 50 durchgeführt, wodurch die Anwendungen verringert werden, die bei Änderungen des Ortes ausführbarer Codes des Programms 23 auftreten, oder bei Änderungen anderer Informationen, die zur Ausführungsform der Anwendungen 23 erforderlich sind.

Claims

1. Verfahren zum Betreiben eines Datenverarbeitungssystems zum Starten eines Anwendungsprogramms (23) in einem Computernetzwerk (10) mit Netzwerkressourcen (22), die zentral von einem Verzeichnisdienst (24) verwaltet werden, der eine hierarchische, synchronisierte Partitionsdatenbank aufweist, die durch ein Schema (28, 32) definiert ist, wobei der Verzeichnisdienst zum Verwalten des Ortes von Ressourcen in dem Netzwerk und der Rechte von Netzwerkbenutzern zur Benutzung der Ressourcen einschliesslich ausführbaren Codes von Anwendungsprogrammen dient, und das Computernetzwerk zumindest einen Dateiserver (14) und zumindest eine Benutzerstation (16) mit einem Desktop (52) aufweist,

wobei das Schema eine Anwendungsobjektklasse zum Definieren verfügbarer Anwendungsprogrammressourcen in dem Netzwerk aufweist, und die Datenbankanwendungsobjekte (49, 51, 53) enthält, die jeweils ein Anwendungsprogramm repräsentieren und mehrere Attribute (91-120) aufweisen, die gesammelte Information in Bezug auf das Anwendungsprogramm oder zu dessen Ausführung aufweisen, wobei die mehreren Attribute ein gemeinsames Namensattribut (128) umfassen, dessen Wert ein kurzer Identifikator des Anwendungsprogramms (98, 106) ist, und ein Dateipfadattribut (100), dessen Wert zumindest ein Dateipfad sein kann, der einen Ort auf einem Dateiserver (14) des ausführbaren Codes der Anwendung angibt, und das Schema die Erzeugung, Löschung und Änderung von Anwendungsobjekten unterstützt; wobei das Verfahren folgende Schritte umfasst:

Reagieren auf die Auswahl einer Anwendung durch den Benutzer durch Zugriff auf ein Anwendungsobjekt (49, 51, 53) in der Datenbank unter Verwendung des kurzen Identifikators;

Reagieren auf einen wahlweisen Benutzerbefehl oder ein Ereignis durch Anzeige des Wertes zumindest eines Attributs des Anwendungsobjekts, auf welches zugegriffen wurde; und

Starten (150, 158) der vom Benutzer ausgewählten Anwendung unter Verwendung von Information, die während des Zugriffsschritts erhalten wurde.

2. Verfahren nach Anspruch 1, mit einem Schritt des Durchsuchens/Suchens (143) zumindest eines Teils der Datenbank.

3. Verfahren nach Anspruch 1, bei welchem weiterhin Konfigurationseinstellungen von einem Startkonfigurationsattribut (96) eines Objekts der Datenbank gelesen (139) werden.

4. Verfahren nach Anspruch 1, bei welchem der kurze Identifikator ein von dem Benutzer ausgewähltes Symbol ist, und der Startschritt (150, 158) eine Ressourceneinrichtungsroutine (162) umfasst, welche zumindest eine der folgenden Massnahmen umfasst:

Zuordnen eines Laufwerks (176),

Erfassen eines Druckerports (178); oder

Anschliessen an einen Server in dem Netzwerk (182).

5. Verfahren nach Anspruch 1, bei welchem dem Startschritt der Schritt der Ausführung eines Anfahrskripts vorausgeht, das sich unter den Attributen (108) des Anwendungsobjekts befindet.

6. Verfahren nach Anspruch 1, bei welchem auf den Startschritt der Schritt der Ausführung eines Herunterfahrskripts folgt, das sich unter den Attributen (110) des Anwendungsobjekts befindet.

7. Verfahren nach Anspruch 1, bei welchem die Anwendungsobjektattribute eine Befehlszeile zum Übergeben von Parametern an das Anwendungsprogramm (23) enthalten, und der Startschritt den Schritt der Übergabe (186) von Befehlszeilenparametern an die Anwendung enthält.

8. Verfahren nach Anspruch 1, bei welchem das Schema ein Automatikstartattribut umfasst, das als seinen Wert eine Liste von Anwendungsobjekten aufweist, die automatisch von dem Desktop (52) gestartet werden sollen.

9. Verfahren nach Anspruch 1, bei welchem das Anwendungsobjekt ein Flag-Attribut (104) definiert, das eine Liste von Anwendungseinstellungen enthält, die während des Startschritts verwendet werden sollen.

10. Verfahren nach Anspruch 1, bei welchem das Schema ein Desktop-Attribut (91) enthält, das eine Liste von Anwendungsobjekten enthält, deren Symbole automatisch von einem Desktop (52) angezeigt werden sollen.

11. Verfahren nach Anspruch 1, mit einem weiteren Symbolauffrischungsschritt (144) zur Feststellung von Änderungen bei Anwendungsobjekten in der Datenbank, und zur Anzeige der Änderungen an dem Desktop (52).

12. Computernetzwerkanwendungsobjekt (49) zum Starten eines Anwendungsprogramms (24) in einem Computernetzwerk (10), wobei das Computernetzwerk zumindest einen Dateiserver (14) und zumindest eine Benutzerstation (16) aufweist, die Benutzerstation einen Desktop (52) aufweist, auf das Anwendungsprogramm von dem Desktop zugegriffen werden kann, das Anwendungsobjekt mehrere Attribute (91-120) aufweist, jedes Attribut einen gemeinsamen Namen aufweist, eine Syntax und einen momentanen Wert, wobei die Syntax die Werte begrenzt, die von dem Attribut angenommen werden, die Attribute in einem Datenbankschema (28, 32) eines Verzeichnisdienstes definiert sind, der eine hierarchische, synchronisierte Partitionsdatenbank (38, 40) aufweist, der Verzeichnisdienst zum Verwalten der Orte von Resssourcen in dem Netzwerk und der Rechte von Netzwerkbenutzern zur Benutzung der Ressourcen einschliesslich vom Anwendungsprogramm ausführbaren Code dient, und das Schema die Erzeugung, Löschung, und Änderung von Anwendungsobjekten unterstützt, wobei die mehreren Attribute ein gemeinsames Namensattribut (128) umfassen, dessen Wert ein kurzer Identifikator des Anwendungsprogramms (98, 106) ist, sowie ein Dateipfadattribut (100), dessen Wert zumindest ein Dateipfad sein kann, der einen Ort auf einem Dateiserver (14) des ausführbaren Codes der Anwendung festlegt.

13. Computernetzwerkanwendungsobjekt nach Anspruch 12, bei welchem die mehreren Attribute Attribute umfassen, die zumindest eines der folgenden Attribute sind: ein Symbolattribut (98), ein Arbeitsverzeichnisattribut (102), ein Flag-Attribut (104), ein Werbetextattribut (106), ein Anfahrskriptattribut (108), ein Herunterfahrskriptattribut (110), ein Lizensierungsattribut (112), ein Befehlszeilenparameterattribut (114), ein Printerportattribut (118), ein Kontaktattribut (120), ein Handlerattribut, ein Suchkartenpfadattribut, ein Fängerattribut, oder ein Hinweisattribut.

14. Computernetzwerkanwendungsobjekt nach Anspruch 12, in Kombination mit einem Anwendungsfehlertoleranzobjekt (53) in dem Computernetzwerk (10), wobei das Anwendungsfehlertoleranzobjekt eine Liste enthält, die auf mehrere Anwendungsobjekte Bezug nimmt.

15. Computerprogrammprodukt, das auf einem von einem Computer benutzbaren Medium gespeichert ist, und eine Vorrichtung für einen von einem Computer lesbaren Programmcode aufweist, zum Starten eines Anwendungsprogramms (23) in einem Computernetzwerk (10), und beim Ablaufen in einem Computernetzwerk dazu ausgebildet ist, das in einem der Ansprüche 1 bis 11 beanspruchte Verfahren auszuführen.