+

WO2005114398A2 - Redeploiement de production a travers un controle de versions des applications - Google Patents

Redeploiement de production a travers un controle de versions des applications Download PDF

Info

Publication number
WO2005114398A2
WO2005114398A2 PCT/US2005/017518 US2005017518W WO2005114398A2 WO 2005114398 A2 WO2005114398 A2 WO 2005114398A2 US 2005017518 W US2005017518 W US 2005017518W WO 2005114398 A2 WO2005114398 A2 WO 2005114398A2
Authority
WO
WIPO (PCT)
Prior art keywords
version
application
ofthe
ofthe application
deploying
Prior art date
Application number
PCT/US2005/017518
Other languages
English (en)
Other versions
WO2005114398A3 (fr
Inventor
Priscilla C. Fung
Ananthan Bala Srinivasan
Eric M. Halpern
Original Assignee
Bea Systems, 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 US10/847,960 external-priority patent/US20050262494A1/en
Priority claimed from US10/848,228 external-priority patent/US20050262495A1/en
Application filed by Bea Systems, Inc. filed Critical Bea Systems, Inc.
Publication of WO2005114398A2 publication Critical patent/WO2005114398A2/fr
Publication of WO2005114398A3 publication Critical patent/WO2005114398A3/fr

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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/71—Version control; Configuration management

Definitions

  • FIG. 1 illustrates a typical redundant application environment 100 in accordance with the prior art.
  • Environment 100 includes an a primary cluster 118 and a secondary cluster 128.
  • Primary cluster 118 includes administration server 110 and managed servers 112, 114 and 116.
  • Managed server 114 includes application Al, A2 and A3.
  • Secondary cluster 128 includes administration server 120 and managed servers 122, 124 and 126.
  • Managed server 124 includes applications Al, A2' and A3. Though not illustrated in FIG. 1, all managed servers within a cluster have the same set of applications deployed.
  • a load-balancer (not shown in FIG. 1) initially routes client requests to the primary cluster 118. During application upgrade, the administrator deploys and tests the new application version of A2, illustrated as A2', on the duplicate cluster 128. When application A2' is ready to service client traffic, the load-balancer is configured to route new client requests to the duplicate cluster 128. Existing clients continue to access the old application version in the primary cluster.
  • the administrator can then undeploy the old application version from the primary cluster. If desirable, the administrator may also deploy the new application version on the primary cluster and perform another switch back from the duplicate cluster to the primary cluster.
  • the approach ofthe prior art requires a hardware load-balancer and a duplicate cluster/cluster configuration for the duration ofthe application upgrade process. It also requires considerable manual configuration efforts from the administrator and there is also no automatic support for determining when in-flight work is done for a particular application. What is needed is a reliable, automatic system for implementing production redeployment that saves hardware resources and provides for greater flexibility, administration and control.
  • the present invention includes a system and method for a reliable, automatic system for implementing production redeployment that saves hardware resources and provides for greater flexibility, administration and control.
  • the system ofthe present invention supports the notion of application versionmg, such that multiple versions of an application can be deployed side-by-side to coexist in an application server cluster. This allows application upgrades, in the form of a new application version, to be applied to the same application environment as the existing application.
  • the new application version is essentially a separate copy ofthe application and is fully isolated from the old application version as far as application-scoped resources are concerned, such as application-scoped JDBC connection pools or JMS destinations, all application components and administrative MBeans.
  • the applications may share global resources (global JDBC connection pools or JMS destinations) accessed in the application.
  • the application server system ofthe present invention may automatically route new clients to the new application version and retire the old application version according to the specified retirement policy.
  • An application versioning and production redeployment support system in accordance with one embodiment ofthe present invention is configured to handle application upgrade needs in mission-critical, production environments. With multiple application versions, application availability to both existing and new clients is not interrupted during the process of application upgrade. Application versioning also provides the ability to test a new application version before providing it to be used by clients as well as the ability to roll back to safe previous versions of applications if there are any errors in the currently active version.
  • the application server system ofthe present invention supports self- contained applications having whose entry point is HTTP, inbound JMS messages to MDBs from global JMS destinations, and inbound JCA requests, hi one embodiment, the application versioning system ofthe present invention may be implemented within a application server system such as WebLogic Server, by BEA Systems, of San Jose, CA.
  • FIGURE 1 is an illustration of a system for implementing production redeployment in accordance with the prior art.
  • FIGURE 2 is an illustration of a system for implementing production redeployment in accordance with one embodiment ofthe present invention.
  • FIGURE 3 is an illustration of a method for implementing deployment of an application in accordance with one embodiment ofthe present invention.
  • FIGURE 4 is an illustration of a method for implementing application retirement in accordance with one embodiment ofthe present invention.
  • FIGURE 5 is an illustration of a method for implementing rollback to previous application versions in accordance with one embodiment ofthe present invention.
  • FIGURE 6 is an illustration of application interactions and contexts in accordance with one embodiment ofthe present invention.
  • FIGURE 7 is an illustration of JNDI bindings in accordance with one embodiment ofthe present invention.
  • FIGURE 8 is an illustration of an internal state machine for deployment in accordance with one embodiment ofthe present invention.
  • FIGURE 9 is an illustration of an externally visible state machine in accordance with one embodiment ofthe present invention.
  • the present invention includes a system and method for a reliable, automatic system for implementing production redeployment that saves hardware resources and provides for greater flexibility, administration and control.
  • the system ofthe present invention supports the notion of application versioning, such that multiple versions of an application can be deployed side-by-side to coexist in an application server cluster. This allows application upgrades, in the form of a new application version, to be applied to the same application environment as the existing application.
  • the new application version is essentially a separate copy ofthe application and is fully isolated from the old application version as far as application-scoped resources are concerned, such as application-scoped JDBC connection pools or JMS destinations, all application components and administrative MBeans.
  • the applications may share global resources (global JDBC connection pools or JMS destinations) accessed in the application.
  • the application server system ofthe present invention may automatically route new clients to the new application version and retire the old application version according to the specified retirement policy.
  • An application versioning and production redeployment support system in accordance with one embodiment ofthe present invention is configured to handle application upgrade needs in mission-critical, production environments. With multiple application versions, application availability to both existing and new clients is not interrupted during the process of application upgrade. Multiple application versioning also provides the ability to test a new application version before providing it to be used by clients as well as the ability to roll back to safe previous versions of applications if there are any errors in the currently active version.
  • the application server system ofthe present invention supports self-contained applications whose entry point is HTTP, inbound JMS messages to MDBs from global JMS destinations, and inbound JCA requests.
  • the application versioning system of the present invention may be implemented within a application server system such as WebLogic Server, by BEA Systems, of San Jose, CA.
  • the developer when an application developer releases an application upgrade in the form of a new application archive (J2EE EAR), the developer can, using the system ofthe present invention, indicate that the application upgrade is a new version ofthe application by including a new version identifier.
  • these versionable applications will have both an application name and a version identifier, together uniquely identifying a particular version.
  • the new version identifier is a main attribute specific to the application server system and located in an archive manifest file, and may be a string or some other type of variable.
  • an application archive whose version is "vl” could have the following manifest content: Manifest- Version: 1.0 Created-By: 1.4.1_05-b01 (Sun Microsystems Inc.) Weblogic- Application- Version: vl
  • the application archive version may be a string and contain characters including but not limited to: alphanumeric (such as"A"-"Z", “a”- "z", “0"-”9"), period (".”), underscore (“_”), and hyphen ("-").
  • the version identifier can be any length. In another embodiment, the length ofthe version identifier should be less than 215 characters.
  • a user may specify the application archive version upon initial deployment ofthe application.
  • the application server system of the present invention may designate the deployed application as non-versionable. In one embodiment, if no designation is made, the application server ofthe present invention will designate the application as non-versionable by default.
  • the application server ofthe present invention will perform production redeployment with version isolation (thus, generate duplicate versions ofthe application). In one embodiment, if the same application archive version is specified, the application server ofthe present invention will perform in-place redeployment, unless there are changes to bindings in the deployment plan, in which case the application server will perform production redeployment also.
  • MBeans may be used to implement the version aware redeployment methodology ofthe present invention.
  • the ApplicationMBean (or DeploymentBean) is one such MBean.
  • the AppiicationMBean class's "Name” attribute can be made version-aware in that it will not be the name ofthe application, but will be the application identifier for the application version. There will be an "ApplicationName” attribute which returns the name ofthe application.
  • the App ⁇ cationMBean may also have the following additional attributes:
  • ciusterMBean may have factory APIs to create/delete Application MBeans as well as a navigation API for looking up Application MBeans based on the application identifier.
  • helper methods may also be provided in a weblogic . application. utils .ApplicationVersionUtils class to manipulate various version-related parameters and to lookup the active version of MBeans.
  • an AppiicationRuntimeMBean may be versioned. The versioning may be implemented by having the version identifier appended to the current name ofthe MBean.
  • the AppiicationRuntimeMBean may have the following attributes:
  • the currently active version may not be the latest redeployed version, since users can rollback to a previous version. All the other MBeans that are the descendents ofthe ApplicationMBean and AppiicationRuntimeMBean will also be versioned.
  • the versioning is implemented by having the version identifier appended to an MBean's current name.
  • each application version will have its own local JNDI tree, which will be version-unaware. During deployment, the correct versions of the components will be bound to it. For the global JNDI tree, the bind, unbind, rebind, and lookup APIs will be made version-aware.
  • J2EE application components that are bound to the JNDI tree, such as EJB homes, JCA resource adapter factories, application-scoped JDBC connection pools and JMS destinations, are also bound in a version-aware manner.
  • Global JNDI lookup ofthe J2EE application components will return the version ofthe components as specified in the WorkContext. If no application version has been assigned yet, JNDI lookup will return the currently active (usually the newest) application version.
  • any custom components that an application version binds to the global JNDI tree will be bound in a version- aware manner.
  • the application server ofthe present invention may automatically deploy the new application version side-by-side with the old application version.
  • the administrator can also specify the retirement policy upon deploying/ redeploying an application version so that it may wait till all in-flight work is done or after a specified timeout period.
  • a method 300 for deploying a new application in an application server environment is illustrated in FIG. 3 in accordance with one embodiment ofthe present invention. Method 300 begins with start step 305. Next, the system determines whether to deploy the new application as versionable or not at step 310. In one embodiment, this determination is made based on administrator input. If the new application is not to be deployed as versionable, operation continues to step 320. At step 320, the application is deployed as non-versionable and operation 12
  • step 330 the system ofthe present invention determines whether to deploy the versionable application in normal mode or administrative mode. If the application is to be deployed in normal mode, operation continues to step 340 where the application is deployed as a new application and the old application is retired. Step 340 is described in more detail with respect to method 400 of FIG. 4. If the application is to be deployed in the administrative mode, operation continues to step 350. At step 350, the application is in administrative mode wherein the administrator may perform tests on the application without affecting any active applications. Once the administrator determines that the application should be made active and deployed in the normal mode at step 360, operation continues to step 340. After the application is deployed, operation ends at step 365. Users may specify the retirement policy ofthe application version when performing production redeployment of versionable applications. Retirement policies in accordance with one embodiment ofthe present invention are displayed below in Table 3.
  • FIG. 4 illustrates a method 400 for implementing application retirement policies in accordance with one embodiment ofthe present invention.
  • Method 400 begins with start step 405.
  • the retirement policy to implement is determined at step 410.
  • the retirement policy to implement is derived from user input.
  • the retirement policy is determined automatically from application server conditions.
  • the default retirement policy is "Complete In-Flight" policy, wherein the application version will be retired after all the in-flight work is complete.
  • the retirement policy if the retirement policy is determined to be "Complete In-Flight”, then operation continues to step 460 wherein all new application requests from clients are forwarded to the new version ofthe application.
  • operation of in-flight operation continues directly from step 410 to step 470.
  • step 450 the old version ofthe application is undeployed.
  • the retirement process begins after the new application version is fully deployed and active. In this case, steps 460 and 420 are executed before 410. If the retirement policy is determined to be a timeout policy at step 410, operation continues to step 420 wherein all new application requests from clients are forwarded to the new version ofthe application. At step 430, once the designated time period has elapsed, operation continues to step 450 where the old version ofthe application is undeployed. After the application is undeployed at step 450, operation ends at step 485. hi one embodiment, the time elapsed is calculated from the time the new version becomes active.
  • the deployment ofthe new version may take some time, and when it is done, it will become the active version (in one embodiment, this step is almost instantaneous). Thereafter, all new requests will be routed to the new version. In this embodiment, before deployment ofthe new version is done, e.g. during the deployment, new requests will still be routed to the old version (which is still the active version at that time). hi one embodiment, at any time during the life of an application, an administrator may force undeploy an application. If the system ofthe present invention receives input that an administrator wishes to force undeploy an application at step 480, operation immediately proceeds to step 450 where the application is undeployed.
  • undeployment of an application version is coordinated by the administration server and is initiated at all the target servers at the same time.
  • the system ofthe present invention may rollback to a previous application version while the new application version is being fixed.
  • administrators can redeploy an old application archive (with the old version identifier).
  • the application server ofthe present invention will automatically make the old redeployed application the currently active application version, whether it is in the process of being retired or it was already undeployed.
  • the problematic application version will then be retired.
  • FIG. 5 illustrates a method 500 for implementing rollback to previous application versions.
  • Method 500 begins with start step 505.
  • operation continues to step 510 wherein the system receives input indicating that a rollback to a previous application version should be performed.
  • step 520 the system determines whether the previous version is in the process of being retired. In one embodiment the previous version may either be completely retired or in the process of being retired. If the previous version is currently in the process of being retired, operation continues to step 530 wherein the version is made the active version. Operation then continues to step 550. If the previous version is already retired, the retired version ofthe application is deployed at step 540 and operation continues to step 550. At step 550, the newer version ofthe application is retired. Operation of method 500 then ends at step 555.
  • a configurable ApplicationMBean attribute may specify the maximum number of application versions allowed.
  • the default number of application versions allowed is two. With two versions, it is possible for the user to rollback to the old version without creating a new application version.
  • the administrator can still choose to perform a partial redeploy (which will be done in-place without version isolation) if the application changes are minor and the disruption to existing clients is minimal and acceptable, e.g. updates to static pages.
  • Production Redeployment is performed when configured security providers support the application versioning security SSPI.
  • the security providers for authorization, role mapping and credential mapping may support the application versioning SSPI.
  • security model changes are not implemented between product redeployment. Making security changes while using other security models, or changing the security model may require a stop, undeploy, distribute and start again.
  • an administrator can specify a "staged" staging mode, in which the new application archive and its associated files will be copied to a subdirectory (named by the version identifier). If the administrator specifies staging mode "no stage", then the administrator should use a different staging path for different application versions. In one embodiment, all application-scoped components of a new application version are version-aware.
  • this includes parts ofthe application including the servlets/JSPs, EJB homes, JCA resource adapters, application-scoped JDBC connection pools and JMS destinations.
  • a client when a client first makes an HTTP request to a WebApp application, it will be serviced by the currently active (usually the newest) application version. For stateful WebApps, the version information is retained in the HTTP session, and all subsequent requests from the same client to the application will be serviced by the same application version.
  • client requests from the client to the application are serviced by the same application version even when the version is retiring or when requests are being failed over to another server.
  • the version information is also associated with the current thread of execution, so that all subsequent requests from the WebApp to other J2EE application components downstream in the thread recursively will be serviced by the same application version as well.
  • J2EE application components access downstream include JNDI loolcups of other J2EE application components (e.g. EJB homes, JCA resource adapter factories) and JCA 1.5 WorkManager requests (which allow applications to schedule units of work to be executed by the application server).
  • the application server system is BEA's WebLogic Server
  • the production redeployment functionality will be exposed as Weblogic extensions to JSR-88 API.
  • JSR-88 For versionable applications, JSR-88
  • JSR-88 redeploy would perform production redeployment with side-by-side versioning.
  • JSR-88 redeploy would perform in-place redeployment as before.
  • new JSR-88 extension methods will be provided to "deploy”, “start”, and “redeploy” an application version in the admin/test mode, and to open an admin mode application version for general traffic.
  • the production redeployment functionality can be implemented through an interface that includes a command line tool or a console or workshop.
  • clients may retain version "stickiness" to the versions ofthe applications that it accesses.
  • the default application retirement policy ensures that application versions will only be undeployed when all in-flight work of the clients are done.
  • the system ofthe present invention may enable apphcation code to be transparent of application versioning and continue to use the same API (whether standard J2EE or WebLogic extensions) to access various components, hi this case, the application server system ofthe present invention will perform any necessary version management and dispatching under the covers, as described herein.
  • application code when application code does not incorporate application versioning, application code should not use the application name as an identifier, such as to use the application name as a key to some global maps or database table. Rather, the identifier should be implemented as Applicationldentifier instead. Thus, users should use the application identifier (provided by the system) as an identifier for their application's usages.
  • Example Scenario An example scenario ofthe implementation of production redeployment in accordance with one embodiment of the present invention will now be discussed. The scenario will be discussed with reference to BEA Systems' WebLogic Server, but is intended to generally apply use ofthe present invention with other types of application server environments and systems as well.
  • the Weblogic administrator has just received a new application "YABookStoreApp" of version "1.0" (the manifest file ofthe EAR contains an "Weblogic-Application- Version” attribute with value "1.0”) from development to deploy to their production servers.
  • the application consists of a JSP and some cluster-enabled stateful session beans and entity beans. He uses the console with the new deployment assistant to deploy the application and resolve all the bindings ofthe application, e.g.
  • the ApplicationMBean that is created for the application will have a name of "YABookStoreApp", an application identifier of "YABookStoreApp: 1.0", and its object name will have an extra key property "version” with value "1.0".
  • the EJB homes will be bound to JNDI tree with an extra name component "1.0" (e.g. The ShoppingCartBean home will be bound under the JNDI name
  • the application context propagates to Server 2 with the JNDI lookup.
  • the JNDI implementation looks up the binding for
  • the JNDI implementation looks up the binding for "CreditApprovalBeanHome.latest", which returns ("CreditAuthorizationApp", "v2", ⁇ ejb home>). JNDI checks the application name and version identifier with those in the application context, and finds that the application "CreditAuthroizationApp” is new. It then adds the tuple (“CreditAuthorizationApp", "v2") to the application context, and returns version "v2" ofthe EJB home for CreditApprovalBean, together with the updated application context: ⁇ ("YABookStore”, "1.0"), ("CreditAuthorizationApp", "v2”) ⁇ , to Server 2. The application context is subsequently propagated back to Server 1 when the checkout method returns.
  • FIG. 6 illustrates the example scenario apphcation interactions and contexts in accordance with one embodiment ofthe present invention.
  • Stefan receives a new version ofthe "YABookstoreApp", version "1.1”, from QA, and he proceeds to redeploy the application in admin mode in order to test out the new version. Stefan does not find any problem with the new application version, and selects the "go live” option from the Console to open the new version for general traffic.
  • the "YABookstoreApp. latest" JNDI binding on Server 2 is now updated to contain ("YABookstoreApp", "1.1”, ⁇ new ejb home>). Meanwhile, some existing client sessions are still accessing version "1.0" of
  • FIG. 7 is an illustration ofthe example scenario JNDI bindings in accordance with one embodiment ofthe present invention.
  • new client sessions access "YABookstoreApp”
  • everything happens as described in the "Application Access before redeployment” section above, except that the version identifier will now be "1.1”.
  • the proxy plug-in redirects the request to the secondary server.
  • the secondary server obtains the application version info from the replicated HTTP session and continues to work as before.
  • Administration Mode When performing production application upgrades, oftentimes administrators would like to test out the new application version in the production environment before opening it for general traffic.
  • An application administration mode within the application server ofthe present invention enables administrators to do this.
  • the administration mode (or admin mode, meaning available for administration') is a state that an application can reside in. When an application is in the Admin Mode, access to it is restricted through the administration channel.
  • An application can enter the Admin Mode in two ways. First, it can be deployed to start up in the Admin Mode as illustrated in method 300 of FIG. 3.
  • an application that is deployed to start up in the Admin Mode will be provided with an option to transition to general availability.
  • applications will start up in general availability mode unless the administrator or deployer explicitly requires that the application start up in Admin Mode.
  • Applications will transition into the Admin Mode if a server is transitioned from the Running to the Admin Mode or if that particular application is transitioned to the Admin Mode.
  • a Work Manager may be associated to each application. When configured, additional Work Managers may also be associated with particular modules ofthe application (such as the Servlet dispatcher). When the application is put into the Admin Mode, the Work Managers associated with that application will reject new work and complete pending work in its queue.
  • a completion call back is registered with each module container as part ofthe first phase of putting an application into Admin Mode.
  • the containers call into the coordinator when all their work is completed.
  • the application is considered to be Admin Mode at which point the coordinator is done with that operation.
  • the transition from the running mode to the admin mode proceeds as follows. First, the application container requests all modules within its scope to go into the admin mode. Each mode immediately starts filtering new requests. Only requests which access existing sessions or that have a transactional state (EJBs) are accepted.
  • EJBs transactional state
  • any attempt to create new transactions or sessions is refused. Requests from administration users are permitted. Each module blocks new requests until the pending state is completed, as the pending state implies transactions and sessions are in progress.
  • the application level work managers begin shutdown. In one embodiment, the work managers complete all requests in the queue and invoke a completion callback. Finally, the application level transaction service is shutdown. In one embodiment, application level transaction service shutdown includes waiting for the transaction count to drop to zero. In one embodiment, as introducing the Admin Mode, the
  • Deployment Life cycle state diagram changes a bit.
  • the various internal states and corresponding actions that trigger transitions in the life cycle of deployment in accordance with one embodiment ofthe present invention is illustrated in FIG. 8.
  • internal states include does not exist 810, new deployment 820, ready for deployment (distributed) 830, prepared 840, available in admin mode 850, available for general use 860 and update prepared 870.
  • the arrows connecting the states indicate the action that triggers the transition between the particular states.
  • the externally visible states 900 and the Deployment API calls that result in transitions in accordance with one embodiment ofthe present invention are illustrated in FIG. 9.
  • the states of state machine 900 are does not exist 910, ready for deployment 920, available in admin mode 930 and available for general usage in 940.
  • the arrows connecting the states indicate the action that triggers the transition between the particular states.
  • the arguments to the API calls are the state transitions in the internal state diagram Currently, the Deployment runtime registers a CallbackHandler with the J2EE Application Container to receive events signaling the state transitions ofthe various modules or containers. This CallbackHandler can be enhanced with a 'quiesced() ! method that can be invoked by each ofthe modules/containers that are part ofthe application. When an administrator puts an application into admin mode, the deployment runtime signals to the containers on the target servers that they need to quiesce their modules and pass along the reference to the
  • CallbackHandler When each container is done, it can call the 'quiesced()' method on the CallbackHandler.
  • the 'start', 'deploy' and 'redeploy' APIs exposed by the deployment subsystem will each have an option - 'enableAdminMode'. When this option is set to 'true', the application will 'start', 'deploy' or 'redeploy' and end up in the Admin Mode. By default, this option will not be set and hence the apphcation should transition to general availability as is done today.
  • the Deployment API may include a call that takes an application in Admin Mode and transitions it to general availability mode. Similarly, the Deployment API may include a call to take a running application and puts it into admin mode.
  • the administrator can use another Weblogic extension to JSR-88 API (and associated command line tool option) to open the application version for general traffic ("go live").
  • the previous application version will be retired.
  • administrators can monitor the activity and status ofthe different application versions (with special indication for the currently active one) via the management Console.
  • they will be able to visualize the inflight work for each ofthe application versions.
  • the in-flight work includes the number of outstanding HTTP sessions and in-flight transactions for each application version.
  • the application versioning and the production redeployment support is designed to handle application upgrade needs in mission-critical, production environments. As such, application availability, consistency, and management are of paramount concern. With multiple application versions, apphcation availability to both existing and new clients is not interrupted during the process of application upgrade. It also provides the ability to test a new application version before opening it to general public as well as the ability to roll back to previous safe versions if there are any errors in the currently active version. Moreover, conscious design efforts have ensured that all clients will see consistent application versions, irrespective and transparent of all failure conditions, including admin or managed server restarts and/or failover. Last but not the least, administrators can monitor and manage application versions easily with the management Console.
  • the invention may also be implemented by the preparation of application specific integrated circuits or by interconnecting an appropriate network of conventional component circuits, as will be readily apparent to those skilled in the art.
  • the present invention includes a computer program product which is a storage medium (media) having instructions stored thereon/in which can be used to program a computer to perform any ofthe processes ofthe present invention.
  • the storage medium can include, but is not limited to, any type of disk including floppy disks, optical discs, DVD, CD-ROMs, microdrive, and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, flash memory devices, magnetic or optical cards, nanosystems (including molecular memory ICs), or any type of media or device suitable for storing instructions and/or data.
  • the present invention includes software for controlling both the hardware ofthe general purpose/specialized computer or microprocessor, and for enabling the computer or microprocessor to interact with a human user or other mechanism utilizing the results ofthe present invention.
  • Such software may include, but is not limited to, device drivers, operating systems, and user applications.
  • Included in the programming (software) ofthe general/specialized computer or microprocessor are software modules for implementing the teachings ofthe present invention, including, but not limited to, production redeployment of applications using versioning.

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

Dans un mode de réalisation de l'invention, un support de redéploiement de la production et du contrôle des versions des applications est conçu pour manipuler des besoins de mises à jour d'applications dans des environnements de production à mission critique. Avec de nombreuses versions d'applications, la disponibilité de l'application à des clients existants ou des nouveaux clients n'est pas interrompue, lors du traitement de la mise à jour de l'application. L'invention concerne la capacité de test d'une nouvelle version d'applications avant son ouverture au grand public, ainsi que sa capacité à retourner à des versions anciennes plus sûres si une erreur apparaît dans une version active. Les clients voient des versions d'applications conséquente, sans défaillance, notamment des redémarrages et/ou la reprise des serveurs gérés ou administrés. Les administrateurs peuvent surveiller et gérer des versions d'applications facilement au moyen de la console de gestion. Cette dernière est une solution fondée sur des logiciels, et cela améliore la solution de mise à jour d'applications traditionnelles par élimination du besoin des équilibreurs de charges matériels et des configurations de domaines/groupes dupliqués et leur équipements de ressources associés et par production de possibilités de gestion sophistiquées.
PCT/US2005/017518 2004-05-18 2005-05-18 Redeploiement de production a travers un controle de versions des applications WO2005114398A2 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US10/847,960 2004-05-18
US10/847,960 US20050262494A1 (en) 2004-05-18 2004-05-18 Production redeployment through application versioning
US10/848,228 2004-05-18
US10/848,228 US20050262495A1 (en) 2004-05-18 2004-05-18 Administration mode for server applications

Publications (2)

Publication Number Publication Date
WO2005114398A2 true WO2005114398A2 (fr) 2005-12-01
WO2005114398A3 WO2005114398A3 (fr) 2008-10-16

Family

ID=35429028

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2005/017518 WO2005114398A2 (fr) 2004-05-18 2005-05-18 Redeploiement de production a travers un controle de versions des applications

Country Status (1)

Country Link
WO (1) WO2005114398A2 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007272996A (ja) * 2006-03-31 2007-10-18 Ricoh Co Ltd フェードインメモリと情報記録方法および情報再生方法
CN107636608A (zh) * 2015-06-05 2018-01-26 国际壳牌研究有限公司 用于利用暂存应用程序替换运转的控制/估计应用程序的系统和方法
CN111104260A (zh) * 2019-12-30 2020-05-05 北京三快在线科技有限公司 服务升级的监测方法、装置、服务器及存储介质
CN113254039A (zh) * 2021-06-01 2021-08-13 通号智慧城市研究设计院有限公司 一种用于多环境部署和多版本同时在线的系统及方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5835911A (en) * 1994-02-08 1998-11-10 Fujitsu Limited Software distribution and maintenance system and method
US6493871B1 (en) * 1999-09-16 2002-12-10 Microsoft Corporation Method and system for downloading updates for software installation
US6658659B2 (en) * 1999-12-16 2003-12-02 Cisco Technology, Inc. Compatible version module loading

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5835911A (en) * 1994-02-08 1998-11-10 Fujitsu Limited Software distribution and maintenance system and method
US6493871B1 (en) * 1999-09-16 2002-12-10 Microsoft Corporation Method and system for downloading updates for software installation
US6658659B2 (en) * 1999-12-16 2003-12-02 Cisco Technology, Inc. Compatible version module loading

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007272996A (ja) * 2006-03-31 2007-10-18 Ricoh Co Ltd フェードインメモリと情報記録方法および情報再生方法
CN107636608A (zh) * 2015-06-05 2018-01-26 国际壳牌研究有限公司 用于利用暂存应用程序替换运转的控制/估计应用程序的系统和方法
US11093235B2 (en) 2015-06-05 2021-08-17 Shell Oil Company System and method for replacing a live control/estimation application with a staged application
CN111104260A (zh) * 2019-12-30 2020-05-05 北京三快在线科技有限公司 服务升级的监测方法、装置、服务器及存储介质
CN113254039A (zh) * 2021-06-01 2021-08-13 通号智慧城市研究设计院有限公司 一种用于多环境部署和多版本同时在线的系统及方法
CN113254039B (zh) * 2021-06-01 2024-04-05 通号智慧城市研究设计院有限公司 一种用于多环境部署和多版本同时在线的系统及方法

Also Published As

Publication number Publication date
WO2005114398A3 (fr) 2008-10-16

Similar Documents

Publication Publication Date Title
US20050262495A1 (en) Administration mode for server applications
US20050262494A1 (en) Production redeployment through application versioning
US7735097B2 (en) Method and system to implement a deploy service to perform deployment services to extend and enhance functionalities of deployed applications
US10853056B2 (en) System and method for supporting patching in a multitenant application server environment
US20210081193A1 (en) System and method for supporting patching in a multitenant application server environment
US7293255B2 (en) Apparatus and method for automated creation of resource types
US9229707B2 (en) Zero downtime mechanism for software upgrade of a distributed computer system
US7562341B2 (en) Deploy callback system with bidirectional containers
US20050278274A1 (en) Transaction model for deployment operations
US7721283B2 (en) Deploying a variety of containers in a Java 2 enterprise edition-based architecture
US9311199B2 (en) Replaying jobs at a secondary location of a service
US7519964B1 (en) System and method for application deployment in a domain for a cluster
US7660824B2 (en) System and method for performing batch configuration changes
US8010504B2 (en) Increasing application availability during automated enterprise deployments
US20050278338A1 (en) Application cloning
US7231436B1 (en) Object-based machine automation method and system
US20090328030A1 (en) Installing a management agent with a virtual machine
US20080059610A1 (en) Dynamically configuring, allocating and deploying computing systems
US20050235273A1 (en) System and method providing single application image
US7216158B2 (en) System, method and interface for controlling server lifecycle
US7882502B2 (en) Single file update
US7673023B1 (en) Method and apparatus for service processor updates
US9384103B2 (en) EJB cluster timer
US20060041662A1 (en) Application loading and visualization
US20070061277A1 (en) Method, system, and storage medium for providing dynamic deployment of grid services over a computer network

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase in:

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

122 Ep: pct application non-entry in european phase
点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载