1. Field of the Invention
The present invention relates to an agent management system, and more particularly to a system for monitoring and controlling an agent from its external environment, in a distributed processing system comprising a single computer or a plurality of computers inter-connected through a workstation and agents being application objects for autonomously operating thereon, and also to a system for constituting the agents to operate in such a manner.
2. Description of the Related Art
FIG. 1 of the accompanying drawings shows a composition of an application coordinating operation system described in Japanese Patent Application No. Hei 4-192112 filed by the present applicant. In FIG. 1, the numerals designate respectively: 65, a process-request input means; 66, a process-request accept means for accepting a process request from the process request input means 65; 71, an application coordinating operation environment which is composed of an environmental information monitoring means 67 for monitoring environmental information based on the process request from the processing request receiving means 66, coordinating operation environmental state information 68, and an environmental state information access means operating based on the application program 70; 72, a processed results output means for outputting a processed result of the environmental information monitoring means 67 in the application coordinating operation environment 71.
In the aforementioned composition, the application coordinating operation environment 71 monitors the environmental information using the environmental state information access means 69, the coordinating operation environmental state information 68 and the environmental information monitoring means 67 in accordance with the plurality of application programs 70 on the basis of the process request having been input from the process request input means 65 to the process request accept means 66, and outputs the processed results to the processed results output means 72.
In this application coordinating operation system, since a plurality of application programs 70 can actively function, it is possible to obtain desired processed results just by issuing process requests from the process-request input means 65 without requiring the system user to clearly indicate the names and positions of a plurality of applications to be used, the starting order of the applications, or data transference relationship among the applications.
FIG. 2 is a conceptual view of a conventional method for encapsulating applications shown in FIG. [2.1] of "Tools-Unifying Method in Software Developing Environment "Soft Beech/Encapsulator in UNIX"" (published by Yokogawa Hewlett Packard Co., Ltd. in July 1992).
As shown in FIG. 2, a window-based interface is accommodated at a portion where a standard input "stdin" and a standard output "stdout" are mutually communicated like in a pipeline, and are encapsulated.
This conventional encapsulating method is based on a so-called pipeline model in which an existing application program in the UNIX operating system reads out data from the standard input "stdin" and writes through the standard output "stdout" and a not shown standard error "stderr". In such a state, according to this method, the user can input and output instructions to the application (command of the UNIX) through the window-based interface i.e. a graphical user interface (GUI) without needing to change the source code of the application. This process is called encapsulation.
On the other hand, FIG. 3 shows a system diagram showing a conventional method for encapsulating applications described in "A Framework "SoftBench" Having Realized Inter-tools Unification" (published by Yokogawa Hewlett Packard Co., Ltd. in September 1992). This is a specific example of the concept shown in FIG. 2. In FIG. 3, the numerals designate respectively: 73, an operating system including signal processing 74; 75, a system call; 76, a BMS (Broadcast Message Server); 77, an event handler; 78, a system event trap; 79, a message event trap; 80, a program capable of being executed by an existing application; 81, an application event trap; 82, a user event trap; 83, an X server; 84, a human interface including a display terminal 85; 86, a standard input (Stdin); 87, a standard output (Stdout) and a standard error output (stderr); and 88, an EDL (Enclosing-type encapsulating program: Encapsulator describing language).
In the aforementioned composition, when the existing application 80 follows a pipeline model, a GUI object suitable for the input/output form of the data to/from the application is set. The EDL 88 is used to describe the event handler 77 in order to connect the input/output data patterns to the GUI object. The event handler 77 newly provides a GUI object being displayed on the X server 83 of the display terminal 85 presenting the human interface 84, and the user event trap 82 in the event handler 77 receives the event generated by the GUI object. The corresponding data defined in the event handler 77 are then input to the existing application 80 through the standard input 86.
The output from the existing application 80 is transferred to the application event trap 81 via the standard output and standard error output 87, and is also displayed on the screen of the display terminal 85 through the X server 83 to be viewed by the user.
It is also possible to describe: the issuance of the system call 75; processing of the signal from the operating system 73; or the communicating operation with the BMS 76; in the event handler 77.
The signal processing 74 is accepted by the system event trap 78 and is then processed in the event handler 77. The BMS 76 controls the broadcasting of the message between other applications. The message event trap 79 receives the message from the BMS 76, and cooperation with other applications can thus be indirectly realized. These series of processes are described as an encapsulated program in the form of the event handler 77 by use of the EDL 88.
This encapsulating program is processed in accordance with the operation shown by way of a flow diagram in FIG. 15.
FIG. 4 is equivalent to FIG. [2.3] shown in the aforementioned "Tools-Unifying Method in a Software Developing Environment "Soft Becch/Encapsulator" in UNIX" (published by Yokogawa Hewlett Packard Co., Ltd. in July 1992).
When the system starts operating, an action function is set in step S1.
In the next step S2, the event to be dealt with in the system is defined by use of a function make--event.
In step S3, the construction of the GUI i.e. the object, is defined by use of a function make--manager and make--object.
In step S4, the system enters an event processing loop with display and start functions, and thereafter, processes 1, 2 and n of steps S5, S6 and Sn respectively corresponding to each event are continued by an event-driven method.
Since the conventional autonomous coordinating environment is constructed as the aforementioned application coordinating operation system, it is possible to readily monitor and control the autonomous coordinating environment from the outside. It is quite hard, however, to finely monitor and control the applications and agents actually operating and functioning in that environment directly from the outside in accordance with the external environment.
Further, if there is any information becoming newly necessary and which has not been previously provided in the agents or applications, it is impossible to add and monitor/control such information in order to monitor and control the agents and the applications in such a system.
Meanwhile, even when monitoring/controlling operations being common to a plurality of agents or applications in a system are to be executed, it is necessary to previously build in each agent application the common method necessary for the monitoring/controlling operations. This is quite inefficient and is not able to perform new monitoring/controlling operations.
Moreover, it is not possible either to join any existing application not being made to operate in an autonomous coordinating operation system to the coordinating operation likewise other agents, or to monitor and control such applications in the same manner.
In addition, for making any application already having a window-based GUI operate in an autonomous coordinating operation environment and for monitoring and controlling it, the source codes of the application must be directly changed for incorporation of a monitoring/controlling method therein. It is therefore quite inefficient to reuse the existing application in the autonomous coordinating operation system.
Further, even when a common monitoring/controlling operations must be made for a group of a plurality of agents having similar functions, similar monitoring/controlling operations must be applied to each of the agents one by one, which significantly lowers the efficiency.
Moreover, when a plurality of autonomous coordinating operation environments are mutually communicated, it is quite difficult to flexibly perform the mutual operations of the whole system without changing the policy of the monitoring/controlling operations existing in every autonomous coordinating operation environment.
As mentioned above, since the conventional system has a number of disadvantages, it has been expected to realize an agent management system which is capable of monitoring and controlling the data and action of agents operating in an autonomous coordinating operation system from an external environment.