ICE

							    Software Architecture for the International Collaborative
                      Environment (ICE)

                             R. P. Brazile, K. M. Swigger,
           Brian Harrington, Ben Harrington, Xiaobo Peng, Cynthia Roberts
                              University of North Texas
                                    Denton, Texas
                                  brazile@cs.unt.edu


                  Abstract: This paper is a description of the software architecture of the International
            Collaborative Environment (ICE), a system implemented as a collection of components
            written in Java. The system allows groups to collaborate, both synchronously and
            asynchronously, to perform tasks over the Internet. The ICE components, all of which are
            shared by users in the same group, are chat, whiteboard, editor, file sharing, help, web
            browser and desktop sharing. In addition to the components provided by ICE, a user of ICE
            may develop and install additional components of their own design. These user-written
            components may take advantage of the collaborative features of the ICE system. This
            feature makes the ICE system user-extendable and able to respond quickly to new and
            different requirements of users.

Introduction

The functionality of ICE has been described elsewhere (brazile et al 2002). Here is a brief review. ICE
allows a person to join a pre-defined group and use the components of the system in a shared synchronous
mode although some features such as file-sharing and chat history support asynchronous use of the system.
Members of a group may chat with each other, draw using the whiteboard so that all members of the group
see the same drawing, and use the shared editor on plain text files. They may use the web browser to surf
the Internet and lead the other members of their group to the same site. They may share files with other
members of the group using the file-sharing component. They may allow other members of the group to see
their desktop and watch while various programs are executed. A user may also allow another member of
the group to take control of their desktop and execute programs on the user’s workstation.

ICE is an evolution of a system developed by the authors called the Virtual Collaborative University
(VCU) (swigger et al 1997). VCU had many of the same collaborative tools but was implemented using
C++. A decision was made at the start of this project to implement everything using Java. By using Java
exclusively, the system is capable of running on any platform that has a Java Virtual Machine. The ICE
system has been tested on all Microsoft Windows operating systems, and several versions of Unix
including Linux, Freebsd and Solaris.

Architecture of the system

Software for ICE is divided into four sections: Server, Client, Administration and Core. The server portion
is small and handles only the initial startup of each client and the shutdown of each client. The client is
larger and contains the launcher and the main program for the client process. It also contains the component
modules of the system. The administration contains programs used in the administration of the system, such
as transferring log files into the system database. The core contains programs that are used by more than
one of the other three sections.

Server
The server listens on port 3000 for clients who want to connect to ICE. The server is task oriented so after
accepting the connection, it waits to receive a command from the client. Currently it can perform four
tasks:

1. VERIFY: after a user enters their username and password, the client sends a verify message to check if it
was valid. If valid the server will send back information for the user (name, email, etc) and a list of the
groups that the user may log into. If the username and password are not valid the server sends an error
message and the client asks the user to try again.

2. CONNECT: The user may select either the default group, or select an alternate group from the list of
groups available to this user. After the user chooses a group, the client sends a connect message telling the
server to enter it in the Active User table. The server will send back the current time for synchronization,
the IP address of the user and a list of users who are currently connected. Once the client has the user list,
which includes IP addresses, it communicates directly with other clients. It communicates with the server
only for keep-alive messages (see 4).

3. DISCONNECT: when the user disconnects, this command tells the server to remove the user from the
Active User table.

4. CHECKIN: the client sends a keep-alive message at some interval (currently 10 minutes) to the server. If
the server does not receive the message it will remove that client and tell group members. This allows the
system to automatically handle users that killed the software, did not shutdown properly, lost their Internet
connection, etc., though it will take some time before they are removed.

The server contains an FTP server that accepts log files from the client. Log files are sent by the client after
twenty log messages have been generated and at the end of a session. The number of log messages before
sending the log file, currently defaulting to twenty, may be changed in the client’s ICE configuration file. If
the system is interrupted before the last log file is sent, the client will send it the next time ICE is started.

Client

The client is divided into three sections; the launcher, the ICE main module and the ICE plugins or
components. The launcher starts first and contacts the ICE HTTP server to download a file named
iceversion.txt. The current version of the ICE client is stored in a file in the ICE home directory on the
client machine. The launcher compares the version numbers and if the downloaded file indicates a newer
version is available, then the launcher downloads and installs the newer modules. Only modules that are
newer are downloaded. Once the system has been updated, the ICE main module is entered.

The ICE main module is designed to be a flexible container for plugins. This consists of providing user
management, networking (between other clients and between the server), and the ability to configure the
placement of plugins within the system.

The user management capabilities include keeping track of the active users and the user of this system.
When a user connects to a group it notifies everyone who is currently active in that group that the user
joined. Similarly, when disconnecting a disconnect message is sent to group members. If the connect
attempts fail the user will receive a notice that the system could not connect to that user. If the disconnect
fails, no notice is given. However, the keep-alive system allows the remaining clients to keep track of
group members. When the client checks in to the server, it will update the active user list if needed. This is
how individuals not in your group are maintained. If you select a user who is not in your group to send a
message to and they have disconnected, the send will fail, you will receive a notice and that user will be
removed from your list. This approach allows the system to minimize the amount of traffic and overhead
associated with precise maintenance of the users not in your group. As the number of people in a group is
usually small compared to the total number of people on the system and communications are generally
within the group, this helps keep network traffic small.

The networking part makes it easy for the plugins to communicate without having to know about all of the
details. It uses non-blocking I/O so that all of the accepts and reads from the different users can be done
within a single thread. As most users have a single processor this increases performance and reduces the
overall memory use (java applications typically require a lot of memory). Since most communication is
within the group, persistent connections are set up with group members. When the user connects to the
group the connection is established. The user who created the connection is responsible for the connection
in case of a failure. This means that the user who first initiated the connection will try to reconnect to the
other user if there is a failure. If the reconnect fails the user will receive an error message. The other user
will receive an error message as soon as the problem is noticed. For users who are not in your group the
system will create a new connection each time you want to send a message. The connection is then closed.
This means that it is more efficient to send to group members because you do not have to wait for the
connection to be set up each time. As most users send few messages to users outside of their group this is
not a problem.

The placement of the plugins is done through the two main configuration files (ice.ini, menu.xml). The ini
file allows you to position the components in cardinal directions and in the center. These components are
separated in a Java Splitpane so that the size of each can be adjusted by the user. The XML file for the
menu allows you to configure the menus so that when a menu item is pressed the system calls a method
associated with a plugin or the system (e.g. connect or disconnect). A special method (<init> which is the
bytecode signature for constructors) is used to denote that the plugin should be shown in a dialog. In
addition plugins can be created that hold other plugins on the interface. For example, in ICE there is a
special plugin that shows other plugins in internal frames. This special plugin will show the other plugin
when it receives its class name from the menu or via another plugin.

Built-in ICE components include chat, whiteboard, editor, web browser, file sharing, desktop sharing and
help. Each of these components may be configured or not, for any individual client. This configuration is
indicated in the ICE.ini file located in the ICE home directory. The ICE main module reads the ICE
configuration file to determine which modules are configured for this specific client and where they will be
positioned on the screen. This may be changed by the user. The main module then loads the configured
modules and begins the logon process as describe in the server section above. The main module is
responsible for logging on and off the system, sending messages to the group, getting user information,
logging and error messages as well as managing the use of the various components of ICE.

Administration

This part of the system contains utility type programs that generally run separate from the ICE system. For
example, there is a program that imports the local logs into the database. There is another program used for
generating some of the help files in the different formats (all in one, by chapter, by section, with or without
images etc.) The clean up program to remove dead users from the database is here. There are also some
testing tools, for example a stress test for the FTP server to see if can handle a lot of traffic and a checking
tool to see if the log files are in valid XML format. Many of the administrative functions have been moved
to a web site that was created to support the ICE system (http://zeus.csci.unt.edu/ ).

Core

The core is part of the system used throughout the other parts. This includes the network message format
(class Message), database access (class DataUtils), and XML conversion for basic types (class
XMLDataUtils).

Message takes care of reading and writing data. For example, as client and server send messages back and
forth to communicate, the formating of the messages is done there. A message is composed of one to any
number of instructions. An instruction is made up of a type and a string for other data. The composition of
the string depends on the type. For example, to use the whiteboard it might be:

Type: COMPONENT
String: Whiteboard:<shape type='rectangle'>other information needed for shape</shape>
The database is set up to hold data for three entities: users, groups, and logs. The basic types (User, Group,
Log) are used to represent this data as Java objects. Basically, DataUtils converts to and from the database
and those types, and XMLDataUtils converts to and from an XML format string and those types.

The remaining program in the core is Talkback. This program is used to help find problems in the software.
For certain exceptions that are thrown, Talkback is used to send an email to the developers, which contains
a stack trace, system properties, etc, so the problem may be analyzed.

User written components

Additional components to extend the functionality of the system may be written by the user. These
components must be written in Java and must extend the class Plugin. Once written the components must
be configured in the ICE.ini file and placed into the class path of the client machine. The user must
implement an abstract method, getName, that returns the unique name of the component. The component
inherits a set of methods that may be called to get information, such as getting User information or to use
system functions, such as logging.

The user information is returned as an object and contains the user login name and other information about
the current user. In an email client, for example, this information may be used to set the “from” information
in the email being sent. The logging method writes an entry to the log file, which will be placed into the
ICE database. These log messages may be analyzed to determine how the system is being operated by the
user.

Two sample user written components have been produced to illustrate the capability of the system. The first
one is an email client component that allows a user to send email to other group members from within the
ICE system. The second one is a voice component that allows a user to establish a voice connection to
another member of the group.

Conclusion

This paper has described the software architecture of ICE, a system written in Java that may be used by
groups of people to solve task oriented problems over the Internet, where the individuals in the groups are
in geographically separate locations. Readers can access the ICE system by visiting http://hera.csci.unt.edu
where they can download the software. A test/demo system has been set up with five groups and a number
of guest IDs. Once you have the software installed, you may logon with an ID of guestXX, where XX is
01-50. The IDs 01-09 and 50 default to group 1, 10-19 default to group 2, etc. Any of the guest IDs may
sign on to any group. These IDs do not have passwords.

Acknowledgements

This work was partially supported by NSF Computation and Social Systems grant CSS-9988605.

References:
Brazile R. P., K. M. Swigger,,Brian Harrington, Ben Harrington, & Xiabo Peng(2002), The International Collaborative
Environment (ICE), http://zeus.csci.unt.edu/ (select publications from menu.)

Swigger, K. M., Brazile, R., Lopez, V., & Livingston, A. (1997). The Virtual Collaborative University. Computers &
Education, 29(2/3), 55-61.