• Aucun résultat trouvé

The Brain

Dans le document Software agents in network management (Page 104-109)

The Brain offers basic and innate facilities necessary for the agent operation. In Fig-ure 4.2, we distinguish the four functional parts of the agent’s brain: Belief management, skill management, inter-agent communication and skill interface.

Skill Management

TheBelief Databasecentralizes all the beliefs produced by the skills loaded into the agent.

In this way, beliefs can be accessed concurrently from any skill. TheBelief Manager al-lows the skills to query and modify the agent belief database. Besides the usual database operations that allow to retrieve, delete, create and modify the beliefs, the belief man-ager allows the skills tosubscribeas listeners to specific changes in the database. For example, a skill that is responsible for the monitoring of the printing service would be interested in each new printer that is introduced in the network. Therefore, the printing skill should subscribe for the creation and deletion of beliefs corresponding to printing devices (which could be supplied by a discovery skill for instance). The belief manage-ment services can be summarized in the following items:

Belief querying service using theaskprimitive.

Belief manipulation services using theinsert,delete, andupdateprimitives.

Belief subscription services using thesubscribeandunsubscribeprimitives.

Belief notifications services following subscription requests.

4.4.2 Skill Management

TheSkill Baseholds the declarative information describing the belief templates and ca-pabilities brought by each skill known to the agent. This knowledge allows theSkill Man-agerto help the agent making efficient use of the functionality offered by each skill. In that, the services offered by the skill manager are enumerated in the following items:

The skill manager links belief changes and action execution requests to their re-spective skills. For belief changes, we mentioned earlier that it is up to the skill to insure the coherence and integrity of its beliefs (i.e. beliefs that are instances of the belief templates defined by this skill). Therefore, changes to such beliefs caused by other skills has to be notified to the corresponding skill to take integrity-maintenance actions when necessary.

For action execution requests, the skill manager looks in the skill base to determine which skill defines the capability that allows to execute this action. The action exe-cution request is then transmitted to that skill.

When an action, say action

A

, requests the execution of another action, say ac-tion

B

, the skill manager automatically subscribes the skill of action

A

to the belief modifications caused by action

B

. This allows action

A

to have a strict control of the evolution of task

B

, and to use the results produced by the latter task as soon as these results are produced. To tranparently set the necessary subscription, the skill manager directly invokes the subscription methods in the belief manager. This is only the default behavior of the skill manager, and can be turned off if deemed unnecessary.

The skill manager keeps track of the tasks performed by the agent. Each task is associated to the capability from which it is instantiated, and therefore to the cor-responding skill.

The skill manager is also responsible for the loading and unloading of agent skills.

The corresponding methods are respectivelyloadSkillandunloadSkill.

Skill loading is achieved either locally or cooperatively with the other agents. The skill manager first searches for the required skill in the local repository of the agent skills. If this search fails, the skill manager sends search requests to the other agents.

Another agent may have the requested skill available and can therefore serialize its code to the requesting agent. Again, this is the default behavior, and can be modi-fied by designing a special skill that intercepts the skill loading query and performs

the skill search process in a different way. The Directory Service skill presented in Section 4.7 is an example of such skill.

Once a skill is loaded, it may require some initialization operations, for example to generate primitive beliefs for its operation. Every skill is endowed with awarmup method for this purpose. The skill manager calls this method as soon as the skill is successfully loaded.

Skills can also be unloaded from the agent. In order to correctly stop the skill activ-ity and to remove its corresponding beliefs, every skill has a disposal method. The skill manager calls this method before a skill can be successfully unloaded.

Therefore, the high-level role of the skill manager is to coordinate the agent tasks and to provide systematic associations between belief changes and the running tasks. This is made possible by the declarative information provided by the skills and stored in the skill base.

4.4.3 The Inter-agent Communication

The Brain offers inter-agent communication facilities that allow skills from different agents to interact in a transparent way. TheCommunication Moduleis responsible for sending to and receiving requests from the other agents, whereas the Social Manager holds such information on the other agents as the host on which they run as well as their addresses. Therefore, skills only deal with the symbolic names of the distant agents with which they interact, and they are not aware of distribution-related details in the agent system.

The communication module provides a set of methods that allow to send communi-cation messages to remote agents. Each method corresponds to a certain performative (see Section 4.5). The name of the agent is resolved by the social manager and trans-formed into a network address (URL).

The communication module receives messages from the other agents. According to the message performative, the message is forwarded either to the belief manager, or to the skill manager. In the particular case of belief query (i.e.askperformative), the com-munication module submits the query to the belief manager and automatically initiates a reply with the result to the remote agent.

Many network protocols can be supported by the communication module including raw TCP, UDP, HTTP and SMTP. This allows to adapt the used communication protocol according to the size and the nature of the information to be exchanged between the agents.

The records maintained by the Social Manager can be mapped into beliefs in the be-lief database. These bebe-liefs allow the skills to make use of the knowledge on the other agents. Particularly, one may build a registration skill that can be loaded into an agent to make it ensure the role of an agent name server. They also allow an agent to ask another agent for the list of all the agents the latter knows about.

4.4.4 The Skill Interface

TheSkill Interfaceis responsible for the dynamic plugging of skills during the agent op-eration. It also ensures the important role of managing the Skill-Brain interaction. The skill-to-brain interactions can be either belief queries, which are forwarded to the belief management part of the brain; task invocations and skill loading orders, which are for-warded to the skill management part; or communication acts, which are forfor-warded to the communication part.

The brain-to-skill interactions are either:

request for the skill declarative information, which is required for skill loading by the skill manager,

request to warmup the skill after being successfully loaded,

notifications for relevant belief changes,

capability invocation to initiate the execution of some tasks,

or a request for skill disposal before the skill is unloaded.

In each of these cases, the skill interface is responsible for forwarding each interaction from the brain to the right skill.

4.5 Agent Communication

Compared to KQML and FIPA ACL (Agent Communication Language), our approach to agent communication is more pragmatic. First, we adopted a set of performatives that are directly useful for NM purposes. This is a bottom-up approach driven by require-ments, opposite to the top-down approach of Benech [Ben99], who applied KQMLas a wholeto NM. The communications requirements in NM are to efficiently exchange in-formation, and to delegate management tasks.

Second, we provided a set of performatives to directly manipulate the beliefs of the agent. Such performatives do not exist in ACL (Agent Communication Language), and

KQML contains only one of them (insert). However such direct belief manipulation is very practical, especially when there is an authoritative relationship between some agents, e.g. a hierarchical authority.

Moreover, we preferred to be explicit in the meaning of the defined performatives.

While FIPA ACL (Agent Communication Language) uses therequestperformative to ask for action execution, we call itrequestAction, since arequestin its general meaning may potentially imply an information request, an action request, or a service request.

Finally, theaskperformative is synchronous in our case. This means that the cor-responding method in the communication module of the brain blocks until a reply is received from the remote agent. This might seem to be inefficient at first glance. How-ever, a synchronous query is easier to use and we rarely encountered cases in which an askquery requires to be asynchronous.

Accordingly, we defined a set of ten performatives:

tell:Allows an agent

A

to inform another agent

B

of a subset of

A

’s beliefs.

ask:Allows an agent to query the beliefs of another agent. Replies are contained in tellmessages.

insert, delete, update:Allow to respectively add, remove or modify a belief or a set of beliefs in the receiver’s belief database.

subscribe:Allows an agent

A

to inform another agent

B

that

A

requires to be no-tified of specific changes in

B

’s belief database. In this case,

B

must send tell

messages for each relevant change in its beliefs. A subscription messages contains a special field to specify which belief manipulation (insertion, deletion, update) are interesting for the subscriber.

unsubscribe:Allows to stop the effect of a precedingsubscribemessage.

achieve:Allows to make the receiver reach a certain state on the managed network.

The content of anachievemessage is an abstract goal that yields the agent to look for the necessary actions to achieve it. Since we did not include any real planning in the agent’s brain, anachievequery should be completely handled by the involved skills if need be.

requestAction:Allows to delegate the execution of a specified action to the receiver agent.

stopAction: Allows to stop an action that has been launched due to a preceding requestActionmessage.

Like in ACL (Agent Communication Language), every message contains a number of fields that specify the context of the agent conversation (conversastion-id) and the message references (message-id,in-reply-to, reply-with). Some performatives re-quire optional fields such as theon-eventfield in thesubscribeperformative, which specifies when notifications should be sent (periodically, following a belief suppression, etc). In contrary, there is no support for ontologies. The reason is that ontologies are suitable only for knowledge sharing, i.e. for an open agent system where agents may deal with different subjects that might use the same terms for different concepts defined in different domains. In our case, we have only one context: Network Management.

Finally, we note that in the following of the manuscript, we make use of a message syntax that is similar to that used in KQML and ACL (Agent Communication Language), although we use a slightly different way to encode these messages to transmit them over the network.

Dans le document Software agents in network management (Page 104-109)