This directory contains a prototype implementation of Mobile Maude (MM/*.maude) along with execution environments to allow the user to interact with a mobile agent system (Env/*.maude) and a simple example application (DataMobile/*) including example initial configurations and instructions for interacting with agent systems in different ways. Mobile agent locations are modeled as Maude process objects. Multiple processes can be run within a single Maude process, or each in its own Maude process, using the IOP platform for communcation between Maude processes. The following is a very brief description of the Mobile Maude architecture. Familiarity with Maude and Maude's reflective capability is assumed for understanding the infrastructure. Mobile agent programs can be written without understanding reflection. See the Mobile Maude report (mobilemaude.pdf), for more detailed discussion. The Maude system (sources and binaries) a primer, reference manual, case studies and many papers can be found at http://maude.cs.uiuc.edu. IOP can be found at http://mcs.une.edu.au. Interactive objects have the form [ mid : cid | atts | in: inQ, out: outQ ] where mid is the objects identifier, cid names the class whose rules define the objects behavior, atts is an attribute set storing the objects state, in: inQ is the objects input buffer, out: outQ is its output buffer. Messages in inQ are of the form msg(to,from,body) where to, from are object identifiers and body is the message content. Messages in outQ can have one of the following forms: msg(to,from,body) ---- message to peer with identifier to print(string) ---- message for the user -- for tracking go(pid) ---- request to move to location named by pid Messages are put into an objects inQ and removed from its outQ either by its container object or rules used to compose object message soups. An object O is mobilized by encapsulating it in a mobile object wrapper [ mid : MO | mod: M, ob: oT, matts | in: inQ, out: outQ ] where mid is the objects identifier, M metarepresents the module defining the objects behavior, and oT is the metarepresentation of the object. A location is represented by objects of class P (process) [ pid : P | cf: C, fwd: fTable, patts | in: inQ, out: outQ ] where C is a configuration of mobile objects and go messages at fTable is a table used by a process to keep track of the locations of the mobile objects it created, in order to forward messages to objects no longer present. To simplify interprocess communication using sockets, process identifiers have the form p(host,port) where host is a string giving the host name ("localhost", dns name, or ip address), and port is a string specifying a port. A mobile object identifier has the form o(P,id) where P is a process identifier (the objects creator) and id is a local name string. The meta-object wrapper moves messages from its input buffer to the base objects input, removing message wrappers (headers) or metarepresenting as necessary. Messages in the base level output buffer are, with the exception of `go' messages, moved to the wrappers output buffer, after suitable processing. The `go' messages are the reason for the mobile wrapper. A message go(pid) causes wrapper to fold itself into a second form of go message, addressed to location pid, containing all the information needed to reconstitute and resume execution of the object at the new location. The interaction mechanism supplied by Maude (the LOOP-MODE module) only processes external input when the internal state is idle (has no more rewrites). To allow for interaction with systems of mobile objects we must ensure that mobile objects and containers pause from time to time to accept external input. After initialization a mobile object wrapper delivers all messages in its input queue, allows its base object to execute some amount of time, extracts and proccess messages for the base objects output queue and then yields, becoming idle until its receives a external signal to resume processing. A location process takes go messages from its contained configuration, turns them into `install' requests addressed to the target locaction, and places them in its outQ. Dually, `install' requests in its inQ are processed by reconstituting the contained mobile object, signalling it to start processing, and reporting its new location to the objects creator (possibly itself). A location process extracts messages from its contained mobile objects output queues and processes them. These messages are either peer-peer messages or service requests. Peer-peer messages are routed using the forwarding tables. New-object service requests are processed by creating a new object, adding it to the contained configuration, and putting a reply with the new objects identifier in the requestors input queue. Other service requests are placed in the process output queue for external processing. The location process also signals its contained objects to resume processing from time to time. The Mobile Maude infrastructure code is contained in the following files: MM/mm.maude --- specification of interactive object configurations --- and object and message syntax MM/metalib.maude --- utilities extending Maudes META-LEVEL MM/mymeta.maude --- collects metalib modules in MY-META MM/mo.maude --- specification of the mobile object wrapper class, MO MM/mp.maude --- specification of the location process class, P, that --- serves as mobile object locations Communication rules for prototyping mobile agents at different levels of abstraction are provided. MM/test-mm.maude -- in/out rules for any objects in a soup MM/test-mo.maude -- in/out rules for mobile objects plus -- -- rule to reconstitute mobile object from a go request -- -- rule to continue execution of mobile object MM/test-mp.maude -- in/out rules for process objects plus -- -- rule to continue execution of mobile objects An execution environment provides a means of interacting with mobile agents using the Maude Loop mode and IMaude an interactive extension of Maude. An execution environment also behaves like a container object. Its input and output queues are the Maude loop mode input and output buffers respectively. Its attributes are held in the loop mode state. In particular it has a conf attribute that contains metarepresented configuration (a pair consisting of a module and a configuration term). Tokens in the input buffer are treated as commands (method invocations). There are commands to initialize attributes, show current attribute values, rewrite the contained configuration, and send messages. An environment object extracts messages from its contained object configurations and processes them, delivering peer-peer messages to their target objects and processing service requests, as appropriate. Two execution environments are provided with the Mobile Agents package. Env/exeenv.maude --- can hold multiple process objects in its configuration and interprocess communication is achieved internally by rewrite rules that are part of the configuration formation. This execution environment provides a print service, printing strings for the user to see. Env/nodeenv.maude --- holds a single process object in its configuration and interprocess communication is achieved using sockets. See Env/doc-ienv.txt for documentation of the basic IMaude execution environment, and the comments at the beginning of exeenv.maude / nodeenv.maude for documentation of environment specific details. The internal communication only execution environment can be run directly in Maude or using the IOP interoperation platform as a user interface. The socket based execution environment requires use of IOP to provide the socket communication primitives. (IOP is available from http://mcs.une.edu.au:~iop). See DataMobile/README.txt for documentation of the DataMobile example including examples for running different configurations both in command line and interactive mode.