Using Asp to Implement Role-Based Collaborative Meeting System

Using Asp to Implement Role-Based Collaborative Meeting System

Liangkun HE

Dept. of Computer Science and Mathematic, NipissingUniversity

North Bay, Ontario, P1B 8L7Canada

and

Haibin ZHU

Dept. of Computer Science and Mathematic, NipissingUniversity

North Bay, Ontario, P1B 8L7Canada

ABSTRACT

Applications of the collaborative systems have gained more and more concerned in the information system research fields in recent years. Due to the facilitation of coordination, access control and expansibility in the implementation of collaborationsof collaborative systems, role-based collaboration theories have developed very fast, and a variety of models and cases systems of that have been proposed for several years. Theories need demonstrations, however, but collaborative systems are commonly complex, big and difficult to be implemented. We surely do not needn’t toimplement a system for every models and theories, but we should find a way with which can is easy to develop and can show the essentials of collaborations. In this paper, we would like to introducepresent how to use ASP to implement a specific collaborative meeting system and point out the analyzing methods and the features needed required on in role-based collaborations.

Keywords: ASP, Collaboration, Meeting system, Role-based, Implementation.

1. INTRODUCTION

Within the Computer Supported Cooperative Work (CSCW) community,much recent work has focused on building varied collaboration model. Applying role mechanism into collaboration implementation can produce derive many benefits in facilitating system objects interaction and security control. Therefore, role-based collaboration is becoming one of the most important branches of the CSCW.

Many collaboration models and theoriesrelevant roles like such as Role-based Based Access Control (RBAC) [1] were proposed in recent years ago and some collaborative systems were developed on the basis of them, such as Lotus, GroupSystems, etc[2,3]. As we all know, it building a practical system is the best approach to demonstrate the validity and efficiency of a model or theory. However, the quantity of the implementation is much less than that of the models or theories themselves. Whether a model is practical or not might result in that???, but we believe that the most important point is the difficulties of the implementation. The A collaborative system has complex relations between different objects, and involves not only the software and network system designs but also the relative hardware structures. We should find the direct and efficient approaches to implement the essentials of the collaborations rather than the whole system with unnecessary contents.

To be a collaborative system,the fundamental requirementsare both virtual face-to-face collaboration platform or environment and effective communications. Active Server Pages (ASP) and Rational Database (RDB)(use ……(ADO) to get data from various databases) meet the requirements. ASP allows specifications for data presentation to be embedded within HTML text, and the specifications can be written in a server-side programming language (VBScript or JavaScript). From our implementation, we found that ASP is anideal tool to implement a new type of collaboration model because it is easy to compose new ideas, new concepts, and new structures with it. It saved us much effort to consider the underlying facilities to manage distributed processing, such as information sharing, message passing and concurrency control.

In order to illustrate the collaborative system design with ASP, wesupposed to implement a specific web-based collaborative meeting system based on a collaboration model. We will present some approaches in the collaborative system design, which support more flexibility for user’s privilegeschangeand interactions among roles. Moredynamic features are introduced in our implementation, whichdemonstrates that collaborative systems with dynamic roles are beneficial and practical.

This paper is organized as follows. After the summary of the specific collaborative meeting system, we argue on some mechanisms and analysis methods of the role-based systemsneeded such as Dynamic Role Definition (DRD)

and Collaborative Communication Mechanism (CCM). In the following section, it describes all the main approaches to implement the main features of the role-based collaborative meeting system. The last section concludes the advantages and disadvantages in using ASP to implement role-based collaborative systems.

2. A COLLABORATIVE MEETING SYSTEM

The collaborative meeting system we will developedstimulates simulates a virtual face-to-face asynchronous meeting system, which implements collaboration with a conventional interface without media, chalkboard, etc. Hence it has to meet the following objectives:

A fundamental requirement is providing some coordinated interfaces for all users or roles.Such multi-user interfaces is intended to let users interact with each other easilyand immediately in a meeting;

Any user can apply for creating a new meeting withrequired information, and the meeting would be created by the system administrator, a default role in the system;

Only the role with create meeting right can appoint ??? the Role Manager, which is the a role with the role manage right, . This role isand in charge of roles creation, roles management, user assignment and giving responseds to the applications about for roles;

Any user can apply for joining a meeting to be a member and playing a certain role, if he or she is accorded with the role requirements;

Any user holds the least rights, and can play more than one role in the system. But only one role can be played in a meeting at a time;

Any meeting member can sense view the meeting status, the rights and responsibilities he or she holds; and

Meeting events or tasks include posting reports, asking or answering questions about reports or the meeting, and voting reports. The events will be available when the meeting status adhering to the event conditions and the member holding the corresponding rights as well.

Figure 1 illustrates the processes of the collaborative meeting system.

3. ROLE-BASED COLLABORATION DESIGN

A Framework for Role-based Meeting Collaboration Framework

Unclear role specification may create ambiguity and conflict in an organization[4], therefore clear role specification is important to collaborative system design. In recent works on thinkletThinklet, roles are defined as a set of rules that enable or constrain activities with the use of specific capabilities [5].It Our previous work has figured out two aspects of the concept of the role: one is the right, and the other is

Note: valid role in processes shown in the dashed panes
Figure 1: Collaborative Meeting System Process

and the other is the responsibility [6].Refer to the RBAC model [1], the role-based collaborative system framework is designed in the figure 2 and is defined as follows:

Note: Ri&e = Rights & Responsibilities
Figure 2. System Framework

U, Ro, Ri, T stand for users, roles, rights & responsibilities and tasks

RA  Ri×Ro ：is a right/responsibility-to-role many-to-many assignment relation (Role Assignment)

UA  U×Ro ：is a users-to-role assignment many-to-many relation (User Assignment)

Intuitively, a meeting is a group in collaboration; a user is a human being or an autonomous agent; a role is ajob function or title within a meeting with some associated semanticsregarding the rights and responsibilities conferred on a member of therole. A user can play many roles anda role can have many users to play. Similarly, a role can have many rights and responsibilities and the same rights and responsibilities can be assigned specified into many roles. [1]

Problems of Implementation ofIn The Collaboration: Analyzing the system framework, we can point out two difficulties. The first difficulty lies in two relations and two assignments.

Relation between roles

Relation between rights and responsibilities

Role Assignment (RA), and

User Assignment (UA)

To solve this difficulty, we will propose a Dynamic Role Definition (DRD).

And the second difficulty lies in communication between different objects.

Communication between roles (Ro) and users (U)

Communication between users (U), and

Communication between roles (Ro) (We would not talk about it in this paper.)

To solve this difficulty, we will build an effective Collaborative Communicative Mechanism (CCM).

Dynamic Role Definition

Relations bBetween Roles: There exist three relations in roles.

Isolated relation

Inherited relation, and

Exclusive relation

To clarify these relations in roles will simplify the processes in defining roles and user assignment.

Relations bBetween Rights and Responsibilities: On the whole, there are three relations between the permissions.

Isolated relation (Desired)

Reliant relation (Avoid)

It means these kinds of rights or responsibilities must coexist. They must be both prohibited or permitted, e.g. role definitionand role management. We can combine tow rights or responsibilities into role management to avoid the relation reliant.

Exclusive relation (Avoid in coding)

It means these kinds of rights or responsibilities must be assigned to different roles, e.g. moderation and report.

Dynamic Roles:By dynamic roles, it means mainly two aspects as follows,

Dynamic Role Assignment

It means the role Role Manager can define roles when the system is running.

Dynamic User Assignment [6]

The Role Manager can assign roles to users after the role definition. There are two ways in user assignment. (1) Active. : That is tthe roles are assigned directly by the Role Manager.(2) Passive. That is: the roles are assigned on basis of the application of the user, but he or she must meet the requirements of the role set by the Role Manager on role definition. Moreover, roles can be revoked or reassigned by the Role Manager.

Dynamic Roles Definition: Within the RBAC model, Access Control Matrix is the simplest way to define roles [1]. In our meeting system, the rights or responsibilities are listed as follows:, (1) Create the mMeeting creation (Create); (2) Roles management (Role manage); (3) Moderate the meeting (Moderate); (4) Post rReport postings (Report); (5) Asking or answering questions (Q/A); and (6) VoteVoting. Based on the analysis above, we should avoid the exclusive ??? and reliant rights or responsibilities, and avoid the exclusive roles??? as well. For example, we can define dynamic roles in this way as table 1.

Right&Resp-
onsibility
Role Name / Create / Role manage / Moderate / Report / Q/A / Vote
Creator / × / ×
Moderator / × / × / ×
Member / × / × / ×
Table 1. Creation of dynamic roles

There are three roles in this meeting as shown in Table 1., Creator, Moderator and Member, and they have the different rights and responsibilities, e.g. Creator is in charge of the role manage right; Moderator will moderate the meeting and can ask or answer questions in the meeting.

Default Roles and Least Rights: Administrator, which is the only one default role in the system, is responsible for accepting create meeting applications, and thencreates the meeting for the applicant. But in a meeting, Creator is the default role. So Administrator will also create default meeting role Creator for the applicant. Creator holds the create meeting right as well. What’s more, all users holds the least rights so that users could commit some basic operations, such as sending the create meeting application, joining a meeting etc.

Collaborative Communication Mechanism

In order to deal with the communication problems between different users in the collaborative systems, we propose Collaborative Communication Mechanism (CCM) here.

Communication Bbetween Users and Roles: Users commit operations by roles in the role-based collaborative systems. Therefore there must be some problemsin communication between users and roles. For example, that a user sends a role assignment application to the role Role Manager, that means the user sends a message to the userswho are holding the role manage right. The applicant does not needn’tto know who is playing this role exactly, but all the users with such right will receive this application. This kind of communication is called Collaborative Message (CM).

Communication Bbetween Users: In the example above, when the Role Managercommits or refuses the application, the communication takes place between the certain Role Manager and the applicant. Because the receiver and sender areaffirmative for us nowdefinite, therefore we can apply with a user-to-user communication approach called Collaborative Short Message (CSM).

Communication Data Format: The CMs or CSMs should be formatted before they are sent. The data in the communication includesa receiver (user or role), a sender (user or role) and the operative data needed. Especially, the operative data in CSMs are only the information of response, other than CMs with the information relevant to the operation of the task. In the case of the create meeting application, the operative data includesthe a meeting id (created by system automatically), the a meeting name and the a meeting topic.

Task Design

Whether a task in the collaborative systems can be operated or not depends on not only the relative rights, but also the specific system environment conditions.Consequently, thespecification of task constraints needs to be considered in system implementation. The different kinds of tasks are listed as follows:

No conditions

That is a task that if a user have the rights to accomplish it , he or sheand can commit it at any time. Cancel meetingis one of the cases in pointsuch tasks.

Must be granted by other roles

For example, only the moderator commits the dismiss meeting operation, but the creator must grant the permission to him or her in advance.

Need certain environment objects

For example, users holding the answer question right could no’t submit answers until there are some questions in the meeting environment.

Need certain environment conditions

For instance, users could no’t ask questions until the meeting status (environment conditions) is ask questions.

4. SYSTEM IMPLEMENTATION

It is impossible to paste all the code here, but we can discuss which methods can facilitate the implementation.

Database Design

Figure 3 illustrates the main structure of the system database. The table Roles is used to define the roles while the table Meeting Roles is used to assign roles in the different meetings. The table Message stores the CMs and CSMs information. Other tables are the basic tables for the objects of the system, such as Report, User, etc.

Note: tables names are in bold & the primary keys are underlined
Figure 3. Database Design

System Process Framework

As figure Figure 4 shown below, the meeting system is composed of three interfaces: communication interface, meeting interface and role management interface. Users exchange information in the communication interface, which lists all the CMs and CSMs received and sent separately. In CMs, a user can accept pass or refuse the applications received. If it an application is acceptedpassed, the system will commit the operation and send a CSM to the applicant as feedbacks. If not, the system will only send a CSM. Users collaborate with others byin the meeting interface, which retrieves all the data about the meeting from the table Meeting and Meeting Roles, such as meetingId, meeting topics, meeting members, etc. And ???? then shows the available tasks depending on the rights and responsibilities of the user defined from table Roles. The tasks without constrains will commit directly, but the other will link to the communication interface to send a CMs. In the end, it wills also retrieves all the data about meeting objects from the table Report, Q/A etc. And Role Manager defines, edits, deletes, and assigns roles in the role management interface.

Figure 4. System Process Framework
Role/Rights / Tasks (Type) / Meeting Status / CMs / CSMs / Operations
Administrator / Create meeting (1) / — / (r) Name and topic of meeting from a user / (s) To applicant / Create meeting
User / Apply new meeting (1) / — / (s) Name and topic of meeting to Administrator / — / —
Apply role (4) / Allow apply / (s) Role id and name to Role Manager / — / —
Create / Start meeting (2,4) / Allow apply / (r) From Moderator / (s) To all the meeting members / Change meeting status
Cancel meeting (1) / — / — / (s) To all the meeting members / Change meeting status
Reassign creator (3) / — / — / — / Reassign creator
Assign Role Manager (3) / — / — / — / Assign Role Manager
Role Manage / Start defining role (4) / Not start / — / — / Change meeting status
Role management (3) / — / — / (s) To relative roles / Define/edit/delete Roles
… / … / … / … / … / …
Note: (r)= receive (s)= send; Task type: (1)= No conditions (2)= Need granted (3)= Need objects (4)= Need conditions
Table 2. System Implementation Clues (abridged)

System Implementation

Table 2 (abridged) lists the clues of the implementation, including the type of tasks, task constrains and communication. Consequently we can easily implement the system in with different interfaces based on this table. For example, we can implement Start meeting task as follows:

(1) Since it is a ‘Need granted’ and ‘Need conditions’ task, Start meeting will be available when the user play the Moderator role and the meeting status is Allow applyin the meeting interface. And a CM will send to Creator after ModeratorclicksStart meeting.