JP4262121B2 - Object management method, system, and program - Google Patents

Description

  The present invention is suitable for a communication system, and in a computer system in which a platform equipped with OpenAPI and a service application using OpenAPI are connected by a software bus, an object is generated in accordance with process extinction and restart or cluster switching. The present invention relates to an object management method, system, and program for recovering data and resuming communication between objects.

  A platform having an application program interface (API) such as OpenAPI and a service application using the API are coupled via a software bus, and a message exchange technique between objects in a distributed system environment is used. There is known a system configured such that a generated object and an object of a service application can perform inter-object communication via a software bus. Such a system configuration is applied to various telephone services based on an IP network, and is known as a so-called VoIP (Voice Over IP) or IP Centrex. In constructing a new service to be provided to the user, the basic control such as call processing is unified through the Open API, which has a great merit including development costs.

  In such a system, it is necessary to provide a mechanism that can increase resistance to various faults and continue to provide a robust service. However, conventionally, there are the following problems. For example, when a platform-side process is restarted independently, the platform-side object generated by process activation or call generation disappears, but since the information for reproducing the object is not retained, the service after restarting A difference with the object managed on the application side occurs, and the service cannot be continued. The same is true when the process is restarted on the service application side, and a difference occurs with respect to the disappeared object. On the other hand, in the cluster switching between the control system composed of the active system and the standby system for processing calls, the object corresponding to the object managed by the active platform and service application is the standby platform and service application. It becomes nonexistent and the service cannot continue. There is no mention in OpenAPI regarding the handling of objects in these cases (see Non-Patent Document 1, for example).

  Therefore, due to the above-described problems, conventionally, there is no other way than to make the service non-rescue in the initial setting of an object by process restart or the like. An electronic exchange in which an application is configured by a set of objects and call connection is realized by a series of these objects is described in Patent Document 1 below, for example. The patent document 1 also describes the initial setting of call processing, but it is not a solution to the above problem.

Japanese Patent No. 2854957

ETSI ES 202 915-3 V1.2.1 (2003-08)

  As described above, in a system in which the platform equipped with OpenAPI and the service application software that uses OpenAPI are connected by a software bus, the process of these platforms or service applications disappears and restarts. When an object having call information managed by a process disappears, there is a problem that it is impossible to control a call related to a call in progress. In services such as so-called VoIP (Voice Over IP) and IP Centrex, it is necessary to continue the service. For this purpose, it is essential to reproduce objects and restore API communication between objects.

  The present invention has been made in consideration of such circumstances, and management of objects in inter-object communication that can relieve service processing by executing recovery of an object and API communication in cooperation with a platform and a service application. It is an object to provide a method, a system, and a program.

An object management method according to an aspect of the present invention includes a first object generated for each event by a platform having an application program interface and a second object generated by an application for each event via a software bus. In the object management method in the system for processing the event by communicating, the first and second object reference information necessary for the first and second objects to refer to each other via the software bus a storage step of storing the storage information which includes the storage means, and reproducing step of said first, according to at least one of disappearance of the second object, reproduces the objects needed to continue processing of the event, the Refers to the first object Sending the first object reference information for the application to the application and sending the second object reference information for referring to the second object to the platform. An object management method comprising: a recovery step of recovering communication via the software bus using information stored in the storage unit after exchanging between the platform and the application .

  According to the present invention, an object and an API related to information that is necessary for continuation of a service when a process is restarted in a system in which OpenAPI is installed and software that uses OpenAPI is connected by a software bus, and an object that holds the information. By performing communication recovery in cooperation with the platform and the service application, service processing can be relieved.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings. FIG. 1 is a block diagram showing a system according to an embodiment to which the present invention is applied. This system is a communication system that can be operated by switching the active control device 10 and the standby control device 20 via the cluster switching unit 50 as shown in the figure, and is connected to the network 40. The network 40 is a telephone network based on, for example, an IP network, and is connected to IP telephones 1, 2,. The control devices 10 and 20 are installed in a carrier or a service provider, for example, and provide an IP telephone service, an IP Centrex service, and various other services. Alternatively, the control devices 10 and 20 are installed in a premises such as a company or a local government, and provide a PBX (Private Branch Exchange). These embodiments are merely examples, and the present invention can be applied to other communication systems. Also, the configuration of the present embodiment shown in FIG. 1 can be variously modified within a range obvious to those skilled in the art. For example, the present invention can be applied to a control apparatus that does not employ a cluster configuration having an active system and a standby system as shown in FIG.

  In the present embodiment, the active control device 10 is a device responsible for call processing related to the IP telephone service, and includes a platform call processing function unit 100 and a service application call processing function unit 110. Although not shown in FIG. 1, the platform call processing function unit 100 is realized based on an operating system (OS). Such platform call processing function unit 100 and service application call processing function unit 110 can be in the form of a computer program, and the present invention can also be implemented as a computer program.

  The platform call processing function unit 100 and the service application call processing function unit 110 are configured to be communicable via the software bus 120. Here, the communication via the software bus 120 refers to inter-object communication (or API communication) between the application process and the platform side process. The platform call processing function unit 100 includes a call control / protocol unit 101 and an OpenAPI 102 as shown in FIG. “OpenAPI” described in this specification is an abbreviation for “Open Application Program Interface”, and is defined so as to conform to a communication method between objects realized through a software bus. The software bus is assumed to be based on a distributed technology such as CORBA (Common Object Request Broker Architecture). The OpenAPI 102 provides an interface to the service application call processing function unit 110 so that inter-object communication with the service application call processing function unit 110 can be performed via the software bus 120.

  FIG. 2 is a diagram illustrating an example of object data. In the platform call processing function unit 100, there are an object generated for each call occurrence and at least one object for managing the object generated for each call. In the present specification, the former object is referred to as a Call object, and the latter object is referred to as CallCntMng. FIG. 2 (a) shows the relationship between the Call object and the CallCntMng object. That is, as shown in FIG. 2A, the data (1022 object data) of one Call object corresponding to one generated call makes the call identifier, call information, and this Call object accessible remotely. Call object reference information (1022 object reference information) and AppCall object reference information (1102 object reference information) for allowing the service application call processing function unit 110 to access an AppCall object corresponding to the Call object. On the other hand, the data (1021) of the CallCntMng object includes reference information (1021 object reference information) of the CallCntMng object and reference information (1101 object reference information) of the AppCallCntMng object corresponding to the CallCntMng object in the service application call processing function unit 110. And have. For all calls, the call identifier, call information, and a pointer indicating the Call object (pointer of the 1022 object) are included.

  Similarly, in the service application call processing function unit 110, there are an object generated for each call and an object for managing the object. In the present specification, the former object is referred to as an AppCall object, and the latter object is referred to as an AppCallCntMng object. FIG. 2B shows the relationship between the AppCall object and the AppCallCntMng object. The details of the data structure correspond to those of the platform call processing function unit 100 as can be seen from FIG.

  In order for the objects of the platform call processing function unit 100 and the objects of the service application call processing function unit 110 to communicate, reference information about these objects needs to be registered in the software bus 120. The reference information of each object registered in the software bus 120 can be acquired through the software bus 120 and is managed in each of the service application call processing function unit 110 and the OpenAPI 102 of the platform call processing function unit 100. .

  FIG. 3 is a diagram illustrating a configuration example of a management table of object reference information in the software bus. The software bus 120 manages objects registered in the software bus 120 and object reference information in a management table 1201 as shown in FIG. When a service application object (for example, object 1102) communicates with a platform object (for example, object 1022), the management table 1201 in FIG. 3 is checked (looked up) with object reference information (for example, object reference information 2) on the software bus 120. Then, the corresponding object (object 2 in this example) among the plurality of objects generated by the platform is specified.

  Conversely, when communication is started from the platform to the service application, the corresponding object can be specified from the object reference information of the object generated by the service application, and an event can be notified to the object.

  The active control device 10 is configured as described above. On the other hand, the standby control device 20 is provided in a pair with the active control device 10 and has a configuration substantially equivalent to the active control device 10 as can be seen from FIG. Such a standby control device 20 is driven by the function of cluster switching when a failure or the like occurs in the active control device 10 and is operated as an alternative. When cluster switching to the standby control device 20 occurs, the software bus used is the software bus 220, but the function provided by the software bus 220 is the same as the software bus 120. Note that the object reference information managed by the software bus 120 and the software bus 220 connected via the network 40 must be unique so that the object can be uniquely identified between these objects.

  FIG. 4 is a sequence diagram showing a callback processing procedure as an example of a basic operation procedure in the system of the present embodiment. The call processing itself of the callback is publicly known, and will not be described as a main feature of the present invention. This processing procedure includes step S1 for registering a callback in response to an external call setting request (event), and step S2 for requesting call setting from the system of the present embodiment to the outside for the callback. Have. After these steps S1 and S2, actual communication is started. During this communication, information storage processing steps S3 and S4 and information deletion processing steps S6 and 7 according to the present invention are executed.

  First, step S1 will be described. When a call is generated externally, a call setting event is generated on the call control / protocol unit 101 side, and the event is notified to the CallCntMng object. In response to this call setup event notification, the CallCntMng object generates a Call object. By registering the Call object in the software bus 120, the CallCntMng object acquires the object reference information of the Call object. Next, the call identifier for the generated Call object is issued in the process of the CallCntMng object, and the object is managed for each call by associating the Call object with the call identifier as shown in FIG. Here, “calling out a call identifier” is to newly generate an identifier that does not overlap with other identifiers that have already been paid out, or to select from predetermined selection candidates. Next, the CallCntMng object notifies the AppCallCntMng object of the call processing event in which parameters such as the object reference information of the Call object that is the target of call control and the call identifier are set. The AppCallCntMng object generates an AppCall object, registers the object in the software bus 120 like Call, and acquires necessary object reference information. In addition, by the callback registration, the Call object acquires and holds the reference information of the corresponding AppCall object.

  After the object corresponding to the call is registered and the object reference information is appropriately acquired and held, the corresponding object is specified by passing the reference information of the communication partner object to the software bus 120, that is, Call, CallCntMng , AppCall, AppCallCntMng is used for inter-object communication.

  In the present embodiment, the platform call processing function unit of the active control device 10 is configured so that the service can be continued without interruption even when the active process is restored and the process is restarted due to cluster switching. 100 and service application call processing function unit 110 execute step S3 and step S4 for the call in communication. In step S <b> 3, information necessary for restoration is stored in the storage device 30 for the service application side object. In step S4, information necessary for recovery is saved in the storage device 30 for the platform-side object. When the call is disconnected (for example, call release notification in step S5), the stored data is deleted from the storage device 30 in steps S6 and S7.

  FIG. 5 is a diagram showing the structure of data stored in the storage device 30. As shown in FIG. 5, the stored data includes call information managed by the object and object reference information 1021, 1101 objects 1021, 1101 associated with objects for API communication via the software bus 120. The link information between objects using the call identifier held as a key, and the call identifier, call information, and object reference information of the 1022 and 1102 objects held in the 1022 and 1102 objects.

  As described above, the software bus 120 manages the relationship between the object notified of the call processing event and the reference information of the object using a table as shown in FIG. When the service application call processing function unit 110 communicates with the OpenAPI 102 object of the platform call processing function unit 100, the software bus 120 uses the object reference information of the object generated by the platform call processing function unit 100 to manage the management table 1201 in FIG. Identify an object from Further, even when communication with the service application call processing function unit 110 is started from the OpenAPI 102 side of the platform call processing function unit 100, the object reference information of the object generated by the service application call processing function unit 110 is the same as the application. The corresponding object is identified from the event, and the event is notified to the object.

  Hereinafter, referring to FIGS. 6 to 8, when the platform call processing function unit restarts the process, when the service application call processing function unit restarts the process, and when switching the cluster between the active system and the standby system The processing procedure of this embodiment is demonstrated about each of these.

  FIG. 6 is a diagram illustrating a processing procedure when the process of the platform call processing function unit 100 is restarted in the active control device 10. As described in the example of the call processing sequence in FIG. 4, the 1021 and 1022 objects relating to the call that has changed during communication are stored in the storage device 30 in accordance with the data structure shown in FIG. 5 (step S101; Object information storage). The 1101 and 1102 objects are similarly stored (step S102; service application management target call information / object information storage).

  Here, when the platform call processing function unit 100 restarts the process (step S103), the storage data of the 1021 and 1022 objects related to the call transitioned during communication is read from the storage device 30 (step S104; platform management target). Call information / object information acquisition). Based on the obtained information, the 1021 and 1022 objects managed by the OpenAPI 102 of the platform call processing function unit 100 are regenerated and restored (step S105). Thereafter, the restored object is re-registered in the management table 1201 of the software bus 120 shown in FIG. 3 (step S106; platform management target object registration), and API communication with the service application call processing function unit 110 is restored (step S107). ).

  According to the above processing procedure, even if the platform call processing function unit 100 restarts the process, the object in the platform call processing function unit 100 is reproduced based on the data stored in the storage device 30, and the software bus Since the data is re-registered in 120, communication between objects (API communication) via the software bus 120 can be restored, and the service is not interrupted. Therefore, the robustness and availability of the system can be improved.

  FIG. 7 is a diagram showing a processing procedure when the process of the service application call processing function unit 110 is restarted in the active control device 10. As described in the example of the call processing sequence in FIG. 4, the 1021 and 1022 objects related to the call that has changed during communication are stored in the storage device 30 in accordance with the data structure shown in FIG. 5 (step S201; Object information storage). The 1101 and 1102 objects are similarly stored (step S202; service application management target call information / object information storage).

  Here, when the service application call processing function unit 110 restarts the process (step S203), the storage data of the objects 1101 and 1102 are read from the storage device 30 (step S204; service application management target call information / object information acquisition). . Based on the obtained information, the 1101 and 1022 objects managed by the service application call processing function unit 110 are regenerated and restored (step S205). After that, the restored object is re-registered in the management table 1201 of the software bus 120 shown in FIG. 3 (step S206; service application management object registration), and API communication with the platform call processing function unit 100 is restored (step S207). ).

  According to the above processing procedure, even if the service application call processing function unit 110 restarts the process, the object in the service application call processing function unit 110 is reproduced based on the stored data in the storage device 30, and Since re-registering with the software bus 120, communication between objects (API communication) via the software bus 120 can be recovered, and the service is not interrupted. Therefore, the robustness and availability of the system can be improved.

  FIG. 8 is a diagram illustrating a processing procedure when cluster switching occurs from the active control device 10 to the standby control device 20. In the active control device 10, the 1021 and 1022 objects related to the call that has transitioned during communication as in the call processing sequence example of FIG. 2 are stored in the storage device 30 according to the data structure shown in FIG. 5 (step S 301; platform Managed call information / object information storage). The 1101 and 1102 objects are similarly stored (step S302; service application management target call information / object information storage).

  Here, when cluster switching occurs from the active control device 10 to the standby control device 20 (step S303), the platform call processing function unit 200 and the service application call processing function unit 210 of the standby control device 20 First, stored data of the 1021 and 1022 objects are read from the storage device 30 (step S304; platform management target call information / object information acquisition). Next, the storage data of the 1101 and 1102 objects are acquired and read out from the storage device 30 (step S305; service application management target call information / object information acquisition).

  Based on the obtained information, the OpenAPI 202 of the platform call processing function unit 200 of the standby control device 20 and the 1021, 1022, 1101, and 1102 objects managed by the service application call processing function unit 210 are regenerated (steps). S306). Thereafter, in order to newly acquire object reference information corresponding to the restored 1021, 1022, 1101, and 1102 objects from the software bus 220, the objects and object reference information of the software bus 220 similar to those shown in FIG. (Step S307; platform management target object registration and object reference information acquisition, step S308; service application management target object registration and object reference information acquisition).

  Next, in step S309, the reference information of the 1021 and 1022 objects managed by the OpenAPI 202 of the platform call processing function unit 200 and the reference information of the 1101 and 1102 objects managed by the service application call processing function unit 210 are mutually exchanged. After the replacement, API communication is restored in step S310.

  According to the above processing procedure, even when a cluster switch occurs between the active control device 10 and the standby control device 20, the active control device 10 and the standby control device 20 are used. Necessary objects are reproduced based on the data stored in the storage device 30 and re-registered in the corresponding software bus 120 (or 220), so that the inter-object communication via the software bus 120 (or 220) is performed. (API communication) can be recovered and the service is not interrupted. Therefore, the robustness and availability of the system can be improved.

  In the above embodiment, the service application and the platform have been described as a cluster configuration in which the platform operates on the same control device. However, in the single configuration mode or the service application and the platform are separated as the control device. However, it goes without saying that the present invention can be applied with obvious modifications. Further, the case of processing a call during communication has been described, but it goes without saying that an object having a call process in another state or a process other than the call process can be similarly processed according to the present invention.

  Further, the present invention is not limited to the above-described embodiment as it is, and can be embodied by modifying the constituent elements without departing from the scope of the invention in the implementation stage. In addition, various inventions can be formed by appropriately combining a plurality of components disclosed in the embodiment. For example, some components may be deleted from all the components shown in the embodiment. Furthermore, constituent elements over different embodiments may be appropriately combined.

The block diagram which shows the system which concerns on one Embodiment with which this invention was applied. Diagram showing an example of object data The figure which shows the structural example of the management table of the object reference information in a software bus FIG. 3 is a sequence diagram showing a callback processing procedure as an example of a basic operation procedure in the system of the embodiment The figure which shows the structure of the data which is preserved in the storage device The figure which shows the process sequence when the process of a platform call processing function part restarts in the active control apparatus The figure which shows the process sequence when the process of the service application call processing function part restarts in the active control apparatus Diagram showing the processing procedure when cluster switching occurs from the active controller to the standby controller

Explanation of symbols

1 to n: IP telephone, 10: active control device, 20: standby control device, 30: storage device, 40: IP network, 50: cluster switching unit

Claims (9)

The first object generated for each event by the platform having the application program interface and the second object generated by the application for each event communicate with each other via a software bus. In the management method,
A storage step of storing storage information including first and second object reference information necessary for the first and second objects to refer to each other via the software bus;
A playback step of playing back an object required to continue processing the event in response to the disappearance of at least one of the first and second objects;
The first object reference information for referring to the first object is sent to the application, and the second object reference information for referring to the second object is sent to the platform. And a recovery step of recovering communication via the software bus using information stored in the storage means after exchanging second object reference information between the platform and the application. . The software bus has a table for storing the first and second objects and the first and second object reference information in association with each other.
The object management method according to claim 1, wherein the restoration step includes a step of re-registering object reference information of the reproduced object in the table. A switching step of switching the first cluster to the second cluster;
Playing back the first and second objects present in the first cluster in the second cluster;
The object management method according to claim 1, further comprising a step of restoring communication in the first cluster via the software bus in the second cluster using information stored in the storage unit. A platform having an application program interface and generating a first object for each event;
An application that generates a second object for each event;
A software bus for communication between a first object generated in the platform and a second object generated in the application;
Storage means for storing storage information including first and second object reference information necessary for the first and second objects to refer to each other via the software bus;
Playback means for playing back an object necessary to continue processing an event in response to the disappearance of at least one of the first and second objects;
The first object reference information for referring to the first object is sent to the application, and the second object reference information for referring to the second object is sent to the platform. And a recovery means for exchanging the second object reference information between the platform and the application and then recovering the communication via the software bus using the saved information of the storage means. The software bus has a table for storing the first and second objects and the first and second object reference information in association with each other.
The system according to claim 4, wherein the recovery means includes means for re-registering object reference information of the reproduced object in the table. Switching means for switching the first cluster to the second cluster;
Means for reproducing the first and second objects existing in the first cluster in the second cluster;
The system of claim 4 or 5, and means for recovering the communication via the software bus in the first cluster, in the second cluster by using stored information of the storage means. A first object generated for each event by a platform having an application program interface and a second object generated by an application for each event communicate with each other via a software bus, and the object is processed in the system that processes the event. A program to manage,
A storage procedure for storing storage information including first and second object reference information necessary for the first and second objects to refer to each other via the software bus in a storage unit;
A playback step of playing back an object required to continue processing the event in response to the disappearance of at least one of the first and second objects;
The first object reference information for referring to the first object is sent to the application, and the second object reference information for referring to the second object is sent to the platform. For causing the computer to execute a restoration procedure for restoring the communication via the software bus using the saved information of the storage means after exchanging the second object reference information between the platform and the application. program. The software bus has a table for storing the first and second objects and the first and second object reference information in association with each other.
The program according to claim 7, wherein the restoration procedure includes a procedure of re-registering object reference information of the reproduced object in the table. A switching procedure for switching the first cluster to the second cluster;
Replaying the first and second objects existing in the first cluster in the second cluster;
The program according to claim 7, further comprising: a procedure for restoring communication in the first cluster in the second cluster using information stored in the storage unit via the software bus.

Images