The main problem is that they are specifically for monitoring. Web information, and do not support monitoring of other information sources, such as X.500. If there ...
A SYSTEM ARCHITECTURE FOR SUPPORTING EVENT BASED INTERACTION AND INFORMATION ACCESS ✝ *Richard Drew, David Morris, Peter Dew and Christine Leigh School of Computer Studies University of Leeds Leeds, England ✝ School of Geography University of Leeds Leeds, England
ABSTRACT The University of Leeds Virtual Science Park © (VSP) is an example of a virtual working system for supporting the provision of a number of services, including virtual consultancy, workbased learning, consortium building and access to information. This paper presents a new architecture based on event mechanisms. The extensions fall into 3 areas: provision of timely, up-to-date information based on users' interests; integration with existing information sources; and chance interaction. The main problems addressed are facilities for keeping the VSP information up to date and keeping users notified of relevant changes to the data. Integration with existing data sources is also key to the provision of an information space capable of supporting VSP services. We describe an event mechanism to support information location, information monitoring, chance interaction and integration with existing information sources. The system will be used in a VSP Workbased learning project for supplying multimedia information and collaboration facilities to remote students to support distance learning. A World Wide Web gateway has also been developed to provide wide scale access to the VSP. Keywords: Information location, information monitoring, agents, virtual working systems, integrating data sources, chance interaction, world wide web gateway
1. INTRODUCTION Networked multimedia information systems have the potential to transform the way people work provided that information resources can be discovered and retrieved efficiently. The current Leeds Virtual Science Park© provides an environment that supports the discovery of services and academic expertise using a ‘yellow pages’ directory service. It also allows communication with other users via standard conferencing tools such as videophones and shared whiteboards. This system is currently being used for pilot projects in Work Based Learning, Virtual Consultancy, and University Research Support. This paper reports on the underlying system architecture for the next generation of Virtual Science Park systems, and reports on current developments. These enhancements are designed to extend the existing system to include: automatic monitoring of the information in the VSP for changes in content and structure, support for chance interaction with other users with similar interests, and integration of disparate information sources into the VSP directory. Specifically, the main requirements for the next generation of the system architecture for the VSP are: Automatic Monitoring of VSP information. A major user requirement is to be able to keep up to date with changes to previously discovered information. At present, information sources must periodically be polled by the user to determine if there has been a change in the state of the information (modified, moved, deleted, etc.). This paper describes an agent based mechanism for automating these queries and reporting the changes. Support For Chance Interaction. A major problem with distributed virtual environments is that they do not give the user an awareness of the interests or presence of other users. Such awareness is essential if the environment is to allow people to make informal contact in the same way that they would in the a common area such as a coffee bar. We propose an awareness mechanism based on a ‘yellow pages’ directory service, a real time location broker, and a monitoring agent that initiates communication between users with similar interests. Integration of Disparate Information Sources. The VSP directory needs to reference or incorporate existing information stored online. We describe a mechanism by which information sources such as the World Wide Web can be integrated into the VSP object store in order to allow seamless access and searching using the VSP tools. This paper describes an architecture that addresses these issues.
2. REQUIREMENTS This section will give an overview of the major components of a system architecture that addresses the requirements in Section 1. In addition we give references to related work.
2.1 A persistent object store containing an enterprise model An underlying persistent object store is required to act as a repository for enterprise information, and the information needed to create, maintain and activate conferencing applications. The object store consists of an information model (schema) which describes the available entities (objects) and relations (links) in the object store. We use Entity Relationship (E-R) models because they have the expressive power to model real organisations, user interests and the communication paths between the members of virtual organisations. Our architecture includes an easily extensible schema which is capable of being implemented on top of existing distributed directory services such as X5001, OSF DCE or CORBA. A major component of our information model is a ‘yellow pages’ directory containing an explicit model of user expertise, services and interests. A novel feature of this system is that it provides explicit support for hierarchical subject descriptions of user interests in areas such as skills, services and subject based online information resources. This feature allows monitoring agents to work at a very high level. In particular, registration of interest in services allows trading relationships to be established and monitored via queries of the type ‘Who is interested in service X’ and ‘who provides service X’. The Intermezzo system 2, provides a basic object store that is used for sharing information for use in collaborations; and Nexor’s EIS system 3 provides an enterprise modelling framework for supporting CSCW based around an object oriented data store.
2.2 A resource monitoring system With the growing increase in the use of the World Wide Web, it has become apparent that monitoring information for changes is a key requirement. However, manually monitoring Web pages is a time and resource hungry process. A number of systems are available that aim to address this 4,5. The main problem is that they are specifically for monitoring Web information, and do not support monitoring of other information sources, such as X.500. If there is a change to a
monitored document, there are limits as to what can be done - usually the changed documents are added to a list which the user then has to browse. It is proposed that a resource monitoring system is used with three components: an automatic mechanism for checking for changes to resources; an event system for notifying the user that the resource has changed, and an action interpreter that allows actions to be triggered when events occur. Section 3 describes these in more detail. This mechanism also allows a user to express an interest in particular services, skills or information sources.
2.3 A real time user location, awareness, and communication system There are many examples of computer-based communication tools that can be used between networked users. However, due to the number of different tools, the differing types of networks, and the location of the recipients, there is no guarantee that users can communicate synchronously at any given time. Users are not however always at the same machine, and a distributed location broker service that tells you where a person is rather than where they were or ‘normally are’ is extremely useful6. In addition, unplanned or chance meetings are an important part of group working in a traditional working environment. When users are working in distributed groups or ‘virtual offices’, these meetings are lost. Simulating these chance interactions has been the focus of a number of projects 7,8,9,10. Many groups have used videoconferencing technology to provide video and audio communications between remote users11,12,13,14. These systems however are relatively bandwidth intensive, and are difficult to scale. There are a number of other very low bandwidth awareness mechanisms 15,10. In the VSP system, chance interaction is made possible by using the interests of particular users, a location broker and a real-time communication system. We define chance interaction as “Communication which automatically occurs due to the proximity of other users with interests in similar information”. In other words, an awareness of other users' interests can allow people to simulate the act of ‘bumping into people’ in an information space. For instance, a service provider could use this mechanism to email or use a videophone to talk to people who are interested in the service they are providing.
2.4 A set of integration tools to access existing information sources The requirement for integration of information is a strong one, as no single information source can provide all of the information required. However, integrating information from diverse sources can be difficult due to the differing nature of the information. The system incorporates a set of information adapters which allow access to information stored on the World Wide Web, Usenet News, and the X500 directory service. These adapters allow transparent searching, browsing and event monitoring to occur.
3. SYSTEM ARCHITECTURE The system architecture that will support the requirements listed above as a means for storing information is described below. This work builds on the University of Leeds Virtual Science Park (VSP) project16 which used a persistent distributed object store (VSPOS). In summary, the requirements discussed above suggest the need for: 1. 2. 3. 4.
5.
a persistent distributed object store (VSPOS) which is discussed in the earlier paper 16; an event model and interface mechanism. The interface provides a means for requesting updates to the VSPOS, and for generating events on state transitions in the VSPOS. This is discussed in more detail in section 3.1; information adapters which provide an interface between the VSPOS and external information sources. Adapters are described in more detail in section 3.4; clients that allow users to interact with the information in the VSPOS. These include browsing and navigation clients allowing information to be viewed and editing clients allow information to be created, modified or deleted. Conference clients allow communication to be initiated, and an information model which allows explicit description of user interests.
Figure 1 gives a high-level overview of the system architecture, which will be described in the following sections.
Object Store
Information Adaptor Event Interface
search results
search request
Search Interface search results search request
External Information Source
Update Events
Event Distribution Activity/Update Events
Event Interface Client Application
Figure 1 - High-level system architecture
3.1 Event Model The usefulness of an information service depends largely on the timeliness of the information. When there are many different sources of information, keeping information up-to-date and finding new relevant information becomes a problem. To aid the user in locating and monitoring information, there needs to be a mechanism for distributing state changes from information sources, (e.g. when new information becomes available, is modified or deleted). The proposed means for supplying information about these state changes is by using events. An event is defined to be a change in state of some resource, or a notification of user activities such as logins, logouts, and selection of hyperlinks. The events are of no use unless they can be acted upon, and this is achieved by providing action interpreters. This section will describe the events, generators, adapters, and interpreters. Note that the use of an E-R graph as the underlying representation makes it possible to express events as state changes in this graph, allowing us to attach semantic meaning to changes in information. Simple web watchers cannot handle monitoring at this level, and are limited to monitoring content. For example, an E-R graph can represent events such as a user becoming interested in a particular subject via the addition of an ‘interested in’ relation between the user and the subject. The event monitoring task can then be modelled as a set of events generated by state changes in the E-R graph. These changes include creation, modification and deletion of entities, attributes and relations. These events are generated by VSPOS information servers, and from information sources that have been interfaced into the VSP via information adapters. (See section 3.4). The next section will describe the current event classification, and the mechanism used for generating new events.
3.1.1 Classification of events The events that are supported by the event mechanism are based on an event hierarchy. This consists of a set of event classes with subtypes. These events are defined by their type (e.g. create, modify, delete, access and select). A base event holds information common to all events: name, a time stamp, information on the application that generated the event and a data field. Event types are derived from this base event. Each of these event types may have a set of subtypes, e.g. create, modify delete and access events have subtypes object, attribute and relationship. Figure 2 shows the event hierarchy. There are three classes of events, which allow interest to be registered in events at a coarse level, (e.g. ‘tell me about all updates’), or in detail (e.g. ‘tell me about updates to attribute X within object Y’). Update events are concerned with changes in state of the object store. These may be create, modify or delete events. Activity events are concerned with external changes in state of users or applications, for example, when a user logs on or when an application accesses the object store. Finally, time based state changes generate timer events. A one shot timer is used for one off situations. For example ‘generate a timer event in 5 minutes time’. A scheduled event is used for generating events at specific times e.g. ‘generate a timer event at 12:30 every Friday’. Finally, the interval timer event is used for generating regular ‘ticks’, e.g. every second, minute or hour.
Logon Event Activity Event
Logoff Event
Object
Access Event
Attribute Relationship
VSP Base Event
Update Events
Create Event
Object
Modify Event
Attribute
Delete object
Relationship
One shot event Timer Events
Schedule event Interval event
Figure 2. Event hierarchy
The event hierarchy is extensible, so that as new types of events are required, they can be added to the appropriate event class, or a new class can be created. The new events may contain additional information as needed, and the event interface can be used to extract this for use.
3.2 Event distribution mechanisms The system supporting the event model has four main interfaces: • Event Generator (EG): This interface is added to information servers and client applications to map server and application specific events into VSP events, and distribute them; • Event Adapter (EA): There is an event adapter for each high-level event type (update, activity, timer). Takes events from the EG and applies an event mask to determine which events are ‘interesting’; • Event Despatcher (ED): Manages event masks for the EAs and multiplexes the resulting events before passing them to the Action Interpreter, and • Action Interpreter (AI): Applies the conditions and actions relevant to the events passed from the ED.
Client UI EG
request s results
activity events
RQ Query Adapter
RE
RQ Object Store
RE
Information Adapter
EA
request s results
Information Server
EG update events EA
activity event mask Scheduler
update event mask
EG timer events EA
timer event mask
Timer Events
Activity Events Update Events Event Despatcher interesting events Action Interpreter
Figure 3. System Architecture.
Key EG - Event Generator EA - Event Adapter RQ - Request for information RE - Results of request for information
An overview of this mechanism is given in Figure3.
3.2.1 Event generator To allow users to monitor information, both in the VSP object store and on other information servers, there needs to be a mechanism for specifying events that the user finds interesting. The Event Generator (EG) is used to convert the events generated by information servers into events, and distribute them. These VSP events are then filtered by event adapters. There are three ways in which VSP events can be solicited from information servers: 1. The information server is un-modified, i.e. has no notion of the EG. Events can only be generated when the server is polled periodically, i.e. these events are only generated on request by an event generator whose task is to poll the server. This has the advantage that events from unmodified information servers can be used. However, the set of events that can be obtained from these servers is limited to determining if information exists or if the information has been modified. 2. The information server has been modified to include an EG. This allows a richer set of events to be generated as they occur because there is no need to perform polling. The events generated will depend on the type of information server. For example, a WWW server can generate access and change events, an X.500 server can generate creation, deletion, modification and access events on a per attribute level if required. 3. The information is accessed indirectly via a proxy server which synthesises events and passes the requests to the correct server. Most WWW browsers have the ability to specify a proxy server. This allows a browser to be pointed at a proxy server that has been modified, allowing requests for information from a server to be intercepted by the proxy and passed on to the VSP system. The second option is more useful than the first, but it requires that the relevant server is updated, which is not always feasible. Option three is the most flexible, but to scale the system up would require a lot of proxy servers, otherwise they would quickly become a bottleneck. Supporting all options makes a larger information set available. It should be noted that in most cases the information server has an event generator, however user applications may also have an EG. This allows application specific events to be used to generate events that the EG can pass on, such as select events in the VSP navigator.
3.2.2 Event adapter The event adapter (EA) provides an interface between the event generator, and the event despatcher. Clients register a set of ‘interesting’ events with the event despatcher as an interest mask, which is passed to the appropriate EA. Events generated by EGs are taken by the EA, filtered using the event mask, and the resulting interesting events are passed to the action interpreter; the un-interesting events are discarded. As well as receiving events, the EA needs to be able to query the servers to determine whether they support the rich set of events or not, and to be able to set the types of events that they are interested in.
3.2.3 Event despatcher The event despatchers’ role is twofold. Firstly, it manages the masks used by the EAs to filter events of specific types, for example, define an interest in all login activity events, schedule timer events and create and modify update events. These masks are distributed to the EAs. Secondly, it is used to multiplex the interesting events from the EAs and forward them to the Action Interpreter. There will usually be a single ED defined for each user. The process of defining the event masks is called registration of interest. For each event class, there are a number of levels of registration of interest. At the simplest level, an event of any type can be registered as interesting, e.g. all create events. Each of these types of events may have a number of sub-events - for create, they are object, attribute and link, and these can be used in the mask. These types of registration are relatively coarse, but provide the ability to specify more useful interest in the action interpreter using conditions and actions.
3.2.4 Action interpreter The Action Interpreter (AI) is used to take incoming events from the event despatcher and use any relevant user specified condition data to ascertain whether any of the conditions are fulfilled. If any conditions are met, the AI checks in the VSP object store for related actions. The conditions and actions are specified in a scripting language that has
interfaces to the event and object store APIs. These actions are then executed. Conditions provide a finer granularity of registration of interest when used in conjunction with event registration. For example, the data stored in the events can be used to determine the level of interest in an event. For example, events are automatically time stamped by the event generator on creation, so an interest may be registered in all events created between 9:30am and 5:00pm. To specify users' interests, a new VSP object is used. The object specifies a single interest and is linked to a VSP ‘person’ object using ‘interest held by’ and the corresponding ‘has interest in’ relationships. This allows users to be searched for based on their interests. The interest object contains a description of the interest and attributes containing the conditions and actions in the form of tcl scripts that the user has specified. Figure 4. shows how the different components of the event model work together. Information adapters, client applications and timers can have an event generator added to them. An API allows VSP events to be generated on request. The user may not necessarily be interested in all of the events generated by the EGs, and it is the event adapters that provide the mechanism to filter out unwanted events. The events that are interesting are specified using an event mask that is sent to the EA by the event despatcher. The EDs job is to maintain the event masks and to pass the interesting events from all of the EAs to the action interpreter, where the user can apply conditions and actions to them. Using this mechanism, an external Access database could be monitored for updates to specific records in the following way. Event Generator
Event Generator
Events Event Adapter Event Mask
Events Event Adapter
Interesting Events
Event Mask
Event Despatcher Interesting Events Action Interpreter Figure 4. Event Model
For instance, an Access database information adapter could be written in order to synthesise VSP objects from an Access database. Whenever a record is updated, a modify object event is generated by an EG. The user specifies that they are interested in modify object events on object X, so the ED creates an event mask that filters all but modify object events. This filter is passed to the EA which allows the modify object events through. The action interpreter gets this event, and executes a condition that checks to see whether the event was generated by a modification to object X. If it was, a user specified action is executed. The next section will discuss conditions and actions in more depth.
3.3 Conditions and actions Conditions and actions allow changes in information state to be acted upon. Conditions will usually take the form of checks on information and users’ state. A condition is defined as a set of user defined statements that, when met, may be used to trigger an action. These actions may be arbitrarily complex and may or may not trigger actions. An action can be defined as a set of user defined statements that generate one of three types of operation: • an object store update, for instance, incrementing a counter in an object whenever it is accessed, providing a guide as to the popularity of the object. • an asynchronous communication, for example, sending an email message. • a synchronous operation, such as initiating a collaborative session with the owner and accessor of an object. The conditions and actions are stored as entries in the object store. A set of default conditions and actions have been created that provide both low and high level functionality. These may be combined using expressions such as ‘if
(((condition1) | (condition2)) & condition3) then (action1)’. Interfaces have been defined which can be used by the condition/action scripts. The first, is an event interface, that provides access to the event that caused the condition to fire, and the information contained within it. The user may use this information to determine whether the condition is met, and therefore whether an action will be fired. The second provides access to the object store, allowing objects to be created, modified, deleted, and accessed to allow the actions to actively modify the object store subject to security permissions.
3.4 Information adapters There are a large number of networked information sources already available and the effort that would be required to reenter the data in the format used by the VSP would be prohibitive. For this reason, information adapters will be used to translate information from their native formats to that used by the VSP object store. This approach is extensively used in the form of gateways to other information sources that are accessible via the WWW. This allows a single browser to access a huge amount of information, however the disadvantage is that the access, display and searching mechanisms are specific to the gateway. By mapping the information sources into a single name space, a number of benefits are gained: the tools used to access, view and manipulate the data can be used to access and search information consistently across the whole information space. A new information source needs two components to allow it to be integrated into the object store: a schema definition and an adapter. The schema definition allows the attribute and link information, as well as a display template for the object to be specified. The adapter contains a set of routines for communicating with the external information source, and for mapping the information contained within each unit of information (which is specific to the external source) into a VSP object. For example, the WWW to VSP object store adapter takes a Uniform Resource Locator (URL)17 and extracts name and link information from it to generate a VSP object with the following attributes: WWW object attribute name VSPName
VSPLongName url *documentText last_modified VSPLinkWWWchildLink VSPLinkWWWparentLink * - optional attribute
Attribute description The unique name of the document. This consists of the WWW anchor point in the object store and a dot-separated list of the traversed links to the current object, e.g. VSP.WWW.Homepage.Whats_new The contents of the ‘‘ field for a WWW document - not all documents specify these, one is generated automatically from the URL and header information. The full URL for this document The full HTML source for this document The date of the last modification for this document A list of links FROM this document (child links) A list of links TO this document (parent links) Table 1 - WWW object
Currently, adapters for WWW, Usenet news and X.500 information servers have been developed. Each information source has its own root in the VSP object store, usually directly under the top-level VSP object, although they can be located anywhere in the hierarchy. Each of these roots specifies the domain for that information source as they are mapped into the VSP namespace. The objects can of course be cross linked, so a Person object may have links to favourite URLs (WWW objects) and their entry in the global X.500 directory. Figure 5 shows an example of the location of the WWW and X.500 domains within the VSP. One useful property of an object is the ability to specify that it is a redirector. This allows an intelligent browser to bypass the display of the VSP object, and to display the information directly. For example, if a WWW object is defined to be a redirector, when it is viewed using the WWW gateway, instead of presenting the user with the VSP entry for the object, i.e. a title, the URL, modification dates etc., the actual WWW document referenced by the URL (or the version stored in the ‘documentText’ attribute if it is up-to-date)is displayed. If the WWW gateway was not being used, the appropriate tool would be started (in this case a WWW browser) and the document would be loaded into that. Adapters are classified in two ways depending on the way how they are run.
Description
WWW Domain WWW Root
VSP Homepage
Projects People
X.500 Domain
country=GB
X.500 Root country=US VSP Expertise
Native VSP Domain
Organisations
Resources
Figure 5 - Locating external information sources in the VSP
1. Polling adapters - the adapters are run periodically in the same way that current WWW wanderers and spiders are used. This provides an automatic way to populate the VSP from other data sources. This periodic approach can be necessary due to the sheer volume of information available, and the problems of keeping the information timely. Current WWW wanderers are run periodically, and each run discovers thousands of new documents. Frequent use of the adapters will be necessary to keep the information up-to-date, and to discover links to documents that are no longer available. One of the major problems is the policy for running the adapter - too often and the object store will be constantly creating and modifying large numbers of objects; too infrequently and the information will not be upto-date. With these problems in mind, there is now a ‘robot exclusion standard'18 which specifies a set of rules that 'well behaved' Web wanderers and spiders should adhere to. These are effectively policy statements on the rate at which documents may be retrieved from a Web server and by whom. 2. Dynamic adapters - the adapters are run dynamically - typically from a navigator tool. For example, if a browsing tool is viewing an object that has a Web link, and the link is traversed, a Web object for the specified document will be created, and it is this object which will be viewed. For example, expanding the ‘VSP Homepage’ Web object in Figure 5 will cause the links to be traversed and the relevant VSP Web objects to be created. The two approaches have their own advantages and disadvantages. The first allows large sections of the non-VSP domains to be mapped into VSP objects as a background task. However, this means that the information contained in the new objects is only as new as the last time the adapter is run. The second approach means that the information is expandable ‘on-the-fly’ with the latest information being retrieved.
4. IMPLEMENTATION The system architecture described in section 3 provides the basic components for addressing the problems defined in section 1. A proof of concept system has been built which takes the original VSP tools and extends them to use the new architectural features. A new set of tools has also been developed, each of which use the new architecture, and a case study has been prepared which uses both sets of tools. The original VSP client, which supported browsing and navigation of the VSP object store has been extended to provide a number of new features: •
integration of an event generator for generating events: when objects are accessed from the object store, an 'access object' event is generated. If an object is selected in the navigator tool, a 'select object' event is generated. Events are also generated when conferences are created and deleted (see below).
•
Addition of information adapters for WWW documents and Usenet News groups: The object store has entry points to WWW and Usenet News. The adapters are activated if an object of the appropriate type is expanded in the navigator tool.
4.1 Web gateway implementation The core of the system is a VSP Web gateway which can be thought of as an intelligent Web-to-X.500 gateway, and has event generators and adapters within it. This allows the object store to be browsed, searched and edited using a standard unmodified WWW browser. The basic WWW gateway works as follows. A VSP server contains a graph holding objects. These are retrieved as requested from the X.500 server. The WWW browser is used to browse, search and edit the object store using interfaces to Common Gateway Interface (CGI) programs. CGI provides a mechanism by which external programs can interface Web servers. For example, initially on entering the WWW Gateway, a link to the toplevel VSP object is displayed. This link references a CGI browse program and the name of the object to be retrieved. The CGI program makes a connection to the VSP server, which retrieves the object from the object store, and generates an HTML document using the presentation template information from the schema and the information in the object. If there are links in the object, these are created as HTML links to the CGI browse program. The search and edit clients provide HTML forms interfaces for performing these tasks, and use the same CGI mechanism. A fourth client is provided to log on and off the system. The enhanced features of Netscape 2.0 have been catered for in the gateway by supporting multiple frames to provide the search and viewer interface, as well as a button bar to switch between the available tools (search, index, navigator and communicator tools). This has proved to be a more intuitive, useful interface than that previously available with single frame browsers due to the elimination of swapping between pages. The VSP server contains not only the object store, but an action interpreter and event generator. The event generator is used to generate events when an object is accessed via the browse CGI program, or created, modified or deleted using the editor CGI program. Having the event generator in the VSP server would seem unnecessary, as the events are despatched by the server to the action interpreter, also in the server. However, adapters to external data sources generate events, as do clients that do not use the Web gateway.
4.2 Event distribution mechanism The proof of concept systems use the following mechanism for the generation and distribution of events. Figure 6 shows the conceptual view of the event despatcher/generator interoperation. When events are generated, they need to be distributed to interested parties. This one-to-many distribution can be achieved by using multicast IP19 communications This approach has been used in other systems (e.g.20) where wide-scale distribution of information is required. In our system, each EG has an associated multicast group. When a VSP event is generated by the information server or application, it is time stamped and the application details and name are added. If any application specific data is required, this is also added (e.g. a select event from the VSP navigator will include the VSP name of the selected object). Once the event has been created, the event generator sends the event to its associated multicast group. In this example, the event despatcher has registered an interest with two multicast groups. From the point of view of scalability, providing a set of connected multicast addresses such as the mechanism used by the MBONE 21 may be the most suitable and scaleable solution. However, multicast IP is by design not a reliable distribution mechanism, i.e. data may be sent, but there is no guarantee that the data will (a) arrive in the order that it was sent and (b) arrive at all. This is clearly unsatisfactory for our system. For this reason, the Reliable Multicast Protocol 22 will be used in future versions, as it provides a totally ordered, reliable multicast service on top of IP Multicasting.
4.3 Action interpreter implementation The AI is based around tcl (Tool Command Language 23) interpreters. Tcl is a simple interpreted language intended primarily for issuing commands to interactive programs. It has a simple syntax and is also programmable, so additional commands can be written to provide more powerful commands than the standard tcl commands. This allows existing code to be used by providing a tcl wrapper around it, and also allows speed critical code to be written in a lower-level language with a high-level Tcl API . A set of tcl command procedures have been written providing an interface to the existing C++ VSP object store API. The conditions defined by the registration of interest are converted into tcl scripts. An interpreter is then created, to which the tcl script is passed and interpreted. If the condition(s) are met, the interpreter will return successfully, and the associated actions are then interpreted in the same manner. We are currently investigating the use of Java 24 as the condition and action language and the possible integration of Uniform Resource Agents 25.
Client Application Application
Action Interpreter
Event Generator
Event Despatcher
Modified Server
Multicast group
Multicast group Unmodified Server
Modified Server
Application Application Proxy Server
Key Event VSP Event Generator
Figure 6 - Event distribution using multicast mechanism
5. CASE STUDY Section 4 outlined the implementation of the architecture presented in section 3. This proof of concept is being tested in an academic environment before being released on a wider scale. The main vehicle for the case study will be the WWW gateway due to the range of computing platforms used around the university, and the availability of HTML browsers on most of these platforms. The case study participants have been chosen from a wide range of backgrounds, including computer and social scientists with varying levels of computer literacy. The existing dataset used in the VSP has been extended to provide directory entries (DEs) for each of these users, as well as a set of WWW DEs automatically created from their Netscape bookmark lists. A set of ‘wizards’ that allow the specification of monitoring controls on these or any other DEs in the object store have been created using HTML forms. These wizards ease the job of specifying the conditions and actions to perform the monitoring tasks by taking the user through the required steps. Users can choose the mechanism used to inform them of changes to information state, including email and popup window notification, and the creation of a new DE listing the updates over a user specified time interval. This provides a simple way to monitor existing information from both external data sources (WWW and Usenet Newsgroups) and information in the object store. A number of mechanisms for supporting chance interaction have been provided • Users with videocameras on their machines have the option to control a capture daemon to grab an image from the camera and updating a special DE connected to the users DE. This allows other users to look at the related page and provide an indication as to the users availability. The capture demon is controlled by the user, and can be set to privacy mode, in which case an image chosen by the user is used instead; • At the bottom of each viewer page in the gateway is a list of the users that are currently looking at the same object. The list consists of a link to the users’ directory entry and is colour coded depending on the length of time that the user has been ‘idle’ on that page, (e.g. red link for < 5 minutes, to blue link for > 1 hour); • Users specify a set of ‘interests’ linked to their DE that comprises of sets of keywords that can be used for performing persistent queries. For instance, a user may want to be informed in some way if an expertise DE in the area of water pollution becomes available. Wizards exist to specify the events to monitor and the action to take. This provides a combination of the information monitoring and chance interaction as the action may be to set up a collaboration session between the expertise provider and the user that specified the persistent query, and
•
Conference objects linked to users and tools may be created. These may be destroyed when the conference has finished, or left as a persistent conference. Used in conjunction with the timer and/or activity events, timely or chance interaction can be achieved. For instance, user A sets up a conference including user B and a set of DEs for tools and resources (such as a document) for a regular weekly meeting. User B is currently unavailable, so the conference is left in the object store. A condition is set up that says ‘when user B accesses the conference object, initiate a videoconference using the tools in the conference between users A and B’.
6. CONCLUSIONS AND FUTURE WORK The set of conditions and actions available to the users is growing, and wizards make it much simpler for them to be grouped to perform useful tasks. The current conditions and actions are biased towards information monitoring and supporting chance interaction. New ones will be added to support the other projects using the VSP, such as workbased learning and research support. The workbased learning requirements are for general navigating and browsing for information, including course catalogue/timetables, library catalogues etc. and communicating with tutors and other students initially using asynchronous tools such as email and bulletin boards. One area that is being pursued is expanding users’ interests by monitoring their behaviour when using the VSP. By monitoring their access to bulletin board groups and information sources, interests can be added to automatically (with user confirmation). These interests could then be used to generate VSP clubs containing like-minded individuals. Coupled with the communication facilities, this would provide a powerful mechanism for interaction between the students. The set of events is to be extended to support multimedia events. For instance, video streams will be generated which may be viewed by registering interest in the appropriate events. The use of the event mechanism for supporting training will be investigated. When complex user interfaces are being used, it is often difficult to articulate problems when using them remotely. The event mechanism may be used to effectively control the remote user interface to allow them to be guided through problems by an experienced user. This is especially useful for teaching, as the multicast events can be used to control many interfaces at a time.
7. ACKNOWLEDGEMENTS The authors wish to thank Andy Walker and Jayne Curson for providing input to the work described in this paper and providing comments on the paper itself. Funding for this work has been provided by an EPSRC studentship.
8. REFERENCES [1] [2] [3] [4] [5] [6]
[7] [8] [9] [10] [11]
Steed, D., X.500 the directory standard and its applications. Technology Appraisals Ltd. 1993. ISBN 1 871802 24 5 Edwards., W.K Session Management for Collaborative Applications, Proceedings of the ACM Conference on Computer-Supported Cooperative Work, Chapel Hill, NC, 1994. Hennessy, P., Harvey, P., Smith, H. Support for Enterprise Modelling in CSCW, Collaborative Computing 1, pp127-146. 1994. Specter Communications WebWatch http://www.specter.com/, 1995 Netscape Communications Netscape Smartmarks http://home.netscape.com/comprod/smartmarks.html 1995 Kraut, R. E., Fish, R. S., Root, R. W. & Chalfonte Informal communication in organisations: form, function and technology, in R M Baecker (ed) Readings in Groupware and CSCW: Assisting Human-Human Collaboration, Morgan Kaufmann Publishers, California Buxton, W A. S.. (1992) Telepresence: Integrating Shared Task and Person Spaces, Proc. Graphic Interface '92, pp. 123-129, paper Root, R.W. (1988) Design of a multi-media vehicle for social browsing. Proc. Conference on Computer Supported Cooperative Work (Portland, Oregon) Benford, S., Fahlen, L. E., Aura, Focus and Awareness Proc. 5th MultiG Workshop 1992 Dourish, P, Bly, S. (1992) Portholes: Supporting Awareness in Distributed Work Groups, Proc. ACM Conference in Human Factors in Computing Systems, CHI'92, pp.541-547 Dourish, P. (1991) Godard: A flexible Architecture for Audio/Video Services in a Media Space, Technical Report EPC-91-134
[12] [13]
[14] [15] [16] [17] [18] [19] [20]
[21] [22] [23] [24] [25]
Mantei, M (1991) Experiences in the Use of a Media Space, Proc. CHI '91 Human Factors in Computer Systems CHI'91, pp.203-208 Gaver, B., Moran, T., MacLean, A., Lovstrand, L. Dourish, P. Carter, K. and Buxton, B. (1992) Realising a Video Environment: EuroPARC's RAVE system, Proc. ACM Conference on Human Factors in Computer Systems. CHI'92, pp.27-35 Li, J and Mantei, M. (1992) Working Together Virtually, Graphics Interface '92 Donath, J.S, Casual Collaboration, Proc. International Conference on Multimedia Computing and Systems, May. 1994 Dew, P.M, Leigh, C.M, Drew, R.S, Morris, D.T, Curson, J.M, Virtual Working Systems to support R&D groups, Multimedia Computing and Networking, San-Jose, Feb. 1995 Berners-Lee.,T RFC 1630. Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web. June 1994. Koster, Martij, A Standard for Robot Exclusion, http://web.nexor.co.uk/mak/doc/robots/norobots.html., June 1994 Deering, S, Host Extensions for IP Multicasting, file://nic.switch.ch/docs/rfc/11xx/1112, RFC 1112 August 1989 Macedonia, M.R, Zyda, M.J., Pratt, D.d., et al Exploiting Reality with Multicast Groups: A Network Architecture for Large-Scale Virtual Environments. Proceedings of the Virtual Reality Annual International Symposium. VRAIS ’95. IEEE Computer Society Press, Los Alamitos, CA, March 1995, pp.2-10 Eriksson, H, MBone: The Multicast Backbone, Communications of the ACM, August 1994, Vol.37, pp.54-60. Whetten, Brean, Montgomery, T., Kaplan., S, A High Performance Totally Ordered Multicast Protocol. Http://research.ivv.nasa.gov/projects/RMP/RMP.html Ousterhout, J, K, Tcl: A Universal Scripting Language, USENIX Symposium on Very High Level Languages Santa Fe, NM, October 26, 1994 Sun Microsystems, The Java Language: A White Paper http://java.sun.com/1.0alpha2/doc/overview/java/index.html Daigle, L., Deutsch, P., Heelan, B., Alpaugh, C., Maclachlan, M. Uniform Resource Agents (URAs), Internet Draft - work in progress, November 1995
