Abstract: The session-based server deployment can be comprised of an engine tier that is designed for high throughput processing of communications and a state tier that maintains state information for access by the engine tier. The engine tier can include a plurality of engine nodes that process incoming messages. The state nodes can contain call state, including various timers. When processing a call, an engine can set various timers in the state tier. Upon expiration of a timer, the state node can transmit a notification assigning the timer to the corresponding engine node which handled previous communications for the call. This affinity between the timer and its respective engine can provide numerous benefits, such as reduced latency and more localized data access.

Abstract: Described herein are systems and methods for managing nodes in a data grid from within an application server. The system includes an application server having an administrative user interface, and a data grid including a plurality of nodes operating as a cluster, wherein each node in the data grid has node attributes that define node functionality. A configuration repository provided by the application server is accessible to the administrative user interface, and stores configuration information used by the administrative user interface to directly manage the plurality of nodes in the data grid. Upon receiving interpreted configuration information from the application server at a node manager client on the application server, the node manager client modifies the operation of the plurality of nodes in the data grid by overriding node attributes according to the interpreted configuration information, wherein the plurality of nodes thereafter operate according to the configuration information.

Abstract: Described herein are systems and methods for providing a software application executing on an application server direct access to at least one of a distributed data or distributed service provided by a data grid. The system includes an application server having software applications executing thereon, and a data grid including a plurality of nodes, wherein each of the plurality of nodes is adapted to provide at least one of a distributed data or distributed service. A resource configuration specified by one of a resource annotation added in the software applications or a resource reference defined in a deployment descriptor of said software applications is provided. Upon deployment of the software applications, the resource configuration is used by the system to provide the software applications direct access the distributed data and the distributed services provided by the data grid.

Abstract: Described herein are systems and methods for managing nodes in a data grid from within an application server. The system includes an application server having an administrative user interface, and a data grid including a plurality of nodes operating as a cluster, wherein each node in the data grid has node attributes that define node functionality. A configuration repository provided by the application server is accessible to the administrative user interface, and stores configuration information used by the administrative user interface to directly manage the plurality of nodes in the data grid. Upon receiving interpreted configuration information from the application server at a node manager client on the application server, the node manager client modifies the operation of the plurality of nodes in the data grid by overriding node attributes according to the interpreted configuration information, wherein the plurality of nodes thereafter operate according to the configuration information.

Abstract: Described herein are systems and methods for providing a software application executing on an application server direct access to at least one of a distributed data or distributed service provided by a data grid. The system includes an application server having software applications executing thereon, and a data grid including a plurality of nodes, wherein each of the plurality of nodes is adapted to provide at least one of a distributed data or distributed service. A resource configuration specified by one of a resource annotation added in the software applications or a resource reference defined in a deployment descriptor of said software applications is provided. Upon deployment of the software applications, the resource configuration is used by the system to provide the software applications direct access the distributed data and the distributed services provided by the data grid.

Abstract: A SIP server can be distributed over a cluster network and handle the processing of various SIP communications. A Diameter protocol web application can be deployed on the engine tier of the SIP server for enabling communication between the SIP server and an HSS. A profile service API can be provided that allows applications running on the SIP server to access user profile data stored on the HSS. The applications can also be allowed to subscribe to notifications about changes to the user profile data on the HSS. An Sh interface provider can be deployed on the SIP server for generating and responding to Diameter command codes. SIP servlets can access the user profile data in the form of an XML document.

Abstract: The session-based server deployment is comprised of an engine tier that is designed for high throughput processing of communications and a state tier that maintains state information for access by the engine tier. The engine tier includes a plurality of engine nodes that process incoming messages. The state nodes contain call state, including various timers. When processing a call, an engine sets various timers in the state tier. The engine then periodically polls the state tier for any timers that have expired. Upon expiration of a timer, the timer is assigned to the corresponding engine node which handled previous communications for the call. This affinity between the timer and its respective engine provides numerous benefits, including reduced latency and more localized data access.

Abstract: The SIP server can be comprised of an engine tier and a state tier distributed on a cluster network environment. The engine tier can send, receive and process various messages. The state tier can maintain in-memory state data associated with various SIP sessions. A near cache can be residing on the engine tier in order to maintain a local copy of a portion of the state data contained in the state tier. Various engines in the engine tier can determine whether the near cache contains a current version of the state needed to process a message before retrieving the state data from the state tier. Accessing the state from the near cache can save on various latency costs such as serialization, transport and deserialization of state to and from the state tier. Furthermore, the near cache and JVM can be tuned to further improve performance of the SIP server.

Abstract: A SIP server can be deployed in a two-tier architecture, including an engine tier for processing of SIP communications and a state tier for maintaining the state associated with these communications. The state tier can include RAM-based replicas that provide data to the engines. Some of the SIP session state can be moved to the database in order to reduce the memory requirements of the state tier. Upon determining that a transaction boundary has been reached where the session state is steady, the state replica can save the data to the database. A hint can be received from the engine tier by the state replica indicating that the state data is ready to be saved. Subsequently, the data can be removed from the state tier by nulling out the bytes of actual data, while preserving the primary key, locking and timer information so as not to impact latency.

Abstract: Systems and methods are provided for improving latency during message processing in a network environment via the use of SIP server architecture. The SIP server can be comprised of an engine tier and a state tier distributed on a cluster network. The engine tier can send and receive messages and execute various processes. The state tier can maintain in-memory state data associated with various SIP sessions. The state tier can store various long lived data objects and the engine tier can contain short lived data objects. The state data can be maintained in partitions comprised of state replicas. When processing messages, the engine can pull state data objects from the state tier, use the objects and push them back to the state tier after processing is complete. If one state replica is unavailable, such as during garbage collection, the engine can retrieve the objects from another replica in the partition.

Abstract: The SIP server deployment can be comprised of an engine tier that provides high throughput processing and a state tier that maintains SIP state data in a set of partitions and replicas. Two sites of SIP server deployments can be configured, each being remotely located with respect to the other. A primary site can process various SIP transactions and communications and upon determining a transaction boundary, replicate the state data associated with the transaction being processed, to a secondary site. Engines in the primary site can generate hints for the state replicas which can be in turn responsible for replicating the SIP session state. The replicas can choose to follow or disregard the generated hints. Upon failure of the primary site, calls can be routed from the failed primary site to the secondary site for processing. Similarly, upon recovery, the calls can be re-routed back to the primary site.

Abstract: Systems and methods are provided for improving latency during message processing in a network environment via the use of SIP server architecture. The SIP server can be comprised of an engine tier and a state tier distributed on a cluster network. The engine tier can send and receive messages and execute various processes. The state tier can maintain in-memory state data associated with various SIP sessions. The state tier can store various long lived data objects and the engine tier can contain short lived data objects. The state data can be maintained in partitions comprised of state replicas. When processing messages, the engine can pull state data objects from the state tier, use the objects and push them back to the state tier after processing is complete. If one state replica is unavailable, such as during garbage collection, the engine can retrieve the objects from another replica in the partition.

Abstract: The session-based server deployment can be comprised of an engine tier that is designed for high throughput processing of communications and a state tier that maintains state information for access by the engine tier. The engine tier can include a plurality of engine nodes that process incoming messages. The state nodes can contain call state, including various timers. When processing a call, an engine can set various timers in the state tier. Upon expiration of a timer, the state node can transmit a notification assigning the timer to the corresponding engine node which handled previous communications for the call. This affinity between the timer and its respective engine can provide numerous benefits, such as reduced latency and more localized data access.

Abstract: The session-based server deployment can be comprised of an engine tier that is designed for high throughput processing of communications and a state tier that maintains state information for access by the engine tier. The engine tier can include a plurality of engine nodes that process incoming messages. The state nodes can contain call state, including various timers. When processing a call, an engine can set various timers in the state tier. The engine can then periodically poll the state tier for any timers that have expired. Upon expiration of a timer, the timer can be assigned to the corresponding engine node which handled previous communications for the call. This affinity between the timer and its respective engine can provide numerous benefits, such as reduced latency and more localized data access.

Abstract: The SIP server can be comprised of an engine tier and a state tier distributed on a cluster network. Engine nodes in the engine tier can process SIP messages and can read/write state information from/to the state tier. State tier can maintain state information in a set of partitions of one or more replicas which contain duplicate information. The engine nodes can be adapted to detect and report replica failures and the replicas can in turn be adapted to detect and report engine node failures. Replicas can detect faults with an engine node if the engine node fails to poll the replica for a specified period of time and can then report the failure. The engine node can detect failures of a replica when reading or writing state information and can report the failure to another replica, which can be responsible for updating the partition view to exclude dead replicas.

Abstract: The SIP server can be comprised of an engine tier and a state tier distributed on a cluster network environment. The engine tier can send, receive and process various messages. The state tier can maintain in-memory state data associated with various SIP sessions. A near cache can be residing on the engine tier in order to maintain a local copy of a portion of the state data contained in the state tier. Various engines in the engine tier can determine whether the near cache contains a current version of the state needed to process a message before retrieving the state data from the state tier. Accessing the state from the near cache can save on various latency costs such as serialization, transport and deserialization of state to and from the state tier. Furthermore, the near cache and JVM can be tuned to further improve performance of the SIP server.

Abstract: A SIP server can be deployed in a two-tier architecture, including an engine tier for processing of SIP communications and a state tier for maintaining the state associated with these communications. The state tier can include RAM-based replicas that provide data to the engines. Some of the SIP session state can be moved to the database in order to reduce the memory requirements of the state tier. Upon determining that a transaction boundary has been reached where the session state is steady, the state replica can save the data to the database. A hint can be received from the engine tier by the state replica indicating that the state data is ready to be saved. Subsequently, the data can be removed from the state tier by nulling out the bytes of actual data, while preserving the primary key, locking and timer information so as not to impact latency.

Abstract: The SIP server deployment can be comprised of an engine tier that provides high throughput processing and a state tier that maintains SIP state data in a set of partitions and replicas. Two sites of SIP server deployments can be configured, each being remotely located with respect to the other. A primary site can process various SIP transactions and communications and upon determining a transaction boundary, replicate the state data associated with the transaction being processed, to a secondary site. Engines in the primary site can generate hints for the state replicas which can be in turn responsible for replicating the SIP session state. The replicas can choose to follow or disregard the generated hints. Upon failure of the primary site, calls can be routed from the failed primary site to the secondary site for processing. Similarly, upon recovery, the calls can be re-routed back to the primary site.

Abstract: The SIP server can be comprised of an engine tier and a state tier distributed on a cluster network. Engine nodes in the engine tier can process SIP messages and can read/write state information from/to the state tier. State tier can maintain state information in a set of partitions of one or more replicas which contain duplicate information. The engine nodes can be adapted to detect and report replica failures and the replicas can in turn be adapted to detect and report engine node failures. Replicas can detect faults with an engine node if the engine node fails to poll the replica for a specified period of time and can then report the failure. The engine node can detect failures of a replica when reading or writing state information and can report the failure to another replica, which can be responsible for updating the partition view to exclude dead replicas.

Abstract: A SIP server can be distributed over a cluster network and handle the processing of various SIP communications. A Diameter protocol web application can be deployed on the engine tier of the SIP server for enabling communication between the SIP server and an HSS. A profile service API can be provided that allows applications running on the SIP server to access user profile data stored on the HSS. The applications can also be allowed to subscribe to notifications about changes to the user profile data on the HSS. An Sh interface provider can be deployed on the SIP server for generating and responding to Diameter command codes. SIP servlets can access the user profile data in the form of an XML document.