Title: Instant messenger for collaborative learning environments
CITATION PDF VIEWER THUMBNAILS PAGE IMAGE ZOOMABLE
Full Citation
STANDARD VIEW MARC VIEW
Permanent Link: http://ufdc.ufl.edu/UF00100796/00001
 Material Information
Title: Instant messenger for collaborative learning environments
Physical Description: Book
Language: English
Creator: Podoski, Chad William, 1976-
Publisher: State University System of Florida
Place of Publication: Florida
Florida
Publication Date: 2001
Copyright Date: 2001
 Subjects
Subject: Telecommunication -- Message processing   ( lcsh )
Team learning approach in education   ( lcsh )
Computer and Information Science and Engineering thesis, M.E   ( lcsh )
Dissertations, Academic -- Computer and Information Science and Engineering -- UF   ( lcsh )
Genre: government publication (state, provincial, terriorial, dependent)   ( marcgt )
bibliography   ( marcgt )
theses   ( marcgt )
non-fiction   ( marcgt )
 Notes
Summary: ABSTRACT: An instant messaging architecture is presented that facilitates collaborative learning among a highly mobile user base. The architecture leverages the write once, run anywhere trademark nature of the Java trademark computing language to enable seamless instant messaging on a range of platforms and devices. Through the use of a persistent network-accessible object repository and service discovery using Internet Protocol multicasting, an architecture is provided that is loosely coupled, reliable in the face of partial failures, and robust. The usability of the architecture is tested by a small-scale deployment. Lastly, possible extensions to the research are proposed.
Summary: KEYWORDS: instant, messenger, jini, javaspaces, java, distributed, chat
Thesis: Thesis (M.E.)--University of Florida, 2001.
Bibliography: Includes bibliographical references (p. 51).
System Details: System requirements: World Wide Web browser and PDF reader.
System Details: Mode of access: World Wide Web.
Statement of Responsibility: by Chad William Podoski.
General Note: Title from first page of PDF file.
General Note: Document formatted into pages; contains x, 52 p.; also contains graphics.
General Note: Vita.
 Record Information
Bibliographic ID: UF00100796
Volume ID: VID00001
Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
Resource Identifier: oclc - 47890070
alephbibnum - 002729360
notis - ANK7124

Downloads

This item has the following downloads:

thesis ( PDF )


Full Text











INSTANT MESSENGER FOR COLLABORATIVE LEARNING ENVIRONMENTS


By

CHAD WILLIAM PODOSKI













A THESIS PRESENTED TO THE GRADUATE SCHOOL
OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
MASTER OF ENGINEERING

UNIVERSITY OF FLORIDA


2001




























Copyright 2001

by

Chad William Podoski

































Dedicated to my parents















ACKNOWLEDGMENTS

I would like to express my deepest appreciation to my advisor, Dr. Doug Dankel II

for the guidance, encouragement, and feedback he provided me during the thesis process,

as well as the rest of my educational career at the University of Florida.

I wish to thank Dr. Richard Newman and Dr. Manuel Enrique Bermudez for

serving on my supervisory committee and for their careful review of this thesis.

I especially would like to thank my parents, Bill and Beverly, my brother, Brett,

and my grandparents, Limpio and Marion Rodrigues for their never-ending support, love,

and encouragement. In addition, I would like to acknowledge my mother, who started me

on this path with the purchase of our first personal computer.

Lastly, I would like to thank my girlfriend, Jessica Hays, who has supported me

and helped me persevere through my graduate career.
















TABLE OF CONTENTS

page

A C K N O W L E D G M E N T S ......... .................................................................................... iv

LIST OF TABLES ........................... .. ........ ............ .viii

LIST OF FIGURES ............. .......... ... ......... ............ ix

A B S T R A C T .............................................................................................. . . x

CHAPTERS

1 IN TR O D U C TIO N ............... ............... .. ..... ........... ... ..................

2 BACKGROUND............................ ................ 5

2.1 Instant M essaging H istory........................................................................ 5
2 .2 C current Instant M essengers ............................................................ ... ................... 7
2 .2 .1 IC Q ............................................................................................... . . 8
2 .2 .2 A IM .................................................................................................................... 8
2 .2 .3 Jabber ....................... ...................................................... . . 9
2 .3 Jin iTM ................................. .................................................... . . 9
2.4 JavaSpacesTM ............................ ...... ..... .... .......... 12
2 .5 Su m m ary ........................................................... ........ ...... 15

3 SPE C IFIC A T IO N S ........................................................................ 16

3.1 Technologies Choices .......................................... 16
3.1.1 JavaT ......................... .. ................................................................... ...... 16
3.1.2 JiniTM ................... ............................................. ......... 17
3 .1.3 Jav aS p acesTM ................................. ......................................... 17
3.2 D desired Functionality ........................................................................................ 19
3.2 .1 L ogin/L ogout ......... ...................................................................... ............... 19
3.2.2 C contact Support.................................. .............. 19
3.2.2.1 Contact list .......................................... 19
3.2.2.2 A dd/rem ove contact ............................................................. 19
3.2.3 Group Support .................. ...................................................... 20
3.2.3.1 Group list... .......................... ............... 20
3.2.3.2 Add/rem ove group... ............................ ............... ......... .. 20


V









3.2.3.3 Subscribe to/unsubscribe from a group................... .................. .............. 20
3.2.4 About............................................ ............ 20
3 .2 .5 E x it ....................................................................................... 2 0
3.3 Logical Structure ................................................. ...... ............ .. 21
3.3.1 H igh Level Overview ..................................................................... 21
3.3.2 C om ponent Structure................................................... ........... .............. 22
3.3.2.1 Instant m essaging client ........................................ ......... .............. 22
3.3.2.2 JavaSpace ............................................................... .. ......... 22
3 .4 Su m m ary ........................................................... ........ ...... 2 4

4 U SE R V IE W ............................................................................. 2 5

4.1 User's View ................................................ .............. 25
4.1.1 Instant M messenger Startup ........................................ .......................... 25
4.1.2 C contact and G roup D isplays................................................... ... ................. 27
4.1.3 C hat W window .... ............................ .... ............................ .............. 27
4.1.4 M enu B ar.............................. ............... ..... 28
4.1.4.1 File m enu ................................ ............................. ...... 28
4.1.4.2 Contact m enu................................. ........... .............. 29
4 .1.4 .3 G rou p m enu ................................................................................. ..... ...... 30
4 .1.4 .4 A b out m enu ................................................................................. ..... ...... 3 1
4 .2 Su m m ary ........................................................... ........ ...... 32

5 IM PLEM EN TA TION ...................................................... .............. 33

5.1 High Level Overview ............................................................... .. ......... 33
5.2 Entry Classes .................................... ............... ............ ......... 34
5.2.1 AccountListEntry and AccountRecord............................ ............. 34
5 .2 .2 S essionE ntry ..................................................................... 3 5
5.2.3 FriendEntry........................................ .............. 36
5.2.4 G roupE ntry ........................................ 37............................
5.2.5 GroupListEntry..................... ............................. 37
5.2.6 ChannelindexEntry.................... ........... ...................... 38
5.2.7 M essageEntry .............................................................................. 39
5.3 Helper Classes .................................................................... ......... 39
5.3.1 AccountListManager ..... .................... ..... ........ 40
5.3.2 SessionManager ............... ........................... 40
5.3.3 F riendM manager ..................................................... .............. 4 1
5.3.4 GroupManager................... ... ........ 42
5.3.5 ChannelIndexM manager .................................. .................... 42
5.3.6 M essageM anager.................. ...................... .............. 43
5.4 Utility Classes ......................................... 43
5.4.1 SpaceTransLocator..................................... ........ 43
5.4.2 FriendM monitor ..................................................... .............. 44
5.4.3 MessageMonitor................... ... ........ 44
5.4.4 ChatTracker........................... ............ .... 45









5 .5 U ser Interface C lasses ...................................... ................................................. 4 5
5.5.1 SpaceChat.......................................... .............. 46
5.5.2 LoginDialog..................... .. ............................... 46
5.5.3 ChatD ialog ......................................... 46
5.5.4 FriendAddDialog......................... ......... 46
5.5.5 FriendR em oveD ialog ................................................................................. 47
5.5.6 G roupCreateD ialog ........................................ 47
5.5.7 GroupRem oveDialog ........................................ 47
5.5.8 G roupSubscribeD ialog ........................................................................ ............ 47
5.5.9 AboutDialog ......... ......... ......... ...... .............. 47
5 .6 Su m m ary ........................................................... ........ ...... 4 8

6 C O N C L U SIO N .............................................................................................. 49

6.1 Conclusion .......................... ........... .............. 49
6.2 Future W ork ........................................ 49

R E FE R E N C E S ..................................................... ..................... .............. 51

BIOGRAPHICAL SKETCH........................................................ 52
















LIST OF TABLES



Table page

5.1: C lass types .............................................. ............... ..... . .. ..... ..... . 34

5.2: AccountRecord class variables ....................................................... .......... .... 34

5.3: A ccountListE ntry m ethods ........................ ........................... ...................................... 35

5.4: FriendEntry class variables................................................ ........................... 36

5.5: FriendEntry class m ethods...................................................... .......................... 36

5.6: GroupEntry m methods .......................................................... .. .............. 37

5.7: G roupListE ntry m ethods................................... .............................. .............. 37

5.8: ChannellndexEntry class variables ........................................ ................. ...... 38

5.9: ChannellndexEntry methods ......... ................................. 38

5.10: M essageE ntry class variables........................................................ ... ... .............. 39

5.11: AccountListM manager class m ethods.............................................. ... ................. 40

5.12: SessionM manager class m ethods..................................................... ... ................. 41

5.13: F riendM manager class m ethods...................................................... .... .. .............. 41

5.14: GroupM manager class m ethods ........................................ ..................... ..... 42

5.15: SpaceTransLocator class methods..................................................... ................ 44

5.16: FriendM monitor class m ethods ........................................... .......................... 44

5.17: M essageM monitor class m methods ........................................ .................... ..... 45
















LIST OF FIGURES



Figure page

3.1: Overall structure of instant messaging architecture. .............................................. 21

4.1: Instant messenger interface at startup .............. ...... ......................... ........... 25

4 .2 : U ser login dialog ........... .. ........ .. ...... ...................... .. .. ....... ............. .. 26

4.3: Instant m essenger after login..................... ............................... ........................... 27

4 .4 : C h at w in d o w ............. ..... ............. ............................................................. 2 8

4.5: A dd contact dialog ......... .................... .. ............ ...... ........... 29

4.6: R em ove contact dialog .. .... ............................................................. .............. 29

4.7: Subscribe to group dialog.................... ..................................... .......................... 30

4.8: Rem ove/unsubscribe group dialog.................................... .......................... ........ 30

4.9: Create group dialog ....................................................... ... .. ........... 31

4 .10 : A b out dialog.................. ................................ ...... .......... ..... 3 1

5.1: Class layers............................................. .......... 33
















Abstract of Thesis Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the
Requirements for the Degree of Master of Engineering

INSTANT MESSENGER FOR COLLABORATIVE LEARNING ENVIRONMENTS

By

Chad William Podoski

May 2001


Chairman: Douglas D. Dankel II
Major Department: Computer and Information Science and Engineering

An instant messaging architecture is presented that facilitates collaborative

learning among a highly mobile user base. The architecture leverages the write once, run

anywhereTM nature of the JavaTM computing language to enable seamless instant

messaging on a range of platforms and devices. Through the use of a persistent network-

accessible object repository and service discovery using Internet Protocol multicasting, an

architecture is provided that is loosely coupled, reliable in the face of partial failures, and

robust. The usability of the architecture is tested by a small-scale deployment. Lastly,

possible extensions to the research are proposed.














CHAPTER 1
INTRODUCTION

Since its inception, the primary purpose of the Internet has been to facilitate the

exchange of information. Initially, this exchange was conducted between researchers at

major educational institutions. The grandfather of the modern day Internet, ARPAnet,

was created by the Advanced Research Projects Agency. President Eisenhower created

the Advanced Research Projects Agency or ARPA in 1957 in response to the USSR's

launch of Sputnik [7]. ARPA brought together some of the country's brightest minds to

establish the US as a leader in science and technology [7]. Initially driven by the

government's request for a way to control its defense systems that would be impervious

to nuclear attack, ARPA turned to the private sector to create ARPAnet in 1968 [7].

ARPAnet began as a network of four nodes: University of California at Los Angeles,

Stanford, University of California at Santa Barbara, and University of Utah [7].

Research done as a result of the ARPAnet lead to many innovations that are still

used today: email (1971), telnet (1972), and the file transfer protocol (1973) [1].

Although not finalized and deployed until 1982, the development of the Transmission

Control Protocol/Internet Protocol or TCP/IP, which is the foundation for networks

worldwide today, began in 1973 [7]. As network technologies became more pervasive,

universities began to create networks of their own called Local Area Networks or LANs.

These LANs were then networked together by making use of Internet Protocol software.









One of these LANs, the National Science Foundation Network or NSFnet, came to

replace the slower ARPAnet and formed the backbone of what is now the Internet [7].

The commercialization of the Internet was driven by a couple of key

developments in the early 1990's, the first of which was the advent of the hypertext

markup language (HTML) and its supporting technologies. Tim Berners-Lee invented

HTML, the hypertext transfer protocol (HTTP), and the concept of uniform resource

locators (URLs) in 1990 [2]. Berners-Lee called his invention the World Wide Web.

Although released in 1992, the World Wide Web did not experience rapid acceptance

until a graduate student at the University of Illinois named Marc Andreessen developed

the first graphical user interface to the World Wide Web in 1993, called Mosaic [10]. It

was this development that marked the beginning of nonacademic uses of the Internet.

Since the introduction of the web browser, the number of people using the Internet has

exploded. Today, the Internet is revolutionizing the way almost everyone on the planet

communicates. The Internet is no longer just being used as a tool for research; it has been

integrated into almost every aspect of our lives.

One application that has become popular because of this proliferation of the

Internet is the instant messenger. An instant messenger is a distributed application that

enables users to sense each other's presence and to have real-time discussions across a

network. Although first used as a way to provide message board users real-time

communication in the mid-80s, the concept of instant messaging did not take off until

1996 [6]. It was then that a company called Mirabilis created ICQTM. ICQTM, currently

the most popular instant messenger, has in excess of 90 million users [5]. In response to

the immense user demand, nearly every major Internet player has created its own instant









messenger, including Yahoo, Microsoft, AOL, and Excite. However, current instant

messengers have been designed for a target audience that mainly uses them as a means to

communicate with friends online, as opposed to the original purpose of the Internet,

professional. While many of the current instant messengers do provide functionality that

aids users in collaboration, none have been designed around a collaborative learning

environment.

Universities provide a unique collaborative learning environment that has a highly

mobile population. Instant messaging users at universities may require instant messaging

services on a number of computer platforms from many possible locations. In the near

future, instant messaging must also be supported for mobile users on mobile computing

devices. An instant messaging architecture designed for such an environment must

satisfy some key issues. First, it must support highly mobile users. A user must be able

to use the instant messenger from anywhere on the network. This includes laptops or

other devices with wireless access that may come and go from the network. Second, this

mobility needs to be provided with no configuration required by the users. Third, because

of the wide range of platforms that may be running on a network, the instant messenger

must be platform independent. Finally, it must support collaborative groups that instant

messaging users can join. Groups will provide the means by which users with similar

educational interests collaborate.

This thesis outlines the process of developing an instant messaging architecture

that supports the key issues described above. The remainder of the thesis is organized as

follows: Chapter 2 presents background information on key technologies. Chapter 3

presents the design issues, challenges, and decisions. Chapter 4 explains the user's view






4


of the instant messenger. Implementation details are presented in Chapter 5. Finally,

Chapter 6 offers some further research areas and concludes the thesis.














CHAPTER 2
BACKGROUND

This chapter presents background information that is critical to understanding

current instant messengers and the technologies used to create a new instant messaging

architecture. First, a short history of instant messaging is presented. Second, a few of the

current instant messengers are examined and their shortcomings are outlined. Third, the

JiniTM networking technology is explained. Last, the concept of the JiniTM service

JavaSpacesTM is examined.

2.1 Instant Messaging History

Instant Messaging is not a new concept; the idea has actually been around since

the mid 1980's. The first example of instant messaging was brought on by the popularity

of bulletin boards among computer enthusiasts [6]. While bulletin boards provided a

great way for users to exchange ideas, they lacked the efficiency of real-time discussion.

Due to this fact, users were forced to wait for new messages to be posted on the bulletin

board. The solution was to provide a way for a user to create a real-time discussion

channel to another user; hence, the concept of instant messaging was born.

The next major point in the history of instant messaging came in 1988 when

America Online provided the buddy list as a feature of its proprietary network software.

Although only allowing for messaging to other users of America Online, this was the first

major example of instant messaging, as we know it today [6]. The buddy list feature was

popular with the users of America Online, but the concept did not really take off until the









mid 1990's, which brought the widespread use of the Internet and a company called

Mirabilis.

Four Israeli computer enthusiasts founded Mirabilis in July 1996 [5]. At this

point the Internet was growing at an unprecedented rate, and millions of users were

making use of the World Wide Web. Although the masses were connected to this

worldwide network, they were not able to communicate directly with each other.

Mirabilis created software to address this problem and distributed it freely. The product

"I Seek You" or ICQ enabled users to detect each other's presence online and have real-

time peer-to-peer discussions. ICQ was an instant success; within a year the service had

over 850,000 subscribers [5]. Currently, ICQ consistently holds the number one position

as the most downloaded program from Download.com.

As a result of the success of ICQ, many companies began creating their own

versions of the popular instant messenger. America Online took their buddy list concept

and created a stand-alone application, AOL Instant Messenger (AIM), which mimicked

much of ICQ's functionality. Microsoft joined the category with its introduction of the

MSN Messenger, again following the template of ICQ. Currently, there are numerous

instant messengers available, but the ones listed above represent the majority of instant

messenger users. The creation of numerous instant messengers introduced a new and

controversial issue, interoperability. Instant messenger providers are hesitant to allow

users of their service to communicate with users of another service, mainly because of the

possible loss of advertising revenue that comes with the declined growth of their own

service. One company has come forward to address this problem, Jabber.com.









Jabber.com developed the first open-standard, open-source, extensible markup

language (XML) based instant messaging platform [6]. The architecture that Jabber.com

created allows Jabber users to detect the presence of an instant message with users of

most of the current instant messengers available as well as future instant messengers.

Jabber provided this functionality by leveraging the open-standard XML and instant

messenger service proxies. XML is used as the basis for messages in the Jabber

architecture; the proxy transforms the XML message into a proprietary format based on

the instant messenger being used by the recipient of the message and delivers the

message. However, the Jabber architecture still requires users to have accounts on all the

instant messenger platforms on which they wish to detect and chat with users.

2.2 Current Instant Messengers

There are a handful of instant messengers that currently dominate the market. All

of these instant messengers follow the popular client/server programming model. The

client/server model provides for a very scalable and robust solution. This scalability is

required to handle the millions of instant messaging users. While the current instant

messengers are very good at providing instant messaging services to a large user base

across the Internet, they are lacking in the qualities outlined that make a good instant

messaging architecture for a collaborative learning environment such as a university.

First, few of the current instant messengers provide a means of creating a local university-

based instant messaging system. Second, most of the current instant messengers do not

provide support for a highly mobile user, such as a student, who may be accessing the

instant messenger from multiple locations and devices. Finally, few of the current instant

messengers provide platform independence and zero setup.









2.2.1 ICQ

The product that created the concept is still the most widely used instant

messenger on the planet with over 92 million users [5]. The reason for this is that ICQ

provides more functionality than any other messenger on the market, including chat,

voice chat, file transferring, group discussions, interest list, chat rooms, and shared

whiteboards among others. The ICQ architecture is based on the popular client/server

programming model. The client is the program that runs on the user's computing

devices. It provides a graphical user interface that allows the users to detect and chat with

other online users. The client also maintains the user preferences, including contact list

information. The server handles message delivery and detects the online presence of

contacts. Also, ICQ uses a flat namespace based on a unique user identification number

[3]. This flat namespace relies on a single server farm that is wholly owned by Mirabilis

[3]. While this decision has allowed ICQ to maintain direct control of access to its users,

it lacks the distributed, robust nature of a namespace hierarchy like the Domain Name

System (DNS) [3]. ICQ provides the best option currently available for collaborative

learning environments. However, ICQ's choice to store the user preferences on the client

computer does not support a highly mobile user. Users of ICQ are required to install ICQ

on every device they wish to use, with a duplicate contact list on that device. Further, ICQ

lacks the ability to locally administer a private instant messaging network.

2.2.2 AIM

AIM is the second largest instant messenger with 84 million subscribers. AIM is

currently the most used instant messenger by the general public, whereas ICQ dominates

in the area of computer enthusiasts. AIM's architecture is based on the same model as









ICQ and therefore, suffers from the same shortcomings. However, in the latest version of

AIM, AOL has addressed the issue of having to create a duplicate users list on each

device. AIM accomplishes this by storing the user's preferences and contact list on the

server.

2.2.3 Jabber

Jabber is an up and coming instant messaging architecture that has been readily

accepted by the computing world. Popular among computer students and professionals,

the Jabber architecture has been adopted by numerous client developers. Jabber provides

an open-source, open-standard, messaging platform that allows its users to chat with users

of almost all the other instant message platforms [6]. Jabber addresses the concerns of

the mobile user by storing user preferences on the server. Jabber also follows the

client/server model.

2.3 JiniTM

JiniTM is a network technology from Sun Microsystems providing an infrastructure

that facilitates the creation of spontaneous, self-healing, self-administered, protocol

independent distributed systems consisting of clients and services. JiniTM provides the

means for services, independent of the underlying hardware, software implementation,

and network protocol, to join/leave networks, discover other services, and use other

services [8]. Further, the JiniTM framework is implemented as a group of classes that

extend the JavaTM programming language, ensuring platform independence [8].

JiniTM represents a new generation of network technologies, the participant-to-

participant generation [9]. Every generation of network technology has been designed to

address certain problems. The client/server generation was designed to address the lack









of connectivity in the age of the centralized mainframe and stand alone personal

computers. The n-tier architecture was designed because of the need for distributed

application and interaction of services with a network [9]. This generation is

characterized by technologies like the Common Object Request Brokerage Architecture

(CORBA), Remote Method Invocation (RMI), and other remote procedure call systems.

The network-to-network technology was designed to address the need for networks to talk

to each other [9]. The participant-to-participant generation was designed to enable

participants in one network to make use of services provided by another participant, who

could be in the same network or a different network [9]. Each of the three earlier network

technologies is generally deployed on private networks that can be closely administered to

guarantee certain network characteristics [9]. Due to this fact, none of these technologies

needed to address Deutsche's Seven Fallacies of Networking:

1. The network is reliable,

2. Latency is zero,

3. Bandwidth is secure,

4. The network is secure,

5. Topology does not change,

6. There is one administrator, and

7. Transport cost is zero.

However, because of the fact that the participant-to-participant generation deals

with services in multiple networks and characteristics of these networks can not be

guaranteed, Deutsche's Seven Fallacies of Networking must be considered. JiniTM

attempts to handle three of the seven fallacies. First, the robust and self-healing nature of









JiniTM enables it to act predictably and consistently in the face of network failure, which

deals with fallacy number one [9]. Second, the JiniTM architecture was designed for

networks that can change topology in a rapid and unpredictable manner, thus addressing

fallacy number five [9]. Lastly, JiniTM allows for multiple administrators, which deals

with fallacy number six [9].

The participant-to-participant generation implemented by JiniTM promises to

revolutionize the way networks and software of the future will be structured and created.

In the area of networks, JiniTM provides for unlimited possibilities in terms of network

administration, device configuration, and network reliability. Network administration

could be greatly simplified and device configuration could be almost eliminated in some

cases by devices that configure themselves. Also, JiniTM networks are reliable and robust

in the face of partial failure. In terms of software design, JiniTM enables the evolution of

component based software design. Currently, software designers reuse previously

developed components that must be located and integrated into applications prior to

deployment. In the future, applications can be designed to leverage the ability to search

for and make use of services available on the network in real-time.

Everything on a JiniTM network can be classified as a client, service, or both. A

printer on a normal network is seen as a piece of hardware with a specific address that

must be know to make use of the printer. A printer on a JiniTM network is seen as a

printer service that can be discovered and used without knowledge of its logical address

on the network. The computer requesting the printer service is a client. The computer

itself may also be a service if it publishes any services to the network. Services can be









strictly hardware, software, or a combination of the two. Also, services can use other

services just like clients use services.

There are a few key steps that enable services to be found and used. The process

of discovering a service is made possible by one or many lookup services running on the

network. A lookup service keeps track of all the services running on the network.

Initially, clients/services discover the lookup service by either doing an IP unicast or

multicast to which the lookup service responds. Once the lookup service is discovered,

clients/services search for desired services by specifying the desired attributes of the

service sought. The lookup service looks for matches based on these attributes.

Matching services along with their interfaces are returned to the client/service.

JiniTM was designed with the idea that services/clients of the future would be

extremely mobile, coming and leaving the network at random. This design goal relates

directly to the ability of the instant messaging architecture supporting highly mobile

users. This feature of JiniTM along with a few others makes it well suited for the instant

messenger application.

2.4 JavaSpacesTM

JavaSpacesTM is a JiniTM service that was created by Sun Microsystems to

facilitate the development of distributed applications on its JiniTM platform. A

JavaSpace, commonly referred to as a "space," is a persistent network-accessible object

store. In addition, JavaSpacesTM are transitionally secure and allow for concurrent access

by multiple processes [4]. JavaSpacesTM makes use of the JiniTM Transaction model,

which provides a transaction model based on the popular two-phase commit protocol [4].

By leveraging JavaSpacesTM, developers can design distribution applications that are









loosely coupled, flexible, scalable, and reliable [4]. JavaSpacesTM, among other things,

can be used to enable one distributed application to communicate with another without

any knowledge of the other application's physical location or state, a communication

model that takes into account the network fallacy that networks are reliable.

JavaSpacesTM, along with the functionality provided by JiniTM, enables the development

of commercial-quality distributed applications [4].

The possible applications of JavaSpacesTM are endless. In addition to being useful

as a communication mechanism for distributed applications, an extremely popular

application of JavaSpacesTM, or any space based programming for that matter, is the area

of parallel computing. Due to the fact that the objects in a space, commonly referred to as

entries, are just instances of a JavaTM class, they can contain code as well as data. A

JavaTM object only needs to satisfy a few requirements to work with JavaSpacesTM,

namely, the class must extend the Entry interface and the class must be serializable. This

concept of mobile code and data being distributed through the space enables the creation

of highly scalable compute servers that can solve, in parallel, any problem that can be

subdivided into a set of smaller problems. A sample application would be cracking an

encryption key or rendering complex graphics.

The JavaSpacesTM implementation provides five operations on a space. First, an

entry can be placed in a space with the write() operation. Second, an entry can be read

from a space with the read() operation. Third, an entry can be removed from a space with

the take() operation. Fourth, in cases in which an entry may be read multiple times from

a space without being changed, an operation named snapshot() is provided that reduces

the overhead of multiple access to the space. Fifth, an operation named notify() is









provided that enables an application to request to be notified when a matching entry

appears in the space. In all operations, except for the write() operation, the entries are

matched in much the same way as services in JiniTM are matched, based on their

attributes.

JavaSpacesTM provides a powerful new distributed computing model solving

many of the problems present in the client/server model that is used by almost all current

instant messengers. The first problem that JavaSpacesTM solves is the need for a complex

centralized server. Instant messaging servers may require a commercial quality database

to handle storage of messages, contact lists, and user preferences. The second problem

that JavaSpacesTM solves is server administration and maintenance. JavaSpacesTM

requires little, if any administration and maintenance. Message entries have set leases

that expire and cause messages to be purged after a set time. If a space crashes, it is

automatically restarted and populated in a consistent manner from a log file. The final

problem, which may be the most important one with the continuing proliferation of

mobile devices and impromptu networking, is the requirement of knowing the logical

address of the instant messaging server. In traditional instant messenger, the instant

messaging client communicates with a predetermined instant messaging server. Since

JavaSpacesTM is a JiniTM service, it can be discovered just like any other JiniTM service.

This feature presents interesting possibilities for an instant messenger that is designed for

a collaborative learning environment such as a university. For example, consider the case

in which each college could have its own instant messaging space. The instant messenger

of a mobile user could automatically detect the instant messaging space it was closest to

and log onto it.









2.5 Summary

This chapter has laid the foundation for the design of a new instant messaging

architecture. By examining the history of instant messaging and the design of current

instant messengers, a new architecture can be created that addresses the shortcomings of

these earlier generations of instant messengers. Further, the JiniTM and JavaSpacesTM

technologies provide for some exciting new ways to design an instant messaging

architecture. In the next chapter, the design and specification process of the new instant

messaging architecture is outlined.














CHAPTER 3
SPECIFICATIONS

This chapter presents the initial specifications and design of the instant messaging

architecture. Design decisions such as technology choices, desired functionality, and

logical structure are outlined. Each decision is examined, as well as contrasted to

alternative choices based on possible benefits and costs.

3.1 Technologies Choices

3.1.1 JavaTM

The first design decision was to determine what programming language would be

used to develop the instant messenger. The two most viable options available were

JavaTM and C++. Each language has its own advantages and disadvantages. Applications

written in C++ generally execute faster than comparable JavaTM applications because of

the compiled nature of C++. However, C++'s greatest advantage is also its greatest

weakness, because as a compiled language it is platform dependent. C++ applications

must be recompiled for each supported hardware platform. On the other hand, JavaTM, as

an interpreted language, has the unique quality of being platform independent as long as

the underlying platform provides a Java Virtual Machine. The performance difference

between C++ and JavaTM is negligible considering the speed of modem processors and an

application domain such as instant messaging. Further, because the overriding design

decision that the instant messaging architecture must support a highly mobile user, and

thus multiple platforms, JavaTM was selected as the design language.









3.1.2 JiniTM

The highly mobile and platform independent nature of JavaTM was expanded to

the network level through the decision to base the instant messenger on the JiniTM

network technology. JiniTM provides a framework that simplifies the design of distributed

applications by providing a higher level network programming model, freeing the

application developer from dealing with network protocols or network structure. As a

consequence, distributed applications based on the JiniTM framework are robust, protocol

independent, and require less configuration. Also, JiniTM tied in nicely with the design

goals of the instant messaging architecture, inherently providing support for mobile

services/clients (i.e. instant messaging users) that join/leave a network at random. In

addition, since JiniTM is an extension of the JavaTM programming language it was the

network technology of choice when developing in JavaTM. There are competing

technologies that could have been considered such as Universal Plug and Play from

Microsoft but unlike JiniTM they do not provide an entire framework for building

distributed applications.

3.1.3 JavaSpacesTM

JavaSpacesTM is a JiniTM service that was developed by Sun Microsystems to aid

in the development of distributed applications. JavaSpacesTM provided an interesting

possibility for the design of the instant messaging architecture. The two possible

architectures to consider for the instant messenger were a client/server structure that

leveraged JiniTM or a client structure that leveraged JavaSpacesTM for client

communication.









The first, the client/server model, would extend and improve the traditional

client/server model by making use of JiniTM. JiniTM would allow the client and the server

to be designed as JiniTM services. Like any JiniTM service, the client and the server could

discover and make use of other JiniTM services. This feature would enable instant

messaging clients to discover instant messaging servers with no knowledge of their

physical location on the network. Also, JiniTM would reduce the complexity of the client

and the server by eliminating the need to handle low-level network communication.

The second model, the client and JavaSpacesTM architecture, provides all the same

advantages as the improved client/server model. However, the use of JavaSpacesTM as

the means of communication between clients, as opposed to a server, greatly reduces the

complexity of the architecture by eliminating the design of the instant messaging server.

Further, JavaSpacesTM provides functionality that increases the robustness of the

architecture, such as transactions, support for concurrent access, and self-administration

in the form of crash recovery.

While both architectures would have supported the desired feature set, the

JavaSpacesTM version was chosen because of its ability to reduce the complexity of the

design. JavaSpacesTM also provides a solution that is easily scaled. Consider the possible

structure of a university-wide instant messenger based on JavaSpacesTM. Each college

within the university could have its own JavaSpace that would serve the instant

messaging users of that college. Also, there could be university-wide JavaSpacesTM that

would serve as a university instant messaging user listing service to enable instant

messaging users of different colleges to locate and sense each other. This hierarchical









structure could be extended to multiple levels, such as departments within colleges,

universities with state university systems, and multiple university consortia.

3.2 Desired Functionality

3.2.1 Login/Logout

The instant messenger must provide a means for users to login to and logout from

the instant messaging service. Login should require a username and password. Upon

login, if a user does not have an account he/she is asked to create one.

3.2.2 Contact Support

The instant messenger must provide the basic contact support that is available in

current instant messengers. The instant messenger must provide the ability to detect

online contacts, add/remove contacts from the contact list, and initiate chat sessions with

online contacts.

3.2.2.1 Contact list

The contact list displays online instant messaging users that belong to the

currently selected group. Also, the contact list enables the user to start a chat session with

another online user, which is conducted in a separate window. The default "Friends"

group, which is unique to each user, is equivalent to the contact list in current instant

messengers.

3.2.2.2 Add/remove contact

A user should be able to add or remove contacts from their contact list. When

requesting to add a contact, the user should be presented with a list of all current

registered users from which to choose. When requesting to remove a contact, the user

should be presented with a list of his/her current contacts.









3.2.3 Group Support

The instant messenger must provide support for chat groups that are the

foundation for collaborative learning among instant messaging users.

3.2.3.1 Group list

The group list displays all groups to which the user is subscribed. Also, the group

list enables the user to change groups, which causes the contact list to display the contacts

in the new group.

3.2.3.2 Add/remove group

A user should be able to add and remove a group. In the case of adding a group,

the group name must be unique. If the group is not already registered, it is created and

registered with the user as the owner of the group. When removing a group, only the

owner of a group may remove a group, and the group must be empty.

3.2.3.3 Subscribe to/unsubscribe from a group

A user should be able to subscribe to and unsubscribe from a group. When

requesting to subscribe to a group, the user should be presented with a list of all current

registered groups. When requesting to unsubscribe from a group, the user should be

presented with a list of groups in which he/she is a member.

3.2.4 About

The instant messenger must provide a way for the user to obtain information about

the instant messenger, such as the creator and version number.

3.2.5 Exit

The instant messenger must provide a way for the user to exit the application.










3.3 Logical Structure

This section outlines the logical structure of the instant messaging architecture.

First, a high level overview of the architecture is presented. This overview examines how

the main components of the architecture interact with each other. Second, an analysis of

the structure of each of the architectural components is presented.

3.3.1 High Level Overview

The basic overall structure of the distributed application consists of the instant

messaging clients and the JavaSpace. Numerous instant messaging clients may be

running on the network at any given time. Also, a single JavaSpace is present on the

network to facilitate communication between clients. Instant messaging clients can

perform three options on the JavaSpace. A client can read an entry from the JavaSpace,

take an entry from the JavaSpace, or write an entry to the JavaSpace. The overall

structure of the distributed application is presented in Figure 3.1.




Instant Messenger




Take Write




S
Write /
Entries


JavaSpace Read



Instant Messenger Instant Messenger
Figure 3.1: Overall structure of instant messaging architecture.









3.3.2 Component Structure

3.3.2.1 Instant messaging client

The instant messaging client is a standard JavaTM application that provides a

graphical user interface similar to current instant messengers. Through its user interface,

the client provides the entire feature set outlined earlier in this chapter. Commands to

login, add contact, remove contact, add group, remove group, subscribe group, and

unsubscribe group are all designed as modal dialogs. The command to initiate a chat

session with another users causes a modeless dialog to be created. Multiple chat session

dialogs may be present at any given time. The instant messaging client does not store any

data or preferences; it is simply an instant messaging user interface.

There are two features of the instant messaging client that rely on external events:

online user detection and message detection. The instant messaging client handles user

detection by creating a separate thread, which uses a polling method with a set time

interval, to monitor the online presence of contacts. User detection is achieved by

searching for the presence of user session entries in the JavaSpace. Message detection is

achieved through the use of the JavaSpacesTM notify() method. The notify() method

allows the instant messenger client to ask the JavaSpace to notify it when message entries

for the user are placed in the JavaSpace.

3.3.2.2 JavaSpace

The JavaSpace serves as the data store for the instant messaging architecture. The

following instant messaging data is stored in the JavaSpace:

1. User account list,

2. Session data,









3. Contact lists,

4. Groups list,

5. Group member lists, and

6. Instant messages.

The data is stored in the JavaSpace in the form of entries. The JavaSpace

provides a framework for entry storage and accessibility. The only functionality that the

JavaSpace provides is the set of operations outlined in the previous chapter. However,

several design choices were made concerning the structure of the data stored in the

JavaSpace.

The JavaSpace is required to maintain all account information, which was

structured in a logical manner based on the way it would be accessed. By examining the

features, it was apparent that there was going to be a need for a complete listing of these

accounts. This could be achieved in two ways, either by having each account represented

as a separate entry or by having a single entry containing a list of all accounts. The first

guarantees that an account creation is not blocked by a locked account list entry.

However, in the case in which a complete listing of users is required, such as in the case

of adding a contact, every account entry is read and the entire list is sorted. The second

provides for a more efficient way to store and to retrieve the whole account list but it also

may cause temporary blocks when trying to create a new account. Due to the fact that

account reads and account list reads are the statistically dominant access methods of the

account list entry, the second method was chosen.

The structure of the group information is another issue that was carefully

examined. The group information stored in the JavaSpace consists of group listings,









group owners, group names, and group members. All of this information could have been

stored in a single entry; however, this would have caused a bottleneck because of the

frequent accesses required by the "subscribe to group" and "unsubscribe from group"

commands. Both of these commands require an exclusive lock to be acquired on the

group entry. To address this issue, the group information was divided into two separate

entries. The first entry was a list of group names and their corresponding owners. The

second entry represents a unique group, having a name and a list of members. Also,

structuring the group data in this manner provides efficient retrieval of the complete

listing of groups, which is needed for the "subscribe to group" command.

3.4 Summary

This chapter examined the initial design and specifications process of the new

instant messaging architecture. Technology choices were defined and scrutinized. Also,

the desired feature set was outlined. Finally, the logical structure of the instant messaging

architecture was examined and structural decisions were explained. In the next chapter,

the user's view of the instant messaging application is presented.















CHAPTER 4
USER VIEW

This chapter presents the user's view of the instant messaging application. Use of

the instant messaging application, including all functionality outlined in the

specifications, is presented.

4.1 User's View

4.1.1 Instant Messenger Startup

At startup, the user is presented with an empty view of the instant messenger

application. After the instant messenger window is displayed, the instant messenger

automatically searches for the instant messaging JavaSpace on the network.


Fie Contacts Groups Help
Select Group


Onrine Curtacts















Figure 4.1: Instant messenger interface at startup









If discovery of the instant messaging JavaSpaces is unsuccessful, the user is

notified through the status box at the box of the instant messenger. The user can attempt

logon manually through the use of the "Logon" command in the "File" menu on the menu

bar, which is only selectable when the user is not logged in. Once the JavaSpace is

located, the user is presented with the user login dialog. The login dialog provides

account login as well as account creation.






Izierarne. II I Login
Password |d Cancel1

Only required for account creation

Password New Accuunl
First Name
Last Name
Information






Figure 4.2: User login dialog



If a user has not previously created an account with the instant messenger, he/she

is required to do so. Once the account is successfully created, and indicated by a status

message displayed at the bottom of the login dialog, the user is asked to login using the

new account. A successful login returns the user to the instant messaging application,

which has been updated to reflect his/her settings.













Fie Cortacts Groups Help
Select Group
|IflendIs ________v.
Online C orDcts














Figure 4.3: Instant messenger after login



4.1.2 Contact and Group Displays

The contact list is a scrollable list of the user's online contacts. The contents of

the contact list change as instant messaging users come and go from the system. A user

can send an instant message to a user on the contact list by double clicking on that user's

name. The group combo box provides the user with a drop down list of the groups to

which he/she is subscribed to, the default "Friends" group is always in the list and does

not need to be subscribed to. When a user selects a new group, the contents of the contact

list are updated to reflect the online members of that group.
Figure 4.3: Instant messenger after login












4.1.2 Contact nd Group Displays

The contact ist is a srollable the user a way to send/receive messcontacts. The contents ofo/from

the contact list change as instant messaging user. A user may have multiple chat windows open at anyuser
can send an instant message to a user on the contact list by double clicking on that user's

name. The group combo box provides the user with a drop down list of the groups to

which he/she is subscribed to, the default "Friends" group is always in the list and does

not need to be subscribed to. When a user selects a new group, the contents of the contact

list are updated to reflect the online members of that group.

4.1.3 Chat Window

The chat window provides the user a way to send/receive messages to/from

another instant messaging user. A user may have multiple chat windows open at any










given time. Messages are sent to a user by writing the message in the message text box

and pressing the "Send" button. The user's messages as well as the contacts messages are

displayed in the main display box of the window.






,7 I iJ .1- F r..i HF :- -I' 13 ll'll Iji jlll "
lr-e K :, a 2 Pr,. Fier t ,.:.J Pnc, Eier l L I
I)I 1 '11 '11 l"











New Mes-age I Iict t,-.td. I air, alirl,-- jor Ie U* IIi [ ihe- "-'I

SsWiV Closs

Figure 4.4: Chat window



4.1.4 Menu Bar

4.1.4.1 File menu

The file menu provides three menu items: "Logon," "Logoff," and "Exit." The

"Logon" menu item, which is only selectable when the instant messenger is offline, starts

the logon procedure outlined in Section 4.1.1. The "Logoff," which is only selectable

when the instant messenger is online, causes the instant messenger to go offline. The

"Exit" menu item shutdowns the instant messenger. The instant messenger can also be

exited by closing the instant messenger window.










4.1.4.2 Contact menu

The contact menu provides two menu items: "Add Contact" and "Remove

Contact." "Add Contact" provides the user with a dialog containing a list of the

registered instant messaging users. The user can add contacts to his/her "Friends" group

by selecting a username and pressing the "Add Contact" button.


F .:. I,




* Ii -ii i

Add ConCact Cancel

Figure 4.5: Add contact dialog


"Remove Contact" provides the user with a dialog containing a list of the user's

contacts. The user can remove contacts to his/her "Friends" group by selecting a

usemame and pressing the "Remove Contact" button.


l11iii





Remove Contact Cancel

Figure 4.6: Remove contact dialog










4.1.4.3 Group menu

The group menu provides four menu items: "Subscribe," "Unsubscribe," "Create

Group," and "Delete Group." "Subscribe" provides the user with a dialog containing a

list of the registered groups. The user can subscribe to a group by selecting a group and

pressing the "Subscribe" button.


' IT I ,-J I


Subscribe Cancel

Figure 4.7: Subscribe to group dialog


"Unsubscribe" provides the user with a dialog containing a list of groups to which

the user is subscribed. The user can unsubscribe from a group by selecting a group and

pressing the "Unsubscribe" button.


.*:: -, .
*:, I- : I LII
,:,.:T 4 f.lrJ l


Unsubste Delete Cancel

Figure 4.8: Remove/unsubscribe group dialog










"Create Group" provides the user with a dialog that enables him/her to create a

new group. The user can create a new group by writing the group name in the text box

and pressing the "Create" button. The group name must be unique and unregistered.


Group Name: I

trel e c Cancel

Figure 4.9: Create group dialog



"Delete Group" provides the user with a dialog that enables him/her to delete a

group. The user deletes a group by writing the group name in the text box and pressing

the "Delete" button. "Delete Group" uses the same dialog as "Unsubscribe," Figure 4.8.

4.1.4.4 About menu

The about menu provides a single menu item, "About." "About" provides the

user a dialog that displays general information about the instant messaging application,

such as creator, description, and version.


Cr--nEd, bE CIrga Pa.Jr.I


r r'aths. i.3 a I 5rsi'i C "ur led Ir:.-,i h r'l e .j;ir.
aivhll-.'hjre t az'l ;rn %un Mi'.a-i-t-iT. Jjr aEr aiez
Nihrhnulij.' In addIlli&ri t.:. Li rrinjAld fiatuiis cf
an In riF t rmre-an Qjl. 'E p.i.ALnt .3S Jp.a-irl foi
cLt i! pirUpi

O Cance

Figure 4.10: About dialog






32


4.2 Summary

This chapter examined the user's view of the instant messaging architecture,

providing a high-level overview of a user's interaction with the instant messaging

application. Instant messenger startup, as well as details on the use of the instant

messenger's functionality, was presented. The next chapter presents the implementation

details of the instant messaging architecture.














CHAPTER 5
IMPLEMENTATION

This chapter presents the implementation of the instant messaging architecture.

First, a high level overview of the classes that constitute the application is presented.

Second, the entry classes, the building blocks of the instant messaging architecture, are

examined. Third, the purpose and functionality of each helper class is explained. Fourth,

each of the utility classes is examined. Finally, the user interface classes are explained.

5.1 High Level Overview

The instant messaging architecture can be broken down into four types of classes:

user interface, entry, helper, and utility. Further, each class type can be organized into

one of three layers, with each layer providing functionality for the layer above it. The

following figure and table illustrates this layered concept and the role of each class,

respectively.


Figure 5.1: Class layers









Table 5.1: Class types
Class Type Purpose
Entry Provide low level representation of data in the JavaSpace
Helper Provide high level functionality on data stored in entries
Utility Handle tasks such as discovery, lookup, and monitoring
User Interface Provide a front end to the functionality provided by the other class types


5.2 Entry Classes

The entry classes are the basis for all interaction between the instant messaging

client and the JavaSpace. In addition to representing instant messages in the JavaSpace,

entries are used to track user and system settings. For a JavaTM class to be used as an

entry, it must implement the Entry interface and provide a constructor that takes zero

parameters. Also, all class variables that are to be serialized must be declared public and

implement the Serializable interface.

5.2.1 AccountListEntry and AccountRecord

The AccountListEntry class is a persistent JavaSpace entry that stores all user

account information. This information includes: usemame, password, first name, last

name, and user information. The user information is encapsulated in an AccountRecord

obj ect.




Table 5.2: AccountRecord class variables
Field Name Type Description
usemame String Usemame of account owner
password String Password for account
lastname String Last name of account owner
firstname String First name of account owner
info String Misc. information about account owner









AccountListEntry stores these AccountRecord objects in a JavaTM TreeMap

structure, a sorted map that uses a Red-Black tree based implementation. The TreeMap

class provides a sorted data structure with log(n) based operations for insertion, retrieval,

removal, and search of an account record. The username was used as the key field for the

TreeMap. AccountListEntry provides the methods listed in Table 5.3, which are used by

the account list helper class to interact with the account records stored in the TreeMap.




Table 5.3: AccountListEntry methods
Method Parameters Return Type Returns
containsKey String boolean True if account record with username
is found, false otherwise
get String AccountRecord An AccountRecord if one is found
with a matching username, otherwise
null
put String, String, AccountRecord An AccountRecord if insertion was
String, String, successful, otherwise null
String
put AccountRecord AccountRecord An AccountRecord if insertion was
successful, otherwise null
remove String AccountRecord An AccountRecord if a record with a
matching username was found and
removed successful, otherwise null
values void Collection A Collection of AccountRecords


5.2.2 SessionEntry

The SessionEntry class is a JavaSpace entry used to represent the online presence

of an instant messaging user. When an instant messaging user logs on, a SessionEntry

entry that has a lease of two minutes is placed in the JavaSpace. At the end of two

minutes, the lease is either renewed by the instant messaging client or the entry is

removed from the JavaSpace. The use of leases guarantees that a user's SessionEntry









entry will be removed even if the user's instant messaging client happens to crash. The

SessionEntry class only has one class variable, a String that holds the username of the

user. The SessionEntry class provides no methods other than two constructors.

5.2.3 FriendEntry

The FriendEntry class is responsible for holding all information about a user's

contact list and the groups to which a user is subscribed. The groups and friends lists are

stored in vectors, which provide a serializable structure that allows easy manipulation of

and access to the lists. A user's FriendEntry entry exists in the JavaSpace for the life of a

user's account. The FriendEntry class provides the following class variables (Table 5.4)

and methods (Table 5.5).




Table 5.4: FriendEntry class variables
Field Name Type Description
username String Owner of the FriendEntry
friends Vector List of user's contacts
groups Vector List of groups user is subscribed to


Table 5.5: FriendEntry class methods
Method Parameters Return Type Returns
addFriend String void Void
removeFriend String boolean True if friend is removed from the friends
list, false otherwise
friends void Enumeration List of contacts in friends list
addGroup String void Void
removeGroup String boolean True if group is removed from the groups
list, false otherwise
groups void Enumeration List of groups to which user is subscribed









5.2.4 GroupEntry

The GroupEntry class is a JavaSpace entry that stores unique group information.

Every group is represented in the JavaSpace by a single GroupEntry entry, which is

persistent until the group owner removes the group. The GroupEntry class contains two

class variables, a String that holds the name of the group and a Vector that holds the

usernames of the members of the group. GroupEntry also provides the following

methods (Table 5.6), which are used by the group helper class.




Table 5.6: GroupEntry methods
Method Parameters Return Type Returns
addMember String void Void
removeMember String boolean True if member is removed from the
group, false otherwise
members void Enumeration List of members in group


5.2.5 GroupListEntry

GroupListEntry keeps a list of all registered groups and their owners. The class

has a single class variable, a Hashtable that holds group name/owner pairs, with the

group name being the unique hash key. GroupListEntry provides the following methods

(Table 5.7).




Table 5.7: GroupListEntry methods
Method Parameters Return Type Returns
containsKey String boolean True if key is found, false otherwise
addGroup String, String String Group name if added, null otherwise
removeGroup String boolean Group name if removed, null otherwise
getGroups void Enumeration List of registered groups
getOwner String String Owner of specified group












5.2.6 ChannellndexEntry

The ChannellndexEntry entry is used to represent a distributed array in the

JavaSpace. JavaSpacesTM does not provide a mechanism to guarantee delivery of entries

(messages) in a specific order, which is paramount to an instant messaging system. When

an instant messaging client searches for new messages in the JavaSpace any random entry

that matches is returned. To address this issue, an instant messaging channel is created

for each user. This channel consists of two ChannellndexEntry entries, one to represent

the head of the array and one to represent the tail of the array. As messages are added to a

user's channel the position of the tail is increased. Also, as a user reads or consumes

messages from the channel, the position of the head is increased. Structuring the channel

in this way also allows users to continue receiving messages while they are retrieving

their current messages. The tables below outline the variables (Table 5.8) and methods of

ChannellndexEntry (Table 5.9).




Table 5.8: ChannellndexEntry class variables
Field Name Type Description
type String Head or Tail
channel String Name of channel -> username
position Integer Integer position in the array



Table 5.9: ChannellndexEntry methods
Method Parameters Return Type Returns
getPosition void Integer Position of head/tail in array
increment void void Void increments position of head/tail









5.2.7 MessageEntry

MessageEntry entries are how instant messages are represented in the JavaSpace.

The messages contain the sender, recipient, position in the recipient's instant messaging

channel, creation date, and the message itself (Table 5.10). MessageEntry does not

provide any methods other than its constructors; all functionality is within its helper class.




Table 5.10: MessageEntry class variables
Field Name Type Description
to String Sender of instant message
from String Recipient of instant message
position Integer Integer position of message in the array of recipient
date Date Date and time the message was created
message String Contents of instant message


5.3 Helper Classes

Helper classes provide most of the functionality in the instant messaging

architecture. Also, helper classes shield the instant messaging client from the low level

details of the JavaSpace entries. All JavaSpace interaction, as well as transaction support,

is handled in the helper classes. Structuring the application this way also eliminates

excessive code in the entry classes, which are regularly serialized and sent across the

network to/from the JavaSpace. All helper classes have class variables that hold

references to the instant messaging client interface and the JavaSpace; with some

requiring additional class variables, such as the transaction manager, the username of the

instant messaging user, and the lease renewal manager. Further, the helper classes

provide error handling. All helper classes follow the same naming convention, which is

based on the underlying Entry class name upon which the helper class acts.









5.3.1 AccountListManager

AccountListManager provides all functionality that is required by the instant

messaging client when dealing with user accounts. This includes account creation,

account removal, user listing, and user validation (Table 5.11). Example instant

messaging commands that make use of this class are account creation and add contact.




Table 5.11: AccountListManager class methods
Method Parameters Return Type Returns
validateUsername String boolean True if valid username, otherwise
false
validateAccount StringString boolean True is username/password pair are
valid, otherwise false
createAccount String, String, void Void creates new account, friend
String,String, entry, and channel entries
String
deleteAccount String, String void Void deletes account, friend entry,
and channel entries
readAccounts void Collection List of instant messaging accounts
setup void void Void Initializes account/group
lists


5.3.2 SessionManager

SessionManager handles creating and maintaining the user's SessionEntry entry in

the JavaSpace. SessionManager is one of the few classes that make use of leases. A

user's SessionEntry entry, with a lease of two minutes, is placed in the JavaSpace when

that user logs on. SessionManager creates a LeaseRenewalManger to handle the

renewing of the SessionEntry entry lease before it expires. If the user logs off or the

user's instant messaging client crashes the SessionEntry entry is automatically removed

from the JavaSpace after two minutes. Table 5.12 lists SessionManager's methods.









Table 5.12: SessionManager class methods
Method Parameters Return Type Returns
beginSession void void Void writes session entry to
JavaSpace and create lease
renewal manager
endSession void void Void removes session entry
from JavaSpace
exists JavaSpace, String void Void checks if user is online
notify LeaseRenewalEvent void Void catches lease renewal
events


5.3.3 FriendManager

The FriendManager class handles all aspects of managing a user's contact list,

including group memberships. FriendManager is used in many operation of the instant

messaging client, such as: contact list display creation, group list display creation, and

contact/group addition/removal. Also, FriendManager makes heavy use of transactions

to guarantee a consistent state of the JavaSpace with respect to FriendEntry and

GroupEntry entries. Table 5.13 lists FriendManager's methods.


Table 5.13: FriendManager class methods
Method Parameters Return Type Returns
create Transaction void Void puts FriendEntry in the
JavaSpace
delete Transaction void Void removes FriendEntry from
JavaSpace
addFriend String void Void adds contact to contact list
removeFriend String void Void removes contact from contact list
friends void Enumeration List of friends in contact list
addGroup String void Void adds group to group list
removeGroup String void Void removes group from group list
groups void Enumeration List of groups to which user is a member









5.3.4 GroupManager

The GroupManager class provides functionality for the GroupEntry and

GroupListEntry entries in the JavaSpace. Any instant messaging command that has to

manipulate either of these entries has to make use of GroupManager. Some examples of

these commands are subscribe to group and create group. GroupManager provides

methods (Table 5.14) for complete management of a user's group details.




Table 5.14: GroupManager class methods
Method Parameters Return Type Returns
create void void Void puts GroupEntry in the
JavaSpace
delete void void Void removes GroupEntry from
JavaSpace
addMember void void Void adds member to group
removeMember void void Void removes member from group
members void Enumeration List of members of group
getOwner String String Username of owner of group
getGroups void Vector List of registered groups
groupExists String boolean True if valid group, false otherwise


5.3.5 ChannellndexManager

ChannellndexManager is a simple class that provides a constructor and two

methods, one method to create a user's instant messaging channel and another method to

remove a user's instant messaging channel from the JavaSpace. ChannellndexEntry's

entry position manipulation is done directly on the head and tail entry objects. This

approach was chosen as opposed to putting the functionality in ChannellndexManager

since ChannelIndexEntry's entry position manipulation was only going to occur in one

class, MessageManager.









5.3.6 MessageManager

MessageManager is another simple class that provides a constructor and two

methods. One method writes a message to another user's instant messaging channel, and

the other method removes messages from the user's instant messaging channel.

MessageManager does all ChannelIndexEntry entry position manipulation.

MessageManager uses transactions to provide consistency for other users instant

messaging channels and its own instant messaging channel.

5.4 Utility Classes

Utility classes provide functionality that is required for the setup or maintenance

of the instant messaging client. All maintenance utility classes have class variables that

hold references to the instant messaging client interface, the JavaSpace, and the

Transaction Manager.

5.4.1 SpaceTransLocator

Space TransLocator is a setup utility class used to handle some initialization of the

instant messenger. An instance of Space TransLocator is created by the instant messaging

client to handle the discovery of the instant messaging JavaSpace and Transaction

Manager, which are present on the network. Discovery is achieved by using the high

level utility class ServiceDiscoveryManager, which is provided with the JiniTM

implementation provided by Sun Microsystems. The JavaSpace and Transaction

Manager discovered by SpaceTransLocator are passed as references to all the classes that

require access to the JavaSpace. Table 5.15 lists SpaceTransLocator's methods.









Table 5.15: SpaceTransLocator class methods
Method Parameters Return Type Returns
locateSpace String JavaSpace JavaSpace with name equal to
the parameter
locateTM void TransactionManager TransactionManager from the
network
cleanup void void Void garbage collects


5.4.2 FriendMonitor

FriendMonitor provides one of the most important functions of the instant

messenger: online user detection. After the initialization of the instant messenger, an

instance of FriendMonitor is run in a separate thread to update the contact list every five

seconds. Table 5.16 lists FriendMonitor's methods.


Table 5.16: FriendMonitor class methods
Method Parameters Return Type Returns
run void void Void Handles all contact user
detection
setGroup String void Void Changes group of contacts to be
detected
showContacts Vector void Void Updates contact list display of
instant messaging client


5.4.3 MessageMonitor

MessageMonitor handles new messages addressed to the user. The detection of

new messages is achieved using the notify() method provided by JavaSpacesTM. The

JavaSpace is asked to notify an instance of MessageMonitor if new messages matching

the user's template get deposited in the JavaSpace. When MessageMonitor's notify()









method is called it causes MessageMonitor to run in a separate thread, in which it handles

the new messages addressed to the user.




Table 5.17: MessageMonitor class methods
Method Parameters Return Type Returns
run void void Void Handles message delivery
notify RemoteEvent void Void Starts new thread to handle messages



5.4.4 ChatTracker

ChatTracker is responsible for handling the delivery of messages to the

appropriate instant message chat dialog. ChatTracker accomplishes this by maintaining a

Hashtable of all the open chat dialogs. If a message is received from a user for whom a

chat dialog open is currently open, the message is delivered to that chat dialog.

Otherwise, a new chat dialog is created and the message is delivered. Every message that

is received by the instant messenger passes through ChatTracker. ChatTracker has a

constructor and a single method, handle(...), which takes an instant message and delivers

it to the correct instant messaging dialog.

5.5 User Interface Classes

The user interface classes provide graphical user interfaces to the functionality of

the underlying helper classes. The user interfaces are based on Java's Swing technology,

which was developed to guarantee cross platform uniformity of the display. All

secondary dialogs are modal except for the chat dialog, which is modeless. Also, all

dialogs provide a status box that supplies users with pertinent information.









5.5.1 SpaceChat

SpaceChat is the main class of the instant messaging client. SpaceChat handles

all the display details of the main instant messaging window, as well as setup details. The

layout of the display mimics most of the instant messengers currently available. The

graphical user interface is implemented using a JMenuBar, a JComboBox for the group

list, a JList for the contact list, and a JLabel for the status box. SpaceChat extends the

JFrame Swing class and uses all Swing components.

5.5.2 LoginDialog

LoginDialog provides the dialog for logging into the instant messenger and for

creating a new instant messaging user account. The login dialog has a JTextField

corresponding to each class variable in AccountRecord.

5.5.3 ChatDialog

ChatDialog provides the dialog box for an instant messaging session between two

users. The dialog has a scrollable JTextArea that displays instant messages, a JTextField

for new messages, a "Send" button to send the message in the JTextField, and a "Close"

button to end the instant messaging session.

5.5.4 FriendAddDialog

FriendAddDialog is a dialog class allowing a user to add a contact to his/her

contact list. The dialog consists of a JList of all the users currently registered. If a user

tries to add a contact already in the contact list, the request is ignored and the dialog box

is closed.









5.5.5 FriendRemoveDialog

FriendRemoveDialog is a dialog class that allows a user to remove a contact from

his/her contact list. The dialog consists of a JList list of users in the contact list. If a user

presses the "Cancel" button, the dialog box is closed.


5.5.6 GroupCreateDialog

GroupCreateDialog is a dialog class providing the user with a graphical user

interface to create a new group. The dialog has a single JTextField for the name of the

new group. If the group is not already registered, it is created when the user presses the

"Create" button.

5.5.7 GroupRemoveDialog

The GroupRemoveDialog class serves a dual purpose. GroupRemoveDialog

provides a dialog that allows a user to remove a group, providing he/she is the owner and

the group is empty, and allows a user to unsubscribe from a group. The two functions

were placed in the same dialog to eliminate redundant interfaces.

5.5.8 GroupSubscribeDialog

GroupSubscribeDialog is a dialog class that allows a user to subscribe to groups.

The dialog provides a JList of all the current registered groups. If a user tries to subscribe

to a group to which he/she is already a member, the command is ignore and the dialog

box is closed.

5.5.9 AboutDialog

AboutDialog is a simple information dialog that gives some details about the

instant messaging application. The dialog provides details, such as version information,

description, and creator.






48


5.6 Summary

This chapter examined the implementation phase of the instant messaging

architecture. The overall structure of the architecture and the logical separation of

component layers were explained. The classes of each layer were then examined in

detail, including class data structures and functionality. The next chapter presents

conclusion of the thesis and some possible extensions.














CHAPTER 6
CONCLUSION

6.1 Conclusion

This thesis presented a new instant messaging architecture targeted for

collaborative learning environments with highly mobile users, specifically universities.

Due to the target user base, the instant messaging architecture was based on a new

programming model, a service based model, as opposed to the traditional client/server

model employed in the current generation of instant messengers. The choice was made

possible by leveraging of the JiniTM and JavaSpacesTM networking technologies invented

by Sun Microsystems.

The functionality of the instant messaging architecture was tested with a small-

scale deployment on a home-based network. An instant messaging JavaSpace and two

instant messaging clients were run on the network. All functionality outlined in the thesis

was tested.

With the proliferation of group working environments in industry, collaborative

learning should become an integral part of university curriculum. This instant messaging

architecture provides a tool to facilitate this collaborative learning. The architecture

provides this functionality through the use of groups.

6.2 Future Work

The structure of the new instant messaging architecture encourages possible

extensions in the future. Designed using a service based model, the architecture provides









for easy extensibility. Addition instant messaging services can be designed that are based

on the JiniTM networking technology, allowing the instant messenger to discovery these

services on a network. Some possible feature extensions to the instant messenger itself

include:

Shared whiteboard,

Multi-user chats, and

File transfers.

Other extensions include new JiniTM services that make use of the preexisting

information in the instant messaging architecture. One example of this idea would be a

user listing directory service. The JiniTM directory service could provide users listings

and details by accessing the user data in the instant messaging JavaSpace. Another idea is

a college-wide instant alert service, providing network administrators a way to alert users

of high priority problems, such as possible virus threats or pending network shutdowns,

in real time. In contrast to the current system, which usually dispatch an email to all users,

a network administrator could use a JiniTM enabled alert service to send an alert instant

message to all users. The alert service could be made extremely lightweight by making

use of the functionality provided by the instant messaging JavaSpace.

Finally, a large-scale deployment could be conducted to test the usability of the

instant messaging architecture in a real world situation, such as the CISE department's

network. Also, by deploying on a network such as this, the cross-platform and underlying

network independence of the architecture could be tested, since fixed and mobile devices

running a variety of operating systems may be present on the network at any time and

may require instant messaging services.
















REFERENCES


[1] About.com, Inc., "ARPAnet-The First Internet,"
http://inventors.miningco.com/science/inventors/library/weekly/aa091598.htm?pi
d=2821&cob=home, January 2001

[2] About.com, Inc., "The History of HTML,"
http://inventors.about.com/science/inventors/library/inventors/blhtml.htm, January
2001

[3] Dutton, J., "Intrigue and Instant Messaging,"
http://www.mids.org/pay/mn/1009/dutton.html, September 2000

[4] Freeman, E., Hupfer, S., & Arnold, K., JavaSpacesTM Principles, Patterns, and
Practice, Sun Microsystems, Inc., Palo Alto, CA, 1999.

[5] ICQ Inc., "ICQ.com," http://www.icq.com/, January 2001

[6] Jabber.com, Inc., "Jabber.com," http://www.jabber.com/, January 2001

[7] Kristula, D., "The History of the Internet,"
http://www.davesite.com/webstation/net-history.shtml, March 1997

[8] Sun Microsystems, Inc., "JiniTM Network Technology," http://java.sun.com/jini/,
January 2001

[9] Sun Microsystems, Inc., "JiniTM Network Technology, An Executive Overview,"
http://www.sun.com/jini/whitepapers/j ini-execoverview.pdf, January 2001

[10] Veen, J., "A Brief History of HTML,"
http://www.wired.com/news/topstories/0,1287,3454,00.html, April 1997















BIOGRAPHICAL SKETCH

Chad William Podoski was born on August 2, 1976, in Wilberhamm,

Massachusetts, and grew up in Winter Haven, Florida. He received his Bachelor of

Science degree from the University of Florida in May 1999, majoring in computer

engineering. He continued at the University of Florida in August 1999 and started to

pursue a master's degree in computer engineering. He worked as a teaching assistant

during his master's degree. His research interests include mobile computing and

distributed applications.




University of Florida Home Page
© 2004 - 2010 University of Florida George A. Smathers Libraries.
All rights reserved.

Acceptable Use, Copyright, and Disclaimer Statement
Last updated October 10, 2010 - - mvs