The most significant advantage of our GUI design is the minimized coupling between the GUI and the application logic. On the client side, there is an ApplicationClient which defines the application logic of the client and handles the incoming and outgoing calls to and from the server. When the client starts up, an object that implements the ClientGUIInterface is registered with the ApplicationClient. Any incoming calls are processed in the ApplicationClient. Now, any updates that need to be done in the GUI (specified as public methods in the ClientGUIInterface), are initiated by the ApplicationClient. The coupling is minimized such that the application logic would not need to know how the GUI is updated. In fact, it is only the object that implements the ClientGUIInterface who really understands the graphical interface and does any of the specific GUI updates.

Figure 1 ApplicationClient and GUI Interrelations

Another advantage of our GUI design is the use of the MVC pattern. For every view, there is a corresponding Model object that maintains the information needed by the GUI. There is also a major control class, ClientGUIControl, that implements the ClientGUIInterface as stated above, that specifies how the information is updated. We also made use of the observer pattern to update the GUI such that only specific components will react to certain information changes.

Security control is implemented by the Model and Control classes of the GUI. This is done by enabling and disabling certain buttons so that only logical and authorized use of a function is allowed. An example would be disabling the inactivate project button when viewing other projects if another project is already activated. The inactivate project button would also be inactivated if the current user is not the chair of the current project.

Improvements to the GUI Design

One major improvement needed for our GUI design is the optimization of calls to the server that request updating information. In our design, every time a minor data change is made, a significant amount of information is requested again and again from the server dramatically increasing the load on both the client and server sides. For example, when a new participant is added to a project, the project view of the GUI is updated by requesting a ProjectInfo object, and the project tree is updated by requesting a ProjectInfo object for every project the user participates in. The way to improve this is to implement a more robust Control class in our MVC model and reduce the amount of information needed for updating and reduce the amount of information that needs to be requested by the ApplicationClient.

2.0 Application Logic Analysis

Advantages of the Application Logic

The advantages to our approach to the application logic of the collaborative tool can be summarized as follows:

Decoupled and Distributed Service Client/Server

The Project, Session Manager, and Session servers may theoretically live on different nodes, all connected through the AMC Server. Each service request entails an instantiation of a service client, followed by the desired function call through the client to the server.

Edit Broadcast Channel in Session

An Edit channel is used in session to handle edit-specific messages. This design encapsulates the potentially bursty edit-messages from other broadcast messages, and will enhance message throughput and performance.

Data Class Isolation

The ProjectInfo data class is isolated from the project client/server. The client/server logic does not affect the data classes.

Improvements to the Application Logic

The following are examples of improvements which may be implemented in the next version of the collaborative tool:

Project: private channel for each project

A private channel may be devoted to each project server, much like the session servers. As of now, the project server handles all the project requests, each being identified by a project ID. The new design may reduce project request delays, but will require the use of additional channels.

Session Manager Client: multiple session clients allowed

A participant is may wish to participate in multiple concurrent sessions. Since the system requirements do not specify this ability, it has been omitted for simplicity. The tradeoff is that implementing this adds extra complexity to the session manager client, as it must now store multiple session clients. The system, as implemented, is designed to handle this straightforward extension.

Session: private participant channel for security

Each participant should have a private channel for receiving client specific messages. This adds security to the system since only the target client will receive the message. The tradeoff is that this requires the use of more free channels.

3.0 RPC Design Analysis

Advantages of the RPC Design

The use of the XML structure provides the flexibility to encode various types of information. Custom XML tags can be created to identify unique information that a user may want to encode into an RPC message.
Using the XML structure allows for easy interpretation of the RPC message string.
The RPC supports the encoding and decoding of Java Objects. This ability allows a wide variety of Java data structures and objects to be sent between the client and server.
The methods provided by the Encode and Decode classes are user friendly. Messages can be encoded and decoded by making a few simple and intuitive function calls.
The RPC package can be adapted to other applications with little to no modification to the original code.

Disadvantages of the RPC Design

The XML structure creates a large amount of overhead during the encoding and the decoding of RPC messages. The XML parser used in the Decode class can only accept a certain range of characters. Any characters that are out of this specific range can cause errors during parsing operations. The cost of filtering out these illegal XML characters is expensive. The overhead problem is especially severe when encoding and decoding Java Objects since the byte array strings created from these objects are long and may contain a large number of illegal characters.
The RPC lacks the ability to encrypt the XML message strings.

Improvements to the RPC Design

Rewrite the entire package to make use of the new JAVA APIs for XML-based RPC (JAX-RPC Ver1.0)
Encrypt the XML message strings.

4.0 Directory Component Design Analysis

Advantages of the Directory Component

Serialized by Default – One advantage of the directory structure is that it can be serialized by default since each node is just a java.util.HashMap containing a list of its sub-nodes. Provided that the Object stored at each node is serializable, there is no need to specify the writeObject and readObject methods to handle serialization. This minimizes implementation errors.

Exception Handling – The directory component provides a robust way to handle exceptions. All server exceptions are re-thrown on the client side. For every client method invocation, it will wait on an exception buffer. In the meantime, if an illegal operation is performed to the directory structure on the server side, such as the retrieval of a node which does not exist, the server will catch the exception. It will then send it to the client through the AMCC and place it into the exception buffer to be re-thrown. This exception mirroring scheme effectively enforces the integrity of the directory content and provides optimal feedback messages on errors.

Independent Directory Structure – The recursive directory tree structure is modeled by the DirectoryStructure class, which the DirectoryServer will extend. This ensures that the directory is independent of any client and server implementation and remains reusable for other purposes in the application.

Improvements to the Directory Component

Asynchronous Persistence – In the current implementation, the directory structure will only be written to disk when the DirectoryServer is shut down. This approach is undesirable if the application crashes. In this case, some keys needed to retrieve objects from the persistent store will not be saved in the directory. Ideally, the directory content should be written to a file with each modification.

DirectoryControl for High-level Access – In the original design document, the DirectoryControl class was proposed to provide high-level methods to access the directory. These included searching for specific information objects under a project node, for example. However, it has not yet been implemented due to time constraints. Currently, clients directly access the directory to retrieve information which means that they are required to understand the directory structure.

5.0 Persistent Store Component Analysis

Advantages to the Persistent Store Component Design

Decoupled Interface and Storage – The interface to the persistent store provides the ability to retrieve, save and overwrite data. It gives no indication as to how the data is actually stored on the hard disk. This allows for a wide range of data storage possibilities such as databases or any number of files.

Single File Implementation – Storing each object into its own file creates a large number of data files. However, these files have no overhead and can be accessed nearly instantaneously as they are stored in a known location identified by a key value upon which their file names are based.

Improvements to the Persistent Store Component

Header Information – Insert within each file a header block which can be used to identify the data contained within the file. This adds complexity to the save routines and increases the file sizes. However, depending on the information contained within the header, it may be possible to rebuild the directory from the persistent store or simply verify the data type before it is extracted.

Database Implementation – Implement the persistent store as a true database. The directory can be merged into the persistent store making the data and the tool used to access the data one and the same. In addition to this convenience, the database would provide advanced storage and access features and even data encryption if necessary. This should certainly be implemented for the next version of the collaborative tool.