Abstract: A system and method for use with an enterprise system or software development system, for determining or checking for dependencies between software components, or between other components of said system. The system utilizes a module architecture specification language and toolkit to check system code for compliance against a set of rules or requisites. The module architecture specification can be structured into product-wide groundrules applicable to all subsystems, subsystem-, layer-, module-specific, and thin-client/server rules. In accordance with one embodiment, the system can be used to allow, forbid, or constrain certain dependencies between software modules, or between the building blocks, organization components, or products that make up a large enterprise system.

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: 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 and receive messages and execute various processes. The state tier can maintain in-memory state data associated with various SIP sessions. For example, 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. A load balancer can receive incoming message traffic and distribute it to the engine tier for processing. When processing a message, 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: In accordance with embodiments, there are provided mechanisms and methods for managing services in a communications network. These mechanisms and methods can enable embodiments to manage services provided by third party service providers, for example, to callers establishing communications sessions in a network. The ability of embodiments to control access to, and manage, third party services associated with communications sessions can enable embodiments to provide improved security and enhanced features to callers.

Abstract: In an embodiment, a system for managing communications sessions is provided. The system embodiment includes a connection to a packet network that receives incoming calls. A stateful tier manages communications sessions established for the at least one incoming call. A stateless tier comprising one or more applications provides service(s) to the communications sessions in the stateful tier. One or more servers allocate and/or manage resources corresponding to the communications sessions established for the incoming calls in the stateful tier. The servers maintain the applications in the stateless tier for providing services to the communications sessions in the stateful tier.

Abstract: A system and method for providing a software module architecture specification language, and checking code for compliance. A module architecture specification can be structured into product-wide groundrules (applicable to all subsystems), and into subsystem-, layer- or even module-specific rules. The system parses the specifications automatically using the notion of rule specificness, and detects contradictory statements. This makes it easy to capture the intent of refactoring efforts and is an effective tool in ensuring that refactored code modules do not suffer from subsequent unnoticed dependency-creep.

Abstract: A system and method for use with an enterprise system or software development system, for determining or checking for dependencies between software components, or between other components of said system. The system utilizes a module architecture specification language and toolkit to check system code for compliance against a set of rules or requisites. The module architecture specification can be structured into product-wide groundrules applicable to all subsystems, subsystem-, layer-, module-specific, and thin-client/server rules. In accordance with one embodiment, the system can be used to allow, forbid, or constrain certain dependencies between software modules, or between the building blocks, organization components, or products that make up a large enterprise system.

Abstract: A system and method for providing a software module architecture specification language, and checking code for compliance. A module architecture specification can be structured into product-wide groundrules (applicable to all subsystems), and into subsystem-, layer- or even module-specific rules. The system parses the specifications automatically using the notion of rule specificness, and detects contradictory statements. This makes it easy to capture the intent of refactoring efforts and is an effective tool in ensuring that refactored code modules do not suffer from subsequent unnoticed dependency-creep.

Abstract: A mechanism for making changes consistently across an application server domain or a cluster. Server configuration consistency is absolutely necessary for cluster deployments. The invention allows changes to the configuration repository and to the application deployment process to be managed via a Data Replication Service (DRS). The former requires that the configuration repository be version aware, while the latter breaks down the application deployment process into two phases—one for data distribution and processing as far as possible, and the second to expose the changes through the Java Naming and Directory Interface (JNDI).

Abstract: A system and method for migrating services in a Java server environment, and particularly to a mechanism for migrating message driven beans. In accordance with the present invention, the JMS server and MDB's are designed to be migratable from one application server to another. In order to expedite Message Driven Bean (MDB) recovery in a cluster environment before a failed server restarts, the MDB is implemented as a migratable service. This enables the migratable service framework to migrate the MDB and JMS server to another available server in the same cluster. After migration, MDB obtains ownership of the JMS server, and continues to pull the messages from the JMS server on behalf of the failed server. This allows the backup server to read the message from JMS server and continue the service.

Abstract: Data is replicated from a master server to a slave server on a network by first sending a start call from a master user level to a master service level on the master server, the start call containing version information for data on the master server. The information is then sent to a slave service layer on a slave server so the slave server layer can determine whether data on the slave server is current. The slave server layer can request a delta from the master server if the slave data is not current. A delta containing the information necessary to update the slave data is sent from the master service layer to the slave service layer so the slave service layer can process the delta and send the updated information to the slave user layer.

Abstract: Data can be replicated over a network using a one or two phase method. For the one phase method, a master server containing an original copy of the data sends a version number for the current state of the data to each slave on the network so that each slave can request a delta from the master. The delta that is requested contains the data necessary to update the slave to the appropriate version of the data. For the two phase method, the master server sends a packet of information to each slave. The packet of information can be committed by the slaves if each slave is able to process the commit.