Abstract: A migration framework provides for the migration of services in a cluster. A migratable target contains a list of servers in the cluster capable of hosting a migratable service. A migration manager can migrate the service between servers in the migratable target, and can activate an instance of the service on the selected host server. The migration manager ensures that only one active instance of the service exists in the cluster. A service stub can serve a user request on servers in the migration target, such as by order of preference, until the user request is served on the server hosting the active instance. A lease manager can assign a lease period to determine how long a server hosts an active instance.

Abstract: A system for managing objects in a clustered network includes a file system containing at least one copy of a data object. The system can include several clustered servers in communication with the file system. A distributed consensus algorithm is used to select a host server. The selected host server can contain a copy of the data object, such as in local cache, providing access to the local copy to any other server in the cluster. Any change made to an item hosted by the host server can also be updated in the file system. If the host server becomes unable to host the object, a new host can be chosen using the distributed consensus algorithm. The other servers are then notified of the new host by multicast messaging.

Abstract: A migration framework provides for the migration of services in a cluster. A migratable target contains a list of servers in the cluster capable of hosting a migratable service. A migration manager can migrate the service between servers in the migratable target, and can activate an instance of the service on the selected host server. The migration manager ensures that only one active instance of the service exists in the cluster. A service stub can serve a user request on servers in the migration target, such as by order of preference, until the user request is served on the server hosting the active instance. A lease manager can assign a lease period to determine how long a server hosts an active instance.

Abstract: A migration framework provides for the automatic migration of services in a cluster. A migratable target list contains a list of servers in the cluster capable of hosting a migratable service. A consensus subsystem can select a host server from the migratable target list. A migration manager can migrate the service from a current host to the host selected by the consensus subsystem, and can activate an instance of the service on the selected host server. The migration manager ensures that only one active instance of the service exists in the cluster. A service stub can serve a user request on servers in the migration target, such as by order of preference, until the user request is served on the server hosting the active instance. A lease manager can assign a lease period to determine how long a server hosts an active instance. This description is not intended to be a complete description of, or limit the scope of, the invention.

Abstract: A migration framework provides for the migration of services in a cluster. A migratable target contains a list of servers in the cluster capable of hosting a migratable service. A migration manager can migrate the service between servers in the migratable target, and can activate an instance of the service on the selected host server. The migration manager ensures that only one active instance of the service exists in the cluster. A service stub can serve a user request on servers in the migration target, such as by order of preference, until the user request is served on the server hosting the active instance. A lease manager can assign a lease period to determine how long a server hosts an active instance. This description is not intended to be a complete description of, or limit the scope of, the invention. Other features, aspects, and objects of the invention can be obtained from a review of the specification, the figures, and the claims.

Abstract: The current structure for starting and shutting down a server is complicated and affords little administrative control. A server must be started in one long-running step and cannot be shutdown without risk of disrupting in-flight work. The ability to bring up a server quickly and bring down a server gracefully is crucial to improving availability. A server configuration in which a server that is brought up as a hot-stand by server for a running, active server can significantly reduce downtime (failover time) in the case of an outage. A server that can be suspended gracefully can be removed from service without disrupting clients. These new features require improvements to the server lifecycle to clearly articulate the distinction between an initialized server and an active server (for hot standby) and between a suspending server and a suspended server (for graceful suspend) and to simplify the lifecycle by removing circular initialization dependencies between services and clarifying the lifecycle contract.

Abstract: A Node Manager monitors the status of multiple servers. The Node Manager detects server failures, periodically monitors server health status, and performs server maintenance. When the Node Manager detects a server failure, it determines whether or not the server should be restarted. While periodically monitoring servers, the Node Manager may determine how often to trigger a health check, how long to wait for a response, and how to proceed if the server is deemed failed. The Node Manager may be controlled by an Administrative Server directly or by an external administrative agent. An administrative agent may control the Node Manager by interfacing with the Administrative Server. The Node Manager and AS may authenticate each other and encode their communications to each other for increased security.

Abstract: A system for managing a JMS message store in a clustered network includes an object acting as a message store for Java Message Service (JMS). A lead server is selected from several clustered servers. The lead server uses a distributed consensus algorithm to select a host server, utilizing multicast messaging while executing rounds of the algorithm. The selected host server hosts the JMS message store, providing sole access to JMS. The other servers are notified of the new host by multicast messaging. All servers in the cluster can use JMS, but they must send messages to the message store on the host and pick up any messages from the message store.

Abstract: A Node Manager monitors the status of multiple servers. The Node Manager detects server failures, periodically monitors server health status, and performs server maintenance. When the Node Manager detects a server failure, it determines whether or not the server should be restarted. While periodically monitoring servers, the Node Manager may determine how often to trigger a health check, how long to wait for a response, and how to proceed if the server is deemed failed. The Node Manager may be controlled by an Administrative Server directly or by an external administrative agent. An administrative agent may control the Node Manager by interfacing with the Administrative Server. The Node Manager and AS may authenticate each other and encode their communications to each other for increased security.

Abstract: In one embodiment, application versioning and production redeployment support is designed to handle application upgrade needs in mission-critical, production environments. With multiple application versions, application availability to both existing and new clients is not interrupted during the process of application upgrade. It also provides the ability to test a new application version before opening it to general public as well as the ability to roll back to previous safe versions if there are any errors in the currently active version. Clients see consistent application versions, irrespective and transparent of all failure conditions, including admin or managed server restarts and/or failover. Administrators can monitor and manage application versions easily with the management Console.

Abstract: In embodiments, the present invention provides mechanisms and methods for making a set of configuration changes to a set of servers comprised of an administration server and one or more managed servers. These mechanisms and methods can enable a number of changes to be made to the configuration at once, e.g., in a batch. In such transaction based processing, embodiments process changes in batches, which enables embodiments to avoid failures in configuration changes that result in the machines being in a non-recoverable or unknown configuration state.

Abstract: In embodiments, the present invention provides mechanisms and methods for making a plurality of configuration changes to a set of servers comprised of an administration server and one or more managed servers. These mechanisms and methods can enable a number of changes to be made to the configuration at once, i.e., in a batch. The ability of an administrator to make a number of changes to the configuration, validate the changes and then persist the changes to the servers is termed a “transaction based” change process. In such transaction based processing, embodiments process changes in batches, which enables embodiments to avoid failures in configuration changes that result in the machines being in a non-recoverable or unknown configuration state.

Abstract: A descriptor class framework fully support a “start-from-class” approach, which defines a descriptor via a set of programmable classes defined in an object-oriented programming language. While the persistent form of a descriptor of a deployed software component is a file, the developer of an application using software component may view the descriptor as a set of programmable descriptor classes. A set of classes can be generated from a descriptor based on a set of construction rules and vise versa. Each class can be annotated, validated and customized. The descriptor class framework is also capable of determining the differences between two versions of a descriptor and notifying the changes to a corresponding class via events to a listener registered with the class. This description is not intended to be a complete description of, or limit the scope of, the invention. Other features, aspects, and objects of the invention can be obtained from a review of the specification, the figures, and the claims.

Abstract: A clustered enterprise Java™ distributed processing system is provided. The distributed processing system includes a first and a second computer coupled to a communication medium. The first computer includes a Java™ virtual machine (JVM) and kernel software layer for transferring messages, including a remote Java™ virtual machine (RJVM). The second computer includes a JVM and a kernel software layer having a RJVM. Messages are passed from a RJVM to the JVM in one computer to the JVM and RJVM in the second computer. Messages may be forwarded through an intermediate server or rerouted after a network reconfiguration. Each computer includes a Smart stub having a replica handler, including a load balancing software component and a failover software component. Each computer includes a duplicated service naming tree for storing a pool of Smart stubs at a node. The computers may be programmed in a stateless, stateless factory, or a stateful programming model.

Abstract: The current structure for starting and shutting down a server is complicated and affords little administrative control. A server must be started in one long-running step and cannot be shutdown without risk of disrupting in-flight work. The ability to bring up a server quickly and bring down a server gracefully is crucial to improving availability. A server configuration in which a server that is brought up as a hot-stand by server for a running, active server can significantly reduce downtime (failover time) in the case of an outage. A server that can be suspended gracefully can be removed from service without disrupting clients. These new features require improvements to the server lifecycle to clearly articulate the distinction between an initialized server and an active server (for hot standby) and between a suspending server and a suspended server (for graceful suspend) and to simplify the lifecycle by removing circular initialization dependencies between services and clarifying the lifecycle contract.