A Design and Management Framework for Mobile Agent Systems Omer F. Rana Department of Computer Science, Cardiff University, POBox 916, Cardiff CF2 3XF, UK email:
[email protected]
Abstract A framework for developing ‘mobile agent’ systems is described based on Petri net models of design patterns in the Aglets workbench [12]. The ‘Meeting’ and ‘Interaction’ design patterns are investigated. The models can be automatically configured from Java source programs, and can account for stochastic parameters such as port contention at hosts, agent registration, background workloads and scalability issues, such as bounds on total number of agents that may be supported at a host. The models are verified by comparing the performance of an application in Aglets with Petri net simulations on the GreatSPN simulator [2].
vided analysis is however more general, and will also hold for other mobile agent libraries, such as Voyager from ObjectSpace. A brief overview of previous work in mobile agents is provided in Section 2, where existing mobile agent libraries and techniques for modelling mobile agent systems are outlined. In Section 3 task and interaction design patterns are described, and in Section 4 the framework and PN models are presented, which combine a Master-Slave and a Meeting design pattern. Analysis of models and experimental results with Aglets are discussed in Section 5. We conclude in Section 6 with future work and extensions to the present system. 2. Previous work and notation
1. Introduction Mobile agent ‘Design Patterns’ [6] capture recurring themes in applications employing migratable code, and provide an efficient means to develop and debug distributed applications that make use of this paradigm. Design patterns fill the gap between high level, agent-specific programming languages such as RADL [14] and LALO [3] and system level programming languages such as C and Java. Design patterns may be combined in a modular way, either graphically, or via a scripting language, and can be used for code generation or rapid prototyping. Lange and Aridor [1] provide design patterns for use with the Java based Aglets mobile agent libraries from IBM, and divide these into various categories, such as Travelling patterns, Task patterns and Interaction patterns. Travelling patterns enable mobility management, and deal with various aspects of migration and forwarding of a mobile agent. Task patterns deal with allocation and assignment of tasks to general-purpose agents. Interaction patterns deal with the coordination and support for collaborative working between agents. A Petri net (PN) based framework for task and interaction patterns is presented, for deriving performance and design parameters. The PN models are analysed to study conditions for possible deadlock, liveness and synchronisation failures in Aglets based mobile agent systems. The pro-
Various programming libraries are currently available which support mobile agent development, such as Odyssey from General Magic, Voyager from ObjectSpace, Aglets from IBM Research, Mole from IPVR at Stuttgart University and Bee-gent from Toshiba, all of which provide Java class libraries, although each handles mobility in different ways. D’Agents from Dartmouth College [13] provides support for multiple programming languages (Tcl, Java and Scheme), and also implements security mechanisms such as encryption, digital signatures and security modules which interact with resource managers to decide which agents are allowed to access what system resources. A survey can be found in [8]. Similarly, mobile agent systems have been modelled in different ways. A pertinent technique involves the concept of a messenger paradigm, and includes various approaches: process algebras (such as monadic and polyadic calculus), actors and actor related formalisms (such as static and dynamic actor algebras), PNs, coordination languages (based on Linda and Objective Linda), temporal logics, category theory and others. A survey can be found in [5], where the authors are particularly interested in classifying formalisms according to the ‘richness’ offered for expressing mobility. They suggest that if a formalism were to allow dynamicity, i.e. the creation at run-time of a new process between several different address spaces, then process mobility is equiv-
alent to a process creating a copy of itself at the new location and ending its execution at the current one. We use PNs to model mobile agent systems, as theoretical results concerning PNs are plentiful, and they have a sound mathematical foundation [4]. Also, numerous tools are available for a quantitative analysis of such discrete event based systems. PNs are particularly relevant for modelling mobile agent systems, as they allow a direct investigation of factors such as resource conflicts, concurrency and synchronisation. It has been shown that SPNs are, under certain conditions, isomorphic to homogeneous Markov chains. By analysing metrics of the Markov chain (such as the steady state probability distribution) it is possible to investigate the behaviour of the system being modelled. A PN consists of a structural part and a dynamic part. The structural part is a bipartite and oriented graph S = (P; T; A; r; s), where P is the set (finite) of places, T the set (finite) of transitions: these two sets form the edges of the graph. A P T [ T P is the set of arcs. r : P T ! N is the value of an arc going from a transition to a place and s : T P ! N is the value of an arc going from a place to a transition. We will indicate with t the set fp 2 P : (p; t) 2 Ag, the input places of t. We define in the same way the set of output places of t with t = fp 2 P : (t; p) 2 Ag, the set of input transitions of a place p as p = ft 2 T : (t; p) 2 Ag and the set of output transition of a place p as p = ft 2 T : (p; t) 2 Ag. We have an initial marking M0 of the set of places. We define ps 2 P as the start place, used to trigger a control sequence and pe 2 P the end place. To represent control conditions in our model, we identify with Pcontrol the set of control places, where Pcontrol 2 P . WT represents the set of parameters associated with transitions, where the ith (1 i length(P )) element can either be pre-defined or expressed as an exponentially distributed random variable. The dynamic part of a PN involves the change in markings over time. We say that a transition t is firable with a marking M if 8p 2 t; M(p) > r(p; t). The firing of a transition changes the state of the PN from marking M into M0 as follows:
8 >M(p) + k2 s(p; t) if p 2 t :M(p) otherwise where k1 and k2 represent multiplicative factors associated with each arc in (A). See [11] for more details. 3. Task and Interaction Design Patterns in Aglets Mobile agent systems involve synchronisation and communication between migrating agents, and in Aglets a distinction is made between static agents that remain attached
to specific hosts, called Stationary Agents (SAs), and agents that can autonomously migrate to other hosts, called Mobile Agents (MAs). In Aglets the SA is responsible for overseeing the dispatch, retrieval, cloning, deactivation and activation of a MA at a host. For instance, various users may dispatch agents to a central host, which implements an ‘electronic marketplace’ or ‘meeting room’, where each user agent may implement different negotiation strategies. Each user agent is a buyer MA, which must interact with a seller SA, and do so within predefined constraints, which may relate to time of interaction or number of messages exchanged. Interactions between the SA and MA take place using tagged messages, and each MA may visit multiple seller agents before either returning to its parent host or before being deactivated. The parent application of a MA must also be able to track it, as it executes on hosts along its itinerary. If exceptions or errors occur, the parent may terminate the agent or may recall it back to its home site. A single host may offer multiple SAs or ‘marketplaces’, and an incoming MA has to identify the particular SA of interest. A MA is transmitted across the network using the Agent Transfer Protocol (ATP) [9], which uniquely identifies a SA service of interest at a remote host, with which it is to interact. This represents a typical e-commerce scenario in which MAs are delegated tasks by their users and negotiate with an SA to reach an agreement, and one which involves both ‘Task’ and ‘Interaction’ design patterns. Meeting Object
111 000 000 111 000 111 000 111 00 11 11 00 00 11 00 11
000 111 111 000 000 111
11 00 00 11 00 11
AgletProxy Meeting Manager Aglet
Agent Host (emerald.cs.cf.ac.uk)
Figure 1: Meeting ‘Interaction’ Design Pattern
Figure 1 illustrates an ‘Interaction’ design pattern, which models the ‘Meeting’ between incoming MA and an SA at a host. The participants involved in the Meeting design pattern are [10]:
MeetingManager: responsible for coordinating interaction between the incoming MAs, and informing them of the arrival or departure of agents. This role can be performed by the SA present at a site. Meeting: an object that stores the address of the meeting point and a unique meeting identifier. It must notify the MeetingManager about the arrival or departure of MAs.
Host: emerald.cs.cf.ac.uk
Host: emerald.cs.cf.ac.uk Aglets
Aglets Slave1
Slave1
Slave2
Slave3
Master Slave2
111 000 000 111 000 111
Slave3
111 000 000 111 000 111
Aglet Proxy
111 000 000 111 000 111
11 00 00 11 00 11
11 00 000 111 00 11 000 00 111 11 000 111
master.sendMessage(new Message("TagA",doTask())) ; dispose(); } catch (Exception e) { // Could not send to master } ... dispatch(destination) ; } catch (Exception e) // Could not create slave aglet }
Code Segment 1 ...
... SA 1 (a)
SA 1
SA n Stationary Agents
Meeting Manager
(b)
SA n Stationary Agents
Figure 2: Master-Slave ‘Task’ Design Pattern
Agent: a base class of a mobile agent.
The presence of an intermediate MeetingManager object allows agents to send multicast or broadcast messages to other agents involved in the meeting. Although MAs may pass messages between each other, it is more efficient to go via the MeetingManager, if more than one message needs to be sent. The MeetingManager is also useful for maintaining data shared by multiple MAs, and to automatically notify them if any changes take place. Each MA must invoke ‘Meeting’ method to interact with a ‘vector’ of other MAs. A MA may either specify the ATP address of where the meeting is to take place, or both the ATP address and a Vector of other MAs with which it must interact. If an MA cannot be registered, or an error occurs, the AgletException is called, and must be handled by the developer. When at a remote site, a MA may either interact directly with a SA, or it may launch other ‘slave’ agents to perform tasks on its behalf. Figure 2 illustrates the Master-Slave Task design pattern, where the creating MA is the ‘master’ and each generated MA is the ‘slave’. Each generated slave may either interact with the same SA, or it may interact with a different SA on the same host. Each generated slave also contains a pointer to the master, so that results for sub-tasks can be returned to the master. Similarly, a SA may launch multiple MAs to be dispatched to remote sites. public abstract class Slave extends Aglet { URL destination = (URL) atp://emerald.cs.cf.ac.uk/serv1:434; AgletProxy master = (AgletProxy)((Object[] p.master)) ; public void onCreation() try { initialiseTask() ; addMobilityListener( public void onArrival(MobilityEvent m) { try {
public class Master extends Aglet { public void run() { try { Object[] args = new Object[] { destination, ... createAglet(getCodeBase(), "MySlave", args) ; } catch (Exception e) { } // could not create slave aglet } public boolean handleMessage(Message msg) { if (msg.sameKind("TagA")) // Process message tagged as "TagA" return true ; } } }
Code Segment 2 Code segment 1 shows the Java class for creating a ‘slave’ Aglet, identifying two main methods initialiseTask() and doTask() that are performed by each slave. initialiseTask() is called on creation, and when the slave has completed its allocated task, it returns the result of the doTask() method to the master using a message tagged as TagA. Code segment 2 illustrates the Java code for creating the master Aglet. The run() method is invoked when the master is created, and leads to the creation of a slave Aglet using the createAglet() method. The handleMessage() method is used to process a tagged message received from a slave Aglet, with the master able to process only one message in this case. A master Aglet can also handle messages from slaves in parallel, but this would correspond to the use of an additional exitMonitor() within the message handler method above (not demonstrated here). 4. Design framework and Petri net models Our framework defines three PN models to describe the combined ‘Task’ and ‘Interaction’ Design Patterns. A coloured PN [7] is first used to model the arrival and departure of MAs at a host, and can account for the existence of multiple active services at a host, where the service of interest is distinguished by the colour of the incoming MA. When a single agent service is present at a host, all incoming agents are treated identically. Each agent header is examined to determine the service it requires, as identified by the destination variable in Code Segment 1 – each different ‘atp’ address is assigned a new colour. An incoming
We use an exponentially distributed random variable to model this time, as it cannot be predefined. The activation time for transition T4 represents the time required to notify existing agents of the presence of the current one, and is dependent on the total number of agents to be notified.
agent needs to be buffered at a port before passing on to the MeetingManager for registration. P5 P1
T1
T2 P3
T3
T4
P4
P6
P7
P2
Figure 3: Arrival Petri net
The PN in figure 3 identifies the receiving and registering of an agent for multiple agent services – the single service case is identical but does not use a colour tag. The colour dictates the creation of new tokens and the enabling of transitions based on the agent service of the same colour. We assume that only one MeetingManager is available for an agent service, and consequently, only one agent can be registered at a time. The MeetingManager therefore represents a synchronisation point for incoming agents. From figure 3:
j
Places (P): Places P1 and P7 represent the so (start) and se (end) place respectively. A token in place P1 represents the existence of an incoming MA, and a token in P2 models the presence of a particular port on which the agent is received. Place P3 represents the buffering associated with an incoming MA at a port. Place P4 is used to model the registration of the agent with the local MeetingManager, the latter being modelled as place P5. Place P6 corresponds to the notification to existing agents of the presence of the new agent. Place P7 is then used to trigger the next PN block which models either an agent-agent or an agent-host interaction. Transitions (T): Transition T1 is an immediate transition, and models the synchronisation between an incoming agent and the availability of a particular port and buffer. For instance, if an incoming agent requests connections on a port which is currently busy, then T1 would block any further operations. Transition T2 is a timed transition, and represents the time to buffer the incoming agent on an identified port. This time is dependent on the size of an agent SMA . Transition T3 represents the time to register and authenticate an incoming agent via the MeetingManager. We assume that only one agent can be registered at a time, hence the synchronisation of places P5 and P4 via T3. As the MeetingManager can perform many operations, the time to register an incoming agent is dependent on the current load on the MeetingManager object. The time associated with the firing of T3 corresponds to the time required for registration.
Markings (M(p)): Marking M(P 1) 1 triggers the operation of this PN block, and M(P 7) 1 terminates it. Marking M0 (P 2) equals the number of connections accepted on the port on which the agent service listens for incoming requests and M0 (P 5) is always equal to 1. The initial marking M0 can be specified as:
M0 = f0; connections; 0; 0; 1; 0; 0g !
Arcs: The output arc (T4,P2) indicates that once an agent has been registered and its existence notified to other agents with which it is to interact, the connection can be released to allow another agent request on a port.
Figure 4 illustrates the PN model for an agent-agent interaction. We assume that an agent may: (i) send a single message to another agent, (ii) send a multicast message to all other agents involved in the ‘Meeting’, (iii) invoke a method on another agent via the AgletProxy, or (iv) create one or more slave agents to handle a task on its behalf. A token in place P11 initiates the operations performed by the PN. Transition T8 is a timed transition and models the delivery of a single message between agents. If a multicast message needs to be sent, then the MeetingManager has to be invoked: places P12 and P4 are condition places which identify whether a multicast operation is sought, and also if the MeetingManager is available to perform the operation respectively; as T9 is an immediate transition, it has a higher priority of firing over transition T8. The place-transition pair P13-T10 model the time required to send a message from one agent to another. This time depends on the size of message to be transfered, the start-up time for the transfer, and the network load when the request for transfer is made. The place-transition pair P14-T11 represent the time to send a message to multiple agents, and depends on the size of the message, the start-up time, the network load, and the number of agents to which the message is to be sent. The condition place P15 indicates that a computation is required (i.e. the current agent wishes to invoke a method on another
P4 P1
Master-Slave PN
T1 P3
p
P11
T8
P5
T2 P13
T3
P6
T4
T10
P7
P2
T6
P8
k
P10
k T5
P18 T9
P14
P12
T11
T12
T7
P17
T14
P9
P15 T13 P16
Figure 4: Agent-agent interaction
agent). The immediate transition T12 models this request, and fires in preference to the timed transition T11. Transition T14 models the time to perform a computation (i.e. execute an operation on another agent and obtain results of the requested operation). If a MA wishes to generate slave Aglets, then 1, and when this happens, a token is delivered to place P1, and the Master-Slave PN is invoked. A maximum of ‘p’ slaves may be generated at any time, as indicated by M(p2) p. The immediate transition T1 acts as a synchronisation point to ensure that the maximum number of Aglets is not exceeded. The place-transition pair P3-T2 models the registration of newly created Aglets with the MeetingManager, and place P4 is a control place used to model the availability of the MeetingManager for a particular agent service. M(p18) 1 indicates the end of an agent-agent interaction. P5-T3 models the time to perform a given task by the slave Aglet once created. We assume that the slaves can operate concurrently, hence the time associated with transition T3 corresponds to the time for the longest task to complete. P5-T3 therefore models the doTask() method in the MS design pattern in Aglets, as identified in code segment 1. The place-transition pair P6-T4 models the time to receive a result from a slave Aglet once a task has been initiated, or it corresponds to the time to receive a response from a delegated task at a remote site. In both cases, the result is returned as a tagged message, and transition T4 models the time to receive one or more messages from another agent. The firing time for transition T4 is an exponentially distributed random variable with a mean of 1.0, although the designer also has
M(p16)
the choice to set this to a deterministic value based on an upper bound to the response time. The former approach is for performing a what-if investigation, while the latter approach may be used when the maximum response time is known. The place-transition pair P7-T5 models the aggregation of replies received from each of the delegated tasks, and ‘k’ results need to be received, corresponding to ‘k’ tokens in place P7 for transition T5 to fire. In the limiting case, k=p, but not all results may be necessary, and hence k p holds for the more general case. T5 therefore acts as a synchronisation point for gathering results from the delegated tasks by the master Aglet, and P8-T6 models the disposing of all the slave Aglets, which includes unregistering them via the MeetingManager and reclaiming memory held by each slave. ‘k’ tokens are then delivered to place P10, signalling the completion of the MS activity, and k=p indicates that all slave agents have been accounted for, enabling the number of tokens in P2 to be reset to ‘p’. A colour tag may be used to model the creation of slaves that can operate on other agent services at the same host. However the aggregation of results by the master is independent of which agent service is used, hence place-transition pair P7-T5 is not tagged. Finally P9-T7 models the generation of slave Aglets by the SA, and is dependent on M(p9) 1. Hence, for agent-agent interaction: Mmulticast = f0,p,0,1,0,0,0,0,0,0,1,1,0,0,0,0,0,0g, Mmaster,slave = f0,p,0,1,0,0,0,0,0,0,1,1,0,0,0,1,0,0g, Pcontrol = fp2,p4,p9,p12,p15,p16g, Pstart = fp1,p11g, Pend = fp10,p18g. Figure 5 illustrates the interaction between an agent and the host environment. We assume that an agent may per-
P5 Computation on host P1
T1
P3
T2
T3
P4
P2
P6
T5
P8
P7
T7
5. Results and analysis P9
T6
T4
Figure 5: Agent-host interaction
form computation directly on the host via the MeetingManager. From figure 5, places P1 and P9 represent the start and end places respectively. Condition place P2 models the availability of the MeetingManager and the host, and is used to enable the immediate transition T1. Place-transition pair P3-T2 models the time for authentication by the stationary agent on the host, i.e. whether the requested operation is permitted. Place P5 models the condition that the required operation is permitted, and used as a condition to enable transition T3. If the condition is not valid, then the timed transition T4 is selected, indicating that permission is not granted for this particular operation, hence marking M(P 5) 1. The place-transition pair P6-T5 models the time to retrieve data for the requested operation from local storage at the host, and is dependent on the quantity of data requested, the size of the network linking the host processor to local storage, the latency and bandwidth of the buses connecting the host processor to local storage. Finally, place-transition pair P7-T6 represent the time to perform the requested computation at the host: the generated results need to be sent back to the agent requesting the operation, and this is modelled by the place-transition pair P8-T7. We suggest that the MeetingManager needs to be involved in this operation, and therefore model this as the input arc P2-T7. Hence, for an agent-host interaction: M0 = f1,1,0,0,1,0,0,0,0g, Pcontrol = fp2,p5g, Pstart = fp1g, Pend = fp9g.
The PN models were simulated on GreatSPN, and results were compared with an Aglets implementation of the ‘Meeting’ and ‘Master-Slave’ patterns. The analysis of the models involved looking at structural (static) and dynamic properties of the PNs, to investigate potential conflicts that could lead to instability in the system being modelled. The arrival PN in figure 3 is deadlock free, indicating that all transitions are potentially firable when an incoming agent arrives. Hence, all incoming agents will be given service at a host, and all agents will have the chance to leave the system once completed. In our model, the capacity of the system is determined by the maximum number of tokens that may be handled by the simulator, although in an actual system the total number of agents supported will depend on system parameters such as local memory, disk space available etc. All agents eventually complete, and leave the system, indicated by the buildup of tokens at the end places. We found that the total number of tokens were preserved, indicating that our PN model of figure 3 is conservative with respect to the total number of tokens present. This analysis was performed assuming there was only a single agent service at a host. Agent arrival at a host is assumed to follow an exponentially distributed random variable, with a mean of 1.0, and this corresponds to the generation of new tokens in place P1 for the arrival PN.
Figure 6
Composition: To model an agent system we combine the PN blocks described above to capture particular agent behaviour as specified in the Aglets source code. Hence, we combine an arrival PN with an agent-agent or an agenthost PN, depending on the requested operations. The use of start and end places allow us to cascade PN blocks, with the end place of an arrival PN feeding into the start place of an agent-agent or agent-host PN. The end place of an agent-agent or an agent-host PN is then fed back to the start place of either an agent-agent or an agent-host PN if a repeated invocation is sought. Alternatively, the end place of an agent-host or an agent-agent PN indicates the departure of an agent from the system. Our model can be scaled to as many agents as necessary, being restricted by the platform on which simulation is performed. The use of specialised PN blocks for specific design patterns enables us to modularise the behaviour of agent-based applications.
Figure 7
Figures 6 and 7 show token distributions at various points in the PN of figure 4. Such a token distribution can be used to identify agent placement at various points in a distributed system, represented by the PN model. The simulation was carried out with an initial marking of: M0 = f5,3,0,1,0,0,0,0,0,0,2,1,0,0,0,2,0,0g, and the
steady-state marking was found to be: Msteady state = f0,3,0,1,0,0,0,0,0,3,0,0,0,0,0,1,0,1g, with 105 tangible and 8 vanishing markings. The net is found to be structurally bounded, and conservative (i.e. the total number of tokens remains constant), indicating that all agents asking for service eventually leave the system. The start and end places act as source and sink for tokens respectively. Place and transition invariance are used to deduce properties of the system being modelled by a PN. Place invariance corresponds to the presence of a fixed number of tokens in a set of places, whereas transition invariance suggests that a number of different firing sequences could lead to the same marking. Also, transition invariance is used to deduce a marking given a particular transition firing sequence. The agent-agent PN was simulated to deduce its structural properties, and all places except p9, p12, p15 were found to be covered by P-invariants. No transitions are covered by Tinvariants.
Figure 10
rate approaching 1.0 in place P5. Conversely, the number of tokens in place P8 decreases as the arrival rate in place P5 increases, indicating that P8 and P6 are ‘competing’ places, and represent a conditional branch in the system. Figure 9 illustrates the build up of tokens (agents) in place P6 as the token arrival rate in place P5 varies from 0.0 to 1.0, for two different firing delays on transition T4. We see that for firing delays on T4 approaching the immediate transition T3, the system reaches stability much quicker, and is stable over a wider range of arrival rates for P5. Figure 10 similarly illustrates the token build up in place P8, when changing the firing delays on T4 and varying the arrival rate of tokens in P5 from 0.0 to 1.0.
Figure 8
Figure 11
Figure 9
Figure 8 illustrates how the PN model in figure 5 responds to the variation in token arrival rate in place P5 as a parameter from 0.0 to 1.0, and the corresponding number of tokens that are created in places P6 and P8. The P5 token arrival rate models the delays in the availability of the host to perform a required computation, and models background workload at a host. We assume during this analysis that transition T4 has a unit firing delay, and there are a total of 50 agents allowed in the system at any time. We see that the token count in place P6 settles for values of arrival
We also perform a similar investigation on the agentagent PN, to deduce parameter values that lead to stability in the system. We vary the arrival rate in start place P11 of figure 4, and measure the buildup of tokens in P3, with M(p12) 1, M(p4) 1, M(p16) 1 and p 1. Varying the arrival rate helps us to modulate the number of agents that enter the system, while keeping all other transition firing rates constant, we get the agent distribution illustrated in figure 11. We see that the number of agents becomes stable for arrival rates greater than 0.5, indicating that stability at the point represented by place P3 would be achieved by generating these conditions in the system. These results may be used to determine bottlenecks in a Meeting/Master-Slave based agent environment. We can also deduce equilibrium conditions that lead to stability in the total agent count, iden-
tified as the steady-state markings above, and by varying the delays associated with particular transitions in our PN models, which we have assumed to remain constant so far. These delays represent particular computational resources at a host, and simulation studies can be used to identify where additional resources may be most effectively utilised.
References [1]
[2]
6. Conclusion and future work [3]
A PN based mobile agent management framework is presented in this paper. The framework is based on models of design pattern for building applications using the Aglets workbench, and two such design patterns are presented. Each PN is above all a visual formalism, which makes such models accessible to a wider range of developers. No protocols or program language statements are modelled (as in other PN based software engineering approaches), rather our intention is to capture synchronisation and coordination between components that make up the ‘Interaction’ and ‘Task’ design patterns. Every application that makes use of these patterns will benefit from our models, and we illustrate with a ‘marketplace’ paradigm how such patterns may be employed in a buyer-seller example. The concurrent semantics of Coloured PNs enable us to monitor multiple agent services at a host. Stochastic parameters in a distributed system are modelling using a GSPN, which may be simulated on various public domain simulators. Providing PN blocks of design patterns in agent systems, such as Aglets, is also aimed at enabling automatic construction of mobile agent systems. Visual development environments may be used to put multiple patterns together, for rapid application development, and also for deciding the best way to launch and control agents. This paper provides two design patterns within a general framework, consisting of PN blocks which are modular and contain places for conditions which may be instantiated directly from code. Such blocks may be simulated to obtain visual feedback on design parameters involved in an agent system. The designer may experiment with different PN blocks and generate comparative bounds on performance. We stress the hierarchical nature of our scheme, and expect that architectures on which agent services are run may also be modelled as PNs, and be combined with those for agent-agent and agent-host interaction. Perhaps the ultimate test of a modelling scheme is its utility in particular real-world applications. This work may also be useful in adding performance models to Aglets, and allow application developers to perform what-if investigations on the code generated with Aglets libraries. Acknowledgment: Thanks to Chiara Biancheri for simulations on “TimeNet”.
[4]
[5]
[6]
[7]
[8]
[9] [10] [11] [12]
[13]
[14]
Y. Aridor and D. Lange. Agent Design Patterns: Elements of Agent Application Design. Second International Conference on Autonomous Agents (Agents ’98), Minneapolis/St. Paul May 10-13, 1998. G. Chiola, G. Franceschinis, R. Gaeta, and M. Ribaudo. GreatSPN2.0. Dipartimento di Informatica, Universit`a di Torino (Italy), 1997. CRIM-Montreal. LALO, 1998. http://www.CRIM.CA/sbc/english/lalo/. R. David and H. Alla. Petri nets for modeling of dynamic systems - a survey. Automatica (Elsevier Science Limited), 30(2):175–202, 1994. G. Di Marzo Seregeundo, M. Muhugusa, C. Tschudin, and J. Harms. Survey of Theories for Mobile Agents. Technical Report No. 106, TeleInformatics, University of Geneva, 1996. E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Abstraction and Reuse of Object-Oriented Design. In ECOOP. Kaiserslautern, Germany, 1993. K. Jensen. Coloured Petri nets. In W. Brauer, W. Reisig, and G. Rozenberg, editors, Petri Nets: Central Models and Their Properties, Advances in Petri Nets 1986 Part I, pages 248–299. Springer-Verlag, Berlin, Germany, 1987. N. M. Karnik and A. R. Tripathi. Design issues in MobileAgent Programming Systems. In IEEE Concurrency, July/September 1998. D. Lange and Y. Aridor. Agent Transfer Protocol/0.1. IBM Research Working Document, 1997. D. B. Lange and M. Oshima. Programming and Deploying Java Mobile Agents with Aglets. Addison-Wesley, 1998. T. Murata. Petri nets: Properties, analysis and applications. In Proceedings of the IEEE, April 1989. I. Research. The Aglets Software Development Kit, 1998. See web site at: http://www.trl.ibm.co.jp/aglets. D. Rus, R. Gray, and D. Kotz. Transportable Information Agents. Journal of Intelligent Information Systems, 9:215– 238, 1997. R. Systems. Reticular Agent Description Language, 1999. http://www.agentbuilder.com/.
