Abstract: In accordance with various embodiments, a set of features are described for enabling an application server platform for telecom based applications. A system for providing an application server for telecom-based applications can include an application server that includes an event broker distributed across a cluster. The event broker can provide a distributed publish-subscribe mechanism that is a generic interface to all server nodes in the cluster. The event broker filters events with event attributes by way of matching criteria. Additionally, the event broker is used to dispatch events to specific listeners based on certain criteria.

Abstract: An application server is described for development of telecommunications-based software applications. The application server provides a protocol-neutral programming model for application developers. Rather than having to account for specific protocol entry points into the server, all interactions in the server are abstracted as asynchronous events through the event broker layer. State management and concurrency are implemented as an actor-based model, where each actor owns its own segment of state and other actors wishing to update that state send asynchronous events to the owner. Thus, any communication in the various protocols can be expressed as an asynchronous event passed to, from and between the actors, who are each responsible for maintaining their own segment of state locally.

Abstract: A plurality of service facades are used to expose the capabilities of an underlying telecommunications network in different ways. Each service façade provides a different interface to access a set of functions of the telecom network. The service facades can be accessed by client applications residing externally with respect to the telecom network. The client applications can invoke a particular service façade to send a message to the network and the invocations can be translated to the native protocols used by the resources in the telecom network to carry out the request. The service facades can be deployed on a service access gateway to the telecom network and can include a simple object access protocol (SOAP) façade, a representational state transfer (REST) façade, a service oriented architecture (SOA) façade and a native façade.

Abstract: Systems and methods are described for exposing the third party call control functionality of a telecom signaling network as a web services interface. An intelligent network application part (INAP) plug-in is used to provide the translation logic of simple web service interface calls received from a client application, into the lower-level signaling protocol invocations needed to provide the third party call functionality at the network level. The INAP plug-in is deployed in a service access gateway positioned between the telecommunications signaling-based network and a multitude of service provider applications that seek to access various functions in the network. By implementing the INAP plug-in, applications are provided with access to third party call control (3PCC) within the network, without the necessity of invoking low-level signaling needed to establish calls, terminate or cancel calls, as well as obtain various call information.

Abstract: A split deployment model is enabled for a telecommunication service access gateway. The services of the gateway are segregated into a set of core services that provide container-based functionality and a set of exposure services that enable network integration and translation of protocols. The core services are executed as part of the application server, while the exposure services are deployed in separate archive files. This isolation of services allows single or groups of services to be independently upgraded, patched or removed and reduces the impact of one service on others. Furthermore, the services can scale independently, allowing additional hardware resources to be added to a particular service. Multiple versions of a single service can also be deployed in a single cluster or server.

Abstract: A gateway is described that performs processing of communications by employing a series of service interceptors. The interceptors can be registered in the gateway by using a configuration file. Once registered, the interceptors can be invoked in a particular sequence for the requests coming into the gateway. Each interceptor can deny the request, allow the request, abstain from processing the request and pass the request to the next interceptor specified by the sequence. The interceptors can also modify the various data associated with the request. There can be dependencies between multiple interceptors. In addition, new custom interceptors can be created and registered at the gateway to process incoming requests.

Abstract: In accordance with various embodiments, a set of features are described for enabling an application server platform for telecom based applications. A system for providing an application server for telecom-based applications can include a computer, including a computer readable medium and processor. The system can also include an application server, executing on the computer. The application server can include an actor container that manages and provides lifecycle and runtime properties for application classes that are executed as actors in the application server. The actor container can manages a set of event transactions, wherein all storage operations are performed as part of the event transaction that spans each event handler invocation.

Abstract: In accordance with various embodiments, a set of features are described for enabling an application server platform for telecom based applications. A system for providing an application server for telecom-based applications can include an application server that includes an event broker distributed across a cluster. The event broker can provide a distributed publish-subscribe mechanism that is a generic interface to all server nodes in the cluster. The event broker filters events with event attributes by way of matching criteria. Additionally, the event broker is used to dispatch events to specific listeners based on certain criteria.

Abstract: An integrated software and hardware system is described that implements a unified lifecycle for the hardware and the software components therein. In the context of adding, removing or moving a hardware appliance, this allows the system to create, coordinate and manage a single lifecycle for each appliance together with its software processes, that is being moved or changed. The system includes a chassis with multiple enclosures for computing blades. Each blade in the chassis is assigned either a worker or bootstrap role. The worker blades perform the core processing of the service broker functionality and the bootstrap blades are used to provide the bootstrapping and administration of the worker blades. In particular, the administration features include an administration console that is provided by the bootstrap blade, which provides hardware management and process management.

Abstract: An integrated software and hardware system is described that functions as a communications service broker in a telecommunications (telecom) network environment. The system can be used to perform mediation and orchestration of services in the telecom network. The integrated system provides the ability of fully automated configuration and provisioning of a compute blade module based on its physical location (in a chassis enclosure). In accordance with an embodiment, each blade in the chassis is assigned either a worker or bootstrap role. The worker blades perform the core processing of the service broker functionality and the bootstrap blades are used to provide the bootstrapping and administration of the worker blades.

Abstract: An application server is described for development of telecommunications-based software applications. The application server provides a protocol-neutral programming model for application developers. Rather than having to account for specific protocol entry points into the server, all interactions in the server are abstracted as asynchronous events through the event broker layer. State management and concurrency are implemented as an actor-based model, where each actor owns its own segment of state and other actors wishing to update that state send asynchronous events to the owner. Thus, any communication in the various protocols can be expressed as an asynchronous event passed to, from and between the actors, who are each responsible for maintaining their own segment of state locally.

Abstract: Systems and methods are described for integrating a gateway in a telecom network environment with charging and payment functionality. The gateway is provided with three points of integration with charging and billing servers. These three points include a payment service, a charging data record listener and a credit control interceptor. The payment service provides an interface for client applications that reside outside of the telecom network to invoke a charging request, to translate the charging request and to relay it to the billing server. The charging data record listener listens for charging data records generated within the gateway and issues offline charging requests to the billing server upon detecting that a particular charging data record has been generated. The credit control interceptor intercepts requests in the communication traffic flowing through the gateway and initiates online charging requests to the billing server upon intercepting said requests.

Abstract: A plurality of service facades are used to expose the capabilities of an underlying telecommunications network in different ways. Each service façade provides a different interface to access a set of functions of the telecom network. The service facades can be accessed by client applications residing externally with respect to the telecom network. The client applications can invoke a particular service façade to send a message to the network and the invocations can be translated to the native protocols used by the resources in the telecom network to carry out the request. The service facades can be deployed on a service access gateway to the telecom network and can include a simple object access protocol (SOAP) façade, a representational state transfer (REST) façade, a service oriented architecture (SOA) façade and a native façade.

Abstract: Systems and methods are described for providing a gateway that enables cloud-based service exposure. The gateway can allow a particular operator to expose its services and to control, manage and monetize the communication traffic that accesses these services. In accordance with one use case, the gateway can be utilized to expose the services of a Web based application to other external service providers and applications and to manage, control and monetize the requests received from the external providers to the exposed service. In accordance with another use case, the gateway can be utilized to expose the excess capacity of a telecom network, such as a code division multiple access (CDMA) network or a global system for mobile communications (GSM) network and to manage the access to the exposed capacity of the network.

Abstract: A network service access gateway is described that provides a pluggable state management architecture for storing state information. The gateway typically processes requests between entities such as external applications and subscriber mobile devices. In processing data, the gateway can implement multiple storage providers which are selected according to the data access requirements of the specific request. Each storage provider can implement a different caching or data management technique in order to provide access to the required information. Examples of the storage providers include in-memory only caches, write-through disk based storage provider, write-behind disk based storage provider and non-cached disk-based storage provider. The particular storage provider can be selected based on a configuration file and according to the traffic path associated with the request.

Abstract: A gateway is described that performs processing of communications by employing a series of service interceptors. The interceptors can be registered in the gateway by using a configuration file. Once registered, the interceptors can be invoked in a particular sequence for the requests coming into the gateway. Each interceptor can deny the request, allow the request, abstain from processing the request and pass the request to the next interceptor specified by the sequence. The interceptors can also modify the various data associated with the request. There can be dependencies between multiple interceptors. In addition, new custom interceptors can be created and registered at the gateway to process incoming requests.

Abstract: A subscriber network can provide services. External applications can use the services on the subscriber network. A service access gateway can control application access to services of the subscriber network. The service access gateway can filter requests from an external application to access services on the subscriber network based on the customer for which the external application is accessing the service.

Abstract: A production upgrade is described for a multiprotocol gateway. This upgrade allows various modules and components within the gateway to be upgraded independently without impacting traffic flow in the gateway. The upgrade can be performed by deploying a new version of the module alongside an older version of the same module. New client requests can then be directed to the new version, while requests requiring the older module can be continued to be serviced by the prior version. A distinction is made between stateless and stateful conversation during the upgrade of various components. For stateful conversations, request traffic can be versioned according to the session to which each request belongs. A highly available state storage scheme allows new versions of the module to consume state information used by the older versions. For stateless conversations, all new requests can be immediately routed to the new version of the module.

Abstract: Systems and methods are described for exposing the third party call control functionality of a telecom signaling network as a web services interface. An intelligent network application part (INAP) plug-in is used to provide the translation logic of simple web service interface calls received from a client application, into the lower-level signaling protocol invocations needed to provide the third party call functionality at the network level. The INAP plug-in is deployed in a service access gateway positioned between the telecommunications signaling-based network and a multitude of service provider applications that seek to access various functions in the network. By implementing the INAP plug-in, applications are provided with access to third party call control (3PCC) within the network, without the necessity of invoking low-level signaling needed to establish calls, terminate or cancel calls, as well as obtain various call information.

Abstract: A split deployment model is enabled for a telecommunication service access gateway. The services of the gateway are segregated into a set of core services that provide container-based functionality and a set of exposure services that enable network integration and translation of protocols. The core services are executed as part of the application server, while the exposure services are deployed in separate archive files. This isolation of services allows single or groups of services to be independently upgraded, patched or removed and reduces the impact of one service on others. Furthermore, the services can scale independently, allowing additional hardware resources to be added to a particular service. Multiple versions of a single service can also be deployed in a single cluster or server.