Proc. IEEE Second International Workshop on Services in Distributed and Networked Environments (SDNE 95) Whistler, British Columbia, Canada, 5-6 June 1995, IEEE Computer Society Press, pp 52-59.
Management Issues for Distributed Services Morris Sloman Imperial College, Department of Computing, 180 Queen's Gate, London SW7 2BZ Email:
[email protected] Abstract
on behalf of users or are downloaded from service providers to user workstations to provide facilities for the user to access the provided services [18]. The provision of a value added service may require the use of services provided by many different organisations. For example, consider an electronic market place where an electronic travel agent arranges a trip for a client and may have to interact with telecommunications service, directory service, car rental, hotels, airlines and credit card companies. It is the management of distributed software components within a heterogeneous, multi-organisational environment that will be important for future distributed systems. However the current management techniques and standards have emerged from the communications world and are biased towards the management of very simple hardware devices or connections. This paper discusses the issues related to applying distributed processing techniques to the management of distributed services and the specific services that are required to support management.
This paper advocates a distributed processing approach to managing distributed services whereby managed objects have a management interface to support their management functionality and other interfaces to support their normal functionality. We discuss the shortcomings of the SNMP and OSI approaches to management for large scale distributed services and explain the need for three basic management services – monitoring to obtain information; domains to group objects and partition responsibility; and policy to permit the behaviour of automated managers to be modified without reimplementation. The key message of the paper is that management should not be designed and implemented independently from the normal functionality provided by a service but that standard distributed processing concepts, tools and techniques should be used for management. This approach permits the management system to be used to manage itself.
1 Introduction
1.2 Characteristics of management
1.1 Distributed service
Management of a system is concerned with supervising and controlling the system so that it fulfils the requirements of both the owners and users of the system. This includes the longer-term planning required for the system to evolve to provide improved performance, incorporate new functionality or new technology. Management may also involve accounting to make sure that resources are fairly allocated to users or to actually charge users for use of services. We use the term manager to refer to any entity, human or automated, that can perform management activities. As part of the on-line control of a system, the managers must monitor it to obtain up-to-date status information and to receive event reports They interpret the overall policy pertaining to the goals or requirements of the organisation that owns the system in order to make decisions about what behaviour is required from the system. Finally managers perform control actions on system resources to change their behaviour (see Fig 1.1).
The trend in implementing distributed systems is to make use of existing services to provide value added services and applications. For example a service to support multimedia cooperative working of distributed users could make use of existing communications, electronic mail, directory and file services. A service is typically implemented by a set of distributed hardware and software components which cooperate to provide the required service to users, which may also be components of a higher level service provider. Some services such as communications are intrinsically distributed with service access points in every computing device, but others may be logically centralised. The software components of a service may be very sophisticated and will have to be dynamically changed without shutting down the complete system in order to install new value added services or to modify the functionality of existing services. Some services may use agents which migrate from user's computing devices to server systems to perform actions
1
tools to determine required characteristics of new components or services. • Many services are charged for, so accounting is needed to keep track of usage and to issue bills. A single consolidated bill may be issued by a service provider to reflect the use of services from many suppliers. Many internal resources are shared and so accounting is also needed to make sure they are fairly allocated to all users. • Security management is needed to specify who can access what resources or services. This is particularly important when users from different organisations access resources. It is necessary to detect and check up on security violations. Encryption keys have to be generated and distributed to permit encryption of confidential information, authentication and “signing” of payments, orders etc. • Monitoring of the system is needed for all these functions to determine the current status of components and to react to events. This entails filtering events, and disseminating event notifications and status reports to those users or components that require them.
Managing distributed services entails performing the following management functions: Management Policies
Distributed Processing or Networked Sytem
Interpret Monitor Managers Control
Resources
(a) Management information flow. Monitor status & receive event reports
Interpret policy & make decisions
Perform control operations
2 Management architectures (b) Management activity loop.
Figure 1.1
We will examine the facilities provided by the two main management architectures which have been proposed as contenders for managing distributed services
Management activities.
• Configuration Management involves defining required component instances, initial bindings between interfaces and installation of software onto the hardware components. It must be possible to perform these functions without shutting down the system so that large systems can evolve or be reconfigured to cope with failures. A key concept is that of hierarchical composition to enable a new service to be specified as a composition of existing services or components [9]. • Registration of users is needed so that they can be identified and held accountable for their use of services. Service components should have unique identifiers so that managers can identify and keep track of what is in the system and where it is. There is thus a need to manage namespaces and allocate unique identifiers or names to users and components. • Fault diagnosis may require interaction with other cooperating organisations or those providing services. Fault recovery actions have to be instigated and repairs tested. • It is necessary to specify a required quality of service (QoS) from outside suppliers such as for communication or database services and to take corrective action if that quality is not maintained. Similarly, the performance of all components of the system must be monitored to detect bottlenecks. Planning for expansion could use modelling or analysis
2.1 SNMP Simple Network Management Protocol (SNMP) is used in the Internet environment and is based on the use of the UDP datagram service [16]. The management information pertaining to a particular class of resource (e.g. router, ATM switch) is defined in a Management Information Base (MIB) for that resource class. The manager accesses the MIB via an agent using SNMP primitives such as get to read values in the MIB, set to write values to the MIB and the agent can send events to the manager using trap messages. Typical data types which can be represented in the MIB include, integers, counters, strings and addresses. The only supported structured data type is a table. Operations on resources are performed by writing to variables in the MIB. Recent extensions to SNMP provides security to control access by different managers to an agent and to permit proxy agents to take on the role of local managers for remote resources but these proxies are still controlled via a MIB. SNMP was kept as simple as possible so that it could be implemented efficiently in very simple devices with limited processing and memory resources. It provides a very low-level, variable oriented approach to management which is analogous to remote debugging. Although you can read (write) multiple variables in a single get (set) message there is no concept of a single operation such as a reset to initialise a number of different
2
variables to a predefined initial state. All the intelligence is assumed to be in the manager which therefore has to have a thorough understanding of all variables of a resource – there are no predefined high level management operations so the manager has full flexibility to control the resources according to what is available via the MIB. This approach is contrary to modern Software Engineering practice which advocates the encapsulation of data together with operations to access and modify the data in an object. In a large system with many heterogeneous resources or services, human managers cannot understand the workings of all these resources so this low level approach of SNMP is too powerful and too dangerous. Automated managers which use SNMP to manage resources will be like assembly language programs – difficult to maintain and evolve.
used for fault management within the communications system. • Naming is based on the principle of physical containment so does not cater for objects which migrate from one system to another e.g. mobile agents or components which are moved to recover from failure. • OSI does not support specification of manager interfaces or peer-to-peer manager interactions, although some parts of the management system such as event forwarding discriminators can be specified as managed objects. • The normal functionality of resources and services are specified and implemented differently from the management view of those resources. Although separate managed objects are needed to represent hardware devices, this is not appropriate for software objects (see section 3).
2.2 OSI management
2.3 TMN
The International Standards Organisation have defined a set of OSI management standards which aim to provide a higher level approach to management, than SNMP, by supporting object oriented concepts. A managed object defines a management view for a resource in terms of attributes (variables visible to the manager which can be read or written) and operations which can be performed on the resource [17]. Managed objects can also emit event notifications to the managers (cf SNMP Trap). It is possible to define object classes and instantiate multiple instances of objects. Inheritance is used for defining new object classes as an extension or refinement of other object classes. The Guidelines for the Definition of Managed Objects (GDMO) [7] defines a very sophisticated specification notation supporting conditional packages, default values and behaviour in English! GDMO provides the functionality of an interface definition language (IDL) but cannot easily be used to generate interface stub procedures for both managers and managed objects, as is done with modern IDLs. Programmers manually transform GDMO specifications into programming language implementation. In addition, GDMO is a very verbose notation – simple specifications look very complicated. Problems with the OSI management approach include the following: • Managers cannot directly invoke operations on managed objects but instead use the CMIP protocol to interact with an agent which invokes operations on local managed objects such as transport connections, or network devices. The object oriented aspects of OSI were defined after the definition of the CMIP protocol so it does not represent a “clean” object oriented approach. • CMIP is meant to be implemented above a full 7 layer OSI communication stack. This implies it needs a fully operational communication system and cannot be
Telecommunications Management Network (TMN) is based on the use of OSI management standards although the management communications is logically and often physically separate from the normal telecommunications. TMN defines a functional architecture specifying logical management functions and a physical architecture stating how these can be mapped onto physical elements to implement them [5]. With high speed ATM networks, there is no need for a separation between the isochronous network used for voice and video and the asynchronous network used for data communications. A separate network for management will not be economically justifiable for most applications. If necessary fault tolerance techniques can be used to improve the availability of the management system or the distributed service itself, but the issues of fault tolerance should not be confused with the management functionality. As TMN is based on OSI concepts, the above comments apply to TMN and it will not be discussed further in this paper.
3 Distributed management SNMP and OSI management emphasise the separation of the management of the service from the provision of the service. They do not recognise that the same tools and techniques that are used to specify, design and implement distributed applications and services should also be used for management. Our view is that management of services should be specified, designed and implemented at the same time as their normal functionality. The normal functionality of a service is accessed via an interface and similarly there should be one or more interfaces to enable the service to be managed (see Figure 3.1). Users of a service may be
3
end-users (subscribers) but may also be higher layer services. Thus service-users require limited access to management functions via a management interface e.g. to query state or accounting information pertaining to their use of the service; to negotiate or query Quality of Service parameters or to permit fault diagnosis between different service layers. Normal Management Interface Interface
Normal Interface
provides as extensions to the basic communication service (see section 3.3). There is sometimes the need for exchanging management information relating to a particular protocol “in band” i.e. to use protocol data units to transfer management information between communicating objects. We consider this to be a special case rather than the norm. Very simple devices and legacy systems may not support the basic management interaction primitives. Adapter objects (Figure 3.3) can be used to convert the interface actually provided by a resource into one which can interact with the management system. To some extent this is the function of OSI managed objects, but we believe that adapters are the exception rather than the rule as our emphasis is on managing software objects capable of providing the required management interface rather than hardware devices.
Management Interface
Distributed Service
Figure 3.1 Distributed service with multiple interfaces.
Management Interface
This need for management and normal interfaces applies to simple resources such as a software component (task or process) as well as complex services. A managed object is any object which supports a management interface. Managed Object Management Interface
Figure 3.2
Figure 3.3
Normal Functionality Interfaces
Managed Object
Resource Dependent Interface
External resource
Normal Interface
Managed object with external resource.
There are two approaches to defining interfaces. The static approach uses an IDL to define an interface in terms of a set of attributes, operations and the datatypes of the operation parameters. The IDL can be used to generate stub procedures for marshalling parameters and handling remote procedure calls in both client and server. Type checking can be performed at bind time. The interfaces may also specify attributes i.e. data variables which are explicitly made visible at the object interface and can be read or written. This is essentially “syntactic sugar” as it enables a compiler to automatically generate the required read and write operations for these variables. The second approach is more dynamic. The server has a single entry port for receiving operation invocation messages which define the operation to be invoked as well as specifying the parameter types. This requires run time type checking. OSI and SNMP essentially follow this approach as it is more flexible and fits in with their concept of a central human manager using a debug style of management, although the static approach can give better performance. OMG’s CORBA supports both styles of object invocation [11]. Our view is that the static IDL based approach is more suitable for implementing automated, preprogrammed managers which are responsible for a group of managed objects and give a higher level of abstraction to the next level of management. For example these manager agents could implement a reliable groupcast management operation invocation, or control the order in which a group of objects start up. The dynamic invocations are more suitable for human operator controlled higher level manager applications which may require interaction with
Managed object.
3.1 Management interactions In order to perform the activities outlined above, managers have to interact with objects they manage. A simple request-reply message transaction or remote procedure call can be used to obtain information from managed objects and to perform operations on them. In addition the managed objects requires a unidirectional message transfer service to emit event notifications. These simple primitives can be used for the lowest level monitoring and control and can be supported by a minimal communication system so can be used to install communication software and perform fault management within the communication system. The need for both RPC and asynchronous message interactions has been recognised by many distributed programming environments, as it is not specific to management. Some management functions require more sophisticated interactions such as reliable message streams, file transfers, reliable multicast to synchronise actions across multiple components, or atomic transactions. These are the sort of interactions needed for implementing many distributed applications and can be
4
so many different interfaces that it is not practical to support them in a single manager object.
define a comparatively simple self-managed object which includes a manager as well as a set of managed objects (figure 3.4). This composite object can be used as a component within a distributed server which has a number of manager objects performing different functions. A manager object may itself be a distributed composite object. This approach of using the same tools and techniques for specifying and implementing both the management system and the objects implementing the functionality of the service has an added advantage. It is simple to define management interfaces to the objects implementing the management system so the management system can itself be managed, which is essential in a large management system. For example the configuration management service can be used to install monitoring objects that are used for security management.
3.2 Management structure A hierarchical management structure may be very useful for many services. For example a local manager may be responsible for managing objects relating to a particular service within a server. The next level manager may be responsible for the servers on a local area network. In addition there may be automated managers responsible for performing specific functions such as fault management, security management or filtering of monitoring information. Hierarchical systems in which low level managers are responsible for short term management and control requiring fast response and higher level management is responsible for longer term supervisory control and monitoring is well understood and used in many control environments. For large-scale, complex services it is essential to provide as much intelligence as possible within local automated managers. A pure hierarchical approach is not appropriate for all management. The management of routing information, whereby routing nodes exchange routing information with neighbours, is a good example of peer-to-peer management. A pure hierarchy does not cater for interorganisational systems where managers need peer-to-peer protocols to negotiate and coordinate their activities. SNMP and OSI do not support the concept of peer-to-peer management but cater only for an hierarchical approach. We are using a configuration notation called Darwin to define the structure of composite object classes which could range from a window management system within a single workstation to a distributed service in a wide area network. Darwin defines the required object instances within the composite object; allocation of instances to physical nodes; bindings between internal object interfaces, to the interfaces provided by existing services or to the interface provided by the composite [9]. Graphical tools are being developed to permit dynamic online configuration management of a distributed service as part of an Esprit Project [6], and the tools are being adapted to support configuration of multi-media systems within a BT funded project.
3.3 Distributed processing services required As management is itself a distributed system it needs all the underlying distributed processing support services which are not specific to management: • Distributed file systems and distributed databases to hold object types, persistent management information i.e. to implement MIBs • Security is essential to control access to management information and operations. This must be sufficiently flexible to permit limited access to external managers, full access to internal managers but also to permit partitioned responsibility between different internal managers. • Time synchronisation is needed for timestamping messages and event reports and to synchronise activities. • Transactions are useful for synchronising updates of distributed information, making sure intermediate states are not made visible during updates and rolling back to a previous state if a failure occurs. • Directories and traders are needed to locate services and resources either by name or using a service description. This must cater for objects which migrate from one node to another because the user is mobile or to balance loads on processors. • The distributed object services permit transparent distribution of the management system – cooperating managers and managed objects spread over a number of nodes on a network. The object support system must permit configuration in terms of creation, deletion and possible migration of objects between nodes. It must also permit location transparent remote invocation and event notification. Further information on the how these services fit in with an overall Management Architecture can be found in [14].
Composite Managed Object
Management Interfaces
Figure 3.4
Managed Object Manager Object
Managed Object
Normal Interface
Composite managed object.
The Darwin approach to configuration can be used to define the structure of distributed management. We can
5
4 Management services
entity but must be distributed to reflect the distribution of the system being managed. Management must thus 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 organisations. There will be a variety of managers fulfilling different functions 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. Domains provide the framework for partitioning management responsibility by grouping objects in order to specify a management policy or for whatever reason a manager wishes. A management domain is a collection of managed objects which have been explicitly grouped together for the purposes of management. More concretely, a domain is a managed object which maintains a list of references to its member managed objects. If a domain holds a reference to an object, the object is said to be a direct member of that domain and the domain is said to be its parent. Since a domain is itself a managed object, it may be a member of another domain and is said to be a subdomain of its parent. Subdomains are the means of flexibly partitioning a large group of objects and applying different policies to different subgroups or assigning responsibility for applying policy to different managers. Members of a subdomain are indirect members of the parent domain. Managed objects can be direct or indirect members of multiple domains. Domains are similar to the notion of a directory commonly found in hierarchical file systems, but the fundamental motivation is one of grouping of objects to apply policy or for manager convenience rather than naming. A local name can be provided for an object in a domain – this can be very useful as an alias to objects which already have unique X.500 or OSI names as these can be very long and inconvenient for humans managers to use. A domain path name is not unique as an object can be a member of multiple domains to reflect the fact that different managers may be responsible for performing particular management functions on the same object. The domain service provides facilities to create/delete domains, insert/remove objects, list domain members and translate between path names and unique object identifiers. The SysMan project has implemented a distributed domain service using ANSAware [2], and this is being ported to a CORBA implementation while the IDSM project has chosen to implement a domain service within an OSI management environment as a particular type of MIB [1]. More information on domain concepts can be found in [13].
There are three services which are needed by all aspects of management
4.1 Monitoring service A generalised distributed monitoring service [8] is needed for all management functions, and includes: i) Generation of monitoring information – objects may have to be polled periodically to determine state and detect changes or may generate status messages and event reports. These monitoring reports are used to construct and log monitoring traces, which represent historical views of system activity. ii) Processing of monitored information – a generalised monitoring service provides common processing functionality such as merging of traces, validation of data (e.g. range checks) and database updating. Raw, low-level information can be converted to more abstract information by filtering and combining all reports relating to the same event; combining a number of events to form a new higher level event and calculation of averages from a set of data values. Analysis of historical information is needed to determine trends which can be useful for performance management. Example events which our event service can specify and generate include: on x:invalid_login [3] when ((@x > ‘17.00’) or (@x < ‘08.00’)) notify sec_violation
This generates a security violation event after 3 invalid logins outside normal office hours. on (x: Talarm and y:Palarm) when (abs (@x@y) < (2*sec)) notify disaster
This generates a disaster event when a Talarm and Palarm event occur, in any order, within a 2 second time period. iii) Dissemination of information is needed to users, managers or other management objects. They can register their requirements to receive particular monitoring information and events with the monitoring service, which is then responsible for disseminating this information. iv) Presentation of status and processed information is displayed to the human managers as part of a most management application. This can entail plotting graphs, histograms or event traces. The user interface should be adaptable and easily tailored to meet the requirements of individual managers.
4.2 Domain service Management of a distributed information system cannot be centralised in a single human or automated
6
4.3 Policy Service
policy. Parameter value constraints define permitted values for management operations. • Obligation polices can optionally be triggered by an event e.g. On error count > 100 monitoring agent must send warning message to operator. A high level obligation or authorisation policy may be refined into a number of lower level obligation and authorisation policies. For example a high level goal:
Distributed systems management involves monitoring the activity of a system, making management decisions and performing control actions to modify the behaviour of the system. Policies are one aspect of information which influences the behaviour of objects within the system. Authorisation policies define what an manager is permitted or not permitted to do. They constrain the information made available to managers and the operations they are permitted to perform on managed objects (see Figure 4.1). Obligation policies define what a manager must or must not do and hence guide the decision making process; the manager has to interpret policies in order to achieve the overall objectives of the organisation [15].
* O+ Manager M must protect Dept. D files from loss due to fire or media failure
could be refined, via many intermediate more detailed policies, into the following set of implementable ones in which an archiver (in Domain BackupSW) performs a backup to tape followed by one to a remote store. Authorisation policies are needed to permit backup software to read and mark files and to perform file transfer to the remote store address passed as a parameter.
Management Interface
Obligation Policies Interpret Information
Authorisation Policies
Software Process
* O+ At 22.00 every Thursday archiver {tape_backup} Domain Dfiles * O+ At 03.00 every Friday archiver {remote_backup (safestore1.ic.ac.uk)} Domain Dfiles * A+ Domain BackupS/W {read, write} Domain Dfiles * A+ Domain BackupS/W {file_transfer, file_access} Domain safestores
Normal Interfaces
Control Manager
Managed Object
The policy service provides the means for storing policy specifications, determining the objects to which they apply and performing analysis to detect conflicts and inconsistency We are currently investigating the implementation of managers which are provided with management policies which they interpret. New policies can be dynamically loaded into managers. This has some similarity with the approach being used by General Magic which has intelligent agents (programmed in an interpreted Telescript) which can be downloaded to servers or workstations within a telecommunication network to perform a function on behalf of a subscriber [19]. A discussion of the implementation of these policy concepts within the IDSM project can be found in [1]. Other approaches to the use of policy in management can be found in [4, 19, 12]
Figure 4.1 Policies Influence Behaviour. Human managers are adept at interpreting both formal and informal policy specifications and, if necessary, resolving conflicts when making decisions. However the size and complexity of large distributed systems has resulted in a trend towards automating many aspects of management into distributed components. If the policies are coded into these components they become inflexible and their behaviour can only be altered by recoding. There is thus a need to specify, represent and manipulate policy information independent from management components to enable dynamic change of policies and reuse of these components with different policies. We have defined a notation to specify policies which have the following characteristics: • Modality – positive or negative authorisation, positive or negative obligation • Subject domain which identifies the objects permitted (forbidden) to perform the activity or which must (must not) perform an obligation activity • Target domain which identifies the objects to which the activity is applied • Activity can range from a single operation to a sequence of operations • Constraints restrict the applicability of the policy. Temporal constraints specify time limits before, after or between which a policy applies e.g. between 09.00 and 17.00 or before 31 December 1994. They may be used to specify a validity time or expiry time for a
5
Conclusion
The key requirements for managing distributed services are: • Management of services should be designed at the same time as the normal functionality of the service and should be accessed via management interfaces. • Management can be treated as a distributed system which can be implemented using the same tools and techniques as any distributed services. • Any management interface should potentially be accessible to any authorised local or remote manager –
7
this implies local and remote communication should use the same interaction primitives. • A distributed management system must itself be managed. • Avoid re-inventing new concepts for management rather than adapting existing ones from the software engineering and distributed processing community. • All management functions requires three basic services – interpreted policy to permit modification of manager behaviours, domains to enable grouping of objects for structuring management and monitoring to obtain the information needed by managers. The OSI and SNMP management approaches are not based on distributed processing principles. However OSF's Distributed Management Environment (DME) is based on CORBA and does consider management as a distributed system [3]. A managed object can have multiple interfaces. DME supports an event service and also supports SNMP and CMIP invocations via adapters. They are working on a configuration notation as an extension to the IDL but there is no concept of domains or policies within DME. Although DME is the most promising of the “standard” approaches to management there is some doubt as to when the full functionality defined by DME will actually be delivered. A substantial part of the DME architecture would have to be developed within OSF rather than just integration of existing technology. The management architecture outlined in this paper is being followed by two Esprit projects – IDSM and SysMan. The industrial partners, Bull, Siemens, ICL and AEG are developing management products based on these concepts within their existing management platforms.
5. 6.
7. 8.
9.
10.
11. 12.
13.
14.
Acknowledgements 15.
I gratefully acknowledge financial support from Esprit SysMan (7026) and IDSM (6311), DTI ESF Project (IED/ 4/410/36/002) and BT Management of Multimedia Networks Project. I also acknowledge the contribution of my colleagues, working on these projects, to the concepts discussed in this paper.
17.
References
18.
1.
2.
3. 4.
16.
Alpers, H. Plansky, Concepts and Application of Policy Based Management, Proc. IFIP Int.Symposium o n Integrated Network Management, Chapman Hall, May 1995 ANSAware 4.1: Application Programming in ANSAware, Document RM.102.02, Architecture Projects Management, Poseidon House, Castle Park, Cambridge CM3 0RD, UK, Feb. 1993. M. Autrata, C. Strutt, DME Framework and Design, Network and Distributed Systems Management, ed. M. Sloman, Addison Wesley 1994, pp.604-628 K. Becker and D. Holden, Specifying the Dynamic Behaviour of Management Systems, Journal of Network
19.
8
and Systems Management, Vol. 1, pp. 281-298, Sep. 1993, Plenum Press R. Cohen, Telecommunications Management Network TMN, Network and Distributed Systems Management, ed. M. Sloman, Addison Wesley 1994, pp. 217-243 S. Crane et.al. Configuration Management for Distributed Software Services, IFIP Int. Symposium o n Integrated Network Management, Santa Barbara, May 1995 T. Jeffree, Guidelines for the Definition of Managed Objects, Network and Distributed Systems Management, ed. M. Sloman, Addison Wesley 1994, pp. 131-164 94 M. Mansouri-Samani, M. Sloman, Monitoring Distributed Systems, Network and Distributed Systems Management, ed. M. Sloman, Addison Wesley 1994, pp. 303-348 J. Magee, N. Dulay, J. Kramer, Regis: A Constructive Development Environment for Distributed Programs, IEE/IOP/BCS Distributed Systems Engineering, Vol. 1 , No. 4, pp. 304-312. J.D. Moffett and M.S. Sloman, User and Mechanism Views of Distributed System Management, IEE/IOP/BCS Distributed Systems Engineering, Vol. 1, No. 1, Aug. 1993, pp. 37-47. Object Management Group, The Common Object Request Broker Architecture (CORBA), Dec. 1991. J. Roos, P. Putter, and C. Bekker, Modelling Management Policy Using Enriched Managed Objects, Integrated Network Management III (C-12), H.-G Hegering, & Y. Yemini eds., North-Holland, 1993, pp. 207–215. M.S. Sloman, B.J. Varley, J.D. Moffett, K.P. Twidle, Domain Management and Accounting in an International Cellular Network, Integrated Network Management III (C-12), H.-G Hegering, & Y. Yemini eds., NorthHolland, 1993, pp. 193–206. M. Sloman, J. Magee , K. Twidle, and J. Kramer, An Architecture for Managing Distributed Systems, Proc. 4th IEEE Workshop on Future Trends of Distributed Computing Systems, Lisbon, Sep. 1993, pp 40-46. M. Sloman, Policy Driven Management for Distributed Systems, Journal of Network and Systems Management, Vol.2 No. 4., 1994, Plenum Press. W. Stallings Simple Network Management Protocol, Network and Distributed Systems Management, ed. M. Sloman, Addison Wesley 1994, pp. 165- 196. J. Tucker, OSI Structure of Management Information, Network and Distributed Systems Management, ed. M. Sloman, Addison Wesley 1994, pp. 95-130. J. White, Telescript Technology: The Foundation for the Electronic Marketplace, General Magic Inc., 2465 Latham Street, Mountain View, California 94040, USA. R. Wies, Policies in Network and Systems Management – Formal Definition and Architecture, Journal of Network and Systems Management, Vol. 2, No.1 pp. 63-83, March 1994, Plenum Press.
