A Java Application Framework for Agent Based Systems€¦ · A Java Application Framework for Agent Based Systems Elizabeth.A.Kendall, P.V.Murali Krishna, Chirag.V.Pathak , ... -

A Java Application Framework for Agent Based Systems

Elizabeth.A.Kendall, P.V.Murali Krishna, Chirag.V.Pathak , C.B.SureshComputer Systems Engineering

Royal Melbourne Institute Of TechnologyCity Campus

GPO Box 2476VMelbourne, VIC 3001 AUSTRALIA

email : [email protected]

Abstract

Agents are the next significant software abstraction, especially for distributed systems. Agent basedsystems have been developed in response to the following requirements:- Personalized and customized user interfaces that are pro-active in assisting the user- Adaptable, fault tolerant distributed systems that solve complex problems- Open systems where components come and go and new components are continually added.- Migration and load balancing across platforms, throughout a network.- New metaphors, such as negotiation, for solving distributed, multi- disciplinary problems.

Agents appear in a wide range of applications, but all agent development to date has been doneindependently by each development team. This has led to several problems, including i) duplicationof effort, ii) inability to satisfy industrial strength requirements for security and scalability, and iii)incompatibility of agent systems.

The application framework described in this chapter captures and clarifies the key aspects of agentbased systems. It provides a reusable and industrial strength agent architecture, design patterns, andcomponents for agent application development. The framework achieves agent interoperabilitybecause agents developed with the framework are inherently compatible with one another and cantherefore cooperate and form agent societies. Java has been utilized as the implementation languagebecause of its support for platform independence, concurrency, and mobility.

1. INTRODUCTIONAgents appear in a wide range of applications, including personalized user interfaces, electroniccommerce, enterprise integration, manufacturing, and business process support[3, 8, 11, 22].However, all agent development to date has been “home grown” [3] and done from scratch,independently, by each development team. This has led to the following problems [3]:

• Lack of an agreed definition: Agents built by different teams have different capabilities.• Duplication of effort: There has been no reuse of agent architectures, designs, or components.• Inability to satisfy industrial strength requirements: Agents must integrate with existing

software and computer infrastructure. They must also address security and scaling concerns.• Incompatibility: Agents should be able to interact and cooperate with each other. However, if

development efforts are not coordinated, the resulting agents are not compatible with one another.This chapter describes the product of several years of research, development, and implementation inagent systems that has been carried out at RMIT [11- 14]. The effort has concentrated on producinga methodology and platform for developing robust and maintainable agent systems through objectoriented software engineering. During framework development, the primary invariants andabstractions of agent based systems were identified and analysed. Subsequently, recurring designpatterns were uncovered and brought together. The result is multi- faceted and comprised of theeight sub- frameworks described in this chapter.

The RMIT agent framework is an application or horizontal framework [18]. An agent is a generalpurpose software module, and this framework captures expertise that is applicable to many diverseclient domains. Agents are a new abstraction, and the framework is still evolving. This means that itwill be significantly modified and used in many unforeseen ways; as such, this chapter providesdocumentation regarding the framework’s design via patterns [9]. Additionally, due to these

challenges, this framework is architecture- driven rather than data- driven [18], and clients mustcustomize the classes and behavior for their problem domain.

The RMIT agent framework addresses the four issues listed above that have plagued agent basedsystems to date. It accomplishes this by capturing and documenting the following:

• A detailed definition of an agent that is flexible enough to encompass simple and sophisticatedagents and agent societies

• A layered architecture, sub-frameworks for each layer, design patterns, and Java code. Thusduring an implementation of an agent based system a software developer can use, extend, orcustomize the framework with respect to a specific application context and therefore reuse theassociated design and code.

• Industrial strength agents that address scaling and integration issues• Interoperability and compatibility. All agents created with the framework are inherently

compatible with one another and therefore able to cooperate and form agent societies.

This chapter has the following outline. Section 2 presents the context of agent systems so that theproblems addressed by the framework can be clearly understood. Section 3 describes the LayeredAgent Pattern that provides the underlying architecture for the framework. Section 3 includes asample use of layered agents. Sections 4 through 7 describe the design of the sub-frameworks foundinternal to the individual layers. The sub-framework detailed in section 8 deals with agentconfiguration and instantiation, and this includes infrastructure for integrating the layers. In sections3 through 8, each sub-framework is documented in terms of its key abstractions and design patterns.For brevity, well known patterns are not described in detail. Lastly, section 9 illustrates how theframework can be employed in a sample application via Java code; key interaction diagrams are alsogiven. Section 10 summarizes the framework.

2. CONTEXT: AGENT BASED SYSTEMS

A weak agent is autonomous, social, reactive, and pro-active, and a strong agent, in addition to thesefeatures, has mentalistic notions and adaptability or learning [24, 25]. An agent can migrate, and amultiagent system is open. It is the combination of autonomous, social, reactive, and pro- activebehavior that distinguishes an agent from objects, actors [1], and robots [4]. Agents are the nextsignificant software abstraction, especially for distributed systems. The following two examplesillustrate the kinds of problems that agents address [24, 25].

• The air- traffic control systems in the country of ABC suddenly fail, due to weather. Fortunately,agentbased air- traffic control systems in neighboring countries negotiate between themselves todeal with affected flights, and the potentially disastrous situation passes without incident.

• Upon logging into your computer, you are presented with a list of news group items, sorted intoorder of importance by your agentbased personal digital assistant (PDA). The assistant drawsyour attention to one article about new work in your area. After discussion with other PDAs,yours obtains a technical report for you from an FTP site. When a paper you have submitted toan important conference is accepted, your PDA makes travel arrangements for you.

The RMIT agent framework is based on the following model of agent behavior [7, 12- 14]. Strongagents reason to select a capability that could achieve their stated goal(s). A plan from the capabilitieslibrary is instantiated when a triggering event occurs, and an instantiated plan is an intention. Anintention executes in its own thread, and an agent may have several intentions executing concurrently.Agents negotiate with each other in conversations or protocols [2, 15] and agent societies may havecentralized or decentralized management. Strong agent collaboration across disciplines often requiresthe use of ontologies [22] so that cross disciplinary semantics can be exchanged.

These aspects of agent behavior are summarized in Figure 1. The agent’s reasoning is within itsmodels, interpreter, and capabilities library. The agent’s knowledge is based upon input fromsensors that monitor external objects. A capability is chosen by the interpreter and manifested as anintention; three sample intentions are shown. One intention involves an effector object that impactsexternal objects. The other two intentions feature collaboration with other agents, either within theoriginal society or external to it. If the other agents are in another society, the agents must migrate,either virtually or in reality, in order to collaborate.

Sensors

Ex ternal

Object(s)

Eff ectors

Ex ternal

Object(s)M odels

Capabili ti es

I nterpreter

M igrati on

Intent ion

Intent ion

Coll aborati on

Intent ion

A gen t

A gen t

K ey : - agent com po nent

- comp o nent i n thread of co ntrol

Figure 1: Model of Agent Behavior

3. THE LAYERED AGENT ARCHITECTURAL PATTERN

Intent:

How can agent behavior be best organized and structured into software? What software architecturebest supports the behavior of agents ? The Layered Agent Architectural Pattern [12] supports allaspects of agent behavior but is flexible enough to address simple and sophisticated agent systems.

Motivation:

An agent system is complex; it also spans several levels of abstraction. There are manydependencies between the levels, and these dependencies are between neighboring levels. All of theinteractions feature two way information flow. The software architecture must encompassautonomous, social, reactive, and pro- active behavior. Agents also interact with their environment,through sensors and effective. The architecture must address agent mobility, translations betweenagent ontologies, virtual and actual migration, and centralized and decentralized collaboration.

Solution:

Agents should be decomposed into layers [4, 5] because i) higher level behavior depends on lowerlevel capabilities, ii) levels only depend on their neighbors, and iii) there is two way information flowbetween neighboring levels. The layers can be identified from the model of the agent’s real world.Figure 2 structures Figure 1 into seven layers as follows:

1. Sensory: the agent gathers sensory input from its environment.2. Beliefs: the agent’s models of itself and its environment.3. Reasoning: the agent determines what to do next, based on its goals, plans, capabilities, and

models. The plans may generically specify requests for services or responses to requests.4. Action: the agent’s intentions (instantiated plans from the reasoning layer) are carried out.

Pending actions for the agent are queued, and these are derived from incoming requests that havebeen accepted by the collaboration layer.

5. Collaboration: the agent determines how to collaborate with another agent. This includesaccepting or rejecting an incoming request for services.

6. Translation: the agent formulates a message for another agent, translating it into another languageor semantics (ontology), if necessary.

7. Mobility: when collaborating agents are in different locations, this layer is required for messaging

In Figure 2, top down information flow is shown on the left side, while bottom- up is on the right. Inbottom- up transactions, an agent’s beliefs are based on sensory input. When presented with aproblem, an agent reasons about its beliefs to determine what to do. When the agent decides on anaction, it can carry it out directly if it is within its capabilities, but an action that involves otheragents requires the collaboration layer. Within this layer, the agent decides how to negotiate withanother agent. Once the approach to collaboration is determined, the actual message is formulated atthe translation layer if the collaborating agents have different semantics. Messages to distant societiesare delivered by the mobility layer.

Layer 1: : senses changes in theenvironment; messages updates

Layer 2: stores the agent’ s beliefs; updatesbeliefs according to sensor input

Layer 3: processes the beliefs to determine

Layer 7: transports the agent todistant societies

what should be done next; stores the reasoner and the plans

Layer 4: stores and carries out the intentionsbeing undertaken by the agent

Layer 6: translates the agent’ s messagesto other agent’s semantics (ontologies)

Layer 5: verifies & directs outgoing messages to distant and local agents

MOBILITY

TRANSLATION

COLLABORATION

ACTIONS

REASONING

BELIEFS

SENSORYLayer 1: gathers regular sensorupdates

Layer 2: updates beliefsaccording to reasoning

Layer 3: reasons regarding theselected action

Layer 4: takes in pending actions

Layer 7: brings in messages from distant agent societies

Layer 6: translates incoming messages

Layer 5: determines whether an incoming message should be processed

Top Down Bottom Up

Figure 2: The Layered Agent Architectural Pattern

Top- down, distant messages arrive at mobility. An incoming message is translated into the agent’ssemantics. The collaboration layer stores contacts and conversations, and determines whether theagent should process a message. If the message should be processed, it is passed to the actions layer.When the action is dequeued for processing, it is passed to the reasoning layer. Depending on thetype of request, processing may continue to the beliefs and sensory layers. Once a plan is instantiatedas an intention and placed in the actions layer, it does not require the services of any lower layers.An intention calls on higher layers when it needs to involve other agents in its tasks.

Agent Society

AAAAAAAAAAAAAAAAAAAA




















Collaboration

AAAAAAAAAAAAAAAAAAAAAAAA




















Translation

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA







































Mobility




Action




Reasoning




Beliefs




Sensory




Action




Reasoning




Beliefs




Sensory




Action




Reasoning




Beliefs




Sensory

Agent Society

AAAAAAAA

AAAAAAAAAction

AAAAAAAAAAAA

AAAAAAAAAAAAReasoning

AAAAAAAA

AAAAAAAABeliefs

AAAAAAAAAAAA

AAAAAAAAAAAASensory

AAAAAAAA

AAAAAAAAAction

AAAAAAAAAAAA


AAAAAAAA

AAAAAAAABeliefs

AAAAAAAAAAAA

AAAAAAAAAAAASensory

AAAAAAAA

AAAAAAAAAction

AAAAAAAAAAAA


AAAAAAAA

AAAAAAAABeliefs

AAAAAAAAAAAA

AAAAAAAAAAAASensory

AAAAAAAA

AAAAAAAA

AAAAAAAA

AAAAAAAA

AAAAAAAA

AAAAAAAA

AAAAAAAA

AAAAAAAA

AAAAAAAA

AAAAAAAA

AAAAAAAAAAAA

AAAAAAAAAAAA

AAAAAAAAAAAA

AAAAAAAAAAAA

AAAAAAAAAAAA

AAAAAAAAAAAA

AAAAAAAAAAAA

AAAAAAAAAAAA

AAAAAAAAAAAA

AAAAAAAAAAAA

Agent Society

AAAAAAAA

AAAAAAAAAction

AAAAAAAAAAAA


AAAAAAAA

AAAAAAAABeliefs

AAAAAAAAAAAA

AAAAAAAAAAAASensory

AAAAAAAA

AAAAAAAAAction

AAAAAAAAAAAA


AAAAAAAA

AAAAAAAABeliefs

AAAAAAAAAAAA

AAAAAAAAAAAASensory

AAAAAAAA

AAAAAAAAAction

AAAAAAAAAAAA


AAAAAAAA

AAAAAAAABeliefs

AAAAAAAAAAAA

AAAAAAAAAAAASensory

AAAAAAAA

AAAAAAAA

AAAAAAAA

AAAAAAAA

AAAAAAAA

AAAAAAAA

AAAAAAAA

AAAAAAAA

AAAAAAAA

AAAAAAAA

AAAAAAAAAAAA

AAAAAAAAAAAA

AAAAAAAAAAAA

AAAAAAAAAAAA

AAAAAAAAAAAA

AAAAAAAAAAAA

AAAAAAAAAAAA

AAAAAAAAAAAA

AAAAAAAAAAAA

AAAAAAAAAAAA

Figure 3: Layered Agents: Centralized Collaboration and Translation and Shared Mobility Layers

Sample Usage:

A sample use of the Layered Agent Architectural Pattern can be seen in Figure 3. In this, theindividual agents each have senses, beliefs, reasoning, and actions. Because the societies arecentralized, the agents share a collaboration layer which contains a manager who delegates tasks andhandles collaboration. As the societies are multi-disciplinary, the collaboration layer calls on atranslation layer. Additionally, three distant agent societies share a common mobility layer.

4. THE SENSORY, BELIEFS AND REASONING LAYER SUB- FRAMEWORKS

4.1 SENSORY LAYER

The Sensory layer of an agent is responsible for proactively sensing the environment and updating thebeliefs; the key abstraction of the sub-framework is a Sensor that needs to cooperate with domainspecific interface classes. The design of the Sensory layer uses the Adapter pattern [6], shown inFigure 4. The sub-framework supplies the abstract Sensor’s interface (the method Sense()), while theapplication developer or user of the framework provides the domain specific SensorAdapter. TheSensory layer has a list of external objects which need to be sensed in the Sensing Plan.

SensingPlan

A

Sensor

virtual Sense(Belief b)

SensorAdapter

void Sense(Belief b)

DomainspecificInterface

GUIOperation(Belief b)

Sense(Belief b){ DomainspecificInterface i; i.GUIOperation(b);....}

Figure 4: Use of Adapter Pattern in the Sensory Layer

4.2 BELIEFS LAYER

The Beliefs layer stores Beliefs that can be primitive or composite. Whenever a belief is changedthrough sensory input or the actions of the agent, the Reasoning layer needs to be notified. TheBeliefs layer uses the Composite pattern [6] so primitive and composite beliefs can be treateduniformly and the Observer pattern [6] for notifying Reasoning when related beliefs are updated. Therole of these two patterns in the Beliefs layer is shown in Figure 5.

CompositeBeliefs

void update()A

INT-Observer

void update()PrimitiveBeliefs

A

Beliefs

void notifyObservers()ObservableBelief

Repository

Figure 5: Composite and Observer Patterns for the Beliefs layer

4.3 REASONING LAYER

The Reasoning layer determines what the agent should do next. In a strong agent, the Reasoninglayer encompasses mentalistic notions to emulate human intelligence, whereas in a weak agent itmatches an action to a stimulus. For strong and weak agents, Reasoning interprets beliefs andrequests to determine an appropriate reaction. Reasoning defines objects for the grammar used todefine stimuli, conditions, goals, and actions, and these are abstracted as Expressions and Plans.

The Interpreter and Strategy patterns [6] are employed per Figure 6. An agent’s plans are representedin expressions and interpreted using the Interpreter pattern. In Figure 6, RegularExpression is ageneral clause, LogicalExpression involves a logical operator, and BeliefExpression is a terminatingsymbol. In Reasoning, the Strategy pattern is employed so each plan is an object.

A

RegularExpression

Interpret( )

BeliefExpression

belief elementInterpret( )

LogicalExpression

Interpret( )

A

AbstractPlan

Expression 2

Expression 1

Figure 6: The Interpreter and Strategy Patterns in the Reasoning Layer

5. THE ACTION LAYER SUB-FRAMEWORK

5.1 OVERVIEW AND KEY ABSTRACTIONS

The Action layer is responsible for carrying out the plan selected by the Reasoning layer. A plan isinstantiated in a separate thread called an Intention. The Action layer handles CollaborationIntentions that utilize an interface to the Collaboration layer known as Collaborators, and ReactionIntentions that use an environment specific interface known as the Effectors. There is a need toprovide a Scheduler and a Prioritizer for scheduling and prioritizing actions.

The Action layer sub- framework consists of the following patterns:

• Command [6] is used to make a plan into a command.• Abstract Factory [6] creates a plan object based on a given class library.• Factory Method [6] creates intention thread objects dynamically.• Decorator [6] implements the Prioritizer.• Future [10], with Observer [5], asynchronous method invocation by an intention thread.• Active Object [16] is used to schedule actions which affect the environment.

5.2 COMMAND PATTERN

Intent

Encapsulate a request as an object, allowing the parameterization of clients with different requests,queuing or logging requests, and supporting undoable operations [20].

Motivation

Each intention has a plan to execute, and a plan specifies primitive actions that are to be taken. Aprimitive action is an operation which can be executed directly by the effectors or collaborators.Plans are known only at the runtime; this framework can’t explicitly implement plans. There is aneed to define a structure for plans that provides high level operations based on primitive ones.

A

INT-ActionPlan

A

IntentionThread

{active}

ReactionThread

ConcretePlan

A

INT-PlanFactory

ConcretePlanFactory

ActionConfigInfo

Library

n

Creates

Reads

GetLibrary

Execute()EffectorRep

Figure 7: Use of the Command and Abstract Factory Patterns in the Action Layer

Solution

The Command pattern [6] solves this problem, as shown in Figure 7. Each ConcretePlan is acommand object which implements the ActionPlan interface that declares the high level operationExecute(). The receiver of this command is a ConcretePlan object which is instantiated at runtimebased on the configuration information provided by the user. Each Concrete Plan will use primitivemethods of EffectorRep in their Execute() method.

5.3 ABSTRACT FACTORY

Intent

Provide an interface for creating families of related or dependent objects without specifying theirconcrete classes.

Motivation

The framework is concerned with providing an abstract command interface that each concrete plancan implement; it is not concerned with implementation. Each application developer will provide acollection of classes in which each plan is a separate class that implements the ActionPlan interface.A plan is instantiated for every new intention. Therefore, there is a need for a creational frameworkfor instantiating plans which reveals their command interfaces but not their implementations.

Solution

The Abstract Factory pattern [6] is used to solve the problem. In Figure 7, the PlanFactory is theabstract factory; it provides the interface to create the ActionPlan interface objects. TheConcretePlanFactory provides the implementation to create the concrete product objects,ConcretePlans. For this it uses the Library which stores several ActionPlan classes and instantiates therequested plan object. This plan object is then used by the Intention Thread.

5.4 FACTORY METHOD PATTERN

Intent

Define an interface for creating an object, but let subclasses decide which class to instantiate. FactoryMethod lets a class defer instantiation to subclasses [6].

Motivation

The sub-framework addresses reaction and collaboration intentions. The type of intention will dependon the action plan to be executed; thus the type of an intention is known only at runtime. TheIntentionManager class has to instantiate an IntentionThread object but can’t anticipate its type. Alsothe information about the composition of an intention object is in the subclasses. Thus there is a needto delegate the responsibility of instantiating intention objects to the respective subclasses.

Solution

The Factory Method pattern offers a solution. The IntentionThread abstract class implements afactory method Create which is declared in the interface IntentionFactory. The default definition ofthis factory method is parameterized by the ActionPlan object. Thus, depending on the ActionPlantype, ReactionIntention or CollaborationIntention subclasses will be instantiated. Both of these definethe virtual methods of the IntentionThread class. These methods are used by the IntentionThreadclass for creating the respective intention thread objects. Thus the ReactionIntention andCollaborationIntention subclasses determine how an object is to be instantiated.

5.5 DECORATOR PATTERN

Intent

Attach additional responsibilities to an object dynamically using Decorators that provide a flexiblealternative to subclassing for extending functionality [6].

Motivation

In an agent based system, priority handling is executed by the Prioritizer object. TheIntentionManager object uses Prioritizer in order to take appropriate priority handing actions. If anintention is of critical priority, all the intention threads currently executing that are of normal prioritywill be suspended and any new normal prority intentions are started in a suspended state. More thanone critical prioirity intention can be executed concurrently. When the execution of all the criticalintentions is complete, the normal priority intentions are resumed.

Solution

The Decorator pattern is shown in Figure 8. This pattern decorates (adds behaviour to) the run()method of the IntentionThread, where action plans are executed. The run() method is declared inRunnable interface and is called whenever a thread is started. Additional priority handling can beadded dynamically to it by using the decorator object, the ThreadControl class that encapsulates theIntentionThread. IntentionThreadManager is the client of IntentionThread and messages it to run().Both the ThreadControl and the IntentionThread classes conform to the Runnable interface, so theinstance of ThreadControl class can be used transparently in place of IntentionThread. The subclassof ThreadControl, the Controller class, provides the concrete decorator. The Controller forwards therequests to the IntentionThread via ThreadControl after performing priority handling.

IntentionThreadManager

A

IntentionThread

run(){active}

A

Runnable

void run()

ThreadControl

run()

Controller

run()run(){ // execute normal // thread run

run(){ // do the priority and other functions super.run();// do the post execution operations

run(){ IntenThrd.run();}

.....InteThread= new Controller(new IntentionThread());InteThread.run();........

Figure 8: Use of the Decorator Pattern in the Action Layer

5.6 THE FUTURE AND OBSERVER PATTERNS

Intent

The Future object provides a placeholder for a result which is expected in the future [16].

Motivation

In Java, actions running in threads can not return results directly because Runnable.run() has a voidreturn type. However, in an agent two separate threads, one of the intention and another of aconcurrent server, have to be able to communicate asynchronously when a result is returned from theserver thread. There is a need to identify a mechanism for supporting asynchronous communicationat the completion of a thread, and this mechanism must simulate “returning a value”.

Solution

In the Future pattern [10] (Figure 9), an instance of Future is used as a placeholder for a future value.The Client will execute an asynchronous operation, DoOperation(), which instantiates a Future objectand returns its reference. The Client will message the Future object’s read() which will block threadexecution if the Future is not in its updated state. Later on, the concurrently executingCoexistingServer updates the state of the Future object. Each Future object is an observable for thecorresponding observer Clients who register themselves with the related Futures. When a Future isupdated by the CoexistingServer it notifies these observers. This notification will execute the updatemethod of the Client, and in this method the blocked (or suspended) Client thread is resumed.

FutureClient

CoexistingServer

A

INT-Observer

Observable

Future f;f=DoOperation();f.read(); // blocks.

update(Observable o,Thread t){ t.resume();// Restarts the blocked thread}

A

INT-Runnable

Update(Object o){ // update the state notifyObservers(); // Calls the client's update}read(Observer o){ CurrentThread.suspend(); // Blocks if the state is not updated

Future f;f.Update(newvalue);

Figure 9: Use of the Future Pattern in the Action Layer Sub- Framework

5.7 COMBINATION OF ACTIVE OBJECT PATTERN AND ADAPTER PATTERN

Intent

The Active Object pattern decouples method execution from method invocation in order to simplifysynchronised access to a shared resource [16].

Motivation

Agent intentions act concurrently in different threads of control. However, an object in theenvironment may need to be affected or impacted by the agent in a sequential manner. Therefore,intentions will invoke the methods to affect the environment concurrently but the execution of thesemethods may need to be actually done sequentially. Thus a mechanism of queueing and dispatching isrequired to convert from concurrent to sequential flow.

Solution

In Figure 10, ClientInterface, Scheduler and ActivationQueue form the Active Object pattern, alongwith Method Object. Each method could be represented as a subclass which inherits from anabstract superclass MethodObject. However, this would mean the application developer has toprovide MethodObject classes encapsulating many methods, including methods to affect theenvironment. It is therefore not practical to represent each method as a seperate class and instantiateit at runtime. The solution to this problem is provided by the Adapter pattern [6] and the classConcreteAdapter. The user has to provide the ConcreteAdapter which marshalls the method callwhen a method is invoked and later on demarshalls the method object when it is dispatched.

Scheduler

void Dispatcher();Future Schedule( String methodid, Object args);

{active}Activation

Queue

{synchronous}

ConcreteRepresentation

ConcreteAdapter

Object Effect(String MethodId,Object args);

ClientInterface

Object NewMethod(String MethodId, Object args);void update(Observable o, Object args);

ConcretePlan

A

INT-Observer

Figure 10: Use of Active Object and Adapter in the Action Layer Sub- Framework

6. THE COLLABORATION LAYER SUB- FRAMEWORK

The collaboration layer is responsible for carrying out the exchange of services and negotiation withother agents. It determines how to collaborate and addresses different coordination protocols. Thecollaboration layer handles sending, accepting, and rejecting requests, along with replying.

6.1 CENTRALIZED COLLABORATION: THE MEDIATOR PATTERN

Centralized collaboration is the responsibility of a Mediator or Manager.

Intent

The Mediator pattern [6] allows an agent to freely collaborate with other agents without directknowledge of their existence.

Motivation

In a given agent society, each agent may not have knowledge of every other agent. Proliferatinginterconnections and dependencies increase complexity, complicate maintenance, and reducereusability.

Solution

The Mediator pattern is made up of a Colleague class category and two Mediator classes: an abstractMediator that defines an interface for communicating with colleagues, and a concrete class thatimplements the behavior required to coordinate the colleagues. Each Mediator has associated with ita multitude of Colleagues, both at the abstract and concrete levels. With a Mediator, agents do nothave to have direct knowledge of one another for collaboration.

6.2 DECENTRALIZED COLLABORATION

6.2.1 Overview and Key Abstractions

In decentralized collaboration agents deal directly with one another via structured messages. In thiscase, the agent maintains the state of each conversation/ negotiation to avoid endless loops. An agentmust also support different agent interfaces and maintain knowledge of agents it wants to interactwith. Decentralized collaboration is more complicated than centralized, and the sub-framework isstill under development; this section describes the present state of the design.

During decentralized collaboration, the Role of an individual agent changes; it can be a client or aserver. For example, when agent A passes a request to agent B, agent A is a client and agent B is aserver. But if the information provided by A is not sufficient, B makes a counter request for extrainformation, making B the client and A the server. Each negotiation Session needs to be uniquelyidentifiable. An agent always sends a Message in the Protocol of the receiving agent, andmessages are converted before being sent. Since the Collaboration layer will be communicating withmore than one agent concurrently, this layer is multithreaded. The many activities of theCollaboration layer are managed by the CollaborationInterface, including message delivery andreception that are addressed by Connectors and Acceptors, respectively.

The Collaboration layer sub-framework consists of the following patterns.

• Sychronized Singleton is used to manage the collaboration threads.• Decorator [6] changes the behaviour of the thread dynamically• Active Object [16] is used to schedule the requests forwarded by the action layer• Future [10] in combination with Observer is used for asychronous method invocation• Strategy [6] is used to convert a message into the corresponding language of the destination agent.

6.2.2 Synchronized Singleton Pattern

Intent:

To ensure that there is only one instance of a class.

Motivation:

There is a group of threads in the Collaboration layer and a single access point is necessary to get athread in order to process a message. Moreover, the state of each thread should be maintained. Allthese tasks should be done by a single object and moreover there should not be duplication or creationof another object of this type.

Solution:

The Synchronized Singleton pattern solves this problem. In sequential programming this can beachieved by making a ThreadPool object a Singleton. But in concurrent programming the Singletonpattern does not work. For example, if mulitple threads executing simultaneously try to instantiatethe Singleton, two objects of the same type are created. To solve this Double-Checked Locking [20]can be used; but, in Java, this can be achieved by wrapping the constructor of the Singleton [6] in asychronized method. This is shown in Figure 11.

ThreadPool

public static ThreadPool instance;public sychronized static instance( ){if(instance = 0)instance = new ThreadPool();return instance;}private ThreadPool( ){ ...}

Figure 11: Use of the Synchronized Singleton Pattern in the Collaboration Sub- Framework

6.2.3 Decorator Pattern (also 5.5)

Motivation:

The Collaboration layer needs a thread every time it sends or receives a message. This can be done byhaving dedicated thread objects, such as acceptor and connector threads. The other way to achievethe required behaviour is to reuse the primitive thread class by delegation, and this approach is moreefficient. But, there is a possibility all sending threads are busy but one is needed. In this case, therewould be an idle acceptor thread, but, because it doesn’t have the behaviour of sending, it cannot beused. This decreases the performance of the agent. A Strategy pattern can be used for this purpose,but behavior should be added dynamically rather than through specialization.

CollabThread

A

Command

CommandDecorator

ConnectorCommand

AcceptorCommand

ConcCommandDecorator

public Command cmd;CommandDecorator( Command cmd){this.cmd= cmd;}void execute( ){cmd.execute( );}

void run( ){ConcCommandDecorator cmdDeco = new ConcCommandDecorator(Command comd);cmdDeco.execute( );}

void execute( ){ super.execute( );}

void execute( );

void execute( );

void execute( );

ThreadPool

Figure 12: Use of the Decorator Pattern

Solution:

Use of the Decorator pattern is shown in the Figure 12. The abstract Command class has a methodexecute(); there are then two concrete command classes: AcceptorCommand andConnectorCommand. AcceptorCommand does the actual processing of the message received by theagent in its execute() method. Similarly, ConnectorCommand sends a message to other agents in theexecute() method. ConcCommandDecorator class is a concrete decorator of CommandDecorator. Theexecute() method of CommandDecorator wraps the execute method of the Command class. The userof the framework can add new behaviour to the thread, such as an authentication algorithm, bydefining a new concrete decorator.

6.2.4 The Collaboration Interface

6.2.4.1 Active Object with Future (also 5.6 and 5.7)

There may be many intention threads forwarding messages to the Collaboration layer. Hence there isa requirement that the Collaboration interface should be an active object. A message forwarded to theCollaboration layer may be a request or a reply; either way, a reply or an acknowledgment is expected.For the collaboration interface, the interface of active object has been modified to return a Futureobject (Figure 13) for each intention thread when a method is invoked and a return is expected. TheFuture acts as a placeholder for the message the intention thread is expecting.

CollabInterfaceRep

Scheduler

ActivationVector

CollabInterface

MessageHolder

Future AbsMessageObject

ConcMessageObject

CollaborationFacade

IntentionThread

CollabThread

Figure 13: Design of the Collaboration Interface.

6.2.4.2 The Collaboration Interface Representation

The CollabInterfaceRep of the active object Collaboration Interface in Figure 13 has to carry outseveral activities before forwarding the message to MessageHolder. This includes passing the messageto NewRepHandler or Reply-ackHandler. The NewReqHandler determines which agent can servicethe request via the AgentId-Service hashtable and creates a SessionId. If the message already has aSessionId, Reply-ackHandler uses the decomposer to obtain the destination agent id. AfterNewReqHandler or Reply-ackHandler perform their tasks, CollabInterfaceRep uses the AgentId-Protocol hashtable to find the protocol of the other agent and then converts the messageappropriately. The CollabInterfaceRep creates a MessageHolder and forwards the FutureId, SessionIdand message to the MessageHolder. Translate forwards the message to the Translation layer, ifnecessary. The objects involved in these steps are depicted in Figure 14.

A

AbsStrategy

CollabInterfaceRep

ConcreteStrategy

AgId_serviceHashtable

A

AbsMesgComposer

ConcreteMesgComposer

A

AbsSessionIdCreator

ConcSessionIdCreator

A

AbsSessionIdDecomposer

AgId_ProtocolHashtabl

A

AbsServiceRep

ConcServiceRep

TranslationFacade

Translate

MessageHandler

HashtableManager

NewReqHandler

Reply_ackHandler

ConcSessionIdDecomposer

Figure 14: Design of the Collaboration Interface RepresentationWhen a message arrives or is ready to be sent, the ThreadPool may not have an idle thread formessage handling. In this situation there is chance that the other agent’s connection or the messageto be sent may be lost. Therefore, it is necessary to hold messages in a separate thread until an idlethread is available.

When an Acceptor receives a message from another agent it checks for the SessionId; if one ispresent, the SessionId-Future hashtable is checked so the message can be placed in the correspondingfuture. If there is no SessionId, the Acceptor inserts one, converts the message into the agent’sinternal semantics, and then forwards it to the Action Layer via the MessageForwarder. WhenCollaborationInterface forwards a message to a Connector thread (ie CollabThread), the thread insertsa new SessionId into the vector (if necessary) and also in the SessionId-Future hashtable beforesending the message to the destination agent. The objects involved are shown in Figure 15.

The Collaboration layer has the following hashtables to maintain. The HashtableManager containsall these hashtables, providing a common access point.AgIdLiSock Hashtable: Contains the listening port for each agent in the societyAgId_Service Hashtable: Provides information about the services provided by the other agentsAgId_Protocol Hashtable : Provides information about agent dialects (KQML,COOL etc).SIdFuture Hashtable : Provides future objects for each session ID

ServerSocket

AcceptorConnector

Socket

ThreadManager

ThreadPool

A

CommandDecorator

A

Command

AcceptorCommand

ConnectorCommand

CollabThread

SessionIdVector

SIdFutureHashtable

AgIdLiSockHashtable

MessageForwarder

ConcommandDecorator

ThrStateHashtable

HashtableManager

MessageHolder

PollingThread

CollabInterfaceRep

Figure 15: Design of the Message Handling Mechanism in the Collaboration Layer

7. THE MOBILITY LAYER SUB-FRAMEWORK

7.1 OVERVIEW AND KEY ABSTRACTIONS

The Mobility layer is shared by several agents and agent societies. It supports virtual migration byproviding location transparency between collaborating agents. It supports actual migration byproviding a framework for cloning an agent in another environment. If agent A has to migratephysically from society 1 to society 2 then a clone of agent A is generated in society 2, and the clonedhas sensors and effectors which are compatible with the new environment.

Client ProxyAgent Mobility Layer

Agent

Remote Configurator

Agent Society

Actual Migration

Virtual Migration

Agent Mobility Layer

Client Proxy Remote Configurator

Agent SocietyAgent

BrokerInformationRepository

Shared Mobility Layer

Figure 16: Architecture of Mobility LayerFigure 16 shows the architecture of the centralised Mobility layer. This design is based on CORBA[21] The Mobility layer consists of a shared region and a region that belongs to an individual agent.It is made up of the following key abstractions. The Client Proxy marshalls the service requestmessages. It also acts as a class loader and as a proxy server to the lower layers, providing locationtransparency for virtual migration. The Remote Configurator supports actual migration by cloningan agent dynamically at runtime. The Broker is the central object for agent mobility. Each agent,Client Proxy, and Remote Configurator object is registered by the Broker. The Broker also providesthe bus through which inter-agent transactions are done. The Information Repository storesinformation about the registered objects.

The design of the Mobility layer is based on the following design patterns:

• Factory Method pattern [6].• Active object pattern [16].• Visitor pattern [6].• Proxy pattern [6].

7.2 FACTORY METHOD PATTERN (ALSO 5.4)

Motivation

An agent can request a service from another society (virtual migration) or it can migrate physically.The type of the request is only known at runtime, and the behaviour required for each type is verydifferent. Thus there is a need to dynamically create the handler object according to the incomingrequest. The framework also should be extensible so new services can be added, and this requires anabstract class Handler which can be specialized.

Solution

Figure 17 shows the design of the Broker in which the abstract class Handler declares the factorymethod MakeHandler in its interface and uses this factory method in the Create(Message). Theconcrete definition of this factory method is given by the subclasses VirtualMigration andActualMigration. The HandlerCreator selects the appropriate subclass according to the client requestand instantiates it. It then calls Create() on this object which then composes itself and creates theobject by using MakeHandler().

Broker

AgentRepository

Acceptor

VirtualMigration

void MakeHandler()

ActualMigration

void MakeHandler()

HandlerCreator

ThreadManager

Configuration

ClassLoader

Message

ServiceRepository

SocietyRepository

S

S

A

Handler

Handler Create(Message)virtual void MakeHandler()

Creates

Repository=Configuration.GetRepository(SERVICE)

this.MakeHandler()

switch(Message){case "virtual" : Handler h=new VirtualMigration(); h.Create(Message);

Figure 17: Design of the Broker.

7.3 ACTIVE OBJECT PATTERN (ALSO 5.7)

Motivation

VirtualMigration and ActualMigration are in their own thread of control; thus more than one threadcan access a ServiceRepository or SocietyRepository object concurrently. There is a need to providesynchronised access to these shared objects. One way to do this is by associating mutual exclusionlocks but this means that any class which inherits from Service Repository inherits the associatedsynchronisation mechanism.

Solution

The ActiveObject pattern (Figure 18) defines the client interface to access the ServiceRepository. Eachthread will have an object with this interface that it can use to message the repository. The interfaceobject methods wrap the calls to the ServiceScheduler. The scheduler in turn instantiates each methodas a MethodObject and enqueues it on the ActivationQueue. While instantiating the MethodObject,the scheduler passes the reference of the representation of ServiceRepository (a ServiceResourceRep).Thus each MethodObject encapsulates a specific method of the ServiceResourceRep.ServiceRepositoryRep is the object which actually defines the repository methods. The MethodObjectis a command object and it defines call() which wraps the method calls to the repositoryrepresentation. Up to this stage only method invocation is done; method execution is done in theseparate dispatcher thread, the Dispatcher() method of the ServiceScheduler. In the dispatcher thread,Scheduler dequeues a MethodObject and executes it.

ServiceRepositorySearchFor(Agent) Activation

Queue

MethodObject

call()

SocietyRepositoryRepSearchFor(Agent);

ServiceSchedulerSearchFor(Agent)

Dispatcher(){active}

1

n

1 1

1

1

AgentRepository

Creates

{ Scheduler sch; sch.SearchFor(Agent);}

{MethodObject m = new MethodObject(Agent,Representaion);ActivationQueue.enqueue(m);}

{Representation.SearchFor(Agent);}

Figure 18: Active Object Pattern used for ServiceRepository.

7.4 VISITOR PATTERN

Intent

Represent an operation to be performed on the elements of an object structure. Visitor lets you definea new operation without changing the class of the elements on which it operates [6].

Motivation

For actual migration, an agent has to be cloned in the destination society. RemoteConfigurator needsconfiguration details for cloning, such as the plan library and the beliefs. The configuration detailsand their format depend on the requirements of a given society’s RemoteConfigurator. Thus eachagent has to support various kinds of configuration access operations. Each agent has a similar objectstructure as all of them are created by the same framework. Thus there is a need to represent theconfiguration accessing functions separately from the agent structure; otherwise each agent has tosupport many distinct and unrelated operations in object structure.

Solution

Figure 19 shows the Visitor pattern. The ActualMigration handler transfers the Visitor from a distantsociety to the migrating agent. The ClientProxy in the Mobility layer instantiates the Visitor object.This Visitor object is passed to the corresponding layers, such as Reasoner, by calling Accept(). Asshown in the figure, the Reasoner object in turn calls back the Visitor object’s Visit method and

passes its reference to the Visitor object. As the object structure of the layer of an agent is fixed, theVisitor can gather the configuration information by using the public interface methods, such asGetPlan(), of the Reasoner. Thus there is no need to define separate methods for transferring theconfiguration details to another society. Moreover, services can be added by adding new Visitorsubclasses, and no change is needed in the agent structure.

A

Layers

virtual Accept(Visitor)

A

Visitor

virtual VisitReasoner(Reasoner)virtual VisitBelief(Beliefs)

ClientProxy

Reasoner

Accept(Visitor)GetPlan()

Beliefs

Accept(Visitor)GetBeliefs()

SocietyAVisitor

VisitReasoner(Reasoner)VistBeliefs(Beliefs)

SocietyBVisitor

VisitReaoner(Resoner)VisitBeliefs(Beliefs)

Broker

Accept(Visitor v){ v.VisitReasoner(this);}

Accept(Visitor v){ v.VisitBeliefs(this);}

VistReasoner(Reasoner r){ r.GetPlan();}VisitBeliefs(Beliefs b){ b.GetBeliefs();}

Figure 19: Design of the Visitor in the Mobility Sub- Framework

7.5 PROXY PATTERN

Intent

Provide a surrogate or placeholder for another object to control access to it [6].

Motivation

The client proxy object acts as a proxy server when an agent is performing virtual migration. Thisprovides location transparency of the server and creates an effect of migration. Thus the client proxyacts as an local representative for the remote agent of the another society.

Solution

ClientProxy is a proxy class, and it inherits and defines the methods declared in InterSocietyCollob,the intersociety collaboration interface which is used by the agent to perform intersocietycollaborations. The ClientProxy provides the service by using a Connector to connect to the Brokerand then requesting the Broker for virtual migration which is handled by the VirtualMigrationhandler. This is transparent to the client for which the Client Proxy is the server object.

8. SUB-FRAMEWORK FOR AGENT CONFIGURATION AND INTEGRATION

8.1 OVERVIEW

The process of creating an agent consists of creating the various layers and then integrating them.A creational framework is required for instantiating and structuring the individual layers according toa configuration provided by the application developer. The remaining object structure is alwayscreated in a configuration independent way. The configuration independent object structure (CIO)uses the configured object structure (CO). Thus there is a need to define a generic structure for theCIO, which is static, and to decouple it from the structure of the CO, which is dynamic. Theintegration of the individual layers means that each layer has access to its neighbouring layer’sinterface object. This interface object is a gateway to the respective layer.

The sub-framework for agent configuration and integration has the following key abstractions. Eachlayer should have an ConcreteInterface object which implements its interface. The ConcreteInterface object provides a wrapper around the implementation of the layer, and a globally knownpublic interface. There is a need to decouple the configured object structure, and theObjectStructureConfiguration provides the required decoupling by registering the CO for accessfrom the CIO. The AgentCreator has two sub-abstractions which are the Configurator and theIntegrator. The Configurator creates the CO and CIO. It also registers the CO into the

ObjectStructureConfiguration. The Integrator object uses the ObjectStructureConfiguration of anindividual layer to get the reference of the ConcreteInterfaceObject. It then integrates individualneighbouring layers according to the layered model of the agent.

The design for creating the object structure of individual layers and integrating them is shown inFigure 20. The design uses

• The Facade pattern to define the Interface objects.• The Builder pattern to create the object structure of the layers.

ObjectStructureConfiguration

CIO

CO

ConcreteInterfaceObjectIntegrator

A

INT-Interface

ALayerInterface

Neigbour

A

Configurator

AgentCreatorLayerSpecificConfigurator

LAYER

Figure 20: Model for the Creating the Agent.

8.2 BUILDER PATTERN

Intent

Separate the construction of the complex object from its representation so that the same constructionprocess can create different representations.

A

Configurator

virtual Configure()virtual SetFacade(Facade)virtual Facade GetFacade()

AgentCreator Creator

Configure(Configuration c)Integrate()

Creator(Configurator Config[7])

Creator f;.....f.Configure(Configuration);

ConfigurationAction

Configuration

ActionConfigurator

Facade GetFacade()SetFacade(Facade)

Configure()

ReasonerConfigurator

Configure()MakePlan()

Creator(Configurator Config[7]){ ActionConfigurator act= Config[3];ReasonerConfigurator reas=Config[2];.. }Configure(Configuration c){ act.Configure(c.GetActionConfig()); ............... Integrate();....}Integrate(){ reas.SetFacade(a.GetFacade());......}

ReasonerConfiguration

Reasoner

A

INT-ReasActInterface

ActionFacade

A

INT-CollabActInterface

EffectorInterface

ActionConfigInfo

CIO

ActionConfiguration AConfig;ActionConfigInfo Info;Configure(){ this.MakeEffector(); this.MakeFacade(); .........}MakeEffector(){ Effector e = (AConfig.GetEffector());if(e==Null){ Info.register(new DefaultEffector();}else{Info.register(e);// user defined interface }}

1 7

Creates

Create

Creates

Figure 21: Use of Builder Pattern and Facade Pattern in the Mobility Layer

Motivation

The agent creation process is directly related to its layered model. As each agent has the samestructure, they are created in the same way, including creating the individual layers and integratingthem. There is a need to isolate the creation process that can be used to generate different objectstructures according to the configuration provided by the user.

Solution

The AgentCreator collects the user configuration details and passes it to the Creator object.According to the Builder pattern [6] Creator is a director object (Figure 21). It stores the process usedto create an agent. The AgentCreator instantiates the Creator with seven Configurator objects, and theConfigurator objects are the builder objects which actually create the object structure based on theinformation in the Configuration. The Configurator declares a virtual method Configure. Theconcrete definition of this method is provided by the layer specific subclasses. For example, the Actionlayer has an object of ActionConfigurator class, which uses the configuration information stored inActionConfiguration object to create an object structure of this layer.

Each Configurator creates the Facade object and other objects which form the configured structure.Use of the Facade pattern [6](Figure 21) provides both a simple interface and decoupling between thesub-frameworks. The Facade object implements the unified interface for the layer. This will promotelayer independence and portability. The Configurator registers them in the configuration repositoryobjects, such as the ReasConfigInfo and the ActionConfigInfo. These repositories are used to get theFacade object reference during the integration phase executed by the Creator object’s integrate().

9. USING THE FRAMEWORK

9.1 SAMPLE APPLICATION

This section presents a network management agent as an example use of the framework. ThisNetwork Management Agent (NMA) has a network management server as its coexisting object in theenvironment. This server handles the management information for that host and this server can behost operating system dependent. The agent has beliefs which model the management information inthe server. The NMA senses this information by requesting it from the server by issuing a “getcommand”, while it affects the environment by giving the “set” commands to the server.

The application developer has to follow the following procedure:

1. Create an array of the Configuration objects: create an array of the Configuration objects. Thiscan be done by the following statement:

Configuration[] Conf=new Configuration[7];Here the array index of Conf points to the (layer number - 1)according to the layered architecture ofan agent. For example Conf[0] should always store the Sensory layer’s configuration information andConf[1] should always store the configuration details of Beliefs layers, etc..

2. Initialise the array of the Configuration objects: initialise the Conf object created in step 1. Thisobject is used by the framework to build the object structures of individual layers and then to integratethem. The initialisation can be done as in following example which initializes and configures theAction layer.

Create configuration object for the Action layer. This is shown in the following:ActionConfig Acon = new ActionConfig();The ActionConfig is the action layer’s configuration class derived from the Configuration superclass.

The next step is to initialise Acon which can be done in following manner.Acon.SetEffector(“agents.action.interObj.SnmpInterfaceObject”);SnmpInterfaceObject should implement the Effector interface and also the user given SnmpInterfaceinterface which declares the methods which effects the environment.Then describe the Effector type whether it an adapter or it is a simple Representation . Followingshows both types of Effectors.Acon.Efftype(0); // No active object.

Note that if Acon.Efftype(1) is executed then SnmpInterfaceObject should be derived from theAdapter class. This derived class should then execute the Object Adapter pattern. Followingexample shows the way to do it.public class SnmpAdapter extends Adapter implements Effector,SnmpInterface{

SnmpInterface Eff;public SnmpAdapter(){ Eff=new SnmpInterfaceObject(); // This is the actual representation of the

//environment}public String Display(String s){ String str = (String)NewMethod("Display",s); // Marshalling the Display

return str;}public Object Effect(String methodid, Object args) // Demarshalling method{ if(methodid.equals("Display"))

{// Call the method in the representation

return Eff.Display((String)args);}else{ return new String("Not proper");}}} // end of class

The SnmpInterfaceObject may look like below,

public class SnmpInterfaceObject implements Effector, SnmpInterface{ private DataOutputStream Output;

public SnmpInterfaceObject(){ utput=new DataOutputStream(Server.getOutputStream()); }public String Display(String str){try{ Output.writeChars(str+"\n");

Output.flush();return new String("Done”);}

catch(IOException e){ System.err.println("Error writing bytes");}

}

The next steps are as follows:Acon.SetPlanLib(“agents.action.SnmpPlanLib”);Acon.SetFacade(“agents.ActionFacObj”);

The SnmpPlanLib implements the PlanLibrary interface. User should provide the list of ActionPlan

objects in the SnmpPlanLib object. Example of SnmpPlanLib is given below,public class SnmpPlanLib implements PlanLibrary{ private Hashtable HTab;

public SnmpPlanLib(){ HTab=new Hashtable();try{

// Initialise the Hashtable with key field = “Name of the plan” and Value field =“Java Class// object of that name” . Note that each action plan must be a separate class.

HTab.put("DoSnmpAction",Class.forName("agents.action.DoSnmpAction"));}catch(ClassNotFoundException e){ system.err.println("SnmpPlanLib : Class error"); }}public Hashtable GetLib() // Interface method.{ return HTab;}

}The DoSnmpAction is the ActionPlan object defined by the user. It is defined as under,import agents.action.inter.*;

import agents.action.interObj.*;import agents.action.intention.*;public class DoSnmpAction implements ActionPlan{ private SnmpInterface Eff; // The Action Plan uses SnmInterface which is the Effector.// This object defines the methods to effect the environment.

private String str; // Binding public DoSnmpAction(){}

public DoSnmpAction(DoSnmpAction t){ this.str=t.str;}

// SetEffector is an Interface mehod used by the CIO to pass the effector object which is// forms the part of CO. Here it will be SnmpInterface object.

public void SetEffector(Effector e){ Eff=(SnmpInterface) e;}

// SetBindings is also a interface method. This method sets the list of bindings associated with this// Action Plan.

public void SetBindings(Enumeration b){// Here a String is a binding.

str=(String)b.nextElement();}

// Execute is the Interface method. This is the Command method used by the framework to// execute the ActionPlan in an intention thread.public void Execute()

{ String s;// Use the SnmpInterface ( which is the Effector ) method to Display a string.

s=Eff.Display(new String("The action is Snmp "+str));}}

Lastly, Conf[3] (layer number is 4 - 1 = 3) stores the Acon object.Conf[3] = Acon;

The Sensory and Beliefs layers’ configuration can be initialized in following manner:

SensoryConfig Scon= new SensoryConfig();Scon.SetSensor(“agents.sensory.MySensor”);Scon.SensPlan(“agents.sensory.SensingPlan”);Scon.SetFacade(“agents.SensoryFacObj”);Conf[0] = Scon;

BeliefsConfig Bcon = BeliefsConfig();Bcon.SetBeliefs(“agents.belief.interObj.MyBelList”);Bcon.SetFacade(“agents.BeliefsFacObj”);Conf[1] = Bcon;

Similarly, the Collaboration layer can be configured in the following manner:CollabConfig Ccon = new CollabConfig( );Ccon.SetCollabPort(PORT_NO); //This is the collaborating port number of this agentCconSetPeerAgentsFile(“~/agents/collaboration/configuration/config.txt”);This file should provide agent ids, listening ports, native agent communication language and servicesprovided by the agentsCconSetNumOfThrds(50);//Number of thread objects of type CollabThreadCconSetLanguage(“agents.collaboration.messagemngr.utils.ConcLangStrategy”);This class should be inherited from agents.collaboration.messagemngr.utils.AbsLangStrategyCconSetLanguageType(type);’1’ if state dependent like COOL or ‘0’ if state independent language like KQML.Ccon.SetFacade(“agents.CollabFacObj”);Conf[4] = Ccon;Note that the arguments of these methods are classnames which will be dynamically loaded andinstantiated at runtime. Also the framework does not enforce datatype checking. For example anyclassname can be passed in Acon.SetFacade which may not be the plan library type. Thus the datatypechecking has to be implemented by the user.

Create Configurators: The application developer has to create the array of Configurators as givenbelow:

Configurator[] ConfigArr= new Configurator[7];ConfigArr[0] = new SensoryConfigurator();ConfigArr[1] = new BeliefsConfigurator();ConfigArr[2] = new ReasonerConfigurator();ConfigArr[3] = new ActionConfigurator();ConfigArr[4] = newCollabConfigurator();ConfigArr[5] = null; // Translation layer not implementedConfigArr[6] = new MobilityConfigurator();

3. Create the Agent: Finally create the agent as follows:Creator Crea = new Creator(ConfigArr); // Configure the creator with the Configurators.Crea.Configure(Conf); // Create and start the agent with the given configuration.

Note that the Crea.Configure method will configure the agent’s object structures of individual layers,integrate them and finally start the agent.

9.2 INTERACTION DIAGRAMS

Figures 22 to 25 provide interaction diagrams to illustrate how the framework provides virtual andactual migration, including agent cloning via the RemoteConfigurator.

Broker ThreadManager HandlerCreator ActualMigration Configuration SocietyRepository

Message

1: Create(Message)2: Create(Message)

3: GetCollobService

4: Instantiate(Message)

5: MakeHandler6: GetSocRepository

7: SocietyRepository

10: Reference

12: Start

13: run()

11: Register

8: GetRemoteConfig

9: Remote Configurator Details

Figure 22: Creating and Starting a Handler for Migration

VirtualMigration Message Connector AgentConnection

ServerAgent ClientConnection

4: GetAgentService

1: Connect(Agent)2: Instantiate

3: AgentConnection

6: Collaborate(AgentService)

5: Desired service

7: Request

8: Reply9: Reply

11: Connect(ClientProxy)

10: GetClientProxy()

12: Instantiate

13: Client Connection

14: Send(Reply)

Figure 23: Performing Virtual Migration

ActualMigration Message ClassLoader Connector ClientConnection

RemoteConfig Connection

1: GetClientProxy

7: Load

2: GetMigrateClass

8: GetData(Classname)

9: Bytes

10: Connect(RemoteConfig)

11: Remote Configurator Connection

4: Connect(Client)

6: Client Connection

12: GetMotive()

15: Send(Motive,Bytes)

5: Instantiate

3: Vistor class name

13: GetClass()

14: Bytes

Figure 24: Actual Migration

ActualMigration RemoteConfigConnection

RemoteConfig Visitor ClientProxy MigratedAgent

1: Send(Motive,Bytes)2: Request

5: Bytes 6: Instantiate

7: Visit(this)8: LoadReasoner

9: Class

10: ProvideBeliefs11: LoadBeliefs

12: Class

13: ConfigureAgent()

14: Start

3: RequestAccepted

4: GetData(Vistor)

Figure 25: Remote Configuration using the Visitor Object for Creating an Agent

10. SUMMARY OF THE FRAMEWORKThe framework described in this chapter is ambitious. In that regard, the RMIT agent frameworkconsists of eight substantial sub-frameworks that could each be considered a distinct framework [18].The framework presented here represents a considerable contribution to agent system understandingand design, and it provides a platform for further development of agent based systems.

The RMIT framework is still under development, particularly in the areas of collaboration, reasoning,and mobility. It is anticipated that the framework can be extended to encompass these features, usingthe object oriented software engineering techniques of specialization and delegation.

Particular areas for further development are as follows.• Internal semantics of an agent: Currently the structures used for interlayer communication arenot well defined. For example the Action interface used by the Reasoner layer to send the action planto the Action layer has to be refined. More work has to be done on defining detailed yet generic (ieflexible and user configurable) interlayer communication semantics between the Action andCollaboration layers and the Reasoner and Action layers.• Collaboration layer: Agent collaboration is an active area of research, especially with respect toconflict management and opportunistic, rather than prescriptive, cooperation.• Mobility layer: The mobility and migration aspects of an agent requires further exploring,especially making the framework compatible to CORBA based centralised mobility. Also in the areaof actual migration issues of security and authentication with respect to agents and agent societieshave to be explored.• Beliefs layer: Currently the Beliefs layer is simply a collection of Beliefs objects. Furtherdevelopment could be carried out in which an object oriented database could be used for representingthe beliefs.• Translation layer: No work has yet been done for the Translation layer.

11. REFERENCES

1. Agha, G., A Model of Concurrent Computation in Distributed Systems. 1986: MIT Press.2. Barbuceanu, M. and M.S. Fox, "COOL: A Language for Describing Coordination in Multi-Agent

Systems", First International Conference on Multi-Agent Systems, 1995.3. Bradshaw, J. M., S. Dutfield, P. Benoit, J. D. Woolley, “KAoS: Toward an Industrial- Strength

Open Distributed Agent Architecture,” J.M. Bradshaw (Ed.), Software Agents, AAAI/ MIT Press,1997.

4. Brooks, R.A., "A Robust Layered Control System for Mobile Robot", IEEE Journal of Roboticsand Automation, 1986. RA-2(1).

5. Buschmann, F., R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal, Pattern-Oriented SoftwareArchitecture: A System of Patterns. 1996: Wiley and Sons.

6. Gamma, E.R., R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of ReusableObject-Oriented Software. 1994: Addison-Wesley.

7. Georgeff, M.P. and A.L. Lansky, "Reactive reasoning and planning", Proceedings of the SixthNational Conference on Artificial Intelligence, Seattle, WA, 1993.

8. Jennings, N.R., P. Faratin, M. Johnson, P. O'Brien, and M. Wiegand, "Using Intelligent Agents toManage Business Processes", First International Conference on the Practical Application ofIntelligent Agents and Multiagent Technology, London, 1996.

9. Johnson, R. E., “Documenting Frameworks with Patterns,” OOPSLA’92, 1992.10. Kafura, D.G., “A Polymorphic Future and First Class Function type for Concurrent Object

Oriented Progrmming”, Journal of Object Oriented Systems.11. Kendall, E.A., M.T. Malkoun, and C.H. Jiang, "A Methodology for Developing Agent Based

Systems for Enterprise Integration", EI '95, IFIP TC5 SIG Working Conference on Models andMethodologies for Enterprise Integration, Heron Island, Australia, 1995.

12. Kendall, E. A., M.T. Malkoun and C.H. Jiang,"The Layered Agent Patterns", The PatternLanguages of Programs (PLoP'96), Illinois,USA, Sept. 1996.

13. Kendall, E. A., M.T. Malkoun and C.H. Jiang, "The Application of Object-Oriented Analysis toAgent Based Systems", The Report on Object Oriented Analysis and Design in conjunction withThe Journal of Object Oriented Programming, February, 1997.

14. Kendall, E. A., M.T. Malkoun and C.H. Jiang, "Multiagent System Design Based on ObjectOriented Patterns", The Report on Object Oriented Analysis and Design in conjunction with TheJournal of Object Oriented Programming, June, 1997.

15. Kuwabara, K., T. Ishida, and N. Osata, "AgenTalk: Describing Multiagent Coordination Protocolswith Inheritance", submitted to Tools for Artificial Intelligence, 1995.

16. Lavender, R.G. and D.C. Schmidt, "Active Object: an Object Behavioral Pattern for ConcurrentProgramming", Pattern Languages of Programming, Illinois, 1995.

17. Orfalli, R., Dan Harkey, “Client/Server Programming with Java and CORBA”, John Wiley &Sons, Inc., 1997.

18. Rogers, G. F., Framework- Based Software Development in C++, Prentice Hall Series onProgramming Tools and Methodologies, 1997.

19. Schmidt, D.C., "The ACE Object-Oriented Encapsulation of Light Weight ConcurrencyMechanisms", 1995.

20. Schmidt, D.C., Tim Harrison, “Double-Checked Locking - An Object Behavioral Pattern forInitializing and Accessing Thread-safe Objects Efficiently”, Pattern Languages of Programming,Illinois, 1996.

21. Vinoski, S., “CORBA: Integrating Diverse Applications within Distributed heterogenousEnvironments”, IEEE Communications Magazine, Vol. 14, No.-2, Febuary 1997.

22. Tenenbaum, J.M., J.C. Weber, and T.R. Gruber, Enterprise Integration: Lessons from SHADE andPACT, in Enterprise Integration Modeling Proceedings of the First International Conference, C.J.Petrie, Editor. 1992, MIT Press.

23. Vere, S. and T. Bickmore, "A Basic Agent", Computational Intelligence, 1990(6): p. 41-60.24. Wooldridge, M.J. and N.R. Jennings, "Agent Theories, Architectures and Languages", ECAI-94

Workshop on Agent Theories, Architectures, and Languages, Amsterdam, 1995.25. Wooldrige, M.J. and N.R. Jennings, Intelligent Agents ECAI-94 Workshop on Agent Theories,

Architectures, and Languages. Lecture Notes in Artificial Intelligence, ed. J.G. Carbonell and J.Siekmann. 1994: Springer-Verlag.

Documents

A Java Application Framework for Agent Based Systems€¦ · A Java Application Framework for Agent Based Systems Elizabeth.A.Kendall, P.V.Murali Krishna, Chirag.V.Pathak , ... -