Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999 Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
A Petri Net Model of the Meeting Design Pattern for Mobile-Stationary Agent Interaction Omer F. Rana and Chiara Biancheri
Department of Computer Science, Cardi University { POBox 916 {Cardi CF2 3XF, UK fO.F.Rana,
[email protected]
Abstract
on laptops and other mobile computing devices.
A framework for modelling performance of agent design patterns (ADPs) as Petri net (PN) models is presented. We explore the Meeting ADP in IBMs Aglets. The framework is extendable to other ADPs, and user speci ed control conditions. Development of the PN will allow a programmer/systems designer to calculate bounds on performance for the Meeting ADP, and enable better resource management in a distributed computing environment. Our PN model can cater for multiple mobile and stationary agents, and also for stochastic variables such as network latency and port contention at a host.
Various systems are currently available which support the mobile agents paradigm, some of which have gained popularity over the past few years. TeleScript from GeneralMagic Inc was the rst commercial transportable agent library [19], which has now been superseded by a Java based library called Odyssey. Voyager from ObjectSpace [15] is a Java class library for supporting distributed mobile components, and combines the Common Object Request Broker Architecture (CORBA) model with mobile Java agents. Voyager also supports a number of other CORBA services such as directory, object persistence and multicast services. Other mobile agent systems include Agent Tcl [10] which uses the scripting language Tcl to write executable code, and Sumatra [16]. Another well known Java based system called Mole [18], developed at Stuttgart, allows restricted migration, where only the code and data for the agent is moved to a remote site, and not its execution state. D'Agents from Dartmouth [17], [10] 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.
Keywords: Mobile-Agents, Petri nets, Aglets, Design Patterns
Introduction An approach gaining favour recently is the concept of moving the computation to the data, in the form of mobile code, that is generally referred to as a mobile agent. This is particularly bene cial when dealing with large data sets, or when the exact sequence of service provision is not known in advance and dependent on the order in which processing is performed. Hence, in a system involving mobile agents, the agent can visit a number of hosts, which o er part of the complete service required by the agent. The agent does not need to know the complete itinerary in advance, and may change its routing tables based on information gathered at intermediate sites. This gives mobile agents the autonomy to make decisions based on interactions with local hosts as they move from one site to another, and negotiate services with hosts as they travel across a communication network. Furthermore, the mobile agent does not need a permanent connection to the originating host, making it ideal for handling temporary network connections, as available
In section 1 we outline the general philosophy behind design patterns, and provide an overview of agent design patterns with reference to the Aglets libraries from IBM Research [11]. The meeting design pattern is explored in detail in section 1.1, and a Petri Net model of this design pattern is provided in section 3. Results obtained from a Petri Net simulation are discussed in section 4, and techniques for constructing a mobile agent based system are outlined. We conclude with our aspirations and extensions to the current work. 1
0-7695-0001-3/99 $10.00 (c) 1999 IEEE
1
Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999 Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
Modelling approaches
we are primarily interested in modelling performance, our interests lie in re ning the Petri Net model representing the host architecture, and the synchronisation between the host and incoming agents.
Various techniques for modelling mobile agent systems exist, one of which is based on the concept of a messenger paradigm. Modelling interactions in a messenger system can be divided into various approaches: process algebras (such as monadic and polyadic calculus), actors and actor related formalisms (such as static and dynamic actor algebras), Petri Nets, coordination languages (such as Linda), Wooldridge temporal logics, category theory and others. A survey can be found in [7]. Di Marzo et al. [6] describe the messenger paradigm on which the approaches summarised in [7] are based. Mobile agents can be viewed as messenger systems which involve mobile threads of execution without a central control. In the messenger paradigm two hosts communicate by exchanging both code and data.
1 Agent Design Patterns Design patterns [8] provide a general description of a recurring theme within a certain context [3]. Various design patterns were provided as standard within the Aglets workbench from IBM, which capture designs for recurring themes in mobile agents, such as the Master-Slave pattern, Messenger-Receiver pattern, Meeting pattern and the Noti er-Noti cation pattern.
1.1 The Meeting Design Pattern
The Meeting concept as described by White [19] requires agents on the same computer to call one another's procedures. Assuming that only one agent service is active at a host site, then according to this definition, an incoming agent may interact with the local stationary agent present at the site, or two agents might travel to the same site to interact with each other. The static or stationary agent may have been dispatched to the site, or it may have been installed by the server operator. The sequence of events that take place from the creation of an aglet at a host, to its migration to other hosts in its itinerary, are as follows:
The messenger paradigm extends the RPC model, with participating hosts assumed to be connected by unreliable channels over which messengers are exchanged as data packets. The messenger paradigm also describes a shared data structure called the 'dictionary' for executing threads to share data, and process queues as low-level mechanisms o ered by a host to implement basic concurrency control such as thread synchronisation, mutual exclusion etc. Each aspect of the messenger paradigm is subsequently modelled using the formalisms listed above.
An aglet is created at the originating host, by call-
Mobile Petri Nets extend the standard Petri Net model by adding mobility (as Mobile Nets) and re exion (Dynamic Nets). Mobile Petri Nets allow the passing of a reference to a process (a channel name) along a communication channel. Places within the Petri Net act as channels and mobility amounts to passing tokens as names for places. Dynamic Nets extend Mobile Nets by adding the possibility of creating new Nets during the ring of a transition. A formalism for describing the complete behaviour of such a system has not yet been de ned. Most extensions proposed to Petri Nets for modelling mobile agent systems are for the dynamic creation and execution of new agents at a remote site. Consequently, stress has been placed on developing Petri Nets to model the creation of new agents during migration. Formal treatment of these extensions have still to be investigated, and their use in modelling a large information system may become cumbersome and complex. In our approach we use the well de ned General Stochastic Petri Net (GSPN) model, which can be simulated on a number of public domain and commercial Petri Net simulators such as GreatSPN[5] or TimeNet[9]. Since
ing the OnCreation() method. A new aglet is created and its data structures are initialised. OnCreation() is called only once during the lifetime of the aglet. A proxy object is also created for this new aglet, which is always local to an aglet host. Hence an aglet travels across a network, whereas a proxy object representing the aglet remains local; The aglet is dispatched to a remote host. The transfer of an aglet from the point of creation to other hosts in its itinerary takes place according to the Agent Transfer Protocol (ATP) [13]. ATP also allows a number of di erent agent services to be active at any host. The incoming aglet therefore has to identify an agent service by a unique address. At a remote host, an aglet can interact with its environment through an AgletContext object, which allows an aglet to add new aglets or retract old ones; At a remote host, the aglet runs an OnArrival() method to perform any initialisation at the remote host, followed by the run() method for executing
2
0-7695-0001-3/99 $10.00 (c) 1999 IEEE
2
Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999 Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
code. OnArrival() needs to be executed each time the aglet visits a new host; The aglet may undergo a number of other operations at a remote host, such as storing the state of the aglet onto disk (deactivating an agent), retrieving the state of an aglet from disk (activating an agent), cloning of an aglet or disposing an aglet.
Meeting Point
Agent Services
Mobile Agent Agent Host (emerald.cs.cf.ac.uk)
The Meeting design pattern de nes how synchronisation between di erent agents that wish to interact with each other is to take place. A Meeting class is used to identify a speci c agent service where the meeting is to take place, and a unique identi er for the meeting itself; the latter allows multiple meetings to take place at the same agent service. Once an agent (which wishes to interact) arrives at the particular agent service identi ed, it needs to register itself with a manager object (such as the stationary agent), and notify other agents of its presence. The participants involved in the Meeting design pattern are described in [4], and include:
Figure 1: Agent Meeting Point Meeting Object
11 00 00 11 00 11 00 11 111 000 000 111 000 111
11 00 00 11 00 11 00 11
000 111 111 000 000 111
AgletProxy Meeting Manager Aglet
Agent Host (emerald.cs.cf.ac.uk)
Figure 2: Meeting Design Pattern
MeetingManager: responsible for coordinating in-
teraction between the incoming agents, and informing them of the arrival or departure of agents. This role can be performed by the stationary agent present at a site; Meeting: an object that stores the address of the meeting point and a unique meeting identi er. It must notify the MeetingManager about the arrival or departure of agents; Agent: a base class of a mobile agent
The MeetingManager is also useful for maintaining data shared by multiple agents, and to automatically notify them if any changes take place. Figure 1 illustrates the existence of multiple agent services at the same host, and gure 2 illustrates the interaction between various components in the Meeting design pattern. We aim to model this interaction in our Petri Net.
2 Petri Nets: de nition and notation
Hence, an agent noti es a Meeting object at its arrival. The Meeting object identi es the MeetingManager object and registers the newly arrived agent using the addAgent() method. The newly arrived agent is noti ed of all agents that have already arrived at the meeting, and all existing agents are noti ed of the presence of the new agent. At departure, a leaving agent noti es the Meeting object, which locates the MeetingManager responsible for the meeting. The departing agent is subsequently unregistered by the MeetingManager.
A brief overview of Petri Nets is provided in this section, a more detailed coverage can be found in [14]. A Petri Net 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 ( nite) of places, T the set ( nite) 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 de ne 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 de ne ps 2 P as the start place, used to trigger a control sequence and pe 2 P
The presence of an intermediate MeetingManager objects allows agents to send multicast or broadcast messages to other agents involved in the meeting. The MeetingManager has to contact the agent proxy at the local host if one agent requests an operation on another. Hence, although agents may pass messages between each other, it is more ecient to go via the MeetingManager, if more than one message needs to be sent. 3
0-7695-0001-3/99 $10.00 (c) 1999 IEEE
3
Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999 Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
PN for agent-agent interaction. Scenario 1: Single Agent Service per host: When
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-de ned or expressed as an exponentially distributed random variable.
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, and needs to be bu ered at a port before passing on to the MeetingManager for registration. The PN in gure 3 identi es the receiving and registering of an incoming agent. We assume that only one MeetingManager is available, and consequently, only one agent can be registered at a time. The MeetingManager therefore represents a synchronisation point for incoming agents. From gure 3:
The dynamic part of a Petri Net involves the change in markings over time. We say that a transition t is rable with a marking M if 8p 2 t; M(p) > r(p; t). The ring of a transition changes the state of the Petri Net from marking M into M0 as follows: M0 (p) = M(p) - k1 r(p; t) if p 2 t, M0 (p) = M(p) + k2 s(p; t) if p 2 t and remains unchanged otherwise, here k1 and k2 represent multiplicative factors associated with each arc in (A).
Places (P): Places P1 and P7 represent the start so and se place respectively. A token in place P1
represents the existence of an incoming agent, and a token in P2 models the presence of a particular port on which the agent is received. Place P3 represents the bu ering associated with the incoming agent 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 noti cation 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 agent-host interaction. It should be noted, that places P2, P5 in gure 3 and P2, P3 in gure 4 are activated by tokens received from external agents.
To describe mobile agent systems we use two extensions to basic Petri Nets called the General Stochastic Petri Net (GSPN) [1] and Coloured Petri Net [12]. In a GSPN, transitions can be of two di erent types: immediate transitions which re in zero time once enabled, and timed transitions that may either re after a pre-de ned interval once enabled, or have an exponentially distributed random variable associated with them, which expresses the delay from their enabling to their ring. GSPNs are shown to be equivalent to stochastic point processes in which an embedded Markov chain can be recognised. Coloured Petri Nets on the other hand allow the modelling of repeated structures, by associating a colour with the enabling of transitions. Each transition and token can be associated with a colour label, causing the ring of transitions to now be dependent on the availability of tokens of particular colour in an input place for a change of marking. Each Petri Net marking should therefore identify the tokens available at each place in a coloured Petri Net, rather than simply the total token count at a place as in a basic Petri Net.
j Transitions (T): Transition T1 is an immediate
transition, and models the synchronisation between an incoming agent and the availability of a particular port and bu er. 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 bu er the incoming agent on an identi ed port. 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 ring of T3 corresponds to the time required for registration. We use a random variable to model this time, as it cannot be prede ned. The activation time for transition T4 represents the time required to notify existing agents of the presence of the cur-
3 PN model of the Meeting Design Pattern We generate a Petri Net for each service identi ed in section 1.1, corresponding to di erent operations involved in the Meeting pattern. These Petri Nets can then be combined together to model an agent system developed using Aglets. The Petri Nets are as follows:
PN for agent arrival and departure; PN for agent-host interaction; 4
0-7695-0001-3/99 $10.00 (c) 1999 IEEE
4
Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999 Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
a computation (i.e. execute an operation on another agent and obtain results of the requested operation). A marking M(p8) 1 indicates the end of an agentagent interaction.
rent one, and is dependent on the total number of agents to be noti ed. 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 requests1 and M0 (P 5) is always equal to 1. The initial marking M0 can be speci ed as:
T3
P4
P8
P5
P2
M0 = f0; connections; 0; 0; 1; 0; 0g
T2
T5
T4
T6
P3
! Arcs: The output arc (T4,P2) indicates that once
P7
an agent has been registered and its existence noti ed to other agents with which it is to interact, the connection can be released to allow another agent request on a port.
P6
Figure 4: Scenario 1: Agent-agent interaction Figure 5 illustrates the interaction between an agent and the host environment. We assume that an agent may perform computation directly on the host via the MeetingManager. The architecture of the host therefore becomes signi cant, for instance, whether the host contains multiple processors, multiple disks etc. We provide a generic model for this interaction here, but in a later paper, we intend to explore the speci cs of a host platform in detail. From gure 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. Placetransition 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). At present we model the computation performed at a host, or on another agent at the meeting point by a
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 or (iii) invoke a method on another agent via the AgletProxy. A token in place P1 initiates the operations performed by the PN. Transition T1 is a timed transition and models the delivery of a message between agents. If a multicast message needs to be sent, then the MeetingManager has to be invoked: places P2 and P3 are condition places which identify whether a multicast operation is sought, and also if the the MeetingManager is available to perform the operation respectively; as T2 is an immediate transition, it has a higher priority of ring over transition T1. The place-transition pair P4-T3 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 P5-T4 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 P6 indicates that a computation is required (i.e. the current agent wishes to invoke a method on another agent). The immediate transition T5 models this request, and res in preference to the timed transition T4. Transition T6 models the time to perform 1
T1
P1
identi ed as port 434 or 10434 in ATP [13]
5
0-7695-0001-3/99 $10.00 (c) 1999 IEEE
5
Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999 Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
A colour is also associated with place P5, to allow multiple MeetingMangers to be active at a host. This is relevant for scenarios where multiple, unrelated meetings may occur at the same host. In the limiting case where only a single MeetingManager exists, or multiple MeetingManagers may operate irrespective of token colour, we may label arc (P5,T3) with , indicating that transition T3 will now be enabled for any token colour, provided any MeetingManager is available.
single place-transition pair (such as P7-T6 in gure 5). However, it is possible to re ne these operations by increasing the granularity of services being modelled, either using more place-transition pairs within the same Petri Net or having a separate Petri Net for modelling computation, containing its own set of start and end places. Scenario 2: Multiple Agent Services per host: It is possible for multiple agent services to be active at a single host, involved in single or multiple meetings. Figure 6 identi es the extension of the PN model for a single agent service, assuming now that agent registry also involves identi cation of which agent service a particular agent is intended for. However, all agent services will listen to incoming agents on the same port, and with many agent services such a simple extension will lead to a very complex model. Multiple agent services would be modelled by associating time with each transition T1, using variable ring delays to identify an incoming agent.
Composition: To model an agent system we com-
bine the Petri Net blocks above to capture particular agent behaviour as speci ed in the Aglets source code. Hence, we combine an arrival Petri Net with an agent-agent or an agent-host Petri Net, depending on the requested operations. The use of start and end places allows us to cascade Petri Net blocks, with the end place of an arrival Petri Net feeding into the start place of an agent-agent or agent-host Petri Net. The end place of an agent-agent or an agent-host Petri Net is then fed back to the start place of either an agent-agent or an agent-host Petri Net if a repeated invocation is sought. Alternatively, the end place of an agent-host or an agent-agent Petri Net 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.
P5 P1 T1
T3
T2
P3
T4
P7
P6
P4
P2 T1 ’
T2 ’
P3 ’
T3 ’
P4 ’
T4 ’
3.1 An application example
P6 ’
A commonly employed example of the Meeting pattern is in a shopping scenario, where a number of agents come together at a site to bid in an auction. In such a scenario, the incoming agent may interact with other agents or with the local host to share data on prices or products. An incoming agent, in such an example may be described as:
Replicated for each agent type
Figure 6: Scenario 2: Arrival Petri Net We extend our PN model to a coloured PN for representing multiple agent services, as illustrated in gure 7. An incoming agent is now represented by a token, which also carries with it an identi er labelled to indicate its colour. Each agent service has a di erent colour, with the ring of transitions and the creation of tokens dependent on the colour of tokens present in the PN. From gure 7, each transition is enabled with respect to the token of its particular colour, and causes a token of the same colour to be added to the output place associated with it. Hence, transition T2 is enabled when token is present in place P3, and after a ring delay based on token colour, T2 places an output token in place P4. Using such a representation, we can model multiple agent services at a host in a similar way to a single agent service, with minor modi cations to our PNs. However, the complexity of simulating a coloured PN is greater, and scenario 1 is recommended whenever possible.
package agletbook; import aglet.*; public class Shopper extends Aglet { public void run() public void initialise() public void meeting() public void generateReport() private void Bid() private void dispatch() }
Once an aglet has been initialised, the run method is called on each host it visits. The PN block identi ed in gure 3 can be used to represent operations run() and initialise(). The meeting() method can correspond to either agent-host or agent-agent interaction, whereas the 6
0-7695-0001-3/99 $10.00 (c) 1999 IEEE
6
Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999 Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
generateReport() method can be modelled by a PN for performing computation. We may treat a computation and report generation identically in our example. The marking for condition places in PNs may be retrieved from the source code of methods in the aglets program. In this way, we can construct either a separate PN for each agent, or we may average values for a number of di erent agents and use these to representing times for transitions.
of tokens in these places is determined by external factors. We nd that all other places within this model are covered by P-invariants, i.e. the total number of tokens in a particular marking are maintained constant. The P-invariance property is self evident for place P5, whereas for the other places, the P-invariance suggests that only one agent can be registered at any one time with the Meeting Manager.
4 Analysis of Petri Net models
P3 is covered by a P-invariant, and no transition is covered by T-invariants. The latter indicates that a particular ring sequence S can be deduced from an initial marking Mk and S = qY (where q is a positive integer), such that executing S from marking Mk leads back to Mk . Consequently, the net is not structurally bounded.
Agent{agent interaction In this model only place
We consider the performance of the Arrival Petri Net illustrated in gure 3 in this section. We can then generalise our analysis to that of multiple agent services of scenario 2. As indicated previously, the presence of multiple agent services at a host can be modelled by replicating the Petri Net for each agent service, with the exception of place P2 which represents a port at a host platform. We used the GreatSPN and TimeNet Petri Nets simulators to verify our models, and obtain results on performance. All of our PN models are deadlock free, indicating that all transitions are potentially rable 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 Petri Net model of gure 3 is conservative with respect to the total number of tokens present.
Agent-host interaction In this Petri Net the only
place covered by P-invariant is P2. No transition is covered by T-invariant and the net is not structurally bounded. A characteristic of the Petri Nets of gures 4 and 5 is the choice between a timed and an immediate transition: (T1,T2) in gure 4 and (T3,T4) in gure 5. We performed some simulations to determine the total number of tokens that would accumulate in the Petri Nets depending on which of the two transitions was enabled for ring. This translates to deciding whether a single or multicast message has to be sent in an agentagent interaction, or whether a particular operation on a host has been granted in an agent-host interaction.
Incoming agents: In all the models illustrated in
Figure 8: Arrival Rate at P5 vs. Token Count in P6
section 3 the starting place represents an incoming agent: we added an external exponential transition to the input of the start place to generate tokens. Hence, agent arrival is modelled by an exponentially distributed random variable.
4.1 Structural properties and performance considerations
Arrival Petri Net of gure 3 shows the receiving
Figure 9: Arrival Rate at P5 vs. Token Count in P8
and registering of an incoming agent. We do not consider the start and end places P1 and P7, as the number
7
0-7695-0001-3/99 $10.00 (c) 1999 IEEE
7
Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999 Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
Figure 10: Arrival Rate at P5 vs. Token Count in P6
Figure 12: Arrival Rate at P5 vs. Token Count in P6
Figure 13: Arrival Rate at P5 vs. Token Count in P8 Figure 11: Arrival Rate at P5 vs. Token Count in P8
Conclusion and Future Extensions We provide an overview of the Meeting design pattern in this paper, outlining the sequence of steps required for stationary-mobile agents interaction at an agent site. We subsequently develop a Petri Net model of this interaction, and use it to determine bounds on performance for developing agent based systems. A shopping example is used to illustrate the utility of our scheme. Providing Petri Net blocks of design patterns in agent systems, such as Aglets, will allow automatic construction of mobile agent systems. Visual development environments may be used to put multiple patterns together, for automatic code generation, and also for deciding the best way to launch and control agents. We provide an overview of one particular design pattern in this paper, but our intention is to allow automatic construction of Petri Net blocks from design patterns provided in agent libraries. This paper provides a rst step in this direction, by identifying Petri Net 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 based system. The designer may experiment with di erent Petri Net 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 Petri Nets, and be combined with those for agent-agent and agent-host interaction. A great deal of literature already exists on modelling computer architectures, such as [2], and such results can be combined with our results to generate a versatile system for modelling. Perhaps the ultimate test of a modelling scheme is its
In gures 8 and 9 we model the presence of a token in place P5 of gure 5 as a parameter varying from 0.0 to 1.0. Transition T4 is assumed to have a unit delay, with a maximum of 50 agents allowed in the system at any time. We see that the token count in place P6 settles for values of arrival rate approaching 1.0 in place P5. Conversely, the number of tokens in place P8 decreases as the arrival rate in place P5 increases. We also consider a ring delay of 10 units on transition T4, as illustrated in gures 10 and 11. We nd in general that increasing the delay at transition T4 leads to longer settling times for the number of tokens in places P6 and P8, keeping all other factors constant. Similarly, on decreasing the delay at transition T4, we nd a faster settling of the number of tokens in places P6 and P8, as illustrated in gures 12 and 13, where the delay at transition T4 is 0.10 units, with arrival rate (determining settling times) varying from 0.0 to 1.0. These results suggest that the time to authenticate and perform an operation at a host site can impact the average agent count at a host, with agent count being stable towards lower times for computation. These results may be used to determine bottlenecks present within an agent-agent or agent-host environment, in order to better manage the total number of agents that could be allowed on an agent host at any one time. Also, we can deduce equilibrium conditions that lead to a stability in the total agent count, by varying the delays associated with particular transitions in our Petri Net models. 8
0-7695-0001-3/99 $10.00 (c) 1999 IEEE
8
Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999 Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
utility in particular real-world applications. We hope the work presented here may be useful in adding performance models to the Aglets framework, and allow application developers to perform what-if investigations on the code generated with Aglets libraries.
[11] IBM. The Aglets Software Development Kit. http://www.trl.ibm.co.jp/aglets, 1998. [12] 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. SpringerVerlag, Berlin, Germany, 1987. [13] D. Lange and Y. Aridor. Agent Transfer Protol/0.1. IBM Research Working Document, 1997. [14] T. Murata. Petri nets: Properties, analysis and applications. In Proceedings of the IEEE, April 1989. [15] ObjectSpace. Voyager: A Java based Mobile Agent System. http://www.objectspace.com/, 1998. [16] M. Ranganathan, A. Acharya, S. Sharma, and J. Saltz. Network-aware Mobile Programs. Proceedings: USENIX Technical Conference, pages 91{104, 1997. [17] D. Rus, R. Gray, and D. Kotz. Transportable Information Agents. Journal of Intelligent Information Systems, 9:215{238, 1997. [18] M. Stasser, J. Baumann, and F. Hohl. Mole - A Java Based Mobile Agent System. 2nd ECOOP Workshop: Mobile Object Systems, 1996. [19] J. White. Mobile Agents White Paper. General Magic Inc., 1996.
References [1] M. Ajmone Marsan, G. Balbo, and G. Conte. A class of generalized stochastic petri nets for the performance evaluation of multiprocessor systems. ACM Transaction on Computer Systems, 2(2):93{ 122, May 1984. [2] M. Ajmone Marsan, G. Balbo, and G. Conte. Performance Models of Multiprocessor Systems. MIT Press, 1986. [3] B. Appleton. Patterns and Software: Essential Concepts and Terminology. 1997. [4] 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. [5] G. Chiola, G. Franceschinis, R. Gaeta, and M. Ribaudo. GreatSPN2.0. Dipartimento di Informatica, Universita di Torino (Italy), 1997. [6] G. Di Marzo, M. Muhugusa, C. Tschudin, and J. Harms. The Messenger Paradigm and its Implications on Distributed Systems. Workshop: Intelligent Computer Communication, 1995. [7] 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. [8] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design patterns : Abstraction and reuse of object-oriented design. In ECOOP. Kaiserslautern, Germany, 1993. [9] R. German, C. Kelling, A. Zimmermann, and G. Hommel. TimeNET - A Toolkit for Evaluating Non-Markovian Stochastic Petri Nets. Technische Universitat Berlin - Real-Timr System and Robotics, Franklinstr. 28/29, 10587 Berlin, F. R. Germany. [10] R. Gray. Agent Tcl: A transportable agent system. Proceedings: 4th annual Tcl/Tk Workshop, Monterey, Ca, 1996. 9
0-7695-0001-3/99 $10.00 (c) 1999 IEEE
9
Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999 Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
P5 P1 T1
T2
T3
P3
P7
T4
P4
P6
P2
Figure 3: Scenario 1: Arrival Petri Net
P5 Computation on host P1
T1
T2
P3
T3
P6
P4
T5
P8
P7
T7
P9
T6
T4
P2
Figure 5: Scenario 1: Agent-host interaction
P5 P1
T1
T2 P3
T3
T4
P4
P6
P7
P2
Figure 7: Scenario 2: Using a coloured Petri Net
10
0-7695-0001-3/99 $10.00 (c) 1999 IEEE
10
