A Model for Collaborative Services in Distributed ... - Semantic Scholar

0 downloads 0 Views 63KB Size Report
as floor control, session control, and telepointers provide additional communication mechanisms to ..... A value of one realizes a mutually-exclusive policy oth-.
A Model for Collaborative Services in Distributed Learning Environments1 Volker Hilt, Werner Geyer University of Mannheim Abstract: Synchronous collaborative work environments, which are mainly based on video-conferencing systems, suffer a lack of human communication channels and social awareness because mostly only audio, video, and joint editing of documents are supported. Collaborative services such as floor control, session control, and telepointers provide additional communication mechanisms to support persons co-working through computers. We propose a collaborative services model (CSM) for distributed learning environments. Our model includes floor and session control mechanisms and policies. Due to the realization of collaborative services as operations on the model, no specific network collaboration protocol is required. We present an optimistic synchronization scheme which provides consistency for the distributed model.

1

Introduction

1.1

Motivation

Advances in multimedia technologies and highspeed networks lead to new types of teaching and learning. Different digital media may be integrated and distributed via networks, such that they are available in arbitrary places and at arbitrary times (independency of space and time). Teleteaching denotes the geographical distribution of teachers and students who are connected via fast networks and who communicate synchronously. Compared to traditional distance learning this allows for a higher degree of interactivity and usage of new instructional media such as digital animations or simulations. In spite of this improvement, teleteaching suffers a lack of communication channels in comparison to traditional classroom instruction. Social protocols or rules control the human interaction and the course of instruction within a classroom. These communication mechanisms include for instance putting-up hands, giving rights to talk or to write on a blackboard, setting-up work groups and reference pointing. They are difficult to reproduce in remote situations because today’s synchronous learning environments, which are mainly based on video-conferencing systems, mostly provide only audio, video, and joint editing of documents. A major goal in developing learning environments is to reproduce, as far as possible, the traditional classroom situation by supplying computer support for controlling remote instruction and human interaction.

1.2

Collaborative Services

The lack of communication channels and social awareness cannot just be found in teleteaching but generally in all computer supported collaborative work (CSCW) systems. Collaborative services (CS) provide mechanisms to support the communication of persons through computers. Basic services are floor control, session control, and telepointers.

1 Extended

version of a paper accepted at IDMS’97, Interactive Distributed Multimedia Systems and Services, Darmstadt, Germany, September 1997.

1

1.2.1 Floor Control Floor control realizes concurrency control for interactive, synchronous cooperation between people by using the metaphor of a floor. A floor denotes the temporary permission to access and manipulate resources (e.g. a shared drawing area or a video channel). The owner of a floor at a certain point of time - called the floor holder - is equipped with well defined rights on a certain floor [Dom97]. In a session, floor control mainly has the following coordinating tasks [Dom97]: •

Reducing non-determinism, setbacks, redundancy, and inconsistencies in groupwork.



Balancing contributions among session participants in a fair manner.



Regulating the collaboration by a predictive and binding protocol for all session participants.



Promoting inter-group awareness, cohesiveness, and integrity.

Crowley et al. [Cro90] distinguish between floor control policy and mechanism. The policy determines the strategy of achieving, holding, and releasing floors while the mechanism provides basic low-level functionality for the implementation of floor control. The best-suited strategy for a certain (instructional) situation depends on the task and size of the group and on the type of interaction in the group; consequently, floor control has to be adaptable [Gut95]. Fluckiger et al. [Flu95] identify four basic floor control policies: 1. No control: Each member of the group can access common resources without control. The discovery and avoidance of conflicts while accessing a resource depends solely on the goodwill, common sense, and social behaviour of the group members. This approach is suitable for small groups only. 2. Implicit floor control: This strategy implicitly grants a floor to a group member as soon as he or she starts to use a certain resource. The resource is then locked for other members. A certain time after the floor holder has stopped using the resource the floor is automatically released. If the floor holder keeps using the floor for more than a certain time, he or she may be notified about other participants requesting the floor. 3. Explicit floor control: The floor is granted to a participant or released only on his or her specific request, for instance, by pressing a dedicated button. The requests of other participants while the floor is locked have to be queued and displayed to the group. Generally, these requests are then served on a first-in-first-out basis. 4. Chair control: One person becomes chairperson or moderator (e.g. the teacher in a teleteaching session) of the collaborative group. He or she can grant or regain the floor for a certain resource at any time. Pending floor requests of participants have to be queued and monitored to the chairperson. Furthermore, Dommel et al. [Dom97] classify policies in queuing and non-queuing depending on whether requests are queued or served immediately. A single floor may be granted to one participant only (mutually-exclusive) or to several participants simultaneously (selective)2. Further classifications can be found in [Dom97].

1.2.2 Session Control Session control denotes the administration and coordination of multiple sessions with its participants and media [MMU96]. It comprises initiation, pause, resume, and stop of sessions. Membership support includes creation, joining, withdrawing, inviting, excluding etc of participants [Dom97]. Session control provides social awareness 2 Dommel

et al. [Dom97] denote the policy of assigning k floors to n participants as mutually-selective. In contrast to their terminology, we use the term selective to express that k participants, k ≤ n , may hold the same floor.

2

in workgroups because members gain knowledge about other members and their status in the session. Floor control relies on session control because a floor grants resource access to a certain participant who is a member of a session. Hierarchical session management allows for the creation of subsessions within a workgroup.

1.2.3 Telepointers Shared application show the same data on all participants’ screens. Take for instance a shared whiteboard to transfer lecture slides. To ease tracking the direction of the lecture, telepointers realize a common point of reference by providing shared pointers. For a detailed insight of telepointers refer to [Nak93]. In our collaborative services model, telepointers are managed as resources.

1.3

Context of the Model

The collaborative services model we propose in this paper has been motivated by our work in the TeleTeaching project Mannheim-Heidelberg. The project aims at an improvement in quality and quantity of lectures by using multimedia technology and networks for the distribution of lectures. We are realizing three different modes of teaching and learning as indicated in Figure 1.

Network

RLR

Network

Network

RIS

IHL

Fig. 1: Teleteaching modes. The three modes are characterized by their scope of distribution, interactivity, and individualization of the learning process. In the Remote Lecture Room (RLR) scenario lecture rooms are connected via a high speed network and courses are exchanged synchronously and interactively between the universities of Heidelberg and Mannheim. Remote Interactive Seminars (RIS) describes a more interactive type of instruction. Small groups of participants are distributed across a few seminar rooms which are also connected by a network. RIS focuses mainly on the co-operative, on-line construction and presentation of reports. The Interactive Home Learning (IHL) scenario is aimed at the maximization of the geographical distribution degree of all class participants. Each student learns asynchronously as well as synchronously at home in front of his PC. For a thorough description of the project see [Gey97]. Currently, we are using the MBone video-conferencing tools and the Internet for remote lecturing. The tools prove to be not sufficient for the purpose of teleteaching because they are not powerful enough to support team

3

work. They are also not flexible enough for the use of media and they do not provide an integrated user interface, while being somewhat difficult to handle by non-experts. Therefore, we are currently developing a novel, integrated teaching software, called digital lecture board (dlb), to overcome the weaknesses of video-conferencing systems. In the context of the dlb, we designed and implemented the collaborative services model which is presented in this paper.

1.4

Terminology

There is no commonly accepted framework for collaborative services, although floor control and session control have been well-known concepts for a long time. Based on [Dom97] we are using the following terminology: The infrastructure for groupwork (e.g. teleteaching) is provided by sessions, which can be divided into subsessions or combined in supersessions. A session denotes an on-line aggregation of participants co-working synchronously on shared resources. Resources in multimedia systems could be, for instance, files, devices, user interface widgets, graphical objects, video and audio streams etc.3 Participants are associated with certain roles. A role is a set of privileges [Ell91]. A multimedia environment allowing remote collaboration with multiple resource types is called a collaborative environment.

2

Related Work

Rajan et al. [Raj95] present a formal model for structured, multimedia groupwork. Their work mainly focuses on formal, verifiable definitions of static model situations. The IETF working group MMUSIC develops mechanisms mainly for session control. Two different session models are described [Han96]: session control for light-weight sessions simply provides membership information whereas tightly-coupled sessions allow for the realization of collaborative services. So far, a standard session control mechanism for tightly-coupled sessions does not exist in the Internet [Han96]. Bormann et al. [Bor95] propose an object oriented model for the local presentation of the session state. The work is focused on the representation of the current state of a session whereas operations on the model are not defined. For the realization of collaborative services, specific protocols, which are separated from the model, are required (e.g. SCCP - Simple Conference Control Protocol [Bor96]). SCCP uses centralized components and relies on transport services which provide global ordering of messages. Dommel et al. [Dom97] introduce a notation for the representation of groupwork environments. Sessions may be structured hierarchically, side talks are possible, participants may take different roles in a session, and resources are also assigned to floors. Dommel proposes the implementation of collaborative services by using a control state table. Protocols providing consistency, policy, and distribution have to be realized separately. The work mainly provides a basic survey of floor control but no specific realization. Shenker et al. [She95] present a more abstract framework for the management of the session state. For the representation of sessions, they use state variables and define abstract operations. Moreover, protocols, mainly for assuring consistent state transitions in the distributed model, are discussed.

3 Note

4

that we use the term resource in a broader sense for all required collaboration objects.

The BERKOM Multimedia Collaboration Service (MMC) [MMC96] provides a complete conferencing architecture including session control and simple floor control for a shared application tool. The conference control concept is based on centralized components. JVTOS [Der93] provides a system level platform for multimedia based telecooperation in heterogeneous environments. Along with video, audio, and session management support, course-grained floor control is realized for an application sharing component (i.e. the complete application is regarded as a resource). The T.120 standard [ITU96] describes a protocol hierarchy to support teleconferencing in public networks such as ISDN. Session control and a token mechansim are based on a centralized concept. The standard does not consider floor control. Existing work in this area mainly focused on session control. There is little about floor control and its realization in combination with session control. Most of the aproaches propose heavy-weighted architectures where specific protocol layers provide session control, ordering, token mechanisms, and other services on which e.g. floor control can be realized. This concept seperates session and floor control although they are tightly coupled. Generally, this introduces a high communication and synchronization overhead. Other approaches simply design collaborative services protocols while not being easily capable of handling the collaboration state and consistency. Consequently, the application has to manage the state, for instance, in variables or tables. Specifically, in larger sessions this introduces a high complexity which is rather difficult to handle by an application. Our work mainly inspired by [Dom97] and [She95] differs in that we combine fine-grained floor control and session control for tightly-coupled sessions in a single collaborative services model. Additionally, the model performs consistency checks based on specific consistency rules, and includes different collaborative services policies, while the separation of mechanism and policy is still provided. We do not need specific protocols for realizing floor control and session control because operations are executed by the model and not by a protocol. An optimistic synchronization scheme assures consistency of the distributed model and offers high responsivness. This light-weighted approach provides high scalability, does not rely on complex conferencing architectures, and can be easily used/incoporated by/into an application. The model has been designed for teleteaching applications but is not limited to them.

3

Collaborative Requirements

The three teleteaching modes (RLR, RIS, IHL) - in regard to common forms of university learning - should comprise both traditional types (e.g. didactic teaching) and cooperative types of instruction (e.g. jigsaw). Modern types of face-to-face instruction should basically serve as an example for remote instruction. In our analysis [Hil96] we derived the following standard situations that should be supported by all learning environments: •

Joining a session at the beginning



Joining a running session



Leaving a session earlier



Leaving a session at the end



Removing a participant from the session (e.g. by the moderator)



Putting-up hands (signaling)



Putting-up hands recursively (for replies)

5



Drawing back signals



Removing signals by the moderator or teacher



Selecting participants (with and without signal)



Selective granting of rights (floors)



Selective removing of rights (floors)



Returning own rights



Pointing to shared instructional materials

Cooperative learning environments should additionally be able to cope with the following situations: •

Creating sub-groups



Joining running sessions (sub-groups)



Closing sub-groups



Private discussions and co-operation



Creating moderators for sub-groups



Surveying sub-groups and participants (super user role of the moderator)



Granting of rights (floors) for working areas and materials to sub-groups



Accessing working areas and materials without a moderator in order to enable internal group discussions

4

Collaborative Services Model

4.1

Overview

We propose a collaborative services model which implements enhanced floor control and session control in order to realize the described service requirements. The model not only holds the required state information but also carries out the collaborative services. While executing services, consistency rules are checked. Our model provides both mechanisms and policies so as to realize its collaborative services. Each participant of a session holds a local copy of the model. The distributed copies in the network are held consistent by applying an optimistic synchronization scheme (see 5). This guarantees a good responsiveness, typically required by CSCW applications. The identified services (see 3) are similar in that they require extensive state information about the session (collaboration state). The collaboration state represents the common state of all collaborative services. Floor control and session control use state information which overlaps considerably. So in order to avoid redundancy and to ease consistency, we manage the collaboration state in a single model. The CSM describes the collaboration state by using state elements (objects) between which relationships are built during a session. Objects are either a mapping of real world objects, like participants and resources, or abstractions such as floors and sessions. A participant may be, for instance, involved into a session and may have the floor for a certain resource. We are using specific floor objects to store the status of a floor, its access permissions to resources, and the applied policy. A floor establishes a relationship between a resource, a participant, and a session, and regulates the repeated, concurrent access to shared resources4 during synchronous groupwork. Collaborative services are realized by executing operations on objects. Thus, using CS always changes the collab-

4 All

6

resources used for collaboration and included in the model are considered as shared.

oration state, except for simple state queries. The semantics of a service is defined by its changes to a given collaboration state (i.e. the required operations needed in order to provide the service). Granting a floor, for instance, always includes the construction of a relationship between the floor and a participant. The operation must check whether or not a relationship between the floor and the other participants already exists. Implementing CS as operations on the collaboration state allows for performing different service provision strategies. The strategies determine the rules for the execution of state changing operations (collaborative services policies). Being independent of the strategies, our model provides the consistent management of objects and relationships, and furthermore, the consistent distribution of the collaboration state in a network (collaborative services mechanisms).

4.2

Objects of the Model

The objects of the CSM contain both information for the representation of the collaboration state and data with informative character only. The stored information is universal and independent of a specific application. Figure 2 depicts the CSM in Coad/Yourdan notation.5 The container class CollaborativeLearning represents the totality of all involved objects. A Session object describes the composition of a workgroup. The object may recursively contain several sub-sessions required for cooperative learning. The following relationships may be established with a Session: •

A Session may contain arbitrary participants by forming relationships with Participant objects.



SharedResource objects can be assigned to a Session using a Floor object.

The following attributes characterize a Session [Dom97], [Han95]: Name, URI (Uniform Resource Identifier), Structure, Purpose, Duration, Entry, Decision Procedure, and Distribution Scope. Purpose, for instance, could carry values such as, “lecture”, “examination” etc. For a thorough description of these attributes refer to [Hil96]. The Participant object represents a potential participant. Since a moderator or teacher has additional rights, we derive a ChairParticipant object. The following relationships are possible: •

A Participant may participate in arbitrary Sessions, using a Participation object.



A Participant may be floor holder of arbitrary Floors.

The object contains the following attributes [Dom97], [Bor96]: Name, Address, Phone, E-Mail, Type, Social Role, Authority, and Link. The participation of a Participant in a Session is realized by a (1:1) relationship using the Participation class. This relationship is characterized by the RoleInSession and IsActive attributes. RoleInSession can be, for instance, “Lecturer”, “Chair”, “Observer” etc. IsActive determines whether a participant is actively or passively involved in a session. A SharedResource object denotes the abstract counterpart to a real resource that has been declared as a shared resource by the application during a session. All collaborative services are carried out in the model on the placemarker SharedResource, i.e. it reflects the resource’s state only, while the real resource has to be managed by the

5 Internal

object methods are omitted in Figure 2 in order to provide a better readability.

7

IdentifiableObject Identity

CollaborativeLearning

0,n 0,n

1

0,n

Participation

1

SharedResource

0,1

Participant

1

IsActive

1

Session

RoleInSession 0,n

0,n

Security

0,n

Address

DecisionProcedure

Authority

DistributionScope

EMail

Duration

Link

0,n

Floor

0,n

Name

Entry Name

Phone

Purpose

ControlPolicy

SocialRole 0,n

Type

EntailedPermissions

1,n

Structure URI

MaxHolders

0, n

Security NamedSharedResource 1,n 0,n

Name

QueuedFloor

NoCtrlFloor

ImplicitCtrlFloor

ChairParticipant 0, n

IdleReleaseDelay MaxHoldTime

0,n

ChairedCtrlFloor

Aggregation

ExplicitCtrlFloor

0,n

"IS A" Relationship

Fig. 2: Collaborative services model.

8

1

application. Clearly, the application has to query the state prior to accessing a real resource. A Shared Resource object is the smallest unit that can be assigned to a Floor, but multiple SharedResources may also be assigned to a single Floor. A Floor object can establish the following (n:m) relationships between SharedResource, Session, and Participant: •

Multiple SharedResource objects may be assigned to a single Floor just as a single SharedResource may be assigned to multiple Floors. The latter requires that the access permissions amongst these Floors are not conflicting.



A Session may hold an arbitrary number of Floor objects and a single Floor may be used in multiple Session objects. This allows for accessing resources across sessions.



Participant objects may be floor holders of an arbitrary number of Floor objects. Using the selective policy, even a single Floor may be assigned to multiple Participant objects.

The Floor object carries the following attributes: Control Policy, Entailed Permissions, MaxHolders, and Security. Control Policy may take the values “NoControl”, “ImplicitControl”, ExplicitControl”, and “ChairedControl”. The Entailed Permissions object defines access rights on the associated resource (“Read”, “Write”, “Execute” etc). MaxHolders limits the maximum number of floor holders. A value of one realizes a mutually-exclusive policy otherwise a selective policy. Security may limit the usage of the Floor to a single Session. The class Floor is an abstract, base class which does not implement a concrete floor control policy but provides mechanisms needed by all Floor objects to establish relationships between other objects. Also, Queued Floor is abstract however it enhances Floor with queuing mechanisms in order to realize queuing policies. In the model, policies are implemented by deriving specialized Floor classes enriched with algorithms which set up relationships to Participant objects considering given criteria. The classes NoCtrlFloor, ImplicitCtrlFloor, ChairedCtrlFloor, and ExplicitCtrlFloor realize policies described in 4.4.

4.3

Consistency Rules

Consistency rules subject possible relationships between objects to conditions so as to avoid conflicting situations and to provide a well defined state of the model at any time. Our CSM defines four basic rules: C1:

SharedResource may only have multiple Floor objects if the floors are compatible6 with each other.

C2:

A Floor can only exist if it is at least assigned to one SharedResource and one Session.

C3:

Participant objects may only be floor holders if they are members in at least one Session to which the related Floor is assigned.

C4:

Participant objects may only become floor holders if the maximum number of floor holders associated with a Floor is not exceeded.

C1 and C2 concern the relationship Shared Resource-Floor-Session. C1 constrains the number of floors for one SharedResource so that floor control is not by-passed by simply creating a new Floor object. There are two situations which prove to be problematic when satisfying C1: (i) Assigning a SharedResource in use to another Session using a Floor object and (ii) creating another Floor with different properties for a SharedResource in use. To satisfy (i), each time a new Floor object is generated, its desired properties (policy and permissions) have to be spec6 Floors

are considered compatible if the attached access permissions are not conflicting. Access permissions have to be specified when creating a Floor. Conflicts can be detected, for instance, by using a conflict matrix.

9

ified. If there exists no Floor for the SharedResource yet, the Floor is created and assigned to the SharedResource and the Session. Otherwise, if an existing Floor has matching properties, it can be re-used for the new Session. Both Session objects then access the resource by using the same Floor. If there is already a Floor with different properties, we check compatibility. In case of no access conflicts, the Floor object can be assigned to the SharedResource and the Session. Otherwise the floor request is rejected. This also satisfies (ii). Setting the Security to “Private” avoids assigning Floors of a certain Session to other Sessions. C2 manifests the purpose of a Floor because it allows accessing shared resources in a Session. A Floor object without SharedResource object and Session object is useless. C3 provides a consistent relationship between Participant-Floor-Session. If Participant objects could access shared resources, which are independent of their Session, the assignment of SharedResource objects to Session objects would have no effect. With C3, Participants may only use SharedResources assigned to their own Session by a Floor. This allows, for instance, that different Sessions can hold different audio resources in order to permit separated discussions. Moreover, when leaving a session, participants are forced to drop their floor holder role so as to avoid locking resources. If a SharedResource is separated from a Session, all Participants of this Session (not being in another Session including this resource) have to drop the floor holder role for this SharedResource. Clearly, C3 is always violated whenever a relationship between Floor and Participant exists, and the relationship Floor-Session-Participant-Floor is interrupted at another point. C4 regulates concurrent access to SharedResource objects.

4.4

Collaborative Services Policies

Taking into account the above consistency rules, different floor control policies can be realized. C4 defines a maximum number of floor holders. Setting it to one provides a mutually-exclusive, setting it to n, n>1, a selective access. The “no control” policy can be, for instance, realized by setting an adequately large limit (e.g. the number of participants in the session). The policies “no control”, “implicit control”, “explicit control”, and “chair control” can be distinguished by different state automata. As an example, Figure 3 depicts the automaton for “explicit control” (see [Hil96] for further diagrams). In state Idle, no participant holds the floor whereas in state Available, the floor holder role is already granted to someone but additional participants can still be permitted (only selective floors). In state Held, no further floor holders may be admitted, but further requests are queued by changing to and remaining in state Requested. Request and release messages are the only way to initiate state transitions from outside (except for the “chair control” policy).7 A release message can either be initiated by a floor holder or by a participant in the queue. In the first case, the floor holder role is granted to another participant and he or she is removed from the queue. In the later case the request is removed from the queue. If no more participants are queued, the floor changes to state Held.

7 The “implicit control” policy defines a time-out for the maximum floor holding time. In this case, the system automatically generates a release message.

10

ExplicitCtrlFloor Request ^ Policy = mutually-exclusive

Idle Release ^ CurrentHolders = 1

Request ^ Policy = selective

Available

Release ^ CurrentHolders > 1

Request ^ CurrentHolders = MaxHolders - 1

Release ^ Policy = selective Release ^ Policy = mutually-exclusive

Request ^ CurrentHolders < MaxHolders - 1

Held Release ^ PendigRequests = 1

Request

Request

Requested Release ^ PendingRequests > 1

Fig. 3: State diagram for “explicit control”. The classes NoCtrlFloor and ImplicitCtrlFloor are non-queuing while ExplicitCtrlFloor and ChairedCtrlFloor provide queuing. All policies may either be mutually-exclusive or selective. Also for sessions, different policies can be selected. The Structure attribute, for instance, allows hierarchical sessions while the Security attribute limits floor usage to a single Session. Further application specific strategies can be defined.

4.5

Accessing Services

Collaborative services, consisting of a sequence of single object methods on different CSM objects, are provided to the user by an application programming interface (API). All API calls are listed in Table 1. Internal methods, which change the state of an object., are not discussed further because they are not accessible by CSM users. By querying the states of objects through the API, the application can read the result of collaborative services. In order to allow for a clear mapping between application objects and CSM objects (which are place markers for real world or user interface objects), the class IdentifiableObject provides a unique ID for each CSM object. Whenever a new object is created in the CSM by using the API, the ID is returned to the application. The application itself is then responsible for distributing this ID to all co-operating applications in the network. Each application instance is now able to access its own CSM by using this ID.

5

Implementation Issues

5.1

Distributed Architecture

The design of synchronous groupware systems for distributed user groups has to consider the following issues, which are especially important for interactive collaborative services [Ell91], [Borg95]: •

Short response times for the initiator of an operation,



Short notification times for other participants,



Arbitrary distribution of user groups, and

11

CreateParticipant DeleteParticipant CreateSession DeleteSession CreateSharedResource DeleteSharedResource JoinSession InviteParticipant LeaveSession CreateFloor RemoveFloorFromSession RemoveFloorFromResource RequestFloor ReleaseFloor RequestChairRole ReleaseChairRole ChairedFloorGive ChairedFloorGet AttachSubsession DetachSubsession GetObjectState SetObjectState Table 1: CSM API calls. •

Robustness of the system in case of component failures and unpredictable user actions.

In order to meet these requirements, we have chosen a distributed, replicated architecture for our implementation of the CSM. Short response times for read- and write-operations are achieved because each participant holds a local copy of the CSM. Due to the synchronization mechanism that keeps the distributed model consistent (see 5.3), a slightly higher delay is introduced for write-operations in case of conflicts. Without a centralized stateserver, minimal notification times are attained because operations are transmitted directly to participants. Since we solely send change operations instead of the complete collaboration state, only low bandwidth is required. High robustness is achieved, due to the replication of the collaboration state and the abscence of a “single point of failure”. Moreover, a distributed, replicated approach allows for better spacial scaling of user groups [Dom97]. The realization of the CSM in a CS agent, separated from an application, avoids redundancy when multiple local applications are using collaborative services. A single agent serves multiple applications. This approach also keeps the development of the CSM independent of specific software. The CS provided by an agent is accessed in the following way. An application requests a specific collaborative service by issuing the appropriate operation to its local agent. The agent carries out the operation on its CSM copy. After successful execution, the operation is distributed to all other agents. A synchronization scheme handles conflicts with other concurrent operations.

5.2

Communication Protocols

Communication in our distributed architecture requires protocols for three different purposes. Firstly, operations and results have to be transferred between application and local agent. Secondly, operations have to distributed amongst agents in the network. Thirdly, concurrent operations have to be coordinated in order to ensure consistency amongst the the distributed CSM copies. The first two tasks are carried out by the transfer component while

12

the synchronization component manages concurrency control. The modular architicture allows for using arbitrary synchronization protocols. In our implementation, we have chosen an optimistic synchronization scheme (see 5.3). Figure 4 provides an overview of our implemented architecture with its communication protocols.

Workstation 1 TeleTeaching Application

Workstation n

Collaborative Service Agent

Collaborative Service Agent

CSM

CSM

API Transf.Comp.

SCP

TransferComponent

SCP

API

Sync.Comp.

SIP

Reliable

TeleTeaching Application

Sync.Comp.

...

TransferComponent

SIP

Transf.Comp.

SCP

SCP

Transport Service

Fig. 4: Communication architecture. The transfer component comprises two protocols: •

The State Control Protocol (SCP) realizes the communication between application and local agent. The application is notified whenever the collaboration state has been changed by a remote agent.



The State Interchange Protocol (SIP) is responsible for the communication between all distributed agents (e.g. transferring operations to remote agents). SIP does not consider conflicting operations.

5.3

Optimistic Synchronization

An optimistic synchronization scheme detects and resolves conflicts instead of avoiding them. Applying this approach to the CSM means that operations on the model are executed optimistically (without considering possible conflicts), and are reversed in the case of conflicts (reversible execution [Ell91]). In the absence of conflicts, a high responsiveness is achieved [Ell91]. This approach allows for a maximum concurrency because actually, only contenting operations are reversed. The distributed data of the model has an ephemeral character, i.e. it is only valid during the period of collaboration. Thus, the requirement of 100% fault tolerance, needed, for instance, for databases, can be relaxed in order to achieve a higher responsiveness, which is more important for distributed learning environments than absolut fault tolerance. Analyses of the three different learning modes (see 1.3) indicate that irreversible conflicts will rarely arise and are tolerable for distributed learning. Basically, optimistic synchronization is based on the assumption of a low probability of conflict [Borg95]. The probability of conflict is determined by (i) the duration of the critical period, in which the proper execution of an operation is endangered by concurrent operations, and (ii) the initiation frequency of operations. The critical period begins when an agent receives an operation by the application and ends with the delivery at the last remote

13

agent. Obviously, this period of time is mainly determined by the transfer delay between CS agents. The initiation frequency of operations requesting collaborative services in a teaching environment is more likely to be low to medium-sized depending of the type of instruction. Conflicts arise only during the critical period. Since the initiation frequency of operations in relation to the critical period is low (actually, the initiation frequency of contenting operations is even lower), the conflict probability is acceptable for optimistic synchronization. Our synchronization scheme comprises the functions (i) conflict detection and (ii) conflict resolution. Conflict detection is based on the idea of defining preconditions for the execution of operations, i.e. prior to their carrying out, all distributed CSM copies have to meet these preconditions. The execution of an operation is determined by the initial state of used objects and the operations’s parameters and algorithm. If these elements are identical in each CSM copy, the execution leads to the same final state in all copies. Also concurrent operations leave the CSM copies in a consistent state, if the preconditions are fulfilled. Since the initial state of used objects has to be identical, no operation can hide the results of another operation in some of the CSM copies. In our model, the preconditions hold true for the parameters and algorithms, but not neccessarily for the initial state of used objects. To verify identity of the initial object state in all copies, the agent receiving an operation from the application, records it’s object state. The agent executes the operation prior to propagating it, along with the recorded object state, to the remote agents. The receiving agents then compare their object state to the received state. In the case of correspondence, the operation is also carried out at the remote agents, otherwise a conflict exists and has been detected. Specifically, if at least one of two concurrently executed operations modifies an object, which is accessed by both operations, a conflict occurs. If none of the jointly used objects is modified, the concurrent execution is allowed.8 Conflict resolution has to reverse conflicting operations in all distributed CSM copies. Since not each agent neccessarily detects the conflict for a specific operation, agents use rollback messages in order to inform each other. It might happen that an agent, receiveing a rollback-message, has already executed successive operations, which also have to be reversed. For this purpose, each agent maintains an operation history containing the sequence of applied operations. The history further stores the initial object state used by the conflict detection. The initial state can be copied into the CSM to reverse an operation. A conflict is very likely to be detected by multiple agents, simultaneously. Hence, a single agent can receive multiple rollback messages for one operation. So we additionally use a rollback-history in order to coordinate the reversal of operations.

6

Conclusion

We have presented an approach for realizing collaborative services in the context of distributed learning environments. Based on an analysis of collaborative service requirements, we developed an object oriented collaborative services model. The light-weighted approach, which follows the paradigm of mechanism and policy, includes fine-grained floor control and session control for tightly-coupled sessions. We do not depend on specific protocols for realizing collaborative services in distributed workgroups because operations are executed by the model and not by a protocol. We implemented the CSM with an optimistic synchronization scheme which offers a high

8 An

14

informal proof for the correctness of the conflict detection is provided in [Hil96].

responsiveness in a distributed architecture.

7

References

[Borg95]

U.M. Borghoff et al.: “Rechnergestuetzte Gruppenarbeit, Eine Einfuehrung in verteilte Anwendungen”. Springer Verlag, Berlin, Heidelberg, 1995.

[Bor95]

C. Bormann et al.: “Elements of Session Semantics”. Internet draft, IETF, draft-bormann-mmusicsemantics-00.txt, November 1995.

[Bor96]

C. Bormann et al.: “Simple Conference Control Protocol”. Internet draft, IETF, draft-ietf-mmusicsccp-00.txt, June 1996.

[Crow90]

T. Crowley et al.: “MMConf: An infrastructure for building shared multimedia applications”. In Proc. CSCW’90, p. 637-650, ACM, New York, 1990.

[Der93]

G. Dermler et al.: “Constructing a Distributed Multimedia Joint Viewing and Tele-Operation Service for Heterogeneous Workstation Environments”. Proc. of the Fourth Workshop on Future Trends in Distributed Systems, pp. 8-15, Lisbon, 1993.

[Dom97]

H.-P. Dommel et al.: “Floor Control for Multimedia Conferencing and Collaboration”. In ACM Journal on Multimedia Systems, Vol. 5, No. 1, January 1997.

[Ell91]

C. A. Ellis et al.: “Groupware - Some Issues and Experiences”. In Communications of the ACM, Vol. 34, No. 1, p. 38-58, 1991.

[Flu95]

F. Fluckiger: “Understanding Networked Multimedia Applications and Technology”. Prentice Hall, New York, 1995.

[Gey97]

W. Geyer et al.: “Multimedia-Technolgie zur Unterstuetzung der Lehre an Hochschulen”. In Multimediales Lernen in der Beruflichen Bildung, BW - Bildung und Wissen, Nuernberg, 1997.

[Gut95]

T. F. Gutekunst: “Shared Window Systems”. Dissertation ETH No. 11120, Swiss Federal Institute of Technology, Zurich, 1995.

[Han95]

M. Handley et al.: “SDP: Session Description Protocol”. Internet-Draft, IETF, draft-ietf-mmusicsdp-01.ps, November 1995.

[Han96]

M. Handley et al.: “The Internet Multimedia Conferencing Architecture”. Internet-Draft, draft-ietfmmusic-confarch-00.ps, IETF, February 1996.

[Hil96]

V. Hilt: “Modellierung und Implementierung von Protokollen und Mechanismen zur Unterstützung von kooperativem Lernen in einer TeleTeaching-Umgebung”. Master’s thesis, University of Mannheim, Germany, 1996.

[ITU96]

International Telecommunication Union: Recommendation T.120 - Data protocols for multimedia conferencing, July 1996.

[MMC96]

“Multimedia Collaboration”. User’s& Installation Guide, Version A.01.00, http://www.prz.tu-berlin.de/docs/html/MMC/manual/index.html, Hewlett-Packard Company, June 1996.

15

[MMU96]

“Multiparty Multimedia Session Control (MMUSIC) Charter”. URL: http://sauce.mmlab.uninett.no/ietf/mmusic-charter.html, 1996.

[Nak93]

A. Nakajima: “Telepointing Issues in Desktop Conferencing Systems”. In Computer Communications, Vol. 16, No. 9, 1993.

[Raj95]

S. Rajan et al.: “A Formal Basis for Structured Multimedia Collaborations”. In Proc. IEEE Multimedia Computing and Systems, Los Alamitos, C.A., 1995.

[She95]

S. Shenker et al.: “Managing Shared Ephemeral Teleconferencing State: Policy and Mechanism”. Internet draft, IETF, July 1995.

16

Suggest Documents