This document discusses some preliminary, public ideas concerned with the implementation of network spaces in pure Java.
The philosophy behind the initial Matrix system design is this:
Java is already almost an ideal platform for implementing and
hosting network spaces
Focus, therefore, on that which is needed for Java to actually be
able to host network spaces, and develop these ideas in the
context of API's and class libraries within Java, rather than by
extending the Java language.
In particular, according to this strategy, Java itself will be the host programming language for network spaces --- hence one can use Java's object-structure, concurency handling, primitive and library data-types to implement the network space's objects and tasks. A separate language (e.g. MOO), compiler, emulator, run-time support are not needed. An object-protection model will be developed exploiting the notion of object-handles as unforgeable capabilities.
Later, we will design a much more declarative, graphical, easy-to-use programming/modeling language for end-users, leaving Java as the "systems" programming language.
The critical issue in this approach is implementing persistence and transformability in Java. Objects in network spaces are persistent --- they exist even when there are no net connections to the server ... they exist forever until they are explicitly disposed off. This means that it is important to allow the structure of these objects to change --- allow methods and properties to be deleted or added, in essence, allow the class structure to be changed at run-time (which is all that there is in a network space).
This shall be accomplished in Matrix thus: a Matrix object will be a container Java object with only one field, the actual Java object currently implementing the Matrix object. Code and data in Matrix will always point to Matrix objects, not to the Java object contained within it. When a Matrix object is transformed (i.e. its class is changed) the Java object it points to is replaced by a new object of the appropriate class, with state from the old object carried over per the rules associated with the transformation. When a Matrix class A is tranformed, all its subclasses are also tranformed, together with all instances of those subclasses. (Not all transformations will be allowed, only those that preserve the underlying security model of Matrix.)
Because of this indirection, it is not possible for a Matrix object to invoke a method directly on other Matrix objects. Instead the code for a Matrix object must use indirect dispatch (i.e., a dynamic "invoke"), passing the name of the method to be invoked as data. This allows Java code to trap erros that arise when a Matrix object invokes a method M on another Matrix object which has since been transformed and no longer supports M.
The architectural components of the system will be as follows:
Moreover, Java's commitment to the CORBA IIOP proposal (and the implementation of IIOP-compliant ORBs in mass-market Java implementations such as Netscape's) provide an excellent base on which to build a communications architecture. The widespread availability of IIOP as a transport will permit us to interoperate with a variety of languages; by providing access to this layer to Matrix objects, we can offer user programs transparent integration with a distributed object system.
Subsequently, we will also develop distributed Matrix servers. These will allow networks of Matrix servers to work together, allowing migration of objects (and their code) from server to server. Again, piggybacking on Java will make our design considerably simpler.