CHAPTER 17 DOMAINS: A FRAMEWORK FOR STRUCTURING MANAGEMENT POLICY Morris Sloman, Kevin Twidle Imperial College of Science Technology and Medicine 180 Queen's Gate London SW7 2BZ Email:
[email protected] Synopsis This chapter and the following one discusses the work on management policy which has emerged from a recent research project funded by the UK Science and Engineering Research Council and Department of Trade and Industry involving Imperial College, Sema Group and BP. This DOMINO project was on Domain Management for Open Systems. Domains, as defined in the Domino project, are a means of grouping objects to which a common management policy applies as well as being a naming context. The Chapter explains how subdomains provide the means of partitioning management responsibility and structuring the overall management of a large distributed system. The use of access rules as a flexible means of specifying relationships between managers and the objects they manage is also explained. An example of the use of domains for configuration management is described and some of the issues relating to implementation of the domain concepts are briefly discussed. 17.1 Requirements for management of large distributed systems A distributed system may consist of a variety of types of objects which have to be managed, for example users and the agents representing users in the system; hardware components such as workstations, mainframes, modems, software components such as processes, threads or files; services such as databases or electronic mail and the servers which implement them. In a very large distributed system there may be millions of objects, making it impossible to specify management policy for individual objects. Instead it is necessary to specify policy for groups of objects. (Note that the term object is being used in this chapter as an entity which encapsulates state and processing. There is no implication about the concept of inheritance found in many object oriented systems.) A distributed processing application may span the computer systems belonging to a number of different organizations. In general, there is no central authority in such systems and the management of the application as well as the underlying communication and processing resources may have to operate across organizational and legislative boundaries. Peer-to-peer negotiation between independent managers are needed to define policies for managing interorganizational interactions. There would be multiple hardware and software vendors supplying the components for such an environment and so management has to accommodate heterogeneity of hardware and operating systems as well as software components implemented in a variety of programming languages. This heterogeneity can be found both in objects being managed and within the management system itself. The communication system supporting this distributed processing is typically made up of multiple interconnected local area and wide area networks which implies a variety of protocols and communication mechanisms to be supported. The components and services being managed are physically distributed with genuine parallelism between components. This makes it difficult to obtain consistent global state information on which to base management decisions, or to synchronize management actions on different components. 2/11/92
1
The above characteristics of a large distributed system lead to the following requirements for management of such systems: • • •
•
•
•
Management cannot be centralized in a single human or automated entity but must be distributed to reflect the distribution of the system being managed. There is a need to automate as much as possible of the management which will thus have to cater for a mixture of both automated and human manager objects. Management must be structured to partition and demarcate responsibility amongst the multiple managers. This structuring could reflect physical network connectivity, structuring of the distributed application or possibly reflect the hierarchical management structure (for example corporate headquarters, regional, site, departmental, and section management) found in many organizations. Management will have to be implemented as a set of distributed components, with interaction between peer managers, and hierarchical interaction between higher level managers and lower level managers. There will be a variety of managers fulfilling different roles and operating in different contexts, but having responsibilities for the same object. For example the maintenance engineer and the user of a workstation have different management responsibilities for the same workstation. The management structure must be able to model these overlapping responsibilities. Flexibility in naming of objects is needed which permits human managers to assign aliases of their choice to the objects they manage.
Domains provide the framework for partitioning management responsibility by grouping objects in order to specify a management policy and thus coping with the complexity of management identified above. 17.2 Domains 17.2.1 Concepts Domains provide a flexible and pragmatic means of specifying boundaries of management responsibility and authority. A domain is an object which represents a collection of objects which have been explicitly grouped together to apply a common management policy. From the user's view, objects exist in a domain but this does not imply the strict containment relationship found in OSI managed objects (see chapter 5). Domains in fact hold references to member objects as shown in figure 17.1. In addition, domains provide a flexible structuring of the name space for identifying objects as explained below. Domains are a generalization of the concepts of a tree structured directory system. It is not practical to specify membership of a domain in terms of a predicate on attributes of objects in a distributed system. For example, to determine the membership of a domain based on the predicate 'objects created before 1 January 1990' would require checking the creation date attribute of all distributed objects throughout the system. The only valid management domains are those where the members have been explicitly inserted into the domain or created in the domain. Most management applications require persistent domains, and it must be possible to create an empty domain and later include objects in it. This permits the definition of a management structure for a system and then populating it with managed objects. Since domains are themselves objects, they may be members of other domains. Domains provide the means of naming and applying policy to managed objects so all managed objects must exist within a domain. Objects should always be created within a domain. The concept of grouping objects should not be confused with that of encapsulation. Hierarchical composition can be used to construct a composite object from several primitive or other composite objects (Magee, 1989). The composite object is viewed as a single object for 2/11/92
2
the purposes of invoking operations and the interface of the composite object hides its internal structure from the user. The component objects are then said to be encapsulated. Encapsulation is an essential concept for coping with the complexity of distributed systems as it permits subsystems containing multiple composite or primitive objects to be treated as a single object with an interface. In particular, a manager may be encapsulated with one or more managed objecta to form a self-managing composite object. Note that although it is sometimes useful to apply a management operation to a set of objects, in many cases the external managers have to perform management operations on the individual objects, which encapsulation prevents. Domains provide grouping but not encapsulation. 17.2.2 Domain Relationships D2
D1 01 02
03
03
01
04
D3 05
D2
D1
02
03
03
04
D3
D3 D3
06
05 06 01 a) User View
02
05
04
06 b) Implementation View
Figure 17.1 User and Implementation Views of Domains Any policy specified in terms of the domain will apply to all its members, which are the objects referenced by its policy set. A subdomain is a domain which is a member of another domain so D3 is a subdomain of both D1 & D2 in figure 17.1. Subdomains form the mechanism for partitioning a large group of objects and applying different policies to subsets of the original group or assigning responsibility to different managers. Note that a subdomain is not a subset, as a change of membership of the subdomain does not affect the direct membership of the parent domain. Objects O1, O2, O3 and D3 in figure 17.1 are said to be direct members of D1, whereas O5 and O6 are indirect members of both D1 and D2 As shown in figure 17.1, objects can be members of more than one parent domain. This fact, which is necessary from the management policy viewpoint as discussed later, makes it difficult to prevent cycles in the domain graph. We advocate a strategy of permitting cycles, and building mechanisms into domain traversal procedures for coping with cycles rather than preventing them. Two domains overlap if there are objects which are members of both domains, for example D3 & O3 in figure 17.1. Overlap arises in many situations relating to sharing of resources such as a gateway between two networks for which both networks have management responsibility or to a person who is a member of two different departments. Overlapping domains reflect the fact that multiple managers can be responsible for an object or that multiple policies apply to the object. Obviously this can lead to conflicts between policies or managers. In some applications there may be a decision to prevent overlap by creating a new domain with an independent manager and all objects from the overlapping set are moved into this new domain. This would be analogous to setting up a new management authority for a service shared by multiple organizations. However the model should permit the overlap case as it does arise in real-life situations. There may be a policy decision to prevent overlap of a particular domain by preventing members of that domain being included in other domains or members of other domains being included in that domain.
2/11/92
3
Maintenance Domain
Maintenance object Implicit overlap
Resource Allocation object
Resource Allocation Domain
Figure 17.2 Implicit overlap Figure 17.2 shows two domains used for different management functions — maintenance and resource allocation. In this case an implicit overlap arises because both the maintenance and resource allocation objects relate to the same hardware workstation, although they are different managed objects. Further examples of the use of domains for specifying security policy are given in Chapter 18. The labels attached to objects and references in figure 17.1 are unique identifiers. The requirement for flexible naming of objects for management purposes was identified earlier, but a local name for an object is only unique within the context of a single domain, which can act as a naming context. Domain path names can be used to name objects in a similar manner to the naming schemes discussed in chapter 10. Since objects can be members of multiple domains different path names can map onto the same object., and therefore path names do not provide unique identifiers for objects. Another strategy for unique identifiers is needed, as explained in section 17.7.2. 17.3 Managers and managed objects Management Policy
Management Interface
Interpret Information
Software Process
Control Manager
Normal Functionality Interfaces
Managed Object
Figure 17.3 Management Managers are responsible for i) Obtaining information about managed objects by monitoring them ii) Interpreting management policy and using this monitored information to make decisions about the objects they manage iii) Performing control actions to modify the behaviour of managed objects. Managers can be human or they may be implemented as automated manager objects acting on behalf of human managers. There is a need to be able to trace responsibility for manager objects back to a human manager. This may be a legal requirements in some applications where wrong decisions could lead to loss of life.
2/11/92
4
A managed object is an object with a management interface. An object may have other interfaces representing its normal functionality. For example a file server would have a normal functionality interface to open, close, read and write files and a management interface to change caching strategy, modify the numbers of buffers allocated to requests or to enable/disable the service. It may be necessary for a managed object to be a representation of an external resource such as a hardware entity but for many software components the managed object is the resource itself. In the OSI approach to management (ISO 10040), the managed object is modeled as a separate object from the resource it represents. This is applicable to managing hardware resources or to a database approach where there is a database object representation for resources. It is not a suitable generalized approach for managing distributed processing components as it introduces a level of indirection into interactions between managers and resources as well as problems in maintaining consistency between resource state and the managed object state. As OSI-compliant managed resources emerge, they are likely to have an OSI management interface and a normal functionality interface. Information request Reply
Manager Object
Notification
Managed Object
Control action Response
Figure 17.4 Management interactions The typical management interactions indicated in figure 17.4 indicate the need for a remote procedure call interaction mechanism for requesting information and performing control actions. In addition an asynchronous unidirectional message primitive is need to support notification of events. The ISO Common Management Information Protocol does support the above type of interactions, although simple distributed processing interaction primitives as described in chapter 3, would be easier and more efficient to use. Another problem about the OSI management framework is that it insists on managers interacting via a manager agent which is in the same system as the managed objects and shields them from direct interaction with managers. This arises out of the historical OSI insistence of protocols only being defined between peer entities and a manager and managed objects are obviously not peers. Delegation of detailed management from a remote manager to local node manager, with the remote manager acting in a supervisory capacity, is a sensible hierarchical implementation approach for some applications (Yemini et al, 1990.) However this is not what OSI management framework is advocating as the management decisions are still being made by remote managers. 17.4 Management Relationships 1 7 . 4 . 1 Access Rules Managers are normally not members of the domains they manage, as in many cases different policies apply to managers and the objects they manage. Other reasons for maintaining a separation between managers and the domains they manage is that this permits managers in one organization to be given (limited) management rights over objects in another organization and structuring a system into subdomains would require including a manager into every subdomain. Access rules (figure 17.5) provide a flexible means of specifying management authorisation policy as a relationship between a manager domain and managed domain in terms of the operations managers are authorized to perform on the managed objects. A manager domain contains manager objects and a managed domain contains managed objects. Access rules can also specify constraints such as the permissible time of access or location of managers.
2/11/92
5
Access Rule OpA … OpZ …
Manager Domain
Permitted Operations
09.0017.00
Managed Domain
Constraints
Figure 17.5 Access Rules An access rule is a generalized means of specifying access control policy which has been applied to management (Moffett et.al, 1990). It permits the specification of arbitrary management relationships as shown in figure 17.6. • There may be multiple managers in a domain for improved availability or performance • Managers may perform multiple roles and so be responsible for managing a number of different domains. • Managers may themselves be managed objects permitting hierarchical management relationships. • Managers can optionally be members of a domain they manage which permits a reflexive management relationship whereby managers manage themselves. Managed Object Domain
Manager Domain
Access Rule Managed Object Domain
Access Rule Manager Domain
Access Rule
Reflexive Management
Figure 17.6 Typical management relationships There is a need for self-managed objects which encapsulate manager and managed objects. However this object is not a domain but a composite object (see chapter 19) constructed using hierarchical composition which hides its internal structure behind an interface. O1
D1
O2
D3
D2 D4
U1 U2
U3
OpA OpB
O3 O4
O5
Figure 17.7 Inheritance of Access Rules Objects in a subdomain, by default, 'inherit' the access rules applying to direct and indirect parents. In figure 17.7 objects in domain D2 inherit the access rule applying to the parent domain D1 so can perform operations (OpA & OpB) on objects in domains D3 and D4 as the latter is a subdomain of D3. There may be more than one access rule which satisfies a particular request, for example as a result of an object's membership of overlapping domains. This indicates that authority has been granted via more than one route. The implications of this 2/11/92
6
inheritance is that the domain service must provide a means of determining the parent and ancestor (indirect parent) domains of an object to determine what policies apply to that object. It is also necessary to control inheritance at both the domain and access rule level. A particular access rule can specify that it applies only to direct member of the source and/or target domains or a domain can specify no inheritance of any access rule by its subdomains.
17.4.2 Representing users Two default domains shown in figure 17.8 are needed to represent human users within the system: i)
A User Representation Domain (URD) is a persistent representation of the human user or manager. When the user logs into the system an user interface object is created within the URD and inherits all access rules specified for the URD.
ii)
A User Personal Domain (UPD) corresponds to a user's home directory and represents the personal resources which the user 'owns'. In addition the user may have limited access to other service domains representing the shared resources the user can access. User Personal Domain (UPD)
User Representation Domain (URD) Default Access Rule = all rights Limited Access Rules User interface
Service Domains
Figure 17.8 Default User Domains 17.4.3
Manager Positions
It is necessary to specify the rights of a manager position independently of the human manager who occupies that position so that when the human manager is transferred to another position, the access rules pertaining to the position do not have to be changed. This can be accomplished by a creating a Manager Position Domain and specifying all access rules with respect to this domain. Allocating a human manager to a position is accomplished by including his/her URD within the position domain. The manager automatically inherits all rights for that position and may be a member of multiple position domains if performing multiple management roles. The model permits multiple URDs to be included in a Manager Position domain indicating a shared position but obviously this would require the managers to coordinate their activities via a suitable protocol.
2/11/92
7
Access Rules
reference User Representation Domain
Manager Position Domain
Figure 17.9 Manager Positions 17.5 Application to Configuration Management (CM) In the previous sections we have explained the basic concepts of management domains and access rules. We will now discuss how these concepts can be applied to a particular management application, namely configuration management of distributed software components in a distributed programming environment such as the Conic system (Magee et.al, 1989). In this environment a human manager makes use of a configuration language to create sofware components (objects), allocate them to hardware nodes and bind interfaces between component instances. The human manager interacts with a configuration manager object (called cman) which executes the mangement operations on her behalf. Domains and access rules are used to control on which objects the manager can perform configuration management operatiions and what interfaces can be bound. The assumption is that the managed object corresponds to a composite software component with an application specific interface as well as a management interface. An interface type is defined using an Interface Specification Language (ISL), in terms of ports which correspond to operations provided (or messages received) by a server or operations invoked (or messages sent) by a client. Port types define the datatypes of the operation parameters as shown in figure 17.10. define ifdefs = { data = array [512] char name = array [64] char length = int interface_xyz = { i: port name -> length, data j: port name -> int k: port name, length, data }
// bidirectional //bidirectional // unidirectional
Figure 17.10 Interface Type Definitions The interface_xyz within the definition unit ifdefs defines 3 operations i, j, k together with the parameters of the operations. Note that port k defines a unidirectional message with no return parameters. A server template would declare the interface as an entry and provide the code to implement the operation defined, while a client template would declare the interface as an exit and invoke operation on the ports (figure 17.11).
2/11/92
8
object xyzclient = exit interface_xyz { use xyz_defs: interface_xyz /* Component is implemented in a suitable programming language - invokes operations /*
object xyzserver = entry interface_xyz { use xyz_defs: interface_xyz /* Component is implemented in a suitable programming language - implements operations/*
}
} i
i
j
j
k
k xyzserver
xyzclient
Figure 17.11 Declaring Interfaces on Client and Server When an interface on a client object instance is bound to an interface on a server object instance, ports of the same type are bound together. An Access Rule specifies for which port types bindings are permitted. So the binding of xyzclient to xyzserver in figure 17.12 results in ports i and k being bound as j is not permitted by the access rule. Note, that if there is no ambiguity, the interface name can be omitted from a bind statement as in figure 17.12. D2
D1 interface_xyz { i, k}
i
i
j
j
k
k xyzserver
xyzclient bind xyzclient -- xyzserver
Figure 17.12 Interface Binding The generic configuration management operations available include delete, stop, start, and reset components; query, bind and unbind interfaces. Binding can apply to individual ports in an interface or all the ports. Every configurable object must support a server CM interface which defines ports corresponding to each CM operation. Note that a configuration manager may also have a create port which would be linked to a factory object, as this is not part of the generic interface supported by all configurable objects. In general a manager or application programmer would be responsible for initially installing the components of a distributed application or service as well as subsequently replacing components with new versions to support evolutionary change. Reconfiguration can be performed dynamically without shutting down the complete service. A human manager (Fred) responsible for configuration would have a configuration manager object, called cman, which supports a graphical interface and a CM client interface. This cman would be created in the Fred's URD. The cman interface can be bound to any managed object which implements the CM server interface to permit CM operation to be performed on that object. The operations which cman is authorized to perform are specified as access rules between Fred's URD and the managed domain. Assume Fred decides to reconfigure the application running in Domain D1 which consists of the objects A and B, with B bound to A. He installs a new object ctype and binds it to A in D1 and to xyzserver in domain D2.
2/11/92
9
Manage D1 use ctype;
// Specifies required template
create
C : ctype @ loc= 'N2'
// Creates an object C at node N2
bind
C.fileio -- A.fileio C.xyz -- D2/xyzserver.interface_xyz
start
C
D1 D2 interface_xyz { i, k}
fileio B
A
CM CM
interface_xyz
xyzserver
fileio
C
CM xyz
CM CM {all}
CM { bind}
N1
CM node { load, create}
cman
N2 Fred Node Domain
Figure 17.13 Configuration Management Example Physical nodes are represented as factory objects which provide a remotely accessible interface to local operating system facilities for loading object templates and creating object instances. In Figure 17.13 an access rule gives Fred access to Nodes N1 and N2. Fred can perform any configuration management operation on objects in D1, but can only perform bind operations on objects in D2. The bind between D1 and D2 permits C to invoke only operations i and k on xyzserver. Note that if a manager has CM {all} permission on a domain he can perform arbitrary configuration management of objects in that domain including binding of any type compatible interfaces of objects which are direct members of that domain but configuration between that domain and any other is subject to access control. 17.6 Inter Organizational Domains As explained in section 17.1, a large distributed application may span multiple organisations. Managers in one organsiation may need to perform, possibly limit operations on objects in othre organisations, for instance to query state or perform diagnostic tests. The Domain Service must therefore be capable of supporting inter-organizational management. The domain hierarchy is also used as a means of naming objects and so it should be possible to include 2/11/92
10
objects or subdomains from another organizational hierarchy into your own domain hierarchy, assign a local name to these objects and hence manage or just access the objects. However including organization A's domain into the policy set of organization B's domain implies that the A's subdomain inherits policy applying to the B's domain, which would violate the mutual independence of the two organizations. The domain permits context references to other objects (usually domains) which do not carry policy implications; in this case the referencing domain is not considered as a parent of the referenced domain so there is no inheritance of policy such as access rules (see figure 17.14). A domain may therefore hold two sets of object references, the policy set to which domain policy will, by default, apply, and the context set to which domain policy does not apply. If a member of Imperial College Staff has access to the DOC Domain, he can obtain an address for objects in the BP/Research domain, but he cannot access those objects as access rules applying to the DOC domain do not apply to context references. A separate access rule must be set up to enable Imperial College Staff to access the BP/Research domain. Imperial College
BP DOC
Research
Context References
BP
IC
Figure 17.14 The Use of Interorganization Context References The disadvantage of this scheme is that it does not use a well known naming convention and so cannot use any existing directory service to locate objects in remote organizations. The addresses of objects from other organizations must be inserted manually. A solution we have adopted is to set up a domain hierarchy at each organization which mirrors the structure of the well known Internet Domain Naming system (see figure 17.15). We could equally have used X.500 naming, but it is not yet widely used. IC Domain Hierachy /
BP Domain Hierachy /
uk
uk
ac
co
ic
ac ic
bp doc
co bp sun-rc
Figure 17.15 Context References Plus Well Known Naming 17.7
Domain Service
The description of the domain service has so far been from a functional point of view. We will now take a more detailed look at the interface the domain service provides to users and how this interface is actually implemented by means of a set of servers. 2/11/92
11
The domain service provides the underlying services required for naming and grouping objects for applying management policy. This is used by all aspects of management as well as configuration management as shown in figure 17.16 Other Service Interfaces
User Interface
Configuration User Interface Software
Other Services
Domain Service Interface
Domain Service
Figure 17.16 Domain Service Interface In this section we will describe the domain service implemented as part of the DOMINO project on Domain Management of Open Systems (Law et al, 1990). This was a collaboration project funded by the UK Department of Trade and Industry and Science and Engineering Research Council involving Imperial College, Sema Group and BP Research. 17.7.1 User and Mechanism Views There is a need to distinguish between the view of the human manager (user) managing a distributed system and the underlying mechanism(s) used within the system for implementing this view, as illustrated below. a)
b)
c)
Management domain objects provide a means of defining sets of objects and structuring them by the use of subdomains. The user view of domains is that they contain a set of named objects. However the system holds the local name (a text string) and an object reference for each member of a domain. Users refer to objects by names, while the system refers to them using the internal object references described below. Access rules specify discretionary access control policy in terms of the set of operations which any of a set of users is authorized to perform on any of a set of target objects. This also is a concept which managers find intuitively easy to deal with, but does not lead to efficient implementation. It would involve unreasonably long searches to evaluate access requests if the system had to search through all access rule objects in order to decide whether to allow the request. Therefore, for the Domino project, we are implementing the access rules by means of Access Control Lists (ACLs) attached to target object domains, as described in Chapter 18. The user views object creation as being an operation on a domain but the underlying mechanism is an operation on a factory object which inserts the reference into the domain.
We believe that it is important to maintain both a distinction and a relationship between the user and mechanism views of management concepts. As with any system, the user requirements must drive the mechanism, but it must be subject to the condition that it can be implemented efficiently. In the remainder of the Chapter we will concentrate on the prototype Domain service implemented as part of the Domino research project. It was necessary to implement both the user and mechanism views as human managers have to be able to work with objects which are implemented in accordance with the user view, while the underlying system has to 2/11/92 12
be able to use a mechanism which provides an efficient implementation of the functions seen by the user. This distinction is similar to Ansa’s (1991) five different viewpoints of a system, but we find the simple binary distinction of views adequate for our purposes. 17.7.2 Object References Users refer to objects by local textual names which are only unique within the context of a domain. An Object Identification Descriptor (OID) is used internally within the system to reference objects. This OID is unique across a much broader namespace - all systems supporting a domain service. The domain service provides the means of translating between these two forms of identifiers. Local name
Object Identification Descriptor (OID)
Text String
Unique Identifier
Locator
Object address Host IP address
Time stamp or random no.
Locator Type
freshness index
X.500 distinguished name Group Address
Figure 17.17 Object Entry held by Domain Service Figure 17.17 shows the format of the OID. Every object is assigned a unique identifier, created from the Host IP address where it was first created plus a uniquefier (time stamp or random number). This does not change if the object is migrated to another host. The current implementation uses actual addresses as a means of locating objects, but the system could be extended to use an X.500 distinguished name (see 10.2.3) or a group address for replicated objects. The freshness index associated with the actual address is incremented when the object is migrated so two addresses for the same object can be compared to find the most recent one. 17.7.3 Domain Operations The following set of operations are supported by our domain service implementation: Create/destroy a subdomain; Include/remove object in/from domain policy set; Include/remove object in/from domain context set; List domain - returns policy set and context set entries; Query object's parents - returns OIDs of direct parents; Query object's ancestors - returns list of direct and indirect parent OIDs; Translate path name to OID and address; Translate OID to path name, choosing an arbitrary path name where there are multiple paths through the domain tree to the object. Note that object creation is not considered a domain service operation, but is invoked on an object factory which creates the object and includes it within a domain as an atomic action. Object deletion is performed on the object itself and the object support system attempts to 2/11/92
13
remove all entries from the domain service but this cannot be guaranteed as in a distributed system some parts of the service may be inaccessible. 17.7.4 Implementation The domain service is implemented by two types of components as shown in figure 17.18. i) Domain servers store and maintain domain objects corresponding to a subtree in the domain hierarchy. If it does not hold the information relating to a particular part of the subtree, it will have the address of the server responsible. The current implementation caters for distributed, partitioned domain information, but we will be investigating replication of domain information for performance and availability. ii) Node Managers reside on every physical node that supports managed objects and maintain information about local objects, such as their parent domains. They act as local agents for interaction with the Domain Servers and are responsible for requesting the Domain Server to include a newly created object in its parent domain, maintaining a cache of addresses of Domain Servers, and holding forwarding addresses for objects which have migrated from its host. An advantage of having a permanent server running on a host is that it can cache some of the domain information such as where the main Domain Servers are and information on frequently used domains. This is available to local objects which may be dynamic and short lived. Another function of the node manager is that of a generic factory server. It creates object instances on the node from the object template which is passed as a parameter. The node manager inserts the created object in a domain specified by the user and also in a node domain of all objects created on that node. The node domain is used by the system administrator responsible for managing the node.
Domain Objects
Domain Servers
Node Managers
Domain Service Figure 17.18 Domain Service Components Cycles of membership, in which a domain is an indirect member of itself, may arise within the domain service. These must be catered for by all programs (such as a user interface program) which trace down the membership tree. Unbounded search for parents, possibly across remote sites, is dealt with by an arbitrary limitation on the number of ancestors which can be searched. We need implementation experience to find out how satisfactory this will be. 17.8 Related Work The OSI security framework (ISO 10181-1) defines a subdomain as a subset. If domain B is a subset of domain A then any member of Domain B must also be a direct member of domain A. If an object X is inserted in domain B, then X will also be a direct member of member of A. Therefore any policy applying to the superset (A) must, by definition apply to the subset (B). However B is a subdomain of A and X is inserted in B, it is not a direct member of A. Our definition of subdomains permits inheritance of policy as an option and permits domains to be used to partition responsibility, as teh manager of a domains does not necessarily manage the member of the subdomain. The manager of a superset would by definition manage all objects 2/11/92 14
in the domain and would not see subsets. Another problem with the OSI definition is that domains include both managers and managed objects. This reduces flexibility of the domain concepts as it is impractical for inter-organizational management where managers have limited management rights over objects in another organization (i.e. a different domain). It does not permit different policies to apply to managers and the objects they manage. In our opinion the OSI concept of domains has not been fully thought through, and there is no implementation experience to validate it. The DEC Enterprise Management Architecture (Strutt, 1991) uses a domain to define a 'sphere of interest of a set of managed objects for a manager' - managers are not part of the domain. Only the managers are aware of the domains and objects do not know which domains they are members of. This model is compatible with the Domino approach as it implements a subset of our concepts. There are no domains of managers and relationships between a manager and domain is implicit in the knowledge of the domain name rather than the use of explicit access rules. They do not use the domains for access control. Domain membership information is held by the name service. Domains perform a name service function and so the implementation is similar to the Digital Equipment Corporation Name Service(DECdns) (DEC, 1991) where a domain corresponds to a directory and their soft-links serve a similar function to our context references. However DECdns does not permit cycles and a sub directory can have only one parent. DECdns makes use of a globally unique name rather than being relevant to a domain so names are independent of users, whereas our names are allocated by individual user and are not unique. There is an Esprit funded project called DOMAINS (1991) which is defining an architecture for managing distributed systems. Their domains encapsulate manager and managed objects which makes it difficult to support managed objects which are members of multiple domains or to support the flexible management relationships we have identified in this paper. 17.9
Summary
Domains serve two functions: i)
A means of grouping objects in order to specify a common policy. It is the means of grouping objects to specify a policy and the ability to partition managed into subdomains that cater for large inter-organizational systems.
ii) A means of allocating local names to managed objects These two functions of domains are reflected in that domains can hold two types of object references: a policy one implying that domain policy applies to the referenced object; and a context reference, used purely for convenient naming of objects, particularly those in other organizations. Multiple domains containing the same managed object can coexist in order to reflect different viewpoints and policies with respect to a set of managed objects, corresponding to different management roles and functions. Access rules have been used as a flexible means of defining relationships between domains of managers and managed objects by defining what operations the managers can perform on the managed domain. The chapter has shown how domains can be used to represent individual users registered in a system and manager positions within an organization. The next chapter gives further examples of the versatility of the domain concepts as a means of specifying management policy and delegation of authority.
2/11/92
15
Abbreviations Used ACL CM IP OID URD UPD
Access Control List Configuration Management Internet Protocol Object Identification Descriptor User Representation Domain - represents a user in the system User Personal Domain - the resources 'owned' by a user
17.10
REFERENCES
Ansa (1991) ANSAware 3.0 Implementation Manual, APM Ltd., Poseidon House, Castle Park, Cambridge CB3 0RD, UK. DEC (1991) Digital Network Architecture, Naming Service Functional Specification Version V2.0.0 Order No. EK-DDNANS-FS-002 DOMAINS (1991). Esprit Project 5165 - DOMAINS Basic Concepts, version 2.0 (Nov 1991), Philips Gmbh, PO Box 1980, W 5100 Aachen, Germany. ISO 10040 (1991). Systems Management Overview, ISO/IEC JTC1/SC21 WG4 ISO 10181-1 (1991) ISO Security Framework I: Overview, ISO/IEC JTC1/SC21 (May 1991). Magee J., Kramer J. & Sloman M.S. (1989). Constructing Distributed Systems in Conic, IEEE Transactions on Software Engineering, 15(6), pp. 663-675. Moffett J.D., Sloman M.S. & Twidle K.P.(1990). Specifying Discretionary Access Control Policy for Distributed Systems, Computer Communications, 13(9), pp. 571-580. Sloman M.S. & Moffett J.D. (1989). Domain Management for Distributed Systems, in Integrated Network Management I, (Meandzija B and Westcott J. eds), North Holland, pp. 505-516. Strutt C. (1991). Dealing with Scale in an Enterprise Management Director, in Integrated Network Management II, (Krishnan I. and Zimmer W. eds.), North Holland (1991), pp. 577-593. Yemini Y, Goldszmidt, G, Yemini S (1991). Network Management by Delegation in Integrated Network Management II, (Krishnan I. and Zimmer W. eds.), North Holland (1991), pp. 95- 107.
2/11/92
16
