Session Chair

Elie Najm is a Senior Lecturer/Reseacher of the now Networks and Informatics departments at ENST in France. Research interests include: Distributed Objects (semantics of distributed computational models, behavioural typing, design by contracts, real time, formalisation of object oriented methods); Telecommunication Services (architectures, platform support, feature and service compostion and interaction) and Formal Methods (specification and verification of network protocols and distributed systems). The ISO/ITU's Open Distributed Processing is a pertinent framework to study the above topics.

R. Hayton, M. Bursell, D. Donaldson and A. Herbert
APM Limited, UK

Presented by Richard Hayton

Mobile objects are really an extension to distributed objects. Flexible binding was felt to be adequate for mobile objects. Large amount of stuff needed by programs that should be hidden from programmer. ODP developed a vocabularly to deal wth this. APM's approach is flexible binding. Java allows mechanisms for generic communication. It's easier to slot things in and take them out. Isn't this just reflection? No: the indirection involved in reflection adds overhead. Java invocation just involves adding one more layer, so it's cheaper. Several binding schemes have been built using reflection. Returing to ODP, however, only some of the transparencieshave been solved.

We need strong encapsulation to support the transparencies and remote agents. Encapsulation keeps clusters and virtual processes apart. Also supports separate security policies and security managers. A diagram showing communication between clusters was shown. A mobility binder was shown which required additional layers to be introduced into the stack. Other things are needed for mobility, however. Consistency must be maintained, a particular problem in multithreaded environments. Location is another problem. The problem of deceit must be addressed. It is particularly problematic if tombstones are used for tracking purposes. A mobility API was illustrated. This does not solve agents, however, because mobile objects are not mobile agents. They form a community, not parts of application. Other problems include trust relatonships.

Java is good for building middleware but not perfect reflection is limited. Sun dosent play by the rules because RMI uses native methods. What about mobile objects? Mobility is just another abstraction, many hard problems need to be solved, such as scale, trust, reliability. Class loading was then described, in terms of where are the classes are loaded from. Do we trust the class? And how do we name the class? A diagram proposing some solutions based on JARS in Java 1.2 was shown but not all of the problems are solved. Security is still an issue. Secure mobile systems remains a bit of a misnomer.

One quick question from the floor asked whether typing is used to improve security? Richard said no, type consistency is checked, but not for security purposes.

D. Hagimont and D. Louvegnies
INRIA, France

Presented by Daniel Hagimont

Daniel described work untaken in the Siriac Project. The motivation was the use of Java in the context of distributed applets providing a means for dynamic application deployment. RMI provides a remote method invocation mechanism. An example is a cooperative editor using dynamic application deployment and distributed sharing of objects involving applets and replication. A second example providing remote access to mail was described, to illustrate the problems of replication and concurrency when doing rlogins on remote machines for mail access to a server.

Javanaise provides a shared run time layer providing replication of objects between applets. Basic issues were to provide a simple programming model, object fetch on demand and maintain consistency between objects. In the programming model Global Objects are provided which provide a graph of local object locations. A java object cannot be shared between global objects. The programmer defines a global class; method signatures can only include references to global classes, cf RMI's remote class. A stub compiler generates machinery which makes it work from the interfaces of the global classes. The implementation of fetching objects via global objects was illustrated in a diagram. The mechanism involved serialisation and dynamic binding of external references. The mechanism for consistency maintenance was described. An illustration of the mechanism used for parameter passing was also described.

A prototype implemented on top of JDK 1.1.5 was described. This includes a client layer, a server layer and stubs which are generated from global class interfaces. An experimental email browser has been implemented. Conclusions were as follows. Replication is a missing feature in Java: existing applictions have to manage this on their own. Javanaise makes replication explicit.

Three brief questions emerged from the floor. Firstly, what kind of consistency is provided for replicas? Daniel answered that the interface of a global object is made consistent through use of locks. Second, does the out proxy takes input from in proxy? The reply was a simple no. Thirdly, can you not use local object as a parameter? Daniel replied that that was correct: global objects are not visible from outside.

J. Baumann, F. Hohl, K. Rothermel, M. Schwehm and M. Strasser
University of Stuttgart, Germany

Presented by Joachim Baumann

Mobile agent systems were described. Issues raised included: what is a mobile agent; what other systems exist; what are the advantages; what problems still need to be solved. Mobile agents were defined by OMG as autonomous, mobile, location aware, fault aware, and heterogeneous. Other solutions include Aglets, AgentTcl, Concordia Grasshopper Odyssey, Tacoma and others. Mobile agents provide a new paradigm, asynchronous operation, overcome network latency, support heterogeneous environments, improve robustness, enable electronic marketplaces, allow customisation of server side software, allow rapid prototype of RPC applictions and allow better funding by use of a buzzword!

The MOLE 3.0 middleware was described. MOLE 3.0's agent model was shown in a diagram, followed by its fault model. The lifecycle of the agent was illustrated. Methods are init, prepare, start, migrate, die. This is non transparent migration, not transparent migration aka weak mobility. The details of MOLE 3.O migration were described, involving thread suspension, serialisation, sending of serialised agents and restarting. Communication in MOLE 3.0 involves unique agent names and badges identifying services offered. There are communication mechanisms. A GUI is provided for viewing the agent system.

MOLE 3.0 is a research tool not a commercial system, although it is used in companies. Research issues include security in particular, transactional support, termination and orphan support, coordination of agent groups, and event and blackboard based anonymous communication. Mobile Agent systems are not hype. MOLE 3.0 is available from the authors web site.

A member of the floor asked for an example of useful mobile agent applications? Joachim answered that all applications have comparable classic distributed solutions but mobile agents have advantages for implementation and development. Another question asked whether the proposed solution solves the network partion problem? The answer was no, it doesn't solve it but can assist in finite length network partitions. Joseph Sventek then queried what were the charecteristics that differentiate MOLE 3.0? Joachim replied the number of different communication mechanisms, claiming a superior method of transporting agents.

Panel

Chair: Elie Najm
RH: Richard Hayton
DH: Daniel Hagimont
JB: Joachim Baumann

Robbert van Renesse: A one size fits all approach seems to have been adopted. If we have only solved problems for Java isn't this a weakness?
RH: In a closed system, yes. We are not closed so can use IOP to talk to CORBA services. Dont't have to fix all of the world!
JB: Use Java because it's easier but what we learn is not just applicable to Java. Lessons can be transferred to other languages and environments.

Comment: In both answers we are hearing results which are applicable but we haven't solved these problems in other languages.
JB: Could use AgentTCl: solutions will migrate to other languages.
RH: We can build new systems with new features but can't fix old systems.

Chair: Could a middleware solution have been adopted?
RH: We did, but used our middleware not CORBA because easier. Research showed how to solve systems sensibly, not legacy problems.
DH: Relation with CORBA is not here. A mobile CORBA service is a potential solution.

Maarten van Steen: You dont seem to have mobile object model?
RH: Can't move things in CORBA because it's not in the standard. So developed in Java.

Comment: ISIS is a model not language. Implemented in language but don't take Java because you get Java problems.
RH: Java is only implementation language can still talk IOP.

Maarten van Steen: Would it be easier to this in C or C++?
JB: No; originally targetted Smalltalk as implementation language but then adopted Java. The research objective is to test concepts. Java is an implementation vehicle for concepts.

Sai-Lai Lo: An application for mobile agents is personalisation so procedural language is inappropriate. It is more likely that declarative language is appropriate.
DH: Declarative properties are really another virtual machine, so we can stack virtual machines.
RH: Java is not a language for intelligence but is good for commmunications and middleware.

Jim Hardwicke: What is MOLE being used for
JB: Multimedia documents, active networks with intelligent switches. To control networks. Siemens has done simulations with MOLE.