CA2211911A1 - Process for managing the naming of objects, process for displaying a logical address of an object on a physical corba address of an object, program module, computer unit and computer system - Google Patents
Process for managing the naming of objects, process for displaying a logical address of an object on a physical corba address of an object, program module, computer unit and computer systemInfo
- Publication number
- CA2211911A1 CA2211911A1 CA002211911A CA2211911A CA2211911A1 CA 2211911 A1 CA2211911 A1 CA 2211911A1 CA 002211911 A CA002211911 A CA 002211911A CA 2211911 A CA2211911 A CA 2211911A CA 2211911 A1 CA2211911 A1 CA 2211911A1
- Authority
- CA
- Canada
- Prior art keywords
- naming
- objects
- corba
- component
- components
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/465—Distributed object oriented systems
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99941—Database schema or data structure
- Y10S707/99944—Object-oriented database structure
Abstract
S U M M A R Y
Process for managing the naming of objects, process for displaying a logical address of an object on a physical CORBA address of an object, program module, computer unit and computer system.
In an object environment, in which a number of objects inter-act, one or several objects in the number of objects are allocated to a component. The naming management is distributed over the components. Each component manages the naming of the component or components which immediately follows it.
(Fig. 2)
Process for managing the naming of objects, process for displaying a logical address of an object on a physical CORBA address of an object, program module, computer unit and computer system.
In an object environment, in which a number of objects inter-act, one or several objects in the number of objects are allocated to a component. The naming management is distributed over the components. Each component manages the naming of the component or components which immediately follows it.
(Fig. 2)
Description
Process for managing the n~ ; ng of objects, process for displaying a logical address of an object on a physical CORBA address of an object, program module, com~uter unit and computer system.
The invention is for a procedure to manage the naming of ob-jects in an object environment, in which a number of objects interact over CORBA mechanisms according to the generic term in claim 1; a procedure for displaying a logical address of an ob-ject on a physical CORBA address of an object according to the generic term in claim 10; a program module with a CORBA inter-face for interaction as a CORBA object over CORBA mechanisms according to the generic term in claim 11; a computer unit ac-cording to the generic term in claim 12 and a computer system according to the generic term in claim 13.
To implement the software of distributed computer systems, ob-ject oriented design is increasingly used as the architectural principle. One such computer system software architecture is the CORBA architecture (CORBA = Common Object Request Broker Architecture), which is an important component of the OSA ar-chitecture (OSA = Object Service Architecture) specified by the Object Management Group (OMG).
The invention is based on the way that the naming management of objects (managed objects) is normally executed in a computer system according to the CORBA architecture. This is described, for example, in "Common Object Request Broker: Architecture and Specification r2.0", Object Management Group, Framingham, Mas-sachusetts, 1995.
A central CORBA service (naming service) is responsible for the naming management which produces this service in a central node ~naming server). Here, the naming management includes, in par-.
particular, the display of a logical address of an object on a physical CORBA address (object reference). This display func-tion is of vital significance for a CORBA system, as objects which act on a CORBA infrastructure can only be found by means of this physical address.
Problems arise when objects which are not specified as CORBA
objects have to interact on the CORBA infrastructure over CORBA
mechanisms. Dependent upon how such objects are implemented in the CORBA architecture, independent naming areas result, which cannot be accessed in a uniform way. The central naming manage-ment cannot manage these areas and access to objects in this naming area is almost impossible using CORBA mechanisms.
The invention is based on the task of developing a more flexi-ble naming management.
This task is solved by procedures under claims 1 and 10, by a program module under claim 11, by a computer unit under claim 12 and by a computer system under claim 13.
The invention is based on the idea that the naming management is no longer executed centrally but is distributed over compo-nents. Each component consists of one or more objects and is responsible for the naming management of the components which immediately follow it. These distributed elements in the naming management work together here by means of a recursive algorithm and work together to display a logical address of an object on its physical CORBA address (object reference) according to this recursive algorithm. Due to the distributed nature of the nam-ing management, it is possible to simply combine special naming managements for independent naming areas in the CORBA naming management.
. 3 An additional advantage is that the transparency of the imple-mentation remains guaranteed. In addition, different naming ar-eas are integrated in a single naming scheme. A different nam-ing management is made possible in a distributed environment.
Additional advantages result if in all part naming managements there is one uniform CORBA interface access to the naming man-agement for all components. Thus a uniform interface (API = ap-plication interface) for the naming management is available to all applications no matter in which naming area the objects are located.
In the following, the invention will be described using an im-plementation example with the help of the attached drawings:
Fig. la shows a block diagram of a computer system as in the lnventlon .
Fig. lb shows a functional representation of the software structure of the computer system as in Fig. 1.
Fig. 2 shows a symbolic representation of dependency relation-ships between objects and the numbering areas resulting from this.
Fig. 3a shows a functional representation of the first possible way of connecting objects not specified in CORBA.
Fig. 3b shows a functional representation of the second possi-ble way of connecting objects not specified in CORBA.
Fig 4a shows a functional representation of the third possible way of connecting objects not specified in CORBA.
Fig. 4b shows a functional representation of a fourth possible way of connecting objects not specified in CORBA.
In the design example, the implementation of the invention pro-cedure in the invention computer system is described, where the computer system consists of one or more invention computer units on which one or more invention program modules are run-ning.
Fig. 1 shows a computer system CS with three computer units C1 to C3 which communicate with one another.
The computer units C1 to C3 can be a computer, a printer or network elements, for example, in a communication network. They each possess a hardware platform consisting of processors, mem-ory devices and peripheral components, a software platform which includes, for example, an operating system and a database system and applications which are formed from application pro-gram modules which are running on the softwaré platform. The computer units C1 to C3 are conected with one another using one or more communication networks, for example using X.25, #7, Ethernet or token ring communication systems. The software platform of the computer units C1 to C3 initialise the neces-sary data transmission services here.
The application program modules are modelled as objects (managed objects), i.e. the code and the data of an object are represented by a sum of attibutes and functions which other ob-jects can access. The alternate accessing of a number of such objects then produces the application functions of the CS com-puter system.
According to the CORBA architecture, the computer units C1 to C3 possess several CO and SO objects and several ORB object re-quest brokers.
-From the point of view of service, the CO and SO objects can be seen as one encapsulated unit which makes available one or more services which can be requested by a client. The CO objects re-quest services (client objects) which are produced by SO ob-jects (server objects).
To request a service, a CO transmits a request to a SO. Such a request contains the following information: an operation, a target object, any or no parameters and, as an option, a re-quest context. After producing this service, the SO transmits an outcome back to the CO which is defined for this request.
To transmit and receive the requests and outcomes, the SO and CO objects have an interface IU available.
Object request brokers (ORB) make available an infrastructure which allows objects to communicate in a distributed environ-ment. It is therefore unimportant for the CO objects on which of the other computer units Cl to C3 a SO object is based and from which they want to request a service, and on which specialplatform or in which implementation process the object is real--ised.
To do this, each object knows at least one object request bro-ker and knows how to contact this local object request broker.
Each object request broker knows how to contact other object request brokers and how to communicate with them. To do this, it uses remote procedure call mechanisms. An object thus trans-mits a request and an ORB; the transmission of the request to the target object is dealt with by the CORBA infrastructure formed by the ORB.
Fig. lb shows a representation of the communication mechanisms for communications between a CO and a SO. Fig. lb shows a com-communications layer ORB core, an overlying communications layer with five function units DII, IDLSubs, ORBI, SKEL and BOA
and two objects, CO and SO, accessing these function units.
In order to be able to interact over the CORBA infrastructure by means of the CORBA mechanisms and to be able to work with other objects on this infrastructure, each of the CO and SO ob-jects must have a CORBA specific interface. Such an interface contains a description of a block of possible operations which can request another object from this object. The interfaces of objects are defined in Interface Definition Language which is a pure interface description language. The inheritance of this interface allows one object to support several interfaces.
In CORBA, an object is directly accessed over this CORBA spe-cific interface. The implementation of this interface is the object itself. It consists of code and data and thus does not require an agent entity as is the case if an object is repre-sented purely by a data structure.
In order to be able to transmit a request, the CO object re-quires access to the object reference of the SO object, re-quires knowledge of the type of the SO object and the operation which is to be executed by it. The CO object initiates the re-quest by calling up subroutines of the IDLSubs or by dynami-cally creating the request by means of the function unit DII
(Dynamic Invocation Interface). The second procedure allows a service to be requested which was not known at the time of the development of the CO object.
In the SO object, the receipt of the request is supported by functions in the DOA function unit (Basic Object Adapter). It is also p.ossible for the object to offer an interface which corresponds to the two possibilities ahove, through the func-tions of the SKEL function unit.
It is also possible for the computer system to contain objects in addition to the CO and SO objects which are not specified in CORBA and which interact with each other and with the CO and SO
objects over special interface units in the CORBA infrastruc-ture described above. For a further explanation of the design example it is assumed that the CS computer system has such ob-jects being differently implemented in the CORBA infrastruc-ture.
The use of such hybrid components in a CORBA infrastructure has the advantage here that objects which already exist here and which are already specified according to another object model architecture can be reused and such objects can work together with CORBA objects. This has great advantages, in particular in the area of network management, as there are already many ob-jects in this area which are specified according to OSI object models. OSI network management components, such as managers, agents and mediation devices, for example, are each formed from one or more such OST objects.
For the area of network management, an object model is stan-dardised by the OSI (Open System Interconnection) (Management framework for open systems interconnection, ITU-T recommenda-tion X.700, 1992). In addition to the object model (SMI =
Structure of Management Information), fundamental objects are also specified, as well as a set of management services (CMIS
common management information service definition) and a network management protocol (CMIP = Common Management Information Pro-tocol) for the objects to communicate with one another. Objects are specified in the description language GEMO which uses ASN
syntax and contains its own additional macros.
The principal difference between "natural" CORBA objects and "natural" OSI objects is that the CORBA objects represent the implementation of the CORBA interface whereas the OSI objects of a network management element are filed as data structure in the MIB data set (Management Information Base) and are manipu-lated through an agent with which communications are made by means of the CEMIP protocol.
In addition, naming and addressing in CORBA and OSI are differ-ent. In CORBA, an object has two addresses: a logical address,10 for example a name in a certain context, and a physical address (object reference) which states the physical location of the object, for example the address of the server on which the ob-ject is running. This address is decisive for locating and in-teracting with a CORBA object. In OSI, an object has only one logical address (full distinguish name) which results from its position in the objects' dependency tree. This address consists of the names of all objects from the root of the dependency tree to the object.
Fig. 2 shows a representation of the logical dependency between components in the computer system CS when non-CORBA specified objects are also implemented in the CORBA infrastructure on the CS computer system.
Fig. 2 shows two areas AREAl and AREA2, a service NS and sev-eral components MOl to MO5, IAl, IA2 and GA, between which a logical dependency relationship is defined.
In the area AREAl, the interaction of objects occurs by means of CORBA mechanisms based on a CORBA infrastructure. In the area AREA2, the interaction of objects occurs by means of the CEMIP protocol.
Each of the components MOl to MO5, IAl, IA2 and GA contains one or more objects and is responsible for the naming management of the components which immediately follow it. The root of the de-pendency tree so defined forms the NS service. This is respon-sible for the naming management of components MOl, IAl and MO2.
This means that the name of the components MOl, IAl and MO2 is contained in its naming context. The component MOl is responsi-ble for the naming management of components MO2 and MO4. The component MO2 is responsible for the naming management of com-ponents MO5 and GA. The component MO5 is responsible for the naming management of component IA2.
The components MOl to MO5 are "natural" CORBA objects as de-scribed in Fig. la and Fig. lb. A CORBA object is thus allo-cated to this component. The dependency relationship between these components follows the dependency relationship between the objects. A CORBA server can also include several CORB ob-jects.
With both the IAl and IA2 components, there are one or more ob-jects which are specified in CORBA and which by means of a spe-cial interface unit are encapsulated so that they can act over CORBA mechanisms over the CORBA infrastructure. Each of these components thus forms an independent naming area which is in-ternally managed.
Examples of the production of such components can be seen in Fig. 3a and Fig. 3b.
Fig. 3a and Fig 3b show a representation of the communication mechanisms for communications between two components IAl and IA2 over the CORBA infrastructure. The components IAl and IA2 are indicated in the description of Fig. 3a and Fig. 3b using M
and A.
Fig. 4a shows a communication layer CORB/ORB, several CMISE
services generally available over this communication layer, two network management components M and A and two communication functions GMO/C++ and CMISE/IDL between these objects and the communication layer CORB/ORB.
In the components M and A we are not dealing with CORBA objects but one or more OSI objects OM or OA and a manager or agent function unit. By means of the agent or manager function units, operations are executed on these objects or requests are sent to other objects. Agent and manager function units communicate over the CMIP protocol. From the point of view of the network management, the component M takes on the rôle of manager and the component A that of agent.
The communication unit GDMO/C++ consists of one or more special access objects which facilitate the execution of CMISE opera-tions on object OA or OM.
The CMISE management services are realised by a CMISE object on the part of the OA object. The interface unit CMISE/IDL con-tains this CMISE object and the services allocated to this ob-ject. The CMISE object of the interface unit CMISE/IDL is specified by an IDL interface and acts and gives the external impression of a CORBA object. In order to facilitate this specification and thus the initialisation of a CORBA interface to the object OA, a type conversion of ASN.l into IDL types is required. CMISE services thus make a set of CORBA objects available. Through CORBA requests routed over the CORBA infra-structure, CMISE operations can thus be executed on the objectOA. The same applies for the object MO.
A second possible way of connecting OSI objects over a CORBA
infrastructure is shown in Fig. 3b.
Fig. 3b shows a communication layer CORB/ORB, several CMISE
services generally available over this communication layer, the objects OM and OA and two communication functions GDMO/IDL and CMISE/IDL between these objects and the communication layer CORB/ORB.
Through the interface unit GDMO/IDL, the OSI objects of compo-nents A and M specified in GDMO are translated into a specifi-cation as an IDL interface. An object specified in such a way can be accessed through classic CORBA messages. Each of these 1 OSI objects is thus transformed into a pure CORBA object. As the specifications in IDL and ASN.1 have different natures (interface description < - > object specification), a complete translation is not possible and only a subset of CMISE opera-tions can be executed on the transformed CORBA objects.
The objects in components IA1 and IA2 have a dependency rela-tionship which is represented by the data structure in the MIB
data set. Each of the components IA1 and IA2 have a name which is registered as a naming context in the preceding components and is managed by them. This naming context thus represents the root of the internal dependency tree for components IA1 and IA2. One could also say that this context represents the root of the naming area of components IA1 or IA2. The agent of com-ponents IA1 and IA2 independently manages the naming of the component dependent on the root of the internal dependency tree; the naming management of MIB is regulated independently like this. In addition, due to the recursive nature, this nam-ing management also forms a part unit of the CORBA naming man-agement and also interacts with the other parts of the CORBAnaming management.
In the GA component we are dealing with several network manage-ment elements (CMIP agents) which interact over the CMIP proto-col and which are connected with the CORBA infrastructure by means of a gateway GATE. These network elements together form form an independent naming area which is connected over the GATE gateway.
In Fig. 4a and 4b, possible ways of interacting such network management components over the GATE gateway are shown. The ex-act method of function can be seen in the representations in figures 4a and 4b together with the description of the corre-sponding units which has already been made in the description of figures 3a and 3b.
The interface to the GA component forms the GATE gateway. The naming of the GA component is managed by the component MO2.
There are as many naming contexts for the GA component con-tained in this as there are roots of internal dependency trees in the AREA2 area. Normally, each CA network element contains a MIB data set with a dependency tree which has one root. Thus in the naming management of component M02 two naming contexts are stored and managed for the component GA, for example, which each represent the root of an OSI dependency tree. One could also say that this naming context represents the root within the independent naming area of the component GA.
Further naming management within the area AREA2 is executed by means of the naming management designed within the OSI archi-tecture.
In addition, this naming management also forms a part unit of the CORBA naming management due to its recursive nature and thus also interacts with the other parts of the CORBA naming management.
The parts of this CORBA naming management each offer an access interface which corresponds to the access interface of the CORBA naming service. Thus a uniform access to all parts of the naming management is possible. If the translation of a logical address into a physical CORBA address is now requested by such a part of the naming management, then this part of the naming management will interact according to a recursive algorithm with the other parts of the naming management. This recursive algorithm involves going from one part of the naming management to the next part of the naming management, according to the logical address in the components' dependency tree, until the part of the naming management is reached in which the logical address of the object sought is stored. This can be the allo-cated part of the naming management which is responsible for the naming of the component which is allocated to this object if we are dealing with a CORBA object in the component. It can also be a case of the internal naming management of the compo-nent to which the object is allocated if, for example, we are dealing with a component of the component type IAl, IA2 or GA.
The invention is for a procedure to manage the naming of ob-jects in an object environment, in which a number of objects interact over CORBA mechanisms according to the generic term in claim 1; a procedure for displaying a logical address of an ob-ject on a physical CORBA address of an object according to the generic term in claim 10; a program module with a CORBA inter-face for interaction as a CORBA object over CORBA mechanisms according to the generic term in claim 11; a computer unit ac-cording to the generic term in claim 12 and a computer system according to the generic term in claim 13.
To implement the software of distributed computer systems, ob-ject oriented design is increasingly used as the architectural principle. One such computer system software architecture is the CORBA architecture (CORBA = Common Object Request Broker Architecture), which is an important component of the OSA ar-chitecture (OSA = Object Service Architecture) specified by the Object Management Group (OMG).
The invention is based on the way that the naming management of objects (managed objects) is normally executed in a computer system according to the CORBA architecture. This is described, for example, in "Common Object Request Broker: Architecture and Specification r2.0", Object Management Group, Framingham, Mas-sachusetts, 1995.
A central CORBA service (naming service) is responsible for the naming management which produces this service in a central node ~naming server). Here, the naming management includes, in par-.
particular, the display of a logical address of an object on a physical CORBA address (object reference). This display func-tion is of vital significance for a CORBA system, as objects which act on a CORBA infrastructure can only be found by means of this physical address.
Problems arise when objects which are not specified as CORBA
objects have to interact on the CORBA infrastructure over CORBA
mechanisms. Dependent upon how such objects are implemented in the CORBA architecture, independent naming areas result, which cannot be accessed in a uniform way. The central naming manage-ment cannot manage these areas and access to objects in this naming area is almost impossible using CORBA mechanisms.
The invention is based on the task of developing a more flexi-ble naming management.
This task is solved by procedures under claims 1 and 10, by a program module under claim 11, by a computer unit under claim 12 and by a computer system under claim 13.
The invention is based on the idea that the naming management is no longer executed centrally but is distributed over compo-nents. Each component consists of one or more objects and is responsible for the naming management of the components which immediately follow it. These distributed elements in the naming management work together here by means of a recursive algorithm and work together to display a logical address of an object on its physical CORBA address (object reference) according to this recursive algorithm. Due to the distributed nature of the nam-ing management, it is possible to simply combine special naming managements for independent naming areas in the CORBA naming management.
. 3 An additional advantage is that the transparency of the imple-mentation remains guaranteed. In addition, different naming ar-eas are integrated in a single naming scheme. A different nam-ing management is made possible in a distributed environment.
Additional advantages result if in all part naming managements there is one uniform CORBA interface access to the naming man-agement for all components. Thus a uniform interface (API = ap-plication interface) for the naming management is available to all applications no matter in which naming area the objects are located.
In the following, the invention will be described using an im-plementation example with the help of the attached drawings:
Fig. la shows a block diagram of a computer system as in the lnventlon .
Fig. lb shows a functional representation of the software structure of the computer system as in Fig. 1.
Fig. 2 shows a symbolic representation of dependency relation-ships between objects and the numbering areas resulting from this.
Fig. 3a shows a functional representation of the first possible way of connecting objects not specified in CORBA.
Fig. 3b shows a functional representation of the second possi-ble way of connecting objects not specified in CORBA.
Fig 4a shows a functional representation of the third possible way of connecting objects not specified in CORBA.
Fig. 4b shows a functional representation of a fourth possible way of connecting objects not specified in CORBA.
In the design example, the implementation of the invention pro-cedure in the invention computer system is described, where the computer system consists of one or more invention computer units on which one or more invention program modules are run-ning.
Fig. 1 shows a computer system CS with three computer units C1 to C3 which communicate with one another.
The computer units C1 to C3 can be a computer, a printer or network elements, for example, in a communication network. They each possess a hardware platform consisting of processors, mem-ory devices and peripheral components, a software platform which includes, for example, an operating system and a database system and applications which are formed from application pro-gram modules which are running on the softwaré platform. The computer units C1 to C3 are conected with one another using one or more communication networks, for example using X.25, #7, Ethernet or token ring communication systems. The software platform of the computer units C1 to C3 initialise the neces-sary data transmission services here.
The application program modules are modelled as objects (managed objects), i.e. the code and the data of an object are represented by a sum of attibutes and functions which other ob-jects can access. The alternate accessing of a number of such objects then produces the application functions of the CS com-puter system.
According to the CORBA architecture, the computer units C1 to C3 possess several CO and SO objects and several ORB object re-quest brokers.
-From the point of view of service, the CO and SO objects can be seen as one encapsulated unit which makes available one or more services which can be requested by a client. The CO objects re-quest services (client objects) which are produced by SO ob-jects (server objects).
To request a service, a CO transmits a request to a SO. Such a request contains the following information: an operation, a target object, any or no parameters and, as an option, a re-quest context. After producing this service, the SO transmits an outcome back to the CO which is defined for this request.
To transmit and receive the requests and outcomes, the SO and CO objects have an interface IU available.
Object request brokers (ORB) make available an infrastructure which allows objects to communicate in a distributed environ-ment. It is therefore unimportant for the CO objects on which of the other computer units Cl to C3 a SO object is based and from which they want to request a service, and on which specialplatform or in which implementation process the object is real--ised.
To do this, each object knows at least one object request bro-ker and knows how to contact this local object request broker.
Each object request broker knows how to contact other object request brokers and how to communicate with them. To do this, it uses remote procedure call mechanisms. An object thus trans-mits a request and an ORB; the transmission of the request to the target object is dealt with by the CORBA infrastructure formed by the ORB.
Fig. lb shows a representation of the communication mechanisms for communications between a CO and a SO. Fig. lb shows a com-communications layer ORB core, an overlying communications layer with five function units DII, IDLSubs, ORBI, SKEL and BOA
and two objects, CO and SO, accessing these function units.
In order to be able to interact over the CORBA infrastructure by means of the CORBA mechanisms and to be able to work with other objects on this infrastructure, each of the CO and SO ob-jects must have a CORBA specific interface. Such an interface contains a description of a block of possible operations which can request another object from this object. The interfaces of objects are defined in Interface Definition Language which is a pure interface description language. The inheritance of this interface allows one object to support several interfaces.
In CORBA, an object is directly accessed over this CORBA spe-cific interface. The implementation of this interface is the object itself. It consists of code and data and thus does not require an agent entity as is the case if an object is repre-sented purely by a data structure.
In order to be able to transmit a request, the CO object re-quires access to the object reference of the SO object, re-quires knowledge of the type of the SO object and the operation which is to be executed by it. The CO object initiates the re-quest by calling up subroutines of the IDLSubs or by dynami-cally creating the request by means of the function unit DII
(Dynamic Invocation Interface). The second procedure allows a service to be requested which was not known at the time of the development of the CO object.
In the SO object, the receipt of the request is supported by functions in the DOA function unit (Basic Object Adapter). It is also p.ossible for the object to offer an interface which corresponds to the two possibilities ahove, through the func-tions of the SKEL function unit.
It is also possible for the computer system to contain objects in addition to the CO and SO objects which are not specified in CORBA and which interact with each other and with the CO and SO
objects over special interface units in the CORBA infrastruc-ture described above. For a further explanation of the design example it is assumed that the CS computer system has such ob-jects being differently implemented in the CORBA infrastruc-ture.
The use of such hybrid components in a CORBA infrastructure has the advantage here that objects which already exist here and which are already specified according to another object model architecture can be reused and such objects can work together with CORBA objects. This has great advantages, in particular in the area of network management, as there are already many ob-jects in this area which are specified according to OSI object models. OSI network management components, such as managers, agents and mediation devices, for example, are each formed from one or more such OST objects.
For the area of network management, an object model is stan-dardised by the OSI (Open System Interconnection) (Management framework for open systems interconnection, ITU-T recommenda-tion X.700, 1992). In addition to the object model (SMI =
Structure of Management Information), fundamental objects are also specified, as well as a set of management services (CMIS
common management information service definition) and a network management protocol (CMIP = Common Management Information Pro-tocol) for the objects to communicate with one another. Objects are specified in the description language GEMO which uses ASN
syntax and contains its own additional macros.
The principal difference between "natural" CORBA objects and "natural" OSI objects is that the CORBA objects represent the implementation of the CORBA interface whereas the OSI objects of a network management element are filed as data structure in the MIB data set (Management Information Base) and are manipu-lated through an agent with which communications are made by means of the CEMIP protocol.
In addition, naming and addressing in CORBA and OSI are differ-ent. In CORBA, an object has two addresses: a logical address,10 for example a name in a certain context, and a physical address (object reference) which states the physical location of the object, for example the address of the server on which the ob-ject is running. This address is decisive for locating and in-teracting with a CORBA object. In OSI, an object has only one logical address (full distinguish name) which results from its position in the objects' dependency tree. This address consists of the names of all objects from the root of the dependency tree to the object.
Fig. 2 shows a representation of the logical dependency between components in the computer system CS when non-CORBA specified objects are also implemented in the CORBA infrastructure on the CS computer system.
Fig. 2 shows two areas AREAl and AREA2, a service NS and sev-eral components MOl to MO5, IAl, IA2 and GA, between which a logical dependency relationship is defined.
In the area AREAl, the interaction of objects occurs by means of CORBA mechanisms based on a CORBA infrastructure. In the area AREA2, the interaction of objects occurs by means of the CEMIP protocol.
Each of the components MOl to MO5, IAl, IA2 and GA contains one or more objects and is responsible for the naming management of the components which immediately follow it. The root of the de-pendency tree so defined forms the NS service. This is respon-sible for the naming management of components MOl, IAl and MO2.
This means that the name of the components MOl, IAl and MO2 is contained in its naming context. The component MOl is responsi-ble for the naming management of components MO2 and MO4. The component MO2 is responsible for the naming management of com-ponents MO5 and GA. The component MO5 is responsible for the naming management of component IA2.
The components MOl to MO5 are "natural" CORBA objects as de-scribed in Fig. la and Fig. lb. A CORBA object is thus allo-cated to this component. The dependency relationship between these components follows the dependency relationship between the objects. A CORBA server can also include several CORB ob-jects.
With both the IAl and IA2 components, there are one or more ob-jects which are specified in CORBA and which by means of a spe-cial interface unit are encapsulated so that they can act over CORBA mechanisms over the CORBA infrastructure. Each of these components thus forms an independent naming area which is in-ternally managed.
Examples of the production of such components can be seen in Fig. 3a and Fig. 3b.
Fig. 3a and Fig 3b show a representation of the communication mechanisms for communications between two components IAl and IA2 over the CORBA infrastructure. The components IAl and IA2 are indicated in the description of Fig. 3a and Fig. 3b using M
and A.
Fig. 4a shows a communication layer CORB/ORB, several CMISE
services generally available over this communication layer, two network management components M and A and two communication functions GMO/C++ and CMISE/IDL between these objects and the communication layer CORB/ORB.
In the components M and A we are not dealing with CORBA objects but one or more OSI objects OM or OA and a manager or agent function unit. By means of the agent or manager function units, operations are executed on these objects or requests are sent to other objects. Agent and manager function units communicate over the CMIP protocol. From the point of view of the network management, the component M takes on the rôle of manager and the component A that of agent.
The communication unit GDMO/C++ consists of one or more special access objects which facilitate the execution of CMISE opera-tions on object OA or OM.
The CMISE management services are realised by a CMISE object on the part of the OA object. The interface unit CMISE/IDL con-tains this CMISE object and the services allocated to this ob-ject. The CMISE object of the interface unit CMISE/IDL is specified by an IDL interface and acts and gives the external impression of a CORBA object. In order to facilitate this specification and thus the initialisation of a CORBA interface to the object OA, a type conversion of ASN.l into IDL types is required. CMISE services thus make a set of CORBA objects available. Through CORBA requests routed over the CORBA infra-structure, CMISE operations can thus be executed on the objectOA. The same applies for the object MO.
A second possible way of connecting OSI objects over a CORBA
infrastructure is shown in Fig. 3b.
Fig. 3b shows a communication layer CORB/ORB, several CMISE
services generally available over this communication layer, the objects OM and OA and two communication functions GDMO/IDL and CMISE/IDL between these objects and the communication layer CORB/ORB.
Through the interface unit GDMO/IDL, the OSI objects of compo-nents A and M specified in GDMO are translated into a specifi-cation as an IDL interface. An object specified in such a way can be accessed through classic CORBA messages. Each of these 1 OSI objects is thus transformed into a pure CORBA object. As the specifications in IDL and ASN.1 have different natures (interface description < - > object specification), a complete translation is not possible and only a subset of CMISE opera-tions can be executed on the transformed CORBA objects.
The objects in components IA1 and IA2 have a dependency rela-tionship which is represented by the data structure in the MIB
data set. Each of the components IA1 and IA2 have a name which is registered as a naming context in the preceding components and is managed by them. This naming context thus represents the root of the internal dependency tree for components IA1 and IA2. One could also say that this context represents the root of the naming area of components IA1 or IA2. The agent of com-ponents IA1 and IA2 independently manages the naming of the component dependent on the root of the internal dependency tree; the naming management of MIB is regulated independently like this. In addition, due to the recursive nature, this nam-ing management also forms a part unit of the CORBA naming man-agement and also interacts with the other parts of the CORBAnaming management.
In the GA component we are dealing with several network manage-ment elements (CMIP agents) which interact over the CMIP proto-col and which are connected with the CORBA infrastructure by means of a gateway GATE. These network elements together form form an independent naming area which is connected over the GATE gateway.
In Fig. 4a and 4b, possible ways of interacting such network management components over the GATE gateway are shown. The ex-act method of function can be seen in the representations in figures 4a and 4b together with the description of the corre-sponding units which has already been made in the description of figures 3a and 3b.
The interface to the GA component forms the GATE gateway. The naming of the GA component is managed by the component MO2.
There are as many naming contexts for the GA component con-tained in this as there are roots of internal dependency trees in the AREA2 area. Normally, each CA network element contains a MIB data set with a dependency tree which has one root. Thus in the naming management of component M02 two naming contexts are stored and managed for the component GA, for example, which each represent the root of an OSI dependency tree. One could also say that this naming context represents the root within the independent naming area of the component GA.
Further naming management within the area AREA2 is executed by means of the naming management designed within the OSI archi-tecture.
In addition, this naming management also forms a part unit of the CORBA naming management due to its recursive nature and thus also interacts with the other parts of the CORBA naming management.
The parts of this CORBA naming management each offer an access interface which corresponds to the access interface of the CORBA naming service. Thus a uniform access to all parts of the naming management is possible. If the translation of a logical address into a physical CORBA address is now requested by such a part of the naming management, then this part of the naming management will interact according to a recursive algorithm with the other parts of the naming management. This recursive algorithm involves going from one part of the naming management to the next part of the naming management, according to the logical address in the components' dependency tree, until the part of the naming management is reached in which the logical address of the object sought is stored. This can be the allo-cated part of the naming management which is responsible for the naming of the component which is allocated to this object if we are dealing with a CORBA object in the component. It can also be a case of the internal naming management of the compo-nent to which the object is allocated if, for example, we are dealing with a component of the component type IAl, IA2 or GA.
Claims (14)
1. Process to manage the naming of objects in an object environment in which a number of objects interact using CORBA
mechanisms, characterised by one or more objects of that number being allocated to a component; by the naming management being distributed over the components and by each component managing the naming of the component or components immediately following it,
mechanisms, characterised by one or more objects of that number being allocated to a component; by the naming management being distributed over the components and by each component managing the naming of the component or components immediately following it,
2. Procedure as in claim 1, characterised by each component of the subsequent components giving access to the naming management over a CORBA interface which is uniform for all components,
3. Procedure as in claim 1, characterised by the parts of the naming management acting in combination in the components by means of a recursive algorithm,
4. Procedure as in claim 1, characterised by a central CORBA
service forming the root of the dependency tree formed by the components,
service forming the root of the dependency tree formed by the components,
5. Procedure as in claim 1, characterised by a first type of component being formed by a CORBA object,
6. Procedure as in claim 1, characterised by a second type of component being formed by a number of objects not specified in CORBA which form an independent naming area for which they themselves are responsible,
7. Procedure as in claim 6, characterised by the logical root of the independent naming area centrally executing the naming management for these components,
8. Procedure as in claim 6, characterised by a first subtype of the second type of component being formed by an OSI
network management element upon which a CORBA interface is set.
network management element upon which a CORBA interface is set.
9. Procedure as in claim 6, characterised by a second subtype of the second type of component being formed by one or several OSI network management elements which are accessed through a gateway.
10. Procedure for displaying a logical address of an object on a physical CORBA address of an object in an object environment, in which a number of objects interact over CORBA
mechanisms, in which procedure the display is produced by a naming management, characterised by the display being produced by two or more partial naming managements working together which for any component manages the naming of a component or components which immediately follow that component, in which such components include one or more objects in the number of objects.
mechanisms, in which procedure the display is produced by a naming management, characterised by the display being produced by two or more partial naming managements working together which for any component manages the naming of a component or components which immediately follow that component, in which such components include one or more objects in the number of objects.
11. Program module with a CORBA interface for interaction as a CORBA object over CORBA mechanisms and with a block of initial functions for initialising ready application services, characterised by the program module containing one or more second functions which are arranged in such a way that they execute the naming management of the child objects which immediately follow it in the dependency tree.
12. Computer unit upon which a program module as in claim 11 runs.
13. Computer system with a number of objects which interact over CORBA mechanisms and with a naming management for this number of objects, characterised by one or more objects in the number of objects being allocated to a component, by the naming management being distributed over the components and by each component being arranged so that it manages the naming of the component or components which immediately follow it.
14. Computer system as in claim 13, characterised by the computer system being a network management system.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP96440062A EP0825524B1 (en) | 1996-08-20 | 1996-08-20 | Method for naming of objects |
| EP96440062.6 | 1996-08-20 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2211911A1 true CA2211911A1 (en) | 1998-02-20 |
Family
ID=8225416
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002211911A Abandoned CA2211911A1 (en) | 1996-08-20 | 1997-08-19 | Process for managing the naming of objects, process for displaying a logical address of an object on a physical corba address of an object, program module, computer unit and computer system |
Country Status (7)
| Country | Link |
|---|---|
| US (1) | US5983233A (en) |
| EP (1) | EP0825524B1 (en) |
| JP (1) | JP3519920B2 (en) |
| AU (1) | AU730208B2 (en) |
| CA (1) | CA2211911A1 (en) |
| DE (1) | DE59604238D1 (en) |
| ES (1) | ES2142564T3 (en) |
Families Citing this family (57)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| SE506535C2 (en) * | 1995-06-16 | 1998-01-12 | Ericsson Telefon Ab L M | Method and apparatus for deriving instance information in an information management system |
| ES2142037T3 (en) * | 1996-08-20 | 2000-04-01 | Cit Alcatel | PROCEDURE FOR AID TO THE INTERACTION OF DIRECTIONS BETWEEN A FIRST AND A SECOND UNITS. |
| JP3230467B2 (en) * | 1997-09-25 | 2001-11-19 | 日本電気株式会社 | GDMO translator, GDMO translation method, and recording medium recording GDMO translator program |
| GB2332288A (en) * | 1997-12-10 | 1999-06-16 | Northern Telecom Ltd | agent enabling technology |
| US6266695B1 (en) * | 1997-12-23 | 2001-07-24 | Alcatel Usa Sourcing, L.P. | Telecommunications switch management system |
| US6029168A (en) * | 1998-01-23 | 2000-02-22 | Tricord Systems, Inc. | Decentralized file mapping in a striped network file system in a distributed computing environment |
| US6202069B1 (en) * | 1998-04-30 | 2001-03-13 | International Business Machines Corporation | Execution paradigm for accessing hierarchical data using an object framework |
| US6317748B1 (en) | 1998-05-08 | 2001-11-13 | Microsoft Corporation | Management information to object mapping and correlator |
| US6671882B1 (en) * | 1998-07-25 | 2003-12-30 | General Instrument Corporation | System for distributing and handling electronic program guide information using CORBA-wrapped objects |
| JP3481867B2 (en) * | 1998-08-17 | 2003-12-22 | 日本電信電話株式会社 | Network management system for multiple management protocols |
| AU753490B2 (en) * | 1998-09-03 | 2002-10-17 | Ibm International Group B.V. | A data processing system and development method |
| US6286047B1 (en) * | 1998-09-10 | 2001-09-04 | Hewlett-Packard Company | Method and system for automatic discovery of network services |
| US7478142B1 (en) * | 1998-09-29 | 2009-01-13 | Netscape Communications Corporation | Self-contained applications that are applied to be received by and processed within a browser environment and that have a first package that includes a manifest file and an archive of files including a markup language file and second package |
| US6581088B1 (en) | 1998-11-05 | 2003-06-17 | Beas Systems, Inc. | Smart stub or enterprise javaTM bean in a distributed processing system |
| US6236999B1 (en) * | 1998-11-05 | 2001-05-22 | Bea Systems, Inc. | Duplicated naming service in a distributed processing system |
| US6571274B1 (en) | 1998-11-05 | 2003-05-27 | Beas Systems, Inc. | Clustered enterprise Java™ in a secure distributed processing system |
| US6385643B1 (en) * | 1998-11-05 | 2002-05-07 | Bea Systems, Inc. | Clustered enterprise Java™ having a message passing kernel in a distributed processing system |
| US7526468B2 (en) * | 1999-01-08 | 2009-04-28 | Computer Associates Think, Inc. | System and method for recursive path analysis of DBMS procedures |
| US6453320B1 (en) * | 1999-02-01 | 2002-09-17 | Iona Technologies, Inc. | Method and system for providing object references in a distributed object environment supporting object migration |
| GB2346983B (en) * | 1999-02-18 | 2003-04-16 | Ibm | Client/server computing for transaction processing with superior coordinator o ptimization |
| US6735771B1 (en) * | 1999-03-12 | 2004-05-11 | Perot Systems Corporation | System and method for delivering web services using common object request broker architecture |
| FI107206B (en) * | 1999-03-16 | 2001-06-15 | Nokia Networks Oy | Method and device for determining interface and communication system |
| US6718377B1 (en) * | 1999-08-13 | 2004-04-06 | Lucent Technologies Inc. | Telecommunications network management system interface |
| US6678743B1 (en) | 1999-11-30 | 2004-01-13 | Recursion Software, Inc. | Method for moving objects in a distributed computing environment |
| US6629128B1 (en) * | 1999-11-30 | 2003-09-30 | Recursion Software, Inc. | System and method for distributed processing in a computer network |
| US6947965B2 (en) | 1999-11-30 | 2005-09-20 | Recursion Software, Inc. | System and method for communications in a distributed computing environment |
| KR100649288B1 (en) * | 1999-12-03 | 2006-11-24 | 주식회사 케이티 | Method and apparatus for alarm reporting in CORBA-CMIP gateway with one-to-one mapping of management function |
| KR100317129B1 (en) * | 1999-12-27 | 2001-12-24 | 오길록 | Method for translation web server and database server in internet envirionment |
| KR100357850B1 (en) * | 2000-03-29 | 2002-10-25 | 삼성전자 주식회사 | Distributed objects oriented communication system and method for common service various protocolby used corba proxy module therefor |
| US7478403B1 (en) | 2000-04-21 | 2009-01-13 | Sun Microsystems, Inc. | Secure access to managed network objects using a configurable platform-independent gateway providing individual object-level access control |
| US7206843B1 (en) | 2000-04-21 | 2007-04-17 | Sun Microsystems, Inc. | Thread-safe portable management interface |
| US6915324B1 (en) | 2000-04-21 | 2005-07-05 | Sun Microsystems, Inc. | Generic and dynamic mapping of abstract syntax notation (ASN1) to and from interface definition language for network management |
| US6839748B1 (en) | 2000-04-21 | 2005-01-04 | Sun Microsystems, Inc. | Synchronous task scheduler for corba gateway |
| US7010586B1 (en) | 2000-04-21 | 2006-03-07 | Sun Microsystems, Inc. | System and method for event subscriptions for CORBA gateway |
| US6813770B1 (en) * | 2000-04-21 | 2004-11-02 | Sun Microsystems, Inc. | Abstract syntax notation to interface definition language converter framework for network management |
| US7228346B1 (en) | 2000-04-21 | 2007-06-05 | Sun Microsystems, Inc. | IDL event and request formatting for corba gateway |
| US7783720B1 (en) * | 2000-04-21 | 2010-08-24 | Oracle America, Inc. | CORBA metadata gateway to telecommunications management network |
| US6950935B1 (en) | 2000-04-21 | 2005-09-27 | Sun Microsystems, Inc. | Pluggable authentication modules for telecommunications management network |
| US7610588B1 (en) * | 2000-10-27 | 2009-10-27 | Global 360, Inc. | Distributed application management software |
| US6883164B2 (en) | 2000-12-15 | 2005-04-19 | International Business Machines Corporation | Strategy for dynamically modeling ASN.1 data to an object model |
| EP1133102B1 (en) * | 2000-12-20 | 2003-07-30 | Agilent Technologies, Inc. (a Delaware corporation) | An interface to a network management system of a communication network |
| US6901446B2 (en) * | 2001-02-28 | 2005-05-31 | Microsoft Corp. | System and method for describing and automatically managing resources |
| GB2376096B (en) | 2001-05-30 | 2005-06-29 | Ibm | Identification of the source of a client/server flow |
| JP4536292B2 (en) | 2001-06-14 | 2010-09-01 | インターナショナル・ビジネス・マシーンズ・コーポレーション | Network system, server, client, inter-object communication method, profile object registration method, program, and storage medium |
| KR100408592B1 (en) * | 2001-06-26 | 2003-12-06 | 엘지전자 주식회사 | Interface Apparatus And Method Of Naming Service Using IOR In Distributed Processing System |
| KR100382357B1 (en) * | 2001-07-28 | 2003-05-09 | 엘지전자 주식회사 | Method for Dynamic Management for Server Object Managing Nodes |
| KR100456720B1 (en) * | 2001-08-31 | 2004-11-10 | 엘지전자 주식회사 | Control Apparatus And Method For Configuration Management In EMS System |
| US20030065761A1 (en) * | 2001-09-28 | 2003-04-03 | Nevton Cereja | System and method of creating and maintaining a replicated naming service to support a telecommunications network |
| US6757899B2 (en) | 2001-10-11 | 2004-06-29 | Harris Corporation | Dynamic CORBA gateway for CORBA and non-CORBA clients and services |
| EP1320218A1 (en) * | 2002-07-30 | 2003-06-18 | Agilent Technologies Inc | A method of creating a number of objects being stored in a database of a network management system |
| US7448066B2 (en) * | 2002-09-19 | 2008-11-04 | International Business Machines Corporation | Application server object-level security for distributed computing domains |
| US7331049B1 (en) | 2003-04-21 | 2008-02-12 | Borland Software Corporation | System and methodology providing typed event and notification services |
| CN101202739A (en) * | 2006-12-11 | 2008-06-18 | 中兴通讯股份有限公司 | Device for processing ASN.1 message OO |
| WO2009063555A1 (en) * | 2007-11-13 | 2009-05-22 | Fujitsu Limited | Control proxy device, control proxy method and control proxy program |
| US20090228959A1 (en) * | 2008-03-04 | 2009-09-10 | Access Business Group International Llc | System and markup language for information extraction from stand-alone devices in webspace |
| US8234586B2 (en) * | 2008-03-26 | 2012-07-31 | Microsoft Corporation | User interface framework and techniques |
| WO2010062617A1 (en) * | 2008-10-27 | 2010-06-03 | Social Gaming Network | Apparatuses, methods and systems for an interactive proximity display tether |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5517645A (en) * | 1993-11-05 | 1996-05-14 | Microsoft Corporation | Method and system for interfacing components via aggregate components formed by aggregating the components each with an instance of a component manager |
| US5724503A (en) * | 1995-03-31 | 1998-03-03 | Sun Microsystems, Inc. | Method and apparatus for interpreting exceptions in a distributed object system |
| US5835914A (en) * | 1997-02-18 | 1998-11-10 | Wall Data Incorporated | Method for preserving and reusing software objects associated with web pages |
-
1996
- 1996-08-20 ES ES96440062T patent/ES2142564T3/en not_active Expired - Lifetime
- 1996-08-20 DE DE59604238T patent/DE59604238D1/en not_active Expired - Lifetime
- 1996-08-20 EP EP96440062A patent/EP0825524B1/en not_active Expired - Lifetime
-
1997
- 1997-08-15 US US08/912,297 patent/US5983233A/en not_active Expired - Lifetime
- 1997-08-18 AU AU34260/97A patent/AU730208B2/en not_active Ceased
- 1997-08-19 CA CA002211911A patent/CA2211911A1/en not_active Abandoned
- 1997-08-20 JP JP26077597A patent/JP3519920B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| DE59604238D1 (en) | 2000-02-24 |
| EP0825524A1 (en) | 1998-02-25 |
| AU3426097A (en) | 1998-02-26 |
| JPH10187637A (en) | 1998-07-21 |
| AU730208B2 (en) | 2001-03-01 |
| US5983233A (en) | 1999-11-09 |
| EP0825524B1 (en) | 2000-01-19 |
| ES2142564T3 (en) | 2000-04-16 |
| JP3519920B2 (en) | 2004-04-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2211911A1 (en) | Process for managing the naming of objects, process for displaying a logical address of an object on a physical corba address of an object, program module, computer unit and computer system | |
| Bruneton et al. | Recursive and dynamic software composition with sharing | |
| US7676552B2 (en) | Automatic provisioning of services based on a high level description and an infrastructure description | |
| US8276166B2 (en) | System and method for providing interoperability between different programming protocols | |
| AU730273B2 (en) | Method for supporting address interaction between a first entity and a second entity in a computer system | |
| US7539743B2 (en) | Method and system of administration in a JMX environment comprising an administration application and software systems to be administered | |
| Leppinen et al. | Java-and CORBA-based network management | |
| Lee | Enabling network management using Java technologies | |
| Quinot et al. | From functional to architectural analysis of a middleware supporting interoperability across heterogeneous distribution models | |
| Wang et al. | Optimizing the CORBA component model for high-performance and real-time applications | |
| AU718933B2 (en) | A method of supporting interaction between a first and second entity in a computer system | |
| Dittrich et al. | Integration of a TMN-based Management Platform into a CORBA-based Environment | |
| Sylor et al. | Applying network management standards to system management; the case for the common agent | |
| AU718930B2 (en) | Procedure for supporting the generation of an object in a computer system | |
| Pavlou | The OSIMIS TMN Platform: Support for Multiple Technology Integrated Management Systems | |
| Bénech et al. | Supervision of the CORBA environment with SUMO: a WBEM/CIM-based management framework | |
| Keller et al. | Dynamic management of Internet telephony servers: a case study based on JavaBeans and JDMK | |
| Daniel et al. | Integration of quality of service in distributed object systems | |
| Almeida et al. | The role of the RM-ODP Computational Viewpoint Concepts in the MDA approach | |
| Krause et al. | Implementing configuration management policies for distributed applications | |
| Mokdad et al. | The computational object approach for network and systems management | |
| Genilloud et al. | Managing ANSA objects with OSI Network Management tools | |
| Benns et al. | What's in the Middle? | |
| Serre et al. | Implementing OSI-based interfaces for network management | |
| Silis et al. | World wide web server technology and interfaces for distributed, high-performance computing systems |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| FZDE | Discontinued |