GB2411995A - Upgrading an object oriented programming language platform - Google Patents

Upgrading an object oriented programming language platform Download PDF

Info

Publication number
GB2411995A
GB2411995A GB0512569A GB0512569A GB2411995A GB 2411995 A GB2411995 A GB 2411995A GB 0512569 A GB0512569 A GB 0512569A GB 0512569 A GB0512569 A GB 0512569A GB 2411995 A GB2411995 A GB 2411995A
Authority
GB
United Kingdom
Prior art keywords
upgraded
application
root
object oriented
server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
GB0512569A
Other versions
GB2411995B (en
GB0512569D0 (en
Inventor
Vladimir Matena
Rahul Sharma
Masood Mortazavi
Sanjeev Krishnan
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sun Microsystems Inc
Original Assignee
Sun Microsystems Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US09/833,845 external-priority patent/US7370322B1/en
Application filed by Sun Microsystems Inc filed Critical Sun Microsystems Inc
Publication of GB0512569D0 publication Critical patent/GB0512569D0/en
Publication of GB2411995A publication Critical patent/GB2411995A/en
Application granted granted Critical
Publication of GB2411995B publication Critical patent/GB2411995B/en
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G06F8/656—Updates while running

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

An object oriented programming language platform, such as a Java¹ or J2EE platform is upgrade by updating the service subsystems including the repository, updating a root server process and updating a root system application. The root system application has a control module which includes application specific policies. User applications may be recursively upgraded. The user applications may be executed in a middle tier between a client browser and a database. The subsystems may be upgraded by creating a new backup process and stopping an old one. The server may be upgraded by generating a new server, loading upgraded class files, transferring the runtime executive to the new server and allocating modules to the new server.

Description

241 1 995
METHOD AND APPARATUS FOR PERFORMING ONLINE
APP] ICATION UPGRADES IN A JAVA PLATFORM by Inventors Vladimir Platens Rahul Sharrna, Max Mortazavi, and Sanjeev Krishnan
BACKGROUND OF THE INVENTION
1. Field of the invention
This invention relates generally to JAVA programming, and more particularly to methods for providing online software upgrades in a Java environment.
2. Description of the Related Art
Today's world of computer prograrmr-ing ofter-s many high-level programming languages. Java, for- example, has achieved widespread use in a relatively short per-rod of time and is largely attributed with the ubiquitous success of the Interpret. The popularity of lava Is due, al least in part, to its platform Independence, object orientation and dynamic nature. In addition, Java reTnoves many of the tedious and errorprone tasks which must be performed by an application programmer, including memory management and cross-platform porting. In this manner, the Java programmer can better focus on design and functionality issues.
One particular JAVA environment is the Java 2 platform, Enterprise Elition (J2EE), which facilitates building Web-based applications. Broadly speaking, J21E services are peTiormecl in the rnddle tier between tile user's browser and the databases and legacy information systenis. J2EE coml>rTses a specification, reference implementation and a set of testing suites. J2EE further- comprises Enterprise Java13eans (LI113), JavaServer Pages (JSP3, Java ser-vlets, and a plurality of interfaces for IhTkTng to infor-rnation resources in the platfor-rn.
The J2EE specifications define how applications should be written for the J2EE environment. I'hus the specifications provide the contract between the applications and the J2LiE platform. I-Iowever-, there exist a class of JAVA applications that require customization.of the J2EE platform These applications generally utilize application specific strategies created by a particular vendor to accomplish specific tasks that are not provided by the general JAVA platform on which the application executes Examples of this class of JAVA applications include telecorurnunications applications and services that are deployed within a particular service provider's environment This class of applications typically requires continuous availability, which means the environment in which the applications operate requires the applications to be available most of the time.
Figure 1 is a block diagram showing a prior art J2EE environment 100. The J2EE environment 100 includes a platform 102, which is generally provided by the user of the J2EE environment 10). 'lithe platform 102 generally incindes the hardware anti operating system OT] which J2EE applications will execute Present on the platform 102 are an application client container 104, a web container 106, and an enterprise Javalleans container 108.
Using the J2E,E environment 100, application developers car' create JAVA applications using EJB, lava servlets, or application clients, which then execute in the aypropiate container 104, 106, and 108. An advantage of the J2'.E environment 100 is that the applications 110 can be simple since the application developer does not need to be concerned about transactions and other system-level programming concepts These aspects are handled by the containers 104-1()8 of the J2EE environment 100.
However, as mentioned above there exist a class of programs that require developers to - 20 provide application-specific policies to the applications 110 Unfortunately, the prior art J2E;,E environment 100 does not allow developers to provide these application-specifTc polices without breaking the basic JAVA paradigm, which define how a particular application 110 will interact with specific aspects of the underlying platform 102 Practically speaking, it is difficult to include application-specific policies within a genetic Java platform itself because there generally is no prior knowledge of what specific policies any particular application will need Thus, vendors have individually configured their Java platfor- ns to include application-specTfc policies 112 that will be needed by the particular programs executnig on that particular vendor's platter- 102. However, when this type of individual configuration is done, the platform 102 IS still unable to execute applications that need ayplication- specific polices that were not built into the particular vendor's platform Moreover, it is difficult to upgrade these vendor specific applications while they are executing on the Java platfonn. There is currently no defined mechanism for online upgrades of software on a J2EE platform Such upgrades require the system to continue providing services to clients while the software upgrade is being perforT;ned.
In view of the foregoing, there is a need for systems and methods that allow online upgrades to occur that generally do not have any detectable impact of the clients using the service provided by the applications during the upgrade. Moreover, the methods should allow developers to provide application-specific strategies in the form of lava code for individual JAVA applications. The systems and methods should allow these application-specific strategies to be provided to the underlying Java platform while preserving compatibility with existing Java programming models.
SUMMARY OF TIIE INVEN rEoN
Broadly speaking, the embodiments of the present invention address these needs by providing systems and methods for performing online upgrades using a control module, executed as part of an application, that includes application-specific strategies for the application, yet can be coded using the lAVA programming lar,guage In one embodiment, a method for performing an online upgrade to a Java application is disclosed. Initially, all application is executed that includes an original service module and an original control module.
The original control module includes application-specific polices for the application. To upgrade the application, an upgraded control module is generated. Then, the upgraded control module is used to create an upgraded service module. Both the upgraded control module and the upgraded service module can be generated using class files for the upgraded modules, which are loaded from a system repository In this manner, the original control module and the original service nodule ore upgraded. This method can also be used to upgrade a child application using the upgraded control module, and the application-specifc polices can be passed to a control module of the child application.
In another emb,dirnent, a lava platform capable elf peTfonning online software upgrades is disclosed. The Java plattonn includes an application having an original service module and an original control module. As above, the original control module includes application-specifc polices for the application. In adclition, the Java platform includes a repository having upgraded class files for the original control module and the original service module. When perfomltug an online software upgrade the original control module is upgraded by generating an upgraded control module using the upgraded class files for the original control module loaded from the repository. Then, the original set vice module is upgraded by creating an upgraded service module using the upgraded control module. As with the control module, the upgraded service module is generated using upgraded class files for the original service module loaded from the repository. Further, the upgraded control module is capable of initiating the upgrade of a child application, where the application-specific polices are passed to a control module of the child application during the 'upgrade of a child application.
A method for upgrading a Java platform is disclosed in a further embodiment of the presen; invention. The method includes upgrading service subsystems, such as a system repository. Then, upgrading a root Java server process, and upgrading a root system application addition user applications currently executing of the Java pladonn are recursively upgraded. More specifically, to upgrade the service subsystems, an upgraded root lava server backup process is created using a bootstrap program, and the execution of an original root Java server backup process is stopped using the bootstrap program. Further, to upgrade the root Java server process, an upgraded root Java server is generated using a runtime executive, and the runtime executive is transferred to the upgraded root Java server. To upgrade the root system application, an upgraded runtime executive is created using the upgraded root Java server, and service modules of the root system application are then upgraded using the upgraded runtime executive. Further upgrading is accomplished by upgrading a top user application and recursively upgrading remaining user applications currently executing on the Java platform.
Advantageously, the embodiments of the present invention allow an online upgrade to occur generally without any detectable impact on the clients using the services provided by the application during the upgrade. Moreover, the control module of the embodiments of the present invention allows application developers to create and interface code-based application- specific strategies for applications, yet allow the service module to remain compatible with existing Java programs [Further, applications executing on the lava system of the embodiments of the present invention can, in some embodiments, achieve continuous availability, on the order of about 99.9999o uptime or better. Other aspects and advantages of the invention will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, illustrating by way of example the principles of the invention I]RIEF DECR[rRlON OF TEIE DRAWINGS The invention, together with further advantages thereof, may best be understood by reference to the following description taken in conjunction with the accompanying drawings in which: Figure 1 is a block diagram showing a prior art J2EE environment; Figure 2 is a logical diagram of a distributed Java system, in accordance with an embodiment of the present invention; Figure 3A is a logical diagram showing a Java application execution paradigm, in accordance with an embodiment of the present invention; Figure 3R is a logical diagram showing a Java application execution paradigm wherein generic control modules are injected into Java applications, in accordance with an embodiment of the present invention; figure 4 is structural diagram of a Java application, in accordance with an embodiment of the present invention; IS Figure 5 is a logical diagram showing an application-server relationship, in accordance with an embodiment of the present Invention; Figure 6 is an architectural diagram showing class structure for a lava system, in accordance with an embodiment of the present invention; figure 7 is a sequence diagram showing an application start sequence, in accordance with an embodiment of the prescut invention; Figure 8 is a sequence diagram showing a module start sequence, in accordance with an embodiment of the present invention; lgure 9 is a sequence diagram showing a JIBE server start sequence, in accordance with an embodiment of the present invention; [figures lOA and 10B are sequence diagrams slowing a 12EE system start sequence, in accordance with an emhodrnent- of the present invention; Figure 11 is a sequencing diagram showing an application stop sequence, in accordance with an embodiment of the present invention; figure 12 is a sequencing diagram showing a module stop sequence, in accordance with an embodiment of the present invention; Figure 13 is a sequencing diagram showing a 12EE server stop sequence, in accordance with an embodiment of the present invention; Figure 14 is a sequencing diagram showing a J2EE system stop sequence, in accordance with an embodiment of the present invention; Figure 15 is a functional diagram showing load balancing operations used by control modules for load balancing a J2EE system, in accordance with an embodiment of the present invent.or.; Fiigure 16 is a sequence diagram showing a module move sequence, in accordance with an embodiment of the present invention; Figure 17 is a sequence diagram showing an application upgrade sequence, in accordance with an embodiment of the present invention; Figure 18 Is sequence diagram showing a module upgrade sequence, in accordance with an embodiment of the present invention; Figure 19 is a sequence diagram showing a J2EE server upgrade sequence, in accordance with an embodiment of the present invention; Figure 20 is a sequence diagram showing a service subsystems upgrade sequence, in accordance with an embodiment of the present invention; figure 21 is a sequence diagram showing a root 12EE server upgrade sequence, in accordance with an embodiment of the present invention; and Figure 22 Is a sequence diagram showing a root system application upgrade sequence, in accordance with an embodiment of the present invention DETAILED DESCP rloN OF THE PREFERRED EMBODIMENTS An invention is disclosed for systems and methods for performing online upgrades in a Java platform To facilitate the online upgrading of software, the embodiments of the present invention provide a control module, executed as part of an application, that includes application-specific strategies for the application, yet can be coded using the JAVA programming language. In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without some or all of these specific details. In other instances, well known process steps have not been described in detail in order not to unnecessarily obscure the present invention.
The control module of the embodiments of the present invention allows application developers to provide application-specific strategies to their applications without needing to alter the lAVA platform itself, using the JAVA programming language. Thus, developers can define start and stop polices, load balancing policies, upgrade policies, and other application 1S specific strategies and policies, as will be apparent to those skilled in the art. When performing upgrades, the control module provides correlation and upgrade polices for upgrading related service modules and child applications. Using the embodiments of the present invention, a system can continue lo provide services to clients while a software upgrade is being performed.
Advantageously, the embodiments of the present invention allow an online upgrade to occur generally without any detectable impact on the clients using the services provided by the application during the upgrade.
Figure 2 is a logical diagram of a distributed Java system 200, in accordance with an embodiment of the present invention. '] he Java system 200 includes an application run time subsystem 202, a repository subsystem 204, a state server subsystem 206, and a clustering framework subsystem 208. The distributed Java system 200 supports development of carrier grade Java apphcations, and further supports online application upgrades, failure recovery, and load balancing across multiple nodes of a clustered system. Moreover, as will be discussed in greater detail subsequently, applications can supply complex policies for the mechanisms implemented by the Java system 20() Advantageously, applications executing on the Java system 200 can, in some embodiments, achieve continuous availability, on the order of about g9.99g9% uptime or better. g
As mentioned above, the Java system 200 includes an application run time subsystem 202, a repository subsystem 204, a state server subsystem 206, and a clustering framework subsystem 208. The repository subsystem 204 is responsible for maintaining class files of applications installed on the system, the class files of the artifacts generated during application deployments and the class files of the application run time subsystem 202. The repository depends on the clustering framework subsystem 208 to achieve high availability The state server subsystem 206 is responsible for storing applications' state information and for making the stored state information highly available to the rest of the system. The clustering framework subsystem 208 represents the underlying high availability cluster framework. Thus, the clusterir,g framework subsyste:n 2n8 is the foundation on which the Java system. 200 is built.
The application runtimc subsystem 202 is responsible for the runtime management and supervision of the Java applications executing on the Java system 2()0. I'he application Tuntime subsystem includes a runtime executive subsystem 210, an application structure 212, an error correlator subsystem 214, a bootstrap subsystem 216, a Java server subsystem 21X, and a replicated state manager 220. The runtime executive subsystem 210 is responsible for maintaining the state of the runtime, and coordinates the collaborations among the objects that implement the use cases. The error correlator subsystem 214 processes errors reported from other application runtirne components, and further determines which parts of the system are faulty. The bootstrap subsystem 216 is used in bootstrapping the application runtime subsystem 200, and uses the facilities of the clustering framework 208 for this purpose The Java server subsystem 21X implements the Java containers and other APIs required by the Java,ulatform specification, thus providing the runtime environment for Java applications. The replicated state manager- (IlSM) 220 implernerTts the management of the recoverable state of Java applications within the Java server 218 lithe RSM 220 uses the state server- 206 to achieve recoverability and availability of an application's state.
Figure 3A is a logical diagram showing a Java application execution paradigm 30(), in accordance with an embodiTnenl of the present invention. The Java application execution paradigm 300 shows a Java application 302 executing in a container under the runtime management and supervision of the application runtime subsystem 202. As mentioned above, 3() the application runtime subsystem 202 includes the nTntime executive subsystem 210, which maintains the state of the runtime and coordinates the collaborations among the objects that implement the use cases 1 1 The Java application 302 includes service modules 304 and control module 306. The service modules 304 are program modules that include the actual code for the application 302, and are generally written as F,nter,prise JavaBeans, Servlets, or Java Server Pages. The Enterprise JavaBeans (EJBs) , Servlets, and Java Server Page implement the actual service logic of the application. The service modules 304 are managed by the runtime executive 210, which determines when and where to execute the service modules 304 Collaborating with the runtime executive subsystem 210 is the control module 306, which is a code module that includes application- specific policies for the Java application 302.
The application-specific policies included in the control module 306 can include policies for i-- 10 application start, application stop, application upgrade, application load balancing, and application failure recovery. 'I'o perform these policies, the control module 306 supervises the life cycle of the service modules 304 of the application 302, child applications, and the Java servers by collaborating with the runtime executive subsystem 210. As discussed in greater detail next with reference to Figure 3B, the application 302 can provide the control module 306, or the application 306 can use a generic control module 306, which the JAVA platform provides.
Figure 3B is a logical diagram showing a Java application execution paradigm 350 wherein generic control modules are injected into Java applications, in accordance with an embodiment of the present invention. Figure 3B shows two Java applications 302a and 302b executing in a container under the runtime management and supervision of the application runtiruc subsystem 202. As mentioned above, the application runtime subsystem 202 includes the runtime executive subsystem 210' which maintains the state of the runtime and coordinates the collaborations among the objects that implement the system.
Figure 313 further shows a glob-1 scheduler applications 352 having a strategy Enterprise JavaFicans module 354 Here, the application runtime subsystem 202 includes genetic implementations of control modules 30tia and 306b that are used for applications 302a and 302b' which do not provide custom contrail modules of their own. The global scheduler application 352 and strategy Enterprise lavaBeans module 354 provide the global scheduling and the application strategies and policies for both Java applications 302a and 302b. In particular, the global scheduler application 352 and strategy Entepase JavaBeans module 354 ensure the control modules 306a and 306b cooperate such that they do not interfere with each other, for example by executing each application 302a and 302b on a separate node. Thus, the embodiments of the present invention are able to provide platform independent application- specific policies and strategies for both applications having custom policies designed by the developer, and for applications that do not have custom policies.
Figure 4 is structural diagram of a Java application 302, in accordance with an embodiment of the present invention. As shown in Figure 4, a Java application 302 comprises one or modules 400, which provide the functionality for the application 302. Each module 400 can be any one of several service module 304 types, such as an Enterprise JavaBean module, a Web module, an Application Client module, or a Resource Adapter module. In addition, a module 400 of an application 302 can the a control module 306, which is a particular type of Enterprise JavaDean module.
In addition to pc'.ornung the operations discussed previously, the contra! module 306 can communicate with the control modules 306 of other applications using EJB invocations or other communication API supported by the Java platform. By communicating with each other, the control modules 306 of related applications can coordinate the policies for multiple applications (c.g. perform load-balancing of multiple applications). In addition, the control module 306 can corrmunicate with the application's 302 service modules 304 using EJB invocations or other communication API supported by the Java platform. By communicating with the service modules, the control modules can affect the functions of the service modules.
Moreover, the control module 306 can communicate with external applications. An external application can thereby affect the supervision of application's modules. Further the control module 3Q6 can use its recover-ahle ETB CMP state, because a Control Module 306 is an EJB Module, which the system manages in a highly available manner.
Figure 5 is a logical diagram showing an application-server relationship 500, in accordance with an embodiment of the present invention. As shown in Figure 5, an application 302 includes a control module 306 and one or more service modules 3()4, which are each allocated to a server process 502. In operation, each module has a parent module that supervises the module, including starting, stopping, and supervising upgrades of the module.
In the embodiments of the present invention, the control module 306 is the parent module of the service modules 304 of the application 302. Thus, the control module 306 starts each service module 304 and allocates the service module to a server process 502. In addition, a control module 306 can start a child application 3)2 by starting a control module 306 for that child application 302.
Figure 6 is an architectural diagram showing class structure for a Java system 600 in accordance with an embodiment of the present invention. The Java system 600 includes an application runtime having four main classes: Executive 210 J2EE Server 502, Application 302 and Module 304. Objects from these classes execute over a physical configuration 208 ol: a cluster 602 comprising several nodes 604 to form a distributed computer system. Typically the lava system 600 has one Executive object 210 and each node 6W in the cluster 602 runs zero or more THEE Servers 502 which can be a UNIX process running a lava virtual machine JVM) with the 12E13 runtime classes. However it should be noted that other ! As shown in Figure 6 each application object 302 comprises of one or more Nodules 304 which generally are the smallest unit for the purposes of runtime supervision in the Java system 600. Each Module 304 preferably is allocated to a single J2LE server 502 however a THEE server 51)2 can allocate multiple modules 304.
IS The executive 210 manages the application 302 module 304 and J2EE server 502 obects.'l'he management includes the orchestration of the use cases such as stats stop and upgrade of the Java system 600 and applications handling failures of the application 302 module 304 and J2EE server 502 objects The executive 210 also performs load balancing across the J2EE servers 502 and nodes 6()4 in the cluster 602. In operation the class files of an application's modules 304 are loaded from a single EAR 610 file in the repository 204. In particular the class files of each module 304 are loaded from a single module archive 6] 2.
In addition a module 304 may have a recoverable state managed by the Replicate State Manager (RSM) which is integrated info the J2EE server 502. The recoverable state includes the state of EJB CMP enterprise beans and to persistent message sent by tle bean but not processed yet by the recipients. If a module 304 has a recoverable state the recoverable state is replicated in a SSPartition object 616 in tle state server 614.
The class files of a J2EE server 502 are loaded from a J2EE server archive 60X in the repository 204. In general the system 600 includes a single repository 204 and one or more state servers 614 however other embodiments can include multiple repositories 204 depending on the particular system requirements. Multiple state servers 614 are used to provide support for different state management policies, and to achieve performance scalability by inning multiple state server 614 instances.
As previously mentioned, the control module 306 of the embodiments of the present invention can be used to manage other aspects of an application, including starting, stopping, and load balancing multiple child applications and modules. Figure 7 is a sequence diagram showing an application start sequence 700, in accordance with an embodiment of the present invention. The application start sequence 700 shows the interaction between a parent application control module 306, a child application control module 750, a runtime executive 210, a J2EE Server 502, a repository 606, and a state server 614.
The application start sequence 700 illustrates how a parent application's control module 306 initiates the start of a child application by creating the child application's control module 750. Broadly speaking, the parent applications control m.odule 306 allocates the child application's control module 7S0 to a specified J2EE server 502. The child application's control module 750 then coordinates the remainder of the child application's start up.
In operation 701, the parent application's control module 306 requests the executive 210 to start a child application. Tle request includes the JIBE server 502 in Chicle the executive 210 should allocate the child application's control module 7S0. The request may also include optional application-specific data to be passed to the child applicaton's control module.
The executive 210 then requests the J21;, server 502 to allocate tle child applicaton's control module 750, in operation 702. The J2EE server 502 then creates the child application's control module 750 and allocates the data structures that the J2EE server 502 needs to manage the child controlmodule 7S0 at runtinne, in operation 703. In addition, the J2EE server 502 loads the child application's control module 7S0 class files from the repository 61)6 into J2EE Server 502 memory, in operation 704 In operation 705, the J2EE Server 502 loads the child application's control module 750 recoverable state from the State Server 614 into the J2E Server 502 memory. The J2EE Server 502 then enables routing of incoming messages to child application's control module 750, in operation 706. Atter enabling routing of income messages to the child control module 7S0, other application modules can corr!municate with child application's control module 750.
Then, in operation 707, the J2EE Server 502 reports completion of module allocation to the executive 210.
In operation 70X, the executive 210 requests the child application's control module 750 to start the rest of the child application, which includes starting the child application's service modules, J2EE Servers, and child applications. The request can also include the application specific data passed from parent application's control module 306.
The child application's control module 750 then stare zero or more child J2EE Servers, in operation 709, using the Start J2ER Server sequence, discussed subsequently with respect to Figure 9. The child application's control module 75() starts zero or more service modules in operation 710, using the Start Module sequence, discussed below with respect to Figure 8. It should be noted that the child application's control module 750 may start the same service module multiple times and spread the instances across multiple J2EE Servers 502 and nodes to scale up the service module's throughput. In operation 711, the child application's control module 750 starts zero or more child applications using the Start Application sequence 700.
The child application's control module 750 then reports completion to the executive 210, in operation 712. The completion message may include optional application-specific data that child application's control module 750 wants lo pass to parent application's control module 306. The executive 210 then reports completion to parent application's control module 306.
This completion message preferably includes the application-specific data passed froth child application's control module 750 in operation 712.
In other embodiments of the present invention, the child application's control module 750 can report completion of "start children" before it starts up its child modules, JIBE Servers, and applications Thus, operations 712 and 713 can occur before operations 709, 710, and 711, or concun-cutly with them. In addition, the child application's control module 750 can perform operations 70'9, 710, and 711 in any order, and can perform them concurrently. Further, in operation 705, the child application's control module 750 may load only a part of its recoverable state from the State Server 614. The remaining parts can then be loafer when the child application's control module 750 needs them for computation.
Figure 8 is a sequence diagram showing a module start sequence BOO, in accordance with an embodiment of the present invention. The module start sequence 800 shows the interaction between a control module 30S, a service module 304, a runtime executive 21O, a J2EE Server 502' a repository 606, and a state server 614. In particular, the module start sequence 800 illustrates how an application7s control module 306 starts a service module 304 and allocates the service module 304 to a specified J2EE server 502.
In operation 801, the application's control module 306 requests the executive 210 to start a module 304. Preferably, the request specifies a particular J2EE Server 502 in which the module 304 should be allocated. The executive 210 then requests J2EE Server 502 to allocate the module 304, in operation 802.
In operation, 803, the J2EE Server 502 creates the module 304 and allocates the data structures that the JOEL server 502 steeds to manage the module 304 at run.tim^.e, and loads the module's class files from repository 606 into its memory in operation 804. In operation 805, J2EE Server 502 loads the module's recoverable state from Stale Server 614 into the J2EE Server rle...orj', and enables routing of inco;rr.g messages to the module 304, in operation 806 After enabling the routing of incoming messages to the module 304, other application modules and external applications can communicate with the module. The J2EE Server 502 then reports completion of module allocation to the executive 210 in operation 807, and the executive 210 reports completion to control module 306, in operation 808.
Figure 9 is a sequence diagram showing a J2EE server start secuencc 900, in accordance with an embodiment of the present invention. The 32EE server start sequence 900 shows the interaction between a control module 306, a runtime executive 210, a J2EE Server 502, and a repository 606. In particular, the J2EE server start sequence 900 illustrates how an application's control module 306 starts a new J2EE:! server process 502 on a specified node.
In operation 901, the control module 3()6 requests the executive 210 to start a J2EE Server 502. Generally, the request specifies the node on which to start the J2EIZ Server 502, and the version of the J2EE Server 502. Then, in operation 902, talc executive 210 creates the new J2F,E Server 502 on the specified node and requests the J2EE server 502 to initialize itself.
In response, the J2EE server 502 loads its class files from the THEE Server Archive in the Repository 606' in operation 903.
The J2EE server 502 then reports completion of its initialization to the executive 2 lO, in operation 904, and the executive reports completion to control module, in operation 905. Since the creation of a new]2EE Server 502 can be (-PU intensive, the implementation preferably ensures that the creation of a new J2EE Server SQ2 is performed at a lower priority than the processing of normal application-level requests by existing J2EE Servers on the same node.
Figures lOA and lOB are sequence diagrams showing a J2EE system start sequence 1000, in accordance with an embodiment of the present invention. The J2EE system start S sequence 1000 illustrates the start up sequence of the J2EE system Broadly speaking, an underlying Clustering Framework 602 starts a bootstrap program 216, which then creates the root J2EE server process 1052 on one node and a backup server process 1054 on another node.
The bootstrap program 216 then requests the root J2EE Server 1052 to create a root system application by creating its control module 306. The executive 210 then starts other system modules and applications. Then, the executive 210 starts a l'op User Application, which recursively starts up other user applications.
Initially, in operation 1001, the underlying Clustering Framework 602 starts the repository 606. In one embodiment, the repository 606 is implemented as a high availability service within the Clustering Framework 602. In operation 1002, the Clustering Framework 602 starts the state server 614, and, if there are multiple state servers 614, all state servers 614 are started. As with the repository, in some embodiments of the present invention, the state server 614 is implemented as a high availability service within the Clustering}framework 602.
Then, in operation 1003, the Clustering Framework 602 starts an instance of the bootstrap program 216.
- 20 In operation 1004, the bootstrap program 216 starts a root J2EE Server 1052 process using an extension of the TREE Server start sequence 900. in addition, in operation 1005, the bootstrap program 216 uses an extension of the J2EE Server start sequence 900 to start a root J23*F, Server Backup 1054 process. Then, in operation 1006, the bootstrap program 216 requests root J2EE Server 1052 to start the root system application. The Root J2EE Server 1052 then starts the roof system application by allocating the control module, which is the module implenenling the executive 210, in operation 1008. After starting the root system application, the Root J2ee Server l 052 loads the executive's class files From the repository 606, in operation 1009, and, in operation 10107 the Root J2E!E Server 1052 loads the executive's recoverable state from the state server 614.
h operation 1011, the Root J2EE Server 1052 requests the executive 210 to start the root system application. It should be rioted that the executive 210 functions as the control 1' module for the root system application. In response, the executive 210 requests itself to start the root system application's other modules, J2EE servers, and child system applications using the module start sequence 800, J2EE Server start sequence 900, and application start sequence 700, in operation 1011. In this capacity, the executive 210 functions as the parent control module in these start sequences.
The executive 210 also requests itself to start the top user application, in operation 1012, using the application start sequence 7'00, and acts as the parent control module in this use case.
In response, the executive 210 allocates the top user application's control module 306 and requests the control module 306 to the start the top user application, in operation 1013.
In operation 14, the top application's control module 306 starts other modules, J2EE Servers, and child applications. Starting of child applications leads to recursion, which results in setting all J2EE applications. Then, Ill operation 1015, the top user application's control module 306 reports completion of the start children request to the executive 210. In response, the executive 210 reports completion to the root J2EE server 1052, in operation 1016, and, in operation. 1017, the root systc n application's control module reports completion to the root J2EE server.
Figures 11-14 illustrate stop sequences used by control modules of the embodiments of the present invention. In particular, Figure l l is a sequencing diagram showing an application stop sequence 1100, in accordance with an embodiment of the present invention. 'I'he application stop sequence 1100 illustrates how a parent application's control module 30G stops a child application by requesting to stop the child application's control module 750. The child application's control module 75V stops the application's service modules 304 and child applications.
In operation llOI, the parent application's control module 306 requests the executive 210 to stop a child application. In response lo the request, the executive 210 sends a stop control module request to the child application's control module 750, in operation 1102. Next, in operation 1103, the child application's control module 750 requests the executive 210 to stop its child application. the child application's control module 750 repeats this step for all its child applications by recursively applying the application stop sequence 1100. When the child applications of the child application's control module 750 are stopped, the executive reports completion of the request, in operation 1104.
- The child application's control module 750 then requests the executive to stop a service module, in operation 1105. The child application's control module 750 repeats this request for all the application's service modules, using the module stop sequence 1200 discussed subsequently with reference to Figure 12. When the executive 210 completes the requests, in operation 1106, the executive 210 reports completion of the requests initiated in operation 1105. The child ayplication's control module 750 then, in operation 1107, requests the executive 210 to stop a 12EE Server 502, and repeats this operation for all its child J2EE Servers 502 using the J2EE Server stop sequence 1300 discussed below with reference to Figure 13. The executive reports completion of the stop J2EE server requests in operation 1108.
In response, the child application's control module 750 reports the completion of the stop control module request to the executive 210.
Next, in operation 1110, tle executive 210 requests the J2E!E Server 502 running the child application's control module 750 to deallocate the child application's control module 750.
In response, the J2EE Server 502 disables child application's control module 750 from receiving new requests, in operation 1111. In addition, the J2EE Server 502 writes any unsaved recoverable state of child application's control module 750 to the state server 614, in operation 1112. Then, in operation 1113, the J2EP, Server deletes child ayplication's control module 750.
Once the control module 750 is deleted, the J2EE Server 502 reports completion to the executive 210, in operation 1114, and the executive 210 reports completion to the parent application's control module 306, in operation 1115.
Figure 12 is a sequencing diagram showing a module stop sequence 1200, in accordance with an embodiment of the present invention. The module stop sequence 1200 illustrates how an applications control module 306 stops a service module 304 Initially, in operation 1201, the control module 306 requests the executive 210 to stop a service module 304 In response, the executive 210 requests the J2EE Server 502 running the module 304 to deallocate the module 304, in operation 1202.
The J2EE Server 502 then disables the module 304 from receiving new requests, in operation 1203, and writes any unsaved recoverable state of the module to the state server 614, in operation 1204. '1 he J2EE Server 502 then deletes the module from its memory, in operation 1205. In operation 1206, the J2EE Server reports completion to the executive 210, and then the executive reports completion to the control module 306' in operation 1207.
Figure 13 is a sequencing diagram showing a J2EE server stop sequence 1300, in accordance with an embodiment of the present invention. The J2EE server stop sequence 1300 illustrates how an applications control module 306 stops a J2EE server process 502. Lnitially, in operation 1301, the control module 306 that started J2EE Server 502 requests the executive 210 to stop J2EP Server 502. Then, in operation 1302, the executive 210 checks whether there are any modules allocated to the J2EE Server 502. If there are any modules allocated to J2EE Server 502, the executive 210 reports an error to the control module 306.
If there are no modules allocated to the J2HE Server 502, the executive 210 requests J2EE Server 502 to delete itself by freeing all resources and exiting, in operation 1303. The completion of the delete request is then reported to the executive 210, in operation 1304, and the executive 210 reports completion to the control niodule 306, in operation 13()5 Figure 14 is a sluencing diagram showing a J2EE system stop sequence 1400, in accordance with an embodiment of the present invention. The J2EE system stop sequence 14()0 illustrates the shutdown of the J2EE system. Broadly speaking, the underlying Clustering Frarne.work 602 requests the bootstrap program 216 to stop the J2EE system. The bootstrap program 216 stops the Root System Application, which recursively stops all user and system applications. Then the bootstrap program 216 stops the root J2EE server 1052.
Initially, in operation 1401, the underlying Clustering Framework 6()2 requests the bootstrap program 216 to stop JIBE system. in response, the bootstrap program 216 requests 2() the root J2EE server 1052 to stop the root system application, in operation 1402. In operation 1403, the roof J2EE server 1052 requests the executive 210, which is root system application's control module, to stop. The executive 210 then requests itself to stop the top user application by using the application stop sequence 1100.
In operation 1405, the executive 210 requests the top user applicaton's control module 306, to stop. In response to the requests the top user application's control module 306 requests the executive 210 to stop child applications, J2E, servers, and the top user application's other modules, in operation 1406. To this end, the top user application's control module 306 uses repeatedly the application stop sequence 1100, the J2EE Server stop sequence 1300, and module stop sequence 1200 to pcrfonn this task.
In operation 1407, the top user application's control module 306 reports completion of the stop children request to the executive 210. The executive 210 then requests the root J2EE Server 1052 to deallocate the fop user application's control module 306, in operation 1408. In response, the root J2EE Server 1052 disables requests to the top user application's control module 306, in operation 1409, and writes any unsaved recoverable state of the top user application's control module 306 to the state server 614, in operation 1410. Then, in operation 1411, the root J2EE Server 1052 deletes the top user application's control module 306 from its memory, and reports completion to the executive 210, in operation 1412.
Thereafter, in operation 1413, the executive 210 stops child system applications, other - 10 root system application's modules, and 12EE servers. The executive 210 uses repeatedly the application stop sequence 1100, J2EE Server stop sequence 1300, and module stop sequence 1200 to perform this task. The executive 210 then, in operation 1414, reports completion of the stop request from operation 1403 above.
In operation 1415, the root J2EE Server 1052 disables requests to the executive 210.
The root J2EE Server 1052 then writes any unsaved recoverable state of the executive 210 to the state server 614, in operation 1416, and then deletes the executive 21() from its memory, in operation 1417. Thereafter, the root J2EE Server 1052 reports completion to the bootstrap program 21G, in operation 1418.
After receiving the completion report from the root J2EE server 1052, the bootstrap program 216 stops the root J2EE server process backup 1054, in operation 1419. Then, in operation 1420, the bootstrap program 216 stops the root J2EE server process 1052. At this point, the Cluster Framework 602 stops the state server subsystem 614, in operation 1421, and then stops the repository subsystem 606, in operation 1422.
In addition, to starting and stopping child applications and modules, the control module of the embodiments of the present invention can perform load balancing of multiple child applications and modules. Figure 15 is a functional diagram showing load balancing operations 1500 used by control modules for load balancing a J2EE system, in accordance with an embodiment of the present invention. The load balancing operations include monitoring resources functions 1502, such as CP[J and memory utilization, and reallocating resources functions 1508.
In operation, a control module makes a request to the system for the status of system resources, shown as polling resource usage functions 1504 in Figure 15. The request's parameters specify a set of resources of interest to the control module, for example, CPU or memory utilization of a J2EE Server or of an entire node. The system then returns the status of the specified resources. In other embodiments, using notify resource usage functions 1506, a control module can request the system to be notified if the utilization of specified resources exceeds some specified limits instead of polling the status of resources. This notification approach can be used to eliminate wasteful polling When necessary, a control module can use reallocate resource functions 1508 to reallocate computing resources to an application's modules A control module can make a decision how to reallocate the computing resources based on an application-specifc policy designed into the control module. The policy can be implemented by the control module itself, or by another application with which the control module communicates, such as a "Load- Balancer" service that monitors the utilization of the computing resources and makes the lS decisions how the resources should be optimally allocated to the J2EE applications When load balancing a J2EE system, a control module can request the system to change the CPU priorities of some modules or J2EE servers to ensure that high-priority applications respond to requests in a bounded time In addition, an application's control module can request the system to move a module from one J2ER server to another 12EE server located on a different node that has some spare CPU capacity using move module functions 1510.
Figure 16 is a sequence diagram showing a module move sequence 160O, in accordance with an embodirncnt of the present invention. The module move sequence 1600 illustrates how an application's control module 306 moves a service module 304 from a first J2EE server 502a to a second WEE server 502b.
Initially, in operation 1601, the control module 306 requests the executive 210 to move a first service module 304a from the first]2EE Server 502a to the second J2EE Server 502b In response, the executive 210 requests the second J2EE Server 502b to take over the allocation of the first service module 304a, in operation 1602. To begin the take over, in operation 1603, the second J2EE Server 502b creates a second service module 502b object and allocates the resources for it. The second J2EE Server 502b then loads the second service module's 304b class files from the repository 6()6, in operation 1604 When code for the second service module 304b is ready, in operation 1605, the second J2EE Server 502b requests the first J2EE Server 502a to give up allocation of the first service module 304a In response to the request, the first J2EE Server 502a disables applications' requests to the hrst service module 304a, in operation 1606. The system will then hold all requests to the first service module 304a. The first J2EE Server 502a then transfers the RSM state of the first service module 304a to the second J2EE Server 502b, which then makes the RSM state available to the second service module 304b$ in operation 1607.
In operation 1608, second J2EE Server 502b enables the second service module 304a to receive requests from other modules and external applications. The second J2EE Server 502b - 10 then reports completion to the executive 210, in operation 1609, and the first J2EE Server 502a deletes the first service module 304a in operation 1610. Thereafter, in operation 1611, the executive 210 reports completion to control module 306.
As previously mentioned, the embodiments of the present invention can perform online upgrades to software. Specifically, the embodiments of the present invention can be used in service-provider environments that require a mechanism to perform online upgrades of an application. lJsing the embodiments of the present invention, a system can continue to provide services to clients while a software upgrade is being performed. Advantageously, the embodiments of the present invention allow an online upgrade to occur generally without any detectable impact on the clients using the services provided by the application during the upgrade.
Figure 17 is a sequence diagram showing an application upgrade sequence 1700, in accordance with an embodiment of the present invention. The application upgrade sequence 1700 illustrates how a parent applications control module 306 upgrades a child application.
Broadly speaking, the child application's control module is upgraded inplace. Then, the child application's control nodule upgrades the application's JIBE servers, service modules, and child applications.
More specifically, in opcraton 1701, the parent application's control module 306 requests the executive 210 to upgrade a child application. Advantageously, the request can include optional application-specific data that the executive 210 will pass to the target application's control module. Next, in operation 1702, the executive 210 requests the J2EE Server 502 running the application's old control module 1750 to upgrade the old control module 1750.
In response, the J2F,12 Server 502 begins the upgrade by loading the class files for the upgraded physical RSM schema of the control module from the repository 606, in operation 1703. The WEE Server 502, in operation 1704, then performs an online upgrade of the control module's stale Lo the new physical schema. 11 necessary, the J2EE Server 502 can upgrade the control module's state server partitions in the state server 614 to the new slate schema, in operation 1705.
The J2EE Server 502 then creates a new instance 1752 of the old control module 1750, in operation 1706, and loads the new class files for the new control module 1752, in operation 1707. After loading the new class files, the J2EE Server 502, in operation 1708, disables requests to the old control module 1750, and enables requests to new control module 1752. In this manner, requests from other application modules or from external applications can now be directed to the new control module 1752. The J2EE Server 502 then deletes the old control module 1750, in operation 1710, and reports completion to the executive 210, in operation 1711.
b operation 1712, the executive 210 requests the new control module 1752 to continue the upgrade. In response, the new control module 1752 upgrades all child J2EE Servers, in operation 1713. The new control module 1752 also upgrades all application service modules, in operation 1714, and upgrades all child applications by recursively using the application upgrade sequence 1700, in operation 1714.
When all the application's scivice modules, child J2EE servers, and child applications have been upgraded, the new control module 1752 reports completion to the executive 210, in operation 1716. The completion message may include optional application-specific data to be passed to the parent application's control module 306. Then, in operation 1717, the executive 21.0 reports completion to parent applications control module 306, passing the application specific data from the new control module 1752.
Figure 18 is sequence diagram showing a module upgrade sequence 1800, in accordance With an embodiment of the present invention. The module upgrade sequence 1800 illustrates how an application's control module 31) 6 upgrades a service module 304. Using the embodiments of the present invention, the upgrade can be performed in-place with no disruption in service.
In operation 1801, the application's control module 306 requests the executive 210 to upgrade a service module 304a. In response, the executive 210 requests the J2EE Server 502 running the service module 304a to upgrade the service module 304a, in operation 1802 The J2EE Server 502 begins the upgrade, in operation 1803, by loading the class files for the upgraded service module's physical RSM schema from the repository 606. operation 1804, the J2EE Server 5V2 performs an online upgrade of the module's state to the new physical schema. If necessary, the J2EE Server 502 upgrades the module's state server partitions in the state server 614 to the new CMP schema, in operation 1805.
Then, in operation 1806, the J2EE Server 502 creates a new instance 304b of the old service module Tea, and loads die new service nmodule's new class files into the new service module 304b, in operation 1807. In operation 1808, the J2EE Server 502 disables requests to the old service module 304a, and temporarily holds all incoming requests. Next, in operation 1809, the J2ER Server 502 enables requests to the new service module 3{14b. Thus, requests from other application modules or from external applications can now be directed to the new service module 304h. 'l'hen, in operation 1810, the J2EE Server 502 deletes the old service module 304a, and reports completion to the executive 210, in operation 1811. 'I'hereat'ter, the executive 210 reports completion of the upgrade to the control module 306. Advantageously, the service module can remain online, processing requests from other modules or external applications, during the execution of the module upgrade sequence 1800.
Figure 19 is a sequence diagram showing a J2EE server upgrade sequence1900, in accordance with an embodiment of the present invention. The 32EE server upgrade sequence 1900 illustrates how an applicaton's control module 306 upgrades a child J2EE server 502a.
The upgrade is realized lay starting an upgraded version of the J2EE server, and transferring to the new J'2EE server 502b the modules that are allocated to the old J2EE server 502a.
Specifically, in operation 1901, the old J2EE Server's parent control module 306 requests the executive 210 to upgrade old J2EE Server 502a to a new software version. In response, the executive creates a new J2EE Server 502b, in operation 1902. The new J2EE: Server 502b is a J2EE! Server process running on the same node as old J2EE Server 502a lichen, in operation 1903, the now J2EE Server 502b loads its class files from the upgraded J2EE Server Archive in the repository G06, and reports completion of the new J2EE Server 502b initialization to the executive 210, in operation 1904 Next, in operation 1905, the executive 210 requests the new J2EE Server 502b to take over the modules from the old J2EE Server 502a To perform this operation, the module move sequence 1600 of Figure 16 is used. After taking over each module from the old J2EE Server 502a, the new J2EE server 502b reports completion to the executive 210, in operation 1906.
Operations 1905 and 1906 are repeated for all the modules that are allocated to the old J2EE Server 502b.
The executive 21Q then requests the old J2E:E Server 502a to delete itself. in operation 1907. Thereafter, in operation 190B, completion of deletion of the old J2EE Server 502a is reported to the executive 210, and the executive 210 reports completion to control module 306, inoperatioi; 1909.
Figures 20, 21, and 22 are sequence diagrams showing how an underlying clustering framework uses the embodiments of the present invention to upgrade a carrier grade J2EE system and executing J2EE applications to their new software versions Specifically, Figure 20 is a sequence diagram showing a service subsystems upgrade sequence 2000, in accordance with an embodimcut of the present invention The service subsystems upgrade sequence 2000, illustrates how the repository 606, state server 614, and the root J2EES server backup process 1054 arc upgraded to the new version of software.
In operation 2001, the underlying high availability Clustering Framework 602 upgrades the repository 606, which is preferably implemented as an 11A service within the Clustering Framework 602 The Clustering Framework 602 then upgrades the state server 614, in operation 2002.
In operation 2003, the Clustering Framework 602 requests upgrade of the bootstrap program 216. Then, in operation 2004, the bootstrap program 216 creates a new instance 1054b of the root old J2EE server backup process 1054a The new Root JIBE Server Backup 1054b then starts up and loads its class files from the new version of the J2EE Server Archive, in operation 2005 h operation 2006, the new Root J2EE Server Backup 1054b reports completion to the bootstrap program 216, and the bootstrap program stops the old instance of the root J2EE Server process backup 1054a After upgrading the service subsystems, the root J2EE server is upgraded to the new version.
Figure 21 is a sequence diagram showing a root J2EE server upgrade sequence 2100, in accordance with an embodiment of the present invention. The root J2EE server upgrade sequence 2100 illustrates how the root J2EE server process 1052 and other system applications arc upgraded to the new versions.
In operation 2101, the bootstrap program 216 requests the old version of the root 12EE server 1052a to perfonn an upgrade to the new version of its class files. In response, the old Root JEER Server 1052a requests the executive 210a to coordinate the upg.ale, in operation 2102. The executive 210a then creates a new version of the root J2EE server 1052b, in operation 2103.
In operation 2104, the new Root J2EE Server 1052b loads its class files from the new J2EE Sewer Archive in the repository 606. The new Root J2EE Server 1052b then reports completion to the executive 210a, in operation 2105. Next, in operation 2106, the executive 210 requests new Root 32EE: Server 1052b to take over the executive module 210a In response, the new Coot J2EE Server 1052b creates a new instance of the executive 210b, in operation 2107. In operation 2108, the new Root J2ELE Server 1052b requests the old Root J2EE Server 1052a to give up the allocation of the executive module 210a. In response, the old Root J2EE Server 1052a disables requests to the executive 210a, in operation 2109.
Next, in operation 211O, the old Root 12EE Server 1052a transfers the old executive's RSM state to the new Root J2EE Server 1052b, and the new Root J2EE Server 1052b makes the state available within its RSM to the new executive 210b.
The new Root J2EE Server 1052b, in operation 2111, then enables the new executive 210b to receive requests. 'thereafter, in operation 2112, the new Root J2EE Server 1052b reports completion to tile new executive 210b. As shown in the root J2EE server upgrade sequence 2100, the message is routed by the system to the new executive 210b.
In operation 2113, the new executive 210b continues the execution of the root J2EE server upgrade sequence 2100 by requesting the new Root J2EE Server 1052b to take over the allocation of other modules from the old Root J2EE Server 1052a As shown in Figure 21, the take over begins with the take over of the top user application's control module.
In operation 2114, the new Root J2EE Server 1052b reports completion to the executive 210b. The executive 210b then reports completion to the old Root J2EE Server 1052a? which is the initiator of the root J2EE server upgrade sequence 2100. Next, in operation 2116, the old Root J2EE Server 1052a reports completion to the bootstrap program 216, and the bootstrap program 216 stops the old Root J2EE Server 1052a using the J2EE Server stop sequence 1300 of Figure 13. After upgrading the root J2EE server, the applications, starting with the root system application, are upgraded to the new version.
Figure 22 is a sequence diagram showing a root system application upgrade sequence 220a, in accordance with an embodiment of the present invention. The root system application upgrade sequence 2200 illustrates how the root systerr. applicatiori and other system applications are upgraded to their new versions.
In operation 2201, the bootstrap proy?rarn 216 requests the new Root J2EE Server 1052b to upgrade the root system application. In response, the new Root J2EE Server 1052b requests the executive 210b to upgrade the root system application. The executive 210b then requests the new Root J2F.Ff Server 1052b to upgrade the root system application's control module, which is the executive 210b itself, in operation 2203.
In operation 2104, the new Root J2EE Server 1052b loads the executive's RSM physical schema class files, and in operation 2105, the new Root J2EE Server 1)52b upgrades the RSM state to the new physical schema. If necessary, the new Root J'2EE Server 1052b requests the State server 614 to upgrade the executive's SSPartitions to the new schema, in operation 2206.
Then, in operation 2207, the new Root J2EE Server 1052b creates a new instance 210c of executive 210b, and loads the new executive's 210c upgrade class files from the repository 606, in operation 2208. The new Root J2EE Server 1052b then, in operation 2109? disables requests to the second executive 210b, which is the older version of the new executive 210c.
In operation 2210, the now Root J2EE Server 1052b enables requests to the new executive 210C? and deletes the old executive 210b, in operation 2211. 'I'he deletion can be done in the background. In operation 2212, the new Root J2EE Server 1052b reports completion to the executive 210c. The new executive 210c then requests the root system application's control module, which is the new executive 210c itself, to continue with upgrading the application.
In response, the new executive 210c uses the module upgrade sequence 1800, the J2EE server upgrade sequcace l90CI, and the application upgrade sequence 1700 to upgrade the root system application's other modules, its child J2EE Servers, and arty child system application, in operation 2214 When the executive 210c finishes upgrading the system applications, the executive 2 lOc requests the upgrrade of the top user application, in operation 2215. This leads to a recursive upgrade of all running J2EE applications The executive 210c then reports completion to new R.oot J2EE Server l052b, in operation 2216, and the new Root 12F,E Server 1052b reports completion to the bootstrap program 216, in operation 2217.
Although tl.e foregoing invention has be n described in som' detail for purposes of clarity of understanding, it will be apparent that certain changes and modifications may be practiced within the scope of the appended claims. Accordingly, the present embodiments are to be considered as illustrative and not restrictive, and the invention is not to be limited to the details given herein, but nary be nodited within the scope and equivalents of tle appended claimers.
I;urtlier aspects are set out in the following numbered clauses: 1. A method for peTIonning an online upgrade to a Java application, the method comprising.
executing an application having an original service module and an original control module, wherein The original control module includes application-specific polices for tle application; generating an upgraded control module; and creating an upgraded service module using the upgraded control module, whereby the original control module and the original service module are upgraded.
2. A method as recited in clause 1, wherein the upgraded control module is generated using upgraded class files for the upgraded control module loaded from a system repository.
3. A method as recited in cleanse 1, whcren the upgraded service module is generated using upgraded class files for the upgraded service module loaded from a system repository.
4 A method as recited m clause 3, further comprising the operation of disabling requests to the original service module.
5. A method as recited in cluse4, further comprising the operation of enabling requests to the upgraded service module.
6. A method as recited in cl,Sel, further comprising the operation of upgrading child application using the upgraded control module.
7. A method as recited include 6, further comprising the operation of passing the application-specifc polices to a control module of the child application.
8. A Java platform capable of performing online software upgrades, the Java platform cornpTising: an application having an original service module and an original control module, wherein the original control module includes applicaìon-specifi.c polices for the application; and a repository having upgraded class files for the original control module and upgraded class files the original service module, wherein the original control module is upgraded by generating an upgraded control module using the upgraded class files for the original control module loaded from the repository, and wherein the original service module is upgraded by creating an upgraded service module using the upgraded control module.
!3. A Java platform as recited in closes, wherein the upgraded service module is generated using upgraded class flies cot- the original service module loaded from the repository.
1) A Java platform as recited in clawed, wherein requests to the original service module are disabled during upgrade of the original service module.
11. A Java platform as recited in clauselO. wherein requests to the upgraded service module are enabled during upgrade of the original service module 12 A Java platform as recited in clauses wherein the upgraded control module is capable of initiating the upgrade of a child application.
13. A Java platform as recited incise 12 wherein the application-specific polices are passed to a control module of the child application during the upgrade of a child application 14. A method for upgrading a lava platform comprising the operations of: upgrading service subsystems wherein the service subsystems include a repository; upgrading a root Java server process; upgrading a roof system application; and recursively upgrading user applications currently executing of the Java platform 15. A method as recited in clnuse14 wherein upgrading the service subsystems comprises the operations of: creating an upgraded root Java server backup process using a bootstrap program; and slopping execution of an original root Java server backup process using the bootstrap program.
16. A method as recited in clause15 wherein upgrading the root Java server process comprises the operations of: generating an upgraded root Java server using a first runtime executive; loading upgraded class files for the upgraded root Java server from the repository; transferring the runtime executive to the upgraded root Java server, and allocating modules allocated to the original root Java server to the upgraded root Java server.
17. A method as recited in clause 16, wherein transferring the runtirne executive to the upgraded root Java server comprising the operations of: creating a second runtime executive using the upgraded root Java server; disabling requests to the first runtime executive; transferring a state of the first runtime executive to the second runtime executive; and enabling requests to the second runtime executive.
18. A method as recited in clause 17, wherein upgrading the root system application comprises the operations of: creating an upgraded runtime executive using the upgraded root Java server; and upgrading service modules of the root system application using the upgraded runtime executive.
19. A method As recited in clausel8, further comprising the operation of upgrading a child system application A method as recited in clause 19 further comprising the operation of upgrading a top user application.
21. A method as recited inclause20 further comprising the operation of recursively upgrading remaining user applications currently executing on the Java platform

Claims (11)

  1. Claims 1. A method for upgrading an object oriented programming language
    platform, comprising the operations of: upgrading service subsystems, wherein the service subsystems include a repository; upgrading a root object oriented programming language server process; upgrading a root system application having an original control module wherein the control module includes application-specific policies for the root system application; and recursively upgrading user applications currently executing of the object oriented programming language platform, wherein the user application is executed in a middle-tier between a client browser and databases having an original service module.
  2. 2. A method as recited in claim 1, wherein upgrading the service subsystems comprises the operations of: creating an upgraded root object oriented programming language server backup process using a bootstrap program; and stopping execution of an original root object oriented programming 2 0 language server backup process using the bootstrap program.
  3. 3. A method as recited in claim 2, wherein upgrading the root object oriented programming language server process comprises the operations of: generating an upgraded root object oriented programming language server using a first runtime executive; loading upgraded class files for the upgraded root object oriented programming language server from the repository; transferring the runtime executive to the upgraded root object oriented p!Ogram^uning language server; and allocating modules allocated to the original root object oriented programming language server to the upgraded root object oriented programming language server.
  4. 4. A method as recited in claim 3, wherein transferring the runtime executive to the upgraded root object oriented programming language server comprising the operations of: creating a second runtime executive using the upgraded root object oriented programming language server; disabling requests to the first runtime executive; transferring a state of the first runtime executive to the second runtime executive; and enabling requests to the second runtime executive.
  5. 5. A method as recited in claim 4, wherein upgrading the root system application comprises the operations of: creating an upgraded runtime executive using the upgraded root object oriented programming language server; and upgrading service modules of the root system application using the upgraded runtime executive.
  6. 6. A method as recited in claim 5, further comprising the operation of upgrading a child system application.
  7. 7. A method as recited in claim 6, further comprising the operation of upgrading a top user application.
  8. 8. A method as recited in claim 7, further comprising the operation of recursively upgrading remaining user applications currently executing on the object oriented programming language platform.
  9. 9. An upgraded object oriented platform comprising: an upgraded root object oriented programming language server; an upgraded service subsystem; an upgraded root system application having an upgraded control module 2 0 wherein the upgraded control module includes application-specific policies for the root system application; and an application executing on the upgraded object oriented programming language platform.
  10. An upgraded object oriented programming language platform of claim 9, further includes, an upgraded repository which holds upgraded class files for the upgraded root object oriented programming language server.
  11. 11. An upgraded object oriented programming language platform of claim 8, wherein the application is configured to be upgraded recursively.
    11. An upgraded object oriented programming language platiGorn,' of claim 9, further comprising: an upgraded runtime executive; and an upgraded service module.
    12. An upgraded object oriented programming language platform of claim 9, wherein the application is configured to be upgraded recursively.
    Amendments to the claims have been filed as follows Claims 1. A method for upgrading an object oncnte1 progT-an1ming language piatti, i-..i, coi,i;'iising the o'erati.iris of-'.
    upgrading service subsystems, wherein the service stbsystems include a repository; upgrading a root object o dented progrramming language server process; upgrrading a root system application having,, an original control module llrli/ Lll, J'lJ1 17JI; Ilu, dl'llaLl('I7-',7lllL J('ilUles i()l Lilt 100t system application; and recursively upy,radi.7lg user applications currently executing on the object oriented programming language platform, wherein the user applications are executed in a niiddle-tier between a client browser and databases having, a service module.
    2. ncthod as recited in claiin 1, whcreii1 upg7ia1i?1,7 the service sthiystelns comprises tle operations of: crc.tnr, an upgraded root object oriented pr7g,ra'7nning language server hackup process using a boot strep programed; and stopping, executii'n ol an original robin object <-> rieuicd pro,g,ran1miTIg 1;,,,-,j,,,,,,, ;,-7- ,7- 7,,-1,,' n,/,f In. ,, care I;,, a. lo,, 3. A n tithed as recited n1 cian-,1 2. vvherci^l u73ladill7 tlic 30(3t Dialect 0rl('ll{C( 7t,, t!!1' l,ll1< 73a<,e Arm,1'')!""' {.7tisc:bs the All'<-, 't Bitt: Al requesting to perform an upgrade ot an original root object oriented programming language server process by the boot strap program; s; encratint, a Die w Oberon of the original root object oriented pro,.- amiriing language server process; ioadrng upgraded class tiles for the new version ofthe original root object o.ierted Hlog-an,imii,g language server process frown tile repository; transferring the rur1tiTne executive to the new version of the original root object oriented programming language server process; and allocating modules allocated to the original root object oriented n programming language server process to the new version of the original root ob ject orientecl programming language server process.
    4. A methoci as recited in claim 3, wherein transferring the runtime executive to the new version of the root object oriented programming language server process comprising the operations of: creating a second runtime executive using the new version of the original root object oriented progr-amn1ing language server process; disabling recluests to the first retina executive; tran.slerri!Tgg a state of the first rintnJlc cecut;Ne to the secoTId rurtinc i () exec Gove; and enabling requests to the second ruiltime cecutrve. To
    5. A method as recited m claim 4, wherem upgrading the root system application comprises the operations of: creating an upgrr,de.l nrltime cxcelJtie using the uptrradcd root object oriented programming language server; and upg,ra<:img service modules of the root system application using talc upgraded n;n.;inc executive.
    fi,,,^A clhd aft r;cit3 ilk!:l.?i! A, 0l!-tl-r cr.npsinY, file,Cf:.i.i. If' upgrading,, a child system application. 1()
    7. A method as recited ul claim fj, further comprising the operation of upgrading a top user application.
    8. An upgraded object oriented platfonn comprising: an upgri-aded root ol:ject oriented progranmingY, language server; an upgraded.scrxiice subsystem; ail. ryg-P'riert rat sysle,i lllicatii Ia\ir', Eli:,,-acle'.i C!tol lod''le wlierciii.hc upg,radccl coitiol module includes ipplicati<, i1-stccfic polcics for the .1 cacti 'l t111'(..,'tir\' :i',,1 a user application executing, on the upgraded object oriented programming laY,aY,e plc:Itl()nIl.
    J. An upgra(led object oriented programming language platform of claim 8, further inclucles, an rpgraled rf yositc!ry which holds upgraded class Tries for tlc upgraded root old Act oricuted programming language server process. )
    1(). An upgraded object oriented programming language piatf->nn of claim 8, iuTther comprising: -I an,nf;-rlerl rl.7n'.> -f.7i7,,= ..,,1 an upgraded service module.
GB0512569A 2001-04-11 2002-04-05 Performing upgrades of a Java platform Expired - Lifetime GB2411995B (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US09/833,845 US7370322B1 (en) 2001-04-11 2001-04-11 Method and apparatus for performing online application upgrades in a java platform
GB0323800A GB2391365C (en) 2001-04-11 2002-04-05 Method and apparatus for performing online application upgrades in a Java platform

Publications (3)

Publication Number Publication Date
GB0512569D0 GB0512569D0 (en) 2005-07-27
GB2411995A true GB2411995A (en) 2005-09-14
GB2411995B GB2411995B (en) 2005-10-26

Family

ID=35058659

Family Applications (1)

Application Number Title Priority Date Filing Date
GB0512569A Expired - Lifetime GB2411995B (en) 2001-04-11 2002-04-05 Performing upgrades of a Java platform

Country Status (1)

Country Link
GB (1) GB2411995B (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015028538A1 (en) * 2013-09-02 2015-03-05 Agfa Healthcare A method and system for upgrading software

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106909410B (en) * 2015-12-23 2024-04-30 鼎捷软件股份有限公司 Updating method for server system and server system

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0807883A2 (en) * 1996-05-06 1997-11-19 Philips Patentverwaltung GmbH Communications system with means for exchanging software processes
US6175855B1 (en) * 1996-12-20 2001-01-16 Siemens Aktiengesellschaft Method for instantiating a class having different versions

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0807883A2 (en) * 1996-05-06 1997-11-19 Philips Patentverwaltung GmbH Communications system with means for exchanging software processes
US6175855B1 (en) * 1996-12-20 2001-01-16 Siemens Aktiengesellschaft Method for instantiating a class having different versions

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015028538A1 (en) * 2013-09-02 2015-03-05 Agfa Healthcare A method and system for upgrading software

Also Published As

Publication number Publication date
GB2411995B (en) 2005-10-26
GB0512569D0 (en) 2005-07-27

Similar Documents

Publication Publication Date Title
US7370322B1 (en) Method and apparatus for performing online application upgrades in a java platform
US7165108B2 (en) Method and apparatus for providing application specific strategies to a JAVA platform including load balancing policies
US20220004381A1 (en) Integration of containers with external elements
KR101574366B1 (en) Synchronizing virtual machine and application life cycles
US6928579B2 (en) Crash recovery system
US7069551B2 (en) Method of administering software components using asynchronous messaging in a multi-platform, multi-programming language environment
US7130897B2 (en) Dynamic cluster versioning for a group
US7392374B2 (en) Moving kernel configurations
US20040243997A1 (en) Method, system, and program for installing program components on a computer
US6912569B1 (en) Method and apparatus for migration of managed application state for a Java based application
US5961642A (en) Generic kernel modification for the dynamic configuration of operating systems in a multi-processor system
US20120272204A1 (en) Uninterruptible upgrade for a build service engine
WO1993020511A1 (en) An integrated remote execution system for a heterogenous computer network environment
US10795688B2 (en) System and method for performing an image-based update
US6922796B1 (en) Method and apparatus for performing failure recovery in a Java platform
US20040098450A1 (en) Method and apparatus for providing a unified component architecture for client-side and server-side components
US5968170A (en) Primary swap size increase on a UNIX based computer system
US7177934B2 (en) Method and apparatus for providing application specific strategies to a JAVA platform including start and stop policies
US20080263183A1 (en) Management of Kernel configurations for nodes in a clustered system
CN113448686A (en) Resource deployment method and device, electronic equipment and storage medium
US20060069909A1 (en) Kernel registry write operations
US7467328B2 (en) Kernel configuration recovery
CN111427588A (en) Suspending installation of firmware packages
GB2411995A (en) Upgrading an object oriented programming language platform
CN115277813B (en) Super-fusion cluster host resource control method, system, equipment and readable medium

Legal Events

Date Code Title Description
PE20 Patent expired after termination of 20 years

Expiry date: 20220404