7.5.1 General Considerations
While mapping our agent specifications detailed in Section 7.3 to JACK concepts, some aspects are translated in a general way, while others are translated in a case-by-case basis.
This section presents the generally-used translations.
7.5.1.1 Agent Communications
The only means of communication in JACK areMessageEvents. However,MessageEvents do not offer built-in facilities to handle subscriptions and goal integration into the agent’s mental cycle. Therefore, to map agent communication messages in JACK, our imple-mentation used normal MessageEvents that are handled with specific plans. These plans take into account the performative semantics of the corresponding message. For exam-ple, the message sent to an agent to subscribe for the status of an NE is mapped into aSubscribeNetworkElementStatusMessage. This message is handled by a plan that first checks whether the required belief exists or not, then adds the subscriber agent to a list of subscribers which is stored as a private attribute in the agent Java class. The subscribers list is indexed according to the NEs. When a change occurs in thenetworkElementStatus database, the subscribers list is checked to find if there are subscribers on the changed NE. If so, an appropriate message is sent to all the NE subscribers.
7.5.1.2 Motivations Handling
In our implementation, we simulated the motivational behavior using goal events and database events. Each motivation is implemented using a goal event that activates the motivation, and another goal event to discard it from the agent’s mental cycle. Theses goals are handled by plans that lead to the motivation satisfaction, or respectively, to its removal. To make the agent detect that the motivation is violated, special database events are defined and triggered when violation situations occur. These events are also handled by dedicated plans that are able to resolve the problem. Obviously, the plans that handle a motivation violation are triggered only when the motivation is active in the agent’s mental cycle.
7.5.1.3 Operational Layer
JACK does not explicitly support the definition of agent capabilities. Instead, we used JACK concepts to have the same function as that of the operational layer. In that, the
different calculators are replaced by database-event driven plans. For example, the TopThreeImportantElementscalculator is replaced by a plan that handles an event corre-sponding to the addition or removal of an NE in the agent’s domain, and re-computes the three selected NEs, then updates the corresponding belief accordingly. Reactors could be implemented in a similar way.
The StatusMonitoringSensorwas implemented in a separate class and runs in its own execution thread. Special methods are defined in the agent class to start and stop a sensor within a plan definition. A sensor can update the agent’s beliefs by invoking belief database methods. Effectors can be implemented in a similar way.
7.5.2 BDI-oriented Implementation
7.5.2.1 Implementation of the Domain Monitoring Role
The motivation (M1), which makes the agent ensure the domain monitor-ing role is replaced by two goal events: StartDomainMonitoringGoal and StopDomainMonitoringGoal.
In JACK, it is not possible to specify composite expressions, such as (M1), in an
@achievestatement. For this reason, a new belief(DomainMonitoring :is enabled)is created when the domain monitoring is enabled. Therefore, motivating the agent to en-sure the domain monitoring is equivalent to the following JACK statement:
@achieve ((DomainMonitoring :is enabled), StartDomainMonitoringGoal).
The plan that handles this goal simply loops on all the NEs listed in InMyDomain beliefs and starts the monitoring sensor for them. Similarly, the plan that handles StopDomainMonitoringGoaldoes the same loop and stops the monitoring sensor on all the NEs in the agent’s domain. This plan is invoked as a response to such statement:
@achieve ((not (DomainMonitoring :is enabled)), StopDomainMonitoringGoal). To ensure that new NEs added to the domain are included in the domain monitor-ing, and that the monitoring stops on the NEs that are removed from the domain, the InMyDomaindatabase generates anInMyDomainUpdateevent whenever an NE is added or removed from the agent’s domain. This event is handled by a plan that accordingly starts or stops the monitoring sensor on that NE.
7.5.2.2 Implementation of the Tester Role
Similarly to the domain monitoring role, to motivate an agent A to ensure the role of a tester for a testee agent B, the following achieve statement should be used:
@achieve ((sldStatus :agent B), SldOnAgentGoal).
This statement generates the goal eventSldOnAgentGoal, which makes the agent be a tester of agent B. The plan that handles this goal event generates equivalent goals to those described in Section 7.3.2.
Getting the Three Representative Elements. The following JACK statement allows to have a selection of three elements in the testee’s domain:
@achieve ((selectedNetworkElements :agent B), SelectThreeElementsGoal). In each agent, there are two distinct plans that deal with goalSelectThreeElementsGoal.
First, the plan for the tester role simply sends a
SubscribeThreeSelectedElementsMessage to the testee agent. The semantics of this message combine both, to achieve goal (G3) and to subscribe for the re-sulting selectedNetworkElements belief. Afterwards, the plan waits until the re-ply of the testee agent is received and processed. The testee agent replies with a TellChangeInSelectedNetworkElementsmessage event containing the three selected NEs. A plan in the tester agent handles this event by creating the corresponding selectedNetworkElementsbelief. The same process occurs when there is a change in the three selected NEs in the testee domain.
Second, the plan for the testee role finds out the three candidate NEs and generates the correspondingselectedNetworkElementsbelief. The content of this belief is then sent to the tester agents. To ensure that this belief is maintained, another plan catches theInMyDomainUpdatedatabase event to update theselectedNetworkElementsbelief if necessary.
Getting the Testee’s Beliefs on Network Element Statuses. The next step consists in obtaining the testee agent’s beliefs on the three selected NEs. This step is initiated by the following statement:
@achieve ((believedNetworkElementStatus :agent B :ne $elt), BelievedNetworkElementStatusGoal).
The plan that handles this goal sends aSubscribeNetworkElementStatusMessageto agent B, and waits until the reply is received and processed. However, JACK does not al-low to express explicit parallel tasks in plans. Therefore, the tester agent would not be able to send the subscribe message for the second NE unless the reply for the first NE is already received and processed. This causes serious performance degradation since the tester agent simply hangs waiting for communication replies, while it is possible theo-retically to send the subscription for the three selected NEs at the same time, and wait for the replies asynchronously. This is what was indeed done in the current
implementa-tion. Instead of the above synchronous@achievestatement, the subscription message is directly sent as the following:
@send (B, SubscribeNetworkElementStatusMessage).
Since communication in JACK is asynchronous, the three subscription messages can be sent and replies processed asynchronously without blocking the initial plan.
The subscription message is handled in the testee agent by registering the sender as a subscriber to the NE status and sending back aTellNetworkElementStatusmessage.
Another plan that handles the database eventNetworkElementStatusChange(which is generated each time a beliefnetworkElementStatuschanges) ensures to notify all the subscribers for an NE status of changes that may occur.
Later on, when the tester agent receives theNetworkElementStatusChange, the han-dler plan maps it into a(believedNetworkElementStatus :agent B :ne $elt :status ..)belief.
We refer back to the problem of managing multiple subscriptions by agent B, men-tioned in Section 7.3.3. If agent A unsubscribes in agent B for the three selected NEs, then agent B should not stop maintaining this belief if another agent C is still subscribed.
For this purpose, the agent Java class contains a table of all the subscriptions for the selectedNetworkElementsbelief. When this table becomes empty, the agent stops main-taining theselectedNetworkElementsbelief and removes it from its database.
Computing the Testee SLD Reliability Status After launching the sensors on the se-lected NEs in agent B’s domain, agent A has all the necessary information to deduce the reliability of agent B. TheComputeSldplan is triggered whenever a change in the status of a selected NE is updated. The plan compares the new status with the last recorded belief received from the testee agent. By combining this comparison with the results of the other selected NEs, the reliability status of the testee agent is deduced and used to update theagentSldStatusbelief.