An Architecture for Heterogeneous Groupware Applications Ivan Marsic Rutgers University Department of Electrical and Computer Engineering Piscataway, NJ 08854-8058 USA +1 732 445 6399
[email protected] ABSTRACT The proliferation of wireless networks and small portable computing devices raises the need for applications that are adaptable to heterogeneous computing and communication environments and the contexts in which they are used. However, most current groupware systems as well as other software applications are not well prepared to handle the heterogeneity. The Manifold framework presented here provides a software architecture for synchronous groupware applications to deal with heterogeneity. The framework’s main characteristics are multi-tier architecture and single data structure (tree). These respectively allow for flexible composition of modules and simpler implementation of group-related functions. The design is tightly integrated with eXtensible Markup Language (XML) to allow dynamic adaptation to heterogeneity. The resulting design is simple yet very powerful and scalable. Manifold is implemented and tested by developing several complex groupware applications.
Keywords Software frameworks, group editors, groupware, design patterns.
1. INTRODUCTION Most current collaboration systems make no distinction or take no advantage of the separation between the underlying model and the way it is visualized on the screen. In addition, these systems strive to synchronize the way the application looks across the different instances, the so-called WYSIWIS (What You See Is What I See) paradigm [6]. A key reason for uniformity is the difficulty and associated cost of developing collaborative applications with different look-and-feel. However, with the recent anytime-anywhere proliferation of computing technology, the need for diversity can no longer be ignored. Group collaboration has the potential to become a very important mobile application. A simple mobile collaboration example would be two-way real-time text chatting to replace current two-way pagers, but more complex workspace sharing is just a step ahead. The physical heterogeneity coming from access devices and communication media manifests itself in CPU speed, memory, display capabilities, and network bandwidth, with the last two
having the most prominent discrepancies. In addition to hardware disparities, mobility also exposes limitations in human information processing. A stationary person focused on a monitor in an office allocates vastly different cognitive resources to the computer display than a roaming person who has to pay attention to other things in the environment. Thus, heterogeneous displays will likely remain with us even if technology shortcomings are surmounted due to the necessity to account for human information-processing limitations. The inevitable heterogeneity of computing environments imposes interesting problems from the perspective of single (even if networked) users but even more so from the perspective of team telecollaboration. This paper presents a software architecture called Manifold for developing general groupware applications. Dewan [6] argues that any collaborative application can be seen as a generalized editor of semantic objects defined by it. A user interacts with the application by editing a rendering of these objects using text/graphics/multimedia editing commands. In addition to passive editing, in a generalized editor the changes may trigger computations or behaviors in the objects. In that sense, the framework presented here can be used in developing any groupware application that deals with structured documents, such as collaborative editor or collaborative virtual world. An important feature of the Manifold architecture is full integration of XML (eXtensible Markup Language). XML is now being promoted as a new Web markup language for information representation and exchange [1],[2]. Information represented in a generic form can be mapped to a particular form for transmission and visualization. However, there is a major need for a software architecture that will help in realizing XML’s full potential. Manifold employs XML to adaptively select and compose the application’s components to best suit the current computing and communication environment. The paper is organized as follows. Section 2 reviews the related work. Section 3 gives a brief overview of the DISCIPLE collaboration system that forms the basis for the Manifold framework. Next, Section 4 presents the multi-tier architecture and design for Manifold-type Java Beans. Section 5 integrates XML into the framework at the level of information exchange and then employs XML for application adaptation to heterogeneity. Section 6 gives example applications for experimental evaluation of Manifold, and Section 7 concludes the paper.
2. RELATED WORK Most of the concepts presented here are well known and proven in practice. The novelty of our work is in a unique combination of these concepts and its application to heterogeneous groupware. The multi-tier architecture is a common architecture for information systems that include user interfaces and persistent storage of data (see, e.g., [15]). Our
design draws on the designs of Unidraw [24] and Fresco [5],[23] (single-user) systems and extensively employs software design patterns [7],[3]. The Model-View-Controller (MVC) pattern was first introduced in the Smalltalk programming language [14]. The pattern is very popular and frequently used in single user applications [3]. However, there is little work on the distributed MVC pattern. An early design for heterogeneous groupware is presented in [12], but it does not employ the MVC pattern. Several groupware systems implement the distributed MVC pattern, e.g., [20], but only a simple version where the model is centralized and the views are shared. Some researchers mention a possibility of implementing the distributed MVC but do not report attempts of implementation [8],[21]. A recent approach to collaboration in heterogeneous computing environments is CMU’s Pebbles project [18]. Pebbles is focused on single-display groupware, with the team being in a single meeting room. Multiple hand-held computers (Personal Digital Assistants) provide simultaneous input (mouse, keyboard) to a single workstation. PDAs are not treated as equal partners in collaboration and thus there is no need for heterogeneous data representation. A quite different approach to heterogeneity and diversity is presented in [19]. The approach is grounded on the premise that almost any information can be encoded as 2D pictures, and those are easily consumed by the human sensory system. The focus is on a common pictorial surface which contains a rendering of graphical objects. Sharing between collaborators is implemented at the level of the pictorial surface (i.e., view), with PostScript as communication medium, whereas our approach implements sharing at the model/data level, with XML as the communication medium. As the authors point out, editing the surface is cumbersome since application logic is lost in the rendering process. Our research has some similarities to the Visage system from Maya Design [9],[13]. Visage is a powerful visualization system that allows direct manipulation and visualization of large and diverse datasets. Visage is information-centric and maintains data repositories that provide data on-demand. The keys are repositories and unique identifiers for data units (collections of attribute-value pairs, called U-forms). Due to the data/view separation, Visage supports polymorphic views of data. Recent work on Visage Link [9] adds multiuser collaboration capabilities. Despite of these characteristics, Visage is primarily a data visualization tool. It is focused on data rather than computation; in particular the behavior part of the model is not supported in Visage. Since objects consist of attributes (data) and operations (behavior), Visage solves only part of the problem. XML from its inception was intended to separate data representation from visualization [1]. This is reflected in the fact that data are described in the XML document whereas the rendering is determined by an XSL (eXtensible Style-sheet Language) document. Several efforts are underway to realize XML’s potential for information exchange on heterogeneous devices. The wireless Application Protocol (WAP) Forum has standardized Wireless Markup Language (WML), an XML language optimized for specifying presentation and user interaction on limited capability terminals such as mobile phones, pagers, two-way radios, and smartphones [27]. Several companies, e.g., Nokia, already offer WAP-compliant devices but this architecture currently does not utilize XML/XSL separation.
WearLogic [26] developed an XML data model and browser for a credit-card-size personal information organizer. It implements simple data rendering, but not arbitrary applications. To our best knowledge, there is currently no other research effort that uses XML/XSL separation for dynamic run-time adaptation of application models and visualizations to heterogeneous devices.
3. OVERVIEW OF DISCIPLE Multi-user, synchronous collaboration is provided by the DISCIPLE framework [25]. DISCIPLE is based on replicated
architecture for groupware. Each user runs a copy of the collaboration client, and each client contains a local copy of the applications (Java Beans [22]) that are the foci of the collaboration. The merits of centralized vs. replicated groupware architectures are a longstanding issue in groupware design (see e.g., [6],[8]). Our choice of replicated architecture is dictated by the main tenet of DISCIPLE of allowing users to customize their workspaces by downloading software components. Since this is done on an individual basis, the architecture is necessarily replicated. Customizability is particularly useful in the context of heterogeneous environments. Figure 1 shows the architecture of the DISCIPLE system. The set of participants is represented hierarchically as an Organization, and they meet in Places (within an Organization). DISCIPLE is organized in two independent layers: (1) the communication layer, called the collaboration bus, deals with real-time event exchange, dynamic joining and leaving, concurrency control and crash recovery; and (2) the graphical user interface layer, itself a Java bean imported into DISCIPLE so it can be customized. The collaboration bus comprises a set of communication channels, where the peers can subscribe to and publish information. In order to make the user aware of other users actions, the DISCIPLE GUI provides several types of group awareness widgets to all the imported beans. Telepointers are widgets that allow a given user to track remote users’ cursors. In addition, the users can exchange messages, post small notes, and annotate regions of the shared application window.
3.1 Sharing Java Beans DISCIPLE is an application framework, i.e., a semi-complete application that can be customized to produce custom applications. The completion and customization is performed by
Figure 1. DISCIPLE architecture. Organizations and Places are abstractions implemented as multicast groups. They are represented in the user interface as Communication Center and Workspaces, respectively.
2
end-users (conference participants) that at runtime select and import task-specific Java components—Beans and Applets. The DISCIPLE workspace is a shared container where Java Beans can be loaded very much like Java Applets downloaded to a Web browser, with the addition of group sharing. Collaborators import Beans by drag-and-drop manipulation into the workspace. The imported Bean becomes a part of a multi-user application and all participants can interact with it. The application framework approach has advantages over the commonly used toolkit approaches in that with toolkit approaches the application designer makes decisions about the application functionality, whereas in our approach the end user makes these decisions. We consider the latter better because it is closer to the reality of usage and the real needs of the task at hand. According to the JavaBeans event model, any object can declare itself as a source of certain types of events. A source has to either follow standard design patterns when giving names to the methods or use the Bean Information class to declare itself a source of certain events. The source should provide methods to register and remove listeners of the declared events. Whenever an event for which an object declared itself as a source is generated, the event is multicast to all the registered listeners. The source propagates the events to the listeners by invoking a method on the listeners and passing the corresponding event object.
+describe Behavior
1
+observes/ acts-on
Glyph.
* +acts-on Us er Action
+acts-on
+contains
Act ion History *
Figure 2. A simple conceptual model of a generalized editor. objects that have a geometry and may be drawn. The name “glyph” is borrowed from typography to connote simple, lightweight objects with an instance-specific appearance [4]. Glyphs also have a size and origin for the purposes of layout. A Glyph may be an aggregate containing multiple leaf or aggregate glyphs. Glyph embodies the Composite pattern and may also include the Flyweight pattern [7], but not in our current design. A corresponding (simplified) class diagram is shown in Figure 3. All Glyphs in a document form the scene graph, itself a Glyph, which has a tree data structure. Glyphs are divided into two groups. Leaf Glyphs (terminal nodes) represent individual graphic elements, such as images, bars in bar charts, figures, text or numbers in spreadsheet cells. PolyGlyphs are containers for collections of Glyphs. They correspond to branch nodes and can have children. Example PolyGlyphs are group figures, paragraphs, maps or calendars. PolyGlyphs have all the functionality of the Glyphs. They also have the additional property that they can contain Glyphs or other PolyGlyphs. The basic operations on a tree are: (1) add node, (2) remove node, and (3) modify node properties. The corresponding Glyph methods are and addChild(), removeChild(), setProperty().The method transform() is essentially a setProperty() method, but we introduce it to speed-up the DomainControl
Document selection : Vector
processCommand() 1 +history CommandHi story presentCmdIndex : int undo() redo() log() +commands
The conceptual model of a typical document editor is shown in Figure 2. The key concept is a Glyph, which represents all
0..*
C ommandEvent
in implementing multi-tier be confused with such level of individual objects, level of large architectural
getSceneGraph() getSelecti on() +children
0..*
Gl yph
target : Glyph
The MVC pattern may be used architectures, but should not architectures. MVC applies at the whereas multi-tier applies at the modules.
+describe Properties
DISCIPLE provides some features to handle heterogeneity, primarily at the communication/networking level [16], but not at the application logic and interaction level. For this, the application bean itself must be properly architectured. Here we present a class of Java Beans called Manifold beans, which are designed to deal with heterogeneity at these levels. The main characteristic of the Manifold beans is the multitier architecture. The common three-tier architecture comprises the vertical tiers of presentation, application or domain logic, and storage. The Manifold’s presentation tier is virtually free of the application logic and deals with visualizing the domain data and accepting the user inputs. The domain tier deals with the semantics of tasks and rules as well as abstract data representation. The third tier in our case comprises the collaboration functionality, which is mainly provided by the DISCIPLE framework, but a part of it resides in the bean as discussed below. The domain tier contains all the model objects and the presentation tier contains all the view/controller objects of the MVC design pattern1 [14],[3]. The main benefit of this decomposition is the resulting separation of concerns. This separation is particularly important in heterogeneous environments, as will be seen below. The design internally comprises three beans, although the outside world (DISCIPLE) sees a single bean.
1
Document Folder
*
1 +contains *
4. MULTI-TIER BEAN ARCHITECTURE
4.1 Domain Bean
+contains
Document.
execute() unexecute() isReversible()
addC hild() removeC hild() getC hild() getParent() createIterator() setProperty() transform () grasp() release()
0..* DocumentFolder activeDocument : Document addDocument() removeDocument() getActiveDocument() setActiveDocument()
PolyGlyph
Figure 3. Domain class diagram of a generalized editor.
3
execution by avoiding checking whether the property name is “transformation” every time we are changing this property. Properties include color, texture, etc., but also various constraints on glyph manipulation. Glyphs are sources of the following types of events which are fired in response to the above listed operations: AppearanceEvent for add/remove operations, PropertyChangeEvent, and TransformEvent. The interested parties register as event listeners for some or all types of the events via the Java Beans delegation event model [22], as mentioned above. DomainControl is the system controller for the domain bean that invokes the system operations. This is the only portal into the domain bean. The only way to cause a state change in the domain bean is to invoke the processCommand() method. Even the local presentation (view) objects interact with the domain objects through this portal only. Undo/redo itself is invoked via the UndoRedoCommand, so the simple interface can be maintained. The CommandEvent class implements the Command pattern [7] and has the responsibility of keeping track of the argument values to invoke operations on Glyph and Document objects so the operations can be undone/redone. We name this class CommandEvent instead of Command to emphasize the Java event distribution mechanism. Concrete commands exist that correspond to the Glyph’s methods. In addition, we have different commands to create Glyphs, PolyGlyphs and Documents even though all of them are Glyphs. There are also commands to open or save a file and document-view-related commands, as will be seen in the next section. CommandEvents include the user ID attribute so it is possible to identify the originator of the command. This is useful for group undo/redo [21] as well as for group activity awareness and for controlling access rights. CommandEvents only encapsulate operation invocation arguments and the actual work is accomplished by Visitors [7], which are instantiated when a CommandEvent gets executed/unexecuted. This helps keeping CommandEvents lightweight, which is important to keep CommandHistory storage requirements lightweight. An example command execution diagram is shown in Figure 4 for CreateGlyphCommand. Other commands follow a similar procedure. Every Command execution is programmed to be an atomic operation in order to prevent contention in collaborative “write” access. Not all of the Glyph’s methods are necessarily primitive. For example, adding a branch node involves several add/remove operations on leaf nodes. There is no contention in the “read” access either, because the Event objects fired to the listeners encapsulate all the relevant source’s information, and this : Gly ph
Client
PresentationControl
GlyphView getModel() getShape() getTransform()
Tool createManipulator()
: Glyph View
getRootChildren() getViewpoint() setViewpoint() setCurrentTool()
4.2 Presentation Bean
4: addChild(Glyph)
The Model-View-Controller (MVC) design pattern divides an interactive application into three components [3]. The model contains the core functionality and data, views display information to the user, and controllers handle user input. A Glyph may have a corresponding GlyphView, which is a view part of the MVC pattern associated with the model Glyph.
6: create()
5: createOccured()
grasp() manipulate() effect()
information cannot be changed concurrently by another process. Behaviors are objects that observe the Glyphs as event listeners and act on Glyphs by invoking the processCommand() method on the DomainControl. We do not have a separate class for Behavior. Any object that satisfies these two conditions is a Behavior. Example behaviors are collision detection in threedimensional worlds, spreadsheet cells with formulas, or coordinated manipulation of several Glyphs, which is not the same as a group movement where all objects are manipulated in the same manner. Another example, a map PolyGlyph positions an icon Glyph according to its (x, y) properties, whereas a card pack PolyGlyph positions all its Glyphs stacked one on another, disregarding the Glyph’s coordinate properties. The Behaviors control only the Glyphs in the local domain bean to avoid duplicate execution in homogeneous applications. We reason that the developer should decide whether to implement the Behavior in each of the replicated copies of the application. In heterogeneous applications, this freedom may be important so to provide lightweight versions of the Bean which do not support Behaviors. The resulting inconsistency is acceptable since the heterogeneous replicas cannot be perfectly consistent anyway. If a Glyph implements a Behavior then other Glyphs may have a reference to it, but not explicitly. The reference is only implicit through the listener registration mechanism. Also, the Behaviors act on Glyphs via the processCommand() method rather than directly invoking the Glyph’s method, so the behavior’s manipulation can be undone via the regular undo/redo mechanism. These two restrictions are important in order to keep the scene graph as a tree data structure. This is very important, since otherwise the data structure would become a graph, which is more difficult in supporting collaboration-related functionality. Thus, even though the Behaviors are physically inside the domain package, they are logically outside since they are not part of the domain’s tree data structure. This separation of behavior structures from the graphic structures (scene graph) automatically results in contention avoidance.
: Command Event
: Document
Manipulator
Figure 5. Presentation class diagram of a generalized editor.
3: create()
: Command Hist ory
PolyGlyphView
DocumentView currentTool : Tool
2: execute( )
7: log(Command)
Decorat ions, t oolbars, menubar
processViewCommand()
1: processCommand(Command)
: Domain Control
Editor
: Document View
Figure 4. Collaboration diagram for creating a Glyph.
4
The Manifold Bean interacts with the collaboration bus to send and receive collaboration events. This interaction is through the Java Beans’ event mechanism: DISCIPLE subscribes for the bean’s events and replicates them to the collaborating peers. In order to support a real-time collaboration, the events must be intercepted before they get executed in the domain so to support event ordering, floor control, and/or concurrency control algorithms to ensure consistency across the peers. The options for interception are shown in Figure 7. The option ➀ intercepts lowlevel input events, which are too early for heterogeneous applications since these events are device- and view-specific. This solution requires commonality in the presentations: all presentation beans must be able to interpret remote events. This compromises our goal of minimizing such commonalities. The option ➁ is at the level of commands, before they change the state of the model. The CommandEvent is delivered to the collaborating peers and each evaluates the event in its own way. This solution is convenient for total event ordering and concurrency control. However, the local application response is slower if the local domain has to wait for the CommandEvent to get reflected back from the collaboration bus. The last option ➂ is to capture the state change notifications from the domain models to listeners. The local application response is nearly at the speed of single-user applications, but it is too late for event ordering since the Command event is already executed on the local model. We could apply a rollback mechanism (via undo/redo) for certain concurrency control algorithms. We select the option ➁ in the following manner. Figure 8 shows the interactions between the beans. Local commands are dispatched to both the local domain bean and to the collaboration bus (Figure 8a), either simultaneously or first to the bus and then wait for the command to get reflected back. Which strategy is used depends on whether an optimistic or a pessimistic concurrency control algorithm is employed. Local view commands are dispatched only to the collaboration bus (Figure 8b). Remote commands are dispatched either to the domain bean (Figure 8c) or to the presentation bean (view commands), but never to both. The case of remote view commands is not shown in the figure, but in it the Manifold bean just relays the remote view commands to the presentation bean. The conferees should also be able to vary the degree of coupling and sharing of the applications. Coupling and decoupling of participant beans is accomplished as follows. The Manifold Bean contains a coupling state object, which when coupled sends commands to both local and remote beans, and
: Tool
First traverses the scene graph and picks the target Glyph.
3: cmd := create(Tool,Glyph,Event)
2: manip := createManipulator(Glyph, Event) : Document View
: Manipulator 4: cmd := grasp(Event)
5: create(Glyph)
User : Command Event
1: mouseClicked(Event) 6: processCommand(Command) : Domain Control
Pass also argument s necessary to invoke the target's method.
Figure 6. Collaboration diagram for direct manipulation. The reverse may not be true, depending on whether the containing Document notifies or not its AppearanceListeners (DocumentView) about the creation of a new Glyph (Figure 4). The GlyphView subscribes to the model and listens to the important state changes. Thus, the derivatives of this class may implement some or all the listener interfaces (AppearanceListener, PropertyChangeListener, and/or TransformListener) as needed. The key user activity in graphical user interfaces is direct manipulation of screen objects. The classes that support direct manipulation are Tool and Manipulator [24]. Tool encapsulates information about the current direct manipulation mode, e.g., rotation, resizing, etc. Tools are essentially state objects for DocumentViews (see the State pattern in [7]). Manipulator encapsulates a Tool’s manipulation behavior and is responsible for providing visual feedback during a manipulation sequence (e.g., redrawing a rubber-band using the XOR technique). Tool– Manipulator breakup separates the state information from manipulation behavior. Manipulation involves a sequence of grasp-wield-effect operations, each of which results in a message to the manipulated object, which is encapsulated in a CommandEvent. Manipulator is the Controller part of the Model-ViewController design pattern in that it converts the user interaction into the CommandEvents for the model. The collaboration diagram for direct manipulation is shown in Figure 6. PresentationControl gathers all user actions that originate in the presentation bean and delivers them to its CommandListener(s), normally a DomainControl object. PresentationControl is the system controller that processes the presentation-related CommandEvents, such as changing the viewpoint, that originate at a remote process. Manipulator separation helps keeping the application lightweight (especially presentation layer), since the Manipulators are created only for direct manipulation.
D
4.3 Manifold Bean $
The two beans presented above need to be glued together since the execution environments assume single beans. We call the “Manifold Bean” the bean that glues the other two beans together and is the only bean visible to the execution environment, DISCIPLE in our case. In the case of single-user applications the presentation bean may assume the gluing role. Multiuser applications require additional functionality for collaboration awareness and group communication. Rather than complicate the presentation bean, we introduce the third bean.
%
&
!
&
'
"
(
#
#
)
*
+
,
(
-
E
F
3
4
5
6
7
8
9
:
4
;
5
=
?
@
A
>
B
C
?
.
Figure 7. Three options for event interception in collaborative Manifold beans.
5
G
(a )
1:
U
V
W
X
Y
Z
[
\
]
^
V
p
es roc
sCo
mma
nd (
I
) K
L
M
N
M
O
2b: p roces sComm and() _
`
pro
1:
l
b
d
c
m
`
n
o
e
f
b
c
P
Q
a
g
(b )
components in a repository, which can be selected at run-time so to customize the application’s document, the way it is visualized, and the way the entire application is generated. We have chosen XML as the language for such purpose. XML is a markup language for documents containing structured information [28]. Structured information contains both content (words, pictures, etc.) and some indication of what role the content plays. For example, content in a section heading has a different meaning from content in a footnote, which means something different than content in a figure caption or content in a database table, etc. Almost all documents have some structure. A markup language is a mechanism to identify structures in a document. On the other hand, XSL is designed to help browsers and other applications display XML. Stated simply, a style sheet contains instructions that tell a processor (such as a Web browser, print composition engine, or document reader) how to translate the logical structure of a source document into a presentational structure. Figure 9 illustrates processing the XML/XSL documents. The source tree is the tree representation of the parsed XML source document. All XML documents can be represented as trees. The XSL processor starts with the source tree and processes it by finding the template in the style sheet that describes how that element should be displayed. The pattern that most closely matches this particular source node is applied and that rule is used to generate a new result node, which is the local representation of the XML data. Each node is processed in turn until there are no more nodes remaining. The tree that is created in this process is called the result tree. The result tree is in a format readily understood by the displaying application. Parsing the common XML file and the local XSL file generates the view at a particular user's machine. The XSL document maps elements in the XML document (source tree) to nodes in the result tree such that the Renderer knows how to render them. By applying the rules defined for the various objects in the XSL file on the XML data the result tree is formed which can be unique for every user. Thus the user can customize his/her view. Figure 10 shows an example in which a camp on a situation map is rendered so that one viewer shows the camp as a group of objects, whereas another viewer shows it as a single icon. Thus, views may differ due to different user needs/expertise/concerns, or due to different display capabilities.
J
P
R
S
O
T
M
Q
O
b
d
b
d
3: transformOccured() appearanceChanged() propertyChanged()
W
2a: processCommand()
H
Vie ess
w Co
mma
) nd( j
i
h
b
f
h
f
c
d
e
f
b
d
i
f
d
k
b
k
c
`
d
e
f
d
_
`
a
b
c
d
e
f
b
d
2: processViewCommand()
g
j
i
f
h
h
i
f
f
d
k
b
k
c
`
d
e
f
(c )
l
b
d
c
m
`
n
o
e
f
b
d
3: transformOccured() appearanceChanged() propertyChanged()
2: pr ocess Comma 1: processRemoteCommand() nd() _
`
a
b
c
d
e
f
b
d
Figure 8: Event exchange and interception in a Manifold bean. (a) Commands generated by the local user that affect the domain bean; (b) commands generated by the local user that affect the presentation bean; (c) commands generated by the remote user that affect the domain bean.
5.1 Mapping XML Documents to Manifold
when decoupled sends only to the local bean. Domain commands can be coupled only in an all-or-none manner. Unlike this, the user may want to couple/decouple just some of the view commands, e.g., scrolling but not zooming. Since the available view commands cannot be foreseen for all possible applications, we require the view command classes to register with the PresentationControl, which maintains a look-up table of registered and coupled/decoupled view commands. The user can change the coupling status at any time.
5. INTEGRATION OF XML So far we have presented an architecture which can be used to build heterogeneous groupware. However, once built, the beans do not allow for dynamic customization so to be able to adapt to the current context. Since Java supports dynamic loading of individual classes, we could exploit this feature and consider the above classes as
The XML programmer creates an XML and XSL files based on, respectively, the sets of available Glyphs and GlyphViews as well as their characteristics. Manifold Glyphs correspond to elements in the source tree and GlyphViews correspond to elements in the result tree. Attributes in the result tree are mapped to the Glyph properties. For example, if the result node corresponding to a Glyph has an attribute COLOR with a value of BLUE, the Glyph’s property “color” is initialized in blue. However, the correspondence between the elements and Glyphs is not one-to-one. Not all XML elements are Glyphs. For example,
x
y
z
{
|
}
~
}
¦
§
«
¬
®
¦
¯
£
p
q
r
s
t
u
v
¤
¡
¥
ª
§
§
¨
©
§
ª
§
¢
¥
w
Figure 9. A typical XML document rendering process using a DOM parser. The SAX parser works in a similar manner [28].
6
§
ª
Figure 11b, so that the XSL document sets up the presentation part and a D-HTML domain embedded in the XML document controls the presentation’s DOM tree. The solution presented in Figure 11a is not flexible and the one in Figure 11b is not elegant for using XML/XSL documents. We apparently need to XSL Rulesm somehow induce the DocumentView to instantiate the XSL Rulesn GlyphViews determined by the result tree. Views Result Elementm must be generated directly by reading the result tree. How can this information be passed via Result Elementn processCommand() onto the presentation bean? We would like to avoid altering the sequence shown in Figure 4 just for this purpose. One way is instantiating Glyphs with preferred views. The Glyph Figure 10. Rendering a source XML element by different XSL rules yields in would not actually know about the view object, different result elements. which is passed as a string via the Java reflection mechanism. Another option is passing a look-up table some elements could describe a Glyph’s properties. A 3D of GlyphViews identified by the result tree to the DocumentView. transformation could be represented as: The table is then used to instantiate GlyphViews upon createOccured() messages from the Glyphs. This solution is … 4x4 matrix defining the 3D transformation … less flexible since all the Glyphs of the same type would have the This element could even have sub-elements if the transformation same GlyphView type. Thus, we chose the first solution. is represented via the axis-angle, scale and translation parameters, 5.2 Structured Messaging each tagged individually. Automatic consistency among the objects in exact replicas is The result tree is used to create the domain scene graph. We typically achieved by executing the same set of operations on considered using the XML’s Document Object Model (DOM) tree these objects. As mentioned earlier, there are only three types of as the scene graph and redesigning the domain bean’s design changes that take place as the user interacts with the system: (1) around the DOM tree. The advantage of this design would be that add node, (2) remove node, and (3) edit node properties2. Even the changes in the DOM tree could be easily converted to an so, the changes may not be applicable directly in the remote XML message and sent to the remote peers, and the change could replicas. With heterogeneous applications, the operations must be be easily effected on their DOM trees. The drawback is that the transformed before applying them to different model Glyphs. DOM tree is heavyweight compared to the Glyph tree, in We define the format for the messages as ASCII text using particular since many DOM nodes correspond to Glyph properties XML notation. This allows structured definition of the events, or do not show up at all, e.g., new lines. In the interest of which in turn yields the following: lightweightness and speed we decided to keep the Glyph tree. • The change notification is more meaningful, as the change When creating the Glyphs in the scene graph, every request to the domain is as usual issued by invoking processCommand() on the DomainControl. The views are created automatically when the DocumentView gets notified via a createOccured() message (Figure 4). However, this implies that the views are hard coded and there is no control over choosing the views adaptively—the XSL document is useless and a key strength of (a) XML is lost! This issue is important in general XML-based applications, not only in Manifold. The simplest solution is to ignore the domain/presentation separation and consider the entire application as the Renderer in Figure 9. The XML document just supplies the attribute values for the applications objects. We can transform this data prior to loading it into the application (Figure 11a). This is what Web browsers currently do as applications. The application serves only as a visualization front-end and is necessarily “shallow” in order to be general. The result tree of Figure 9 must (b ) be fed directly to the application’s domain rather than to the Figure 11. (a) XML document (transformed) sets up the presentation, which is affected only indirectly. One problem with models but does not directly affect the views. (b) XML this solution is that the domain/model is not programmable by the document carries the domain part of the application. end user. From the user’s viewpoint, no advantage is achieved by model-view separation and they might as well be tightly coupled. 2 Java applets and Dynamic HTML (e.g., JavaScript) offer a way to There are also file saving/opening operations and viewpoint implement specific behaviors and can even manipulate the operations, but they are simpler to handle since they do not browser’s DOM tree. It is possible to implement a solution as in affect the document data structure. XML Element °
±
²
³
´
À
µ
Á
Â
²
Ã
Ä
ã
³
Å
ä
ã
¹
é
½
Ê
ì
3
7
8
9
:
3
;
9
E
F
:
7
G
H
F
6
7
?
¿
Ì
Í
î
Î
ì
Ï
ï
Ð
ð
Ñ
ñ
Ò
ò
Ó
'
(
ó
Ô
ô
Õ
õ
ö
Ö
×
÷
Ø
Ù
õ
ø
Ú
Ü
û
ú
Û
ù
Ý
ü
ý
Þ
ß
þ
ÿ
à
á
â
ß
ÿ
!
"
#
$
"
%
&
)
*
+
,
-
.
/
0
1
2
2
0
N
¸
Ê
í
3
¾
Ë
ë
¼
É
ê
»
È
è
º
Ç
ç
¸
Æ
æ
·
Ã
å
¶
@
A
O
P
B
Q
C
R
D
0
S
T
2
U
V
W
T
X
P
Q
~
R
S
T
V
W
Y
T
o
Z
[
\
]
^
_
`
a
_
]
b
c
^
d
e
f
g
h
i
j
k
l
m
n
o
p
y
u
o
o
o
t
u
v
w
x
y
z
{
t
|
}
~
~
~
~
o
t
l
j
k
l
m
n
|
o
o
p
o
o
q
p
r
o
}
s
q
r
o
r
¡
¢
£
¤
q
z
t
{
~
Æ
¥
¦
¨
Ð
®
¶
³
°
±
´
Ó
Ê
Ë
Ì
É
Ô
Õ
Ö
×
Ø
Ó
Í
Î
²
´
µ
·
¸
¹
º
»
¼
½
¾
¿
Ù
²
µ
Ú
Û
à
á
â
ÿ
þ
Þ
ß
ã
ä
ç
è
û
é
ì
í
ê
î
ü
å
æ
ÿ
Ü
Ý
ï
ë
ð
ñ
ò
ó
ô
ó
7
É
¯
Ò
³
È
Ñ
°
¬
Ç
ª
Ï
«
Ç
§
©
õ
ù
ö
ú
÷
ø
ü
ý
þ
ÿ
þ
ÿ
ü
À
¿
Á
Â
Ã
Â
Ä
Å
Á
information includes the type change taking place as well as the data being manipulated • The same XSL rules can be used to transform the CommandEvent itself so that it applies to the remote domain The events are communicated over the DISCIPLE collaboration bus to the peers as XML fragments. An example event is:
&
2
!
'
(
When an event arrives at the remote sites, the local source trees get updated and re-rendered to the result trees. We use XML’s XPointer to identify the changed XML element and its attributes in the remote documents. Manifold uses weak sharing, which means that each client distributes the changes in only the elements and attributes that its view knows about. Let us consider the example in Figure 10. If user n relocates the icon, attributes (XPOS,YPOS) will change. When multicasting the change to the peers, we need to send only the change in (XPOS,YPOS). When the 3D peer m receives the event message, it updates its own (XPOS,YPOS) attributes. If the terrain is not flat, the change in the (x,y) coordinates only may result in the object being buried under the ground or floating above the ground. In order to correct for this, the client m may have a Behavior that automatically adjusts the z-coordinate. The question is, should this automatic correction be multicast to the peers? If not, we will end up with inconsistent models across the collaborators. If the correction is broadcast, it may result in oscillatory event traffic, as discussed elsewhere [17].
!
)
NAME="color" VALUE="magenta"
"
*
#
$
%
+
,
-
)
"
1
+
Figure 12: Bean loading mechanism for heterogeneous clients. ① The control module (Manifold Bean equipped with the information from DISCIPLE) downloads the domain bean based on the computing/network environment characteristics. ② The control module then downloads the XSL document, parses it and downloads the presentation bean. environment and loads the other two beans accordingly. The process is illustrated in Figure 12. The user’s current task determines the corresponding Manifold bean. The DISCIPLE framework senses the environment capabilities, such as display size or network bandwidth and passes this information onto the Manifold bean [16]. The Manifold bean then loads the domain/presentation beans pair and the client is ready for the collaborative session. An even more flexible and advanced solution is available by using the Bean Markup Language (BML) [10] to assemble the beans at run time. Instead of directly loading the pre-packaged domain/presentation beans, the Manifold bean may load two BML documents. The BML documents contain scripts for dynamic assembling of the beans from a (remote) repository of Java classes. We are presently working on implementing this solution.
5.3 Heterogeneity Management
6. EVALUATION
We could implement one general domain bean that contains many different Glyphs and Behaviors. Also, a corresponding presentation bean could render any object, whether twodimensional or three-dimensional. The extreme solution would be to make no distinction between the beans. However, these solutions are very inflexible and particularly inappropriate for thin clients which cannot handle large programs. For example, if a Glyph represents a vehicle that can be set into motion, the Glyph’s behavior should be pre-programmed to act as a mobile vehicle and cannot be altered. For every new behavior, we have to alter the domain or presentation packages and introduce new Glyphs or Behaviors. A key benefit of implementing presentation and domain as distinct beans rather than the whole package as a single bean is in being able to mix and match different combinations. We can have a set of more or less complex beans for each. Different domain beans can implement complex Behaviors and the presentation beans can implement visualizations with varying realism. Depending on the context, different domain/presentation pairs can be downloaded on demand. In addition, each bean in the pair may run on different machines. The presentation bean may run on a hand-held device, and the domain bean would run on a PC embedded in the environment (base station). In this solution the user selects which overall bean to load for the task at hand, and which domain/presentation beans for its components. Having the user manually select domain/presentation beans may be overwhelming. Instead, this process can be automated. The “glue” bean can assume the role of automatic bean selection since it loads and interconnects the other two beans. The built-in intelligence senses the computing and network
The framework presented here generalizes to arbitrary groupware applications. The Glyph tree data structure may not be the most efficient data type for specific applications but settling on one data type simplifies the framework design. To demonstrate the versatility of the Manifold framework, we implemented several complex applications. The applications include: • A powerful two-dimensional graphics drawing editor • A low-end three-dimensional collaborative virtual environment • A set of virtual biology laboratories including cell division (Figure 13), centrifugation, spectrophotometry and virtual
Figure 13: Screen snapshot of a phase in the cell division virtual lab.
8
microscopy The virtual biology laboratories interactively guide the user through the phases of the actual lab experiment. Both direct manipulation and animation behaviors are incorporated. The virtual labs are currently not implemented as heterogeneous collaborative applications. In order to assess the Manifold approach to heterogeneous collaboration, we defined a DTD language for representing a 3D situation map. We developed two Manifold beans: one that can render 2D graphics and the other that renders 3D graphics. We also created an XML document with a map and objects on it, as well as two XSL documents for the corresponding viewers. The hypothesis being tested is that conferees can collaborate on (nearly) the same document displayed with different user interfaces that best suit their needs. In our tests, a user with a high-end workstation has a 3D representation of a terrain map, whereas the user with a Xybernaut wearable computer uses a 2Dmap representation with reduced resolution. Manifold should provide for meaningful collaboration. Figure 14 shows the two Manifold Beans loaded in the DISCIPLE workspace along with the chat bean. Here we have an example where the models are different too. Different user types load slightly different XML documents, where, for example, the camp object is mapped as in Figure 10. The mobile users load a 2D-bitmap GIF file, whereas the stationary users load a 3D-elevation map DTED (Digital Terrain Elevation Data) file. Also, the 2D XML document uses GIF icons for asset symbols, whereas the 3D XML document uses VRML models. Conferees are able to refer to the “same” object and manipulate it, although they see it quite differently in their respective displays. A rigorous human factors evaluation is currently in progress and will be reported elsewhere. Our first applications span a somewhat narrow range of heterogeneity. The restriction is intentional so we do not need to deal with other issues from the beginning. The move to palmtops requires user interface design and usability research [11], which is outside the scope of this paper. Nevertheless, our experience with
the framework to date indicates that the present Manifold design will remain virtually unchanged in such environments.
7. CONCLUSION The Manifold framework presented here provides for developing groupware applications that can adapt to disparities in computing and communication capabilities of the collaborative participants. Different capabilities may result in different replicated objects being shared, e.g., due to compression in order to conserve communication bandwidth. Manifold ties a flexible software architecture with XML-based information exchange into an adaptive design for heterogeneous application sharing. XML is a standard that recently has already gained great acceptance [2], and provides a powerful medium for both data exchange and visualization specification. The Manifold framework offers a software architecture to realize XML’s potential for information exchange in heterogeneous environments. The framework’s main characteristics are a multi-tier architecture and a single data structure (tree). These respectively allow for flexible composition of modules and simpler implementation of group-related functions. There are significant issues with maintaining consistency and state synchronization of heterogeneous models, but those are outside the scope of this paper and are addressed in [17]. Ideally, we should be able to dynamically generate the application based on the computing and communication capabilities of the access device. Our current efforts are in the direction where the device publishes its characteristics and automatically receives the XSL file appropriately adapted. The DICIPLE framework, on the other hand, senses the communication link characteristics [16] and customizes the domain bean and the document to be loaded into the application bean. Bean Markup Language [10] opens further possibilities for dynamic application customization. The solution presented here can be extended to a broader domain of data sharing in heterogeneous environments. For example, a user may carry his/her XML documents (models) on a wearable computer. As the user connects the computer to different display devices, heterogeneous views may be created according to
Figure 14: Two collaborating users share the same mission-planning workspace but with different versions of the area map application. The left user uses two-dimensional and right user uses three-dimensional rendering of the missionplanning document. They both use the same chat JavaBean. 9
the device characteristics. Manifold source code, detailed documentation and example applications are available at: http://www.caip.rutgers.edu/disciple/
[13] Kolojejchick, J., Roth, S. F., and P. Lucas, “Information Appliances and Tools in Visage,” IEEE Computer Graphics and Applications, 32-41 (July/August 1997).
[14] Krasner, G., and S. Pope, “ A Cookbook for Using the Model-View-Controller User Interface Paradigm in Smalltalk-80,” J. Object-Oriented Programming, 1(3), 2649 (August/September 1988).
8. ACKNOWLEDGMENTS Allan Krebs, Ajay Wanchoo, Bogdan Dorohonceanu, and Krishnam Raju Pericherla contributed significantly to this work. The research reported here is supported in part by DARPA Contract No. N66001-96-C-8510, NSF KDI Contract No. IIS-9872995 and by the Rutgers Center for Advanced Information Processing (CAIP).
[15] Larman, C., Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design, Prentice-Hall PTR, Upper Saddle River, NJ (1998).
[16] Liang, C., and I. Marsic, “Wireless Awareness in Heterogeneous Networks,” submitted for publication.
9. REFERENCES [1] Bosak, J., “XML, Java, and the Future of the Web.” Sun Microsystems (c. 1 Oct 98) http://sunsite.unc.edu/pub/suninfo/standards/xml/why/xmlapps.htm (1997).
[17] Marsic, I., “State Synchronization in Heterogeneous Groupware,” submitted for publication.
[18] Myers, B.A., Stiel, H., and R. Gargiulo, “Collaboration Using Multiple PDAs Connected to a PC,” Proc. ACM 1998 Conf. Computer-Supported Cooperative Work (CSCW'98), Seattle, WA, 285-294 (November 1998).
[2] Bosak, J., and T. Bray, “XML and the Second-Generation Web.” Sci. Amer., 89-93 (May 1999).
[3] Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., and M. Stal, Pattern-Oriented Software Architecture: A System of Patterns, John Wiley & Sons, Inc., New York, NY (1996).
[19] Olsen, D. R., Hudson, S. E., Phelps, M., Heiner, J., and T. Verratti, “Ubiquitous Collaboration via Surface Representations,” Proc. ACM 1998 Conf. ComputerSupported Cooperative Work (CSCW'98), Seattle, WA, 129138 (November 1998).
[4] Calder, P.R., and M. A. Linton, “Glyphs: Flyweight Objects for User Interfaces,” Proc. 3rd ACM SIGGRAPH Symp. User Interface Software and Technology (UIST), Snowbird, UT, 92-101 (October 1990).
[20] Patterson, J. F., Hill, R. D., Rohall, S. L., and W. S. Meeks, “Rendezvous: An Architecture for Synchronous Multi-User Applications,” Proc. ACM 1990 Conf. Computer-Supported Cooperative Work (CSCW'90), Los Angeles, CA, 317-328 (October 1990).
[5] Churchill, S., Structured Graphics in Fresco, C++ Report, 7(3), 61-68, (March/April 1995).
[6] Dewan, P., “Architectures for Collaborative Applications,”
[21] Prakash, A., “Group Editors,” in Computer Supported Co-
in Computer Supported Co-operative Work, M. BeaudouinLafon (Ed.), John Wiley & Sons, Chichester, England, 169193 (1999).
operative Work, M. Beaudouin-Lafon (Ed.), John Wiley & Sons, Chichester, England, 103-133 (1999).
[22] Sun Microsystems, Inc. JavaBeans API Specification, http://www.javasoft.com/beans/
[7] Gamma, E., Helm, R., Johnson, R., and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software. Addison Wesley Longman, Inc., Reading, MA (1995).
[23] Tang, S. H., and M. A. Linton, “Blending Structured Graphics and Layout,” Proc. 7th ACM Symp. User Interface Software and Technology (UIST), Marina Del Rey, CA, 167173 (November 1994).
[8] Greenberg, S., and M. Roseman, “Groupware Toolkits for Synchronous Work,” in Computer Supported Co-operative Work, M. Beaudouin-Lafon (Ed.), John Wiley & Sons, Chichester, England, 135-168 (1999).
[24] Vlissides, J. M., and M. A. Linton, “Unidraw: A Framework for Building Domain-Specific Graphical Editors,” ACM Trans. Information Systems, 8(3), 237-268 (July 1990).
[9] Higgins, M., Lucas, P., and J. Senn, “VisageWeb: Visualizing WWW Data in Visage,” Proc. IEEE Symp. Information Visualization (InfoVis ‘99), San Francisco, CA (October 1999).
[25] Wang, W., Dorohonceanu, B., and I. Marsic “Design of the DISCIPLE Synchronous Collaboration Framework,” Proc. 3rd
(BML),
IASTED Int’l Conf. Internet, Multimedia Systems and Applications, Nassau, Bahamas, 316-324 (October 1999).
[11] Jones, M., Marsden, G., Mohd-Nasir, N., Boone, K., and G.
[26] WearLogic web page: http://www.wearlogic.com/ [27] Wireless Application Protocol Forum. Wireless markup
[10] IBM,
Inc., Bean Markup Language http://www.alphaWorks.ibm.com/tech/bml/
Buchanan, “Improving Web Interaction on Small Displays,” Proc. 8th Int’l World Wide Web Conference, (1999).
[12] Karsenty, A., Tronche, C., and M. Beaudouin-Lafon, “GroupDesign: Shared Editing in a Heterogeneous Environment,” USENIX Computing Systems, 6(2), 167-195 (Spring 1993).
language specification SPEC-WML-19990616.pdf. http://www.wapforum.org/what/technical.htm
At:
[28] World Wide Web Consortium. Extensible Markup Language. At http://www.w3.org/XML/.
10
