MANAGING COMPOSITE OBJECTS IN A NETWORK

Abstract: A software object model for modelling resources (resource instances (RI) and resource types (RT)) in a network management system. The model comprises object instances (OI) and object classes (OC). Each class comprises fragments (FG) of data and/or program code and is a generalization of one or more object instances (OI). The model models each resource type (RT) by an object class (OC) and assigns to the class a class version identifier (CVI) which indicates at least some capabilities of the resource (RI, RT) and a collection of the fragments (FG) included in the class (OC) of the version in question. The model further models each resource instance (RI) by an object instance (OI) of the corresponding class, and assigns to the instance (OI) an object instance identifier (OII) and an instance version identifier (IVI) which indicate the version of the class (OC) used for modelling the resource type (RT) in question.

Description: Managing composite objects in a network Background of the invention The invention relates to methods and equipment for managing composite objects in a data processing system for a telecommunication net- work, such as in a telephone exchange. Network management standards are nowadays largely based on object-oriented descriptions, though the prevailing standards do not require the use of this technique. Objects are data structures in a network management system, which describe the functions and state of a network component. An object is an element having. certain attributes ("I am like this") and certain operations ("I can do these things"). In the object-oriented approach, objects with the same data structure (attributes) and the same behaviour (operations) are grouped into a class. A specific implementation of an operation is called a method and each object is said to be an instance of its class. A typical object is, for example, a representation of a cross-connection device with certain attributes (cross-connections that are active) and certain methods (e.g. make a cross-connection and release a cross-connection). An example of object-based network management is disclosed in co-assigned patent application W097/24837, which is incorporated herein by reference. A 'physical resource' (of a network) is a tangible resource, such as a cable, port, channel. A 'logical resource' is typically a physical resource with some enhancements or added value, such as a cable group which is an arbitrary combination of cables, or a path which is a route across a network, utilising cables, ports and channels. However, the distinction between physical and logical resources is not essential for understanding or implementing the invention. They both belong to the category of real resources (or simply 'resources'), as distinct from software classes (of software objects), which are used for modelling real (i.e. physical or logical) resource types. A resource type represents a set or group of substantially similar network resources, such as circuits or ports. A resource instance is an individual instantiation of a resource type, for example 'circuit 1234' or 'port 2-21'. A software object is an instance of an object class. A managed or manageable object (MO) refers to a software presentation of a network resource which is capable of sending notifications or measurements and/or which must be configured from a network management system (NMS). Managed objects are typically implemented in several subsystems, such as: in the network element (NE) proper; on the element management layer (EML) of the network manage- ment system (NMS); in a regional subsystem of the network management layer (NML) of the NMS; in a network-wide subsystem of the NML of the NMS; in the service management layer (SML) of the NMS; in one or more planning systems. The above list is for illustration rather than limitation; there may be other subsystems where manageable objects are stored, and some of these subsystems may not be present in every telecommunications system. There are valid reasons in favour of storing a separate realization of an MO in each of these subsystems. For example, these subsystems operate on different aspects of a given MO. Especially when a new subsystem is being constructed, aspects relating to other subsystems are not known (yet). In addition, telecommunication systems have high availability requirements which are difficult to meet by a single realisation accessed over data communication links. A problem with the prior art object-management mechanism is that implementing, operating and maintaining multiple realizations of a single MO is resource-consuming and error-prone. Disclosure of the invention An object of the invention is to provide a mechanism for eliminating, or at least mitigating the above problem. This object is achieved with a method and equipment which are characterized by what is disclosed in the attached independent claims. Preferred embodiments of the invention are disclosed in the attached dependent claims. According to one aspect of the invention, there is provided a method for modelling a plurality of resources in a network management system. The resources comprise resource instances and resource types such that each resource type is a generalization of one or more resource instances. The method comprises forming a software object model which comprises object in- stances and object classes, wherein each object class comprises fragments of data and/or program code and is a generalization of one or more object in- stances, each instance inheriting the capabilities of the corresponding class. Each resource type is modelled by a software object class, and a class version identifier is assigned to the object class. The class version identifier directly or indirectly indicates: (a) at least some capabilities of the resource; and (b) a collection of the fragments included in the object class of the version in question. Each resource instance is modelled by an object instance of the corresponding class. The method further comprises assigning to the object in- stance an object instance identifier and an instance version identifier which directly or indirectly indicate the version of the class which is used for modelling the real resource type in question. An advantage of the invention as defined above is that it lays a software foundation for the embodiments defined by the dependent claims. Another advantage is that the invention enables a network operator to change, add or delete code/data fragments dynamically (at run-time). When fragments are changed, added or deleted, the object class version is changed. Each object class version preferably implements all the features of an older version. Since the objects retain their instance versions, it is possible to perform an object instance version inquiry. Based on the results of this inquiry, it is possible to use an appropriate interface (collection of fragments) to the object in question. A benefit of this approach is that it reduces the amount of required software to manage network elements of many different versions. According to a preferred embodiment of the invention, each MO is implemented as one single composite object which is accessible to all subsystems by means of distributed object technology. An advantage of this embodiment is that the number of different versions and implementations of an MO is reduced. According to another preferred embodiment of the invention, each object class version implements all the features of the objects with the same object identifier but with an older version identifier. An advantage of this embodiment is that the system is backwards-compatible. Brief description of the drawings The invention will be described in more detail by means of preferred embodiments with reference to the appended drawings in which: Figure 1 is a block diagram which illustrates a method according to the invention for modelling real resources with software objects; Figure 2 is a signalling illustrating a possible set of events in a telecommunication network according to the invention; Figure 3 illustrates a prior art mechanism of managing manageable objects; and Figure 4 illustrates an object-managing mechanism according to the invention. Detailed description of the invention Figure 1 illustrates modelling real resources with software objects. A horizontal dashed line separates a software model according to the invention from real world resources. A software application APPL utilizes (software) object classes. Each real (physical or logical) resource type RT is modelled by a separate object class OC. The class is provided with a class version identifier CVI which directly or indirectly indicates the capabilities of the real resource type being modelled. This means that the capabilities (the attributes and methods) of a resource type are modelled by an object class. A class is instantiated as a resource type is instantiated. Each real resource instance RI is modelled by a software object instance OI of the corresponding class. The software object instance is provided with a unique object instance identifier Oil. Additionally, it is provided with an object instance version identifier IVI which directly or indirectly indicates the model class version which must be used to model the corresponding real resource. Software objects (classes and instances), which are used to model real resources, consist of fragments FG of data and program code. The class version identifier CVI directly or indirectly indicates a collection of fragments included in each particular version of the software object. When changes are needed to the modelling of a real resource, new fragments of program code and/or data are added to the software object class, and the class version identifier CVI is changed to represent the new collection of fragments. When a software object is instantiated (generated), the correct version of the model in selected by using the object instance version identifier OVI. Figure 2 is a signalling diagram illustrating a possible set of events in a telecommunication network according to the invention. Let us assume that a software application needs to use an object instance OI of a given version. In step 2-2, the application sends the object instance a version inquiry. In step 2-4, the object instance returns its version number xyz. In step 2-6, the application requests the corresponding object class to instantiate an object with an interface of this particular version. In step 2-8, the object class instantiates such an object instance. In step 2-10, the application uses the object instance by sending a procedure call. In step 2-12, the object instance communicates with the real resource instance which returns a response in step 2-14. The response is returned to the application in step 2-16. In step 2-18, the application deletes the object instance. An essential difference between telecommunication systems and stand-alone computer systems is that telecommunication systems cannot be shut down for adding new fragments. This is why new fragments must be implemented so that they can be incorporated in a software object in a running network management system. This feature of the invention is illustrated in figures 3 and 4, of which the former illustrates a prior art mechanism for manag- ing objects in a network management system and the latter illustrates a mechanism according to a preferred embodiment of the invention. Figure 3 shows a prior art mechanism for storing managed objects in various network management systems NMS1 to NMS4 and in various network elements NE. An example of a network element is a telephone ex- change. For clarity, figure 3 shows only one managed object M01. Each network management system NMS1 to NMS4 and the network element NE stores a different version of the managed object M01, as illustrated by the different shapes of the quadrangle. Figure 4 shows a mechanism according to a preferred embodiment of the invention. Now each managed object is implemented as one single composite object. Again, figure 4 shows only one managed composite object M01'. By means of distributed object technology, the object M01' is accessible to all subsystems NMS1 to NMS4 and network elements NE which need access to any aspect of the managed object. In order to maintain high avail- ability, the composite object M01' can be replicated component-wise or as a whole to one or more additional subsystems. During the lifetime of the composite object, more composite objects can be added and old composite objects can be deleted and/or replaced by enhanced versions of the same composite object. Composite objects may (but do not have to) reflect the different aspects of the MO needed by different management systems. Although the invention has been described in connection with network management systems, it is not limited to these examples, but it can be used in virtually all digital data processing systems, such as process automation and the like.

Claims: Claims 1. A method for modelling a plurality of resources in a network management system, said resources comprising resource instances (RI) and resource types (RT) such that each resource type (RT) is a generalization of one or more resource instances (RI), the method comprising the steps of: forming a software object model, the model comprising object instances (OI) and object classes (OC), wherein each object class (OC) comprises fragments (FG) of data and/or program code and is a generalization of one or more object instances (OI), each instance inheriting the capabilities of the corresponding class; characterized by: modelling each resource type (RT) by a software object class (OC), and assigning to said object class a class version identifier (CVI) which directly or indirectly indicates: (a) at least some capabilities of the resource (RI, RT); and (b) a collection of the fragments (FG) included in the object class (OC) of the version in question; and modelling each resource instance (RI) by an object instance (OI) of the corresponding class, and assigning to said object instance (OI) an object instance identifier (ON) and an instance version identifier (IVI) which directly or indirectly indicate the version of the class (OC) which is used for modelling the resource type (RT) in question. 2. A method according to claim 1, characterized by model- ling at least some objects as composite objects (M01') which implement the capabilities of all versions of the resource type (RT) in question. 3. A method according to claim 1 or2, characterized in that each object class version implements all the features of the objects with the same object identifier but with an older version identifier. 4. A method according to any one of the preceding claims, characterized by the steps of: sending a version inquiry (2-2) from a software application (APPL) to an object instance (OI) to obtain (2-4) an instance version identifier (IVI); sending an instantiate command (2-6) from the software application (APPL) to an object class (OC), the command including the instance version identifier obtained in the previous step; instantiating (2-8) the object class (OC) to obtain an object instance of a version indicated by the instance version identifier (IVI). 5. A method according to any one of the preceding claims, characterized in that the network is a telecommunication network. 6. A computer-readable program product comprising a computer program, characterized in that executing the program in a computer causes the computer to carry out the steps of a method according to claim 1. 7. A computer-readable program product according to claim 6, characterized in that the program is a network management program of a telecommunication network. 8. A software object model for modelling a plurality of resources in a network management system, said resources comprising resource instances (RI) and resource types (RT) such that each resource type (RT) is a generalization of one or more resource instances (RI), the software object model comprising object instances (OI) and object classes (OC), wherein each object class (OC) comprises fragments (FG) of data and/or program code and is a generalization of one or more object instances (OI), each instance inheriting the capabilities of the corresponding class; characterized in that the software object model: models each resource type (RT) by a software object class (OC), and assigns to said object class a class version identifier (CVI) which directly or indirectly indicates: (a) at least some capabilities of the resource (RI, RT); and (b) a collection of the fragments (FG) included in the object class (OC) of the version in question; and models each resource instance (RI) by an object instance (OI) of the corresponding class, and assigns to said object instance (OI) an object instance identifier (Oil) and an instance version identifier (IVI) which directly or indirectly indicate the version of the class (OC) which is used for modelling the resource type (RT) in question.

Inventors: AUTERINEN OTSO, GEUDER UWE, KASKI JYRKI, NURMI ESA, ZOHREN STEFAN, AUTERINEN, OTSO, GEUDER, UWE, KASKI, JYRKI, NURMI, ESA, ZOHREN, STEFAN
Applicants: AUTERINEN OTSO, GEUDER UWE, KASKI JYRKI, NOKIA NETWORKS OY, NURMI ESA, ZOHREN STEFAN, AUTERINEN, OTSO, GEUDER, UWE, KASKI, JYRKI, NURMI, ESA, ZOHREN, STEFAN
Application year: 2001
Main classification: H04L12
IPC codes: H04L12