a functional model of cooperative system management

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

A Functional Model ofCooperative SystemManagementThere is a need for information exchange andcommunication between management applications that aredistributed over a large system. In this situation, afundamental problem is how the management systemsshould cooperate in order to achieve overall managementof a system. In order to address this problem, this articlepresents a functional model of cooperative systemmanagement. 1998 John Wiley & Sons, Ltd.

By Bharat Bhushan and Ahmed Patel*

Introduction

The concept of cooperative workinginvolves a number of persons workingon a common task. In computer sup-ported cooperative work (CSCW), com-

puters are used to support the groups of personor application software working on common task.

Bharat Bhushan works as a researcher at GMD-FOKUS (GermanNational Research Centre for Information Technology—ResearchInstitute for Open Communication), Berlin. His areas of researchinclude networks management, distributed systems, and co-operat-ive working.Ahmed Patel is a lecturer in computer science and head of the Com-puter Networks and Distributed Systems Research Group. He isinvolved in various multi-national R&D projects in ESPRIT,RACE/ACTS, INFOSEC, AIM, COST and the Irish national Tele-communications programmes. His main research interests includenetwork management, security, protocols, performance evaluation,intelligent networks, CSCW and open distributed processing systems.

*Correspondence to: Ahmed Patel, Computer Networks and Distrib-uted Systems Research Group, Department of Computer Science,University College Dublin, Belfield, Dublin 4, Ireland.Email: apatelKccvax.ucd.ie

1998 John Wiley & Sons, Ltd. CCC 1055–7148/98/030170–11$17.50

Cooperative working requires the application ofmany disciplines including, sociology, organiza-tional management and computer science.

Cooperative working can be used in two typesof tasks or problems: descriptive and prescriptive.If tasks or problems are descriptive then users arerequired to give new (or creative) input to thegroup in order to cooperate (e.g. software design,writing a paper, etc.). If tasks or problems are pre-scriptive then users are not required to give newinput to the group in order to cooperate. They areroutine tasks and mere routine action or inputwould suffice. Some commonly used systemsmanagement tasks are prescriptive:

I Fault correctionI Performance control and log maintenanceI Recording and generating accounting infor-

mation,I Maintaining integrity of protocol and

resourcesI Availability evaluation

These are procedural tasks. They do not require anew and creative input if a person or application

171A FUNCTIONAL MODEL OF CO-OPERATIVE SYSTEM MANAGEMENT

software is to carry them out. Therefore, systemsmanagement can be regarded as a prescriptivetask.

The concept of cooperative working is requiredfor distributed systems management for two mainreasons. First, managed resources are distributedgeographically. Second, data and control aredecentralized. This type of management environ-ment requires an organization-wide system man-agement, which allows personnel to share infor-mation and services. The concept of cooperativeworking can enable sharing of time-critical infor-mation and services not only within the boundaryof an organization but also across several organi-zations. System management activities areinherently cooperative activities.

The concept of cooperative working canenable sharing of time-critical

information and services not only withinthe boundary of an organization but alsoacross several organizations.

The organization of this article is as follows.First, the requirements for cooperative systemmanagement are discussed. The main features ofco-operative system management are brieflydescribed. This is followed by a presentation of afunctional model for cooperative system manage-ment and definitions of its components. Therelationship between an existing group communi-cations model, the AMIGO model, is explored. Ademonstration of cooperative system managementusing components of the functional model ispresented. Finally, an analysis of the cooperativeaspects of functional model is given and the appli-cation of the model to other research areas isbriefly discussed.

Requirements of CooperativeSystem Management

There are three main requirements for cooperat-ive system management. The first is that of overallsystem-wide management. When a managed sys-tem grows in size, the management functionality

1998 John Wiley & Sons, Ltd. Int. J. Network Mgmt., 8, 170–181 (1998)

needs to distribute for remote monitoring and con-trol. Operation management and administrationmust be done across the boundaries of a managedsystem. System management should be proactiveand automatic and intelligence-based manage-ment techniques should be used.

The second requirement is the use of a systemmanagement framework which provides a broadrange of management services. The system man-agement model should support addition of newmanagement services to the managing system andnew managed resources to the managed system.The system management model should also sup-port interoperability among different types ofmanagement applications.

Finally, cooperation among several manage-ment applications is required. Management appli-cations are required to share management infor-mation and services. Cooperation systemmanagement itself is an unorganized activitybecause operations occur in real-time in an opensystem and unexpected conditions may arise fre-quently. Also, information and management ser-vices required by system administrators and oper-ators are incomplete and may contain only partialinformation for day-to-day operations. Means ofcoordination during cooperation are required inorder to organise the cooperative system manage-ment activity. Management applications should beprovided with means of coordination duringcooperation.

Features of Cooperative SystemManagement

The system management of a distributed systemis a cooperative activity, in which distributed man-aging modules co-operate for system manage-ment. The principal features of the cooperativesystem management, which are fully described inreference 1, are briefly discussed below. Phrases initalics are the principal features.

Managing modules are autonomous and self-contained cooperative entities. They provide servicesdefined in terms of OSI management functionalareas (FCAPS). There are two levels of interactionsthat occur during cooperative system manage-ment: interaction of a managing module with themanaged system and interaction of the managingmodules with each other. The first type of interac-

172 BHARAT BHUSHAN AND AHMED PATEL

tion is a synchronous activity and communicationoccurs on a client–server basis. The second type ofinteraction is an asynchronous activity and com-munication occurs on a peer-to-peer basis.

All managing modules interoperate using a com-mon set of basic management operations, proto-cols, and system management functions. Manag-ing modules are constructed as objects. The objectsbelong to an object class, which in turn representsa management functional area. This ensures thatthe functionality of managing modules is scalableand new services can be added within their man-agement scope.

Managing modules automatically coordinate thecooperative system management activity using a set ofpre-specified guidelines. The managing modulesinterpret guidelines in order to decide which oper-ations need to be executed. Guidelines provide allmanaging modules with the knowledge of man-agement problems and means to solve problemscooperatively. They must be detailed and welldefined and include operations to be executed andmessages to be sent to other cooperating module.Detailed and well-defined guidelines ensure thatcooperation is efficient and managing modules areresponsive to each other. These guidelines arederived from the requirements process and sub-sequently applied to establish the rules.

Specification of the participant and activitiesinvolved in co-operative system management usesthe AMIGO Activity Model.2 This is a group com-munication model. There are two main reasons forselecting the AMIGO model. First, the concept ofcooperative system management is orientedtowards coordination of distributed managementactivities. Therefore the selected model must beoriented towards distributed managementactivity. Second, the problems are related to sys-tem management and the management environ-ment is object-oriented. Therefore the bearing ofthe selected model should be towards systemmanagement problems and its components shouldcorrespond to the basic object-oriented concepts(i.e. class, methods, data) that lead to an object-oriented design. The AMIGO model meets thesetwo requirements.

In order to make coordination efficient, the needfor cooperation between two cooperative managingmodules is explicitly specified. For cooperativesystem management, one managing module usesmanagement services supplied by the other man-


aging module(s). This need is stated explicitly. Itis used to specify issues such as which of the twomanaging modules starts the cooperation, whenthe cooperation ends, etc. Also, the solutions tomanagement problems that can be anticipated canbe composed and specified as actions in the co-ordination guidelines. A managing module candetermine a specific event or alarm which mayoccur in the managed system and needs to be dealtwith. By determining the need for cooperation andusing a set of pre-specified guidelines, cooperationbetween managing modules can be automated. Anevent and alarm can start the cooperation betweentwo managing modules and then pre-specifiedguidelines can coordinate the activities that occurduring cooperation.

All managing modules use a single managementinformation model in order to manage the resourcesof a distributed system. This specifies whatresources and management information are avail-able in the managed system and what their statusis. The basic unit of the shared information modelis an object. A formal language is used to definethe resources and management information in theinformation model. All managing modules use asingle set of management operations to obtain andmodify information from the management infor-mation model.

A manager–agent paradigm is used for open anddistributed system management. In this paradigm,the managing modules operate as a manager andinvoke operations on system management agents.Managing modules, agents and the shared infor-mation model may be distributed over manyhosts.

From the description of the features of cooperat-ive system management, the following functionalcharacteristics are derived:

I Autonomy and management services pro-vided by the managing modules

I Functional dependency of one managingmodule on other managing modules. Func-tional dependency is used to specify arelationship between two cooperative manag-ing modules

I The use of messages to carry operationrequests, results and management infor-mation

I The use of rules for the coordination ofcooperative system management activity


I Four common operations for cooperative sys-tem management: send and receive to send andreceive messages and open and close end-pointfor communication and service requests fromone managing module to the other.

The Structure and Definition ofthe Functional Model

Figure 1 illustrates the structure of the func-tional model. The managing modules are the entitiesthat cooperate for the management of a distributedsystem. The rules coordinate the activities of themanaging modules during cooperation. The man-aging modules use messages to communicate with

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


other managing modules and operations to sharemanagement information with other managingmodules and to manage the resources usingagents. The relationship specifies which managingmodule uses the management services of the othermanaging module. The system management agentsdistribute the management functionality of themanaging module. The management informationmodel is used as shared information scheme amongall managing modules. Communication support pro-vides the managing modules and system manage-ment agents with necessary communication ser-vices. Each of these components is defined in thefollowing sub-sections.


—Managing Modules—

A managing module is an autonomous set ofmanagement applications that provide servicesdefined in the OSI management functional areas.Management applications that provide one type ofservices are grouped into one managing module.A managing module therefore can be consideredas a set of responsibilities delegated to its manage-ment applications.

A managing module is a set of objects, whichprovide management services. The managing mod-

ule is the base class for different types of manag-ing modules, which represent various manage-ment functional areas. The managing module baseclass represents the top level of management func-tion hierarchy. As the functional model isextended, other object classes can be inheritedfrom the base object class. Each managementapplication of a managing module can furtherderive its own object class, resulting in a hier-archical managing module class structure.

For example, two managing modules, which arederived from managing module base object class,are the fault managing module and performance

managing module. These two managing modulesare classes within themselves. However, in thehierarchy of co-operating managing modules, theyare derived instances of the base class which residea level above in the class hierarchy. The fault-fix

and fault-report applications of the fault mod-ule, which provide fault management services, aregrouped into the fault module (similar groupingmechanism are described in references 3 and 4).The calculate-throughput and test-capacity

applications, which provide performance manage-ment services, are grouped into the performance

module.In order to achieve interoperability in this

scheme, a managing module class that is derivedfrom the base class can be given a unique name.The names of other classes that are derived fromthe base class can be formed by linking the namesof all its parent classes.

During cooperation, a managing module mayuse the services that are provided by othermodule(s). Also, management application in onemanaging module may use services of other man-agement applications of the same managing mod-ule.

Creating groups of management applications


facilitates information sharing. For example, per-formance-related management data obtained bythe test-capacity application may be shared bythe calculate-throughput application. If bothapplications are grouped into the same managingmodule, there will be no need to send this infor-mation to the calculate-throughput application.Managing modules can reduce the complexity ofsharing management information and unnecessarymessage exchange can be avoided.

—Management Information Model—

The information model provides the managingmodules with a common schema of information.The management information model is used in co-operation system management in the followingways:

I Messages carry information, which isobtained from the information model

I Operations are executed on resources, whichare modelled as objects and are part of theinformation model

I As a result of cooperation information fromthe information model is manipulated.

The information model specifies the types ofinformation (e.g. fault-oriented information) amanaging module can obtain, modify and sharewith other managing modules. The informationmodel also specifies the specific need (e.g. event-type or threshold) for which a managing moduleneeds to start cooperation with another module.For distributed system management, the infor-mation model specifies with which system man-agement agent in the distributed system a manag-ing module should communicate. There can bemany instances of the management informationmodel, which may be distributed over many sys-tems.

—System Management Agents—

System management agents perform systemmanagement operations on distributed resources.Therefore they can be viewed as the componentsthat distribute the functionality of managing mod-ules. Agents make use of the management infor-mation model in order to obtain resource-specific


information. Agents also monitor pre-specifiedevents on behalf of managing modules and informthem of any events that occur.

—Messages—

Managing modules use messages to communi-cate with each other. Messages are pre-definedand are exchanged in a real-time manner to carrymanagement data, management operationrequests and operation results. Messages are struc-tured in such a way that a message can carry anoperation request as well as a result (oracknowledgement) of the message received.

New messages may also be introduced if thefunctional model is to be extended. In order tosupport this requirement, messages may also becategorized on the basis of their purpose and suchcategories can be represented by object classes.The communications between managing modulescan be abstracted to form categories. For example,an abstraction can be done on the basis of whatmessage is sent to which module. Other categoriesof message may be acknowledgement type, eventreport type and management information type.This categorization can provide three classes ofmessages from which new messages of a parti-cular type can be derived.

—Operations—

Managing modules use a set of operations toobtain, manipulate and share management infor-mation. Operations describe the action that a man-aging module takes when it receives a message.Operations can be locally or remotely executable.An operation can be characterized5 by the manag-ing module that uses the operation, the rules thatare used in the execution of the operation, and theevents that invoke the operation. There are fourtypes of operations (see operations in Figure 1). Themanaging modules use two types of operations forcooperation and two types are used by manage-ment applications for system management.

Managing modules cooperate using operationsCall(management-application-name) and message-exchange operations send(message) andreceive(message). A managing module usesCall(management-application-name) when it wants to


provide a management service to another manag-ing module. The send(message) and receive(message)operations are used by managing modules toexchange messages with each other.

Management applications use three system man-agement operations, namely Get, Set and Event-Report. Management applications use connectionmanagement operations open-end-point(entity-name) and close-end-point(entity-name to create andclose end-points for communication with systemmanagement agents. When communicating with amanaging module, the entity-name contains thelogical address of a managing module. When com-municating with an agent, the entity-name con-tains the logical name of an agent.

—Relationship—

The relationship (shown in Figure 2) is one ofthe global components of the functional model andis derived from the functional dependency6 ofmanaging modules. There can be many types ofrelationship between managing modules. Therelationship relates managing modules by decid-ing three aspects of cooperation. The first concernswhich managing module uses services and man-agement information of which managing module.The second aspect concerns when they shouldcooperate. The third concerns which of the relatedmanaging modules initiates the cooperation.Inserting and deleting links between object classescan easily change the relationship among manag-ing modules and new relationships can be estab-lished.

An example of a relationship, the ‘uses’ relation-ship between the fault and the performance

module, is shown in Figure 2. This relationshipspecifies that the performance module use thefault report and fault fix services of the fault

module. By establishing this relationship, it isexplicitly stated that out of many managing mod-ules it is the fault module that contacts the per-

formance module. The relationship ‘uses’ betweenthe two modules is a one-to-one relationship wherethe performance module uses services providedby only one managing module, the fault module.


Figure 2. Relationship between managing modules.

—Rules—

Rules are also global parts of the functionalmodel and coordinate the messages exchangedbetween managing modules. They specify whatoperations a managing module should performwhen it receives a message or a predefined eventoccurs. All managing modules follow a commonset of rules.

Rules bind messages and events with one andmore operations of a managing module. Con-structing rules in this manner is also explained inreferences 7 and 8. Rules are defined in such a waythat all possible message-exchanges between allthe components can be pre-specified. A rule isspecified in the following format:

if h(receive(message) OR uAND event)

jthen h

(operation(s) )j

The above statement declares that if a specifiedevent occurs or a message is received, the statedoperation(s) are to be started. A specified messageis then sent to a managing module or a manage-ment operation request is sent to an agent. Eventsoccur at agents or managing modules. A simpleexample of an event occurred at an agent is whena fault type ABC occurs, a fault recovery action isto be started. In this example, the event occurredis ‘fault type ABC’. An example of an event trig-gered by a managing module is when a managingmodule detects that its peer managing module hasnot responded, the managing module that


observes the event sends a message to other man-aging modules.

—Communication Support—

In order to allow managing modules to com-municate with each other and with agents, thefunctional model includes communication sup-port. The communication support organizes thecommunication paradigm and services that arerequired for cooperative system management. Themessages and system management operations aresubmitted to the communication support, whichcarries them to managing modules or to theagents. There are two types of communication thatare supported in the functional model: synchron-ous and asynchronous. With the synchronouscommunication support, managing modules cansend Get and Set system management operationsto a system management agent. With the asyn-chronous communication support, managingmodules can share management information, sendmanagement requests to each other, and receiveevent notifications from agents. Cooperation andsystem management require guaranteed deliveryof messages and system management operations.In order to meet this requirement, the communi-cation support provides reliable message exchangebetween two modules.

—The AMIGO Activity Model—

The AMIGO model was developed in order tosupport modelling of group communication pat-


terns and meets the requirements of applicationssuch as distribution lists, coordination of newsreporting, etc. These applications have two aspectsin common. The entities that take part in groupcommunication can be clearly identified. Also,information produced by one entity is used byother entities. The AMIGO model includes bothfunctional elements and the activities in whichthese elements may be involved.9 Research workdescribed in reference 10 states how the AMIGOmodel has been used in defining an object-orientedframework for describing organizational com-munication.

The AMIGO model has four main elements: role,message, function and rule. Role elements define theentities involved in the communication and theirresponsibilities. Message elements items areexchanged during communication. Functionelements declare the individual operations to beperformed by role elements. Rule elements definethe actual procedure of starting an activity withinthe functional model. The necessary coordinationof the role is declared in this element. During co-operation, the rule element coordinates the mess-age exchange between roles.

The functionality of all four elements can beextended to allow more sophisticated specificationof the model. As described in reference 2, estab-lishing a relationship between two roles can makean extension to the role element. Two other exten-sions, namely the management information modeland system management agents, are made in orderto meet the need for sharing of information inopen and distributed environment. Communi-cation services that the components of the func-tional model use for system management and co-operation are provided as communication sup-port component.

A Specification of the Activitiesof the Model

This section specifies how the components of thefunctional model are used to achieve cooperativesystem management. A cooperative system man-agement activity using the functional model isillustrated in Figure 3.

The main purpose of this specification is topresent the modelling of cooperative system man-agement activities using the components of the


functional model. From the specification, the mainactivities are identified and the rules and messagesused are derived. There are three major phases incooperative system management:

I Initialization of cooperation system management:The initialization phase begins when a man-aging module receives a message from othermanaging modules or a predefined eventoccurs. The model checks the relationship andevaluates the message with rule. The outcomeof the evaluation decides which service ormanagement information to offer. Therelationship between two managing modulesis used to determine to which managing mod-ule the result of an operation is to be sent.

I Cooperation: In this phase, the managing mod-ules exchange messages with each other.When a message arrives at a managing mod-ule, it is evaluated and operations areinvoked. The managing module uses rules todecide which operation to execute and whichmessage to send. If a managing modulereceives a message containing a request toexecute an operation on a resource, it sendsthe request to an agent.

I Termination of cooperation system management:Eventually, one of the cooperating modulesdecides to terminate the cooperation.

In the specification, the performance moduleand the fault module are cooperative entities.The problem presented shows the details ofcooperative management activity and modellingof this activity with the functional model. In thisspecification, failure in a resource, which isrequired by the performance module, is beingused as an instance of an event in a distributedsystem. The failure is denoted by resource status’svalue −1. This scenario represents a typical prob-lem is a large distributed system. Different typesof activities are required to cooperatively solve it.The ‘uses’ relationship is used. This relationshipstates that the performance module uses faultreporting and fault fixing services of the fault

module in that the fault module sends a messageto the performance module when a fault occursat an agent. The fault module, by calling thefault-fix application, fixes the fault when theperformance module requests it.


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

—Initialization Phase—

The fault and performance modules start asautonomous modules at state 1 and remain sountil at state 2. During the initialization phase, thefault module is prompted by a message from anagent. At state 2, a fault occurs and fault-report

receives a notification from an agent.

Rule 1:if (receive (“resource status = −1”) )

then hsend (“fault occurred”)

j

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


fication from agent. The fault module checks theabove rule and the relationship, whereupon itfinds that it is the performance module that usesits services. It opens a connection and sends themessage ‘fault occurred’ to the performance mod-ule.

—Cooperation Phase—

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


Rule 2:if (receive(“fault occurred”))

then hsend (“restart resource”)

j

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

Rule 3:if (receive(“restart resource”))

then hreturn value = call (fault-fix)

j

The fault module checks whether the fault hasbeen fixed. Rule 4 below is used when the fault-

fix application fixes the fault reported and tells thefault module that it has fixed the fault (byreturning a value 0).

Rule 4:if (return value = 0)

then hsend (“resource restarted”)

j

—Termination Phase—

In the termination phase, the decision to termin-ate can be taken by any of the managing modulesthat cooperated. The reason for terminating thecooperation is made clear by sending an appropri-ate message. The receiver of the message that ter-minates the cooperation must send an acknowl-edgement. For example, the fault-fix

management may not fix the fault. If the fault-

fix application informs the fault module that itcould not fix the fault, which it does by returningthe value −1, the following rule is used:

Rule 5:if (return value = −1)

then hsend (“restart failed”)

j

If the performance module receives ‘restart fai-led’, it sends ‘message accepted’ to the fault mod-ule using rule 6.


Rule 6:if (receive (“restart failed”)

then hsend (“message accepted”)

j

The above message-exchange takes placebetween states 2 and 3. The final message sent bythe performance module ends the cooperation,after which the two modules start functioningautonomously.

This example showed that the components ofthe functional model allow representation of a co-operative system management activity. Solvingthe problem selected in this section represented agoal-oriented activity in which two autonomousmanaging modules cooperated. Table 1 summar-izes the messages exchanged and rules invokedwhen sending and receiving messages. This tablemay be used as a basis to produce design of rulesthat are used to coordinate the cooperationbetween the fault and the performance module.

Conclusions and AnalysisThis paper has presented a functional model of

cooperative system management based on theobject-oriented paradigm and supports groupcommunication. The merits of using the functionalmodel for distributed systems management havebeen evaluated by producing a design of acooperative management system andimplementing a prototype system.11

In order to conform to the cooperative workingprinciples, a group communication model wasused for the specification of the cooperative sys-tem management activities. This ensures thatcooperative system management is not providedin an ad hoc manner. The following subsectionanalyses the cooperative aspects of functionalmodel.

—Analysis of the Cooperative Aspects—

I Use of intelligence-based management techniques:Three components of the functional modelachieve intelligence-based management: rule,relationship and Call(management-appli-cation-name) operation. All management


Message/Events From To Rule

resource status = −1 Agent fault module Rule 1fault occurred fault module performance module Rule 2restart resource performance module fault module Rule 3resource restarted fault module performance module Rule 4restart failed fault module performance module Rule 5message accepted performance module fault module Rule 6

Table 1. Rules and messages used to govern activity of fault and performance modules

decisions taken by a managing module areconveyed to a management application withthe call(management-application-name) oper-ation. In turn, the management applicationcalled carries out the operation management.In order to inform the managing modules ofthe results of the operation, managementapplications communicate with the managingmodule using rules and relationship.

I Group communication for distributed systemmanagement: The AMIGO Activity Model wasused for the specification of participants andactivities in cooperative system management.

I Coordination: Cooperative system manage-ment requires that a set of predefined guide-lines to be used in order to coordinate thecooperation between the managing modules.The functional model achieves the goal ofcoordination because the managing modulesare responsive to each other. They operatesimultaneously on a common task and sharemanagement information and services. Theco-ordination mechanism used in the func-tional model makes use of a single set of pre-defined rules used by both managing mod-ules. The need for cooperation is stated interms of a relationship between the manag-ing modules.

—Application Areas—

There are two areas to which the functionalmodel can be readily applied: TMN for servicesand networks management12,13 and intelligentmanagement agents.14

Today’s telecommunication networks requireautomation and enhanced control capabilities formanagement and interfunctional area manage-ment is needed to support this requirement. The


TMN framework aims at the management of het-erogeneous networks, services and equipment dis-tributed over many operators and service pro-viders. It provides rich management functionalityand has provision for interworking among mul-tiple management and operational systems.15

Many types of relationship exist among the usersand the providers of telecommunication servicesand networks. In this development, the idea ofcooperation among several management systemsis competent. In cooperation, many administratorsand operators share management information andservices to manage heterogeneous resources (e.g.network elements) and operations. Therefore thefunctional model can be used in the area of TMN.

Today’s telecommunication networksrequire automation and enhanced

control capabilities for management andinterfunctional area management is neededto support this requirement.

The intelligent agent research area is novel andhas many applications. Intelligent agents can becharacterized by five fundamental attributes: inte-grated (i.e. supports interfaces), expressive (i.e.accepts requests), goal-oriented, cooperative andcustomized.16,17 The developed functional modelexhibits these attributes. First, intelligence is incor-porated into the autonomous objects. Second,objects interpret a set of rules to carry out manage-ment tasks. Third, support for autonomy and co-operation given. Finally, the autonomous objectshave access to all information available. The func-tional model can be applied to develop two ormore intelligent management agents.18


References

1. B. Bhushan and A. Patel, Requirements and the con-cept of co-operative system management, Inter-national 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 AMIGOactivity 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 sys-tems 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 theentity-relationship model, Communications of theACM, 38, No. 9, September 1995.

7. J. Bowers et al., Local and global structuring of com-puter mediated communication: developing linguis-tic perspectives on CSCW in COSMOS, Proceedingsof Conference on Computer-Supported Co-operativeWork, September 1988, pp. 125–39, Association forComputing Machinery, Inc., 1988.

8. V. Tschammer et al., Co-operative management inopen distributed system, Computer Communication,17, No. 10, October 1994.

9. S. Benford, Requirements of activities management,Proceedings of the First European Conference on Com-puter 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:


an object-oriented framework for describing organ-isational communication, Proceedings of the First Eur-opean Conference on Computer Supported Co-operativeWork—EC-CSCW ’89, 13–15 September 1989,pp. 160–73, Elsevier Science, London, 1989.

11. B. Bhushan, Application of Co-operative Working to theManagement of a Heterogeneous Distributed System,PhD thesis dissertation, Department of ComputerScience, University College Dublin, Belfield, Dublin4, Ireland, February 1997.

12. S. R. Hedberg, Industry Spotlight: The telecommuni-cation network of the new millennium, IEEE Paralleland Distributed Technology, 4, No. 1, Spring 1996.

13. S. R. Hedberg, AI’s impact in telecommunications—today and tomorrow, IEEE Expert, 11, No. 1, Febru-ary 1996.

14. A. M. Hayashi and S. E. Varney, Six hot technologiesfor the 21th century: software agents, Datamation,August 1996.

15. CCITT Recommendation M.3010. Principles for aTelecommunication Management Network (TMN), ITU-T, Geneva, 1989.

16. D. Weld, The role of intelligent systems in thenational information infrastructure, AI Magazine,45–64, March 1995.

17. C. Hsinchun et al., Toward intelligent meetingagents, IEEE Computers, August 1996.

18. B. F. Lubomir et al., Distributed computing usingautonomous objects, IEEE Computers, August 1996.

K

If you wish to order reprints for this or anyother articles in the International Journal ofNetwork Management, please see the SpecialReprint instructions inside the front cover.

a functional model of cooperative system management

Documents