A Functional Model of Cooperative System Management

INTERNATIONAL JOURNAL OF NETWORK MANAGEMENT Int. J. Network Mgmt., 8, 170–181 (1998)

A Functional Model of Cooperative System Management There is a need for information exchange and communication between management applications that are distributed over a large system. In this situation, a fundamental problem is how the management systems should cooperate in order to achieve overall management of a system. In order to address this problem, this article presents a functional model of cooperative system management.  1998 John Wiley & Sons, Ltd. By Bharat Bhushan and Ahmed Patel* Introduction he concept of cooperative working involves a number of persons working on a common task. In computer supported cooperative work (CSCW), computers are used to support the groups of person or application software working on common task.

T

Bharat Bhushan works as a researcher at GMD-FOKUS (German National Research Centre for Information Technology—Research Institute for Open Communication), Berlin. His areas of research include networks management, distributed systems, and co-operative working. Ahmed Patel is a lecturer in computer science and head of the Computer Networks and Distributed Systems Research Group. He is involved in various multi-national R&D projects in ESPRIT, RACE/ACTS, INFOSEC, AIM, COST and the Irish national Telecommunications programmes. His main research interests include network management, security, protocols, performance evaluation, intelligent networks, CSCW and open distributed processing systems. *Correspondence to: Ahmed Patel, Computer Networks and Distributed Systems Research Group, Department of Computer Science, University College Dublin, Belfield, Dublin 4, Ireland. Email: apatel얀ccvax.ucd.ie

 1998 John Wiley & Sons, Ltd.

Cooperative working requires the application of many disciplines including, sociology, organizational management and computer science. Cooperative working can be used in two types of tasks or problems: descriptive and prescriptive. If tasks or problems are descriptive then users are required to give new (or creative) input to the group in order to cooperate (e.g. software design, writing a paper, etc.). If tasks or problems are prescriptive then users are not required to give new input to the group in order to cooperate. They are routine tasks and mere routine action or input would suffice. Some commonly used systems management tasks are prescriptive: 쐌 Fault correction 쐌 Performance control and log maintenance 쐌 Recording and generating accounting information, 쐌 Maintaining integrity of protocol and resources 쐌 Availability evaluation These are procedural tasks. They do not require a new and creative input if a person or application

CCC 1055–7148/98/030170–11$17.50

A FUNCTIONAL MODEL OF CO-OPERATIVE SYSTEM MANAGEMENT

software is to carry them out. Therefore, systems management can be regarded as a prescriptive task. The concept of cooperative working is required for distributed systems management for two main reasons. First, managed resources are distributed geographically. Second, data and control are decentralized. This type of management environment requires an organization-wide system management, which allows personnel to share information and services. The concept of cooperative working can enable sharing of time-critical information and services not only within the boundary of an organization but also across several organizations. System management activities are inherently cooperative activities.

T

he concept of cooperative working can enable sharing of time-critical information and services not only within the boundary of an organization but also across several organizations.

The organization of this article is as follows. First, the requirements for cooperative system management are discussed. The main features of co-operative system management are briefly described. This is followed by a presentation of a functional model for cooperative system management and definitions of its components. The relationship between an existing group communications model, the AMIGO model, is explored. A demonstration of cooperative system management using components of the functional model is presented. Finally, an analysis of the cooperative aspects of functional model is given and the application of the model to other research areas is briefly discussed.

Requirements of Cooperative System Management There are three main requirements for cooperative system management. The first is that of overall system-wide management. When a managed system grows in size, the management functionality

 1998 John Wiley & Sons, Ltd.

171

needs to distribute for remote monitoring and control. Operation management and administration must be done across the boundaries of a managed system. System management should be proactive and automatic and intelligence-based management techniques should be used. The second requirement is the use of a system management framework which provides a broad range of management services. The system management model should support addition of new management services to the managing system and new managed resources to the managed system. The system management model should also support interoperability among different types of management applications. Finally, cooperation among several management applications is required. Management applications are required to share management information and services. Cooperation system management itself is an unorganized activity because operations occur in real-time in an open system and unexpected conditions may arise frequently. Also, information and management services required by system administrators and operators are incomplete and may contain only partial information for day-to-day operations. Means of coordination during cooperation are required in order to organise the cooperative system management activity. Management applications should be provided with means of coordination during cooperation.

Features of Cooperative System Management The system management of a distributed system is a cooperative activity, in which distributed managing modules co-operate for system management. The principal features of the cooperative system management, which are fully described in reference 1, are briefly discussed below. Phrases in italics are the principal features. Managing modules are autonomous and selfcontained cooperative entities. They provide services defined in terms of OSI management functional areas (FCAPS). There are two levels of interactions that occur during cooperative system management: interaction of a managing module with the managed system and interaction of the managing modules with each other. The first type of interac-

Int. J. Network Mgmt., 8, 170–181 (1998)

172

tion is a synchronous activity and communication occurs on a client–server basis. The second type of interaction is an asynchronous activity and communication occurs on a peer-to-peer basis. All managing modules interoperate using a common set of basic management operations, protocols, and system management functions. Managing modules are constructed as objects. The objects belong to an object class, which in turn represents a management functional area. This ensures that the functionality of managing modules is scalable and new services can be added within their management scope. Managing modules automatically coordinate the cooperative system management activity using a set of pre-specified guidelines. The managing modules interpret guidelines in order to decide which operations need to be executed. Guidelines provide all managing modules with the knowledge of management problems and means to solve problems cooperatively. They must be detailed and well defined and include operations to be executed and messages to be sent to other cooperating module. Detailed and well-defined guidelines ensure that cooperation is efficient and managing modules are responsive to each other. These guidelines are derived from the requirements process and subsequently applied to establish the rules. Specification of the participant and activities involved in co-operative system management uses the AMIGO Activity Model.2 This is a group communication model. There are two main reasons for selecting the AMIGO model. First, the concept of cooperative system management is oriented towards coordination of distributed management activities. Therefore the selected model must be oriented towards distributed management activity. Second, the problems are related to system management and the management environment is object-oriented. Therefore the bearing of the selected model should be towards system management problems and its components should correspond to the basic object-oriented concepts (i.e. class, methods, data) that lead to an objectoriented design. The AMIGO model meets these two requirements. In order to make coordination efficient, the need for cooperation between two cooperative managing modules is explicitly specified. For cooperative system management, one managing module uses management services supplied by the other man-

 1998 John Wiley & Sons, Ltd.

BHARAT BHUSHAN AND AHMED PATEL

aging module(s). This need is stated explicitly. It is used to specify issues such as which of the two managing modules starts the cooperation, when the cooperation ends, etc. Also, the solutions to management problems that can be anticipated can be composed and specified as actions in the coordination guidelines. A managing module can determine a specific event or alarm which may occur in the managed system and needs to be dealt with. By determining the need for cooperation and using a set of pre-specified guidelines, cooperation between managing modules can be automated. An event and alarm can start the cooperation between two managing modules and then pre-specified guidelines can coordinate the activities that occur during cooperation. All managing modules use a single management information model in order to manage the resources of a distributed system. This specifies what resources and management information are available in the managed system and what their status is. The basic unit of the shared information model is an object. A formal language is used to define the resources and management information in the information model. All managing modules use a single set of management operations to obtain and modify information from the management information model. A manager–agent paradigm is used for open and distributed system management. In this paradigm, the managing modules operate as a manager and invoke operations on system management agents. Managing modules, agents and the shared information model may be distributed over many hosts. From the description of the features of cooperative system management, the following functional characteristics are derived: 쐌 Autonomy and management services provided by the managing modules 쐌 Functional dependency of one managing module on other managing modules. Functional dependency is used to specify a relationship between two cooperative managing modules 쐌 The use of messages to carry operation requests, results and management information 쐌 The use of rules for the coordination of cooperative system management activity

Int. J. Network Mgmt., 8, 170–181 (1998)

A FUNCTIONAL MODEL OF CO-OPERATIVE SYSTEM MANAGEMENT

쐌 Four common operations for cooperative system management: send and receive to send and receive messages and open and close end-point for communication and service requests from one managing module to the other.

The Structure and Definition of the Functional Model Figure 1 illustrates the structure of the functional model. The managing modules are the entities that cooperate for the management of a distributed system. The rules coordinate the activities of the managing modules during cooperation. The managing modules use messages to communicate with

173

other managing modules and operations to share management information with other managing modules and to manage the resources using agents. The relationship specifies which managing module uses the management services of the other managing module. The system management agents distribute the management functionality of the managing module. The management information model is used as shared information scheme among all managing modules. Communication support provides the managing modules and system management agents with necessary communication services. Each of these components is defined in the following sub-sections.

Figure 1. The structure and information flow within the Functional Model.

 1998 John Wiley & Sons, Ltd.

Int. J. Network Mgmt., 8, 170–181 (1998)

174

BHARAT BHUSHAN AND AHMED PATEL

— Managing Modules — A managing module is an autonomous set of management applications that provide services defined in the OSI management functional areas. Management applications that provide one type of services are grouped into one managing module. A managing module therefore can be considered as a set of responsibilities delegated to its management applications. A managing module is a set of objects, which provide management services. The managing module is the base class for different types of managing modules, which represent various management functional areas. The managing module base class represents the top level of management function hierarchy. As the functional model is extended, other object classes can be inherited from the base object class. Each management application of a managing module can further derive its own object class, resulting in a hierarchical managing module class structure. For example, two managing modules, which are derived from managing module base object class, are the fault managing module and performance managing module. These two managing modules are classes within themselves. However, in the hierarchy of co-operating managing modules, they are derived instances of the base class which reside a level above in the class hierarchy. The fault-fix and fault-report applications of the fault module, which provide fault management services, are grouped into the fault module (similar grouping mechanism are described in references 3 and 4). The calculate-throughput and test-capacity applications, which provide performance management services, are grouped into the performance module. In order to achieve interoperability in this scheme, a managing module class that is derived from the base class can be given a unique name. The names of other classes that are derived from the base class can be formed by linking the names of all its parent classes. During cooperation, a managing module may use the services that are provided by other module(s). Also, management application in one managing module may use services of other management applications of the same managing module. Creating groups of management applications

 1998 John Wiley & Sons, Ltd.

facilitates information sharing. For example, performance-related management data obtained by the test-capacity application may be shared by the calculate-throughput application. If both applications are grouped into the same managing module, there will be no need to send this information to the calculate-throughput application. Managing modules can reduce the complexity of sharing management information and unnecessary message exchange can be avoided.

— Management Information Model— The information model provides the managing modules with a common schema of information. The management information model is used in cooperation system management in the following ways: 쐌 Messages carry information, which is obtained from the information model 쐌 Operations are executed on resources, which are modelled as objects and are part of the information model 쐌 As a result of cooperation information from the information model is manipulated. The information model specifies the types of information (e.g. fault-oriented information) a managing module can obtain, modify and share with other managing modules. The information model also specifies the specific need (e.g. eventtype or threshold) for which a managing module needs to start cooperation with another module. For distributed system management, the information model specifies with which system management agent in the distributed system a managing module should communicate. There can be many instances of the management information model, which may be distributed over many systems.

— System Management Agents — System management agents perform system management operations on distributed resources. Therefore they can be viewed as the components that distribute the functionality of managing modules. Agents make use of the management information model in order to obtain resource-specific

Int. J. Network Mgmt., 8, 170–181 (1998)

A FUNCTIONAL MODEL OF CO-OPERATIVE SYSTEM MANAGEMENT

information. Agents also monitor pre-specified events on behalf of managing modules and inform them of any events that occur.

— Messages — Managing modules use messages to communicate with each other. Messages are pre-defined and are exchanged in a real-time manner to carry management data, management operation requests and operation results. Messages are structured in such a way that a message can carry an operation request as well as a result (or acknowledgement) of the message received. New messages may also be introduced if the functional model is to be extended. In order to support this requirement, messages may also be categorized on the basis of their purpose and such categories can be represented by object classes. The communications between managing modules can be abstracted to form categories. For example, an abstraction can be done on the basis of what message is sent to which module. Other categories of message may be acknowledgement type, event report type and management information type. This categorization can provide three classes of messages from which new messages of a particular type can be derived.

— Operations — Managing modules use a set of operations to obtain, manipulate and share management information. Operations describe the action that a managing module takes when it receives a message. Operations can be locally or remotely executable. An operation can be characterized5 by the managing module that uses the operation, the rules that are used in the execution of the operation, and the events that invoke the operation. There are four types of operations (see operations in Figure 1). The managing modules use two types of operations for cooperation and two types are used by management applications for system management. Managing modules cooperate using operations Call(management-application-name) and messageexchange operations send(message) and receive(message). A managing module uses Call(management-application-name) when it wants to

 1998 John Wiley & Sons, Ltd.

175

provide a management service to another managing module. The send(message) and receive(message) operations are used by managing modules to exchange messages with each other. Management applications use three system management operations, namely Get, Set and EventReport. Management applications use connection management operations open-end-point(entityname) and close-end-point(entity-name to create and close end-points for communication with system management agents. When communicating with a managing module, the entity-name contains the logical address of a managing module. When communicating with an agent, the entity-name contains the logical name of an agent.

— Relationship — The relationship (shown in Figure 2) is one of the global components of the functional model and is derived from the functional dependency6 of managing modules. There can be many types of relationship between managing modules. The relationship relates managing modules by deciding three aspects of cooperation. The first concerns which managing module uses services and management information of which managing module. The second aspect concerns when they should cooperate. The third concerns which of the related managing modules initiates the cooperation. Inserting and deleting links between object classes can easily change the relationship among managing modules and new relationships can be established. An example of a relationship, the ‘uses’ relationship between the fault and the performance module, is shown in Figure 2. This relationship specifies that the performance module use the fault report and fault fix services of the fault module. By establishing this relationship, it is explicitly stated that out of many managing modules it is the fault module that contacts the performance module. The relationship ‘uses’ between the two modules is a one-to-one relationship where the performance module uses services provided by only one managing module, the fault module.

Int. J. Network Mgmt., 8, 170–181 (1998)

176

BHARAT BHUSHAN AND AHMED PATEL

Figure 2. Relationship between managing modules.

— Rules— Rules are also global parts of the functional model and coordinate the messages exchanged between managing modules. They specify what operations a managing module should perform when it receives a message or a predefined event occurs. All managing modules follow a common set of rules. Rules bind messages and events with one and more operations of a managing module. Constructing rules in this manner is also explained in references 7 and 8. Rules are defined in such a way that all possible message-exchanges between all the components can be pre-specified. A rule is specified in the following format: if 兵 (receive(message) OR兩AND event) 其 then 兵 (operation(s) ) 其

The above statement declares that if a specified event occurs or a message is received, the stated operation(s) are to be started. A specified message is then sent to a managing module or a management operation request is sent to an agent. Events occur at agents or managing modules. A simple example of an event occurred at an agent is when a fault type ABC occurs, a fault recovery action is to be started. In this example, the event occurred is ‘fault type ABC’. An example of an event triggered by a managing module is when a managing module detects that its peer managing module has not responded, the managing module that

 1998 John Wiley & Sons, Ltd.

observes the event sends a message to other managing modules.

— Communication Support — In order to allow managing modules to communicate with each other and with agents, the functional model includes communication support. The communication support organizes the communication paradigm and services that are required for cooperative system management. The messages and system management operations are submitted to the communication support, which carries them to managing modules or to the agents. There are two types of communication that are supported in the functional model: synchronous and asynchronous. With the synchronous communication support, managing modules can send Get and Set system management operations to a system management agent. With the asynchronous communication support, managing modules can share management information, send management requests to each other, and receive event notifications from agents. Cooperation and system management require guaranteed delivery of messages and system management operations. In order to meet this requirement, the communication support provides reliable message exchange between two modules.

— The AMIGO Activity Model — The AMIGO model was developed in order to support modelling of group communication pat-

Int. J. Network Mgmt., 8, 170–181 (1998)

A FUNCTIONAL MODEL OF CO-OPERATIVE SYSTEM MANAGEMENT

terns and meets the requirements of applications such as distribution lists, coordination of news reporting, etc. These applications have two aspects in common. The entities that take part in group communication can be clearly identified. Also, information produced by one entity is used by other entities. The AMIGO model includes both functional elements and the activities in which these elements may be involved.9 Research work described in reference 10 states how the AMIGO model has been used in defining an object-oriented framework for describing organizational communication. The AMIGO model has four main elements: role, message, function and rule. Role elements define the entities involved in the communication and their responsibilities. Message elements items are exchanged during communication. Function elements declare the individual operations to be performed by role elements. Rule elements define the actual procedure of starting an activity within the functional model. The necessary coordination of the role is declared in this element. During cooperation, the rule element coordinates the message exchange between roles. The functionality of all four elements can be extended to allow more sophisticated specification of the model. As described in reference 2, establishing a relationship between two roles can make an extension to the role element. Two other extensions, namely the management information model and system management agents, are made in order to meet the need for sharing of information in open and distributed environment. Communication services that the components of the functional model use for system management and cooperation are provided as communication support component.

A Specification of the Activities of the Model This section specifies how the components of the functional model are used to achieve cooperative system management. A cooperative system management activity using the functional model is illustrated in Figure 3. The main purpose of this specification is to present the modelling of cooperative system management activities using the components of the

 1998 John Wiley & Sons, Ltd.

177

functional model. From the specification, the main activities are identified and the rules and messages used are derived. There are three major phases in cooperative system management: 쐌 Initialization of cooperation system management: The initialization phase begins when a managing module receives a message from other managing modules or a predefined event occurs. The model checks the relationship and evaluates the message with rule. The outcome of the evaluation decides which service or management information to offer. The relationship between two managing modules is used to determine to which managing module the result of an operation is to be sent. 쐌 Cooperation: In this phase, the managing modules exchange messages with each other. When a message arrives at a managing module, it is evaluated and operations are invoked. The managing module uses rules to decide which operation to execute and which message to send. If a managing module receives a message containing a request to execute an operation on a resource, it sends the request to an agent. 쐌 Termination of cooperation system management: Eventually, one of the cooperating modules decides to terminate the cooperation. In the specification, the performance module and the fault module are cooperative entities. The problem presented shows the details of cooperative management activity and modelling of this activity with the functional model. In this specification, failure in a resource, which is required by the performance module, is being used as an instance of an event in a distributed system. The failure is denoted by resource status’s value −1. This scenario represents a typical problem is a large distributed system. Different types of activities are required to cooperatively solve it. The ‘uses’ relationship is used. This relationship states that the performance module uses fault reporting and fault fixing services of the fault module in that the fault module sends a message to the performance module when a fault occurs at an agent. The fault module, by calling the fault-fix application, fixes the fault when the performance module requests it.

Int. J. Network Mgmt., 8, 170–181 (1998)

178

BHARAT BHUSHAN AND AHMED PATEL

Figure 3. Activities occurring in co-operative system management.

— Initialization Phase — The fault and performance modules start as autonomous modules at state 1 and remain so until at state 2. During the initialization phase, the fault module is prompted by a message from an agent. At state 2, a fault occurs and fault-report receives a notification from an agent.

fication from agent. The fault module checks the above rule and the relationship, whereupon it finds that it is the performance module that uses its services. It opens a connection and sends the message ‘fault occurred’ to the performance module.

— Cooperation Phase — Rule 1: if (receive (“resource status = −1”) ) then 兵 send (“fault occurred”) 其

The above rule is used by the fault module when the fault-report application receives a fault report ‘resource status = −1’ as an event noti-

 1998 John Wiley & Sons, Ltd.

After the initialization phase, both modules are at state 2 and cooperation begins. The cooperation phase is short-term and services or management information offered are of immediate use. When the performance module receives the fault module’s message, it checks the rules. Applying rule 2 below, it opens a connection and replies with the message ‘restart resource’ to the fault module.

Int. J. Network Mgmt., 8, 170–181 (1998)

A FUNCTIONAL MODEL OF CO-OPERATIVE SYSTEM MANAGEMENT

179

Rule 2: if (receive(“fault occurred”)) then 兵 send (“restart resource”) 其

Rule 6: if (receive (“restart failed”) then 兵 send (“message accepted”) 其

The fault module uses the rule 3 when it receives the message ‘restart resource’. Here the action taken is to call the fault-fix application.

The above message-exchange takes place between states 2 and 3. The final message sent by the performance module ends the cooperation, after which the two modules start functioning autonomously. This example showed that the components of the functional model allow representation of a cooperative system management activity. Solving the problem selected in this section represented a goal-oriented activity in which two autonomous managing modules cooperated. Table 1 summarizes the messages exchanged and rules invoked when sending and receiving messages. This table may be used as a basis to produce design of rules that are used to coordinate the cooperation between the fault and the performance module.

Rule 3: if (receive(“restart resource”)) then 兵 return value = call (fault-fix) 其

The fault module checks whether the fault has been fixed. Rule 4 below is used when the faultfix application fixes the fault reported and tells the fault module that it has fixed the fault (by returning a value 0). Rule 4: if (return value = 0) then 兵 send (“resource restarted”) 其

— Termination Phase — In the termination phase, the decision to terminate can be taken by any of the managing modules that cooperated. The reason for terminating the cooperation is made clear by sending an appropriate message. The receiver of the message that terminates the cooperation must send an acknowledgement. For example, the fault-fix management may not fix the fault. If the faultfix application informs the fault module that it could not fix the fault, which it does by returning the value −1, the following rule is used: Rule 5: if (return value = −1) then 兵 send (“restart failed”) 其

If the performance module receives ‘restart failed’, it sends ‘message accepted’ to the fault module using rule 6.

 1998 John Wiley & Sons, Ltd.

Conclusions and Analysis This paper has presented a functional model of cooperative system management based on the object-oriented paradigm and supports group communication. The merits of using the functional model for distributed systems management have been evaluated by producing a design of a cooperative management system and implementing a prototype system.11 In order to conform to the cooperative working principles, a group communication model was used for the specification of the cooperative system management activities. This ensures that cooperative system management is not provided in an ad hoc manner. The following subsection analyses the cooperative aspects of functional model.

— Analysis of the Cooperative Aspects — 쐌 Use of intelligence-based management techniques: Three components of the functional model achieve intelligence-based management: rule, relationship and Call(management-application-name) operation. All management

Int. J. Network Mgmt., 8, 170–181 (1998)

180

BHARAT BHUSHAN AND AHMED PATEL

Message/Events

From

To

resource status = −1 fault occurred restart resource resource restarted restart failed message accepted

Agent

fault module performance module fault module performance module performance module fault module

fault module performance module fault module fault module performance module

Rule Rule Rule Rule Rule Rule Rule

1 2 3 4 5 6

Table 1. Rules and messages used to govern activity of fault and performance modules decisions taken by a managing module are conveyed to a management application with the call(management-application-name) operation. In turn, the management application called carries out the operation management. In order to inform the managing modules of the results of the operation, management applications communicate with the managing module using rules and relationship. 쐌 Group communication for distributed system management: The AMIGO Activity Model was used for the specification of participants and activities in cooperative system management. 쐌 Coordination: Cooperative system management requires that a set of predefined guidelines to be used in order to coordinate the cooperation between the managing modules. The functional model achieves the goal of coordination because the managing modules are responsive to each other. They operate simultaneously on a common task and share management information and services. The co-ordination mechanism used in the functional model makes use of a single set of predefined rules used by both managing modules. The need for cooperation is stated in terms of a relationship between the managing modules.

— Application Areas — There are two areas to which the functional model can be readily applied: TMN for services and networks management12,13 and intelligent management agents.14 Today’s telecommunication networks require automation and enhanced control capabilities for management and interfunctional area management is needed to support this requirement. The

 1998 John Wiley & Sons, Ltd.

TMN framework aims at the management of heterogeneous networks, services and equipment distributed over many operators and service providers. It provides rich management functionality and has provision for interworking among multiple management and operational systems.15 Many types of relationship exist among the users and the providers of telecommunication services and networks. In this development, the idea of cooperation among several management systems is competent. In cooperation, many administrators and operators share management information and services to manage heterogeneous resources (e.g. network elements) and operations. Therefore the functional model can be used in the area of TMN.

T

oday’s telecommunication networks require automation and enhanced control capabilities for management and interfunctional area management is needed to support this requirement.

The intelligent agent research area is novel and has many applications. Intelligent agents can be characterized by five fundamental attributes: integrated (i.e. supports interfaces), expressive (i.e. accepts requests), goal-oriented, cooperative and customized.16,17 The developed functional model exhibits these attributes. First, intelligence is incorporated into the autonomous objects. Second, objects interpret a set of rules to carry out management tasks. Third, support for autonomy and cooperation given. Finally, the autonomous objects have access to all information available. The functional model can be applied to develop two or more intelligent management agents.18

Int. J. Network Mgmt., 8, 170–181 (1998)

A FUNCTIONAL MODEL OF CO-OPERATIVE SYSTEM MANAGEMENT

References 1. B. Bhushan and A. Patel, Requirements and the concept of co-operative system management, International Journal of Network Management, 8 (3), 139– 158, May-June 1998. 2. T. Danielsen, AAM—The AMIGO Activity Model, in Computer Based Group Communication: The AMIGO activity model, edited by Pankoke-Babatz, pp. 72–97, Ellis Horwood, Chichester, 1989. 3. S. M. Dauber, Finding fault, BYTE, p. 207, Section ‘State of the Art’, March 1991. 4. D. Gaiti, Introducing intelligence in distributed systems management, Computer Communication, 17, No. 10, October 1994. 5. P. Hennessy et al., Distributed work management: activity coordination within the EuroCoOp Project, Special Issue: Computer Supported Co-operative Work, Computer Communication, 15, No. 8, 477–88, October 1992. 6. S. Ram, Deriving functional dependencies from the entity-relationship model, Communications of the ACM, 38, No. 9, September 1995. 7. J. Bowers et al., Local and global structuring of computer mediated communication: developing linguistic perspectives on CSCW in COSMOS, Proceedings of Conference on Computer-Supported Co-operative Work, September 1988, pp. 125–39, Association for Computing Machinery, Inc., 1988. 8. V. Tschammer et al., Co-operative management in open distributed system, Computer Communication, 17, No. 10, October 1994. 9. S. Benford, Requirements of activities management, Proceedings of the First European Conference on Computer Supported Co-operative Work—EC-CSCW ’89, 13–15 September 1989, pp. 276–85, Elsevier Science, London, 1989. 10. H. T. Smith, et al., The activity model environment:

 1998 John Wiley & Sons, Ltd.

11.

12. 13. 14. 15. 16. 17. 18.

181

an object-oriented framework for describing organisational communication, Proceedings of the First European Conference on Computer Supported Co-operative Work—EC-CSCW ’89, 13–15 September 1989, pp. 160–73, Elsevier Science, London, 1989. B. Bhushan, Application of Co-operative Working to the Management of a Heterogeneous Distributed System, PhD thesis dissertation, Department of Computer Science, University College Dublin, Belfield, Dublin 4, Ireland, February 1997. S. R. Hedberg, Industry Spotlight: The telecommunication network of the new millennium, IEEE Parallel and Distributed Technology, 4, No. 1, Spring 1996. S. R. Hedberg, AI’s impact in telecommunications— today and tomorrow, IEEE Expert, 11, No. 1, February 1996. A. M. Hayashi and S. E. Varney, Six hot technologies for the 21th century: software agents, Datamation, August 1996. CCITT Recommendation M.3010. Principles for a Telecommunication Management Network (TMN), ITUT, Geneva, 1989. D. Weld, The role of intelligent systems in the national information infrastructure, AI Magazine, 45–64, March 1995. C. Hsinchun et al., Toward intelligent meeting agents, IEEE Computers, August 1996. B. F. Lubomir et al., Distributed computing using autonomous objects, IEEE Computers, August 1996.

쮿 If you wish to order reprints for this or any other articles in the International Journal of Network Management, please see the Special Reprint instructions inside the front cover.

Int. J. Network Mgmt., 8, 170–181 (1998)