The Agent Framework Design

The proposed system is a multi agent system with the agents designed using the itinerary pattern. There are basically eight kinds of agent design patterns: itinerary, branching, star-shaped, master-slave, MoProxy, meeting, Mutual Itinerary recording and facilitator (Emerson et. al., 2003). Aridor and Lange (1998) identified nine patterns that were grouped conceptually into three, and Danny (2008) also agrees with the classification, the classes are travelling, task and interaction. The travelling patterns include Itinerary, Forwarding and Ticket. In the task patterns two specific patterns are

UNIVERSITY OF IBADAN LIBRARY

64 identified, Master-Slave and Plan. A set of five patterns identified within the Interaction patterns are Meeting, Facilitator, Locker, Messanger and Organized group.

The basic idea of design patterns according to Emerson et. al., (2003) is to define general solution models for common problems that are found in a given context.

Design patterns make the development of applications easier, present a better understanding of the project, increase flexibility and promote reuse of components (Ajay et al, 1999: Silva and Delgado, 1998; Emerson et. al., 2003).

I. Itinerary pattern

Itenerary pattern provides a way to execute the migration of an agent, which will be responsible for executing a given task in remote hosts (Emerson et. al., 2003). The agent will create the itinerary object and initialize it with a list of destinations to visit sequentially and a reference to the agent. The agent will dispatch itself to the next available destination in its itinerary or back to its origin. The agent receives an itinerary on the source agency indicating sequence of agencies to visit. Once in an agency, the agent executes its task locally and continues on its itinerary. After visiting the last agency on its itenerary, the agent goes back to its source agency with the result (Aridor and Lange,1998; Danny, 2008).

The itinerary pattern is used when there is a need to hide the details of an agent‟s tour from its behavior in order to promote modularity of both parties. It is also used when there is need to provide a uniform interface for sequential traveling of agents to multiple hosts and to define tours that can be shared by agents (Emerson et. al., 2003).

The itinerary pattern was chosen for this study because of certain attributes inherent in it, among these are the fact that it supports variations in routing, it makes it easy to provide such variations by simply replacing one itinerary object with another or by defining itinerary subclasses, the agent class however, is not modified. Itimerary patterns also facilitate sharing of tours by different agents. This is made possible by sharing itinerary objects, although not simultaneously, for example, two agents may use the same tour to multiple users‟ desktops with different messages. The itinerary pattern also simplifies the implementation of sequential tasks, tasks can be encapsulated in special task objects while an itinerary class is extended with an interface to associate task objects with destinations. The itinerary object keeps track of the current tasks to perform. When the agent is dispatched to a new destination, it simply triggers the execution of the current task saved by its itinerary object.

UNIVERSITY OF IBADAN LIBRARY

65 II. Branching Pattern

The agent receives a list of agencies to visit and clones itself according to the number of agencies in the itenerary. Then each clone will visit an agency of the received list, execute its corresponding task and notify the source agency when the task is completed. This pattern splits the tasks that can be executed in parallel (Emerson et. al., 2003).

III. Star-shaped pattern

The agent receives a list of agencies it has to migrate to. It migrates to the first destination agency, executes a task, goes back to the source agency. The agency repeats this cycle until it visits the last agency on its list (Emerson et. al., 2003).

IV. Master-Slave

The master slave pattern defines a scheme whereby a master can delegate tasks to a slave agent. A master delegates a task to be performed on a given agency to a slave agent, in order to continue executing other tasks that cannot be interrupted (Emerson et.

al., 2003). Master-Slave also improves performance, a master agent can continue to perform other tasks in parallel with the slave agent. The master agent creates a slave agent, the slave agent visits the remote host, accomplishes the task and returns to the master with the results of the tasks (Aridor and Lange,1998). The master agent receives the results from the slave agent. The slave agent then destroys itself. The Master-Slave pattern is used when an agent needs to perform a task in parallel with other tasks for which it is responsible and when a stationary agent wants to perform a task at a remote destination. The Master-Slave pattern provides a fundamental way to reuse code among agent classes. However, the behaviour of a slave agent is not dynamic, as it is fixed at design time. An agent cannot be transformed into a slave at runtime nor can a slave agent easily be assigned to perform new tasks.

V. MoProxy pattern

The MoProxy (mobile proxy) pattern is used to control access to a resource (Ajay et al., 1999). When an agent needs a resource, it asks the Resource Granter (RG), indicating the desired permissions. Then, the resource granter returns a mobile proxy

UNIVERSITY OF IBADAN LIBRARY

66 for the agent with desired access right on the resource, in order to access the resource with the desired permissions depending on the restrictions of the resources. This prevents the agent from directly accessing the resource. This pattern is unique in that the mobile proxy can move along with the agent. If the resource moves, the mobile proxy keeps track of the resource, it moves along with the agent and provides the agent with controlled access to the resource at any location. Thus mobile proxy provides location transparent controlled access to an agent.

VI. Meeting pattern

The meeting pattern presents a way to promote local interactions between agents distributed on the network(Emerson et. al., 2003). Such interactions allow the execution of given tasks as well as the optimization of results. The meeting pattern uses the notion of meeting to synchronize various agents which were initially at different hosts, so they can visit a virtual place and find one another. The meeting agent, who will meet others, has a meeting object that keeps the place and the identification of the meeting. In this way the meeting agent requests from the meeting object the place of the meeting and then migrates to it. Each agent dispatches itself independently to the meeting place, where it will use the unique identifier to locate a specific local meeting manager object to register itself (i.e add itself to a list of agents that have arrived at that host). A meeting manager that manages the meeting notifies the agents already registered in the meeting place about the arrivals and departures of new ones (Aridor and Lange, 1998). Departing agents unregister themselves before leaving the meeting place. The meeting object intermediates the register of the agent on the manager.

Through the use of unique identifiers, multiple meetings can take place simultaneously at a single host. Meeting objects can be distributed by messages or located in central directories. The meeting pattern is used where there is a need for agents on different hosts to interact locally, and the overhead of travelling to a central place and interact locally is less than associated with remote communication. It is also used when agents cannot interact remotely, since they are located behind firewalls or on hosts with unreliable and low-bandwidth network connections, or if their origins are disconnected for the network, e.g. laptops. One solution is for these agents to dispatch themselves to a remote host where they can interact more efficiently. Meeting pattern is also used when agents need to access local resources on a given host, in this case the agents need to interact locally with the service provided by a given host.

UNIVERSITY OF IBADAN LIBRARY

67 VII. Facilitator pattern

Defines an agent that provides a name service and localization of agents with specific abilities thus facilitating the localization of a given agent (Emerson et. al., 2003). It is often convinient to assign a symbolic name to an agent in order to locate it on a later occasion.

VIII. Mutual Itinerary Recording

Is a general schema that guarantees the itinerary of a given agent will be registered and tracked by other cooperative agent and vice-versa, in a disposal of mutual support (Emerson et. al., 2003). When an agent is moving between platforms, it carries the information from the last platform, the current and the next ones to the cooperative agent through an authenticated channel. The agent keeps the register of the itinerary and it always compares the itinerary that it possesses with the received one. When an inconsistence is detected it should be treated . e.g it would either disallow the agent to visit the platform that caused the inconsistency or suspend the functioning of an agent or send the agent back to the source agency.

The use of mobile agent design patterns presents solutions that can be reused, avoiding loss of time and efforts to investigate problems that have already been solved.