Using Reprogrammable Coordination Media as Mobile Agent

Using Reprogrammable Coordination Media as Mobile Agent Execution Environments Tim Coninx, Tom Holvoet, and Yolande Berbers Katholieke Universiteit Leuven Dept. of Computer Science Celestijnenlaan 200A 3001 Leuven, Belgium {tim.coninx|tom.holvoet|yolande.berbers}@cs.kuleuven.ac.be http://www.cs.kuleuven.ac.be/˜tim/MOS/

Abstract. In this paper, we propose to design a mobile agent execution environment, based on the bare coordination media. To do this, we discuss two ways to enhance a coordination medium. First, we introduce a way to add system specific non-functional behaviour (such as performance, security) to the medium, in order to add dynamism to the otherwise fixed coordination laws. Our current research focuses on reprogrammable coordination media by means of a reflexive architecture. Second, we discuss ways to add mobility to the coordination medium by introducing the concept of federation. We use federation and normal OO referencing to distinguish different kinds of mobility in coordination media. After clarifying our view on coordination media, we describe and discuss a Meta-Object Protocol (MOP) that fulfils a set of requirements for making these coordination media reprogrammable. Next, we show how the different “flavours” of mobility can be introduced. We implemented all this on our object space prototype, CO3 PS . Keywords: mobile agents, non-functional properties of coordination, meta object protocols, CO3 PS

1

Introduction

Mobile agents today gain more interest as both research and industry embrace the technology as a new design paradigm for the development of distributed software. Among others, the problem of accessing and integrating heterogeneous services is well met by mobile agent (MA) systems. There is a common ground for mobile agents, that says[7] that the most elegant way of coordinating agents’ actions is making use of a time and location uncoupled coordination medium. When many different agents gather on a certain site, there is an a priori absence of knowledge about communicating parties and availability of parties. These situations prove to be only workable when interaction happens through generative communication in uncoupled coordination

media. Most commonly, people use Tuple Space Systems (based on Linda[5]) for designing open mobile agent systems. While the openness of middleware like Linda-like systems is evidently an advantage, it also has a disadvantage of being too open. Not only in terms of security (as addressed in [2]), but also in terms of other non-functional concerns, such as performance and robustness. A typical linda-like system will not include primitives to take care of these concerns. We aim to handle these without touching the openness of the middleware. Linda-like systems (tuple spaces) can have different uses in an application. Aside from “normal” databases, on which agents can perform standard queries, it can also be used as “data spaces” in which agents trade and process information with different known or unknown partners. Suppose for example a public information site which lets random agents connect to various data spaces (implemented as tuple spaces). In order to allow different kinds of agents to connect to the data spaces, the information site has to offer a uniform and widely accepted interface, ideally restricting itself to the formally accepted tuple space operations (Out, In and Rd). While this restriction is fine in general to be used by different mobile agent based applications, it is very difficult to deal with non-functional concerns enforced by the applications on one side, and the site’s own concerns on the other. Taking the previous example, an information analysing mobile agent application could use the site for trading information with other kinds of agents, like news gathering agents. Publishing his own information and connecting it to partial results obtained by other analysing agents (from the same application) makes perfect use of the uncoupled communication offered by the site. But a few problems remain. The first problem is when the information analysing agents have certain requirements about the way loads of information has to be processed. Sensitive information (of course, the meaning of “sensitive” can change over time) has to be delivered to certain kinds (also variable) of agents as soon as possible. This is meant to be a performance issue for the information analysing mobile agent application. While this is clearly a configuration issue for the middleware, the openness of the tuple space can’t provide this kind of dynamism. Second, when different analysing agents are communicating sensitive data, they’d like to keep that data protected. As the site uses an uncoupled coordination medium, it has no way of preventing other, not authorised agents to use and even delete the data of the agents. On the other hand, the site itself would probably like to be able to control access to the data spaces, by placing restrictions on for example the size of the data that gets inserted by various agents. Analysis of a distributed application distincts between the technology the application uses (e.g. languages, mechanisms), the coordination laws by which it is designed (e.g. tuple space laws, client-server protocol), and the non-functional policies by which the application is enhanced (like security and robustness). In MA systems, we differentiate that last point further between application specific non-functional policies, like robustness and scalability (of an application) and

site or system specific non-functional policies, like security and quality of service (of a site/system). In other research, like discussed in “related work”, the lack of dynamism in tuple spaces is handled by offering changes in coordination laws, thus adding a lot of dynamism to the coordination medium. However, a great strength of the medium, notably the clean separation between computation and coordination, is severely weakened when coordination actions are allowed to interfere with the computation of the agents. We propose to make the coordination medium reprogrammable while guarding the semantics of the original coordination laws. As an additional dimension, our coordination medium gives the agents an environment to connect to other media. This can be done in two different ways. First, tuple spaces can be merged, or federated so they share the data of both spaces. Second, tuple spaces contain references to other spaces. These references can be used by agents to connect to other “places”. The rest of the paper is organised as follows: first, we describe a “bare” coordination medium. We present a set of requirements for making the coordination media reprogrammable and describe a Meta-Object Protocol (MOP) that fulfils these requirements. Next, we discuss means of modelling mobility on our coordination media. The following section describes our work on implementing these reprogrammable coordination media, and continues with an implementation of a distributed job scheduler to show how real-life applications can benefit from reprogrammable coordination media. Finally, we compare our approach with parallel research projects and conclude with ways to continue this research.

2

Coordination media

A coordination model consists of three elements [6]: the coordinables, i.e. the entities whose interactions need to be coordinated (e.g. objects, components, agents, processes); the coordination media, i.e. the abstractions that offer coordination actions (e.g. channels, tuple spaces, blackboards, semaphores); and coordination laws which define the semantics of the coordination actions. The most popular family of coordination models is the one based on generative communication (the tuple space model, [5]). Object-oriented versions include JavaSpaces[9], Objective Linda[15], CO3 PS[11]. These models adopt the idea of pure generative communication. This means that the coordinables cannot influence the semantics of the coordination actions.

Agent

agentOp(object)

Tuple Space

Fig. 1. basic tuple space model

In figure 1 we model a basic Linda-like tuple space, using agents as coordinables. An agent is always bound to the tuple space and therefor always has a reference to it. A possible agent operation to the reference is made by agentOp(object) where this agent operation is one of the linda operations: – Out: puts an object into the tuple space – In: gets an object matching the argument from the tuple space, deleting it from the tuple space in the process – Rd: gets an object matching the argument from the tuple space, without deleting it 2.1

Requirements for Reprogrammable Coordination media

We propose the following requirements for architectures or systems that support reprogrammable coordination media. The requirements reflect the idea of separation of concerns [14] of functional and non-functional aspects of coordination media. This short list is by no means intended to be complete. It merely contains two essential requirements that formed the starting point for our research. – conforming semantics: of utmost importance to the idea of reprogrammable coordination media is that the semantics of the coordination actions (e.g. tuple space operations) do not contradict to the semantics of the default coordination media; – separation of concerns: coordinables should not have to be redesigned because of reprogrammed coordination media. The first requirement stipulates that a coordinable must be able to rely on the predefined semantics of its coordination actions. The knowledge the coordinable has about coordination actions is the semantics of different operations provided by the coordination media. Obviously, these semantics should not change because of non-functional requirements. Changing those semantics would prohibit to reason upon the entire system. In other words, we aim to make our coordination media as programmable as possible, without rendering the semantics of the medium formally unusable. The second requirement advocates a clean separation of concerns between functional aspects of the system (i.e. the functional behaviour of the coordinables and the semantics of the coordination actions) and the non-functional aspects of the coordination media. Adding or adapting non-functional aspects of the coordination media should not affect the configuration nor the behaviour of the coordinables. This results in a two-phase design process for developing systems with programmable coordination media. First, the application designer develops the application as a set of software entities which coordinate through the media. This is the logical phase. Second, in what we call the non-functional phase, the application components, the medium, and the interaction between these two are enhanced with non-functional requirements such as security, performance and load balancing.

2.2

A reflective architecture

Run-time reflection is a powerful technique that can be used to control an application’s behaviour. Existing research has shown how this technique is used successfully to implement various non-functional requirements [18]. In this approach, the code that realises the non-functional requirements is expressed as a meta program. This meta program consists of a collection of meta-level objects to control the application. The use of runtime reflection in our model is shown in figure 2. This flowgraph clarifies the order in which a certain tuple space operation propagates through our model. 1. An agent issues an operation (agentOp(args[])) at the reference it has of the tuple space, the TSRef (tuple space reference). 2. The TSRef makes a reification1 of the agent operation, and sends it to the meta tuple space, where non-functional requirements may alter the operation. 3. After the evaluation, the TSRef sends the (altered) operation to the real tuple space, where the operation is being invoked. 4. Finally, in the case of multiple results (In, Rd), those results are sent to the meta tuple space. Non-functional requirements, which may have impact on the choice of results, select which results are sent back. The meta tuple space is a modular sequence of meta programs. This sequence is constructed at load-time, and acts as a “chain” in which the tuple space operation is evaluated by each meta object. After the operation has been evaluated and issued on the tuple space, the result is sent back through the chain of meta objects. 2.3

Federating Coordination media

In [10] it is argued that all mobile code paradigms explicitly model the concept of location. The site abstraction is introduced at the architectural level in order to take into account the location of the different components. When reasoning about tuple spaces, the site abstraction can be represented by the tuple space reference an agent is connected to. Mobility of agents may appear in different flavours[21]: Virtual Mobility Agents are aware of the distributed nature of their environment, and explicitly locate and access resources, services and other agents. From a different perspective, agents “navigate” between sites and virtually move across their resources. Actual Mobility This refers to the agents’ capability of moving across sites while executing. This is done by dynamically and autonomously transferring their code, data and state, toward the resources they need to access. 1

reification is a technique for using runtime reflection. In object oriented systems, it allows the application programmer to treat abstract principles (like methods, constructors and classes) as normal objects.

Agent

1. agentOp(args[])

TSRef

2. startNew (agentop,args[])

TSOp

3. evaluate(tsop) 4. invoke(tsop) 5. evaluate(result)

Tuple Space

Meta Tuple Space

Fig. 2. Tuple space model + meta object tuple space

Physical Mobility Mobile devices accessing the network – such as palmtops, cellular phones, etc. – are more and more present in application scenarios. In our model, we limit ourselves to two types of mobile agents, virtual and actual. This is because we set the scope of our research on Local Area Networks. Physical mobility, which gets used in ad hoc networks, falls outside of this scope. Our model expands according to these two types: – virtually mobile - The tuple space the agent connects to, is federated to other tuple spaces. Two or more tuple spaces are said to be federated when they have a common repository of data, and agents connecting to either partner have access to all data (figure 3a). – actually mobile - The agent retrieves a reference to a different tuple space. Using this reference, the agent moves itself to that tuple space and connects to it (figure 3b). Note that physically (from a stance of the network) this is still virtual mobility. We limited ourself to concepts to limit the complexity that arises from “real” actual mobility. The limitation allows us to gradually build up the concept of actual mobility, while controlling the complexity. The two figures also show how the meta tuple space relates with the main tuple space in both scenario’s. With federating tuple spaces, the objects that make up the meta tuple spaces, are merged as soon as one tuple space connects with another. The resulting meta tuple space is traversed by an operation on any of the two tuple spaces. Logically, the federation of tuple spaces has only one meta tuple space.

host boundaries

host boundaries

Agent

Agent

Tuple Space

Tuple Space MetaTS

a. virtual mobility by federation

Tuple Space Reference

Tuple Space

Tuple Space

MetaTS

MetaTS

b. actual mobility by using references

Fig. 3. virtual and actual mobility

In the case of tuple space references, every single tuple space has its own meta tuple space. When an agent connects to an acquired reference, it changes both basic tuple space and meta tuple space.

3

Prototype issues

We implemented a prototype of our proposed architecture in an experimental environment which supports distributed agents and generative communication in an object environment. CO3 PS2 embodies a method, a language, a formal framework and an execution environment for the development of open multiagent systems [11]. It advocates a separation between computation – the internal behaviour of the agents – coordination – using generative communication through object spaces – and composition – allowing virtual agent mobility. The coordination media are the objects spaces. The semantics of the coordination actions are formally defined using a Petri net formalism, PnSol [12]. 3.1

Reactivity implementation

When initialised, an object space reads in an XML document (like in figure 4a). We use XML as meta language for the definition of the meta object protocol because of its ability to extend and evolve easily, offering an additional degree of flexibility. The XML document contains (among more practical settings): – the name and location of the meta object space – the names and locations of the different meta programs that should be used with this object space The use of this extra indirection (towards the meta object space) is twofold. First, for reasons of experimentation, we regularly want to change or adapt our meta object protocol. Also, there is a strong speculation that a certain MOP 2

computation, coordination and composition by Petrinet Specifications

MetaObjectSpace UserBasedACL BehaviorBasedACL TwistedObjectSel Visualisation

Object Space

Agent A

operation

meta object space

a. XML configuration

user−based access control

basic object space container

behav.−based access control twisted object selector visualisation component

b. Tower model

Fig. 4. The Meta Object Space

can differ over applications. For example, some applications may need a more complex MOP, while others need only to incorporate one simple meta program. Our implementation uses a meta object tower to realize a reflective architecture for coordination media. The drawback of this approach is that a meta object tower assumes that different aspects of reflection can be defined orthogonally and can be composed in a sequential way. Although this is not the case in general, it does work in the applications we experimented in. Figure 4b depicts the configuration of our reflective architecture specified in figure 4a. In this example, a “chain” of meta programs are composed in the meta tower of the coordination medium. An operation on the tuple space gets intercepted by the meta object space, which sends it to the meta programs in the order specified. First it traverses both a user based and behaviour based access control list (ACL). This adds application specific security to the object space. Next it passes an object selector which, in case of multiple results, will give preference to some object, should there need be. Finally, the operation goes through the visualisation meta program for a depiction of what happens in the object space at runtime. Notice these are very generic meta programs, and are very easy to deploy in other applications. Also, there are many COTS programs that can be used (with minimal adaption) in this setting. The two main interfaces are: Meta Object Space (MOS) This interface must be implemented, and looks like figure 5. – During initialisation, the MOS is handed the chain of meta programs – When an operation is invoked on the OS Ref3 , it (the OS Ref) sends it (the operation) to the MOS for evaluation – When the result is available, the OS Ref gets it from the MOOS. 3

Objectspace Reference, similar to TSRef on page 5

public interface Mos { public void setChain(Vector chain); public public public public

void void void void

sendIn(OSInOperation oio); sendOut(OSOutOperation ooo); sendRd(OSReadOperation oro); sendEval(OSEvalOperation oeo);

public public public public

OSObject getInResult(OSResult result); Boolean getOutResult(OSResult result); OSObject getRdResult(OSResult result); Boolean getEvalResult(OSResult result);

}

Fig. 5. The interface for a meta object space

Meta Program This (figure 6) is the interface for a meta program

public interface MetaProgram { public void reviewOSObject(String op, OSOperation oo); public void reviewAgent(String op, OSOperation oo); public void choose(String op, Vector m); }

Fig. 6. The interface for a meta program

– A meta program is given the operation and the identifier for evaluation. It handles an OSObject (a tuple) different than an Agent. Using the operation, the meta program can both evaluate and change its parameters (for example priority). – When handling multiple results, the meta program may change order, or can decide none of the results are “permitted”. 3.2

Federation Implementation

Physically, CO3 PS only supports virtual code mobility. That is to say, there are no means for an agent to serialise itself and go to an other location. Conceptually however, both virtual mobility by federations, and actual mobility by following references are supported. When initialised, an object space can connect to an already existing object space, local or remote. The OS Ref representing this object space shares his data

with the object space it connected to: local residing agents use the object space as a local one, knowing it contains information from remote object spaces. This way, an agent can virtually move across the LAN’s resources, by using the local federations. The other way an agent can be made “mobile”, is giving the agent the opportunity to connect to an OS Ref that is made available on one host, pointing to another host. The agents hereby “leaves” his own place (or object space) in order to “join” another one. Making the step from pretending the agent did move, to really packing it up, and moving it physically to the other host, is very small, because conceptually the agent did an actual move from one place to another.

4

Application

We have tested the CO3 PS system, enhanced with the proposed extensions, with a distributed job scheduler application. This application, when described below, serves mainly as a demonstration of our system as an execution environment for mobile agents. The distributed job scheduler application is a set of processes wrapped in agents that find “a perfect site” to be executed on. “A perfect site” is a site that meets the process’ demand for resources. A certain process could be looking for a site that offers a certain amount of memory, bandwidth, libraries and general tools. In the first phase, the functional phase, the application developer models the agents (as in figure 7) to define and enforce their demands. These agents can connect to different sites to meet with other agents to negotiate where and when they will deploy their encapsulated process.

Application Specific set of non−functional policies

Job A

Job B

Job C

Job D

Job E

Job F

Object Space @ Site 1

Object Space @ Site 2

Object Space @ Site 3

Site Specific Policies

Site Specific Policies

Site Specific Policies

Fig. 7. The distributed job scheduler application

The application developer can (or must) provide an application specific nonfunctional policy for the whole application. The most important policies are quality of service and scalability. These can be implemented at the application level and do not meddle with basic tuple space operations, so can be viewed upon as “normal” application specific, or functional concerns. Finally, the application developer adds to the different sites the site specific non-functional policies. These meta programs, mainly behaviour based and user based access control lists, differ from site to site. This is because every single site has its own policy to protect itself from malicious and/or unauthorised processes. Looking back to our earlier requirements we set for reprogrammable coordination media, we argue both requirements have been met. For the first requirement, conforming semantics, we point out that none of the formally defined tuple space operations have been changed. We illustrate this by considering a user based access control list which blocks “In” requests to certain “forbidden” objects that do not originate from authorised agents. An “In” operation is formally defined as follows: – – – – –

it takes a template object as argument it either returns one object or none if an object is returned, that object matches 4 the template when there are multiple matches, one (unspecified) object is returned the returned object is removed from the object space

The user based access control list acts in two ways when receiving an “In” request from an unauthorised agent: – when a template object would automatically match a forbidden object, the whole operation is voided, and the operation returns no object. – when there are forbidden objects in the set of results, the meta program chooses an allowed one as result, or no result when the set only contains forbidden objects. Thus, the end result of the meta program is that forbidden objects can be viewed with a “Rd” operation, but can’t be deleted with an “In” operation. Or in other words: there is no forbidden object to “In”, although there are forbidden objects to “Rd”. The second requirement, separation of concerns, is the most important one to discuss. In terms of the application, both the application specific as the site specific non-functional policies are separated from the functional concerns of the distributed job scheduler. The order in which the application is developed, shows the first phase as being completely independent from the next phases of development. In terms of the coordination medium however, only the site specific nonfunctional policies are truly separated from the coordinables. This is because 4

the match operation is a functionality of the CO3 PS system – one object matches another when they at least instantiate the same class, further conditions can be specified by the application developer

the coordination medium sees both the application as the application specific non-functional policies as one whole. This practice does not form a problem for our model of reprogrammable coordination media, because we focused on creating an execution environment for mobile agents. An application which uses mobile agents can still safely use a meta object protocol on a level higher than the coordination medium.

5

Related Work

There exist other approaches that entail programmable coordination media. Most of these approaches use the term reactions to distinguish the additional behaviour from the original coordination medium. In [19], a distinction is made between reactions on the client side and reactions in the space. The latter is what our research is about, as the former (techniques like JavaSpaces’ notify) does not pose the question of conforming semantics. IBM’s TSpaces[20] allows to dynamically add new functionality to the coordination media at runtime. However, one of the reasons we started to use tuple spaces was the medium’s openness and genericity. The TSpaces approach therefor is fine for specific applications, but not for a general execution platform as ours. TuCSoN [1] “tuple centres” are tuple spaces enhanced with the notion of behaviour specification: the behaviour in response to communication events of every tuple centre can be defined according to the system requirements. This is archived by allowing any communication event to be associated to specific computations, called reactions[8]. A reaction is defined as a sequence of reaction goals, which may access the properties of the communication event triggering the reaction, perform simple term operations and manipulate tuples in the tuple space. TuCSoN also enables explicit access to remote tuple spaces via URLs. MARS [4] provides an environment for network-aware, mobile agents. The semantics of coordination actions may be influenced by the presence of reaction tuples in a meta space. As stated in [3] this includes reactions as “modify the matching tuple”, “modify the space” and even “return a different tuple”. This is diametrically opposed to our requirement that the operations of programmable coordination media may not have semantics that are not conform the default semantics. MARS agents only have implicit access to local tuple spaces, although lately[21] research focuses on federating tuple spaces. Lime[16] is a middleware for physical and logical mobility. It provides programmers with a global virtual data structure, a linda-like tuple space whose content is determined by the connectivity among mobile hosts. Lime extends the basic Linda tuple space with a notion of reactions. After each operation on the tuple space, a reaction is selected non-deterministically and executed when it matches a certain tuple in the tuple space, determined by the reaction. Lime defines two types of reactions [17]. Strong reactions couple in a single atomic step the detection of a tuple and the execution of a code fragment. Weak reactions decouple the two by allowing execution to take place eventually after

detection. Because of the non-deterministic nature of tuple spaces, weak reactions can be looked upon as reactions on the client side, while strong reactions can act in the space. Where Lime also compares to our approach is in the notion of federating tuple spaces. When tuple spaces are joined in the Lime system, a so-called interface tuple space (ITS) is used to access the global context of different mobile units. As Lime focuses on physical mobility, the content perceived through the ITS changes dynamically in response to changes in the set of co-located mobile units. Our view on federating tuple spaces is a more static one, and works primarily with referencing resources (tuple spaces).

6

Conclusions and Future Work

We explained why current agent based systems lack interoperability and form incompatible islands of functionality. Our approach, starting from just the coordination medium, has two properties which “upgrade” it to an execution environment for mobile agents. Besides that, we keep our basic coordination medium very simple (and therefore interoperable) although it can be used to implement very complex distributed applications. First, our coordination medium is reprogrammable. By providing meta programs which evaluate tuple space operations on one hand, and sets of results on the other, we give the application programmer more control over the coordination medium. Two requirements have to be met, the first conforming semantics – tuple space operations may not be altered or changed in any way – to be able to always rely on formally defined application behaviour, and the second separation of concerns, which stipulates that coordinables should not be redesigned because of reprogrammed coordination media. We design the reprogrammability by using a reflective architecture. Second, our coordination medium is able to federate with other instances by sharing their data, and presenting it as one logical whole on one hand, and presenting itself as a references at other sites on the other. Because of the flexibility of using references to tuple spaces, mobile agents can either use federated tuple spaces for reaching other sites, or they can migrate to other sites by using embedded tuple space references as leads. The prototype of this model is designed using an in-house developed framework named CO3 PS , because it concentrates on formally defined semantics of its coordination actions. Until now, our prototype uses a meta object tower to realize a reflective architecture, and supports federation of object spaces. We tested our prototype by developing a multi-producer, multi-consumer application, and a distributed job scheduler. One of the current research topics in this matter is the means of distributing meta programs over tuple spaces. A problem here is the fundamental difference between site specific and application specific non-functional requirements. The latter should move with the agents, as the former should remain on site.

Also, there is a need to formalise a MOP for tuple spaces. Sequential ordering of meta programs (as we illustrated) will not work in every sort of application. For example, the notion of “non-orthogonal non-functional aspects” or aspects that influence one another, is a serious problem that requires an advanced separation of concerns theory. At the moment, we are considering the use of aspect oriented programming [13] for tackling these kind of problems.

References 1. The aliCE research team, DEIS - University of Bologna/Cesena, Italy. TuCSoN Documentation, October 2001. 2. Ciaran Bryce, Manuel Oriol, and Jan Vitek. A Coordination Model for Agents Based on Secure Spaces. In P. Ciancarini and A. Wolf, editors, Proc. 3rd Int. Conf. on Coordination Models and Languages, volume 1594, pages 4–20, Amsterdam, Netherland, 1999. Springer-Verlag, Berlin. 3. Giacomo Cabri, Letizia Leonardi, G. Reggiani, and Franco Zambonelli. Design and implementation of a programmable coordination architecture for mobile agents. In Proc. of TOOLS Europe ’99 Conference, Nancy (F), June 1999. 4. Giacomo Cabri, Letizia Leonardi, and Franco Zambonelli. Mars: A programmable coordination architecture for mobile agents. IEEE Internet Computing, 4(4):26–35, August 2000. 5. Nicolas Carriero, David Gelernter, and Jerry Leichter. Distributed data structures in linda. In Proc. 13th ACM Symposium on Principles of Programming Languages, 1986. 6. Paolo Ciancarini. Coordination languages for open system design. In Proc. IEEE Conf. on Computer Languages, pages 120–129, 1990. 7. Paolo Ciancarini, Andrea Omicini, and Franco Zambonelli. Coordination technologies for internet agents. Nordic Journal of Computing, 6:215–240, August 1999. 8. Marco Cremonini, Andrea Omicini, and Franco Zambonelli. Coordination and access control in open distributed agent systems: The TuCSoN approach. In Ant´ onio Porto and Gruia-Catalin Roman, editors, Coordination Languages and Models, volume 1906 of Lecture Notes in Computer Science, pages 99–114. Springer-Verlag, 2000. 9. Eric Freeman, Susanne Hupfer, and Ken Arnold. JavaSpaces, Principles, Patterns, and Practice. The Jini Technology Series. Addison-Wesley, 1999. 10. Alfonso Fuggetta, Gian Pietro Picco, and Giovanni Vigna. Understanding code mobility. IEEE Transactions on Software Engineering, 24(5):342–361, May 1998. 11. Tom Holvoet. An Approach for Open Concurrent Software Development. PhD thesis, Department of Computer Science, KULeuven, Belgium, December 1997. 12. Tom Holvoet and Thilo Kielmann. Behaviour specification of active objects in open generative communication environments. In Proc. of the Thirtieth Annual Hawaii International Conference on System Sciences, volume 1, pages 349–358, Wailea, Hawaii, USA, 1997. IEEE. 13. Gregor Kickzales, John Lamping, Anurag Mendhekar, et al. Aspect-oriented programming. In Mehmet Aksit and Satoshi Matsuoka, editors, 11th European Conference on Object-Oriented Programming, volume 1241 of Lecture Notes in Computer Science, pages 220–242. Springer Verlag, 1997. 14. Gregor Kiczales. Beyond the black box: Open implementation. In IEEE Software, 1996.

15. Thilo Kielmann. Objective Linda: A Coordination Model for Object-Oriented Parallel Programming. PhD thesis, Dept. of Electrical Engineering and Computer Science, University of Siegen, Germany, 1997. 16. Amy Murphy, Gian Pietro Picco, and Gruia-Catalin Roman. Lime: a middleware for physical and logical mobility. In Proc. of the 21th International Conference on Distributed Computing Systems (ICDCS-21), May 2001. 17. Gian Pietro Picco and Marco L. Buschini. Exploiting transiently shared tuple spaces for location transparent code mobility. In Farhad Arbab and Carolyn Talcott, editors, Coordination Models and Languages, volume 2315 of Lecture Notes in Computer Science, pages 258–273, York, UK, April 2002. Springer-Verlag. 18. Robert Stroud and Zhixue Wue. Using metaobject protocols to satisfy nonfunctional requirements. In Chris Zimmermann, editor, Advances in ObjectOriented Metalevel Architectures and Reflection. CRC Press, 1996. 19. Robert Tolksdorf and Gregor Rojec-Goldmann. The spacetub models and framework. In Farhad Arbab and Carolyn Talcott, editors, Coordination Models and Languages, volume 2315 of Lecture Notes in Computer Science, pages 348–363, York, UK, April 2002. Springer-Verlag. 20. Peter Wyckoff. Tspaces. IBM Systems Journal, 37(3), 1998. 21. Franco Zambonelli, Giacomo Cabri, and Letizia Leonardi. Programmable coordination infrastructures for mobility. In Gruia-Catalin Roman and Gian Pietro Picco, editors, Sofware Engineering and Mobility – a Workshop co-located with the 23th International Conference on Software Engineering, pages 47–51, Toronto, Ontario, Canada, May 2001.