海量文库 文档专家
当前位置:首页 >> >>

A CORBA Platform for Component Groupware

A CORBA Platform for Component Groupware
G. Henri ter Hofte, Hermen J. van der Lugt, Harm Bakker Telematics Research Centre, the Netherlands E-mail: {H.terHofte, H.vanderLugt, H.Bakker}@trc.nl Abstract
The next generation of CSCW systems should be component-based. Such systems consist of independently developed groupware components (i.e. CSCW software components) which users can pick and mix to obtain a groupware application environment tailored to their needs. To support developers in achieving this, groupware platforms should be based on CORBA, an emerging industry standard for distributed object computing. In this paper, we describe the rationale for a platform for component groupware and the extensions CORBA requires for such a platform. We briefly describe our experiences with the design and implementation of a prototype of such a platform.

1. Problems with current groupware
Many cooperative work situations require comprehensive and flexible technological support. It ranges from support for synchronous collaboration to support for asynchronous collaboration [2, 8]. Moreover, a large variety of media types should be supported, varying from discrete media such as text and graphics, to continuous media such as audio and video. Compared to development of single-user applications, development of groupware applications involves many additional technical issues from distributed systems development, such as replication, consistency, concurrency, and communication protocols. Due to these extensive requirements and the complexity of groupware development, up to now, users often end up with support for very limited collaborative tasks and have to deal with a lack of integration of groupware applications [3], if more complex collaborations are to be supported.

2. Component Groupware
Groupware systems that consist of independently developed groupware components provide an important solution to these problems. These component-based systems can both provide the power of isolated tools and the virtues of integration and migration. Component groupware enables users to pick their favourite groupware components and mix them into a suitable groupware application environment. This requires well-defined program interfaces between different groupware components, enabling component interworking (possibly between components of different vendors). Each groupware component typically consists of interworking component entities located at different interconnected computer systems. This requires well-defined groupware component protocols. Preferably, the interfaces and protocols are open and standardized. Moreover, component groupware enables component-by-component migration. Users could start with a groupware application environment where existing single-user applications are combined with collaborative platform features to become groupware components that support primitive forms of collaboration (such as file sharing and user interface sharing). Then, the environment can migrate, component-by-component, towards a groupware application environment that consists of groupware components that support more media types, various modes of collaboration, and transitions between these modes.

TRC/SS/96016, Accepted for the OZCHI’96 workshop on the Next Generation of CSCW systems, November 25, 1996


3. Platform
In order to realize the full potential of component groupware, we need a platform to support development of groupware components based on a high-level groupware software architecture. The high-level groupware software architecture should distinguish different classes of groupware components, their combinatory possibilities and their interworking. We propose, inspired by the Co4 model of groupware functionality [10], an architecture which distinguishes four classes of groupware components: x conference management components; x shared workspace components; x conversation channel components; x coordination support components. A platform for component groupware allows developers to abstract from generic issues, by providing reuse of generic functionality that is embodied in the platform. It allows developers to concentrate on the important details of their particular groupware component. The platform should support construction and interworking of the identified component classes. Ideally, such a platform should be based on standards for distributed systems and groupware.

4. Using CORBA to Support Groupware
The Common Object Request Broker Architecture (CORBA) is one of the most widely supported emerging standards for Distributed Object Computing [15]. It can be of great value to a platform for component groupware: x CORBA supports basic interworking between objects implemented in different programming languages. For this purpose, developers specify object interfaces in the standardized CORBA Interface Definition Language (IDL). Method invocations between objects are mediated by an Object Request Broker (ORB). CORBA allows for the construction of software components from (a number of) objects and facilitates interworking of such components. x CORBA also supports interworking between objects across network boundaries by providing transparent invocation of methods on remote objects, while hiding, if necessary, low-level details such as communication protocols, transport encodings, concurrency, and bridging heterogeneity in operating systems and programming languages. However, CORBA (like other contemporary platforms for Distributed Object Computing) lacks adequate support for groupware issues. Groupware platforms, such as GroupKit, Rendezvous, MEAD, IBM Lakes and Prospero (for overviews, we refer to [7, 20]), on the other hand, do address these issues, but rarely provide support for component software and are rarely based on standards. Recent research on CORBA-based groupware [4, 12] and group communication-based groupware [18, 19, 9], and research into combining CORBA and group communication [13] indicates that a combination of CORBA, group communication and groupware is a very promising approach for platforms for component groupware.

5. Extending CORBA for Groupware
In the Platinum1 project [16] we designed and built a prototype of a CORBA-based platform for component groupware. Based on our experiences, we propose that CORBA should be extended with the concept Object Group (§5.1), that ORB support for object groups should be provided (§5.2) and that CORBA facilities should be created for conference management components (§5.3), shared workspace components (§5.4), conversation space components (§5.5) and coordination support components (the latter is left for further study).

1 A joint research project on multimedia groupware over broadband networks (http://www.trc.nl/projects/platinum.htm), in which Lucent Technologies, the Telematics Research Centre, the University of Twente and Deutsche Telekom participated.

TRC/SS/96016, Accepted for the OZCHI’96 workshop on the Next Generation of CSCW systems, November 25, 1996


5.1 Object Groups in Groupware Typical patterns of interaction occurring in groupware systems are easily implemented with object groups [11], a concept originating from fault tolerant computing. An Object Group consists of a number of replicas: the member objects. To the world outside the group, an object group behaves as if it were a single object. A method invocation on an object group is invoked on all replicas. This ensures state changes are applied to all object replicas. Thus, a high availability of an object’s state can be achieved, even if some members are not available due to faults such as system or network crashes. A groupware system can be modelled as a distributed computer system with multiple user interfaces, each providing representation and manipulation of some shared artefact, be it a shared document, a textual discussion, or a workflow. Each user interface reflects the actions of its user. Due to different actions by different users, the interfaces diverge, and sooner or later, the system will synchronize the user interfaces so they not only reflect a user’s own actions (feedback), but also the actions of other users (feedthrough). A typical pattern of interaction in such a groupware system, as illustrated in Figure 1, is an invocation, triggered by a user action, that needs to be invoked “simultaneously” on a number of objects, each containing a replica of the shared artefact located at a users’ site, in order to change the state of the shared artefact globally. Here, an object group can be used for the objects containing the shared artefact.
s ite A S h a red a retefa c t o b jec t g ro u p (c o u p led o b jec t g ro u p ) s ite B

U s er in terfa c e o b jec ts (u n c o u p led o b jec t g ro u p )

Figure 1 Typical use of Object Groups 5.2 Multicast Object Request Broker Platform support for such Object Groups should be provided by a Multicast Object Request Broker (MORB). It should provide generic support for multicasting object invocations, multipoint ordering services, response collation, object group membership management and state transfer for newcomers. In addition to these services from the fault-tolerant domain, it should support services such as coupling and uncoupling object groups (see also §5.4), parallel versions support (intentionally diverged replicas) and version merging support (synchronizing diverged replicas). MORBs could evolve from current ORBs by replacing the transport layer with one that supports multicast RPCs, as done in Orbix+ISIS and Electra [13], or by connecting two ORBs with an inter-ORB multicasting bridge, an approach we followed in the Platinum project. 5.3 Conference Management Facility Conferences consist of a number of participants (users), media (shared workspaces and conversation spaces) and coordination policies (such as a floor control policy). Conference Management functions, which manage associations between a number of users, shared workspaces, conversation spaces and coordination policies, are the multi-user CSCW equivalent of single-user desktop and window management functions, which manage associations between one user, applications and files. Conference Management functions include functions such as create, terminate, join, leave, add medium, delete medium, add coordination policy, delete coordination

TRC/SS/96016, Accepted for the OZCHI’96 workshop on the Next Generation of CSCW systems, November 25, 1996


policy. More advanced functions are conference suspend and resume, conference split and merge and creation of conference hierarchies in which a conference can contain subconferences. Conference Management functions should be provided to users in a component separate from shared workspace and conversation space components, allowing reuse and uniformity of conference management functions for a wide array of conferences. However, it is unlikely that one conference management component can be used for all styles of conferences, ranging from long-lasting conferences with open participation and many participants, to short-lived conferences with closed participation and few participants. A Conference Management facility should provide reuse of generic functionality of conference management components and should ensure interworking between conference management components and other components in a conference, including other conference management components of subconferences. 5.4 Collaborative Compound Document Facility Collaborative Compound Document Editing represents an important enhancement over compound document editing. The latter was recently standardized in CORBA’s Distributed Document Component Facility (DDCF) [1], which is based on OpenDoc [15]. In compound document editing, different parts of a document, such as picture, spreadsheet and text, are edited in-place, each by its own component editor, which together act as a seamlessly integrated editor. Users can pick and mix these different components to create the editing environment suitable for their needs. New content types can easily be added to documents by adding their component editor to the environment. Whereas compound document editing already supports step-wise migration towards editing new media types, Collaborative Compound Document Editing in addition enables a step-wise migration from existing editing components (e.g., OLE applications) with limited collaborative facilities (e.g., only file and interface sharing), towards more advanced collaborative component editors. More advanced collaborative component editors typically require multiple object groups which do not always need to be “coupled”. If a level is coupled, state changes in objects at that level occur “simultaneously” for all users; if a level is not coupled, state changes in objects at that level occur in isolation, i.e. states of each member of an object group are unrelated. To enable users to selectively suppress feedthrough of actions with less profound impact, such as moving a mouse, a number of levels can be distinguished. We use four levels (from high to low: file, edit, view and user interface). With these levels, users can decide to “couple” all object groups at a certain level and all higher levels and to “uncouple” all lower levels (this is also known as the “zipper architecture” [6, 17]). Thus, users can be allowed control —per document part— over the “tightness” of collaboration support simply by coupling and uncoupling object groups. Developing collaborative component editors requires platform support in the form of a Collaborative Compound Document Facility, which extends the existing DDCF with object groups and user controllable coupling in line with the zipper architecture. The facility should also provide interworking with other kinds of groupware components, such as conference management. 5.5 Multiflow Multipoint Channel Facility CORBA currently primarily supports a request-response style of interaction, which is not suitable for support of continuous media flows with isochronous characteristics such as audio and video. In groupware, the continuous media streams typically have a multipoint character. Recently, OMG issued a Request For Proposal (RFP) on “Control and Management of A/V Streams” [14], seeking interface specifications for the control (i.e. setup, QoS (re)negotiation) of multipoint (i.e. with multiple sources and sinks) streams, consisting of multiple flows. We contend that such generic support should be provided by a multiflow multipoint channel facility, which provides interworking with other groupware components, such as conference management. The ReTINA approach [5] is an interesting starting point in this respect.

TRC/SS/96016, Accepted for the OZCHI’96 workshop on the Next Generation of CSCW systems, November 25, 1996


6. Implementation
During the Platinum project, we implemented a multicast ORB according to the inter-ORB multicasting bridge approach, based on IBM’s SOM ORB and the SOM Metaclass Framework, which provides (non-CORBAcompliant) hooks for changing a class’ method invocation mechanisms. For conference management, we implemented a (non-CORBA-compliant) conference management application. On top of the MORB, we implemented CoCoDoc, a prototype of a framework for collaborative compound document editing, which supports four document-wide levels of coupling (file, edit, view, user interface) and allows collaborative part editors to offer additional coupling levels to users. CoCoDoc is implemented as an extension of OpenDoc. Our implementation of CoCoTree, a simple collaborative compound outline editor on top of the CoCoDoc platform, confirmed that using CoCoDoc requires only minimal learning effort from OpenDoc programmers.

7. Conclusion and Open Issues
The next generation of CSCW systems needs to be component based. This requires a CORBA-based object oriented groupware platform, which supports Object Groups with a Multicast Object Request Broker (MORB), and provides CORBAfacilities for Conference Management, Collaborative Compound Documents (CoCoDoc) and Multiflow Multipoint Channels as important extensions to CORBA. Further research is needed by the CSCW and CORBA community to standardize these extensions. Some important open issues we intend to address in future research are: x What kind of platform support should be provided for coordination components? x How should existing and emerging groupware protocol standards be used, such as the ITU-T T.120 multipoint data conferencing standards?

The authors wish to thank all Platinum project participants, in particular, Raymond Otte, Ferial Moelaert, Wouter Teeuw and Maurice Houtsma.

[1] Apple Computer, Component Integration Laboratories, IBM and Novell, OMG RFP submission : Compound presentation and compound interchange facilities. Object Management Group, Framingham, MA, USA, 1995, http://www.omg.org/docs/1995/95-12-30.ps. OMG document, 95-12-30. [2] Beck, E.E. and V.M.E. Belotti, 'Informed opportunism as strategy : Supporting coordination in distributed collaborative writing'. In G. de Michelis, C. Simone and K. Schmidt (eds.), Proceedings of the third European conference on computer-supported cooperative work. Kluwer Academic, Dordrecht, NL, 1993, p. 233-248. [3] Bullen, C.V. and J.L. Bennett, 'Groupware in practice : An interpretation of work experiences'. In R.M. Baecker (ed.), Readings in groupware and computer-supported cooperative work : Assisting human-human collaboration. Morgan Kaufmann, San Mateo, CA, USA, 1993, p. 69-84. [4] Costa, F.M. and E.R.M. Madeirea, 'An object model and its implementation to support cooperative applications on CORBA'. In A. Schill, C. Mittasch, O. Spaniol, et al. (eds.), Distributed Platforms : Proceedings of IFIP/IEEE international conference on distributed platforms. Chapman & Hall, London, UK, 1996, p. 213-228.

TRC/SS/96016, Accepted for the OZCHI’96 workshop on the Next Generation of CSCW systems, November 25, 1996


[5] Dang Tran, F., V. Perebaskine, J.N. Stefani, B. Crawford, A. Kramer and D. Otway, 'Binding and streams: The ReTINA approach'. In The convergence of telecommunications and distributed computing technologies : Proceedings of TINA'96 conference in Heidelberg, Germany, September 3-5, 1996. VDE, German Association of Electrical Engineers, Berlin, D, 1996, p. 101-113. [6] Dewan, P. ‘Multiuser architectures’ In C. Unger and L.J. Bass (eds.), Engineering for HCI (Proceedings of the IFIP WG2.7 Working Conference on Engineering for Human-Computer Interaction in Grand Targhee Resort, Wyoming, USA, August 14-18, 1995. Chapman & Hall, London, UK, 1996, p. 247-270, ftp://ftp.cs.unc.edu/pub/users/dewan/papers/arch.ps.Z [7] Dourish, P., Open implementation and flexibility in CSCW toolkits. Ph.D. Thesis, University College London, 1996, ftp://cs.ucl.ac.uk/darpa/jpd/dourish-thesis.ps.gz. [8] Dourish, P. and V.M.E. Belotti, 'Awareness and coordination in shared workspaces'. In J. Turner and R.E. Kraut (eds.), CSCW'92 : Proceedings of the conference on computer-supported cooperative work, Oct. 31 to Nov. 4 1992, Toronto, Canada. ACM, NY, 1992, p. 107-114. [9] Farooqui, K., Group communication models, in press [to be published in Computer Communications Journal, 1997; also available via author's web homepage], http://www.csi.uottawa.ca/~farooqui. [10] ter Hofte, G.H., H.J. van der Lugt and M.A.W. Houtsma, Co4, a comprehensive model for groupware functionality, 1996. TRC Scientific Series, SS/96002 [to be published in Proceedings of the APTEC conference of Euromedia'96, held December 19-21, 1996 in London, UK. The Society for Computer Simulation, in press]. [11] ISIS Distributed Systems, Inc. Object groups : A response to the ORB 2.0 RFI. Object Management Group, Framingham, MA, USA, 1993, OMG document, 93-04-01, http://www.omg.org/docs/1993/93-04-11.ps. [12] von Lukas, U. and U. Dietrich, 'CSCW in einer CORBA-basierten CA-umgebung' [CSCW in a CORBAbased CA environment (in German)]. In H. Krcmar, H. Lewe and G. Schwabe (eds.), Herausforderung Telekooperation : Einsatzererfahrungen und L?sungsans?tze für ?konomische und ?kologische, technische und soziale Fragen undserer Gesellschaft : Proceedings of Deutsche Computer Supported Cooperative Work 1996, DCSCW'96 in Stuttgatt-Hohenheim, D, September 30-October 2, 1996. Springer-Verlag, Berlin, D, 1996, p. 225-242. [13] Maffeis, S., 'Adding group communication and fault-tolerance to CORBA'. In Proceedings of USENIX conference on object-oriented technologies (COOTS) in Monterey, CA, USA, June 26-29, 1995. USENIX association, Berkely, CA, USA, 1995, p. 136-145, ftp://ftp.cs.cornell.edu/pub/maffeis/electra/electra_corba.ps.gz. [14] Object Management Group. Control and management of A/V streams : RFP. Object Management Group, Framingham, USA, 1996, OMG doc. telecom/96-08-01, http://www.omg.org/docs/telecom/96-08-01.ps. [15] Orfali, R., D. Harkey and J. Edwards, The essential distributed objects survival guide. Wiley, NY, 1996. [16] Ouibrahim, H. and J. Schot, 'Tele-teaching and the electronic superhighway : Towards a vertical approach'. In Proceedings of IDC'95 : First international distributed conference on high-perforance networking for teleteaching in Madeira, Portugal; Madrid, Spain; Sophia Antipolis, France; Brussels, Belgium, November 16-17, 1995, 1995. [17] Patterson, J.F., 'A taxonomy of architectures for synchronous groupware applications'. SIGOIS Bulletin, 15 (April 1995), 3, p. 27-29. [18] Powell, D., 'Group communication (special issue)'. Communications of the ACM, 29 (1996), 4, p. 50-97. [19] Trevor, J.J., Infrastructure support for CSCW. Ph.D. Thesis, Lancaster University, UK, 1994, ftp://ftp.comp.lancs.ac.uk/pub/reports/ThesisGS.ps.Z. [20] Urnes, T. and R. Nejabi, Tools for implementing groupware : Survey and evaluation. Department of Computer Science, York University, North York, Ontario, Canada, 1994, Technical Report No. CS-94-03, ftp://ftp.cs.yorku.ca/pub/clock-papers/CS-94-03.ps.Z.

TRC/SS/96016, Accepted for the OZCHI’96 workshop on the Next Generation of CSCW systems, November 25, 1996



A CORBA Platform for Component Groupware.pdf

A CORBA Platform for Component Groupware_专业资料。The next generation of CSCW systems should be component-based. Such systems consist of independently ...

Management Group’s Common Object Request Broker (CORBA), ....pdf

(CORBA), Microsoft’s Distributed Component Object Model, Sun Microsystems’ ...A state in the state-space model is comdleware architecture like ...

...Group’s Common Object Request Broker Architecture (CORBA)....pdf

the Object Management Group’s Common Object Request Broker Architecture (CORBA), Microsoft’s Distributed Component Object Model (DCOM) and Java’s Remote...

MOVE: Component Groupware Foundations for Collaborative ....unkown

MOVE: Component Groupware Foundations for Collaborative Virtual Environments ... the framework is constructed on top of a middleware integration platform ...

...Adaptive Groupware Applications Using a Mobile Component ....unkown

Developing Adaptive Groupware Applications Using a Mobile Component Framework Radu Litiu and Atul Prakash Department of Electrical Engineering and Computer ...

...-based Office Space in a Call Center on a Groupware Platform.unkown

University of Paderborn Faculty of Business Studies (FB 5) Master Thesis Designing workflow-based Office Space in a Call Center on a Groupware Platform ...

Kolab and kontact as a cross platform groupware solution.unkown

Kolab and kontact as a cross platform groupware solution Abstract Describes how to install and configure kolab server and the kontact client as complete ...

Groupware Program Component 2: Sales Distribution.unkown

13, 2013 Sheet 2 0f 6 US 2013/0151381 A1 GroupWare Program Component l: Inventory Integration Retailer inventory file any format txtntswgxls 'X1111, ...

Design of extensible component-based groupware.unkown

Design of extensible component-based groupware Jakob Hummes (hummes@eurecom.fr) and Bernard Merialdo ( )merialdo@eurecom.fr Eurecom, 06904 Sophia ...

Simplifying Component Development in an Integrated Groupware ....unkown

Simplifying Component Development in an Integrated Groupware Environment Mark Roseman and Saul Greenberg Department of Computer Science, University of Calgary ...

Component-Based Groupware Development Based on the 3C ....unkown

XX Simpósio Brasileiro de Engenharia de Software Component-Based Groupware Development Based on the 3C Collaboration Model Marco Aurélio Gerosa1, Alberto ...

Design of Extensible Component-Based Groupware.unkown

53 Design of Extensible Component-Based Groupware JAKOB HUMMES and BERNARD MERIALDO Eurecom, 06904 Sophia Antipolis, France (E-mail: hummes@eurecom.fr ...

...Platform Collaboration - Transferring Real-Time Groupware ....unkown

Towards Cross-Platform Collaboration - Transferring Real-Time Groupware To The...replacing a Java based component of our Tele-Board [5] collaboration system...

Dictionary Free.unkown

Group, Map, Meaning, Pie, Quorum, Sharp

MOVE: : component groupware foundations for collaborative ....unkown

//www.researchgate.net/publication/221274295 MOVE: : component groupware ... the framework is constructed on top of a middleware integration platform ...

A Highly Customizable Tutoring-System with JavaBeans.pdf

Versioning control is offered as a Corba service, while Java supports ...5.1 Component model and IDE A component-based groupware platform needs, ...

A Component Based Workbench for Groupware Prototyping.unkown

Disponível em http://www.les.inf.puc-rio.br/groupware A Component Based Workbench for Groupware Prototyping Marco Aurélio Gerosa1 & Hugo Fuks2 1 ...

...Optimistic Virtual Synchrony to a CORBA Object Group Service.unkown

Integrating Optimistic Virtual Synchrony to a CORBA Object Group Service Gláucia de Oliveira Dias and Alba Cristina Magalhaes Alves de Melo Department of ...

oracle application server installation guide for microsoft ....unkown

Groups for Each Component ..................CORBA Communication" Section 2.12, "Cloning ...(non-XP) platform OracleAS Developer Kits ■ ...

A Group Communication Protocol for CORBA.unkown

CORBA ORB PGMP (Processor Group Membersh

网站首页 | 网站地图
All rights reserved Powered by 酷我资料网 koorio.com
copyright ©right 2014-2019。