Programming the Mobility Behaviour of Agents by ... - CiteSeerX

0 downloads 0 Views 170KB Size Report
transition rules and provide examples of itineraries for meeting scheduling, sales order processing, and network modelling. 1 Introduction. Mobile agents can be ...
Programming the Mobility Behaviour of Agents by Composing Itineraries Seng Wai Loke1 , Heinz Schmidt2 , Arkady Zaslavsky2 1

CRC for Enterprise Distributed Systems Technology School of Computer Science and Software Engineering Monash University, Caulfield VIC 3145, Australia [email protected], [email protected], [email protected] 2

Abstract. We present an algebra for programming the itineraries of mobile agents. The algebra contains operators for modelling sequential, parallel, nondeterministic, and conditional mobility behaviour. Iterative behaviour is also modelled by a language of regular itineraries borrowing ideas from regular expressions. We give an operational semantics for the operators using Plotkin-style transition rules and provide examples of itineraries for meeting scheduling, sales order processing, and network modelling.

1 Introduction Mobile agents can be regarded as software components which can move from one host to another to perform computations. Mobile agents have many benefits for distributed computing such as reducing network load by moving computation to data and asynchronous computation [5]. With the growing popularity of the mobile agent paradigm (e.g., [12, 10]) and the increasing ubiquity of networked computers, we envision future mobile agent applications involving complex movements of agents over large scale environments with hundreds or thousands of nodes within and between enterprises and homes. Programming the mobility behaviour of these agents would be a challenge. Recent work such as Java-based Moderator Templates (JMTs) [7] which enable agent itineraries or plans to be composed and coordination patterns [13] provide abstractions for the mobility behaviour of agents. This paper aims to take such work further by providing an algebra of itineraries for reasoning with and programming the mobility behaviour of mobile agents. The goals of this language are fourfold: – Encourage separation of concerns to simplify mobile agent programming. The mobility aspect of a group of agents are abstracted away from code details implementing the computations the agents are to perform on hosts. Herein lies a similarity between our approach to mobile agent programming and the emerging paradigm of aspect-oriented programming (AOP) [4]. – Provide top-level structuring of a mobile agent application. – Provide economy of expression of mobility behaviour. The programmer expresses behaviour such as “move agent A to place p and perform action a” in a simple direct succinct manner without the clutter of the syntax of a full programming language.

– Facilitate identification and reuse of patterns in mobility behaviour. The rest of this paper is organized as follows. In x2, we describe the mobile agent model on which our work is based. In x3, we describe the syntax and operational semantics of agent itineraries, and discuss two example itineraries. In x4, we discuss allowing the destination of agents to be dynamically determined by operations, and give an itinerary for network modelling as example. In x5, we present related work and conclude in x6.

2 Mobile Agent Model A mobile agent architecture consists of agents and places. A place receives agents and is an environment where an agent executes. A place has an address which we call a place address. Typically, as in many agent libraries, a place is a server which can be addressed using a hostname and a port number (e.g., www.dstc.edu.au:888). We use an object-oriented model of agents. We assume that an agent is an instance of a class, and roughly, we define a mobile agent as follows: mobile agent = state + action + mobility State refers to an agent’s state (values of instance variables) possibly including a reflection of the agent’s context. Action refers to operations the agent performs to change its state or that of its context. Mobility comprises all operations modifying an agent’s location, including moving its state and code to other than the current location. While mobility assumes that an agent moves at the agent’s own volition, the itineraries may be viewed as a specification or plan of agent movements. A community of agents is considered to implement the movement plan correctly, if their observed behaviour corresponds to (i.e., “simulates”) the plan. This links our calculus with other more general calculi for concurrent objects, such as the pi-calculus. We assume that the agents have the capability of cloning, that is, creating copies of themselves with the same state and code. We also assume that agents can communicate to synchronize their movements, and an agent’s code is runnable in each place it visits.

3 An Algebra of Itineraries

A

O

P

and Let f0;1g (where f0; 1g denotes strings of zero or more zeroes or ones), be finite sets of agent, action and place symbols, respectively. In expressions we use letters A; B; C; : : : 2 f0;1g , a; b; c; : : : 2 and p; q; r; : : : 2 . Also, we use the following convention for generating names for agents and their clones. When an agent A is cloned, agent A is renamed A0 and its clone is named A1 . Similarly, when A0 is cloned, we have (A0 )0 (or A00 ) and (A0 )1 (or A01 ), and for A1 , we have A10 and A11 , and so on. More generally, to any A 2 f0;1g , we add superscripts 0 and 1 to form A0 and A1 . Note that with this convention, the name of the original agent is in f0g . For example, A000 and B 000 denote original agents.

A

O

A

P

A

Itineraries (denoted by I ) are now formed as follows representing the null activity, atomic activity, parallel, sequential, nondeterministic, conditional nondeterministic behaviour, and have the following syntax:

I ::= 0 j Aap j Aal j (I k I ) j (I  I ) j (I j I ) j (I : I ) where A 2 A 0;1 , a 2 O, p 2 P, PO  P ! P is a set of placement operations described in x4, l 2 LPO which is the language of regular itineraries described in x4,  is an operator which combines an agent with its clone to form a new agent, and  is 

f

g

an operator which returns a boolean value to model conditional behaviour. Whenever  and  are not part of current dicussions, for simplicity, we write “” and “:”. Below, we give an operational semantics to the above operators. 3.1 Operational Semantics

We first define ags(I ) to mean the set of agents (symbols) occurring in the itinerary I . ags(I ) is defined inductively as the minimal subset of f0;1g satisfying: ags( ) = ;, ags(Aap ) = fAg, ags(Aal ) = fAg, ags(I  J ) = ags(I ) [ ags(J ), ags(I k J ) = ags(I ) [ ags(J ), ags(I j J ) = ags(I ) [ ags(J ), and ags(I : J ) = ags(I ) [ ags(J ). We also define configuration which is a relation involving agents, actions and places, denoted by  (and by  0 ,  00 : : : ), where   f0;1g   . Given a collection of agents, the configuration represents the location and action of each agent. A constraint on a configuration is that it defines a function from f0;1g to , the same agent cannot be in two places in the same configuration. The operational semantics is given by Plotkin-style rules defining transitions from premises [condition]. Declaratively, the conone configuration to another of the form conclusion clusion holds if the premises and condition hold. Procedurally, to establish the conclusion, establish the premises and then check that condition holds. We write  ? !I  0 to mean an itinerary I causes a transition from configuration  to configuration  0 . We assume that all agents in an itinerary have a starting place (which we call the agent’s home) denoted by h 2 . Given a collection of agents Agts, we define a distinguished configuration called the home configuration denoted by hAgts . The home configuration is the configuration where all the agents are at home. For example, the home configuration for a collection of agents A; B and C is:

A

A

A

0

O P P

P

f(A; id; h); (B; id; h); (C; id; h)g Note that the operations at home are the identity action id 2 O. Also, all agents used in

an itinerary must be mentioned in the home configuration, i.e. none of the rules which follows can add new agents unless they are clones of existing agents. Agent Movement (Aap ). Aap means “move agent A to place p and perform action a”. This expression is the smallest granularity mobility abstraction. It involves one agent, one move and one action at the destination. The underlying mobility mechanisms are hidden. So are the details of the action which may change the agent state or the context in which it is operating at the destination place:

a : states(A)  states(p) ! states(A)  states(p)

In our agent model, each action is a method call of the class implementing A. The implementation must check that a is indeed implemented in A. represents, for any agent A, the empty itinerary Aid here , where the agent performs the identity operation id 2 on the state at its current place here. The transition rule for agent movement replaces a triple from a configuration  :

0

O

Aa

(1)

p  ??! ( n f(A; b; q )g) [ f(A; a; p)g

For example, applying this rule to the home configuration with the expression Aap gives a new configuration with only the location and action of A changed: Aap

f(A; id; h); (B; id; h); (C; id; h)g ??! f(A; a; p); (B; id; h); (C; id; h)g Parallel Composition (“k”). Two expressions composed by “k” are executed in parallel. For instance, (Aap k Bqb ) means that agents A and B are executed concurrently. Parallelism may imply cloning of agents. For instance, to execute the expression (Aap k Abq ), where p = 6 q, cloning is needed since agent A has to perform actions at both p and q in parallel. In the case where p = q , the agents are cloned as if p = 6 q. In general, given an itinerary (I k J ) the agents in ags(I ) \ ags(J ) are cloned and although having the same name are different agents. In the transition rule below, we show how clones are distinguished for the purposes of specifying the operational semantics. Before presenting the rule, given Agts  f0;1g and a configuration  , we define the operator “?” which removes triples mentioned in Agts from  :

A

 ? Agts =  n f(A; a; p) j A 2 Agts; (A; a; p) 2  g

The transition rule for parallel composition is as follows:

renamed (I ) renamed (J ) renamed0 ( ) ????????!  ^ renamed1( ) ????????!  IJ  ??!  [  0

1

0

k

0

00

(2)

00

renamed0 ( ) is  without the triples concerning agents in ags(J ) and with agents in ags(I ) \ ags(J ) renamed: renamed0 ( ) = ( ? ags(J )) [ f(A0 ; a; p) j A 2 (ags(I ) \ ags(J )); (A; a; p) 2  g. Similarly, renamed1 ( ) = ( ? ags(I )) [ f(A1 ; a; p) j A 2 (ags(I ) \ ags(J )); (A; a; p) 2  g. This means that agents to be cloned (i.e. those mentioned in ags(I ) \ ags(J )) and

clones are renamed apart. With the naming of clones, when the resulting configurations are combined in  0 [  00 , the clones retain their identities. We use renamed0 (I ) to denote the corresponding renaming of I (defined recursively on the algebra): renamed0 ( ) = , renamed0 (Aap ) = A0p a if A 2 ags(I ) \ ags(J ), renamed0 (Aap ) = Aap if A 62 ags(I ) \ ags(J ), renamed0 (Aal ) = A0l a if A 2 ags(I ) \ ags(J ), renamed0 (Aal ) = Aal if A 62 ags(I ) \ ags(J ), renamed0 (I  J ) = renamed0 (I )  renamed0 (J ), renamed0 (I k J ) = renamed0 (I ) k renamed0 (J ), renamed0 (I j J ) = renamed0 (I ) j renamed0 (J ), and renamed0 (I : J ) = renamed0 (I ) : renamed0 (J ). renamed1 is defined similarly. Parallel composition splits the configuration  into renamed0 ( ) and renamed1 ( ) each acted on separately by I and J respectively. An example illustrates this.

0

0

f(A; a; p); (B; b; q); (C; c; r); (D; d; s)g, I = Aet  Bvg , and J = = f(A ; a; p); (B; b; q ); (D; d; s)g, renamed ( ) = f(A ; a; p); (C; c; r); (D; d; s)g, renamed (I ) = At e  Bvg , and renamed (J ) = Au f  Cwh . And so,  = f(A ; e; t); (B; g; v); (D; d; s)g and  = f(A ; f; u); (C; h; w); (D; d; s)g (by the semantics of “” given below). The resulting configuration is  [  = f(A ; e; t); (A ; f; u); (B; g; v ); (C; h; w); (D; d; s)g Let



=

Afu  Cwh . Then, renamed0 ( ) 1 1

0

1

0

0

1

0

0

00

1

0

0

00

1

which contains A and its clone A . In the next operator, combining of clones is carried out. 0

1

Sequential Composition (“”). Two expressions composed by the operator “ ” are executed sequentially. For example, (Aap  Abq ) means move agent A to place p to perform action a and then to place q to perform action b. Sequential composition is used when order of execution matters. In the example, state changes to the agent from performing a at p must take place before the agent goes to q . Sequential composition imposes synchronization among agents. For example, in the expression (Aap k Bqb )  Crc the composite action (Aap k Bqb ) must complete before Crc starts. Implementation of such synchronization requires message-passing between agents at different places or via shared memory abstractions. When cloning has occurred, sequential composition performs decloning, i.e. clones are combined. For example, given the expression (Ads k Aet )  Afu and suppose that after the parallel operation, the configuration has clones. Then, decloning is carried out before continuing with Afu . The transition rule for sequential composition is:

I  ^ decloned( ) ?! J   ?! J   ?I?! 0

0



00

(3)

00

where decloned( 0 ) is the configuration  0 with all clones substituted by their combinations. We now define decloned. When two clones Ax0 and Ax1 , for some x 2 f0; 1g, are combined, we name the combined agent Ax . We denote the combination operation by  : ( f0;1g  f0;1g ) ! f0;1g . The semantics of , i.e. how the states and code of the clones are combined is left to the implementation. Also, the place where an agent is combined with its clone is the agent’s place. The clone which is not at that location will move to that location before combination takes place. For example, when combining Ax0 and Ax1 , Ax resides at Ax0 ’s place and Ax1 must move to that place before the combination takes place. Let  and  0 be configurations such that decloned( ) =  0 . Then  0 is computed by the following algorithm where, in each iteration, two clones are replaced by their combination until no combinations are possible:

A

A

A

1. If there exists (Ax0 ; a; p); (Ax1 ; b; q ) 2  , for some x 2 f0; 1g, then (2), else  0 :=  (finish). 2. Modify  :  := ( n f(Ax0 ; a; p); (Ax1 ; b; q )g) [ f(Ax ; id; p)g where Ax = Ax0  Ax1 . Go to (1).

For example, decloning the configuration f(A0 ; a; p); (A10 ; b; q ); (A11 ; c; r); (B; d; s)g gives the following result after the first iteration: f(A0 ; a; p); (A1 ; id; q ); (B; d; s)g and

after the second (final) iteration, we have: f(A; id; p); (B; d; s)g. The combined agent has the identity operation id at p. We can associate the operator “” with “” by writing “ ”. In the expression (Ads k Aet )Afu , cloning could take place at the following destination u. However, in other expressions such as (Ads k Aet )  (Afu k Agv ) there are two possible destinations u and v . Also, note that since the clones have the same names at this level (they are given distinguished names only for the purposes of specifying their operational semantics), it is also unclear from the expression which agent (the original or its clone) goes to u or to v . Our operational semantics solves this ambiguity by viewing the above expression as causing a cloning (in the first parallel composition), a combination (in the sequential composition), and another cloning (in the second parallel composition). Independent Nondeterminism (“j”). An itinerary of the form ( I j J ) is used to express nondeterministic choice: “I don’t care which but perform one of I or J ”. If ags(I ) \ ags(J ) 6= ;, no clones are assumed, i.e. I and J are treated independently. It is an implementation decision whether to perform both actions concurrently terminating when either one succeeds (which might involve cloning but clones are destroyed once a result is obtained), or trying one at a time (in which case order may matter). Two transition rules are used to represent the nondeterminism:

I   ?! J  ?I?! 

J   ?! J  ?I?! 

0

j

These rules show that I

00

(4a)

j

0

(4b) 00

j J leads to one of two possible configurations.

Conditional Nondeterminism (“:”). Independent nondeterminism does not specify any dependencies between its alternatives. We introduce conditional nondeterminism which is similar to short-circuit evaluation of boolean expressions in programming languages such as C. We first introduce status flags and global state function: – A status flag is always part of the agent’s (say, A’s) state, written as A:status. Being part of the state, A:status is affected by an agent’s actions. A:status might change as the agent performs actions at different places. – A global state function  : }( f0;1g   ) ! ftrue; falseg maps a configuration to a boolean value.  need not be defined in terms of status flags but it is useful to do so. For example, we can define  as the conjunction of the status flags of agents in a configuration  :  ( ) = (A;a;p)2 A:status We can view  as producing a global status flag. From the implementation viewpoint, if a configuration involves more than one agent, these agents must communicate to compute  .

A

O P V

The semantics of conditional nondeterminism depends on some given  in the way described above. We express this dependency of “:” on a  by writing “: ”. The transition rule for “ : ” is as follows:

I  ^ decloned( ) ?! J  I   ?!  ?! [ ( ) = true] (5a) [ ( ) = false] (5b) I : J : J  ???!   ?I??!  0

0

0

0

0

00

00

0

Rule (5b) is similar to rule (3). Note that we can introduce variations of “:” with different global state functions such as “: ” and “: 0 ”, and similarly with “”: “ ” and “0 ”. The operational semantics of the operators and how  and  are used is specified as above (and so, applicationindependent), but definitions for  and  are application-specific.

Given the above rules, an itinerary I , a set of agents ags(I ), and home configuration  0 (i.e. computing  0 ) will form a derivation tree whose root is that conclusion, whose internal nodes are derived using the above rules and whose leaves are empty.

I hags(I ) , establishing the conclusion hags(I ) ?!

Algebraic Properties of Itineraries. Due to space limitations, we will not discuss the algebraic properties of the operators in detail in this paper but state without proof the following properties used in our examples: – associativity: from the above definitions, sequential, parallel and both nondeterministic compositions are associative, i.e. for example, I  (J  K ) = (I  J )  K . Note that with parallel composition, starting with the same configuration  , if I k (J k K ) brings  to  0 and (I k J ) k K brings  to  00 , then  0 is same as  00 , except for naming of clones (e.g.,  0 contains A0 , A10 and A11 , and  00 contains A00 , A01 and A1 ). Associativity lets us leave some brackets out in composite expressions. – distributivity of “” over “j”: (I j J )  K = (I  K ) j (J  K ) 3.2 Two Examples Meeting Scheduling. We use a two phase process for demonstration purposes: (1) Starting from home, the meeting initiator sends an agent which goes from one participant to another with a list of nominated times. As each participant marks the times they are not available, the list of nominated times held by the agent shortens as the agent travels from place to place. After visiting all places in its itinerary, the agent returns home. (2) At home, the meeting initiator selects a meeting time from the remaining unmarked times and informs the rest. With four participants (excluding the initiator), the mobility behaviour is given by:

ask ask ask finalize  (Ainform k Ainform k Ainform k Ainform ) Aask p  A q  Ar  As  Ah p q r s ask is an action which displays unmarked nominated times to a participant and allows a participant to mark times he/she is unavailable. finalize allows the meeting initiator to select a meeting time from the remaining unmarked times, and inform presents the selected meeting time to a participant. Note that the expression of mobility is separated from the coding of these three actions.

Sales Order Processing. We consider a scenario adapted from [9] for processing sales orders in a virtual enterprise. Each sales order is carried o ut by a mobile agent which moves through several entities to process the order. We first name the entities. Let us sc be a place where the agent can interact with the US stock control, asia sc be a place where the agent can interact with the Asian stock control, mat be a place where the agent can purchase raw materials for manufacturing the products requested in a sales order,

man be the place where the agent can place an order for products to be manufactured (i.e., man represents the manufacturer), and ext be a place where the agent can interact with an external buyer. Also, let query be an action where the agent queries a stock control, report be an action where the agent reports the results of a completed sales order, buy raw be the action of purchasing raw materials, buy prod be the action of buying products for a sales order, and order be an action of placing an order to have some products manufactured. The business logic for processing a sales order is as follows. The agent first receives an order while at home. Then, one of the following takes place. 1. The agent checks with the US stock control to see if the requested products are available. If so, the agent returns home reporting this. We can represent this behaviour report . as Aquery us sc  Ah 2. Otherwise, the agent checks with the Asian stock control, and if the requested products are available, reports this at home. This behaviour is captured by Aquery asia sc  . Areport h 3. If the Asian stock control does not have the products available, the agent purchases raw materials for manufacturing the product and places an order for the product with the manufacturer. Thereafter, the agent reports what it has done at home. We buy raw  Aorder  Areport . write this behaviour as Amat man h 4. Alternatively, if the agent cannot fulfill (3), for example, the raw materials are too expensive. The agent buys the products from an external buyer and reports this: prod  Areport . Abuy ext h In essence, there are four ways to process a sales order and we just want to perform one of them (each in the sense described above). We can capture the essence of the business logic as follows: query report ) j (Aquery  Areport ) j (Abuy raw  Aorder  Areport ) j (Abuy prod  Areport ) (Aus sc  Ah man mat ext asia sc h h h query buy raw  Aorder ) j Abuy prod )  Areport query = (Aus sc j Aasia sc j (Amat man ext h (by distribution of  over j)

However, the above itinerary does not model the fact that the four ways of processing a sales order are tried sequentially and the next way is used only when one way has “failed” (e.g., if the product is not in stock, then get it manufactured). Using conditional nondeterminism, the sales order agent’s behaviour is:

query buy raw  Aorder ) : Abuy prod )  Areport Aquery us sc : Aasia sc : (Amat man  ext h

(

This more precisely models the business logic. The operator is non-deterministic in the sense that the resulting configuration of an operation I : J is either decided by (5a) or (5b). However, the decision of which rule depends on  . For example, assuming we use the definition of  in x3.1 which is in terms of status flags, if no stock is available at us sc, then, A:status would be set to false. Note that it is left to actions of A to properly set A:status to reflect the intended purpose of the application.

4 Regular Itineraries So far, the place p in Aap is assumed to be a constant. This section replaces p with computed destinations and introduces iterative behaviour produced by repeatedly applying the same computation to an agent’s current location.

P

Placement Operation. Given a set of place symbols, we define a partial function o : ! which maps a place to another which we call a placement operation. For some places, o is undefined, i.e. returns ?, and always o(?) = ?. In place of a place constant, we can write a placement operation. Aao denotes “move agent A to the place obtained by applying o to A’s current position”:

P P

a

o ( n f(A; b; p)g) [ f(A; a; o(p))g  ?A?!

o p 6 ?]

[ ( )=

(1’a)

0

In case o(p) = ?, we define Aa? as the empty itinerary , i.e. the agent A does nothing and stays at its current position:

a

o ( n f(A; b; p)g) [ f(A; id; p)g  ?A?!

op

[ ( )=

?]

(1’b)

We consider A:here denoting agent A’s current location as part of the agent’s state like A:status. This permits the agent to record its own location for its own use in its actions. For example, given the current configuration f(A; d; s); (A1 ; e; t); (B; b; q); (C; c; r)g, A:here = s, A1 :here = t, B:here = q, C:here = r. Note that the value of A:here for any agent A might be changed by itineraries involving A but always has the initial value of h. We do not specify how o computes its value which is application-specific, but note that evaluation of o occurs at the agent’s current location. Placement operations are intended for capturing the idea that the agent’s destination could be dynamically computed at run-time rather than declared statically as in the previous section. Itineraries involving mix of place symbols and placement operations is admitted, such as Aap  Aao , which moves agent A to p and then to o(p). We also define operators to allow placement operations to be combined. The operators are similar to those in regular expressions as we show below.

PO

P

P

Placement Language. Let  ( ! ) be a set of placement operations. We define a placement language LPO representing combinations of placement operations in as follows. The members of a placement language are called regular itineraries. Let l1 ; l2 2 LPO . Then  LPO , i.e. LPO contains all placement operations in , (l1 k l2 ) 2 LPO , (l1  l2 ) 2 LPO , (l1 j l2 ) 2 LPO , (l1 : l2 ) 2 LPO , l1 n 2 LPO , l1  2 LPO , and no other strings are in LPO . The semantics of the above operators for placement operations are induced by that for the operators for itineraries. Also, we always apply the regular itineraries on A:here. Let l1 ; l2 2 LPO , A 2 , a 2 . Then, Aal1 kl2 = Aal1 k Aal2 , Aal1 l2 = Aal1  Aal2 , Aal1 jl2 = Aal1 j Aal2 , Aal1 :l2 = Aal1 : Aal2 , and Aal1 n = Aal  : : :  l .

PO PO

PO

A

O

| {z } 1

1

n times

f n (x) be n repeated applications of function f on x (e.g., f 3 (x) = (f:f:f )(x) = f (f (f (x))), where “:” is function composition), l 2 LPO be some sequential composition of placement operations (i.e., l = o1  o2  : : : ok , where k 2 Z+ and oi 2 PO for 1  i  k), and rew(l) be a rewriting of l in reversea by replacing “” with “:” (e.g. rew(o1  o2  o3 ) = o3 :o2 :o1 ). Then, we define Al as Also, let



Aal



=

Aal  : : :  l , where n is the smallest integer such that rew(l)(n+1) (x) = ?, and

| {z } n times

x is the current location of A just before the start of the operation Aal . For example, if the current location of A is p, l = o1  o2 , o2 (o1 (p)) 6= ?, o2 (o1 (o2 (o1 (p)))) 6= ? and o2 (o1 (o2 (o1 (o2 (o1 (p)))))) = ?, then rew(l) = o2 :o1 , and (o2 :o1 )3 (p) = ?, and so, Aal = Aa(o1 o2 ) (o1 o2 ) . If there is no such n, we define Aal = 0. In addition, we define Aal = 0 for l not a sequential composition of placement operations since expressions like (o1 k o2 )(p) are not defined as functions over P, though we have lifted sequential composition to function composition using rew. We can think of ln and l as iterators over the places obtained from repeatedly applying l. 













An Example: Network Modelling. In [14], mobile agents are applied to network modelling, where the agent visits a collection of nodes identifying those nodes satisfying some criteria (e.g., host with CPU utilization > 90% and has less than 1GB of disk space). The agent which is injected into the network carries a pre-configured itinerary describing a traversal of a collection of nodes. Let be the collection of nodes (places), next : ! be the placement operation which given a node returns the next node in the traversal, A be the agent, and test be the action performed by the agent on a node to determine if the node satisfies a specified criteria. Nodes passing the test are recorded by the agent. The last node plast in the traversal is modelled by next(plast ) = ?. We send the agent home after it has completed its traversal which reports its results via the operation report. The agent’s report itinerary is represented by: Atest next  Ahome . We can extend the above itinerary so that the agent traverses three different domains, each domain a collection of nodes, and two adjacent domains connected by a gateway node. Let , , be the collection of nodes (places) in each domain, nextP : ! , nextQ : ! , nextR : ! be placement operations for each respective domain, pq be the gateway node between domains P and Q and qr be the gateway node between domains Q and R, and sec be an action where the agent requests permission to cross into another domain. Then, the agent’s extended itinerary is as follows:

P

P P

PQR Q Q

R

P P

R

report sec test sec test Atest nextP  Apq  AnextQ  Aqr  AnextR  Ah 





5 Related Work In many Java mobile agent toolkits such as IBM Aglets [7], a sequential itinerary can be defined as a separate object, where each element of the itinerary is a pair: (place address, method call). Such itineraries can be defined using our “” operator. Emerging work attempts to provide further aid for programming more complex agent itineraries. For example, JMTs mentioned in x1 enable agent itineraries or plans to be composed where the plans may involve parallelism, cloning and combining of clones. We contend that our itineraries provide greater economy of expression for representing mobility behaviour. Moreover, although we have adopted an object-based agent model, our itineraries are programming language independent - actions could have been written in C, say. However, JMT would provide a convenient platform for implementing our itineraries with Java.

The coordination patterns for information agents described in [13] have more details about how they are to be used but are presented less formally than our itineraries. Finite state machines (FSMs) are used to represent agent itineraries in [6]. Each state of the machine represents a task which is either some computation at a place or a movement to another place. Sequential and nondeterministic dependencies between tasks are expressed conveniently with FSMs. In [2], interaction diagrams are used to represent agent mobility behaviour, vertical lines represent places and arrows between these lines represent movements of agents between places. Such a visual notation is highly appealing for non-programmers. In the PLANGENT mobile agent system [8], plans are dynamically created from rules expressed in the declarative KIF language. Their advantage is dynamic planning but the plans are sequences of tasks: parallelism is not expressed. In contrast to these techniques, we give a formal and compositional approach to itineraries. The Pict language [11] derived from the Pi-Calculus and the Join-Calculus language [3] derived from a variant of the Pi-Calculus both contain a parallel composition operator for concurrently executing processes. However, Pict does not have the concept of agent places - where processes execute is not explicit. Join-Calculus has the concept of addressable locations corresponding to agent places. The locations are themselves mobile and have embedded code, and so, locations also correspond to mobile agents. However, an individual agent view of mobility is employed: a location’s code contains a primitive go(address) which moves the location itself to another location at address. In contrast, our itineraries take a top-level (“God-view”) of mobile agents where mobility is expressed outside of the agent’s actions. Moreover, Join-Calculus does not have implicit cloning. The ambient calculus [1] focuses on movements across administrative domains and boundaries. An ambient is a named location which may contain processes or subambients. Ambient’s capabilities are moving inside or outside other ambients, and removing the boundary of an ambient exposing its contents. There are operators for replicating and parallel composition of processes and ambients. In contrast to the ambient calculus, our algebra focuses on itineraries of movements. We have assumed a flat space of places (modelled simply as a set ). We could explore a more structured space of places by modelling as an ambient with subambients.

P

P

6 Conclusion We have presented an algebra of itineraries for programming the mobility aspect of agents, and illustrated our operators via examples in three scenarios: meeting scheduling, sales order processing and network modelling. We are exploring templates for itinerary reuse, and extensions to atomic movement (given in x3): (1) When an agent moves from p to q, it goes from p to a mediator place s and then to q. The advantage of this is greater fault tolerance and allowance for mobile places: the agent can wait at s for q to reconnect to s. Similarly, we can also model domain crossings if the mediator place is a gateway. (2) Optimise bandwidth usage by first moving the agent’s state over to the destination, and then, only transfer the code if the agent’s code for actions is not already available at the destination. If places run on small devices such as PDAs, a further optimization

is not to send the entire agent’s code but only code required for the specified action. (3) Generalize our place-level units to domain level units each consisting of an agent group - a collection of mobile agents perhaps with a leader agent, a domain - an Intranet consisting of a network of places, and a domain action - not a method call but refers to the agent group’s action in the domain. For instance, in the following expression, an agent group G moves sequentially through domains P , Q, and R collecting the information all  Gcol all  Gcol all . from each domain: Gcol P Q R Acknowledgements. The work reported in this paper has been funded in part by the Cooperative Research Centre Program through the Department of Industry, Science & Tourism of the Commonwealth Government of Australia.

References 1. L. Cardelli and A.D. Gordon. Mobile Ambients. LNCS, 1378, 1998. 2. B. Falchuk and A. Karmouch. Visual Modeling for Agent-Based Applications. Computer, 31(12):31–38, December 1998. 3. C. Fournet and L. Maranget. The Join-Calculus Language Release 1.04: Documentation and User’s Manual. Available from , January 1999. 4. G. Kiczales. Aspect Oriented Programming. ACM SIGPLAN Notices, 32(10):162–162, October 1997. 5. D.B. Lange and M. Oshima. Seven Good Reasons for Mobile Agents. CACM, 42(3):88–89, March 1999. 6. R.P. Lentini, G.P. Rao, and J.N. Thies. Agent Itineraries. Dr. Dobb’s Journal of Software Tools, 24(5):60, 62, 64, 66, 68, 70, May 1999. 7. K. Minami and T. Suzuki. JMT (Java-Based Moderator Templates) for Multi-Agent Planning. In OOPSLA’97 Workshop: Java-based Paradigms for Agent Facilities, 1997. Available at . 8. A. Ohsuga, Y. Nagai, Y. Irie, M. Hattori, and S. Honiden. PLANGENT: An Approach to Making Mobile Agents Intelligent. IEEE Internet Computing, 1(4):50–57, 1997. 9. T. Papaioannou and J. Edwards. Manufacturing System Performance and Agility: Can Mobile Agents Help? Special Issue of Integrated Computer-Aided Engineering (to appear), 1999. Available at . 10. T. Papaioannou and N. Minar, editors. Workshop on Mobile Agents in the Context of Competition and Co-operation at Agents’99, May 1999. Available at . 11. B.C. Pierce and D.N. Turner. Pict: A Programming Language Based on the Pi-Calculus. Technical Report CSCI 476, Computer Science Department, Indiana University, 1997. To appear in Proof, Language and Interaction: Essays in Honour of Robin Milner, Gordon Plotkin, Colin Stirling, and Mads Tofte, editors, MIT Press, 1999. 12. K. Rothermel and F. Hohl, editors. MA ’98: Proceedings of the 2nd International Workshop on Mobile Agents, number 1477 in LNCS. Springer-Verlag, September 1998. 13. R. Tolksdorf. Coordination Patterns of Mobile Information Agents. Cooperative Information Agents II, LNCS 1435, pages 246–261, 1998. Available at . 14. T. White, B. Pagurek, and A. Bieszczad. Network Modeling for Management Applications Using Intelligent Mobile Agents. Journal of Network and Systems Management - Special Issue on Mobile Agents (to appear), September 1999. Available at .

Suggest Documents