[1146] in java-interest
Re: Remote Objects in Java
daemon@ATHENA.MIT.EDU (Arvind Srinivasan.)
Fri Aug 25 02:53:04 1995
Date: Thu, 24 Aug 1995 14:04:01 -0400 (EDT)
From: "Arvind Srinivasan." <asriniva@cat.syr.edu>
To: "John D. Mitchell" <johnm@csua.berkeley.edu>
Cc: nataraj@cat.syr.edu, java-interest@java.sun.com
In-Reply-To: <199508160116.SAA20818@soda.CSUA.Berkeley.EDU>
On Tue, 15 Aug 1995, John D. Mitchell wrote:
> Your web document doesn't seem to address any security/privacy/etc. issues.
> Could you comment on that?
>
> Thanks,
> John
Hi John,
The local and the remote sites both run Java interpreters. The function we
modified (with respect to executing bytecodes) was ExecuteJava() (in
interpreter.c) which is the "heart" of the java interpreter. To make life
easy for us, here are some of the assumptions we made
A1. all .class files (needed by the program) would be
"visible" to both the local and the remote interpreters.
A2. the remote interpreter (which behaves as a server) would work
in an iterative manner
A3. the remote site's IP address/port would be hardcoded into the local
java interpreter. (in our prototype there is no load balancing
mechanism which determines which machine on the network should
be used as the remote site)
We have hardcoded this right now, but changing it to select a machine from
a list of hosts, 'find'ing the least loaded one and load balancing using
some heuristics to start up with, is easy to incorporate into the existing
prototype.
You raised the question about security/privacy. We did add a socket entry
point directly into the Java interpeter on the remote machine. We also
added a new opcode (remotenew) which has the same syntax as 'new'
As regards privacy, I guess you are asking about which workstations on the
network will be selected to run remote interpreters, and what if a someone
is using that workstation, right ? We didn't address this issue at all as
we did not plan to implement any load balancing mechanism.
Here are more details on how we implemented remote objects in Java.
Setting up the environment(ExecEnv ee) for the interpreter on the remote
site was tricky. Our hack for this was to let the remote interpreter go
through the following stages of initialization (the classname used is
'remote' in remote.java, and this is the output obtained using the trace
option - java_g -v -t remote )
[Initializing java/lang/Object]
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
