AU718933B2

AU718933B2 - A method of supporting interaction between a first and second entity in a computer system

Info

Publication number: AU718933B2
Application number: AU34261/97A
Authority: AU
Inventors: Laurant Carre; Linda Helene Hauw
Original assignee: Alcatel CIT SA; Alcatel SA
Current assignee: Alcatel Lucent SAS
Priority date: 1996-08-20
Filing date: 1997-08-18
Publication date: 2000-05-04
Anticipated expiration: 2017-08-18
Also published as: JPH10171658A; EP0825526B1; ES2141457T3; DE59604241D1; EP0825526A1; AU3426197A

Description

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

AUSTRALIA

Patents Act 1990

S

ORIGINAL

COMPLETE SPECIFICATION STANDARD PATENT Invention Title:

S

A METHOD OF SUPPORTING INTERACTION BETWEEN A FIRST AND SECOND ENTITY 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 method for supporting interaction between a first entity specified according to a first specification language and a second entity specified according to a second specification language each of the two units being provided with classes which control the processing of types.

To implement distributed computer systems in software, object-oriented modelling is increasingly being used as an architectural principle.

Such a software architecture of a computer system is the CORBA architecture (CORBA Common Object Request Broker Architecture), which is an important component of the OSA architecture (OSA Object Service Architecture), specified by S•10 the Object Management Group (OMG). Objects conforming to this specification, henceforth called "CORBA objects", are specified by means of the specification language CORBA IDL (IDL Interface Definition Language). All types of such an object are also specified in this language, in CORBA IDL.

For the area of network management, an object model has been standardized in an OSI (Open Systems Interconnection) standard (Management framework for open systems interconnection, ITU-T Recommendation X.700, 1992). Its objects, henceforth °*•4.called "OSI objects, are specified in the specification language ASS.1 (Abstract Syntax Notation). All types of such an OSI object are also specified in this language, in ASN.1.

00 The invention is particularly related to the way the processing of types is normally implemented in a computer system. For each type one class is normally available which controls the processing of this type.

If interaction between objects specified in different specification languages is to be made possible, problems arises: In the objects, the types are specified in different ways, such as in ASN.1 in OSI objects and in CORBA IDL in CORBA objects. For interaction, therefore, mechanisms are necessary which permit type interoperability.

An object of the invention is to support the interaction between objects specified in different specification languages.

According to a first aspect of the invention, there is provided a method for supporting interaction between a first entity specified according to a first specification language and a second entity specified according to a second specification language, each of the two units being provided with classes which control the processing of types, wherein the first entity and/or the second entity are provided with one or more hybrid classes which control both the processing of a type specified according to the first specification language and the processing of a type corresponding to said type and converted to a type according to the second specification language.

According to a second aspect of the invention, there is provided a method for interaction between a first entity specified according to a first specification language and a second entity specified according to a second specification language, the first unit being provided with classes which control the processing of types, wherein the first unit is provided with one or more hybrid classes which control both the processing of a 10 type specified according to the first specification language and the processing of a type corresponding to said type and converted to a type according to the second specification language.

According to a third aspect of the invention, there is provided a computer system comprising at least one first entity specified according to a first specification language and at least one second entity specified according to a second specification language, each of the two entities being provided with classes which control the :processing of types, wherein the first entity and/or the second entity are provided with S•one or more hybrid classes which are designed to control both the processing of a type specified according to the first specification language and the processing of a type corresponding to said type and converted to a type according to the second specification language.

According to a fourth aspect of the invention, there is provided a program module specified according to a first specification language and provided with one or more classes which control the processing of types, wherein the program module is provided with one or more hybrid classes which are designed to control both the processing of a type specified according to the first specification language and the processing of a type corresponding to said type and converted to a type according to the second specification language.

The idea underlying the invention is to provide hybrid classes which control both the processing of types specified according to a first specification language and the processing of the correspondent types according to the second specification language. By means of such a hybrid class, types specified in the first specification language can be manipulated in the context of the second specification language and vice versa.

Such types may preferably be data types. Data types are categories of operation arguments to be processed which typically contain both the behaviour and the representation.

A class is an abstract data type which encapsulates one or more static or dynamic data types and operations, called "method". Moreover, a class is an implementation which can generate objects (object instances) that belong to this object class and all show a similar behaviour. Classes specify objects according to a general 10 implementation.

Another advantage of this invention is that it is fast, since type definition, and thus mapping, took place already prior to the program run. No decisions, such as the checking of types, need be carried out during the program run.

It is particularly advantageous to use the invention in the network management area if both OSI entities and CORBA entities are present there. Because of the high degree of interaction required in such an environment, the use of the invention there is '..particularly advantageous.

The invention will become more apparent from the following description of an embodiment taken in conjunction with the accompanying drawings, in which: Figure 1 is a block diagram of a computer system according to the invention; Figure 2a is a functional representation of a first possible manner of interaction between differently specified objects; Figure 2b is a functional representation of a second possible manner of interaction between differently specified objects; Figure 3a is a functional representation of a third possible manner of interaction between differently specified objects; Figure 3b is a functional representation of a fourth possible manner of interaction between differently specified objects; and Figure 4 is a logical representation of the interoperability principle.

In the embodiment described in the following, the method according to the invention is carried out in a computer system according to the invention consisting of one or more computer entities according to the invention which each execute one or more program modules according to the invention.

Figure 1 shows a computer system CS with three computer entities C1 to C3 which communicate with one another.

The computer entitles C1 to C3 are, for example, computers, printers, or network elements of a communications network. They each have a hardware platform, consisting of processors, memory devices, and peripheral components, a software platform, comprising an operating system and a database system, for example, and applications formed by application program modules running on the 10 software platform. The computer entities C1 to C3 are interconnected by one or more communications networks, such as X.25, Ethernet, or token-ring communications systems. The software platforms of the computer entities CI to C3 provide the onecessary data transmission services.

The application program modules are modelled as objects (managed objects), the code and the data of an object are represented by a sum of attributes and functions which can be accessed by other objects. Through mutual access by a plurality of such objects, the application functions of the computer system CS are provided.

According to the CORBA architecture, the computer entities C1 to C3 have 20 several client objects CO and server objects 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 entity which provides one or more services that can be requested by a client. The objects CO request services (client objects) which are provided by the objects so (server objects).

To request a service, a CO sends a request message to an So. Such a request message contains the following information: an operation, a target object, one or more parameters, and, optionally, a request context. After the service has been provided, the SO sends an outcome message defined for this request message to the

CO.

For sending and receiving the request and outcome messages, each of the objects SO and CO has an interface unit IU.

6 The object request brokers ORB provide an infrastructure which enables the objects to communicate in a distributed environment. It thus makes no difference to the objects CO in which of the other computer entities C1 to C3 an object SO whose service they want to request is resident and on which specific platform or in which form the object is implemented.

To this end, each object knows at least one object request broker ORB and how to contact this local object request broker. Each object request broker knows how to contact and communicate with other object request brokers. For this purpose, the object request broker uses the RPC mechanism (RPC Remote Procedure Call). An object thus sends a request message to one of the object request brokers ORB, from which the request message is routed to the target object by the CORBA infrastructure formed by the object request broker ORB.

I To be able to interact via the CORBA infrastructure by means of CORBA mechanisms and cooperate with other objects on this infrastructure, each of the objects CO and SO must have a CORBA-specific interface. Such an Interface contains a description of a set of possible operations which another object can request from this °;*.object. The interfaces of the objects are defined in the specification language IDL (Interface Definition Language). The inheritance of these interfaces makes it possible for an object to support two or more interfaces.

In CORBA, an object is accessed directly via this CORBA-specific interface. The implementation of this interface is the object itself. It consists of a code and data and thus requires no agent entity, which is necessary if an object is represented exclusively by a data structure.

Besides the objects CO and SO, the computer system contains further objects, which are not shown in Figure 1. These are not specified in CORBA and interact with one another and with the objects CO and SO via specific interface units and the above-described CORBA infrastructure.

The use of such hybrid components on a CORBA infrastructure has the advantage that existing objects specified according to another object-model architecture can be reused and that a cooperation between such objects and CORBA objects is made possible. This has great advantages mainly in the network management area, since a large number of objects specified according to the OSI 7 object model exist in this area. OSI network management components, such as manager, agent, and mediation device, are formed by one or more such OSI objects.

For the network management area, an object model has been standardized in an OSI (Open Systems Interconnection) standard (Management framework for open systems Interconnection, ITU-T Recommendation X.700, 1992). Besides the object model (SMI Structure of Management Information), fundamental objects. a set of management services (CMIS Common Management Information Service definition), and a network management protocol (CMIP Common Management Information Protocol) are specified for communication between the objects. Objects are specified 10 in the specification language GDMO, which uses ASN syntax and contains further macros.

The basic difference between "natural" CORBA objects and "natural,, OSI objects consists in the fact that CORBA objects represent the implementation of the CORBA interface, whereas the OSI objects of a network management element are 15 stored as a data structure in the MIB (Management Information Base) data record and are manipulated by an agent, with which communication is carried out by means of the CMIP protocol. In addition, their data types are specified in different specification languages, namely in CORBA IDL and in ASN.1, and are thus not compatible.

Figs. 2a, 2b, 3a, and 3b show possible implementations of OSI entities on a CORBA infrastructure and possible manners of interaction between CORBA entities and OSI entities Via a CORBA infrastructure. Possible interaction via a CORBA infrastructure implies such an interaction between entities in different specification languages. It requires the same procedure. An "entity" is considered here to be an item with one or more objects.

Figure 2a shows a communication layer CORBA/ORB, several CMISE services CMS generally available via this communication layer, two network management components M and A, and two communication functions GDMO/C++ and CMISEIIDL between each of these components and the communication layer CORBA/ORB. The components M and A are no CORBA objects, but the component M consists of one or more 051 objects OM and a manager unit, and the component A consists of one or more OSI objects OA and an agent unit. Each of the components M and A thus represents an 051 entity. By means of the agent and manager units, operations are performed on these objects and requests are sent to other objects, respectively. The agent unit and the manager unit communicate via the CMIP protocol. ]From a network management point of view, the component M plays the role of a manager and the component A that of an agent.

The communication entity GDMO/C+ consists of one or more specific access objects which make it possible to perform CMISE operations on the object OA or OM.

The CMISE management services are implemented 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 unit CMISE/IDL is specified by an IDL interface, and acts, and thus appears to the outside, like a CORBA object. To permit this specification and, thus, the provision of a CORBA interface for the object OA, type conversion from ASN.1 to IDL, or type interoperability, is necessary. How this type Interoperability is achieved will be shown later with the aid of Figure 4. CMISE services thus provide a set of CORBA objects.

S 15 Through the CORBA request routed via the CORBA infrastructure, CMISE operations can thus be performed on the object OA. The same applies to the object OM.

A second possible manner of interaction between CORBA entities and OSI entities via a CORBA infrastructure is illustrated in Figure 2b.

Figure 2b shows the communication layer CORBA/ORB, several CMISE services 20 CMS generally available via this communication layer, the objects OM and OA, and two communication functions GDMO/IDL and CMISE/IDL between each of these objects and the communication layer CORBA/ORB.

The interface unit GDMO/IDL translates the OSI objects OM and OA of the components from GDMO to IDL. An object so specified can be accessed by classic CORBA messages. Each of these OSI objects is thus transformed into a pure CORBA object. Since the specifications in IDL and ASN.1 are of different natures (interface description object specification), complete translation is not possible and only a subset of CMISE services is offered via the interface unit GDMO/IDL. This means that only a subset of CMISE operations can be performed on the transformed CORBA objects.

Figs. 3a and 3b show further possible manners of interaction between network management components in which a gateway GATE is incorporated. The mode of 9 operation is apparent from the representation in Figs. 3& and 3b In conjunction with the description of the corresponding entities given in connection with rigs. 2a and 2b.

Type interoperability is achieved as follows: Types in the ISO context are defined in the specification language ASN.1, and types in the CORBA context are defined in the specification language IDL. The necessary support for these types must be controlled in each context. This support is implemented in classes, both in CORBA entities and in OSI entities. The following classes are chosen.

The classes which provide support for the types in the specification language 10 IDL in CORBA entities, henceforth called "Idl G classes". It should be noted that .normally one class supports one type.

o* The classes which provide support for the types in the specification language o. ASN.1 in OSI entitles, henceforth called "AsnG classes".

A dual approach is used. This is shown in the following with the aid of a S 15 transmitter-receiver pair: To support the treatment of Idl G types in an OSI entity, the correspondent AsnG type is constructed from the Idl G type. To do this, a "constructor", a control element for generating a program object, is added to the class which supports the AsnG type. This "constructor" takes an Idl G type as a parameter. In this manner, this 20 AsnG class also supports the processing of the correspondent Idl G type.

S

To permit the use of AsnG types in a CORBA entity, the AsnG type is transformed into the correspondent Idl G type. In this manner, a new function is added to the class which supports this AsnG type. This function takes the AsnG type as a parameter and returns the correspondent Idl G type.

Figure 4 shows a logical representation of this interoperability principle.

An entity SEM represents the entire semantics. the contents of an object. A part thereof is the class CLASS, which deals with syntax descriptions. This class CLASS receives types of different syntaxes, namely types in the specification languages IDL and ASN.1. It provides support for the correspondent different types Idl G and AsnG.

The support for the Idl G types is provided as described above, namely by generating Idl G types via a "constructor" and converting AsnG types to Idl G types.

Claims

1. A method for supporting interaction between a first entity specified according to a first specification language and a second entity specified according to a second specification language, each of the two units being provided with classes which control the processing of types, wherein the first entity and/or the second entity are provided with one or more hybrid classes which control both the processing of a type specified according to the first specification language and the processing of a type corresponding to said type and converted to a type according to the second specification language.

2. A method as claimed in claim 1, wherein as the first specification language for specifying types, ASN.1 is used.

3. A method as claimed in claim 1, wherein as the second specification language for specifying types, CORBA IDL is used.

4. A method as claimed in claim 1, wherein the hybrid class or the hybrid classes perform a conversion between types according to the first specification language and types according to the second specification language.

A method for interaction between a first entity specified according to a first specification language and a second entity specified according to a second specification language, the first unit being provided with classes which control the S 20 processing of types, wherein the first unit is provided with one or more hybrid classes which control both the processing of a type specified according to the first specification language and the processing of a type corresponding to said type and converted to a type according to the second specification language.

6. A method as claimed in claim 5, wherein the first entity is formed by at least one object, and that the hybrid class or one of the hybrid classes is offered in the interface of said object.

7. A computer system comprising at least one first entity specified according to a first specification language and at least one second entity specified according to a second specification language, each of the two entities being provided with classes which control the processing of types, wherein the first entity and/or the second entity are provided with one or more hybrid classes which are designed to control both the processing of a type specified according to the first specification language and the processing of a type corresponding to said type and converted to a type according to the second specification language.

8. A method as claimed in claim 7, wherein the first entity is an OSI entity.

9. A method as claimed in claim 7, wherein the second entity is a CORBA entity.

10. A program module specified according to a first specification language and provided with one or more classes which control the processing of types, wherein the program module is provided with one or more hybrid classes which are designed to control both the processing of a type specified according to the first specification language and the processing of a type corresponding to said type and converted to a 10 type according to the second specification language.

11. A computer entity on which a program module as claimed in claim 10 is run.

12. A method substantially as herein described with reference to Figures 1 4 of the accompanying drawings.

13. A computer system substantially as herein described with reference to Figures 1 15 4 of the accompanying drawings.

14. A programme module substantially as herein described with reference to Figures 1 4 of the accompanying drawings. S S" 20 DATED THIS FIFTEENTH DAY OF AUGUST 1997 ALCATEL ALSTHOM CMPADA IE GENERALE d'ELECTRICITE