DE69732943T2

DE69732943T2 - Datenverarbeitungsvorrichtung und -verfahren

Info

Publication number: DE69732943T2
Application number: DE69732943T
Authority: DE
Inventors: Yasuyuki 1-1 Shibaura 1-chome Tahara; Akihiko 1-1 Shibaura 1-chome Ohsuga; Yasuo 1-1 Shibaura 1-chome Nagai; Akira 1-1 Shibaura 1-chome Kagaya; Masanori 1-1 Shibaura 1-chome Hattori; Yutaka 1-1 Shibaura 1-chome Irie; Shinichi 1-1 Shibaura 1-chome Honiden
Original assignee: Toshiba Corp
Current assignee: Toshiba Corp
Priority date: 1996-09-17
Filing date: 1997-09-17
Publication date: 2006-05-04
Anticipated expiration: 2017-09-18
Also published as: JPH10149287A; DE69732943D1; EP0829806A3; JP3952544B2; US6134580A; EP0829806B1; EP0829806A2

Description

HINTERGRUND DER ERFINDUNG
1. Gebiet der Erfindung
Die vorliegende Erfindung betrifft eine Datenverarbeitungseinrichtung, die Information verarbeitet, welche in verteilter Form in einem Netz existiert, und eine Verbesserung in einem Datenverarbeitungsverfahren.
2. Beschreibung des Standes der Technik
In den letzten Jahren tendierte man auf dem Gebiet der Datenverarbeitung unter Fokussierung auf die Verwendung von Computern zu einer Verkleinerung und der Implementierung von Netzumgebungen wie dem Internet. Als ein Ergebnis haben die hauptsächlich verwendeten Datenverarbeitungs-Hardware und Verfahren eine Verschiebung zu einem verteilten System gezeigt, in welchem Bestandteile, wie zum Beispiel Datendateien und Funktionsbibliotheken auf alle Geräte des Netzes verteilt sind. Mit dieser Änderung hat es eine Entwicklung beim Implementieren einer Offensystemumgebung in Verbindung mit Weitbereichsnetzen gegeben, selbst in dem Fall privater Firmen und Laboratorien. Solche Netze, die mit Weitbereichsnetzen verbunden sind, sind als offene Netze bekannt.
In Großnetzen, wie es typischerweise offene Netze sind, kommt es häufig vor, dass eine einzelne Software-Einheit aus einer Kombination von Bestandteilen, wie Datendateien und Funktionsbibliotheken erstellt wird, die über eine Vielzahl von Geräten verteilt sind. Auf diese Weise aufgebaute Software ist als verteiltes System bekannt. Im Hinblick auf die Steuersituation der verschiedenen Geräte oder Knoten und die Steueraspekte des Netzes ist es vorstellbar, dass Bestandteile, die in einer verteilten Weise angeordnet sind, zu anderen Geräten oder Datenverzeichnissen (Directory) im Netz migriert werden mit einer Änderung der Eigenschaften, wie zum Beispiel des zugeordneten Namens und der Zugriffsprivilegien. Aufgrund solcher Änderungen treten die folgenden Probleme auf.
Erstens wird beim Anfragen eines Software-Teils zum Vornehmen einer Verarbeitung ein Anfragecode, wie zum Beispiel eine Meldung oder ein Befehl eingegeben und beim Vornehmen dieser Eingabe wird ein sich auf die Verarbeitung bei einem gegebenen Gerät beziehender Bestandteil spezifiziert. Wenn jedoch der spezifizierte Bestandteil zu einem anderen Gerät migriert worden ist, ist es zum Spezifizieren eines neuen Gerätes an dem Migrationsziel erforderlich, die Eingabe wieder vorzunehmen oder zu modifizieren in Bezug auf die Software. Insbesondere in dem Fall, in dem ein Teil der Software konfiguriert ist, um auf einen migrierten Bestandteil zuzugreifen, ist die Migration des Bestandteiles äquivalent zur Änderung der Konfiguration der Software selbst. In diesem Fall ist es erforderlich, den Teil der Software, der den Zugriff durchführt, zu ändern und das neue Gerät bei dem Migrationsziel zu spezifizieren.
In der Vergangenheit war es, wegen der expliziten Namensspezifikation in Bezug auf Geräte, Funktionen, Dateien und ähnliches, wenn eine Funktion oder eine Datei migriert worden sind, erforderlich, die Software zu ändern oder einzugeben, um die Änderung unterzubringen. Zudem muss diese Art von Spezifikation vor dem Start der Verarbeitung vorgenommen werden.
In einem verteilten System ist es, um einem Benutzer zuverlässig einen Dienst bereitzustellen, wichtig, flexible Software aufzubauen, die solche Änderungen adaptieren kann. Es ist insbesondere wünschenswert, imstande zu sein, die Adaption automatisch vorzunehmen, wenn überhaupt möglich ohne menschlichen Eingriff, selbst nachdem die Verarbeitung gestartet worden ist.
In einem Netz hat in den letzten Jahren Agenten- bzw. Agentorientierte Technologie an Aufmerksamkeit gewonnen als eine Technik zum Erreichen dieser flexiblen Software-Architektur, und viele Implementierungen davon sind versucht worden. Agent-orientierte Technologie ist eine Software-Entwicklungstechnologie, die versucht, Software in Einheiten von Agents zu konfigurieren, wobei der Begriff "Agent" in diesem Fall die Verarbeitungseinheit der Software ist, die sich unabhängig und flexibel an eine Änderung in der Umgebung anpasst.
Beispielsweise ist in der japanischen ungeprüften Patentanmeldungsveröffentlichung H7-182174 ein Verfahren zum Implementieren ferner Programmierung offenbart. Ferne Programmierung (Remote Programming) ist eine Programmierung, bei der in einem verteilten System ein Agent von einem Knoten, bei dem eine Verarbeitung gestartet worden ist (bekannt als lokales Gerät) zu einem anderen Knoten (als fernes Gerät bekannt) migriert wird.
Um einen Agent zu verwenden, sind Anweisungen und interne Informationen erforderlich. Anweisungen werden zum Codieren der Operation (des Verhaltens) des Agent verwendet und interne Informationen sind die Informationen, die durch die Operation des Agent bearbeitet werden. Speziell schließen diese internen Daten zusätzlich zu Variablen und Arrays, Stapel, Puffer, Warteschlangen, Flags bzw. Merker und ähnliches ein, die die gesamte zum Betrieb des Agent erforderliche Information ausmachen. Zusammengenommen, bilden Anweisungen und interne Informationen, was als Agent-Information bekannt ist.
Anweisungen werden in Einheiten verschiedener Operationen codiert, wie zum Beispiel Öffnen und Schließen von Dateien.
Bei ferner Programmierung (Remote Programming) gibt es eine Spezialanweisung, die eine go- bzw. Gehe-zu-Operation ist. Die Go-Operation verursacht die Verarbeitung, die eine Migration eines Agent zu einem fernen Gerät vornimmt, und wenn während der Verarbeitung einer Anweisung in Bezug auf eine Datei, die sich in einem anderen Gerät befindet, vorgesehen ist, muss beispielsweise vor dieser Anweisung eine Go-Anweisung codiert und ausgeführt werden.
Ein anderes Beispiel einer Technologie der Vergangenheit zum Zwecke des Ausführens einer Verarbeitung, die zwischen einer Vielzahl von Knoten eines Netzes verteilt ist, ist die folgende (es wird Bezug genommen auf Oren Etzioni und Daniel Weld "A Softbot-Based Interface to the Internet" (Communications of ACM)). In dieser Technologie werden die gewöhnlichen Netzfunktionen, wie zum Beispiel ftp, welche eine Dateiübertragung ausführt, und telnet, welche eine virtuelle Endgerätefunktion für fernes Anmelden (Login) vornimmt, verwendet zum Ausführen einer Verarbeitung, die sich über eine Vielzahl von Geräten verteilt. Basierend auf Information, die während des Betriebs gesammelt wird, wird eine automatische Trial-and-Error-Verwendung jeder Funktion unter Software-Steuerung vorgenommen, um flexible Planung in Übereinstimmung mit Bedingungen vorzunehmen, hierdurch eine Funktionsauswahl ausführend, die Konfigurationsänderungen, wie Änderungen in den Dateien unterbringt.
Beispielsweise in dem Fall, in dem eine gewünschte Funktion zu einem anderen Knoten übermittelt wird, wird, weil ein Versuch, auf diese Funktion zuzugreifen, bei dem Knoten vor der Übermittlung zu einem Fehler führen wird, eine Planung bei dem Ursprungsgerät (Knoten) ausgeführt, das Zugriffsziel wird geändert zu dem zweiten Kandidaten und der Zugriff wird wieder vorgenommen. In Übereinstimmung mit dieser Technik ist es möglich, einen flexiblen Betrieb in Übereinstimmung mit Bedingungen zu verschiedenen Zeitpunkten in dem System vorzunehmen. Die Verwendung von telnet, ftp und ähnlichem wird innerhalb eines Bereichs gehalten, der als kompatibel vorausbestimmt ist.
Jedoch treten bei der oben beschriebenen Technologie der Vergangenheit die folgenden Probleme auf. Erstens war bei dem Fernprogrammierverfahren (japanische ungeprüfte Patentanmeldungsveröffentlichung H7-182174), weil alle Benutzer die Agent-Betriebsreihen als Anweisungen codieren mussten, die Aufgabe des Programmierens schwierig und es gab eine Einschränkung in Bezug auf die Agent-Flexibilität. Zusätzlich ist es zum Unterbringen einer Änderung in den Bestandteilen der Software, wie zum Beispiel, wenn ein Agent ansprechend auf eine Go-Operation migriert wird, oder ein Knotennamen (Identifizierer des Netzes) eines Gerätes geändert wird, bei welchem ein Element, das zu verwenden war, sich befindet, erforderlich, der Art der Änderung gewahr zu werden, aber es war in der Vergangenheit keine Handhabe vorgesehen, diese Art von Änderung unterzubringen. Zudem ist es zum Unterbringen einer Änderung in einem Bestandteil, erforderlich, eine Unterbringungsanweisungsänderung vorzunehmen. In der Vergangenheit war es jedoch, weil der Zugangszielgerätenahmen explizit spezifiziert war, in Fällen, in denen das Erreichen eines Zwecks nicht möglich war ohne Änderung des Zugangsziels, nicht möglich, an diesem Punkt, die Anweisung zu ändern. Aus diesem Grund gab es Bedarf für eine Technik zum flexiblen Unterbringen einer Änderung in einem Bestandteil. Weil die Häufigkeit der Änderungen zunimmt, je größer der Maßstab des Netzes wird, gab es ein speziell starkes Bedürfnis nach einem Verfahren des Unterbringens solcher Änderungen, wie zum Beispiel offener Netze.
In dem Verfahren nach Etzioni et al. gibt es ein Bedürfnis während der Verarbeitung, gegenseitigen Zugriff zwischen dem lokalen Gerät und dem fernen Gerät fortgesetzt aufrechtzuerhalten und einen kontinuierlichen Informationsaustausch dazwischen vorzunehmen. Aus diesem Grund war es, wenn ein Leitungsfehler während der Verarbeitung auftrat, der eine Unterbrechung der Zugangsroute verursachte, nicht möglich, einen normalen Zugang fortzusetzen. Auch in dem Fall, in dem der Informationsinhalt an einem fernen Knoten regelmäßig in kleinen Mengen bezugrifft wird, oder in welchen es erforderlich ist, eine große Anzahl an Zugriffen auf eine Information an einem fernen Knoten vorzunehmen, und in dem Fall, in dem eine Verarbeitung zu einem Grade in Echtzeit ausgeführt werden muss, gibt es Fälle, in welchen es besser ist, Informationsverarbeitung als einen Prozess der fernen Maschine vorzunehmen.
Gemäß Etzioni et al. führen Agents höherschichtige Aufgaben anstelle eines Benutzers aus, und ein Zielmanager (Goal Manager) empfängt Aufgabenspezifikationen von dem Benutzer und ruft einen Planer auf mit zu erreichenden Zielen. Ein solcher Planer synthetisiert Abfolgen von Betriebssystembefehlen zum Erfüllen von von dem Benutzer empfangenen Anfragen und sendet dann auszuführende Befehle an einen OS-Manager bzw. Offensystemmanager. Der jeweilige OS-Manager behandelt alle Interaktionen zwischen dem ausführbaren Prozess bzw. Agent und seinen Bestandteilen, was eine Kommunikation zwischen Knoten (nachstehend Zwischenknoteninformation genannt), ein Befehlsausführen und eine Zustands- bzw. Statusüberprüfung einschließt. Ein Modellmanager gilt als zentrale Ablage für das Wissen der ausführbaren Prozesse bzw. Agents, logische Positionen speichernd, Betriebssystembefehle und die Systemzustände beschreibend. Ferner ist ein Planer offenbart, der ein anfängliches Ziel erstellt und eine seinen Plan repräsentierende Datenstruktur aufrechterhält. Wenn ein Planer entscheidet, einen Befehl auszuführen, sendet er eine Nachricht an den OS-Manager, den Befehl und seine Argumente detaillierend. Der OS-Manager spricht mit einer Nachricht darauf an, die angibt, ob der Befehlt erfolgreich ausgeführt worden ist, und welche Information erhalten worden ist. Wenn die Ausführung fehlgeschlagen ist, kann der Planer den fehlgeschlagenen Befehl zu einem späteren Zeitpunkt erneut probieren, einen alternativen Befehl auswählen, oder in einen Debugging-Modus eintreten.
Domel P: "Mobile telescript and the web", Digest of papers. Comecon '96. Technologies for the information superhighway., Forty-first IEEE Computer Society International conference (Cat. No. 96CB35911), Comcon '96, (Technologien für den Informations-Superhighway, Kurzfassung von Schriftstücken), Santa Clara, CA, Seiten 52–57, XP002099151, ISBN 0-818-7414-8, 1996, Los Alamitos, CA, USA, IEEE Comput. Soc. Press., USA, offenbart eine Datenverarbeitung, bei der als Mobile-Agent bezeichnete ausführbare Programme eine Datenverarbeitung an einem Knoten eines Netzes mit einer Vielzahl von Knoten ausführt. Gemäß dieser Veröffentlichung gehen Agents zwischen zwei Orten, und insbesondere können interaktive Agents erstellt werden und zu dem Heimatort eines Benutzers gesendet werden zum Vornehmen irgendeiner Handlung, und zum Senden irgendeines Ergebnisses an einen Server, welcher Server Prozeduren basierend auf einem solchen und einem anderen Ort im Netz auszuführenden Ergebnis erzeugen wird. Das Speichern von die Prozessstufe repräsentierender Information innerhalb eines Knotens und/oder das Repräsentieren von Aktionen des ausführbaren Prozesses in der Form von URLs, die verwendet werden zum Steuern des Verhaltens des Agents, werden offenbart. Jedes Mal, wenn ein Agent sich bewegt, nimmt er die Objekte, die er innehat, und seinen Prozesszustand mit sich. Ferner wird ein Agent erstellt und an einen Ort gesendet zum Ausführen irgendwelcher Aktion. Abhängig von dieser Aktion erstellt eine HTTP-Server einen Prozess, der eine Prozedur erzeugen wird, welche letztendlich an einem anderen Ort ausgeführt wird. Es ist möglich, Prozesse durch Aussetzenlassen von ihnen selbst und Wiederaufnehmen der Ausführung an einem unterschiedlichen Knoten in einem Netz zu migrieren durch einfaches Ausführen einer Anweisung "GO".
Die vorliegende Erfindung wurde vorgeschlagen, um die Probleme des Standes der Technik, wie sie oben beschrieben worden sind, zu lösen, und hat ein Ziel des Vorsehens eines Datenverarbeitungsgerätes und eines Datenverarbeitungsverfahrens, die flexibel eine Änderung in einem Bestandteil der Software unterbringen, und die eine erhöhte Immunität in Bezug auf Leitungsausfälle bereitstellen. Speziell ist ein Ziel der vorliegenden Erfindung, ein Verhaltens des Agents, welcher das ausgeführte Element ist, in Übereinstimmung mit einem Plan einzurichten, der basierend auf einer Information erzeugt wird in Bezug auf die Bestandteile der Software. Ein anderes Ziel der vorliegenden Erfindung ist das effiziente Erzeugen eines Plans durch Verbinden von Aktionen basierend auf Vorher-Bedingungen und Nachher-Bedingungen für jede Aktion. Noch ein anderes Ziel der vorliegenden Erfindung ist es, eine effiziente Nutzung der Systemressourcen und der parallelen Verarbeitung vorzunehmen durch Implementieren eines Agents als einen Prozess.
Noch ein anderes Ziel der vorliegenden Erfindung ist es, eine Datenverarbeitungseinrichtung und ein Datenverarbeitungsverfahren bereitzustellen, die imstande sind, flexible Operationen vorzunehmen. Noch ein anderes Ziel der vorliegenden Erfindung ist es, eine Datenverarbeitungseinrichtung und ein Datenverarbeitungsverfahren bereitzustellen, die mit erhöhter Effizienz verarbeiten. Speziell ist es dieses Ziel der vorliegenden Erfindung, flexible Datenverarbeitung durch Durchführen einer Planerzeugung für selbst einen Knoten, der ein Transferziel ist, zu erreichen. Noch ein anderes Ziel der vorliegenden Erfindung ist es, die Effizienz der Planerzeugung durch Trennen der Information, die in der Planerzeugung verwendet wird, in eine Vielzahl von Felder zu verbessern, und durch Verwenden nur der Information in Feldern, die der Art des Agent entsprechen. Noch ein anderes Ziel der vorliegenden Erfindung ist das Unterstützen des Behandelns eines Fehlers in der Migration durch Anhängen einer Vorab-Bedingung an einen Transferbefehl. Noch ein anderes Ziel der vorliegenden Erfindung ist es, eine glatte Datenverarbeitung selbst bei Neuerzeugen eines Plans, in dem Fall, dass eine Planausführung oder eine Übertragung fehlschlägt, auszuführen.
RESÜMEE DER ERFINDUNG
Um die oben erwähnten Ziele zu erreichen, ist ein Aspekt der Erfindung (Anspruch 1) eine Datenverarbeitungseinrichtung, wobei ein ausführbarer Software-Prozess Datenverarbeitung an einem bestimmten Knoten eines Netzes mit einer Vielzahl anderer Knoten ausführt, wobei die Einrichtung umfasst: eine erste Speichervorrichtung zum Speichern einer ersten, einen Zustand von Bestandteilen des Knoten, auf den der ausführbare Prozess zugreifen soll, repräsentierenden Information; eine zweite Speichervorrichtung zum Speichern einer zweiten, Aktionen des ausführbaren Prozesses repräsentierenden Information; eine Planerzeugungsvorrichtung, um ansprechend auf einen gegebenen Anfragecode einen eine Reihe von Aktionen des ausführbaren Prozesses unter Verwendung der ersten und zweiten Information repräsentierenden Plan zu erzeugen; eine Ausführungsvorrichtung zum Ausführen der Reihe von Aktionen des ausführbaren Prozesses an den Bestandteilen basierend auf dem erzeugten Plan; und eine Steuervorrichtung, die eingerichtet ist zur Migration des ausführbaren Prozesses von dem Knoten zu andern Knoten ansprechend auf ein gewisses Ergebnis des Ausführens durch den ausführbaren Prozess.
In diesem Aspekt der vorliegenden Erfindung sind Bestandteile, wie zum Beispiel Datendateien und Funktionsbibliotheken und ähnliches über verschiedene Knoten des Netzes verteilt. Die Domain-Namen, Knoten-Namen, Verzeichnis- und Aufrufprozeduren für jedes der Bestandteile werden als die erste Information gespeichert. Wenn es beispielsweise eine Migration eines Bestandteiles zu einem anderen Knoten gibt, wird die erste Information entweder manuell oder automatisch aktualisiert. Die Inhalte, die mit Hilfe der Datenverarbeitung zu erzielen sind, beispielsweise eine Datei oder ein Suchschlüssel, die Ziel einer Suche sind, werden als Anfragecode eingegeben. Die Aktion des ausführbaren Elementes zum Erfüllen dieses Anfragecodes wird als ein Plan erzeugt. Ein Plan ist ein Satz von Aktionen (Verarbeitungen) und Aktionen schließen eine erste Aktion (go-Aktion) zum Zwecke der Knotenmigration ein. Durch das Ausführen der ersten Aktion innerhalb eines Plans wird das ausführbare Element migriert zu einem anderen Knoten (fernes Gerät), das Ausführen der Aktion und die erforderliche Planerzeugung werden bei dem fernen Gerät fortgesetzt. Wenn eine gegebene Datei ein Objekt ist, werden spezifische Elemente, wie zum Beispiel, auf welchem Knoten zugegriffen werden muss, durch Referenznahme der ersten Information zum Zeitpunkt des Planerzeugens eingerichtet.
Auf diese Weise ist es in diesem Aspekt der vorliegenden Erfindung, weil das Verhalten des ausführbaren Elementes durch den Plan eingerichtet wird, nicht erforderlich für den Benutzer, die Operationsreihe des ausführbaren Elementes zu codieren, hierdurch die Datenverarbeitungseffizienz verbessernd.
Spezifische Knoten, die Zugriffsziele für jeweilige Bestandteile sind, werden basierend auf der ersten Information zum Zeitpunkt des Planerzeugens eingerichtet. Aus diesem Grund wird, selbst wenn es eine Änderung in der Funktion oder einer Datei gibt, diese Änderung im Verhalten des ausführbaren Elementes wiedergespiegelt. Auch, weil es keinen Bedarf für das Fortsetzen der Migration von Information zwischen dem lokalen Gerät und dem fernen Gerät gibt, kann die Verarbeitung, selbst in dem Fall, dass eine unerwartete Bedingungsänderung, wie zum Beispiel eine Unterbrechung der Verbindung zwischen Knoten des Netzes auftritt, fortgesetzt werden.
In einem anderen Aspekt der vorliegenden Erfindung umfasst die oben erwähnte Speichervorrichtung eine Vorrichtung zum Speichern eines Satzes von Aktionen, welche die Einheit für Operationen des ausführbaren Prozesses ist; eine Vorrichtung zum Speichern von Aktionsinformation, die einen Vorher-Zustand einschließt, der repräsentativ ist in Bezug auf ausführbare Aktionen und einen Nachher-Zustand, der repräsentativ ist in Bezug auf eine durch das Ausführen verursachte Zustandsänderung; eine Vorrichtung zum Speichern einer vorgeschriebenen Einschränkungsbedingung des Ausführens der Aktion; und eine Vorrichtung zum Speichern von Information, die repräsentativ ist in Bezug auf einen kausalen Zusammenhang zwischen den Aktionen; wobei die Planerzeugungsvorrichtung eine Vorrichtung umfasst zum Speichern in der zweiten Speichervorrichtung für eine vorgeschriebene Aktion des Satzes von Aktionen mindestens eine neue Einschränkungsbedingung und die Information, die repräsentativ ist in Bezug auf einen kausalen Zusammenhang, basierend auf der Aktionsinformation.
In dem obigen ist es wünschenswert, dass die Planerzeugungsvorrichtung zu dem Satz von Aktionen eine Aktion hinzufügt zur Migration des ausführbaren Prozesses zu dem andern Knoten mit der Vorher-Bedingung einer Aktion, die an dem andern Knoten auszuführen, ist als eine Nachher-Bedingung, zum sequenziellen Auswählen nicht erreichter Ziele als Unter-Ziele, ferner sequenziell Aktionen mit Nachher-Bedingungen auswählt, die die ausgewählten Unter-Ziele erreichen, und für jede solche ausgewählte Aktion, in der zweiten Speichervorrichtung mindestens eines aus der Gruppe bestehend aus einer neuen Einschränkungsbedingung und Information speichert.
Zusätzlich ist es wünschenswert, dass die oben erwähnte Planerzeugungsvorrichtung zu jeder der ausgewählten Aktionen eine ausgewählte Aktion, die eine Vorher-Bedingung einer anderen Aktion angibt, hinzufügt zu der dem kausalen Zusammenhang entsprechenden Aktion.
Es ist auch wünschenswert, dass die oben erwähnte Planerzeugungsvorrichtung jede ausgewählte Aktion, die eine Vorher-Bedingung einer andern Aktion hingibt, und die zu der oben erwähnten Einschränkungsbedingung hinzugefügt werden kann, welche den Verlust der oben erwähnten Vorher-Bedingung vor dem Ausführen der andern Aktion verhindert, zu der oben erwähnten Information hinzufügt, die repräsentativ ist in Bezug auf den kausalen Zusammenhang, und die oben erwähnte Einschränkungsbedingung hinzufügt.
Diese Aspekte der vorliegenden Erfindung arbeiten folgendermaßen. Es ist möglich, für eine Aktion, ausgeführt zu werden, wenn die Vorher-Bedingung erfüllt ist, wobei die Nachher-Bedingung als ein Ergebnis dieses Ausführens erzeugt wird. Mit Hilfe der Information, die den kausalen Zusammenhang repräsentiert, wird eine Aktion, die einen Zielzustand als eine Nachher-Bedingung verursacht, mit einem Zielzustand verbunden, eine Aktion, die eine Vorher-Bedingung für die verbundene Aktion als ihre Nachher-Bedingung erzeugt, wird ferner verbunden. Wenn diese Verbindung in der Umkehrfolge von der der ausführbaren Folge wiederholt wird, wird eine Betriebsablaufserie, die den gewünschten Zustand erreicht, erhalten. Daher wird, weil gemäß der vorliegenden Erfindung ein Plan erzeugt werden kann im Sinne einer verkleinerten Verarbeitung als eine Einheit, die Effizienz der Verarbeitung verbessert werden.
Gemäß einem ferneren Aspekt der vorliegenden Erfindung umfasst in einer Datenverarbeitungseinrichtung, wie sie oben erwähnt worden ist, der ausführbare Prozess einen Agent, wobei der Agent eine Reihe von Software-Prozessen ist, der gegebene Anfragecode umfasst ein gegebenes Ziel; und die Steuervorrichtung ist eingerichtet zum Migrieren des Agent von dem gewissen Knoten zu einem anderen Knoten des Netzes, wenn das Ergebnis des Ausführens durch den Agent an dem Knoten nicht zufriedenstellend ist.
In diesem Aspekt der vorliegenden Erfindung bewegt sich ein Agent nicht nur basierend auf einem Plan zwischen Knoten, sondern es wird auch an dem Zielknoten ein fernerer Plan erzeugt. Aus diesem Grund ist es möglich, die Art der ausgeführten Verarbeitung flexibel abzustimmen in Übereinstimmung mit der Stufe der Planausführung und der Stufe des Zielknotens, hierdurch die Effizienz der Datenverarbeitung verbessernd.
In noch einem anderen Aspekt der vorliegenden Erfindung wird die oben erwähnte Information, die sich an jedem der oben erwähnten Knoten befindet, durch jeden Agent-Typ in eine Vielzahl von Felder aufgeteilt und ferner wird der oben erwähnte Agent-Plan basierend auf dem oben erwähnten Agent entsprechende Feldinformation erzeugt, und eine Migration zwischen Knoten wird ausgeführt, um eine Migration des oben erwähnten Agent zu dem oben erwähnten entsprechenden Feld bei dem oben erwähnten anderen Knoten vorzunehmen. In diesem Aspekt der vorliegenden Erfindung wird beim Erzeugen eines Plans, weil nur dem Agent-Typ entsprechende Information verwendet wird, der erforderliche Suchumfang, reduziert, hierdurch die Effizienz der Planerzeugung verbessernd. Selbst bei einem Migrieren zwischen Knoten, wird weil ein Agent zu einem entsprechenden Feld migriert wird, dieselbe Feldinformation verwendet, wie vor der Migration bei der Planausführung und der Planerzeugung.
In noch einem anderen Aspekt der vorliegenden Erfindung hat der oben erwähnte Agent Information, die repräsentativ ist in Bezug auf den charakteristischen Zustand oder eine Aktion des oben erwähnten Agent, wobei die oben erwähnte Information gemeinsam mit dem oben erwähnten Agent migriert wird, wenn eine Migration zwischen Knoten vorgenommen ist, wobei die oben erwähnte Information gemeinsam mit der oben erwähnten ersten Information und der oben erwähnten zweiten Information zum Ausführen der Planung an dem oben erwähnten anderen Knoten verwendet wird.
In diesem Aspekt der vorliegenden Erfindung wird, weil der Agent gemeinsam mit seiner charakteristischen Information migriert wird, diese Information auch an einem Zielknoten verwendet und es ist möglich, eine Planung vorzunehmen, die geeignet ist für die Zustände und Aktionen der individuellen Agents.
In noch einem anderen Aspekt der vorliegenden Erfindung hängt die oben erwähnte Planerzeugungsvorrichtung beim Erzeugen eines Migrationsbefehls, der einen Agent zwischen Knoten migriert, oder eines anderen Befehls als Teil eines Plans, eine Vorher-Bedingung als Vorbedingung für den oben erwähnten Migrationsbefehl oder den oben erwähnten anderen Befehl an.
In diesem Aspekt der vorliegenden Erfindung wird eine Vorher-Bedingung als eine Basis zu einem Befehl hinzugefügt. In dem Fall, in dem eine auf einem Migrationsbefehl basierende Migration fehlschlägt, besteht die Möglichkeit, dass die Vorher-Bedingung für den Befehl nicht erfüllt worden ist. Weil diese Vorher-Bedingung zu dem Migrationsbefehl angehängt worden ist, kann sie leicht durch Bezugnahme auf den Befehl identifiziert werden, hierdurch sowohl die Identifikation der Ursache der fehlgeschlagenen Migration, als auch die Korrektur der verfehlten Bedingung unterstützend.
Zum Erreichen der oben erwähnten Ziele, ist ein fernerer Aspekt der vorliegenden Erfindung (neuer Patentanspruch 20) ein Datenverarbeitungsverfahren, wobei ein ausführbarer Software-Prozess eine Datenverarbeitung bei einem bestimmten Knoten eines Netzes mit einer Vielzahl anderer Knoten verarbeitet, wobei das Verfahren die Schritte umfasst:

a) Speichern einer ersten, einen Zustand von Bestandteilen des bestimmten Knotens repräsentierten Information zum Zugriff durch den ausführbaren Prozess;
b) Aktualisieren vorbeschriebener Information der gespeicherten Information;
c) Speichern einer zweiten, Aktionen des ausführbaren Prozesses repräsentierenden Information;
d) Eingeben eines der Datenverarbeitung entsprechenden Anfragecodes;
e) Erzeugen eines eine Reihe von Aktionen des ausführbaren Prozesses repräsentierenden Plans unter Verwendung der ersten und zweiten Information ansprechend auf einen gegebenen Anfragecode;
f) Ausführen der Reihe von Aktionen des ausführbaren Prozesses an den Bestandteilen basierend auf dem erzeugten Plan; und
g) Migration des ausführbaren Prozesses von dem Knoten zu einem anderen Knoten ansprechend auf ein gewisses Ergebnis des Ausführens durch den ausführbaren Prozess.

Gemäß noch einem ferneren Aspekt der vorliegenden Erfindung sind Speichermedien zum Speichern eines Computerprogramms darin vorgesehen, welches ein erfindungsgemäßes Datenverarbeitungsverfahren implementiert, wie es durch die Verfahrensansprüche definiert ist.
BESCHREIBUNG DER ZEICHNUNGEN
Es zeigt:
1 ein Funktionsblockdiagramm des Aufbaus einer Datenverarbeitungseinrichtung gemäß der ersten Ausführungsform der vorliegenden Erfindung;
2 ein Ablaufdiagramm der Betriebsprozedur der Datenverarbeitung in der ersten Ausführungsform der vorliegenden Erfindung;
3 ein Ablaufdiagramm der Abfolge der Planerzeugung in der ersten Ausführungsform der vorliegenden Erfindung;
4 ein Baumdiagramm des Inhaltes des in der ersten Ausführungsform der vorliegenden Erfindung erzeugten Plans;
5 ein Ablaufdiagramm der Prozedur für die Agent-Migration der ersten Ausführungsform der vorliegenden Erfindung;
6 eine Zeichnung eines Anzeigebeispiels in der ersten Ausführungsform der vorliegenden Erfindung;
7 ein Funktionsblockdiagramm der Knotenkonfiguration der zweiten Ausführungsform der vorliegenden Erfindung;
8 ein Blockdiagramm der Knotenkonfiguration, die in der Datenverarbeitungseinrichtung der zweiten Ausführungsform der vorliegenden Erfindung enthalten ist;
9 eine Zeichnung des Konzeptes der Aufteilung von Knoten in Felder in der zweiten Ausführungsform der vorliegenden Erfindung;
10 eine Zeichnung einer Vielzahl von Phasen, die einen Betrieb eines Agent in der zweiten Ausführungsform der vorliegenden Erfindung ausmachen;
11 eine Zeichnung des logischen Aufbaus eines Agent in der zweiten Ausführungsform der vorliegenden Erfindung;
12 eine Zeichnung des Ziel-Skript-Satzes in der zweiten Ausführungsform der vorliegenden Erfindung;
13 ein Funktionsblockdiagramm der Funktionen, die Kommunikationen implementieren in Bezug auf den Knotenmanager in der zweiten Ausführungsform der vorliegenden Erfindung;
14 eine Zeichnung des Aufbaus der Wissensbasis in der zweiten Ausführungsform der vorliegenden Erfindung;
15 ein Ablaufdiagramm der Betriebsprozedur des Knotenmanagers in der zweiten Ausführungsform der vorliegenden Erfindung;
16 ein Ablaufdiagramm von Details der Planung in der zweiten Ausführungsform der vorliegenden Erfindung;
17 ein Ablaufdiagramm der Betriebsprozedur zur Planungsausführung in der zweiten Ausführungsform der vorliegenden Erfindung;
18 ein Ablaufdiagramm der Betriebsprozedur des Knotenmanagers bei dem Migrationsursprung in dem Fall der Migration eines Agent zwischen Knoten in der zweiten Ausführungsform der vorliegenden Erfindung;
19 ein Ablaufdiagramm, das die Betriebsprozedur des Knotenmanagers beim Migrationsziel im Falle der Migration eines Agent zwischen Knoten in der zweiten Ausführungsform der vorliegenden Erfindung zeigt;
20 eine Zeichnung des Zustands der Agent-Migration zwischen Knoten über einen Knotenmanager in der zweiten Ausführungsform der vorliegenden Erfindung;
21 ein Ablaufdiagramm der Betriebsprozedur des Agent in der zweiten Ausführungsform der vorliegenden Erfindung; und
22 ein Ablaufdiagramm der Methode zur Planausführung in der zweiten Ausführungsform der vorliegenden Erfindung.
DETAILLIERTE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORMEN
Bevorzugte Ausführungsformen der vorliegenden Erfindung werden nun detailliert unter Bezugnahme auf die relevanten beiliegenden Zeichnungen beschrieben. In den nachstehend beschriebenen Ausführungsformen wird die Umgebung als eine geteilte ? Umgebung angenommen, die ein Netz umfasst mit einer Vielzahl von Knoten, wobei der Begriff "Netz" mit der allgemein akzeptierten Bedeutung des Systems verwendet wird, das Computer verbindet und insbesondere mit der Bedeutung wie z.B. dem Internet, Telefonleitungen und ähnlichem. Der Begriff "Knoten" bezieht sich auf die Agent-Migrationseinheit. Während die Grundannahme getroffen wird, dass es einen Knoten bei einem Host (Hauptrechner) oder Computer gibt, ist es möglich, dass auch eine Vielzahl von Knoten existieren. Eine "verteilte Umgebung" ist eine, in der eine Vielzahl von Computer über ein Netz verbunden existieren, wobei die von jedem der Computer gehaltene Information unterschiedlich ist.
Die Umgebungen, die nachstehend zu beschreiben sind, werden durch Steuern einer CPU (zentrale Verarbeitungseinheit) in Übereinstimmung mit einem Programm bei einem Computer implementiert und eine Vielfalt spezifischer Verfahren der Implementierung sind vorstellbar. Aus diesem Grund präsentiert die folgende Beschreibung die Einrichtung der vorliegenden Erfindung in Form virtueller Schaltungsblöcke wie z.B. dem "XXX-Abschnitt", welche jeweiligen der verschiedenartigen Funktionen davon entsprechen. Die CPU ermöglicht die Implementierung der Aktionen der oben erwähnten virtuellen Schaltungsblöcke während der Verwendung verschiedener Hardware-Ressourcen des Computers wie von dem Programm spezifiziert.
Typische Beispiele von Hardware-Ressourcen sind ein aus Speicherelementen wie RAM-Einrichtungen erstellter Speicher, eine Hilfs-Speichereinrichtung wie z.B. ein Festplattenlaufwerk, eine Eingabeeinrichtung wie z.B. eine Maus oder eine Tastatur, eine Ausgabeeinrichtung wie z.B. eine Anzeigeneinrichtung oder ein Drucker, die mit der CPU über einen Bus und eine Eingabe/Ausgabe-Steuerschaltung verbunden sind. Der Computer ist mit dem Netz über eine Netzverbindungseinrichtung verbunden. Fachleuten wird klar sein, dass dieses bloß spezifische Beispiele von Hardware-Ressourcen sind und es möglich ist, auch andere Arten von Einrichtungen zu dem Zwecke des Erzielens spezifischer Ziele zu verwenden wie z.B. Informationsspeicherung, Eingabe und Ausgabe.
1. Erste Ausführungsform
Das Folgende ist eine Beschreibung der ersten Ausführungsform einer Datenverarbeitungseinrichtung, wie in den Ansprüchen 1 bis 11 wiedergegeben, und eines Datenverarbeitungsverfahrens, wie in den Ansprüchen 12 bis 14 wiedergegeben, wobei Bezug genommen wird auf die relevanten beiliegenden Zeichnungen.
(1) Konfiguration
[Hardware-Konfiguration]
1 ist ein Blockdiagramm, das die Konfiguration dieser Ausführungsform zeigt. Wie in dieser Zeichnung gezeigt, sind in der ersten Ausführungsform eine Vielzahl von Knoten, die Knoten L und R einschließen, mit einem Netz N verbunden. In dieser Anordnung wird Anfragecode eingegeben, der Knoten L, in den der Anfragecode eingegeben wird und bei wem die Verarbeitung gestartet wird, wird lokales Gerät genannt und der Knoten R, der ein Ziel ist, zu welchem ein Agent von dem lokalen Gerät migriert wird, ist als fernes Gerät bekannt. Die Bestandteile der Software, die in der Informationsverarbeitung verwendet werden, sind über diese Vielzahl von Knoten verteilt, ein Agent, der ein ausführendes Element der Software ist, ist an einem der oben erwähnten Knoten aktiv, hierdurch Datenverarbeitung ausführend.
Jeder der Knoten L und R hat eine Lokalinformations-Speichervorrichtung 1 (1L und 1R, diese Bezeichnung wird nachstehend verwendet und entspricht der oben erwähnten ersten Speichervorrichtung), welche Lokalinformation (entsprechend der oben erwähnten ersten Information), die beim Zugriff auf ein Bestandteil verwendet wird, speichert, und eine Aktualisierungsvorrichtung 2, die die oben erwähnte gespeicherte Lokalinformation aktualisiert. Jeder der Knoten L und R hat eine Agent-Informationsspeichervorrichtung 3 (die der oben erwähnten zweiten Speichervorrichtung entspricht) zum Zwecke des Speicherns von Agent-Information (welche der oben erwähnten zweiten Information entspricht), und eine Eingabe/Ausgabe-Vorrichtung 4 (entsprechend der oben erwähnten Eingabe/Ausgabe-Vorrichtung für den Zweck des Eingebens von Eingabecode in bezug auf eine Datenverarbeitung). Die Agent-Information ist eine Information in bezug auf das Verhalten eines Agent und wird sukzessive in Übereinstimmung mit dem Verhalten des Agent selbst aktualisiert.
Jeder der Knoten L und R hat eine Planerzeugungsvorrichtung 5 (die der oben erwähnten Erzeugungsvorrichtung entspricht), welche einen Plan erzeugt, der die von einem Agent zum Zwecke des Befriedigens eines Eingabeanfragecodes vorzunehmende Aktion ausdrückt, die als ein aus einer Vielzahl von Aktionen bestehender Satz erzeugt wird. Wenn erforderlich, schließen in dem von der Planerzeugungsvorrichtung 5 erzeugten Plan eingeschlossene Aktionen eine go-Aktion (der oben erwähnten ersten Aktion entsprechend) zum Zwecke des Implementierens einer Migration eines Agents zwischen Knoten ein (Anspruch 2).
Jeder der Knoten L und R hat eine Planausführungsvorrichtung 6 (die der oben erwähnten Ausführungsvorrichtung entspricht), welche den Betrieb des Agent an den Knoten L und R definiert basierend auf jeder Aktion des oben erwähnten erzeugten Plans, und einen Agent-Steuerabschnitt 7 (welcher der oben erwähnten Steuervorrichtung entspricht), der einen Agent zwischen Knoten migriert basierend auf einer go-Aktion des Plans. Der Agent-Steuerabschnitt 7 funktioniert als Beurteilungsvorrichtung (Anspruch 10), die eine Beurteilung in bezug auf den erzeugten Plan vornimmt.
In dieser Ausführungsform ist die verwendete Hauptinformation die folgende.
[Agent-Information] (Zweite Information)
Die Agent-Information besteht aus verschiedenen Informationen, die das Verhalten des Agent steuern und die durch dieses Verhalten betrieben werden. Speziell sind Beispiele der Agent-Information ein Satz von Aktionen (nachstehend auch als Aktionensatz bezeichnet), Informationen in bezug auf jede Aktion (nachstehend auch als Aktionsinformation bezeichnet) in dem Satz einschließend, Steuerbedingungen in bezug auf die Sicherheit (nachstehend auch als Sicherheitsbedingungen bezeichnet) und eine kausale Verknüpfung (entsprechend der Information, die den oben erwähnten kausalen Zusammenhang repräsentiert). Als erstes ist der Aktionssatz eine Listendarstellung des Satzes von Aktionen, die den Plan ausmachen, welcher erzeugt worden ist, wobei eine Aktion die Einheit des Betriebs ist, der von einem Agent vorgenommen werden kann.
In bezug auf jede Aktion gibt es Aktionsinformation. Aktionsinformation schließt Aktionscode ein, welcher den Aktionsnamen und die Argumente (Parameter) repräsentiert, die Vorher-Bedingung, welche die Vorbedingung ist, welche erforderlich ist zum Ausführen der Aktion und die Nachher-Bedingung, welche die aus dem Ausführen resultierende Zustandsänderung repräsentiert, wobei alle diese als Gegenstände (Items) oder Gegenstandsliste dargestellt sind.
Die Sicherheitsbedingungen für jede der Aktionen in einem Aktionensatz sind Bedingungen, die eine Einschränkung in bezug auf die Abfolge des Ausführens zwischen Aktionen repräsentieren, wobei diese als eine Liste von Aktionscodepaaren repräsentiert werden. Das heißt, jedes der Paare, das die Sicherheitsbedingungen ausmacht, drückt eine Einschränkung aus, dass das erste Element ausgeführt werden sollte vor dem Ausführen des zweiten Elementes. Hier gibt es keinen Zusammenhang zwischen der Abfolge innerhalb des Aktionensatzes und der tatsächlichen Ausführungsabfolge, wobei die Ausführungsabfolge nur durch die Sicherheitsbedingungen eingeschränkt ist.
Eine kausale Verknüpfung in bezug auf irgendeine Aktion, die Teil eines Aktionensatzes ist, ist eine Information, die den kausalen Zusammenhang darlegt, dass das tatsächliche Ausführen einer Aktion es ermöglicht, eine Aktion auszuführen, wobei dies in der Form einer Baumliste vorliegt, die aus Aktionscode besteht, ein Punkt der die Tatsache repräsentiert, dass Aktionen auftreten und Aktionscode, der ausführbar wird wegen dieser Tatsache.
Im Folgenden wird ein Beispiel von Aktionsinformation wiedergegeben
Aktionscode (Action code): grep(File, Keyword)
Vorher-Bedingung (Pre-condition): [file-exists(File)]
Nachher-Bedingung (Post-condition): [add(include(File, Keyword))]
In dem obigen Beispiel ist der Aktionscode " grep(File, Keyword)" der als "grep" bezeichnete Betrieb, welches der Betrieb des Suchens einer Datei mit dem Namen "File" ist zum Bestimmen, ob oder nicht es die Zeichenkette "Schlüsselwort" bzw. "Keyword" einschließt und des Implementierens der Nachher-Bedingung, wenn die Datei diese Zeichen einschließt. Die Vorher-Bedingung drückt die Bedingung aus, welche erfüllt sein muss, wenn diese Aktion auszuführen ist. In diesem Beispiel repräsentiert die Vorher-Bedingung "file-exists(File)", welches dasselbe Format hat wie der oben beschriebene Statuscode, die Bedingung, in welcher eine Datei mit dem Namen "File" existiert.
Die Nachher-Bedingung drückt allgemein eine Tatsache aus, die als ein Ergebnis des Ausführens einer Aktion auftritt. Im obigen Beispiel tritt dies nur auf, wenn die in der Datei vorliegende Zeichenkette existiert. In der Vorher-Bedingung "add(include(File, Keyword))" in diesem Beispiel repräsentiert "include(File,Keyword)" die Tatsache, dass die Datei mit dem Namen "File" die Zeichenkette "Keyword" einschließt. Das "add()" repräsentiert den Betrieb des Addierens der Tatsache, die in der Klammer enthalten ist (in diesem Fall, "include(File,Keyword)") bzw. schließt ein "(Datei, Schlüsselword)" zu dem Agent als Wissen ein. Zum Löschen des Wissens ist die vorgenommene Operation eine von dem Formt "de1()".
[Lokal Information] (Erste Information)
Die Lokalinformations-Speichervorrichtung speichert Lokalinformation. Die Lokalinformation in dieser Ausführungsform ist Information zum Zwecke des Zugriffs auf ein Bestandteil, der ausgedrückt wird als eine Reihe von Items genannten Symbolen. In dieser Ausführungsform sei angenommen, dass der in dem nachstehenden Beispiel gezeigte Statuscode in der Lokalinformation-Speichervorrichtung 1 gespeichert ist. Der Statuscode ist eine Information, die irgendeine Tatsache in bezug auf einen Bestandteil der Software repräsentiert.
maybe(file-exists(file1) at node1)
In diesem Beispiel gibt "maybe()" an, dass die Tatsache innerhalb der Klammer nicht verifiziert worden ist. "file-exists(file1)" gibt an, dass eine Datei mit dem Namen "file1" existiert. Das folgende "at node1". gibt an, dass die oben erwähnte Tatsache (Existenz der Datei file1) an einem Gerät vorliegt, das den Knotennamen "node1" hat. Wenn der Statuscode "maybe()" ist, ist es erforderlich, zu dem Gerät node1 zu migrieren zum Verifizieren, ob oder nicht die oben erwähnte Tatsache (die Existenz der Datei file1 an dem Gerät Knoten 1) existiert. In diesem Fall ist der Knotennamen node1 ein Knotennamen des fernen Gerätes R.
Die Aktualisierung solcher Lokalinformation kann beispielsweise durch den Systemadministrator manuelle vorgenommen werden, die Lokalinformation aktualisierend wenn eine Änderung in dem Bestandteil an irgendeinem Gerät vorgenommen wird. Wenn dies ausgeführt worden ist, ist es möglich, einen flexiblen Betrieb durch Abstimmen der Inhalte, die eingegeben worden sind, um einer spezifischen Situation zu genügen, flexibel auszuführen (Anspruch 3).
Lokalinformation kann auch automatisch aktualisiert werden durch eine Programmreferenz, beispielsweise eine Dateiliste, die die Netzkonfiguration beschreibt. In diesem Fall ist es, weil das Erfassen einer Änderung und die Lokalinformations-Aktualisierung automatisch vorgenommen werden, möglich, die manuelle Eingabe von Information zu eliminieren, hierdurch die Effizienz der Verarbeitung verbessernd (Anspruch 4).
Während es vorstellbar ist, dass die oben beschrieben Agent-Information und Lokalinformation in Form von Textzeichenketten wie oben erwähnt gespeichert werden können, ist es auch möglich, sie erforderlichenfalls in anderen internen Formaten zu speichern, wie z.B. durch Ersetzen von Code mit reservierten Wörtern.
(2) Aktion und Wirkung
In dieser Ausführungsform der vorliegenden Erfindung, die wie oben beschrieben, konfiguriert ist, wird eine Datenverarbeitung auf folgende Weise vorgenommen.
[Request Code Input]
2 ist ein Ablaufdiagramm, das die Verarbeitungsprozedur zur Datenverarbeitung in Übereinstimmung mit dieser Ausführungsform zeigt. Als erstes wird ein Code zum Zwecke des Erreichens eines gewünschten Zustandes durch die Datenverarbeitung als Anfragecode durch einen Benutzer von der Eingabe-Ausgabevorrichtung eingegeben (Schritt 201). Der derart eingegebene Anfragecode wird in der Agent-Informations-Speichervorrichtung 3 gespeichert. In diesem Fall besteht der Anfragecode aus einer Vielzahl von Items. Das Folgende ist ein Beispiel eines solchen Anfragecodes.
file-exist(File) at Node
include-keyword(File,patent)
Im obigen Beispiel ist das "file-exists(File) at Node" der ersten Zeile einer Anfrage zum Finden einer Datei mit dem Namen File auf einem Gerät mit dem Knotennamen Node. Die zweite Zeile ist eine Anforderung, dass die Datei File das Schlüsselwort "patent" einschließt. Demnach repräsentiert dieser Anfragecode eine Anfrage, dass das Netz durchsucht wird nach einer Datei, die das Schlüsselwort "patent" einschließt, mit dem Dateinamen und dem Knotennamen für die Suche spezifiziert.
[Initialization] (Initialisierung)
Als nächstes führt der Agent-Steuerabschnitt 7 eine Initialisierungs-Verarbeitung aus (Schritt 202). Speziell wird die folgende Information separat als Aktionssatz, (action set), Sicherheitsbedingung (safety condition) und kausale Verknüpfung (causal link) innerhalb der Agent-Informations-Speichervorrichtung 3 gespeichert.
Action set: [*start*, *end*]
Safety condition: [(*start*, *end*)]
Causal links [] (empty list)
Zusätzlich wird in bezug auf die Agent-Informations-Speichervorrichtung 3 die folgende Information hinzugefügt und als Aktionsinformation gespeichert. Als erstes wird von dem initialisierten Bedingungen eine Liste von Bedingungen, die von den durch "maybe()" repräsentierten Bedingungen (maybe-Bedingung genannt) abweichen, festgelegt als Nachher-Bedingung für eine Aktion, die den Aktionsnamen "*start*" hat.
Von den initialisierten Bedingungen wird in bezug auf die Bedingung der Form "maybe(cond at node)" (wo die Bedingung cond und der Knoten node die spezifische Bedingung und der Knotennamen sind) die folgende Aktionsinformation hinzugefügt.
Aktion name: go(node)
Pre-condition: []
Post-condition: [add(cond at node)]
Das heißt, dies definiert eine go-Aktion mit einer Nachher-Bedingung (post-condition), die eine Bedingung ist, die sich von der maybe-Bedingung unterscheidet. Dies gibt an, dass eine Aktion, die einen Agent an einen spezifischen Knoten migriert, zu dem Aktionssatz als eine Nachher-Bedingung hinzugefügt worden ist, wobei diese die Vorher-Bedingung (pre-condition) für eine Aktion ist, die zum Vornehmen eines Ausführens an einem spezifischen Knoten dient.
In dieser Ausführungsform wird beispielsweise der folgende Typ von Aktionsinformation hinzugefügt.
[Plan Generation] (Planerzeugung)
Als nächstes wird mit Hilfe der Planerzeugungsvorrichtung 5 ein Plan zum Zwecke des Erfüllens des Anfragecodes erstellt (Schritt 203, Anspruch 5 bis 8 und Anspruch 13). Die Planerzeugung wird durch Aktualisieren von Aktionsinformation während der Bezugnahme auf Lokalinformation vorgenommen, wobei die aktualisierte Aktionsinformation der erzeugte Plan ist. Mit Ausnahme des sich auf die Migration eines Agent beziehenden Teils wird die Prozedur zur Erzeugen eines Plans durch eine bekannte Planungstechnik vorgenommen (Referenz 1: Setsouo Osuga Ed. "Artificial Intelligence Dictionary" SS. 979–988). Diese Planung ist das Erzeugen eines Aktionsplans zum Zwecke des Erzielens eines gegebenen Ziels (goal) in bezug auf ein Aktionselement wie z.B. einen Roboter, das imstande ist, die externe Umgebung zu verändern. Die Eingaben, die zum Zwecke der Planung gegeben sind, sind der Anfangszustand der externen Umgebung, verschiedene Aktionen (acts), die die externe Umgebung ändern und eines oder mehrere Ziele (goals).
Die Planungsprozedur in dieser Ausführungsform wird durch das Ablaufdiagramm der 3 gezeigt. Als erstes wird eine Prüfung in bezug auf nicht erreichte Ziele vorgenommen (Schritt 301). Ein nicht erreichtes Ziel ist eine Bedingung unter den Vorher-Bedingungen jeder Aktion, die einen Aktionensatz bilden, welcher nicht aufgezeichnet ist als eine Tatsache, die in einer kausalen Verknüpfung aufgetreten ist. In dieser Ausführungsform, weil die erste kausale Verknüpfung leer ist, sind die beiden Vorher-Bedingungen der Aktion "*end*" unerreichte Ziele.
In dem Fall, indem es kein unerreichtes Ziel gibt, wird die Planerzeugung beendet. Wenn ein unerreichtes Ziel existiert, wird jedoch ein unerreichtes Ziel als Unterziel (subgoal) ausgewählt (Schritt 302). In dieser Ausführungsform wird beispielsweise "file-exists(File) at Node" als ein Unterziel ausgewählt. Als nächstes werden beim Schritt 303 Aktionen zusammengruppiert, um das oben erwähnte Unterziel als eine Nachher-Bedingung in bezug auf das ausgewählte Unterziel zu erreichen.
Wenn die Bedingungen das Unterziel (subgoal) erreichen, ist es durch Einsetzen geeigneter Items in die Variablen dieser Bedingung möglich, Koinzidenz mit dem Unterziel zu erzielen. Speziell bedeutet eine Aktion, die ein Unterziel erzielt, eine Aktion, die eine Nachher-Bedingung hat, die mit der Vorher-Bedingung des ausgewählten Unterziels koinzidiert im Hinblick auf Elemente, die keine Variablen sind. In dieser Ausführungsform ist beispielsweise nur die Aktion "go(node1)" gelistet.
Dann wird eine Prüfung dahingehend vorgenommen, ob überhaupt eine Aktion gelistet werden könnte (Schritt 304) und wenn sie nicht könnte, wird erneut eine Unterzielauswahl vorgenommen, was als Zurückaufspürungs-Verarbeitung (backtracking processing) bekannt ist (Schritt 302).
Dann wird eine Aktion von den gelisteten Aktionen ausgewählt (Schritt 305), die die ausgewählte Aktion zu der kausalen Verknüpfung hinzugefügt hat, die die Vorher-Bedingungen anderer Aktionen in Übereinstimmung mit den Unterzielbedingungen hingeben. Die ausgewählte Aktion, die die Vorher-Bedingung einer anderen Aktion hingibt und zu der eine Sicherheitsbedingung hinzugefügt werden kann, die den Verlust der Vorher-Bedingung vor dem Ausführen der anderen Aktion verhindert, wird zu der kausalen Verknüpfung in Übereinstimmung mit den Unterzielbedingungen hinzugefügt.
Speziell wird die oben erwähnte Verarbeitung folgendermaßen ausgeführt. Als erstes werden die kausale Verknüpfung und das unerreichte Ziel aktualisiert basierend auf der Aktionsinformation der Aktion (Schritt 306). Die Aktualisierung der kausalen Verknüpfung wird durchgeführt durch Vornehmen des oben beschriebenen Ersetzens in bezug auf die Aktionsinformationselemente (Aktionscode, Vorher-Bedingung und Nachher-Bedingung) und durch Hinzufügen der kausalen Verknüpfung des Aktionscodes, des Unterziels und des Aktionscodes einer Aktion, die das Unterziel als eine Vorher- Bedingung hat. Gleichzeitig hiermit wird die Vorher-Bedingung dieser Aktionsinformation erneut zu dem unerreichten Ziel hinzugefügt. In dieser Ausführungsform wird beispielsweise die Aktion "go(node1)" ausgewählt, was zu der folgenden Aktualisierung der kausalen Verknüpfung und des unerreichten Ziels führt.
Causal links: [(go(node1),file-exists(File at node1, *end*)]
Unachieved goal: [include-keyword(File,patent)]
[Threat Detection] (Threat-Erfassung)
Als nächstes wird bei Schritt 307 eine Prüfung vorgenommen zum Bestimmen, ob oder nicht die ausgewählte Aktion einen Verlust einer anderen Kausalverknüpfungsbedingung verursachen würde, d.h., einen Verlust eines Zustandes, der die Vorher-Bedingung für eine andere Aktion ist (Schritt 307). Wenn ja, ist diese Bedingung als ein "threat" bekannt. In dieser Ausführungsform verursacht die ausgewählte go-Aktion keinen Verlust dieser Bedingung. Das heißt, die go-Aktion verursacht nicht allgemein einen Verlust einer Bedingung. Die go-Aktion verursacht keinen Verlust, weil es keine Aktion gibt, die wegen einer Knotenmigration unmöglich wird.
Wenn ein Threat existiert, wird eine Prüfung vorgenommen, um zu sehen, ob es möglich ist, die Sicherheitsbedingung zu aktualisieren, um diesen Threat zu vermeiden (Schritt 308). Aktualisieren der Sicherheitsbedingung ist in dem folgenden Fall möglich.
Beispielsweise ist dieser Fall, in welchem wenn in bezug auf eine Gruppe, die zu einer kausalen Verknüpfung hinzugefügt worden ist (Aktion 1, Bedingung, Aktion 2) es möglich ist, das Paar (Aktion 1, Aktion 2) der Sicherheitsbedingung ohne Veranlassen eines Konfliktes hinzuzufügen und wenn ein Threat existiert, d.h., wenn in bezug auf eine andere kausale Verknüpfung (Aktion 3, Bedingung 2, Aktion 4) Aktion 1 den Verlust von Bedingung 2 verursacht, ist es möglich, das Paar (Aktion 3, Aktion 1) oder das Paar (Aktion 4, Aktion 1) zu der Sicherheitsbedingung ohne Veranlassen eines Konflikts hinzuzufügen.
In dem Fall, in dem es nicht möglich ist, die Sicherheitsbedingung zu aktualisieren, werden die aktualisierten Zustände der kausalen Verknüpfung und des unerreichten Ziels zu jenen vor der Aktualisierung zurückgeführt (Schritt 310) durch sogenanntes Rückwärtsaufspüren (backtracking), einer Verarbeitung, die noch einmal von dem Auswählen einer Aktion ausgeführt wird. In dem Fall, in dem Sicherheitsbedingungs-Aktualisierung möglich ist, wird die oben beschriebene Aktualisierung der Sicherheitsbedingung (Addition eines Paars) bei Schritt 309 vorgenommen.
In dieser Ausführungsform ist, weil das Paar "(go(node1), *end*)" konfliktfrei zu der Sicherheitsbedingung hinzugefügt werden kann, als ein Ergebnis der Aktualisierung die Sicherheitsbedingung "[go(node1),*end*),(*start*,*end*)]. Daraufhin wird die Verarbeitung wieder vom Schritt 301 wiederholt. Auf diese Weise ist es durch wiederholte Verarbeitung unter Bezugnahme auf die erforderliche Lokalinformation möglich, Hinzufügungen zu der kausalen Verknüpfung auszuprobieren für alle Aktionen, die zu jeweiligen der unerreichten Ziele korrespondieren.
Das heißt, eine Aktion kann ausgeführt werden, wenn ihre Vorher-Bedingung erfüllt ist, wobei das Ergebnis des Ausführens die Nachher-Bedingung ist. Eine Aktion, die das Auftreten eines gewünschten Zielzustandes als ihre Nachher-Bedingung veranlasst, wird durch eine kausale Verknüpfung mit dem Zielzustand verbunden und eine fernere Verbindung wird vorgenommen zu einer Aktion, die die Vorher-Bedingung der verbundenen Aktion als deren Nachher-Bedingung veranlasst.
Auf diese Weise wird durch Wiederholen der Verbindung in der Umkehrfolge von der der Ausführungsfolge eine Operationsserie erhalten, die den gewünschten Status erzielt. Demnach wird in der vorliegenden Erfindung, weil ein Plan erzeugt wird bezüglich einer Kleinbereichsverarbeitung als eine Einheit, die effizient die Verarbeitung verbessert.
[Agent Information Updating] (Agent-Informations-Aktualisierung)

In dieser Ausführungsform ist nach dem Wiederholen des Abschließens der Verarbeitung die Information, die in der Agent-Informations-Speichervorrichtung 3 gespeichert ist, die folgende.

Action set:	[grep(File,patent),go(node1)]
Safety condition:	[(grep(File,patent),end), (go(node1),end),(start,end)]
Causal links:	[(grep(File,patent), include(File,patent),end), (go(node1),file-exists(File) at node1,end*)]
Unachieved goal:	[file-exists(File)]

4 zeigt die Inhalte dieser Aktionsinformation als ein Baumdiagramm (Planbaum).
[Plan Evaluation] (Plan Evaluierung)
Wenn ein Plan wie oben beschrieben erzeugt wird (Schritt 203 der 2), wird eine Beurteilung getroffen in bezug auf das Auftreten des Plans (Schritt 204; Anspruch 10). Wenn hierbei ein unerreichtes Ziel existiert und die Aktion auf leer festgelegt wird, wird die Planerzeugung als fehlgeschlagen beurteilt. In dem Fall, in dem kein unerreichtes Ziel vorliegt, ist die Planerzeugung erfolgreich und der Anfragecode wird als sein Ziel erreicht habend beurteilt ohne tatsächliches Ausführen des Plans. Wenn ein unerreichtes Ziel existiert und die festgelegte Aktion nicht leer ist, wird die Beurteilung getroffen, dass die Planerzeugung erfolgreich gewesen ist und das Ausführen des Plans ist erforderlich.
In dem Fall, in dem die Planerzeugung erfolgreich ist und der Anfragecode erreicht worden ist, und in dem Fall, in dem die Planerzeugung selbst fehlgeschlagen ist, informiert der Agent den Benutzer hiervon über die Eingabe/Ausgabe-Vorrichtung 3 (Schritt 205) und die gesamte Prozedur wird beendet. Wenn der Agent von dem Ursprungslokalgerät L migriert wird und der Anfragecode erreicht wird oder die Planerzeugung fehlschlägt bei dem fernen Gerät R, kehrt der Agent zu dem lokalen Gerät L zurück und gibt eine Information bezüglich dieser Wirkung aus. Auf diese Weise werden in dieser Ausführungsform die Ergebnisse der Planerzeugung evaluiert, die Verarbeitung wird basierend auf dieser Evaluierung ausgewählt, hierdurch die Effizienz der Verarbeitung verbessernd.
[Plan Execution] (Planausführung)
Die Planausführungsvorrichtung 6 sucht nach einer ausführbaren Aktion, die nicht eine go-Aktion ist (Schritt 205; Anspruch 9). Unter den Aktionen in einem Aktionensatz ist eine ausführbare Aktion eine, für die die Vorher-Bedingung momentan erfüllt wird, und auch eine, die nicht ausgeführt werden braucht nach einer anderen Aktion in Übereinstimmung mit einer Sicherheitsbedingung.
Wenn es eine ausführbare Aktion gibt, die keine go-Aktion ist (Schritt 207), wird diese Aktion ausgeführt (Schritt 208), die Prozedur wird noch einmal vom Schritt 206 ausgeführt. Wenn es keine ausführbare Aktion gibt, die keine go-Aktion ist, wird eine go-Aktion ausgeführt (Schritt 209).
Demnach wird in dieser Ausführungsform, weil eine ausführbare Aktion, die keine go-Aktion ist, ausgeführt wird vor dem Ausführen einer go-Aktion, die Neu-Migration eines Agent zurück zum Ursprungsknoten minimiert, hierdurch die Effizienz der Verarbeitung verbessernd.
In dem Beispiel dieser Ausführungsform, an einen Punkt, an dem die Planausführung beginnt, gibt es die Aktion "grep(File.patent" als eine Aktion, die keine go-Aktion ist. An diesem Punkt kann jedoch die Aktion, weil die Vorher-Bedingung für diese Aktion noch nicht erreicht worden ist, nicht ausgeführt werden, was dazu führt, dass es keine andere ausführbare Aktion gibt als die go-Aktion. aus diesem Grund wird die Aktion "go(node1)" ausgeführt.
Wenn die go-Aktion interpretiert und ausgeführt wird, informiert die Planausführungsvorrichtung 6 den Agent-Steuerabschnitt 7 von dieser Wirkung, wobei der Agent-Steuerabschnitt 7 die nachfolgend beschriebene Agent-Migrationsverarbeitung ausführt.
[Agent-Transfer] (Agentübertragung)
Beim Migrieren eines Agents wird die folgende Prozedur zwischen dem Agent-Kontrollabschnitt 7L, der nachstehend als lokalseitig bezeichnet wird (auf der Lokalgeräteseite und dem Agent-Steuerabschnitt 7R, der nachstehend als fernseitig bezeichnet wird) auf der fernen Seite ausgeführt über das Netz N (Patentansprüche 1 und 14. 5 ist ein Ablaufdiagramm, das die Prozedur des Migrierens des Agents zeigt.
Zuerst wird eine Agent-Akzeptanzanfrage von der Lokalseite zu der Fernseite gesendet (Schritt 501). Auf den Empfang der Anfrage (Schritt 502) legt die Fernseite den Prozess für den Agent fest, um für die Akzeptanz des Agents vorzubereiten (Schritt 503), woraufhin der Lokalseite mitgeteilt wird, dass sie bereit ist (Schritt 504).
Auf den Empfang der oben erwähnten Bereitschaftsmitteilung (Schritt 505) liest die Lokalseite die Agent-Information innerhalb der Agent-Informationsspeichervorrichtung 3 und sendet sie an die Fernseite (Schritt 506). (Die migrierte Agent-Information schließt den internen Status des Agents zum Zeitpunkt, wenn die go-Aktion interpretiert und ausgeführt worden ist, ein). Wenn sie die Agent-Information empfängt (Schritt 507), speichert die Fernseite die empfangene Agent-Information der Agent-Informationsspeichervorrichtung 3 (Schritt 508), informiert die Planausführungsvorrichtung 6 von dieser Wirkung, veranlasst den Start der Interpretation und des Ausführens (Schritt 509) und sendet eine Meldung an die Lokalseite, dass die Akzeptanz des Agents erfolgreich ist (Schritt 510).
Die Lokalseite löscht auf den Empfang der Meldung des Erfolgs hin (Schritt 510) den Agent-Prozess (Schritt 512) und gibt nun Ressourcen frei, wie zum Beispiel unnötige Speicher, hierdurch die Agent-Migration beendend.
In dem Beispiel dieser Ausführungsform wird nach der Migration die folgende Information in dem Lokalgeräteknoten 1 des fernen Gerätes gespeichert.
file-exists(file1)
Zusätzlich wird der Fall betrachtet, in dem tatsächlich eine Datei mit dem Namen file1 am dem Gerät node1 existiert und dass diese Datei die Zeichenkette "patent" enthält. In diesem Fall führt der Agent, nachdem er zu dem Gerät node1 migriert worden ist, die Planerzeugung erneut aus, beginnend von der Initialisierung. Als ein Ergebnis ändert sich die in der Agent-Informationsspeichervorrichtung 3 gespeicherte Information folgendermaßen.
Wegen dieser Änderungen ist die Planerzeugung erfolgreich und weil das Ausführen der Aktion "grep(file1.patent" einen Erfolg des Plans verursacht, wird der Agent zurückgegeben zu dem lokalen Gerät und der Benutzer wird von dieser Wirkung benachrichtigt. 6 ist ein Beispiel der Ausgabe des Ausführungsergebnisses. In diesem Beispiel werden in dem Anzeigefenster die Ausführungsergebnisse 501 gemeinsam mit dem Anfragecode als letztendliches Ziel (final goal) 500 angezeigt.
Selbst in dem Fall, in dem die Datei file1 zu einem anderen Gerät migriert wird, kann, wenn Information, wie zum Beispiel "maybe(file-exists(file2) at node2) oder ähnliches stattdessen in der Lokalinformationsspeichervorrichtung gespeichert wird, eine Neuplanung den Agent zu dem Gerät node2 bewegen, was das Erreichen des Ziels ermöglicht, hierdurch flexible Unterbringung einer sich ändernden Umgebung ermöglichend.
Wie oben beschrieben gibt es in Übereinsstimmung mit dieser Ausführungsform der vorliegenden Erfindung, weil Agent-Verhalten durch einen Plan festgelegt wird, keinen Bedarf für den Benutzer, eine Reihe von Agent-Operationen zu codieren, hierdurch die Effizienz der Datenverarbeitung verbessernd.
Insbesondere, wenn spezifische Knoten, die Zugangsziele jedes Bestandteils sind, basierend auf Lokalinformation eingerichtet beim Erzeugen eines Plans. Aus diesem Grund, selbst wenn es eine Änderung der Funktion oder einer Datei gibt, wird diese Änderung im Verhalten des Agents reflektiert. Auch weil es keinen Bedarf für das Fortsetzen der Migration von Information zwischen dem lokalen Gerät und dem fernen Gerät gibt, ist es möglich, die Verarbeitung fortzusetzen, selbst wenn es eine unerwartete Änderung der Bedingungen, wie zum Beispiel eine Unterbrechung einer Verbindung zwischen Knoten des Netzes gibt.
2. Zweite Ausführungsform
Die zweite Ausführungsform der vorliegenden Erfindung ist eine Datenverarbeitungsvorrichtung, die weitgehenden Aufbau, wie die erste Ausführungsform hat (1), wobei die Konfiguration und der Betrieb davon detaillierter spezifiziert sind, speziell in Bezug auf die Neuplanung, die vorgenommen werden kann an einem Migrationszielknoten in dem Fall, dass dies erforderlich ist wegen beispielsweise eines Fehlers des Ausführens eines Plans.
(1) Konfiguration
(1-1) Gesamtkonfiguration
Die zweite Ausführungsform ist ähnlich der ersten Ausführungsform eine Datenverarbeitungseinrichtung, die Daten mit Hilfe der Operation eines Agents, der ein ausführendes Element in der Software ist, an einer Vielzahl von Knoten verarbeitet, die über ein Netz verbunden sind. 7 ist ein Funktionsblockdiagramm, welches die Konfiguration jedes Knotens zeigt, der an das Netz N in der zweiten Ausführungsform angeschlossen ist. Wie in dieser Zeichnung gezeigt, hat jeder Knoten eine Feldwissensbasis 11, eine Knotenwissensbasis 12, einen Planer 13, eine Ausführungsmaschine 14, einen Knotenmanager 15 und einen Aktualisierer 16.
Speziell hat jeder Knoten Lokalinformation als erste Information, die zur Verwendung beim Zugreifen auf ein an dem Knoten befindliches Standteil vorgesehen ist. Die Feldwissensbasis 11 und die Knotenwissensbasis 12, welche Datenbanken sind, speichern diese erste Information, dieses entsprechend der Lokalinformationsspeichervorrichtung in der ersten Ausführungsform. Das heißt, die Lokalinformation schließt einen Teil ein, der aufgeteilt ist in eine Vielzahl von Feldern, die Agent-Typen entsprechen, und einen Teil, der charakteristisch ist für den Knoten, welcher jeweils in der Feldwissensbasis 11 und bzw. der Knotenwissensbasis 12 gespeichert sind. Begriff Feld ist eine Einheit innerhalb des Knotens, die eine individuelle Wissensbasis hat, wobei die in der Feldwissensbasis 11 gespeicherte Information eine Gruppe von Informationen ist, die nur für Agents verwendet werden für eine spezifische Art von Agent, das heißt, für einen Agent für einen speziellen Zweck oder ein Feld.
In der zweiten Ausführungsform hat jede der Wissensbasen 11 und 12 zusätzlich zu der oben erwähnten Lokalinformation zweite Information darin gespeichert, die sich auf die Aktion bezieht, die von dem Agent ausgeführt werden kann. Der Planer 13 ist ein Teil, welcher basierend auf dieser ersten und zweiten Information eine Planung zum Erzeugen eines Plans zum Ausführen durch den Agent 17 vornimmt, um einen gegebenen Zweck zu erreichen, dieses in Entsprechung zu der Planerzeugungsvorrichtung in der ersten Ausführungsform.
Die Ausführungsmaschine 14 ist ein Teil, der den erzeugten Plan ausführt, dies in Entsprechung zu der Planausführungsvorrichtung in der ersten Ausführungsform. Der Knotenmanager 15 ist der Teil, der zum Zwecke des Erzeugens/Löschens eines Agents vorgesehen ist und zum Migrieren eines Agents zwischen Knoten, dies in Entsprechung zu dem Agent-Steuerabschnitt der ersten Ausführungsform. Der Planer 3 und die Ausführungsmaschine 14 jeden Knotens führen einen Plan aus, und wenn erforderlich, erzeugen sie einen Plan selbst für einen Agent, der von einem anderen Knoten migriert worden ist (Patentansprüche 16 und 24).
Die von der ersten Information repräsentierte Information ist eine Information in bezug auf die Software-Elemente an dem Knoten, und spezieller sind dies solche Gegenstände bzw. Items, wie der Status des Knotens und Dateien, Datenbanken und Software, die sich an dem Knoten befinden. Die zweite Information in bezug auf Aktionen wird für jeden Knoten individuell definiert.
Beim Erzeugen eines Agent-Plans ist der Planer 13 konfiguriert, um den Plan basierend auf einer dem Agent entsprechenden Feldinformation zu erzeugen. Der Knotenmanager 15 ist derart konfiguriert, dass ein Agent, wenn er zwischen Knoten migriert, migriert wird zu einem entsprechenden Feld an dem Migrationszielknoten (Patentansprüche 17 und 25). Um die Migration zu einem vorgeschriebenen Feld an einem Migrationsziel eines Agents zu veranlassen, ist es unter Migrationsbefehlen, die in dem Plan enthalten sind, möglich, ein Feld als einen Parameter eines Befehls in einem vorgeschriebenen Format zu spezifizieren.
Der Aktualisierer 16 ist ein Teil, der im Fall, in welchem die Planung, Planausführung oder Migration in Übereinstimmung mit einem Plan fehlschlägt, Information korrigiert, die den Fehler verursacht, dies in Entsprechung zu der Aktualisierungsvorrichtung in der ersten Ausführungsform (Patentanspruch 23).
Knoten verwenden eine GUI-Anwendung 18 bzw. graphische Benutzerschnittstellenanwendung 18 als Benutzerschnittstelle.
Die Benutzerschnittstelle ist eine Software zum Zwecke der direkten Überwachung des Status des Agents durch den Benutzer, dies in Entsprechung zu der Eingabe-/Ausgabe-Vorrichtung der ersten Ausführungsform. Weil es tatsächlich einen Agent in der Software gibt, ist es für den Benutzer notwendig, auf den Status davon zuzugreifen und ihn zu kontrollieren, was eine Software erfordert, die eine Benutzerschnittstelle hat, und die GUI-Anwendung 18 wird als diese Software verwendet. Information in bezug auf das Management von Ressourcen, wie zum Beispiel Speicher, an jedem individuellen Knoten wird in der Knotensteuerinformationsspeichervorrichtung 19 gespeichert.
8 zeigt eine spezifische Knotenkonfiguration, die in einem Beispiel der zweiten Ausführungsform angenommen wird. In diesem Beispiel ist das angenommene System eine Datenverarbeitungseinrichtung, in der drei Knoten X, nämlich node0, node1 und node2, mit dem Netz N verbunden sind. Jeder Knoten X hat ein Feld F mit dem Namen make, wobei die anderen Felder weggelassen sind. Das heißt, in diesem Beispiel der Knotenkonfiguration in der zweiten Ausführungsform werden in der von einer Anzahl von Personen entwickelten Software beispielsweise eine Vielzahl von Quellendateien, die innerhalb des Netzes verteilt sind, zu irgendeinem Zeitpunkt als an einen spezifischen Knoten gesammelt angesehen, wobei die Beschreibung des folgenden die der Verarbeitung an einem speziell ausgewählten Teil davon ist.
Wie in 8 gezeigt, hat der Agent A Information in bezug auf seinen charakteristischen Status oder Aktionen und diese Information ist in der Wissensbasis DA innerhalb des Agents gespeichert. Der Agent A führt diese Information mit sich selbst wenn er zwischen Knoten migriert, wobei diese portierte Information bei der Planung verwendet wird (Anspruch 18).
(1-2) Allgemeine Agent-Konfiguration
Ein Agent ist ein Prozess, der an einem Knoten in Übereinstimmung mit einem Ziel (goal) auftritt, das entweder durch einen Benutzer oder eine andere Software gegeben wird, die dieses System verwendet. Der Begriff Knoten bezieht sich auf die Einheit der Migration eines Agent, was ein abstraktes Konzept ist. Während die gewöhnliche Annahme ist, dass ein einzelner Knoten in bezug auf ein einzelnes Host-Gerät existiert, ist es auch möglich, dass es eine Vielzahl von Knoten gibt, die an einem Host-Gerät existieren. Der Benutzer gibt dem Knoten einen Namen, der einzigartig ist, innerhalb des Netzes. In diesem Fall wird ein Name möglicherweise einem Knoten zugewiesen, der dasselbe Namengebungsverfahren verwendet, wie in einem existierenden Computernetz, wie zum Beispiel dem Fall des URL (Universal Resource Locator bzw. universeller Ressourcenlokalisierer). Der oben erwähnte "Prozess" ist die Einheit des Ausführens von Software auf einem Computer, der von einem Betriebssystem gemanagt wird.
9 ist eine Zeichnung, die eine Umgebung in dem Fall eines Plan-Agents zeigt als einen Mobil-Agent, wobei diese Konzeptzeichnung die Trennung von Knoten in Felder zeigt. Was tatsächlich in Felder getrennt wird, sind die erste Information und die zweite Information, die in jedem Knoten gespeichert sind, wobei diese Information als Lokus bzw. Ort für die Aktivitäten des Agents, wie zum Beispiel die Planerzeugung und die Planausführung durch einen Agent dient. Demnach gibt es durch Aufteilen der Information an einen Knoten eine Vielzahl von Feldern, die als Ort der Agent-Aktivitäten dienen.
Die in der Zeichnung gezeigten Umgebungsbestandteile schließen den sich permanent an dem Host H befindlichen Knoten X ein, das innerhalb des Knotens X aufgeteilte Feld F, und den Agent A, der zu dem Knoten X über das Netz migriert.
Das Ziel eines Agents, wie diesem ist das Erreichen eines in einem vorgegebenen Format als einen Zweck zur Datenverarbeitung gegebenen Ziels. Ein Beispiel eines solchen Ziels (goal) ist das Suchen nach einer spezifischen Datei, von der angenommen wird, dass sie an irgendeinem anderen Knoten existiert, und zum Holen einer Kopie davon. Aus diesem Grund erzeugt der Agent einen Plan zum Erfüllen des gegebenen Ziels und führt ihn aus. Wenn erforderlich zum Erreichen des Ziels, kann der Agent an einen anderen Knoten migrieren. Die Verarbeitung, die sich auf die Planerzeugung und Ausführung eines Agents und die Migration zwischen Knoten eines Agents bezieht, wird tatsächlich von dem Planer 13, dem Knotenmanager 15 und anderen Elementen implementiert.
Ein erzeugter Agent erreicht letztendlich einen Zustand, in welchem er sein Ziel erreicht hat oder in welchem das Erreichen des Ziels unmöglich wird, an welchem Punkt er aufhört zu existieren. Der Fall, in dem das Ziel erreicht wird, ist als Normalabschluss des Agents bekannt und der, in dem das Erreichen des Ziels unmöglich wird, ist als Komplettverfehlen des Agents bekannt. Wenn der Agent aufhört zu existieren, wird die Abschlussverarbeitung (Termination Processing, auch Auflösungs- od. Auslöse-Verarbeitung) aufgeführt.
10 ist ein Zustandsübergangsdiagramm, das die verschiedenen Phasen in den Aktivitäten eines Agents zeigt. Speziell führt ein Agent, sobald er erzeugt ist, eine Datenverarbeitung aus während des Wiederholens der drei Phasen, die aus der Planungsphase P, der Ausführungsphase E und der Migrationsphase M bestehen.
(1-3) Logischer Aufbau eines Agents
Wenden wir uns nun 11 zu, die den logischen Aufbau eines Agents in der zweiten Ausführungsform zeigt, wir sehen, dass ein Agent einen Agent-Namen hat, einen entsprechenden Feldnamen und Daten, wie zum Beispiel eine Datei oder Dateien haben kann. Die Dateien eines Agents sind Dateien, die Teil des Agents selbst sind. Mit einem Agent, der zu einem anderen Knoten migriert worden ist, und Kopien seiner Dateien zu dem Ursprungsknoten zurücküberträgt, ist es möglich, Daten effizient zu sammeln, wenn der Zweck das Sammeln von Dateien ist. Zusätzlich zu den oben erwähnten Items hat ein Agent die folgenden Bestandteile.
Als erstes ist der Ziel-Stapel 5 ein Stapel von Zielen während des Ausführens, der vorgesehen ist zum Zwecke des Vornehmens hierarchischer Planung. Der Ziel-Stapel S wird als ein Satz von Zielskripten (Goal Script) gehalten. Dieser Zielskriptesatz ist ein Satz aus dem letztendlichen Ziel und Unterzielen und aus Skripten zum Zwecke des Erzielens dieser Ziele, welche alle Skripte einschließen, die der Agent zu irgendeinem speziellen Zeitpunkt hat.
Die Agent-Wissensbasis DA ist eine Wissensbasis, die von dem Agent gemeinsam mit der Knotenwissensbasis und der Feldwissensbasis bei der Planung verwendet wird. Das Element "anderes" ("other"), das in 11 gezeigt ist, kann beispielsweise Ausführungsinformation sein. Ausführungsinformation schließt solche Items ein, wie einen Agent-Namen, Feldnamen, Ausführungsposition für ein Skript und variable Werte, die einem Skript verwendet werden. Es ist auch möglich, dass die "other"-Information beispielsweise Information sein kann in bezug auf die Spezifizierung der Abschlussverarbeitung. Die tatsächliche Datenstruktur, die diese Arten von Informationen repräsentieren, können abhängig von der Agent-Phase unterschiedlich sein. Beispielsweise kann es während der Migrationsphase Kommunikationsinhalt im Netz sein, während der Ausführungsphase kann es eine Dateistruktur im Speichermedium sein und während der Planungsphase kann es eine Datenstruktur in dem im Computerspeicher gespeicherten Programm sein.
Der Grund, weshalb die Ziele als eine Stapelstruktur ausgedrückt sind, ist, dass ein Ziel, das von einem Benutzer gewöhnlicher Weise gegeben wird, eine hierarchische Struktur hat aufgrund des Planungsprozesses. Das heißt, ein erneut erstelltes Unterziel muss hierarchisch in Stapelform innerhalb des Agents gespeichert werden. Die Zielskriptsatz-Datenstruktur, die den Zielstapel ausmacht, ist in 12 gezeigt.
In 12 ist das Ziel bzw. "goal" eine Anfrage, die entweder von einem Benutzer gegeben wird, der den Agent verwendet oder durch eine andere Software. Wenn wir einen beliebigen Zielskriptsatz annehmen, kann man sich vorstellen, dass ein Ziel ein Unterziel sein kann. Das heißt, ein Unterziel kann ein Ziel sein, das die Aufteilung einer Bedingung ist, die erforderlich ist zum Erfüllen eines Ziels, das dem Agent als erstes gegeben wird.
Die Unterziele, die in der zweiten Ausführungsform erzeugt werden können, sind von zwei Arten: ein Unterziel, wenn ein Fehler auftritt, und ein Unterziel während der Planung. Das Fehlerunterziel ist ein Unterziels, das zum Zwecke des Versuchs des Ausführens eines Befehls in einer unterschiedlichen Form in dem Fall erzeugt wird, in welchem das Ausführen eines Skripts durch einen Agent fehlschlägt in Bezug auf einen spezifischen Befehl. In diesem Fall, beispielsweise, wenn es der erste Kandidatenknoten für die Adresse einer Datei versäumt, zu dem Entdecken der Datei zu führen, ist es das Unterziel, welches die Datei an dem zweiten Kandidatenknoten entdeckt. Ein Planungsunterziel ist ein Unterziel, das enthalten ist innerhalb eines Skriptes als Ergebnis der gewöhnlichen Planung. Beispielsweise, wenn ein Ziel das Entdecken und Holen einer Datei ist, ist das anfängliche Entdecken der Datei oder die Migration zu einem anderen Knoten zum Zwecke des Entdeckens der Datei ein Unterziel.
Ein Unterziel kann ferner ein Unterziel haben wobei die Gesamtstruktur der Ziele hierarchisch ist. Der Zielstapel bzw. "goal stack" wird von einem momentan ausführenden Agent gehalten und ist ein Stapel, der die hierarchische Zielstruktur steuert. Der Agent hält das letztendliche Ziel und Unterziele, die ihm zum Zeitpunkt seines Erstellens gegeben worden sind, in einer hierarchischen Struktur.
(1-4) Knotenmanager
Der Knotenmanager 15 ist ein Teil, der das oben beschriebene Management des Agent ausführt. Der Knotenmanager ist ein Modul, das Knoten managt und insbesondere Steuerung des Erstellens eines Agents und der Migration eines Agent zwischen Knoten ausführt. Während des Ausführens dieser Art von Verarbeitung, führt der Knotenmanager erforderlichenfalls eine Kommunikation mit dem Knotenmanager eines anderen Knotens aus. Die Schnittstelle, die bei dieser Kommunikation verwendet wird, wird als Zwischenknotenschnittstelle (Internode Interface) bezeichnet. Diese wird in der zweiten Ausführungsform mit Hilfe der TCP-Schnittstelle bereitgestellt, die in dem Internet-Protokoll verwendetn wird und dies wird Knotenport bzw. Knotenanschluss genannt. Jeder Knotenmanager funktioniert als Server an jedem der jeweiligen Ports.
Der Knotenmanager führt auch eine Kommunikation mit dem Agent, den er selbst erstellt, aus. Die Schnittstelle, die in dieser Kommunikation verwendet wird, wird als Knoten-zu-Agent-Schnittstelle bezeichnet. In der zweiten Ausführungsform wird der Knotenport des Knotenmanagers zum Implementieren der Knoten-zu-Agent-Schnittstelle verwendet, wobei der Knotenmanager als Server dient und der Agent-Prozess als Client.
13 ist eine Zeichnung, die ein Beispiel der Konfiguration zum Zwecke des Implementierens von Knoten-zu-Agent-Kommunikation und Interknotenkommunikation zeigt. An jedem Knoten ist ein Beobachter MN (Monitor) vorgesehen, der ein Software-Modul ist zum Ausgeben des Status des Agent, der Knotenmanager 15 sendet ein Beobachtungsskript zu dem Beobachter MN, dieses dient als Anzeigeanweisung. Der Portname in der zweiten Ausführungsform ist der Überwachungsport MP (Monitorport). Auf der Seite des Knotenmanagers 15 ist der Serverport und auf der Seite des Beobachters MN ist der Clientport. Solange nicht anderweitig gesagt, wird eine Bezugnahme einfach auf einen Knotenport einen Knotenport NP bezeichnen innerhalb desselben Knotens. Das Kommunikationsprotokoll bei jedem der Kommunikationsports wird aus den folgenden Aussagen erstellt, welche durch die vorgeschriebenen Delimiter bzw. Separatoren separiert sind.
Als erstes zeigt die folgende Tabelle das Protokoll der Zwischenknotenschnittstelle in dieser Ausführungsform
Tabelle 1
Die folgende Tabelle zeigt das Protokoll der Knoten-zu-Agent-Schnittstelle in dieser Ausführungsform
Tabelle 2
Der Knotenmanager 15 gibt ein Beobachterskript von dem Beobachterport zum Zwecke des Beobachtens des Agent aus. In Bezug auf den Kommunikationsport wird die Sitzung in dem Knotenmanager 15, der der Server ist, von dem Beobachter ausgeführt, der der Client ist. Der Beobachter empfängt das Beobachterskript und kann eine Benutzerschnittstellen-Aktualisierung vornehmen. Die Inhalte des Beobachterskripts sind wesentlichen im folgenden Format, ansprechend auf den Zugriff in Bezug auf den Knotenport.
Tabelle 3
Das heißt, der Beobachter empfängt eine Meldung in Bezug auf den Status des Agent vom Knotenmanager 15 in Form eines Beobachterskripts und stellt dem Benutzer den Agent-Status bereit. Natürlich gibt der Knotenmanager 15, wenn kein Server-Client-Zusammenhang zum Beobachter eingerichtet ist, kein Beobachterskript aus. Die Folge, die in dem Ablaufdiagramm gezeigt ist, geht davon aus, dass Verbindungen eingerichtet worden sind zu allen Beobachtern, und es braucht nicht erwähnt zu werden, dass in dem Fall, in dem eine Verbindung nicht eingerichtet worden ist, es nicht erforderlich ist, eine Kommunikation in Übereinstimmung mit dem nachfolgenden Protokoll vorzunehmen.
(1-2) Wissensbasis
Eine Wissensbasis ist eine Datenbank, die Deklarationscodierung verwendet und in der zweiten Ausführungsform ist dies das Sammeln von Tatsachen, die in der Prolog-Sprache codiert sind. 14 ist ein Konzeptblockdiagramm, welches die Konfiguration einer Wissensbasis zeigt. Wie in dieser Zeichnung gezeigt, gibt es zwei Arten von Wissensbasen: die Aktionsbasis D1 und die Datenbank D2. Die Aktionsbasis D1 ist ein Satz von Aktionen, der absolut erforderlich ist bei der Planung. Die Datenbank D2 ist eine Wissensbasis, in welche der Anfangszustand des Systems gespeichert ist, wobei dies absolut erforderlich ist zur Planung. Jede dieser Wissensbasen kann mit Hilfe einer Aktion aktualisiert werden.
Die Aktionsbasis D1 und die Datenbank D2 haben jeweils einen Agent-spezifischen Teil, eine Teil, der aufgeteilt ist in Felder und einen knotenspezifischen Teil, wobei diese Agent-Aktionsbasis D1A und Agent-Datenband D2A, Feldaktionsbasis D1F und Felddatenbank D2F und Knotenaktionsbasis D1N und Knotendatenbank D2N genannt werden. Ein Feld ist ein Teil, der einem spezifischen unterschiedlichen Zweck eines Agent entsprecht, ein einzelnes gegebenes Feld entspricht Agents, die einen gemeinsamen Zweck haben. Durch Aufteilen einer Wissensbasis in Felder zusätzlich zu dem Implementieren einer Vielzahl unterschiedlicher Wissensbasen innerhalb eines einzelnen Knotens unter Verwendung von nur der bei der Planung für einen gegebenen einzelnen Agent erforderlichen Information ist es möglich, eine Planung mit guter Effizienz auszuführen.
Im Allgemeinen verursacht beim Darstellen von Wissen das Vorhandensein von konfliktbehaftetem Code Probleme in der Semantik. Das Aufteilen einer Wissensbasis in Felder erleichtert das Erreichen semantischer Einförmigkeit des Ausdrucks innerhalb jedes Feldes, was ein Ermöglichen einer glatten Planung mit Agents bewirkt, und das Unterstützen der Codierung, was die Definition von Aktionen erleichtert.
Das heißt, in Bezug auf sowohl die Aktionsbasis, als auch die Wissensbasis, gibt es drei Arten von Wissensbasen: eine zu einem Knoten gehörende Wissensbasis, eine zu einem Feld gehörende Wissensbasis und eine zu einem Agent gehörende Wissensbasis.
In der zweiten Ausführungsform wird eine Beschreibung präsentiert unter Verwendung der Prolog-Sprachterminologie. Während viele Beschreibungen der Prolog-Sprache vorgenommen worden sind, einschließlich Leon Sterling & Ehud Shapiro "The Art of Prolog", verwendet die in der zweiten Ausführungsform verwendete Prolog-Sprache nur Standardcodierung. In der Prolog-Sprache sind Namen, die mit Großbuchstaben beginnen, Variablen, die ersetzbar sind durch Abbilden von Kleinbestandteilen bzw. Atomen oder Items, die eine Kombination aus Atomen sind.
Das folgende ist eine Beschreibung eines Beispiels, welches darstellt, wie unter Verwendung von Information in Bezug auf einen anderen Knoten, wie von einem vorgeschriebenen Knoten gesehen, das heißt, durch Verwenden von Maybe-Information ein Agent eine Planung ausführt, und das Verfahren zum Bestimmen des Verhaltens des Netzes ansprechend auf eine Netzänderung. Maybe-Information ist in der Prolog-Sprache gegebenenfalls implementiert. Das heißt, aus Information, die in einer Wissensbasis gespeichert ist, gibt die Information vom Maybe-Typ (Maybe-Information) erwartete, aber nicht verifizierte Tatsachen an. Maybe-Information wird in einer Felddatenbank oder in einer Knotendatenbank gespeichert.
Der Knotenmanager in diesem System, welches der in 1 gezeigte Agent-Steuerabschnitt ist, ist konfiguriert, um imstande zu sein, eine Vielzahl von Arten von Agents zu handhaben, die den unterschiedlichen Feldern entsprechen. Beispielsweise hat ein Agent, wenn der Agent erstellt wird, für sich spezifiziert ein Feld, das einem Agent-Typ entspricht, oder der Rolle, die der Agent spielt. In der zweiten Ausführungsform ist es durch eine Wissensbasis, die aufgeteilt ist in individuelle Felder, möglich, den Umfang des Wissens zu reduzieren, der bei der Planung verwendet wird, was zu einer Verbesserung der Effizienz der Planung führt.
(1-5-1) Aktionsbasis
Eine Aktionsbasis ist ein Satz von Definitionen von Aktionen, die ein Agent vornehmen kann, wobei mit den Definitionen Vorher-Bedingungen und Nachher-Bedingungen für die Aktionen einhergehen, wobei ein Aktionensatz auch eine go-Aktion einschließt, die als ein Migrationsbefehl dient, der eine Migration eines Agents zwischen Knoten implementiert. Wenn eine ausführende Maschine eine go-Aktion als einen Befehl ausführt, wird der Agent zwischen Knoten des Netzes migriert, und ein integrierter Plan wird ausgeführt vor und nach dieser Migration.
In einer Aktionsbasis schließt Information in Bezug auf eine gegebene Aktion nicht nur Details der Aktion ein, sondern auch den Aktionsdefinitionsnahmen, eine Vorher-Bedingung und eine Nachher-Bedingung. Aus dieser Information ist der Aktionsdefinitionsname eine Darstellung des Aktionsnamens und der Argumente (Aktionsparameter), die als Items ausgedrückt werden. Die Vorher-Bedingung ist die Bedingung, die erforderlich ist zum Ausführen der Aktion, welche als eine Itemliste ausgedrückt wird. Die Nachher-Bedingung ist eine Statusänderung, die sich aus dem Ausführen der Aktion ergibt und diese wird auch als eine Itemliste ausgedrückt.
Information in Bezug auf eine Aktion kann beispielsweise in dem nachstehend gezeigten Format dargestellt werden. In der zweiten Ausführungsform gibt unter Verwendung der Prolog-Prädikataktion dieser Code eine Aktionsdefinition an.
action(<action definition name>,<action>,<pre-condition>,<post-condition>).
In dem obigen wird <action> aus Befehlen erstellt, die durch die Ausführungsmaschine ausführbar sind. Das heißt, es ist eine Kette einer Vielzahl von Befehlen, wie nachstehend gezeigt.
(1-5-2) Codierformatbeispiel in einer Aktionsbasis
Ein Beispiel des Codierformats einer Aktionsbasis unter Verwendung von Prolog in der zweiten Ausführungsform wird nun beschrieben. Die Aktionsbasis und die Feldaktionsbasis sind in ähnlicher Weise codiert.
Bei der Planung werden Aktionen, die zum Erreichen eines Ziels erforderlich sind, von den Aktionen herausgezogen, die in der Aktionsbasis definiert sind und ein Skript, welches eine Reihe von Aktionen ist, die einen Plan bilden, wird erstellt.
(1-5-3) Datenbank
Die Datenbank D2 in der zweiten Ausführungsform ist ähnlich dem Fall der Aktionsbasis der Gesamtname, der sich auf die drei unterschiedlichen Datenbanken bezieht, in diesem Fall die Agent-Datenbank D2A, die Felddatenbank D2F und die Knotendatenbank D2N, welche ein Satz von Tatsachen sind, in Bezug auf die Software-Ressourcen des Netzes. Beispielsweise ist die Agent-Datenbank D2A eine Datenbank, in welcher hauptsächlich Information gespeichert ist in Bezug auf das Agent-Verhalten, wie zum Beispiel Historieninformation einschließlich beispielsweise Information in Bezug darauf, ob oder nicht die Operation des Agent abgeschlossen worden ist. Die Felddatenbank D2F ist eine Datenbank, die repräsentiert, welche Verarbeitung vorgenommen werden kann einem speziellen Knoten in Bezug auf Software-Ressourcen, die für dieses Feld speziell sind. Die Knotendatenbank D2N ist eine Datenbank, in welche Code in Bezug darauf, welche Verarbeitung an dem Knoten möglich ist, und welche Ressourcen der Knoten hat, gespeichert ist. Natürlich kann, wenn erforderlich, eine Datenbank andere Informationsarten speichern.
Die Kombination der Agent-Datenbank D2A und der Agent-Aktionsbasis D1a ist kollektiv als Agent-Wissensbasis DA bekannt, die Kombination der Felddatenbank D2F und der Feldaktionsbasis D1F ist kollektiv als Feldwissensbasis F bekannt und die Kombination der Knotendatenbank D2N und der Knotenaktionsbasis D1N ist kollektiv als Knotenwissensbasis DN bekannt.
(1-6) Planer 13
Der Planer 13 führt eine Planung basierend auf Zielen durch, die als Zweck der auszuführenden Datenverarbeitung gegeben sind, was der Teil ist, den ein Skript als Plan zum Erreichen des Ziels ausgibt, und repräsentiert einen Teil der Agent-Funktion. Die Planung bezieht sich auf das Erzeugen eines Aktionsprogramms durch den Agent. Ein Plant ist eine Reihe von Aktionen, die durch Planung erzeugt werden und ein Skript ist eine Datenstruktur oder eine Datei in Software, in der ein Plan codiert ist. Das Skript ist unter Verwendung von Skriptbefehlen codiert. Das heißt, ein Skriptbefehl ist ein ausführbarer Befehl, der innerhalb eines Skripts codiert ist.
In dem Fall der zweiten Ausführungsform wird der Inhalt der Planung als eine Serie von Aktionen erzeugt, um ein gegebenes Ziel zu erreichen unter Verwendung der Vorher-Bedingung und des Nachher-Bedingungssatzes (Aktionsdefinition), die in der Wissensbasis gespeichert sind, welche speziell ist für den Knoten und das Feld. Der Planer 13 führt, wenn erforderlich auch eine Neuplanung aus. Neuplanung ist das Neuerzeugen eines Aktionsprogramms für den Agent, beispielsweise in dem Fall, in dem das Ausführen fehlschlägt.
Planung kann unter Verwendung des von dem Benutzer gegebenen Ziels implementiert werden und die Inhalte einer Aktionsbasis, in der ein Aktionssatz gespeichert ist, und einer Datenbasis, in der Information gespeichert ist, die den Momentanzustand repräsentiert. Der Planer 13 ist ein Modul, das diese Information eingibt, und das eine Planung durch Ausgeben eines Skripts vornimmt.
Beim Vornehmen der Planung liest der Planer 13 von der Agent-Wissensbasis, der Feldwissensbasis und der Knotenwissensbasis in Bezug auf sowohl auf die Aktionsbasen, als auch auf die Datenbanken, diese verschiedenen Informationssätze zum Vornehmen der Planung verschmelzend.
Die als Planung ausgeführte Verarbeitung kann von einer bekannten Art der Verarbeitung sein, (Referenz: S. C. Shapiro, "Encyclopedia of Artificial Intelligence", Planungsseite). Ein Beispiel einer Implementierung eines Planers unter Verwendung von Prolog-Sprache ist nachstehend als Prolog-Programm gezeigt.
(1-7) Ausführungsmaschine 14
Die Ausführungsmaschine 14 ist der Teil, der das Skript eines Plans, welcher von dem oben erwähnten Planer 13 erzeugt wird, interpretiert und ausführt. Speziell ist das Konzept das, dass der Agent eine ausführende Maschine 14 hat, die in Bezug auf ein Skript, das von dem Agent unter Verwendung des Planers 13 erstellt wird, die Reihe von Aktionen interpretiert und ausführt, die in dem Skript als eine Reihe von Befehlen codiert sind, wobei der Agent arbeitet, um sowohl den Planer 13, als auch die Ausführungsmaschine 14 zu steuern.
Das Ausführungsverfahren und die Betriebstechnologie der Ausführungsmaschine 14 ist allgemein die einer Interpretersprache. Die Ausführungsmaschine 14 in der zweiten Ausführungsform ist intrinsisch äquivalent zu csh in einem Unix-Betriebssystem, wobei das Skript Zeile für Zeile eingegeben und ausgeführt wird, was zu einer Rückgabe eines Ausführungsstatus führt. Skriptbefehle, die von der Ausführungsmaschine 14 interpretiert und ausgeführt werden, können von dem in den folgenden Beispielen wiedergegebenen Typ sein.
(1-7-1) Befehlsreihen mit einer Aktion in Common With csh
Die folgenden Befehle gibt es, die Aktionen haben, welche in Common With csh sind. Während diese Befehle auf einem Unix-System durch Aufrufen von csh ausgeführt werden, ist es offensichtlich, dass sie auch in anderen Sprachen implementiert werden können.
Tabelle 4
(1-7-2) Steuerstruktur und Variablenverarbeitung
Obwohl das Ausführen eines Skripts in der zweiten Ausführungsform im allgemeinen in Abfolge von oben vom Skript nach unten vorgenommen wird, mit einem ausgeführten Befehl pro Zeile, können die folgenden Aussagen verwendet werden zum Vornehmen von Bedingungsverzweigung und Wiederholung. Für Details in Bezug auf die Semantiken und das Definieren von Gleichungen von Operationen wird Bezug genommen auf den C-Sprachspezifikationssub-Satz.
Tabelle 5
(1-7-3) Agent-Befehle
Die Ausführungsmaschine kann die folgenden Befehle innerhalb eines Skripts verwenden, um die Verarbeitung zu erreichen, die als ein mobiler Agent erforderlich ist. In der zweiten Ausführungsform ist es durch Erweitern der Ausführungsmaschine möglich, die Befehlstypen zu erweitern.
Tabelle 6
Die Bedeutung von "Einschieben des Unterziels in den Zielestapel und Ausführung von Planung" in dem letzten Punkt in Tabelle 6 ist, dass, wie in 11, zusätzlich zu den Unterzielen momentanes Skript, Skriptsausführungsposition und Variablenwerte, die in dem Skript verwendet werden, in einen Stapel geschoben werden als Zielskriptsatz. Von diesen Items sind der goto_with_subgoal-Befehl der check_with_subgoal-Befehl und plan_and_exe-Befehle, die ein Unterziel haben. Ein Befehl, der ein Unterziel hat, ist ein Migrationsbefehl, der einen Agent veranlasst, sich zwischen Knoten zu bewegen, wobei ein Unterziel spezifiziert ist für den Fall, in dem die Migration fehlschlägt.
Der goto-Befehl mit der "Information von der Datenbank, die als Basis für die Migration verwendet wird" in der zweiten Zeile von oben der Tabelle 6, ist ein Befehl mit einer Basis. Normalerweise muss, wenn ein Agent einem spezifischen Ziel eine Planung ausführt, eine Aktion, die ein Befehl ist, der bei der Planung verwendet wird, eine Vorher-Bedingung haben, die in den Wissensbasen erfüllt ist. Diese Vorher-Bedingung kann eine maybe-Information sein. Jedoch in dem Fall der maybe-Information gibt es, weil es keine Garantie gibt, dass die Information in dem tatsächlichen Netz wahr ist, nachdem der Agent die Planung abgeschlossen hat, an dem Punkt, bei dem das erzeugte Skript ausgeführt wird, Fälle, in welchen codierten Inhalte der maybe-Information, die eine Vorher-Bedingung ist, sich unterscheiden. Ein Befehl mit einer Basis ist ein Befehl, der die Aktion eines korrigierten Fehlers in der maybe-Information einschließt, welcher zum Zeitpunkt des Ausführens erfasst wird. Das heißt, ein goto-Befehl mit "Information von der Datenbank, die als die Basis der Migration verwendet wird", ist ein Befehl mit einer Funktion, die, wenn die Migration nicht möglich ist, beurteilt, dass die Vorher-Bedingung zum Zeitpunkt der Planung unterschiedlich war und, wie in Tabelle 6 gezeigt, hat dieser Befehl die Aktion des Löschens der Information von der Datenbank als ein Argument gegeben.
Auf dieselbe Weise ist der in Tabelle 6 gezeigte Prüf- bzw. Check-Befehl auch ein Befehl mit einer Basis. Bei einem Knoten, bei dem ein Agent existiert, der einen Check-Befehl ausführt, wird, wenn die durch das erste Argument davon angegebene Datei nicht existiert, die durch das dritte Argument angegebene Information als fehlerhaft betrachtet und wird von der Datenbank gelöscht, die durch das zweite Argument angegeben wird.
Die Aktion dieser Befehle mit einer Basis ist wirksam, wenn eine Neuplanung ausgeführt wird durch einen Agent, der einen solchen Befehl ausführt, und, wenn, wie in einem nachfolgenden Betriebsablaufsbeispiel gezeigt, eine Neuplanung durch einen folgenden unterschiedlichen Agent ausgeführt wird.
(1-7-4) Datenbankaktualisierungsprädikate
Der in Tabelle 6 gezeigte Aktualisierungs- bzw. Update-Befehl dient als Schnittstelle zu dem Aktualisierer 16 (7) und führt in der zweiten Ausführungsform eine Aktualisierung der Inhalte der Agent-Wissensbasis, der Feldwissensbasis und der Knotenwissensbasis durch. Es gibt die folgenden zwei Arten von Aktualisierungsprädikaten.
Tabelle 7
Die Aktualisierungsprädikate sind Anweisungen zum Zwecke des Aktualisierens der Inhalte einer Datenbank basierend auf dem Wissen, das durch das Verhalten des Agents erlangt wird. Wegen der Existenz eines Aktualisierungsprädikats wird die Aktualisierung in einem Netz, das sich ändert, durch Planung durch den Agent selbst untergebracht, was eine Neuplanung des Agents selbst oder eine Planung in Bezug auf ähnliche Ziele eines unterschiedlichen nachfolgenden Agents basierend auf einer neuen Information ermöglicht.
(1-7-5) Einfaches Skriptbeispiel
Ein einfaches Skriptbeispiel unter Verwendung des oben beschriebenen Skript-Befehls wird nun wiedergegeben. Dieses Skript ist eines, das zu dem Knoten node0 die Datei file1 bewegt und kopiert, die in einem vorgeschriebenen Verzeichnis am Knoten node1 existiert. Wenn der Planer dieses Skript ausgibt, würde der Agent das Skript beginnend von oben und nach unten fortschreitend ausführen.
%goto node1
%get file(file1)
%goto node0
%put file(file1)
(2) Wirkung
Die zweite Ausführungsform, die wie oben beschrieben aufgebaut ist, hat die folgende Wirkung. Als erstes startet die Aktivität des Agents in der zweiten Ausführungsform mit dem Zuteilen eines Ziels (Goal) und in dem nachstehend präsentierten Beispiel wird vor dem Eingeben des Ziels die folgende Information in verschiedene Datenbanken eingegeben.
(2-1) Aktionsdefinitionsbeispiel
Die Definition der Aktionsbasis eines Feldes, das in diesem Beispiel verwendet wird, ist folgendermaßen. Das Beispiel, das folgt, ist eines, das einen Agent beschreibt, der Dateien sammelt, die im Netz verteilt sind, und die Felder für diesen Zweck. Die fünf Aktionen zum Zwecke des Erzielens dieser Art von Ziel, sind in dem nachstehend gezeigten Feld definiert. Eine Definition einer einzelnen Aktion ist, wie oben erwähnt, ein Satz, bestehend aus einem Aktionsdefinitionsnamen, einer Aktion, einer Vorher-Bedingung und einer Nachher-Bedingung.
Der Aktionsdefinitionsnamen ist ein passender Name, der der Aktion zugewiesen wird. Die "Aktion" bzw. "action" in der Aktionsdefinition gibt die Inhalte der tatsächlichen Verarbeitung an, die die Aktion ausführt, ähnlich dem Fall eines Befehls der Ausführungsmaschine 14. Das heißt, die "action" in einer Aktionsdefinition sind die Befehle, die in einem durch den Planer 13 erzeugten Skript enthalten sind, wenn diese Aktionsdefinition bei der Planung verwendet wird, und jene werden ultimativ ausgeführt, wenn ein Agent in die Ausführungsphase übergeht.
Die Vorher-Bedingung ist eine Bedingung, die erforderlich ist für das Ausführen der Aktion. Diese Bedingung wird verwendet durch den Planer 13 beim Ausführen der Verarbeitung der Planung und ist nicht direkt bezogen auf die Ausführungsphase des Agents.
Die Nachher-Bedingung ist eine Bedingung, die hinzugefügt wird als ein Ergebnis des Ausführens einer Aktion. Diese Bedingung wird durch den Planer 13 beim Ausführen der Verarbeitung bei der Planung verwendet und bezieht sich nicht direkt auf die Ausführungsphase des Agents. Das heißt, Planung ist eine Simulation, die vor dem Ausführen ausgeführt wird.
In der Aktionsbasis ist es erforderlich, dass jedes Feld die Aktionsdefinition entsprechend dem entsprechenden Interessengebiet im voraus erstellt worden ist. Die Aktionsbasis wird anhand von fünf Aktionsdefinitionen definiert, der ersten Aktion bis zur fünften Aktion, wie nachstehend angegeben. Das heißt, die Aktionsbasis, die nachstehend beschrieben wird, ist im voraus verteilt über die Knoten node0, node1 und node2. Die Verteilung und die Korrektur der Aktionsbasis in bezug auf jeden Knoten kann auch unter Verwendung des Agents in der zweiten Ausführungsform ausgeführt werden.
(2-1-1) Aktion: goto1
In der ersten Aktionsdefinition ist eine Migrationsaktion definiert, die eine Datei F an einem anderen Knoten holt. Die Inhalte der ersten Aktionsdefinition sind die folgenden.
Die Inhalte der ersten Aktionsdefinition sind zwei spezifische Befehle. Der Befehl update_agent_base führt eine Aktualisierung der Agent-Datenbank aus, und wenn dieser Befehl ausgeführt wird, wird die folgende Tatsache zu der Agent-Datenbank hinzugefügt.
info(home(HomeNode)).
Diese Operation bedeutet das Speichern des Ursprungsknotens des Agents in dem Agent. Die zweite Aktion in dieser Aktionsdefinition ist eine goto-Aktion mit einer Basis. In dem Fall, in dem diese Aktion bei der Planung ausgeführt wird, führt ein Agent, der das erzeugte Skript ausführt, zuerst den goto-Befehl mit einer Basis als den oben erwähnten Ausführungsmaschinenbefehl aus. Eine goto-Aktion mit einer Basis ist ein Migrationsbefehl, zu welchem eine Vorher-Bedingung angehängt wird als ein Parameter.
Die erste Aktionsdefinition hat zwei Vorher-Bedingungen. Die erste Vorher-Bedingung ist, dass das maybe-Prädikat in Bezug auf das Vorliegen einer Datei an einem anderen Knoten in einer der drei Datenbanken (Knoten-, Feld- und Agent-Datenbanken) vorliegt. Die zweite Vorher-Bedingung dient dem Zwecke des Einschränkens der Prolog-Variable HomeNode und zum Reflektieren dieses in dem Argument der Nachher-Bedingung, wobei dieses Item erforderlich ist, um den Migrierungsstatus des Agent in der Nachher-Bedingung exakt zu reflektieren.
Die Nachher-Bedingung der ersten Aktionsdefinition gibt dem Planer 13 eine Migration an, die dieser Agent erfahren hat unter der Bedingung, dass er vom HomeNode zum Node migriert worden ist zum Suchen nach der Datei F über das Netz. Der hinzugefügte Teil dieser Aktionsdefinitions-Nachher-Bedingung ist vollständig unterschiedlich von dem Updating-Add-Prädikat (Tabelle 7), das als Argument gegeben wird, zu jedem der Aktualisierungsbefehle der Ausführungsmaschine 14. Das heißt, während in diesem Code das Hinzufügen (add) ein Angeben durch den Aktionsdesigner in dem System des Planers 13 eines Zwischenplanstatus ist, der für die Planung erforderlich ist, ist das Hinzugefügte (add) des Update-Befehls der Ausführungsmaschine 14 ein Angeben, dass ein Skript die Ausführungsmaschine 14 angewiesen hat, Information zu einer Datenbank hinzuzufügen. Die Bedeutung des add-Prädikats in der Nachher-Bedingung ist auch in den folgenden Aktionen dieselbe.
(2-1-2) Aktion: goto2
Die zweite Aktionsdefinition definiert eine Aktion, die eine Datei F, welche durch den Agent eingefangen worden ist, zu dem Ursprungsknoten HomeNode kopiert. Die Inhalte der zweiten Aktionsdefinition sind die folgenden.
Die Aktion der zweiten Aktionsdefinition ist der goto_with_goal-Befehl, ein Migrationsbefehl mit einem Unterziel. Wenn dieser Befehl bei der Planung verwendet wird, wird ein goto_with_goal-Befehl der Ausführungsmaschine in dem Skript, das der Plan erzeugt, codiert. In der zweiten Aktion wird vor dem goto_with_goal-Befehl der Datenbank-Aktualisierungsbefehl update_agent_base ausgeführt, was die Wirkung des expliziten Informierens des Agents in bezug auf den Zurückkehrstatus des Agents hat. Wenn dieser Befehl ausgeführt wird, wird die folgende Tatsache zu der Agent-Datenbank hinzugefügt.
info(myself,returning)
Die Betriebsabläufe dieser zwei Ausführungsmaschinenbefehle update_agent_base und goto_with_goal haben die Wirkung des Bereitstellens einer Möglichkeit zur Neuplanung mit Hilfe des "returning"-Unterziels selbst in dem Fall, in dem der Betriebsablauf von returning bzw. Zurückkehren vom momentanen Knoten zum HomeNode temporär fehlschlägt bedingt durch einen Fehler oder ähnliches im Netz.
Die Vorher-Bedingung der zweiten Aktionsdefinition ist, dass der Agent bereits die gewünschte Datei F eingeholt hat, das heißt, have(file(F)). die Nachher-Bedingung der zweiten Aktionsdefinition bringing(file(F).HomeNode) gibt dem Planer an, wenn diese Aktion verwendet wird, dass der Agent-Status ist, dass er die momentan gewünschte Datei F eingeholt hat, und dass er zurückgekehrt ist zu HomeNode.
(2-1-3) goto-Aktion
Die dritte Aktionsdefinition definiert einen Befehl, der im Fall, in dem eine Agent-Migration nicht möglich war aus Gründen irgendwelcher Fehler im Netz, für einen gegebenen Zeitraum offen als ein Verfahren des Unterbringens davon wartet, und die Migration mit einer vorgeschriebenen Häufigkeit erneut probiert. Die Inhalte dieser dritten Aktionsdefinition sind die folgenden.
Die Aktion der dritten Aktionsdefinition ist eine wait_and_go, die ein Warten für einen gegebenen Zeitraum veranlasst, nach welchem die Migration neu probiert wird, mit einer vorgeschriebenen Häufigkeit. Wenn diese Aktion bei der Planung verwendet wird, wird der oben erwähnte goto_with_goal-Befehl in dem Skript, das erzeugt wird, codiert.
Das Prädikat "Zurückführen" (returning), das als Vorher-Bedingung der dritten Aktionsdefinition angegeben wird, gibt an, dass der Agent die vorgeschriebene Migration erreicht hat und dass er sich in einem Zustand bzw. Status befindet, zum Ursprungsknoten, welcher HomeNode ist, zurückgekehrt zu sein. Das Prädikat home(HomeNode), das zuvor hierzu codiert worden ist, dient zum Einschränken der variablen HomeNode.
Das Zurückkehren, das als Nachher-Bedingung der dritten Aktionsdefinition angegeben wird, gibt dem Planer an, dass wenn diese Aktion verwendet wird, der Agent-Status der ist, zu HomeNode zurückgekehrt zu sein.
(2-1-4) get-Aktion
Die vierte Aktionsdefinition schließt einen Befehl ein (wie zum Beispiel eine put-Operation oder eine get-Operation), die ein Objekt (Datei, Daten oder ähnliches) erhält. Durch Tragen des erhaltenen Objektes durch den Agent zu seinem Migrationsziel, bringt der Agent es zu einem erzeugten Knoten zurück.
Das heißt, diese Aktion bezieht sich auf einen spezifischen charakteristischen Agent-Status und im bezug auf das Erhalten einer Datei durch den Agent. Die Inhalte dieser Aktionsdefinition sind die Folgen.
Die Aktion der vierten Aktionsdefinition hat zwei Befehle in sich codiert. Wenn der Check-Befehl tatsächlich ausgeführt wird, wird eine Prüfung vorgenommen in bezug darauf, ob oder nicht die Datei F tatsächlich an dem Knoten existiert, an dem sich der Agent befindet, und wenn die Datei nicht existiert, schlägt die Ausführung des Skripts durch den Agent fehl. Das erste Argument HomeNode des Check-Befehls gibt den Ort der Wissensbasis an, die die Basis für die Prüfung bildet und das zweite Argument maybe(exist(file(F),node)) ist das Wissen, das die Basis bildet.
Das Prädikat zurückführen bzw. returning, das als Vorher-Bedingung für die vierte Aktionsdefinition angegeben ist, zeigt, dass der Agent die vorgeschriebene Migration erzielt hat, und dass er sich in dem Zustand befindet, zu HomeNode zurückgekehrt zu sein. Das Prädikat home(HomeNode), das hierzu zuvor codiert worden ist, dient zum Einschränken der variablen HomeNode.
Das have(file(F)), das als Nachher-Bedingung der vierten Aktionsdefinition angegeben ist, zeigt dem Planer an, dass, wenn diese Aktion verwendet wird, der Agent-Status der ist, zu HomeNode zurückgekehrt zu sein.
(2-1-5) put-Aktion
Die fünfte Aktionsdefinition ist in bezug auf einen Agent das Kopieren einer Datei. Die Inhalte der fünften Aktionsdefinition sind folgende.
Die Aktion der fünften Aktionsdefinition hat zwei Befehle in sich codiert. Die put-Aktion kopiert die Datei F des Agents zu dem Knoten, bei dem der Agent sich momentan befindet. Wenn der Agent eine neue Datei kopiert hat, fügt der update_field_base-Befehl Information in Bezug auf diese Datei der Dateidatenbank des Knotens hinzu, bei dem sich der Agent momentan befindet.
Das Prädikat bringing(file(F),HomeNode), das als Vorbedingung in der fünften Aktionsdefinition angegeben ist, gibt für HomeNode an, dass der Agent die Datei F trägt. Das add(exist(file(F),HomeNode)), das als Nachher-Bedingung der fünften Aktionsdefinition angegeben ist, gibt dem Planer an, dass die Datei F am HomeNode als Nachher-Bedingung existiert, wenn das Kopieren durch den Agent abgeschlossen ist.
(2-2) Datenbankcodierbeispiel
Das folgende ist ein Beispiel der Datenbankcodierung, eine Knotendatenbank in der zweiten Ausführungsform zeigend.
info (node0, maybe(exist(file(file1),node1))).
info(node0, home(node0)).
Diese Dantenbank zeigt das Beispiel der Codiering der Datenbank bei dem Knoten node0. Der Code in der ersten Zeile dieser Datenbank ist das Wissen bei node0, dass die Datei file1 am Knoten node1 existiert. Jedoch gehören node0 und node1 zu unterschiedlichen Hosts und diese Art von Information in bezug auf einen anderen Knoten ist nicht notwendigerweise in einem Netz, in dem Aktualisierung der Information konstant vorgenommen wird, korrekt. Die maybe-Information ist eine Information in Bezug auf einen anderen Knoten, wie diese. Der Code in der zweiten Zeile wird in der zweiten Ausführungsform übernommen zum Darstellen der Tatsache, dass der Knoten node0 tatsächlich node0 ist.
Das vorgestellte Ziel in dem obigen Beispiel ist das Erhalten der Datei file1 am Knoten node0. Wenn es im voraus bekannt ist, dass die Datei file1 eine Datei ist, die node1 oder node2 verwendet, kann hypothetisiert werden, dass die Datei file1 entweder am Knoten node1 oder node2 existiert. Diese Tatsache ist in folgender Weise in der Datenbank dargestellt in dem Feld make des Knotens node0, welches der Rolle eines Sammelpunktes für die Datei file1 dient. Diese Datenbank, wie in dem Fall der ersten Ausführungsform beschrieben, kann den Ansatz des automatischen Hinzufügens zu der Datenbank ergreifen unter Verwendung eines Agents eines unterschiedlichen Feldes, das zum selben Netz gehört, oder separate Anwendungs-Software verwenden.
In diesem Beispiel wird zum Zwecke der Einfachheit die Knotendatenbank und die Knotenaktionsbank jeweils als leer angenommen. In diesem Fall ist die Felddatenbank des Feldes make am Knoten node0 folgendermaßen.
info(node0, home(node0)).
info(node0, exist(file(file2),node0)).
info(node0, maybe(exist(file(file1),node1))).
info(node0, maybe(exist(file(file1),node2))).
In dem obigen ist in der zweiten Ausführungsform das Prädikat info ein Prädikat, das explizit angibt, dass dies ein Datenbankcode ist, welcher zwei Argumente hat. Das Prädikat info in der zweiten Ausführungsform wird nur ausgedrückt durch seinen Kopfteil, welcher eine sogenannte Prolog-Tatsache ist. Das erste Argument im Kopf des Prädikats info gibt explizit den Knotenort der Information an und in diesem Festdatenbankcodebeispiel ist sein gesamter Inhalt node0. Das zweite Argument des Kopfes des Prädikats info hat wesentliche Information, welche unter Verwendung eines Prolog-Items (term genannt) ausgedrückt wird. In diesem Code-Beispiel ist die spezifische Bedeutung die folgende.
Tabelle 8
Der Unterschied zwischen der Information exist(file(file2),node9) und der Information maybe(exist(file(file1),node1))) ist, dass in der vorhergehenden Information in bezug auf eine Datei, die am Knoten node0 existiert, zu der die Datenbank in dem Codebeispiel gehört, dies ein Informationstyp ist, der in der Datenbank als eine Tatsache festgelegt werden kann, wohingegen der letztere ein maybe-Pradikatcode ist in bezug auf Knoten node1, welcher ein unterschiedlicher Knoten ist, wenn betrachtet von node0, und in einem Netz, in dem das Auftreten von Änderungen anzunehmen ist, reflektiert dies die Tatsache, dass es nicht immer möglich sein kann, die Korrektheit des Codes in bezug auf node0 zu garantieren.
Demnach sind die Bedeutungen der vier info-Prädikate in dieser Felddatenbank die folgenden

– Der Knoten, zu dem dieses Feld gehört, ist node0.
– Die Datei file2 existiert an node0.
– Die Datei file1 wird begründetermaßen als an node1 existierend angenommen.
– Die Datei file2 wird als an node2 existierend angenommen.

Die folgenden Inhalte sind in der Felddatenbank bei node1 gespeichert. Dies ist ein maybe-Prädikat in bezug auf file1 basierend auf der Vorkenntnis, dass es entweder am node1 oder am node2 existiert.
info(node0, maybe(exist(file(file1), node2))).
Auf dieselbe Weise hat die Felddatenbank am Knoten node2 die folgende maybe-Information in sich gespeichert.
info(node0, maybe(exist(file(file1), node1))).
Die hier diskutierte maybe-Infornation ist eine vom Typ des zuvor präsentierten info-Prädikats. Dieses bildet einen Teil des info-Prädikats, das in jeder der Datenbasen enthalten ist, welches die Agent-Datenbasis, die Felddatenbasis und die Knotendatenbasis ist. Die oben erwähnte Information wird dem Planer gegeben, wenn der Agent die Planungsphase übergeht. Diese info-Prädikate sind Vorbedingung, welche erforderlich ist für den Planer, um eine Aktion auszuwählen.
(2-3) Zieleingabe und Agent-Erzeugung
In einer Datenverarbeitungseinrichtung gemäß der zweiten Ausführungsform, die die oben beschriebene Information hält, erzeugt der Knotenmanager 15, wenn ein Ziel an den Knoten gegeben wird, einen Agent-Prozess 17 und der Planer 13 führt die Planung durch. In der zweiten Ausführungsform wird der Planer 13 mit dem Erhalten eines Ziels gestartet. In der oben erwähnten Planerimplementierung unter Verwendung von Prolog in der zweiten Ausführungsform wird ein Skript erzeugt, welches den Agent-Namen als Dateinamen verwendet durch Geben eines Ziels codiert als eine Prolog-Abfrage.
In der dritten Ausführungsform ist es, wenn ein Ziel auf die Inhalte der oben beschriebenen Datenbanken hin prädiziert ist, möglich, dieses in folgender Weise zu codieren.
(Beispiel) exist(file(file1),node0)
Dieses Ziel ist die Akquisition der Datei file1 am Knoten node0 oder anders ausgedrückt, das Kopieren von file1, die momentan nicht am Knoten node0 existiert, von einem anderen Knoten, eine Ausgabe am Knoten node0 verursachend.
Ein spezifisches Beispiel des Anwendens dieses Ziels auf den Planer 13 ist das Ausgeben der folgenden Abfrage an den oben erwähnten Planer 13. Dieses Ziel wird validiert durch Kombinieren mit der oben erwähnten Aktionsbasis und Datenbasis.
(Beispiel): -plan(exist(file(file1),node0,_).
Die Agent-Erzeugung wird durch Ausgeben dieses Zielcodes an den Knotenmanager 15 der Felderstellung des Knotens node0 ausgeführt. Dieser Betriebsablauf wird unter Verwendung einer vorgeschriebenen Eingabe/Ausgabevorrichtung ausgeführt.
Die Betriebsprozedur des Knotenmanagers einschließlich des Erzeugen eines Agents ist in 15 gezeigt. Der Knotenmanager hat eine Liste AL (Aktiv-Agent-Liste), in welcher Agents (Aktiv-Agents) gespeichert sind, die an den zugeordneten Knoten existieren (13). Der Knotenmanager 15, wie in 15 gezeigt, empfängt (Schritte 1501 bis 1505) die Kommunikationsinhalte von dem Knotenport NP (13) als Anweisungen von einem anderen Knotenmanager oder Agent-Prozess und ansprechend auf die gegebene Anweisungszeichenkette (Schritte 1506 bis 1510), führt der Agent ein Erzeugen (Schritte 1511 und 1512), ein Löschen (Schritte 1521 und 1522), eine Migration (Schritte 1531 bis 1533) durch und aktualisiert die Aktiv-Agent-Liste entsprechend.
Während der Knotenmanager 15 die Details der Verarbeitung an jeder Schnittstelle zum Interpretieren des empfangenen Inhaltes von Code, der in dieser Weise empfangen worden ist, verarbeitet, kann das eigentliche Verfahren des Übertragens irgendeines aus einer Vielzahl von Verfahren sein, die frei nach Wunsch ausgewählt werden können.
Ein Agent-Prozess 17 (7), der von dem Knotenmanager 15 erzeugt wird, implementiert unter der Steuerung des Knotenmanagers 15 den Gesamtbetrieb des Agents A. Der Knotenmanager 15 kann simultan eine Vielzahl von Agent-Prozessen 17 erzeugen.
Nach der Agent-Erzeugung, wird dem Agent von dem Knotenmanager 15 ein Name gegeben. Weil der Agent zwischen Knoten im Netz migriert wird, ist es, um den Agent zu identifizieren, erforderlich, ihm einen Namen zuzuordnen, der einzigartig ist innerhalb des Netzes. Der Knotenmanager 15 ordnet einen Agent-Namen zu, der einzigartig ist innerhalb des Netzes für einen erzeugten Agent, kombiniert die derartige Information als Knotennamen, den momentanen Zeitpunkt und die Anzahl der Agents, die bereits erzeugt worden sind. Der erzeugte Agent, wie oben beschrieben, hat die drei Phasen der Planung, Ausführung und Migration in diese Phasen, wenn erforderlich eintretend.
(2-4) Planerzeugen
Wenn ein Ziel gegeben wird und ein Agent erzeugt wird, führt der Planer 13 eine Planung in Bezug auf das gegebene Ziel durch. Durch Zuweisen des Ziels exist(node0,file(file1)) über eine vorgeschriebene Eingabe/Ausgabevorrichtung wird ein Agent erzeugt. Dieser Agent tritt dann in die Planungsphase ein. Das heißt, der Agent schiebt das festgelegte Zielskript in den Zielstapel und startet den Planer 13 zum Ausführen der Planung.
16 ist ein Konzeptablaufdiagramm zum Zeigen interner Inhalte des Planungsprozesses, welches eine bekannte Planungstechnik darstellt. Speziell führt der Planer 13 in der zweiten Ausführungsform Zurückverfolgung (Backtracking) durch und bestimmt eine Reihe von Aktionen, um das Ziel zu erfüllen, während Bezug genommen wird auf Vorher-Bedingungen und Nachher-Bedingungen. Mit anderen Worten, 16 ist eine vereinfachte Darstellung des tatsächlichen Planungsprozesses. Dies ist eine Vereinfachung, in welcher die Unifizierung von tatsächlich auftretenden Variablen und Atomen in dem Prolog-Betrieb weggelassen worden sind.
In diesem Planungsprozess wird ähnlich dem Fall der ersten Ausführungsform eine Aktionsdefinition gesucht, für welche das Ziel eine Vorher-Bedingung hat. Dann wird nach Aktionsdefinitionen gesucht, welche Nachher-Bedingungen haben, die das Ziel, das die Vorher-Bedingungen der oben erwähnten gefundenen Aktionsdefinitionen sind. Sie werden an ein Planskript ausgegeben und dieselbe Art der Prozedur wird ferner wiederholt mit der Ausgabeaktion als ein Ziel zum Erzeugen des Plans. Speziell wird die Prozedur wiederholt, rückwärts nachverfolgend von einem Ziel (Schritt 1601) zu den Aktionen put, goto2, get und goto1, bis alle Bedingungen erfüllt sind (Schritte 1602 bis 1605). Weil diese Suche in Rückwärtsrichtung vom Ziel zur momentanen Bedingung vorgenommen wird, ist die Abfolge die Umkehrung der ausgewählten Aktionsdefinitionen. Die Inhalte der Aktionen in den Aktionsdefinitionen, welche Befehlsfolgen sind, werden als ein Skript generiert. Wenn dies erledigt wird, schlägt die Planung fehl, wenn es nicht möglich war, alle Bedingungen zu erfüllen, unabhängig davon, welche Folgen von Aktionsdefinitionen verwendet worden sind. Mit Hilfe der in 16 gezeigten Verarbeitung werden die nachstehend gezeigten Planungsergebnisse als ein Skript erhalten basierend auf der Feldwissensbasis, der Felderstellung (Field Make) und der Aktionsbasis von node0. Die Zahlen am linken Rand sind Zeilennummern.

1 %update_agent_base "add(myself, home(node0))"
2 %goto_node1 "maybe(exist(file(file1),node1))"
3 %checkfile(file1) node0 "maybe(exist(file(file1), node1))"
4 %get file(file1)
5 %update_agent_base "add(myself, returning, node0)"
6 %goto_with_goal node0 "return"
7 %put file(file1)
8 %update_field_base "add(node0, exist(file(file1),node0))"

Wenn der Planer 13, wie durch den Befehl go to (secod line) in Tabelle 6 einen Migrationsbefehl erzeugt, der ein agent zwischen Knoten als Teil des Plans bewegt, fügt er eine Vorher-Bedingung hinzu, die eine Vorbedingung für diesen Befehl ist (Ansprüche 19 und 26). Dies bedeutet, dass die Basis der Migration zum Knoten 1 ist
"maybe(exist(file(file1),node1))".
Beim Anhängen der oben erwähnten Vorher-Bedingung zu einem Migrationsbefehl wird die gesamte oder ein Teil der Vorher-Bedingung zu einem hinzugefügten Parameter des Migrationsbefehls gemacht.
Auf diese Weise wird in der zweiten Ausführungsform eine Vorher-Bedingung zu einem Migrationsbefehl hinzugefügt (als eine Basis). In dem Fall, in dem die Migration basierend auf solch einem Migrationsbefehl fehlschlägt, ist der wahrscheinlichste Fall, ein Fehler, die Vorher-Bedingung zu erreichen, die eine Vorbedingung für den Befehl ist. Diese Vorher-Bedingung wird zu dem Befehl angehängt und kann leicht identifiziert werden durch Bezugnahme auf den Befehl, hierdurch das Unterbringen eines Fehlers zum Migrieren erleichternd.
Der Planer 13 liest in der Knotenaktionsbasis und Datenbank, der Feldaktionsbasis und Datenbank und der Agentaktionsbasis und Datenbank vor dem Ausführen der Planung. In der zweiten Ausführungsform wird das obige kollektiv als Wissensbasis bezeichnet. In der Prolog verwendenden Implementierung in der zweiten Ausführungsform ist es, wie bereits angegeben weil die Information in jeder der Datenbanken durch eine Prologklausel repräsentiert wird, möglich, den Prolog-Anspruch zu verwenden zum Lesen in allen der oben erwähnten Wissensbasen vor der Planung.
Durch die oben erwähnte Abfrage wird zuerst ein Skript mit dem Dateinamen "Skript" erzeugt. Dann ändert der Agent den Dateinamen in Übereinstimmung mit dem entsprechenden charakteristischen Agent-Namen, um diesen von den Skripten eines anderen Agent zu unterscheiden, der simultan damit ausgegeben werden kann. In dem Fall der simultanen Planung durch eine Vielzahl von Agents werden sicherlich beide parallel verarbeitet, und eine Synchronisation der Agent-Operation ist erforderlich in Bezug auf die Dateierzeugung und Löschung und durch ein Anwenden eines geeigneten Verriegelungsmechanismus ist es möglich, eine Vielzahl von Agents gleichzeitig am selben Knoten auszugeben.
Planung wird entweder erfolgreich sein oder fehlschlagen, abhängig von den Inhalten der Knotenwissensbasis, der Feldwissensbasis und der Migrationswissensbasis. In dem Fall der erfolgreichen Planung wird ein Skript als Ausgangsgröße der Planung erzeugt und der Agent geht über zur Ausführungsphase. Zusätzlich zu einem Ziel, das einem Agent zum Zeitpunkt zu dem er erzeugt wird gegeben wird, hat er einen Zielstapel, der im Stande ist, eine Vielzahl von Unterzielen zum Zwecke des Wiederaufnehmens von einem zwischenliegenden Fehler. Wenn die Planung eines Unterziels fehlschlägt, wird die Planung durch ein ferneres stromaufwärtiges Ziel erledigt. Wenn ultimativ alle Planungen fehlschlagen, wird diese Bedingung als Gesamtfehlerbedingung genommen, in welchem Fall der Agent beendet wird.
Weil das oben erwähnte Skript als ein Ergebnis eines Planungsprozesses erhalten wird, speichert der Agent dies in dem Zielskriptsatz auf der obersten Ebene des Zielstapels. Dann geht der Agent über in die Ausführungsphase.
Bei der Planung ist es möglich, zwischenliegende Unterziele für den Zweck des Erreichens des letztendlichen angestrebten Ziels zu erzeugen und Tochteragents zum Zwecke des Erreichens dieser Zwischenziele zu erzeugen (Anspruch 20). Weil die Aufgabe des Erzeugens eines zwischengelegenen Ziels einem Tochteragent überlassen wird, wird die durch jeden Agents vorgenommene Datenverarbeitung hierdurch vereinfacht, dabei die Effizienz der Datenverarbeitung verbessert. Durch Betreiben einer Vielzahl von Agents entweder parallel oder in Serie, kann Datenverarbeitung mit hoher Geschwindigkeit ausgeführt werden.
(2-5) Planausführung
Wenn ein Skript kodiert wird, verwendet der Agent die Ausführungsmaschine 14 zum Eintreten in die Ausführungsphase. Wie später beschrieben wird, ist das Skript eine Befehlsreihe, die eine Steuerstruktur hat. In der Ausführungsphase führt der Agent eine Interpretation und ein sequenzielles Ausführen von Befehlen in Übereinstimmung mit dieser Steuerstruktur aus.
17 ist ein Ablaufdiagramm, das die Prozedur zum Ausführen eines Plans zeigt. In dieser Prozedur wird jeder Befehl zeilenweise gelesen, da die Ausführungszahl implementiert wird bis das Ende des Skripts erreicht wird (Schritte 1701 bis 1714, 1715 und 1716). Wenn ein Migrationsbefehl angetroffen wird, wird hierzu eine Anfrage zu dem Agentmanager gegeben (Schritt 1707) und für Nicht-Migrationsbefehle wird die Verarbeitung in Übereinstimmung mit dem Befehlstyp ausgeführt (Schritt 1708). Wenn ein Fehler während des Ausführens auftritt (Schritt 1709) wird eine vorgeschriebene Fehlerverarbeitung ausgeführt (Schritte 1710 bis 1714) abhängig von dem Befehlstyp, der den Fehler verursacht hat.
Speziell liest die Ausführungsmaschine 16 in dem Skript, die Befehle zeilenweise analysierend (parsing), den Befehlsnamen und das Skript interpretierend und die Befehle der oben präsentierten Tabelle ausführend in Übereinstimmung mit dem Befehlstyp. Obwohl eine Anzahl von Variationen vorstellbar ist für die Syntax des Skriptes, das von der Ausführungsmaschine 16 ausgeführt wird, wird die Auswahl der von der Ausführungsmaschine 16 zu interpretierenden Syntax nicht eigentlich die vorliegende Erfindung betreffend, und ein Merkmal der vorliegenden Erfindung ist, dass Befehle wie jene in der Tabelle gezeigt sind, wie z.B. Migrationsbefehle, Datenbankaktualisierungsbefehle und Befehle, die explizit als eine Basis zu verwendende Information liefern, in der Ausführungsmaschine vorgesehen. Durch Bereitstellen dieser Befehle ist es möglich, einem Agent ein geeignetes Unterziel zu geben oder eine geeignete Aktualisierung einer Datenbank in Übereinstimmung mit Änderungen im Netz vorzunehmen.
Wenn ein Befehlsausführen fehlschlägt oder wenn ein Neuplanungsbefehl erstellt wird, wird ein Zurückkehren in die Planungsphase zum Zwecke des Ausführens der Planung basierend auf einem vorgeschriebenen Ziel vorgenommen. Wenn ein Migrationsbefehl gegeben wird, wird ein Übergang in die Migrationsphase vorgenommen.
(2-6) Agent-Übergang
Wenn die Ausführungsmaschine 16 auf einen Migrationsbefehl trifft während des Ausführens eines Skriptes, meldet sie den Knotenmanager 15 dieses und sendet den Agent zu dem anderen Knoten. Die Information, die tatsächlich zum Zwecke der Migration des Agents gesendet wird, besteht aus dem Skript, dem Agent, dem Zielstapel und der Agentwissensbasis. Wenn das Senden all dieser Informationen zu dem Migrationszielknoten erfolgreich ist, kehrt der Agent zurück in die Ausführungsphase an dem Ziel.
(2-6-1) Übergang eines Agents zu einem anderen Knoten
18 ist ein Ablaufdiagramm, das den Betrieb des Knotenmanagers 15 bei dem Migrationszielknoten zeigt, wenn ein Agent zu einem anderen Knoten migriert wird. Speziell, zusätzlich zu dem Sammeln der Information, die in Bezug auf den Agent erforderlich ist (Schritte 1802 bis 1804), versucht der Knotenmanager 15 eine Kommunikationsmigration, den Zielknoten als den Host behandelnd (Schritte 1805 und 1808) und in dem Fall, indem das Einrichten des Kommunikationspfades fehlschlägt, bricht er die Migration ab (Schritte 1806 und 1809), meldet dem Agentprozess von dem Fehler (Schritte 1807 und 1810). Wenn der Kommunikationspfad eingerichtet worden ist, sendet er die erforderliche Information zu dem Migrationsziel und wartet auf eine Antwort (Schritte 1811 und 1812 und 1815). Selbst wenn der Knotenmanager 15 Kommunikation einrichten könnte, wenn er keine Antwort von dem anderen Knoten empfangen könnte, wird er dies auch als einen Migrationsfehler behandeln (Schritt 1813) und den Agentprozess benachrichtigen (Schritt 1814).
(2-6-2) Übergang eines Agents von einem anderen Knoten
Ansprechend auf die in 18 gezeigte Verarbeitung akzeptiert der Knotenmanager 15 am Zielknoten den Agent durch die Verarbeitung, die in 19 gezeigt ist. Speziell, wenn der Knotenmanager 15 an seinem Knotenport ein Protokoll MF von einem anderen Knoten empfängt, akzeptiert er die erforderliche Information (Schritt 1901), ordnet Ressourcen zu dem neuen Agent (Schritt 1902), und speichert die neue Agent-Information in einem vorgeschriebenen Bereich (Schritt 1903), woraufhin zu dem Migrationsursprung gemeldet wird, dass die Migration erfolgreich ist (Schritte 1904 und 1905) und startet den Agentprozess (Schritt 1906). Sollte eine Abnormalität während dieser Verarbeitung auftreten, wird die Verarbeitung mit Hilfe von Ausnahmeverarbeitung wie z.B. bei objektorientierter Programmierungssprache wie Java oder C++ ausgeführt.
20 ist eine Hilfszeichnung, die zeigt, wie der Agent migriert wird, unter Verwendung der Agent-zu-Knotenschnittstelle und der Knoten-zu-Knotenschnittstelle. Der Agent wird indirekt migriert über den Knotenmanager.
(2-7) Fehlerbehandlung
Wenn das Ausführen eines Skriptes oder einer Migration fehlschlagen sollte, d.h., wenn die Planausführung fehlschlagen sollte, wird die Planausführung unterbrochen und ein neuer Plan wird erstellt und ausgeführt (Patentansprüche 21 und 27). Ein Mechanismus für einen auftretenden Fehler ist beispielsweise das Auftreten einer Abweichung bzw. eines Fehlers oder einer Ausnahmebedingung. In der zweiten Ausführungsform wird die Datenverarbeitung selbst wenn die Planausführung oder Migration fehlschlägt, weil eine neue Planung vorgenommen wird zum Erzeugen eines neuen Plans glatt fortgesetzt.
Speziell, wenn das Ausführen einer Aktion oder einer Migration während eines Plans fehlschlägt, wird ein Unterziel erzeugt, um von der verfehlten Ausführung oder Migration zurückgeführt zu werden und Daten werden bereitgehalten für den Neustart des Ursprungsplans nach Abschluss des Erreichen des Unterziels, und das Erzeugen und Ausführen des Plans wird basierend auf dem oben erwähnten Unterziel vorgenommen. Dann wird nach dem Ausführen des Plans basierend auf dem Unterziel oben erwähnte gespeicherte Information verwendet zum Fortsetzen des Ausführens des Ursprungsplans (Anspruch 22).
Beispielsweise, wenn eine Agent-Migration basierend auf einen Go-Befehl fehlschlägt, und es keine Basis gibt abhängig von diesem Go-Befehl, wird das Ziel, dass das momentane Skript erzeugt, nochmals verwendet als ein Ziel zum Durchführen der Planung. Eine Migration kann in dem Fall fehlschlagen, indem die Netzverbindung des Migrationszielknotens nicht eingerichtet worden ist, in dem Fall, indem Migration nicht abgeschlossen worden ist innerhalb einer gegebenen Zeitdauer und in dem Fall, indem es nicht möglich ist, am Migrationsziel die erforderlichen Ressourcen zu erreichen, wie z.B. Speicher oder Plattenraum. In solchen Fällen wird die Migration als Fehlschlagung behandelt und eine Rückführung zu der Planungsphase wird vorgenommen basierend auf einem vorgeschriebenen Unterziel.
Es ist wünschenswert, dass ein solcher Fehler bei dem Migrationsursprung erfasst wird. Wenn beispielsweise ein Agent einen Go-Befehl ausführt an dem Knotenmanager, der die Agentmigration steuert, wird, wenn es irgendein Problem bei dem Zielknoten gibt, das die Migration des Agents verhindert, dessen Migrationsfehler an dem Ursprung für die Migration erfasst. Das Erzeugen eines Unterziels zum Erzeugen eines Plans wenn ein Fehler auftritt, bedeutet, dass es möglich ist, in die Planungsphase überzugehen, wenn erforderlich selbst wenn man in der Ausführungsphase ist. Informationsarten, die man sich als die oben erwähnten erhaltenen Informationen vorstellen kann, schließen solche Informationen ein wie Ursprungsziel, Ursprungsskript und Skriptausführungsposition, wobei diese Informationen speicherbar sind durch Einschieben in einen Zielstapel. Dann wird eine Planung vorgenommen beginnend mit dem Unterziel der niedrigsten Ordnung der erzeugten Unterziele und der derart erzeugte Plan wird dann ausgeführt. Nach dem Ausführen wird zum Neustart des Ursprungsplans die oben erwähnte Information aus dem Stapel genommen.
In der zweiten Ausführungsform wird, wenn die Planung, die Planausführung oder die Migration basierend auf dem Plan fehlschlagen, die Information, die die Ursache des Fehlers war, korrigiert (Ansprüche 23 und 28). Hierdurch werden nachfolgende Fehler reduziert, dadurch die Effizienz der Datenverarbeitung verbessert. Beispielsweise, wenn die Ausführungsmaschine 16 beim Ausführen eines Go-Befehls, der eine Vorher-Bedingung als expliziten Parameter gegeben hat, fehlschlägt, wird dieser von der logischen Information entfernt, d.h., aus der Felsdatenbank.
Die Weise des Erzeugen eines Unterziels und das Korrigierens von Information kann basieren auf einer zuvor definierten Definition oder individuellen Aktionen oder für individuelle Migrationen basierend auf einer Definition in Hinblick auf irgendeine Information stattfinden, die beim Erzeugen des Plans verwendet wird und kann auch auf lokaler Information oder ähnlichem basieren.
Auf diese Weise wird in der zweiten Ausführungsform einschließlich dem Fall, indem es erforderlich ist, eine Fehlerbedingung zu behandeln, ein Unterziel beim Ausführen eines Plans erzeugt und ein fernerer Plan wird erzeugt und ausgeführt in Bezug auf das Unterziel, hierdurch Daten unter Verwendung einer hierarchischen Zielstruktur verarbeitend. In diesem Fall ist es, wenn ein Agent mit Hilfe einer go-Aktion migriert worden ist, das er gemeinsam mit einem hierarchischen Zielstapel migriert worden ist, möglich, selbst am Migrationszielknoten den Zielstapel zu verwenden zum Ausführen von nahtloser Operation unter Verwendung des selben Zielstapels.
Zum Ausführen einer glatten Neuplanung auf diese Weise, wird ein Neuplanungsbefehl als eine Art von Befehl verwendet, um den Plan zu erstellen und wenn dieser Neuplanungsbefehl innerhalb der Ausführung eines Plans ausgeführt wird, erzeugt die Planerzeugungsvorrichtung einen Unterplan.
Wenn das Planen nach einer Migration fehlschlägt wird in dem Fall, indem es letztendlich nicht möglich ist, eine Aktion zu erzeugen, die die Vorher-Bedingung erfüllt, das Skript zur Fehlerbestimmung erstellt, ein Zurückführen zu dem Knoten vor der Migration wird vorgenommen und Neuplanung kann unter Verwendung des Ziels ausgeführt werden, das in dem Stapel gespeichert worden war. In dem Fall, indem das Erzeugen eines Plans in Bezug auf das Ziel letztendlich unmöglich ist und in dem Fall, indem ein nichtausführbares Ziel empfangen wird, kann Elektronikmail oder eine andere Vorrichtung verwendet werden zum Vornehmen einer Meldung an den Sender, wenn erforderlich.
Eine andere mögliche Form der Fehlerbehandlung ist die, bei der die Vorrichtung, die den Plan erzeugt, zu dem Plan ein Skript addiert, das verifiziert, ob oder nicht die Vorher-Bedingung, die eine Vorbedingung für den Plan ist, erfüllt worden ist zum Zeitpunkt des Ausführens. Hierdurch wird eine Bedingung zum Zeitpunkt des Erzeugens des Plans verifiziert zum Zeitpunkt des Ausführens, d.h., weil es ein unabwendbares Zeitintervall zwischen der Zeit gibt, wenn die Planung vorgenommen wird und der Zeit, zu der der erzeugte Plan ausgeführt wird, wurde eine Bedingung erfüllt zum Zeitpunkt der Planung, die nicht mehr erfüllt werden kann zum Zeitpunkt des Ausführens. Durch Verifizieren der Vorher-Bedingung ist es möglich, eine geeignete Ausführung des Plans sicherzustellen.
(2-8) Abschluss-Verarbeitung
Ein Beispiel der Abschluss-Verarbeitung ist in dem Fall einer erfolgreichen Datenverarbeitung durch einen Agent, in welchem Fall der Herausgeber des Ziels durch Mail von dem Erfolg benachrichtigt wird und von einem Fehlschlag im Falle des Fehlschlags benachrichtigt wird. Andere verschiedene Formen der Abschluss-Verarbeitung sind vorstellbar und es ist möglich, wenn ein Agent erzeugt wird, Information in Bezug auf den Typ der auszuführenden Abschluss-Verarbeitung hinzuzufügen, hierdurch eine Variation in der Abschluss-Verarbeitung ermöglichen.
(2-9) Detaillierter Agent-Betrieb
Jede der oben beschriebenen Operationen ist im Ablaufdiagramm der 21 gezeigt, welches die Verarbeitungsprozedur zeigt fokussierenden auf den Agent. Speziell wird zum Zeitpunkt, zu dem ein Agent erzeugt wird, wenn ein Ziel von dem Knotenmanager empfangen wird, dieses Ziel in den Zielstapel geschoben (Schritt 2101). Es wird eine Prüfung vorgenommen, um zu sehen, ob der Stapel leer ist (Schritt 2102). Wenn der Stapel leer ist, wird eine Beurteilung getroffen, dass dieser Agent das Erreichen des Ziels vollständig verfehlt hat und die Abschluss-Verarbeitung, die später zu beschreiben ist, wird ausgeführt, hierdurch einen Abbruch bewirken (Schritt 2103).
Wenn der Zielstapel nicht leer ist, wird ein Ziel von dem Zielstapel hervorgeholt und später zu beschreibende Planung wird vorgenommen in Bezug auf dieses Ziel (Schritt 2104). Wenn die Planung fehlschlägt, wird eine Rückführung zu dem Schritt vorgenommen, der die Prüfung der Inhalte des Stapels ausführt (Schritt 2105).
Wenn die Planung erfolgreich ist, wird ein Skript erzeugt (Schritt 2106). Wenn dies erledigt wird, wird die Skriptausführungsposition aktualisiert (Schritt 2107) und ein Übergang von der Planungsphase in die Ausführungsphase wird vorgenommen.
Bei der Planung und dem Erzeugen eines Skriptes, beim Planen unmittelbar nach dem Erzeugen eines neuen Agents, wird ein neues Skript erzeugt. Bei der Planung und Skripterzeugung werden bei der unmittelbar daraufhin erzeugten Planung die Ergebnisse der Planung zu dem Skript, das unmittelbar vor der Planung existiert hat, hinzugefügt. Bei der Planung und Skripterzeugung wird wenn die Planung nicht erfolgreich ist, wieder eine Rückführung zum Prüfen vorgenommen, ob oder nicht der Zielstapel leer ist.
Wenn die Planerzeugung erfolgreich ist, wird ein Übergang vorgenommen zur Interpretation und Ausführung des Skriptes. Die Interpretation und Ausführung des Skriptes wird von der Ausführungsmaschine des Agents verarbeitet, welche später zu beschreiben ist. Die Betriebsabläufe des Interpretierens und Ausführens des Skriptes sind im Grunde liegend die selben wie die bei einem Sprach-Interpreter, wie z.B. BASIC oder ähnlich. Die Ausführungsmaschine interpretiert durch Bewegen von der momentanen Skriptausführungsposition zu der nächsten Position, bei der Befehle eingelesen werden, interpretiert den Befehlstyp und die Argumente und führt die Befehle aus.
In dem Interpreterteil der Ausführungsmaschine wird, wenn der Befehl in der momentanen Ausführungsposition ein Migrationsbefehl ist (goto) (Schritt 2108) eine Verschiebung in den Migrationsverarbeitungsschritt vorgenommen. Bei dem Migrationsverarbeitungsschritt wird eine später zu beschreibende Migrationsverarbeitung ausgeführt. Übergangsverarbeitung ist eine Verarbeitung, die zwischen Knoten überbrückt und von dem Knotenmanager ausgeführt wird, und eine Verarbeitung, bei der der Agent von dem Migrationsursprung verschwindet und am Migrationsziel reproduziert wird (Schritt 2109). Wenn diese Migration abgeschlossen ist (Schritt 2110), wird die in dem Ablaufdiagramm der 21 gezeigte Verarbeitung an dem Migrationszielknoten fortgesetzt.
Wenn die Migration fehlschlägt (Schritt 2110), wird eine Prüfung am Migrationsursprung vorgenommen, ob der Migrationsbefehl von einem Unterziel begleitet war (Schritt 2114). Wenn es ein Migrationsbefehl ohne Unterziel ist, wird, um in die Planungsphase einzutreten eine Rückführung zu dem Schritt vorgenommen, bei dem eine Prüfung dahingehend vorgenommen worden ist, ob der Zielstapel leer ist. Wenn der Migrationsbefehl einer mit einem Unterziel war, wird die später zu beschreibende Fehlerverarbeitung ausgeführt (Schritt 2115), das Unterziel wird in den Zielstapel geschoben (Schritt 2116), und eine Rückführung wird noch einmal zu dem Planungsschritt vorgenommen.
In dem Fall, indem der Befehl an der Ausführungsposition kein Migrationsbefehl ist (Schritt 2108), wird eine Prüfung durch die Ausführungsmaschine dahingehend vorgenommen, ob oder nicht das Skript beendet worden ist (Schritt 2111). Wenn das Skript beendet worden ist, wird eine Beurteilung getroffen, dass der Agent vollständig erfolgreich war, eine Erfolgreich-Abschluss-Verarbeitung wird vorgenommen, hierdurch ein Abbrechen bewirkend (Schritt 2117).
Wenn ein Schritt 2111 des Skriptes nicht beendet worden ist, wird der Befehl an der Ausführungsposition interpretiert und ausgeführt (Schritt 2112). In dieser Verarbeitung wird, wenn die Befehlsausführung erfolgreich ist, eine Rückführung zu der Verarbeitung bei Schritt 2107 vorgenommen. Wenn die Befehlsausführung fehlschlägt, wird ein Übergang (bei Schritt 2113) zur Verarbeitung bei Schritt 2114 vorgenommen.
Das Vorangehende ist das Verhalten, wie es von dem migrierten Agent gesehen wird. Zum Erreichen des ursprünglich gegebenen Gesamtziels erzeugt der Agent ein Skript und führt in einer nahtlosen Weise basierend auf dem Skript ein Verhalten aus.
(3) Skriptausführung und Knotenübergangsbeispiele
Wir wenden uns nun dem Verhalten des Agents in der Ausführungsphase zu, in welcher er ein Skript ausführt, das durch den Planer und in der Migrationsphase erzeugt worden ist, wobei das oben beschriebene Skript (das nachstehend als erstes Skript bezeichnet wird) als ein spezifisches Beispiel beschrieben wird. 22 ist ein Ablaufdiagramm, das die Verarbeitung in diesem Beispiel zeigt einschließlich der Handhabung der Fehlerbedingungen.
(3-1) Erfolgreiches Beispiel
Als erstens wird ein spezifisches Beispiel präsentiert, bei welchem alle Annahmen zur Planungsstufe korrekt waren, indem kein Ausführungsfehler auftrat.
Durch Ausführen der ersten Zeile des oben erwähnten Plans,
%update_agent_base "add(myself, home(node0))"
wird die Information
info(myself.home(node0))
zu der Datenbank des Agents hinzugefügt (Schritt 2201). Dieser Betriebsablauf ist erforderlich, um den Planer des Abwanderungsknotens des Agents selbst (Ursprung) in dem Fall zu informieren, indem ein nachfolgendes Skriptausführen aus irgendwelchen Gründen fehlschlägt und es erforderlich ist eine neue Planung vorzunehmen.
Als nächstes wird durch Ausführen der zweiten Zeile,
%goto node1 "maybe(exist(file(file1), node1))"
welches ein Migrationsbefehl zu node1 mit einer Basis ist, der Agent zu node1 migriert (Schritt 2202). Die Wirkung des Basisargumentes wird später beschrieben.
Dann wird durch Ausführen der dritten Zeile
%checkfile(file1)node0 "maybe(exist(file(file1), node1)) "
eine Verifizierung vorgenommen dahingehend, ob die Datei file1 tatsächlich am Knoten node1 existiert (Schritt 2205). In diesem Beispiel, gerade wie bei der Planung angenommen, nehmen wir den Fall, indem file1 tatsächlich am node1 existiert, in welchem Fall die zweiten und dritten Argumente des Prüfbefehls keine Bedeutung haben.
Dann wird durch Ausführen der dritten Zeile
%get file(file1)
die Datei file1, die vom Knoten node1 erhalten worden ist, der das Migrationsziel ist, eine Datei gemacht, die dem Agent eigen ist (Schritt 2209). Daraufhin trägt der Agent bis er sie erledigt, die Datei mit sich, wenn er migriert wird.
Durch Ausführen der fünften Zeile
%update_agent_base "add(myself, returning, node0)"
wird die Information
info(myself.returning.node0)
zu der Datenbank des Agents hinzugefügt (Schritt 2209). Diese Operation dient dem, Zweck, bei der Planung die Tatsache zu reflektieren, dass der Agent sich im zurückgeführten Zustand befindet wenn eine Neuplanung ausgeführt wird, weil ein Fehler des Agents zu einer Zurückführung zum node0 aus irgendwelchen Gründen geführt hat.
Dann wird durch Ausführen der sechsten Zeile
%goto_with_goal_node0 "return"
der Agent zum Knoten node0 migriert (Schritt 2209). Durch Ausführen der siebten Zeile
%put file(file1)
wird die Datei file1, eine dem Agent eigene Datei, zum Knoten node0 kopiert (Schritt 2214). Und schließlich wird durch Ausführen der achten Zeile
%update_field_base "add(node0, exist(file(file1),node0))"
der Agent info(exist(file(file1),node0)) zu der Dateidatenbank des Knotens node0 hinzufügen (Schritt 2214). Wie oben beschrieben, wird, solange der Agent keinen Ausführungsfehler während der Ausführung des Skriptes erfährt, das ursprünglich gegebene Ziel erreicht.
(3-2) Fehlerbeispiel
Als nächstes wird der Fall der Agentoperation während der Neuplanungsausführung basierend auf einem Fehler betrachtet. Die Planung, die am Knoten node0 ausgeführt wird, ist nicht mehr als eine Planung, welche am Knoten node0 bekannte Information verwendet. Tatsächlich, weil der Zustand jedes Knotens mit dem Netz verbunden ist, und der Zustand des Netzes mit der Zeit ändert, kann das Ausführen eines Skriptes, das durch die Planung erzeugt wird, irgendwo dazwischen liegen.
Die folgenden Arten von Agentausführungsfehler sind vorstellbar.

(1) Ein Knoten oder das Netz arbeitet temporär nicht bedingt durch einen Fehler, Wartung oder Überlastung.
(2) Die Inhalte einer Agentplanung verwendeten Datenbank sind fehlerhaft.
(3) Die Inhalte einer Datenbank sind durch die verstrichene Zeit überholt.

Wie in 16 gezeigt kann man sich in diesem Betriebsbeispiel die folgenden Fälle vorstellen.

– Das Verfehlen einer Migration eines Agents von Knoten node0 zu Knoten node1.
– Das Verfehlen, dass ein Agent eine Datei erhält, weil file1 nicht am node1 existiert (aber an node2 existiert).
– Das Verfehlen, einen Agent vom Knoten node1 von der Datei file1 zum Knoten node0 zu migrieren.

Das Folgende ist eine Beschreibung, wie in einem Beispiel einer Datenverarbeitungseinrichtung gemäß der vorliegenden Erfindung solche Fälle wie oben erwähnt behandelt werden.
(3-2-1) Erstes Fehlerbeispiel
Als erstes sei der Fall betrachtet, bei dem die zweite Zeile des Skriptes %goto node1 "maybe(exist(file(file1), node1))" (Schritt 2201), die Migration vom Knoten node0 zum Knoten node1 durch einen goto-Befehl mit einer Basis, fehlschlägt (das Fehlerszenario 1 in 22). In diesem Fall (Schritt 2202) führt der Knotenmanager die in 18 gezeigte Operation aus, dem Agent mitteilen, dass eine Migration nicht möglich ist. In diesem Fall löscht die Ausführungsmaschine des Agents daraufhin die Information, die die Basis für die Migration zum Zeitpunkt der Planung war, d.h., das wissen des dritten Argumentes, von den Knoten-/Feld- und Agentdatenbanken (Schritt 2203). Durch Löschen der Basis werden die Datenbanken folgendermaßen geändert.
Als erstes, weil in dem Fall der zweiten Ausführungsform die Knotendatenbank von node0 keinen Inhalt hat, gibt es keine Änderung. In dem Fall der Agentdatenbank wird durch Ausführen des update_agent_base-Befehl in der ersten Zeile des ersten vorherigen Skriptes die einzelne Klausel info(myself.home(node0)) hinzugefügt, weil es kein maybe- Prädikat in der Agent-Datenbank gibt, wird keine Änderung vorgenommen.
Weil die Inhalte der Datenbank der Datei make des Knotens node0 zur Zeit des ersten Fehlers die folgenden sind
info(node0, home(node0)).
info(exist(file(file2),node0)).
info(node0,maybe((exist(file(file1),node2))).
führt nach dieser Operation die Ausführungsmaschine den Ausführungsfehlerzustand zu dem Agentprozess zurück und der Agent geht über in die Planungsphase. Weil der goto-Befehl, der fehlschlägt, kein Befehl mit einem Unterziel ist, wird basierend auf dem in 21 gezeigten Betrieb eine Neuplanung unter Verwendung der momentanen Inhalte des Zielstapels vorgenommen (Schritt 2204).
Das folgende zweite Skript wird durch Neuplanung erzeugt, welches die oben erwähnte Festdatenbank, Agent-Datenbank und die oben beschriebene Aktionsdatenbank verwendet sowie den oben beschriebenen Planer.
%update_agent_base "add(myself, home(node0))"
%goto node2 "maybe(exist(file(file1), node2)) "
%checkfile(file1) node0 "maybe(exist(file(file1), node2))"
%get file(file1)
%update_agent_base "add(myself, returning, node0)"
%goto_with_goal node0 "return"
%put file(file1)
%update_field_base "add(node0, exist(file (file1), node0))"
Der Unterschied in diesem Skript in Bezug auf das erste Skript ist die Änderung des Objektes von dem Erhalten von der Datei file1 vom Knoten node1 zum Knoten node2.
D.h., wenn das Ausführen fehlschlägt, wenn die Datenbankaktualisierung nicht in geeigneter Weise vorgenommen worden ist, gibt es eine Gefahr dahingehend, dass eine Neuplanung zu dem selben Skript führt wie das erste Skript, was zu dem selben Agent-Fehlschlagen führt. In der zweiten Ausführungsform wird durch Verwenden eines goto-Befehls mit einer zugeordneten Basis die Information
info(node0,maybe(exist(file(file1),node1))),
welches eine Information über das Existieren von file1 an node1 ist, von der Dateidatenbank gelöscht. Aus diesem Grund wird beim Durchführen einer Neuplanung die Planerzeugung unter Verwendung von node2 ausgeführt, welches der zweite Kandidat für den Ort der Datei file1 ist. Demnach gibt es in der zweiten Ausführungsform eine Verbesserung in der in einem Softwareagent erforderlichen Unabhängigkeit, welche Verbesserung eine Verbesserung der Fähigkeit des Agents ermöglicht, Änderungen in einem Netz unterzubringen.
(3-2-2) Zweites Fehlerbeispiel
Als nächstes sei der Fall des Verhaltens des Agents in dem Fall betrachtet indem das erste Skript, die Migration vom Knoten node0 zum Knoten node1, erfolgreich ist aber file1 nicht an node1 existiert (Fehlerszenario 3 in 22). In diesem Fall tritt beim Prüfbefehl in der dritten Zeile des ersten Skriptes, wenn die Ausführungsmaschine des Agents, die zum node1 migriert worden ist, eine Prüfung des Existieren von file1 vornimmt, weil file1 nicht tatsächlich existiert, ein Ausführungsfehler auf (Schritt 2205).
In dem Prüfbefehl, wie in der Tabelle der Ausführungsmaschinenbefehle beschrieben, ist das zweite Argument der Knoten, bei dem die Basis und der Ursprung, d.h. die Datenbank, die die Information hält, die die Basis und der Ursprung ist sich befinden, und das dritte Argument ist die Information, die die Basis ist. Wie in dem Fall für das erste Fehlerbeispiel wird in diesem Fall auch eine Aktualisierung der Information vorgenommen, die die Basis bildet (Schritt 2207).
Jedoch, was ein eigener Unterschied zwischen dem ersten Fehlerbeispiel und dem zweiten Fehlerbeispiel ist, dass der Agent bereits zu node1 migriert worden ist im zweiten Beispiel. Demnach ist es zum Aktualisieren der Datenbank erforderlich, wieder zum Ursprungsknoten zu migrieren. Durch das Verfahren, dem Knoten, bei dem die fehlerhafte Datenbank existiert explizit den Prüfbefehl zu geben, werden sowohl die Felddatenbank dieses Knotens als auch die Knotendatenbank aktualisiert.
Wenn dies ausgeführt wird, würde eine Möglichkeit der Aktualisierung der Datenbankinhalte die Verwendung von Inter-Knoten_kommunikation bzw. Zwischen-Knoten-Kommunikation über den Knotenmanager sein oder ein separates Ziel auszugeben, das die Information aktualisiert, einen zu beratenden zweiten Agent erzeugend, und ihn veranlassend, eine unabhängige Operation auszuführen. In irgendeinem dieser Fälle ist es möglich, eine Datenbank durch das Existieren eines Befehls mit einer Basis zu aktualisieren.
In dem neuerstellten Plan bei Knoten node1 sind die verwendeten Datenbanken die node1-Knotendatenbanken, die node1-Felddatenbank und die Agent-Datenbank.
In dem zweiten Fehlerbeispiel sind die Inhalte der Agent-Datenbank in der Aktualisierung nach dem Fehler
info(myself,home(node0)),
die Inhalte der node1-Knotendatenbank sind leer, und die Inhalte der Felddatenbank der Felderstellung des Knotens node1 sind
info(node1,maybe(exist(file(file1),node2))).
Von diesen zwei Informationen wird ähnlich dem Fall des ersten Fehlerbeispiels, wenn Neuplanung in Bezug auf das Ursprungsziel exist(file(file1),node0) ausgeführt wird (Schritt 2208), ein Skript ähnlich dem Fall des ersten Fehlerbeispiels erhalten. Der Unterschied ist in diesem Fall, dass während beim ersten Fehlerbeispiel der Agent von node0 nach node2 migriert worden ist, im zweiten Fehlerbeispiel ein Plan zur Migration von node1 zum node2 ausgeführt wird.
%update_agent_base "add(myself, home(node0))"
%goto node2 "maybe(exist(file(file1), node2))"
%checkfile(file1) node0 "maybe(exist(file(file1), node2))"
%get file(file1)
%update_agent_base "add(myself, returning, node0)"
%goto_with_goal node0 "return"
%put file(file1)
%update_field_base "add(node0, exist(file(file1), node0)) "
Dies ist, weil es durch die Existenz der Agent-Datenbank möglich ist, die Datenbank zu verwenden, wenn der Ort des Heimatknotens des Agents zu einem anderen Knoten migriert worden ist. Demnach ist es möglich, Gleichförmigkeit in dem Agent beizubehalten selbst wenn er migriert wird.
(3-2-3) Drittes Fehlerbeispiel
Betrachten nun das Verhalten des Agents in dem dritten Fehlerbeispiel, in welchem in dem ersten Skript Operationen bis zu dem Erhalten von der Datei file1 am Knoten node1 erfolgreich sind (Schritt 2209), aber bei dem letztendlich die Migration des Agents, um ihn zurückzuführen zum Knoten node0 fehlschlägt.
Dieser Fehler tritt in der sechsten Zeile des ersten Skripts auf, welche ist
%goto_with_goal node0 "return".
Dies ist ein Migrationsbefehl mit einem Unterziel, dessen drittes Argument "return" das Unterziel ist. In diesem Beispiel muss demnach, selbst wenn es der selbe Migrationsfehler ist, das Verfahren der Behandlung eines Migrationsfehlers durch den Agent unabwendbar unterschiedlich sein zu dem Fall des ersten Fehlerbeispiels.
Die Ausführungsmaschine des Agents empfängt durch die in 21 gezeigte Prozedur eine Meldung von dem Knotenmanager in Bezug auf das Fehlschlagen der Migration vom Knoten node1 zum Knoten node0 durch einen Befehl mit einem Unterziel, welcher ist goto_with_goal. In diesem Fall wird in Bezug auf das zu diesem Zeitpunkt ausgeführte Skript gemeinsam mit Information bezüglich der momentanen Ausführungsposition das Unterziel "return" in den Stapel geschoben und Neuplanung wird ausgeführt (Schritt 2211).
Vor dem Ausführen des Befehls goto_with_goal, weil die Inhalte der Agent-Datenbank bei Ausführen der Neuplanung hinzugefügt werden zu der fünften Zeile des ersten Skripts, sind es die folgenden. Das hinzugefügte Wissen "Zurückführen" bzw. "returning" hat die Wirkung des expliziten Aussagens, dass der Agent sich im Zustand des Zurückführens zum Knoten node0 befindet, welcher sein Heimatknoten ist.
%info(myself,home(node0)).
%info(myself,returning).
Ähnlich dem Fall des zweiten Fehlerbeispiels besteht die Datenbank der Felderstellung (field make) des Knotens node1 aus der folgenden Zeile.
%info(node1,maybe(exist(file(file1),node2))).
Die Inhalte der Knotendatenbank von node1 sind leer.
Das vierte Skript, welches basierend auf diesen Datenbanken und der zuvor angegebenen Aktionsdefinition und dem Planer erzeugt wird, ist die folgende einzelne Zeile.
%wait_and_goto node0
Dieser Befehl ist ein Befehl, der zum Warten für eine vorbestimmte Zeitdauer veranlasst und dann eine vorbestimmte Anzahl von Versuchen macht zum Ausführen einer Migration (Schritt 2212). Es ist leicht vorstellbar, dass ein temporäres Problem das Fehlschlagen der vorherigen Migration zum Knoten node0 verursachen kann. In diesem Beispiel erfordert das Anfangsagentziel von exist(file(file1),node2)) implizit die Existenz am Knoten node0, und es ist demnach erforderlich, den Fall zu betrachten, bei dem eine Änderung im Netz sein Verschwinden verursacht. Daher ist es angemessen, den Fehler der Migration vom Knoten node1 zum Knoten node0 als temporären Fehler nach zu verfolgen.
In dem Fall, in dem das Ausführen von wait_and-goto node0, welches das Skript ist resultieren von der Neuplanung, noch in der Unfähigkeit der Migration resultiert (Schritt 2213), weil es kein weiteres Unterziel gibt, wird der Agent von dem Zielstapel hervor geholt in Übereinstimmung mit der in 21 gezeigten Prozedur, und Neuplanung wird wieder ausgeführt unter Verwendung des Ursprungsziels von exec(file(file1)),node1). In diesem Fall ist das erzeugte Skript das selbe wie in dem Fall des zweiten Fehlerbeispiels, welches eine Migration zum Knoten node2 ist, gefolgt durch ein Zurückführen zum Knoten node0. Zu dem, wenn selbst das Ausführen dieses Plans zum Migrieren zum Knoten node2 fehlschlägt, wird der Agent als total ausfallend beurteilt. Die vorgeschriebene Abschlussverarbeitung wird ausgeführt, die Tatsache das der Knoten total ausgefallen ist wird aufgezeichnet in einem der Knoten.
Wenn das Ausführen von wait_and_goto node0, welches das Skript ist, das erzeugt wird durch Neuplanung, in einer erfolgreichen Migration zum Knoten node0 resultiert, ist das vierte Skript erfolgreich und endet dann, und der Agent wird hervorgeholt aus dem Zielstapel in Übereinstimmung mit der in 21 gezeigten Prozedur, und das Ausführen am Knoten node0 des ersten Skripts wird von Zeile 7 davon fortgesetzt. Diese Art von Erfüllung des Unterziels hat die Wirkung des Suchens nach einer Ersatzvorrichtung bei dem Migrationszielknoten in Bezug auf eine lokale Fehlfunktion, die in dem Fall auftritt, in dem eine Rückkehr des Agents zum Knoten node0 in dieser Ausführungsform vorgenommen wird.
Die Existenz eines Zielstapels innerhalb des Agents und das Portieren des Stapels gemeinsam mit der Migration des Agent hat die Wirkung des Bereitstellens einer Änderung zum Neuerstellen der Planung mit einem größeren Ziel in dem Fall, in dem eine lokale Ersatzvorrichtung nicht erfolgreich ist.
Während die erste Aktion und die zweite Aktion in der Aktionsdefinition beide Migrationsbefehle sind, wobei die erste Aktion eine Migration zum Zwecke des Findens einer Datei F ist, ist die zweite Aktion eine Aktionsdefinition für einen Agent, um das Ausführen eines vorgeschriebenen Befehls bei dem Migrationsziel zu erzielen und dann zum Migrationsausgangspunkt zurückzukehren.
Wie oben beschrieben ist es in der zweiten Ausführungsform, wie durch die ersten und zweiten Fehlerbeispiele angegeben, selbst in dem Fall desselben Migrationsbefehls durch Kodieren einer Aktion, die ein kontextempfindliches Unterziel in Übereinstimmung mit dem Agent-Kontext ausgibt, möglich, einen Agent zu kodieren, der eine Autonymität besitzt zum Ermöglichen des Unterbringens einer Vielzahl unerwarteter Änderungen.
(4) Wirkung der zweiten Ausführungsform
Wie oben beschrieben ist es in der zweiten Ausführungsform nicht nur möglich, einen Agent zwischen Knoten in Übereinstimmung mit einem Plan zu migrieren, sondern auch fernere Planung an einem Zielknoten vorzunehmen. Aus diesem Grund wird die tatsächlich ausgeführte Datenverarbeitung ansprechend auf die Stufe der Planausführung eingerichtet und den Zustand des Zielknotens, hierdurch eine Verbesserung der Effizienz der Datenverarbeitung bereitstellen (Ansprüche 16, 24 und 29).
Zudem wird in der zweiten Ausführungsform bei nur Information in Übereinstimmung mit dem Agent-Typ bei Erzeugen eines Plans verwendet wird, die Effizienz der Planerzeugung verbessert. Selbst wenn zwischen Knoten migriert wird, ist es weil ein Übergang zu einem dem Agent entsprechenden Feld vorgenommen wird, einen Plan auszuführen oder einen Plan zu erzeugen unter Verwendung von Feldinformation, die in derselben Weise wie zuvor die Migration entspricht (Ansprüche 19, 25 und 30).
Ferner ist es in der zweiten Ausführungsform weil der Agent gemeinsam mit seinen charakteristischen Informationen migriert wird, die am Zielknoten auch verwendet wird, möglich, eine Planung auszuführen, die zu dem individuellen Status eines Agent oder zu einer Aktion passt (Anspruch 18).
3. Andere Ausführungsformen
Die vorliegende Erfindung ist nicht auf die oben erwähnten Ausführungsformen beschränkt und umfasst die folgenden Beispiele als Ausführungsformen ebenfalls. Beispielsweise gibt es keine Einschränkungen in Bezug auf das Haben gegenseitig unabhängiger Hardware am selben Knoten, eine Konfiguration ist auch möglich mit einer Vielzahl von Prozessen implementiert in ein und derselben Hardware. Zusätzlich gibt es keine Einschränkung, nur einen Agent zu haben, es ist auch möglich, eine Vielzahl von Agents parallel zu betreiben. Auch gibt es keine Einschränkung bezüglich der Datenverarbeitung zu Dateienbetriebsabläufen, es ist auch möglich, eine Datenverarbeitung als frei einzurichten, beispielsweise eine Berechnung, eine Störung, eine Kommunikation mit einem anderen Knoten und ähnliches.
Die Inhalte der Lokalinformation werden nicht auf Namen der Knoten beschränkt, bei welchen eine Datei existieren könnte, es ist auch möglich, die Inhalte frei einzurichten, dass sie beispielsweise ein Domänenname sind, ein Hausname, ein Dateienverzeichnisname, eine Zugangs-ID und ein Passwort und ähnliches zum Zwecke des Zugreifens auf einen Bestandteil.
In Bezug auf die Inhalte der Agent-Information oder das Darstellungsformat eines Plans, wurden nur Beispiele präsentiert in Bezug auf die oben erwähnten Ausführungsformen und sie können frei eingerichtet werden. Beispielsweise ist es beim Repräsentieren eines Plans ohne Verwendung des Formates, bei welchem Aktionen durch kausale Verknüpfungen verbunden sind, möglich, einen Aktionensatz in der Form einer Listenstruktur oder einer Baumstruktur zu speichern. In der zweiten Ausführungsform war das Verfahren des Unterbringens von präsentierten Fehlern bloß ein Beispiel und es ist möglich, dieses frei einzurichten als irgendein anderes Verfahren. In der Ausführungsform der vorliegenden Erfindung ist es nicht absolut erforderlich, eine Struktur zu verwenden, bei der eine Wissensbasis aufgeteilt ist in Felder, in welchen charakteristische Agent-Information verwendet wird, und in welchen eine Vorher-Bedingung abhängig ist von den Migrationsbefehlen. Tatsächlich ist es in der Ausführungsform der vorliegenden Erfindung nicht absolut erforderlich, eine Struktur zu verwenden, bei der Information, die sich aus dem Fehler einer Tochteragent-Erzeugung ergibt, oder dem Fehler der Planung wenn ein Ausführungsfehler auftritt, oder dem Fehler der Ausführung, aktualisiert wird.
In dem Fall, in dem ein Anfragecode eingegeben wird, der erfordert, dass ein Plan erfolgreich erstellt und ausgeführt wird, ist es ansprechend auf die Natur der angewendeten Aufgabe nicht unbedingt erforderlich, eine Beurteilungsvorrichtung bereitzustellen. Auch der Agent braucht nicht als ein Prozess bei einem Knoten eingerichtet zu werden, es kann auch möglich sein, ihn mit dedizierter Hardware oder Software zu implementieren.
Auch ist während ein Datenverarbeitungsgerät und ein Datenverarbeitungsverfahren gemäß der vorliegenden Erfindung üblicherweise unter Verwendung eines Computerprogramms implementiert werden, ein Speichermedium, auf welchem ein solches Programm gespeichert wird auch eine Form der vorliegenden Erfindung (Anspruch 28).
Wie oben im Detail beschrieben ist es gemäß der vorliegenden Erfindung möglich, ein Datenverarbeitungsgerät bereitzustellen und ein Datenverarbeitungsverfahren, die flexibel Änderungen in den Bestandteilen der Software unterbringen und die ferner höhere Immunität auf Leitungsausfälle bereitstellen.

Claims

Datenverarbeitungseinrichtung, wobei ein ausführbarer Software-Prozess Datenverarbeitung an einem bestimmten Knoten (L, R; X) eines Netzes mit einer Vielzahl anderer Knoten (R, L; X) ausführt, wobei die Einrichtung umfasst: eine erste Speichervorrichtung (1L, 1R) zum Speichern einer ersten, einen Zustand von Bestandteilen des Knotens (L, R; X), auf den der ausführbare Prozess zugreifen soll, repräsentierenden Information; eine zweite Speichervorrichtung (3L, 3R) zum Speichern einer zweiten, Aktionen des ausführbaren Prozesses repräsentierenden Information; eine Planerzeugungsvorrichtung (5L, 5R), um ansprechend auf einen gegebenen Anfragecode einen eine Reihe von Aktionen des ausführbaren Prozesses unter Verwendung der ersten und zweiten Information repräsentierenden Plan zu erzeugen; eine Ausführungsvorrichtung (6L, 6R) zum Ausführen der Reihe von Aktionen des ausführbaren Prozesses an den Bestandteilen basierend auf dem erzeugten Plan; und eine Steuervorrichtung (7L, 7R) zur Migration des ausführbaren Prozesses von dem Knoten (L, R; X) zu andern Knoten (R, L; X); dadurch gekennzeichnet, dass die Steuervorrichtung (7L, 7R) eingerichtet ist zur Migration des ausführbaren Prozesses von dem Knoten (L, R; X) zu einem andern Knoten (R, L; X) ansprechend auf ein bestimmtes Ergebnis des Ausführens des ausführbaren Prozesses.
Datenverarbeitungseinrichtung nach Anspruch 1, wobei die Aktionen, falls erforderlich, eine Aktion einschließen, die eine Migration des ausführbaren Prozesses zu einem andern Knoten (L, R) implementiert.
Datenverarbeitungseinrichtung nach Anspruch 1, ferner eine Aktualisierungsvorrichtung (2L, 2R) umfassend zum Aktualisieren der ersten in der ersten Speichervorrichtung (1L, 1R) gespeicherten Information, wobei die Aktualisierungsvorrichtung (2L, 2R) eine Vorrichtung einschließt zum Aktualisieren der ersten Information basierend auf den geänderten Inhalten der Bestandteile, welche an jedem Knoten (L, R) eingegeben werden.
Datenverarbeitungseinrichtung nach Anspruch 1, ferner eine Aktualisierungsvorrichtung (2L, 2R) umfassend, zum Aktualisieren der in der ersten Speichervorrichtung (1L, 1R) gespeicherten ersten Information, wobei die Aktualisierungsvorrichtung (2L, 2R) eine Vorrichtung einschließt zum Aktualisieren der ersten Information, wenn eine gegebene Bedingung auftritt, durch Bezugnahme auf dem Netz entsprechender Information.
Datenverarbeitungseinrichtung nach Anspruch 1, wobei die zweite Speichervorrichtung (3L, 3R) umfasst: eine Vorrichtung zum Speichern eines Satzes von Aktionen, welche die Einheit für Operationen des ausführbaren Prozesses ist; eine Vorrichtung zum Speichern von Aktionsinformation, die einen Vorher-Zustand einschließt, der repräsentativ ist in Bezug auf ausführbare Aktionen und einen Nachher-Zustand, der repräsentativ ist in Bezug auf eine durch das Ausführen verursachte Zustandsänderung; eine Vorrichtung zum Speichern einer vorgeschriebenen Einschränkungsbedingung des Ausführens der Aktion; und eine Vorrichtung zum Speichern von Information, die repräsentativ ist in Bezug auf einen kausalen Zusammenhang zwischen den Aktionen; wobei die Planerzeugungsvorrichtung (5L, 5R) eine Vorrichtung umfasst zum Speichern in der zweiten Speichervorrichtung (3L, 3R) für eine vorgeschriebene Aktion des Satzes von Aktionen mindestens eine neue Einschränkungsbedingung und die Information, die repräsentativ ist in Bezug auf einen kausalen Zusammenhang, basierend auf der Aktionsinformation.
Datenverarbeitungseinrichtung nach Anspruch 5, wobei die Planerzeugungsvorrichtung (5L, 5R) zu dem Satz von Aktionen eine Aktion hinzufügt zur Migration des ausführbaren Prozesses zu dem andern Knoten ((R, L; X) mit der Vorher-Bedingung einer Aktion, die an dem andern Knoten (R, L; X) auszuführen, ist als eine Nachher-Bedingung, zum sequenziellen Auswählen nicht erreichter Ziele als Unter-Ziele, ferner sequenziell Aktionen mit Nachher-Bedingungen auswählt, die die ausgewählten Unter-Ziele erreichen, und für jede solche ausgewählte Aktion, in der zweiten Speichervorrichtung (3L, 3R) mindestens eines aus der Gruppe bestehend aus einer neuen Einschränkungsbedingung und Information speichert.
Datenverarbeitungseinrichtung nach Anspruch 5, wobei die Planerzeugungsvorrichtung (5L, 5R) zu jeder der ausgewählten Aktionen eine ausgewählte Aktion, die eine Vorher-Bedingung einer andern Aktion hingibt, hinzufügt zu der dem kausalen Zusammenhang entsprechenden Aktion.
Datenverarbeitungseinrichtung nach Anspruch 5, wobei die Planerzeugungsvorrichtung (5L, 5R) jede ausgewählte Aktion, die eine Vorher-Bedingung einer andern Aktion hingibt, und zu der die Einschränkungsbedingung hinzugefügt werden kann, welche den Verlust der Vorher-Bedingung vor dem Ausführen der andern Aktion verhindert, zu der Information hinzufügt, die repräsentativ in Bezug auf den kausalen Zusammenhang ist, und die Einschränkungsbedingung hinzufügt.
Datenverarbeitungseinrichtung nach Anspruch 5, wobei die Steuervorrichtung (7L, 7R) eine Migration des ausführbaren Prozesses basierend auf einer ersten Aktion der Reihe von Aktionen ausführt, und die Ausführungsvorrichtung (6L, 6R) eine zweite, von der ersten Aktion abweichende Aktion vor dem Ausführen der ersten Aktion ausführt, während die vorbeschriebene Einschränkungsbedingung erfüllt wird.
Datenverarbeitungseinrichtung nach Anspruch 6, außerdem eine Beurteilungsvorrichtung umfassend, um, wenn es kein unerreichtes Ziel gibt, eine Beurteilung zu treffen, dass ein Plan erfolgreich ist und dass ein Anforderungscode erreicht worden ist, ohne zu einem Ausführungsvorgang weiterzugehen, und ferner, um wenn es ein unerreichtes Ziel gibt und der Satz von Aktionen nicht leer ist, eine Beurteilung zu treffen, dass ein Plan erfolgreich ist, und dass ein Ausführen eines Plans erforderlich ist.
Datenverarbeitungseinrichtung nach Anspruch 1, wobei: der ausführbare Prozess festgelegt ist als ein Prozess an einem Knoten (L, R;); ansprechend auf die Migration des ausführbaren Prozesses von dem bestimmten Knoten (L, R; X) zu dem andern Knoten (R, L; X), eine Akzeptanzanfrage von dem bestimmten Knoten (L, R; X) zu dem andern Knoten (R, L; X) gesendet wird zum Vorbereiten der Akzeptanz des ausführbaren Prozesses, ein Prozess für den ausführbaren Prozess bei dem andern, die Akzeptanzanfrage empfangenden Knoten (R, L; X) festgelegt wird, eine Bereitschaftsmitteilung von dem andern Knoten (R, L; X) zu dem bestimmten Knoten (L, R) gesendet wird, die erste Information von dem bestimmten Knoten (L, R), der die Bereitschaftsmitteilung empfangen hat, zu dem andern Knoten (R, L; X) gesendet wird, das Ausführen des Prozesses basierend auf der empfangenen ersten Information bei dem andern Knoten (R, L; X), der die erste Information empfangen hat, gestartet wird, und der Prozess des ausführbaren Prozesses bei dem andern Knoten (R, L; X) beendet wird.
Datenverarbeitungseinrichtung nach Anspruch 1, wobei: der ausführbare Prozess einen Agent umfasst, wobei der Agent eine Reihe von Software-Prozessen ist, der gegebene Anfragecode ein gegebenes Ziel umfasst; und die Steuervorrichtung (7L, 7R) eingerichtet ist zur Migration des Agent von dem bestimmten Knoten (L, R; X) zu einem andern Knoten (R, L; X) des Netzes, wenn das Ausführungsergebnis durch den Agent an dem Knoten (L, R; X) nicht zufriedenstellend ist.
Datenverarbeitungseinrichtung nach Anspruch 12, wobei die Information, die sich an jedem der Knoten (L, R; X) befindet, aufgeteilt ist in eine Vielzahl von Feldern durch jeden Agent-Typ, und wobei ferner der Agent-Plan basierend auf Feldinformation entsprechend dem Agent erzeugt wird und die Migration zu einem andern Knoten (L, R; X) ausgeführt wird, um eine Migration des Agents zu dem entsprechenden Feld bei dem andern Knoten (R, L; X) vorzunehmen.
Datenverarbeitungseinrichtung nach Anspruch 12 oder Anspruch 13, wobei der Agent Information hat, die repräsentativ ist in Bezug auf einen charakteristischen Zustand einer Aktion des Agents, wobei die Information, wenn eine Migration zu einem andern Knoten (L, R) vorgenommen wird, gemeinsam mit dem Agent eine Migration erfährt, wobei die Information gemeinsam mit der ersten Information und der zweiten Information bei dem andern Knoten (R, L; X) verwendet wird zum Ausführen der Planung.
Datenverarbeitungseinrichtung nach Anspruch 12 oder 13, wobei die Planerzeugungsvorrichtung (5L, 5R) beim Erzeugen eines Migrationbefehls, der eine Migration eines Agent zu einem andern Knoten (L, R; X) vornimmt, oder eines andern Befehls als Teil eines Plans, eine Vorher-Bedingung als einen Zusatz zu dem Migrationbefehl oder dem andern Befehl anhängt.
Datenverarbeitungseinrichtung nach Anspruch 12 oder 13, wobei der Agent ein Zwischen-Sub-Ziel erzeugt zum Erreichen eines End-Ziels und einen Unter-Agent erzeugt zum Erreichen dieses Sub-Ziels.
Datenverarbeitungseinrichtung nach Anspruch 12 oder 13, wobei, wenn das Ausführen eines Plans oder die Migration eines Agents fehlschlägt, die Ausführungsvorrichtung (6L, 6R) das Planausführen unterbricht, die Planerzeugungsvorrichtung (5L, 5R) einen andern Plan erzeugt, und die Ausführungsvorrichtung (6L, 6R) den andern Plan ausführt.
Datenverarbeitungseinrichtung nach Anspruch 17, wobei, wenn das Ausführen einer Aktion oder einer Migration fehlschlägt während eines Teils eines Plans, die Planungserzeugungsvorrichtung (5L, 5R) ein Sub-Ziel erzeugt, um sich von dem fehlgeschlagenen Ausführen bzw. der Migration zu erholen und nach Abschluss des Ausführens dieses Sub-Ziels, Information zum Neustarten des Ausführens des Plans gespeichert wird, ein Plan basierend auf dem Sub-Ziel erzeugt wird und ausgeführt wird, und nach dem Ausführen des Plans basierend auf dem Sub-Ziel, die gespeicherte Information zum Fortsetzen des ursprünglichen Plans verwendet wird.
Datenverarbeitungseinrichtung nach Anspruch 12 oder 13, außerdem eine Vorrichtung umfassend zum Korrigieren von Information, die den Fehler verursacht hat, wenn das Ausführen eines Plans oder eine Migration basierend auf einem Plan fehlschlagen.
Datenverarbeitungsverfahren, wobei ein ausführbarer Software-Prozess eine Datenverarbeitung bei einem bestimmten Knoten (L, R; X) eines Netzes mit einer Vielzahl anderer Knoten (l, R) verarbeitet, wobei das Verfahren umfasst: Speichern einer ersten, einen Zustand von Bestandsteilen des bestimmten Knotens (L, R; X) repräsentierenden Information zum Zugriff durch den ausführbaren Prozess; Speichern einer zweiten, Aktionen des ausführbaren Prozesses repräsentierenden Information; Eingeben eines der Datenverarbeitung entsprechenden Anfragecodes; Erzeugen eines eine Reihe von Aktionen des ausführbaren Prozesses repräsentierenden Plans unter Verwendung der ersten und zweiten Information ansprechend auf einen gegebenen Anfragecode; Ausführen der Reihe von Aktionen des ausführbaren Prozesses an den Bestandteilen basierend auf dem erzeugten Plan; und Migration des ausführbaren Prozesses von dem Knoten (L, R; X) zu einem andern Knoten (R, L; X) gekennzeichnet durch ein Aktualisieren einer vorgeschriebenen Information der gespeicherten Information; wobei der Migrationschritt ansprechend auf ein bestimmtes Ergebnis des Ausführens durch den ausführbaren Prozess ausgeführt wird.
Datenverarbeitungsverfahren nach Anspruch 20, wobei das Speichern zweiter Information ferner umfasst: Speichern eines Satzes von Aktionen, welcher die Einheit zum Betreiben des ausführbaren Prozesses ist; Speichern von Aktionsinformation, die eine bezüglich der ausführbaren Aktion repräsentative Vorher-Bedingung einschließt und eine bezüglich durch das Ausführen verursachter Zustandsänderung repräsentative Nachher-Bedingung; Speichern einer dem Ausführen der Aktion entsprechenden, vorgeschriebenen Einschränkungsbedingung; und Speichern von für einen kausalen Zusammenhang zwischen den Aktionen repräsentativer Information, wobei das Erzeugen eines Plans das Speichern mindestens einer neuen Einschränkungsbedingung und der in Bezug auf den kausalen Zusammenhang repräsentativen Information für eine vorgeschriebene Aktion basierend auf der Aktionsinformation einschließt.
Datenverarbeitungsverfahren nach Anspruch 20, wobei: der ausführbare Prozess festgelegt ist als ein Prozess bei einem Knoten (L, R; X); ansprechend auf die Migration des ausführbaren Prozesses von dem bestimmten Knoten (L, R; X) zu dem andern Knoten (R, L; X) eine Akzeptanzanfrage von dem bestimmten Knoten (L, R; X) zu dem andern Knoten (R, L; X) gesendet wird, ein Prozess für den ausführbaren Prozess bei dem andern, die Akzeptanzanfrage empfangenden Knoten (R, L; X) zum Vorbereiten der Akzeptanz des ausführbaren Prozesses festgelegt wird, eine Bereitschaftsmitteilung von dem andern Knoten (R, L; X) zu dem bestimmten Knoten (L, R) gesendet wird, die erste Information von dem bestimmten Knoten (L, R), der die Bereitschaftsmeldung empfangen hat, zu dem andern Knoten (R, L; X) gesendet wird, das Ausführen des Prozesses basierend auf der empfangenen ersten Information bei dem andern Knoten (R, L; X) gestartet wird, der die erste Information empfangen hat, und der Prozess des ausführbaren Prozesses bei dem andern Knoten (R, L; X) beendet wird.
Datenverarbeitungsverfahren nach Anspruch 20, wobei: der ausführbare Prozess einen Agent umfasst, wobei der Agent eine Serie von Software-Prozessen ist, der gegebene Anfragecode ein gegebenes Ziel umfasst; und der Migrationschritt der Migration des Agents von dem bestimmten Knoten (L, R; X) zu einem andern Knoten (R, L; X) des Netzes ausgeführt wird, wenn das Ergebnis des Ausführens durch den Agent an dem Knoten (L, R; X) nicht zufriedenstellend ist.
Datenverarbeitungsverfahren nach Anspruch 23, ferner das Aufteilen verschiedener, an den jeweiligen Knoten (L, R; X) vorgesehener Information in eine Vielzahl von Feldern durch jede Art von Agent umfassend, wobei das Erzeugen des Agent-Plans auf einer dem Agent entsprechenden Feldinformation basiert, und die Migration des Agents zu einem andern Knoten (L, R; X) die Migration des Agents zu dem entsprechenden Feld bei dem Migrationzielknoten umfasst.
Datenverarbeitungsverfahren nach einem der Ansprüche 23 oder 24, wobei das Erzeugen eines Plans beim Erzeugen eines Migrationbefehls, der eine Migration eines Agents zu einem andern Knoten (L, R; X) oder einen anderen Befehl als Teil eines Plans ausführt, das Anhängen einer Vorher-Bedingung als eine Voraussetzung des Migrationbefehls oder des andern Befehls einschließt.
Datenverarbeitungsverfahren nach Anspruch 23 oder 24, außerdem, wenn eine Planausführung oder eine Agent-Migration fehlschlägt, das Unterbrechen der Planausführung und das Erzeugen eines anderen Plans und das Ausführen des andern Plans umfassend.
Datenverarbeitungsverfahren nach Anspruch 23 oder 24, ferner, wenn eine Planausführung oder eine Migration basierend auf einem Plan fehlschlägt, das Korrigieren von Information, die den Fehler verursacht hat, umfassend.
Speichermedium, auf welchem ein Computerprogramm gespeichert ist, das, wenn es ausgeführt wird, ein Datenverarbeitungsverfahren implementiert, wie es in einem der Ansprüche 20 bis 27 definiert ist.