(synchronous or group usage) as well when the local system is being used as a stand alone decision tool (asynchronous or local usage). The support for these ...
SOME DESIGN OPTIONS FOR PERSISTENT DISTRIBUTED INFORMATION WITHIN GROUP DECISION SUPPORT SYSTEMS Paulo Melo Faculty of Economics, University of Coimbra and INESC Coimbra, Portugal and
João Paulo Costa Faculty of Economics, University of Coimbra and INESC Coimbra, Portugal ABSTRACT This communication intends to present the group supporting mechanisms that are being built into the AGAP group decision support system (Aid for Group Analysis and evaluation of Projects [6]). In it we make an abridged system description, focusing on AGAP's main components. We then detail the framework that was implemented for supporting distributed groups, namely regarding message passing, data sharing and voting. We then focus on the underlying techniques that support those functions, describing DOCs, permissions and data replication. Finally, some problems with this approach are addressed and an alternative architecture based on distributed objects is presented and discussed. Keywords: Group Decision Support Systems; Data Structures; Distributed Systems; Persistence.
1. INTRODUCTION The AGAP system is a distributed group decision support system for project analysis and evaluation support. It intends to provide level one and some level two group support (according to DeSanctis [7]) to decision makers working on project analysis and evaluation. It's main goal is group analysis and evaluation of several projects, each characterized by its own data, although some data can be shared between projects. On each project, or on several at once, different analysis methods are available. With them, a single project can be analyzed (for instance checking the effect of different tax rates) or various projects can be compared (using either single or multiple criteria decision tools present in the system). AGAP is being developed (in this version) for small (less than 10 elements) co-operative groups. However this group can be distributed in both the spatial and temporal domains (for information on distributed groups support systems see for instance [15], [16] or [17]), i.e. their users may be far apart, and their use of the systems need not be synchronous. This allows it to support "virtual teams" distributed between several offices or even different organizations. The main group support mechanisms implemented (or considered) for AGAP are message passing, information sharing, voting, routing and scheduling. The bases for all group interaction on the system are messages passed between group elements, or between them and the central unit. As a primal building block, the messages can themselves be very simple, or can have a complex internal data structure. A message can refer to the data stored in the local workstations, and in fact some of that data can be attached to the messages, and the data attached to a message can be in turn integrated with the local contents of the recipients databases. To implement the mechanisms described before, some internal structures had to be developed. As the data managed by the system is usually stored in simple relational databases, its usage by the decision maker would probably be difficult. To help limit the need to refer directly to the stored data, a semantic level was created over the data stored in the databases. This semantic level acts by encapsulation related information in a "bundle" with a unique ID and some significance – the DOC structure. Notice that this encapsulation stops short of the usual object oriented, as no support for procedural knowledge is present. The goals of this information structuring are twofold: •
Allow for location independence and sharing of information, while maintaining all its properties and organization.
•
Allow for time independence, allowing the operation when the local system is connected to the central unit (synchronous or group usage) as well when the local system is being used as a stand alone decision tool (asynchronous or local usage).
The support for these two different modes of usage may be needed for several reasons:
•
Although in the future the connection to a desired network may be possible at all times, today the issues of cost, bandwidth and quality of service usually still prevent a completely connected mode of operation, and thus the systems must also be functional when no such connection is available.
•
Even if all the technical and economical barriers preventing the systems from inter-operating at all times were removed, differences in time zone and schedules may prevent the simultaneous operation of all systems (although this problem may be lessened by the existence of a central unit available at all times).
•
Finally, security and expedience issues may force a system to be usable independently of actions from the other users or even independently from the availability of the central unit.
Each DOC that is to be explicitly shared between users is transmitted to the central unit, where it is stored and placed on outbound queues, awaiting connection of their designated users. A DOC that is to be shared but without a explicit destination user or group designed, is stored in a common storage area on the central unit, where the users will be able to check it and request it if needed, according to its access permissions. The DOC architecture, with the DOC structure, allows for a simple grouping of related information in a way that permits its distribution, access and version control. It also permits the more complex grouping of less strongly banded information by means of dependencies. However, it is a bulky, static, or at least hard to change solution, that can become corrupt in (almost) normal usage and still cannot adequately represent all the data structures to be used in the AGAP system. To address the problems stated, and in evolving the model we analyzed several potential alternatives to the DOC structure from the more elaborate Distributed Databases (see [3]) and Group Communication Platforms (like the ones presented in [2][12] and [18]) to the more basic Resource Reservation approaches (see [13]) or Distributed Objects (possibly using a distributed objects infrastructure like DCOM or CORBA – see [4]). However, the general shortcomings of the former for asynchronous operation, made us focus on the distributed objects approach. In this communication we make an abridged system description, focusing on AGAP's main components on section 2. We then detail the framework that was implemented for supporting distributed groups on section 3, namely regarding message passing, data sharing and voting. We then focus on the underlying techniques that support those functions, describing DOCs, permissions and data replication on section 4. Finally, some problems with this approach are addressed and an alternative architecture based on distributed objects is presented on section 5.
2. SYSTEM DESCRIPTION The AGAP system described here is a distributed group decision support system for project analysis and evaluation support. It intends to provide level one and some level two group support to decision makers working on project analysis and evaluation. It's main goal is group analysis of several projects, each characterized by its own data, although some data can be shared between projects. On each project, or on several at once, different analysis methods are available. With them, a single project can be analyzed (for instance checking the effect of different tax rates) or various projects can be compared (using either single or multiple criteria decision tools present in the system). Although it can function as a stand-alone tool, AGAP is a group support system and as such it can keep both local and shared information. This way, a user (decision-maker) may participate in the group process sharing not only her views and values but also her data (and even her data structuring). Proviso has been made so that although some information may be shared, its distribution may be controlled or even restricted. This way a user can engage for instance in testing remote hypotheses or new projects without having to discuss them with others, or a subgroup can explore different ideas without submitting them to third parties). AGAP is being developed (in this version) for small (less than 10 elements) co-operative groups. As such no negotiation tools have been implemented, and the scalability of the system is not a main goal. However this group can be distributed in both the spatial and temporal domains, i.e. their users may be far apart, and their use of the systems need not be synchronous (in fact, in its first version, synchronous use is the exception rather than the norm). This allows it to support “virtual teams” distributed between several offices or even different organizations. The physical system consists of a central unit and (several) workstations, which communicate with the central unit and between themselves by way of the central unit, through a TCP/IP network, like the Internet. Each user has her own workstation, while the central unit runs a (potentially faceless) process that communicates with all the workstations, as shown in Figure 1. Each user has her own local work station, that she can use as a stand alone machine, to perform local data insertion and analysis, or connect to the central unit. Each work station keeps it's owner data, and if connected to the central unit can exchange data with it. All the processes of data manipulation are local, and as such data must be transported from the central unit before it can be used on local workstations.
Work Station 1
Central Unit Internet / Intranet
Work Station 2
Work Station 3 Figure 1 - The Physical System
The central unit acts as a central communications hub, talking with each workstation (potentially with all of them at once, so it can support synchronous data exchange). It is also the central storage area that keeps all the information that is shared between users. It acts also as a gatekeeper, implementing the data access policies required by the owners of each shared information. A particular kind of information that is kept on the central unit is the so-called “group memory”, comprising all the information that is to be recollected later on by the group elements. The system takes an “actuarial” view of the group memory, in which only information that is explicitly added by a group element is stored there. The central unit has also a function of co-ordination of the task of the group. It handles the communications between group elements, the sharing and delivery of particular data and it keeps all the records and tallies the results on each voting process. It is also its function the implementation of anonymity and pseudonimity between group elements so that details regarding user identities may be kept secret when needed. The main group support mechanisms implemented (or considered) for AGAP are message passing, information sharing, voting, routing and scheduling.
3. AGAP - GROUP SUPPORT BASICS The basis for all group interaction on the system are messages passed between group elements, or between them and the central unit. As a primal building block, the messages can themselves be very simple, or can have a complex internal data structure. It can refer the data stored in the local workstations, and in fact some of that data can be attached to the messages, and the data attached to a message can be in turn integrated with the local contents of the recipients databases. The messages that are exchanged between users can be protected by permissions. Those permissions define the degree of access to the message to users other than the sender and the recipients - from no information to knowing that a message was sent to even knowing the actual message contents. Other permissions affect the recipients of the message, and allow anonymous messages, or messages sent to a group but whose recipients don't know who else also got that message. Default permissions may be placed on the messages, but the user can override them. The actual messages exchanged by the system between users can be classified into simple messages, structured messages (which have a pre-defined structure, and are thus adequate to exchange information of particular kinds, like projects, or project attributes) and opinion gathering messages (like structured messages, but that elicit response from the recipient). Threading of messages (that is, grouping of related messages, or reply chains) is supported by the system. Message exchanges between the users (or between the users and the system) can be incorporated into group memory, that can be kept in the system even after the end of a particular decision process, and each member of the decision group can at any time recall that. Besides the environmental anonymity (as defined by Gavish [9]) supplied by the spatial distribution, the system also tries to accomplish some level of procedural anonymity, by means of anonymous messages (the messages can be anonymous to the recipients, and can potentially even be anonymous to the central unit). However, truly anonymous messages are limited in the context of a discussion, as e.g. there is no common reference to who is proposing which idea (and a truly anonymous message can't be replied to). To obviate to this problem the system also implements pseudonymous messages with an automatic creation of pseudonyms (and heteronyms) to the users that so desire. Information stored in the local databases can be shared between users. Information can be explicitly delivered to individual users (akin to messages) or can be placed in a shared “common area” into which the users can check if they are interested in that particular piece of information. The access to that shared information is restricted by permissions that allow some
particular information to be perused for instance by the chief manager, but not by some other participants. Although the group may be co-operative, not all the data must be equally shared to each member. Collaboration on a particular piece of information (e.g. by each member contributing with her knowledge) can be achieved creating data that has writing permissions for the active contributing members. The implementation of such a scheme however means that some sort of mechanism to update shared information (for instance the adding of new data, but also the correction of some possibly flawed or imprecise data). In AGAP this is implemented by means of version control, with each shared piece of information having version identification, and each public change on that information implying the change of version. Note that this, coupled with distributed information storage means that the database copies of shared information on different users work stations may not have the same version. However, effort is made to avoid having incoherent data versions simultaneously in user work stations, trying to update “in block” linked information. Information can also be shared between group members explicitly, and as such can be used by several group members in their own analysis. Information may either be explicitly sent to a particular subgroup, or it can be placed in a common area where interested group members may have access to it, according to the particular permissions placed on that object. Even in co-operative groups, in face of different opinions presented by the participants, some decisions must be resolved by means of voting. In AGAP support is present for voting on any kind of decision, by means of a general but easy customizable voting tool. On each vote the central unit acts as the manager, imposing the agreed upon rules, and as the counter, presenting the voting results when the vote ends. However, in this version of the system there is no automatic linking of voting results to actions to be performed by the central unit. This allows the votes to be advisory, rather than mandatory. Several voting methodologies are available in the system, to be chosen by the participants of each voting process. From “standard” majority voting, to multiple votes, point allocation and preference voting, different ways of accessing individual preferences are present, to be used at the choice of the group. Unequal voting conditions can be assigned to each participant, and the central unit can use one of several accounting methods to arrive at the final result. Other voting options available to the users regard the secrecy (or no) of individual votes, the conditions for ending the vote (e.g. by a time limit) or for considering a vote as valid (e.g. a threshold on the number of voters/or votes may be required). Some decision process related information is also stored and handled by the system. The main purpose of this information is to enforce decision process-wide rules and restrictions, and also to facilitate the system usage by defining defaults adequate to that decision process. Thus, group and personal defaults can be associated with a particular decision process, so the user may, for instance, send the usual kinds of messages to the group with the least hassle. More strongly, constraints associated with a particular decision process may be enforced, for instance restraining every user of the system not in that particular decision process from accessing process information. Other group support mechanisms, such as routing a message through several users or scheduling of events, are yet to be implemented.
4. INFORMATION SHARING “INTERNALS” To implement the mechanisms described before, some internal structures had to be developed. We will now take a closer look at these structures, namely at document encapsulation (DOCs), permissions, data replication mechanisms and decision process related information. An AGAP user must handle lots of diverse information, usually stored in a relational database. The direct manipulation of those tables and rows by the end user will be usually difficult and unrewarding for her. To help limit the need to refer directly to the stored data, a semantic level was created over the data stored in the databases. This semantic level acts by encapsulation related information in a “bundle” with a unique ID and some significance. Notice that this encapsulation stops short of the usual object oriented, as no support for procedural knowledge is present. The general DOC model is presented in Figure 2. A DOC refers to the actual information, i.e. of tuples stored in relational tables in databases, and can also refer to other DOCs, that are needed to handle those tuples. Thus, DOCs create a hierarchy of objects. Each DOC contains also information needed to perform version and access control. A particular tuple is part of only one DOC, so that each particular information is part of only one DOC. The same DOC however can be referred by several DOCs, and as such the overall structure is of a lattice (in an ideal use) or of a mesh (in actual unrestricted use) of DOCs.
Data Diccionary Tables Fields Keys
DOC Structures DOC contents DOC access DOC dependencies
Data
DOC Distribution DOC shared list DOCs to be sent
Figure 2 - DOC general model
Each DOC is stored in relational databases. Thus it needs an auxiliary mechanism to refer to “common” data tuples, also stored in relational tables. For this purpose, a data dictionary is kept and used. Each reference on the DOCs to common data uses the data dictionary, which allows the DOC to be independent from the actual information storage, on both structure and location. To further this independence, all references to shared data must go through DOCs. The data dictionary tries to describe the different data tables used in the system, and provide an adapting way to match the DOCs with the actual information stored. Regardless of differences in data storing, the data dictionary hides those changes from the DOCs built. Small differences between the data dictionaries on the central unit and the work stations can even allow different organization of data between the two subsystems, but the benefits of that option must be trade-off with the added complexity and updating costs for the system. The DOCs are the bases of information interchange in the AGAP system. All the information that passes between the central unit and the work stations is “enclosed” in DOCs. A particular DOC can refer to other DOCs that are needed for understanding the first one. When a DOC that refers to other DOCs is shared, the ones referred to must also be shared. However, different access permissions may be placed on each DOC that comprise the whole information. Some form of automatic checking on global access permissions may be needed to insure that the DOCs shared are in a consistent state, regarding their access permissions, but that is still not implemented in the current version of the system. Each DOC that is to be explicitly shared between users is transmitted to the central unit, where it is stored and placed on outbound queues, awaiting connection of their designated users. A DOC that is to be shared but without a explicit destination user or group designed, is stored in a common storage area on the central unit, where the users will be able to check it and request it if needed, according to its access permissions. The check on the access permissions is always made by the central unit, as it is understood that a particular work station may be compromised, and as such should never have access to information its owner is not allowed to possess. Consistency of DOCs regarding the changes on their underlying data is taken care of by version control. Each DOC has version information, that can be used by the central unit in conjunction with a log that records which user has which version of which DOC, to force the updating of the versions of each user to the latest current one known by the central unit, upon connection of that user. Information that is shared and that has access permissions allowing several users to make changes must be controlled by the central unit, to ensure that two users don't undertake modifications at the same time, causing consistency problems. That control will use timed semaphores, to achieve in effect a “lease” of a ticket that allows change on information regarding a particular DOC. The ticket will expire after a certain time, thus decreasing the chances of deadlock or denial of service. It can be renewed, allowing for extended working periods. However, long change periods may make wiser that a copy of the DOC will be used (for instance, a new case on a project) rather than working on the original data. Unfortunately, the automatic updating of the contents will be more difficult to assure with this kind of option. As an example of DOC usage, Figure 3 presents a couple of DOCs, and related information. DOC1 refers to the data regarding a particular plant expansion project. It contains links to the project authors, and scenario information (including project duration and Value Added Tax rate to be used). It also refers another DOC (DOC2, case information associated with that project). The reference of another DOC implies that the information referred by that DOC is somehow needed to the full handling of the referrer DOC (and as such must be transferred when that DOC is used, and so on). DOCs are also the bases of shared information access control. Associated with them are information permissions that describe the kind of access allowed to each particular kind of information (to each DOC). As such, some users cannot access a DOC; others can read the contents of that DOC; others still can change its contents. The authorization information created is subgroup based. It allows the owner of an information create groups and associate permission levels with those groups.
DOC 1
DOC 2
Project 1 (Plant Expansion Project)
refers
Case 1 (minimum budget case)
Net Present Value
contains contains
contains Authors
Scenario
contains
contains
João Lopes
Duration
Secundino Costa
V.A.T. rate
Data Series
Figure 3 – a DOC usage example
Some problems with the DOC architecture
The DOC structure, although it can partially achieve the proposed goals, is not general enough, and has some important failure modes, namely regarding complex data chains, and lack of local consistency. It is also hardly adequate to control synchronous complex manipulation of a group procedure, since it may be bulky (a single DOC may be distributed throughout several tuples in several tables) and therefore possibly slow to access. The strictly hierarchic structure of DOC chains is not particularly well suited to represent complex projects, where the same DOCs may be used on different places, with different contributing data. Within a strictly hierarchic model, that data may be replicated on this occasion, but it will then lose its identity, losing functions like automatic updating. The authorization information associated with each DOC is subgroup based, so a potential problem is the existence of conflicting permissions for a user that is member of several groups. It is possible in this model for the DOC hierarchy to become corrupt, since its different local instances aren't strongly bound. A partial update on the DOC structure may happen, since each DOC is treated individually, even when it is part of a larger complex structure. The strongly persistent nature of the DOCs, more precisely its reliance on a database as persistence mechanism makes it ill suited to be a dynamic structure, that may be frequently updated, and even change its structure, for instance during an interactive manipulation of a graphic or other means of group interaction.
5. OTHER MODELS UNDER DEVELOPMENT To address the problems stated, and in evolving the model we analyzed several potential alternatives to the DOC structure from the more elaborate Distributed Databases and Group Communication Platforms (like the ones presented in [2][12] and [18]). We also examined the Resource Reservation approaches (see [13]) and Distributed Objects (using a distributed objects infrastructure like DCOM or CORBA – see [4]). However, the general shortcomings of the elaborate solutions to the task at hand (namely the inability to handle easily the asynchronous operation of the system), made us focus on the distributed objects approach. On distributed systems study, persistence of a data object may be defined as the period of time during which this object is usable (see [1]). It can be argued that only information with complex data structures may need a persistence support above the one achieved by standard storage means, like databases (see [14]). We argue that the data structures needed for distributed group support systems benefit from that higher level of structure, and as such persistent support should be provided. In this approach, we are trying to implement the basis for persistent information storage, while allowing for change and easy control of common actions. We will investigate the use of a resource reservation approach on the distributed information, without trying to implement the full persistence proprieties expected of “real-time” systems.
The distributed objects will handle all the information access and interchange. The stored information will be enhanced, allowing for more complex structures, including possibly procedural information. The freedom that the use of a basic approach like distributed objects allows must be paid for on increased development costs, as most of the work must be made from the scratch. Nevertheless, we will try to reuse, whenever possible, previously proven solutions to the problems at hand. Changing the DOCs – the DOC2 model
We therefore suggest changing the DOC model proposed before to one that can be modeled using distributed objects with persistence. A simple model may be created changing the DOC infrastructure by a dynamic structure, composed of objects with the functions of the original DOCs. We call each of these new objects DOC2. Each DOC2 manages an information bundle, much like the original DOC, handling the access control and version control on that particular piece of information. A particular DOC2 may not transverse different work stations (it is not an mobile agent), it can however be replicated in each workstation that has a need for it. As in the DOC model, the dependencies between particular DOCs must be kept. Several kinds of dependencies may exist (a DOC may be needed for updating other, a DOC may be needed to be compared to another, etc.). These different kinds may be kept on another object, with differentiated methods and properties according to the dependence type. Again, version information must be kept on these objects. To model complex structures, that may be comprised of many DOC2 and with complex dependencies between them, a new structure is proposed. The “name” is an archetype of a frequently used structure as a set of DOC2 and dependencies (it should be able to describe all common structures, from the projects that are analyzed to a single used to describe a particular value). The internal description of those structures may be fixed or have conditionally added information. The “name” will have methods that will force the creation of the different DOC2 and dependencies, according to the internal description, whenever that particular complex structure is needed. All of these objects will refer to persistent data, that may be kept on a standard relational database, or on whatever kind of data structure is deemed useful. (Distributed) Services to be implemented
The DOC2 infrastructure described previously is based on objects that may exist on the central unit or on a workstation. However, to allow the system to be useful on both the synchronous (group usage) and asynchronous (local usage) situation, the services needed on the single user decision support must be available even when no contact is possible with the central unit or the other work stations. As such, at least some of the services that would be logically centralized must be replicated on each work station. A distributed objects infrastructure like CORBA (see [5]), or DCOM may provide support for distributed usage of those objects. We found that the standard “distributed communication platforms” being proposed to help the creation of group communication systems (like Ensemble[10], Horus[2] or Totem[11]) are geared to the synchronous mode of operation of the system, and as such little or no help is provided to create systems with both local (asynchronous) and group (synchronous) operation. As a minimum, we can identify a core functionality, provided by DOC2 / dependencies objects, a data reference module, a “name” usage module and possibly a “name” creation module. This core functionality is needed even when the system is being used to provide just local/individual decision support, and as such it must be implemented on each local work station. Other services are needed mostly when the system is being used as a group decision tool, like a object reservation manager (needed to guarantee coherence on the “name” space and the DOC2 / dependencies between work stations). Also, effects of the actions that are made on the local level must be distributed throughout the system to the central unit and work stations affected by those changes. The data reference module takes the role of the Data Dictionary on the DOC model, but may also be used to provide access to information with complex structure by itself. The data reference module service could be incorporated into the DOC2 structure, but its separation allows some independence from a particular work station implementation of the base data structure (again the trade-off between flexibility and development/management cost must be take into account in actual implementation of the model). The object reservation manager to be implemented will use calendars to manage access to each distributed resource. Only a central manager is needed, although a coalition of resource managers could also be used as shown in [13]. Implementation Issues
The proposed communication mechanism between DOC2 / dependencies that belong to different work stations is simply the remote invocation of the distributed objects. In this way, we intend to use the communication facilities of the distributed objects infrastructure, without having to duplicate it. As an example, a DOC2 factory on a work station may be remotely started to provide a new DOC2 (potentially a replica of one existing on another work station or the central unit).
On a general note, the remote invocation mechanism may be used whenever there is the need to communicate between different work stations, or between those and the central unit. However, care must be taken, since the packing and unpacking of information to communicate it between systems (“marshaling”) may create performance difficulties when massive data is being replicated. On this situation, a custom data transfer mechanism may be better suited. The distributed objects base of the DOC2 model still leaves some questions to be addressed. We present them here, along with some potential solutions. Unlike the DOC model, the persistency of the objects (DOC2 / dependencies) is not assured between invocations. A persistency mechanism must be created to support it (which can be easily done if, for instance, the objects are created on a language like Java, but harder to achieve with other implementation choices). The asynchronous creation of DOC2 and dependencies may not create problems of identity duplication, however care must be taken not to create duplicates in the “name” space. A trivial solution uses the object reservation manager on the central unit to serialize the “name” creation tasks, with the local “name” creators having only a smaller (reference) function. The increase on the DOC2 expressive power on dependencies allowed by the “names” may create the possibility of “crossdependencies” between DOC2, which in turn may lead to deadlocks on version updates or similar operations. Possibly a “sanity check” of the “name” space may be needed on the actual usage of the system The access control on shared information may be done through the DOC2, however that can create problems of local consistency, with some information needed (according to a “name”) not directly accessible. However, as the same DOC2 may belong to more than a single “name”, the logical solution to move the access control to the “name” level does not work either. The best choice may be to keep the access control at a DOC2 level, coupled with some “sanity rules” on the “name” space as a whole.
6. CONCLUSIONS AND FUTURE DEVELOPMENTS In this paper we addressed the issue of the distributed data communication needs of distributed group support systems. We presented parts of the AGAP system, a GDSS being developed by our group, and the design decisions that were adopted to provide distributed data for synchronous and asynchronous usage. The DOC model, a solution based on local databases for persistency was presented, and its advantages (allowing for a simple and complex grouping of related information in a way that permits its distribution, access and version control) and problems (inflexibility, bulk, unreliability and insufficient expressive power) were stated. An alternative model under study (DOC2) was also presented, along with its structure. Its advantages over the DOC model (including flexibility, consistency, as well as the creation of a new “archetype” structure) were presented. Some potential problems (namely persistency, performance and internal coherence in actual usage) were also introduced. The continuous evolution of AGAP system will try to address the shortcomings described in the present system, by means of the implementation and evolution of the DOC2 architecture. As the information exchanged in the system may be of a confidential nature and can travel over an “open” and unsafe network, secure data communication techniques may be implemented (as referred to in [8], [15]). The work presented here was partially supported by PRAXIS, under grant PRAXIS/PCSH/C/CEG/28/96.
7. REFERENCES [1]
M. P. Atkinson, P. Bailey, K. Chisholm, W. P. Cockshott and R. Morrison, “An approach to persistent programming”, The Computer Journal, Vol. 26, No. 4, 1983, pp. 360-365.
[2]
K. Birman, “The process group approach to reliable distributed computing”, Communications of the ACM, Vol. 36, No. 12, 1993, pp. 37-53.
[3]
M. Buretta, Data replication: tools and techniques for managing distributed information, New York, Wiley Computer Publishing, 1997.
[4]
P. Chung, Y. Huang, S. Yajnik, D. Liang, J. Shih, C. Wang and Y. Wang, “DCOM and CORBA Side by Side, Step by Step, and Layer by Layer”, http://www.research.att.com/~ymwang/papers/HTML/DCOMnCORBA/S.html, September 1997.
[5]
CORBA, The Common Object Request http://www.omg.org/corba/corbaiiop.html, July 1998.
[6]
J. P. Costa, P. Melo, P. Godinho and L. Dias, “The design of a GDSS for project analysis and evaluation: the AGAP system”, in Proceedings of the ITI'98, 20th International Conference on Information Technology and Interfaces, D. Kalpic e V. Dobric (eds), Pula, Croatia, 1998, pp. 297-302.
[7]
G. DeSanctis and B. Gallupe, “A foundation for the Study of Group Decision Support Systems”, Management Science, Vol. 33, No. 5, 1987, pp. 589-610.
Broker:
Architecture
and
Specification,
Revision
2.2,
[8]
B. Gavish, J. Gerdes and S. Shridar, “CM3 a distributed group decision support system”, IEE Transactions, Vol. 27, 1995, pp. 722-733.
[9]
B. Gavish and J. Gerdes, “Anonymous mechanisms in group decision support systems communication”, Decision Support Systems, Vol. 23, No. 4, 1998, pp. 297-328.
[10] M. Hayden, The Ensemble System, PhD. Thesis, Cornell University, 1998. [11] L E Moser, D. Agarwal, C. Lingley-Papadopoulos, P. Melliar-Smith, and R. Budhia, “Totem, a fault-tolerant multicast group communication system”, Communications of the ACM, Vol. 39, No. 4, 1996, pp. 54-63. [12] D. Powell (editor), special section on “Group Communication”, Communications of the ACM, Vol. 39, No. 4, 1996, pp. 50-53. [13] R. Ramamoorthi, A. Rifkin, B. Dimitrov and K. M. Chandy, “A General Resource Reservation Framework for Scientific Computing”, http://www.cs.caltech.edu/~adam/papers/iscope/, 1997. [14] M. M. Silva, “Mobility and Persistence” in Mobile Object Systems, Lecture Notes in Computer Science, 1222, Springer-Verlag, 1997. [15] L. Tung and E. Turban, “A proposed research framework for distributed group support systems”, Decision Support Systems, Vol. 23, No. 2, 1998, pp. 175-188. [16] M. Turoff, S. Hiltz, A. Bahgat and A. Rana, “Distributed Group Support Systems”, MIS Quarterly, Vol. 17, No. 4, 1993, pp. 399417. [17] J. Valacich and L. Jessup (eds.), Group Support Systems: New Perspectives, Macmillan Publishing Co. 1993. [18] R. Van Renesse, K. Birman and S. Maffeis, “Horus, a flexible group communication system”, Communications of the ACM, Vol. 39, No. 4, 1996, pp. 76-83.
