Group Orientation: a Paradigm for Modern Distributed Systems Introduction

Group Orientation: a Paradigm for Mo dern Distributed Systems Paulo Verssimo Lus Ro drigues Werner Vogels [email protected] [email protected] [email protected] Tech. Univ. of Lisb oa Tech. Univ. of Lisb oa IST - INESC IST - INESC INESC Abstract of consistency, user-friendliness, p erformance and de- p endability. When lo oking at the several classes of distributed Increasing use of distributed systems, with the cor- activities that may take place in a distributed system, responding decentralisation, stimulates the need for the group concept app ears intuitively: when a group structuring activities around groups of participants, of participants co op erate in an activity (e.g. manage- for reasons of consistency, user-friend liness, perfor- ment of a fragmented database, distributed do cument mance and dependability. Although there is a signi - pro cessing or distributed pro cess control), comp ete in cant number of group communication protocolsinthe an activity (e.g. to share a given resource), or execute literature, they arepenetrating too slow ly in operating a replicated activity for p erformance or fault-tolerance systems technology. Two important reasons are: the reasons (e.g. replicated database server, replicated ac- literal interpretation general ly made of the end-to-end tuator). argument, and the lack of a layer mapping end-user needs (management of replication, competition, coop- Group-orientation, as a general rule, do es not imply eration and group membership) into what is general ly group-oriented programming for the end user. That providedbythecommunication layer: agreement and is, group to ols can help the programmer build appli- order properties. cations where groups are visible , b ecause they are part of the problem sp eci cation. However, they mayal- The paper discusses both problems, proposing ways so b e useful to implement system supp ort function- for structuring systems and de ning building blocks s used transparently by the programmer, that is, in for group-oriented activity, using concepts like objec- an invisible way. In fact, the utility of groups p er- tgroups. It suggests that the group concept should vades all layers of a distributed architecture, from pervade the whole architecture, from network multi- multicasting network infrastructures, through group casting, to group communications and management. communication and memb ership, to the group activi- Emerging technology wil l help materialise these con- ty management services. They may b e at the core of cepts. ecient implementations at several levels of abstrac- tion: op erating system (e.g. microkernel p ort group management), internetworking (e.g. routing and state Intro duction dissemination and management of groups of router- s), distribution supp ort (e.g. replication management, The increasing use of distributed systems is in part distributed lo cks), applications (e.g. co op erativeedi- due to the requirements of inherently decentralised tors, teleconferencing, manufacturing cells). In some activities, such as computer supp orted collab orative applications, the end user will not see groups at al- working, or distributed computer control. It b ecomes l, reasoning in terms of ob ject invo cations, RPCs, then natural for a numberofsuch computations to b e and so forth. However, underlying that users's pro- structured around groups of participants, for reasons gramming environment, groups may b e ful lling their r^ole in transparently supp orting a distributed shared Instituto de Engenharia de Sistemas e Computadores,R. o memory mechanism, a replicated ob ject mapp er, a dis- Alves Redol, 9 - 6 - 1000 Lisb oa - Portugal, Tel.+351-1- 3100281. This work has b een supp orted in part by the CEC, tributed lo ck manager, etc. through Esprit Pro jects BROADCAST and DINAS, and JNIC- Regardless of the current prep onderance of other T, through Programs Ci^encia and STRIDE. This pap er is an ex- paradigms, other than group-orientation, for program- tended and revised version of a pap er that app eared in Pro cs of the ACM SIGOPS 1992 Workshop, MontSaint Michel-France. ming distributed applications, a few observations are The combined notion of object and group may provide in order: designers and programmers with a suitable framework Real-time { or responsive { systems deal with to achieve those ob jectives. Practically all works cited the environment, thus handling of events is in- ab ovehave addressed a part of the problem, and a few evitable. In event-driven systems, events \travel" of them have tried to systematise solutions. inside the (distributed) system in the form of mes- In this pap er, we discuss how to structure groups sages, or message-interrupts, b efore b eing trans- in distributed systems, from networking to application formed. There is a numb er of applications b eing supp ort. Westartby dissecting two main arguments b etter addressed in the domain of events [40]; against using groups: the end-to-end argumentand group visibility.We continue bypresenting an overall in highly concurrent and/or interactive system- picture of the necessary building blo cks of a group- s (e.g. collab orative group work or distributed oriented system, then detailing eachoftheblocks. Fi- computer control) message-passing paradigms are nally,we do a discussion ab out programming over a necessary; group-oriented system, either with group visibilityor remote pro cedure call, b eing blo cking, unilater- not. al and asymmetric (client-to-server), has some shortcomings, more evident in the kind of systems just mentioned; it should b e complemented with The arguments against groups paradigms supp orting multilateral, non-blo cking 1 and p eer-to-p eer interactions . An existing reluctance to having services with high These observations lead us to the conclusion that a quality (e.g. reliable multicast) provided o -the-shelf distributed computing platform can only b ene t from in a system, has b een related to the literal interpreta- the co existence of remote-op eration based paradigms, tion often made of the end-to-end argument [35]. In such as RPCs, with message-passing, di usion-based fact, the argument is against providing more func- ones, such as group proto cols. This, without denying tionality than needed at a given layer of a system, the validity and usefulness of either one. b ecause this go es against optimising eciency,risks The requirements of highly distributed activities intro ducing redundant proto col actions like error re- are not adequately satis ed by the basic interfaces covery steps, and ultimately, go es against go o d sense. traditionally supplied as\distribution supp ort", such Nevertheless, if a class of applications requires a cer- as \so ckets" or \streams": these are semantically to o tain functionality (or quality of service), however com- p o or, and most of them are not multi-participant. plex it may b e, the lower layer or more generally the Building blo cks for group activityhave b een studied operating system support, should provide it. It frees in the past in pioneering pro jects suchastheV-kernel the user from programming it, and will probably have [11], ISIS at Cornell [5], the Circus pro ject [12], and b een optimised and widely tested when supplied with also [1,19]. They are currently the sub ject of great in- a system. terest, illustrated by pro jects as the PSYNC/x-Kernel In fact, a numb er of classes of distributed activities workatUniv. of Arizona [29], the workonobjec- can b e de ned whose requirements are solved bya t groups by ANSA [3], the work of Molina [27], the set of distributed algorithms. In that case, supplying IBM ight control AAS [17], the Europ ean DELTA-4 a suite of the corresp onding proto cols is in essence a pro ject [30], the work ab out groups in Arjuna [23], the correct interpretation of the end-to-end argument, if currentwork on Isis/Horus [31]. done in a way such that the users not requiring them In order for applications with high levels of concur- are not p enalised by their existence. This reasoning rency to b e correctly designed, have acceptable p erfor- applies to all levels of the architecture, from network mance, and remain op erational for long enough, what- hardware through communications to computing. ever distribution supp ort environment to b e conceived One such \semantically-loaded" class of proto col- must combine: encapsulation, mo dularity and diversi- s is that of group communication. Though there is ty; fault tolerance and timeliness; distributed algorith- a signi cant b o dy of research in this area, they have mics; supp ort for actions and data (events and state). had a slow p enetration in op erating system technolo- 1 Engineering-wise, some of these problems have of course gy.We are convinced that there is a ma jor reason for b een solved long ago one way or the other (replicated RPC, this fact, b eyond the end-to-end argument one: vis- "asynchronous" RPC or RSR, calling pro cess fork, etc.). How- ibility of the group communication protocols is often ever, they should b e prop erly addressed at the mo del level, if awkward for the applications programmer. It is nec- p ossible. ing and co op eration. User User User Applic. Applic. Applic. AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA

Load more