A Collaboration-Enabling Framework for Java Beans - Semantic Scholar

Download PDF
1 downloads 139524 Views 690KB Size Report
Comment
The objective of this work is to develop a collaboration- enabling framework to simplify the development of multi- user collaborative applications, in particular ...
A Collaboration-Enabling Framework for Java Beans Ivan Marsic Department of Electrical and Computer Engineering and the CAIP Center Rutgers University Piscataway, NJ 08854-8088 USA +1 732 445 6399 [email protected]

ABSTRACT

This paper presents a JavaBeans framework to support realtime collaborative applications. The paper contributes a generic collaboration bus to which any (including singleuser) applications can be plugged in as is and made collaborative with no modifications to the application or to the collaboration bus. It also provides the design guidelines for developing collaboration-aware applications to take advantage of the cooperative features of the bus. Unlike most of the existing collaboration toolkits and frameworks, the application does not explicitly establish relationship to any of the framework classes, and is thus independent of the framework. The framework supports multi-user visual programming using JavaBeans: the users at geographically separate locations can collaboratively compose a complex JavaBeans application using simple Beans. The framework has been implemented and tested on a variety of applications. Keywords

Synchronous groupware, CSCW frameworks, shared electronic workspaces, group communication, JavaBeans, object request broker. INTRODUCTION

The objective of this work is to develop a collaborationenabling framework to simplify the development of multiuser collaborative applications, in particular real-time synchronous groupware. Development of single-user applications is hard, and development of multi-user applications introduces many more degrees of complexity. Our goal is to dissociate to the maximum the communication and group aspects from the application's task. Another important motivation is that the majority of applications continue to be developed for a single user. However, with the advent of the Internet, there is an

increasing need to provide the same functionality for groups of users. The developers of multi-user applications usually duplicate the work done on single-user applications, which often results in a failure to keep up with the latest features available on their single-user counterparts. An important goal of the presented framework is to enable rapid porting of single-user applications to the multi-user domain. We target a particular class of applications—applications known as JavaBeans. There is currently a strong trend in software industry towards standardizing software development to reusable software components. Two major component architectures are JavaBeans from Javasoft [20] and ActiveX controls from Microsoft [6]. Components enable rapid application development using third party software: independent components are used without modifications as building blocks to form composite applications. Our approach offers a single solution to what is currently viewed as two disparate problems in developing multi-user applications: the development of special purpose applications that are collaboration aware and the adaptation of existing single-user applications to provide collaboration-transparent shared applications. The additional feature of our system, not present in other collaborative frameworks, is that it allows both run-time and design time collaboration. As a result of the latter, it supports collaborative visual programming using JavaBeans. The users at different locations can collaboratively compose a complex JavaBeans application using simple Beans. The central part of the framework is the collaboration bus (Figure 1). The applications get “plugged” into the bus, freeing the application developer from concerns with the technical details of group work and with the communication infrastructure. The requirements that we have set for a collaborationenabling framework are as follows: R1 simplification of the development of multi-user applications by delegating the group and communication aspects to the collaboration-enabling framework

R2 ability to work with collaboration-transparent applications without modifications to the application code R3 intact preservation of the underlying Java platform (graphics user interface toolkit Java AWT and other system packages) R4 no requirement for explicit relationships to the framework classes for collaboration-aware applications, thus allowing the applications to work independently of the framework R5 flexibility to employ complex cooperative algorithms, such as multiple concurrency control algorithms, varying degrees of coupling and sharing, group awareness features, etc. An additional desirable feature is support for design-time collaboration, where users can at run time customize the application or compose more complex applications from simpler ones1. All of the above should be accomplished with a minimum impact on performance, since the framework is intended for real-time groupware.

transparent applications or require porting process. Once an application is developed using a given framework, the application classes have some relationship, e.g., inheritance, to the framework classes, thus effectively locking the application to the framework. Unlike this, in our framework single-user applications can be used as is, without a porting process, and collaboration-aware applications can be used independently of the framework. Most other approaches to building collaborative applications are intrusive, and this can be categorized in two types: •

replace the underlying graphics toolkit (Java AWT), see for example [1,2]

•

modify the application classes to become related (e.g., inheritance) to the collaboration framework classes, see for example [18,16,3]

The framework presented here is the only (to our knowledge) non-intrusive and self-contained framework in the sense that neither the underlying graphics toolkit nor the application is modified. Java Collaborative Environment [1] provides a collaborative abstract windowing toolkit (Collawt) that Java applications should use in place of the java.awt package. Each java.awt component is replaced with a double that intercepts the user events and multicasts them to the collaborating peers. The Java applications can be developed as single-user applications without any knowledge of collaboration. The main disadvantage with this architecture is that the applications have to be built using the Collawt windowing toolkit. This rules out the existing single-user applications that have been built using ordinary java.awt.

Figure 1 The architecture of the collaboration framework. The collaboration bus provides various group- and communication-related services. This paper presents the design for a collaboration-enabling framework that satisfies all of the above requirements. The framework has been implemented and tested on a variety of JavaBeans applications. Related Work

The problem of shared applications development is well recognized and there is a large body of related work [18,10,16,19,3]. All existing approaches violate at least one of the requirements listed above. For example, most of the existing approaches do not support collaboration1

Design-time collaboration is the act of collaboratively assembling a composite JavaBeans application from simple single-user JavaBeans components. Once the application is composed, all the state changes in the application will be shared. This stage is the run-time collaboration of applications.

A similar but less restrictive approach is presented in [2]. Here, java.awt is replaced by a new GUI toolkit which also intercepts the events and multicasts them to the peer applications. Although the single-user applications can be used as is, the approach works only if the underlying GUI toolkit is replaced. An additional problem with this approach is that the substitute toolkit needs to be re-built every time a new version of the original toolkit is released. GroupKit [18], DistView [17], and more recent similar toolkits [16,19,3] provide as set of classes and interfaces that the developer needs to use to develop a shared application. The Habanero framework [16] provides two strategies to develop collaborative applications using Java: (i) design guidelines for developing applications with awareness about the Habanero collaboration architecture, and (ii) guidelines for porting single-user applications that have been developed without knowledge about collaboration into collaborative applications that will work within the Habanero framework. Porting includes implementing additional interfaces and modifying method signatures, and

is not a trivial task, especially for non-Java programmers. Once the modifications are done, the application is no longer an independent entity since it is type-cast for the particular collaborative framework which required the modifications. The Java Shared Data Toolkit (JSDT) [3] defines a multipoint data delivery service for collaboration-aware Java applications. JSDT provides a set of API's for the application programmers to design run-time collaborative applications. The resulting applications are tightly coupled with the toolkit and cannot be run without it. Microsoft NetMeeting [15] provides for sharing of collaboration-transparent COM-based (Component Object Model [6]) applications. However, it has limited capabilities for state replication as well as limited cooperative features (concurrency, coupling, awareness, etc.). It also supports the development of collaborationaware applications, but the application's classes need to inherit or use certain object from the development kit. Java Beans

The presented framework is based on the JavaBeans component model, which is a part of the Java Development Kit 1.1. The delegation-based event model was introduced with the JavaBeans framework. In this model, there is no central dispatcher of events; every component that generates events dispatches its own events as they happen. An event is something of importance that happens at a specific point in time. An event can take place due to a user action such as a mouse click—when the user clicks a mouse button, an event takes place. Events can also be initiated by other means, e.g., input from a monitoring instrument. EventSource Any object can declare itself as a source of certain types of events. An event source has to either follow standard design patterns when giving names to the methods or use the BeanInfo class to declare itself as a source of certain events [20]. The source should provide methods to register and remove listeners of the declared events. EventListener An object can register itself as a listener of a certain type of events originating from an event source. A listener object should implement the generic java.util.EventListener interface. According to the delegation model, whenever an event for which an object declared itself as a source gets generated, the event is multicast to all the registered event listeners. The source object propagates the events to the listeners by invoking a method on the listeners and passing the corresponding event object. Delegation event model is in the essence of the JavaBeans specification and it is precisely the feature that makes the framework possible. COLLABORATION BUS

The collaboration-enabling framework is based on a replicated architecture for groupware (see e.g., [12,17,18]).

Each user runs a copy of collaboration client, and each client contains a copy of the applet that is to be collaborated on. For each object within a user's applet, there will be a counterpart in all the other users' applets. Collaboration in this type of architecture essentially translates into intercepting the state changes occurring in a user's applet and replicating the state changes in all the peer users' applets. The purpose of the collaboration bus (C.bus) is to replicate in an object-oriented way the state changes in real-time multi-user applications. We assume that there will be two types of messages exchanged between the collaborating applications: 1.

application state changes need to be replicated by multicast communication

2.

signaling messages to handle special situations need to be sent by unicast (point-to-point) communication

A general object request broker cannot be used due to the specific requirements on real-time collaborative applications. The overall architecture of the collaboration bus resembles the classic Broker pattern [4], but differs in many details. The collaboration bus is built using a general object communication toolkit (ACT) [8], and can be run on top of CORBA or in parallel with CORBA. ACT also supports multiple protocols simultaneously. Here we describe the components of the collaboration bus and their interactions on its main task: event replication. Event Replication

Event adapters convert events of arbitrary types generated by the application into unified events that can be processed by the collaboration bus (). Adapters are needed since the bus cannot have methods for arbitrary events that an application programmer may come up with. Event adapters are equivalent to object proxies (stubs, skeletons); however, there are differences, and a major one is that they need to be registered as listeners of events generated by an application so that the bus gets notified about the state changes. Event replication works in the same way for collaboration transparent and for collaboration aware applications. The event object is converted to a byte-stream using Java serialization [20]. Event adapters for collaborationtransparent applications are predefined since the events are known in advance (Java AWT events). For aware applications, the developer needs to generate the adapters using the Interface Definition Language-like compiler supplied with the C.bus.

At the time an application gets connected to the C.bus, the Communicator does the following actions:

Figure 2 The architecture of the collaboration bus follows the Broker pattern [4]. Communicator is the layer in the C.bus whose main purpose is to provide demultiplexing of requests (multithreading), as well as cooperative features, such as concurrency, coupling, etc. Communicator multicasts the application's state changes to the remote peers. It also receives state change notifications from the remote peers and replicates them to the local application.

1.

discovers the application

inner

Beans

of

the

2.

for each Bean, determines the events it can generate

3.

for each event, creates an EventAdapter and assign an object reference to it

4.

registers the EventAdapter as a listener to the Bean

This model differs significantly from the CORBA model [22], where the object references are transmitted from a server object to a client object, and the proxies are per object rather than per method or a subset of methods (Figure 3). Unlike CORBA, the EventAdapters represent proxies for object events, and the same Bean may generate several events. The reasons that the proxies are not done in the CORBA way are (i) it would result in a larger number of proxy classes, and (ii) it would not be compliant with Java EventAdapter model.

Protocol is a simple multicast protocol that, however, needs to be reliable, rather than a plain datagram-based multicast. All remote calls are one way and no reply is expected. At present, the Communicator uses pseudomulticast, but this is being replaced with Lightweight Reliable Multicast Protocol [14]. As already stated, all calls are by value, which means that method arguments are serialized, rather than by passing object references. CORBA IIOP [22] could have been used as a communication protocol, but we saw no need for it. IIOP would introduce significant overhead, cannot be implemented with true multicast, and is not needed in a closed system such as the one where all collaborating applications use the C.bus for communication. Thus, IIOP is not used for communication within-the-C.bus. Where the need arises to talk to the outside world, the design is flexible to provide for coexistence of multiple protocols, including IIOP. Object References

An object reference uniquely identifies an object in a distributed environment. In CORBA, for example, the object references are composed from the host IP address, network port number, and the unique local identifier. Since in a collaborative environment we assume the exact copies of the applications across the collaborating workspaces, the object references can be just indices of the application's inner Beans. An object reference is associated with an EventAdapter, and when an event is multicast, the reference is attached. At the other end, the reference is used to index the counterpart EventAdapter and to deliver the event to it.

Figure 3 A comparison of the CORBA ORB proxies (a), where only one proxy per object is defined, and the collaboration bus proxies (b), where multiple proxies are defined for object events. (The notation uses the Unified Modeling Language—UML.) Since the C.bus proxies do not inherit from anything equivalent to CORBA::Object interface, they need to be manually linked to the JavaBeans which are sources of the events that need to be replicated. This is done either by the application developer or by a collaboration-enabling framework, as explained below.

Collaboration Components

An object request broker normally deals with demultiplexing of the requests and switching the messages to the appropriate recipients at the layer corresponding to the Communicator (Object Adapter [22]). In addition to these, the Communicator handles the cooperative aspects of group work, such as concurrency control, coupling, etc. It relies on various collaboration components that are part of the Communicator layer. The components are built as Java Beans and support the typical elements found in real-time, synchronous groupware applications that include session management, concurrency control, coupling, group awareness, etc. [11]. The components provide fine granularity in controlling the cooperative aspects of the application, to the extent that each application Bean can have its own associated collaboration component(s).

channel. It only knows about the component's intent to deal with a channel, but we don't know when will these actually happen. Once the channels are open, reading or writing data takes place independently of the SecurityManager. The problem is subject of our current investigation. Collaboration Bus and Object Request Brokers

C.bus resembles an ordinary object request broker, such as CORBA [22], Java RMI [23], or DCOM [9]; however, it also differs in that it is customized for real-time The following features collaborative applications4. distinguish the C.bus: 1.

simultaneous support for multiple communication modes (multicast for state change replication and unicast for signaling)

2.

definition of object references (see below)

3.

semantics and instantiation of object proxies (see below)

4.

event echoing prevention

5.

concurrency control for simultaneous state changes

Sources of State Changes

All application state changes are caused either by user inputs or by channels (network ports, data acquisition devices, files, etc.) open at the initialization stage or in response to the user's commands. The current collaboration bus architecture provides for replication of all application events that the bus can find about2. In collaboration-aware applications this means all events that are of interest. However, in collaboration-transparent applications, it means only the AWT events generated by the user's interaction with an application. The problem is that not all users will have access to all resources, e.g., not all users will have a local copy of a file. Another problem is that even if the resource were replicated, e.g., all users had monitoring instruments, these instruments would generate different data. Thus, in the case of collaboration-transparent applications, all state changes coming from or related to non-globally available resources need to be monitored and replicated. This assumes (i) detection of the state changes from those sources, and (ii) replication of the events or the resources that are aren't globally available. In solving the problem (i), we have noticed that all of these state changes would be in violation of Java security. The Java security manager can detect when an application tries to read a file or open a network port and notify the C.bus about these3. However, since the SessionManager is invoked only from the resource's class constructor, it can only identify the application component that opens the 2

In addition to the events, application threads, timers and random number generators need to be synchronized and this is currently not accounted for.

3

Applets are not allowed to override the SecurityManager in a browser, but neither can they have access to those types of input channels, which obviates the need for their detection.

conflict

resolution

of

The semantics and instantiation of the component proxies in C.bus are the result of the need to avoid modifications to collaboration transparent applications. Unlike traditional object request brokers, C.bus automatically creates colocated stubs and skeletons. In CORBA, stubs are created (automatically) based on the receipt of a remote object reference within the reply to a remote call. Unlike this, event adapters are created based on the information on what events the local application can generate, as explained above. For all events of each of the application's components, the corresponding event adapter is instantiated. It is assumed (but not verified) that the remote peer applications have the counterpart components that will accept the multicast events.

4

C.bus has no similarity to InfoBus [5]. InfoBus-connected applets must all reside in the same Java Virtual Machine, although InfoBus can participate in distributed applications. In such a case, the application must use some other communication system, such as CORBA,RMI, etc. There are many dissimilarities, but the basic one is that InfoBus is not an Object Request Broker, neither it has any special features to support synchronous collaboration.

Similarly, skeletons in CORBA are instantiated at the time when the server object is instantiated. The ORB is invoked automatically since the server object inherits from the CORBA::Object interface, and the object reference is created at the same time. In C.bus we assume that the remote applications will invoke only event listener interface methods. The object references are created as explained above in Figure 3. COLLABORATION-ENABLING FRAMEWORK

Collaboration bus cannot be used like a CORBA ORB due to the reasons discussed above. It needs to be interfaced to an application and we are currently pursuing two approaches: 1.

hard-wired stand-alone applications

2.

collaboration-enabling framework that does dynamic “wiring”

In the first case, the application developer links the C.bus to the application much like the CORBA ORB is linked to the applications. In the second case, collaboration-enabling framework (CEFRAM) acts as a mediator between the C.bus and the applications and does the following: 1.

determines the constituent components (atomic Beans) of the application and the events each component generates

2.

creates corresponding EventAdapters and register them as listeners to the components

3.

registers Communicator EventAdapter events

as

a

listener

to

the

Here we present CEFRAM as one of the possible approaches to interfacing the C.bus to the application.

Collaboration-Enabling Framework Components

The main components of the collaboration-enabling framework are shown in Figure 4. Workspace is the central part of the CollaborationEnabling Framework. Each user in a collaborative session has a Workspace, which forms a non-shared, private workspace where the user imports applications to be made shared. It can contain JavaBeans-compliant applets and applications; Workspace itself is implemented as a Bean, so it allows nesting of Workspaces. Workspace is used in both design-time and run-time collaboration of applications. A Bean applet can be displayed in a Workspace window or it can launch its own independent window. Collaboration Bus multicasts the state changes taking place in an application contained within the Workspace to the remote Workspaces. The bus also receives state change notifications from remote Workspaces and replicates the state changes in the local application. C.bus is an invisible Bean (does not have a GUI) and is a default component of a Workspace. Each Workspace has its own C.bus (see Figure 4), which is analog of the way CORBA or Java RMI object request brokers operate: each application has its own ORB. We could have had only one C.bus per application Bean, but this would introduce additional complexity to the C.bus. On the other hand, bus-per-workspace implies that every time an application Bean needs to join a different session, a new Workspace needs to be created. JavaBean Application The application refers to a third party single-user applet that is to be made collaborative. In order to be made collaborative, the applet should be developed as a JavaBean in accordance with JavaBeans

Figure 4 Components of the collaboration-enabling framework. Desktop contains multiple Workspaces, which further contain multiple application Beans. Workspace establishes the links between the application and the collaboration bus. One session manager, located on a remote server, supports several client nodes.

specifications [20]. An applet can be a composite Bean, made of other composite and/or atomic Beans. The application itself is a component contained in Workspace. SessionManager keeps track of all the Workspaces involved in a session. It keeps a record of all user actions and generates a session history. The SessionManager may also participate in concurrency control policies of the collaborative system, e.g., granting the token in a lockingbased concurrency control scheme. Each public Workspace is required to register with this object. Collaboration-Aware Applications

A collaboration-aware application is an application that was developed with the intention of being used with the collaboration-enabling framework presented here. Such an application is provided with fine-grained, less restrictive mechanisms to mediate the collaborative session. The benefits of developing this kind of applications include: •

Grouping of several related low-level events into a single high-level event. For example, in a given context the sequence of events (mouse pressed, mouse dragged, mouse released) may result in rotating a graphic figure in the workspace. The sequence, then, may be compressed to a single event (rotate figure) before being multicast to the other users. This feature is useful when collaborating over the low-bandwidth networks5.

•

Access to advanced concurrency algorithms. For example, it is very difficult to implement group undo features for collaboration-transparent applications. This is very easy in case of aware applications, since the developer supplies the undo method for every input.

•

Coupling in a more meaningful manner. In case of transparent applications, coupling is possible only for the AWT components, whereas for the aware applications, it is possible for any component Bean.

•

Replication of all types of state changes. Replication of certain types of state changes may be very difficult in transparent applications, as discussed earlier.

The specifications for the development of collaborationaware applications along with examples are available on the Web site listed at the end of the paper. Here is a brief summary of the steps that the developer needs to follow: 1.

define the inner Beans of the application

2.

define the high-level semantic events that each Bean can generate and receive; each event should extend java.util.EventObject

5

Notice, however, that this feature compromises the user’s group awareness, since the observing users don’t see the intermediate results of the user’s activity.

3.

provide listener methods for all events that the application receives so that the events can be delivered

4.

provide registration methods for all events that the application generates so that interested parties can register as listeners

5.

provide the method dispatchEvent() for each Bean (Figure 3b); Java AWT components come with this method, and for collaboration-aware Beans, the developer needs to provide the method.

Bean Loading and Replication

Initially, when the user runs Workspace, the Communicator first registers an EventAdapter as a ContainerListener with Workspace (see Figure 5). As a result, the Communicator gets notified at any point during the session when a component gets loaded into the Workspace. The Communicator then notifies the remote Communicators to load the same component in their Workspaces. A remote Workspace first tries to load the component locally; if the component is not available locally, it will be downloaded from a remote location using a URL received in the loading notification message. In the case of collaboration-aware applications, instead of detecting the AWT components of the application as in the case of transparent applications, CEFRAM reads the BeanInfo contained in the application to determine the application Beans and their events. In this case, CEFRAM registers only the listeners for the events listed in the BeanInfo object. If the developer wishes to expose some of the application's AWT events, they need to be explicitly listed in the BeanInfo object. SESSION MANAGEMENT

Users join to collaborative sessions using the interface shown in Figure 6. The session manager keeps track of the ongoing sessions and the user selects the session to join from a list of active sessions. Traditional groupware applications do not encounter the problem of interoperability between the collaborating applications, since all collaborating users are forced to use the same application. However, in the framework presented here, session management is complicated due to the following framework capabilities:

Figure 5 Sequence diagram for Bean loading. The example shows two collaborative users, where the user on the left loads the Bean and the user on the right gets a replicated Bean. 1.

the user can assemble an arbitrary JavaBean application, and try to join to an existing session where the other users use a slightly different application

2.

the users may have two applications, participating in different sessions and, in a design-time collaboration, establish a link between these applications

The problem in the first case is of interoperability: the new application may attribute different meaning to the event messages coming from the peers. Also, the application may have additional components/events, not having counterparts in the peer applications. Thus, it is possible that some of the events generated by this application cannot be properly replicated.

contained applets belongs to a single session. This solution is similar to the one used in [13], where the applets are downloaded from the session manager to all but the first user. A more flexible solution would be that the user loads a local application Bean in a Workspace, selects the Workspace, and invokes the Join menu entry (see Figure 4). This would allow the users to use their own (possibly slightly different) applications to collaborate. However, the problem of interoperability needs to be solved. We are currently investigating the use of Java reflection and introspection features [20] to verify the interoperability. The design-time collaboration is allowed only upon the applets contained in the same Workspace—the users cannot interconnect the applets contained in different Workspaces. As a result, the composed applets belong to the session that their parent Workspace does. Also, the nested Workspaces are not allowed to be in the set of applets that are used to compose more complex applications6. DESIGN-TIME COLLABORATION

Figure 6 User interface for joining to a session. In the second case, it is not clear to which session the new application belongs. Does it belong to one or both of the old sessions or perhaps a new session should be created? In the current implementation of the framework, only the first user to create a session can drop an application Bean in the Workspace. All other users get the Bean downloaded from the SessionManager. Each Workspace with its

The collaboration-enabling framework is a simplified Java Integrated Development Environment (IDE), augmented with a collaboration bus and the mediators between the bus and an application. The framework is not intended to be a full-featured IDE. The design-time collaboration feature is intended for user-extensibility and incremental programmability of collaborative applications, rather than as a development tool. It is provided for advanced users to be able to rapidly add extra features to an existing 6

The Session menu of the nested Workspaces is automatically disabled to prevent them joining to different sessions. A Workspace can join to a session only if the parent Workspace has not joined to any session.

application or to prototype an application using simpler components. Although we do not expect that users will frequently use this feature, we believe that it can be very valuable at occasions. System administrators or other superusers who do not see themselves as programmers would use this feature and save the results for future use by ordinary users.

application. Another unsolved issue is to what class an application belongs when it is composed of two simpler applications, one collaboration-transparent and one collaboration-aware. This is more than a philosophical issue, since at the time of bean loading the framework registers different event adapters based on the application type.

Design-time collaboration can be compared to the macro language for spreadsheets, where the advanced users are able to create powerful macros to carry out complex and useful work, without the need to require upgrades and modifications to the application from the original developer.

The work presented here is part of the larger effort on the DISCIPLE system (DIstributed System for Collaborative Information Processing and LEarning). We are developing knowledge-based planning and learning strategies for discerning the communication needs of participants and computational task demands, which will further improve the performance of the collaboration-enabling framework.

CONCLUSIONS

This work presents a novel framework for replicating state changes across the shared workspaces. The framework enables separation of the semantics of applications from the semantics of collaboration and of distributed computing. It provides a mechanism to control the cooperative features of the system in an application-independent manner. The main strength of the framework is that it does not require modifications to the underlying graphics toolkit or application. We offer a unified treatment for both collaborationtransparent and collaboration-aware applications. The only difference is in the degree of exposed internal structure of the application. As a result, the collaboration-aware applications can be used independent of the bus, in a singleuser mode or in some other framework. The framework has been implemented [21] and tested on a number of Beans, both collaboration-transparent (available on the World Wide Web) as well as collaboration-aware developed internally. The applications include whiteboarding, collaborative mapping, speech signal acquisition and processing, and image analysis. The concept succeeds in replicating most of the state changes while satisfying all of the requirements stated in the introduction. Due to its simple design, the collaboration bus introduces a minimum overhead compared to the Java sockets, so the performance is very good. We haven't yet systematically measured the latency or done any comparative studies to examine its performance against other real-time collaborative environments. However, the experiments between two sites over a wide-area Internet connection as well as over modem lines demonstrate that the system has a near real-time response. The framework is still evolving and there are unsolved problems. For example, if an application (by mistake) exposes chained events, where an event causes the next event in the chain, the C.bus will not be able to detect this, and will cause duplicate events in remote applications. An example is when in design-time collaboration a collaboration-aware application is chained after any other

Collaboration-enabling framework source code, documentation, and examples are freely available at the following URL: http://www.caip.rutgers.edu/multimedia/groupware/ ACKNOWLEDGMENTS

Senthilkumar Sundaram implemented an early version of the collaboration-enabling framework. The author had many inspiring discussions with Stephen Juth, Cristian Francu and Bogdan Dorohonceanu. Steve, Cris and Bogdan are currently developing a new version of the collaboration bus as well as collaboration components. The research reported here is supported by the DARPA Contract No. N66001-96-C-8510 and by the Rutgers Center for Computer Aids for Industrial Productivity (CAIP). CAIP is supported by the Center's Corporate Members and by the New Jersey Commission on Science and Technology. REFERENCES

1. H. Abdel-Wahab, B. Kvande, and S. Nanjangud. Using Java for Multimedia Collaborative Applications. Proc. 3rd Int’l Workshop on Protocols for Multimedia Systems (PROMS'96), pp.49-62, Madrid, Spain, October 1996. 2.

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.

3. R. Burridge. Java Shared Data Toolkit (JSDT). Sun Microsystems, Inc., Mountain View, CA, February 1998. Available at http://www.javasoft.com/people/richb/jsdt/. 4. F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal. Pattern-Oriented Software Architecture: A System of Patterns. John Wiley & Sons, Inc., New York, 1996. 5. M. Colan. InfoBus 1.1 Specification. Lotus, Inc., Cambridge, MA, March 1998. Available at http://www.javasoft.com/beans/infobus.

6. A. Denning. Active X Controls Inside Out. Microsoft Press, Redmond, Washington, 2nd edition, 1997. 7. P. Dewan and R. Choudhary. Coupling the User Interfaces of a Multiuser Program. ACM Transactions on Computer-Human Interaction, 2(1):1-39, March 1994. 8. C. Francu, W. Wang, and I. Marsic. Design of an Advanced Communication Toolkit for Implementing the Broker Pattern. Submitted for publication. Available at http://www.caip.rutgers.edu/multimedia/groupware/. 9. R. Grimes. Professional DCOM Programming. Wrox Press Ltd., Chicago, IL, 1997. 10. R. D. Hill, T. Brinck, S. L. Rohall, J. F. Patterson, and W. Wilner. The Rendezvous Architecture and Language for Constructing Multiuser Applications ACM Transactions on Computer-Human Interaction, 1(2):81125, June 1994.

15. Microsoft Corporation. NetMeeting 2.1 Resource Kit. Redmond, WA, July 1996, Available at http://www.microsoft.com/netmeeting/. 16. NCSA Habanero Group. NCSA Habanero. Champaign, IL, September 1996. Available at http:// www.ncsa.uiuc.edu/SDG/Homepage/habanero.html. 17. A. Prakash and H. S. Shim. DistView: Support for Building Efficient Collaborative Applications Using Replicated Objects. Proc. ACM 1994 Conf. on Computer Supported Cooperative Work (CSCW'94), pp.153-164, Chapel Hill, NC, October 1994. 18. M. Roseman and S. Greenberg. GroupKit: A Groupware Toolkit for Building Real-Time Conferencing Applications. Proc. ACM 1992 Conf. on Computer Supported Cooperative Work (CSCW'92), pp.43-50, Toronto, Canada, November 1992.

11. S. Juth and I. Marsic. Collaboration Components to Support Rapid Application Development of Multi-User Applications. Submitted for publication. Available at http://www.caip.rutgers.edu/multimedia/groupware/.

19. C. Schuckmann, L. Kirchner, J. SchÕmmer, and J. M. Haake. Designing Object-Oriented Synchronous Groupware with COAST. Proc. ACM 1996 Conference on Computer Supported Cooperative Work (CSCW'96), pp.30-38, Cambridge, MA, November 1996.

12. A. Karsenty and M. Beaudouin-Lafon. An Algorithm for Distributed Groupware Applications. Proc. 13th International Conf. on Distributed Computing Systems, pp.195-202, Pittsburgh, PA , May 1993.

20. Sun Microsystems, Inc. JavaBeans 1.0 API Specification. Mountain View, CA, December 1996. Available at http://www.javasoft.com/beans/.

13. J. H. Lee, A. Prakash, T. Jaeger, and G. Wu. Supporting Multi-User, Multi-Applet Workspaces in CBE. Proc. ACM 1996 Conf. on Computer Supported Cooperative Work (CSCW'96), pp.344-353, Cambridge, MA, November 1996. 14. T. Liao. Light-Weight Reliable Multicast Protocol. INRIA Rocquencourt, Le Chesnay Cedex, France, June 1996. Available at http://webcanal.inria.fr/lrmp/.

21. S. Sundaram. A Collaboration-Enabling Framework for Java Beans. Master's thesis, Rutgers University, New Brunswick, NJ, January 1998. 22. The Object Management Group. The Common Object Request Broker: Architecture and Specification, Technical Report 97-09-01, Object Management Group, Inc., Framingham, MA, September 1997. Available at http://www.omg.org/corba/c2indx.htm. 23. A. Wollrath, R. Riggs, and J. Waldo. A Distributed Object Model for the Java System. USENIX Computing Systems, 9(4), Fall 1996.