The Mobility Aspect Pattern - CiteSeerX

The Mobility Aspect Pattern Alessandro Garcia, Uirá Kulesza, Cláudio Sant’Anna, Carlos Lucena Software Engineering Laboratory – SoC+Agents Group Pontifical Catholic University of Rio de Janeiro - PUC-Rio - Brazil {afgarcia,uira,claudios,lucena}@inf.puc-rio.br

Abstract. Software engineers of multi-agent systems (MASs) are faced with the design and implementation of the mobility concern in addition to the agents’ basic functionalities and other agent-related concerns. As the agents’ complexity increases, the mobility concern cannot be modularized based only on object-oriented abstractions. The mobility concern tends to spread across several system classes and methods, which in turn leads to the production of MASs that are difficult to maintain and reuse. MAS developers, however, have mostly relied on object-oriented design techniques and on object-oriented programming languages, such as Java. This paper presents the Mobility Aspect pattern, which documents an aspect-oriented solution for the modularization of the mobility concern. The use of this pattern minimizes code replication as well as increase the reusability and maintainability of the mobility concern and other agent concerns.

1. Intent The Mobility Aspect Pattern decouples the mobility concern from the agent’s basic functionality and other agent concerns.

2. Context Recently, cooperative distributed applications based on mobile agents have increased in importance. The internal architecture of a mobile agent includes the basic agent functionality, such as the agent services that are made available to the clients, and a number of additional concerns, such as mobility and collaboration. As a consequence, software engineers of mobile agents must deal with several additional concerns on top of the basic concerns of each software agent. Many facets of the mobility concern should be considered [1, 2, 3], including the following issues: the specification of the mobile agent elements, the description of the circumstances in which the agent needs to move, the departure to remote environments, the return to the home environment, and the control of the agent itinerary. These facets of the mobility concern should be seamless to the agents’ basic functionalities and other agent concerns. In this context, separation of Copyright  2004, Alessandro Garcia, Uirá Kulesza, Cláudio Sant’Anna, Carlos Lucena. Permission is granted to copy for the SugarLoafPlop 2004 Conference. All the other rights reserved.

concerns is at the core of the development of mobile agents. The reuse and maintenance of multi-agent systems depend largely on the ability of software engineering abstractions to support the explicit separation of the mobility concern and other agent concerns.

2. Example This section introduces a conference management system, a classical example of application based on mobile agents [13, 14]. EC is an open multi-agent system that supports the management of paper submission and reviews for conferences. This system is from herein referred to as Expert Committee (EC). The EC system encompasses two agent types: information agents and user agents. Each agent type provides different services. For simplicity purposes, this section focuses on the description of the user agents. The basic functionality of the user agents is to infer and keep information about the corresponding users related to their research interests and their participation in conferences. In addition to their basic functionality, user agents can collaborate with each other; the collaboration concern is represented by the roles played by the agents. Each role represents collaborative activities in specific contexts. Different roles are attributed to each EC agent, but the main ones are: (i) paper author, (ii) reviewer, (iii) PC member, and (iv) chair. Since these roles need to communicate with each other in the reviewing process, user agents play them in order to cooperate with each other. Classes are used to represent the basic functionalities of the agent types and the different roles. Each role is associated with a set of plans which are used to implement more sophisticated collaborative activities; plans are represented by separate classes. The chair role has plans for distributing review proposals; the reviewer role and the PC member role have plans for evaluating the chair proposals. The chair, PC members and reviewers negotiate with each other for performing reviews. There are other plans to address user workloads and invitations to new reviewers. Figure 1 presents some classes representing agent types (basic functionality), roles, and plans in the EC system. User agents and information agents need to move in some circumstances, including when they are playing a specific role. For example, when a user agent is playing the chair role, it needs to consult the reviewer profiles in order to optimize the paper distribution in terms of the research interests of each reviewer. If a reviewer profile is not available, it collaborates with an information agent and requests this agent to search for information of the speci?ed reviewer. The information agent controls the local database and is able to query for the profile. However, if the information is not available in the database, the chair role needs to move and try to find the missing profile in remote environments. The agent assigns the searching task to the information agents dispersed over the Internet by roaming through hosts. Figure 1 presents the objectoriented design of the mobile agents and their roles using the JADE mobility framework. There are several object-oriented frameworks to support the implementation of the mobility concern, such as Aglets [5, 6] and JADE [7]. Ubayashi and Tamai [2] present distinct object-oriented approaches for separating the mobility concern from the agent functionality and other agent concerns, such as collaboration. They present the system of design patterns from Aridor and Lange [6, 15] as one of the best object-oriented

solutions. These design patterns have been implemented in the Aglets framework. In this approach, the Itinerary pattern holds the information for roaming, which is encapsulated in an instance of the Itinerary class. To make an agent type or a role mobile, the agent type class or the role class is de?ned as a subclass of the Aglet class. Agent

Information Agent

User Agent user move() beforeMove() afterMove() returnHome() …

database move() beforeMove() afterMove() returnHome() …

Collaboration

getName() move() beforeMove() afterMove() ..

Reviewer papersToReview chairName biddingDeadline move() beforeMove() afterMove() returnHome() …

Chair papers submissionDeadline getPapers() getDeadline() move() beforeMove() afterMove() returnHome() …

SearchingPlan executePlan() executeQuery() searchProfile() …

Additional Reviewer

Basic Functionality

reviewer …

Legend: JADE class

Figure 1. An object-oriented design for the EC agents and roles

However, Ubayashi and Tamai [2] argue that this solution has some limitations to provide the isolation of the mobility concern. Although part of the mobility concern (code for roaming around hosts) is separated from collaborative activities (roles), it is mixed with agent classes and methods that implement the agent’s basic functionality. If an agent must have multiple roles or mobility actions, the code of this agent will be more complex [2]. Since all mobile agents need to extend the Aglet class, the agent type class has an explicit reference to the Aglet class. It has also an explicit reference to an instance of the Itinerary class. The implementation of the agent’s basic services is intermingled with explicit calls to the method roam(). These problems are not specific to the Aridor and Lange’s patterns. Mobility frameworks usually impose on agent classes the implementation of mobility-specific interfaces, the extension of mobility-specific classes, the extension of abstract methods on these mobility classes, and the invocation of mobility-specific methods in the basic agent methods. Figure 2 illustrates these problems in the design and implementation of EC user agents, which are based on the JADE framework [7]. Agent types and roles need to extend the Agent class provided by the framework. Note that the mobility code is intermingled with several methods and classes of roles, agent types, and plans. As a result, the design and implementation of the mobility concern crosscut the agents’ basic functionality (agent types) and agents’ collaborative activities (roles). Moreover, additional reviewers (Figure 2) have to inherit the mobility behavior even when no mobility action will be performed in the context of this role. Supposing some instances of additional reviewers will be mobile and other instances will be static, an inheritance

level needs to be added to the system in order to separate the static and mobile additional reviewer in different classes. In addition, all the agent classes need to be serializable in Java environments, i.e. the agent classes need to implement the interface Serializable due to mobility purposes. Mobility Agent getName() move() beforeMove() afterMove() ..

Collaboration User Agent user move() beforeMove() afterMove() returnHome() …

Information Agent database move() beforeMove() afterMove() returnHome() …

Reviewer papersToReview chairName biddingDeadline move() beforeMove() afterMove() returnHome() …

Chair papers submissionDeadline getPapers() getDeadline() move() beforeMove() afterMove() returnHome() …

SearchingPlan executePlan() executeQuery() searchProfile() …

Basic Functionality Additional Reviewer Legend: – mobility-specific members – methods with some mobility code JADE class

reviewer …

public Result searchProfile(...) { ... chair.move(); ... chair.returnHome(); ... }

Figure 2. Mobility concern: crosscutting roles, plans and agent types

3. Problem The fact that agents and its roles change their locations should not affect their basic functionality. However, the use of object-oriented abstractions does not provide support for the separation of the mobility concern and other agent concerns, such as the basic agent functionality and the agent’s collaborative activities. The design and implementation of the mobility concern tend to affect or crosscut many classes. As a consequence, it is difficult to understand the agents’ basic functionalities, collaborations among agents, and mobility strategies of individual agents as a whole, which in turn decreases the system reusability and maintainability. How do agents incorporate the mobility property without having their basic functionalities intertwined with the mobility concern? The following forces are associated with this problem: • The design should support the uniform introduction of the mobility property to both roles and agent types. • It should be easy to (un)plug the mobility property in the multi-agent system. • When one role moves, its associated agent type also needs to be moved, since the role depends on the agent type classes.

• The agent design should be flexible to support the change of the mobility strategy in use. • The design solution should minimize replication of mobility code across different classes and methods of the multi-agent system.

4. Solution Use aspects to improve the separation between the mobility concern and the other agent concerns. Mobility aspects are used to modularize the mobility concern which crosscuts many classes and methods of a software agent. A Mobility aspect separates the mobility implementation from agent type classes, plan classes, and role classes. It implements not only the basic mobility behaviors, but also the specification of which agent types or roles are mobile, the declaration of the traveling circumstances, the calls to departure and return methods, and the control of its itinerary. Mobility aspects define how and when the agents will move to other environments. These aspects are able to crosscut some agent execution points – e.g. method invocations on Plan classes - and change their normal execution in order to check the need for transferring the agent to another host. The aspect itself invokes the methods responsible for implementing the mobility-specific actions, such as move() and returnHome(). No mobility code remains in the agent classes that implement the basic functionality and collaborative activities.

4. Structure Figure 3 illustrates the structure of the Mobility Aspect pattern. The aspect design is based on the ASideML modeling language [16, 17], which is used throughout this paper. This language extends UML with notations for representing aspects. The notations provide a detailed description of the aspect elements. In this design language, an aspect is represented by a diamond; it is composed of internal structure and crosscutting interfaces. The internal structure declares the internal attributes and methods. A crosscutting interface specifies when and how the aspect affects one or more classes [16, 17]. Each crosscutting interface is presented using the rectangle symbol with compartments (Figure 3). A crosscutting interface is composed of inter-type declarations, pointcuts and advices. The first part of a crosscutting interface represents inter-type declarations, and the second part represents pointcuts and their attached advices. The notation uses a dashed arrow to represent the crosscutting relationship, which relates one aspect to classes and/or aspects. The Mobility Aspect pattern has five participants: • -

Mobile Element represents a mobile agent element, which its main purpose is to modularize other agent concerns – it can be a role or an agent type.

• -

Mobility Aspect implements the generic part of the mobility concern.

• -

Specific Mobility Subaspect implements the part of the mobility concern that is specific to an agent type or role.

• -

Agent Class provides the context from where mobility-specific behaviors are triggered – this element has no mobility code.

• -

Mobility Framework is the used mobility framework and provides the systemic mobility services.

The structure of the Mobility Aspect pattern has some parts that are common to all potential instantiations of the pattern, and other parts that are specific to each instantiation. The common parts are: 1. The general mobility protocol: a. events are picked out b. conditions are checked, and c. the mobility-specific methods are invoked. 2. The generic mobility methods. 3. The itinerary object. The parts specific to each instantiation of the pattern are: 4. The specific events associated with a specific context (role or agent type) when the agent must be moved - which classes or aspects need to be observed. 5. The specific mobility methods.

Traveling

Mobility

is Mobile moving_() returning_()

* Plan

itinerary ... init() move() addHost() prepareToMove() ...

Mobility Framework move() returnHome() ...

executePlan() ... Role AgentType belief1 belief2 ... goals plans action1() action2() ...

Specific Mobility init() move() ... Legend: _beforeAdvice afterAdvice_ _aroundAdvice_

Figure 3. The static view of the Mobility Aspect pattern.

The purpose of the Mobility aspect is to decouple the mobility concern from the basic agent concerns and the collaboration concern. It modularizes the mobility property of agents and roles; all the mobility implementation is localized in the aspect source code. This aspect contains the pointcuts that describe the events which may lead the agent or the role to travel to a remote environment. The Mobility aspect also contains

the advices that are associated with these pointcuts. The advices are responsible for checking the need for the agent roaming and for calling the mobility actions. A Mobility aspect has two main parts: the aspect itself and one crosscutting interface. The aspect holds the data structures and methods which control the agent itinerary. The aspect also implements the methods for moving to a new environment and for returning to the original host. The crosscutting interface Traveling defines which agent types or roles are mobile. It also defines when these MAS elements should move. It defines the pointcuts in the agent classes or role aspects which should trigger the agent roaming. There are two kinds of pointcuts: (i) the first one is used to specify when the agent should move to another environment, and (ii) the second one is used to specify when the agent should go back to the home environment. The interface contains two advices associated with these pointcuts; they run after execution of actions on Agent subclasses, actions on Plan subclasses, or actions on role aspects. Depending on the mobility framework used in a specific MAS, the interface also describes the classes that are serializable or should implement specific framework interfaces (represented by is Mobile in Figure 3). As a consequence, the agent classes are not intermingled with mobility code, therefore improving their maintainability and reusability. The pointcuts are declared as abstract since they need to be redefined for specific agent types and roles.

Traveling

Mobility

is Mobile moving_() returning_()

itinerary ... init() move() addHost() prepareToMove() ...



Traveling

Chair Mobility

is Mobile

Chair papersToReview deadlines ... goals plans getPapers() ...

moving_() returning_()

init() move() ...

JADE Agent move() returnHome() ...

SearchingPlan executePlan() executeQuery() searchProfile() ...

Figure 4. The Mobility Aspect pattern for the chair role.

Each mobility aspect in the EC system crosscuts about 7 classes. Figure 4 illustrates the pattern instantiation for the chair role in this system. It shows the ChairMobility aspect crosscutting two elements: the Chair class and the SearchingPlan class. The ChairMobility aspect crosscuts this plan class because

when the searchProfile() method returns null, the agent needs to move. The moving pointcut defines the executions of the searchProfile() method as the join points of interest to the ChairMobility aspect. It also crosscuts the Chair class because the agent needs to roam depending on the results of some internal role actions, such as the getPapers() method.

5. Dynamics Two scenarios are described below in order to illustrate the dynamic behavior of the Mobility Aspect pattern. The scenarios show how the mobility aspects move agents and roles in a transparent way. Scenario I – Moving an Agent Role whenever its Plan Fails to Find an Information, which is illustrated by Figure 5, presents the pattern behavior when the mobility aspect detects the need for moving the agent to a remote environment: • • • • • • •

The chair’s searching plan is called. The ChairMobility aspect detects the execution of the searchProfile() method on the SearchingPlan class (pointcut moving). This aspect gathers the information needed from the plan context, i.e. the return value of the searchProfile() method. The execution of the checkResult() method on the ChairMobility aspect detects the need for moving the agent playing the chair role. The aspect invokes the prepareToMove() method to execute the last actions before the agent roaming. The ChairMobility aspect invokes the method to move physically the agent to the remote environment. The method of the mobility framework (JADEAgent) implements the agent motion. :Chair

:SearchingPlan

:ChairMobility

:JADE Agent

new()

searchProfile() moving_(Hashtable) checkResult() prepareToMove()

Legend: join point

move()

jadeAgent.move()

Figure 5. Moving when a plan fails to find required information

Scenario II – Moving an Agent Role whenever its Internal Action Fails to Find an Information, which is illustrated by Figure 6, presents the behavior of the ChairMobility aspect when it detects the need for moving the agent role to a new environment:

• • • • • •

The getPapers() method is requested. The ChairMobility aspect detects the execution of the method getPapers() on the Chair aspect (pointcut moving). This aspect gathers the information needed from the role context, i.e. the return value of the getPapers() method. The ChairMobility aspect detects the need for moving the agent playing the chair role. The aspect invokes the prepareToMove() method to execute the last actions before the agent roaming. The aspect invokes the method to move physically the agent to the remote environment. :Chair

:ChairMobility

:JADE Agent

getPapers() moving_(Hashtable) checkResult() prepareToMove()

move()

jadeAgent.move()

Legend: join point

Figure 6. Moving when a role action fails to find required information.

The scenarios presented above only involve roles. However, the dynamics of the pattern is similar to the case when an event associated with an agent type triggers the agent traveling.

6. Consequences The pattern solution provides the following benefits: • Improved Separation of Concerns. The mobility concern is totally modularized in the aspects. The basic agent classes implement no mobility behavior and do not need to be changed as changes in the mobility strategy is required. The code of role classes and plan classes are also not mixed with mobility code. • Flexibility. The mobility strategies explored in a MAS application may vary as the system evolves. The design is more flexible to support the change of the used mobility strategy. • Transparency. The mobility property can be added to or removed transparently from static agents since their code do not need to be changed. • Better Support for Maintenance. There are two other issues in the mobility protocol which usually changes: (i) the execution points on roles and agents, which trigger agent roaming, and (ii) the events which trigger the agent returning home. Since the definition of these points and events are localized in a single module, the Mobility aspects, the agent maintainability is improved.

•

Absence of Code Replication: Note that the use of the Mobility Aspect pattern results in fewer lines of code since the agent type classes and role classes do not need implement the mobility abstract methods of mobility frameworks.

Although the mobility concern is completely defined apart from other agent concerns, the use of the pattern imposes some problems to the MAS designer: •

Required Refactoring. In some circumstances, the realization of the Mobility Aspect pattern requires restructuring of the base code associated with other agent components in order to expose suitable join points. In this way, capturing the mobility concern as aspects sometimes requires restructuring of the classes and methods to expose suitable join points. For instance, we have extracted code from existing methods of a plan class into a new method to expose a methodlevel join point so that the mobility aspect can intercept it. In these cases, the aspect obliviousness [18] is not complete. Intimacy is defined as the additional effort required to prepare the classes and methods for the incorporation of aspects into the system [18]. Tools to help in the refactoring would make it easier to introduce aspects into an existing system.

•

Description of Mobility Aspects Depends on Speci?c Core Classes. The names of agent classes and role aspects appear in the de?nition of the mobility aspects. Therefore, the description of a mobility aspect cannot be directly applied to other core classes [2].

7. Variants Reflective Mobility. This variant is similar to the aspect-oriented solution presented here. The difference relies on the use of meta-objects as alternative to aspects. However, this approach requires a meta-object protocol [19] which usually introduces changes to the virtual machine. In addition, reflective solutions do not provide support for composing the mobility meta-objects with other concerns. As the agents’ complexity increases, good composition mechanisms are essential to the system reusability and maintainability.

8. Known Uses We have implemented the Mobility Aspect pattern both in the Portalware system [10, 11] and in the EC system. The Epsilon/J framework, which supports the RoleEP approach [2], has implemented the reflective variant. The RoleEP approach supports only role mobility and not agent mobility, and the agent programmers have to extend several Epsilon/J interfaces and abstract classes. In RoleEP, the use of bindingoperation [2] eliminates the necessity of AOP style weaving. Inter-type declarations in AspectJ can be replaced by adding role methods through binding-operation. However, advises weaving does not correspond to any model constructs in RoleEP. This is a weak point of RoleEP, and reduces the ability to prevent code duplication. From the viewpoint of static evolution, advises weaving is very useful because it prevents code duplication.

9. Related Patterns The Mobility Aspect pattern is alternatively related to the Role Object pattern [20] when this pattern solution is used for structuring the agent roles. The Mobility Aspect pattern can be combined with the Itinerary pattern [15] in order to register the actions and plans executed in each visited host. It can be also used in connection with patterns for specific mobility strategies, such as Forwarding and Ticket [15]. The Mobility Aspect pattern is potentially used in conjunction with a number of existing patterns for specific remote collaboration or coordination. Some classical examples are: Meeting, Locker, Messenger, Facilitator, and Organized Group [15]. The Reflective Blackboard pattern, which we have presented in another work [21], supports mobility based on distributed tuplespaces. Yoshioka et al. [22] propose a system of patterns to implement security policies for mobile agents that can be combined with the Mobility Aspect pattern. The Mobility Aspect pattern can be connected to several classical patterns, such as: (i) the Factory Method pattern [23] – allows virtual and actual migration handlers to be instantiated as needed at runtime, (ii) the Active Object pattern – addresses access to shared resources [24], (iii) the Visitor pattern – used for remote configuration [23], and (iv) the Proxy pattern – employed for issues of virtual migration [23]. Finally, the AspectJ [26] implementation of the Mobility Aspect pattern requires the use of advanced idioms, like Pointcut Method, Container Introduction and Abstract Pointcut [25].

10. Implementation We describe below pieces of code that are relevant to understand how to implement the Mobility Aspect pattern using the AspectJ language [26] and the JADE framework [7]. Step 1: How to define a Mobility aspect?

Ê The Mobility aspect is declared as abstract (line 1) since it needs to be redefined in different contexts, i.e. different agent types and roles. Several abstract pointcuts and methods are declared in Mobility aspect to be implemented by its subaspects, such as: • moving() pointcut (line 39) – used to define join-points in the agent execution, where it could be moved to another environment; • returning() pointcut (line 50) – used to define the specific join-point that identifies that an agent has moved; • init() method (line 19) – used to initialize the agent mobility capabilities in a specific platform; • move() method (line 21) – used to define the actions to be executed to move an agent to another enviroment; • initializeAgentInNewEnviroment() method (lines 55-56) – used to define the initialization of the agent after move; • checkMobilityNeed() method (lines 58-59) – identifies the mobility need of the agent. The Mobility aspect uses the Container Introduction [25] AspectJ idiom in its implementation. This idiom is used in general to define the implementation of a specific type and which classes implement that type. We used the Container Introduction idiom

to define the implementation of the MobileElement interface and to define which agent types and agent roles implement this interface. The Mobility aspect is responsible to define attributes and behavior to be introduced in the MobileElement interface by using AspectJ inter-type declarations. Mobility subaspects (step 2) define which agent types and agent roles implement the MobileElement interface. The Mobility aspect introduces several attributes and methods in the classes that implement the MobileElement interface, such as: • home attribute (line 5) – stores the home location of the agent; • location attribute (line 6) – stores the current location of the agent; • mobilityComponent attribute (line 8) – provides services to agent move to another environment using a specific mobility framework. In the EC system, a mobility component was implemented using the JADE framework. It is detailed below; • agentOut boolean attribute (line 10) – used to indicate the agent has moved to another enviroment; • prepareMessageDepartureNotification() method (lines 23-25) – used to prepare a message that notifies the agent departure to another environment; • prepareMessageArrivalNotification() method (lines 26-28) – used to prepare a message that notifies the agent arrival to an environment; • “setters” and “getters” methods to the attributes listed above are also introduced. In the EC system, the JADE framework was used to provide mobility capabilties to their agents. We defined a mobility component (JADEAgent class) by subclassing jade.core.Agent class (line 8). In this manner, the mobility component can provide several mobility methods of the JADE platform (such as doMove(), beforeMove(), afterMove()). By using JADE, it was also necessary to force that kernel classes (such as Agent, Plan, and Goal) implement the Serializable interface in order to make it possible the object migration through the network (lines 2-3). The “declare parents” construction of AspectJ was used for this purpose. 1. public abstract aspect Mobility { 2. declare parents: 3. Agent || AbstractPlan || Goal || ... implements Serializable; 4. 5. private String MobileElement.home; 6. private String MobileElement.location; 7. 8. protected JADEAgent MobileElement.mobilityComponent; 9. 10. private boolean MobileElement.agentOut; 11. 12. protected abstract pointcut agentInstantiation(Agent agent); 13. 14. after(Agent agent) : agentInstantiation(agent) { 15. agent.setAgentOutFalse(); 16. init(agent); 17. } 18. 19. public abstract void init(Agent agent); 20. 21. public abstract void move(Agent agent); 22. 23. public Message MobileElement.prepareMessageDepartureNotification(){ 24. ...

25. } 26. public Message MobileElement.prepareMessageArrivalNotification() { 27. ... 28. } 29. public boolean MobileElement.isAgentOut() { 30. return this.agentOut; 31. } 32. public void MobileElement.setAgentOutTrue() { 33. this.agentOut = true; 34. } 35. public void MobileElement.setAgentOutFalse() { 36. this.agentOut = false; 37. } 38. ... 39. protected abstract pointcut moving(Plan plan); 40. 41. after(Plan plan) returning (Object result): moving(plan) { 42. Agent agent = plan.getAgent(); 43. boolean moveAgent = checkMobilityNeed(agent, result); 44. if (moveAgent && (!agent.isAgentOut())) { 45. agent.prepareDepartureNotification(); 46. move(agent); 47. } 48. } 49. 50. protected abstract pointcut returning(Plan plan); 51. 52. after(Plan plan) returning (Object result): returning(plan) { 53. ... 54. } 55. public abstract void initializeAgentInNewEnvironment( 56. Object mobileAgent); 57. 58. protected abstract boolean checkMobilityNeed(Agent agent, 59. Object result); 60. 61. ... 62. } q

Step 2: Why the mobility aspect must be singleton? Ê In general, each agent instance must have its own mobility aspect. As a consequence, mobility aspects must be instantiated per Agent instance (or Role instance). The current version of AspectJ supports the specification of per-object aspects. We could describe the instantiation of the Mobility aspect using perthis: public abstract aspect Mobility perthis(Agent) {…}

However, the use of perthis restricts the scope of the aspect. When one AspectJ aspect is declared to be singleton or static, its scope is the whole system and the aspect can crosscut all system classes. Per-object aspects can only crosscut the object with which it is associated. Since the mobility protocol crosscuts several classes, not only the Agent class or the Role class, the perthis clause cannot be used in this context. As a result, you have to declare learning aspects as singletons and introduce the methods and attributes to the Agent and Role classes. This was the strategy followed in the definition of the mobilityComponent attribute described in Step 1. Note that although the structure of the Mobility Aspect pattern does not describe these aspect members as part of a crosscutting interface, they have to be introduced due to AspectJ restrictions. They are declared as protected or private, which means that “they are protected or private to the aspects”: only code in the aspect and subaspects can

see these fields and methods. If the Agent or Role class has other protected members named in the same way (declared in the Agent or in another class) there will not be a name collision, since no reference to these members will be ambiguous. The use of inter-type declarations complicates the design of the Mobility aspect since it requires the agent or role instance to be exposed as a parameter in each advice of the Mobility aspect. The Mobility aspect in the EC system is implemented in AspectJ as a singleton aspect since it crosscuts many system classes. In this sense, the Agent instance is passed as a parameter in the advices of the Mobility aspects so that the advice code can determine which system’s agent is in charge of being moved. q Step 3: How to define a specific mobility aspect? Ê Mobility subaspects define specific implementations of the Mobility aspect. We can specify a different mobility subaspect to each agent type or agent role defined in our MAS. The subaspects must implement the abstract pointcuts and methods of the Mobility aspect. For exemplify, in EC system these elements were implemented in the ChairMobility aspect, as follows: • moving() pointcut – defines the interception of the searchInformation() method of the InformationSearchPlan class, as a possible execution point where the agent could be moved; • returning() pointcut – defines the interception of a specific method, as a possible execution point where the agent could be moved back to the home host; • init() method – defines the initialization and configuration of the agent mobility capacities in the JADE platform; • move() method – invokes the doMove() method of the JADEAgent class; • initializeAgentInNewEnviroment() method – defines actions to be executed after the agent has moved to another enviroment (such as, notifies other agents, installs sensors and effectors in the new enviroment, reinitialize interrupt plans); • checkMobilityNeed() method – verifies if the execution of the plan of information search has got any result. The Mobility subaspects must also specify which agent types and agent roles implement the MobileElement interface (step 1). ChairMobility aspect defines that the ResearcherUserAgent class implements the MobileElement interface. It specifies a “declare parents” AspectJ construction as presented below. 1. public aspect ChairMobility extends Mobility { 2. declare parents: ResearcherUserAgent implements MobileElement; 3. ... 4. ... 5. } q

Acknowledgments We would like to give special thanks to Rossana Andrade, our shepherd, for her comments, helping us to improve our pattern. This work has been partially supported by CNPq under grant No. 141457/2000-7 for Alessandro Garcia, grant No. 140252/2003-7 for Uirá Kulesza, and by FAPERJ under grant No. E-26/150.699/2002 for Alessandro. Cláudio is supported by CAPES under grant No. 31005012004M-9. The authors are also supported by the PRONEX Project under grant 7697102900, and by ESSMA under grant 552068/2002-0 and by the art. 1st of Decree number 3.800, of 04.20.2001.

References [1] Kiniry, J., Zimmerman, D.: A Hands-On Look at Java Mobile Agents, IEEE Internet Computing, vol.1, No.4, 1997. [2] Ubayashi, N., Tamai, T. Separation of Concerns in Mobile Agent Applications. Proceedings of the 3rd International Conference Reflection 2001, LNCS 2192, Kyoto, Japan, September 2001, Springer, pp. 89-109. [3] Fuggetta, A., Picco, G., Vigna, G. Understanding Code Mobility. IEEE Transactions on Software Engineering, vol.24, No.5, pp.342-361, 1998. [4] Karnik, N., Tripathi, A. Security in the Ajanta Mobile Agent System. Software Practice and Experience, January 2001. [5] Lange, D., Oshima, M. Programming and Deploying Java Mobile Agents with Aglets. Addison-Wesley, 1998. [6] IBM: AGLETS SOFTWARE DEVELOPMENT KIT HOME PAGE. http://www.trl.ibm.co.jp/aglets/index.html, 1999. [7] Bellifemine, F., Poggi, A., Rimassi, G. JADE: A FIPA-Compliant Agent Framework. Proceedings of the Practical Applications of Intelligent Agents and MultiAgents, April 1999; pp. 97-108. [8] Gosling, J., Joy, B., Steele, G. The Java Language Specification. Addison-Wesley, 1996. [9] Pace, A., Campo, M., Soria, A. Architecting the Design of Multi-Agent Organizations with Proto-Frameworks. Software Engineering for Large-Scale MultiAgent Systems, C. Lucena et al (eds.). Springer, LNCS 2940, February 2004, pp. 75-92. [10] Garcia, A., Cortés, M., Lucena, C. A Web Environment for the Development and Maintenance of E-Commerce Portals based on a Groupware Approach. Proceedings of the Information Resources Management Association International Conference (IRMA’01), Toronto, May 2001, pp. 722-724. [11] Garcia,A., Lucena,C., Cowan, D. Agents in Object-Oriented Software Engineering. Software: Practice & Experience, Elsevier, Vol. 34, Issue 5, May 2004, pp. 489 - 521. [12] Garcia, A., Sant'Anna, C., Chavez, C., Silva, V., Lucena, C., Staa, A. Separation of Concerns in Multi-Agent Systems: An Empirical Study. In: C. Lucena et al (Eds), "Software Engineering for MASs II", Springer, LNCS 2940, January 2004. [13] Deloach, S., Wood, M., Sparkman, C. Multiagent Systems Engineering. International Journal of Software Engineering and Knowledge Engineering, 11(3):231-258, 2001.

[14] Zambonelli, F., Jennings, N., Wooldridge, M. Organizational Abstractions for the Analysis and Design of Multi-agent Systems. In: Ciancarini, P., Wooldridge, M. (eds.): Agent-Oriented Software Engineering, Springer-Verlag (2001). [15] Aridor, Y., Lange, D. Agent Design Patterns: Elements of Agent Application Design. Proceedings of the 2nd International Conference on Autonomous Agents (Agents '98), ACM Press, 1998, pp. 108-115. [16] Chavez, C. A Model-Driven Approach to Aspect-Oriented Design. PhD Thesis, Computer Science Department, PUC-Rio, April 2004, Rio de Janeiro, Brazil. [17] Chavez, C., Lucena, C. Design-level Support for Aspect-oriented Software Development. Proceedings of the Workshop on Advanced Separation of Concerns in Object-Oriented Systems at OOPSLA'2001, Tampa Bay, USA, October 14, 2001. [18] Filman, R. What Is Aspect-Oriented Programming, Revisited. Proceedings of the Workshop on Advanced Separation of Concerns at ECOOP’01, June 2001. [19] Maes, P. Concepts and Experiments in Computational Reflection. Proceedings of the ACM Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA’87), ACM SIGPLAN Notices, October (1987): 147-155. [20] Baumer, D., Riehle, D., Siberski, W., Wolf, M. Role Object. Proceedings of the 4th Annual Conference on the Pattern Languages of Programs, Monticello, Illinois, USA, September 2-5, 1997. [21] Silva, O., Garcia, A., Lucena, C. The Reflective Blackboard Pattern: Architecting Large-Scale Multi-Agent Systems. In: Garcia, A. et al (Eds). Software Engineering for Large-Scale Multi-Agent Systems, Springer-Verlag, LNCS 2603, April 2003, pp. 73-93. [22] Yoshioka, H.; Tahara, Y.; Ohsuga, A.; Honiden, S. Security for Mobile Agents. Proceedings of the 1st International Workshop on Agent-Oriented Software Engineering at ICSE 2000, Limerick (IR), June 2000. [23] Gamma, E. et al. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, Reading, MA, 1995. [24] Lavender, R., Schmidt, D. Active Object: an Object Behavioral Pattern for Concurrent Programming. In: Pattern Languages of Program Design (J. O. Coplien, J. Vlissides, and N. Kerth, eds.), (Reading, MA), Addison-Wesley, 1996. [25] Hanenberg, S., Unland, R., Schmidmeier, A. AspectJ Idioms for Aspect-Oriented Software Construction. Proceedings of the 8th European Conference on Pattern Languages of Programming and Computing (EuroPlop’03), Irsee, Germany, June 2003. [26] AspectJ Team. The http://eclipse.org/aspectj/

AspectJ

Programming

Guide.

March,

2003.