System support for object groups

  • Authors:

  • Rachid Guerraoui;Pascal Felber;Benoît Garbinato;Karim Mazouni

  • Affiliations:

  • Computer Science Department, Swiss Federal Institute of Technology, CH-1015, Lausanne, Switzerland;Computer Science Department, Swiss Federal Institute of Technology, CH-1015, Lausanne, Switzerland;Computer Science Department, Swiss Federal Institute of Technology, CH-1015, Lausanne, Switzerland;Computer Science Department, Swiss Federal Institute of Technology, CH-1015, Lausanne, Switzerland

  • Venue:
  • Proceedings of the 13th ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications
  • Year:
  • 1998

Quantified Score

Hi-index 0.01

Visualization

Abstract

This paper draws several observations from our experiences in building support for object groups. These observations actually go beyond our experiences and may apply to many other developments of object based distributed systems.Our first experience aimed at building support for Smalltalk object replication using the Isis process group toolkit. It was quite easy to achieve group transparency but we were confronted with a strong mismatch between the rigidity of the process group model and the flexible nature of object interactions. Consequently, we decided to build our own object oriented protocol framework, specifically dedicated to support object groups (instead of using a process group toolkit). We built our framework in such a way that basic distributed protocols, such as failure detection and multicasts, are considered as first class entities, directly accessible to the programmers. To achieve flexible and dynamic protocol composition, we had to go beyond inheritance and objectify distributed algorithms.Our second experience consisted in building a CORBA service aimed at managing group of objects written on different languages and running on different platforms. This experience revealed a mismatch between the asynchrony of group protocols and the synchrony of standard CORBA interaction mechanisms, which limited the portability of our CORBA object group service. We restricted the impact of this mismatch by encapsulating asynchrony issues inside a specific messaging sub-service.We dissect the cost of object group transparency in our various implementations, and we point out the recurrent sources of overheads, namely message indirection, marshaling/unmarshaling and strong consistency.