Online upgrade of container-based software components

Techniques for online upgrading of software components are disclosed. The techniques are especially suited for online upgrading of container-based software components in object oriented computing environments. A multi-stage online upgrade system can facilitate online installation of the container-based software components (e.g., applications) in object oriented computing environments. Moreover, online software upgrades can be achieved without interrupting online services which are provided by the container-based software components. The multi-stage online upgrade system can be implemented so as to allow interaction with an upgrade management entity (e.g., an application developer or system administrator). This allows controlling and/or monitoring of the online upgrade operations.

FIELD OF THE INVENTION

The present invention relates to object oriented computing environments, and more particularly, to techniques for upgrading container-based software components.

BACKGROUND OF THE INVENTION

Recently, container-based software components have been developed for object oriented computing environments. These software components (e.g., application programs) can interact with a “container” which can typically provide various standard functions (e.g., security, networking, etc.). This offers many advantages, for example, ease of use and reusability.

To elaborate, in Sun Microsystems' Enterprise JavaBeans component architecture, and in Microsoft Corporation's Component Object Model (COM), a container is an application program or subsystem in which the program building block known as a component is run. For example, a component, such as a button, a small calculator, or a database requester, can be developed using Enterprise JavaBeans that can run in application servers.

In today's computing environments, there is often a need to upgrade software components. As such, it is desirable to perform software upgrades in an efficient way. Moreover, for some applications, it is highly desirable to perform software upgrades without having to shut down the system. Unfortunately, conventional techniques do not allow software upgrades to be performed without having to shut down the system or otherwise degrade the performance of the system in some other manner. Typically, services being performed have to be interrupted to allow for the upgrade. In some cases, interruption of services can be very costly, thus need to be avoided.

In view of the foregoing, there is a need for improved techniques for upgrading software components.

SUMMARY OF THE INVENTION

Broadly speaking, the invention relates to techniques for online upgrading of software components. The invention is especially suited for online upgrading of container-based software components in object oriented computing environments. In accordance with one aspect of the invention, a multi-stage online upgrade system is disclosed. As will be appreciated, the multi-stage online upgrade system can facilitate online installation of the container-based software components (e.g., applications) in object oriented computing environments. Moreover, online software upgrades can be achieved without interrupting online services which are provided by the container-based software components. The multi-stage online upgrade system can be implemented so as to allow interaction with an upgrade management entity (e.g., an application developer or system administrator). This allows controlling and/or monitoring of the online upgrade operations. Other aspects of the invention provide techniques suitable for performing online upgrades of container-based software components. As will be appreciated, online upgrades of the container-based software components can be implemented in multiple stages.

The invention can be implemented in numerous ways, including as a system, an apparatus, a method, or a computer readable medium. Several embodiments of the invention are discussed below.

As an object oriented computing environment one embodiment of the invention includes: a first container based software component being an upgraded version of a second container based software component, a container suitable for interaction with the first container based software component, and an online upgrade system capable of operating to facilitate online upgrading of said second container based software component to said first container based software component.

As a method of upgrading software in a object oriented computing environment, one embodiment of the invention includes the acts of: loading an online upgrade module, notifying an online-upgrade controller to initiate an online upgrade process, and performing one or more operations to facilitate online upgrade of said second container based software component to said first container based software component. The online upgrade module includes a first container based software component, an online upgrade listener and an online upgrade specification. The first container based software component being an upgrade of a second container based software component.

As a method of upgrading container based software components in multiple stages one embodiment of the invention includes: an upgrade prepare stage, a pre-upgrade stage, one or more upgrade operations, and a post-upgrade stage.

DETAILED DESCRIPTION OF THE INVENTION

The invention pertains to techniques for online upgrading of software components. The invention is especially suited for online upgrading of container-based software components in object oriented computing environments. In accordance with one aspect of the invention, a multi-stage online upgrade system is disclosed. As will be appreciated, the multi-stage online upgrade system can facilitate online installation of the container-based software components (e.g., applications) in object oriented computing environments. Moreover, online software upgrades can be achieved without interrupting online services which are provided by the container-based software components. The multi-stage online upgrade system can be implemented so as to allow interaction with an upgrade management entity (e.g., an application developer or system administrator). This allows controlling and/or monitoring of the online upgrade operations. Other aspects of the invention provide techniques suitable for performing online upgrades of container-based software components. As will be appreciated, online upgrades of the container-based software components can be implemented in multiple stages.

FIG. 1Aillustrates an object oriented computing environment100including a multi-stage online upgrade system102in accordance with one embodiment of the invention. The multi-stage online upgrade system102includes a first container-based software component104, a multi-stage online upgrade listener interface106, a multi-stage online upgrade controller108, a multi-stage online upgrade specification110, and generated code (artifacts)112.

The first container-based software component104represents an upgraded version of a second container-based software component116. The second container-based software component operates in a container116of the object oriented computing environment100. The container116can, for example, represent a standard interface which implements various functions (e.g., security, networking, etc.). The first or second container-based software components104and114, for example, can be Enterprise JavaBeans II applications developed in accordance with Sun Microsystems' specifications.

As will be appreciated, the multi-stage online upgrade system102can facilitate online installation of the first container-based software component104in the object oriented computing environment100. Moreover, online software upgrades can be performed without interrupting services that are typically performed by first or second container-based software components104and114. In other words, at least one of the first or second container-based software components104and114are operable while the multi-stage online upgrade system102is upgrading the object oriented computing environment102(i.e., replacing the second container-based software component114to the first container-based software component104).

As noted above, the multi-stage online upgrade system102can include the multi-stage online upgrade control module108. In the described embodiment, the multi-stage online upgrade control module108is capable of interacting with the multi-stage online upgrade listener interface106to facilitate online installation of the first container-based software component104. The multi-stage online upgrade listener interface106can access the first container-based software component104, as well as the second container-based software component114. It should be noted that at least a portion of the multi-stage online upgrade control module108can be implemented in the container116. Furthermore, the multi-stage online upgrade control module108can be in communication with a program developer or system administrator118. In this way, online upgrading can be controlled and/or monitored by a human operator.

It should also be noted that the multi-stage online upgrade specification110can provide information regarding the upgrade. The generated code (artifacts)112can represent the code which is generated for the operation of the second container-based software component104. As will be appreciated, when the online upgrade operations have successfully been completed and the first container-based software component104is fully operable the second container-based software component114can be removed. However, it should be noted that first and second container-based software components104and114may simultaneously be operable during the online upgrading process. As will be appreciated, this means that it is possible to “roll back” to the second container-based software component114during the online upgrading process, for example, in the event the upgrade is unsuccessful or the upgrade process is terminated. In any case, the multi-stage online upgrade system102allows software components to be upgraded without interruption to services provided by them.

As will be appreciated, one or more components of the multi-stage online upgrade system102can be packed in a software package.FIG. 1Billustrates an exemplary online upgrade package150in accordance with one embodiment of the invention. The online upgrade package150includes an Enterprise JavaBeans II application152, an upgrade listener interface154, and a manifest156which includes an upgrade specification158. It should be noted that online upgrade package150can also include a generated code (artifact)160.

FIG. 2illustrates an online upgrade method200in accordance with one embodiment of the invention. Initially, at operation202, an online upgrade package is loaded. The online upgrade package includes a container-based software component. Typically, the container-based software component needs to be installed to upgrade a computing environment with a newer version of a software component. As noted above, an online upgrade package can also include other components, for example, an upgrade listener interface and a manifest which includes an upgrade specification.

After the online upgrade package is loaded, an upgrade controller (e.g., multi-stage online upgrade control module108ofFIG. 1A) is notified at operation204so that the online upgrading of a software component can be initiated. Next, at operation206, one or more online upgrade operations are performed to upgrade the computing environment with the container-based software component of the online upgrade package. The online upgrade method200ends following operation206.

As noted above, the online upgrade operations can be performed in two or more stages.FIG. 3illustrates a method300for performing online upgrade operations in accordance with one embodiment of the invention. The method300represents on line operations that can be performed, for example, by the operation206ofFIG. 2. Initially, at operation302, one or more upgrade prepare (ready) operations are performed. Next, at operation304, one or more pre-upgrade operations are performed. Thereafter, at operation306, one or more upgrade operations are performed. After the upgrade operations, one or more post-upgrade operations are performed at operation308.

Next, at operation310, a determination is made as to whether the software upgrade is ready for service. If it is determined at operation310that the software upgrade is ready for service, the method300proceeds to operation312where one or more commit operations are performed. As will be appreciated, after the commit operations are performed, the old version of the software can be taken offline and/or removed. The method300ends following operation312.

On the other hand, if it is determined at operation310that the upgrade software is not ready for service, the method300proceeds to operation314where a determination is made as to whether any rollback operations should be performed. If it is determined at operation314that there is no need to perform any rollback operations, the method300proceeds to operation310where it is determined whether the software is ready for service. However, if it is determined at operation314that at least one rollback operation should be performed, the method300proceeds to operation316where one or more rollback operations are performed. As will be appreciated by those skilled in the art, the rollback operations, among other things, can ensure the integrity of the computing environment (e.g., integrity of a data). After operation316, the method300proceeds to operation318where a determination is made as to whether to terminate the online upgrade process. The method300ends if it is determined at operation318that the online upgrade process should be terminated. However, if it is determined at operation318that the online upgrade process should not be terminated, the method300proceeds to operation310where it is determined whether the software upgrade is ready for service. Thereafter, the method300proceeds in the same manner as described above. The method300ends following the commit operations312or after operation318if it is determined that online upgrade processing operations should be terminated.

FIG. 4illustrates an exemplary method400for performing upgrade prepare (ready) callbacks in accordance with one embodiment of the invention. The method400represents, for example, the operations that can be performed by the upgrade prepare stage302ofFIG. 3. In the described embodiment, the method400demonstrates interactions between a server (e.g., an Enterprise JavaBeans II server) and an online upgrade listener (e.g., multi-stage online upgrade listener interface106ofFIG. 1A). As will be appreciated by those skilled in the art, the server can be implemented, for example, as a cluster (i.e., two or more computing nodes that can be coupled together).

At operation402, online upgrade listener classes are loaded and a listener is instantiated. Next, at operation404, a determination is made as to whether the online upgrade listener classes are successfully loaded and the listener is successfully instantiated. If it is determined at operation404that the online upgrade listener classes are not successfully loaded or the listener is not successfully instantiated, the method400proceeds to operation406where the results are conveyed to the cluster management, allowing the cluster management to take appropriate action.

However, if the online upgrade listener classes are successfully loaded and the listener is successfully instantiated, the method400proceeds to operation408where upgrade prepare callbacks are performed. In addition, at operation409, the old version of the application is alerted that the online upgrading is about to begin. Next, at operation410, a determination is made as to whether the upgrade prepare callbacks were successfully performed. If it is determined at operation410that the callbacks were successfully performed, the method400proceeds to operation to412where the upgrade sequence is initiated. However, if it is determined at operation410that the callbacks were not successfully performed, the method400proceeds to operation406where the results are conveyed to the cluster management, this allowing the cluster management to take appropriate action (e.g., terminate the upgrade prepare stage, restart the upgrade ready stage, etc.).

FIG. 5illustrates a method500for performing online upgrade operations. In the described embodiment, the upgrade operations include: pre-upgrade callbacks, upgrade operations, and post-upgrade operations. The method500represents, for example, the operations that can respectively be performed at the pre-upgrade, upgrade, and post-upgrade stages304,306and308ofFIG. 3. In the described embodiment, the method500demonstrates interactions between a server (e.g., an Enterprise JavaBeans II server) and an online upgrade listener (e.g., the multi-stage online upgrade listener106ofFIG. 1A). Again, the server can be implemented, for example, as a cluster (i.e., two or more computing nodes that can be coupled together).

Initially, at operation502, one or more pre-upgrade callbacks are performed. In addition, at operation504, the signal prior to upgrade operation is handled. Next, at operation506, a determination is made as to whether the pre-upgrade callbacks have been performed successfully. If it is determined at operation506that the pre-upgrade callbacks were not performed successfully, the method500proceeds to operation508where the results are conveyed to the cluster management, allowing the cluster management to take appropriate action. However, if it is determined at operation506that the pre-upgrade callbacks have been performed successfully, the method500proceeds to operation510where one or more upgrade operations are performed. These upgrade operations, for example, can be schema expansion or schema contraction for a database application.

Next, at operation512, a determination is made as to whether the upgrade operations were performed successfully. If it is determined at operation512that the upgrade operations were not performed successfully, the method500proceeds to operation508where the results are conveyed to the cluster management. However, if it is determined at operation512that the upgrade operations were performed successfully, the method500proceeds to operation514where one or more post-upgrade call backs. In addition, at operation515, the signal posterior to the upgrade operation is handled.

Thereafter, at operation516, a determination is made as to whether the post-upgrade callbacks were performed successfully. If it is determined at operation516that the post-upgrade callbacks were not performed successfully, the method500proceeds to operation508where the results are conveyed to the cluster management. However, if it is determined at operation516that the post-upgrade callbacks were performed successfully, the method500proceeds to operation518where loading of the new version of the application is initiated.

FIG. 6illustrates a method600for performing load and redirect operations upgrade operations. The method600represents, for example, the operations that can be performed at operation310FIG. 3. In the described embodiment, the method600demonstrates interactions between a server (e.g., an Enterprise JavaBeans II server) and an online upgrade listener (e.g., multi-stage online upgrade listener interface106). Again, the server can be implemented, for example, as a cluster.

At operation602, the new version of the application is loaded. Next, at operation604, a determination is made as to whether the new version of the application was loaded successfully. If it is determined at operation604that the new version of the application was not loaded successfully, the method600proceeds to operation606where the results are conveyed to the cluster management. However, if it is determined at operation606that the new version of the application was loaded successfully, the method600proceeds to operation608where a “is-ready-for-service” callback is performed. In addition, at operation609, the “is-ready-for-service” signal is handled.

Next, at operation610, a determination is made as to whether the “is-ready-for-service” callback was performed successfully. If it is determined at operation610that the “is-ready-for-service” callback was not performed successfully, the method600proceeds to operation606where the results are conveyed to the cluster management. However, if it is determined at operation610that the “is-ready-for-service” callback was performed successfully, the method600proceeds to operation612where a redirect callback is performed. Next, at operation614, it is determined whether the redirect callback is performed successfully. Thereafter, at operation606, the result of the determination made at operation614are conveyed to the cluster management.

FIG. 7illustrates a method700for performing commit operations. The method700represents, for example, the operations that can be performed at operation312ofFIG. 3. In the described embodiment, the method700demonstrates interactions between a server (e.g., a Enterprise s II server) and an online upgrade listener (e.g., multi-stage online upgrade listener interface106ofFIG. 1A, or upgrade listener interface154ofFIG. 4). The server can be implemented, for example, as a cluster. Initially, at operation702, it is assured that the old version of the application is drained. Next, at operation704, a determination is made as to whether the drainage of the old version of the application was successful. If it is determined at operation704that the drainage of the old version of the application was not successful, the method700proceeds to operation706where the results are conveyed to the cluster management. However, if it is determined at operation704that the drainage of the old version of the application was successful, the method700proceeds to operation708where the upgrade commit callback is performed. In addition, at operation709, the upgrade commit signal is handled.

Next, at operation710, a determination is made as to whether the upgrade commit callback has been performed successfully. If it is determined at operation710that the upgrade commit callback has been not performed successfully, the method700proceeds to operation706where the results are conveyed to the cluster management. However, if it is determined at operation710that the upgrade commit callback has been performed successfully, the method700proceeds to operation712where the old version of the application is unloaded. Thereafter, at operation714, a determination is made as to whether the old version of the application was unloaded successfully. Accordingly, at operation714, the results are conveyed to the cluster management.

The invention can use a combination of hardware and software components. The software can be embodied as computer readable code (or computer program code) on a computer readable medium. The computer readable medium is any data storage device that can store data which can thereafter be read by a computer system. Examples of the computer readable medium include read-only memory, random-access memory, CD-ROMs, magnetic tape, and optical data storage devices. The computer readable medium can also be distributed over network-coupled computer systems so that the computer readable code is stored and executed in a distributed fashion.