The FUSE Platform: Supporting Ubiquitous Collaboration Within Diverse Mobile Environments SHAHRAM IZADI* PEDRO COUTINHO* TOM RODDEN* GARETH SMITH** *Mixed Reality Laboratory, University of Nottingham, Nottingham, UK **Apama (UK) Limited, Cambridge, UK
[email protected] [email protected] [email protected] [email protected]
Abstract. The recent proliferation of heterogeneous computing devices and wireless network technology presents new opportunities for Computer Supported Cooperative Work (CSCW). One emergent paradigm is that of ubiquitous collaboration, which provides widespread access to shared services through a variety of interactive devices, irrespective of whether individuals are mobile or deskbound. However, developing groupware that is interoperable across diverse, often mobile, environments can be difficult and costly. The fundamental issue is that current support infrastructures, which will meet the requirements for multi-user application development, are not operable within emerging ubiquitous settings. This paper explores this problem and presents a generic platform that promotes new forms of collaboration through mobility and ever-present computing services. The developed platform seeks to provide a wide range of collaborative services to a very diverse set of devices by adapting and extending existing middleware technologies. Keywords: ubiquitous computing, mobility, heterogeneous devices, CSCW, collaboration, groupware, middleware
1. Introduction The notion of ubiquitous collaboration has gained considerable prominence in CSCW over the last few years. This paradigm provides members of a collaborating group with widespread access to shared services through a variety of interactive devices, irrespective of whether group members are mobile or deskbound. The emergence of mobile computing, the maturing of wireless networking and the rapid dissemination of heterogeneous computing devices have helped form this model of collaboration. The key motivation for ubiquitous collaboration is to allow continuity of cooperative work through pervasive access to personal and shared information, communication facilities, and groupware services. It is a view of collaborative work that has clear benefits for organisations that require individuals to work electronically away from the principal site but still maintain a collaborative link with other group members. Within such scenarios, one may envisage office applications that can be utilised from either the desktop or whilst on the move, with features for users to communicate, update documents and share new documents with each other; as well as, CAD applications that can provide both 2D and 3D views of a shared model, so that an expert may utilise a head mounted display to collaborate and assist a mobile fieldworker utilising a portable device. There are a number of clear challenges associated with ubiquitous collaboration [Weiser,93; Abowd,99]. Within ubiquitous environments, applications must support interaction across multiple input and output devices, and accommodate for communication between devices with potentially different protocols and data representations. Furthermore, the physical and computational setting in which applications are deployed can play an important role in shaping the interaction between users, and so users may often require additional feedback regarding the context of the collaborating group. Further challenges also arise when supporting mobile users and devices [Forman,94; Satyanarayanan,96]. Mobile applications will need to accommodate for handheld devices with limited power, memory and display size. Such devices may be connected to wireless networks, which can suffer from major bandwidth latencies, often leading to network disconnection. Applications must also support devices that routinely change their point of network connection, potentially resulting in a transition from one network infrastructure to another.
These challenges suggest that developing and deploying groupware applications across diverse mobile environments will be costly and difficult. Clearly, application writers require support infrastructures, such as platforms, toolkits and frameworks, to aid the development of ubiquitous groupware. However, current infrastructures, which will meet the requirements for multi-user application development, are not operable within emerging ubiquitous settings. It is our belief that groupware developers should be free to concentrate upon the semantics of the collaborative system rather than being tied down by issues arising from ubiquity. In this paper, we put this belief into practice by describing a flexible platform known as FUSE, which is capable of developing next generation, ubiquitous collaborative applications. The FUSE platform seeks to promote new forms of collaboration through mobility and ever-present computing services. More specifically, it comprises of a service-driven infrastructure capable of sharing, managing and communicating information among disparate groups of users and devices. In deriving our results, we argue for the use of dynamic middleware technologies, such as Jini [Jini,01a] and Universal Plug and Play (UPnP) [UPnP,01], with adaptations and extensions for collaboration and increased ubiquity. The FUSE platform provides access to devices that carry a diverse set of interaction and communication facilities, regardless of whether these devices are fixed or mobile. The need to handle such diverse deployment scenarios has resulted in an architecture that exploits the notion of community facilitators, which act as a bridge between novel interaction devices and services provided through existing middleware platforms. In addition to providing access to services, community facilitators allow users to permanently present themselves to others across the network, allowing full user participation within group work, even when on the move. 2. Related Work Our work owes much to Weiser’s pioneering vision for ubiquitous computing [Weiser,91] and subsequent experiments carried out at PARC [Want,95]. Weiser describes a proliferation of devices at varying scales, ranging in size from handheld “inch-scale” personal devices to “yard-scale” shared devices. It is a vision that has become increasingly more realistic through the emergence of commonly used devices such as Personal Digital Assistants (PDAs), digital tablets, laptops and wall-sized electronic whiteboards. Results from experiments carried out at PARC highlight the importance of developing dynamic applications that can adapt services based upon contextual information sensed from the environment [Shilit,94]. Recent work within the area of context-awareness has focused upon providing reusable representations of context [Salber,99a] and in creating more complex context from sensor fusion [Salber,99b], synthesis [Brown,00] and activity recognition [Abowd,99]. From a CSCW perspective, we are particularly interested in the sharing of contextual information between system users [Cheverst,00]. Systems such as GUIDE [Cheverst,99] and AROMA [Pedersen,97] have shown that this increased level of feedback and awareness can allow members of a group to collaborate more effectively within ubiquitous environments. The need to facilitate collaboration between diverse sets of devices was recognised early by [Engelbart,84], with trials of conferencing between dissimilar workstation terminals. More recently, the Pebbles Project [Myers,98] has exploited multiple PDAs to provide concurrent input to a single-display workstation. However, the system does not exploit the full potential of handheld devices, only utilising PDAs as portable input devices and choosing to render output onto a single large screen display. In contrast, SharedNotes [Greenberg,99] provides users with the ability to share and view information through both handheld and large screen displays. The system provides features for individuals to create personal notes on PDAs, publicise these notes by transferring them to a shared public display and manipulate personal and public items in real time through either device. Other novel work within this area has seen the use of small portable Inter-Personal Awareness Devices (IPADs) [Holmquist,99] to support social awareness between people situated within the same physical or virtual location. Systems such as Proem [Kortuem,99] utilise IPADs and wireless communications to provide members of a group with continuous aural and visual indications of other individuals that are within their proximity. Although these systems provide a valuable insight into collaboration across diverse and often mobile environments, they do not offer any support tools for application writers intending to exploit such models
of group work. Our survey of related work reveals an evident lack of support infrastructures that can provide effective multi-user development within emerging ubiquitous settings. One noteworthy exception has been the DISCIPLE project [Marsic,99], which provides a JavaBeans framework for real-time collaboration across heterogeneous environments. We recognise the importance of contemporary service-driven middleware platforms, such as Jini, CORBA and UPnP for developing ubiquitous groupware. Middleware presents a unified programming model and set of services to application writers, which can improve the process of developing, deploying and maintaining distributed systems. As the majority of groupware applications are distributed in nature, middleware offers a suitable foundation on top of which an appropriate collaborative platform may be developed. Furthermore, many middleware platforms offer some degree of support for heterogeneous devices and mobility. For example, Jini and UPnP utilise device independent languages (Java and XML respectively) so that a range of devices may be supported. They also provide discovery mechanisms for both mobile and stationary nodes to dynamically locate resources. However, there are a number of issues that should be addressed before utilising such platforms. Firstly, middleware platforms do not offer mechanisms to sufficiently tolerate intermittent connectivity and bandwidth latencies. Secondly, the minimal set of requirements for devices to become middleware enabled can be high, and as such, many devices remain unsupported by these platforms. With regards to this latter point, Jini’s Surrogate project [Jini,01b] attempts to reduce the requirements for devices to access middleware services. This approach works by directing communication between the device and the Jini community through a proxy. Devices issue an initial registration request, which specifies the desired protocol to utilise, and then transfer the surrogate to the proxy. The surrogate encapsulates a set of mappings from the device protocol onto Jini requests. The main issue regarding this approach is that devices must utilise the IP surrogate protocol to register with the proxy and transfer the surrogate over. As a result, existing devices will need appropriate surrogate extensions before they may utilise middleware services. As later described in section 5.1, we favour an approach that can provide devices with access to middleware services without any extensions or adaptations. As highlighted earlier, another issue regarding current middleware platforms is their lack of support for network disconnection and bandwidth latencies. Our survey of related work reveals a number of techniques for addressing these issues [Houston,98; Sutton,01]. Many mobile-aware systems provide mechanisms for computational and data migration between servers and clients, in response to current or predicted network limitations. During a fall in bandwidth, objects that have migrated to the server can perform computation on behalf of disconnected clients, returning results when network conditions improve. The Rover toolkit [Joseph,95] provides the further abstraction of Queued Remote Procedure Calls (QRPC). This allows clients to make non-blocking RPCs even when the client is disconnected. Requests are queued until reconnection, whereupon they are delivered to the server and the responses returned to the client. Although not designed for mobile environments, certain groupware toolkits such as GroupKit [Roseman,96] handle some degree of intermittent behaviour to meet the demands for asynchronous work patterns. They offer session management facilities for initiating a collaborative session, tracking that session and persistently storing the session for further use. These toolkits require that users explicitly request discontinuous operation. However, within wireless environments, intermittent behaviour is often forced upon the user, without participants actually leaving sessions. As such, the notion of session management supported by these toolkits must be extended to recognise scenarios when clients disconnect without warning. 3. General Overview The FUSE platform provides a further layer of abstraction above a middleware platform, which supports collaboration, mobility and device heterogeneity. This abstraction layer comprises of lightweight clients for users to access collaborative applications; community facilitators that allow mobile and fixed access to middleware services using a variety of interactive devices; and a set of groupware widgets for developing collaborative applications.
The platform provides users and developers with the following core features: Session management Services are provided for users and applications to create, modify, destroy, join and persistently store collaborative sessions. This basic abstraction promotes asynchronous, as well as, synchronous work patterns and allows sessions to migrate when users move location. Tolerance towards intermittent connectivity and network latencies Features are provided for tracking of requests made during a session, with storage of subsequent notifications for delivery to intermittently connected clients. Apart from session tracking, the platform provides the notion of migratable objects, which can dynamically relocate between clients and community facilitators during a fall in bandwidth. Features are also provided for clients to operate when suffering from loss of network connection, with local replication of application state and queuing of network requests, which are executed upon reconnection. Support for roaming of users and their devices within the physical environment A number of mechanisms are provided to allow devices to change their point of connection to the network and also allow users to transfer from one device to another. Automated resource discovery allows applications to be routinely notified of changes to resource availability. Universal session retrieval and delegated authentication of users can allow the transition between community facilitators to be transparent to users and application instances. Environmental awareness A variety of pre-packaged awareness widgets [Gutwin,96; Salber,99] are provided for gathering, distributing and presenting contextual information to application instances and their users. Each widget manages a discrete piece of contextual information, with the goal of helping individuals identify with other group members and coordinate their tasks together. The platform incorporates social information regarding the individuals within the collaborating group and their current activities; spatial information regarding the physical location of group members; resource information regarding accessible devices and computational services; as well as, information regarding environmental constraints, such as bandwidth limitations and loss of connectivity, imposed upon group members. Support for heterogeneous communication Another driving goal for the FUSE architecture is to limit the burden upon the device accessing middleware services, so that existing protocols and client applications, such as web browsers, may be utilised. The platform supports components known as protocol adaptors, which provide a mapping from commonly used protocols (such as HTTP) onto middleware commands. These adaptors can allow devices to become middleware enabled without any extensions or adaptations. 4. Platform Architecture The main aims of the FUSE architecture (figure 1) are to allow members of a group to collaborate irrespective of location, class of device or communication medium; and to provide a suitable development environment for producing ubiquitous groupware. The architecture achieves these aims by providing a clean separation between the middleware-enabled developer communities and the external user communities through the notion of community facilitators. This separation of concerns allows developers to exploit the full potential of middleware, whilst masking many complexities from users and their devices. The platform architecture comprises of a number of distinct components: Client devices These can include existing device applications, such as WAP [WAP,01] and Web browsers, with appropriate protocol connections to community facilitators. A generic FUSE client has also been developed, which comprises of a Communications Module for communication with other clients and facilitators, and a User Interface Handler for requesting and downloading service user interfaces from community facilitators. Community facilitators These act as gateways to mask complexities from networked devices, promoting access to collaborative applications through thin clients. Community facilitators provide a Point of Presence (PoP) [Dix,99] where devices can make themselves and associated users available
to cooperative applications. Users can exploit facilitators to permanently store data, receive information and collaborate. The specific services offered by community facilitators include session tracking and computational migration for intermittently connected clients; session forwarding for user and device roaming; protocol adaptation for heterogeneous communication; and user authentication.
Figure 1 The platform architecture
Middleware services These comprise of a generic set of components for distributed computing. The derived services extend the core functionality provided by the middleware platform. Programmers can directly exploit these services when developing both single and multi user applications. Community facilitators also access a subset of these components, and so, application instances will often indirectly utilise these middleware services. Standard components provided through the middleware platform include a discovery service for locating resources within the proximity of the user, and a lookup service for finding, activating and utilising other services. FUSE components include a connection service for queries regarding the connectivity of users, and a location service for deriving the physical location of users and certain devices. Groupware services These comprise of a set components for developing multi-user collaborative applications. Key components include a user activity service for providing members of a collaborating group with knowledge regarding the activities of other users; a history service for feedback regarding the actions previously performed by group members; and a notification service for attaching events to shared objects held within the system, which are triggered after the state of the object changes. 5. Community Facilitators: A Closer Look Community facilitators are modular in design (figure 2) and contain components that may be dynamically loaded at run time. Clients log onto the facilitator through an authentication module. Authentication is required just the one time, with clients that suffer a loss of connection during an active session being automatically logged back onto the facilitator when they regain network connectivity. The purpose-built FUSE client provides a number of mechanisms for authenticating users, including standard username and password, as well as, novel identification techniques such as fingertip recognition [Pankanti,00], iButtons [iButton,01] and RF Tag technology. After logon, clients are free to issue commands through the community facilitator. Initially, most clients will issue a command to locate a particular, user specified application. Upon receiving such a request, the facilitator will perform discovery and query lookup services. If the specified application is found, an application proxy will be downloaded and cached by the facilitator. The proxy will allow the client to indirectly invoke the remote application. The proxy also holds references to one or more service user
interfaces. Clients can download these user interfaces on demand, where they can be presented to the users. After a proxy has been downloaded, devices are free to issue requests to use the application. Clients are not restricted to one particular protocol. Standard protocol commands, such as HTTP or WebDAV [Whitehead,98], may be issued, which are adapted through the protocol adaptor to recognisable commands and then relayed onto the application proxy. Facilitators may also offer feedback to the devices during the execution of a request or once the request has completed.
Figure 2 The community facilitator architecture
Community facilitators serve two principal roles in supporting collaboration across disparate communities of users and applications: 1. As a monitor within direct client-to-client collaboration This model is usually adopted during synchronous collaboration, when clients wish to communicate directly with each other. Under these circumstances, facilitators merely monitor and store session data sent between clients. Typically, session monitoring is transparent to the clients, unless a client has suffered a period of disconnection and requires session updates from the community facilitator. 2. As a conduit for client-to-client collaboration This model is normally adopted in asynchronous collaboration. Under these circumstances, clients communicate through the community facilitator and the application proxy. Again, every request is tracked and stored by the facilitator’s session management module. Clients issue commands to the facilitator, which are translated and invoked upon the application proxy. This invocation will lead to any relevant communication events being forwarded to other group members. Each subnet or network cell may have any number of facilitators managing and providing access to its services. Facilitators can also form a larger federation that can span several networks and provide interoperability between different network infrastructures. Such federations can allow a user on one network type (such as Bluetooth [Bluetooth,01]) to collaborate with a user on another type (such as GSM). Because FUSE allows users to run multiple sessions simultaneously, users can have sessions that are spread across community facilitators and networks. This approach allows users to be connected to multiple networks concurrently. For example, a user may print through a facilitator on a Bluetooth network, whilst communicating with another participant through a facilitator connected to the wireless LAN.
5.1 Facilitator Protocol and Protocol Adaptation Community facilitators respond to a set of facilitator protocol commands. However, devices are not constrained to using this protocol. Facilitators allow the use of protocol adapters, which, given a mapping between a device protocol and the facilitator protocol, can translate requests to an acceptable form. When choosing a device protocol, one possibility is to adopt a standard protocol such as HTTP, WAP or WebDAV. The protocol adaptor can then map these protocol commands onto facilitator requests. For example, facilitators could interpret an HTTP GET request as a prompt to use a particular service. Adopting the use of standard protocols can remove the requirement for the purpose-built FUSE client. For example, the use of HTTP can provide users with access to applications through their existing web browsers. Each set of protocol mappings is encapsulated as a distinct reusable component that is stored in a centralised lookup service. When facilitators receive an unrecognised request, the details of the request are used to query this repository for an adapter that is capable of translating protocol requests. Using this model, once an adapter has been introduced into the FUSE community, it can quickly be shared between different community facilitators. 5.2 Intermittent Communication and Bandwidth Latencies A key requirement for ubiquitous collaborative applications is the ability to tolerate intermittent communication. This tolerance is important for two reasons. Firstly, wireless communications cannot always guarantee connectivity, with devices often becoming disconnected as they move out of range of a base station or when large obstacles block the signal path. Secondly, a significant proportion of collaborative activities in the real world occur asynchronously, with people’s schedules often governing that systems are used intermittently. Community facilitators provide a number of mechanisms to deal with both intermittent communication and bandwidth latencies. Session tracking is provided by persistently storing requests made by all clients. These requests can then be referred to when a client reconnects to the facilitator. Session tracking allows the client to be returned to a state that is similar to the one before disconnection. Calculation of disconnection time is based upon a login request only, as it is assumed that clients may be unable to issue a logout request before disconnecting. Requests made by clients are time-stamped and persistently stored. These can be discarded after a client defined Time To Live (TTL) period has passed. Facilitators assume a period of disconnection if a client is logged back in. The period of disconnection is either calculated client-side, and issued within the login request, or it can be calculated by the facilitator by comparing the new login time with the time of the last request. During a period of disconnection, clients may receive various messages, events and results. Therefore, all incoming information is cached. If the facilitator has observed a period of disconnection, then the cache is referred to and any valid information within the disconnection period is retransmitted (figure 3). Time-dependent events can be discarded by examining their TTL value. Clients can also set a priority value within the event, which allows facilitators to carry out simple event filtering for low bandwidth connections.
Figure 3 Event retransmission after disconnection
Session tracking is particularly important for mobile collaboration. Within these scenarios, when a user loses connectivity, the session will remain open and other group members may make potentially important changes to the shared application state. As a result, upon reconnection, the user will need to be provided with feedback regarding the actions performed by other group members during the disconnection period. This feedback is only possible if all requests made by members of collaborating group are logged by the system. Aside from session tracking, the FUSE platform provides the notion of migratable objects, which can dynamically relocate between the client and the community facilitator, during a fall in bandwidth. The main advantage of migratable objects is that they allow community facilitators to perform computation on behalf of intermittently connected, low resource devices. For example, when needing to minimise network activity, an object that checks for recent changes to a large, remotely stored, shared document, may migrate onto the facilitator, check for recent changes and return the results when bandwidth increases. In addition, migratable objects allow clients to replicate shared local data onto the community facilitators so that critical information is accessible to others, even when the client is disconnected. For example, shared files carried on the client can also be replicated on the facilitator, so that, when the client is disconnected or suffering from bandwidth latencies, other members of the group can access the replicated files. Another concern within mobile environments is sudden drops of connectivity from high levels to zero. For tolerating complete and sudden network disconnection, the FUSE client allows queuing of client requests. This paradigm allows clients to issue unicast or multicast requests, even when they are disconnected. Upon reconnection, queued requests are sent to the community facilitator, which in turn forwards the appropriate requests onto other clients. Queuing is supported through the FUSE client’s communication module. By default, all client requests are queued before they are transmitted, although finer grained control is provided so that application writers can explicitly specify the requests to queue. Upon reconnection, the FUSE platform uses an existing framework [Munson,97] to synchronise local data that has been queued with any centralised state. This framework defines conflicts and specifies conflict resolution dependent upon an application’s structure and semantics. 5.3 Device and User Roaming A goal for the FUSE platform is to allow users and their devices to roam freely throughout the physical environment. These styles of roaming are distinct. Device roaming occurs when a device changes its point of connection to the network, potentially resulting in a transition to another network infrastructure, whilst user roaming occurs when a user changes from one device to another. One concern regarding roaming is that applications may exploit resources within their local domain, for example, printers and network file spaces, which may be unavailable if the device or user changes location. In response to this concern, the FUSE client provides features to automatically update resource information based upon location. In addition, the client can automatically monitor resources, so that feedback may be provided to users regarding the availability of particular resources. Within certain deployment scenarios, changing the network location of an active device may result in the requirement to connect to a new community facilitator. To achieve this transition, during a session each client receives a unique identifier, which contains a global address for the current facilitator. This identifier is integrated into all subsequent client requests. Upon connection to a new facilitator, clients issue requests as normal, without first needing to register or provide authentication. Instead, the new facilitator extracts any unrecognised session identifiers from the request and relays these, with a forwarding address, to the previous facilitator. This allows facilitators to delegate commands on behalf of each other and share existing session state such as cached application proxies and outstanding events. 5.4 User Interaction The FUSE platform provides a separation between the underlying semantics of a service and its associated graphical representation or view. This allows multiple user interfaces, perhaps specialised for different classes of devices, to be associated with a given service. Within FUSE, user interfaces can belong to one or more of the following categories: A control user interface allows users to provide input to the service; a
presentation user interface represents the graphical output from the service; and an administrator user interface provides management and configuration displays for the service. Although not strictly enforced, this separation between different user interface types can provide for some novel forms of interaction across multiple input and output devices. For example, a PDA can download a control interface to provide input to a shared drawing service, and specify a large screen display to present the outputs of the service. Client applications that carry appropriate access privileges can download any suitable user interface associated with a service. For example, a WAP browser may request a WML based user interface, whilst a 3D client may request a VRML representation. The main advantage of this approach is that it allows service user interfaces to fit more closely with the requirements of the client device. However, there is an issue in that service writers must create separate user interfaces for each class of device they wish to support. To address this issue, service writers could use a device-independent user interface language, such as XWeb [Olsen,00] or UIML [Abrams,01], to automatically generate native user interfaces from a single abstract representation. We are not currently focusing on developing such representations ourselves, but rather on the infrastructure that is capable of delivering such representations to clients. 6. Platform in Use This section illustrates some of the deployment scenarios promoted by the FUSE platform. It considers the development of a simple heterogeneous instant messaging/chat application, which allows groups of users to communicate and share ideas using a variety of interactive devices. To fully demonstrate the notion of ubiquitous collaboration, a number of differing usage scenarios are derived (figure 4). Asynchronous behaviour is illustrated through WAP phones that run on low bandwidth GSM connections (currently 9k in the UK). Synchronous behaviour is provided through PDA devices over wireless LAN and desktop computers utilising fast Ethernet and multicasting capabilities. Both PDA devices and desktop computers will be capable of incorporating the purpose-built FUSE client. As a result, such devices can exploit the communication module’s multicast discovery facility to locate neighbouring resources and community facilitators. Upon discovery, users will be prompted to register (if required) and log on to a new or existing facilitator session. A new session will result in community facilitators querying the lookup service and presenting the resulting list of applications to the users. Users are then free to select particular applications or search the lookup service further. Client can tap into the main semantics of the chat application by downloading an associated user interface.
Figure 4 Usage scenario for chat application
The FUSE client utilised by PDA and desktop devices removes the need for protocol adaptation, as the communication module will be capable of issuing facilitator protocol commands directly. However, WAP phones will not be capable of running such a client. Consequently, these devices will require protocol adaptation of WAP requests and will provide facilitator discovery based upon standard Universal Resource Identifiers (URIs). Protocol adaptation is simplified by incorporating a WAP gateway, which
interprets WAP commands to standard HTTP commands. The inclusion of a WAP gateway allows for wide-range support of Internet devices though a single HTTP protocol adaptor (figure 6). Subsequently, the key issue of adaptation focuses upon deriving appropriate mappings between HTTP and facilitator protocol commands. As the majority of protocol requests received by the adaptor will be HTTP GET requests, the nature of these GET requests is used to determine the adaptation, with different URI requests identifying different mappings.
Figure 5 WAP and HTTP Protocol Adaptation
The chat application incorporates two generic groupware services – awareness and history. Both these services are linked to data that resides at the community facilitator. Facilitator data will comprise information about registered users, their network status, the devices that they exploit and any existing session information. The awareness service will utilise the facilitator data to represent user activities, their current connection status and the device they are currently using. The history service will build upon facilitator data to provide backlogs of group activities and system events. When these services are coupled with the session management features of the platform, users can recover from disconnection by automatically rejoining a persistently stored session and receiving feedback regarding the collaborative activities that had been performed during the disconnection period. Applications access both awareness and history information through a service filter, exploiting the information specific to the application rather than the entire distributed community. In the overall scenario, the opposing models of cooperative work and differing locations of application data prompts requirements for synchronisation and consistency management. More specifically, mechanisms are needed to promote effective communication between disparate groups of multicast and unicast devices and provide consistency between the centralised and replicated application data. The community facilitator promotes communication between multicast groups and other unicast clients. The facilitator is part of the multicast group and has connections to unicast devices. As a result, the facilitator can adapt and relay information between these disparate groups. Data consistency between localised and centralised data is also provided through the facilitator. The facilitator monitors multicast updates, with changes to replicated data resulting in an event notifying the centralised application of changes in localised state. Similarly, when the facilitator receives unicast requests to change centralised data, it triggers a distributed event notifying the multicast group of changes to centralised state. Any conflicts between the centralised and replicated data can be resolved using the framework identified in section 5.2. 7. Implementation The current version of the FUSE platform has adopted Jini as its middleware technology. Jini promotes the development of service-driven applications, without the constraints of a particular network model. These applications are composed of services that can either be accessed remotely through Remote Method Invocation (RMI) or downloaded and executed locally. The main rationale for exploiting Jini is that it provides a separation of interface and implementation, which raises the level of abstraction for distributed
systems programming. For the application developer, the use of “well-known” interfaces and high-level method invocation removes the requirement for understanding low-level protocols and device drivers to interact with networked devices. Additionally, Jini recognises the importance of dynamic reconfiguration of a distributed community. With features such as leasing, distributed communities can be self-healing, recovering from partial failures, and thus, requiring little administration and maintenance. Jini also provides features such as asynchronous notification and persistence, via distributed events and object serialization respectively, which are beneficial when developing groupware features such as user awareness and session tracking at the application level. Community facilitators are implemented using Java servlet technology. Servlets facilitate the execution of server-side Java code and can be embedded behind any appropriate Web server. Servlets are versatile in the protocols they can support and can be extended to support new protocols, including the facilitator protocol. This ability to handle a variety of protocols makes servlets an attractive candidate for the facilitator implementation, however this is not the sole rationale for choosing servlets. Servlets offer several other advantages. Firstly, Jini is itself a Java technology, resulting in servlets having the ability to directly perform Jini requests. Servlets also have the ability for dynamically loading and accessing object classes during execution. This is consistent with our modular design of community facilitators, with the result that each facilitator module can be implemented by a set of Java classes. 7.1 Initial Results We have developed a set of initial test applications on the FUSE platform to exercise a number of deployment scenarios and collaborative models. Our first demonstrator focuses on supporting the ad hoc styles of collaboration that can occur within meetings and presentations. Rather than developing a single application, we have developed a set of independent services that users can themselves configure and assemble together through a generic service browser. A FileSharing service allows documents stored locally on a device to be shared over the network. A DocumentTransfer service allows users to transfer documents from any reachable filesystem (for example, on their current device or from their home location) to other users. A SlideshowViewer service accepts presentations (currently as PowerPoint slides or WebPages) over a network connection, which are in turn rendered upon a specified output device and controlled remotely by the sender. With this small set of services, a number of collaborative scenarios are possible. Relevant documents, such as minutes of a meeting, project deliverables, business cards and meeting entries can be transferred between participants at the meeting, even if the documents are on a remote machine. Because the FUSE platform inherently supports session tracking, this scenario is extended to users that are currently offline, allowing all members of a group to receive relevant documents even if they are not present at the meeting. The session management features of FUSE are also valuable during unscheduled meetings that may occur in places such as corridors. Often in these scenarios, participants may wish to playback or update certain aspects of the session after the event has occurred, for example, if they have forgotten to give other participants an important document. FUSE’s session management facilities support this form of usage, with users being able to replay and update sessions including associated artefacts, such as documents. A more complex usage of the services described is one where a user arrives to give a presentation with only a handheld device. Under these circumstances, the user can browse their home FileSharing service and find the file containing the desired presentation. This is then copied over to the SlideshowViewer component, typically running on a PC connected to a projector within the meeting room. To start the presentation, the user requests the control user interface of the SlideshowViewer service. This allows the user to control the presentation that is ongoing on the PC using only their PDA. Our second demonstrator focuses on implementing the chat/instant messaging application described in section 6. We wish to extend the ideas behind such systems to integrate generic features of the FUSE platform including additional feedback and awareness, support for disconnection and the ability to transfer sessions when moving between devices.
Figure 6 shows the main user interfaces for the messaging application. The main component of this UI is a list showing all other members of the group. An icon by each entry within the list indicates an incoming message from a particular participant. Each user can view or send messages by double-clicking specific entries within the list. The list also provides an at-a-glance view of the status of other users. This information is mainly drawn from the generic awareness widgets provided by FUSE. The system provides connection awareness indicating whether users are connected, disconnected or reconnecting to the system, as well as, device awareness signifying the device other system participants are currently interacting through. These forms of awareness were complimented with more standard awareness mechanisms such as availability awareness, allowing the identification of the presence of users within the system and their willingness to participate within group activities.
Figure 6 The instant messaging application as shown on Desktop (left) and Palm (right) devices
When the user requests the chat application, a new session is started on the community facilitator. Once initiated, the session is registered as a service with the community facilitator’s lookup service. This allows other participants to search for the session and request to join. In our demonstrator, control of whether other members may join the session is delegated to the user that instigated the session. This allows users to control whether to invite new participants and accept requests to join the session. Once the session has been created the user is free to move to another device or network. After authentication, the instant messaging session may be resumed. Any new messages or relevant notifications that occurred during the transition are then downloaded to the device. This same event delivery mechanism is used when clients suffer a period of disconnection due to lack of network coverage. We have also developed a range of applications that provide collaboration between mobile handheld devices, and 3D workstations or head-mounted displays. These applications can be used in scenarios when just-in-time assistance is required between control-room personal and field operatives. To allow this model of collaboration, we have developed a wrapper service that provides a general-purpose bridge between FUSE and the MASSIVE-3 system [Greenhalgh,00]. MASSIVE-3 is a Collaborative Virtual Environment (CVE) that provides its own data distribution facilities to construct and maintain shared 3D audio-graphical virtual worlds. Our wrapper service provides several high-level method calls to create and animate 3D virtual objects in MASSIVE-3 worlds. Utilising a Global Positioning System (GPS) unit and a mobile device with wireless connectivity (such as an Compaq iPaq or laptop), it is possible for outdoor users to have an avatar (virtual body) within the virtual world and interact with other entities within their proximity. The GPS data is sent via a wireless link over to a community facilitator. The facilitator uses an adaptor to parse the raw output from the GPS unit and map any location updates onto the relevant method within the MASSIVE-3 service proxy.
Figure 7 Supporting collaboration between mobile field operatives and control-room personal
7.2 Initial Reflections Our initial demonstrators provide a number of insights into developing ubiquitous groupware under the FUSE platform. Results from our first demonstrator suggests that in certain circumstances it is sufficient to provide users with the necessary tools to build up applications ‘on the fly’, rather than developing custom-built systems beforehand. Given the heterogeneity and ad hoc nature of ubiquitous environments, it is often impractical to expect application writers to keep pace with the evolution of these environments and with the emergent requirements of users. Instead, by providing users with the necessary mechanisms to select, configure and combine services, fairly complex usage scenarios can be formed, which can often provide a closer match to the user’s task. This suggests that it is often important to keep users ‘in the loop’ when selecting and assembling available services, rather than fully automating this process. This does not however imply that delegating the ‘decision making’ from users to the system cannot add significant value to certain aspects of the system. For example, when developing the session management features of FUSE, we found that users could accumulate a large number of sessions over a very short period of time. It would clearly be disruptive to keep prompting users to create and maintain these sessions manually. Instead, we found that by exploiting contextual information, in particular detecting when a user changes device or network, we could partially automate this process and provide users with more fluid interaction with the system. Findings from our second demonstrator revealed that new forms of awareness are essential for collaboration within mobile ubiquitous environments. In particular, we found that the provision of information regarding each participant’s connectivity and current device could help prevent users from making possibly false assumptions regarding the state of the collaborating group. We also discovered that providing feedback regarding the location of users could be excessive, with users often only requiring information regarding the availability of other group members and their willingness to collaborate. This suggests that for certain ubiquitous groupware applications activity sensors, such as workstation monitors or pressure pads, can be as sufficient as positioning systems, such as GPS. The demonstrators also allowed us to study the effects of disconnection upon the collaborative process. Understandably, we found very different results when comparing real-time, visually intensive applications, such as a shared drawing tool or CVE, with asynchronous applications, such as an instant messenger. We found that the queuing mechanisms provided by the platform were most effective when utilising asynchronous applications. During a period of disconnection, the user would try and continue their task to reach a certain point of completion, even if this would result in the queuing of certain requests. For example, if disconnection occurred whilst users were partially through writing a message, they would typically continue writing the message and send it as normal, realising that it would only reach other parties once connection had been regained. In contrast, when connectivity was lost during a real-
time session, users would almost immediately stop and wait for reconnection. Upon reconnection, the user would often step-through the previous activities within the session. Due to the high rate of events produced by real-time systems, it was critical to determine how these backlogs of events would be presented to the user. We found that textual representations were not sufficient, but rather, users needed options so that they could view the exact output of these events, in a similar way to playing back a video clip. In order for users to quickly get up-to-date with the session, this playback facility needed to be complimented with options for easily skipping-through and locating parts of the session that were of interest. We found that the FUSE platform significantly reduced the development effort and time to produce ubiquitous groupware systems. The model-view separation encouraged by the platform allowed the bulk of application semantics to be coded using a unified and familiar programming language. As such, the main development effort could be focused upon a single application source, instead of having to produce numerous, disparate device applications. The generic groupware services provided by the platform were also easily integrated into new application types, with our instant messaging application being primarily composed of subclasses of the generic system history, user communication and awareness services. New services, potentially built around existing systems such as CVEs, could also be easily integrated within the system. Apart from extensibility, the service-driven paradigm associated with the platform allowed runtime assemblage of services to fit particular usage contexts. The inclusion of community facilitators within the architecture allowed our applications to inherently benefit from features such as session tracking, authentication, and user and session management, without having to produce any application-specific code. The ability for facilitators to translate an extensive set of protocols also allowed many device types to exploit services, irrespective of whether they carried a FUSEenabled client. Finally, the session management features, coupled with system history and awareness services, enabled users to recover from disconnection by automatically rejoining a persistently stored session and receiving feedback regarding the collaborative activities that had been performed during the disconnection period. 8. Conclusions And Future Work This paper has presented a platform that attempts to address the wide-ranging problems involved in supporting collaborative applications across heterogeneous, ubiquitous and mobile environments. We have also shown the shortcomings of middleware systems, which we have embraced within our architecture. In the near term, our work has two main goals. Firstly, we feel that the current subnet-wide discovery mechanisms can be limiting for applications and their users. Therefore, we plan to investigate mechanisms to provide more fine-grained service discovery using positioning techniques such as ultrasound [Randell,01]. Secondly, we are investigating how to provide better representations of devices and users within our infrastructure. In particular, we are looking at refining the generic interfaces associated with both these entities to fit closely with the requirements drawn from our initial demonstrators. References [Abowd,99] Abowd, G.D. and Mynatt, E.D. 1999. Charting Past, Present and Future Research in Ubiquitous Computing. ACM Transactions on Computer-Human Interaction, Vol. 7, No. 1, pp. 29-58. [Abrams,01] Abrams, M., Phanouriou, C., Batongbacal, A.L., Williams, S.M., Shuster, J.E. 2001. UIML: An Appliance Independent XML User Interface Language. http://www.uiml.org/specs/uiml2/index.htm. [Bluetooth,01] Bluetooth Consortium. 2001. Specification of the Bluetooth System, version 1.1 core. http://www.bluetooth.com. [Brown,00] Brown, P.J. and Jones, G.J.F. 2000. Context-Aware Retrieval: Exploring a New Environment for Information Retrieval and Information Filtering. Personal Technologies, Springer-Verlag. [Cheverst,99] Cheverst, K., Davies, N., Mitchell K., and Friday, A. 1999. The Role of Connectivity in Supporting ContextSensitive Applications. in Handheld and Ubiquitous Computing, Lecture Notes in Computer Science No. 1707. Springer-Verlag, pp. 193-207. [Cheverst,00] Cheverst, K., Mitchell, K. and Smith, G. 2000. Exploiting Context to Support Social Awareness and Social Navigation. Workshop on Mobile CSCW, ACM Publications. [Dix,99] Dix, A., Ramduny, D., Rodden, T., Davies, N. 1999. Places to stay on the move - software architectures for mobile user interfaces. in Second Workshop on Human Computer Interaction with Mobile Devices, Edinburgh, Scotland.
[Engelbart,84] Engelbart, D. 1984. Authorship provisions in AUGMENT. IEEE Computer. [Forman,94] Forman, G.H. and Zahorjan, J. 1994. The Challenges of Mobile Computing. IEEE Computer, Vol. 27, No. 6. [Greenberg,99] Greenberg, S., Boyle, M. and LaBerge, J. 1999. PDAs and Shared Public Displays: Making Personal Information Public, and Public Information Personal. Personal Technologies, Vol.3, No.1, 54-64, Springer-Verlag. [Greenhalgh,00] Greenhalgh, C., Purbrick J., Snowdon, D. 2000. Inside MASSIVE-3: Flexible Support for Data Consistency and World Structuring. Proc. of ACM Conference on Collaborative Virtual Environments (CVE2000), USA, 119-127. [Gutwin,96] Gutwin, C., S. Greenberg and M. Roseman. 1996. A Usability Study of Awareness Widgets in a Shared Workspace Groupware System. In Computer-Supported Cooperative Work, pages 258-267, ACM Publications. [Holmquist,99] Holmquist, L.E., Falk, J. and Wigström, J. 1999. Supporting Group Awareness with Inter-Personal Awareness Devices. Personal Technologies, Special Issue on Handheld CSCW, Springer Verlag. [Houston,98] Houston, P. 1998. Building Distributed Applications with Message Queuing Middleware. Microsoft Corporation. [iButton,01] Dallas Semiconductor. 2001. iButton Home Page. http://www.ibutton.com/. [Jini,01a] Sun Microsystems Inc. 2001. Jini Architectural Overview. Technical White Paper, http://www.sun.com/jini/whitepapers/architecture.html. [Jini,01b] Sun Microsystems Inc. 2001. The Jini Surrogate Project, http://developer.jini.org/exchange/projects/surrogate/. [Joseph,95] Joseph, A.D., DeLespinasse, A.F., Tauber, J.A., Gifford, D.K. and Kaashoek, M. F. 1995. Rover: A Toolkit for Mobile Information Access. Symposium on Operating Systems Principles (SOSP). [Kortuem,99] Kortuem, G., Segall, Z., Thompson, G.C. 1999. Close Encounters: Supporting Mobile Collaboration through Interchange of User Profiles. In Proceedings of the First International Symposium on Handheld and Ubiquitous Computing (HUC 99), Germany. pp. 171-185. [Marsic,99] Marsic, I. 1999. DISCIPLE: A Framework for Multimodal Collaboration in Heterogeneous Environments. ACM Computing Surveys, Vol.31, No.2es. [Munson,97] Munson P. and Dewan, P. 1997. Sync: A Java Framework for Mobile Collaborative Applications. IEEE Computer, Vol.30, No.6, pp. 59-66. [Myers,98] Myers, B.A., Stiel, H., and Gargiulo, R. 1998. Collaboration Using Multiple PDAs Connected to a PC. Proceedings CSCW'98: ACM Conference on Computer-Supported Cooperative Work, Seattle, WA USA, pp. 285-294. [Olsen,00] Olsen, D., Jefferies, S., Nielsen, T., Moyes, W., and Fredrickson, P. 2000. Cross-modal Interaction using Xweb. in Proceedings UIST'00: ACM SIGGRAPH Symposium on User Interface Software and Technology, San Diego, CA, pp. 191-200. [Pankanti,00] Pankanti, S., Bolle, R.M. and Jain, A. 2000. Biometrics: The Future of Identification. IEEE Computer, Vol. 33, No. 2, pp. 46-80. [Pedersen,97] Pedersen E.R. and Sokoler, T. 1997. AROMA: Abstract Representation of Presence Supporting Mutual Awareness. ACM Symposium of Computer Human Interaction 1997 (CHI’97), Atlanta, GA USA, pp. 51-58. [Randell,01] Randell, C. and Muller, H. 2001. A Low Cost Indoor Positioning System. ACM Symposium of Ubiquitous Computing 2001 (Ubicomp’01), Atlanta, GA USA, To be published. [Roseman,96] Roseman, M. and Greenberg, S. 1996. Building Real-Time Groupware with GroupKit, A Groupware Toolkit. ACM Transactions on Computer-Human Interaction, Vol.3, No.1, pp. 66-106. [Salber,99a] Salber, D., Dey, A.K. and Abowd, G.D. 1999. The Context Toolkit: Aiding the Development of Context-enabled Applications. International Conference on Human Factors in Computing Systems (CHI’99), Pittsburgh, PA USA, pp. 434-441. [Salber,99b] Salber, D., Dey, A., Orr, R., and Abowd, G. 1999. Designing for Ubiquitous Computing: A Case Study on Context Sensing. Graphics. Visualization, and Usability Center Technical Report 99-29, Georgia Tech. Available at http://www.cc.gatech.edu/gvu/reports/1999/abstracts/99 -29.html
[Satyanarayanan,96] Satyanarayanan, M. 1996. Fundamental Challenges in Mobile Computing. In Fifteenth ACM Symposium on Principles of Distributed Computing, Philadelphia, PA USA. [Shilit,94] Schilit, B.N., Adams, N. and Want, R. 1994. Context-aware Computing Applications. IEEE Special Issue on Mobile Computing Systems and Applications. [Sutton,01] Sutton, P., Arkins, R. and Segall, B. 2001. Supporting Disconnectedness - Transparent Information Delivery for Mobile and Invisible Computing. CCGrid 2001 IEEE International Symposium on Cluster Computing and the Grid, Australia. [UPnP,01] Universal Plug and Play Forum. 2001. Universal Plug and Play. http://www.upnp.org/. [Want,95] Want, R., Schilit, B.N., Adams, N.I., Gold, R., Petersen, K., Goldberg, D., Ellis, J.R. and Weiser, M. 1995. An Overview of the ParcTab Ubiquitous Computing Experiment. IEEE Personal Communications Magazine, Vol. 2, No.6, pp. 28-43. [WAP,01] WAP Forum. 2001. Wireless Application Protocol. http://www.wapforum.org. [Weiser,91] Weiser, M. 1991. The Computer of the 21st Century. Scientific American, Vol. 265, No. 3, pp. 66-75. [Weiser,93] Weiser, M. 1993. Some Computer Science Issues in Ubiquitous Computing. Communications of ACM, Vol. 36, No. 7, pp. 74-83. [Whitehead,98] Whitehead E. and Wiggins, M. 1998. WebDAV: IETF Standard for Collaborative Authoring on the Web. IEEE Internet Computing: Software Engineering over the Internet, Vol.2, No.5, pp. 34-40.
