KR100362173B1 - Method of asynchronous communication mode support based on CORBA for multi-service switching system - Google Patents

Abstract

The present invention relates to a method for supporting asynchronous communication mode in an open multiservice exchange system, and provides asynchronous communication between a host system and a signal-based remote system in an open multiservice platform using specialized middleware without an object concept for the best performance. In order to provide an asynchronous communication mode supporting method that can improve the throughput by reducing the load of the entire system by providing a mode service, and to deliver the address information of the response servant for the execution result according to the service request from the client. A first step of generating an input signal through a skeleton code implemented in the middleware and registering information on the return servant in a database; And extracting a corresponding signal by transmitting a return signal for the service request from the client to a middleware matching process, querying the database with the extracted signal value as a key value, obtaining address information of a return servant, and returning the result value. It includes a second step of delivering to the client, such as used in an open multi-service exchange system.

Description

Method of asynchronous communication mode support based on CORBA for multi-service switching system}

The present invention relates to a method of supporting an asynchronous communication mode in an open multiservice exchange system and a computer-readable recording medium recording a program for realizing the method. On the other hand, if the response requires a certain time due to the nature of the operation management block or the function request, if the service request is requested from the function request block, the service processing block responds to the service request block after performing non-real-time processing such as a relay line setting in the function processing block of the exchange The present invention relates to a method for supporting an asynchronous communication mode in an open multiservice exchange system capable of improving the performance of the entire system, and to a computer-readable recording medium having recorded thereon a program for realizing the method.

The open multiservice exchange software is implemented based on the signal of the Higher Design and Description Language (SDL), a language dedicated to the development of telecommunication systems of the Telecommunication Part of International Telecommunication Union (ITU-T). And, middleware based on C programming language is implemented so that object concept in object-oriented language can't be applied, so it is processed based on actual address of execution function. Therefore, in the present invention, the asynchronous communication mode service can be supported in an open multiservice exchange system based on middleware and a signal.

In other words, the present invention uses a high-level design and specification language (SDL) used in the system specification for the purpose of communication system development in the ITU-T, the SDL language is communicated to the independent process based on the signal communication is made, distributed Software is communicated using an interprocess communication process (IPC) of a supported operating system. In addition, middleware uses a method of building a distributed cross-platform software communication bus, executing a function implemented in a remote software by calling a function, and returning a result value. Software for communication systems implemented to date has been developed using an inter-process signal or communication protocol using an SDL or CHILL programming language based on an embedded real-time operating system.

For reference, the object access method is described in detail as follows.

First of all, with regard to the object access method, the "remote object creation and access method in the distributed object system" (Korean Patent Application No. "10-1999-0051702", filed on December 19, 1999) is as follows.

Prior art discloses that stubs can be created and accessed in the same way as creating and accessing objects in the same region as the client in a distributed object environment. It connects to the skeleton of the remote system and creates and accesses the object in the skeleton.

However, here, by accessing the remote object with client, server, and matching programs in the COVA environment to support the distributed computing environment, the remote object can be accessed using the object mediator to guarantee position transparency. It is not suggested to support the asynchronous communication mode using.

On the other hand, with respect to other object access method look at "multicast communication apparatus and method using the KOBA" (Korean Patent Application No. "10-1998-0050055", filed November 21, 1998).

The prior patent relates to a communication apparatus and method for transmitting multi-session, multicast, and multimedia streams using COVA, and applies a multicast structure required for multimedia data transmission in the Internet environment to a COVA environment, a distributed platform, and a signal processing part. By dividing the data transmission part, the signal processing part uses COBAR's object broker (ORB) and the data transmission part uses TCP / IP (Transmission Control Protocol / Internet Protocol) socket to make the signal processing part and data transmission part independent. It may have a flexible structure and a highly portable structure.

However, in this case, the signal processing part passes through COVA's object intermediary and transmits data using TCP / IP socket, so that the system can be made independently and has a flexible structure and a highly portable structure. It is not suggested to improve the performance.

Therefore, in the current technical field, a Servant Address, which is an implementation function, is a function implementation by integrating a signal-based open multiservice exchange system and an implementation function call of a middleware for a multiservice exchange system implemented in a C programming language. Through the conversion and mapping technology between the information and the specific signals of the SD-based multiservice exchange system function block, it is necessary to minimize the response delay for the service request and to support the asynchronous communication mode for the non-real time service request. It is required.

The present invention has been proposed to meet the above requirements, and provides an asynchronous communication mode service between a host system and a signal-based remote system in an open multiservice platform using specialized middleware without an object concept for the best performance. The purpose of the present invention is to provide an asynchronous communication mode supporting method for reducing the load of the entire system and improving a throughput, and a computer readable recording medium having recorded thereon a program for realizing the method.

1 is an exemplary configuration diagram of an open multiservice exchange system to which the present invention is applied.

2 is a flowchart illustrating a service processing procedure between SDL-based switching systems including application (servant) address information for a response in a host system requesting a non-real-time service according to the present invention.

3 is a flowchart illustrating a service processing procedure according to a servant information query for a signal in a remote system according to the present invention.

* Explanation of symbols for the main parts of the drawings

10: host system 11: operation management client

12,34: Skeleton code 13,33: Stub code

20: Database 14,35: Object Broker-A, Object Broker-B

30: remote system

31: Open Multiservice Switching System Software

32: middleware matching program

In order to achieve the above object, the present invention provides a method for supporting an asynchronous communication mode applied to an open multiservice exchange system. The present invention is implemented in middleware to deliver address information of a response servant in response to a service request from a client. Generating an input signal through the skeleton code and registering information on the return servant in the database; And extracting a corresponding signal by transmitting a return signal for the service request from the client to a middleware matching process, querying the database with the extracted signal value as a key value, obtaining address information of a return servant, and returning the result value. And a second step of delivering to the client.

In addition, the present invention, in order to deliver the address information of the response servant to the execution result in response to the service request from the client to the open multi-service exchange system having a processor, generates an input signal through the skeleton code implemented in the middleware And registering information about the return servant in the database; And extracting a corresponding signal by transmitting a return signal for the service request from the client to a middleware matching process, querying the database with the extracted signal value as a key value, obtaining address information of a return servant, and returning the result value. A computer readable recording medium having recorded thereon a program for realizing a second function delivered to a client is provided.

The present invention aims to support an asynchronous communication mode for a non-real time service request in order to minimize the response delay for the service request through the conversion and mapping technique between the servant address information and the specific signal of the functional block of the SDL-based multiservice switching system. . This method generates the code by the program generation tool by converting the implementation function address information into the input signal of the signal-based system through the skeleton code for calling the implementation function in the middleware technology and mapping the output signal to the address information of the return function. It is possible to ensure the software scalability of the signal-based system, the program reusability, the flexibility to overcome the difficulties in the expansion or maintenance of the system, and the position transparency of the middleware. There are features that can improve the overall throughput.

Therefore, the present invention provides the maximum number of service requests between the open multiservice exchange software written in SDL and the operation management software written in the middleware or the non-real-time call processing block in the same manner as the priority processing in the exchange system. By processing the real-time request first and processing the service request in the asynchronous communication mode later, it is possible to reduce the call processing load of the entire system and improve the call throughput. At this time, the service request by the asynchronous communication mode is transmitted as the parameter of the response request for the execution result as the service request parameter, thereby generating the input signal from the skeleton code implemented in the implementation part of the middleware, The information will be registered in the database. When the exchange system handles the service request and passes the return value to the middleware matching process via a signal, it extracts the signal from the delivered information. Since the address information of the return servant is obtained by querying the database with the extracted signal value as the key value, the implementation function is called in the same way as the service request using this information.

The above objects, features and advantages will become more apparent from the following detailed description taken in conjunction with the accompanying drawings. Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings.

1 is an exemplary configuration diagram of an open multiservice exchange system to which the present invention is applied.

As shown in FIG. 1, an open multi-service switching system includes a host system 10 for requesting a service that handles non-real time or operational management functions, a database 20, and a required service request. It consists of a remote system 30 that handles the open multiservice exchange function.

First, in order to process a specific function in the host system 10, the operation management client program 11 generates a service request message for performing a function. The generated message is located in the remote system 30 via the object intermediary-A 14, which forms a software bus via stub code 13 located in the operations management client program 11 to call the implementation function in the middleware. A communication path is established using the TCP / IP-based interworking protocol through the object intermediary-B 35 and the Internet or an internal network. At this time, if the message is transmitted through the set path, the object code of the remote system 30 is transmitted to the skeleton code 34 through the B-35, and the skeleton code 34 analyzes the message and returns it in case of an asynchronous communication mode service. Register the address and output signal information of the servant in the database 20, extract the parameters of the implementation function, convert them into parameters of the information of the input signal of the multiservice exchange system, encode them, and give the lowest priority. To send a signal to that block.

The open multiservice exchange system software 31 processes the corresponding function according to the input signal. At this time, the asynchronous communication mode signal is processed by the scheduler so that the priority of execution is changed to the execution priority. Minimize response latency to requests. When the request of the asynchronous communication mode service is processed, the return information is passed to the middleware matching program 32 via a signal, and the information about the return function for the corresponding signal is queried from the database to obtain the information, and the signal information is middleware. When the stub code for the implementation function is called to convert the service request message to the corresponding stub code 33, the stub code 33 extracts the information from the signal, encodes a parameter for the return information, and responds through the object broker-B 35. The message is delivered to the host system 10 where the system's implementation function is located. The forwarded message activates the corresponding function in the object broker-A 14 of the host system 10, unmarshalls the forwarded message in the skeleton code 12, and then calls the implementation function.

2 is a flowchart illustrating a service processing procedure between SDL-based switching systems including application program (servant) address information for a response in a host system requesting a non-real-time service according to the present invention.

As shown in FIG. 2, first, in order to request a service in an asynchronous communication mode, the lowest priority is set to perform a specific function in an operation management software block, and the address information for an implementation function and a return function is included. Call the function (201).

The stub code then interprets the type and data for the parameters passed from the operational management block to marshal them in the General Inter-Operability Protocol (GIOP) of the middleware, and then sends the GIOP request message to the object broker. Deliver (202).

After interpreting the GIOP request message, the object broker-A delivers information for setting up a TCP-based stream for delivering the message through the Internet with the object broker of the system where the service function implementing function is located (203). Then, the remote system transmits error information when the path to the corresponding port is activated or cannot be set due to lack of system resources, and sets the stream by returning a response message if the setting is possible. Thus, a communication path for message delivery between the two distributed systems is established (204).

Subsequently, the asynchronous communication mode service request message including the Internet InterORB Protocol (IIOP) header information in the GIOP request message is transmitted to the object broker process of the remote system through the connected path (205).

The object broker process of the remote system interprets the received IIOP message to obtain skeleton code information for the implementation function (206), and calls the skeleton code for the implementation function (207).

Subsequently, the skeleton code for the implementation function unmarshals the received message information, extracts information about the return signal and the return function in the case of the asynchronous communication mode service (208), and registers it in the database (209). Then, the input signal information of the signal-based exchange system is converted from the parameters of the implementation function through the middleware and coded, and the input signal is transferred to the corresponding block of the exchange software to perform the required function (210).

3 is a flowchart illustrating a service processing procedure according to a servant information query for a signal in a remote system according to the present invention. In the case of an exchange or other communication system, a call processing request is required to more service users by minimizing the load of the system. This is to shorten the service delay for.

Therefore, an open multiservice switchboard system can be implemented on real-time and non-real-time operating systems and the load on the system should be minimized.

As shown in FIG. 3, the service using the middleware requests a service in a synchronous mode communication method, and then uses a method of stopping execution of a process until a response is received. This is because the open multiservice exchange system software performs the request function received from the operation management block, passes the signal to the service request block, performs the function for a predetermined time in real time, and then returns the service request. It is a way of requesting service for return value through function.

Therefore, the exchange system software requests the service to the middleware matching process through the output signal after performing the request function in order to return the signal that is the result of execution (301).

Then, the middleware matching process interprets the signal received from the software at the time of exchange, obtains the information by querying the database for return function address information on the return signal (302), and calls the stub code for the corresponding return function (303). .

The stub code interprets the type and data of the parameter of the return signal, marshals it to the general message transfer format (GIOP) of the middleware, and then transmits the GIOP request message to the object broker-B (304).

Then, the asynchronous communication mode object broker-B interprets the GIOP message and attempts to set up a TCP-based stream for passing the message through the object broker-A of the system where the implementation function of the service request is located. However, since the communication path is already established as a return service request, after checking the state of the corresponding port, if it is possible to transmit, the object of the host system sends the asynchronous communication mode service request message including IIOP header information to the GIOP message through the connected path. Forward to Intermediate-A (305).

The object broker-A of the host system interprets the received IIOP message, obtains the skeleton code information from the servant information on the return function in the asynchronous communication mode, and implements the corresponding implementation function through the portable object adapter of the object broker. After activation, call the skeleton code for the implementation function (306).

In the skeleton code, the received message is unmarshalled to extract parameter information for a function call, and then the return implementation code is called (307) to pass the corresponding return value to the return information search block of the operation management block of the host system ( 308).

The method of the present invention as described above may be implemented as a program and stored in a computer-readable recording medium (CD-ROM, RAM, ROM, floppy disk, hard disk, magneto-optical disk, etc.).

The present invention described above is not limited to the above-described embodiments and the accompanying drawings, and various substitutions, modifications, and changes are possible in the art without departing from the technical spirit of the present invention. It will be apparent to those of ordinary knowledge.

As described above, the present invention can improve the call processing performance of the entire system by providing the asynchronous communication mode service for the low-priority non-real-time service request, and the host system for high-cost switch control. By reducing the number of subscribers, the initial investment cost of the service provider can be reduced.

In addition, the present invention can support the development of an open multiservice exchange system on a non-real time operating system, and can reduce the load of the exchange system in an interworking service between a signal based exchange system and a synchronous mode type middleware.

Claims (4)

In the asynchronous communication mode support method applied to an open multiservice exchange system, A first step of generating an input signal through a skeleton code implemented in middleware and registering information on a return servant in a database in order to deliver address information of a response servant to an execution result according to a service request from a client; And Deliver the return signal for the service request from the client to the middleware matching process, extract the signal, query the database with the extracted signal value as a key value to obtain the address information of the return servant, and return the result value to the client. 2nd step forwarding to Asynchronous communication mode support method in an open multiservice exchange system comprising a. The method of claim 1, The first step is, Setting a lowest priority to perform a specific function in the operation management software, and calling the corresponding function including address information on the implementation function and the return function; A fourth step of parsing a type and data of a parameter transmitted from an operation management unit through the stub code and marshalling it in a general message transfer format (GIOP) of middleware, and then delivering a GIOP request message to an object mediator; A fifth step of interpreting the delivered GIOP request message and setting a stream to deliver a message through the Internet with the object intermediary in which an implementation function of a service request is located to connect a communication path for message delivery; Transmitting asynchronous communication mode service request message including IIOP (Internet InterORB Protocol) header information in a GIOP request message to the object broker process of the remote system through the connected path; A seventh step of interpreting the delivered IIOP message to obtain skeleton code information on an implementation function and calling the skeleton code on the implementation function; An eighth step of unmarshalling the message information received through the skeleton code, extracting information about a return signal and a return function in the case of an asynchronous communication mode service, and then registering the information in a database; And A ninth step of delivering the registered information to a corresponding block of the exchange system software; Asynchronous communication mode support method in an open multiservice exchange system comprising a. The method according to claim 1 or 2, The second step, A tenth step of sending a return signal to the middleware matching process to return a signal requested from the client; An eleventh step of interpreting the transmitted return signal, querying the database for return function address information on the return signal, obtaining the information, and calling a stub code for the return function; A twelfth step of parsing a type and data of a parameter of a return signal through the stub code and marshalling it in a general message transfer format (GIOP) of middleware, and then delivering a GIOP request message to an object broker process of the remote system; ; After interpreting the delivered GIOP request message, the stream is set to deliver the message through the Internet with the object broker, and after checking the state of the corresponding port, the service request message is transmitted through the connected path according to the transmission state. A thirteenth step of transferring to a process; Acquiring skeleton code information according to the delivered service request message, activating a corresponding implementation function through the portable object adapter of the object intermediary, and then calling the skeleton code for an implementation function; And Extracting parameter information for a function call by unmarshalling the called message, and then calling a return implementation code to deliver a corresponding return value to a return information search block of an operation management block of the host system Asynchronous communication mode support method in an open multiservice exchange system comprising a. In an open multiservice exchange system with a large processor, A first function of generating an input signal through a skeleton code implemented in middleware and registering information on a return servant in a database in order to deliver address information of a response servant to an execution result according to a service request from a client; And Deliver the return signal for the service request from the client to the middleware matching process, extract the signal, query the database with the extracted signal value as a key value to obtain the address information of the return servant, and return the result value to the client. Function to forward to A computer-readable recording medium having recorded thereon a program for realizing this.