7
0018-9162/03/$17.00 © 2003 IEEE 56 Computer ANTS Framework for Cooperative Work Environments T he Internet’s ubiquity, along with enor- mous growth in network bandwidth and computing power, has fostered a multitude of computer-supported cooperative work (CSCW) environments in recent years. These include instant messaging services such as ICQ and Yahoo Messenger, peer-to-peer file-shar- ing systems such as Napster and Gnutella, multi- user games such as Ultima Online, and shared workspace systems such as BSCW (basic support for cooperative work). Key factors in facilitating the advent of CSCW environments include the use of open systems that permit system interoperability; advances in data- base, computer graphics, and display technology; and widespread acceptance of networking tech- nologies and protocols. The open-ended commu- nication possibilities of this emerging medium will soon lead to a boom in such environments, enabling remote users to interact in unprecedented ways. GROUPWARE Developing the software that runs CSCW systems, known as groupware, on conventional platforms presents a complex task that forces developers to repeatedly invent similar solutions to similar prob- lems. Consequently, many R&D initiatives have embedded generic solutions into their groupware development platforms. 1 These platforms, or tool- kits, seek to simplify groupware development by reusing solutions for the common problems found in multiuser collaborative applications. Many groupware toolkits successfully abstract access to distributed services, thereby reducing the learning curve. For example, the classic GroupKit 2 groupware platform provides programming abstrac- tions such as multicast remote procedure calls, multiuser interface objects, session management events, and shared data structures—called environ- ments—that have embedded collaborative consis- tency management. Although powerful, GroupKit and many other existing platforms have three main deficiencies: At the conceptual level, they concentrate on multiuser services for groupware applications and thus do not define powerful monitoring and awareness services for analyzing the infor- mation the collaboration process generates. At the architectural level, they lack a consis- tent component model, which is necessary for developing collaborative third-party compo- nents that can be assembled into an applica- tion framework. At the technological level, they lack horizon- tal middleware integration and thus implement custom proprietary services, which siphon off development effort and resources to create the required middleware, precluding system inter- operability and thus widespread acceptance. Subsequent research assimilated results from the first groupware toolkits but emphasized component models to simplify development. Habanero Hablets, 3 ComeCo Medium grouplets, 4 and Disciple Java- Beans 5 all define component platforms that consid- erably simplify development and software reuse. Unfortunately, these toolkits do not provide a com- Designed to facilitate computer-supported cooperative work, ANTS overcomes the major deficiencies found in earlier groupware toolkits at the conceptual, architectural, and technological levels. Pedro García López Universitat Rovira i Virgili Antonio F. Gómez Skarmeta Universidad de Murcia RESEARCH FEATURE Published by the IEEE Computer Society

ANTS framework for cooperative work environments

  • Upload
    afg

  • View
    212

  • Download
    0

Embed Size (px)

Citation preview

Page 1: ANTS framework for cooperative work environments

0018-9162/03/$17.00 © 2003 IEEE56 Computer

ANTS Framework forCooperative WorkEnvironments

T he Internet’s ubiquity, along with enor-mous growth in network bandwidth andcomputing power, has fostered a multitudeof computer-supported cooperative work(CSCW) environments in recent years.

These include instant messaging services such asICQ and Yahoo Messenger, peer-to-peer file-shar-ing systems such as Napster and Gnutella, multi-user games such as Ultima Online, and sharedworkspace systems such as BSCW (basic supportfor cooperative work).

Key factors in facilitating the advent of CSCWenvironments include the use of open systems thatpermit system interoperability; advances in data-base, computer graphics, and display technology;and widespread acceptance of networking tech-nologies and protocols. The open-ended commu-nication possibilities of this emerging medium willsoon lead to a boom in such environments, enablingremote users to interact in unprecedented ways.

GROUPWAREDeveloping the software that runs CSCW systems,

known as groupware, on conventional platformspresents a complex task that forces developers torepeatedly invent similar solutions to similar prob-lems. Consequently, many R&D initiatives haveembedded generic solutions into their groupwaredevelopment platforms.1 These platforms, or tool-kits, seek to simplify groupware development byreusing solutions for the common problems foundin multiuser collaborative applications.

Many groupware toolkits successfully abstractaccess to distributed services, thereby reducing the

learning curve. For example, the classic GroupKit2

groupware platform provides programming abstrac-tions such as multicast remote procedure calls,multiuser interface objects, session managementevents, and shared data structures—called environ-ments—that have embedded collaborative consis-tency management.

Although powerful, GroupKit and many otherexisting platforms have three main deficiencies:

• At the conceptual level, they concentrate onmultiuser services for groupware applicationsand thus do not define powerful monitoringand awareness services for analyzing the infor-mation the collaboration process generates.

• At the architectural level, they lack a consis-tent component model, which is necessary fordeveloping collaborative third-party compo-nents that can be assembled into an applica-tion framework.

• At the technological level, they lack horizon-tal middleware integration and thus implementcustom proprietary services, which siphon offdevelopment effort and resources to create therequired middleware, precluding system inter-operability and thus widespread acceptance.

Subsequent research assimilated results from thefirst groupware toolkits but emphasized componentmodels to simplify development. Habanero Hablets,3

ComeCo Medium grouplets,4 and Disciple Java-Beans5 all define component platforms that consid-erably simplify development and software reuse.Unfortunately, these toolkits do not provide a com-

Designed to facilitate computer-supported cooperative work, ANTSovercomes the major deficiencies found in earlier groupware toolkits at the conceptual, architectural, and technological levels.

Pedro GarcíaLópezUniversitat Rovira i Virgili

Antonio F.GómezSkarmetaUniversidad de Murcia

R E S E A R C H F E A T U R E

P u b l i s h e d b y t h e I E E E C o m p u t e r S o c i e t y

Page 2: ANTS framework for cooperative work environments

ponent model that integrates with a flexible moni-toring service. Further, the developers have not con-structed their models atop a middleware integrationframework, so broadcasting and persistence serviceshave to be created ad hoc.

Another important trend in groupware toolkitsunderscored the importance of a collaboration busas an essential service either for supporting statepropagation and event management or for moni-toring awareness systems. For example, PrasunDewan’s Collaboration Bus project at the Uni-versity of North Carolina at Chapel Hill (www.cs.unc.edu/~dewan/cb.html) developed a softwareabstraction that facilitates composing collabora-tive systems by providing generic services such assession and coordination support and shared datastructures.

ANTS FRAMEWORKTo address the deficiencies with existing toolkits,

we created the ANTS CSCW component frame-work (http://ants.etse.urv.es/). We based ANTS onrefined versions of all three groupware develop-ment approaches, proposing new solutions at theconceptual, architectural, and technological levels.

The distributed Model View Controller in Bell-core’s Rendezvous project6 also influenced our work,as did monitoring and awareness systems such asNessie.7 Designed to provide a generic multiuser col-laborative framework, ANTS is based on solid dis-tributed technologies and provides generic CSCWservices to the user and developer communities.

The framework defines a dedicated awareness

and monitoring service that seamlessly integrateswith the overall component model. Based on thestandard JavaBean specification, the componentmodel hides complexity from users by providingtransparently remote persistence, distributed events,and component descriptors and packaging. Themonitoring services and component model are posi-tioned atop a middleware integration framework,which uses a standardized approach to distributedservices. By combining centralized and replicatedarchitectural services, ANTS provides developerswith a variety of tools and architectural designs tomanage different problem sets.

The overall architecture consists of three mainlayers: a technology layer, a CSCW layer, and anapplication layer. Upper layers represent high-levelabstractions that hide the complexity of the layersbelow. As Figure 1 shows, all components triggerevents to the collaboration bus, and awarenesscomponents listen to it for information about whatis happening in the system.

Application layerOur primary goal is to facilitate the development

of collaborative components and applications ormonitoring agents by achieving a smooth transi-tion from local to distributed applications. Theapplication layer abstracts access to a remote prop-erty-based persistent component and distributedevents produced in the current session. Like manyother groupware toolkit developers, we use Javaand JavaBean as our preferred technologies. Ourapproach sustains JavaBean components in a con-

March 2003 57

Vote

rBea

n

Ligh

tBea

n

Slid

esBe

an

Bus

CORE

Mon

itorin

g

Data

ana

lysi

s

Info

bots

AWS

COMM

Middleware integration frameworkMiddlewareservices

Technologylayer

CSCWlayer

Applicationlayer

Figure 1. ANTS architecture. All components trigger events to the collaboration bus, and awareness componentsglean system changes from it.

Page 3: ANTS framework for cooperative work environments

58 Computer

tainer that hides complexity in distributed pro-gramming and networking skills.

The ANTS server stores properties as shared datastructures. Each JavaBean component can usestring properties, string indexed properties, andserializable object properties. To assure componentpersistence, the remote property-based componentstores these properties in a database. Each prop-erty change will trigger an event that allows a latersubscription to PropertyChangeEvents. In addition,addPropertyChangeListener methods receive prop-erty-change events in bound properties. Theseevents are received from the distributed notifica-tion service and restricted to events in the currentsession and component.

The framework supports coordination generi-cally by providing coordination rules for access,concurrency, and floor control. Each method cantrigger a PropertyVetoException similar to theJavaBean model’s constrained-property conven-tion. Our model differs, however, in the source ofthe VetoException: In ANTS, registered coordina-tion managers interpose calls to a component toassure the requested action’s validity.

An XML descriptor file facilitates ANTS frame-work customization and component introspection.In general, a descriptor includes properties andevent information. Event information provides theawareness infrastructure with the key for knowingwhich events are triggered by each resource in theshared environment.

Component packaging uses standard jar files sim-ilar to the JavaBean component model. The pack-age must contain the XML descriptor, componentclasses, and any local resource, such as images orfiles, used in the component. An automated processuses the XML descriptor to register components inthe component repository, deploys the packagedcomponents to the ANTS server, and copiesunpackaged resources to the Web container. Therepository controls the permissions for gettinginformation about registered components andallows insertion and removal of artifacts in shared-session contexts.

CSCW layerThe “CSCW Services” sidebar describes the set

of collaborative services that the ANTS containeroffers to the application layer. Two main modulesseamlessly interconnect via the collaboration bus.CORE is a runtime container with a generic andextensible application layer for collaborative tools,while AWS is a generic awareness service that pro-vides appropriate actuators for events receivedfrom the collaboration bus.

CORE. This module includes explicit support forsessions, shared artifacts, coordination control,security, and integration of both synchronous andasynchronous applications. Its design was stronglyinfluenced by multiuser object-oriented (MOO)architectures, which are both extensible and generic.In a MOO system, place objects, which representdiscrete locations interconnected by portal objects,define the space’s topology. These portal objects canestablish graph-directed relationships betweenplaces. Every static or dynamic entity is an objector thing, which has a set of properties and a set ofverbs that can be added or removed at runtime.

As in a MOO system, the place object representsan ANTS shared session, interconnected by portalobjects. JavaBean components, dynamically loadedby the ANTS container, represent the shared arti-facts. Object properties are represented by theremote, persistent property-based component, andobject verbs are JavaBean classes.

The place object represents a shared session andcontains users, components, and links to otherplaces. It provides methods to send or subscribe to

CSCW Services

In creating the ANTS framework, we focused on four essential CSCWservices: shared sessions, support for synchronous and asynchronouscomponents, coordination, and awareness.

A session is a group of objects associated with some common com-munications pattern, supporting full-duplex multipoint communicationamong an arbitrary number of connected application entities. The con-cept of a shared session is essential to any CSCW toolkit, and it definesthe basis for shared interactions in a common remote context.

Explicit support for shared artifacts is also essential. Normally, usersengage in collaborative interaction with other users in a shared context,or with accessible collaborative components. These collaborative com-ponents—usually called artifacts—range from synchronous to asyn-chronous, depending on the interaction time. Explicit support for thecreation and insertion of new artifacts is a differentiating factor betweenextensible and nonextensible CSCW toolkits.

Another key issue is explicit software support for coordination poli-cies. These policies can be set programmatically or declaratively, andthey can be categorized in rules for access, concurrency, and floor con-trol. The platform should provide extension hooks to insert customcoordination components that would then transparently interpose innormal calls to a collaborative component.

Finally, collaborative environments require awareness, which can bedefined as “an understanding of the activities of others, which providesa context for your own activity.” From our perspective, an awarenessplatform should facilitate data acquisition from the running environment.

Page 4: ANTS framework for cooperative work environments

events in the current context. The place object alsosupplies methods to get connected users and avail-able links to other places. In addition, it permitsdynamic loading of JavaBean components to theshared context.

The JavaBean component model provided inspira-tion for defining our coordination managers. In ourapproach, these special listener objects can approveor veto property changes on constrained properties.At this stage, we provide sample access-control andfloor-control coordinators. We also supply a central-ized token-based lock component that provides thebase for many floor-control coordinators.

AWS. Based on existing CSCW awareness systems,7

the server-side awareness infrastructure enables trig-gering of a set of actuators that perform special tasksin response to sensors. Sensors represent any physi-cal or software component that produces and trans-mits events to the notification system. The mediatorbinds a sensor with one or more actuators andlaunches actuators in response to events.

Event sensors activate in response to applicationevents that the information bus produces. AWScreates an event sensor by using a subscription thatfollows the constraint filter language available inthe notification system. The time scheduler acti-vates time sensors, which can be created for a spe-cific date or even set to trigger on repetitive dates.The time scheduler notifies the awareness servicewhen it activates a time sensor.

XML descriptors included in packaged compo-nents seamlessly integrate AWS with the compo-nent model. Every descriptor contains the eventsthat the component triggers to the bus. Because therepository stores this information during thedeployment phase, external monitoring applica-tions or AWS actuators can be aware of the infor-mation that every component in the platformproduces.

AWS provides the basis for sophisticated moni-toring applications, intelligent agents, and persis-tent actuators activated by events received from thenotification system. For example, we could createan event sensor subscription that says we are inter-ested in events produced by a user named Pedro.We could then make the sensor persistent with anactuator that would log each event Pedro initiatedin the environment. We could also create our ownbots, which would react to events that our sub-scription specifies.

Technology layerGiven that many CSCW systems rely on nondis-

tributed, single-threaded environments that limit their

applicability to more complex problems, wechose the Java 2 Enterprise Edition standardas our technology infrastructure. Using J2EEavoids the need to implement infrastructure-and system-specific code and lets us base ourwork on open specifications and components.Our system is thus vendor-independent:Developers can choose any J2EE-compliantapplication server or relational database.

Our framework’s message-oriented mid-dleware also needed a publish-subscribe noti-fication service. Java Message Service (JMS)offered the standard alternative, but the Elvinnotification service also offers good perfor-mance and has been used for CSCW purposes. Wetherefore implemented a façade API, COMM, thatlets us choose between any JMS-compliant mes-saging solution and Elvin.

We provide several sample bus aliases for devel-opers to connect to different middleware services.Depending on the specific requirements and theselected middleware, we can choose different trans-port layers such as raw multicast, reliable multicast,encrypted Secure Socket Layer streams, or orderedstreams. Nonexpert programmers can simply selectSSL as the bus alias and thus use an encrypted com-munication channel. Applications requiring scala-bility for many users could then select the RMCastalias.

IMPLEMENTATIONTo prove our concept’s viability, we have imple-

mented several projects using ANTS, including ashared whiteboard, multiuser games such as Pong,and a MOO text interface. The Multiuser-OrientedVirtual Environment (http://ants.etse.urv.es/move)and Innovative Technologies for CollaborativeLearning and Knowledge Building (www.euro-cscl.org/site/itcole) highlight the benefits of the key designdecisions that shaped the framework. These bene-fits include a component-based approach that sim-plifies development of collaborative artifacts andapplications, a monitoring service for creating event-analysis tools and agents that react to informationevents in the collaboration bus, and a system thatruns—transparently to users—atop advanced dis-tributed services that assure scalability and perfor-mance under high loads.

Move!Part of the Catalonian Internet2 project (www.

i2cat.net/), Move! is a three-dimensional collabo-rative virtual environment that lets user avatarsinteract with one another or with shared artifacts

March 2003 59

AWS provides the basis for sophisticated

monitoring applications,

intelligent agents,and persistent

actuators.

Page 5: ANTS framework for cooperative work environments

60 Computer

such as presenters or 3D simulations. As an edu-cational tool for use in medicine, archaeology, andother disciplines, Move! supports many users andpermits visualization and interaction with compu-tation-intensive 3D simulations. Built on open tech-nologies such as the Virtual Reality ModelingLanguage and the H-Anim humanoid specification,Move! demonstrates how well ANTS handles com-plexity and software architecture.

Application level. Every shared artifact in the

Move! environment is implemented as a frame-work component that must be packaged anddeployed for later use. As Figure 2 shows, depend-ing on their specific performance requirements,components can follow either a centralized orreplicated approach. The ANTS distributed model-view-controller pattern facilitates developing dif-ferent views for the same component. Move!includes both 3D and text-based views of theshared scenarios.

CSCW level. Framework components represent theshared artifacts, and coordination through tokensassures consistency in multiuser access to a sharedobject. As Figure 3 shows, AWS forms the basis forthe Move! agent infrastructure, while the bus pro-vides state-propagation and awareness functions.Developers can program bots that perform specialtasks and react to events in the environment. Forexample, when a user moves beside a guide bot, itshows the scene and interacts with the relevantartifacts. We are using more advanced agents per-vasively to test the environment under high loads.

Technological level. Our neutral approach to mid-dleware lets developers choose from among a widerange of application servers, database engines, andnotification services. In this case, we chose theOracle database, Orion application server, andElvin notification service, but we could easilyreplace any of these with competing products.Move! also illustrates the benefits of advanced mid-dleware features such as application server clus-tering, load balancing, and Elvin event perfor-mance. By moving the processing burden to theunderlying middleware, we can focus on imple-menting the CSCW framework services.

Performance issues. Tests using Move! reveal thatthe critical point as far as performance resides onthe client side, not in the ANTS platform or server-side middleware. Each user connected to the sys-tem requires small memory and processing-powerallocations. Further, the notification system canhandle massive event flows without degradation,thus achieving sufficient scalability under highloads. Although Move! scales up smoothly with200 users in a shared session, the Internet2 pro-ject-usage scenario provides better hardware andbandwidth resources that can sustain more users.

On the client side, the 3D visualization enginerequires large amounts of memory when it handlescomplex simulations or avatars. Moreover, thearrival of many events at the client creates prob-lems with transmitting to the visualization engine,which can lead to system degradation. To solve thisproblem, we implemented a distance-based algo-

Figure 2. Move! components. The relatively undemanding 2D and 3D presenters,voting tool, and bars tool (top) use a centralized property store. The computation-ally demanding avatar control (bottom) uses a replicated approach that directlyaccesses the collaboration bus for state propagation.

Page 6: ANTS framework for cooperative work environments

rithm that discards events located outside a speci-fied radius around each user. This strongly limitsunnecessary processing on the client side and letsthe system handle many concurrent users.

ItcoleAnother ongoing project, Itcole applies ANTS

services and concepts to create a seamless infra-structure for synchronous applications and moni-toring agents in a collaborative learning environ-ment. Itcole includes a knowledge constructiontool, synchronous components such as a sharedwhiteboard, and event analysis applications. Theuser can interact asynchronously with the envi-ronment through a Web client or collaborate syn-chronously through Java applets.

Figure 4 shows the Itcole architecture. Both syn-chronous and asynchronous applications send

events to the collaboration bus, enabling monitor-ing applications to listen to a unique informationstream and react in specific ways. Synchronouscomponents such as the map applet use the bus topropagate state changes. Monitoring applications,such as persistent log agents or tutor bots, can bedeveloped atop AWS to react to information pro-duced in the bus, providing a flexible scenario forstudying the running environment.

We foresee research in the application of machinelearning techniques across areas such as clusteringand the development of event analysis tools to studyinformation flows in the collaboration bus. The con-fluence of both synchronous and asynchronousevents can help researchers better understand thecollaboration process. This aspect plays an evenmore important role in the Itcole project, whichrequires analyzing collaborative learning scenarios.

March 2003 61

(d)

(a)

(c)

(b)

Persistentlog agent

Bus

Guidebot

CORE

Avatarbean

CORE

Avatarbean

AWS

Figure 3. Move! services. (a) Move! sends the user’s movements to the bus, which (b) transmits them to the otherclients in the shared context. The mediator monitoring service (c) listens to the bus and launches specified actuatorsin response to filtered events—in this case, (d) the mediator activates a guide bot that begins a chat interaction withthe specified user.

Persistentlog agent

BusGuidebot

CORE

Avatarbean

AWS

Webserver

Itcolekernel

Webclient

Figure 4. Itcole architecture. This ongoing project provides a seamless infrastructure for synchronous applicationsand monitoring agents to create a collaborative learning environment.

Page 7: ANTS framework for cooperative work environments

ANTS constitutes an ambitious applicationframework that simplifies development ofdistributed collaborative components in the

Java language. A major drawback of the currentplatform, however, is its Java-centered approach.Therefore, we are using XML-RPC and XMLstreams to create an XML system interface thatsupports other user interfaces and programminglanguages. Further, future support for Web servicesin application servers could facilitate system inter-operability.

The generic concepts we have described can eas-ily be mapped to other non-Java component mod-els. Consequently, we could replace JavaBeans withother client-side component models, using a non-Java middleware integration framework to replacethe J2EE application server. Ultimately, we foreseechallenging research work in advanced middle-ware services—constructed atop overlay net-works—as the basis for the next generation ofcollaborative systems. �

AcknowledgmentsThis project was partially funded by the Euro-

pean Project ITCOLE IST-2000-26249 and the

Generalitat de Catalunya Internet2 AdvancedTelecommunications project.

References1. P. Dourish, Open Implementation and Flexibility in

CSCW Toolkits, doctoral dissertation, Dept. Com-puter Science, University College London, London,1996.

2. M. Roseman and S. Greenberg, “Building Real-TimeGroupware with GroupKit, a Groupware Toolkit,”ACM Trans. Computer-Human Interaction, vol. 3,no. 1, 1996, pp. 66-106.

3. A. Chabert et al., “Java Object-Sharing in Habanero,”Comm. ACM, vol. 41, no. 6, 1998, pp. 69-76.

4. H. ter Hofte, Working Apart Together: Foundationsfor Component Groupware, Telematica InstituutFundamental Research Series, no. 001, TelematicaInstituut, Enschede, the Netherlands, 1998, p. 288.

5. I. Marsic, “DISCIPLE: A Framework for MultimodalCollaboration in Heterogeneous Environments,”ACM Comp. Surveys, vol. 31, no. 2es, 1999; http://portal.acm.org/citation.cfm?doid=323216.323225.

6. R.D. Hill et al., “The Rendezvous Architecture andLanguage for Constructing Multiuser Applications,”ACM Trans. Computer-Human Interaction, vol. 1,no. 2, 1994, pp. 81-125.

7. W. Prinz, “NESSIE: An Awareness Environment forCooperative Settings,” Proc. 6th European Conf.Computer Supported Cooperative Work (ECSCW99), Kluwer Academic, 1999, pp. 391-410.

Pedro García López is an assistant professor in theDepartment of Computer Engineering and Math-ematics at the University of Rovira i Virgili, Spain.His research focuses on distributed systems andmiddleware infrastructures for computer-supportedcollaborative work and learning. García receiveda PhD in computer engineering from the Univer-sity of Murcia, Spain. He is a member of the ACM.Contact him at [email protected].

Antonio F. Gómez Skarmeta is a professor in theDepartment of Computer Science, Artificial Intelli-gence, and Electronics at the University of Murcia.His research interests include fuzzy modeling, dis-tributed artificial intelligence, telelearning and com-puter-supported collaborative work, and telematicsservices in broadband networks. Skarmeta receiveda PhD in computer science from the University ofMurcia. He is a member of the IEEE ComputerSociety. Contact him at [email protected].

You are invited to attend the

IEEE Virtual Reality 2003 Conference (IEEE-VR2003)

MARCH 22-26, 2003

Biltmore Hotel

Los Angeles, California, USA http://www.vr2003.org

General Sessions: Papers, Panels, Posters

Commercial Exhibits & Research Demonstrations

Workshop on Commodity Clusters for VR

Half and Full Day Tutorials:

• Introduction To VR Technology

• Scalable VR Application Authoring

• Recent Methods For Image-Based Modeling

And Rendering

• Virtual Humans For Virtual Reality And

Augmented Reality

• Hollywood Meets Simulation: Creating

Immersive Training Environments At The

Institute for Creative Technologies Held in conjunction with the 11th Symposium on Haptic

Interfaces for Virtual Environment and Teleoperator

Systems (http://www.hapticssymposium.org)

Sponsored by

The IEEE Computer Society Technical Committee on

Visualization and Graphics

IEEE®