A Functional Model of Cooperative System Management: by Bharat Bhushan and Ahmed Patel

INTERNATIONAL JOURNAL OF NETWORK MANAGEMENT
Int. J. Network Mgmt., 8, 170181 (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.
Bharat Bhushan works as a researcher at GMD-FOKUS (German

National Research Centre for Information TechnologyResearch
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: apatelccvax.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 10557148/98/03017011$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.
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
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-
172
tion is a synchronous activity and communication

occurs on a clientserver 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-
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 manageragent 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
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.
174
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
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
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
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.
176
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) ORAND 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
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-
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
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 statuss
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.
178
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-
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 modules message, it checks the rules. Applying rule 2
below, it opens a connection and replies with the
message restart resource to the fault module.
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.
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
180
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
Todays telecommunication networks require
automation and enhanced control capabilities for
management and interfunctional area management is needed to support this requirement. The
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.
odays 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
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, AAMThe AMIGO Activity Model,
in Computer Based Group Communication: The AMIGO
activity model, edited by Pankoke-Babatz, pp. 7297,
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, 47788,
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. 12539, 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 WorkEC-CSCW 89,
1315 September 1989, pp. 27685, Elsevier Science,
London, 1989.
10. H. T. Smith, et al., The activity model environment:
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
WorkEC-CSCW 89, 1315 September 1989,
pp. 16073, 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, AIs 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,
4564, 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.

A Functional Model of Cooperative System Management: by Bharat Bhushan and Ahmed Patel

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

A Functional Model of Cooperative System Management: by Bharat Bhushan and Ahmed Patel

Uploaded by

Copyright:

Available Formats

INTERNATIONAL JOURNAL OF NETWORK MANAGEMENT

Int. J. Network Mgmt., 8, 170181 (1998)

Bharat Bhushan works as a researcher at GMD-FOKUS (German

1998 John Wiley & Sons, Ltd.

Cooperative working requires the application of