[541] in java-interest
Re: WebObjects
daemon@ATHENA.MIT.EDU (Henry Sinnreich)
Thu Jun 29 12:31:08 1995
Date: Thu, 29 Jun 95 11:14 EST
From: Henry Sinnreich <0002498337@mcimail.com>
To: Ward Harold <0006378709@mcimail.com>
Cc: Java Interest <java-interest@java.sun.com>,
Alasdhair Campbell <0004572354@mcimail.com>
Ward, Robert,
We are trying to encourage the use of the newsgroup
mci.webclub.technical on the news server hermes.dna.mci.com
that you can click on from
http://mww.nml.mci.com/mciwclub.com without changing your
newsgroup. Please give us your support, take a look and post the
discussion there. This is a HOT topic.
Thanks, Henry
Date: Wed Jun 28, 1995 12:23 pm CDT
Source-Date: Wed Jun 28, 1995 12:16:15
From: Ward Harold / MCI ID: 637-8709
TO: Java Interest
EMS: INTERNET / MCI ID: 376-5414
MBX: java-interest@java.sun.com
CC: Alasdhair Campbell / MCI ID: 457-2354
CC: * Henry Sinnreich / MCI ID: 249-8337
Subject: WebObjects
Message-Id: 22950628172322/0006378709PK2EM
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
