The role identification phase is identical to that described in Chapter 5 and therefore, we simply reuse the same defined roles. The purpose here is mainly to experiment the BDI approach and not to reach a fully operational agent system. Therefore, this work restricts to the domain agent roles, i.e. it considers only the roles of tester, testee and domain monitoring. The implementation of the domain agent role is sufficient to perceive the main concepts of a BDI agent approach.
The specification of these roles using the abstract agent model is described in the following sections.
7.3.1 The Domain Monitoring Role
Goal Generation To make an agent ensure the role of domain monitoring, it must be motivated to have the status belief for each of the NEs in its domain. We use the same belief templates as in Chapter 5: aninMyDomainbelief specifies an NE in the agent’s do-main, and anetworkElementStatusbelief specifies the status of a NE. Accordingly, the domain monitoring motivation can be expressed as:
(inMyDomain :ne ?e) , (networkElementStatus :ne $e) (M1).
This motivation is formulated as a
p
,q
expression, which is violated either whenp
holds andq
does not hold, or whenq
holds andp
does not hold. The first case oc-curs when a new NE is added to the agent’s domain. This causes the agent to create the following goal:(achieve (networkElementStatus :ne $e)) (G1).
The second case in which(M1)is violated corresponds to an NE that is removed from the agent’s domain. For this situation, the generated goal is:
(achieve (not (networkElementStatus :ne $e))) (G2).
Intentions To achieve goal(G1), the agent needs a sensor to perceive the status of the NE. TheStatusMonitoringSensoris defined for this reason. To start it on an NE, the agent must execute:
(startSensor StatusMonitoringSensor :ne $e)
which will create and maintain the missingnetworkElementStatusbelief, thus leading to the satisfaction of the motivation.
Goal(G2)can also be easily achieved, assuming a closed world assumption for the networkElementStatusbeliefs, by executing:
(stopSensor StatusMonitoringSensor :ne $e).
7.3.2 The Tester Role
Goal Generation An agent
A
ensures the tester role regarding a testee agentB
whenit has a belief on the reliability of agent
B
. As in Chapter 5, such belief is written as (sldStatus :agent B :status reliable). Therefore, to make agentA
ensure the tester role, it should simply be motivated with:(sldStatus :agent B) (M2).
Satisfying this motivation requires the generation of multiple successive goals. Firstly, the tester should have a belief containing a set of, let us say, three representative elements in agent
B
’s domain. Therefore, the following goal has to be generated:(achieve (selectedNetworkElements :agent B :element1 ?elt1 :element2 ?elt2 :element3 ?elt3)) (G3)
Once this goal is achieved, or if it is already achieved, the next step is to have agent
B
’s belief onelt1,elt2andelt3. For each of these elements, a goal (achieve (believedNetworkElementStatus :agent B :ne $elt)) (G4)is generated, where the belief (believedNetworkElementStatus :agent B :ne $elt :status DOWN)tells that agent
B
believes that the status ofeltis down.Afterwards, agent
A
has to start monitoring the selected NEs. This is done exactly in the same way as for the domain monitoring role, i.e. by generating goal(G1).Finally, if all the above goals are achieved, then all the beliefs required to deduce agent
B
’s reliability status are available. The goal:(achieve (sldStatus :agent B)) (G5) can be generated and successfully achieved.
Later in time, the domain of agent
B
might change. One (or more) of the three ele-ments, let us sayelt1, that have been chosen in theselectedNetworkElementsmay be replaced by another element, e.g. elt4. When agentA
get informed of the change, the motivation becomes violated since the status belief onelt4is missing and, hence, the SLD status of agentB
cannot be maintained. Consequently, agentA
will successively generate the following goals:(achieve (not (believedNetworkElementStatus :agent B :element $elt1))) (G6).
(achieve (not (networkElementStatus :ne $elt1))), which makes the agent stop theStatusMonitoringSensoron$elt1.
(achieve (believedNetworkElementStatus :agent B :ne $elt4)).
(achieve (networkElementStatus :ne $elt4)).
Intentions To achieve goal(G3), we use the same approach as in Chapter 5, i.e. the tester agent asks the testee to establish a list of selected NEs, then subscribes for them.
The way this approach is mapped in this context consists of two steps. In the first step, the tester agent recursively delegates the same goal(G3)to the testee agent. The way the testee agent achieves(G3)is described in the next subsection. In the second step, the tester agent sends a subscription message for the selectedNetworkElements be-lief of the testee agent. As soon as the testee agent replies with atellcontaining the selectedNetworkElementsbelief, the tester inserts it into its belief database. Hence goal (G3)becomes achieved.
Goal (G4) can be achieved by sending a subscription message to agent
B
,ask-ing it for the status of the required NE. Each time agent
B
sends a tell messagewith a networkElementStatus belief on a selected NE elt, agent
A
converts it to a (believedNetworkElementStatus :agent B :ne $elt :status ...)belief.Finally, goal(G6)is achieved in the opposite way. The tester agent first unsubscribes for the(networkElementStatus :ne $elt1)belief in agent
B
, then retracts the corre-spondingbelievedNetworkElementStatusfrom its belief database.7.3.3 The Testee Role
The testee role is a passive role, in the sense that there is no need to motivate the testee agent to make it ensure the role. In fact, the testee agent only replies to the queries sent by the tester agent, and achieves what it is asked to do. For example, when the tester re-ceives the message containing goal(G3), it integrates the goal in its mental cycle and tries to achieve it. The achievement of this goal is simply done by activating the correspond-ing calculatorTopThreeImportantElements. This persistent calculator creates the belief (selectedNetworkElements :agent B)and updates it whenever the domain of agent
B
evolves.
In addition, the testee agent must be able to manage multiple subscriptions originat-ing from different testers. For example, suppose that there is another agent, agent
C
, thatis also testing agent
B
. If later in time, agentC
is no longer motivated to test agentB
, thenagent C should unsubscribe on agent
B
’s belief(selectedNetworkElements :agent B), and then tells that agentB
no longer needs to have this belief achieved. However, agentB
should be aware that agentA
still needs the belief and therefore, it should not stop maintaining it.Although this problem frequently occurs in distributed agent-based design, we still do not provide a high-level solution to tackling it. Instead, we postpone its resolution to the implementation phase.
The implementation is based on an agent programming framework that supports many interesting agent concepts. This Java-based agent programming framework is called JACK. The next section provides an overview of JACK concepts, while the section after details how JACK was applied to implement the proposed BDI abstract design.