CUSTOMIZABLE DATA DISTRIBUTION FOR SYNCHRONOUS

GROUPWARE

Stephan Lukosch

University of Hagen

Department for Computer Science

58084 Hagen, Germany

Keywords:

Collaborative applications, development support, data distribution.

Abstract:

The state of a groupware application must be shared to support interactions between collaborating users. There

have been a lot of discussions about the best distribution scheme for the state of a groupware application. Many

existing groupware platforms support only one distribution scheme, e.g. a replicated or a central scheme, and

apply the selected scheme to the entire application. None of these schemes ﬁts well for every groupware

application. Different applications and even single applications have different requirements concerning data

distribution. This paper describes DreamObjects, a development platform that simpliﬁes the development of

shared data objects. DreamObjects supports a variety of distribution schemes which can be applied per shared

data object. Additionally, it offers an interface that developers can use to introduce their own distribution

schemes.

1 INTRODUCTION

Synchronous groupware brings together users who

are geographically distributed and connected via a

network. It encompasses a wide range of applica-

tions like collaborative whiteboards, text editors or

Web browsers. All these applications have to share

data to support interactions between their users.

There have been a lot of discussions about the best

distribution scheme for the data objects of a group-

ware application. Many existing groupware platforms

support a replicated distribution scheme or a central

one and apply the supported scheme to the entire ap-

plication. None of these schemes ﬁts well for ev-

ery groupware application. Different applications or

even single applications have different requirements

concerning data distribution. Therefore, developers

should be able to select the distribution scheme per

shared data object.

This paper presents the DreamObjects platform

(Lukosch, 2003), which substantially simpliﬁes the

development of shared data objects. DreamObjects

is based on DreamTeam (Roth, 2000). DreamTeam

is a platform for synchronous collaboration and fo-

cusses on the coordination and communication of dis-

tributed users. DreamTeam offers a hierarchical class

library with groupware speciﬁc solutions, e.g. aware-

ness widgets, and provides an infrastructure with spe-

cial groupware facilities. This, e.g., includes a ses-

sion manager that is responsible for starting, joining,

and leaving sessions, and a rendezvous manager that

determines the actual network addresses of all team

members.

In DreamObjects, developers can select between

an asymmetric, a replicated, and different adaptive

distribution schemes. Adaptive distribution schemes

dynamically change the distribution of a shared data

object according to a user’s working style or accord-

ing to the topology of the connecting network. Ad-

ditionally, DreamObjects offers interfaces and build-

ing blocks that permit developers to deﬁne their own

distribution schemes and integrate them into the plat-

form. Developers can specify the distribution scheme

of a shared data object at runtime. Thereby, they can

use the same data object with different conﬁgurations

and adapt the conﬁguration to the runtime needs of an

application.

Further beneﬁts of DreamObjects are a ﬂexible and

extensible concurrency control mechanism, an adapt-

able notiﬁcation service, a ﬂexible latecomer support,

and a decentralized persistency service. By applying

the object-oriented substitution principle, DreamOb-

jects achieves all these beneﬁts with a maximum of

transparency for the developer. After an initial con-

Lukosch S. (2004).

CUSTOMIZABLE DATA DISTRIBUTION FOR SYNCHRONOUS GROUPWARE.

In Proceedings of the Sixth Inter national Conference on Enterprise Information Systems, pages 70-77

DOI: 10.5220/0002633900700077

 SciTePress

ﬁguration, developers can use shared data objects like

local objects of a single-user application. Developers

do not have to care about data sharing issues.

The next section discusses the requirements con-

cerning data distribution. Section 3 compares these

requirements to the state-of-the-art. Section 4 and

section 5 introduce the DreamObjects platform and

its data distribution mechanisms, followed by conclu-

sions.

2 REQUIREMENTS

Roth and Unger introduce an extensible classiﬁcation

model for synchronous groupware (Roth and Unger,

2000). In contrast to former classiﬁcation models,

e.g. Patterson’s taxonomy (Patterson, 1995) or De-

wan’s generic architecture (Dewan, 1996), this model

directly addresses the distribution characteristics of

a groupware application. It consists of an applica-

tion scheme and a distribution scheme. The applica-

tion scheme strictly separates the user interface of an

application from the underlying data and algorithms.

To classify existing groupware platforms, Roth and

Unger identify different distribution schemes: central

state, asymmetric state, and replicated state.

Fig. 1 shows the central state distribution scheme.

The dotted frames indicate different sites inside a net-

work. The user interface is replicated to every site.

A well-known server manages the shared data objects

of an application. The main advantage of this distri-

bution scheme is that it is very simple to ensure data

consistency and to handle persistency. However, one

has to maintain the server, and the server is a bottle-

neck for the communication between the participat-

ing sites. Slow network connections increase the re-

sponse time of an application. For interactive applica-

tions, it is a quite important issue to keep the response

time low, as this time is directly perceived by the user

and a high response time disturbs the interaction of

the user with the application.

Shared data

objects

User interface

objects

User interface

objects

Figure 1: Central state distribution scheme

In the asymmetric state distribution scheme (see

ﬁg. 2), an arbitrary participating site fulﬁlls the tasks

of a server. Using this scheme, every participant can

easily share local data. Apart from this advantage, this

scheme has the same drawbacks as the central distri-

bution scheme. However, both schemes, the central

and the asymmetric one, can be useful in cooperative

applications, e.g. to share large amounts of data or to

introduce local data.

Shared data

objects

User interface

objects

User interface

objects

Figure 2: Asymmetric state distribution scheme

In the replicated state distribution scheme (see ﬁg.

3), the shared data objects are distributed to every

participating site. As an application can access the

shared data objects locally, the response time of an

application is reduced. This can be useful in highly

interactive cooperative applications, like e.g. coopera-

tive games. However, as already discussed by Molina

(Garcia-Molina, 1986), this distribution scheme also

has its drawbacks. The runtime system has to use

more complex algorithms, e.g. for concurrency con-

trol. The network trafﬁc increases to keep the shared

data consistent, since every site has to be informed

about a modiﬁcation.

Shared data

objects

User interface

objects

User interface

objects

Shared data

objects

Figure 3: Replicated state distribution scheme

A variant of the replicated distribution scheme

is the partially-replicated one. In this distribution

scheme, the shared data objects are distributed to

more than one site, but not necessarily to all sites.

Compared to the asymmetric and central distribution

scheme, this increases the availability of the shared

data. Compared to the replicated distribution scheme,

this decreases the network trafﬁc that is necessary to

keep the shared state consistent. However, the run-

time system still has to use more complex algorithms.

Different approaches exist for a partially-replicated

distribution scheme. The shared data objects can, e.g.,

be replicated to a predeﬁned set of sites. These sites

CUSTOMIZABLE DATA DISTRIBUTION FOR SYNCHRONOUS GROUPWARE

can access the shared state locally and have to keep

the shared state consistent. The other sites choose

an arbitrary site to access the shared state. Fig. 4

shows this scenario. On the one hand, this approach

increases the availability of the shared data objects,

but on the other hand the predeﬁned sites may not be

the sites that intensively access them.

Shared data

objects

User interface

objects

User interface

objects

Shared data

objects

User interface

objects

Figure 4: Partially-replicated state distribution scheme

Normally, not all users view or edit all shared data

objects. Thus, not every participating site requires all

shared data objects at all times. Instead, a site only re-

quires the shared data objects the user currently views

or edits.

To take this into account, a platform can replicate

a shared data object on demand, e.g. as soon as a

user accesses the part of a document that the shared

data object represents. When a site does not ac-

cess a shared data object anymore, e.g. the local user

changed his working focus, it has to discard it. Other-

wise the set of replicas continually grows and ﬁnally

the shared data object is replicated to all participating

sites. As the working style of a user is not determin-

istic, this approach can lead to high communication

costs.

A partially-replicated distribution scheme that

takes the changing working style into account, is

called adaptive or dynamic and was postulated by

Gavish et al. (Gavish and Sheng, 1990). Wolfson et al.

(Wolfson et al., 1997) describe a distributed algorithm

for an adaptive replication that uses a cost-function to

adapt the replication scheme of a shared data object.

They show that their algorithm compared to a static

replication signiﬁcantly reduces the network trafﬁc.

The discussion shows that every of the presented

distribution schemes has its drawbacks and advan-

tages and that none suits well for every groupware ap-

plication or for all data objects of an application. The

asymmetric distribution scheme ﬁts well when a user

wants to introduce local data into a collaborative ses-

sion. The replicated distribution scheme offers high

responsiveness. Developers choose an adaptive distri-

bution scheme, if they want to increase the availability

of a data object and, compared to the replicated dis-

tribution scheme, want to decrease the network trafﬁc.

They can also choose an adaptive distribution scheme,

if the data of an application can be divided into sin-

gle logical pieces, e.g. sections or paragraphs in a text

document, and they want to adapt the distribution of

the data to a user’s working style. Thus, to cover all

possible requirements of a collaborative application,

a platform has to support an asymmetric, a replicated,

and an adaptive distribution scheme.

3 RELATED WORK

There exist platforms that use a central, a replicated,

or a partially-replicated distribution scheme, others

offer a variety of distribution schemes.

Rendezvous (Hill et al., 1994), Suite (Dewan and

Choudhary, 1992), and Notiﬁcation Service Transfer

Protocol (NSTP) (Patterson et al., 1996) are sample

groupware platforms, which use a central distribu-

tion scheme for the data of a collaborative applica-

tion. A lot of groupware platforms, e.g., GroupKit

(Roseman and Greenberg, 1996), COAST (Schuck-

mann et al., 1996), or DECAF (Strom et al., 1998) use

the replicated distribution scheme. D

Agora (Sim

et al., 1997) is a sample platform for the partially-

replicated distribution scheme.

In contrast to the previous platforms, TCD (Ander-

son et al., 2000), Clock (Urnes and Graham, 1999),

GEN (O’Grady, 1996), and DistView (Prakash and

Shim, 1994) support a variety of distribution schemes.

DistView is a part of the Collaboratory Builder’s En-

vironment (CBE) (Prakash et al., 1999). Normally,

all shared objects are replicated. If this is not possi-

ble, e.g., if a shared object accesses a ﬁle in the local

ﬁlesystem, the shared object is maintained at the cre-

ating site. Thus, DistView supports a replicated and

an asymmetric distribution scheme.

TCD and Clock build groupware applications from

components. In both platforms, the components can

be customized via a visual programming environ-

ment. A developer may, e.g., choose between a

central and a replicated distribution strategy. While

TCD supports concurrency control for both distri-

bution schemes, Clock supports concurrency control

only for the central one.

GEN especially focuses on ﬂexible distribution

strategies. It provides shared objects as a high-level

abstraction and allows a developer to specify, how a

shared object is distributed and how its consistency

is maintained. For this purpose, the developer has to

be completely aware of the underlying concepts and

protocols, as he has to change the implementation. As

default, GEN offers implementations for a central and

a replicated distribution scheme. Additionally, GEN

offers a distribution scheme that is based on migra-

tion.

In summary, platforms for almost every distribu-

ICEIS 2004 - SOFTWARE AGENTS AND INTERNET COMPUTING

tion scheme exist. As already argued, every distribu-

tion scheme has its advantages and drawbacks. As

different applications or even single applications can

have different requirements, none of the distribution

schemes ﬁts well for every groupware application.

For this reason, some of the presented groupware plat-

forms support different distribution schemes, but none

supports an adaptive distribution scheme.

4 DREAMOBJECTS

DreamObjects is a platform that simpliﬁes the devel-

opment of shared data objects. It consists of two parts,

an object-oriented framework and a runtime environ-

ment. Both are entirely implemented in Java. The

object-oriented framework provides building blocks

for the development of shared data objects. These

building blocks offer a lot of conﬁguration possibil-

ities and even allow developers to integrate their own

solutions.

As already mentioned, DreamObjects enhances the

DreamTeam platform (Roth, 2000). At our insti-

tute, we created several groupware applications with

DreamTeam, e.g. a brainstorming tool, a collaborative

Web browser, and a distance teaching environment

(Lukosch et al., 1999). During the development, we

noticed that the major obstacles are concerned with

data sharing issues.

In our opinion, the development of a groupware

application should be almost as simple as the de-

velopment of a single-user application. A platform

should support a developer such that he can con-

centrate on application-speciﬁc details. For this rea-

son, we extended DreamTeam with DreamObjects.

They complement one another, reduce the develop-

ment costs for a collaborative application, and even

allow a developer to reuse existing single-user appli-

cations (Lukosch and Roth, 2001).

DreamObjects divides a collaborative application

in data objects and user interface objects. The data

objects are split up in shared and private objects. The

user interface objects control the user interface behav-

ior and display the content of the data objects. Users

collaborate by modifying the shared data objects via

the user interface of the application.

DreamObjects offers a set of services to man-

age the shared data objects, e.g. distributed method

calls and object creations. Most of the services

are handled completely transparent for developers

(Lukosch, 2002), i.e. they can use shared data ob-

jects like local objects of single-user applications. To

achieve this transparency, DreamObjects uses substi-

tutes (Lukosch and Unger, 2000), which are based

on the substitution principle of object-oriented pro-

gramming languages. A substitute class extends a

developer-deﬁned data class and overwrites some of

their methods to add functionality, e.g. the mecha-

nisms for modifying and reading method calls.

As a substitute class offers the same interface as

the developer-deﬁned data class, it can easily be used

to replace a developer-deﬁned data object. For this

purpose, a developer has to call a special registration

method of the runtime system, which creates and re-

turns the substitute to the developer. When calling

the registration method a developer has to provide the

runtime conﬁguration of the shared object. This, e.g.,

deﬁnes how the shared object is kept consistent or

how it is distributed to the other participating sites.

When a new shared object is registered, the regis-

tering site informs all other participating sites, which

results in creating a substitute for the new shared ob-

ject. Thus, each site can access a shared data object

like a local object. However, depending on the cho-

sen distribution scheme only some sites may hold the

data of the shared object. These sites are called data

holder. A data holder can execute a method call lo-

cally. A site that does not hold the data of a shared

object must involve a data holder in the execution of

a method call. Then the substitute for the shared ob-

ject maps possible method calls to data holding sites.

For this purpose, DreamObjects uses mechanisms that

reduce the number of involved sites to a minimum

(Lukosch, 2002). A reading method call is, e.g., only

executed by one data holding site, while a modifying

method call is executed by all data holding sites to

ensure the consistency of the shared data objects.

To fulﬁll the requirements as discussed in section 2,

DreamObjects offers an asymmetric, a replicated, and

an adaptive distribution scheme. When developers

distribution scheme for the shared object. Thereby,

developers can use the same data class with different

distribution schemes.

5 DISTRIBUTION SCHEMES

Let D denote the set of shared data objects used in

a collaborative session, let S denote the participating

sites, and ﬁnally let DH

⊆ S denote the sites that are

data holders of a shared object d ∈ D.

Each distribution scheme in DreamObjects is con-

trolled by an instance of an Evaluator class that

must be deﬁned during the registration of a shared ob-

ject.

5.1 Static Distribution Schemes

DreamObjects offers two predeﬁned evaluators for

static distribution schemes. The asymmetric distribu-

tion scheme ﬁts well, when a developer wants to allow

CUSTOMIZABLE DATA DISTRIBUTION FOR SYNCHRONOUS GROUPWARE

the users of a collaborative session to introduce local

data, e.g. a video that is stored in the local ﬁlesystem

of a user. The replicated distribution scheme ﬁts well

for highly interactive cooperative application, as it re-

duces the response time of an application.

DreamObjects uses an evaluator for a static dis-

tribution scheme to determine the set DH

, when

a shared data object d is created, and to determine

whether a latecomer’s site becomes a data holder of

a shared object d. Furthermore, the runtime system

uses an evaluator to sort the data holders in DH

when

a site s 6∈ DH

executes a reading method call. In a

ﬁrst attempt, the runtime system involves the ﬁrst site

in the execution of the reading method call. If an error

occurs, the runtime system passes the task to execute

the reading method call to the next site. Thereby, it is

possible to deﬁne arbitrary further static distribution

schemes.

If a developer, e.g., develops an application that

is used in a predeﬁned network, he can deﬁne an

speciﬁc evaluator and only distribute a shared ob-

ject to the sites that have a good network connection.

For this purpose, a developer has to extend the basic

Evaluator class and implement the three methods:

getDataHolders, becomesDataHolder, and

sortDataHoldersForRead. The runtime sys-

tem calls these methods in the respective cases. Fig.

5 shows the corresponding class hierarchy.

+getDataHolders()

+becomesDataHolder()

+sortDataHoldersForRead()

Evaluator

ReplicatedEvaluatorAsymmetricEvaluator

Figure 5: Class hierarchy of static evaluators

5.2 Adaptive Distribution Schemes

In case of a static distribution scheme, the set of data

holders only changes when either a site joins the ses-

sion or leaves the session. In case of an adaptive

distribution scheme, the set of data holders can also

change in dependence of how a site accesses a shared

data object. Developers choose an adaptive distribu-

tion scheme, if they want to increase the availability

of a data object and, compared to the replicated distri-

bution scheme, want to decrease the network trafﬁc.

To adapt the distribution of a shared object, the run-

time system informs the local evaluator for d about

the method call, whenever the local site initiated and

executed a method call directed to a shared object

d ∈ D. It passes the name of the method, a boolean

value that indicates, whether the method call modiﬁed

the content of the object, and the size of the shared

data object in bytes to the evaluator. Based on this in-

formation and the information about previous method

calls, the evaluator can initiate a change in the set of

data holders DH

DreamObjects associates a write master wm

∈

with every shared object. The write master

of a shared data object, e.g., ensures that a method

call or a method call result is distributed (Lukosch,

2002). When the write master of a shared object

leaves the session, DreamObjects deterministically

selects a new write master. Concerning adaptive data

distribution, the write master of a shared object en-

sures that the number of data holding sites does not

fall below a developer-deﬁned minimum. To ensure

the availability of a data object, the speciﬁed mini-

mum has to be greater than or equal to two. When

|DH

| falls below the speciﬁed minimum, the write

master wm

of the shared object increases the num-

ber of data holding sites.

To develop an evaluator for an adaptive distribu-

tion scheme, developers have to extend the basic

AdaptiveEvaluator class (see ﬁg. 6). Com-

pared to the static distribution schemes, following

methods must be implemented:

1. methodCalled: This method is called by the

runtime system, whenever the local site initiated a

method call. Based on the passed parameters, the

name of the method etc., this method has to de-

cide if the distribution of the shared object has to

be changed.

2. getMinDataHolders: This method has to re-

turn the minimum number of data holding sites.

3. getNewDataHolders: When the number of

data holding sites falls below the deﬁned minimum,

this method has to determine the sites that become

a data holder.

+getDataHolders()

+becomesDataHolder()

+sortDataHoldersForRead()

Evaluator

+methodCalled()

+getMinDataHolders()

+getNewDataHolders()

AdaptiveEvaluator

UserOrientedEvaluator NetworkOrientedEvaluator

Figure 6: Class hierarchy of adaptive evaluators

DreamObjects offers two pre-deﬁned evaluators for

an adaptive data distribution: a user-oriented and a

network-oriented evaluator. Both evaluators are based

on the following ideas:

ICEIS 2004 - SOFTWARE AGENTS AND INTERNET COMPUTING

1. If a site s 6∈ DH

intensively accesses a shared data

object d ∈ D, it should become a data holder. So

the site can execute reading method calls locally

and thus decrease the response time of the applica-

tion.

2. If a site s ∈ DH

does not access a shared data ob-

ject d ∈ D frequently, it should give up its role as

a data holder. So the number of data holding sites

is reduced. This decreases the number of messages

that is necessary to keep a shared data object con-

sistent and thus the response time of an application

at every site.

5.2.1 User-oriented Adaptive Distribution

Developers choose the user-oriented distribution

scheme, if the data of an application can be divided

into single logical pieces. For instance, consider a

collaborative text editor. A text document is struc-

tured into single logical pieces, i.e. words, sentences,

paragraphs, sections, and chapters. Depending on the

kind of collaboration that a developer wants to sup-

port between the users of the collaborative text editor,

he can use a shared data object for every single word,

sentence, etc. of the text document. Normally, only

a few users of a text editor work at the same logical

piece of the document. The user-oriented distribution

scheme takes this into account and distributes a data

object to those sites that intensively access it. As a

user’s working style can change during a collabora-

tive session, the evaluator reﬂects these changes in the

distribution of the shared data object.

When a new object d ∈ D using this scheme is cre-

ated, the evaluator as default selects two of the par-

ticipating sites as initial data holders. One of the data

holding sites is the object creating site s

, which also

becomes the initial write master wm

. To select the

other initial data holders for the shared data object,

the evaluator chooses the sites with the fastest net-

work connection.

When a site s 6∈ DH

initiates a reading method

call, one of the data holding sites has to execute the

method call. To determine this site, the evaluator sorts

the data holding sites according to their network con-

nection. In a ﬁrst attempt, a site s 6∈ DH

selects the

ﬁrst site in the list to execute the reading method call.

If this site fails, the next one is selected, until there is

no site left in the list or the method call was executed.

When a site joins a session, the evaluator has to

decide whether this site becomes a data holder of d. A

latecomer’s site only becomes a data holder if |DH

is lower than the deﬁned minimum.

To adapt the distribution of a shared data object to

the working style of the collaborating users, the eval-

uator observes how a site accesses and uses a data ob-

ject. It uses the information about every method call

the local site initiates to calculate an overall load, a

read load, and a write load in calls per second. The

overall load includes all, the read load the reading,

and the write load the modifying method calls.

To calculate these values, the evaluator for a data

object d at a site s counts how many reading, modify-

ing, and general methods of the data object the local

site calls in a developer-deﬁned period of time ∆t.

Every ∆t the evaluator calculates new load values.

All load values in calls per second are calculated in

the same way. When, e.g., ol

denotes the current

value of the overall load at a site s for a data object d,

denotes the developer-deﬁned weight of the last

load value, and mcs denotes the number of all method

calls in the last period of time ∆t, the evaluator cal-

culates the new overall load ol

as follows

= ol

mcs

∆t

(1−w

), with 0 ≤ w

≤ 1.

A developer can specify different weight values

and can set minimum and maximum limits for every

load. When at a site s ∈ DH

a load falls below a

minimum limit, the evaluator decides that the site s

does not need to be a data holder anymore. Then, the

site s informs the other participating sites which re-

move s from the set of data holders DH

. After s was

removed, it is not notiﬁed about modifying method

calls anymore and the network load is reduced. To

ensure the availability of a shared object, a site may

just give up its role as data holder, if |DH

| is greater

than the deﬁned minimum.

When at a site s 6∈ DH

a load exceeds a maximum

limit, the evaluator calculates the expected transmis-

sion time of the shared data object. By specifying

a maximum transmission time, a developer can pre-

vent that large data objects are transferred to a site

with a poor connection type. If the expected time is

below the developer-deﬁned maximum, the evaluator

requests the state of the data object, stores it in the

local substitute for d, and informs the other partici-

pating sites about the new data holder s.

5.2.2 Network-Oriented Adaptive Distribution

Developers use the network-oriented distribution

scheme for shared data objects that rarely change and

that are mostly accessed with reading method calls,

e.g. shared data objects that contain the conﬁguration

of a shared application.

To reduce the network trafﬁc and thus the response

time of an application in this case, the network-

oriented distribution scheme attempts to optimize the

distribution of a shared data object with regard to

the underlying network structure of the collaborating

group. When a new object using this scheme d ∈ D

is created, the evaluator determines a partition of sub-

CUSTOMIZABLE DATA DISTRIBUTION FOR SYNCHRONOUS GROUPWARE

sets SN

S =

[

i=0

, with n ∈ N

For this purpose, the evaluator checks the IP ad-

dress of every site. Sites whose IP address only varies

in the last octet are assumed to be in one subnet and

added to one subset SN

. After this, the evaluator se-

lects one site from every subset SN

as a data holder

of the new shared object. For the subset SN

with

∈ SN

, the object creating site s

is chosen as the

data holding site. In the other subnets, the evaluator

chooses the site with the fastest network connection.

This is done for the following reasons:

• Usually, sites in a subnet have a good network con-

nection to each other, i.e. there is a low network de-

lay and a high transfer rate between the sites. If one

site s in a subset SN

is a data holder of a shared

data object d ∈ D, the other sites in the subnet can

access d via s.

• As only one site in every subnet becomes a data

holder of the shared data object, the number of data

holders, compared to, e.g., the replicated distribu-

tion scheme, is reduced. This, e.g., decreases the

network load for modifying method calls and thus

the response time of an application.

When a new shared object is created, the evaluator

selects one site from every subnet to become a data

holder. Of course, the object creating site becomes

a data holder. If the participating sites cannot be di-

vided into as many subnets as the deﬁned minimum

of data holding sites, the evaluator sorts the sites ac-

cording to their network connection. From these sites,

the evaluator selects as many sites as are necessary ac-

cording to the deﬁned minimum.

When a site joins a session, the evaluator has to

decide, whether this site becomes a data holder of d.

The evaluator checks if the joining site belongs to one

of the subsets SN

. In this case and if |DH

| is greater

than or equal to the deﬁned minimum, a latecomer’s

site does not become a data holder. If the latecomer’s

site is the ﬁrst site of a new subnet, it becomes a data

holder in any case.

When a site s 6∈ DH

executes a reading method

call, it is the task of the evaluator to determine a sorted

list of data holding sites. For this purpose, the evalu-

ator sorts the list of data holding sites as follows. For

a site s ∈ SN

, the data holding sites in the same sub-

net, i.e. SN

∩ DH

, are put into the ﬁrst places. After

the data holding sites from the same subnet SN

were

added to the list, the evaluator adds the rest of the data

holding sites to the list. Again, data holding sites with

a better network connection are rated higher than oth-

ers.

To adapt the distribution, the evaluator again cal-

culates an overall load, a read load, and a write load

(see section 5.2.1). A developer can again set mini-

mum and maximum limits for the different load and

can specify a maximum transmission time. When at a

site s 6∈ DH

a load exceeds a maximum limit and the

expected transmission time is below the developer-

deﬁned maximum time, the evaluator requests the

state of the shared object d and the site s becomes

a data holder of d.

When at a site s ∈ DH

a load falls below a mini-

mum, the evaluator decides that the site s has to give

up its role as a data holding site. However, to en-

sure that each subnet contains at least one data hold-

ing site, a site must not give up its role as data holder

if there is not another data holder in its subnet. Addi-

tionally, a site must not give up its role as data holder

if the number of data holders is less than or equal to

the deﬁned minimum or if it is the write master.

6 CONCLUSIONS

An ideal platform has to support a variety of distribu-

tion schemes, as different applications or even single

applications have different requirements concerning

data distribution. Compared to the other platforms

discussed in section 3, DreamObjects does not only

support the common asymmetric and replicated dis-

tribution scheme, it also supports two adaptive distri-

bution schemes. One of these distribution schemes

adapts the distribution of a shared data object in re-

lation to a user’s working style. The other distribu-

tion scheme attempts to optimize the distribution of a

shared data object with regard to the underlying net-

work structure of the collaborating group. The sup-

ported distribution schemes can be applied on a per-

object basis and ﬁrst have to be deﬁned at object reg-

istration time. Thus, a developer can use the same ob-

ject with different distribution schemes. In addition

to the supported distribution schemes, DreamObjects

offers an interface that enables developers to deﬁne

their own distribution schemes and to integrate them

into the platform.

Nevertheless, there are still open issues. The adap-

tive distribution schemes use a heuristic approach. A

developer can deﬁne limits for different load values.

Based on these limits, an evaluator decides, whether

it changes the distribution of a shared data object

or not. As already argued, it is an application- and

network-dependent task to choose appropriate limits.

However, DreamObjects enables further research in

adaptive distribution schemes for collaborative appli-

cations, e.g. to evaluate different limits for different

application types and network topologies. The results

could be used to provide a developer with a set of

instructions, how to choose the appropriate evaluator

for a data object.

ICEIS 2004 - SOFTWARE AGENTS AND INTERNET COMPUTING

REFERENCES

Anderson, G. E., Graham, T. N., and Wright, T. N. (2000).

Dragonﬂy: Linking Conceptual and Implementation

Architectures of Multiuser Interactive Systems. In

Proceedings of the 22nd International Conference on

Software Engineering, ICSE 2000, pages 252–261,

Limerick, Ireland.

Dewan, P. (1996). Multiuser Architectures. In Proceed-

ings of IFIP WG2.7 Working Conference on Engi-

neering for Human-Computer Communication, pages

247–270.

Dewan, P. and Choudhary, R. (1992). A High-Level and

Flexible Framework for Implementing Multiuser In-

terfaces. ACM Transactions on Information Systems,

10(4):345–380.

Garcia-Molina, H. (1986). The Future of Data Replication.

In Proceedings of the IEEE Symposium on Reliability

in Distributed Software and Database Systems, pages

13–19, Los Angeles, CA, USA.

Gavish, B. and Sheng, O. R. L. (1990). Dynamic File Mi-

gration in Distributed Computer Systems. Communi-

cations of the ACM, 33(2):177–189.

Hill, R. D., Brinck, T., Rohall, S. L., Patterson, J. F.,

and Wilne, W. (1994). The Rendezvous architecture

and language for constructing multiuser applications.

ACM Transactions on Computer-Human Interaction,

1(2):81–125.

Lukosch, S. (2002). Adaptive and Transparent Data Dis-

tribution Support for Synchronous Groupware. In

Groupware: Design, Implementation, and Use, 8th

International Workshop, CRIWG 2002, LNCS 2440,

pages 255–274, La Serena, Chile. Springer-Verlag

Berlin Heidelberg.

Lukosch, S. (2003). Transparent and Flexible Data

Sharing for Synchronous Groupware. Schriften zu

Kooperations- und Mediensystemen - Band 2. JOSEF

EUL VERLAG GmbH, Lohmar - K

oln.

Lukosch, S. and Roth, J. (2001). Reusing Single-user

Applications to Create Multi-user Internet Applica-

tions. In Innovative Internet Computing Systems

CS), LNCS 2060, pages 79–90, Ilmenau, Germany.

Springer-Verlag Berlin Heidelberg.

Lukosch, S., Roth, J., and Unger, C. (1999). Marrying On-

Campus Teaching to Distance Teaching. In Proceed-

ings of the 19th World Conference on Open Learning

and Distance Education, Vienna, Austria.

Lukosch, S. and Unger, C. (2000). Flexible Management of

Shared Groupware Objects. In Proceedings of the Sec-

ond International Network Conference (INC 2000),

pages 209–219, University of Plymouth, United King-

dom.

O’Grady, T. (1996). Flexible Data Sharing in a Group-

ware Toolkit. Master’s thesis, University of Calgary,

Department of Computer Science, Calgary, Alberta,

Canada.

Patterson, J. F. (1995). A Taxonomy of Architectures for

Synchronous Groupware Architectures. ACM SIGOIS

Bulletin Special Issue: Papers of the CSCW’94 Work-

shops, 15(3):27–29.

Patterson, J. F., Day, M., and Kucan, J. (1996). Notiﬁ-

cation Servers for Synchronous Groupware. In Pro-

ceedings of the ACM 1996 Conference on Computer

Supported Cooperative Work, pages 122–129, Boston,

Massachusetts, USA.

Prakash, A. and Shim, H. S. (1994). DistView: Support

for Building Efﬁcient Collaborative Applications us-

ing Replicated Objects. In Proceedings of the ACM

1994 Conference on Computer Supported Coopera-

tive Work, pages 153–164, Chapel Hill, NC, USA.

Prakash, A., Shim, H. S., and Lee, J. H. (1999). Data Man-

agement Issues and Trade-Offs in CSCW Systems.

IEEE Transactions on Knowledge and Data Engineer-

ing, 11(1):213–227.

Roseman, M. and Greenberg, S. (1996). Building

Real-Time Groupware with GroupKit, A Groupware

Toolkit. ACM Transactions on Computer-Human In-

teraction, 3(1):66–106.

Roth, J. (2000). ’DreamTeam’: A Platform for Synchronous

Collaborative Applications. AI & Society, 14(1):98–

119.

Roth, J. and Unger, C. (2000). An extensible classiﬁcation

model for distribution architectures of synchronous

groupware. In Proceedings of the Fourth International

Conference on the Design of Cooperative Systems

(COOP2000), Sophia Antipolis, France. IOS Press.

Schuckmann, C., Kirchner, L., Sch

ummer, J., and Haake,

J. M. (1996). Designing object-oriented synchronous

groupware with COAST. In Proceedings of the ACM

1996 Conference on Computer Supported Coopera-

tive Work, pages 30–38, Boston, Massachusetts, USA.

Sim

ao, J., Domingos, H. J., Martins, J. L., and Preguic¸a,

N. (1997). Supporting Synchronous Groupware with

Peer Object-Groups. In Proceedings of the Third

USENIX Conference on Object-Oriented Technolo-

gies (COOTS), Portland, Oregon, USA.

Strom, R., Banavar, G., Miller, K., Prakash, A., and Ward,

M. (1998). Concurrency Control and View Notiﬁca-

tion Algorithms for Collaborative Replicated Objects.

IEEE Transactions on Computers, 47(4):458–471.

Urnes, T. and Graham, T. N. (1999). Flexibly Mapping Syn-

chronous Groupware Architectures to Distributed Im-

plementations. In Proceedings of Design, Speciﬁca-

tion and Implementation of Interactive Systems (DSV-

IS’99).

Wolfson, O., Jajodia, S., and Huang, Y. (1997). An Adap-

tive Data Replication Algorithm. ACM Transactions

on Database Systems, 22(2):255–314.

CUSTOMIZABLE DATA DISTRIBUTION FOR SYNCHRONOUS GROUPWARE