POSTER LAYOUT:


TITLE - TCNJ/CLAY RESEARCH GROUP, ETC...

PROBLEM AND PROPOSED SOLUTION:

Problem:  To create effective collaborative environments in which .......(what is happening in Clay 

coordination of effort on large "software" projects.

Tasks........  software development
               specialized end user collaboration (Hopewell)
               non-textual remote communication

Plenty of softare for syncronous text markup.

Solution:  Balance the impact of 
- user management and peer control, 
- content management and version control, 
- process management and workflow design. 

BACKROUND AND DEFINITIONS:
(tighten language throughout this section)
Each of the ??? areas is essential to a collaborative
environment that ensures the quality of the end product and guards
against the breakdown of the team.

*User management is defined as the administration of user accounts and associated privileges. 
This administration should be as simple as possible to avoid wasted time and confused roles

*Content management is the process of ensuring the integrity of the data at the heart of the 
project. Content management systems often employ versioning control that transparently 
preserves the progression of the project as the associated documents mature and grow. 

*A workflow is an abstraction of the process that a task takes through a team of people. 
During the execution of the workflow, it is often difficult and time-consuming to manage 
individual processes. Process management handles the interaction between different levels 
of project contributors. 


DESIGN SOLUTION:

Based upon our consideration of the three core components, we designed a framework for 
synchronous collaboration and implemented a solution to the specific problem of coordinating 
a physically dispersed team of software developers. The current design of Clay includes 
a main RMI server, a pool of project servers, a CVS system, user authentication mechanisms, 
and several client implementations. The servers are available via the RMI Registry and control 
client interaction. 
(schematic rather than text)


SYSTEM IMPLEMENTATION:
STATE UP FRONT THAT THE CURRENT DESIGN IS IMPLEMENTED AS FOLLOWS:

Components  Tasks/Responsibiliities

The main server coordinates the collection of project servers. Every client connects to the main 
server via an RMI lookup and is then passed to the appropriate project server. The main server 
is responsible for this initial client connection and management of the fault tolerance for the 
project servers. The main server is also responsible for starting the other pieces of the Clay 
server environment, such as the JDBCConnectionPool. 

The project servers created by the main server are responsible for arbitration of client 
communication and the passing of documents from the CVS to the client. There is a one-to-one 
relation between the project servers and the projects listed in the CVS. Each project server 
is responsible for user authentication and authorization. 

Client interfaces enable Clay to be flexible. Java RMI requires that distributed components be 
made remotely accessible via a stub class. This technical requirement works to Clay's advantage 
because any client can be developed independently of the interface to Clay. Clay has the ability 
to dynamically load new classes, and can therefore take advantage of new clients without a 
recompilation. 

The CVS system is responsible for the management of the content associated with a given project. 
The project servers are responsible for passing documents back and forth from the CVS to the 
clients. Documents are stored in an XML format. We designed a protocol for client interaction 
that resolves some readers-writers issues: we do not lock a file for editing, but rather lock 
it for saving. A project committer approves a stable version or resolves late changes by hand. 


GENERALIZATION OF USER INTERFACE:

The current client is a robust GUI interface that can handle many types of data. 
It implements a single interface (see II), and has the ability to handle additional 
interfaces easily

* The coding agent in the client is a useful utility to program multiple code files within a 
project structure. A user may open any number of files from the server or their local machine, 
and upon completion of the file, "commit" the document to be saved to the server. In addition 
to this, the main JTextArea contains multiple document listeners and can show other coders' 
progress working on the same file that you are viewing. While the updating of the document will 
be done in real time, it will not be constraining and overly distracting. In addition, the code 
is syntax highlighted via XML, which can mark code as Java, HTML, C++, etc. 

* The client contains a chat feature for real time typing and conversation outside of the working 
window. This can be useful for typing to single users or broadcasting to all users. We envision 
the window to be used for discussion of the project, coordination of user jobs, and the archived 
listing of ideas and contributions from separate users.

* A whiteboard-type of application to allow group members to communicate with each other visually. 
This application will utilize simple drawing tools to represent ideas, but will not have the 
overhead of containing code-writing features.
(Think of these in terms of the statements made in the problem section..... HOW can they be used as opposed to what they do.)

RESULTS:
(Cast this in language that say what it does.  Explain how each of the trade-offs described in the problem section are balanced through the Clay architecture.)

The CLAY architecture is programmed in Java. Java is useful for its extendibility, and 
cross-platform application. The system consists of a centralized server waiting for 
connections from clients. Users connecting to the system login to their group project via 
this lightweight client, and are logged in to an environment that they may easily communicate 
with others in their group. 

The communication between clients and server takes place completely transparent to the user. 
It utilizes the RMI (Remote Method Invocation) package developed as part of the Java API. The 
client application is designed for maximum plugability with different (and multiple) 
interfaces available to each group. In addition, administrator tools exist on 2 levels for 
ease of management of the groups, as well as members within the groups.


FUTURE:
(make the decision on "what's implement" with regard to interfaces before finalizing this section).

We anticipate extending Clay to handle different types of documents beyond the current 
"text document" implementation. New clients will be capable of handling different types of 
media, like graphics and music. In addition, we plan to improve on the design stages of 
system software projects by creating clients that deal with workflow design and visual 
code design. 


REFERENCES:

1. Lee, Byong G., Kai H. Chang, and N. Hari Narayanan. An Integrated Approach to Version 
Control Management in Computer Supported Collaborative Writing. Auburn University. 1998.

2. Prakash, Atul, and Hyong Sop Shim. DistView: Support for Building Efficient 
Collaborative Applications using Replicated Objects. University of Michigan. 1994.

3. Dourish, Paul and Victoria Bellotti. Awareness and Coordination in Shared Workspaces. 
1992.