Object-oriented encapsulation of a telecommunications service protocol interface

[0002] The present invention relates to client server communications interfaces and, in particular, to a communications interface between servers and service application programs running on a transaction server computer.

[0003] Telecommunications networks use computer platforms, called network intelligent platforms (“NIP”), to provide enhanced telephone services such as toll-free 800 call routing and virtual private network call routing. A telephone call originates in a local exchange carrier (“LEC”) network and propagates from the LEC network to a switch, such as an originating switch or a terminating switch. For example, the originating switch processes the telephone call and routes the call to its destination. The destination may be in a different LEC or in a different type of telecommunications network, including a public switch telephone network (“PSTN”). The originating switch determines when processing for enhanced services is required for a telephone call. When processing for enhanced services is required, the originating switch opens a dialogue with a NIP, exchanging with the NIP higher-level protocol messages embedded within lower-level SS7 protocol messages. Signaling System No. 7 (“SS7”), is a well known dialogue-based communications protocol that may be used for communications with computing platforms such as the NIP. The data exchanged using the SS7 protocol interface between an originating switch and a NIP is commonly formatted into intelligent network application protocol (“INAP”) messages. At the end of the exchange of INAP messages that comprises a dialogue between an originating switch and a NIP, the NIP directs the originating switch to connect the telephone call to a final destination. In the event of an error, the originating switch will be directed to terminate the call. The exchange of INAP messages between originating switches and NIPs constitutes a telecommunications service protocol interface, the INAP protocol interface, implemented on top of the lower-level SS7 protocol interface.

[0004] A NIP contains several computers known as transaction servers. Transaction servers simultaneously execute two types of software programs. The first type of program is a Transactions Capability Application Part (“TCAP”) server that receives messages from originating switches and that sends response messages back to the originating switches. A TCAP server extracts INAP messages from the SS7 protocol messages that the TCAP server receives from originating switches and forwards the INAP messages to service application programs, the second type of software program that runs on transaction servers. Service application programs process enhanced service requests from originating switches and communicate with the originating switch by exchanging INAP messages. Service application programs send response INAP messages back to TCAP servers which, in turn, direct the response messages back to the originating switches.

[0005] Service application programs must include specialized communications software for handling the exchange of INAP messages through the INAP protocol interface. In particular, this specialized communications software must keep track of the originating switch that sent an incoming message as well as the TCAP server through which the incoming message passed so that responses to the incoming message can be returned to the same originating switch that sent the incoming message through the same TCAP server through which the incoming message passed. The specialized communications software must also maintain state information about each separate dialogue that is conducted between an originating switch and a service application. A dialogue can extend over the exchange of many different INAP messages. In addition to the INAP messages, Integrated Services Digital Network (“ISDN”) user part (“ISUP”) messages may also be embedded within SS7 protocol messages. The specialized communications software included in service applications must therefore detect ISUP messages and handle them as well. The specialized communications software must handle the different encoding and decoding schemes used for the data included in INAP messages and must process many separate fields within the INAP message header contained in a typical INAP message. The specialized communications software must also maintain detailed configuration information about the particular transaction server on which the service application is running.

[0006] When a new service application program is developed, the specialized communication software is generally written specifically for the new service application program. When the configuration of the transaction server is changed or modified, the specialized communications software of each service application program that runs on that transaction server must correspondingly be modified to include updated configuration information that the specialized communications software uses to route messages to and from NIP. As a result, the maintenance of existing service applications and the creation of new service applications are often costly and complicated tasks. A need has therefore been recognized for abstracting the communications interface between TCAP servers and service applications so that the service applications need not themselves include specialized communications software.

[0007] The present invention provides an abstract, object-oriented encapsulation of the communications interface between intermediary, lower-level protocol handlers, such as TCAP servers, and higher-level telecommunications service providers, such as the service application programs that run on transaction server computers within an enhanced services platform, such as a NIP. A TCAP server receives a TCAP message that includes a request INAP message from a telephone network switch seeking an enhanced service provided by the NIP. The request INAP message includes a request type and request data. The TCAP server extracts the request INAP message from the TCAP message and encapsulates the request INAP message in a message encapsulation interface object. The TCAP server then passes the message encapsulation interface object to a service application program by calling a transfer method of an object transfer interface object within the TCAP server. The service application program receives the message encapsulation interface object by calling a transfer method of an object transfer interface object within the service application program. The service application program then obtains the type and request data from the message encapsulation interface object by calling methods of the message encapsulation interface object.

[0008] The abstract, object-oriented communications interface of the present invention greatly simplifies the development and maintenance of service application programs. The specialized INAP communications handlers that were formerly developed for each different service application program can now be replaced by including in each service application program the library routines of the abstract, object-oriented communications interface of the present invention.

[0009] FIG. 1 displays the network architecture of a NIP.

[0010] FIG. 2 displays the NIP network architecture in parallel with the nested communications protocols that are received and transmitted by each component of the NIP.

[0011] FIG. 3 displays several example INAP message dialogues between an originating switch and a service application program.

[0012] FIG. 4 displays the internal message transfer architecture of a transaction server.

[0013] FIG. 5 displays a simple flow control diagram for the IDP message handling function of a TCAP server.

[0014] FIG. 6 displays a simple flow control diagram for a service application message handler.

[0015] FIG. 7 displays a TCAP server response message handler.

[0016] FIG. 8 illustrates an exemplary layout of an INAP message in the message buffer when an INAP_Operation object is sent between the TCAP server and the service application program through the INAP_Interface.

[0017] FIG. 9 illustrates an exemplary Connect Encapsulated INAP message.

[0018] The present invention provides an abstract, object-oriented encapsulation of the communications interface between intermediary, lower-level protocol handlers, such as TCAP servers and higher-level telecommunication service providers, such as service application programs running on transaction server computers within an enhanced services platform, such as a NIP. The abstract interface of the present invention is implemented as a set of software library routines that are called by TCAP servers and service application programs. The library routines of the abstract interface provide a few simple object-oriented methods to TCAP servers and service application programs that enable them to exchange information contained in underlying INAP messages. The library routines of the abstract interface handle the complex INAP protocol management functions that were previously implemented as specialized communications software within TCAP servers and service applications. The abstract interface of the present invention greatly simplifies the development of new service applications and the maintenance of existing service applications by centralizing INAP protocol management into a set of library routines commonly shared by TCAP servers and service application programs.

[0019] The abstract interface of the present invention is preferably implemented as a set of C++ interface objects. These interface objects encapsulate INAP messages and generally include all additional information needed to direct the FNAP messages to their destinations within the context of a dialogue between an originating switch and a service application program. These interface objects present a very simple set of C++ methods that can be called by TCAP servers and service application programs to receive encapsulated INAP messages from message queues associated with the TCAP servers and service application programs and to direct encapsulated INAP messages to the message queues associated with destination processes. Thus, rather than explicitly handling the INAP protocol interface, TCAP servers and service application programs instead pass C++ interface objects back and forth through an abstract interface. The abstract interface represents a new, higher-lever, simplified communications protocol.

[0020] FIG. 1 displays the network architecture of a NIP, the framework on which the present invention is implemented. The NIP 101 is connected through SS7 communications links 102 to a number of originating switches 103-108 that receive incoming telephone calls from LEC networks. The topology of the network connections between the originating switches and the NIP can be quite complex, involving many intermediate level signal transfer points not shown in FIG. 1. The NIP includes one or more communications servers 109-110 that perform protocol and message format translations on incoming SS7 messages, when necessary, and direct the incoming messages through a FDDI local area network (“LAN”) 111 to a number of transaction server computers 112-115. A Fiber Distributed Data Interface or FDDI, is a transmission protocol developed for fiber-optic LANs. The transaction server computers 112-115 process requests for enhanced services embodied in the messages passed to them by the communications servers 109-110 and respond to those messages by sending responses back through the FDDI LAN 111 to the communications server computers. The communications server computers then transmit the responses embedded in SS7 protocol messages back to the originating switches.

[0021] FIG. 2 displays the NIP network architecture in parallel with an indication of the nested communications protocols that are received and transmitted by each component of the NIP. The originating switch 201 packages a request for enhanced services into an INAP message 202. The originating switch packages the INAP message within a TCAP message 203 which is, in turn, embedded within messages of a number of additional protocol levels 204-207. Each protocol level requires a separate message header to be appended to the message of the next lowest protocol layer. The entire nested collection of protocol layer headers and the request data constitutes a single SS7 protocol message.

[0022] The originating switch transmits a request for enhanced services within the SS7 protocol message to a communications server computer 208 within NIP 209. The communications server computer processes the received SS7 protocol message 210 and extracts from it a TCAP message 211 which it transmits to the transaction server computer 212. Note that the TCAP message 211 has only two protocol layers, the underlying INAP protocol layer 213 and the enclosing TCAP protocol layer 214. The TCAP server 215 running on the transaction server receives the TCAP message, extracts the INAP message 216 from the TCAP message and forwards the INAP message to a service application program 217.

[0023] One way to consider the communications interfaces displayed in FIG. 2 is that an originating switch communicates with a specific service application program using the INAP protocol interface. The remaining protocol layers of a SS7 message are used to direct an INAP message through the various communications interfaces intervening between the originating switch and the service application program.

[0024] FIG. 3 displays example dialogues between an originating switch and a service application program. The originating switch 301, in handling an incoming telephone call, determines that it must seek enhanced services provided by service application program 302 running on a NIP. Two simple unrelated dialogues 303 and 304 are shown in FIG. 3.

[0025] The first dialogue 303 represents a request by the switch to translate a destination 800 number into a physical routing address. The originating switch initiates the dialogue by sending an initial detection point (“IDP”) message to the service application program 305. This IDP message represents a single INAP operation. The message includes the 800 number to be translated and an indication of the specific translation service that the originating switch is requesting. The service application program receives the request, looks up the 800 number in a database to find a physical routing address that corresponds to the 800 number, formats the physical routing address into an INAP response message, and sends the response message 306 back to the originating switch. In this case, the response message is an INAP Connect message that includes the physical routing address to which the switch should connect the incoming call. The INAP Connect message thus terminates the dialogue between the originating switch and the service application program.

[0026] The next dialogue 304 displayed in FIG. 3 is somewhat more complicated. This dialogue represents a request by the originating switch to route a telephone call to a voice server that plays an announcement to the caller and then, following completion of the announcement, to route the telephone call to a final destination. Again, the originating switch initiates the dialogue with an IDP message 307. The IDP message represents an INAP operation that requests routing of the telephone call to a voice server. The service application first replies with a FurnishCharginglnformation message 308 that directs the originating switch to add billing information included in the FurnishCharginglnformation message to a tabulation of the total charges for the telephone call maintained by the originating switch. The service application then sends to the originating switch an EstablishTemporaryConnection message 309 which directs the originating switch to route the telephone call temporarily to a specific voice server. The voice server then plays a recorded announcement 310. When the announcement is finished, the service application program directs the originating switch to disconnect the telephone call from the voice server by sending to the originating switch a DisconnectForwardConnection message 311. Then the service application program sends to the originating switch a FurnishChargingInfornation message 312 that causes the originating switch to further increment the tabulation of charges for the telephone call. The service application program then sends a SendChargingInformation message 313 to the originating switch. This SendChargingInformation message directs the originating switch to complete its tabulation of the charges for the call and send the tabulation to a downstream processing system. Finally, the service application program sends a Connect message 314 which directs the originating switch to connect the telephone call to a final physical routing address. The Connect message ends the dialogue between the originating switch and the service application program.

[0027] It should be noted that the INAP messages exchanged between an originating switch and a service application program during a dialogue do not necessarily fall into a strict request/response sequence. As shown in the second dialogue 304 of FIG. 3, the service application program may send several discrete INAP messages back to the originating switch without an intervening response from the originating switch. Much of the complexity of the specialized communications software that is included in service application programs arises from the complexity and variety of dialogues that may occur between an originating switch and the service application program. State information is saved by the specialized communications software for each concurrent dialogue being conducted by the service application program with all connected originating switches. Many different discrete pieces of information must be stored and maintained over the course of the dialogue by the service application program. Finally, the specialized communications software must keep track of routing information for each dialogue to ensure that individual FNAP messages are directed to the appropriate originating switch.

[0028] FIG. 4 displays the internal messaging architecture of a NIP transaction server. The transaction server is generally a midrange computer that runs one or more TCAP server processes 401-402 and a number of instances of service application programs 403-407. For a given service application program, the transaction server may instantiate one or more separate running processes. In the example shown in FIG. 4, for example, service application program instances 403 and 404 correspond to service application program 420, service application program instance 405 corresponds to service application program 421, and service application program instances 406 and 407 correspond to service application program 422. There is a single message queue 408-410 associated with each service application program. Message queue 408 is associated with the service application program 420, message queue 409 is associated with service application program 421, and message queue 410 is associated with service application program 422. There is a single message queue 411-412 associated with each TCAP server process.

[0029] The abstract, object-oriented communications interface of the present invention, referred to below as the INAP interface, is a set of library routines that are shared by both TCAP server processes and by instances of service application programs. Accordingly, in FIG. 4, an INAP interface component 415-419 is included in each instance of the service application program and an INAP interface component 415-419 is included in each TCAP server process. A TCAP server sends a high-level interface object to an instance of a target service application program by calling INAP interface routines that direct the interface object to the appropriate message queue associated with the target service application program. Thus, TCAP server 401 may send an interface object through INAP interface 413 to message queue 408. The target service application program instance can then acquire the interface object by calling INAP interface routines to remove the interface object from message queue 408. In similar fashion, a service application program instance can send a reply interface object back to a TCAP server by calling INAP interface functions to place the interface object into the appropriate message queue associated with that TCAP server.

[0030] Embedded in each interface object exchanged through the abstract communications interface of the present invention is a standard INAP message along with additional information required by the abstract communications interface to keep track of the message within the context of an ongoing dialogue between an originating switch and a service application program and routing information that allows subroutines of the INAP interface to direct the message to a message queue of a service application program or a TCAP server. Class definitions 1-7 below display simple C++ class definitions of seven interface objects, including the INAP_Context object, the INAP_Operation object, the INAP_InterfaceData object, the Network_ContextID object, the Service_ContextID object, the INAP_Interface object, and the CommsChannel object. In this application, indented text of a different font corresponds to pseudocode or exemplary code.

[0031] The INAP_Context object includes information used by the INAP interface to direct INAP operation objects that include TNAP messages to the appropriate TCAP server or service application program. This information includes an identifier for the TCAP server.

[0032] The INAP_Operation object includes data that provides a reference to an INAP_InterfaceData instance. A clean( ) function serves as a virtual function for initializing all types of INAP Operation data. A setOperationType( ) function sets the INAP Operation type. A setOperationData( ) function initializes the INAP Operation data. A setNetwork_ContextID( ) function provides methods for setting the Network_Context in the INAP_InterfaceData. A getOperation( ) function provides a method for retrieving the INAP_InterfaceData instance. A getSize( ) function provides methods for retrieving INAP Operation data size. A getOperationType( ) function provides methods for retrieving the INAP Operation type. A getOperationData( ) function provides methods for retrieving the INAP Operation. A getNetwork_ContextID( ) function provides methods for retrieving the Network ContextID. A getService_ContextID( ) function provides methods for retrieving the Service ContextID.

[0033] Within the INAP_InterfaceData object, freeList provides network re-usable memory for a new INAP Operation. NumDataBuffers provides the number of previously allocated memory for INAP Operations. NetworkId provides a pointer to the call context in the TCAP Server. ServiceId provides a pointer to the call context in the service application program. OperationType provides the INAP Operation type, and operation provides the INAP Operation.

[0034] In the INAP_InterfaceData object, the getSize( ) function provides methods for retrieving the message size of INAP Operation class object. The getMaxSize( ) function provides methods for retrieving the maximum size of an INAP Operation object. The new( ) function is an operator overload function that re-uses the memory allocated earlier from another INAP Operation. The deletes function is an operator overload function that puts the pointer to the memory of an INAP Operation to the free list for re-use.

[0035] In the Network_ContextID object, serverId provides an identification for the TCAP Server that passes the INAP operations of a call between the originating switch and the service application. Reference provides a TCAP message correlation id of a call context. The iNAP_Id provides a pointer to the call context in the TCAP Server. The tcsPid provides the TCAP Server process ID. Combining reuseCount and tcsPid ensures that the INAP Operation received from the service application belongs to the call context in memory.

[0036] In the Network_ContextID object, the setReference( ) function provides methods for setting reference data. The setINAP_Id( ) function provides methods for setting iNAP_Id data. The setServerId( ) function provides methods for setting the serverId data. The setTCS_Pid( ) function provides methods for setting the tcsPid data. The setReuseCount( ) function provides methods for setting reuseCount data. The getReference( ) function provides methods for getting reference data. The getINAP_Id( ) function provides methods for retrieving iNAP_Id data. The getServerId( ) function provides methods for getting serverId data. The getTCS_Pid( ) function provides methods for retrieving tcsPid data. The getReuseCount( ) function provides methods for retrieving reuseCount data.

[0037] In the Service_ContextlD object, the serverId provides the service plication program server ID. The p_CallContextIndex provides a pointer to the service application program context. The p_valid provides a flag that indicates if the context will still be valid.

[0038] In the Service_ContextID object, the setServerId( ) function provides methods for setting the server ID. The getServerId( ) function provides methods for retrieving the server ID. The setCallContextIndex( ) function provides methods for ting the value of p_CallContextIndex. The getCallContextIndex( ) function provides methods for retrieving the value of p_CallContextIndex. The setValid( ) function provides methods for setting the value of p_valid. The is valid( ) function returns a value of true when the value of p_valid is “true.”

[0039] The INAP_Interface object channel is a common interface to the NIP common channels and application protocols. MyServerId identifies the message queue of the application program. The function sendOp( ) transmits an INAP Operation message to its destination. The getOp( ) function receives an INAP Operation message. The isNearlyFull( ) function determines if its upstream message queue is nearly full. The isAlive( ) function provides methods for checking if the remote application is up and running. The getMyServerID( ) function provides methods for retrieving myServerId.

[0040] In the CommsChannel object, the sendBuffer( ) function provides methods for sending a message to the message queue. The getBuffer( ) function provides methods for receiving a message from the message queue. The isNearlyFull( ) function checks if the outgoing message queue is nearly full. The isAlive( ) function provides methods for determining if any TCAP server is running. The getServerID( ) function retrieves the process server ID. The rereadConfig( ) function re-reads the configuration values from the config file.

[0041] An INAP_Context object is associated with each INAP_Operation object passed through the INAP interface from a TCAP server to a service application program or from a service application program to a TCAP server. The INAP_Context object and INAP operation object together abstract an INAP protocol message.

[0042] The INAP_Operation object is a base class object from which specific INAP operations are derived. There is a derived INAP_Operation object that represents each INAP operation. The INAP_Operation object includes only methods. The data corresponding to an INAP message is stored in an INAP_InterfaceData object that is associated with an INAP_Operation object. The INAP_Operation object includes methods that allow a service application program or a TCAP server to obtain the type of the INAP operation represented by an INAP_Operation object and to get the contents of the INAP message represented by an INAP_Operation object. The INAP_Operation object further includes methods that allow a service application program or TCAP server to associate a specific INAP_Context object with the INAP_Operation object.

[0043] An INAP_Operation object has a reference to an INAP_InterfaceData instance. The INAP_InterfaceData object holds the data of an INAP message encapsulated by an INAP_Operation object. The access functions in the INAP Operation classes allow the service application program to retrieve or set the data in its INAP_InterfaceData instance. The disassociation of the data from an INAP_Operation object facilitates passing INAP_Operation objects between processes via InterProcess Communication Protocols. The INAP_InterfaceData class also maintains a static list of pointers to the used INAP_InterfaceData instances for memory reuse. After an INAP Operation message is sent to its destination, the pointer to the memory for its INAP_InterfaceData is added to the list for re-use. When an INAP Operation object is instantiated, the list of used memory addresses is checked first to determine if there is one available. When no used memory addresses are available according to the list, memory for the INAP_InterfaceData instance will only then be allocated. The INAP_InterfaceData objects may be reused by a service application program, allowing the service application program to avoid the overhead of allocating memory for each new INAP_Operation that it receives from the TCAP Server. An INAP_InterfaceData object has an inap_ops object which holds the encapsulated INAP message. An INAP_InterfaceData object also has a Network_ContextID object, and a Service_ContextID object. The Network_ContextID object holds the address of the call context data in the TCAP Server. The Service_ContextID object holds the address of the call context data in the service application program. Passing only the addresses of call contexts eliminates the need for data to be passed between the TCAP Server and the service application program. The combined information of the reuse count and the TCAP Server process Id in the Network_ContextID object ascertains that the INAP Operation message received from the service application program belongs to the same dialogue stored in the call context by the TCAP Server. The INAP_Interface is an object that transmits messages between the TCAP Server and the service application program. A CommsChannel object encapsulates the InterProcess Communication Protocols. The CommsChannel is a virtual class and is inherited by classes of different protocols.

[0044] The INAP_Interface object represents the INAP interface used by TCAP servers and service application programs to pass INAP_Operation objects back and forth through the INAP interface. The INAP_Interface object essentially encapsulates the abstract communications interface of the present invention. The INAP_Interface objects contains a few simple methods. The method sendOp allows one process to send an INAP_Operation object to another. The method getOp allows a process to receive an INAP_Operation object that had been queued to a message queue associated with the process. There are, in addition, three methods that specify direct communications between a TCAP server and a service application program rather than communication between a service application program and an originating switch via a TCAP server. The method in abortCallContext allows a TCAP server to notify a service application program that the dialogue between that service application program and an originating switch will be terminated by the TCAP server. Such termination may be undertaken by the TCAP server in response to a timeout arising from interruption of the physical links between the TCAP server and the originating switch. A service application program can indicate to the TCAP server that is ready to receive interface objects by calling the enableCallReceipt method, and can likewise indicate to the TCAP server that it is no longer available to receive interface objects by calling the method disableCallReceipts.

[0045] Simple inclusion of header files that specify the above discussed interface objects and the library routines that correspond to the methods provided by those objects allows a service application program to communicate with a TCAP server without the need for specialized communications software. The library routines of the INAP interface use the data included in the various interface objects to handle all INAP protocol details, including routing of INAP messages to appropriate targets and associating INAP messages to the context of a dialogue between an originating switch and a service application program.

[0046] FIG. 5 displays a simple flow control diagram for the IDP message handling function of a TCAP server. In step 501, the TCAP server receives a TCAP protocol message from an originating switch and extracts the INAP message included within it. In step 502, the TCAP server instantiates an INAP_InterfaceData object. The INAP_InterfaceData object has an inap_ops object which holds the encapsulated INAP message. The INAP_InterfaceData object also has a Network_ContextID object and a Service_ContextID object that store the context information used to associate additional INAP messages to a dialogue between an originating switch and a service application program. In step 503, the TCAP server uses the INAP_InterfaceData object to instantiate an INAP_Operation object to encapsulate the received INAP Message. Finally, in step 504, the TCAP Server calls the INAP_Interface sendOp method to send the instantiated INAP_Operation object to the appropriate service application program. Each type of enhanced service request has an associated service application program.

[0047] The INAP_Interface routes a given INAP_Operation object to the appropriate service application program using the type of INAP operation represented by the INAP_Operation object. A single service application program handles each possible INAP operation. The INAP_Interface object maintains configuration information about the InterProcess Communication facility that it uses, along with information contained in an INAP_Operation object, to determine to which message queue to direct a particular INAP_Operation object in response to an INAP_Interface sendOp method call.

[0048] FIG. 6 displays a simple flow control diagram for a service application message handler. This handler receives INAP_Operation objects from TCAP servers, executes the INAP operations request represented by those INAP_Operation objects, and returns INAP response messages through TCAP servers back to the appropriate originating switches. In step 601, the service application handler calls the INAP_Interface getOp method to retrieve the next INAP_Operation queued to the message queue associated with the service application program. The service application handler determines, in step 602, whether the INAP_Interface getOp method call has in fact returned a new INAP_Operation object. If so, control proceeds to step 603. Otherwise, the service application handler returns. The service application handler is called or awakened in response to the queuing of a new INAP_Operation object to the service application program's message queue by the INAP interface. The service application program may instead quiesce for a certain period of time and then again test for the receipt of INAP_Operation objects. When a new INAP_Operation object has been retrieved, the service application handler, in step 603, instantiates a INAP_InterfaceData object or reuses an existing INAP_InterfaceData object to include the data of the INAP message represented by the received INAP_Operation object. In step 604, the service application handler processes the request represented by the received INAP_Operation object. The service application handler calls INAP_Operation object methods to retrieve the type of the request and the contents of the request from the INAP_Operation object in order to process the request. Once the request is processed, the service application handler instantiates, in step 605, an INAP_Operation object to contain the response to the processed request. In step 606, the service application message handler calls the INAP_Interface sendOp method to send the instantiated INAP_Operation object back through the TCAP server to the originating switch.

[0049] FIG. 7 displays a TCAP server response message handler. This handler receives responses from service application programs and passes those responses back to originating switches. In step 701, the INAP response handler calls the INAP_Interface getOp method to retrieve the next response queued to the message queue associated with the TCAP server. If no response has been queued, as detected in step 702, the INAP response handler returns. Alternately, the INAP response handler could quiesce and then again test for any received response messages. In step 703, the INAP response handler packages a response INAP message included within a INAP_Operation object retrieved from the message queue associated with the TCAP server into a SS7 protocol message. In step 704, the INAP response handler sends the SS7 protocol message to the appropriate originating switch via a communications server running on the same NIP.

[0050] FIG. 8 provides an exemplary layout for an INAP message in the message buffer when an INAP_Operation object is sent in between the TCAP Server and the service application program through the INAP_Interface. The actual INAP message is buried in part of Encapsulated INAP Message 801. An example of a type Connect Encapsulated INAP message is shown in FIG. 9. The data in the message buffer is actually the entire INAP_InterfaceData object. After using the INAP_Operation functions to construct an INAP_Operation object, the TCAP server uses the INAP_Interface::sendOp( ) function to send the INAP_InterfaceData object contained in the INAP_Operation object. On the other side, the service application program simply calls the INAP_Interface::getOp( ) function to receive the INAP Message, such as the Encapsulated INAP Message 801 shown in FIG. 8. The INAP Operation message type may be retrieved by one of the INAP_Operation access functions. With a known INAP Operation type, an INAP Operation is instantiated with the existing INAP_InterfaceData encapsulating the INAP message. All INAP Operation member attributes of a specific INAP Operation type can be retrieved and manipulated by using its access functions. Without the uses of INAP_Interface and INAP_Operation classes, the service application program will need to know every detail of the data structure and message layout of each INAP message type in order to retrieve or manipulate any field in the INAP message received from the message queue. The following example pseudocode illustrates a service application program's response to an Initial Detection Point INAP message with a Connect INAP message without the use of INAP_Interface and INAP_Operation classes. The service application program takes the Calling Party Number in the InitialDP and puts it in the Destination Routing Address in the responding Connect INAP message.

[0051] This same program may be rewritten to use the INAP_Interface and INAP_Operation classes.

[0052] The INAP_Interface class allows the service application program to send and receive INAP message objects to the TCAP Server without knowledge of the transmitting mechanism. By using the INAP_Operation class, the service application program does not need to know about the data structure or field names of any INAP message type to retrieve or manipulate data fields in an INAP message. The INAP_Interface object has a CommsChannel instance. The CommsChannel is a pure virtual class, which is a base class derived by all interprocess communication classes. This class holds no member attributes, all data needed for routing and configuration information are found only in its derived classes. When any function from the CommsChannel class is invoked, the polymorphic function from the transmitting type class is the one actually invoked. The service application program will be automatically configured to use the same interprocess communication protocol used by the TCAP server without knowledge about the protocol. When an INAP message is sent to the service application program, the TCAP server's server ID is contained in its Network-ContextID. In responding to the message, the service application program simply calls the sendOp( ) function, which routes the message back to the originating TCAP server according to the server ID.

[0053] Although the present invention has been described in terms of one embodiment, it is not intended that the invention be limited to this embodiment. Modifications within the spirit of the invention would be apparent to those skilled in the art. For example, many different encapsulation techniques could be devised in order to abstract the INAP protocol interface. Different schemes might use a number of different base interface object types and different derivation hierarchies. Protocols other than the INAP protocol may be abstracted, and underlying lower-level protocols other than the SS7 protocol might be employed to transfer data between originating switches and NIPs. A different allotment of protocol handling tasks may be made to the various components of the NIP, including the intermediary, lover-level protocol handlers and the service providers. The scope of the present invention is defined by the claims that follow.