AU718930B2 - Procedure for supporting the generation of an object in a computer system - Google Patents

Description

P

P/00/011 28/5/91 Regulation 3.2

AUSTRALIA

Patents Act 1990

S

S.

S.

I.

S

S. S

S

S

ORIGINAL

COMPLETE SPECIFICATION STANDARD PATENT Invention Title: PROCEDURE FOR SUPPORTING THE GENERATION OF AN OBJECT IN A COMPUTER SYSTEM" The following statement is a full description of this invention, including the best method of performing it known to us:- This invention relates to a procedure for the support of the production of a first object within an object environment, in which the first and other objects interact by means of CORBA-mechanisms in accordance with the generic term of Claim 1, procedures for the production and the deletion of a first object in accordance with the generic term of Claim 6 or 7, a programme-module with a CORBA-interface for interaction as a CORBA-object by means of CORBA-mechanisms in accordance with the generic term of Claim 8 and a computer unit in accordance with the generic term of Claim 11.

To an increasing extent, object-oriented modelling is used as the architectural principle for the design of software to be used with divided computer systems. The eCORBA-software (CORBA common object request broker architecture) has such an :architecture and is an important component of the OSA-Architecture (OSA objectservice architecture) specified by the Object Management Group (OMG).

The invention is based upon the procedure by which objects (managed objects) are normally produced and deleted in a computer system in accordance with i the CORBA- Architecture. This is described by way of example in "Common Object Request Broker: Architecture and Specification r2.o", Object Management Group, Framingham, Massachusetts, 1995.

The production and deletion of objects is carried out by means of special objects, namely the generating-objects (factories). The sole function of such a generating-object is to carry out the deletion and generation of objects for specific kinds of objects. A special service, the lifecycle service is used to define such generating-objects. A general generating-object is available. Proceeding from this, special generating-objects for every kind of object e.g. special classes of objects (object class) can be defined which permit the input of special production parameters.

In order to be able now to produce or extinguish only one special object, first of all the appropriate generating-object for the production and deletion of this special object must be found. To achieve this, a search message is sent to a special service, the factory finder service which is a part of the lifecycle service and the search criteria (type, location, for this search entered. If the appropriate generating object is found, a requirement message (invocation) is generated and the generating object sent, which thereupon produces or extinguishes an object corresponding to the parameters contained in the invocation.

The disadvantage of this procedure is that, normally, finding a suitable generating object is a time-consuming activity and results in a further increase in communication loading for the computer.

An object of the invention is to reduce the loading of the system in a computer system provided with CORBA-architecture.

According to a first aspect of the invention, there is provided a procedure for the support of the production of a first object in an object environment in which the first and other objects interact through CORBA-mechanisms, such that by means of the procedure a second object, which is a CORBA-generating object comprising at least o :one function for the production of the first object, is made available wherein the first object which is assigned as a second object to a directly preceding parent-object in i'* *accordance with a containment tree and that at least one function for the production of the first object corresponding to a CORBA-generating object is integrated into this **oo parent-object.

According to a second aspect of the invention, there is provided a programme-module with a CORBA-interface for interaction as a CORBA-object by means of CORBA-mechanisms and with a set of primary functions for the establishment of application-services, wherein the programme-module contains one or more secondary functions which have such a form that they make available a service as a CORBA-generating-object, which carries out from the programme-module the production of child-objects which from a logical point of view with respect to a containment tree are directly-succeeding child-objects.

In this respect the invention is based upon the concept that objects in a CORBA-environment are responsible for the production or deletion of the objects immediately following them (descendant objects) in the containment tree. In addition, they consequently take over the role of generating objects for their child objects.

As a consequence of this procedure which differs from the CORBA-philosophy, the following advantages are obtained: The number of objects in the computer system is reduced as a result, there is also a reduction in the system loading and the number of references.

Furthermore, there is no longer any requirement for the factory finder service and the computer load represented by the search procedure. They are easy to find because of their arrangement in the containment tree.

In addition, the system-consistency is improved. A succeeding object is produced only if its predecessor exists in the containment tree.

Further advantages result from hybrid systems in the general area of network management, in which a network-management system based upon CORBA exists.

For one thing, the CMISE Services can be used for the production- and extinguishing functions, which are inherited from a simple interface in which all CMISE Services are held.

In order that the invention may be readily carried into effect, embodiments oooo thereof will now be described in relation to the accompanying drawings, in which: Figure 1 a shows a block circuit diagram of a computer system for a first explanatory example.

Figure 1 b is a functional representation of the structure of the software of the *computer system as in Fig 1.

Figure 2 is a symbolic illustration of dependency relationships between objects.

Figure 3 is an extract from an interface description in a representation in a symbolic description phase.

Figure 4a is a functional representation of the software structure of a computer system for a second explanatory example.

Figure 4b is a functional representation of the software structure of a computer system for a third explanatory example.

In a first explanatory example, the execution of the procedure in a computer system in accordance with the invention is described, which consists of one or more computer units in accordance with the invention and in each of which a programmemodule in accordance with the invention is running.

Figure 1 shows a CS Computer System with three computer units, C1 to C3 which communicate with one another.

Typically, the computer units C1 to C3 consist of computers, printers or network elements of a communication network. Each has a hardware-platform consisting of processors, memory facilities and peripheral components, a software platform which includes, for example, an operating system and a databank system, and applications which are made up of application-programme-modules running from the software platform. The computer units C1 to C3 are connected together by one or more communication networks, for example, by X.25, Ethernet or Token- Ring communication systems. The software-platform of the computer units C1 to C3 hereby provide the necessary data transmission services.

~The application-programme-modules are modelled as objects (managed o objects), i.e. the code and the data of an object are represented by a sum of attributes and functions to which other objects can have access. The application functions of the computer system CS result from the reciprocal access between a multiplicity of such objects.

In accordance with the CORBA-architecture, the computer units C1 to C3 o **exhibit several objects CO and SO and several object-request-brokers ORB.

From a service point of view, each of the objects CO and SO can be regarded as an encapsulated unit, which offers one or more services, which could be required by a client. In this way, the objects CO request a service (client object) which is provided by the SO objects (server objects).

To request a service, the CO forwards a request to an SO. Such a requests contains the following information: one operation, one target-object, no or several parameters and, optionally, a request-context. After the service has been provided, the SO forwards an outcome message back to the CO which is specified for this request message.

In order that request and outcome messages can be sent and received, an interface unit IU is available to the SO and CO objects.

The object-request-brokers (ORB) make an infrastructure available which permits the objects to communicate in a divided environment. In this context, the location of the SO which is requested to provide the service is not important for the object CO, i.e. it is of no consequence in which of the other computer units it is to be found nor does it matter in which special platform or in which implementation procedure the object has been realised.

In this context, each object knows at least one object-request-broker (ORB) and also how it has to make contact with this local object-request-broker Each object-request-broker knows how to make contact with other object-request-brokers and how it has to communicate with them. In this situation, he uses the RPCprocedure (RPC remote procedure call mechanisms).With this, an object sends a request message and one of the object-request-brokers ORB ensures that the message is passed on to the target-objective by means of the CORBA-infrastructure built up by the object-request-brokers.

Figure 1 b represents an illustration of the communication mechanism for the *tB° communication between a CO and an SO. Figure l b shows a communication layer ORB core, a superimposed communication layer containing 5 function units DII, IDLSubs, ORBI, SKEL and BOA together with two objects CO and SO having access to these function units.

In order to be able to communicate over the CORBA-infrastructure and to be able to co-operate with other objects in this infra-structure, each of the objects CO and SO must have access to a CORBA-specific interface. In this context, such an interface contains a description of a set of possible operations which another object can require of this object. The object interfaces are defined here in the description language IDL (interface definition language) which consists purely of an interface description language. The inheritance of this interface permits that one object supports several interfaces.

In CORBA, access is made to an object directly through this CORBA-specific interface. The implementation of this interface is the object itself. It consists of the code and data and requires no agent entity as is the case if an object is represented purely by data structure.

In order to send a request message, the object CO needs to have access to the reference (object reference) of the object SO and needs to know about the type of the object SO and the operation which it is to carry out. The object CO initiates the request message by calling up sub routines of the function unit IDLStube or by producing the request message dynamically by means of the function unit DII (dynamic invocation interface). The second procedure makes it possible to request a service which was still unknown at the time the object CO was developed.

The receipt of the request message at object SO is supported by means of the function unit DOA (basic object adaptor). It is also possible for the object to offer an interface by means of the functions of the function unit SKEL, which corresponds to the above-mentioned second opportunity.

There is a logical relationship between the objects of the computer system CS, the structure of which, by way of an example, is demonstrated in Figure 2.

SFigure 2 shows seven objects OA to OAABB which have a relationship between them. The relationship of the objects to one another is known as the containment tree or containment hierarchy. Each object represents an example (object instance) of a special object-class. The object-classes have a special hierarchy, thus for example, a more specialised object-class is contained within more-generalised class and a more generalised object class contains several more specialised object- .*.classes. The same applies to the concrete objects (managed objects, object instances).

The object OA forms the root of the containment tree. The objects OAA and OAB are more specialised objects which are contained in the higher object OA. The objects OAAA and OAAB are objects which are contained within the object OAA and the objects OAABA and OAABB are objects which are contained in object OAAB The higher object is also described as the parent-object of the contained objects, which can yet again be described as their child-objects.

In CORBA, the generation and deletion of objects by means of special generating objects (factories) can be carried out in exactly the same way as the request for and provision of services. Each of these generating-objects contain a set of operations which are suitable for the production and deletion of any special kinds of objects at any one time.

This set of operations is now transposed from the special generating-objects to other objects, the main task of which is really the provision of quite different services.

The transposition of these operations proceeds in accordance with the following scheme: the set of operations is transposed into each parent-object which is responsible for the production and deletion of the assigned child-objects in accordance with the containment tree. By generation of a child-object to a parentobject this set of operations is inherited and can be further specialised in the generation process, so that more specialised production functions, for example, with more parameters, become possible. Objects (managed objects) thus form generating objects (factories) for their direct successors in the dependency tree. To administer these production and deletion activities for objects, the object stores a list of the types of objects which can possibly succeed it directly.

In this way, in addition to the operations which were originally present, the interface of this object also contains the production- and deletion functions for the directly-succeeding objects in the containment tree.

If an object is to be generated or deleted in this way, a corresponding request message is sent to the appropriate parent-object. The semantics of this request message is that of a generating-object. Because of the logical relationship, it is easy to localise the parent-object so that it is simple to find the responsible generatingobject.

The possibility also exist that this form of producing and extinguishing objects need not be applied to all the objects of the computer system CS but rather only to the objects assigned to a branch of the containment tree. It would even be possible to separate the deletion- from the production function. Consequently, the deletion operations could also be integrated into the interface of the of the object to be deleted.

If it is still necessary first to specify generating-objects for special classes of objects, it is also possible to reach back to existing functions already present.

If CMISE-operations are available in the computer system, then CMISEoperations can be used for the production- and deletion functions and can be further inherited in a CMISE-interface The relevant part of such a further inheritable interface is specifically represented in Figure 3 in a description language.

In this connection, the operations in Figure 3 have the following significance: Supportsubordinate is in this connection a specification of the generic factory: supports operation. It has an object-identifier as input instead of a more general key.

Create_subordinate is a specialisation of generic factory:: create object.

Once again the object-identifier is used instead of a more general key. An extra parameter, "name" is present, which uses the attribute of the produced object to give it a name. However, the parameter "name" can also be contained within the last parameter "criteria". This is the same as in generic factory create object one. We have a list of <name, value> pairs, which can contain any one of the production parameters (initial values, resource constraints, location,..... The reference object, if one is present, is stored in a criterion. Exceptions are reported back by generic factory create_object. Except for a back report, autonaming, which indicates that the name parameter has been ignored, the objects are automatically named.

Delete_subordinate is a specialisation of lifecycle object remove. This requirement is directed to the parent-object so that this can administer the resources which become free after the deletion of the object. This operation can itself release a reverse operation in the reversed object itself so that it can check whether or not it is capable of being reversed and thereby of extinguishing its own resources. Delete subordinate can extinguish the 'not-removable variation', exactly as by means of lifecycle object remove. It possesses an additional invalid name variation which expresses the fact that the name made available does not identify any existing childobject.

The second explanatory example provides a situation from the network management area.

In a second explanatory example, a description is given of the performance of the invention-based procedure in an invention-based computer unit which consists of one or more invention-based computer units, in each of which an invention-based programme-module is running. Contrary to the first explanatory example, this situation in respect of the computer system relates to a network management system in which non CORBA objects are so modified by adaptation procedures that from the outside, they behave on the CORBA infrastructure as if they were CORBA objects. The computer system is equipped like the computer system CS in Figure la. The computer units represent network management units, for example, network elements, network management centre or a mediation device It is also possible for the computer system to undertake still further tasks such as administration or provision of network services. These services could also be based upon the TINA-software architecture (TINA DPE Service Specification, TINA-C, 1994).

Figure 4a is an illustration of the communication mechanism for the communication between two such network-management-objects through the CORBAinfrastructure.

Figure 4a displays a communication layer CORB/ORB, several CMISE *.'services which are generally available by means of this communication layer, two network-management-components M and A and at any one time two communication functions GMO/C+ and CMISE/IDL situated between the latter objects and the communication layer CORB/ORB.

Similarly, an object-model (management framework for open systems interconnection, ITU-T Recommendation X.700, 1992) has been standardised by the OSI (open system interconnection) for the area of network management. In addition to the object-model (SMI structure of management information), basic objects, a set of management services (CMIP common management information protocol) have also been specified for communication between the objects. Objects are specified in the description language GEMO, which uses the ASN Syntax and contains additional macros of its own.

In the case of the Components M and A, these are not CORBA-objects but rather one or more OSI-objects OM or OA and a manager or agent function unit. By means of the manager or agent function unit, operations are carried out on the objects or request messages are sent to other objects.

Agent and manager function unit communicate through the CMIP-protocol.

From the point of view of the network management the component M takes on the role of a manager and component A that of an agent.

11 The communication unit GDMO/C+ consists of one or more special accessobjects, which make possible the execution of CMISE operation upon the object OA or the object OM.

The CMISE management services are realised by a CMISE-object on the side of the object OA. The interface unit CMISE/IDL contains this CMISE-object and the services assigned to this object. The CMISE-object of the interface- CMISE/IDL is specified through an IDL-interface object and, externally, operates and appears like a CORBA-object. In order to render this specification possible and, thereby, to provide a CORBA-interface to the object OA, a type conversion from ASN.1 into IDL types is required. In this way, CMISE-services are available as a set of CORBA objects. By means of the CORBA- request fed through the CORBA-infrastructure, CMISEoperations can therefore be carried out on the object OA. The same applies to the object MO.

The part represented in Figure 3 in the interface is now further inherited to permit the production or deletion of objects.

A second possibility of binding OSI-objects through a CORBA-infrastructure is displayed in Figure 4b, which represents a third explanatory example.

Figure 3b displays a communication layer CORB/ORB, several CMISE services which are generally available by means of this communication layer, the objects OM and OA and at any one time the communication functions GDMO/IDL and CMISE/IDL situated between the latter objects and the communication layer

CORB/ORB.

By means of the interface unit GDMO/IDL, the specified OSI-objects of the components A and M in GDMO are translated into a specification as an IDL interface.

Access to such a specified object can be made by means of classic CORBA-messages.

In this way, each of the OSI-objects are transformed into a pure CORBA-object. Since the specifications in IDL and ASN.1 are of a different nature, (interface description object specification) a complete translation is not possible and only a subset of CMISE-services are offered through the interface unit GDMO/IDL. This means that only a subset of CMISE-operations can be carried out on the transformed CORBAobjects.

12 To facilitate the deletion and production of objects by means of CMISE services, an additional interface unit CMISE/IDL is provided. The production function (m-create) present in CMISE is rendered accessible by means of a CORBA interface and an application of this function to the transformed CORBA-objects thus made possible.

To produce an object in component A, an object of the component M or a special CORBA-object of the computer system CS must be addressed for the administration of the generating object responsible for production and deletion of the object. This generating object is the parent-object of the object to be produced, which is equally an object of component A. In order to be able to gain access to the production function, access is made here through the CMISE/IDL interface unit to the CMISE-production function, which makes the parent-object accessible through this interface. The production of this child-object is thereby carried out by means of a CORBA-message making use of the CEMISE semantic and with the support of CMISEservices by means of a transformed CORBA object. In a reciprocal manner, access is made to the corresponding CMISE service to extinguish objects.

Claims (12)

1. A procedure for the support of the production of a first object in an object environment in which the first and other objects interact through CORBA-mechanisms, such that by means of the procedure a second object, which is a CORBA-generating object comprising at least one function for the production of the first object, is made available wherein the first object which is assigned as a second object to a directly preceding parent-object in accordance with a containment tree and that at least one function for the production of the first object corresponding to a CORBA-generating object is integrated into this parent-object.

2. A procedure as claimed in Claim 1 wherein the assignment is registered in a central service.

3. A procedure as claimed in Claim 1, wherein at least one CORBA-generating- S*. object corresponding to a function for the deletion of the first object is integrated into the parent-object.

4. A procedure as claimed in Claim 1, wherein CMISE-functions are integrated Sinto the parent-object as production functions.

A procedure as claimed in Claim 1, wherein the production functions of the parent-object are passed on to a CORBA-child-object.

6. A procedure for the production of a first object within an object environment in which the first and other objects interact through CORBA-mechanisms such that in the course of the procedure a production-message is sent to a CORBA-generating object, wherein the production-message to the first object is sent to a directly-preceding parent-object as claimed in a containment tree and that the parent-object functioning as a CORBA-generating-object, carries out the production of the first object.

7. A procedure for the deletion of a first object within an object-environment, in which the first and further objects interact by means of CORBA-mechanisms, such that as a result of the procedure, a deletion-message is forwarded to a CORBA-generating object, wherein the deletion-message to the first object is sent to a directly-preceding parent-object as claimed in a containment tree and that the parent-object functioning as a CORBA-generating-object carries out the deletion of the first object. 14

8. A programme-module with a CORBA-interface for interaction as a CORBA- object by means of CORBA-mechanisms and with a set of primary functions for the establishment of application-services, wherein the programme-module contains one or more secondary functions which have such a form that they make available a service as a CORBA-generating-object, which carries out from the programme-module the production of child-objects which from a logical point of view with respect to a containment tree are directly-succeeding child-objects.

9. A programme-module as claimed in Claim 8, wherein the first functions are application services for the network management.

10. A programme-module as claimed in Claim 8, wherein the semantic of the second function is a CORBA-generating-object.

11. A computer unit which operates on a programme-module as claimed in Claim 8.

12. A computer unit as claimed in Claim 11, wherein the computer unit is a network management component. S13. A procedure substantially as herein described with reference to Figures 1 4 of the accompanying drawings. A programme-module substantially as herein described with reference to oFigures 1 4 of the accompanying drawings. DATED THIS FIFTEENTH DAY OF AUGUST 1997 ALCATEL ALSTHM MPANI NA 'E Ri