Citation
Implementation of Conference Control Service in Distributed Conference System

Material Information

Title:
Implementation of Conference Control Service in Distributed Conference System
Copyright Date:
2008

Subjects

Subjects / Keywords:
Access control systems ( jstor )
Collaboration ( jstor )
Computer technology ( jstor )
Conference tables ( jstor )
Databases ( jstor )
Groupware ( jstor )
Imports ( jstor )
Personal computers ( jstor )
Voting ( jstor )
Windows ( jstor )

Record Information

Source Institution:
University of Florida
Holding Location:
University of Florida
Rights Management:
Copyright the author. Permission granted to the University of Florida to digitize, archive and distribute this item for non-profit research and educational purposes. Any reuse of this item in excess of fair use or other copyright exemptions requires permission of the copyright holder.
Embargo Date:
8/8/2012
Resource Identifier:
81204363 ( OCLC )

Downloads

This item is only available as the following downloads:


Full Text

PAGE 1

IMPLEMENTATION OF CONFERENCE CONTROL SERVICE IN DISTRIBUTED CONFERENCE SYSTEM By ASHISH BHALANI A THESIS PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE UNIVERSITY OF FLORIDA 2002

PAGE 2

Copyright 2002 by Ashish Bhalani

PAGE 3

ACKNOWLEDGMENTS I would like to sincerely thank Dr. Richard Newman-Wolfe, my thesis advisor, for his supportive and extensive contribution in guiding me and supervising me throughout my thesis. His insights and support have been a major asset in writing my thesis and I will miss working with him. I would like to extend my special thanks to him for allowing me the flexibility and opportunity to work with him. I would like to thank my committee members, Dr. Abdelsalam Helal and Dr. Jonathan C. Liu, for being cooperative and supportive. I would like to thank my colleagues for sharing with me their expertise and lending me advice. I would also like to thank all the University and editorial staff for their contribution in editing and organizing my thesis. I appreciate and take this moment to thank my friends who provided so much support and encouragement to all my efforts in various ways. My family’s contribution has also been tremendous in helping me succeed in my work. I would like to take this opportunity to thank my wonderful parents and family for always being there with me and for their infinite patience and good grace. I thank all of them. iii

PAGE 4

TABLE OF CONTENTS page ACKNOWLEDGMENTS.................................................................................................iii LIST OF TABLES............................................................................................................vii LIST OF FIGURES.........................................................................................................viii ABSTRACT.......................................................................................................................ix CHAPTER 1 INTRODUCTION............................................................................................................1 1.1 Overview...................................................................................................................1 1.2 Definitions.................................................................................................................1 1.3 Conference Control Service......................................................................................2 1.4 Need for Conference Control Service.......................................................................2 1.5 Organization of the thesis.........................................................................................5 2 SURVEY OF RELEVANT WORK.................................................................................7 2.1 CSCW and Groupware.............................................................................................7 2.1.1 Introduction.....................................................................................................7 2.2 Some Groupware Systems........................................................................................8 2.2.1 Computer Conferencing System.....................................................................9 2.2.1.1 EMISARI...............................................................................................9 2.2.1.2 Usenet....................................................................................................9 2.2.1.3 Distributed Conference System (DCS) v1...........................................10 2.2.2 Chat Systems.................................................................................................12 2.2.3 Electronic Meeting System...........................................................................13 2.2.4 Application Sharing Systems........................................................................13 2.2.5 Co-authoring Systems...................................................................................14 2.2.5.1 Quilt.....................................................................................................15 2.2.5.2 GROVE................................................................................................15 2.2.6 Group Scheduling and Calendars Systems...................................................16 2.2.6.1 MPCAL................................................................................................16 2.2.6.2 RTCAL................................................................................................17 2.2.7 Videoconferencing Systems..........................................................................17 2.2.8 MERMAID...................................................................................................18 2.3 Motivation for DCS v2a..........................................................................................19 iv

PAGE 5

2.4 Summary.................................................................................................................20 3 REQUIREMENT ANALYSIS AND CCS FEATURES................................................22 3.1 Conference Control Service Requirements.............................................................22 3.2 System Requirements..............................................................................................26 3.3 Graphical Interface..................................................................................................26 3.4 Summary.................................................................................................................28 4 DESIGN OF CCS...........................................................................................................30 4.1 Interface with Database Service..............................................................................30 4.2 Interface with Access Control Service....................................................................31 4.3 Controls...................................................................................................................31 4.3.1 Site................................................................................................................32 4.3.2 Conference....................................................................................................33 4.3.3 Roles..............................................................................................................35 4.3.4 Merging of conferences.................................................................................35 4.3.5 Merging of two DCS instances.....................................................................35 4.3.6 Splitting of Conference.................................................................................37 4.3.7 Splitting of DCS Instance.............................................................................38 4.3.8 Import /Export objects...................................................................................38 4.4 Management of applications...................................................................................39 4.5 Summary.................................................................................................................40 5 IMPLEMENTATION.....................................................................................................41 5.1 Message Passing System.........................................................................................41 5.2 Detailed Implementation.........................................................................................42 5.2.1 General Queries.............................................................................................42 5.2.2 Creation of Conference.................................................................................43 5.2.3 Site Creation..................................................................................................45 5.2.4 Inviting A User or Joining Conference.........................................................47 5.2.5 Merging of two DCS instances.....................................................................48 5.2.6 Merging of two conferences..........................................................................48 5.2.7 Conference Splitting......................................................................................50 5.2.8 Splitting of DCS Instance.............................................................................50 5.2.9 Applications..................................................................................................50 5.2.10 Import and export of objects.......................................................................52 5.3 Summary.................................................................................................................52 6 CONCLUSION AND FUTURE WORK.......................................................................54 v

PAGE 6

6.1 Conclusion..............................................................................................................54 6.2 Future Work............................................................................................................55 6.3 Summary.................................................................................................................56 LIST OF REFERENCES...................................................................................................57 BIOGRAPHICAL SKETCH.............................................................................................60 vi

PAGE 7

LIST OF TABLES Table page 2.1 Time and Space view of CSCW....................................................................................8 4.1 Site Global table...........................................................................................................32 4.2 Global Conference Table.............................................................................................33 4.3 Global User Info Table................................................................................................34 4.4 Object table..................................................................................................................38 4.5 Archive application table.............................................................................................39 vii

PAGE 8

LIST OF FIGURES Figure page 1.1 Distributed Conference System (DCS) Architecture.....................................................4 3.1 Main window of CCS..................................................................................................27 3.2 Discussion window of CCS.........................................................................................28 4.1 DCS Instance Merging.................................................................................................37 5.1 Client-Server model for CCS.......................................................................................42 5.2 Conference Creation Wizards for General Information...............................................43 5.3 Sub Conference Creation.............................................................................................45 5.4 Site Creation process....................................................................................................46 5.5 Joining a Conference....................................................................................................47 5.6 Merge menu in main conference window....................................................................49 5.7 Export application........................................................................................................51 5.8 Import Objects from DCS............................................................................................52 viii

PAGE 9

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 Science IMPLEMENTATION OF CONFERENCE CONTROL SERVICE IN DISTRIBUTED CONFERENCE SYSTEM By Ashish Bhalani August 2002 Chairman: Dr. Richard Newman-Wolfe Major Department: Computer and Information Science And Engineering The rapid evolution in the field of technology and information sciences and the boundless yearning among humans along the journey of the growing era have brought a great advancement in the field of communication. This has induced various organizations to put forth better ways of organizing and coordinating work activities with ad hoc task groups along with flexible communication structures. The Distributed Conferencing System (DCS) is a real-time system, which allows sharing of applications, multi-user access to facilities, and greater integration of applications over a Wide Area Network (WAN). DCS v1 had a flat structure of conferences versus the v2 and v2a, which use a hierarchical structure of conferences with a client-server model. The older version (v1) of DCS was designed such that there was a separation of function for group communication and administrative management but with advanced resources and masterminds, the new version (v2 and v2a) was designed, which was different in architecture and implementation from the former one with the primary goal of coordinating all the resources to support a number of group activities, and this was done by coordinating all the components of DCS. DCS v2a supports notification service, ix

PAGE 10

decision support service, access control service, consistent database service, and authentication and security service through which a user can dynamically create objects, modify them, and share tools for writing and editing documents in a shared workspace provided by DCS. In order to operate these services appropriately and efficiently, the Conference Control Service (CCS) provides a more flexible and user-friendly interface. Also it provides additional functionalities, which would allow users to accomplish their work with increased effectiveness. This thesis mainly discusses the CCS, one of the important components of DCS v2a. It elaborates about the role of CCS within the various DCS applications and services. It emphasizes how CCS is primarily responsible for all resources used by DCS and also for initialization of all services supported by DCS. It also discusses how CCS maintains a consistency and integrity among all services supported by DCS and thereby enhances the versatility of DCS. x

PAGE 11

CHAPTER 1 INTRODUCTION The Conference Control Service (CCS) provides a flexible and friendly Graphical User Interface (GUI) to the Distributed Conference System (DCS) to manage conference control activities, shared applications, and resources. 1.1 Overview Fuelled by organizational trends, such as increased teamwork, and technical trends, such as increased availability of networked computing, Computer Supported Cooperative Work (CSCW) has emerged as a promising way of supporting tasks that are carried out by groups of mutually dependent persons. The DCS v2a at University of Florida is a tool to facilitate collaborative work and allow access to shared applications and resources over a Wide Area Network (WAN). A conference is the heart of DCS project through which, user can share and jointly manipulate information. The function of DCS is to support real-time distributed conferences, multi-user accesses and distributed applications for cooperative work. For the DCS to function efficiently, some service, which can provide an easy way to manipulate various activities of conference and information, is needed. More precisely, CCS can be used ideally to achieve this task. This study, thus, focuses on detailed analysis and issues involved in providing this service. 1.2 Definitions The following definitions are provided to understand some of the terms pertaining to DCS. In general, all the terms described below correspond to their standard meaning in real computing community. 1

PAGE 12

2 1. User is an entity, usually human being, which uses resources available in DCS and also initializes various services. In order to access DCS and its objects, a user needs to have user name and pass phrase. 2. Subject is an entity, which can perform action on objects. 3. Resources are atomic (non-divisible) units of the system that can be used for computation and communication. Objects can be composed from the resources. Some examples of resources are disk storages, printer, CPU time, etc. 4. Object is a set of resources. The subjects may access it. This is passive entity. Some examples are documents, files, etc. 5. Role is a collection of permissions and rights bound to a subject at a particular time. 6. Conference is the set of members, roles, applications and objects. 7. Site is the location where information about conferences is stored. 1.3 Conference Control Service DCS requires a user interface, which provides more useful and convenient tools in order to operate effectively. The role of CCS is to provide a list of acceptable alternatives at the same time, not violating security constraints for a smoother functioning of DCS. Also it should contain identification for the conference, the user handle and the role to which the subject is bound. The major issues handled by the CCS are add a new site in a conference, merge two DCS instances, split a DCS instance, delete a site from the conference, add a new conference, delete a conference, merge two conference, split a conference, import and export applications and objects to a conference. A detailed understanding of the CCS will be discussed further. 1.4 Need for Conference Control Service The DCS provides a variety of services. Each of these services enables DCS to perform its needed functionality. The function of the CCS is to manage these services

PAGE 13

3 and resources in the most efficient manner. The various services provided by DCS and controlled by CCS mainly include: Access Control Service, Notification Service, Database and Communication Service, Security Service, Decision Support Service, Conference Control Service. The DCS architecture is shown in Figure 1.1. The access control service controls the access to the objects. Subjects, who have permission, can access the objects through access control service. A user can request to be notified when certain events occurs and have the option to specify how soon or how often he should be notified. This is taken care of by the notification service. Almost all the above services need database service in some form to store information about the various states of the conference. The database used in DCS is the replicated database. This database service is responsible for the replication of updates from one site to other sites. User authentication and secure communication between sites and users is handled by security service. Both, the DCS users and the system, use the group decision process. Decision support service allows group decisions to be made within DCS. DCS uses voting mechanism provided by

PAGE 14

4 Figure 1.1 Distributed Conference System (DCS) Architecture

PAGE 15

5 decision support service for group decision. Conference control service initializes all above services and manages conferences and their objects. Why are CCS and DCS services so closely related? Many DCS services require storing of information in database through database service. The CCS has varied functions, which could be summarized as Initializes database service for the user to store and to query about the various global states of conferences. Initializes the access control service and security service to authenticate user and services. Provides user interface for access control service to add, delete and bind users and roles. Initialize the notification service and provide user interface for notification service from where user can request to be notified when certain event occurs. Conveys messages between subjects of a conference depending on the permissions. Launches applications and manages them. Imports and exports applications to and from conference, if needed. Additionally, it also handles operations related to site and conference, such as joining a conference, adding a site to conference, merging two conferences, splitting a conference, etc. 1.5 Organization of the thesis This study discusses about the implementation of conference control service (CCS) in distributed conference system (DCS). The study design has six chapters.

PAGE 16

6 Chapter 2 describes the previous work done in this area. This chapter presents an overview of existing conferencing system. In chapter 3, CCS features and additional functionality of CCS have been discussed. Also this chapter covers issues involved in design and implementation of these additional features. Chapter 4 concerns itself with the design of the CCS. Chapter 5 deals with implementation details. Chapter 6 provides the conclusion of this study and future work than could be done in this area.

PAGE 17

CHAPTER 2 SURVEY OF RELEVANT WORK The function of the DCS is to support collaborative work and shared applications. Many stems have been developed in the industrial as well as educational world to support collaborative work. Conference Control Service (CCS) is an important component of DCS, which provides flexible user interface and some additional functionality to DCS. Although studies in the past have discussed the components on DCS v1, none of the research has focused on DCS v2a. This is our first attempt focusing on the implementation of CCS in DCS v2a. In this chapter, mainly some of the research related to various groupware systems like DCS v1 has been surveyed. Section 2.1 gives a brief introduction to CSCW and groupware applications. Section 2.2 gives an overview of these groupware applications developed in the past. Finally, we summarize and conclude based on the reviews and we talk about the motivation and need for the development of CCS in DCS v2a. 2.1 CSCW and Groupware 2.1.1 Introduction CSCW refers to how people work together in a collaborative environment using computer technology. General applications include use of email, hypertext, videoconferencing, chat systems, and real-time shared applications, such as collaborative writing or drawing. CSCW opens up or expands the time interval of interaction for groups. Electronic meetings can be at a specific time or members can interact over a time interval. The interface introduces a further flexibility which enables that, the meeting can 7

PAGE 18

8 be between people in the same room or distributed access such as in different rooms, buildings or spread over a wide geographical area. Mainly two dimensions--time and place--can define CSCW domain. The following table illustrates these two dimensions. Table 2.1 Time and Space view of CSCW Same place Multiple places Synchronous -same time possible possible Asynchronous -different time possible possible Groupware consists of Computer-based systems that support groups of people engaged in a common task and that provide an interface to a shared environment [1]. Groupware typically refers to products or working prototypes based on the concept of CSCW. However in budding a groupware, a number of difficulties are encountered, like any other system development. Research in this field has been ongoing to strive to overcome these deficiencies to allow the groupware users to work in a problem-free environment. 2.2 Some Groupware Systems Various groupware prototypes and products have emerged in the industrial as well as educational systems, each of which provides a meticulous functionality to users. Each groupware system is designed to support a particular of cooperative work situation or a particular range of cooperative work situations. Cooperative work settings are very varied in terms of task, duration, group, organizational context and culture [2], and

PAGE 19

9 likewise is the diversity in groupware. Some of the groupware systems have been briefly described below. 2.2.1 Computer Conferencing System Computer Conferencing system is like an alternative to electronic mail systems. Electronic mail systems makes communication possible by sending messages via the computer to one or more persons. Versus computer conferencing systems, allow users to send a message to a uniquely identified group of people who have gathered to discuss about a particular topic. Presence of all the members at the same time is not needed. Messages sent with a conferencing system can be retrieved and responded to by the other members of the group at a later time. 2.2.1.1 EMISARI The Emergency Management Information Systems And Reference Index (EMISARI) was developed by Murray Turoff for the US Office of Emergency Preparedness in 1971, later to be followed by EIES, in 1976 [3]. EMISARI was written under EXEC VIII on a UNIVAC computer, which had newly developed multiprocessing capabilities, making possible the new, interactive functionality that Turoff designed. The EMISARI chat functionality was called the Party Line, which had a range of efficient features, such as a record of the existing participants, and an alert signal when someone joined or left the group. EMISARI also supported real--time voting, data collection assignment and reporting, and discussion threads for individual database elements. 2.2.1.2 Usenet Usenet stands for "User's Network," often called the "newsgroups,” consists of millions of virtual bulletin boards on different subjects available around the world. Anyone with access to the Internet can post a message to any Usenet newsgroup, read

PAGE 20

10 any message, and post a response to any message. The Usenet is functioned by thousands of servers across the Internet that exchange millions of messages each day to distribute new postings so each newsgroup looks almost the same from anywhere in the world. Multiple users can use each newsgroup and in some groups the number of messages can reaches to more than hundreds per day. Sometimes some of the conference systems may support but at the same time develop additional relationship between messages, which could exploit the relation between messages. In other words, it allows presentation of messages to be ordered in threads, the outcome being there is a hierarchy of messages in which responses are ordered under the message they respond to. The most recent conferencing systems allow even worksheets and database to be posted in a most proficient way. 2.2.1.3 Distributed Conference System (DCS) v1 DCS is a distributed system that provides real-time support for collaborative work. It provides a set of shared applications and this enables groups of users to work together to dynamically create and modify text and graphic documents [4]. DCS provides two types of conferences--Short term and long term. A long-term conference remains active till the last member resigns. A log of members, the files and access information is maintained during this period. Short-term conferences have no such logs and they are terminated automatically when the last member exits. Role is another major concept in DCS. The integrity of the conference is maintained by limiting the rights given to the members. Architecture: The Central Conference Server (CCS) is responsible for creating the CMs, maintaining a list of conferences and their addresses along with permitting CMs

PAGE 21

11 to communicate when needed. It also serves as an interface for users who want to create a new conference or join an existing conference. The Conference Manager (CM) controls the discussion window and is responsible for the overall control of the conference. CM is assigned the task of managing the file base, providing the message passing mechanism among the UMs, and maintaining other conference specific status information. The User Manager (UM) acts as a user interface for the individual user active in a conference. The Application Manager (AM) is in charge of the communication between the application and the CM and interacts with the Application Window (AW). Each application has its own (logical) AM. The user interacts with the system through different windows: 1. The Status Window (SW) always exists whether or not the user is inside the conference. It allows users to make motions, request information, open new windows and vote. 2. The Discussion Window (DW) is opened by default when the user joints a conference. All active members of a conference carry on a real-time written conversation through this window. A transcript of the discussion is kept on file so members can refer back to it when they first join or after they have been inactive for a while. 3. The Execute Window (EW) is opened by the user and allows him to access the shell. This window can be exported to other users, allowing them to see the execution in the source window. This is the only window that requires the

PAGE 22

12 user to gain control of it before accessing it. It allows members to view a file or execute a program that handles only ASCII input and output. 4. The Text Edit Window allows a user to work on a document concurrently. It also provides facility for text manipulation like moving, cutting, copying and pasting [5]. 5. The Graphics Edit Window provides users an object-oriented graphics editor based on tgif [6]. Tgif is an interactive drawing tool that allows a user to draw and manipulate objects. DCS v.1 offers support for both extra-conference and intra-conference activities. The user can ask for a list of conferences, can initiate a conference or request to join a conference. If the user is a member of a conference he can make queries, motions and vote. DCS v.1 allows users to be aware of the actions taking place in the conference while they are actively participating. 2.2.2 Chat Systems Chat systems enable text-based computer-mediated discussions amongst users. These systems facilitate rapid turn taking in discussions as each letter or sentence that is typed is immediately observable on the screens of other users. Initially chat systems, such as UNIX talk, acted as a supplementary feature of timeshared operating systems, and provided communication between two users of a network. But now with rapid advancement, systems such as Internet Relay Chat (IRC) provide interpersonal communication for a random number of users connected with personal computers to the Internet.

PAGE 23

13 2.2.3 Electronic Meeting System In multimedia and large--scale organizations, the general managers and staff personals spend large proportions of their time in face-to-face meetings. To increase the effectiveness and efficiency of such meetings, many groupware systems have been developed. The University of Arizona developed an electronic meeting system such as the MIS Planning and Decision Laboratory [7] to overcome the time constraints. It consisted of a room furnished with a large common screen, connected to a set of interconnected personal computers or terminals. GroupSystems and Colab [8], developed by Xerox PARC, are also some of the marketable electronic meeting systems, which work on the principle of the MIS Planning and Decision Laboratory system. The advantages of using these types of systems are: Parallel typing, rapid forwarding and accumulation of ideas--A verbal presentation of ideas requires waiting for a suitable moment to speak, versus with typing, the speed of idea production is increased as people can type ideas in parallel. Thus, parallel typing reduces this kind of production blocking of ideas [9]. The option to remain anonymous promotes proposition of bold ideas and giving candid opinions about ideas. Transferring computer-based information in and out of the meeting is easy. These kinds of applications can facilitate viewing and manipulating electronic documents, such as designs or infrastructures, during a meeting. 2.2.4 Application Sharing Systems In an application sharing system, multiple users can use a single--user application simultaneously without any modification. A single--user image of the application is

PAGE 24

14 maintained by applying some external functions to the single user application. These external functions provide the output from the application to each user and combines input from users in such a way that only one user at a time can control the application. A characteristic for application sharing systems is all the other users can view all the actions performed during the sharing process. In early application sharing system [10,11], each user sees the same at his or her computer screen and there is no private space. Thus, the entire screen is shared. Examples of some of the recently developed systems, in which user just share single application window, instead of the entire screen include--MBlink [12](based on sharing the output bitmaps of programs that run on Xerox workstations), X windows-based tools (such as XTV, shX, SharedX from Hewlett Packard and the application sharing module in ShowMe from Sun), and Cross-platform tools (such as the BERKOM Multimedia Collaboration Service (MMC) [4,5,13-15], Face to Face and Timbuktu Pro, which allow sharing applications between users that use different graphical user interface platforms, such as Apple Macintosh, MS Windows and X windows). 2.2.5 Co-authoring Systems It is an important application domain of CSCW. The rationale of the co--authoring system is that it is supposed to support small groups in their computer based collaborative work, both synchronous and asynchronous and from any place. That is, the co--authoring system is created to support work by several authors, who not necessarily share the same work hours and who might be distributed geographically. It is mostly thought to support groups at a size of 2--6 people, but it can also be useful to individuals and larger group

PAGE 25

15 2.2.5.1 Quilt The function of the Quilt system is to provide a rich set of appendix and definition of social roles as a means for coordinating the authoring process. Quilt’s support for shared documents is based on a shared database that stores texts and interpretation. Annotation for revision and voice or text comments is provided, which are associated via a hypertext link with particular parts of the base document, or with another annotation. Annotations are of three types: Private comments, which are visible only to the creator; Directed messages, which are only accessible to specific users or user groups; and Public comments, which are exposed to all users that may read the base document. Quilt allows multiple users to edit the base document concurrently. If a user is modifying the base document and at the same time another user tries to modify the same base document, Quilt provides a warning to the second user to avoid unwanted conflicts. Further Quilt automatically locks the base document to prevent other users from editing. The key to the underlying strength of Quilt lies in its profuse support for the usage and the hierarchy of social roles. This structure gives rights with respect to certain actions on the shared document and annotations. Rights supported by Quilt consist of--modify, delete, attach revision, attach comment, attach message, attach private comment and read. The units over which the rights may be granted are the base document, suggested revision, public comment, directed message, private comment and history. 2.2.5.2 GROVE The objective of the GRoup Outline and Viewing Editor (GROVE) developed at the Microelectronics and Computer Technology Corporation (MCC) [1,16], was to find

PAGE 26

16 options for a real-time multi--user tool to implement and collect informal observations about its use. A single user initiates a GROVE conferences and he/she specifies the filename of a document that is to be edited. Any user with enough permission and rights can access the conference to edit a document. A noteworthy feature of GROVE is that shared documents cannot be edited extensively. GROVE largely follows the What You See Is What I See (WYSIWIS) [17] concept. It keeps the use informed about any actions performed. GROVE allows concurrent and conflicting operations without locking documents. It uses a special algorithm that utilizes operational transformations to maintain consistency to minimize the response and notification times. However, GROVE does not strictly bind to the WYSIWIS--paradigm. It provides private, shared and public windows to access different items based on user rights. In short, GROVE essentially supports private windows accessible to creator, public windows accessible to all users and shared windows accessible to selected users. Any user may have created each of these windows. Users can also temporarily leave and later rejoin a session. 2.2.6 Group Scheduling and Calendars Systems Scheduling a meeting with a group becomes a lot easier with computer support. Via group scheduling system, a meeting between groups can be arranged even in the absence of certain group members through exchange of special messages. Some of the calendar systems include-2.2.6.1 MPCAL MPCAL (“Multi-Person CALendar) was developed at MIT lab in 1986. MPCAL used role assignment to control access to calendars. The public role only allowed others to see the free/busy times on one’s calendar by default. Each role defined in the system provides the information to which the user has access and is able to manipulate.

PAGE 27

17 Example, a secretary can see all the information in the calendar and can confirm and cancel appointments. 2.2.6.2 RTCAL RTCAL (Real-Time CALendaring) [12] was developed at MIT lab. The application is a decision support system that allows users to collaboratively schedule meeting times such as a thesis defense. It displays both private and public data: for each time slot, it shows to each user, in a shared column, whether slot is free for all users, and in another, private column, the details of any appointment of that user at that time. It supports common scrolling of these so that as users scroll to different time slots, the displays of both the private and public appointments is updated. It does not allow users to privately scroll to private time ranges. It gathers and tallies votes for the users and allows a user to leave and then later join the conference. Users are given the option of ignoring meeting times committed by the group in their absence. User commands are divided into application and conference-control commands. Application commands manipulate the calendar and only the controller can enter these commands at any one time. Conference--control commands are used to pass control and enter and leave the conference. RTCAL system stores the calendar information in centralized database and maintains a consistent view through message passing mechanism. 2.2.7 Videoconferencing Systems Today, the bandwidth of the communication networks has increased significantly. The data transfer rate has increased and hence, the video and audio data can be easily transferred from one network to other. This has lead to the development of prototypes and research systems with a focus on various aspects of video communications.

PAGE 28

18 2.2.8 MERMAID The MERMAID (Multimedia Environment for Remote Multiple Attendee Interactive Decision-making) [18] system has developed based on the group collaboration support architecture. The system supports various collaborative work including, group decision-making, cooperative document editing, cooperative software development, workstation conference, etc. Some of the server and client’s functions are as follows: 1. Conference Management Server (CMS) The CMS controls functions like organizing, opening and closing of conferences, member’s joining and leaving, floor requesting and passing and conference status. 2. Conference Information Server (CIS) The CIS provides information which includes conference’s name, title, date, time, participants’ names, agenda, advance notices etc about the conference upon member request. 3. Document File Server (DFS) The DFS manages retrieving and storing of documents in conference and also helps user to create and process documents. 4. Local Communication Server (LCS) The LCS is responsible for the communication among different domains by sending and receiving of information to/from the multi-domain communication server. 5. Multi-domain Communication Server (MCS) The MCS controls transmission routing and information flow among domains and thereby ensures efficient communication among clients. 6. Client (C)

PAGE 29

19 The clients are the group members who communicate with other servers and clients through user-friendly interfaces. To support above--mentioned functions, MERMAID provides five kinds of windows. A conference window, which provides menus to members to manage the activities of a conference, request to join a conference, etc. A shared window, in which all members share documents. A personal window, which is the same as shared window, however is personal to user and other members do not see the data in the personal window. A video window, which provides multiparty video conferencing tools to users. A status window, which provides the menu for opening all above window except conference window. It also provides the current information about the conference. To facilitate smooth interaction with the system and other members, MERMAID provides large variety of features, which includes, wide area multiparty real time communication, flexible conference support, multimedia communication and presentation, user--friendly interface, etc. 2.3 Motivation for DCS v2a The world of computers is growing each day by leaps and bounds. There is an immense amount to learn each day and because of the evolutionary flexibility and crave among humans to put forth the best to the world, this could be accomplished. Today because of the rapid advances in technology, the world seems to get closer each day. Gone are the days when communication from one part to the other part of world used to

PAGE 30

20 be like something rare or impossible. The cyber world has progressed to such an extent that communication via conferencing is getting easier and unblemished especially in the industrial and educational fields. Motivated by all the literature review of the research done in past put forth stepping stones on the evolutionary road to expand an understanding of the DCS v2a, with its limitations, deficiencies as well as versatility and the role of conference control service in DCS v2a. The DCS v2a at university of Florida is an attempt to provide a facility for synchronous and asynchronous collaborative work on a shared workspace over a WAN. 2.4 Summary Any conferencing application requires an efficient conference control service. Conference applications play a vital part in workgroups. Hence in this chapter, we first discussed about the various groupware systems and delved deeper into the DCS v1. The proposed features of conference control service were then discussed to enable an understanding of the role of conference service, which is fundamental for the development and control of DCS like groupware application. Conference control is used to manage and coordinate multiple users in a conference. It regulates the control both locally and globally. Further, enumerating the various groupware applications, we found that DCS v2a was an upcoming application and very few studies have been done on it. This paper introduces and discusses the features of DCS v2a and talks about how the conference application relies on geographically distributed nodes through communication networks and that there has to be an efficient control service to facilitate this. We reviewed every little aspect of the DCS v1 to ensure that DCS v2a is a step higher without some of the controllable flaws. This study focuses on the communication

PAGE 31

21 integration among geographically distributed groups with a sound and efficient control service.

PAGE 32

CHAPTER 3 REQUIREMENT ANALYSIS AND CCS FEATURES This chapter describes the requirements of the CCS within DCS and some features of CCS. The CCS manages all services within DCS, with its varied features. In DCS v1, user interface, application and network infrastructure were the main parts. Since this version worked in a Local Area Network (LAN) only, it proved to be inefficient in this rapidly evolving era. However, DCS v2 and v2a has a hierarchical structure of conferences with CCS as one of its main components along with the others, and it works in a Wide Area Network (WAN). 3.1 Conference Control Service Requirements The CCS is an important module of DCS v2a. The CCS is the highest level in a DCS for a user through which he/she can communicate with other services available in DCS. The CCS needs to be able to perform the following functions: 1. Initialize all services The CCS initializes all the services supported by DCS and maintains a consistency among these services. This function is like the primary purpose of any service that initializes that system. Therefore, this implies that the CCS has to be capable of supporting the services provided by DCS since it initializes those services. From the programmer’s perspective, it is very important that CCS closely interacts with each of the services of DCS. For e.g. when interacting with Notification Services (NS), the CCS needs to inform the NS about the events like addition of application, addition of role, etc. in a conference, to enable the NS to notify the CCS whenever these events actually occur. 22

PAGE 33

23 The CCS conceals all irrelevant information from the user thus providing transparency in a simple yet effective manner. It hides all the low-level information from the user. A user himself is not concerned with the issues related to storage location, access control details, notification details, etc. The user only needs to have a smooth and flexible interface between these services, which allows him to work effectively in DCS. In a way, hiding such information from the user adds some security measures to the DCS. 2. Add site in the conference Increased availability of resources, despite the presence of failures, is a desirable feature in any distributed system. Various possible failures can occur on a site such as hardware failure (processor, machine, power failure, link failure, etc) or software failure (systems errors, operating system faults, etc.). Even in such cases, there should be an outlet and the user should be able to log on to the system and work efficiently. Hence, adding a site in a conference overcomes these failures in distributed systems. In DCS, all the data of a particular conference is replicated on all the sites that have been added to that conference. This enables the user to log on either of the sites in case he fails to log on a particular site. 3. Delete Sites from conference If the number of users is scarce and the probability of a site failure is less, then it is feasible to delete a site from a conference. Hence this function of deleting a site is rightly carried out by CCS to reduce the overhead of data replication. 4. Create conferences In a collaborative work environment, there are generally issues of common interest amongst some group of people, which they would like to share or delve deeper into.

PAGE 34

24 DCS provides a concept of conference where such discussions would be encouraged in the form that a user could create a conference of his or her own interest and invite other users sharing the same interest to join the discussion and express his or her ideas. 5. Merge two conferences In many organizations, merging small departments or units into one department or unit would be beneficial for value based work, and increased efficiency, productivity and quality of work. Merging allows communicating and collaborating more effectively. The distinctive feature about merging is it does not eliminate the work or features of any of the merging organizations, but instead merges them. Merging organizations often site the ability both to offer better and more comprehensive services and to reduce overhead and administration costs. The CCS also follows the same guidelines and facilitates merging of two DCS conferences. The CCS merging features overcome the problems of name space collision by providing varied options to the users. Merging will require resolution of duplicate names both for users and conferences and site as well. Sometimes when users are the same, then in that case, their rights have to be merged. In case the users are not the same but share a common user name, the administrators of both conferences must resolve this before merging. This topic will be discussed further in more details in the succeeding chapters. 6. Split a Conference Splitting means dividing. On surface, this term does seem to appear as a positive feature of any organization. But at times, when administrative tasks expand incredibly and are difficult to be handled by a single management or organization, it is advisable to divide the tasks amongst groups, which then function independently and still provide

PAGE 35

25 efficient, productive and quality work. In other words, the splitting is for a better performance. The CCS, like the merging feature also has the feature of splitting a conference. It creates new conferences by splitting a conference and moves some of the objects and users from the original conference to the new conferences. 7. Delete Conferences There can be multiple reasons to delete a particular conference from the system. When a conference is created to discuss and share ideas to resolve a specific topic or problem, then in such a case, the conference is deleted once the problem is resolved or discussion is over and all the members of the conference have left the conference. This is the most common reason to delete a conference. To reduce the load on a site, the administrator can enforce all the members of the conference to quit the conference and thus a conference is deleted. In rare circumstances, if the discussion or the debate on an issue in a conference seems to be inconclusive or redundant and the issue continues to be unresolved over an extensive period of time, the conference could be deleted. Either of the members could request to delete the conference. 8. Import/Export objects At times some documents need to be shared to review comments and obtain suggestions pertaining to a particular issue in a conference. DCS provides a way to facilitate this functionality. A user can import or export a document or object and provide his input, feedback or suggestion on the current issue, which can be shared by the other users in the conference. DCS v2a keeps a record of each object stored at different sites so that each site can provide a uniform view of the objects to all users.

PAGE 36

26 9. Import/Export of Applications An application, which is developed outside DCS, can be imported into DCS through CCS. Some applications can be developed within DCS and could be exported into other conferences through CCS. CCS should provide sufficient storage space to store all the applications in archival state. These applications should be such that they could be replicated easily within sites. Management of these applications has been discussed later. 3.2 System Requirements The System requirement for the Conference Control Service Server is Linux OS with postgre SQL database installed and a database named ‘globaldb’ needs to be created before CCS is initialized. The Conference Control Service Client can be installed on any system with Linux OS. Java Programming language has been used to write this module in this thesis. 3.3 Graphical Interface The CCS provides a Graphical User Interface (GUI) to control the activities of a conference. To support these activities, it provides a set of windows to the user. The current implementation of the CCS offers two types of windows-the main window and the discussion window. The conference control takes place through the main window. Members can create/delete conference, merge/split conference, add/delete site, import/export application, and perform various other functions through the main window and its menus (Figure 3.1).

PAGE 37

27 Figure 3.1 Main window of CCS Main window displays information about the list of applications and sites available in a particular conference. This information is displayed to the users, according to the individual role they are bound to. A real time and synchronous communication takes place between the members of the conference through the discussion windows. A discussion window opens by default whenever the user clicks the window sub-menu in the discussion menu on the main window. Every member can access the local discussion window of the conference in which he or she is participating. A member has an active discussion window per conference to which he has logged on. The discussion window has three sections, the output window, the input window and the active users window as shown in Figure 3.2.

PAGE 38

28 Figure 3.2 Discussion window of CCS After the user composes the message to be sent, he or she clicks on the send button and this message now gets displayed in the output window of all the active users. A record of the discussion is kept in the file to enable members to flip back and forth to see when they first joined or whenever they get back after having been inactive for a while. 3.4 Summary In this chapter we have discussed the requirements of Conference Control Service within DCS along with a brief overview on a window-based interface used for interaction between users and DCS. By fulfilling these requirements, the Conference Control Service will provide a smooth coordinated interface besides, supporting efficient and

PAGE 39

29 systematic collaborative work. Flexibility has been provided to allow a user to regulate the functions of conference effectively.

PAGE 40

CHAPTER 4 DESIGN OF CCS We have already discussed about the requirements for CCS. In this chapter we further discuss the design of CCS in DCS. Section 4.1 and 4.2 discusses about the interface of CCS with database service and access control service. It also gives detail about the design of the tables that CCS maintains. Section 4.3 gives overview of some of the control activities maintained by the CCS. Section 4.4 shows how applications are managed in CCS. Finally, Section 4.5 summaries the chapter. 4.1 Interface with Database Service DCS maintains two types of database, Local and Distributed (as shown in the DCS Architecture Fig 1.1). The information in distributed database is replicated to each site under that DCS instance through database service. CCS initializes this database Service. The basic tables required by the database service are created by the command from CCS to the database service. The tables that are required by database service are: 1. glb_conf_Info Conference Id /*unique conference Id for each conference*/ Site Id /*unique site Id for each site*/ Version No /*unique version no*/ 2. glb_conftable_info Site Id /*unique site Id for each site*/ IP Address /*IP address of the site*/ 30

PAGE 41

31 Port # /*Site Port #*/ 3. glb_site_info Conference Id /*unique conference Id for each conference*/ Table Name /*Names of the table for the conference*/ Owner Id /*owner Id of the table*/ Each site under a DCS instance controls a set of global tables, while each conference controls a set of conference specific tables. Like the database service tables, these tables are also created and maintained by the database service though CCS. These tables have been discussed later in this chapter. 4.2 Interface with Access Control Service Access control service (ACS) controls access to various conference objects. CCS initializes ACS. The CCS passes all user requests to ACS. The ACS makes decision by looking up at the access control table. If request is approved, the ACS informs the CCS about the approval otherwise ACS returns vote number or decision pointer. The latter indicates that request is pending and the request has been sent to the request pending table. The ACS informs the CCS whenever the decision is taken on the pending request. The CCS then informs the user about the decision. 4.3 Controls A control devise needs to be formulated so as to preserve the veracity of a conference. The CCS manages all conference activities. The CCS is the primary service in DCS, which also initialize all other services and maintains a consistency among these services. As mentioned earlier, CCS also creates and maintains global and conference specific tables to store information. The site, conference, user and application archival related information is maintained in the global tables. Role information, objects available in

PAGE 42

32 conference, and applications available in conference are maintained in the conference specific tables. The DCS has hence defined its own control mechanism in order to preserve the integrity of the conference objects. DCS by these control mechanisms gives users different roles, which enables these users to limit their access and control. Above all it has a voting mechanism supported by decision support service to improve all conference control activities. The basic control include: 4.3.1 Site Site is the location where information about all existing sites and conferences under a particular DCS instance is stored. Each of these sites maintains global tables that contain information about all other sites and conferences existing on those sites. Table 4.1 Site Global table Site Id Unique Id for the site Site Name Generally the name of the system where DCS server is installed. Site Owner One who owes the site Site Administrator One who creates and manages all activities of that site Administrator Email Contact address for the administrator Generally a user who creates a site is an administrator for that site. Site cannot exist without conference. Whenever a user creates a new site, a default conference, called ‘Vestibule’ is also created. Once the site and default conference is created, the user (administrator) can add more roles, users or/and create more conferences. A user with adequate permission and rights can also request to create a new site within a conference. The request is passed on to the ACS through CCS. A decision support system is then invoked by ACS to make a decision. The members of the conference can make a decision whether to allow the user to create a site or reject his request. Members, who

PAGE 43

33 have the rights to vote on such a group decision, can vote. If request is accepted, user can create a new site. Again if under the same DCS instance, other sites already exist, the new site has to contact one of those existing sites to maintain the global table consistency. 4.3.2 Conference Conference is a heart of DCS. In DCS, the conference has a hierarchical structure. A user can do collaborative work supported by DCS in scope of the conference. CCS handles the requests from the remote member of the conference. It also manages communications among the sites. A user in DCS could create two types of conferences, --New conference or --Sub conference. A user can request to create a new conference in DCS at any time. A request is put to vote in front of conference members. This again depends on the conference policy. If the conference policy defines that a new conference creation requires simple majority, then the access control service checks the conference policy and approves the user to create the new conference as soon as half of the members vote. Thus, the decision to create a new conference is governed by the access control service, enabling the user to create the new conference. Upon creation of the new conference, it is added in the Conference table. Table 4.2 Global Conference Table. Conference Id Unique Id to identify conference across all sites. Conference Name Name of the conference provided by the user. Conference Owner User who creates the conference. Parent Conference Id Conference Id of the parent conference. Home Site Id Site Id on which the conference is created. Date created Date and time conference is created.

PAGE 44

34 Entry for user who created a conference is added to User Info table and user is bound to an administrator role. A new conference by default has two types of roles, admin role, which is an administrator role for user who creates a new conference and member role, with least amount of rights. The new conference becomes the child of the parent conference. An administrator at any time can changes the rights and permissions of roles or adds new roles in the conference; he is the only member in the conference. The status of the conference is set to active if any member is active in conference. Table 4.3 Global User Info Table. User Id Unique User Id generated by database service. User Name Unique username Password Pass phrase used to log onto conference First Name First name of the user Last Name Last name of the user Email Address Valid email address. City City of residence State State of residence Zip Code Residential Status Position/level within the organization. A user can also put a request to create a sub-conference, which is a conference created by importing objects, roles, users, and/or applications from the parent conference. After the user has decided all the roles, objects, users and/or application that he wants to import from the parent conference, this sub conference creation request is put to vote in front of the parent conference members for permission to import depending upon the conference policy. During this period, the new sub-conference that has been created is set to ‘inactive’ and during this inactive period, if any of the conference members try to log in to the conference, he/she get the ‘access denied’ message. As soon as permission to create a sub-conference is granted, the CCS sets the new sub-conference status to ‘active’ and users are thereafter permitted to log in to the conference.

PAGE 45

35 4.3.3 Roles The DCS supports Role Based Access Control mechanism. A member can be bound to multiple roles in the conference, but at any given time, he must be bound to a single role only. Access permissions and privileges can be defined on roles and a user has rights and permissions according to the role he is bound to a particular time. Roles are created so as to let more people chip in and at the same time maintain the integrity of the conference system by providing limitations to some members and enough permission to other members, depending upon the role of a user. 4.3.4 Merging of conferences A user can request to merge two conferences. If the first conference members decide to merge, the request is sent to the second conference. The second conference also puts request in front of its conference members. If the second conference is inactive at that time, the request is appended to its list of pending activities, so its members can vote on it whenever the conference is reactivated. If the second conference members also decide to merge, the merging is performed. Merging is performed only after both the conferences agree to merge to avoid the unnecessary motion in the conference. The administrator of both the conferences has to resolve the name collision issue before the actual merger. 4.3.5 Merging of two DCS instances Merging a site is also an access type in DCS.A user who has permission to merge DCS instance, generally an administrator, can request to merge two DCS instances and then wait for the permission to be granted. However this depends on the conference policy. If policy is set such that no votes are required for merging, a user does not need to wait instead can send the request of merging to the other DCS instance directly. The

PAGE 46

36 second DCS instance then puts the request of merging in front of its members. If he gets an approval, the merging is executed. One such scenario is shown in Figure 4.1. Merging is unsuccessful, if any name collision exists. As shown in Figure 4.1, the DCS instance 2 has site name Site 1 and Site 2, which are the same as in DCS Instance 1. In such a case, the administrator of both the sites need to resolve this name collision before the merging takes place. The global tables are updated and new information is added in the corresponding global tables accordingly. Also a new set of conference specific tables is created and corresponding information is added. The administrator has to also resolve the name collision between conferences, roles, objects or applications, if there is any, before the merging of the two DCS instances.

PAGE 47

37 Figure 4.1 DCS Instance Merging 4.3.6 Splitting of Conference A member, who has a permission to split the conference, can put the request to split the conference in front of members of the conference. As per the conference policy, the members of the conference vote on the request and if they agree to split the conference, a user can split the conference. A new set of conference specific tables is created. All the objects and applications of the original conference are copied to the new conference. The

PAGE 48

38 information of the members, who agree to join the new conference, is also moved to the new conference. A new conference entry also adds in the conference table. All roles are also moved to the new conference. After splitting, the members of the new conference can modify and delete files and objects available in that conference independently. 4.3.7 Splitting of DCS Instance The splitting of DCS instance is kind of a reverse process of merging. Generally an administrator can request splitting of DCS instance. A new DCS instance needs to be first initialized at some place. The IP address and port number of the new DCS instance are sent to the existing DCS instance, which want to split. Again, the vote is put in front of the existing members and if permission is granted, the CCS moves all the objects and applications available from the existing DCS instance to the new DCS instance. As far as conferences are concerned, the only ones that agree to be split are moved to the new DCS instance. After splitting, members of the conferences at new DCS instance can modify and manage all the resources available at that DCS instance in their own ways. 4.3.8 Import /Export objects A user with enough permissions and rights can import or export an object from or to the DCS file space. The CCS maintains an object table to keep record of the objects available in conference. The format of the object table is shown below (Table 4.4) Table 4.4 Object table Object Id Unique object Id generated by CCS Object Name Name of the object Description Description of the object Owner Name of the owner of the object Location Location of the object in conference Operation Operations that can be performed on the object Creation time Time when the object is imported

PAGE 49

39 The user who imports the object in conference automatically becomes the owner of that object. 4.4 Management of applications Applications exist in any of the three forms: archival state, executable state or registered state. The application in archival state consists of its source code, documentation and any auxiliary files for compilation and execution [19]. Some of the advantages of keeping application in archival state are the applications are easily transferable within sites, and they could serve as backup when originally installed applications have been corrupted or damaged. The applications in this state are stored under the DCS/application/archive directory. The record for each archive application in CCS is stored in an archive application table. The format of this table is shown below: Table 4.5 Archive application table Name Name of the application Description Description of the application OS List List of the operating system on which the selected application can run Path Initial location of the application Replica locations The address of the systems where the selected application has already been replicated Creation time The time when application was stored in archival directory Operations The list of operations that can be performed on application. A user with sufficient access permission and rights can request a copy of these archive applications. Once the copy is received, the user can unpack it and install it on the local system. The application is now said to be in executable state, and this state consists of executable files of the application, configuration files, and other auxiliary files for execution [19]. For an application to be executed it has to be registered. Before any member of a conference can launch this application, it has to be registered with the

PAGE 50

40 conference. Once the application is registered, it is now said to be in the registered state and is ready to be launched. The advantage of the application in registered state is that the access and use of application can be controlled. 4.5 Summary The CCS provides mechanism that result in flexible and smooth control over the conference members, objects and activities. A modular design of CCS provides easy addition of alternative user interfaces and conference facilities. It also provides multiple site access to user if a user fails to log on at one site. With its additional features, a user can easily manipulate and control DCS instances, sites and conferences.

PAGE 51

CHAPTER 5 IMPLEMENTATION The CCS implementation uses the client-server model concept. All user interfaces are the clients of a server. All interfaces are based on messages that represent events or operations of the clients and the server. The Site Server (SS) is the server for the Conference Servers (CS) under a single DCS instance and the Conference Servers are the servers for the User Managers (UM). The UMs are the user interfaces that act as clients for Conference Servers (Figure 5.1). This chapter discusses the messages that are passed between the clients and servers of the DCS and how they are handled. It includes a description of the format of the messages and summary of important techniques used throughout the implementation. 5.1 Message Passing System The DCS uses request and reply communication model to support the communication needs of the DCS objects. The DCS also uses basic message passing communication model to support some of the other communication needs. This kind of structure forms a protocol, which provides a clear interface between SS and CS, CS and UM. The DCS v2 uses JAVA RMI to support its communication needs. The RMI supports the creation of remote objects, which are accessible by clients. All Site Servers and Conference Servers bind their remote objects to rmiregistry. The rmiregistry always runs on well know ports. 41

PAGE 52

42 Figure 5.1 Client-Server model for CCS 5.2 Detailed Implementation The Conference Server receives input from the UM. The requests handled by Conference Server include queries from UMs, creating of conferences, joining and exiting a conference, merging and splitting of conferences, adding a site to conference, deleting a site from the conference, merging and splitting of DCS instances, import and export of applications and objects. The following sections discuss each type of requests received by the Conference Server and the actions involved in satisfying these requests. 5.2.1 General Queries Members of the conference can make queries to the CS. The types of queries confronted are with the list of conferences, their descriptions, list of active users in the conferences, list of sites in the conference, list of roles available in conference, list of applications available in conference, etc. The CS keeps an updated list of conferences,

PAGE 53

43 which holds the information needed to resolve these queries. The CS checks with the access control service whether user has the permission to execute the query. If access control service gives permission, the CS then executes the query and sends the result back to the UM. 5.2.2 Creation of Conference There are two ways through which a user can create a conference as discussed in previous chapter. A user can create a new conference or he can create a sub conference. When a user requests to create a conference, the UM asks user for following information (Figure 5.2): Figure 5.2 Conference Creation Wizards for General Information The UM sends the new conference name, the conference owner, home site, parent conference name and site name to the CS. CS submits the request to ACS. ACS returns with one of the parameters which either give permission, deny request or come up with

PAGE 54

44 an error message in the form of an ‘integer’. CS will create the response message depending upon the integer returned by ACS and will then send this message to the UM. When the request is accepted to create new conference, the UM shows the message indicating that conference has been successfully created and the user can now log on to the new conference. In case of the request to create a sub conference, upon successful creation, the UM provides an option to transfer all or selected user roles, users, objects and applications that the user wants to import from the parent conference. The Figure 5.3 shows one of the screens (for roles import) seen. Similar screens for objects, users, and applications also appear consecutively. Once the user has completed the process of selection, the UM submits this information to CS. CS initializes ACS to store the information about the rights and permissions granted to these selected roles, objects applications and users. CS then creates required tables and adds this information to the tables. It also updates the global tables to maintain a consistency among all the sites under a single DCS instance. CS also notifies all the users of the new sub conference through NS. The user now gets the message of conference successfully created and he/she can log on.

PAGE 55

45 Figure 5.3 Sub Conference Creation 5.2.3 Site Creation When the SS first initializes, it creates a site on which its functions later. The SS then initializes the CS for the default conference ‘Vestibule’. The CS initializes the UM, which gets the information from the user about the site to be created and the default conference as shown in Figure 5.4 When user initializes the SS for the very first time, he does not need to provide Existing Site IPAddress and Existing Site Port #. But if user creates another site under the same DCS instance, he has to provide the IP Address and port number of one of the formerly created site in order to maintain integrity among the sites. Once the user provides all the above information, the CS initializes all the other services including CCS.

PAGE 56

46 Figure 5.4 Site Creation process CS besides creating the default conference –‘Vestibule’ also binds the user to an administrator role. It also binds the services provided by the CCS and Communication Module to the rmiregistry. It also creates global and conference specific tables. It further starts with a UM for an administrator. It also creates archival application space to store the archival copy of applications. DCS server initialization file is also created by it, which it refers to when it starts the next time to avoid the unnecessary repetition of creation of tables. A user can also add a new site to an existing conference.

PAGE 57

47 5.2.4 Inviting A User or Joining Conference Any user can request to join the conference at any time. The members of the conference can also invite a user to join the conference at any time. A new user can request to join the conference through UM. When new user starts UM, he gets the screen as shown in Figure 5.5. Figure 5.5 Joining a Conference A new user provides user name and password as “DCS User”. He also provides his personal information and contact information (seen in Figure 5.4--user information screen). He is then provided the list of the conferences available on that site. The UM submits all this information to CS. The CS further checks with the ACS whether to give access to the new user depending on the conference policy. If access is permitted, the CS informs the user through NS and then user can log in to the conference. An existing user has to provide the user name and password; select the site name from the list. He then has to select the conference and role to which he wants to bind to and

PAGE 58

48 this finally enables him to log in to the conference. If the user is not a member of the conference, a log in failed message is sent back to the UM telling the user ‘incorrect username or password’. When a user wants to invite a new user, he can send an email notification to the new user to join the conference. The CS sends this email through NS with conference name and site information. Once the new user gets the email and he decides to join the conference, he has to go through the same procedure like he were joining a conference as seen in Figure 5.5. 5.2.5 Merging of two DCS instances DCS instances are basically collections of sites and conferences available on these sites. Merging of two DCS instances is a special feature of DCS. When members of one DCS instance agrees to merge with another DCS instance, a request is sent to the other DCS instance about the merging through email. After the agreement, the administrator of both instances resolve the name space collision issue and all other issues related to the merger. Finally, when members of both instances are in compliance, the merging is performed. 5.2.6 Merging of two conferences CCS carries out merging of two conferences. When the members of a conference, say for instance Conference A, agree to merge with another conference--Conference B, the administrator of Conference A or the user, who has the right to merge conferences,

PAGE 59

49 Figure 5.6 Merge menu in main conference window selects the “merge request” from the conference menu as shown in Figure 5.6. He/she has to select the name of the conference he wants to merger to (in this case Conference B) from the conference list, the name and email address of the administrator of that conference and the site name and submit this information to the CS. The CS notifies the administrator of Conference B by email through the notification service. If the members of conference B agree to accept the merging request of conference A, the administrator of Conference B selects ‘merge accept’ from the conference menu. Once the administrator of conference A gets the acceptance from conference B, he then selects ‘merge conference’ from the conference menu. A new conference name, say for instance in this case Conference AB, the new administrator name parent conference and home site are to provided based on the decision of members of both the conferences. In case of name space collision, the administrator of both the conferences have to resolve those issues

PAGE 60

50 first. The CS provides the option where administrator can select the objects with the same name and make them same in newly merged conference. The CS performs actions depending up on which option user chooses. 5.2.7 Conference Splitting CS plays a key role even when a conference needs to be split. If members of the conference agree to split a conference, the UM asks user to provide a new conference name and home site name. A user has to also provide as to who the new conference administrator would be Figure 5.4 Conference Information Screen). When the required information is provided, UM sends this information to CS, which then provides on option of transferring users with roles, based on who agree to move, from original conference to the new conference. All the objects and applications are copied to the new conference. Once the splitting is successful, both the conferences can manage their objects and applications independently. 5.2.8 Splitting of DCS Instance To split a DCS instance, a user needs to provide a new DCS instance name, IP address and port number of new DCS instance. It is very important that this new DCS instance has to be initialized on that address so that the existing DCS instance can communicate with it while the split is taking place. The sites and conferences under the original DCS instance are split among the original DCS and the new DCS instance and this split is generally based on the administrative and its member’s decision. 5.2.9 Applications The UM provides archive menu under application through which user can import, export, replicate or delete an application. When user selects to ‘export’ an application, the following screen pops up (Figure 5.7). After user fills all the information, he clicks

PAGE 61

51 export button. The UM send this information to CS. CS creates a new record in archival application table and also saves the archival pack of application in DCS/application/archive directory. Figure 5.7 Export application When user selects to ‘import’ an application from an archive directory, he gets the list of applications available for import. From the list, the user can select the application he wants to import and click the import button. The UM requests the destination and copies the application to the destination. The replication of an application is same as importing an application. The only difference between importing and replicating is that in the former application is copied to the user’s file space while in the latter the application is copied to other sites under a single DCS instance. The user interface for the deletion of

PAGE 62

52 an application is the same as for the import application. However in deletion, the copy of an application is removed from the local site. 5.2.10 Import and export of objects A user can import or export objects by selecting ‘import’ or ‘export from the file menu on the main window. When user selects to export an object, he needs to provide the information same as shown in figure 5.7. The UM sends this information to CS. CS stores this information in object table and copies the object to the conference file space. When user selects to import an object, he gets the list of available objects as shown in Figure 5.8. He then selects the object and clicks the ‘Import’ button. The object is then copied to the users file space. Figure 5.8 Import Objects from DCS 5.3 Summary This chapter describes the message passing mechanism that CCS objects use to interact with each other. A simple and well-defined protocol is formed by this

PAGE 63

53 mechanism to provide a clear interface between various components of the CCS. The steps involved in satisfying the requests made by different controls have been explained in details in case a new site or conference needs to be created, two conferences need to be merged or a conference needs to be split.

PAGE 64

CHAPTER 6 CONCLUSION AND FUTURE WORK 6.1 Conclusion The Distributed Conference System (DCS) enhanced with, a rich set of mechanism for a conference management, provides collaboration and support concurrency amongst its users. The DCS v1 was designed to support alternative user interfaces and facilitate the addition of shared applications. With the evolution of a new paradigm in the field of CSCW and to meet with the increased demands for highly developed and structured distributed computer systems and groupware applications, DCS v2 evolved at the University of Florida and has been an area of research since early nineties. The work on this thesis began with the aim of implementing the Conference Control Service (CCS) within the DCS v2a. The CCS was successfully implemented and met the objectives and requirements stated earlier. The accomplishments made, after working with the DCS v1, were scrutinized. The limitations encountered with the DCS v1 were taken into considerations while designing and implementing CCS in DCS v2a. DCS v1 was split into three sections – user interface, network infrastructure and applications without a separate CCS unlike DCS v2a. DCS v2a has a separate access control service, conference control service, database service, notification service, decision support service and security service. CCS plays a key role within the DCS v2a. It is one of the most vital components of DCS v2a. It provides a flexible user interface to each of its member. CCS with its varied functions can initialize the database service, access control service, provide user interface 54

PAGE 65

55 to add or delete roles or users, initialize notification service, launch applications, import or export objects or applications, merge conferences, split a conference and handle operations related to a conference. Management of the applications in CCS is carried out in a systematic and efficient way at each DCS site. These applications exist in archival, executable or registered state in CCS so that they could be easily installed, retrieved, replicated or deleted from DCS sites and conferences. The characteristics and the role of CCS in DCS v2a have been shown in detail in this study. As DCS v2a is intended to work in a collaborative environment, it should have a robust mechanism to control various activities of the conference. CCS is capable of this and by its interaction with other supported services, is successful in making DCS v2a function fruitfully. Overall, we were able to attain considerable improvement in the DCS v2a by implementing CCS over WAN. 6.2 Future Work There are some functions that can be added in future to overcome some of the limitations of CCS. By incorporating new and advanced features, the functionality of CCS can be amplified. Some of these features mentioned below could be considered for future work. --There is no provision to upgrade an application once the application is stored in the archive state as CCS adds a new entry each time the application is imported to the archival storage. --Implementation of different types of interfaces could be performed to allow members to customize their environment. In other words, the graphical user interface of CCS can be customized to provide more functionality and ease of use.

PAGE 66

56 --More security measures need be applied on RMI calls among sites and also between conference servers and user managers. --The current version of CCS allows the merging of any two conferences under a single DCS instance. In future, this function of merging could be extended by allowing the merging to take place between conferences across two DCS instances. -Also in the current version the administrator or user performing the merger, has to resolve the name space collision issue before merging the two conferences. This sometimes affects user activity. For example, if users in the two conferences to be merged have the same username with different rights, then both these users have to wait and cannot access the merged conference until the issue of same username is resolved. In future, a simpler way needs to be developed so that the administrator can resolve such issues without affecting user activities. 6.3 Summary This thesis showed a model of how CCS functions within DCS and that it plays a key role in interacting with all the other important components of DCS. It is like an important cable, which is interconnected to all the components of DCS for smooth circuit. It is the strongest link between the user interface and components of DCS. The current implementation mainly is a concept better understood than described.

PAGE 67

LIST OF REFERENCES [1] Ellis, C.A., S.J. Gibbs and G.L. Rein, “Groupware: Some issues and experiences” Communications of the ACM, 34 (1991), 1, p. 38-58, 1991. [2] Hinssen, P.J.H., “What difference does it make? The use of groupware in small groups”--Telematica Instituut Fundamental Research Series Telematica Institute, Enschede, the Netherlands, in press, vol. 002. http://www.telin.nl/publicaties/1998/scout/scout.htm , 01/02. [3] Hiltz, S.R. and M. Turoff, “The network nation: Human communication via computer” Addison-Wesley, London, 1978. [4] R.E. Newman-Wolfe, C.L. Ramirez, M. Montes H.K. Pelimuhandiram, M. Webb, and D.L. Wilson, “A brief overview of the distributed conferencing system (DCS)” University of Florida Department of Computer and Information Sciences and Engineering, Gainesville, 1991. [5] R.E. Newman-Wolfe and H.K. Pelimuhandiram, “Mace: A fine grained concurrent editor” Proceedings of Conference on Organizational Computing Systems, Atlanta, Georgia, p. 240-54, November 1991. [6] R.E. Newman-Wolfe, M. Webb, and M. Montes, “Implicit locking in the ensemble concurrent object-oriented graphics editor” University of Florida Department of Computer and Information Sciences and Engineering, Gainesville, 1991. [7] Applegate, L.M., B.R. Konsynski and J.F. Nunamaker, “A group decision support system for idea generation and issue analysis in organization planning” Computer Supported Cooperative Work 86, p. 16-34. [8] Stefik, M., G. Foster, D.G. Bobrow, K. Kahn, S. Lanning and L. Suchman, “Beyond the chalkboard: Computer support for collaboration and problem solving in meetings” Communications of the ACM, 30, p. 32-47, January 1987. 57

PAGE 68

58 [9] Nunamaker, J.F., A.R. Dennis, J.S. Valacich, D.R. Vogel and J.F. George, “Electronic meeting systems to support group work” Communications of the ACM, 34, p. 40-61, July 1991. [10] Engelbart, D.C. and W.K. English, “A research center for augmenting human intellect” Proceedings of Fall Joint Computer Conference, San Francisco, USA, vol. 33, AFIPS conference proceedings, p. 395-410, December 1968. http://www.histech.rwthaachen.de/www/quellen/engelbart/ResearchCenter1968.ht ml , 01/02. [11] Engelbart, D.C., “NLS teleconferencing features: The journal, and shared-screen telephoning” CompCon75 Digest, September 9-11, 1975. IEEE, Los Alamitos, CA, USA, 1975, p. 173-176, http://www.bootstrap.org/augment-33076.htm , 12/01. [12] Sarin, S. and I. Greif, “Computer-based real time conferencing systems” Computer, 18, 10, p. 33-45, 1985. [13] Abdel-Wahab, H.M. and M.A. Feit, “XTV-A framework for sharing X window clients in remote synchronous collaboration” Proceedings of IEEE Tricomm’91: Communications for distributed applications & systems, Chapel Hill, NC, USA, 1991. IEEE Computer Society Press, Los Alamitos, CA, USA, 1991, p. 159-167. [14] Altenhofen, M., B. Neidecker-Lutz and P. Tallett, “Upgrading a window system for tutoring functions” Proceedings of the European X window system conference, London, November 12-14, 1990, CEP Consultants, Edinburgh, UK, 1990, p. 37-44. [15] Garfinkel, D., B.C. Welti and T.W. Yip, “HP SharedX: A tool for real-time collaboration” Hewlett-Packard Journal, 45 (1994), 2, p. 23-36, April 1994. http://www.hp.com/hpj/94apr/23to36.pdf , 01/02. [16] Ellis, C.A., S.J. Gibbs and G.L. Rein, “Design and use of a group editor” In G. Cockton (ed.), Engineering for human-computer interaction: proceedings of the IFIP TC2/WG2.7 working conference on engineering for human-computer interaction, Napa-Valley, CA, USA, 21-25 August 1989. North-Holland, Amsterdam, 1990, p. 13-28.

PAGE 69

59 [17] Stefik, M., D.G. Bobrow, G. Foster, S. Lanning and D. Tatar, “WYSIWIS revised: Early experiences with multiuser interfaces” ACM Transactions On Office Information Systems, 5, p. 147-167, April 1987. [18] Watabe, K., Sakata, S., Maeno, K., Fukuoaka, H. and Ohmori, T, “Distributed Multiparty Desktop Conferencing System : MERMAID” Computer Supported Cooperative Work 90 Proceedings, p. 27-38, October 1990. [19] Li, Ling, “File Services for a Distributed Conferencing System (DCS)” Master’s Thesis (M.S.) University of Florida, 1995.

PAGE 70

BIOGRAPHICAL SKETCH Ashish D Bhalani was born in Gujarat, India. He completed his undergraduate studies in engineering from L.D College of Engineering, Ahmedabad, India. He worked for a year with Yagis Networking Services as a Network Administrator. He joined the University of Florida in 1999 to pursue his master’s in computer and information science. 60