[115] in java-interest
Re: Object Migration
daemon@ATHENA.MIT.EDU (Matthew Fuchs)
Wed May 24 11:19:01 1995
From: fuchs@cerc.wvu.edu (Matthew Fuchs)
Date: Wed, 24 May 1995 00:16:46 -0400 (EDT)
To: java-interest@java.Eng.Sun.COM
> Hi all,
> some time ago (about 3 weeks) there was a discussion about object migration
> in Java. We decided to implement this.
> Why? We are in the beginning of implementing an agent system (scripting
> language based), and decided to use the Java technology as a base for
> this. What we need to implement in the first step is migration and
> communication. We want to implement this without changing the API, which
> means that all functionality has to be implemented as additional classes
> (e.g. one Migrator and one Communicator).
> We would be very interested in your comments and help. :-)
> Greetings, Joachim
> -------------------------------------------------------------------------------
(Joachim, was hier gescrieben ist, ist etwas anders, und eigentlich
besser, als was ich dir fruher geschickt habe)
My first attempts at object migration were in C++ and, unfortunately,
required hand crafting the marshalling and demarshalling code for object
members. I don't think that you can avoid that for the moment
(otherwise you need to pre-process java code). I suspect that there
are enough hooks in the compiler to put something together, if you
take the time, but I would recommend biting the bullet for the moment
to get something running.
Where java gives you the big win over C++ is that if you marshall an
object's members, and send that and the class identifier, the receiver
can recreate the class and pass in the marshalled code when calling
the constructor for migrated objects.
This is all the time consuming, but trivial and uninteresting part.
The important part is deciding on the structure of your distributed
system. What kinds of things do you want your mobile objects to do?
For example, in Dreme, every object is potentially visible over the
network, therefore, when an object migrates, every non-migrating
object that it points to must receive a network address (since
[almost] all references are lexically scoped). This is not so easy to
kluge on afterwards, which is why I wrote Dreme from scratch.
For Java, you might start with something a little more modest, but
which covers much of what people will want to do (in fact, it seems to
cover most of what Telescript allegedly gives, but who knows?).
Essentially, consider each migratory object as an independent agent;
while migrated it performs in "untethered" mode and does not
communicate with objects at its original site, although it eventually
returns to its original site after 1 or more hops. This will let you
sidestep a lot of nasty issues (such as distributed garbage collection
and distributed addressing) while getting some experience.
To do this, only one object at each node needs to be net-visible, the
Codec (coder/decoder) object. At the originating site, the migrater
passes the Codec:
(1) a buffer with the internal members marshalled
(2) a list of pointers to other local objects
(3) class name
(4) target location
(5) name of method to be invoked on the receiving side
You may also need a continuation method to be invoked when the object
returns. It depends on how you handle the threading, and I haven't
thought this point through.
The Codec creates a migration id and creates a migration record with the
id, the list of pointers (so they won't be GC'd before the
object returns) and continuation method (if you use one). Items (1),
(3) and (5) are bundled with the id and sent to the destination.
The other Codec receives the message. The Codec forks a thread which
creates an instance of the object (possibly pulling over the class)
and passes in the marshalled guts. After that, it calls the
appropriate method (or some standard method with a case statement, to
avoid security). If the object migrates again the above process is
repeated. When the object returns to its sender, the guts are
remarshalled and sent back. The originating Codec recreates the
object with the guts and the list of local pointers. Note that a
migrating object must retrace its path to free all the resources it
has claimed at each node
Each participating node also needs a name service to allow arriving
objects to locate local resources (otherwise they can compute, but
they can't find anything). The name service is passed to the
constructor for the arriving instance, so it can be parametrized by
source (i.e., you get more/better service if you pay more).
I think this would be fairly straightforward in java. You could
probably even get the basic structure up in a week or two, and then
there's a lot that can be done with just this.
Matthew Fuchs
fuchs@cerc.wvu.edu
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
