9
Microprocessing and Microprogramming 32 (1991) 271-280 271 North-Holland LANGUAGE AND RUNTIME SUPPORT FOR DISTRIBUTED OBJECT GROUPS Alexander Schill University of Karluruhe, Institute of Telematics Am Zirkel 2, 7500 Kadsruhe, Germany Distributed object-oriented systerrm provide a natural way of representing d/utfibuted appl/ca- tion problems and offer a high level of distribution abstraction. To manage such environments, the notion of collections of objects with specific ~mnntics, i.e. ebject groups, can be very helpful and has been applied in several areas. Tho maj:~r contribution of the paper is to introduce an abstraction facility to handle common ~.,pects of distributed object groups in a uniform way. After the discussion of existing ]finds of object groups, a new approach based on language and zuntime support is presented to imple- ment this abstraction. Common issues covered by it are the the representation, instantlation and termination of groups, the handling of conflicting groups, and the application of genetic group operations like status inquiries or voluntary enrolhnent. The provided abstraction is specialized by applying it to different exa~..ples like group communication, group-based distributed object allocation, or group-based resource management. Keywords: distributed systems, distributed object co,,peration, distributed object groups, ab- straction mechanisms, language extensions, distributed runtime protocols I. I'~'I'20DUCTION z Recently, tlistdbuted object-oriented systems b3s,,d on net- worked workstation environments have be,:ome quite popular [BEN87], [B!1.187], [BLAgg]. They provide a natural way of representing distributed applicatioil problems by enabling a relatively direct mapping of entities of a problem domain to objects o! a distrilmted computer system. Objects have an internal state and a collection of operations operating on that state. They can be of very different hind and grain according to the given application, i.e. an object can be a small data item, a document, a server, or even a network node. l)i~ tributed object-hased systems offer a high level of distribution abstraction. Operation invocations on obj,,cts are I.cation in- dependent, i.e. their syntax and semantics is identical in the local and remote cause. In addition, high-level mobility oper- ations are offered which enable an object or a whole set of objects to be moved between nodes, e.g. in order to move communicating objects together dyuami¢ally. To manage such environments, the notion u[ collections of ob- jects with specific semautics, i.e. object .qro~tps, can he very helpful ",nd has been applied in several are&q. Concrete ex- amples in a workstation environment arc distributed group cmnmunicatiou support, e.g. between authors of a joint pa- per, joint placement of grouped objects at a common node, e.g. by moving several personal documents to a node where an mnployment application is processed, or gwoups of distributed sezvers with similar fnnctionality, e.g. :.~Yintservers of vat, IParts of this workhave heen performed during a researchslay at thP IBM T.J. Wat~m ResearchCenter, YorktownII~.igkts, N~¢: ~%rk. [n~ o quality, cost and speed. Possibl~ management tas~ in these examples are the instantiat~on, termination and anab ysis of communication groups, the ~lection of an appropri- ate node for group placement, and the dispatching of server invocations to an available ~rver, e.g. bxsed on service ~e- quirements and load statistics. Such management operations are particularly important in distributed workstation envi- ronments due to their significant degree of decentralization, their large amount of computing [~ower, and their increasing network integration. Previous approaches have treated distributed object groai,~s ~parately according to their given ~mantics. This h~s lead to a non-uniform terminology of group representation and management and to redundant implementations of basic group functionality. In addition, several aspects of object grouping semantics, e.g. conflicts between membe~hip of an object in different gronps at a time are still not wel|-nndemtood. Therefore, this paper introduces a unified abstraction to de- fine and manage object groups. It first di~asses different examples of object groups and points oat their major charac- teristics. Then language and runtimn support is provided to express and manage common issues of such groups. In partic- ular, common aspects and problems are group instantiation and termination protocols, the evaluation of groups according to given criteria, the handling of conflicting membership in different object groups, the management of internal rdation- ships between group members, and the provision of generic group operations like status inquiries or voluntary enro|lment. This way, basic gronp functionality is extracted and sepa-

Language and runtime support for distributed object groups

Embed Size (px)

Citation preview

Microprocessing and Microprogramming 32 (1991) 271-280 271 North-Holland

L A N G U A G E A N D R U N T I M E S U P P O R T FOR D I S T R I B U T E D O B J E C T G R O U P S

A l e x a n d e r Schill

University of Karluruhe, Institute of Telematics Am Zirkel 2, 7500 Kadsruhe, Germany

Distributed object-oriented systerrm provide a natural way of representing d/utfibuted appl/ca- tion problems and offer a high level of distribution abstraction. To manage such environments, the notion of collections of objects with specific ~mnntics, i.e. ebject groups, can be very helpful and has been applied in several areas. Tho maj:~r contribution of the paper is to introduce an abstraction facility to handle common ~.,pects of distributed object groups in a uniform way. After the discussion of existing ]finds of object groups, a new approach based on language and zuntime support is presented to imple- ment this abstraction. Common issues covered by it are the the representation, instantlation and termination of groups, the handling of conflicting groups, and the application of genetic group operations like status inquiries or voluntary enrolhnent. The provided abstraction is specialized by applying it to different exa~..ples like group communication, group-based distributed object

allocation, or group-based resource management.

K e y w o r d s : distributed systems, distributed object co,,peration, distributed object groups, ab- straction mechanisms, language extensions, distributed runtime protocols

I. I'~'I'20DUCTION z

Recently, tlistdbuted object-oriented systems b3s,,d on net- worked workstation environments have be,:ome quite popular [BEN87], [B!1.187], [BLAgg]. They provide a natural way of representing distributed applicatioil problems by enabling a relatively direct mapping of entities of a problem domain to objects o! a distrilmted computer system. Objects have an internal state and a collection of operations operating on that state. They can be of very different hind and grain according to the given application, i.e. an object can be a small data item, a document, a server, or even a network node. l)i~ tributed object-hased systems offer a high level of distribution abstraction. Operation invocations on obj,,cts are I.cation in- dependent, i.e. their syntax and semantics is identical in the local and remote cause. In addition, high-level mobility oper- ations are offered which enable an object or a whole set of objects to be moved between nodes, e.g. in order to move communicating objects together dyuami¢ally. To manage such environments, the notion u[ collections of ob- jects with specific semautics, i.e. object .qro~tps, can he very helpful ",nd has been applied in several are&q. Concrete ex- amples in a workstation environment arc distributed group cmnmunicatiou support, e.g. between authors of a joint pa- per, joint placement of grouped objects at a common node, e.g. by moving several personal documents to a node where an mnployment application is processed, or gwoups of distributed sezvers with similar fnnctionality, e.g. :.~Yint servers of vat,

IParts of this work have heen performed during a research slay at thP IBM T.J. Wat~m Research Center, Yorktown II~.igkts, N~¢: ~%rk.

[n~ o quality, cost and speed. Possibl~ management tas~ in these examples are the instantiat~on, termination and anab ysis of communication groups, the ~lection of an appropri- ate node for group placement, and the dispatching of server invocations to an available ~rver, e.g. bxsed on service ~e- quirements and load statistics. Such management operations are particularly important in distributed workstation envi- ronments due to their significant degree of decentralization, their large amount of computing [~ower, and their increasing network integration.

Previous approaches have treated distributed object groai,~s ~parately according to their given ~mantics. This h~s lead to a non-uniform terminology of group representation and management and to redundant implementations of basic group functionality. In addition, several aspects of object grouping semantics, e.g. conflicts between membe~hip of an object in different gronps at a time are still not wel|-nndemtood. Therefore, this paper introduces a unified abstraction to de- fine and manage object groups. It first di~asses different examples of object groups and points oat their major charac- teristics. Then language and runtimn support is provided to express and manage common issues of such groups. In partic- ular, common aspects and problems are group instantiation and termination protocols, the evaluation of groups according to given criteria, the handling of conflicting membership in different object groups, the management of internal rdation- ships between group members, and the provision of generic group operations like status inquiries or voluntary enro|lment. This way, basic gronp functionality is extracted and sepa-

272 A. Schill

rated from semantic-specific aspects. This enables a generic but still customizable implementation which can be used to manage very different kh~ds of groups. In addition, tools can exploit their explicit knowledge of basic grouping semantics, e.g. to support a status analysis of a group or to provide a vi- sual representation of its current participants. The provided alrstraction is specialized by applying it to different examldes like group communication, group-based distributed object al- location, or group-based resource managenmnt. This way, the extendability and customizability of the unified approach is demonstrated. In addition, an experimental prototype imple- menting the basic ideas is described.

Section 2 gives a survey of related work in the area of ,!i~- tribnted object grouping and outlines the basic motivation of the presented approach. Section 3 presents a basic framework to provide a nniform notion of object groups. In section 4, this framework is applied to several examples of group types to demonstrate its use in different semantic domains. Section 5 concludes with an outlook to filture work.

2. EXAMPLES OF DISTRIBUTED OBJECT GROUPS

To illustrate the importance of distributed object grouping, a number of examples [SMII88] will be given. All of them share the notion of having several typed members which act or which are acted upon because of their membership within a group. However, all of them also have some kil,~l of specific sem&ntics.

2.1. Distributed Group Communication

Significant work has been performed in the area of group communication between active entities of a computer sys- tem. Most of these approaches are focusing on distributed or at |east concurrent environments. The participants of a communication group are either processes or fine-grained ob- jects. The Script approach [FHT86], [EFK89] enables the representation and management of n-party communication between an arbitrary number of operating system processes. A script defines a group communication abstraction based on communication roles. Each role has a body of executable code associated with it. At runtime, processes can enroll in a script and can then communicate by executing the code of their role. Different kinds of options are possible to contru| the enrollment (e.g. collections of roles, minimal set of partic- ipants and active enrollment vs. passive naming of new par- tidpants). In the Raddle approach [ESF88], a similar group communication model (n-p~rty interaction) is used. llowever, t~ifferent processes are a.~sumed to have physically or l~gically shared memory available. In addition, a stepwise refinement method to develop group interactions is specified. Other approaches like communication schedules [SCII90] are focusing on object-based group models where the participants are basically passive objects which can he activated by sev- eral concurrent threads of execution during their membership. That is, their duration of participation is not necessarily de- pendent on the duration of a single operation. The group is rather a structural, long-duration entitity serving as a base for longer-term interobject communication. The Coutracts

approach [IIIIGg0] is also based on the object-oriented model of computation and communication. It is mainly focusing on design a.qpects and proposes an interaction-oriented design method based on the identification, specification and reuse of interaction patterns of object groups. The approach provides means to specify the actual semantic dependencies amongst cooperating objects explicitly.

2.2. Group-Based Allocation Control

Distributed object groups can also be used as a means for allocation control ~i a distributed system, i.e. to control the placement of entltiti~.~ to network nodes. In approaches focus- ing on load balancing, the processors of a distributed system are represented as participants of an object group. The ma- jor goal of the group is to manage shared information about processor load and about processors willing to accept new jobs. This goal can be achieved by running a decentralized allocation protocol [CAK88] which is implemented within the processor group and which is based on shared load informa- tion managed by the group. In other approaches, the participants themselves are the el- ements of allocation control. This view is common in dis- tributed object-based systems like Emerald [BllJ87], [.JLll~8] or in Distributed Smulltalk [BEN87]. In Emerald for exam- ple, object groups can be built by specifying attributes of interobject relations. Objects which are attacked to other ob- jects via such relations move together. A related approach is presented in [SCI189], [MSK89]. Groups of objects to be allocated at tho same location dynamically are represented explicitly as collocations. A special protocol is implementing the identification of participating objects, a valuation of their migration costs and expected communication intensities, and the decision about their final migration destination. This way, communication of dynamically collocated object groups can be perfomed locally and therefore more eJficiently.

2.3. Replication Groups

Groups can also be used to implement replication mechanisms in distributed systems to increase availability or performance. Replicas of a data object are participants in a replication group and share some common information, e.g. a table of currently available replicas and common identificatioc infor- mation. In addition, a protocol based on primary/secondary copies [OKL88] or weighted voting [GIF79] is implemented within the replication group to manage update and access ".J replicas. To guarantee replica consistency in the face of pos- sible network partitions, in general a majority of replica.s has to be up-to-date. From the outside environment, the replica- tion group can be seen as a black box, i.e. the group can be accessed like a non-replicated object. However, to improve performance, the group can schedule read access to replicas internally according to the imposed communication overhead.

2.4. Object Groups as Server Collections

In distributed environments, the client/server model of dis- tributed processing is very common [SVO85]. Several dif- ferent servers offer their services to clients in a distributed

Language and runtime support for distributed ~ groups 273

system. Frequently, a regular service like printing or storing of da ta can be performed by several different servers. How- ever, they are not necessarily replicas in a strong sense, i.e. do not have consistent replicated data structures. Object groups can be used to manage the access to such server collections; servers are acting as participants of the server group. The management operations include the selection of an appropri- ate server, access control, and the actual transfer of service invocation. The selection can be based on a specification of the client's service requirements if the hlnctionality of servers within a gronp differs. The group has to manage a table of current service providers with associated service character- istics. The access control can be based on the group as a whole aml can possibly be specialized by individual servers. As opposed to replication groups (see above), different server groups may overlap, i.e. a server can be a member or several groups according to its functionality.

3. A FRAMEWORK FOR GROUP MANAGEMENT

Based on the above discussion, this section presents a frame- work to integrate different aspects of object group manage- meat. As opposed to other approaches, we propose a com- mon linguistic and runtime-ofiented basis for different hinds of groups. Specific features of our approach are the explicit distinction of group types and instances, it~ flexibility to be adapted to different hinds of groups, and its uniform object- oriented representation. We also show how the framework can be applied to selected example ~ of group types.

3.1. Generic Issues aml Characteristics of Groups

Several genetic issues and characteristics of object groups can be identified wlfich shmdd be represented and managed ex- plicitly:

B a s i c d e s c r i p t i o n a n d r e p r e s e n t a t i o n : In order to enable grm~p management, a description facil- ity for group types and an explicit internal representation of group instances at runtime has to be provided. Typically, a group type consists of a number of roles which arc filled with objects a t group instantiatian time. The concrete seman- tics of roles and role management depends on several group management and group activity issues which are summarized below.

G r o u p m a n a g e m e n t : Several aspects of group management have to be covered by language and runtime support:

u Group instantiution and enrolbuent: To create a group instance to a given type, a special instantiation mechanism is required. The mechanism can include the specification of a minimal set of partic- ipants, different alternatives for an object to enroll into an existing group, and means of finding existing object groups to enroll in.

u Group evaluation and conflicting participation: Frequently, the generation of a new object group de- pends on an estimation of its value, e.g. based on ex- pected communication patterns among i ts participants.

Therefore. a conditional generation of groups bs .~] on a distributed evaluation shouM be supported ia a generic way. In addition, different groups may intersect a t run- time, i.e. they may have shared participants. Several alternatives are possible to handle group intersections depending on the semantics of given group types.

* Shored group data orLd initial distribution aspects: Group management frequently requires shared group data. Examples are a list of group meml~rs or the current value of a s ta tus variable of a g¢oup. This da ta should be typed and be dec|ared vfithia the group con- text explicitly. In addition, the quest;on of allocating or even replicating this da ta a~i.~es ~n a d~tribute~_l e~.- vironment.

u Group termination: Like the group instantiation, the termination can also be dependent on a specific protocol. First, there can be several diffecent events or conditions which trigger the termina*.ion. Secondly, the termination may p ~ i - bly only be temporary, i.e. a terminated group can be reactivated in this case.

G r o u p o p e r a t i o n s a n d g r o u p a e t | v i t y : Once a group has been [nstantiated completely, i t will typ- ically perform semantic-specific actions and will a l ~ be ac- cessed from its environment to control i t o¢ to init iate appli- cation dependent operations on it. Support for the definition, invocation and execution of these different kinds of operations is required. In our prototype, the application dependent oper- ations are written in C + + which is integrated with our group specification notation.

The sumn~arized issues are covered by our linguistic and runtim~ oriented abstraction mechanism which is introduced in the following sections.

3.2. Example

As a first example to introduce the basic ideas which are descibed in closer detail below, a communication group will be presented. The example consists of several communicat- ing objects which pTocess a travel application form, i.e. an employee, his manage¢ and the expense acconnt ofnce of his company. In addition, the manager is part icipating in a group of communicating managers who meet fro~ t ime to time. The employee sends a tcavel request form to the manager who ap- proves it. Then he forwards the form to the expense account of Rce to get an advance. After completing his trip, he inserts i ts actual costs into the form and sends i t to the manager and to the expense account office again to get a refnnd. The following description of the example group is based on the language support described below. Although the body of the operations implemented in the host language in omitted, the basic ideas should become clear.

GRflU'P.TYPE T r a n e l P r o c e n s i n g (IM l i f e t i m e : I n t e g e r ffi I n d e f i n i t e l y , I i n u m ~ r : I n t e g e r = I ) ;

GROUP_DAT& form: T rave lFo rn ; s t a t e : ProceanJ .ngState ;

274 A. Schill

GR~UP_~ETHDDS getProcessingState: ProcessingState; getCopy0fForm: TravelForm; abortProcessing;

ROLE Employee emp (I~ inputForm:TravelForm, ~UT ~inalState:Proce~singState);

R~LE_DATA currentForm:TravelForm; ROLE_~ETHODS

~ravelRequest (TravelForm);

refundRequest (TravelForm);

ROLE Ranagermgr[num~gr]; ROLE_RETEODS

approveTravelRequest (~ravelForm); approveRefundRequent (TravelForm, RefundForm); authorized: Boolean;

ROLE ExpenseAccountOff ice office; ROLE_~ETHODS

makeRefund (TravelForm, ReftmdForm); a v a i l a b l e : Boolean;

MINImAL_SETS standard_population: emp, mgr:l, office;

GROUP_VALUATIOm offlce.available AND EXISTS mgr.authorized;

CONFLICT mgr WITH Reeting mgr PREFER OTHER AT_ENROLLRENT_TIRE;

TERHINATION: TIMEOUT lifetime FINAL;

GLOBAL_DATA_TNSTAITIATION form = e ~ . i n p u t F o r m ; s t a t e = X n i t i a l S t a t e ;

DISTRIBUTION emp WXI~ mgr; form AT emp; s t a t e AT emp;

TWTTIALL¥ emp. travelRequest ;

EWD_GROUP_TYPE;

The example group consists of three roles which are filled by its participants, i.e. by the employee, the manager and tile expense account office. The manager role can be instantiated by several managers within one group. The group type h ~ two value parameters; they specify the lifetime of i ts instances and the number of managers which can can instantiate the manager role within one group. A travel form and the current processing s ta te are global group da ta and are shared by all pa~tidpants. The group offers global methods to access its global da t a from the environment and to abort i ts processing.

The minimal set of participants consists of an employee, of one manager and of tile expense account office. A group can only start its processing if tile office is available and if one of the managers are authorized; this condition is given by the group valuation. A mana~:er is not supposed to handle a travel request and participate in a meeting at a time; he will prefer the meeting in such a ease. This is specified by the conflict clause. The global da ta instantiation section provides initial vahms for the global da ta of the gronp. In the distribn- tion section, tile actnal distribution of the participants and of the global da ta is specified. Finally, the initial invocation of the employee's travel request operation is requested once the minimal set of participants is present. The different lal~guage sections will be described in closer detail below.

3.3. Basic Description and Representation of Object Groups

Our approach is based on group types and associated groap instances. A 9roup type consists of a set of roles which can be instantiated with objects when an instance of the group type has been created. Roles are strongly typed and can be filled by objects of the requested type or of one of its snl~types. We assume that tile object types are already specified when role types are developed, i.e. that role types may refer to object types but Itot vice versa except tile participation operations (see below). We distinguish between singular roles (filled by one object) and collection roles, i.e. arra- roles (fixed by an indexed and fixed set of objects), and se~ roles (filled by an arbitrary set of objects). Each kind of role can also be optional; it does not haw ~ to be instantiated absolutely then. Each participant of a collectiol, role call query i ts index within the collection. Each object instantiat ing a role can have a set of input and output value parameters associated with it. This mechanism serves as & means to exchang,, da ta between the group and its environment. Default valnes can be provided and are used if no actual parameters are present or if a role has not been instantiated at all. With each role, a set of role methods and role variables can be associated. The role meth- ods can only be executed by the objects which instantiate a given role. The ~ole varialdes are shared by the role meth- ods of a role and are available during tile whole lifetime of a group. Each group instance also has a set of input and output val ,e parameters and a set of shared group variables. These da ta are instantiated and distributed before the actual operation of a group begins. In addition, global methods can be declared which are executed by a group acting as a first class object. These methods have access to the shared group da ta and serve as an external interface to a group. Usually, they will dele- gate operations to participants by invoking role methods. In a distributed environment, the invocation of role methods and of global methods as well as the access to group variables is assumed to be location independent; mechanisms to achieve this are described in [BlIJ87] and [BLA89], for example.

The following language flame is provided to represent these issues. For abbreviation, some nonterminals (e.g. conven- tional method, parameter or variable specifications) are not resolved in detail. Special characters (e.g. braces, commas, or semicolons) are quoted if they belong to the specified Inn-

Language and runtime support for distributed object groups 275

guage. The notation (<expression> \ ",") specifies a list of expressions of a given kind with zero or more elements which are separated by commas.

GROUP_TYPE <group_type_naae> " ( " <va] .ue_paraaetern> ") . . . . ;"

GROUP_DATA < g r o u p _ d a t a _ s p e c i f i c a t i o n > " ; " GROUP_HETHODS < g r o u p _ a e t h o d _ s p e c i f i c a t i o n > " ; " (

ROLE <object_type> <role_name> [ " [ " <n> " ] " ] [ OPTIOMAL ] " ( " ( ( ( IM I OUT ) <vaJ~:~_lJarameter> [ " = " < d e f a u l t > I ) \ " , " ) * ") . . . . ;" ROLE_DATA < r o l e _ d a t a _ s p e c i f i c a t i o n > " ; " ROLE_METHODS <role_~ethod_specificat:on> " ; "

)*

3.4. Group Management Protocol

The management protocol of object groups can be described in a simplified way by a state model. A group is initially in the state not existing and enters the state created after its create operation has been executed. Once a minimal set of participants is fulfilled or the enrollment of participants is terminated explicitly, the group becomes i~staati~ted. Alter a valuation, a conflict resolution concerning overlapping par- ticipation, and a distribution of the participants have been performed, the group enters the ready state. After i ts activa- tion, it becomes active and can execute operations. It can be saspendcd by invoking a suspend operation and will become active again by calling its resume operation. It becomes ter- minated if one of the termination conditions described below are fulfilled and no final deletion is requested or it becomes not e.ristin 9 again. A terminated group can become ~ctive again ~f i ts minimal set of participants is fulfilled and if it is explicitly reactivated. In the following subsections, details of the described steps are described.

3.4.1. lnstantiat ion and Enrollment

To instantiate a group, an instance of a group type has to be created by invoking a constructor and has to be filled with participants then. The group operation

<group_ins tance> .ENROLL (<role_name> [<index>] ( <parameter> \ " , " ) )

performs an ,ctive enrollment of the invoking object. Like- wise, an object can force other objects to participate in a group (passive enrollment):

<group_ ins tance> .FORCE_ENROLL ( <ob jec t> , <role_name> . . . )

Both enroll functions return an error code if the named role is already instantiated. If no index is specified for array roles, a free index is selected if possible aml is returned. In addition, an error code is issued if the type of the enrolling object does not conform to the type requested by the role. This check is done at runtime to make the approach language independent but could of course be performed at compile t ime with com- plete integration with a host language. By first applying ENROLL and then FORCE-ENROLL sev- eral times, an object can perform a part~ers-named egroll- ment ~.q described in [FHT86] and can determine the whole

participant configuration of a group explicitly. Alternatively, a group can be configured in a completely decentralized way. That is, the group is created by an object which enrol~ after- wards and is then registered at a name server or i ts ~en t i t y Ls pgopogated to potential participants. These objects can then inquire the group identity or will have i t avallab~ immedi- ately in the latter case. They are free to invoke aa ENROLL operation afterwards.

The instantiation of an object group can also be t r i~e red by application events which are attached to objects and which have to be imported into the context of a group type. A sim- ple example of an event is the beginning of a method invoca- tion. "]'he event reeeiverin this example is the invoked object. I t will automatically become a member of a new o l f pzct group of the given type. The enrollment of the other pa r t idpaa t s can be controlled by this object by naming other participants explicitly; for example in [$C~89], the enrollment in alloca- tion groups is controlled by scanning relationships o~ginaLing born the event receiver.

After each enroll operation, the group checks whether a pro- defined minimum set of objects, i.e. all mandatory objects of the group are already participating. The mlaimum is given explicitly as part of the group specification and consists of a number of alternative role sets of which at legst one has to be instantiated completely:

RIIIMaL_SETS ( <set_na~o> ":"

( <role_name>

[":"<Bin_no_participants>] "," )~ ";" )*

If no minimal set is given, all roles are mandatory, floweret, the enrollment can be completed explicitly in this case by the management operation CompleteEarollmeut. Then the next phase of the group generation is entered even if the all roles are instantiated. The automatic checking of the minimal set can be switched off by invoking the management operation l%MiaimaISet with explicit completion of enrollment after- wards.

3.4.2. Group Evaluation and Conflict Resolution

After the completion of enrollment, a optional evaluation of the whole group can be performed to decide whether the group should really become active. This evaluation is b ~ l on application-specific valuation m~thods of the participants; the valuation methods have to be implemented as role meth- ods. A regular arithmetic or boolean expre-~ion can be given with the keyword GROUP-EVALUATION; the expre.~ion must be based on the results of the evaluation methods of one or several roles. In the case of collection roles, the the sum of the evaluation method values of all instantiat ing ob- jects is applied if the participants are not indexed explicitly. Constants can of course also be part of the expression.

In addition, conflicts between different group instances have to be dealt with. A conflict occurs if one or more o~jects a t tempt to participate in more than one group and if their participation is allowed in only one group at a time. ThL,~ is

27G A. Schill

c,f practical relevance, e.g. if a group detmmines the common location of i ts participants; a participant will only be able to reside at one location if i t is not replicated. To enable a flex- ible conflict handling, different conflict resolution heuristics can be defined:

CO[FLICT ( <ro le>* ) gIT[~ <group_type>

[ " : "< r~ le>* ] [ EXCLUSIVE ] PREF~,R ( T R I S J OTi]ER I OLDER

I YOL~GER I PRTORITY I VALUATIOH I <group_method> )*

[ AT_ENROLLmENT_TIRE ] " ; "

This description defines a conflict to occur if an obiect is a part icipant of a group of the enclosing group type and at- tempts to participate in a group of tile additionally given group type, too. Such a situation can be detected easily: At runtime, each object keeps a list ,,f groups which it is cur- rent |y part icipating in. The two group types within a conflict definition can be identical. Conflicts can be restricted to par~ tic/pation in selected ~ohs ol each of the two groups. Conflicts caused by participation in more than two groups at a t ime are not treated explicitly; th~ y are reduced to several conflicts between two groups. The conflict can be of exchl",!ve nature, i.e. an object may ab- sdu te ly belong to only one ',7oup. Otherwise, an object lnay participate in more than or~ group but is only a structural member and not an active ':..articipant in the other groups, i.e. i t is not affected by the .~perations within these groups. The conflict resolution, i.e. the determination of the group in which an object patt ie[tutus actively is sper'ified in the PREFER section. Either o,~e of the two groups is preferred permanently or the group can be selected based on its age, its prior/ty, and its valuation. In addition, an application-specific grmJp method of both groups returning a decision value can he applied. If several criteria are specified, they are applied in the given order. I t is possible to specify that the conflict resolution should be performed immediately when an object enrolls. However, in this case the valuation of the whole group is not available and cannot be applied for conflict resolution. Application specific group evaluation methods can also not be applied then.

3A.3. Data Instantiation and Group Distribution

After a successful evaluation and conflict handling, an ini- t ial da ta instantiation and distribution of the group is per- formed. The global da ta of a group can be instantiated within the GLOBAL_DATA_|IqSTANT1ATION section by assigning ar i thmetic expressions based on the values of role vahm pa- rameters. At this time, the participants are still distributed as they were during enrollment. The internal representation of the group and i ts global da ta are still located at the node where the group was c_~eated. Before the group is activated, however, i t may be desirable to redistribute the participants and the group da ta explicitly, e.g. to reduce remote commu- nication between rda ted participants. This distribution can be specified as follows:

DISI"RTBU'T ]lOW ( ( ( <role> \ " , " ) WI'gB <role> " ; " ) I

( ( <ro].e> \ " , " ) AT <role> " ; " ) I

( ( <role> \ " , " ) APART " ; " ) I ( ( <data> \ " , " )

AT ( <role> \ " , " ) " ; " ) )*

The AT clause says that .~everal participants shouhl I,e al- located at the node where another participant is located al- ready. The AT clause can also be used to specity the al- location of da ta at a location given by a role. If several roles are given, a da ta object should be replicated at each of their locations, however, no g~;,-rantee of replica consis- tency after updates is given. The- APART clause says that the named participants should be allocated to diflerent nmles. Several participants can be requested to be allocated on the same node without determining that node by using the WITIi clause. If a collection of roles or da ta is not named explicitly on the left side of an allocation statement, all i ts elements are af- fected by an allocation clause. N~, collections are allowed on the right side of an allocation statement (except the specifi- cation of replicated data allocation). A simple heuristics is applied to perform the requested allocation at runtime.

3.4.4. Group Activation

After the distribution phase, the group becomes active. For each role, one or several initial invocations of role methods can be specified in an I[qIT1ALLY section. The invocatioqs will all be performed automatically and concurrently by the system. In general, any activity within a group is initiated this way and is then propagated by invocations of other role methods or of methods of the participating objects. The ac- tual parameters of the initial invocatioe.~ can be composed of the input value parameters of a role, of global group data and operations, aml of results of method invocations on the enrolled object.

3.4.5. Group Termination

Object groups will usually have a limited lifetime. With some group types, e.g. communication groups, tile termination of a group is given by the end of the algorithm performed by the group, i.e. when all its methods started initially have termi- nated. Other groups, e.g. collocation groups are terminated by their environment, i.e. when there is no need to allocate the participants at a common location any more. We offer the following means to request a group termination within the TEi?MINATION section of a group specification. First, a group is terminated when all initial role method invoca- tions have terminated (end of algorilhm). Secondly, termiua- tion can be initiated by an application event if the instatia- tion has also been event-triggered (e~ent-bused termination). Moreover, the termination can be caused by a timer which controls tile lifetime of a group (lime-based lerTninulion). In addition, a group is terminated if its minimal set of partici- pants is not satisfied any more and the termination can also be forced explicitly by invoking the termination operation (see section 3.5.). As a result of its termination, a group can either be deleted (indicated by the keyword FINAL) or can only be suspended. In the first case, all group information is erased and the partic- ipants are informed of the termination. The group is removed

Language and run,m,-, stspport for disMbut.~ object groups 277

from their list of groups they are enrolled in. In the lat ter case, the structural group information remains unchanged. However, the group will not perform any kind of activity be- fore it is reactivated again. The participauts are informed el the suspension. The suspension mecLanism can be used to run an algorithm on the same group ¢,'; participants (or on a similar group) several times.

3.5. General Operations on Groups

Groups are first-class ohjects and offer a set of generic op- erations to manage them. These operations can be divided into internal and external ones; tlte former ones are invoked l)y the presented management mechanisms while the latter ones can be invoked by application programs antl by tools directly. Internal operations are: In.*tantiate [(<input-parameters>)] is applied to a group type and creates a new gronp instance with tlte given initialization parameters. EI;alnatt' per[orms the described group evaluation and the conflict resolution. Close closes the group for fnrther participation and can op- tionally be invoked before a group is initiated. Initiate performs the participant allocation and data distri- Imtion and starts tile initial group methods. Tcrmin,zte requests the termination of a group; it can also be called externally.

The following operations are external ones: <name-~erver>.Qnerp (<query_specification>)

performs a query for all existing group instances of a given type or nf a given name at a name server. Enroll enables an object to participate in an existing group. ForceEnroll (<objec t>) forces an object to participate in an existing group. NoMinimulSet switches off the minimal set check. CompleteEnrollment completes the enrollment phase explic- itly. Status returns the current s tatus of a group. Participants returns a set of current participants of a group. Suspend leads to the suspension of a group, i.e. all further role method invocations are blocked after this operation has been invoked. Resume restarts the activities of a suspended group. Reactivate reactivates a terminated group if its minhnal set of participants is present. Invoke (<operat ion> [,<object_type>l) invokes a given op- eration on an arbitrary member of a given type. If the type is omitted, an arbitrary object offering the operation is se- lected. Multipleluvoke (<operat ion> [ ,<object- type>l) performs a multicast invocation on all members of a given type. Seleetivcluvoke(<operation> [,<selection-clause>l) performs an invocation on selected members of a group. The mem- ber selection can be performed via boolean conditions imple- mented by role methods.

4. AI'PI,ICATION TO SELECTED GROUPING EXAMPLES

Thi~ section gives several examp|es of object groups; the ex- amples are extracted from an office application. For all differ cut kinds of object groups mentioned in section 2, the more generic features which can be represented explicitly are dis- cussed. For Ihe sake of space, no atlditiona| language ex- amples (like in section 3.2.) are given, however, all major semantic anpects will be covered t\v our informal description.

4.1. Distributed Group Communication

In section 3.2., an example of a communication group (the processing of a travel application form by an employee, his manager and tile expense acconnt o[fice) has already been given. We do not describe more details of this specific exam- pie but discuss its genera~ characteristics: R,31es: The examph consists of three roles: The employee and tile expense account office rule are singular roles ant| the manager role is an array role and can be h~stantiated by mul- tiple managers. E n r o l l m e n t : The employee can create the group and per- fl~rm a partners-named enrollment of the other participants. Alternatively, a brag-term travel proc~sing group can he con- figured by partners-unnamed enrollment of the managers and the office ami by dynamic enrollment / dero|lmeat of emphJy- ees. M i n i m a l s e t : The minimal set of participants comprises an employee, a manager and the expense account office. If sev- eral managers shall participate, the minima| set check has to be switched off and enrollment has to he completed explicil|y. I n i t i a l o p e r a t | o a : Initially, the travel rvqnes! operation of the employee is triggered I)y the system. This operathm will then perfi~rm invocations of role methods of the manager ant| of the expense account office. V a l u a t i o n : The ruination of the group is based on a luJolean expression checking the availability of tile office and the atl- thorization of tile manager. Conf l i e t s : The conflict definition rnles out participation of a manager beth in a meeting and in a travel requ~t proce.~.sing. No other conflicts are treated by the group definition. G r o u p d a t a : The proce.~sed form and the current proce.~ ing state are shared between the participants. These da ta are updated by different role metho~ls and are a l ~ acce.~*~e~l by group methmls. D a t a d l n t r [ b u t i o n : The participants could in general he allocated to different nodes, liowever, for organizational rea- sons, the employee is allocated at the manager 's location. The group data is allocated with the e,nployee to avoid freqnent remote invocations. G r o u p a c t i v i t y : The activity of tile grmtp consiMs of inter- role communication. In addition, there may be external ac- cesser, e.g. to get the current processing state. A p p l i e d g r o u p o p e r a t i o n s : Generic group operations can be applied to multicast requests to severM managers, to sus- pend or resume processing, and to do s ta tus inqnirit~. T e r m i n a t i o n : Upon termination, tile g;3np tines not have to he deleted necessarily, i.e. the proce.~ging of a travel re- quest form can be initiated repeated|y with the same set of

278 A. R.chill

participants. The termination will be by end of algorithm or ~ime-ba.~ed. It could also be by lack of participants, e.g. if a manager shmdd derolg premat:zrely.

4.2. Gronp-Ba~qed Allocation Control

As an example of group-based allocation control, the alloca- tion of da ta objects at a common location is discnssed. The selected exahlple is based on the previous one and adds stone more details concerning the affected data objects. To com- p|ete a travel expense refund application, nsnally a n:]mhor of documents are required, e.g. the travel request and travel ~xpense forms and a collection of receipts. Moreover, the ex- pense account office will possibly access the mnployee's record ~o get information abont previous trips and expenses and to get information about the employee's salary, marriage state etc. In a computerized environment, the documents will be represented as da ta objects and will possibly be transported by at taching them to envelope objects. While the refund ap- plication is processed by the expense acconnt office, it is rea- sonable to allocate all objects mentioned above at its location. This way, all accesses to da ta objecls can he performed lo- cally and therefore more efficiently. The con,non allocation can be controlled by an allocation gre~lp: R o l e s : As no specific operations except a migration request are applied to the participants, only one set role is necessary in general. Ilowever, if the group instant |a t |on is triggered by application events, i t is resonable to introduce one dedicated role to control the instant |at |on process. The set role will then be used to represent dependent objects. E n r o l l m e n t : The earollnwnt ca,, he triggered by an appli- cation event. A partners-named enrollment of the dependent objects will be performed. As described in [SCIlgg], this an- re | |men[ can be supported by a mechanism to determine the participants by scanning interobject relationships originating from the controlling object. lVl |n lma] s e t : A minimal set does not. have to be applied. ]towever, to guarantee the common allocation of all affected objects, a fllrther distinction of different roles for different documents is reasonable. These roles can then be used to define a minimal set explicitly. ~[nltlal o p e r a [ l o s : Initially, a migration of the participants to a selected location will be requested; this can include a so- phisticated evaluation process. Alternatively, the migration can be handled by the built-in distribution facilit i~, e.g. I,y moving the participants to the site of the controlling object using the built-in AT clause. Ve,] tmtlon: A preliminary group valuation is important if the goal of the group is to reduce remote commnnication. A given estimation of the expected interobject commnnication can be compared with the actual migration costs reported by the participants. Confl]cf~s: If objects are no; replicated, a participant can only be allocated to one location, even if he participates in ~vera8 allocation groups with different location requests. For example, there may be the conflicting req,,est to allocate the travel expense form at the employee's location permanently. The conflict resolution mechanism can be applied, e.g. by preferring the group of higher priority and the younger allo- cation group if priorities are equal.

G r o u p d a t a : Iml)ortant shared group data are a final valu- ation of actual migration costs and expected communication costs and (he completed amonnt of communication between participants. D a t a d i s t r l b u t h m : The participants aml the grmlp data are all allocated to a common Iocatinn. If this is not possible fiJr some participants, the valuation data may be replicated at additional locations. G r o u p a c t l v i t y : There i~ no par t |odor grm]p activity once the final allocation has been completml. A p p l | e d g r o u p o p e r a t i o n s : It is possible to do statns in- quiries to existing allocation groups, e.g. to perform location inquiries. In addition, a group can be suspended in order In deactivate the allocation enforcement. Abet reactivation, its participants will be moved to a common location again. T e r m i n a t i o n : The termination is event-based (see ahove) or explicit. It will usually be final, i.e. the allocation group will be deleted.

4.3. Relflication (]roups

As an exmnple of a simple replication gr~mp, the replication of the travel request form mentioned above will be discussed. A replication group can be used to iml)lentent the manage- ment of synchronized updates to the different replicas and of failure handling. We assume that a primary/secondary repli- cation scheme is used but we are not interested in details of replication protocols here; they can be hmml in [OKl,g,q], fi)r example. r o l e s : The ave|laid, • roles are one primary and an array of secondaries. The siz~ of this array will typically be specified in advance. A sel of additional weak replica roles which will not necessarily always be up-to-dale is possible. E n r o l l m e n t : Partners-named enrollment is applied, i t is possible to add weak replicas as participants dynamically. M i n h n a l so.t: The minimal set of participants comprises the primary copy and one or more secondary copies. I n | t l a l o p e r a t l o n : Initially, the primary will propagate its s ta te to the secondary copies. A mnlticast can be applied for that.

V n h m t | o n : A valuation is not required, llowever, i t is rea- sonable to ew.l~ate the avail.~.bi!ity probability of the whole group by collecting failnre statistics from the locations of the participating objects. C o n f l | e t s : A replica is only allowed to be a mmnber of one replication set; therefore, an exclusive conflict definition is given concerning the participation in more than one replica- t ies group.

G r o u p d a t a : Management information about the current set of participating and of available replicas can Ice stored as shared gronp data. D a t a d i s t r i b a t i o n : The replicas have to be allocated apart from each other in order to increase availability. The group data shouhl be allocated at the site of the primary and should possibly be reid|coted at some secomlary sites in order to in- crease availability. G r o u p a c t i v i t y : After the distribution of the primary state, internal group activity will be triggered by the environment issuing read or npdate reqnests to the replication group. The secondary copies will forward npdate requests to the primary

Language and runtlmo support for distributed object groups 2 7 9

which will initiate an update ,oordination protocol. Read re- [BILl87] quests will be handh'd by the secondaries directly. Applled group operations: Possil)lo group operations in- clude the inspection of the participants, the integration of new weak secondary replicas, antl the request of read ant] t i p - [BLA89] date requests to the group as a whole. Such requests can be implemented by group methods and are internally forwarded to the participants. [CAK88] Term|nat ion: The termination will be explicit anti will he requested when apldication reconfigarations are necessary which require different kinds of replica sets. A replication group will usually be deleted then. [ESF88]

The example of a print server collection shows similar char- acteristics and han been evaluated, too.

5. CONCLIISION [EFK89]

The paper gave an overview of different examples and aspects o| distrilmted object groups. It presented an abstraction la- cility to represent and manage such groups itr a uniform way [FLIT86] within a distribute,I workstation el~vironment. 'Vhe approach improves the clarity of several semantic aspects of groups by introducing au explicit language representation with as- sociated runtime support. Due to the separation of generic [GIF79] gronping aspects and due to the typing of bbject groups, the rouse of existinL3 group definitions is facilitated. By providing additional tool support which can be directly b,xsed on the [HIIG90] explicit group representation, group behavimzr can I,e atta- lyzed at runtime in order to visualize or dehug dedicah,d parts of a distrihuled application. Specific tools for the described group cotnmnnication abstraction and for group-based a l l o - [.1Ll!88] cation control have been implemented and evaluated success- fldly. Details are reported in [SC!190] and [SCi189], respec- tively.

Future work will focus on the refinement of grouping aspects, [MSK89] on the application of the group paradigm to several other ex- ample areas, and on the implementation of an extended proto- type as outlined above. Refinements are possible concerning the instantiation, ternfination anti couflict resohttion proto- [OKI~8] coin for groups, concerning support for predefined libraries of group types, and concerning extended analysis facilities at rnntinte. Further example areas which can be investigated in detail arc grmtp-based resource management policies and the management of complex office procedures with several execn- [SC1189] lion agents involved in long-term operation executions.

ACKNOWLEDGEMENTS [S('ll90]

I would like to thank the colleagues of the DOCASE project at the University of Karlsrnhe, especially Dr. M. Muehlhaenser, W. Gerteis and L. I|enser for several frnitfid discussions. |n [SMH88] addition, I wonhl like to thank Dr. A. Malhotra and I. lhd- land for important comntents on tiffs paper.

REFERENCES [SVO851

[BEN87] Bennett, J.K.: The Design and Implementation of Dis- trlbqted Smalltalk; ACM OOPSLA Conf.. Orlando 1987, pp..$18.8.~0

Bla~k, A., HitcMnson, N., .Inl, E., Levy, H., C~rter, b.: Distrlbntlon and Abstract Typ-s in Emern.|,t; IEEE Transaetions ,n Software Engineering. VoL I3. Nr. I. Jan. 1987, pp. (;5-75

Black, A., Artsy, ¥.: Implementing Location Indepen- dent Invocation; 9th Int. Conf. on Distributed Com- puting ,~ystems, Newport Beach 1.089, pp. 550-559

Ca.savant, T.L., Kuhl, .LG.: A Taxonomy of Schednb ing in General Pqrpo.qe Distributed Compat~ng Sys- tems; IEEE Trans. on .qofh.are Eneineerin 9, VnL 15. No. ~, FeL 1988, pp. 141 15$

Evangelist, M., Shen, V.Y., Forman, LR., Gnat, M.: Using Raddle to Design Distribsted Systems; lOth. Int. Conf. on Software Engineering, Singapore 1.088, pp. 10~-111

Evangelist, M., Francez, N., Katz, S.: M~ltlparty Tn- teraetions for Interpreters Comtnunicatlon and Syn- chronization; IEEE Trans. on Software Engineering, Vol. 15. No. 11, Not,. lgsg, pp. 1$17-14~a

France'z, N., tlailpern, B., Tanbenfeld, G.: Script: A Communication Abstraction Mechanism and its Ver- ification; Science of Cementer Programming. Vt~L a. No. I. 1986. pp.35.88

Gifford, D.K.: Weighted Voting for Replicated Dat~ 7th Syrup. on Operatic9 Spstcm Principles. Pacific Grove 1979, pp. 150.16~

llelm, B., Holland, LM., Gangopadkyay, D.: Co~- tracts: Specifying Bchavlosral Compositions in Object-Orlented Systems; ACM OOPSLA Conf., O f lawn 1990

Jul, g., Lev}; H., Hutchinson, N., Black, A.: ["ine- Grained Mobility in the Emerald System; ACM Trans- actions on Computer ,~tfstems, Vol. 6, No. 1, I'lL 1988, pp. 109-133

Msehlhaesser, M., ScMll, A., Kienhoefer, Frank, H., Heaser, L.: A Software Engineering Environment for Distributed Applications; E,;romicro Conference, Cologne. Sept. 1.$89, pp. 327-332

Oki, B.M., Liskov, B.H.: Viewstamped Replication: A New Prlmmy Copy Method to Support Highly- Available Dis t~ted Systems; ACM Conf. o:: Prin- ciples of Distributed Compnllng, 1988, pp. 8-17

Schill, A.: Integrated Support for Dis~rlbated Object- Oriented Applications; IEEE (Yompeon Conf., San Francisco. Feb. 1990, pp. 57~-579

Schill, A., Gerteis, W.: Commnnlzation Schedules: An N-Party Communication Abstra,~tioa Mechanism for Distributed Applications; IEEE Int. Conf. on Corn- pater Communication (ICCC), Delhi, India, 1990

Shlmlzn, K., Maekawa, M., Humane, J.: t[ierarcklc,'d Object Groups in Distributed Operating Systems; 8th. Int. Conf. on Distri6ated Compnting Systems, San Jose IgRS, pp. h$-2,J

Svobodova, L.: Client/Server Model of Distrlbnted Processing; ITG/Gl-Faehtagun9 "Kommnnikation in t, erteilten Systemen" Karlsrnh, 1985, lnformatik- Faehberiehte Bd. 95, Springer-['trial. Berlin 1.q85