[528] in java-interest
WebObjects
daemon@ATHENA.MIT.EDU (Ward Harold)
Wed Jun 28 14:00:37 1995
Date: Wed, 28 Jun 95 12:23 EST
From: Ward Harold <0006378709@mcimail.com>
To: Java Interest <java-interest@java.sun.com>
Cc: Alasdhair Campbell <0004572354@mcimail.com>,
Henry Sinnreich <0002498337@mcimail.com>
I've followed with some interest the various requests/proposals for enabling
network communication between Java objects. What follows is my contribution to
this discussion.
Rather than invent a new mechanism why not leverage existing work? In particular
why not leverage the NetworkObjects work done by the Modula-3 developers at DEC
SRC? Java is not that far from Modula-3 in many respects -- they are both
strongly typed, multi-threaded, etc. The goals of the NetworkObjects work are
also compatible with the Java approach: the distinguishing aspect being
simplicity. According to the developers:
"We restricted our feature set to those features that we believe are
valuable to all distributed applications (powerful marshaling, strong
type-checking, distributed garbage collection, efficient and convenient
access to streams), and we omitted more complex or speculative features
(transactions, object migration, distributed shared memory). Also we
organized the implementation around a small number of quite simple
interfaces ..."
-- DEC SRC Research Report 115; Birrell, Nelson, Owiki, Wobber
The NetworkObjects report claims that the design should work "on any system that
provides threads, garbage collection, and object types with single inheritance."
Happily Java provides all of these features. However, the devil is in the
details and a few modifications to the Java language/compiler/runtime might
serve to make implementing the NetworkObjects design much simpler. Specifically,
under 'object types with single inheritance' Birrell et al assume the ability
to:
o test the type of an object at runtime
- one can do this in Java via 'instanceof' but Modula-3 has a 'typecode'
primitive that is better suited to this application
o allocate an object given a code for its type
- I assume they are referring to the Modula-3 'typecode'
o find the code for the direct supertype given the code for the type
- ditto
o determine at runtime the sizes and types of the fields of and object given
the type of the object
- do all these capabilities exist in the ObjectScope class?
Under 'garbage collection' they require a "hook for calling a cleanup routine
when an object is garbage collected (or explicitly freed)".
In addition a "method of communicating object typecodes from one address space
to another". Specifically,
"The numerical typecodes assigned by the compiler and linker are unique
within a give address space, but not across address spaces. Compiler
support is required to solve this problem. The Modula-3 compiler computes
a 'fingerprint' for every object type appearing in the program being
compiled. A fingerprint is a 64-bit checksum with the property that (with
overwhelming probability) two types have the same fingerprint only if they
are structurally identical. [Modula-3 uses structural, rather than name,
equivalence in its type system] Thus a fingerprint denotes a type
independently of any address space."
If the necessary, and mostly transparent, modifications were made to Java then I
believe the NetworkObjects design, and perhaps many of the interfaces, could
form the basis of a Java-based WebObjects implementation.
>>soapbox
I think most of us on this list have an inkling of what Java-enabled browsers
may do for the Web, though none of us can probably forsee all the ramifications.
Who knows what a simple, efficient, small, architecture neutral, secure, robust
distributed object technology might enable?
<<soapbox
... WkH
Ward K. Harold wharold@mcimail.com
MCI Consumer Markets (512) 339-5354
9001 N IH-35
Austin, TX 78753
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
