W. Wang, B. Dorohonceanu, and I. Marsic. Design of the DISCIPLE ... Internet and Multimedia Systems and. Applications, Nassau, Grand Bahamas, October 1999.
Proceedings of the ACM International Conference on Supporting Group Work (GROUP'99) November 14-17, 1999, Phoenix, AZ.
Collaboration Transparency in the DISCIPLE Framework Wen Li, Weicong Wang, and Ivan Marsic CAIP Center Rutgers — The State University of New Jersey Piscataway, NJ 08854-8088 USA +1 732 445 6399 {vinceli, weicong, marsic}@caip.rutgers.edu ABSTRACT
Sharing single-user software applications is a major goal of synchronous groupware particularly because the majority of applications continues to be developed for single users. We present a mechanism for sharing collaboration-transparent single-user applications in our DISCIPLE collaboration framework. DISCIPLE is the equivalent of a Web browser that allows sharing applets (Java components, both transparent and aware of collaboration). It allows users with no programming background to quickly assemble arbitrary collaborative applications. Even though the presented solutions are specific to Java, many apply to other platforms as well. We introduce a novel concept of resource servers to solve the problem of resource access in collaborationtransparent applications. We also discuss the limitations of the framework in particular and of sharing collaboration-transparent applications in general. The framework has been implemented and tested on a variety of applications. Preliminary experimental results are reported. Keywords
CSCW frameworks, synchronous groupware, collaboration-transparent applications, JavaBeans. INTRODUCTION
Development of single-user applications is generally an expensive and challenging effort. Development of multi-user applications introduces many more degrees of complexity. The problem is well recognized and there is a large body of work in real-time synchronous groupware. Nevertheless, multiuser applications lag behind in features or compatibility with single-user applications. This is worsened by the inadequacies of the current window systems for application sharing. Even though these issues are well known [16], they remain ignored in the latest graphics toolkits, such as Java GUI toolkits. Sharing collaboration-transparent applications received great interest in the 1980s [2,9,13,15,16,22]. It was then predicted to be the dominant technology for synchronous collaborative work in the near future [13]. However, in the recent years researchers have mostly turned to
collaboration-aware applications. Despite the great benefits of sharing collaboration-transparent applications, the need for collaboration awareness was recognized early on [17]. While the present work acknowledges the need for collaboration awareness, it pushes the frontier for collaboration-transparent applications further. The objective of the DISCIPLE project is to develop a collaboration-enabling framework to simplify the development of multi-user collaborative applications [19]. An important goal is to provide support for applications that are not originally developed for group usage, i.e., collaboration-transparent applications. We target a particular class of collaboration-transparent applications—Java applications or applets that comply with the JavaBeans specification [24]. The reason for focusing on JavaBeans is that JavaBeans, along with ActiveX controls from Microsoft [10], represent a strong software industry trend towards standardizing software development through reusable software components. Components enable rapid application development using third party software: independent components are used without modifications as building blocks to form composite applications. We expect there will be a great variety of software components commercially available or as freeware/shareware on the Internet in the near future. We require specific constraints on the applications to be shared in order to make the solution feasible. Java has a great appeal due to its platform independence and dynamic code download, but introduces certain difficulties not present in solutions based on native environments. Our aim is to provide the maximum flexibility and keep the restrictions at minimum. A key tool used to avoid the need for programming intervention on the user's part is dynamic bytecode modification. We use the Java Object Instrumentation Environment (JOIE) [7] for this purpose. We dynamically modify the nonsystem (i.e., excluding the JDK and DISCIPLE) bytecode and substitute the relevant classes with custom ones. The paper is organized as follows. We first review the state of knowledge and work in progress. After briefly reviewing the DISCIPLE framework, we present our approach to sharing user events from input devices. The following section addresses the issues that arise when the application accesses external resources. We then present a novel solution with resource servers. Finally, we discuss the limitations of sharing single-user applications and the need for collaboration awareness.
Figure 1: Common techniques for sharing collaboration-transparent applications: (a) slightly modifying the application code to relate (e.g., inheritance) to the collaboration framework classes, (b) substituting the underlying window system or graphics toolkit, and (c) interposing a conference agent between the application and the window system. Related Work
Sharing collaboration-transparent applications involves one of the one of the techniques shown in Figure 1. Examples of (a) are [1,6]; examples of (b) are [4,12]; examples of (c) are most shared window systems, such as [9,17]. The agent in the last technique intercepts the user input events usually by tapping into the system event queue or by delegating a special transparent window to intercept the events destined for the shared window. The first technique can take place at run-time transparently to the user (e.g., [3]). The DISCIPLE system uses a hybrid approach that combines both (a) and (c). Lauwers and Lantz [15,17] did the first in-depth study of collaboration-transparent application sharing in windowbased environments. Their system Dialogo supports collaboration-transparent applications in the X Window System by running a conference agent that is interposed between applications and the window system. The agent controls the system event queue. Dialogo successfully addresses many constraints imposed by the underlying window systems. JAMM [4] substitutes the default Java AWT window toolkit with a new one which intercepts the events and multicasts them to the peer applications. The single-user applications can be used as is, but the underlying Java toolkit has to be replaced. An additional problem with this approach is that the entire substitute toolkit needs to be re-built every time a new version of the original toolkit is released. Although our approach also depends on certain Java classes, the dependencies are much fewer. [4] discusses ways to handle resource access, but does not attempt implementation. ITU T.128 [14] defines a protocol for sharing of collaboration-transparent applications. It uses a centralized groupware architecture where only one user runs the application while others receive a bitmap of the application's window. Access to resources, such as files, databases, and network connections, does not pose a problem since there is only one copy of the shared
application. There are several commercial systems that use this approach, of which probably the best known is Microsoft NetMeeting [20]. It provides for sharing of collaboration-transparent Windows applications. NetMeeting does not posses cooperative features such as coupling or group awareness and has only a floor control type of concurrency control. AT&T’s VNC [21] also uses centralized architecture but works on a variety of computing platforms. One client implementation is a Java applet, whereas the server is platform-dependent and runs on the machine whose desktop is being shared. The Habanero framework [6] and Java Collaborative Environment [1] provide for pseudo-collaborationtransparency since the user is required to modify the code of single-user applications before sharing them. New multiuser applications can also be developed as single-user with no knowledge of collaboration. However, even though the code modification is fairly straightforward, it is a great obstacle for non-Java programmers. Once the modification is done, the application is no longer an independent entity since it is typecast for the particular collaborative framework. Neither framework addresses events other than the user input. Flexible JAMM [3] uses the Java dynamic binding feature to replace some of the Java GUI classes with custom ones. Thus it modifies the application but this is transparent to the user. Sharing is limited to distributing user-input events although an idea is presented of resource access through replicated proxies. DISCIPLE uses a similar approach, but introduces the concept of resource servers that provide for sharing of inputs from other sources. THE DISCIPLE FRAMEWORK The central idea of the DISCIPLE framework is to
provide a shared container where the applications (Java components) can be loaded very much like Java applets are downloaded to a Web browser, with the addition of
Figure 2: Snapshot of a user view of a DISCIPLE collaboration place with three sample beans (Whiteboard, Chat and Calendar). group sharing. The system is based on a replicated architecture for groupware [15,17]. Each conference participant runs a copy of collaboration client, and each client contains a copy of the application(s) used in collaboration. Collaboration in this type of architecture essentially translates into watching for state changes occurring in an application and replicating the changes to all the peer users' applications. The central part of DISCIPLE is conceptualized as the collaboration bus [25]. It spans network fabrics and provides a virtual interconnect for geographically distributed clients. Collaborating users import Java components by dragand-drop manipulation into the shared workspace. The imported component becomes a part of a multi-user application and all conferees can collaboratively interact with it. The bus achieves synchronous collaboration through real-time event delivery, event ordering and concurrency control. The set of all collaboration participants is structured to reflect various people groupings as in everyday life. The basic unit is a meeting place where two or more participants collaborate on a particular topic and share a set of Java components. A workspace is a client visualization of a meeting place and provides an individual view of the place [11]. The workspace window gets automatically launched as the user enters a place. A current version of the DISCIPLE workspace graphics interface is shown in Figure 2. Sharing a bean in collaboration is as easy as pointing to its URL. A bean can be loaded from a local file system or, given the
bean's URL, it can be loaded from a Web server. The toolbar on top provides for opening the Bean browser, changing the telepointers color and getting help, respectively. In addition, the toolbar has three buttons per each bean in the workspace: show minimized/hidden, activate/deactivate telepointers, and activate/deactivate radar view. As is the case with the overall desktop view, the Workspace does not require the same view across all clients—each conferee can position the beans at different locations within the Workspace. Thus, application sharing is not in a strict WYSIWIS (What You See Is What I See) [23] mode. Beans view consistency will be explained in the following sections. The telepointers and radar views are provided at the bean level because users are free to adjust the size and position of each bean in the workspace. We chose to exclusively use the Swing toolkit due to the problems with heavyweight Java AWT toolkit. Java Swing components do not have native opaque windows associated with them, and require no native data structures or peer classes. This leads to complete consistency across different platforms. DISCIPLE supports simultaneously both collaboration-
aware and collaboration-transparent applications. The only difference from the framework's point of view is that the former behave cooperatively by exposing more internal structure and doing partial event management, whereas the latter expose only basic structure which is the default for Java components. As a result, the latter
are much more difficult to handle and the rest of the paper presents our approach.
:
;
?
@
1
2
USER INPUT EVENTS 0
The most common events are input device (keyboard, mouse) events. Our initial approach [18] was based on the property of Java Development Kit (JDK) version 1.1 event model that any object can register as an event listener to the event sources and all listeners get notified upon the event occurrence [24]. We call this approach bottom-up since it assumes knowledge about the application's internal structure. Unfortunately, while we can capture events this way, we cannot intercept them before they get executed locally and thus cannot provide any type of concurrency control. The approach works for collaboration-aware applications that behave cooperatively and either do not execute the event before being permitted or provide an undo mechanism. If Java would provide facilities to make the source surrender the listeners, the approach would work in the collaborationtransparent case, too. We would just seize all listeners from all sources and register ourselves as listeners. Since we need to account for the new listeners and for the listeners that dynamically unregister, we would need the following method:
G
H
I
I
J
K
L
M
N
3
A
B
B
C
D
E
4
5
6
6
7
5
8
9
F
Figure 3: The component of container covers all other components without occluding them. corresponds to the workspace shown in Figure 2. O
P
O
Q
P
R
Q
R
R
V
V
R
V
W
S
W
S
X
Q
X
T
Q
X
X
U
T
Y
Y
W
V
X
W
X
X
Y
X
Z
Y
[
Z
[
\
U
Z
Z
\
]
]
[
[
\
\
]
]
and deleted, and there can be a large number of them. Keeping such dynamic IDs synchronized across the peers is difficult. To simplify the ID synchronization, we assume that the bean's GUI components are created in a single thread (this does not imply that the bean is singlethreaded). This ensures that the components are added or removed in the same order and the IDs are assigned as the components are added to the container.
!
This way, the call to the old source would be automatically rerouted to the new owner of the listeners, i.e., to the new source. Finally, upon event occurrence, we would selectively deliver the event to the original listeners. The top-down approach treats the application as a black box and intercepts the events before they reach the application. Beginning with JDK1.2, we can intercept events by reading the . But, since this queue is system-wide, we first need to filter out the events destined for the public workspace. The solution would be similar to shared window systems [2,9,17], but would fall short due to the reasons listed earlier. Additionally, it is hard to implement and would end up duplicating the functions of the Java event dispatch mechanism. "
#
$
%
&
'
(
$
(
$
Another top-down approach is to intercept all the user events (mouse, keyboard, input focus events) using a transparent GUI component called , which is available in the Swing toolkit. It is at the topmost Zorder to cover the bean's GUI area and intercepts all the user's events, without occluding the underlying Java component (Figure 3). The can also be dynamically shrunk or expanded, thus allowing easier management of public and private areas of the same workspace. An additional benefit is the accompanying visual effects on the remote sites as well (e.g., mouse click results in a depressed button). )
)
*
+
,
,
*
-
+
+
,
.
,
-
+
.
/
/
A major issue requiring attention is the granularity of target components for remote event delivery. We could either deliver the events to the target bean or directly to the target GUI component within the bean. In either case, we need a unique ID for the target. The triplet (placeID,beanID,componentID) uniquely identifies a component. The components are dynamically inserted
Mouse Events
The system maintains two hash tables, beanID-toreference and beanReference-to-ID, that cross-map between the beans and their IDs to simplify the two-way lookup. The moment the bean gets loaded into the workspace, the system adds a corresponding entry into both tables. Any time an event gets intercepted by the , we need to locate the deepest component in the underlying layer whose bounding box contains the mouse position and set that as the event's source attribute value. After determining the event source, the event could be directly dispatched to it. But this approach causes a system event queue deadlock upon opening a modal dialog. Thus, instead we post the event to the system event queue. )
*
+
,
,
-
+
.
/
The beans do not necessarily cover the entire workspace. If the event does not belong to any bean, it gets dispatched only locally to the workspace. If contained within a bean in the workspace, the event gets dispatched both locally and remotely. For remote dispatch, it gets converted to a remote event object, comprised of the event and the bean's ID. Remote recipients convert it to a local event and use the ID to look up the bean to which the event gets delivered. The event coordinates are transformed to the bean's local coordinate space, relative to the bean's top left corner. An important result is that the same bean can be at different locations in different users' workspaces. Using a finer-granularity IDs to identify the event source, i.e., ID-per-component, makes it possible for conferees to have different sized beans. Here we should be aware of a possibility for duplicate dispatch because user inputs often trigger another kind of event, semantic events. For example, if the user clicks a button we intercept the mouse event and replicate it to
the peers. But then, on the event origin site, the button fires the action event, which should not be replicated. Thus, only the user input events are replicated1. Keyboard Events
To intercept the keyboard inputs we need to let the have the input focus and this causes problems. After dispatching the intercepted events to the underlying target, we need to request focus back onto the to continue intercepting the keyboard events. This activity may interfere with the activity of the . If in the process we lose track of the underlying focus owner, unpredictable things could happen. A simple solution is to track the underlying focus owner before we request the focus back to the topmost component. Another solution is to dynamically modify the application's bytecode and replace the object with our own implementation. Problems arise since the application may have a custom . Since we do not know the custom implementation, we cannot reproduce its functionality and the user may have to tolerate a different focus management style from the original one. In addition, operations that rely on having the focus may not function properly. For example, the caret of text component will not be shown because always grabs the focus2. As a result, at present we introduce the following restrictions on the application: ^
_
`
a
a
b
`
c
d
^
_
`
a
a
b
`
c
d
e
f
g
h
i
j
k
l
k
e
f
g
h
i
j
k
l
k
m
n
o
e
f
g
h
i
j
k
l
k
m
n
o
m
n
o
p
q
k
i
i
r
k
l
n
1. It should not hold or transfer the focus directly 2. It should not replace the underlying focus manger with a customized one 3. The focus transfer preferred mode is via the mouse rather than the tab key. The restrictions can be relaxed if the user is willing to tolerate focus behavior different from the original one.
owner as the event's source attribute and dispatch the event. • Assume that all peers create and add components in the same order. Two additional hash tables keep the information about the relationship between the component ID and the component. The component ID is used to identify the event source. The first approach is more efficient to deal with keyboard input. It is very simple and direct, but in some cases may suffer concurrency control problems. As an example, let us assume there are two text-fields TF1 and TF2 in a bean. At a certain time, user m may have TF1m as focus owner that gets the key input. Before the key input event is distributed to the peers, TF2m may become focus owner for some reason. Then TF2 in the peers' beans will get the key input that should have been targeted to TF1. We need to introduce two assumptions to solve the problem: (i) the only cause for focus events is user input, and (ii) focus event can be triggered atomically. (i) is valid in most cases, but (ii) fails in many cases and the concurrency control problem persists. To assume that each place has the same component as the current focus owner is dangerous since the focus event will not be triggered when the workspace window containing the bean does not have the focus. If at first TF1 has focus on all sites and then user m clicks the mouse on TF2m, TF2 is supposed to become focus owner. However, if the workspace at the remote site n does not have focus at that moment, the focus event will not be generated in response to receiving the mouse event from site m. The remote site n will continue to think TF1n is the focus owner, while the site m thinks TF2m is the focus owner. The second approach is very basic and also a necessary condition for the successful replication of s because we must make sure the same component is at the same position relative the bean it belongs to. This approach can be used to speed up the distribution of s since only one of the peers needs to compute which is the deepest component—the source of the event. At present, DISCIPLE implements this approach.
Tracking the Last Owner of Keyboard Focus
Before the grabs the focus from other components, the original focus owner has to be recorded because we need to know the 's actual source object. We use the bottom-up approach to add a focus listener to all components added to the place. Each time the listener receives a , it records the actual focus owner, acquires the focus and passes it to the . p
q
k
i
i
r
k
l
n
s
z
{
|
}
~
v
w
t
t
x
u
v
w
t
x
y
y
{
v
w
t
x
}
t
~
v
~
x
t
x
y
y
If the bean activates additional windows not covered by , the above techniques are not satisfactory since the events in the newly created window will not be intercepted and replicated. Here we discuss what we call property windows, since their purpose is to modify certain application properties. The dialog windows which initiate I/O communication are addressed in the following section.
s
t
u
v
w
t
x
{
}
~
t
v
w
t
x
y
y
• Assume that the current focus owner for all peers is the same GUI component. When peers receive a from remote, they set their current focus t
u
v
w
t
x
~
To distribute a , it is enough to know the ID of a bean since the JDK has a utility function to get the deepest component in a container. However, to distribute a , we have to keep track of the last focus owner. There are two alternative approaches to identify the source:
y
~
x
t
Figure 4 shows a typical scenario. A local copy of the application launches a new dialog which automatically gets launched at the remote peers. Since only the application's window is covered with the , the events in the dialog will not get replicated.
~
2
t
Handling the Additional Windows
Identifying Event Source
1
w
~
s
~
t
}
{
Focus events are another example of semantic events and thus are not replicated remotely in our implementation. We solve this problem by replacing the original caret manager with a custom one.
~
x
t
A possible solution is to create a new to cover the dialog. A problem arises when the captured event has to be delivered on a remote machine and the target component needs to be identified. First, we need to determine the ID of the bean that created the dialog
~
~
x
t
approach is that it is system-independent. But, system dependence is unavoidable if we want to make it flexible. Since no general solution is possible, we solve it on a case-by-case basis and try to make it as flexible as possible. For example, will have system-dependent view since it displays local disk information that is likely to be different at each site. This makes event distribution more difficult because the same mouse position may correspond to different GUI components on different hosts. ¬
Figure 4: The application launches a dialog box which is not covered by the . º
º
»
»
¼
½
¼
½
½
¾
½
¼
¾
¿
¼
À
¿
À
box. Unfortunately, a popped up component does not know which bean popped it up. We considered dynamic bytecode modification to add a statement just after the constructor of a popped component is called and pass the bean ID as an argument. However, the problem recurs since the caller does not know the bean ID either. Second, at a remote site, we need to identify the dialog given the bean's ID. The difficulty arises because the beans are “non-cooperative” in this process, for they are not programmed to be such. Generally, both steps are hard, and even harder if the users participate in meetings with multiple unaware workspaces. We simplify the problem by introducing an additional constraint. The conferees can collaborate in only one place at a time with unaware beans. The workspace has a class (static) variable as a counter and uses it as the component's ID. In addition, the popped-up components must be Swing components ( , , , etc.)3. The reason is that only a has the . Dynamic bytecode modification substitutes the relevant classes with custom ones. For example, gets substituted with a custom-made class , which extends and overwrites its methods. When the new class becomes instantiated, it receives an ID by a static method call which increments the component counter. But merely replacing all direct references to , and is not enough, for in some cases there are indirect references. For instance, pops up a modal dialog.
¡
£
£
¢
£
¤
¢
¤
¡
¡
©
ª
«
¥
¥
£
¤
¡
£
¥
¤
¦
¡
¤
¥
§
¨
¬
®
¯
°
±
²
³
³
´
°
µ
To implement the above technique, we could either: • Add s to the popped windows, frames or dialogs to intercept input events and replicate them. ¶
¯
·
´
´
¸
·
¹
°
• Activate the additional windows, frames or dialogs only locally.
®
¯
°
±
²
³
³
´
°
µ
The second approach seems better if we want to avoid all users interacting with the dialog. It is reasonable to assume that the person who initiates the dialog knows what they are doing. They should know whether the dialog could be completed successfully. The others may get confused about the dialog: they may wonder whether they all should enter the same values, and if yes, why do they need to do this extra work? To implement this approach, we need to know which input event will lead to window activation so that we can suppress it on remote sites. A more difficult problem with this approach is replicating the result of the dialogue. Again, a general solution is not possible. RESOURCE ACCESS
Resource access is a major issue with collaborationtransparent applications. Resources include files, network ports, data acquisition devices, databases, etc. Given that the application itself is exactly replicated to all peer collaborators, each copy requires the same resources. Resources are accessed either at initialization time or in response to user input events. A usual approach to solving this problem is to require exact replication of the resources across all conferees [9,17]4. This can be done by other applications, e.g., FTP, ahead of the meeting, or the collaborative system itself may provide for replication. The problem is that it is not always possible to replicate the application's environment. Not all users will have access to all resources—the resource may be unique or expensive to replicate. Even if the resource were replicated this may be insufficient in some cases. For example, if all conferees had monitoring instruments locally, these instruments may generate different data. Thus, environment replication does not offer a general solution. Here we offer a solution based on resource servers. Resource Servers
There are still many problems with both approaches. Our current implementation uses the first approach. As mentioned earlier, the basic assumption of
To access a resource (file, network port, data acquisition device, etc.), we propose that there should be a centralized agent, we call it resource server, which serves as a point-of-contact for resource access.
3
Introducing the concept of resource servers simplifies the access to the resources, especially if resources are unique
¶
¯
·
´
´
¸
·
¹
°
Even though a solution for non-Swing components seems feasible, we have not pursued it at present. Theoretically, we could implement our own component toolkit to substitute the heavyweight AWT components with Swing components by overriding their nonprivate member methods. But this is not feasible in practice. Notice that it is not enough to substitute only the containers (window, frame and dialog) since the application may add heavyweight components like button and text field to the containers.
4
Another option is modify the external environment to make it collaboration-aware. The resource drivers get modified so that they know when they are communicating with shared applications. This option is usually not pursued since it requires modifications to existing software.
or difficult to replicate. Another example is database access. In many cases the number of connections is limited especially under the same username and password, which normally happens due to keeping consistency among all peers. Also, it would be very difficult to enable different users to connect to the database using their own username and password. Our model is shown in Figure 5. It works similarly for both collaboration-aware and collaboration-transparent applications, except that for the latter bytecode modification is necessary to induce the application into working with the server. A client who first accesses the resource creates a resource server and publishes its URL on the collaboration bus. (Conventional sharing of resources, e.g., via tokens, would not work here, since we want the resource to be accessed only once per event.)
Figure 6: UNC-based file chooser view displays the configuration file on all conferees’ desktops. modification mechanism in the class loader searches for and substitutes it with our custom class . Since the File class in JDK 1.2 supports UNC file names, we implemented our own UNC-based subclass of to make the file chooser show the file hierarchy structure. Peer s read the same configure file, located at a well-known server, and thus show the same view. Here is an example of the configuration file: Á
Â
Ë
Ã
Ä
Á
Å
Â
Æ
Ã
Ç
Ä
Å
È
È
Æ
É
Ç
È
Å
Ê
È
É
Å
Ê
Ì
×
Í
Î
Ï
Ð
Ñ
Ò
Ó
Ï
Ô
Õ
Í
Ï
Ö
Ø
Ì
Í
Ý
Î
Ý
Ï
Ý
í
Ý
Ù
î
Þ
ï
Û
ß
ð
ý
Ú
à
î
ñ
Û
á
â
ó
ô
ò
Ò
Ï
Ü
ã
ä
õ
ä
ä
ä
ä
ä
ä
ä
ä
ö
ä
÷
ä
÷
ä
ä
ä
ø
ä
ù
ä
ú
å
ù
û
æ
ú
ü
û
þ
ý
þ
ü
ý
ç
è
é
ÿ
ê
ë
ÿ
þ
ý
ì
ë
ç
ý
û
æ
ì
þ
ü
ý
ü
The model presented in Figure 5 can be slightly modified by broadcasting the results from the peer with the actual accessor (push), instead of storing them at server and awaiting the other peers to read (pull). In the first case, the receiving peers buffer the push data locally until the application reads them. We note in passing that in our solution all inputs from resources are shared, whereas the outputs to the resources are never shared. So, if a conferee opens a file, it will be opened by all other conferees, but if the users initiates file saving, the file will be saved for that user only.
û
Figure 5: Generic interactions in the resource server model for resource access.
"
#
$
û
ú
ý
!
!
&
'
(
(
!
)
A more general solution for file resources is based on the file URLs. Each client creates a file resource server and publishes its URL on the collaboration bus (Figure 7). Each bus subscriber updates its resource list. An URLbased subclass of has to be implemented to show the file hierarchy structure. Here is an example: $
0
1
2
2
File Resource Server
In case of files we can employ a simple solution based on the Universal Naming Convention (UNC) on platforms that support Client for Microsoft Networks, which is supported under WFW3.11/Win9x/WinNT and SAMBA on UNIX [5]. The dynamic bytecode
%
9
In this case users share multiple resources (files), each of which may be at a different machine. View consistency of file choosers is required for meaningful collaboration—a problem that does not arise for other types of resources. For security reasons the users are requested to explicitly declare the files available for sharing. Each user is prompted for this in a private dialog.
A that covers the file chooser intercepts the user events and broadcasts to the peer file choosers (Figure 6). As a user clicks the “Open” button, the s return the same selected file name in the UNC format. If the file can be shared read, the peer applications will simply read it. If it cannot be shared, a solution is to download remote files to a local temporary folder. If the file needs to be updated, we need to have a mechanism to make sure only one user (at a time) can perform updating.
%
%
Here we give two examples of resource server implementation: file resource server and database resource server.
3
1
4
:
;
5
3
6
1
!
*
+
,
!
-
.
!
/
4
?
7
@
A
B
C
C
D
E
F
F
G
H
G
A
@
@
G
A
I
J
A
G
H
H
E
J
K
K
K
F
L
M
N
F
O
P
Q
R
@
A
L
M
G
A
B
C
C
D
E
F
F
G
H
G
A
@
@
G
A
I
J
A
G
H
H
E
J
K
K
K
F
L
M
N
F
O
P
Q
R
G
A
L
M
T
U
V
V
W
X
Y
Y
Z
[
Z
T
\
\
Z
T
]
^
T
Z
[
[
X
^
_
_
_
Y
`
a
b
S
Unfortunately, the g
h
i
j
Z
Y
c
d
e
f
S
T
N
N
`
a
b
class at present does not support
Figure 7: Interactions in file access using resource servers.
URL file names. In addition, a file can have many equivalent URLs, which makes difficult to show the hierarchy structure in the file chooser. A solution is to enforce a single format for declaring the shared resources. To get around the lack of support for URL file names, we can provide a custom class. A benefit of this solution is that it makes simple support for hierarchical file structure. Another solution is that after a user makes a selection, we use the file's URL name to download the file to a local folder. The file now gets opened using the local notation. k
l
m
n
When a selection is made in the file chooser, the corresponding file name is communicated to the peers. They access the server and download the file using the server's protocol (e.g., HTTP, FTP). Then they open the file locally. Database Resource Server
Java Database Connectivity (JDBC) comprises a set of interfaces, to be implemented by database vendors in form of JDBC drivers. We exploited this feature and wrote a simple JDBC implementation which acts as a wrapper to a real JDBC driver. Our driver emulates the behavior by sending requests and receiving results from the actual JDBC driver. The application opens a database connection by invoking . As part of its initialization, the manager attempts to load the driver classes referenced in the “ ” system property. This allows a user to customize the JDBC drivers used by their applications. We place our driver in front of the driver list and make it always answer positively to the inquiry as to whether it can open a connection to a given database, i.e., . This ensures that the application will always use the custom JDBC driver, which in turn will determine the actual driver that can connect to the database. o
p
q
r
s
p
t
u
v
u
w
s
p
x
w
s
y
z
{
v
v
s
|
y
q
{
v
}
~
The solution does not involve bytecode modification since our custom driver implementation entirely complies with the JDBC interface and applications in any case determine the drivers dynamically. The only manipulation involves modifying the system property at startup time to insert the custom manager. Figure 8 shows the interactions when the application accesses the database. The request for opening a connection reaches the custom JDBC driver which asks the actual driver to open the connection. However, only one peer is given a privilege to create the real connection
Figure 8: Interactions in JDBC database access.
and that is the user who triggered the event. For this, each peer checks whether the event originated locally or remotely. We keep track of the owner of the last input event and assume that that user triggers the connecting event. The assumption is valid in most cases, especially for single-threaded applications. Other Resource Servers
Other types of resource servers are needed for interprocess communication, such as pipes, shared memory and sockets. For stream sockets, we need to substitute and with our customized versions. These in turn open real socket connections. A different solution is necessary for datagram and multicast sockets.
¡
¢
£
¤
¥
¦
Communication with other processes is also needed if the application supports the drag-and-drop mechanism or data sharing via the system clipboard. The most difficult case will be finding a solution for accessing data from I/O devices, e.g., various interfaces for data acquisition. These are usually implemented through Java Native Interface (JNI) calls to device drivers written in native code and we do not have a solution at this point. DISCUSSION OF EXPERIMENTAL RESULTS
The present framework has been tested on a number of collaboration-transparent JavaBeans applications, both available on the World Wide Web as well as developed internally. Unfortunately, there are not many beans/applets implemented using the Swing graphics toolkit. The applications include whiteboarding, collaborative viewing and annotating of geographical maps, speech-signal acquisition and processing, and medical image retrieval and analysis. The present framework successfully supports sharing of beans such as those shown in Figure 2. For example, the area-map bean features typical whiteboard functionality with file loading and saving. Another application used in testing is a medical database search application using image features [8]. The input image used in database querying is currently loaded through a file-opening dialog. Future implementation will feature direct image acquisition from a microscope. The database query is implemented as presented above. A major difficulty to be addressed involves native calls to the microscope driver. LIMITATIONS OF COLLABORATION TRANSPARENCY
Sharing applications that are not aware of collaboration may seem a controversial goal. Collaboration means sharing artifacts, knowledge, work, etc., and the question is whether these can be achieved with collaborationtransparent applications, where little more can be shared beyond the user interface. However, interface sharing suffices in many cases to support collaborative work and to enhance communication between geographically distributed coworkers, even though collaborationenabled single-user applications cannot substitute for collaboration-aware applications in general. Although seen as a temporary solution while awaiting collaboration-aware applications, collaboration
transparency continues to have significant appeal. One of their main limitations was thought to be the lack of support for group awareness and difficulty of implementing concurrency algorithms other than floor control. However, recent work, such as [3], which implements radar views and object-based concurrency control, shows that such limitations can be overcome. Unfortunately, there are more serious limitations to collaboration transparency.
Replicated states result in identical views on shared applications.
Nondeterministic Applications
Collaboration transparency remains insufficient for supporting all types of collaborative applications. As noted by Lauwers et al. [17], the need for collaborationaware applications remains. However, many of the reasons listed in [17] have disappeared with the advent of the Java programming environment. For example, run-time code replication is very simple due to the interpretative nature of Java and Java's platform independence. Also, Java serialization allows direct state transfer for latecomer support instead of replaying the session event log.
If the events that cause the state transitions at any time come from a single source and could be delivered to all collaborating applications in the proper order, the state of all collaborating applications would be consistent at any moment. However, there are certain situations where the event sources are not shared. For example, the thread schedulers, timers and random number generators usually run on a local machine and are not synchronized globally. Use of local event sources will likely result in inconsistent states of collaborating applications. For example, if the users are sharing a multithreaded application, the differences in thread scheduling may result in different states of their corresponding applications. Accordingly, new events (including those that are replicated from single sources) will find the applications in different states, and they will cause further discrepancies in the states of the collaborating applications. This is a general problem for replicated groupware architecture—it cannot support nondeterministic applications except in a few cases [17]. Fortunately, few applications are of such nature. Application Semantics
Exact state replication is the basis of sharing collaboration-transparent applications. It is based on the simple assumption that multi-user interfaces can be modeled as a collection of multiple single-user interfaces. However, not all multi-user applications satisfy this assumption and as difficult as state replication may be, in some cases it is not sufficient to enable meaningful collaboration. The following example illustrates the point. Let us assume that we have a bean to play the Black Jack card game in the single-player mode. The bean has a card dealer and displays the card stack, the amount of money bet, and the player's bank. If the bean gets imported into a shared workspace, exact state replication will not be sufficient since all players will get the same screen display and in effect only one user can play the game. The remaining users are just observers. To solve this problem, the dealer should be made aware that there is more than one player, so that it deals the cards accordingly. Additionally, the display should show the corresponding number of card stacks and the amounts bet, while each player's bank should be kept private. A general solution is impossible to achieve with collaboration-transparent beans. CONCLUSIONS
The presented framework enables group sharing of collaboration-transparent Java applications, originally developed for individual users. It succeeds in making an exact copy of the application's state as an application goes through state transitions to all peer applications.
Application sharing involves several issues including event distribution and state replication, concurrency control and conflict resolution, awareness information about the activities of others, etc. This paper focuses on event distribution for maintaining consistent state across peer applications. Other issues are the subject of our current efforts.
Nevertheless, Java introduces some problems on its own. We have seen that event interception is more complex than for the platform-specific approaches based on, e.g., Win32 or the X Window System. In the latter case, a Win32 application or an X client grabs the events for the entire screen and can easily deliver them based on the information in the event objects. Unlike this, the Java Virtual Machine (JVM) itself runs as an application and has no access to the event queues of either window manager or other applications. Even though it is not possible to achieve full support for collaborative activities using only collaborationtransparent applications, collaboration-transparency becomes ever more important with the explosive growth of the World Wide Web and increasing need for team knowledge work and interactivity on the Internet. Providing a framework that enables easy application sharing allows users with no programming background to quickly create customized collaborative applications. It also leverages the effort expended on single-user applications and avoids duplicating it. To account for the insufficiency of collaborationtransparent applications, DISCIPLE provides for concurrent sharing of both collaboration-transparent and collaboration aware applications. Both types can be mixed and matched in the same workspace. Collaboration-enabling framework source code, sample beans, and documentation are freely available at: §
¨
¨
©
ª
«
«
¬
¬
¬
®
¯
°
©
±
²
¨
³
´
±
µ
´
¶
²
«
¶
°
µ
®
°
©
·
´
«
ACKNOWLEDGMENTS
The research reported here is supported by DARPA Contract No. N66001-96-C-8510 and by the Rutgers Center for Advanced Information Processing (CAIP). REFERENCES
1. H. Abdel-Wahab, B. Kvande, and S. Nanjangud. Using Java for multimedia collaborative applications. Proc. 3rd Int’l Workshop onProtocols for Multimedia Systems (PROMS'96), pp.49-62, Madrid, Spain, October 1996.
2. S. R. Ahuja, J. R. Ensor, and S. E. Lucco. A Comparison of application sharing mechanisms in real-time desktop conferencing systems. In Proceedings of the ACM/IEEE Conference on Office Information Systems (COIS), Cambridge, MA, pp.238-248, April 1990.
14. International Telecommunication Union. Recommendation T.128—Multipoint application sharing, February 1998. http://www.itu.int/itudoc/itu-t/rec/t/t128.html
3. J. B. Begole, M.B. Rosson, and C.A. Shaffer. Supporting worker independence in collaboration transparency. Proc. 1998 ACM Symposium on User Interface Software and Technology (UIST'98), pp. 133-142, San Francisco, CA, November 1998.
15. K. A. Lantz. An experiment in integrated multimedia conferencing. In Proceedings of the ACM 1986 Conference on Computer-Supported Cooperative Work (CSCW'86), Austin, TX, pp. 267-275, December 1986.
4. J. B. Begole, C. A. Struble, and C. A. Shaffer. Transparent sharing of Java applets: a replicated approach. Proc. 1997 ACM Symposium on User Interface Software and Technology (UIST'97), pp.5564, Banff, Alberta, Canada, October 1997.
16. J. C. Lauwers and K. A. Lantz. Collaboration awareness in support of collaboration transparency: requirements for the next generation of shared window systems. In Proceedings of CHI’90, pp. 303311, April 1990.
5. J. D. Blair. Samba: Integrating UNIX and Windows. Specialized Systems Consultants, Inc., 1998. http://www.ssc.com/ssc/samba/
17. J. C. Lauwers, T. A. Joseph, K. A. Lantz, and A. L. Romanow. Replicated architectures for shared window systems: a critique. In Proceedings of the ACM/IEEE Conference on Office Information Systems (COIS), Cambridge, MA, pp. 249-260, April 1990.
6. A. Chabert, E. Grossman, L. Jackson, S. Pietrowicz, and C. Seguin. Java object-sharing in Habanero. Communications of the ACM, 41(6):69-76, June 1998. 7. G. Cohen, J. Chase, and D. Kaminsky. Automatic program transformation with JOIE. In Proceedings of the 1998 USENIX Annual Technical Symposium, 1998. http://www.usenix.org/events/no98.
Systems (COIS), Cambridge, MA, pp.227-237, April 1990.
18. I. Marsic and B. Dorohonceanu. An application framework for synchronous collaboration using Java Beans. In Proceedings of the 32nd Hawaiian International Conference on System Sciences (HICSS-32), Wailea Maui, Hawaii, January 1999.
8. D. Comaniciu, P. Meer, D. Foran, and A. Medl. Bimodal system for interactive indexing and retrieval of pathology images. In Proceedings of the 4th IEEE Workshop on Applications of Computer Vision (WACV'98), Princeton, NJ, October 1998.
19. I. Marsic. DISCIPLE: A framework for multimodal collaboration in heterogeneous environments. To appear in ACM Computing Surveys, 1999.
9. T. Crowley, P. Milazzo, E. Baker, H. Forsdick, and R. Tomlinson. MMConf: An infrastructure for building shared multimedia applications. In Proceedings of the ACM 1990 Conference on Computer-Supported Cooperative Work (CSCW'90), Los Angeles, CA, pp.329-342, October 1990.
21. T. Richardson, Q. Stafford-Fraser, K. R. Wood, and A. Hopper. Virtual network computing. IEEE Internet Computing, 2(1):33-38, January/February 1998. http://www.uk.research.att.com/vnc/.
10. A. Denning. Active X Controls Inside Out. Microsoft Press, Redmond, Washington, 2nd edition, 1997. 11. B. Dorohonceanu and I. Marsic. A desktop design for synchronous collaboration. In Proc. Graphics Interface '99 (GI’99), Kingston, Ontario, Canada, pp.27-35, June 1999. 12. D. Garfinkel, B. C. Welti, and T. W. Yip. HP SharedX: A tool for real-time collaboration. HewlettPackard Journal, 45(2):23-36, April 1994. http://www.hp.com/hpj/94apr/toc-04-9.htm 13. S. Greenberg. Sharing views and interactions with single-user applications. In Proceedings of the ACM/IEEE Conference on Office Information
20. Microsoft Corporation. NetMeeting 3.0. Redmond, WA. http://www.microsoft.com/netmeeting/.
22. S. Sarin and I. Greif. Computer-based real-time conferencing systems. IEEE Computer, 18(10):33-45, October 1985. 23. M. Stefik, D. G. Bobrow, S. Lanning, and D. Tatar. WYSIWIS revised: early experiences with multiuser interfaces. ACM Transactions on Information Systems, 5(2):147-167, April 1987. 24. Sun Microsystems, Inc. JavaBeans 1.0 API specification. Mountain View, CA, December 1996. http://www.javasoft.com/beans/. 25. W. Wang, B. Dorohonceanu, and I. Marsic. Design of the DISCIPLE synchronous collaboration framework. In Proceedings of the 3rd IASTED International Conference on Internet and Multimedia Systems and Applications, Nassau, Grand Bahamas, October 1999.
