A novel approach for scalability and performance enhancement in JADE

Abstract

In multi-agent systems, the yellow pages service is very important for agents to be able to interact with each other. The more the number of agents is high, the more performance degradation will result, due to the overload of requests sent to central yellow pages. This issue didn’t get much attention from researchers despite its importance. The proposed approach for solving this scalability issue is based on the aspect-oriented paradigm. An aspect was used to play the roles of a replicator and a distributor of requests to several new yellow pages. The use of aspect-oriented programming simplifies the implementation, reduces the maintenance effort and offers a good reusability of the proposed solution. The approach is validated on three JADE applications and evaluated on five different machines. Results, which are very promising, show a significant scalability and performance improvement of the yellow pages service especially on Linux operating system.

Keywords

Perfective maintenance performance scalability yellow pages multi-agent systems

1. Introduction

During the last decade, the development of multi-agent systems (MAS) has aroused great interest in the research community. The agent paradigm offers, in fact, undeniable advantages in the development of software systems that can operate in complex, distributed, heterogeneous and open environments. Several MAS development methodologies have, indeed, been proposed in the literature [1, 2]. The main objective is to facilitate and support the development of agent-based applications. These methodologies have allowed real progress in the design and implementation of MAS. However, maintenance of agent-based applications is not yet sufficiently addressed [3].

Software maintenance is still the most complex and expensive phase of agent-based applications life cycle. Maintaining existing source code is more economical than rewriting or replacing it with a new one [4, 5, 6, 7]. If the maintenance activity of procedural and object-oriented programs [8, 9] was the subject of several research projects, it is not the case of multi-agent applications, which have their proper specificities like deliberation, communication, etc. Although MAS represent an active research area, agent-based applications maintenance remains preliminary and has not yet achieved a high level of maturity [10, 11, 12]. Indeed, there are still various crucial issues that have not yet been addressed.

Enhancing the scalability and the performance of multi-agent systems [13] has been the interest of many researchers even recently by focusing on improving agent properties like deliberation [14, 15, 16], cooperation [17], communication [18], reactivity [19], etc. One of these properties is the yellow pages service [20] (directory or matchmaking service). It is a very important service for agents to be able to interact with each other. Many researchers have highlighted the importance of a scalable and efficient yellow pages service in many fields [21, 18, 22]. In this service, the more the number of agents is high, the more performance degradation will result, due to the overload of requests sent to central yellow pages, which cannot handle these requests especially on high frequency. This is a major problem and can lead even to a total system breakdown.

The proposed approach for solving this scalability issue is based on the aspect-oriented paradigm [23]. An aspect that plays the roles of a replicator and a distributor of requests to several new yellow pages was used. This aspect creates a number of yellow pages copies and manages all the registration, deregistration and modification requests to ensure data consistency. All the yellow pages take turn to respond to the search requests, which will be distributed by the aspect to ensure a load balancing over all the yellow pages of the system.

Furthermore, our approach facilitates the maintenance process which does not require any change in the original source code by using aspect-oriented programming. In addition, the added functionalities are located in one aspect, which means better understanding, tracking and documenting.

This work focuses on a crucial issue in agent-oriented software engineering and aims to developing a new perfective maintenance approach that allows to enhancing the scalability and the performance of the yellow pages service [24] for existing large scale applications.

The proposed approach has been validated on three JADE applications using five different machines. Obtained results are very promising and show a great performance improvement of the yellow pages service especially on Linux operating system.

The remainder of this paper is organized as follows. In Section 2, a brief overview of major related work is given. Section 3 presents preliminaries. The proposed approach is presented in Section 4. Section 5 illustrates the validation and discussion of the proposed approach using three concrete case studies. Section 6 gives some conclusions and future work directions.

2. Literature review

In MAS, agents need to interact in order to achieve their tasks. Therefore, interaction is an important property in agent societies. An agent is able to interact with another one only if it knows its location that can be found using a service called the yellow pages. The more agents search for each other using this service, the more performance decrease will result due to the overload of the requests. In this case, the MAS will not be able to respond to the search requests in a proper time, which increases exponentially. These delays will propagate to other processes leading to a very slow system, to exceed timeout constraints and even to a total system breakdown. To prevent these situations from accruing, many researchers have proposed different approaches even recently to enhance the system’s overall performance by enhancing some of its properties, like deliberation [14, 15, 16], cooperation [17], communication [18], and reactivity [19]. Unfortunately, not like other agent properties, only few researches have been done to enhance this service by proposing different architectures like in [21], where the authors have focused on how to store and propagate information within cyber physical production systems, using a directory facilitator different than the usually used one of the JADE platform. This is the consequence of its centralized architecture that can produce bottlenecks when the system is scaled up. They proposed an agent called Capability Dissemination Agent (CDA) which is a redundant, decentralized and resilient extension of the available Directory Facilitator (DF). They validated their approach which provided correct propagation with more robustness and change resilience. Their work needs more improvements to establish the best CDAs distribution based on the system topology and scale.

In [22], authors have presented the use of homophily, which is a social feature that is present in complex networks that acts as a self-organizing criterion to create a decentralized and self organized structures. The agents have a greater probability of establishing links with similar agents than with dissimilar ones. Their approach, where agents collaborate with each other to perform a service discovery in contradiction to the centralized services as they mentioned, suffers from bottleneck situations, lack of coordination, outdated data, larger required memory space, etc. The results of their evaluation showed a considerable improvement in the performance of the system providing a high success rate and short paths.

In [25, 26], authors propose a category based service discovery, which employs a category database searching method instead of a sequential searching method. Similarly to [27, 28], where the authors propose a new yellow pages service or DF. Their evaluations show an important improvement in memory usage in every time when the number of registered services grows from 10000 to 100000, comparing to JADE’s memory usage. In the other hand, the request response time of one request in JADE’s yellow page (DF) is better than their proposed DF when the searching service is by name only. But, when multiple searching parameters are involved, the proposed approach shows a small improvement in request response time at a high number of registered services. In our study, we are not interested in the memory usage but in reducing the overload and enhancing the performance when the number of search requests is high.

In [29, 30], the authors focused on the same performance and scalability issue of the yellow pages service when search requests number is high. Several solutions were proposed where the best one was the integration of a shared and distributed memory with the yellow pages service of JADE. In this solution, each agent container has its own yellow pages agent (DF) which: (a) receives only requests from agents located in the same container, and (b) connects to a central replication server responsible for the registered services consistency. The results were very significant in terms of decreasing search’s response time and on increasing the number of agents in the system before it crashes due to a Java virtual machine (JVM) out of memory error. Their maintenance process requires a new package named Replication.distributeddf to be imported into the MAS, along with some modifications in the original source code. The authors did not present how their solution was implemented (algorithms, memory type used, etc.), or where the source code can be found. Therefore, it was not possible for us to test and investigate the solution for comparing it with our approach. They validated their approach on an IBM Think Pad T43 machine with a 1.8 GHz (single core) processor and 512 MB of RAM. This configuration is very low and prohibited them to run the system with a larger number of agents where they reached only 70 agents. Therefore, we cannot say that the solution is suitable for large scale applications unless more tests with much higher number of agents have to be done.

The authors have replaced the original yellow page methods (register, deregister, modify and search) with new methods but with different arguments and return types (String), for example static void Register (String name, String service) and static String Search (String service), instead of the original JADE’s methods arguments like AID, DFAgentDescription, SearchContsraints, etc. Therefore, the methods have to be changed in the original source code. Another disadvantage of their proposal is when all or a large number of agents are located in the same container, and because the search requests can be only sent to the local yellow page, it takes us back to the initial overload problem where one central yellow page is responsible for all the requests. Another disadvantage is that their yellow page agents are not fault tolerant which means that in case they crash, they must restart again and restore the services previously registered; exactly like how the JADE’s default DF does, otherwise the agents of that container cannot start an interaction process any more. Also, this approach has an interoperability problem, where extern agents can’t interact with their proposed DF, but only with the JADE’s DF, which in this case has no registered services. Another weakness is that their proposal has no support for search constraints which is very useful for more search precision. The authors planned to enhance their proposal by incorporating the shared distributed memory principle within the original JADE’s DF. Therefore, we believe that the overload will still be improved than the original JADE’s DF due to the distributed and the duplicated yellow pages. But, the search response time will be slower than their first proposal, because the searching procedure in JADE’s DF is more complex and requires several actions and concepts like ACL (agent communication language) processing, matching: AID, services, ontologies, protocols, etc.; where the services are stored in a database which is slower in reading and writing operations than using a simple memory (arrays, lists, etc.).

In our approach, the yellow pages are copies of the original JADE’s yellow pages; they can be located in any container and receive requests from any agent. These requests are distributed over all the yellow pages evenly. These enhancements are managed by one aspect that makes it very easy to apply them in the MAS.

3. Preliminaries

In this section, some basic concepts and tools related to the proposed approach, namely, the yellow pages (matchmaking) service [20], JADE [31] and AspectJ [32] are introduced.

3.1 The yellow pages service

In MAS, the yellow pages service is also known as matchmaking or directory service. As defined in [20], it consists of a cooperative partnership between information providers and consumers, with an intermediate called the matchmaker or the directory facilitator. The providers advertise their services to a matchmaker and the consumers search for some services by sending requests to the matchmaker which identifies any registered information that is relevant to the search requests and send the results to the requester.

3.2 JADE platform

JADE (Java Agent DEvelopment Framework) [31] is a software framework fully implemented in Java. It simplifies the implementation of MAS through a middleware that complies with the FIPA specifications and through a set of graphical tools that support the debugging and deployment phases. The agent platform can be distributed across machines (which not even need to share the same operating system) and the configuration can be controlled via a remote GUI. JADE currently is one of the most widely used platforms for research purpose. It has three main modules:

1.
The DF (Directory Facilitator) provides yellow pages services to other agents. Agents may register their services with the DF or query the DF to find out what services are offered by other agents, including the discovery of agents and services they offer in ad hoc networks.
2.
The AMS (Agent Management System) controls access and use of the agent platform and provides services like maintaining a directory of agent names. It provides white page services to other agents. Each agent must be registered with an AMS.
3.
The ACC (Agent Communication Channel) manages the communication between the agents.

3.3 AspectJ

AspectJ [32] is a seamless aspect-oriented extension to Java. It enables a different way to further and cleaner modularize all crosscutting concerns in a complex system compared to the object-oriented paradigm. AspectJ adds to Java several new constructs, including join points, point cuts, advice, intertype declarations, and aspects. An aspect is a modular unit of crosscutting implementation in AspectJ. Each aspect encapsulates functionality that may crosscut several classes in a program. Join Points are well-defined points in the execution of the program, such as, method call (a point where a method is called), method execution (a point where a method is invoked) and method reception join points (a point where a method received a call, but this method is not executed yet). Pointcuts are a means of referring to collections of join points and certain values at those join points. Advice is a method-like construct used to define additional behavior at join points. It consists of instructions that are executed before, after or around a join point. The around advice executes in place of the indicated join point, which allows the aspect to replace a method. An aspect can also use an intertype declaration to add a public or private method, field or interface implementation declaration into a class [33]. AspectJ has two types of weaving: a static weaving where it provides all the codes corresponding to the join points declared in a pointcut without execution, and a dynamic weaving where only the executed join points are intercepted at runtime. AspectJ Plugin is an aspect-oriented extension to the Java programming language. AJDT (AspectJ Development Tools) is the name of this AspectJ Plugin.

4. The proposed approach

Over the last decade, a considerable progress on MAS engineering techniques has been made in terms of methodologies and mature tools. However, maintenance of existing MAS code, which is an important research area, is not explored enough. The proposed approach provides a solution for enhancing the performance and scalability of yellow pages service in multi-agent applications. For clarity reasons, it is preferred to present the proposed approach through concrete examples of JADE platform. The proposed approach consists in three activities managed using aspect-oriented programming (Fig. 1) for the following reasons:

(i)
The simplicity of the implementation.
(ii)
The added functionalities are located in one file (aspect) and separated from the original code which remains intact (better separation of concerns).
(iii)
Requests (register, search, etc.) are intercepted and changed or forwarded during execution, which is easy to implement using aspect programming.
(iv)
The reusability of the solution and the maintenance effort is better, because it is only needed to insert the aspect to the system to be enhanced. So, no redevelopment or manual refactoring is required.
(v)
Updating the documentation of the system is easier.

Figure 1.
The proposed approach.

After the platform creation, the aspect creates a number of yellow page (DF) copies in the system. When agents send register, deregister or modify requests to the default DF, the aspect replicates the requests to all the DF copies to insure data consistency. In the other case of search request, the aspect intercepts and forwards it to the DF in turn (including the default DF).
4.1 Yellow pages replication

In JADE applications, agents are located in containers which have to be created before any agent. The container creation is the starting point of the replication process.

This activity is managed by the DFenhancer aspect which intercepts the container creation and creates DF copies in it (Fig. 2), using an agent class named DFCopy which extends the Jade.domain.df agent class. So, it can acquire the same DF behaviors like register, deregister, modify and search. An empirical research has to be made to find the optimum number of DF copies according to system status, but for now this number is set by the administrator.

The implementation of the DFCopy agent presented in Snippet 1 is very simple. Its class needs to extend the jade.domain.df class and execute the super.setup() method to acquire all behaviors of the default DF agent like register, deregister, modify and search.

Snippet 1: The DFcopy class
public class DFCopy extends jade.domain.df {
public void setup() {
/* Execute the setup of jade.domain.df which includes all the default behaviours of a df (i.e. register, deregister,modify and search).*/
super.setup();
/* Show the default Gui of a dfcopy Optional*/
this.showGui(); }

The DFenhancer.aj aspect will be presented now. It plays two roles, first as a replicator of DF agent and register, deregister and modify requests, secondly as a distributer of search requests. The code fragments responsible for DF replication are presented next.

Figure 2.

The yellow pages replication in JADE.

4.1.1 Initializations

When the application starts, it is required to have some variables as presented in Snippet 2: (a) the number of DF copies needed, which is a fixed value for now, (b) a list to save the agent IDs of the DF agents including the copies, and a counter for its size, so it can be used instead of calling for the list size method at every request, (c) a counter of intercepted search requests that will be used to define the DF in turn, and (d) a Boolean variable used to find the default DF AID that will be added to the DF agents list.

Snippet 2: The DFenhancer aspect and the used variables
/* Section to import required packages*/
public aspect DFenhancer {
int dfCopies_number $=$ 4; /* DF copies number in the system*/
LinkedList $<$ AID $>$ dfAgents_list $=$ new LinkedList $<$ AID $>$ ();/list of all DFAgents/
int listSize $=$ 0; /* Used to optimize code instead of calling dfAgents_list.size()*/
int search_count $=$ $-$ 1; /* Number of searchrequest*/
boolean defaultDF_Found $=$ false; /* To find the default df*/

4.1.2 Creating DF copies

In this paper, the goal is to improve the scalability and the performance of the yellow pages service in a local host with DF agents created on the main container only, to avoid any influence of the network that can affects the results. Therefore, distributing the DF copies or creating new ones in each container or in other hosts is possible, but it’s not our goal for now.

When the aspect intercepts the main container creation call, it completes its creation first. Then, it creates DF copies in it, as presented in Snippet 3.

Snippet 3: The pointcut and the advice used for creating DF copies
/* Intercept the creation of the main container*/
pointcut makeDFcopies (): call(*createMainContainer(..)); / We can add the simple containers here.*/
/* Start the DFcopies in the intercepted Container.*/
AgentContainer around():makeDFcopies () {
/* Allow container creation first*/
AgentContainer agentContainer $=$ proceed();
/* Create and start the DFcopies agents*/
AgentController dfCopy $=$ null;
try {
for (int i $=$ 0; i $<$ dfCopies_number; i $++)$ {
dfCopy $=$ agentContainer.createNewAgent(
"DFCopy" $+$ Integer.toString(i), "DFCopy", null);
dfCopy.start();
}
} catch (StaleProxyException ex) { }
/* Return the intercepted container*/
return agentContainer; }

4.1.3 Adding all DFs AID to a list

Once the DF copies are created, their AID information must be saved in a DF agents list. The getAID method cannot be accessed using method call like it is done with objects, because this will violate the principal of the privacy of agents attributes and behaviors. Therefore, as presented in Snippet 4, their execution is intercepted to access to their attributes. The last AID to be added to the list is the default DF.

Snippet 4: Saving the AIDs of the DF agents to a list
/* Intercept The created DFcopy previously to add their AID the the DFagents List*/
pointcut intercept_dfCopy(): execution(*DFCopy.setup(..));
Object around(): intercept_dfCopy() {
if(!dfAgents_list.contains(((Agent)thisJoinPoint.getThis()).getAID())) {
dfAgents_list.addFirst(((Agent)thisJoinPoint.getThis()).getAID());
listSize $++$ ;
} /* Get Default DF – executed only once*/
if (!defaultDF_Found) {
dfAgents_list.addLast(((Agent)thisJoinPoint.getThis()).getDefaultDF());
defaultDF_Found $=$ true;
listSize $++$ ;
}
return proceed(); }

4.2 Registering, deregistering and modifying services

When an agent sends a registering, deregistering or modifying request for its services to the DF agent

by invoking its proper method, the DFenhancer aspect intercepts this invocation and sends request copies to the DF copies created earlier. Then, it allows the original request to reach the DF (Fig. 3).

Figure 3.

Registering, deregistering and modifying services.

4.2.1 Registering services

As shown in Snippet 5 of the aspect code, the registration requests called by the DFService.register() method are intercepted by the intercept_Register() pointcut. In the around advice, the requests are replicated and forwarded to all the DF copies, then by calling proceed() the original request is passed to the default DF.

Snippet 5: Intercept and forward the register requests to all the DF agents
pointcut intercept_Register(): call(*DFService.register(..)) && !within(DFenhancer);
Object around(): intercept_Register() {
try {
for (int i $=$ 0; i $<$ listSize – 1; i $++)$ /* (listSize – 1) only the created DF copies */
/* We add this parameter dfAgents_list.get(i) to forward the request two all the DF copies we need the first and the last arguments (Agent,DFAgentDescription)*/
DFService.register( (Agent) thisJoinPoint.getArgs()[0], dfAgents_list.get(i), (DFAgentDescription)
thisJoinPoint.getArgs()[thisJoinPoint.getArgs().length – 1]);
} catch (FIPAException e) {}
/* Register in the Default DF too.*/
proceed();
return null; }

4.2.2 Deregistering services

In deregistration process presented in Snippet 6, the same idea like in the registration is used, only that the join point to intercept is the DFService.deregister method.

Snippet 6: Intercept and forward the deregister requests to all the DF agents
pointcut intercept_Deregister(): call(* DFService.deregister(..)) && !within(DFenhancer);
Object around(): intercept_Deregister() {
try {
for (int i $=$ 0; i $<$ listSize – 1; i $++)$ /* (listSize – 1) only the created DF copies */
/* We add this parameter Fagents.get(i) to forward the request two all the DFcopies*/
DFService.deregister((Agent)thisJoinPoint.getArgs()[0], dfAgents_list.get(i));
} catch (FIPAException e) {}
/* Deregister from the Default DF also.*/
proceed();
return null; }

4.2.3 Modifying services

Service modification presented in Snippet 7 also is similar to registration and deregistration, with the method DFService.modify as the pointcut which will be intercepted.

Snippet 7: Intercept and forward the modify requests to all the DF agents
pointcut intercept_Modify():call(* DFService.modify(..)) && !within(DFenhancer);
Object around(): intercept_Modify() {
try {
for (int i $=$ 0; i $<$ listSize – 1; i $++)$ /* (listSize – 1) only the created DF copies */
/* We add this parameter DFagents.get(i) to forward the request two all the DFcopies*/
DFService.modify((Agent)thisJoinPoint.getArgs()[0],dfAgents_list.get(i),(DFAgent
Description)
thisJoinPoint.getArgs()[thisJoinPoint.getArgs().length – 1]);
}
catch (FIPAException e) { }
/* Modify in the Default DF also.*/
proceed();
return null; }

4.3 Searching services

When the two previous activities are well achieved, the yellow pages service is ready to face a high number of searching requests, which will be passed to many DF agents instead of one using the DFenhancer aspect (Fig. 4).

Figure 4.

Searching for services by distributing requests on DF agents.

The DF copies and the default DF will take turns to respond to search requests. This load balancing process is managed by the DFenhancer aspect, which intercepts the search request and directs it to the DF in turn (Fig. 5).

Figure 5.

Distribution of requests by turn.

The aspect code, responsible for distributing requests, uses an around advice type, which is presented in Snippet 8. In JADE applications, developers must use the method DFService.search to search for services in the DF. If the search request is addressed to the default DF, there is no need to specify its AID in the method’s arguments. Otherwise, when the second argument is set to a specified DF other than the default DF, the administrator must not alter the request, unless he takes this case into account while implementing the DFenhancer aspect, so that the system runs properly.

The search request can be configured also with a search constraints argument. Therefore, in this case or the other, the same search request has to be directed.

Managing DF agents turns is implemented by a circular list which holds the AIDs of all the DFs in the system. To implement the circular list, a modulo function is used which returns the position (index) in the DF agents list of the DF responsible for the current intercepted request as presented in Eq. (1).

$=$ (1)

Snippet 8: Intercept and redirect the search request to the DF agent in turn
pointcut intercept_Search(): call(* DFService.search(..)) && !within(DFenhancer);
DFAgentDescription[] around(): intercept_Search() {
/* If the second argument is a DF Agent ID, the request will not be changed.*/
if(thisJoinPoint.getArgs()[1].getClass().getSimpleName().equals("AID") ) {
try {
/* To distribute the requests to the current DF on the list we increment the search_count then we divide it by listSize so that the reminder of the division is the position of DF in the list – (this emulate a circuler list, where the next element of the last one is the first element)*/
switch (thisJoinPoint.getArgs().length)
{ /* Depending on the search arguments, if there is a search constraints or NOT*/
case 2:return DFService.search((Agent) thisJoinPoint.getArgs()[0],dfAgents_list.get( $++$
search_count % listSize),(DFAgentDescription) thisJoinPoint.getArgs()[1]);
case 3:return DFService.search((Agent) thisJoinPoint.getArgs()[0],dfAgents_list.get( $++$
search_count % listSize),(DFAgentDescription) this JoinPoint.getArgs()[1],(SearchConstraints)
thisJoinPoint.getArgs()[2]);
default: break;
}
}
catch (FIPAException e) {}
return null; } }

5. Validation and discussion

The aspect-oriented programming paradigm used in the proposed approach has simplified its deployment by separating the concern of enhancing the performance and the scalability of the yellow pages service from the other original concerns of the multi-agent system.

Therefore, to use and validate the proposed approach, we don’t need to change any line of code in the application’s source code. Instead, only these elements have to be added to the application as follows (Fig. 6):

(i)
Add the DFCopy.java class and the DFenhancer.aj aspect to the default package in the source code.
(ii)
Add the AspectJ package to the BuildPath.

Figure 6.
Applying the proposed approach.

A search has been done for unified benchmarks used by the community in multi-agent systems that can be used to validate the proposed approach, but no results have been obtained except for the examples offered within the agent platforms. Therefore, three multi-agent systems have been proposed to validate the proposed approach, which are: (a) A simple example provided with the JADE platform named bookTrading [34]. It is about sellers (book selling agents) who register their services into the DF agent, and buyers (book buyer agents) who search in the DF agent for book selling services. (b) Translators, another simple JADE application that we developed which has 4 agents types. The first type is a requester agent for translating an English word, the other 3 agent types offer translation services each one specializes in a specific language. (c) im2008-jade [35], is a more complex application that we used in previous work [36]. It’s an information system for real-time sharing of resources whose availability is manifested with very short notice and with a very limited useful lifetime. For example, such resources can be linked to situations such as:

(i)
Resale of tickets (train, show, etc.) already purchased and no longer available to the first buyer.
(ii)
Availability of places on private transport.
(iii)
Short-term discounts on products for sale.

Two simple examples were selected for the evaluation to avoid interferences of other functionalities on the yellow page service.

The im2008-jade application is more complex and can demonstrate how the proposed approach will perform with other agent properties in the system, taking in consideration that many concerns can be faced during evaluation:

(i)
Other functionalities can take too much CPU resources that the DF needs to respond in time, this can degrade the performance of the yellow page service which means slower response time due to the CPU sharing, not due to the yellow page itself.
(ii)
If an agent behavior takes too much execution or waiting time before requesting a service, this can reduce the pressure on the DF agent, which will prevent any DF bottleneck from happening.
(iii)
An agent can perform cyclic behaviors which sends more than one search request per agent. Therefore, the evaluation is no longer related to the number of agents, but to the number of requests which is not unique for all the agents and with frequencies that can’t be controlled (agents are unpredictable and can send different number of requests).

To run the bookTrading application, the Jade.boot command line is supposed to be used to lunch the JADE platform and start the agents manually, which is not proper to validate our proposal. Therefore, the application was instrumented with a main class to start the evaluation programmatically and perform these tasks, exactly like in the Translators application:

(i)
Launching the JADE platform.
(ii)
Creating 100 (which is the default results number of one search offered by the DF) book seller agents and wait for all their services to be registered (in the Translators application there are three translators types, in each translator type 100 agents were created).
(iii)
Launching five iterations where in each one book buyer are created. These agents will be terminated after each iteration, starting with 2000 buyers at the first iteration. In the next iteration, the number of buyers is incremented with 2000 agents, until the last iteration where 10000 buyers is reached. Each new iteration starts with our demand, so the results of the previous one could be saved.

The im2008-jade application has its launcher class which starts the system. To maintain the original functioning of the application, the only modifications that have been applied are an augmentation of the requester agents number to 6000 agents while the number of registered services remains intact, and a removed waiting time of 30 seconds used to be set in the requester’s setup method.

The number of DF copies to be added into the system is fixed as a randomly choice to four agents beside the original DF agent.
5.1 Execution environment

The proposed approach was evaluated on different machines, desktop and laptop with different RAM and CPU capacities and under different operating systems (Linux 64 bits and Windows7 64 bits). In Table 1, the technical characteristics of these machines are presented.

Table 1
The used machines for the yellow pages service evaluation

	Desktop Linux	HP Windows	Acer Windows	HP Linux	Acer Linux
Model	Desktop – GigaByte	HP dv6	Acer 5733	HP dv6	Acer 5733
	H55M-S2 motherboard
CPU	i3-530 2.93 Ghz	i5-2410M	i3-M380	i5-2410M	i3-M380
		2.30 GHz	2.53 GHz	2.30 GHz	2,53 GHz
RAM	6 GB	8 GB	4 GB	8 GB	4 GB
Operating system	Linux (Ubunto 14)	Windows 7	Windows 7	Linux (Ubunto 14)	Linux (Ubunto 14)

All the computers systems have the same used software versions, which are:

(i)

Eclipse Luna (4.4.1) with JDK8 Update 91

(ii)

JADE v4.1.1 (since v4.2, a DF search timeout was set to 30 seconds, last version now is v4.4)

(iii)

AspectJ (AJDT 2.2.4 for Eclipse 4.4)

5.2 Evaluation of the DF performance

In a heavy loaded multi-agent system, DF search requests frequency is very high which makes it difficult for the DF agent to answer in a proper time.

The performance of the JADE’s DF agent will be examined now under several search request frequencies using only two previously mentioned applications bookTrading and Translators.

The search request response time or RTT (round-trip delay time) is used as a performance evaluation criterion [29, 30, 37, 38]. To obtain the RTT of each search request made by the requester agent, these two code fragments were added (1 and 2) in the agent’s class where the search function has been called as presented in Snippet 9.

Snippet 9: Calculating the response time of a search request
long startTime $=$ System.nanoTime();/* System time before request in nanoseconds (1)*/
DFAgentDescription[] result $=$ DFService.search(myAgent ,template);
System.out.println((System.nanoTime() – startTime)/1000000 );/* RTT in mili-seconds (2)*/

The examples were instrumented with a simple main class responsible for starting the JADE platform and the required agents as mentioned before.

Starting with the bookTrading example presented in Snippet 10, where the book seller agents were created first to register their services in the DF (100 seller agents), then the book buyer agents were lunched starting from 2000 buyers in the first iteration to 10000 buyers in the last iteration by adding 2000 agents after each one. The agents of the previous iteration were terminated before starting the next one.

Snippet 10: Starting buyer agents in the bookTrading example
/* $\ldots\ldots$ Here is The code for starting the JADE platform and 100 seller agent
$\ldots\ldots$ */
int buyers_number $=$ 0;
int iterations $=$ 5;
for(int iter $=$ 0;iter $<$ iterations;iter $++)$
{
buyers_number $=$ buyers_number $+$ 2000;
for (int i $=$ 0;i $<$ buyers_number;i $++)$
{
buyer $=$ ac.createNewAgent("BookBuyer" $+$ Integer.toString(i),"examples.bookTrading. BookBuyerAgent",argss); /creating buyer agents/
buyer.start(); /starting buyer agents/
/* Delay time in mili seconds before starting a new buyer agent, we remove the code in the no delay case */
try { Thread.sleep(1); /* No delay, 1 ms, 2 ms, 5 ms, 6 ms and 7 ms were used */
catch (InterruptedException e) { }
} /* end for (i)*/
/* $\ldots$ code to obtain the results and terminate the agents*/
} /end for(iter)/

In the Translators application we used the same execution sequence, only that in this example 300 translation services have been registered (100 services for each one of the three translator agents), while in the im2008-jade the original execution was used which will be explained later with its evaluation results.

In each machine, the same evaluations were launched, where each one has a different search requests frequency, and because the performance and scalability observations were similar in all the used computers, only the investigation results lunched on the desktop linux machine using the bookTrading example will be presented.

The first evaluation was started with no delay and in full frequency of requests. In each evaluation, 2000 buyers were started as the first iteration to the 5 ${}^{\rm th}$ one with 10000 buyers and translation requester agents. The last evaluation with 7ms delay was the state where the yellow pages service starts to perform smoothly with no performance and scalability degradation.

In each iteration, the median (Table 2) and the mean (Table 3) of search response times (RTTs) using the bookTrading application are calculated (Translators has approximately similar results).

Table 2
The median of RTTs of JADE’s DF performance in the Desktop Linux machine according to requests frequency (bookTrading)

	The median of RTTs (ms)
Agents	No Delay	1 ms Delay	2 ms Delay	5 ms Delay	6 ms Delay	7 ms Delay
2000	9173	6092	6202	2374	1360	142
4000	15297	12686	11154	3237	958	10
6000	21674	19200	16845	4747	624	9
8000	30175	26793	23989	7155	863	9
10000	37797	34593	31645	8343	1028	9

Table 3

The mean of RTTs of JADE’s DF performance in the desktop Linux machine according to requests frequency (bookTrading)

	The mean of RTTs (ms)
Agents	No Delay	1 ms Delay	2 ms Delay	5 ms Delay	6 ms Delay	7 ms Delay
2000	8708	6046	5821	2433	1626	183
4000	14903	12343	10835	3407	959	17
6000	22060	19203	16500	5010	646	10
8000	30457	26564	23319	6939	899	10
10000	37956	34205	30476	8969	1078	10

In statistics [39], when the mean and the median values of certain data are close to each other, it is preferred to use the mean values, otherwise when data is skewed and there is a difference between them, the use of the median is more appropriate. Thus, in Fig. 7, only the median values of the RTTs are presented next.

The RTT necessary for the DF to return 100 services of only one search request varies about 10 to 25 ms (could be less or more).

Figure 7.

The performance of Jade’s DF in a Desktop Linux machine according to requests frequency (bookTrading).

Figure 7 shows six curves for the response time of service search requests sent to the DF agent. Each one depends on the requests frequency. We observe that at higher frequencies (less delay time between requests), the more performance degradation will result when the number of agents is augmented. But, when the delay time was set to 6 ms, the RTTs were nicely stable even if they were not optimal like in the 7 ms delay curve, which shows that The DF agents runs smoothly at high number of agents. We also notice that the RTT in the first iteration (2000 agents) of the 7 ms delay is a little larger than the others, where the first requests of the iteration 1 has higher RTTs than the rest of values in the same iteration.

Table 4

The JADE’s DF performance in the Desktop Linux machine according to requests frequency with No Delay (full frequency) (bookTrading)

Agents	Mean (ms)	Median (ms)	Min (ms)	Max (ms)
2000	8708	9173	57	15194
4000	14903	15297	17	28271
6000	22060	21674	16	43684
8000	30457	30175	13	60139
10000	37956	37797	9	74133

Basically, these high RTTs values were observed at the beginning of all the evaluations that have been made. But, they were hidden because the RTT keeps on increasing after every new search request inside every iteration. When the RTTs drop down and stabilized after that, we noticed that something is influencing the response time when the evaluation starts. Therefore, this observation needed a further investigation by performing a system profiling (using JProfiler [40]), which detected that an activity of the garbage collector was started with the system execution and takes a lot of CPU resource for a small period. Another explanation was provided by the founders of JADE in [41] which can be relevant, where they explained that the performance degradation at the beginning of system execution may depend on several factors such as: (a) ClassLoading: At the first round, the agent classes as well as the DB driver classes must be loaded but at next rounds they are already there, (b) DB connections: At the first round, all connections with the DB must be opened. But, at the next round (depending on how you access the DB) they may be already there, and (c) just-in-time compilation.

It is clear now that at 6 ms delay between search requests the RTTs are stable and can handle high number of requests even if they are not optimal, while under 6 ms delay. The JADE’s DF starts to lose scalability and as known that the search response time in the late versions of JADE starting from JADE 4.2 was limited to 30000ms (30 seconds). Therefore, in every iteration shown in Table 4 where the Max value exceed 30 seconds, the system returns a timeout error. This is the reason why the 4.1 version was used, so we can test the limits, as in this case the DF could pass only the 4000 agents (2nd iteration) if an earlier version of JADE was used.

Next, our approach will be applied on the mentioned applications to enhance the matchmaking service especially at high request frequency when it did fail with the JADE’s default DF.

5.3 Results and discussion

The first evaluation was with the bookTrading application with four extra DF copies and a search request frequency with no delay using five machines. The results are presented in Table 5 using only the median of RTT values, without missing to mention that in all the performed evaluations the number of requested services returned in every search response was the exact count of 100 services like with the JADE’s DF, which means a success rate [24] of 100%. The results in Table 5 have shown a great improvement in RTTs which means better performance and scalability of the yellow pages service than with the JADE’s DF especially in the Linux machines, the improvement percentage was stable at more than 99.5%.

Table 5
The performance of the proposed approach with four new DF copies in using the bookTrading application and according to requests frequencies with no delay

		Number of agents
		2000	4000	6000	8000	10000
HP Windows	JADE’s DF	7453	12903	19023	25620	32322
	Proposed approach	5580	7421	10731	14122	18019
	Improvement %	25.13%	42.49%	43.59%	44.88%	44.25%
Acer Windows	JADE’s DF	13824	18815	27339	38515	48980
	Proposed approach	9647	10764	15207	22550	28399
	Improvement %	30.22%	42.79%	44.38%	41.45%	42.02%
Desktop Linux	JADE’s DF	9173	15297	21674	30175	37797
	Proposed approach	52	35	55	50	60
	Improvement %	99.43%	99.77%	99.75%	99.83%	99.84%
HP Linux	JADE’s DF	7283	13629	20054	26796	33794
	Proposed approach	32	27	49	40	51
	Improvement %	99.56%	99.80%	99.76%	99.85%	99.85%
Acer Linux	JADE’s DF	10093	16490	26682	36447	47179
	Proposed approach	972	55	139	140	87
	Improvement %	90.37%	99.67%	99.48%	99.62%	99.82%

Table 6

The performance of the proposed approach with four new DF copies in using the bookTrading application and according to requests frequencies with 1 ms delay

		Number of agents
		2000	4000	6000	8000	10000
HP Windows	JADE’s DF	4005	9946	16251	22370	27672
	Proposed approach	9	10	10	10	15
	Improvement %	99.78%	99.90%	99.94%	99.96%	99.95%
Acer Windows	JADE’s DF	3643	11874	22597	31559	42141
	Proposed approach	13	12	14	14	13
	Improvement %	99.64%	99.90%	99.94%	99.96%	99.97%
Desktop Linux	JADE’s DF	6046	12343	19203	26564	34205
	Proposed approach	14	12	12	12	12
	Improvement %	99.77%	99.90%	99.94%	99.95%	99.96%
HP Linux	JADE’s DF	5550	10926	17073	23410	31001
	Proposed approach	12	12	11	11	11
	Improvement %	99.78%	99.89%	99.94%	99.95%	99.96%
Acer Linux	JADE’s DF	8840	16065	25625	35247	46449
	Proposed approach	21	18	17	17	17
	Improvement %	99.76%	99.89%	99.93%	99.95%	99.96%

The improvement percentage was calculated in every iteration by Eq. (2).

$\displaystyle\textit{Improvement percentage}=\left[1-\left(\frac{\text{RTTs % Median of the proposed approach }}{\text{RTTs Median of the default DF }}\right)\right]\times 100$ (2)

In Windows machines, about 25% to 45% in performance improvement percentage was obtained, where it was maintained at about 42–44 % with more than 4000 running agents, which is different than the Linux machines results where it was stable at more than 99.5%.

Table 7

The performance of the proposed approach with four new DF copies in using the Translators application and according to requests frequencies with no delay

		Number of agents
		2000	4000	6000	8000	10000
HP Windows	JADE’s DF	9186	12212	17839	24161	30796
	Proposed approach	6229	6255	10169	12968	16749
	Improvement %	32.19%	48.78%	43.00%	46.33%	45.61%
Acer Windows	JADE’s DF	12426	17461	26945	35608	47041
	Proposed approach	9654	9629	14512	20285	26857
	Improvement %	22.31%	44.85%	46.14%	43.03%	42.91%
Desktop Linux	JADE’s DF	9246	13476	20411	28910	37425
	Proposed approach	33	46	41	49	50
	Improvement %	99.64%	99.66%	99.80%	99.83%	99.87%
HP Linux	JADE’s DF	7838	11458	18193	24892	31331
	Proposed approach	75	31	50	83	78
	Improvement %	99.04%	99.73%	99.73%	99.67%	99.75%
Acer Linux	JADE’s DF	8867	16625	25218	35598	45655
	Proposed approach	475	52	61	66	72
	Improvement %	94.64%	99.69%	99.76%	99.81%	99.84%

Figure 8.

The proposed approach evaluation on bookTrading with 1 ms delay.

Figure 9.

The proposed approach evaluation on bookTrading with no delay.

In Table 6, the results for the evaluation using bookTrading example according to requests frequencies with 1ms delay show a significant and stable improvement percentage of more than 99.5% even with the Windows machines with median of RTTs from 9 ms to 15 ms. While the RTTs were even more optimized with Linux systems than the previous no delay evaluation with median of RTTs of (11 ms and 12 ms).

So, it is only in the no delay evaluation using windows machines where the proposed approach did not result as expected theoretically and practically like in the Linux machines, which means that the operating systems has definitely an impact on the approach. Unfortunately, no other explanation is found yet, unless other investigations have to be performed.

For visual presentation of the results, Figs 9 and 9 present the evaluation of the proposed approach on the bookTrading example using 1 ms and no delay in requests frequency. For each used machine the scalability and the performance were secured, except for the Windows machines with the no delay evaluation where the system has been enhanced by up to 45%.

The maximum number of agents reached before (10000 agents) has been increased to 50000 agents in one last evaluation using the bookTrading example, which has showed a significant scalability and performance improvements just like with the 10000 agents.

The second evaluation was performed on the Translators application that we developed. It is a simple JADE application which require one type of agent to request some words translation from three possible agent types that offer translation services of three languages Dutch, French and Arabic (each agent type offers translation to only one specific language).

Differently from the bookTrading example, in this evaluation, the number of the registered services is 300 services (100 translator agent for each language) instead of 100 services.

The results of this evaluation are presented in Table 7 using five computers with no delay in requests frequency. The obtained RTTs were approximately similar to those of the bookTrading example, where the best improvements were in the Linux machines.

In Table 8, the results for the evaluation using Translators application according to requests frequencies with 1ms delay shows a significant and stable improvement percentage of more than 99% even with the Windows machines. While the RTTs were even more optimized with Linux systems than the previous no delay evaluation. Compared to the bookTrading evaluation on Windows machines with 1ms delay, the RTTs obtained in this evaluation on Windows machines are slightly slower but very stable.

Table 8

The performance of the proposed approach with four new DF copies in using the bookTrading application and according to requests frequencies with 1 ms delay

		Number of agents
		2000	4000	6000	8000	10000
HP Windows	JADE’s DF	3959	9202	14107	20400	26618
	Proposed approach	36	33	45	43	43
	Improvement %	99.09%	99.64%	99.68%	99.79%	99.84%
Acer Windows	JADE’s DF	2368	11890	20041	29781	37904
	Proposed approach	91	30	54	49	57
	Improvement %	96.16%	99.75%	99.73%	99.84%	99.85%
Desktop Linux	JADE’s DF	6532	11941	18579	25838	33517
	Proposed approach	14	13	13	13	13
	Improvement %	99.79%	99.89%	99.93%	99.95%	99.96%
HP Linux	JADE’s DF	6482	11201	17408	24139	31266
	Proposed approach	12	12	12	12	12
	Improvement %	99.81%	99.89%	99.93%	99.95%	99.96%
Acer Linux	JADE’s DF	9437	14760	23115	33031	43303
	Proposed approach	20	17	16	16	16
	Improvement %	99.79%	99.88%	99.93%	99.95%	99.96%

The last evaluation was performed differently from the two previous ones. A more complex JADE application named im2008-jade was used. The evaluation was performed on the five machines with only no delay in requests frequency and with 6000 requester agents. Noting that the number of returned services from the DFs was varied from 1, 3 to 5 services only, differently than before (100 services). The results are presented in Table 9 using the median of RTTs.

Table 9

The performance of the proposed approach with four new DF copies in using the im2008-jade application and according to 6000 requester agents with no delay in requests frequency

	JADE’s DF (mili-seconds)				Proposed approach (mili-seconds)				Improvement %
	Mean	Median	Min	Max	Mean	Median	Min	Max	(using medians)
HP Windows	11895	12078	15	13618	1.97	1.42	0.72	436.46	99.99%
Acer Windows	18374	18762	6	22081	3.30	2.28	0.79	244.95	99.99%
Desktop Linux	6826	7498	230	11120	3.33	2.71	0.84	499.97	99.96%
HP Linux	6433	8003	11	8732	2.61	2.11	0.70	168.34	99.97%
Acer Linux	9899	12104	10	15167	3.81	3.08	1.09	155.10	99.97%

Figure 10.

Performance comparison between JADE’s DF and the proposed approach using im2008-jade application with no delay and 6000 requester agents.

As expected, the improvements on the Linux machines where very promising like in the previous evaluations. Only that, in the Windows machines, the improvement percents were much higher than the previous evaluations on the same machines using no delay in requests frequency, where it reached now 99.99%.

Even that this application is more complex and larger in size, the results of the proposed approach were very significant than the two simple examples. This could mean that: (a) The DFs does not spend much time in searching services because only few have been registered (1 to 5 services), and yet, a bottleneck was detected in the JADE’s DF. So, the pressure of requests was nicely handled by the proposed approach. (b) Other application’s functionalities were influencing the evaluation. Therefore, for better performances evaluations where much pressure is needed for bottlenecks situations, simple applications are preferred.

The presented diagram in Fig. 10 shows that JADE’s DF suffers from weak performance in all the machines, where the proposed approach has successfully enhanced the yellow pages service performance.

5.3.1 Impact of the proposed approach on CPU and memory usage

To investigate the impact of the proposed approach on the CPU and the memory usage, a profiling process has been performed using JProfiler [40]. The presented results in Figs 11 and 12 were obtained from the Linux desktop machine and performed on the bookTrading example with 4000 buyer agents and 100 seller agents with no delay on requests frequency. A sampling technique with the default 5 ms interval was used as a configuration of the JProfiler.

Figure 11.

CPU load comparison with no delay in requests frequency.

Figure 12.

Memory usage comparison with no delay in requests frequency.

The selected buyers number (4000 agents) shows approximately the same CPU and memory usage variation when higher number has been used but with much more execution time, especially that the JProfiler has its own load on the CPU usage.

In Fig. 11, the CPU load diagram is presented where the buyer agents were started at the 11th second with an initial load of 4.5% on CPU usage.

The proposed approach’s curve shows an average increase of 20% of CPU usage than the JADE’s DF curve, while the overall execution time was decreased from 118 seconds with the JADE’s DF to 44 seconds with the proposed approach.

In fact, the high CPU usage can be seen as a negative point, even with that, a system that can’t exploit the full potentials of the machine or an added resources (better CPU ) when it is needed has a scalability issue.

In Fig. 12, the memory usage diagram is presented. The profiler has recorded a negligible increase of 0.54% in memory usage but much less memory occupation time, where the average of recorded memory sizes was from 253.45 MB with JADE’s DF to 254.83 MB with the proposed approach, during only the execution time of the proposed approach (44 seconds). But during all the execution time with JADE’s DF (118 seconds) an average size of 339.18 MB has been recorder.

6. Conclusion and future work

In a large scale MAS, the yellow pages service implemented in a centralized manner in which a single agent is responsible for all the requests will face a big performance degradation due to service overload. This propagates a time delay in the system and can lead to a breakdown situation. This problem didn’t get much attention from researchers despite its importance.

In the literature, the proposed solutions are either: (a) new designs for the yellow pages service and can’t be integrated easily in an agent system unless they are applied within the agent platform used for the system development, or (b) refactoring approaches for the agent system’s source code which aren’t fully developed and need more enhancements to be able to handle all possible situations of an agent system. Our approach offers a replication of the yellow pages with a distribution strategy of search requests using aspect-oriented programming. Therefore, no changes in the source code are required, it’s easy to implement and to reuse. The proposed approach was evaluated on three JADE applications (bookTrading, Translators, im2008-jade) using five different machines. The obtained results are very promising in terms of reducing the search’s response time and handling more requests especially on Linux operating system with an improvement of more than 99% and a success rate of 100% in all the evaluations where all the search responses have the exact number of requested services (100 services). A CPU and memory usage profiling process has been performed to evaluate the impact of the proposed solution on the system. About 20% increase was observed in the CPU usage but with much less execution time than the original JADE’s DF and a negligible increase on the memory usage using the proposed approach with much less memory occupation time than in the JADE’s DF evaluation.

Further studies will be done to enhance our proposal by:

(i)

Proposing a sensor to detect any degradation in the performance and scalability of the yellow pages service during runtime, for starting and stopping the DF enhancer automatically.

(ii)

Proposing an approach to identify automatically the optimum number of yellow pages replicates needed to enhance the service, which can be changed during runtime depending on the service performance.

(iii)

Reducing the memory space after replicating yellow pages, especially when the number of registered services is high, by dividing the services on the DF agents and connecting them together, so that the request get passed to another DF if no results were found by the previous one.

(iv)

Adapting the approach for external DF requests in multi-hosts systems.

(v)

Developing an eclipse plug-in that facilitates this maintenance process.

Footnotes

Authors’ Bios

Salim Zerrougui is a Phd student at the University of Mohamed Khider in Biskra, Algeria. He is a member of the research team “DISE” (distributed-intelligent systems engineering) at Oum el Bouaghi University in Algeria. He received his Master in Computer Science (artificial intelligence and image) in 2014 from Oum el Bouaghi University. His research is focused on software maintenance and evolution, aspect-mining and refactoring techniques for multi-agent systems.

Farid Mokhati is a professor of Computer Science at the Department of Mathematics and Computer Science of the University of Oum El-Bouaghi in Algeria. He holds a University accreditation (Habilitation Universitaire) in Computer Science (Distributed Artificial Intelligence) awarded by BADJI Mokhtar University (Annaba) in Algeria. Currently, he is the head of ReLa(CS) ${}^{2}$ Laboratory and the head of DISE (Distributed-Intelligent Systems Engineering) team. His main areas of interest include object and agent-oriented software engineering and formal methods.

Mourad Badri is a full professor at the Department of Mathematics and Computer Science of the University of Quebec, Trois-Rivières, Québec, Canada. He is also the director of the Software Engineering Research Laboratory. He holds a PhD in computer science (software engineering) from the National Institute of Applied Sciences in Lyon, France. His main areas of interest include object and aspect-oriented software engineering, software quality attributes, software quality assurance, software maintenance and evolution as well as aspect mining and refactoring.

Mohamed Chaouki Babahenini is a researcher and head of real-time rendering group at LESIA Laboratory. He is also a full professor at the Department of Computer science of the Biskra University in Algeria, where he received a Ph.D. in 2006. His current research interests are real-time rendering, 3D reconstruction, point-based rendering and data mining. He has co-authored many papers in these fields.

References

Zambonelli

Jennings

N.R.

and Wooldridge

, Developing Multiagent Systems: The Gaia Methodology, ACM Trans Softw Eng Methodol 12(3) (2003), 317–370.

DeLoach

S.A.

, Multiagent Systems Engineering: A Methodology and Language for Designing Agent Systems, June, 1999.

Kraetzschmar

G.K.

, Distributed Reason Maintenance for Multiagent Systems, Springer Science & Business Media, 1997.

Jarzabek

, Effective Software Maintenance and Evolution: A Reuse-Based Approach, Boston, MA, USA: Auerbach Publications, 2007.

Alkhatib

, The Maintenance Problem of Application Software: An Empirical Analysis, J. Softw. Maint. 4(2) (1992), 83–104.

Lientz

B.P.

and Swanson

E.B.

, Problems in Application Software Maintenance, Commun ACM 24(11) (Nov. 1981), 763–769.

Boehm

B.W.

and others, Software engineering economics, vol 197. Prentice-hall Englewood Cliffs (NJ), 1981.

Capretz

L.F.

and Capretz

M.A.M.

, Object-Oriented Software: Design and Maintenance, WORLD SCIENTIFIC, 1996.

Kamiya

Ohata

Kondou

Kusumoto

and Inoue

, Maintenance support tools for Java programs: CCFinder and JAAT, in: Proceedings of the 23rd International Conference on Software Engineering, ICSE 2001, May 19, 2001, 837–838.

10.

Reuss

and Althoff

K.-D.

, Maintenance of Distributed Case-Based Reasoning Systems in a Multi-Agent System, in: LWA, January 2014, 20–30.

11.

Hao

and Leung

, Maintaining cooperation in homogeneous multi-agent system, in: 2012 IEEE International Conference on Systems, Man, and Cybernetics (SMC), Seoul, South Korea, October 14–17, 2012, 301–306.

12.

Khosravifar

Gomrokchi

Bentahar

and Thiran

, Maintenance-based trust for multi-agent systems, in: Proceedings of The 8th International Conference on Autonomous Agents and Multiagent Systems-Volume 2, Budapest, Hungary, May 10–15, 2009, 1017–1024.

13.

Lee

L.C.

Nwana

H.S.

Ndumu

D.T.

and De Wilde

, The stability, scalability and performance of multi-agent systems, BT Technol. J. 16(3) (1998), 94–103.

14.

Rens

and Moodley

, A hybrid POMDP-BDI agent architecture with online stochastic planning and plan caching, Cogn. Syst. Res. 43 (2017), 1–20.

15.

Yao

and Logan

, Action-level intention selection for BDI agents, in: Proceedings of the 2016 International Conference on Autonomous Agents & Multiagent Systems, Singapore, May 9–13, 2016, 1227–1236.

16.

Faccin

and Nunes

, Bdi-agent plan selection based on prediction of plan outcomes, in: 2015 IEEE/WIC/ACM International Conference on Web Intelligence and Intelligent Agent Technology (WI-IAT), Singapore, December 6–9, 2015, 166–173.

17.

Wang

Zhang

Peng

and Chen

, Memory Mechanism Enhances Cooperation in Mobile Multi-agent System, in: 2016 8th International Conference on Intelligent Human-Machine Systems and Cybernetics (IHMSC), Hangzhou, China, August 27–28, 2016, 476–479.

18.

Kadera

and Novák

, Performance Modeling Extension of Directory Facilitator for Enhancing Communication in FIPA-Compliant Multiagent Systems, IEEE Trans. Ind. Inform. 13(2) (2017), 688–695.

19.

Dam

H.K.

Zhang

and Ghose

, Improving the reactivity of BDI agent programs, in: International Conference on Principles and Practice of Multi-Agent Systems, Dunedin, New Zealand, December 1–6, 2013, 85–100.

20.

Kuokka

and Harada

, Matchmaking for Information Agents, International Joint Conference on Artificial Intelligence (IJCAI), Montreal, Quebec, Canada, August 20–25, 1995.

21.

Páscoa

Pereira

Ferreira

and Lohse

, Redundant and decentralised directory facilitator for resilient plug and produce cyber physical production systems, in Service Orientation in Holonic and Multi-Agent Manufacturing, Springer, Cham, 2017, 71–79.

22.

Del Val

Rebollo

and Botti

, Enhancing decentralized service discovery in open service-oriented multi-agent systems, Auton. Agents Multi-Agent Syst. 2014, pp. 1–30.

23.

Kiczales

et al., Aspect-oriented programming, ECOOP97 – Object-Oriented Program, 1997, pp. 220–242.

24.

Cao

Kerbyson

D.J.

and Nudd

G.R.

, High performance service discovery in large-scale multi-agent and mobile-agent systems, Int. J. Softw. Eng. Knowl. Eng. 11(5) (2001), 621–641.

25.

Han

Youn

H.Y.

and Song

, Efficient category-based service discovery on multi-agent platform, Inf. Syst. Front. 14(3) (2012), 601–616.

26.

Kim

Son

Han

and Youn

, Agent platform-based directory facilitator for efficient service discovery, in: International Conference on Cyber-Enabled Distributed Computing and Knowledge Discovery, 2009. CyberC’09, Zhangijajie, China, October 10–11, 2009, 101–107.

27.

Kim

H.-J.

Lee

K.M.

Choi

K.-H.

and Shin

D.-R.

, Service discovery using FIPA-compliant AP to support scalability in ubiquitous environments, in: Fourth Annual ACIS International Conference on Computer and Information Science (ICIS’05), Jeju Island, South Korea, South Korea, July 14, 2005, 647–652.

28.

Kim

D.U.

Lee

G.H.

Lee

K.M.

Heo

S.P.

Choi

K.H.

and Shin

D.R.

, Design and Implementation of Advanced Directory Facilitator for Efficient Searching, in: The 9th International Conference on Advanced Communication Technology, February 2007, 403–406.

29.

Shahid

and Hassan

, Directory scalability in multi-agent based systems, Master thesis in software engineering, N

{}^{\circ}

MSE-2008-22, School of Engineering Blekinge Institute of Technoloy, Sweden, 2008.

30.

Mengistu

Tröger

Lundberg

and Davidsson

, Scalability in distributed multi-agent based simulations: The jade case, in: Second International Conference on Future Generation Communication and Networking Symposia, 2008 FGCNS’08, Sanya, China, December 13–15, 2008, 93–99.

31.

Bellifemine

Poggi

and Rimassa

, Developing Multi-agent Systems with JADE, in: Intelligent Agents VII Agent Theories Architectures and Languages Castelfranchi

and Lespérance

, Eds, Springer Berlin Heidelberg, July 7–9, 2000, 89–103.

32.

Kiczales

Hilsdale

Hugunin

Kersten

Palm

and Griswold

W.G.

, An Overview of AspectJ, in: Proceedings of the 15th European Conference on Object-Oriented Programming, London, UK, UK, June 18–22, 2001, 327–353.

33.

Xie

Zhao

Marinov

and Notkin

, Detecting Redundant Unit Tests for AspectJ Programs, in: 2006 17th International Symposium on Software Reliability Engineering, November 2006, 179–190.

34.

Book Trading

|

Jade Site.

35.

The im2008-jade Open Source Project on Open Hub.[Online]. Available: https://openhub.net/p/im2008-jade [Accessed: 11-May-2017].

36.

Zerrougui

Mokhati

and Badri

, Toward a new aspect-mining approach for multi-agent systems, J. Syst. Softw. 98 (2014), 9–24.

37.

Nguyen

P.T.

Schau

and Rossak

, Performance Comparison of some Message Transport Protocol Implementations for Agent Community Communication., in: IICS, 2011, 193–204.

38.

Cortese

Quarta

Vitaglione

and Vrba

, Scalability and performance of jade message transport system, in: AAMAS Workshop on Agentcities, Bologna, June 2002, 28.

39.

Mean, Mode and Median – Measures of Central Tendency - When to use with Different Types of Variable and Skewed Distributions

|

Laerd Statistics. [Online]. Available: https://statistics.laerd.com/statistical-guides/measures-central-tendency-mean-mode-median.php [Accessed: 28-Jun-2016].

40.

Java Profiler – JProfiler. [Online]. Available: https://www.ej-technologies.com/products/jprofiler/overview.html [Accessed: 26-Jun-2016].

41.

R: [jade-develop] performance measurement for mobile agent and rmi. [Online]. Available: http://jade.tilab.com/pipermail/jade-develop/2011q2/017085.html [Accessed: 26-Jun-2016].