DE19708281A1 - Fernausführungssystem mit Programmempfänger - Google Patents

Description

Die Erfindung betrifft ein Fernausführungssystem mit ei­ nem Programmempfänger.

Ein herkömmliches Fernausführungssystem mit einem Pro­ grammempfänger (im folgenden als "Server-System" bezeichnet) befindet sich an einem entfernten Standort und wird zum Aus­ führen einer angeforderten Verarbeitung verwendet, z. B. ge­ mäß "UNIX Network Programming", Kapitel 14, Juli 1992.

Ein Beispiel für ein herkömmliches Fernausführungssystem dieser Art zeigt Fig. 2, in der ein Server-System 351 einen Ausführungssteuerabschnitt 352 und einen Befehlsausführungs­ abschnitt 353 aufweist.

Der Ausführungssteuerabschnitt 352 kann UNIX-Befehle während einer Fernausführung steuern, und der Befehlsausfüh­ rungsabschnitt 353 kann die UNIX-Befehle ausführen, die von einem Client-System C1 als Anforderungssendequelle gesendet werden. Wenngleich in Fig. 2 nur ein Client-System C1 gezeigt ist, sind gewöhnlich mehrere Client-Systeme C1 bis Ck (k ist eine positive Ganzzahl) mit dem Server-System 351 verbunden.

Fig. 3 zeigt ein herkömmliches Agent-System mit einer Delegierungsvorrichtung (im folgenden als "Agent-System" be­ zeichnet) in einem Netzwerk-Management, auf das das vorge­ nannte Fernausführungssystem mit einem Programmempfänger an­ gewendet ist, z. B. gemäß der Offenbarung in "Network Manage­ ment by Delegation. The MAD Approach", German Goldszmidt et al., IBM Research Report, RC 17256 (#76343), April 1991. Die­ ses Agent-System wird zur Senkung der Kommunikationskosten zwischen Manager-Systemen und Agent-Systemen sowie der Bela­ stung der Manager-Systeme in einem zentralisierten Netzwerk- Management verwendet, das auf herkömmliche Weise erfolgt.

In Fig. 3 weist das herkömmliche Agent-System 3601 auf:
einen Agent-Kernel 3602, delegierte Management-Prozeßinstan­ zen (im folgenden "DMIP′s" genannt) D1 und D2 zum Implemen­ tieren von Scripts von Management-Tasks, die durch das Agent- System 3601 auszuführen sind (delegierte Management-Programme (im folgenden als "DMP′s" bezeichnet)), sowie "gemanagete" bzw. verwaltete Objektressourcensteuerungen CO1, CO2 und CO3, die mit "gemanageten" bzw. verwalteten Objektressourcen O1, O2 und O3 verbunden sind. Obgleich in diesem Fall zwei DMPI′s D1 und D2, drei verwaltete Objektressourcensteuerungen CO1, CO2 und CO3 sowie drei verwaltete Objektressourcen O1, O2 und O3 in Fig. 3 gezeigt sind, sind strenggenommen mehrere DMPI′s D1 bis Dk, mehrere verwaltete Objektressourcensteuerungen CO1 bis Com (m ist eine positive Ganzzahl) und mehrere verwaltete Objektressourcen O1 bis Om vorhanden.

Die DMPI′s D1 und D2 führen die in den DMP′s beschriebe­ nen Management-Tasks durch. Die verwalteten Objektressourcen­ steuerungen CO1, CO2 und CO3 bilden Einrichtungen zum Zugriff auf die eigentlichen verwalteten Objektressourcen O1, O2 und O3. Der Agent-Kernel bildet ein Delegierungssystem und weist auf: eine Delegierungsprotokoll-Verarbeitungseinrichtung 3603, einen Delegierungsinformationsspeicher 3604, einen DMP- Konverter 3605, eine Steuereinrichtung 3606, eine DMPI-Steue­ rung 3607, eine Schedule-Steuerung 3608, einen Namensbestim­ mer 3609 und einen Interprozeß-Kommunikator 3610.

Die Delegierungsprotokoll-Verarbeitungseinrichtung 3603 empfängt die DMP′s und DMPI-Steuerbefehle, die von Manager- Systemen M1, M2 und M3 gesendet werden, ermöglicht dem Dele­ gierungsinformationsspeicher 3604, die DMP′s zu speichern, und sendet die Ausführungsergebnisse der DMPI′s D1 und D2 so­ wie die Steuerbefehle zu den Manager-Systemen M1, M2 und M3. Wenngleich in Fig. 3 drei Manager-Systeme M1, M2 und M3 ge­ zeigt sind, können eigentlich mehrere Manager-Systeme M1 bis Mm verwendet werden. Die von den Manager-Systemen M1, M2 und M3 ausgegebenen DMP′s weisen Quellcodes, die in der Sprache C oder C++ geschrieben sind, sowie Objektcodes auf, die durch deren Kompilierung erhalten werden.

Die DMPI-Steuerung 3607 führt das eingegebene DMP als "Light-weight"-Prozeß durch, steuert die DMPI′s D1 und D2 und sendet die Operationsergebnisse der DMPI′s D1 und D2 zur De­ legierungsprotokoll-Verarbeitungseinrichtung 3603. Die DMPI- Steuerung 3607 kann Steuerbefehle, z. B. Anhalten bzw. Sus­ pendieren, Stopp und Wiederaufnahme, für die DMPI′s D1 und D2 ausführen.

Die Steuereinrichtung 3606 erzeugt alle Komponenten 3603 bis 3610 des Agent-Kernels 3602, um das Agent-System 3601 zu initialisieren, wenn das Agent-System in den Speicher geladen wird, initiiert die DMP′s, um sie ab Initiationszeit des Agent-System als die DMPI′s D1 und D2 auszuführen, führt die Nachverarbeitung durch, z. B. eine Freigabe des Speichers bei Abschluß des Agent-Systems 3601, und verwaltet das Agent-Sy­ stem selbst, z. B. das durch die Manager-Systeme M1, M2 und M3 angeforderte Verarbeitungsverfahren.

Der DMP-Konverter 3605 konvertiert die von den Manager- Systemen M1, M2 und M3 gesendeten DMP′s in ihre ausführbaren Codes. Das heißt, die in C oder C++ geschriebenen, eingegebe­ nen DMP′s werden in die ausführbaren Objektcodes unter Ver­ wendung eines Kompilierers oder Verknüpfers im DMP-Konverter 3605 konvertiert.

Bei den vorstehend beschriebenen bekannten Ansätzen be­ steht das erste Problem darin, daß es schwierig ist, eine Verarbeitungsfolge mit einer komplizierten Steuerkonfigurati­ on mit Verzweigungen und Wiederholungen auszuführen. Grund dafür ist, daß die bekannten Ansätze anstreben, UNIX-Befehle im Server-System auf die gleiche Weise wie jene auszuführen, die auf einer Shell bzw. Oberfläche als Schnittstelle zwi­ schen einem Benutzer und einem UNIX-Betriebssystem in einem Client-System erteilt werden.

Das zweite Problem ist, daß der Benutzer die Aufsätze und die praktische Verwendung des Server-Systems im voraus verstehen muß. Der Grund dafür ist folgender: Bei Ausführung des Befehls im Server-System gemäß Fig. 2 erzeugt der Be­ fehlsausführungsabschnitt 353 einen neuen UNIX-Prozeß, und dieser Prozeß wird die Shell zum Ablauf des angeforderten Be­ fehls. Hierbei wird der vom Client-System C1 gesendete Be­ fehlsname unverändert zur Shell weitergeleitet. Ist folglich ein solcher Befehl nicht in einem Befehlsabrufpfad vorhanden, kann keine Befehlsausführung erfolgen.

Bei Anwendung des vorgenannten herkömmlichen Fernausfüh­ rungssystems mit einem Programmempfänger auf ein Agent-System in einem Netzwerk-Management entsteht ferner das folgende dritte bis achte zu lösende Problem.

Das dritte Problem ist, daß ein Management-Informations­ speicher (im folgenden "MIS" genannt) im Agent-System 3601 von Fig. 2 nicht berücksichtigt ist. Grund ist, daß eine sy­ stemfreie Kommunikation (im folgenden "OSI" genannt) über­ haupt nicht berücksichtigt ist.

Das vierte Problem besteht darin, daß das Agent-System 3601 nicht mit einer gemeinsamen Management-Operationsein­ richtung für die verwalteten Objektressourcen O1, O2 und O3 versehen ist. Grund dafür ist, daß die verwalteten Objektres­ sourcensteuerungen CO1, CO2 und CO3 die Einrichtungen bilden, damit die DMPI′s D1 und D2 auf die eigentlichen verwalteten Objektressourcen O1, O2 und O3 zugreifen können, und den ver­ walteten Objektressourcen O1, O2 bzw. O3 entsprechen. Sind mehrere verwaltete Objektressourcen O1 bis Om vorhanden, so sind mehrere verwaltete Objektressourcensteuerungen CO1 bis COm so angeordnet, daß sie auf die jeweilige verwaltete Ob­ jektressource O1 bis Om direkt unter Verwendung jeweiliger Management-Operationsweisen zugreifen.

Das fünfte Problem ist, daß bei Beschreibung der DMP′s im Agent-System 3601 diese Beschreibung die Arbeit des Super­ visors erschwert. Grund ist, daß die DMPI′s D1 und D2 auf die notwendigen verwalteten Objektressourcensteuerungen CO1, CO2 und CO3 direkt zugreifen, und bei Zugriff auf mehrere verwal­ tete Objektressourcen O1, O2 und O3 muß sich die Beschreibung je nach den jeweiligen Management-Operationsweisen der ver­ walteten Objektressourcen O1, O2 und O3 ändern.

Das sechste Problem besteht darin, daß die Kommunika­ tionsmenge zwischen den Manager-Systemen M1, M2 und M3 und dem Agent-System 3601 enorm wird. Der Grund dafür ist folgen­ der: Da die DMP′s in C oder C++ geschrieben sind, müssen zum Konvertieren der DMP′s in die ausführbaren Formen die DMP′s kompiliert oder verknüpft werden. Werden jedoch die durch Kompilieren oder Verknüpfen der DMP′s in den Manager-Systemen M1, M2 und M3 erhaltenen ausführbaren Codes zum Agent-System 3601 gesendet, kann in dem Fall, in dem sich die Manager-Sy­ steme M1, M2 und M3 vom Agent-System 3601 in ihrer Architek­ tur unterscheiden, das Agent-System die Befehle nicht ausfüh­ ren. Folglich müssen die Manager-Systeme M1, M2 und M3 die in C oder C++ geschriebenen Quellcodes zum Agent-System 3601 senden.

Das siebente Problem ist, daß das Agent-System 3601 nicht flexibel die Management-Linien der Management-Standorte behandeln kann. Der Grund ist folgender: Die von den Manager- Systemen M1, M2 und M3 gesendeten DMP′s werden bald nach Kompilieren oder Verknüpfen im Agent-System 3601 ausgeführt. Es gibt nur zwei DMPI-Informationen, z. B. "Initiationszeit der DMPI′s" und "aktuelle Zustände der DMPI′s", und es gibt keinen Befehl für den Supervisor, um diese Informationen zu erhalten.

Das achte Problem besteht darin, daß das Agent-System 3601 nicht beurteilen kann, ob in Abhängigkeit von den Mana­ ger-Systemen M1, M2 und M3 zuzugreifen ist. Grund dafür ist, daß durch ein Zugriffsteuersystem die verwalteten Objektres­ sourcensteuerungen CO1, CO2 und CO3 nur auf die Attribute der verwalteten Objektressourcen O1, O2 und O3 zugreifen können, die durch die verwalteten Objektressourcensteuerungen CO1, CO2 und CO3 im Agent-System 3601 geöffnet sind.

Daher besteht angesichts der vorgenannten Probleme des Stands der Technik eine Aufgabe der Erfindung darin, ein Fernausführungssystem mit einem Programmempfänger (Server-Sy­ stem) bereitzustellen, durch das eine Fernausführung einer komplizierten Verarbeitung mit solchen Steuerkonfigurationen wie Verzweigungen und Wiederholungen im Server-System erfol­ gen kann, ein Benutzer nur einen Ablauf einer Verarbeitung ohne Berücksichtigung eines Aufbaus und von Aufsätzen des Server-Systems zu beschreiben braucht, um das Schreiben von Programmen zu vereinfachen, die Sicherheit des Server-Systems verbessert und die Kommunikationsmenge zwischen dem Server- System und einem Client-System verringert werden kann.

Eine weitere Aufgabe der Erfindung angesichts der vorge­ nannten Probleme des Stands der Technik besteht darin, ein Agent-System mit einer Delegierungsvorrichtung (Agent-System) bereitzustellen, das die Beschreibungseffizienz eines Script- Skeletons bzw. Script-Gerüsts verbessern kann, Programmen in Textform und ausführbaren, in Binärcodes oder Zwischencodes geschriebenen Programmen entsprechen kann, die Kommunika­ tionsmenge zwischen dem Agent-System und Manager-Systemen senken kann, eine genaue Script-Steuerung durchführen kann, um flexibel eine Script-Ausführung und managementseitige Ma­ nagement-Maßnahmen je nach Lastzustand des Agent-Systems zu handhaben, und eine flexible Zugriffsteuerung der Manager-Sy­ steme auf das Agent-System durchführen kann, um die Sicher­ heit des Agent-Systems zu verbessern.

Diese Aufgaben werden mit den Merkmalen der Ansprüche gelöst.

Durch die Merkmale von Anspruch 3 kann die Zugriffsteue­ rung in Abhängigkeit vom Client-Systemnamen mit verbesserter Sicherheit des Server-Systems erfolgen.

Mit dem System nach Anspruch 5 kann der Benutzer das Programm unabhängig von den Aufsätzen jedes Server-Systems beschreiben, und das Schreiben von Programmen läßt sich ver­ einfachen.

Das System nach Anspruch 13 führt zu einer verbesserten Flexibilität des Delegierungsausführungsabschnitts.

Die Aufgaben, Merkmale und Vorteile der Erfindung gehen aus der nachfolgenden näheren Beschreibung in Verbindung mit den beigefügten Zeichnungen deutlicher hervor. Es zeigen:

Fig. 1 ein Blockschaltbild eines Fernausführungssystems mit einem Programmempfänger (Server-System) gemäß einer er­ sten Ausführungsform der Erfindung;

Fig. 2 ein Blockschaltbild eines herkömmlichen Fernaus­ führungssystems mit einem Programmempfänger;

Fig. 3 ein Blockschaltbild eines herkömmlichen Agent-Sy­ stems mit einer Delegierungsvorrichtung;

Fig. 4 einen Ablaufplan einer Verarbeitung eines Pro­ grammempfängers von Fig. 1;

Fig. 5 einen Ablaufplan einer Verarbeitung eines dynami­ schen Bindungsabschnitts von Fig. 1;

Fig. 6 einen Ablaufplan einer Verarbeitung eines Pro­ grammausführungsabschnitts von Fig. 1;

Fig. 7 eine schematische Darstellung eines Beispiels für Namen verknüpfbarer spezifischer Operationsobjekte, die zum Verknüpfen mit Client-Systemen berechtigt sind und in einem Programmausführungs-Informationsspeicher von Fig. 1 zu spei­ chern sind;

Fig. 8 eine schematische Darstellung eines Formats einer Meldung, die von einem Server-System zu Client-Systemen in der Erfindung zu senden ist;

Fig. 9 ein Blockschaltbild eines Fernausführungssystems mit einem Programmempfänger (Server-System) gemäß einer zwei­ ten Ausführungsform der Erfindung;

Fig. 10 einen Ablaufplan einer Verarbeitung eines Pro­ grammempfängers von Fig. 9;

Fig. 11 einen Ablaufplan einer Verarbeitung einer Zu­ griffsteuerung von Fig. 9;

Fig. 12 eine schematische Darstellung eines Beispiels für eine Liste von Namen von Client-Systemen, die in einem Programmausführungs-Informationsspeicher von Fig. 9 zu spei­ chern ist;

Fig. 13 ein Blockschaltbild eines Fernausführungssystems mit einem Programmempfänger (Server-System) gemäß einer drit­ ten Ausführungsform der Erfindung;

Fig. 14 einen Ablaufplan einer Verarbeitung eines Pro­ grammempfängers von Fig. 13;

Fig. 15 einen Ablaufplan einer Verarbeitung eines Pro­ grammkonverters von Fig. 13;

Fig. 16 eine schematische Darstellung einer Entspre­ chungsliste für spezifischen Operationsobjekte, die in einem Programmausführungs-Informationsspeicher von Fig. 13 zu spei­ chern ist;

Fig. 17 einen Ablaufplan einer Verarbeitung eines Pro­ grammempfängers eines Fernausführungssystems mit einem Pro­ grammempfänger (Server-System) gemäß einer vierten Ausfüh­ rungsform der Erfindung;

Fig. 18 ein Blockschaltbild eines Fernausführungssystems mit einem Programmempfänger (Server-System) gemäß einer fünf­ ten Ausführungsform der Erfindung;

Fig. 19 einen Ablaufplan einer Verarbeitung einer Zu­ griffsteuerung von Fig. 18;

Fig. 20 einen Ablaufplan einer Verarbeitung eines Pro­ grammkonverters von Fig. 18;

Fig. 21 einen Ablaufplan einer Verarbeitung eines Pro­ grammempfängers eines Fernausführungssystems mit einem Pro­ grammempfänger (Server-System) gemäß einer sechsten Ausfüh­ rungsform der Erfindung;

Fig. 22 ein Blockschaltbild eines Agent-Systems mit ei­ ner Delegierungsvorrichtung gemäß einer siebenten Ausfüh­ rungsform der Erfindung, auf das ein Fernausführungssystem mit einem Programmempfänger der Erfindung in einem Netzwerk- Management angewendet wird;

Fig. 23 einen Ablaufplan einer Verarbeitung einer Dele­ gierungsprotokoll-Verarbeitungseinrichtung von Fig. 22;

Fig. 24 einen Ablaufplan einer Verarbeitung einer Zu­ griffsteuerung von Fig. 22;

Fig. 25 einen Ablaufplan einer Verarbeitung eines Anfor­ derungsanalysators von Fig. 22;

Fig. 26 einen Ablaufplan einer Verarbeitung einer Script-Steuerung von Fig. 22;

Fig. 27 einen Ablaufplan einer Verarbeitung eines Script-Konverters von Fig. 22;

Fig. 28 eine schematische Darstellung eines Formats ei­ ner von einem Manager-System zu einem Agent-System von Fig. 22 zu sendenden Meldung;

Fig. 29 eine schematische Darstellung eines Formats ei­ ner von einem Agent-System zu Manager-Systemen von Fig. 22 zu sendenden Meldung;

Fig. 30 eine schematische Darstellung eines Beispiels für eine Manager-Systemnamensliste, die in einem Delegie­ rungsinformationsspeicher von Fig. 22 zu speichern ist;

Fig. 31 eine schematische Darstellung eines Beispiels für eine Management-Operationsberechtigungsliste, die im De­ legierungsinformationsspeicher von Fig. 22 zu speichern ist;

Fig. 32 eine schematische Darstellung eines Beispiels für eine Entsprechungsliste für spezifische verwaltete Objek­ te, die im Delegierungsinformationsspeicher von Fig. 22 zu speichern ist;

Fig. 33 eine schematische Darstellung eines Beispiels für eine Entsprechungsliste für spezifische verwaltete Grund­ elemente, die im Delegierungsinformationsspeicher von Fig. 22 zu speichern ist;

Fig. 34 ein Blockschaltbild eines Agent-Systems mit ei­ ner Delegierungsvorrichtung gemäß einer achten Ausführungs­ form der Erfindung, auf das ein Fernausführungssystem mit ei­ nem Programmempfänger der Erfindung in einem Netzwerk-Manage­ ment angewendet wird;

Fig. 35 einen Ablaufplan einer Verarbeitung eines Script-Konverters eines Delegierungsausführungsabschnitts von Fig. 34; und

Fig. 36 eine schematische Darstellung eines Beispiels für eine Entsprechungsliste für verwaltete Grundelemente, die in einem Delegierungsinformationsspeicher des Delegierungs­ ausführungsabschnitts von Fig. 34 zu speichern ist.

In den Zeichnungen, in denen gleiche Bezugszeichen durchweg gleiche oder entsprechende Teile in den mehreren An­ sichten bezeichnen, weshalb der Kürze halber auf ihre wieder­ holte Beschreibung verzichtet werden kann, zeigt Fig. 1 ein Fernausführungssystem mit einem Programmempfänger (im folgen­ den "Server-System" genannt) gemäß einer ersten Ausführungs­ form der Erfindung.

In Fig. 1 weist das Server-System 1 einen Programmemp­ fänger 2, einen dynamischen Bindungsabschnitt 3, einen Pro­ grammausführungsabschnitt 4 und einen Programmausführungs-In­ formationsspeicher 5 auf.

Der Programmempfänger 2 empfängt von Client-Systemen C1, C2 und C3 gesendete Programme und sendet die Ausführungser­ gebnisse der Programme. Die Programme sind in Binärcodes ge­ schrieben, so daß sie durch das Server-System 1 sofort aus­ führbar sind, oder in Zwischencodes unabhängig von Architek­ turen von Servern. Obwohl nur drei Client-Systeme C1, C2 und C3 in Fig. 1 gezeigt sind, können eigentlich mehrere Client- Systeme C1 bis Ck mit dem Server-System 1 verbunden sein. Der Programmausführungsabschnitt 4 implementiert die Programme.

Der Programmausführungs-Informationsspeicher 5 speichert Programme, Verknüpfungssteuerinformationen und spezifische Operationsobjekte. Die Verknüpfungssteuerinformationen weisen eine Tabelle verknüpfbarer spezifischer Operationsobjekte für die Client-Systeme C1, C2 und C3 zur Ausführungszeit auf (im folgenden als "Verknüpfungsberechtigungstabelle" bezeichnet). Ein Beispiel für die Verknüpfungsberechtigungstabelle ist in Fig. 7 gezeigt, in der ein Feld 51 für Client-Systemnamen ("clientA, "clientB", "clientC", . . .) Namen von Client-Syste­ men enthält, die auf das Server-System 1 zugreifen können, und ein Feld 52 für Namen spezifischer Operationsobjekte Na­ men ("readfp", "writefp", "getfp", . . .) verknüpfbarer spezi­ fischer Operationsobjekte für die Client-Systeme C1, C2 und C3 im Server-System 1 enthält.

Der dynamische Bindungsabschnitt 3 weist einen Verknüp­ fungsberechtigungsprüfer 6 und einen Verknüpfer 7 für spezi­ fische Operationsobjekte auf. Der Verknüpfungsberechtigungsprüfer 6 prüft, ob die Client-Systeme C1, C2 und C3 berech­ tigt sind, die spezifischen Operationsobjekte entsprechend den Prozeßoperationsnamen in den Programmen zu verknüpfen, die von den Client-Systemen C1, C2 und C3 gesendet werden. Der Verknüpfer 7 für spezifische Operationsobjekte verknüpft die spezifischen Operationsobjekte entsprechend den Prozeß­ operationsnamen in den Programmen.

Fig. 4 bis Fig. 6 veranschaulichen die Verarbeitungen des Programmempfängers 2, des dynamischen Bindungsabschnitts 3 und des Programmausführungsabschnitts 4.

Gemäß Fig. 4 weist die Verarbeitung des Programmempfän­ gers 2 auf: einen Schritt S201 zum Erfassen des Client-Sy­ stemnamens, einen Schritt S202 zum Speichern des Programms, einen Schritt S203 zum Senden des Client-Systemnamens, einen Schritt S204 zum Unterscheiden des Ergebnisempfangs und einen Schritt S205 zum Senden des Ergebnisses.

In Fig. 5 weist die Verarbeitung des dynamischen Bin­ dungsabschnitts 3 auf: einen Schritt S301 zum Empfangen des Client-Systemnamens, einen Schritt S302 zum Unterscheiden der Verknüpfbarkeit spezifischer Operationsobjekte, einen Schritt S303 zum dynamischen Verknüpfen spezifischer Operationsob­ jekte, einen Schritt S304 zum Senden des Programmausführungs­ auftrags und einen Schritt S305 zum Senden von "spezifische Operationsobjekte nicht verknüpfbar".

Gemäß Fig. 6 weist die Verarbeitung des Programmausfüh­ rungsabschnitts 4 auf: einen Schritt S401 zum Empfangen der Programmausführungsanforderung, einen Schritt S402 zur Pro­ grammausführung und einen Schritt S403 zum Senden des Ausfüh­ rungsergebnisses.

Im folgenden wird der Betrieb des vorstehend beschriebe­ nen Server-Systems gemäß der ersten Ausführungsform der Er­ findung anhand von Fig. 1 sowie 4 bis 6 beschrieben.

Unter der Annahme, daß der Programmempfänger 2 ein Pro­ gramm vom Client-System C1 empfängt, beginnt der Programmemp­ fänger 2 die Verarbeitung gemäß Fig. 4. Zunächst erfaßt im Schritt S201 der Programmempfänger 2 die Namen der Client-Sy­ steme, von denen Verbindungen mit dem Programmempfänger 2 hergestellt wurden. Anschließend speichert der Programmemp­ fänger 2 im Schritt S202 das vom Client-System C1 empfangene Programm im Programmausführungs-Informationsspeicher 5. Im Schritt S203 sendet der Programmempfänger 2 die erfaßten Na­ men der Client-Systeme zum dynamischen Bindungsabschnitt 3. Anschließend wartet im Schritt S204 der Programmempfänger 2 die Verarbeitungsergebnisse der anderen Komponenten ab.

Danach beginnt der dynamische Bindungsabschnitt 3 die Verarbeitung gemäß Fig. 5. Zunächst empfängt im dynamischen Bindungsabschnitt 3 der Verknüpfungsberechtigungsprüfer 6 im Schritt S301 die Client-Systemnamen vom Programmempfänger 2. Anschließend prüft der Verknüpfungsberechtigungsprüfer 6 im Schritt S302, ob das Client-System C1 berechtigt ist, die spezifischen Operationsobjekte unter Verwendung der Verknüp­ fungsberechtigungstabelle (siehe Fig. 7) zu verknüpfen, die im Programmausführungs-Informationsabschnitt 5 gespeichert ist. Das heißt, der Verknüpfungsberechtigungsprüfer 6 erfaßt alle verknüpfbaren spezifischen Operationsobjektnamen aus der Verknüpfungsberechtigungstabelle unter Verwendung der Client- Systemnamen als Schlüssel und prüft, ob die angeforderten spezifischen Operationsobjektnamen in allen verknüpfbaren spezifischen Operationsobjektnamen vorhanden sind.

Ist als Ergebnis des Schritts S302 das Client-System C1 nicht verknüpfungsberechtigt, beurteilt der dynamische Bin­ dungsabschnitt 3, daß die spezifischen Operationsobjekte nicht verknüpft werden können, und sendet dieses Ergebnis im Schritt S305 zum Programmempfänger 2. Bei Empfang dieses Er­ gebnisses vom Verknüpfungsberechtigungsprüfer 6 sendet der Programmempfänger 2 im Schritt S205 eine Meldung über die Un­ verknüpfbarkeit der spezifischen Operationsobjekte zum Cli­ ent-System C1.

Kann andererseits im dynamischen Bindungssystem 3 als Ergebnis des Schritts S302 das Client-System alle spezifi­ schen Operationsobjekte verknüpfen, verknüpft der Verknüpfer 7 für spezifische Operationsobjekte dynamisch die spezifi­ schen Operationsobjekte entsprechend den Prozeßoperationsna­ men innerhalb des Programms im Schritt S303. Anschließend sendet der Verknüpfungsberechtigungsprüfer 6 im Schritt S304 einen Programmausführungsauftrag zum Programmausführungsab­ schnitt 4.

Danach startet der Programmausführungsabschnitt 4 die Verarbeitung gemäß Fig. 6. Zunächst empfängt im Schritt S401 der Programmausführungsabschnitt 4 den Programmausführungs­ auftrag vom dynamischen Bindungsabschnitt 3 und führt im Schritt S402 das im Programmausführungs-Informationsspeicher 5 gespeicherte Programm aus. Anschließend sendet der Pro­ grammausführungsabschnitt 4 im Schritt S403 das Programmaus­ führungsergebnis zum Programmempfänger 2. Bei Empfang des Programmausführungsergebnisses vom Programmausführungsab­ schnitt 4 sendet der Programmempfänger 2 im Schritt S205 das Programmausführungsergebnis zum Client-System C1.

Fig. 8 zeigt ein Format einer Meldung, die vom Server- System 1 zu den Client-Systemen C1, C2 und C3 zu senden ist. In Fig. 8 enthält ein Ergebnisfeld 61 ein Programmausfüh­ rungsergebnis, d. h., entweder "0 (Erfolg)" oder "1 (Mißer­ folg"). Ein detaillierteres Ergebnisfeld 62 enthält detail­ liertere Informationen, z. B. "1 (Unverknüpfbarkeit spezifi­ scher Operationsobjekte)" oder "2 (andere Fehler)", wenn das Ergebnisfeld 61 "1 (Mißerfolg)" enthält. Enthält das Ergeb­ nisfeld 61 "0 (Erfolg)", so enthält das detailliertere Ergeb­ nisfeld 62 "0". Ein Feld 64 für das Programmausführungsergeb­ nis enthält das Ausführungsergebnis des Programms.

Im folgenden wird ein Server-System gemäß einer zweiten Ausführungsform der Erfindung gemäß Fig. 9 näher beschrieben.

In Fig. 9 hat das Server-System 1 einen ähnlichen Aufbau wie in der ersten Ausführungsform von Fig. 1 mit der Ausnah­ me, daß das Server-System 1 ferner eine Zugriffsteuerung 71 aufweist. Die Zugriffsteuerung 71 prüft, ob die Client-Sy­ steme auf das Server-System 1 zugreifen können. Außerdem weist der Programmausführungs-Informationsspeicher 5 zusätz­ lich eine Liste von Namen von Client-Systemen auf, die auf das Server-System zugreifen können und für die Zugriffsteue­ rung 71 verwendet werden (im folgenden als "Client-Systemna­ mensliste" bezeichnet). Ein Beispiel für die Client-Systemna­ mensliste zeigt Fig. 12, in der eine Feld 101 für Namen von Client-Systemen mit Zugriffserlaubnis Client-Systemnamen ("clientA", "clientB", "clientC", . . .) enthält, für die der Zugriff auf das Server-System erlaubt ist.

Fig. 10 zeigt eine Verarbeitung des Programmempfängers 2 mit einem Schritt S801 zum Erfassen des Client-Systemnamens, einem Schritt S802 zum Senden des Client-Systemnamens und des Programms, einem Schritt S803 zum Unterscheiden des Ergebnis­ empfangs und einem Schritt S804 zum Senden des Ergebnisses.

Fig. 11 zeigt eine Verarbeitung der Zugriffsteuerung 71 mit einem Schritt S901 zum Empfangen des Client-Systemnamens und des Programms, einem Schritt S902 zum Unterscheiden der Zugriffserlaubnis, einem Schritt S903 zum Speichern des Pro­ gramms und einem Schritt S905 zum Senden von "Zugriff unmög­ lich".

Als nächstes wird der Betrieb des vorstehend beschriebe­ nen Server-Systems gemäß der zweiten Ausführungsform der Er­ findung anhand von Fig. 9 bis 12 beschrieben.

Unter der Annahme, daß der Programmempfänger 2 ein Pro­ gramm vom Client-System C1 empfängt, startet der Programmemp­ fänger 2 die Verarbeitung gemäß Fig. 10. Zunächst erfaßt der Programmempfänger 2 im Schritt S801 die Namen der Client-Sy­ steme, von denen Verbindungen mit dem Programmempfänger 2 hergestellt wurden. Anschließend sendet der Programmempfänger 2 im Schritt S802 die erfaßten Namen der Client-Systeme und das Programm zur Zugriffsteuerung 71. Danach wartet der Pro­ grammempfänger 2 im Schritt S803 die Verarbeitungsergebnisse der anderen Komponenten ab.

Anschließend startet die Zugriffsteuerung 71 die Verar­ beitung gemäß Fig. 11. Zunächst empfängt die Zugriffsteuerung 71 im Schritt S901 die Client-Systemnamen und das Programm vom Programmempfänger 2. Danach bestimmt die Zugriffsteuerung 71 im Schritt S902, ob dem Client-System C1 der Zugriff auf das Server-System 1 zu erlauben ist. Das heißt, die Zugriff­ steuerung 71 durchsucht die Client-Systemnamensliste (siehe Fig. 12), die im Programmausführungs-Informationsspeicher 5 gespeichert ist, unter Verwendung der vom Programmspeicher 2 gesendeten Client-Systemnamen als Schlüssel, um den Namen des Client-Systems C1 auszulesen.

Wird als Ergebnis des Schritts S902 der Client-System­ name ausgelesen, beurteilt die Zugriffsteuerung 71 die Zu­ griffserlaubnis auf das Server-System 1 und sendet das Pro­ gramm zum Programmausführungs-Informationsspeicher 5 zum Speichern des Programms im Schritt S903. Danach sendet die Zugriffsteuerung 71 im Schritt S904 den Client-Systemnamen zum dynamischen Bindungsabschnitt 3.

Wird andererseits als Ergebnis des Schritts S902 der Client-Systemname nicht ausgelesen, sendet die Zugriffsteue­ rung 71 im Schritt S905 "Zugriff auf Server-System 1 unmög­ lich" zum Programmempfänger 2. Bei Empfang von "Zugriff un­ möglich" von der Zugriffsteuerung 71 sendet der Programmemp­ fänger 2 im Schritt S804 die Meldung "Zugriff auf Server-Sy­ stem 1 unmöglich" zum Client-System C1.

Anschließend werden der dynamische Bindungsabschnitt 3 und der Programmausführungsabschnitt 4 nacheinander auf die gleiche Weise wie in der zuvor gegebenen Beschreibung der er­ sten Ausführungsform anhand von Fig. 7 und 8 betrieben, wes­ halb der Kürze halber auf ihre Beschreibung verzichtet werden kann.

Ferner hat in dieser Ausführungsform ein vom Server-Sy­ stem 1 zu den Client-Systemen C1, C2 und C3 zu sendendes Mel­ dungsformat das gleiche Meldungsformat wie in der ersten Aus­ führungsform gemäß Fig. 8 mit der Ausnahme, daß das detail­ liertere Ergebnisfeld 62 "1 (Zugriff auf Server-System unmög­ lich)", "2 (Unverknüpfbarkeit spezifischer Operationsobjek­ te)" oder "3 (andere Fehler)" enthält.

Im Server-System der zweiten Ausführungsform ist neben der Verknüpfungsberechtigungssteuerung des dynamischen Bin­ dungsabschnitts 3 im Server-System der ersten Ausführungsform die Zugriffsteuerung 71 zum Steuern des Zugriffs der Client- Systeme C1, C2 und C3 auf das Server-System zugefügt, wodurch die Zugriffsteuerung in Abhängigkeit von den Client-Systemen C1, C2 und C3 wirksam durchgeführt werden kann. Als Ergebnis läßt sich die Sicherheit im Server-System verbessern.

Nachstehend wird ein Server-System gemäß einer dritten Ausführungsform der Erfindung anhand von Fig. 13 näher be­ schrieben.

In Fig. 13 hat das Server-System 1 einen ähnlichen Auf­ bau wie in der ersten Ausführungsform von Fig. 1 mit der Aus­ nahme, daß das Server-System 1 ferner einen Programmkonverter 111 aufweist. Der Programmkonverter 111 konvertiert abstrakte Operationsobjektnamen in spezifische Operationsobjektnamen und konvertiert gleichzeitig anstelle von Programmen, die in Binärcodes oder Zwischencodes geschrieben sind, die im Ser­ ver-System der ersten Ausführungsform verwendet werden, Pro­ gramme eines veränderlichen Texttyps in ausführbare Formen für das Server-System 1, z. B. durch Kompilieren.

Außerdem weist der Programmausführungs-Informationsspei­ cher 5 zusätzlich eine Entsprechungsliste zwischen abstrakten und spezifischen Operationsobjektnamen auf (im folgenden als "Entsprechungsliste für spezifische Operationsobjekte" be­ zeichnet). Ein Beispiel für die Entsprechungsliste für spezi­ fische Operationsobjekte zeigt Fig. 16, in der ein Namensfeld 141 für abstrakte Operationsobjekte Namen abstrakter Opera­ tionsobjekte enthält ("file_read", "file_write", . . .), und ein Namensfeld 142 für spezifische Operationsobjekte Namen spezifischer Operationsobjekte enthält (readfp", "writefp", . . .), die jeweils den vorgenannten abstrakten Objektnamen entsprechen.

Fig. 14 zeigt die Verarbeitung des Programmempfängers 2 mit einem Schritt S1201 zum Erfassen des Client-Systemnamens, einem Schritt S1202 zum Senden des Client-Systemnamens und des Programms, einem Schritt S1203 zum Unterscheiden des Er­ gebnisempfangs und einem Schritt S1204 zum Senden des Ergeb­ nisses.

Fig. 15 zeigt die Verarbeitung des Programmkonverters 111 mit einem Schritt S1301 zum Empfangen des Programms und des Client-Systemnamens, einem Schritt S1302 zum Konvertieren abstrakter in spezifische Operationsobjektnamen, einem Schritt S1303 zum Konvertieren des Programms in eine ausführ­ bare Form, einem Schritt S1304 zum Speichern des Programms und einem Schritt S1305 zum Senden des Client-Systemnamens.

Im folgenden wird der Betrieb des vorstehend beschriebe­ nen Server-Systems gemäß der dritten Ausführungsform der Er­ findung anhand von Fig. 13 bis 16 beschrieben.

Unter der Annahme, daß der Programmempfänger 2 ein Pro­ gramm vom Client-System C1 empfängt, startet der Programmemp­ fänger 2 die Verarbeitung gemäß Fig. 14. Zunächst erfaßt der Programmempfänger 2 im Schritt S1201 die Namen der Client-Sy­ steme, von denen Verbindungen mit dem Programmempfänger 2 hergestellt wurden. Anschließend sendet der Programmempfänger 2 im Schritt S1202 die erfaßten Namen der Client-Systeme und das Programm zum Programmkonverter 111. Danach wartet der Programmempfänger 2 im Schritt S1203 die Verarbeitungsergeb­ nisse der anderen Komponenten ab.

Im Anschluß daran startet der Programmkonverter 11 die Verarbeitung gemäß Fig. 15. Zunächst empfängt der Programm­ konverter im Schritt S1301 die Client-Systemnamen und das Programm vom Programmempfänger 2. Der Programmkonverter 111 konvertiert im Schritt S1302 die abstrakten Operationsobjekt­ namen in die spezifischen Operationsobjektnamen. Dies erfolgt unter Verwendung der Entsprechungsliste der spezifischen Ope­ rationsobjektnamen (siehe Fig. 16), die im Programmausfüh­ rungs-Informationsspeicher 5 gespeichert ist, um die abstrak­ ten Operationsobjektnamen in die spezifischen Operationsob­ jektnamen zu konvertieren. Danach konvertiert der Programm­ konverter 111 im Schritt S1303 das Programm in die ausführ­ bare Form, z. B. Binärcodes oder Zwischencodes, für das Ser­ ver-System 1, z. B. durch Kompilieren o. a. Anschließend sen­ det der Programmkonverter 111 das Programm aus Binärcodes oder Zwischencodes zum Programmausführungs-Informationsspei­ cher 5 zum Speichern des Programms im Schritt S1304. Danach sendet der Programmkonverter 111 im Schritt S1305 den Client- Systemnamen zum dynamischen Bindungsabschnitt 3, um das Script auszuführen.

Anschließend werden der dynamische Bindungsabschnitt 3 und der Programmausführungsabschnitt 4 nacheinander auf die gleiche Weise wie in der zuvor gegebenen Beschreibung der er­ sten Ausführungsform anhand von Fig. 7 und 8 betrieben, wes­ halb der Kürze halber auf ihre Beschreibung verzichtet werden kann.

Ferner hat in dieser Ausführungsform ein vom Server-Sy­ stem 1 zu den Client-Systemen C1, C2 und C3 zu sendendes Meldungsformat das gleiche Meldungsformat wie in Fig. 8 der er­ sten Ausführungsform.

Im Server-System der dritten Ausführungsform werden nicht die in den Binärcodes oder Zwischencodes für das Ser­ ver-System der ersten Ausführungsform geschriebenen Programme verwendet, sondern es können die in abstrakter Form, z. B. als Texttyp unabhängig vom Aufbau des Server-Systems, ge­ schriebenen Programme verwendet werden, und der Benutzer kann die Programme in abstrakten Ausdrücken unabhängig von den Server-Systemen schreiben. Dadurch vereinfacht sich das Schreiben von Programmen.

Im folgenden wird ein Server-System gemäß einer vierten Ausführungsform der Erfindung näher beschrieben.

In dieser Ausführungsform hat das Server-System 1 den gleichen Aufbau wie in der dritten Ausführungsform von Fig. 13. Allerdings kann der Programmkonverter 111 nicht nur die im Server-System der dritten Ausführungsform verwendeten Pro­ gramme vom Texttyp konvertieren, sondern auch Programme, die in den Binärcodes oder Zwischencodes geschrieben sind, die im Server-System der ersten Ausführungsform verwendet werden.

Fig. 17 veranschaulicht die Verarbeitung des Programm­ konverters 111 mit einem Schritt S1501 zum Empfangen des Pro­ gramms und des Client-Systemnamens, einem Schritt S1502 zum Unterscheiden eines Programms in Binärform, einem Schritt S1503 zum Konvertieren abstrakter in spezifische Operations­ objektnamen, einem Schritt S1504 zum Konvertieren des Pro­ gramms in eine ausführbare Form, einem Schritt S1505 zum Speichern des Programms und einem Schritt S1506 zum Senden des Client-Systemnamens.

Nachstehend wird der Betrieb des zuvor beschriebenen Server-Systems gemäß der vierten Ausführungsform der Erfin­ dung anhand von Fig. 17 beschrieben.

Der Unterschied im Betrieb der vierten Ausführungsform vom Betrieb der dritten Ausführungsform besteht darin, daß der Programmkonverter 111 den zuvor beschriebenen Betrieb ge­ mäß Fig. 17 durchführt. Nach dem Betrieb des Programmempfän­ gers 2 startet der Programmkonverter 111 die Verarbeitung ge­ mäß Fig. 17.

Zunächst empfängt im Schritt S1501 der Programmkonverter 111 das Programm und die Client-Systemnamen vom Programmemp­ fänger 2. Danach prüft der Programmkonverter 111 im Schritt S1502, ob das Programm in Binärcodes geschrieben ist. Ist als Ergebnis des Schritts S1502 das Programm in Textform ge­ schrieben, konvertiert der Programmkonverter 111 im Schritt S1503 die abstrakten Operationsobjektnamen in die spezifi­ schen Operationsobjektnamen unter Verwendung der Entspre­ chungsliste für spezifische Operationsobjekte (siehe Fig. 16), die im Programmausführungs-Informationsspeicher 5 ge­ speichert ist. Danach konvertiert der Programmkonverter 111 im Schritt S1504 das Programm in die ausführbare Form, z. B. Binärcodes oder Zwischencodes, für das Server-System 1, z. B. durch Kompilieren o. ä. Als nächstes sendet der Programmkon­ verter 111 das Programm aus den Binärcodes oder Zwischencodes zum Programmausführungs-Informationsspeicher 5 zum Speichern des Programms im Schritt S1505. Anschließend sendet der Pro­ grammkonverter 111 im Schritt S1506 den Client-Systemnamen zum dynamischen Bindungsabschnitt 3, um das Script auszufüh­ ren.

In dieser Ausführungsform hat ein vom Server-System 1 zu den Client-Systemen C1, C2 und C3 zu sendendes Meldungsformat das gleiche Meldungsformat wie in Fig. 8 der ersten Ausfüh­ rungsform.

Im Server-System der vierten Ausführungsform lassen sich neben den in der dritten Ausführungsform verwendeten Program­ men in Textform die in den Binärcodes und Zwischencodes ge­ schriebenen Programme verwenden, und alle Formen von Program­ men sind anwendbar. Dadurch läßt sich die Flexibilität in der Auswahl von Programmformen verbessern, die durch den Benutzer erstellt werden.

Im folgenden wird ein Server-System gemäß einer fünften Ausführungsform der Erfindung anhand von Fig. 18 näher be­ schrieben.

Gemäß Fig. 18 hat das Server-System 1 einen Aufbau, der sich aus einer Kombination der Server-Systeme der zweiten und dritten Ausführungsform zusammensetzt. Das heißt, in dieser Ausführungsform weist das Server-System 1 ferner eine Zu­ griffsteuerung 71 und einen Programmkonverter 111 zusätzlich zu allen Komponenten der ersten Ausführungsform auf.

Fig. 19 zeigt die Verarbeitung der Zugriffsteuerung 71 mit einem Schritt S1701 zum Empfangen des Client-Systemnamens und des Programms, einem Schritt S1702 zum Unterscheiden der Zugriffserlaubnis, einem Schritt S1703 zum Senden des Client- Systemnamens und des Programms und einem Schritt S1704 zum Senden von "Zugriff unmöglich".

Fig. 20 zeigt die Verarbeitung des Programmkonverters 111 mit einem Schritt S1801 zum Empfangen des Programms und des Client-Systemnamens, einem Schritt S1802 zum Konvertieren abstrakter in spezifische Operationsobjektnamen, einem Schritt S1803 zum Konvertieren des Programms in eine ausführ­ bare Form, einem Schritt S1804 zum Speichern des Programms und einem Schritt S1805 zum Senden des Client-Systemnamens.

Im folgenden wird der Betrieb des vorstehend beschriebe­ nen Server-Systems gemäß der fünften Ausführungsform der Er­ findung anhand von Fig. 18 bis 20 beschrieben.

Unter der Annahme, daß der Programmempfänger 2 ein Pro­ gramm vom Client-System C1 empfängt, startet der Programmemp­ fänger 2 die Verarbeitung gemäß Fig. 10, die nahezu die glei­ che wie in der zweiten Ausführungsform ist, weshalb ihre Be­ schreibung der Kürze halber entfallen kann. In dieser Ausfüh­ rungsform können Programme in Textform verarbeitet werden.

Danach startet die Zugriffsteuerung 71 die Verarbeitung gemäß Fig. 19. Zunächst empfängt die Zugriffsteuerung 71 im Schritt S1701 die Client-Systemnamen und das Programm vom Programmempfänger 2. Danach bestimmt die Zugriffsteuerung 71 im Schritt S1702, ob das Client-System C1 auf den Server 1 zugreifen darf. Die Verarbeitung im Schritt S1702 ist die gleiche wie im Schritt S902 von Fig. 11.

Wird im Schritt S1702 der Client-Systemname ausgelesen, beurteilt die Zugriffsteuerung 71 die Zugriffserlaubnis auf das Server-System 1 und sendet den Client-Systemnamen und das Programm zum Programmkonverter 111 im Schritt S1703.

Wird dagegen im Schritt S1702 der Client-Systemname nicht ausgelesen, sendet die Zugriffsteuerung 71 im Schritt S1704 "Zugriff auf Server-System 1 unmöglich" zum Programm­ empfänger 2. Bei Empfang von "Zugriff unmöglich" von der Zu­ griffsteuerung 71 sendet der Programmempfänger 2 die Meldung "Zugriff auf Server-System 1 unmöglich" im Schritt S804 zum Client-System C1.

Danach startet der Programmkonverter 111 die Verarbei­ tung gemäß Fig. 20. Die Verarbeitung in Fig. 20 ist die glei­ che wie die in Fig. 15 in der zweiten Ausführungsform mit der Ausnahme, daß der Programmkonverter 111 das Programm und den Client-Systemnamen von der Zugriffsteuerung 71 empfängt, wes­ halb ihre weitere Beschreibung der Kürze halber entfallen kann.

Anschließend werden der dynamische Bindungsabschnitt 3 und der Programmausführungsabschnitt 4 nacheinander auf die gleiche Weise wie in der zuvor anhand von Fig. 7 und 8 be­ schriebenen ersten Ausführungsform betrieben, weshalb der Kürze halber auf ihre Beschreibung verzichtet wird.

In dieser Ausführungsform hat ein vom Server-System 1 zu den Client-Systemen C1, C2 und C3 zu sendendes Meldungsformat das gleiche Meldungsformat wie in Fig. 8 der ersten Ausfüh­ rungsform.

Im Server-System der fünften Ausführungsform lassen sich die Vorteile der Server-Systeme der zweiten und dritten Aus­ führungsform erhalten. Das heißt, durch Zufügen der Zugriff­ steuerung 71 ergibt sich eine verbesserte Sicherheit, und durch Zufügen des Programmkonverters 111 kann der Benutzer Programme in abstrakten Ausdrücken unabhängig von den Server- Systemen mit dem Ergebnis schreiben, daß sich das Schreiben von Programmen vereinfacht.

Nunmehr wird ein Server-System gemäß einer sechsten Aus­ führungsform der Erfindung näher beschrieben.

In dieser Ausführungsform hat das Server-System 1 den gleichen Aufbau wie in der fünften Ausführungsform von Fig. 18. Obwohl der Programmkonverter 111 im Server-System der fünften Ausführungsform nur die Programme in Textform behan­ delt, kann in dieser Ausführungsform der Programmkonverter 111 nicht nur die Programme vom Texttyp, sondern auch die in den Binärcodes oder Zwischencodes geschriebenen Programme, d. h., alle Programmformen, verarbeiten.

Fig. 21 veranschaulicht die Verarbeitung des Programm­ konverters 111 mit einem Schritt S1901 zum Empfangen des Pro­ gramms und des Client-Systemnamens, einem Schritt S1902 zur Unterscheidung der Binärform des Programms, einem Schritt S1903 zum Konvertieren abstrakter in spezifische Operations­ objektnamen, einem Schritt S1904 zum Konvertieren des Pro­ gramms in die ausführbare Form und einem Schritt S1906 zum Senden des Client-Systemnamens.

Als nächstes wird der Betrieb des zuvor beschriebenen Server-Systems gemäß der sechsten Ausführungsform der Erfin­ dung anhand von Fig. 21 beschrieben.

Der Unterschied im Betrieb der sechsten Ausführungsform zum Betrieb der fünften Ausführungsform besteht darin, daß der Programmkonverter 111 den zuvor beschriebenen Betrieb ge­ mäß Fig. 21 durchführt. Außerdem ist die Verarbeitung von Fig. 21 die gleiche wie die in Fig. 17 in der zweiten Ausfüh­ rungsform mit der Ausnahme, daß der Programmkonverter 111 das Programm und den Client-Systemnamen von der Zugriffsteuerung 71 empfängt, weshalb ihre nähere Beschreibung der Kürze hal­ ber entfallen kann.

In dieser Ausführungsform hat ein vom Server-System 1 zu den Client-Systemen C1, C2 und C3 zu sendendes Meldungsformat das gleiche Meldungsformat wie in Fig. 8 der ersten Ausfüh­ rungsform.

Im Server-System der sechsten Ausführungsform lassen sich die Vorteile der Server-Systeme der vierten und fünften Ausführungsform erhalten. Das heißt, durch Zufügen der Zu­ griffsteuerung 71 ergibt sich eine verbesserte Sicherheit. Ferner kann der Programmkonverter 111 alle Programmformen verarbeiten, z. B. die Programme in Textform und die in den Binärcodes oder Zwischencodes geschriebenen Programme, wo­ durch sich die Flexibilität in der Auswahl der durch den Be­ nutzer erstellten Programmformen verbessern läßt.

Im folgenden wird ein Agent-System gemäß einer siebenten Ausführungsform der Erfindung näher beschrieben.

In Fig. 22 ist ein Agent-System mit einer Delegierungs­ vorrichtung (im folgenden "Agent-System" genannt) gemäß der siebenten Ausführungsform der Erfindung in einem Netzwerk-Ma­ nagement dargestellt, auf das ein Fernausführungssystem mit einem Programmempfänger (Server-System) Anwendung findet.

Gemäß Fig. 22 weist das Agent-System 201 auf: einen De­ legierungsausführungsabschnitt 202, einen Agent-Kern 203, ei­ nen Managementprotokoll-Verarbeitungsabschnitt 203, einen MIS (Management-Informationsspeicher) 205, ein laufendes bzw. Lauf-Script S1 (im Verlauf der Ausführung) und "gemanagete" bzw. verwaltete Objektressourcensteuerungen CO1, CO2 und CO3, die mit verwalteten Objektressourcen O1, O2 bzw. O3 gekoppelt sind. Obwohl in Fig. 22 ein Lauf-Script S1, drei verwaltete Objektressourcensteuerungen CO1, CO2 und CO3 sowie drei ver­ waltete Objektressourcen O1, O2 und O3 gezeigt sind, werden eigentlich mehrere Lauf-Scripts S1 bis Sk, mehrere verwaltete Objektressourcensteuerungen CO1 bis COm und mehrere verwal­ tete Objektressourcen O1 bis Om verwendet.

Der Agent-Kern 203 verwaltet den MIS 205, führt eine Operation zum MIS 205 und eine gemeinsame Management-Opera­ tion zu den verschiedenen verwalteten Objektressourcen O1, O2 und O3 und konvertiert die angeforderte Management-Operation in eine adaptive Form für die verwalteten Objektressourcen­ steuerungen CO1, CO2 und CO3, um die konvertierte Form zu den geeigneten verwalteten Objektressourcensteuerungen CO1, CO2 und CO3 zu senden.

Der Managementprotokoll-Verarbeitungsabschnitt 204 kon­ vertiert die Operationsanforderungen im Managementprotokoll in adaptive Formen für das Agent-System 201. Der MIS 205 speichert die verwalteten Objekte, die durch Abstrahieren der verwalteten Objektressourcen O1, O2 und O3 erzeugt werden. Die verwalteten Objektressourcensteuerungen CO1, CO2 und CO3 bilden Einrichtungen zum Zugriff auf die eigentlichen verwal­ teten Objektressourcen O1, O2 und O3.

Der Delegierungsausführungsabschnitt 202 weist eine De­ legierungsprotokoll-Verarbeitungseinrichtung 211, eine Zu­ griffsteuerung 212, einen Anforderungsanalysator 213, einen Script-Konverter 214, einen Delegierungsinformationsspeicher 215 und eine Script-Steuerung 216 auf.

Informationen, z. B. Meldungen, werden zwischen der De­ legierungsprotokoll-Verarbeitungseinrichtung 211 und Manager­ systemen M1, M2 und M3 übertragen. Obwohl in Fig. 22 nur drei Manager-Systeme M1, M2 und M3 gezeigt sind, sind strenggenom­ men mehrere Manager-Systeme M1 bis Mm mit der Delegierungs­ protokoll-Verarbeitungseinrichtung 211 gekoppelt. Die Zu­ griffsteuerung 212 bestimmt, ob es den Manager-Systemen M1, M2 und M3 erlaubt ist, als Reaktion auf ihre Anforderung auf das Agent-System 201 zuzugreifen. Der Anforderungsanalysator 213 analysiert die von den Manager-Systemen M1, M2 und M3 gesendeten Meldungen.

Der Script-Konverter 214 konvertiert Script-Gerüste in Scripts. Die Script-Gerüste sind in Textform, z. B. Quell­ codes, oder in sofort ausführbarer Form, z. B. Binärcodes oder Zwischencodes, für das Agent-System 201 geschrieben. Die Script-Steuerung 216 initiiert neue Scripts und steuert die Lauf-Scripts. Der Delegierungsinformationsspeicher 215 spei­ chert die Scripts, die Script-Informationen, die Zugriff­ steuerinformationen und die Script-Gerüstkonvertierungsinfor­ mationen.

Die Script-Informationen weisen auf: die "Script-Ken­ nung" zum einheitlichen Identifizieren der Scripts innerhalb des Agent-Systems 201, die "Namen der Manager-Systeme", die die Script-Gerüste senden, den "Zustand" zum Anzeigen der Zu­ stände der aktuellen Scripts mit drei Zuständen "Läuft", "Suspendiert" und "Ruht", die Inhalte und Zwecke der Script- Gerüste sowie den "Kommentar", der die Sendedaten zum Agent- System 201 beschreibt.

Zunächst weisen die Zugriffsteuerinformationen eine Li­ ste der Namen der Manager-Systeme auf, die auf das Agent-Sy­ stem 201 zugreifen können (im folgenden als "Manager-System­ namensliste" bezeichnet). Ein Beispiel für die Manager-Sy­ stemnamensliste zeigt Fig. 30, in der ein Feld 281 für Namen von Manager-Systemen mit Zugriffserlaubnis Manager-Systemna­ men enthält (z. B. "ManagerA", "ManagerB", "ManagerC"), die auf das Agent-System 201 zugreifen können.

Ferner weisen die Zugriffsteuerinformationen Zugriffsbe­ rechtigungen (nur Lesen möglich, Lesen-Schreiben möglich, Zu­ griff unmöglich) auf die spezifischen verwalteten Objekte im Hinblick auf die Manager-Systeme M1, M2 und M3 auf (im fol­ genden "Management-Operationsberechtigungsliste" genannt). Ein Beispiel für die Management-Operationsberechtigungsliste zeigt Fig. 31, in der ein Feld 291 für Manager-Namen die Na­ men der Manager-Systeme enthält, die auf das Agent-System 201 zugreifen können, und ein Feld 292 für spezifische verwaltete Objekte Namen ("moA", "moB", "moC", . . .) von spezifischen verwalteten Objekten im Agent-System 201 enthält. Die Manage­ ment-Vollmachten der Manager-Systeme, z. B. ManagerA, Mana­ gerB und ManagerC, gegenüber dem spezifischen verwalteten Ob­ jektname "moA" sind die Operationsvollmachten "read-write" (Lesen-Schreiben), "read-write" bzw. "not-access" (kein Zu­ griff) usw.

Die Script-Gerüstkonvertierungsinformationen weisen eine Entsprechungsliste zwischen den abstrakten und spezifischen verwalteten Objektnamen auf (im folgenden als "Entsprechungs­ liste für spezifische verwaltete Objekte" bezeichnet). Ein Beispiel für die Entsprechungsliste für spezifische verwal­ tete Objekte zeigt Fig. 32, in der ein Feld 302 für spezifi­ sche verwaltete Objektnamen die spezifischen verwalteten Ob­ jektnamen, z. B. "moA", "moB", "moC", . . ., im Agent-System 201 enthält, und ein Feld 301 für abstrakte verwaltete Ob­ jektnamen die abstrakten verwalteten Objektnamen, z. B. "netA.ne1", "netA.ne2", "netA.ne3", . . ., enthält, die den spezifischen verwalteten Objektnamen entsprechen.

Ferner weisen die Script-Gerüstkonvertierungsinformatio­ nen eine Entsprechungsliste zwischen abstrakten und spezifi­ schen verwalteten Grundelementnamen auf (im folgenden als "Entsprechungsliste für spezifische verwaltete Grundelemente" bezeichnet). Ein Beispiel für die Entsprechungsliste für spe­ zifische verwaltete Grundelemente zeigt Fig. 33, in der ein Feld 302 für spezifische verwaltete Grundelementnamen die spezifischen verwalteten Grundelementnamen enthält, z. B. "M-Get", "M-Set", "M-Create", "M-Delete", . . ., die tatsäch­ lich auf das Agent-System 201 aufgesetzt sind, und ein Feld 301 für abstrakte verwaltete Grundelementnamen die abstrakten verwalteten Grundelementnamen enthält, z. B. "getValue", "setValue", "createMO", "deleteMO", . . ., die den spezifischen verwalteten Grundelementnamen entsprechen.

Ferner speichert der Delegierungsinformationsspeicher 215 eine Gruppe spezifischer verwalteter Grundelemente.

Fig. 23 bis 27 sind Ablaufpläne von Verarbeitungen der Delegierungsprotokoll-Verarbeitungseinrichtung 211, der Zu­ griffsteuerung 212, des Anforderungsanalysators 213, der Script-Steuerung 216 und des Script-Konverters 214.

Gemäß Fig. 23 weist die Verarbeitung der Delegierungs­ protokoll-Verarbeitungseinrichtung 211 auf: einen Schritt S2101 zum Erfassen des Namens des Manager-Systems, einen Schritt S2102 zum Senden der empfangenen Meldung und des Ma­ nager-Namens, einen Schritt 2103 zum Unterscheiden des Ein­ treffens der Verarbeitungsergebnisse und einen Schritt S2104 zum Senden des Meldungsverarbeitungsergebnisses.

In Fig. 24 weist die Verarbeitung der Zugriffsteuerung 212 auf: einen Schritt S2201 zum Empfangen des Manager-Sy­ stemnamens und der empfangenen Meldung, einen Schritt S2202 zum Unterscheiden der Zugriffserlaubnis, einen Schritt S2203 zum Senden des Manager-Systemnamens und der empfangenen Mel­ dung und einen Schritt S2204 zum Senden von "Zugriff unmög­ lich".

Gemäß Fig. 25 weist die Verarbeitung des Anforderungs­ analysators 213 auf: einen Schritt S2301 zum Empfangen der empfangenen Meldung und des Manager-Systemnamens, einen Schritt S2302 zum Unterscheiden der Script-Erzeugung, einen Schritt S2303 zum Senden des Steuerbefehls, der Script-Ken­ nung und des Manager-Systemnamens und einen Schritt S2304 zum Senden des Kommentars, des Manager-Systemnamens, des Script- Gerüsts und des Steuerbefehls.

In Fig. 26 weist die Verarbeitung der Script-Steuerung 216 auf: einen Schritt S2401 zum Empfangen des Manager-Sy­ stemnamens, des Steuerbefehls und der Script-Kennung, einen Schritt S2402 zum Unterscheiden der Möglichkeit der Script- Steuerung, einen Schritt S2403 zum Unterscheiden des Starts der Script-Ausführung, einen Schritt S2404 zum Steuern des Scripts, einen Schritt S2405 zum dynamischen Verknüpfen der spezifischen verwalteten Grundelemente, einen Schritt S2406 zum Unterscheiden der Abweichung der Operationsberechtigung, einen Schritt S2407 zum Ausführen des angeforderten Scripts, einen Schritt S2408 zum Aktualisieren des Delegierungsinfor­ mationsspeichers, einen Schritt S2409 zum Senden des Steuer­ befehl-Ausführungsergebnisses, einen Schritt S2410 zum Senden von "Steuerung unmöglich" und einen Schritt S2411 zum Senden von "Zugriff auf spezifische verwaltete Objekte unmöglich".

Gemäß Fig. 27 weist die Verarbeitung des Script-Konver­ ters 214 auf: einen Schritt S2501 zum Empfangen des Manager- Systemnamens, des Script-Gerüsts, des Kommentars und des Steuerbefehls, einen Schritt S2502 zum Unterschieden des Bi­ närcodes des Script-Gerüsts, einen Schritt S2503 zum Konver­ tieren abstrakter in spezifische verwaltete Objektnamen, ei­ nen Schritt S2504 zum Konvertieren abstrakter in spezifische verwaltete Grundelementnamen, einen Schritt S2505 zum Unter­ scheiden der Abweichung der Operationsberechtigung, einen Schritt S2506 zum Konvertieren des Scripts in den ausführba­ ren Code, einen Schritt S2507 zum Speichern der Script-Infor­ mationen und des Scripts oder Script-Gerüsts, einen Schritt S2508 zum Unterscheiden der sofortigen Script-Ausführung, ei­ nen Schritt S2509 zum Senden des Steuerbefehl-Ausführungser­ gebnisses, einen Schritt S2510 zum Senden des Steuerbefehls "Start" und der Script-Kennung und einen Schritt S2511 zum Mitteilen von "Zugriff auf spezifische verwaltete Objekte unmöglich".

Im folgenden wird der Betrieb des vorgenannten Agent-Sy­ stems 201 gemäß der siebenten Ausführungsform der Erfindung anhand von Fig. 22 bis 33 beschrieben.

Unter der Annahme, daß die Delegierungsprotokoll-Verar­ beitungseinrichtung 211 eine Meldung z. B. vom Manager-System M1 empfängt, startet die Delegierungsprotokoll-Verarbeitungs­ einrichtung 211 die Verarbeitung gemäß Fig. 23. Zunächst er­ faßt die Delegierungsprotokoll-Verarbeitungseinrichtung 211 im Schritt S2101 die Namen der Managersysteme, von denen Ver­ bindungen mit der Delegierungsprotokoll-Verarbeitungseinrich­ tung 211 hergestellt wurden. Die Delegierungsprotokoll-Verar­ beitungseinrichtung 211 sendet die erhaltenen Manager-System­ namen und die empfangene Meldung im Schritt S2102 zur Zu­ griffsteuerung 212. Anschließend wartet die Delegierungspro­ tokoll-Verarbeitungseinrichtung 211 im Schritt S2103 die Ver­ arbeitungsergebnisse der anderen Komponenten 212 bis 216 ab.

Danach beginnt die Zugriffsteuerung 212 die Verarbeitung gemäß Fig. 24. Zunächst empfängt die Zugriffsteuerung 212 im Schritt S2201 die Manager-Systemnamen und die empfangene Mel­ dung von der Delegierungsprotokoll-Verarbeitungseinrichtung 211. Danach ruft die Zugriffsteuerung 212 im Schritt S2202 ab, ob die empfangenen Manager-Systemnamen in der Manager-Sy­ stemnamensliste (siehe Fig. 30) vorhanden sind, die im Dele­ gierungsinformationsspeicher 215 gespeichert ist. Wird als Ergebnis im Schritt S2202 der Manager-Systemname gefunden, läßt die Zugriffsteuerung 212 den Zugriff des Manager-Systems M1 auf das Agent-System 201 zu und sendet den Manager-System­ namen und die empfangene Meldung zum Anforderungsanalysator im Schritt S2203.

Wird andererseits als Ergebnis im Schritt S2202 kein Manager-Systemname gefunden, lehnt die Zugriffsteuerung 212 den Zugriff des Manager-Systems M1 ab und sendet im Schritt S2204 "Zugriff auf Agent-System 201 unmöglich" zur Delegie­ rungsprotokoll-Verarbeitungseinrichtung 211. Bei Empfang die­ ser Meldung "Zugriff unmöglich" von der Zugriffsteuerung 212 sendet die Delegierungsprotokoll-Verarbeitungseinrichtung 211 die Meldung "Zugriff unmöglich" im Schritt S2104 zum Manager- System M1.

Danach startet der Anforderungsanalysator 213 die Verar­ beitung gemäß Fig. 25. Zunächst empfängt der Anforderungsana­ lysator 213 im Schritt S2301 den Manager-Systemnamen und die empfangene Meldung von der Zugriffsteuerung 212. Anschließend analysiert der Anforderungsanalysator 213 im Schritt S2302 die empfangene Meldung, um zu beurteilen, ob der Steuerbefehl die Script-Erzeugung darstellt.

Fig. 28 veranschaulicht ein Format einer von den Mana­ ger-Systemen M1, M2 und M3 gesendeten Meldung. In Fig. 28 enthält ein Steuerbefehlsfeld 261 Kennungen der Steuerbe­ fehle, d. h., "1 (Erzeugen)", "2 (Löschen)", "3 (Starten)", "4 (Suspendieren)", "5 (Wiederaufnehmen)", "6 (Informatio­ nen)" oder "7 (Erzeugen & Starten)". Ein Script-Kennungsfeld 262 enthält eine Kennung zum Identifizieren des Scripts als Objekt der Steuerbefehlsausführung, wobei die Kennung ein­ heitlich dem Script-Konverter 214 zugewiesen wird. Ein Kom­ mentarlängenfeld 263 speichert eine Länge eines Kommentars, den ein Kommentarfeld 265 enthält, in der Einheit von Bytes, und ähnlich speichert ein Script-Gerüstlängenfeld 264 eine Länge eines Script-Gerüsts, das ein Script-Gerüstfeld 266 enthält, in der Einheit von Bytes.

Im Schritt S2302 trennt der Anforderungsanalysator 213 die Felder 261 und 266 in ihre jeweiligen Teile und prüft das Steuerbefehlsfeld 261, um die angeforderten Steuerbefehle zu analysieren. Lautet als Ergebnis im Schritt S2302 der Steuer­ befehl in der empfangenen Meldung "Erzeugen" oder "Erzeugen & Starten", sendet der Anforderungsanalysator 213 im Schritt S2304 den Kommentar, das Script-Gerüst, den Manager-Systemna­ men und den Steuerbefehl getrennt zum Script-Konverter 214.

Lautet andererseits als Ergebnis im Schritt S2302 der Steuerbefehl anders als "Erzeugen" und "Erzeugen & Starten", sendet der Anforderungsanalysator 213 im Schritt S2303 den Steuerbefehl, die Script-Kennung und den Manager-Systemnamen zur Script-Steuerung 216. Ferner startet die Script-Steuerung die Verarbeitung gemäß Fig. 26. Zunächst empfängt die Script- Steuerung 216 den Manager-Systemnamen, den Steuerbefehl und die Script-Kennung vom Anforderungsanalysator 213 im Schritt S2401. Anschließend prüft die Script-Steuerung 216 im Schritt S2402, ob das Manager-System M1 das angeforderte Script steu­ ern kann. Diese Prüfung erfolgt durch Erfassen des Manager- Systemnamens in den Script-Informationen der angeforderten Script-Kennung aus dem Delegierungsinformationsspeicher 215 und durch Vergleichen des erfaßten Manager-Systemnamens mit dem vom Anforderungsanalysator 213 gesendeten Manager-System­ namen.

Stimmt im Schritt S2402 der Manager-Systemname nicht überein, bestimmt die Script-Steuerung 216, daß das Manager- System M1 keine Steuervollmacht für das Script hat, und sen­ det "Steuerung unmöglich" im Schritt S2410 zur Delegierungs­ protokoll-Verarbeitungseinrichtung 211. Bei Empfang dieser Meldung "Steuerung unmöglich" von der Script-Steuerung 216 sendet anschließend die Delegierungsprotokoll-Verarbeitungs­ einrichtung 211 die Meldung "Steuerung unmöglich" im Schritt S2104 zum Manager-System M1.

Stimmt dagegen im Schritt S2402 der Manager-Systemname überein, beurteilt die Script-Steuerung 216, daß das Manager- System M1 die Steuervollmacht für das Script hat, und prüft dann im Schritt S2403, ob der Script-Steuerbefehl "Starten" lautet. Lautet im Schritt S2403 der Steuerbefehl "Starten", verknüpft die Script-Steuerung 216 im Schritt S2405 das spe­ zifische verwaltete Grundelement dynamisch, um das durch die Script-Kennung bezeichnete Script auszuführen.

Danach prüft die Script-Steuerung 216 im Schritt S2406, ob die dynamisch zu verknüpfenden spezifischen verwalteten Grundelemente von der dem Manager-System M1 zuvor erteilten Operationsberechtigung abweichen. Dies geschieht wie folgt: Die im Delegierungsinformationsspeicher 215 gespeicherte Ma­ nagement-Operationsberechtigungsliste (siehe Fig. 31) wird unter Verwendung des Manager-Systemnamens und der spezifi­ schen verwalteten Objektnamen als Schlüssel durchsucht, um die Operationsberechtigung zu erhalten, und die Operationsbe­ rechtigung wird mit der Operationsberechtigung der angefor­ derten spezifischen verwalteten Grundelemente verglichen.

Weicht als Ergebnis im Schritt S2406 keines der spezifi­ schen verwalteten Grundelemente von der Operationsberechtigung ab, führt die Script-Steuerung 216 das angeforderte Script im Schritt S2407 aus. Weichen als Ergebnis des Schritts S2406 die spezifischen verwalteten Grundelemente von der Operationsberechtigung ab, sendet die Script-Steuerung 216 im Schritt S2411 "Zugriff auf die spezifischen verwalte­ ten Objekte unmöglich" zur Delegierungsprotokoll-Verarbei­ tungseinrichtung 211. Bei Empfang der Meldung "Zugriff unmög­ lich" von der Script-Steuerung 216 sendet anschließend die Delegierungsprotokoll-Verarbeitungseinrichtung 211 die Mel­ dung "Zugriff auf die spezifischen verwalteten Objekte unmög­ lich" im Schritt S2104 zum Manager-System M1.

Ist ferner als Ergebnis des Schritts S2403 der Steuerbe­ fehl ein anderer als "Starten", führt die Script-Steuerung 216 im Schritt S2404 den Steuerbefehl für das durch die Script-Kennung bezeichnete Script aus. Anschließend aktuali­ siert die Script-Steuerung 216 im Schritt S2408 die entspre­ chenden Informationen, die im Delegierungsinformationsspei­ cher 215 gespeichert sind, in Übereinstimmung mit der Script- Informationsänderung infolge der Befehlsausführung. Ihrer­ seits sendet die Script-Steuerung 216 im Schritt S2409 das Ergebnis (Erfolg oder Mißerfolg) der Steuerbefehlsausführung zur Delegierungsprotokoll-Verarbeitungseinrichtung 211. Bei Empfang dieses Steuerbefehl-Ausführungsergebnisses von der Script-Steuerung 216 sendet die Delegierungsprotokoll-Verar­ beitungseinrichtung 211 das Steuerbefehl-Ausführungsergebnis im Schritt S2104 zum Manager-System M1.

Ist ferner als Ergebnis im Schritt S2302 im Anforde­ rungsanalysator 213 der Steuerbefehl ein anderer als "Erzeu­ gen" und "Erzeugen & Starten", implementiert der Script-Kon­ verter 214 die Verarbeitung gemäß Fig. 27. Zunächst empfängt der Script-Konverter 214 im Schritt S2501 den Manager-System­ namen, das Script-Gerüst, den Kommentar und den Steuerbefehl vom Anforderungsanalysator 213. Anschließend prüft der Script-Konverter 214 im Schrift S2502, ob die Beschreibungs­ form des Script-Gerüsts die veränderliche Textform oder die Binärcodes ist. Ist als Ergebnis im Schritt S2502 das Script- Gerüst in der Textform geschrieben, konvertiert der Script- Konverter 214 im Schritt S2503 die abstrakten verwalteten Ob­ jektnamen in die spezifischen verwalteten Objektnamen. Diese Konvertierung erfolgt durch Durchsuchen der Entsprechungsli­ ste für spezifische verwaltete Objekte (siehe Fig. 32), die im Delegierungsinformationsspeicher 215 gespeichert ist, un­ ter Verwendung der abstrakten verwalteten Objektnamen als Schlüssel zum Auffinden der entsprechenden spezifischen ver­ walteten Objektnamen.

Anschließend konvertiert der Script-Konverter 214 die abstrakten verwalteten Grundelementnamen in die spezifischen verwalteten Grundelementnamen unter Verwendung der Entspre­ chungsliste für spezifische verwaltete Grundelemente (siehe Fig. 33), die im Delegierungsinformationsspeicher 215 gespei­ chert ist, im Schritt S2504 auf die gleiche Weise wie im Schritt S2503. Danach durchsucht der Script-Konverter 214 im Schritt S2505 die Management-Operationsberechtigungsliste (siehe Fig. 31), die im Delegierungsinformationsspeicher 215 gespeichert ist, unter Verwendung der spezifischen verwalte­ ten Objektnamen und des Manager-Systemnamens als Schlüssel, um die Operationsberechtigung aller konvertierten spezifi­ schen verwalteten Objekte zu prüfen, um die Operationsberech­ tigung des Manager-Systems M1 zu erhalten, und um zu prüfen, ob die angeforderten spezifischen verwalteten Grundelemente von der Operationsberechtigung abweichen.

Weicht als Ergebnis im Schritt S2505 mindestens eines der spezifischen verwalteten Objekte von der Operationsbe­ rechtigung ab, bestimmt der Script-Konverter 214 die Unmög­ lichkeit des Zugriffs auf die spezifischen verwalteten Ob­ jekte und sendet diese Meldung "Zugriff unmöglich" zur Dele­ gierungsprotokoll-Verarbeitungseinrichtung 211 im Schritt S2511. Nach Empfang dieser Meldung "Zugang unmöglich" vom Script-Konverter 214 sendet die Delegierungsprotokoll-Verar­ beitungseinrichtung 211 anschließend die Meldung "Zugang zu den spezifischen verwalteten Objekten unmöglich" zum Manager- System M1 im Schritt S2104.

Weicht andererseits als Ergebnis im Schritt S2505 keines der spezifischen verwalteten Objekte von der Operationsbe­ rechtigung ab, konvertiert der Script-Konverter 214 im Schritt S2506 die in den Schritten S2503 und S2504 erzeugten Scripts in die ausführbare Form, z. B. die Binärcodes, für das Agent-System 201, z. B. durch Kompilieren. Der Script- Konverter 214 sendet das Script-Gerüst aus den im Schritt S2502 erhaltenen Binärcodes oder das Script aus den Binär­ codes und die sich im Schritt S2506 ergebenden Script-Infor­ mationen zum Delegierungsinformationsspeicher 215 zu ihrem Speichern im Schritt S2507. Die zu speichernden Script-Infor­ mationen weisen den Manager-Systemnamen, den Kommentar, die einheitlichen Script-Kennungen, die der Script-Konverter 214 innerhalb des Agent-Systems 201 zuweist, und den Zustand "Ruht" auf.

Danach prüft der Script-Konverter 214 im Schritt S2508, ob der Steuerbefehl "Erzeugen & Starten" lautet. Lautet als Ergebnis im Schritt S2508 der Steuerbefehl "Erzeugen & Star­ ten", sendet zur sofortigen Ausführung des im Delegierungsin­ formationsspeicher 215 im Schritt S2507 gespeicherten Scripts der Script-Konverter 214 im Schritt S2510 den Steuerbefehl "Starten" und die im Schritt S2507 zugewiesene Script-Kennung zur Script-Steuerung 216.

Lautet als Ergebnis im Schritt S2508 der Steuerbefehl "Erzeugen", sendet der Script-Konverter 214 im Schritt S2509 das Ausführungsergebnis (Erfolg oder Mißerfolg) zur Delegie­ rungsprotokoll-Verarbeitungseinrichtung 211. Bei Empfang des Ausführungsergebnisses vom Script-Konverter 214 sendet die Delegierungsprotokoll-Verarbeitungseinrichtung 211 im Schritt S2104 das Ausführungsergebnis zum Manager-System M1.

Fig. 29 zeigt ein Format einer Meldung, die ein Steuer­ befehl-Ausführungsergebnis enthält, das vom Agent-System 201 zu den Manager-Systemen M1, M2 und M3 zu senden ist. In Fig. 29 enthält ein Ergebnisfeld 271 die Ergebnisse, d. h., "0 (Erfolg)" oder "1 (Mißerfolg)", der durch die Manager-Systeme M1, M2 und M3 angeforderten Steuerbefehle. Enthält das Ergeb­ nisfeld 271 "1 (Mißerfolg)", so enthält ein detaillierteres Ergebnisfeld 272 detailliertere Informationen, d. h., "1 (Zugriff auf Agent-System 201 unmöglich)", "2 (Steuerung für Script unmöglich)", "3 (Zugriff auf spezifische verwaltete Objekte unmöglich)" oder "4 (andere Fehler)". Enthält das Er­ gebnisfeld 271 "0 (Erfolg)", so enthält das detailliertere Ergebnisfeld 272 "0". Ein Feld 273 für die Anzahl der Script- Informationen enthält eine Anzahl von Script-Informationen 274 bis 279, die diesem Feld 273 folgen. Ein Feld 274 für die Script-Kennung enthält die Kennung des diese Informationen enthaltenden Scripts. Ein Zustandsfeld 275 enthält den Exi­ stenzzustand des Scripts, d. h., "1 (Läuft)", "2 (Suspen­ diert)" oder "3 (Ruht)". Ein Feld 276 für die Länge des Mana­ ger-Systemnamens enthält eine Länge des Manager-Systemnamens, den ein Feld 278 für den Manager-Systemnamen enthält, in der Einheit von Bytes. Ein Kommentarlängenfeld 277 enthält eine Länge eines Kommentars, den ein Kommentarfeld 279 enthält, in der Einheit von Bytes. Diese Felder 274 bis 279 stellen die Informationen eines Scripts dar und setzen sich bis zu der Anzahl fort, die das Feld 273 für die Anzahl der Script-In­ formationen enthält.

Im folgenden wird ein Agent-System gemäß einer achten Ausführungsform der Erfindung anhand von Fig. 34 beschrieben.

In dieser Ausführungsform gemäß Fig. 34 hat das Agent­ system 201 den gleichen Aufbau wie in der siebenten Ausfüh­ rungsform von Fig. 22 mit der Ausnahme, daß Informationen zwischen Lauf-Scripts S1 und S2 und einem Managementproto­ koll-Verarbeitungsabschnitt 204 übermittelt werden. Obwohl in Fig. 34 zwei Lauf-Scripts S1 und S2, drei verwaltete Objekt­ ressourcensteuerungen CO1, CO2 und CO3 sowie drei verwaltete Objektressourcen O1, O2 und O3 gezeigt sind, werden strengge­ nommen mehrere Lauf-Scripts S1 bis Sk, mehrere verwaltete Ob­ jektressourcensteuerungen CO1 bis COm und mehrere verwaltete Objektressourcen O1 bis Om verwendet.

Im zuvor beschriebenen Agent-System der siebenten Aus­ führungsform der Erfindung erfolgt die Kommunikation zwischen dem Lauf-Script S1 und dem Agent-Kern 203 direkt, beispiels­ weise unter Verwendung ihres eigenen Systems, z. B. einer Bi­ bliothek. In dieser Ausführungsform gemäß Fig. 34 ist die Kommunikation zwischen den Lauf-Scripts S1 und S2 und dem Agent-Kern 203 über den Managementprotokoll-Verarbeitungsab­ schnitt 204 implementiert. Das heißt, unter Verwendung eines Standard-Managementprotokolls, z. B. eines einfachen Netz­ werk-Managementprotokolls oder eines gemeinsamen Management- Informationsprotokolls, erfolgt zunächst die Kommunikation zwischen den Lauf-Scripts S1 und S2 und dem Managementproto­ koll-Verarbeitungsabschnitt 204. Der Managementprotokoll-Ver­ arbeitungsabschnitt 204 konvertiert die durch das Standard- Managementprotokoll ausgewiesene Management-Operationsanfor­ derung in seinen internen Ausdruck und kommuniziert anschlie­ ßend mit dem Agent-Kern 203, was zur indirekten Implementie­ rung der Kommunikation zwischen den Lauf-Scripts S1 und S2 und dem Agent-Kern 203 führt.

Fig. 35 zeigt die Verarbeitung eines Script-Konverters 214 eines Delegierungsausführungsabschnitts 202 gemäß Fig. 35 mit einem Schritt S3301 zum Empfangen des Manager-Systemna­ mens, des Script-Gerüsts, des Kommentars und des Steuerbe­ fehls, einem Schritt S3302 zum Unterscheiden des Binärcodes des Script-Gerüsts, einem Schritt S3303 zum Konvertieren ab­ strakter in spezifische verwaltete Objektnamen, einem Schritt S3304 zum Konvertieren abstrakter in spezifische verwaltete Grundelementnamen, einem Schritt S3305 zum Unterscheiden ei­ ner Abweichung der Operationsberechtigung, einem Schritt S3306 zum Konvertieren des Scripts in die ausführbare Form, einem Schritt S3307 zum Speichern der Script-Informationen und des Scripts oder des Script-Gerüsts, einem Schritt S3308 zum Unterscheiden einer sofortigen Script-Ausführung, einem Schritt S3309 zum Senden des Steuerbefehl-Ausführungsergeb­ nisses, einem Schritt S3310 zum Senden des Steuerbefehls "Starten" und der Script-Kennung und einem Schritt S3311 zum Mitteilen von "Zugriff auf spezifische verwaltete Objekte un­ möglich".

Im folgenden wird der Betrieb des vorgenannten Agent-Sy­ stems 201 gemäß der achten Ausführungsform der Erfindung an­ hand von Fig. 34 bis 36 beschrieben.

In dieser Ausführungsform besteht der Unterschied der achten Ausführungsform des Agent-Systems zur zuvor beschrie­ benen siebten Ausführungsform darin, daß die Verarbeitung des Script-Konverters 214 gemäß Fig. 27 in die Verarbeitung gemäß Fig. 35 geändert ist. Insbesondere ist der Schritt S3304 von Fig. 35 gegenüber dem entsprechenden Schritt S2304 von Fig. 27 geändert. Das heißt, abstrakte verwaltete Grundelementna­ men werden in verwaltete Grundelementnamen konvertiert (ver­ waltete Grundelemente stellen verschiedene durch das Manage­ mentprotokoll bereitgestellte Dienste dar), wobei eine Ent­ sprechungsliste zwischen den abstrakten verwalteten Grundele­ mentnamen und den verwalteten Grundelementnamen (im folgenden als "Entsprechungsliste für verwaltete Grundelemente" be­ zeichnet) zum Einsatz kommt, die im Delegierungsinformations­ speicher 215 im Delegierungsausführungsabschnitt 202 gespei­ chert ist. Bei Verwendung eines MSAP (Management-Dienstzu­ griffspunkt), der durch einen OSIMIS (Management-Informa­ tionsdienst in systemfreier Kommunikation) bereitgestellt ist, zeigt Fig. 36 ein Beispiel für die Entsprechungsliste für verwaltete Grundelemente, in der ein Feld 341 für Namen abstrakter verwalteter Grundelemente die Namen der abstrakten verwalteten Grundelemente enthält, z. B. "getValue", "set- Value", "createMO", "deleteMO", . . ., und ein Feld 342 für Namen verwalteter Grundelemente die Namen der verwalteten Grundelemente enthält, z. B. "M-Get", "M-Set", "M-Create", "M-Delete", . . ., die den vorgenannten abstrakten verwalteten Grundelementnamen entsprechen.

In dieser Ausführungsform wird das Standardprotokoll für die Kommunikation zwischen den Lauf-Scripts S1 und S2 und dem Agent-Kern 203 über die Managementprotokoll-Verarbeitungsein­ richtung 204 im Delegierungsausführungsabschnitt 202 des Agent-Systems 201 verwendet, wodurch sich die Flexibilität im Delegierungsausführungsabschnitt 202 als Delegierungsvorrich­ tung erhöhen läßt.

Ferner wird im Agent-System der siebten Ausführungsform angenommen, daß die verwalteten Objektressourcen O1, O2 und O3, die tatsächlich zu verwalten sind, in der Nähe des Agent- Systems angeordnet sind. Beim Agent-System der achten Aus­ führungsform erfolgt dagegen die Kommunikation zwischen den Lauf-Scripts S1 und S2 und dem Agent-Kern 203 indirekt über die Managementprotokoll-Verarbeitungseinrichtung 204 unter Verwendung des Standard-Managementprotokolls, und auch wenn sich die verwalteten Objektressourcen O1, O2 und O3 an ent­ fernten Standorten befinden, kann die Delegierungsvorrichtung verwendet werden. Als Ergebnis läßt sich die Flexibilität des Delegierungsausführungsabschnitts 202 verbessern, und das Agent-System kann die verwalteten Objektressourcen O1, O2 und O3 verwalten, die an verschiedenen Standorten positioniert sind.

Wie vorstehend beschrieben wurde, ist erfindungsgemäß ein Server-System mit einem Programmempfänger, einem dynami­ schen Bindungsabschnitt, einem Programmausführungsabschnitt und einem Programmausführungs-Informationsspeicher bereitge­ stellt, und Verarbeitungen, deren Ausführung ein Benutzer wünscht, werden programmiert und zum Server-System gesendet, um die Programme auf ihm auszuführen. Dadurch werden kompli­ zierte Verarbeitungen mit solchen Steuerstrukturen wie Ver­ zweigungen und Wiederholungen auf Server-Systemen an entfern­ ten Standorten ausführbar.

Ein von einem Client-System zu einem Server-System zu sendendes Programm beschreibt lediglich einen Verarbeitungs­ ablauf, und das Server-System weist einen Verknüpfer für spe­ zifische Operationsobjekte auf, um spezifische Operationsob­ jekte jedes Server-Systems zum Durchführen verschiedener Ver­ arbeitungen zur Programmausführungszeit mit dem Programm dy­ namisch zu verknüpfen. Dadurch reicht es für einen Benutzer aus, nur den Ablauf der Verarbeitung zu beschreiben, ohne den Aufbau und die Aufsätze des Server-Systems zu berücksichti­ gen, und die Programmbeschreibung kann rationeller erfolgen.

Ferner weist das Server-System einen Verknüpfungsberech­ tigungsprüfer auf, um die Verknüpfung unter Verwendung einer Verknüpfungsberechtigung eines Client-Systems beim Verknüpfen der spezifischen Objekte mit dem Programm zu steuern, wodurch die Programmausführung über die Verknüpfungsberechtigung des Client-Systems hinaus verhindert wird. Dadurch läßt sich die Sicherheit des Server-Systems verbessern.

Das Programm, das nur den Ablauf der Verarbeitung unab­ hängig vom Aufbau und von den Aufsätzen des Server-Systems beschreibt, wird zum Server-System zur Programmausführung ge­ sendet, und die Kommunikationsmenge zwischen dem Server-Sy­ stem und dem Client-System kann verringert werden.

Bei Anwendung eines Server-Systems mit einem Programm­ empfänger ("Server-System") auf ein Agent-System mit einer Delegierungsvorrichtung ("Agent-System") in einem Netzwerk- Management ist das Agent-System ferner mit einem Agent-Kern versehen, der einen MIS steuert, eine Operation zum MIS und eine gemeinsame Management-Operation zu verschiedenen verwal­ teten Objektressourcen führt, angeforderte Management-Opera­ tionen in adaptive Formen für verwaltete Objektressourcen­ steuerungen konvertiert und die konvertierten Formen zu ent­ sprechenden verwalteten Objektressourcensteuerungen ausgibt, wodurch das Netzwerk-Management unter Berücksichtigung des OSI-Netzwerk-Managements erfolgen kann. Zusätzlich kann ein Script-Gerüst unter Verwendung der gemeinsamen Management- Operationseinrichtung für die verwalteten Objektressourcen beschrieben werden, was zu einer effizienteren Beschreibung des Script-Gerüsts führt.

Innerhalb des Agent-Systems wird der dynamische Bin­ dungsabschnitt verwendet, und das vom Manager-System gesen­ dete Script-Gerüst beschreibt nur den Ablauf der Management- Task. Daher kann beim Senden des Script-Gerüsts die Kommuni­ kationsmenge zwischen dem Manager-System und dem Agent-System im Vergleich zu der eines herkömmlichen Agent-Systems verrin­ gert werden.

Durch Zufügen von Steuerbefehlen eines Lauf-Scripts und von Script-Informationen kann eine präzise Script-Steuerung erfolgen, die kein herkömmliches Agent-System hat, und das Agent-System kann flexibel der Script-Ausführung und den Ma­ nagement-Maßnahmen der Management-Standorte je nach den Last­ bedingungen des Agent-Systems entsprechen.

Mit der Zufügung einer Zugriffsteuerung kann das Agent- System eine flexible Zugriffsteuerung in Abhängigkeit von Ma­ nager-Namen und Management-Maßnahmen der Management-Standorte durchführen, was zu verbesserter Sicherheit des Agent-Systems führt.

Claims (13)

1. Fernausführungssystem (1) mit einem Programmempfänger (2), das aufweist:
einen Programmempfänger (2) zum Empfangen eines Pro­ gramms, das einen Ablauf einer Verarbeitung beschreibt und von einem Client-System (C1, C2 oder C3) als Anfor­ derungssendequelle gesendet wird, und Senden eines Aus­ führungsergebnisses des Programms;
einen dynamischen Bindungsabschnitt (3) mit einem Ver­ knüpfer (7) für spezifische Operationsobjekte zum dyna­ mischen Verknüpfen spezifischer Operationsobjekte von Verarbeitungsoperationen, die auf dem Fernausführungssy­ stem (1) als Server-System zum Ausführen einer angefor­ derten Verarbeitung an Verarbeitungsoperationsnamen auf­ gesetzt sind, die in dem durch den Programmempfänger (2) empfangenen Programm beschrieben sind, und einem Ver­ knüpfungsberechtigungsprüfer (6) zum Prüfen, ob ein Cli­ ent-System (C1, C2 oder C3) eine Verknüpfungsberechti­ gung beim Verknüpfen der spezifischen Operationsobjekte mit dem Programm hat;
einen Programmausführungsabschnitt (4) zum Ausführen des durch den dynamischen Bindungsabschnitt (3) verknüpften Programms; und
einen Programmausführungs-Informationsspeicher (5) zum Speichern des Programms, von Informationen, die für eine durch den dynamischen Bindungsabschnitt (3) durchge­ führte Zugriffsteuerung erforderlich sind, und der spe­ zifischen Operationsobjekte.

2. Dynamischer Bindungsabschnitt (3) in einem Fernausfüh­ rungssystem (1) mit einem Programmempfänger (2) nach An­ spruch 1, der dynamisch die spezifischen Operationsob­ jekte entsprechend von Aufsätzen des Server-Systems mit den in dem Programm beschriebenen Verarbeitungsopera­ tionsnamen verknüpft und prüft, ob das Client-System (C1, C2 oder C3) die Verknüpfungsberechtigung für die spezifischen Operationsobjekte beim Verknüpfen hat, um das Server-System zu schützen.

3. Fernausführungssystem (1) mit einem Programmempfänger (2) nach Anspruch 1 oder 2, ferner mit einer Zugriff­ steuerung (71) zum Prüfen, ob das Client-System (C1, C2 oder C3) auf das Server-System zugreifen kann.

4. Zugriffsteuersystem in einem Fernausführungssystem (1) mit einem Programmempfänger (2) nach Anspruch 3 mit:
einer Zugriffsteuerung (71) zum Prüfen, ob es dem Cli­ ent-System (C1, C2 oder C3) zu erlauben ist, auf das Server-System zuzugreifen, wenn das Programm von dem Client-System (C1, C2 oder C3) gesendet wird, um eine Ausführung eines unrichtigen Programms zu verhindern, das von der dem Client-System (C1, C2 oder C3) zugewie­ senen Berechtigung abweicht; und
einem Verknüpfungsberechtigungsprüfer (6) zum Prüfen, ob eine Verknüpfungsberechtigung für die spezifischen Ope­ rationsobjekte, die mit dem Programm beim Ausführen des Programms dynamisch zu verknüpfen sind, von der zuvor dem Client-System (C1, C2 oder C3) zugewiesenen Verknüp­ fungsberechtigung abweicht.

5. Fernausführungssystem (1) mit einem Programmempfänger (2) nach einem der Ansprüche 1 bis 4, ferner mit einem Programmkonverter (111) zum Konvertieren abstrakter Ope­ rationsobjektnamen als gemeinsame Verarbeitungsopera­ tionsnamen für alle Server-Systeme in spezifische Opera­ tionsobjektnamen und Konvertieren von Programmen mit ei­ ner veränderlichen Textform in Programme mit einer aus­ führbaren Form für die Server-Systeme durch Kompilieren o. ä.

6. Fernausführungssystem (1) mit einem Programmempfänger (2) nach Anspruch 5, wobei der Programmkonverter (111) eine Einrichtung zum Behandeln nicht nur der Programme in der Textform, sondern auch von Programmen hat, die in Binärcodes oder Zwischencodes geschrieben sind.

7. Fernausführungssystem (1) mit einem Programmempfänger (2) nach einem der Ansprüche 1 bis 6, ferner mit:
einer Zugriffsteuerung (71) zum Prüfen, ob ein Client- System (C1, C2 oder C3) auf das Server-System zugreifen kann; und
einem Programmkonverter (111) zum Konvertieren abstrak­ ter Operationsobjektnamen als gemeinsame Verarbeitungs­ operationsnamen für alle Server-Systeme in spezifische Operationsobjektnamen und Konvertieren von Programmen mit einer veränderlichen Textform in Programme mit einer ausführbaren Form für die Server-Systeme durch Kompilie­ ren o. a.

8. Fernausführungssystem (1) mit einem Programmempfänger (2) nach einem der Ansprüche 1 bis 7, ferner mit:
einer Zugriffsteuerung (71) zum Prüfen, ob ein Client- System (C1, C2 oder C3) auf das Server-System zugreifen kann; und
einem Programmkonverter (111) zum Konvertieren abstrak­ ter Operationsobjektnamen als gemeinsame Verarbeitungs­ operationsnamen für alle Server-Systeme in spezifische Operationsobjektnamen, Konvertieren von Programmen mit einer veränderlichen Textform in Programme mit einer ausführbaren Form für die Server-Systeme durch Kompilie­ ren o. a. und Behandeln nicht nur der Programme in der Textform, sondern auch von Programmen, die in Binärcodes oder Zwischencodes geschrieben sind.

9. Agent-System (201) in einem Netzwerk-Management, auf das ein Fernausführungssystem (1) mit einem Programmempfänger (2) nach einem der Ansprüche 1 bis 8 angewendet ist, mit:
einer Delegierungsprotokoll-Verarbeitungseinrichtung (211) zum Kommunizieren von Meldungen mit Manager-Syste­ men (M1, M2 und M3);
einer Zugriffsteuereinrichtung (212) zum Bestimmen, ob es den Manager-Systemen (M1, M2 und M3) zu erlauben ist, auf das Agent-System (201) als Reaktion auf eine Zu­ griffanforderung der Manager-Systeme (M1, M2 und M3) zu­ zugreifen;
einer Anforderungsanalysierungseinrichtung (213) zum Analysieren der von den Manager-Systemen (M1, M2 und M3) gesendeten Meldung;
einer Script-Konvertierungseinrichtung (214) zum Konver­ tieren eines Script-Gerüsts, das nur einen Ablauf einer Management-Operation in abstrakten Ausdrücken unabhängig von Aufsätzen des Agent-Systems (201) und einer in dem Agent-System (201) realisierten Management-Operation be­ schreibt und ein Programm in ein Script konvertiert, das eine Folge von Management-Operationen entsprechend dem Agent-System (201) und ein Realisierungsverfahren der Management-Operationen darstellt;
einer Script-Steuereinrichtung (216) zum Steuern eines Starts eines neuen Scripts und eines Lauf-Scripts (S1); einem Delegierungsinformationsspeicher (215) zum Spei­ chern der Scripts, von Informationen der Scripts, Infor­ mationen, die für die Zugriffsteuerung erforderlich sind, und Informationen, die für die Script-Konvertie­ rung erforderlich sind;
verwalteten Objektressourcensteuerungen (CO1, CO2 und CO3) zum Steuern verwalteter Objektressourcen (O1, O2 und O3);
einem Management-Informationsspeicher (205) zum Spei­ chern von Management-Objekten, die durch Abstrahieren der verwalteten Objektressourcen (O1, O2 und O3) erhal­ ten werden;
einem Agent-Kern (203), der den Management-Informations­ speicher (205) verwaltet, Operationen zu dem Management- Informationsspeicher (205) und gemeinsame Management- Operationen zu verschiedenen verwalteten Objektressour­ cen (O1, O2 und O3) führt, die angeforderten Management- Operationen in Formen konvertiert, die den verwalteten Objektressourcensteuerungen (CO1, CO2 und CO3) entspre­ chen, und die konvertierten Formen zu geeigneten verwal­ teten Objektressourcensteuerungen (CO1, CO2 und CO3) ab­ gibt; und
einem Managementprotokoll-Verarbeitungsabschnitt (204) zum Konvertieren von Operationsanforderungen in dem Ma­ nagementprotokoll in Formen, die dem Agent-System (201) entsprechen.

10. Zugriffsteuersystem in einem Agent-System (201) nach An­ spruch 9 mit:
einer Zugriffsteuerung (212) zum Bestimmen, ob es den Manager-Systemen (M1, M2 und M3) zu erlauben ist, auf das Agent-System (201) zuzugreifen, wenn Meldungen von den Manager-Systemen (M1, M2 und M3) gesendet werden, um die verwalteten Objektressourcen (O1, O2 und O3) und das Agent-System (201) zu schützen;
einer Script-Steuerung (216), die beim Steuern des Scripts bestimmt, ob das Manager-System (M1, M2 und M3) eine Script-Steuerung ausführen kann, und prüft, ob eine Operationsberechtigung für spezifische verwaltete Grund­ elemente, die dynamisch mit einem neuen Script beim Aus­ führen des neuen Scripts zu verknüpfen sind, von der zu­ vor dem Manager-System (M1, M2 und M3) zugewiesenen Ope­ rationsberechtigung abweicht; und
einem Script-Konverter (214) zum Bestimmen, ob das Mana­ ger-System (M1, M2 und M3) von der Operationsberechti­ gung für die spezifischen verwalteten Objekte abweicht, wenn abstrakte verwaltete Grundelement- und Objektnamen in dem gesendeten Script-Gerüst in spezifische verwalte­ te Grundelement- und Objektnamen konvertiert werden.

11. Script-Steuersystem in einem Agent-System (201) nach An­ spruch 9 oder 10 mit einer Suspendierung, einem Stopp und einer Wiederaufnahme sowie einer Script-Erzeugung und -Sendung, einer Script-Löschung, einem Script-Aus­ führungsstart und einer Script-Informationserfassung.

12. Script-Informationsstruktur in einem Agent-System (201) nach Anspruch 9, 10 oder 11 mit einem "Startdatum", ei­ nem "Zustand", einer "Script-Kennung", die einheitlich innerhalb des Agent-Systems (201) zu sein hat, wobei ein "Manager-Systemname" ein Script gesendet hat und in ei­ nem "Kommentar" eine einfache Beschreibung des Scripts erfolgt.

13. Agent-System (201) nach einem der Ansprüche 9 bis 12, wobei bei Zugriff eines Lauf-Scripts (S1) auf einen Ma­ nagement-Informationsspeicher (205) und verwaltete Ob­ jektressourcen (O1, O2 und O3) das Lauf-Script (S1) in­ direkt auf einen Agent-Kern (203) durch Kommunizieren mit einem Managementprotokoll-Verarbeitungsabschnitt (204) zum Konvertieren einer Operationsanforderung in einem Managementprotokoll in eine Form zugreift, die dem Agent-System (201) entspricht.