[1580] in java-interest
Re: Java and namespace management
daemon@ATHENA.MIT.EDU (Christophe Meessen)
Fri Sep 8 11:55:53 1995
Date: Fri, 8 Sep 1995 14:46:56 +0200
To: beethovn@ai.mit.edu (Ian S Eslick), java-interest@java.sun.com
From: meessen@cppm.in2p3.fr (Christophe Meessen)
At 21:34 07/09/95 EDT, Ian S Eslick wrote:
>
>I haven't written about the namespace issue in awhile - been in and
>out of town. However, here's a strawman proposal that I recently
>mailed to a friend.
...
We are facing a now well know problem in distribted computing.
It is surprising how often I stumble on the same problem in various domain.
I don't have the ultimate solution but I thought alot about it.
(1) The problem is to locate an object in a distibuted environement.
The proprieties of the locating system are follow:
(2) Allow infinite or close to infinite number of object instances.
(3) Allow to reference and access an object instance indepently of it's
location.
(4) Allow transparent and smart local caching.
(5) distributed system
About Java one should not focus on classes. It should also be possible to
reference remote instances of classes. A class thus beeing an instance of the
class of classes (metaclass).
An object could then be a user, a computer, a file, a software resource,
a hardware resource...
Objects would be moved around the network as Applets are in Hotjava.
ie a mail, a news article, ...
The problem raised by Ian S.Eslick about the java classes naming and
management is very close to this more fundamental and general problem.
So if the java solution would be a satisfying answer to those previous
requirements, the solution could bevery usefull in many other domains.
(1) locating objects.
Lets name this locating system the Universal Object Locator. UOL
The UOL has for sole purpose to locate objects in a distributed environement.
This means that it is a function mapping an object space into a location space.
Each location being a domain, a computer, a directory or a file.
The relation is functional: This mean that each object refers to a unique
location.
(2) infinite object space
Since the location space is close to infinite, we need an object space with
equivalent properties.
(3) location independent object naming
This should allow to move the instance around and let the UOL locate it in it's
new place. Object moving should be restricted to authorized person only.
(4) transparent local caching
The caching should be possible for appropriate objects and left under local
control. It should be smart in allowing updating of the cache instances.
There are different types of objcts according to their cache behaviour.
a-never cache (dynamic objects)
b-cache & noupdate (objects that will never change)
c-cache & update (objects that may be updated)
Case a and b are trivial to handle. Case c requires to check if the object has
to be updated.
(5) distributed system
This is more a performance and robustness driven constrain.
A distributed system would optimize network and cpu usage in the translating
operation of this UOL.
So the UOL works like a phone book. It receive the object name and return the
object location what ever this location is. No more no less.
Two other possible answer are possible, the object does not exist anymore or
the object can't be located. The later case would happen in case of network
or UOL server failure.
As you can probably see there are not that many different ways to implement
this UOL. I wish there was such a usefull system as we actualy enjoy the DNS
system. Java could be a key piece in it.
I'm much further in the UOL conception. Anybody interested may contact me
for more information.
Bien cordialement,
Ch.Meessen
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
