sdb@cs.nott.ac.uk (Steve Benford) (01/11/90)
The GRACE (GRoup ACtivity Environment) Project ============================================== for Group Communication in an OSI Environment ============================================= Steve Benford Communications Research Group The University of Nottingham England 22nd December 1989 Abstract -------- GRACE is the name of the UK Joint Network Team funded project to specify and prototype an OSI "group communication" service. This report describes the background to the project, the project's goals and scope, and progress throughout the first three months. The report describes the collective work of the GRACE project team. Steve Benford Howidy Howidy Julian Onions Alan Shepherd Hugh Smith Goals of the project -------------------- GRACE is a two year research project at Nottingham University, funded by the UK Joint Network Team, with the aim of specifying and implementing a prototype OSI based group communication service. There are several motivations for embarking on this project at the present time. * Existing inter-personal communication services such as electronic mail are now widely recognised as being insufficient to support the rich diversity of communication found within many human 'activities', * Existing group communication services, such as computer conferencing, news and bulletin boards, are often deficient in functionality (e.g. little support for management) or architecture (e.g. centralised and therefore limited in scale). * Many network communities, including the UK Academic Community, are migrating to the use of OSI networks and services. Consequently, existing tools for group communication based on other protocols, limited as they are, are becoming increasingly out of place. * In the light of the above, 'group communication' has been adopted by both the ISO and CCITT as a new work item for the standardisation of Message Handling Systems (i.e. X.400/MOTIS). Input is urgently required to this work. Given these motivations, the GRACE project aims to produce a specification for a group communication service which: * is rich in functionality, particularly in management functions (e.g. member subscription, submission control and topic control) * adopts an architectural framework which supports communication over a wide range of scales. * uses OSI application services and protocols in order to be compatible with planned migration strategies for the UK and European academic communities. * makes significant input to emerging international standards in this area. The project will also produce demonstrators in the form of prototype group communication services. These will utilise publically available implementations of X.400 (PP) and X.500 (QUIPU) and will take advantage of planned JNT piloting of these services. Liaison with the UK academic and international research communities is a key goal of the project. This will be achieved through groups such as RARE and COSINE. What is group communication? ---------------------------- Group communication refers to the communication processes which occur within groups of people who, in a general sense, are working together to achieve some set of goals. This topic is also commonly referred to as "Computer Supported Cooperative Work" (CSCW), "Cooperative Work Technology" (CWT) or "Groupware". Group communication differs from other applications of information technology in that: * communication is considered within the context of a specific group or task. This is in contrast to the view of existing inter-personal communication services which are typically limited to considerations of how to pass information between individuals or, occasionally, between an individual and a set of individuals (e.g. distribution lists in electronic mail). * The role of technology is to support communication between people. This differs from applications such as shared databases where, although groups of users may access the same information, no real communication occurs. Groups are involved in a wide diversity of 'activities', ranging from small-scale formalised office procedures to world-wide information services such as newspapers. Activities may differ in may ways. For example, degree of formal structure; number of participants; synchronous or asynchronous; fixed time period or continuous. Clearly, the range of possible group activities is huge. To appreciate this, consider the following non-exhaustive list of examples. EXAMPLE GROUP COMMUNICATION ACTIVITIES ====================================== bulletin boards computer conferences and news face to face meetings: brainstorming committees expert meeting (e.g. medical case conference) group authoring office and organisational procedures (e.g. travel application) newspapers, magazines, journals and periodicals games (e.g. trivial pursuits, bridge) software design teams voting and elections opinion polls seminars, lectures, tutorials presentations panel sessions (question and answer) auctions stock market trial by jury buying a house producing international standards large engineering projects (e.g. building the Channel Tunnel) It was clear at the beginning of the GRACE project that we could not address the full range of examples listed above. Consequently, the first goal of the project was to precisely define its scope. As a first step, a classification of group activities was proposed. This classifies activities according to two major criteria: * The 'scale' of communication (i.e. the number of participants). * The degree of 'formal procedure' within the activity (i.e. the number of rules which constrain who may take which actions at which point). For example, an activity such as 'applying for a job' has more procedural structure in terms of when various forms are passed between different participants than a bulletin board activity where users browse and contribute at will, usually independently of other users. These are not the only two dimensions which might be used to classify activities. However, they do seem to capture the essential differences between many types of activity. The following diagram indicates how several of the example activities might be classified. The horizontal axis represents the degree of formal procedure and the vertical axis represents the number of participants. number of participants | elections | 1000000 | newspapers | | USENET News 10000 | | | engineering project | 100 | departmental lecture teaching course | bulletin board | departmental 10 | staff | meeting travel apply | office procedure 0 ------------------------------------------------------------------- none highly procedural degree of formalised procedure Fig 1: CLASSIFICATION OF GROUP ACTIVITIES It should be noted that this is not intended as an exhaustive classification of group communication activities. Instead, the aim is to demonstrate the broad scope of the subject and to provide a mechanism for focusing on specific application areas. Previous group communication projects ------------------------------------- Before discussing the scope of the GRACE project in more detail, it is worth briefly describing the scopes of other recent projects which have addressed group communication issues. These will provide useful input to the GRACE work. A more detailed comparison of these projects can be found in [Hennessy 89]. AMIGO Advanced: this project was funded under the EC COST-11-TER initiative. The broad aim of the project was to produce a notation and architecture for representing a wide variety of group communication activities. AMIGO Advanced appears to have mainly focused on procedural activities such as 'voting', 'date planning' and 'travel apply'. In fact, the 'AMIGO Activity Model', produced by the project, contains an explicit representation of 'rules' governing the flow of information within an activity [Pankoke-Babatz 89]. AMIGO MHS+: this project was a companion to AMIGO Advanced. The focus of the MHS+ project was on the extension of existing communication services such as X.400 and X.500 to support activities such as bulletin boards and computer conferencing. The results of this project include a model of distributed information sharing within groups [Smith 89a]. COSMOS: This project was funded under the UK Alvey initiative and involved a number of UK companies and universities. The objective of the project was to produce a 'configurable structured messaging system' capable of supporting a variety of group activities. Outputs from the project included notations for representing activities [Bowers 88] and a distributed system architecture. As with the AMIGO Advanced project, the examples explored within COSMOS mainly covered procedurally structured activities. MacALL: The MacALL project was concerned with developing an object-oriented framework for describing organisational communication. The project focused its attention on the kinds of group activities which occur within the context of a single organisation, typically within an office environment. Outputs of the project included an abstract model of activities and a prototype implementation of this model [Smith 89b]. In addition to these specific projects, there is a large body of previous research which will provide input to the GRACE work. This includes other models of group communication such as those in the CHAOS and DOMINO projects; existing conferencing systems such as COM and EIES; news systems such as 'USENET News'; and extended messaging systems such as the 'Information Lens'. Scope and approach of the GRACE project --------------------------------------- The first major task of the GRACE project was to define the scope of group communication activities under consideration. The following general constraints were agreed early on in the project: * The project would address large-scale activities where the number of participants might eventually be in the millions. * The project would focus more on 'information sharing' activities such as news distribution and electronic journals, as opposed to highly procedural office activities. * The project would not initially focus on synchronous (i.e. real-time or co-present) modes of group communication, although these may be considered in the future. In addition to these constraints, it was noted that the goals of the project require both the design of a general framework for group communication within an OSI environment (for standardisation) and focusing on specific activities (for demonstrators). As a result, the following overall approach has been adopted: The GRACE project will produce a specification for a generic OSI based Group Communication Service, capable of supporting a wide range of activities. This specification will be based on an analysis of a number of example activities. Once the generic service has been specified, demonstrators for some of these activities will then be prototyped. After consideration, the following four example group communication activities have been chosen for specification on the grounds that, between them, they cover a wide range of group communication functionality. 1. USENET News plus USENET News provides an immensely popular service to the world-wide academic community. Hundreds of thousands of users subscribe and contribute to a huge number of 'newsgroups' covering a bewildering variety of topics. USENET News is therefore perhaps the best example of an existing large-scale group communication service we have, and represents a rich source of experience and information. However, USENET News suffers from a number of limitations which include: * Users are presented with a continuous stream of information from which they select items of interest. However, there are no general facilities for archiving and group (i.e. multi-user) storage. * There is no well defined service architecture which clearly distinguishes different components of the system * Management functionality is limited (e.g. subscription and accounting management). * The service does not use the OSI application services/protocols towards which many communities are beginning to migrate. Thus, the existing USENET News service does not utilise features of the new OSI services such as multi-media messaging within X.400 and the naming and management potential of X.500. As a result, one of the activities specified by the project will be a large-scale "news service" which includes much of the functionality of USENET News and also some additional functionality. 2. A 'Which' style magazine The "Which ?" magazine is produced by the Consumer's Association to provide information to customers on the various products and services available to them. For example, the magazine may contain a review of various types of burglar alarms, possibly including manufacturer, installer and price details. The production of the magazine is heavily dependent on the cooperation of consumers who provide details of purchases, experiences and dealings with manufacturers and retailers. This is typically accomplished through the magazine announcing its intention of covering a specific topic and inviting its readers to apply for a questionnaire. An electronic "Which ?" style magazine would provide an interesting and potentially useful example of a group communication activity. The electronic version will focus on the production of reports based on consumer's responses to questionnaires. This process might involve several issues: * Identifying a consumer community likely to have experience with a specific range of products. * Constructing and distributing a questionnaire to this community. * Collecting responses to the questionnaire. * Analysing these responses and producing a report. * Publishing and distributing the report. 3. The 'Help Desk' Organisations providing services frequently support a 'help desk' where users of these services can go for advice and help. For example, the University's computing centre has an 'operational enquiries' desk which is manned most of the time. In general, users approach the help desk with some set of problems and are put in contact with someone who attempts to solve them. In a simple help desk, there might only be one helper who deals with all problems. However, it is possible to envisage more complex scenarios with many helpers responsible for different kinds of problem. Once a helper has been assigned, the user enters a dialogue with them until the problem is resolved. An electronic help desk could fulfil a similar role within a networked environment. In this case, customers would be able to establish contact with helpers and maintain a dialogue to resolve problems via telecommunications services. Features supported by an electronic help desk might include: * Mechanisms for publicising the help-desk and guiding users to the relevant helpers. * Support for assigning from a pool of helpers to the set of current users, and maintaining a dialogue between helpers and users. * An archive of common problems and their solutions which could be accessed by users and helpers. 4. Classified Advertisements Classified advertisements provide a mechanism for people to advertise items and services within newspapers, journals or magazines. A huge variety of items and services are sold this way. Classified ads are also used to request "wanted" items and services. Classified ads are a vital source of revenue for publishers (a number of publications exist on the proceeds of advertising alone). It seems likely that classified ads will play an equally vital role in a future electronic environment. Even without the financial implications, classified ads provide an extremely popular and useful service. The general structure of classified advertising is that an advertiser pays for an advert to be placed under some relevant classifications (e.g. "motor cars"). Potential customers can then browse the advertisements, using the classifications as a guide, to find the items/services they require. The advertisements then instruct the customer on how to contact the advertiser (e.g. phone, PO box). Additional, key features to be included in an electronic classifieds activity include: * Accounting facilities for automatically invoicing advertisers and customers. * The ability for advertisers to specify automatic expiry times for adverts or to remove them manually at will. * Support for 'auctions' where customers can make offers for an item and advertisers, and perhaps other customers, can inspect the 'current best price offered'. * Support for geographical advertising areas. In addition to classifications, customers often wish to browse adverts by geographical location. Geographical areas might also support the management of adverts. In summary, the approach adopted by the GRACE project is to analyse a range of group communication activities in order to derive the functionality of an underlying generic Group Communication Service capable of supporting them (and other activities besides). As well as specifications, the project will produce prototype demonstrators of some of the activities which are considered. General system architecture --------------------------- Having defined the scope of the issues to be addressed, the next task is to develop a general system architecture around which specification and development can proceed. One such architecture was specified in the AMIGO MHS+ project and this has been adopted as the basis of the GRACE work. The following paragraphs outline the architecture as it is envisaged at the present time. However, this may change as a result of on-going work. As described above, the underlying assumption of the project is that a wide variety of group activities can be supported by a generic Group Communication Service (GCS). The user accesses each activity through an activity specific user agent (e.g. a 'help desk user agent'). This agent presents the user interface in terms of activity specific commands. It then maps these commands into combinations of operations invoked on the Group Communication Service. In addition, activity user agents may implement specific functions not supported by the GCS. It should be noted that each activity may define a number of different activity user agents. In order to access the GCS, each activity user agent contains a 'Group Communication User Agent' (GCUA) which makes connections to the 'Group Communication System' via the 'Group Communication Access Protocol' (GCAP). USER USER | | ----------------- ----------------- | help desk | | which magazine| | User Agents | | User Agents | | | | | | ----------------------------------------- | | | | Group Communication | | | | | GCUA | Service | GCUA | | | | | | | | --------|-------- --------|-------- | \ GCAP / | | ------------------------- | | | Group | | | | Communication | | | | System (GCS) | | | ------------------------- | | / \ | --------|-------- --------|-------- | | | | | | | | GCUA | | GCUA | | | | | | | | | --------|-----------------------|-------- | | | | | | classifieds | | USENET plus | | user agents | | user agents | ----------------- ----------------- Fig 2: Group Communication Activities Built on the Generic Group Communication Service The Group Communication System is a distributed system, consisting of a set of Group Communication System Agents (GCSAs), each of which may communicate with other GCSAs via the 'Group Communication System Protocol' (GCSP). Furthermore, the Group Communication System makes use of a number of other OSI application services, accessing them via their access protocols. These include: * X.400 Message Handling Service * X.500 Directory Service * Management Service * Multi-user Archive Service (to be specified) The functionality of GCSAs and their use of other services remains to be specified. However, the following diagram indicates how the Group Communication System might be refined into combinations of GCSAs and other services. It is important to note that, at the present time, this is just a sketch of how the system may be structured. The details have yet to be worked out. Group Communication System ------------------------------------------------------------- | Group | | Group | | Communication | | Communication | | System Agent | | System Agent | |---------------| |---------------| | D | M | U | A | | D | M | U | A | | U | U | A | U | | U | U | A | U | | A | A | | A | | A | A | | A | ----------------- ----------------- | | | | | | | | .............System.Access.Protocols............. | | | | --------- --------- --------- --------- |Direct-| |Message| |Multi | |Manage-| |ory | |Trans- | |User | |ment | |System | |fer | |Archive| |System | | | |System | |System | | | --------- --------- --------- --------- ------------------------------------------------------------- Fig 3: REFINEMENT OF THE GROUP COMMUNICATION SYSTEM Progress and Future Work Items ------------------------------ Work so far has focused on defining the scope of the project and undertaking an initial analysis of the four example activities described above. Given these example applications and the basic system architecture, the following future work items can be identified. * Further specifying the example activities. * Specifying the Group Communication Service and, in particular, the Group Communication Access Protocol (GCAP) of figure 2. * Mapping between the functionality of each activity and the functionality offered by the GCAP. * Describing the internal operation of the Group Communication System Agent and how it utilises other services. * For each underlying service, specifying precisely how the service will be used (e.g. defining new Directory schema). * Implementing some demonstration activities. At present, it is intended to support implementation work with a number of existing tools: - the ISODE OSI development environment - the PP X.40 implementation - the QUIPU X.500 implementation - an object oriented database Liaison with research communities --------------------------------- Liaison with international research communities is a key aspect of the GRACE project. This will take place through established groups such as RARE and COSINE within Europe, as well as through the international standardisation process. In addition, the "group-comms" distribution list has been established as a forum for discussion on this project and related issues. A series of 'open meetings' are also planned, where results from the project will be presented and feedback will hopefully be obtained. Finally, we are extremely keen to hear from related projects and liaise directly with other researchers. Please do not hesitate to contact us if interested. References ---------- [Hennessy 89] Pippa Hennessy, Steve Benford and John Bowers, "Modelling Group Communication Structures: An Analysis of Four European Projects", In SICON 89: Proceedings of the Singapore Conference on Networks, Singapore, 1989, IEEE Computer Press. [Pankoke-Babatz 89] Uta Pankoke-Babatz, "Computer Based Group Communication: the AMIGO activity model", Ellis Horwood, Chichester, England, 1989. [Smith 89a] Hugh Smith, Julian Onions and Steve Benford, "Distributed Group Communication - The AMIGO Information Model", Ellis Horwood, Chichester, England, 1989. [Bowers 88] John Bowers, John Churcher and Tim Roberts, "Structuring Computer-Mediated Communication in COSMOS", Research Into Networks and Distributed Applications - Proceedings of EUTECO '88, Vienna, 1988, North-Holland. [Smith 89b] H.T Smith, P.A. Hennessy, G. Lunt "The Activity Model Environment: An Object Oriented Framework for Describing Organisational Communication", Proceedings of the 1st European Conference on Computer Supported Cooperative Work, Gatwick, September 1989.
yam@nttmhs.ntt.jp (Toshihiko YAMAKAMI) (01/16/90)
From article <16454@robin.cs.nott.ac.uk>, by sdb@cs.nott.ac.uk (Steve Benford): > > The GRACE (GRoup ACtivity Environment) Project > ============================================== > for Group Communication in an OSI Environment > ============================================= ( a lot of stuff deleted, please refer to the original ) It is very interesting. We know there are many communication research activities in Europe, including many in ESPRIT. But I did not know there is some project for Group Communication. MHS/MOTIS based group communication has been under discussion for rather a long period. I (I am one of SC18/WG4 member of Japanese Boday) think there is no definite group communication model in ISO SC18/WG 4. MHS/MOTIS based communication model is under discussion, and some working memos were made. It made me surprised that there exists a real implementation project based on MHS/MOTIS based enhansed group communication. Many people will agree that we cannot support group activities from a lot of series of inter-personal communication. We need some more powerful model to support group communication. A group communication agent located over MOTIS/MHS based UA and MTA is one model. Maybe another example is network-based hypertext approach. In OSI view, it is possible to provide such communication base with standardized hypertext on DFR. MHS/MOTIS based group communication has one strength. Its interconnectability of worldwide communication. It will take some time we can communication some types of hypertext or higher level document systems in world wide scale. But e-mail is the easiest background to provide group communication. Its weakness will include security-related issues(some EDI discussion people point out MOTIS/MHS security is not enough for EDI, maybe same to group communication), updatability(messages are low level communication primitives, so information manipulation such as cancel on voting will be hard tasks on application entity over MOTIS/MHS UA). MHS/MOTIS group communication has been a long-discussed matter in ISO SC18/WG 4. Now some CCITT people begins to discuss it since last year. We hope GRACE project provide real interconnectable group communication bases in world wide manner. -- Tosihiko YAMAKAMI Toshihiko YAMAKAMI NTT Telecommunication Networks Laboratories Telephone: +81-468-59-3781 FAX: +81-468-59-2546 junet: yam@nttmhs.ntt.jp CSNET: yam%nttmhs.ntt.jp@relay.cs.net snail-mail: Take 1-2356-523A, Yokosuka, Kanagawa 238-03 JAPAN