Revisiting "lost codebases"

Hi,

        A few months ago I discussed the "lost codebases" problem with you
guys. I have since put together a system which I hope solves most of the
existing problems and I would like to get your feedback on it.

        Start off by forgetting RMI, JINI, etc and imagine a new system being
designed from the ground up with the following characteristics:

- When two nodes establish a connection, each assigns a local "session
id" to the connection and shares that id with its peer. So now each node
knows about the local and remote session id associated with the
connection. The idea would be to ensure that nodes retain the same ID if
their calls boomerang to nodes they have already visited, so as one node
from an existing session expands the "bubble" to another node which
isn't yet part of the session he shares all known nodes and associated
session ids with it. Alternatively, a node initiating a new session
would generate a globally-unique session id and all subsequent nodes
joining the session would use that id to communicate with one another
and when expanding the bubble to new nodes. --- At the time of this
writing I am not yet convinced I want to go with the unique id approach.
I don't like the idea that you can't guarantee that the generated UUID
really is unique. Call me a perfectionist but I'd rather be sure ;)

- Each local session has a ClassLoader associated with it. Therefore any
operations that take place within that session get loaded by that same
ClassLoader.

- If a node encounters a ClassNotFoundException while trying to execute
a command on behalf of a remote node, it asks that remote node for the
class definition. "Effectively rehosting the codebase with each
transmission hop" as mentioned in section 6.2 of Michael Warres' paper.

- When a node references a specific class in its communication (such as
"invoke a method on class C"), it specifies two things: the class name
and the class version. The class version is currently defined as the
SHA-1 digest of the class definition (bytecode). The idea is that two
nodes talking in terms of different versions of the same class will
"fail fast".

- Nodes no longer reference classes using codebases hosted on HTTP
server but rather they transmit class definitions "inline" using the
main communication protocol. When a class requests a class definition
the remote host automatically computes all dependent class definitions
and sends them back over the wire in a single burst (in order to
minimize multiple back and forth transmissions). This will probably be
optimized further in the future.

        Anyway, I think this covers the basics of my proposal. I believe this
solves the problem of type conflicts because any collection of nodes
that collaborate on the same operation run within the same session and
as such run within the same ClassLoader.

        There are two problems I didn't fully solve:

1) Long-term codebase availability. Though I argue this less of an issue
with my architecture because if the node hosting the service went down
we have no use for its class definitions.

2) Duplication of class definitions if two different sessions load the
exact same class. I don't know how much of an overhead this really is
and I suspect this could be optimized further.

3) Passing resources over the wire. To my recollection, JINI bundles
these into JAR files and references them using codebase annotations. I'd
need to add some sort of mechanism for referencing resources in the future.

        Anyway, please tell me what you think.

Thank you,
Gili


--------------------------------------------------------------------------
Getting Started:     http://www.jini.org/wiki/Category:Getting_Started
Community Web Site:  http://jini.org
jini-users Archive:  http://archives.java.sun.com/archives/jini-users.html
Unsubscribing:       email "signoff JINI-USERS"  to [email protected]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGOrTuIC8Z3eiKRrQRAkr1AJ9437/Z1bfXbGD4aabZ+/GP0+hF/ACeN63O
OR2SRQRpndOqMIZCvW52VmA=
=l70L
-----END PGP SIGNATURE-----