KR20030033520A - Method and system for conversion output message descriptor data into common object request broker architecture data - Google Patents

Abstract

PURPOSE: A method and a system for converting the CORBA(Common Object Request Broker Architecture) data for operating and managing an exchange system based on the CORBA are provided to easily and efficiently manage the system by converting the non-standard OMD and POD data into a formatted and analyzable data architecture, and transmitting it to the system through a CORBA IIOP(Internet-Inter ORB Protocol) protocol. CONSTITUTION: A CORBA data generator(200) generates various kinds of data files and the source codes related to the CORBA used for the input of the CORBA data converter(400) by receiving an OMD data definition file(100) such as an alarm related OMD file(110), a failure related OMD file(120), a status related OMD file(130) and a command and response related OMD file. An IDL(Interface Definition Language) compiler(300) generates and compiles a client stub and a realization skeleton for the CORBA system from the IDL of each generated files. A CORBA data converter(400) converts the OMD and POD data(500) received from the exchange system into the standard CORBA data(600) by receiving the files generated from the compiler(300) and transmits it to an external system.

Description

Method and system for conversion output message descriptor data into common object request broker architecture data}

The present invention relates to a COVA data generator, which is a software block that produces various data related to CORBA through input of OMD and POD files defined in an exchange system using OMD data or POD data. And an interface definition language compiler (IDL Compiler) for compiling various data defined by the interface definition language (IDL) produced by the COVA data generator and source code related to COVA, and data compiled from the interface definition language compiler. The present invention relates to a COVA data conversion system for operating and managing an exchange system based on a common object request broker structure composed of a COVA data converter which is produced as an input and converts OMD and POD data into COVA data.

Today's computing environment enables users to share data in different places and exchange information in a short time due to the development of information and communication technology. Was built.

However, distributed application programming should consider distribution of information, overcoming heterogeneous heterogeneity, dependency on implementation language, and security by using network than existing programming.

Therefore, in order to solve these problems, the standardization of the integration of heterogeneous applications is underway, and the CORBA, a common object request mediation structure proposed by the Object Management Group (OMG), is a standard for heterogeneous distributed computing. Currently, products developed to comply with the COVA specification are available and various COVA systems are being built.

On the other hand, in order to efficiently manage and operate the switching system, generally, as shown in FIG. 1, the system management apparatus 20 and the network management apparatus 10 are connected to the switching system 40 through various network management protocols. The operation and management of the exchange system 40 is performed.

Currently, a common management information protocol (CMIP: Common Management Information Protocol) is used as a standard management protocol for operating and managing the switching system 40 as described above, and uses OMD and POD data output methods that are non-standard data. The exchange system 40 receives the OMD and POD files, which are specification files for defining the format and basic content of each data, through the CIT 50 which is an external terminal device and interworks with the system management device 20. .

At this time, the OMD and POD operation and management data produced from the exchange system 40 is transmitted to the system management device 20 and the network management device 10 through a common management information protocol (CMIP) in the Q3 relay device 30. Is sent to.

The CIT (Craft Interface Terminal) (50) is an external terminal to perform the function of inputting the command and output the device status related to the overall maintenance by the operator 60, and interprets the command received from the operator accordingly Send a request message.

However, according to the OMD / PI data, which is a management data structure used to operate and manage the exchange system 40 as described above, data processing in the management apparatus for managing the exchange system 40 becomes complicated, In order to convert this to CMIP protocol, which is a standard management protocol, there was a difficulty in converting operation and management data received in the form of OMD and POD into CMIP protocol through an additional Q3 relay device 30 which is a Q3 adapter in the middle. .

In addition, the OMD data is composed of a form that cannot be translated only by the data itself, and the POD data is a non-normal representation composed of pure ASC II, which has considerable complexity and limitation in using and operating the system. have.

Accordingly, the present invention provides a number of disadvantages pointed out in the conventional exchange system operation and management method based on OMD / POD data produced from the exchange related equipment to manage the exchange system as described above. It is designed to solve the problem and converts non-standard OMD and POD operation and management data produced from the exchange system into a formal and analytical operation and management data structure and converts it into a standard Common Object Request Brokerage Structure (CORBA) IIOP. An object of the present invention is to make it easier and more efficient to manage the system by transmitting it to a device that operates and manages the system using a protocol.

1 is a schematic configuration diagram showing a conventional exchange system operation and management data transmission structure.

Figure 2 is a schematic structural diagram showing a structure of the exchange system operation and management data transmission in accordance with the present invention.

3 is a block diagram of a COVA data conversion system in accordance with the present invention.

((Explanation of symbols for main parts of drawing))

10. Network management device 20. System management unit

Q3 repeater 40. Exchange system

50. CIT60. Operator

100. OMD data definition file 200. Coba data generator

210. OMD format file generation unit 220. Data structure file generator

230. COVA type code source file generator

300. Interface Definition Language Compiler 400. COVA Data Converter

500. OMD / PIO data 600. Coba data

The above object of the present invention is that the OMD or POD files defined in the exchange system using the OMD data structure or the POD data structure are used as the input of the COVA data generator and this software block is the COB data. It is configured to produce various data files to be used for the input of the translator and source code related to COVA, and the output files produced are defined in COBA's interface definition language (IDL), which compiles the interface definition language compiler (IDL). It is achieved by COVA data conversion system for operating and managing exchange system based on common object request mediation structure composed of COVA converters produced by dynamically linking the result.

The CORBA (Common Object Request Broker Architecture) is a common object request broker architecture, and refers to a protocol for communication between objects in a distributed environment.

The COVA data conversion system according to the present invention converts OMD data, which is a data structure for interworking with a system management device, to the standardized COVA data proposed by OMG and transmits the data through IOP protocol (IIOP). To be able.

The IIOP protocol is a protocol for accessing an object request forwarder (ORB), which is one of CORBA's sub-protocols, and allows distributed programs written in different programming languages to communicate with each other over the Internet.

Details of the above object and technical configuration and the effects thereof according to the present invention will be more clearly understood by the following detailed description based on the accompanying drawings.

First, FIG. 2 is a schematic diagram of an exchange system operation and management data transmission structure according to a KOVA data conversion method and system for operating and managing an exchange system based on the common object request brokering structure of the present invention.

As shown, in order to efficiently manage and operate the switching system 40, the system management device 20 and the network management device 10 are connected to the switch and are used. In this case, the network management system uses various network management protocols. The exchange system 40 is managed, and the network management through the exchange system 40 is performed by the operator 60 inputting a command through the CIT 50 which is an external terminal device.

In this case, the exchange system 40 using the OMD and POD data output method receives the OMD and POD file, which is a specification file for defining the format and basic content of each data, through the CIT 50. It is linked with the management device 20.

The OMD / POD file is classified into an alarm related OMD file, a fault related OMD file, a state related OMD file and a command, a response related OMD file, and the like in the corresponding exchange system to interface with an external system. Defines all output messages for the same four kinds of OMD families.

The OMD and POD data generates various necessary data and software codes for producing a software block called a COVA data converter and converts the OMD and POD files received by the COVA data converter into a COVA data structure which is a standardized data structure. It converts the data to the system management apparatus 20 and the network management apparatus 10 through the IIOP protocol.

FIG. 3 shows the cobar data for converting the management data for operating and managing the switching system 40 to a standardized data structure in order to be transmitted to the operation and management apparatus of the corresponding system using a standard Cobar IIOP. A block diagram of the conversion system.

As shown in the drawing, the COVA data conversion system of the present invention generates a COVA data generator 200 for generating data for input of a COVA data converter with an input of an OMD data definition file 100, and generated from the data generator 200. An IDL compiler 300 for compiling data in a predefined interface definition language and a COBA data converter 400 generated by input of the compiled file to convert OMD / POD data 500 to CORBA data 600. It consists of.

The COVA data generator 200 includes OMD data such as an alarm related OMD file 110, a fault related OMD file 120, a state related OMD file 130, and a command and response OMD file 140. The definition file 100 is input to generate various data files to be used for input of the KOVA data converter 400 and source codes related to COVA.

COVA data generator 200 is composed of OMD format file generation unit 210, data structure file generation unit 220, COVA type code source file generation unit 230, as shown in the COVA data converter 400 OMD format file 211, data structure file 221 and COVA type code source file 231 is generated.

At this time, the OMD format file 211 is a format file for sequentially translating the OMD file received from the exchange system 40, the data structure file 221 is a structured form of the unstructured OMD data Coba type code source file 231 is a file for converting to a data structure, and the coba type codes generated by the COBA IDL compiler 300 from the structured data defined in the data structure file correspond to each OMD data in a one-to-one correspondence relationship. The OBA data received by the COVA data converter 400 may be corresponded to the corresponding COVA data.

On the other hand, each file generated from the COVA data generator 200 is defined by an interface definition language (IDL) for defining the function of the distributed service in a common data type in the distributed services interact with each other.

The CORBA IDL enables interface definitions that can be compiled into client stubs and server skeletons. Using client stubs, clients can use COBA interfaces regardless of implementation language or location. You can call the definition language object.

COVA IDL compiler 300 generates a COVA type code supporting an interface defined in the COVA interface definition language as described above.

That is, a file written in the interface definition language (IDL) is an object implementation called by a client stub and an object request broker (ORB), which are parts for generating a request through the COVA IDL compiler 300. It is automatically converted to the implementation skeleton, the interface to the method, and changed to code for a specific COVA system.

The stub and implementation skeleton of CORBA IDL are glue-like roles between client and server applications and object request forwarders. The stub is a client-side invocation mechanism. The skeleton is a server-side interface to the request, and the mapping procedure creates an interface definition language stub from the requested host language.

Meanwhile, the file changed through the compiler 300 is used as an input of the COVA data converter 400 so that the COVA data converter 400 receives the OMD and the POD data 500 received from the exchange system 40. It converts it into a form of standard COVA data 600 and transmits it to an external system.

Accordingly, the KOVA data conversion method and system for operating and managing the exchange system based on the common object request intermediation structure of the present invention may be applied to the operation of the exchange system using OMD data and POD data for communication with an external system. In the management, it converts non-standard OMD and POD data into standard COVA data format and transmits it using COVA IOP protocol so that the system can be easily and efficiently analyzed and processed to easily manage the system. It is effective.

Claims (3)

Coba data is stored in the OMD data definition file 100, such as the alert related OMD file 110, the fault related OMD file 120, the state related OMD file 130, and the command and response related OMD file 140. Inputting to the generator 200; Generating an OMD format file (211), a data structure file (221) and a COBA type code source file (231) from the input OMD data definition file (100); Generating and compiling a client stub and an implementation skeleton from an interface definition language through a CORBA IDL Compiler (300); The COVA data converter 400 receives the generated file, converts the OMD and POD data 500 received from the exchange system 40 into a form of standard COVA data 600 and transmits the converted file to an external system. ; COVA data conversion method for operating and managing the exchange system based on the common object request mediation structure, characterized in that consisting of. Receives an OMD data definition file 100 such as an alarm related OMD file 110, a fault related OMD file 120, a state related OMD file 130, and a command and response OMD file 140. A KOVA data generator 200 for generating various data files to be used for input of the KOVA data converter 400 and source codes related to KOVA; An interface definition language (IDL) compiler 300 for generating and compiling a client stub and an implementation skeleton for a specific COVA system from the interface definition language of each of the generated files; COVA data converter which receives the file generated by the compiler 300 and converts the OMD and POD data 500 received from the exchange system 40 into a form of standard COVA data 600 and transmits it to an external system. 400; COVA data conversion system for operating and managing the exchange system based on the common object request mediation structure, characterized in that configured to include. The OVA format file generator (210) of claim 2, further comprising: an OMD format file generator (210) for generating a format file (211) for sequentially translating OMD files received from the exchange system (40); A data structure file generator 220 for generating a data structure file 221 for converting the unstructured OMD data into a structured data structure; The OMB received by the COVA data converter 400 by maintaining the one-to-one correspondence between the COBA type codes generated by the COVA interface definition language compiler 300 from the structured data defined in the data structure file with each OMD data. A cobar typecode source file generator 230 for generating a cobar typecode source file 231 for allowing data to correspond to corresponding cobar data; Coba data conversion system for operating and managing the exchange system based on the common object request broker structure, characterized in that made, including.