KR100357850B1 - Distributed objects oriented communication system and method for common service various protocolby used corba proxy module therefor - Google Patents

Abstract

The present invention relates to a distributed object-oriented communication system and a method for various protocol common services for providing a standard COBER programming interface to heterogeneous communication protocols in a communication switching control application.

It has different communication applications and has a number of clients that send service requests to servers distributed in remote systems and return responses returned by the servers, and service information for different communication applications. A number of servers that receive the service requests of the clients distributed to and provide the requested service and return the response, and CORBA Proxy internally converts the service request into a message form, and protocols such as TCP / IP or SS7 A client-side CORBA Proxy API that sends a service request message to a CORBA Proxy of the server, and a TCP that connects the client-side CORBA Proxy API and the server-side CORBA Proxy API to transmit a message generated by a CORBA Proxy. / IP, SS7 protocol, and CORBA Proxy internally service request responses in the form of messages In turn, the server-side CORBA Proxy API that sends service request response messages to the CORBA Proxy on the client side using protocols such as TCP / IP or SS7, which are underlying protocols, and the client-side CORBA Proxy API and the server-side CORBA Proxy API. As a function to provide location transparency of CORBA, it provides naming service so that CORBA Stub Proxy can find the desired CORBA Skeleton Proxy and request a service, and basically manages service list that binds service name and server address. And a service list storage unit for storing a service request relay and a service name and a server address.

Description

DISTRIBUTED OBJECTS ORIENTED COMMUNICATION SYSTEM AND METHOD FOR COMMON SERVICE VARIOUS PROTOCOLBY USED CORBA PROXY MODULE THEREFOR}

The present invention relates to a distributed object-oriented communication system, and more particularly, to a distributed object-oriented communication system and a method for various protocol common services for providing a standard Cober programming interface to heterogeneous communication protocols in a communication switching control application.

Typically, a communication system consists of a plurality of subsystems, each of which exchanges data with each other using different communication protocols. Protocols used in communication systems include protocols designed for different purposes, such as CORBA, TCP / IP, and SS7. These protocols use different application programming interfaces (APIs) as shown in FIG. It is dependent on different communication equipment and communication media. For example, CORBA and TCP / IP protocols are used on the Internet, and SS7 is used between communication devices.

The protocol used for the exchange control of the communication system requires reliability and real time, and the Internet protocols such as TCP / IP do not provide such characteristics. CORBA's IIOP protocol feature is based on the existing Internet protocols and is insufficient to control communication systems. However, the advantages of CORBA's programming model and interface, such as location transparency, language transparency, and platform transparency, which are not provided by the existing network programming APIs, are still important for programming communication systems. In order to take advantage of these advantages, there was a problem that the lower communication protocol could not be applied to the communication system while the upper API of CORBA was saved.

In addition, programs that perform the same function should be written differently for each communication protocol, and APIs for each protocol should be written using different programming models. Because of this, if the same program needs to use a different protocol or to apply a new protocol, it cannot be applied without changing the existing protocol.

In addition, CORBA is a standard protocol for distributed systems using distributed object-oriented models, and it is easy to program because it provides an independent and programming language independent interface using the client / server model. However, the current commercial CORBA implementations mainly support the Internet network, use IIOP (Internet Inter ORB Protocol), and use TCP / IP as the underlying protocol.

In addition, the existing TCP / IP and SS7 have different APIs and do not directly support distributed object systems. Therefore, there is a problem in that programming must be complicated and the program must be modified and applied to each protocol.

Accordingly, an object of the present invention is to create an application program using a standard CORBA programming interface in a distributed processing system using various communication protocols, and to provide a distributed object-oriented communication system for various protocol common services that provide location transparency, language transparency, and platform transparency. And it provides a method.

Another object of the present invention is to provide a distributed object-oriented communication system and method for processing a protocol by an application program using a different CORBA programming interface.

1 is a configuration diagram of a distributed system using different programming interfaces between heterogeneous communication protocols

2 is a configuration diagram of a distributed system using a consistent programming interface by applying a standard CORBA API to heterogeneous protocols according to an embodiment of the present invention.

3 is an internal structure diagram of a CORBA Proxy according to an embodiment of the present invention

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings. In the following description of the present invention, if it is determined that a detailed description of a related known function or configuration may unnecessarily obscure the subject matter of the present invention, the detailed description thereof will be omitted.

2 is a block diagram of a distributed system using a consistent programming interface by applying a standard CORBA API to heterogeneous protocols according to an embodiment of the present invention.

App A, B, and C clients are client of communication application program. It sends service request to server distributed in remote system and sends back server's reply. App A, B, C server is a server of communication application program, receives service request of client distributed in remote system, provides requested service and returns response. The application receives the service request according to the CORBA Server API rules. The CORBA API is where CORBA Proxy provides applications with standard CORBA APIs. CORBA Proxy Internally converts a service request into a message form and sends a message to the CORBA Proxy on the server side using protocols such as TCP / IP or SS7. TCP / IP and SS7 protocols are used to send messages generated by CORBA Proxy to underlying protocols.

3 is an internal structural diagram of a CORBA Proxy according to an embodiment of the present invention.

CORBA Stub is a module that provides CORBA APIs as a client part of an application. It is a standard interface part of CORBA. It is generated by CORBA compilers for each programming language and passes requirements to CORBA Stub Proxy. It is modified to receive and provides the language transparency of CORBA. CORBA Skeleton is a module that provides CORBA APIs as the server part of an application. It is a standard interface part of CORBA, and is generated by the CORBA compiler for each programming language, and passes the requirements to the CORBA Stub Proxy. It is fixed and provides the language transparency of CORBA. The CORBA Stub Proxy receives the service request from the CORBA Stub, converts it into a simple message that can be sent through the underlying protocol, and sends it back to the CORBA Stub as a CORBA response. It acts on behalf of CORBA, connects to CORBA Skeleton Proxy through CORBA, and then sends and receives messages directly. The CORBA Skeleton Proxy converts the service request in the form of a simple message received through the underlying protocol to the CORBA Skeleton, converts the request result processed by the server into a CORBA response message, and converts it into a simple message. Send to CORBA Stub Proxy through underlying protocol. Initially, it registers itself with SRB so that CORBA Stub Proxy can connect through SRB (Service Request Broker), which is a service request relay. SRB is a function to provide location transparency of CORBA, and provides naming service so that CORBA Stub Proxy can find the desired CORBA Skeleton Proxy and request service. Basically, it manages service list which binds service name and server address. When a client performs a server connection request at initialization, it retrieves this service list and informs the client of the server's address.

In describing the operation of registering the service of the server, the server requests that the service name be registered in the list using the CORBA Skeleton API during the initialization process. CORBA Skeleton then receives this request and forwards it to the CORBA Skeleton Proxy. At this time, CORBA Skeleton Proxy transmits the service name of the server and the CORBA Skeleton Proxy address of the server to the remote SRB using the underlying transport protocol. The SRB then registers it in the service list.

In describing the operation of a client connecting to a server, the client sends a request signal to a CORBA stub to initialize the CORBA stub by using the CORBA stub API to send a request signal to the CORBA stub during initialization. . The CORBA Stub Proxy sends the query signal to the remote SRB using the underlying transport protocol with the name of the desired service. The SRB then receives this query and sends the CORBA Skeleton Proxy address to the CORBA Stub Proxy that corresponds to the service name in the service list. The CORBA Stub Proxy records the CORBA Skeleton Proxy address of the server it receives.

In this way, the client connects to the server and sends a request signal from the application program through the CORBA stub proxy. Then, CORBA Stub Proxy converts this request signal into a message form through marshaling process and sends it to the CORBA Skeleton Proxy of the server through a sub-protocol, and waits for the server's response message when it needs to wait for the server's response. When the application request signal is sent to the server, the CORBA Skeleton Proxy of the server analyzes the application's request message from the client and calls the appropriate server's method, which unmarshals the arguments. Pass it to the method of the server application via CORBA Skeleton. The server application method performs the service corresponding to the client's request and returns the result to the CORBA Skeleton Proxy through the CORBA Skeleton. The CORBA Skeleton Proxy then takes the result of the server application's method and converts it into a message after marshaling. The CORBA Skeleton Proxy then sends it to the client via the underlying transport protocol. At this time, the CORBA Stub Proxy of the client analyzes the received response message and converts it into a message through unmarshaling. The CORBA stub proxy then returns the server's response to the client application through the CORBA stub.

As described above, the present invention minimizes modification of an application program in a communication system using various communication protocols, and makes it possible to easily program a protocol suitable for a communication system using a standard CORBA programming interface, and also to use a standard CORBA programming interface. Allows you to write applications using, which has the advantage of providing location transparency, language transparency, and platform transparency.

Claims (5)

In a distributed object-oriented communication system for various protocol common services using a coberflash module, A plurality of clients having different communication applications and sending a service request to a server distributed in a remote system and returning a response from the server; A plurality of servers having service information for different communication applications, receiving a service request of a client distributed in a remote system, providing a requested service, and returning a response; A client-side CoberFlock API that internally converts a service request into a message form and transmits a service request message to the server's CoberFlock using a protocol such as TCP / IP or SS7, A TCP / IP and SS7 protocol connected to the client-side Coberloxi API and the server-side Coberloxi API to perform a function of transmitting a message generated by Coberloxi; The server-side Coberflix API that internally converts the service request response into a message form and transmits the service request response message to the client's Coberloxi using a protocol such as TCP / IP or SS7. , Naming service, which is connected to the client-side Coberflash API and server-side Coberflash API to provide Cober's location transparency so that Cobus Tube Flash can find and request a Cober Skeleton Flash. And a service request relay that manages a list of services that bundle and manage service names and server addresses. A distributed object-oriented communication system for various protocol common services using the CoberFlock module, which comprises a service list storage unit that stores service names and server addresses. The method of claim 1, The application program is a distributed object-oriented communication system for a variety of protocol common services using the Cober-Flash module, characterized in that for receiving the service request in accordance with the Cober Server API rules. The method of claim 1, wherein the client-side CORBA API is CobusTube, generated by the Cober compiler for each programming language, modified to pass and receive requirements to CobusTube Flash, Receives a service request from the Cobus tube and converts it into a simple message form that can be transmitted through a lower protocol, and receives a response from the server and returns a Cober response to the Cobus tube on behalf of Cober, A distributed object-oriented communication system for a variety of protocol common services using the Cober-Flocky module, which is connected to Cober-Skerriton-Flocky through Cober and subsequently sends and receives messages directly. 4. The server side cover API of claim 3, wherein Generated by the Cober compiler for each programming language, modified to pass and receive requirements to CobusTube Flash, and to provide CoberScaleton's language transparency, Converts the service request in the form of a simple message received through the lower protocol to the Cober Skeletton, converts the request result processed by the server into a Cober response message, and converts the request result to the Covers tube FLASH through the lower protocol in the form of a simple message. Distributed object-oriented communication system for a variety of protocol common services using a Coberflash module, characterized in that it consists of transmitting Cober Skeletton flash. It has different communication applications and has a number of clients that send service requests to servers distributed in remote systems and return responses returned by the servers, and service information for different communication applications. A number of servers that receive service requests from clients distributed to and provide requested services and return responses, and are created by the Cober compiler for each programming language and modified to pass and receive the requirements to CobusTube Flash. , CobusTube, which provides Cober's language transparency, Receives the service request from the Cobus tube and converts it into a simple message form that can be transmitted through the lower protocol, transmits, receives a response from the server and returns it as a Cober response to the Cober tube on behalf of Cober, Cober Through CoberSkyriton's FLASH, and then directly send and receive messages, CoberSkyRitton's FLASH is generated by the Cober compiler for each programming language, and modified to pass and receive requirements to CoberS tube Flash. Cober Sritten provides Cober Sritten and Cober Sritten by converting and forwarding service requests in the form of simple messages received through sub-protocols, and converts the server-requested results into Cober Response messages. Cobbstube flash through the underlying protocol in the form of a message And a TCP / IP and SS7 protocol which is connected to the client-side Cober-Flash API and the server-side Cober-Flash API to transmit the messages generated by the Cober-Flash. It is connected to the client-side Cober Flash API and the server-side Cober Flash API to provide the transparency of Cober's location. It provides a naming service so that Cobus Tube Flash can find and request the Cober Skeleton Flash. In the distributed object-oriented communication system, which has a service request relay that manages a service list that basically manages the service name and server address, and the service list storage unit that stores the service name and server address, various protocols using the Coberflash module In the common service method, A process of delivering from CobusTube to CobusTube Flash when a request is made to find a server providing a name of a desired service from one of the clients; Sending a query to the service request relay at a remote location by using a lower transmission protocol containing a name of a desired service in the cobus tube flash; Receiving, by the service request relay receiving the query, the address of the server Cover Scritten Flock corresponding to the service name from the service list storage unit and transmitting the address to the Covers tube flash; Transmitting a requirement to a cobers tube flash through a cobus tube in an application of the client among the plurality of clients; Converting the requirement into a message form through a marshalling step in the cobus tube flash, and transmitting the same to the coverskerton flash server of the server through a lower protocol; When the Cober Skeletton Flock receives a message containing a client's requirement, calling the application method of the corresponding server through an unmarshalling step by analyzing the message; Returning the result to the Cober Skeleton proxy through the Cober Skeleton to perform a service corresponding to the client request in an application method of the server; Transforming the returned result value into a message form through a marshalling step, and then transmitting the result value to a client through a lower protocol.