Jason Hong
JTransport was designed for mobility in an ideal environment where computing devices are ubiquitous, obviating the need to physically carry around these computing devices. One key point is that the action of pushing or pulling an applications is initiated by the user (as opposed to being designed in by the programmer).
Currently, JTransport is an application replication system. Although collaborative work was taken into consideration in creating the design, no collaboration mechanisms were implemented. Also, the author has since learned a great deal more about collaborative systems.
Once a synchronous collaboration mechanism is implemented in JTransport, there will be two uses for it. The first is to allow users to extend any single-user Java applet into a multi-user Java applet with little or no changes in the original applet. It should be noted, however, that extending a single-user system to a multi-user system does not necessarily work well.
The more important use will be the creation of a general framework for collaboration in Java. This will allow future designers to concentrate more on the functionality of their future system instead of on low-level implementation details such as synchronization, replication, and protocols.
After the basic window-sharing mechanism is finished, there are many other things that can be added, such as a relaxation of WYSIWIS (What You See Is What I See), a method for communication through the computer, or autonomous collaboration. These additions are detailed under the Grading Contract section.
In the scenario above, group work is accomplished by multiple people around a single computing device. So there is only one application, one interface to that application, a single computing device, one location, and synchronous collaboration. Here is another scenario.
In the scenario above, group work is accomplished by multiple people using multiple computing devices. There is only one application, which may be viewed with different interfaces (one for each computing device it was run on). There are multiple locations, and the work is done asynchronously.
Below are two scenarios for what JTransport could do with the proposed additions.
The changes would allow multiple users to have multiple interfaces, and allow synchronous work in multiple locations.
However, this creates a single point of failure in the centralized server. If the centralized server fails, the entire system will fail. Also, this model does not scale as well, since the number of connected users is determined by the maximum network throughput and processing power of the centralized server.
Decentralized systems are exact opposites of centralized systems in terms of the pros and cons. Synchronization problems across the system can lead to paradoxes in the decentralized system. Also, the system may not necessarily be idempotent. If email is to be sent, then it could be the case that every single client sends the email when only one was desired.
On the other hand, decentralized systems are more resistant to failure since there is no single point of failure. Also, the system can scale up to many users since there is no centralized behavior.
Since I do not plan on having a large number of users using a single application simultaneously, and because of the synchronization problems, a centralized application-replication system will be implemented.
Currently, when an application is replicated through JTransport, its state is independent of any other applications. This will be extended to allow a user to request a collaboration with another user's application. When this happens, a new server will be spawned which handles the collaboration for this group exclusively. New users can also join and leave this session at any time.
At this point, all of the events for each of the individual applications will be intercepted and redirected to the centralized server. Screen updates will then be broadcasted to each of the individual applications. Taking this from the perspective of the Model-View-Controller design pattern, the Model will be the server, the View will be each of the synchronized applications, and the controller will be each individual event handler and the redirection to the centralized server.
One key thing to note is that replication and collaboration are independent of a given application. One of the goals of JTransport is that there will be few or no changes needed in existing Java applications or in existing Java programming practices in order to effect these changes.
Perhaps the best way to test this system would be to have other programmers create groupware applications through this system. A simple application would be a single Frame that contains two Text Areas. Two people could use this simple application as a talk window.
A server which accepts serialized Java events, and adds these to the Event Queue. This will entail modifying the Java source code to bypass security mechanisms which currently prevent this. However, this ability is slated to be available in the next release of Java, JDK 1.2.
The reason for this is because of my experience this summer in creating the JTransport system. It took me approximately six weeks to research how to bypass the Java security manager, poring over the Java source code, and learning all of the new mechanisms required to implement the JTransport system.
This project will involve extending the JTransport protocol to signal a collaboration, spawning a new server, hacking the Java source code to control and throttle the Event Queue, creating a new protocol to send events to the centralized server, allowing for applications to gracefully (and ungracefully) de-synchronize, allowing for new users to enter, and sending updates to each of the applications. In addition, it may involve fixing any bugs I may have inadvertently created (I know of at least one I need to fix).
Currently, every computing device that will have application transport enabled will use a Transport Server. This Transport Server forwards Transport Messages. For performance reasons, I will also need to create a simplified wrapper around an application that can extend it to become a centralized server.
I will also need to create some kind of "board" that lists who is on the synchronized system.
Lastly, I will need to create a collaborative application for use in this system.
One of the problems is that there is no way for users to communicate in this system. I have been considering different mechanisms for users to communicate with each other. This may involve partial integration with MASH tools.
or
I have also been considering building some of the WYSIWIS relaxations into the system. By relaxing congruence, users could see which events came from whom (by using the cloudburst mechanism or color decay). This capability could be built directly into the system and be used for free by designers. Another WYSIWIS relaxation that could be interesting is support for subgroups.
or
Another thing I have been considering adding is what Keith Edwards and Beth Mynatt term "autonomous collaboration", where an application is replicated as independent applications, but at some later point in time the applications are merged back together into a consistent state.
As an aside, I believe that at some point in time, I will be eventually implementing all of these additions. It's just a question of when.