Smart rebinding for live product install

An upgrade of an application product is installed to a first location in a shared environment that is different than a second location in the shared environment. An indication of the newer version of the application product and an indication of the first location are recorded in a registry that comprises indications of a plurality of application products and locations corresponding thereto. Metadata and binding information are obtained from an instance of the previous version of the application product while the instance of the previous version of the application product continues running. The metadata and the binding information are instantiated for an instance of the newer version of the application product in execution space thereof. Work is diverted work from the instance of the previous version of the application product to the instance of the newer version of the application product while both instances continue running in the shared environment.

BACKGROUND

Embodiments of the inventive subject matter generally relate to the field of computer processing and, more particularly, to live install of a product with smart rebinding.

Typically, an enterprise customer runs multiple software products as a solution. The multiple software products interact to provide the solution for that enterprise customer. One software product implements a user interface, while another software products manages a database. Other software products implement web services, security, and data processing. These products are often updated on different timelines. For instance, the database manager product is updated at a time when the other software products are not updated. Upgrading one of these products is inefficient and often introduces an interruption in handling requests submitted to the software product being upgraded.

SUMMARY

Embodiments include a method for live install of a product without interrupting a running solution that includes an instance of the product. One or more files of a newer version of an application product are installed to a first location in a shared environment that is different than a second location in the shared environment where one or more files of a previous version of the application product are installed. The application product is one of a plurality of application products of a solution implemented in the shared environment. An indication of the newer version of the application product and an indication of the first location are recorded in a registry that comprises indications of the plurality of application products and locations corresponding thereto. Metadata and binding information are obtained from an instance of the previous version of the application product while the instance of the previous version of the application product continues running in the shared environment. The metadata and the binding information are instantiated for an instance of the newer version of the application product in execution space thereof. Work is diverted from the instance of the previous version of the application product to the instance of the newer version of the application product while both instances continue running in the shared environment.

Embodiments include a computer program product for installing a newer version of an application server product that is part of a solution without interrupting the solution. The computer program product comprises a computer readable storage medium having computer usable program code embodied therewith. The computer usable program code comprises a computer usable program code configured to install one or more files of a newer version of an application server product to a first location in a shared environment that is different than a second location in the shared environment where one or more files of a previous version of the application server product are installed. The application server product is one of a plurality of application products of a solution implemented in the shared environment. The computer usable program code is configured to record an indication of the newer version of the application server product and an indication of the first location in a registry that comprises indications of the plurality of application products and locations corresponding thereto. The computer usable program code is configured to obtain metadata and binding information from an instance of the previous version of the application server product while the instance of the previous version of the application server product continues running in the shared environment. The computer usable program code is configured to instantiate the metadata and the binding information for an instance of the newer version of the application server product in execution space thereof. The computer usable program code is configured to migrate an instance of a first of the plurality of application products from the instance of the previous version of the application server product to the instance of the newer version of the application server product.

DESCRIPTION OF EMBODIMENT(S)

The description that follows includes exemplary systems, methods, techniques, instruction sequences and computer program products that embody techniques of the present inventive subject matter. However, it is understood that the described embodiments may be practiced without these specific details. In other instances, well-known instruction instances, protocols, structures and techniques have not been shown in detail in order not to obfuscate the description.

The description uses the terms “instance,” “component,” “execution space,” “wire,” and “shared environment.” The term “instance” is used to refer to executing code or program instructions. An application server instance refers to the executing code that implements the application server. The term “component” is used to refer to a reusable piece of code that implements well-defined interfaces. Typically, a runtime environment contains a component. For instance, a Java® Enterprise Edition (Java EE) runtime environment (also referred to herein as “container”) contains JavaBean® components. Examples of components also include portlets and widgets. The term “execution space” refers to the memory allocated to an instance. Execution space may also encompass other resources (e.g., sockets). The term “wire” is used to refer to a logical connection between components/applications, including user interfaces, that facilitates the transfer of data between the components. A wire identifies a target component and the protocol for conducting data transfer (e.g., a defined interface). The term “shared environment” is used to refer to an environment shared by multiple users. Examples of a shared environment include a server, a virtual server, and an operating system.

A shared environment hosts an application server, a web server, a database connector and database, services, and software components (e.g., Java beans). Software products are installed on an instance of the application server. Instances of the software products bind to the application server, services, and components. When one of the software products are to be upgraded to a newer version, the newer version of the software product is installed and begins running on an application server instance, perhaps an instance of a newer version of the application server. The instance of the newer version of the software product (hereinafter referred to as “upgrade instance”) obtains binding information for the instance of the previous version of the software product (hereinafter referred to as “current instance”). The upgrade instance binds to the service and objects in accordance with the obtained binding information. Requests that are in-process with the current instance are completed. Requests that are queued for the current instance are directed to the upgrade instance. The software product is upgraded while the solution continues to run, thus avoiding interrupting users using the solution.

FIG. 1depicts a conceptual diagram of an example live install with smart rebinding. A shared environment100initially hosts an application server version 6.0 instance101, and application A version 1.2 instance103, and an application B version 2.3 instance105. The application server 6.0 instance101hosts a component container, a service, and a database connector. The component container is depicted as containing two software components. The database connector is depicted as managing a database107outside of the application server 6.0 instance101. The shared environment100also hosts a deployment engine113. The deployment engine113tracks the member of a solution by product identifier (e.g., product name and version) and an indication of location of the product (e.g., directory path).

The applications are bound to the application server 6.0 instance101. The application A 1.2 instance103is bound to the component container, and the service of the application server 6.0 instance101. The application B 2.3 instance is bound to the component container, the service, and the database container of the application server 6.0 instance101.

At a stage A, a new version of the application server and application B are installed. A version 7.0 of the application server is installed in the shared environment100. A version 3.0 of application B is also installed in the shared environment100. The initial part of the install involves installing the application server and the application B into a specified location (e.g., folder or directory). After the location is known, the deployment engine113updates a component and service registry117with indications of the newly installed products and their locations. The deployment engine117adds an entry for the application server 7.0 and an entry the application B 3.0 in the component and service name registry117.

At a stage B, the deployment engine113configures the newly installed products in accordance with configuration data in. The deployment engine113copies the configuration data of the application server 6.0 for the application server 7.0. The deployment engine113then modifies the configuration data for the application 7.0 to reflect any changes specified for application 7.0 (e.g., by an administrator or in a default configuration data). The configuration data for the newly installed products can indicate the solution host, port numbers, etc. Similarly, the deployment engine113copies configuration data of application B 2.3 for the application B 3.0. The deployment engine113modifies the copied configuration data to suit the application B 3.0. Although the example depicts the deployment engine113as configuring the newly installed software products, the illustration is intended to present an example to aid in understanding the inventive subject matter and not intended to limit embodiments. An implementation can task an administrative console or module with configuring newly installed software products.

At stage C1, the application server 7.0 has been launched. The resulting application server 7.0 instance109obtains metadata (e.g., metadata about pages, wires, and certificates, etc.) and binding information from the application server 6.0 instance101. The application server 7.0 instance109creates data structures with the metadata and the binding information in execution space of the application server 7.0 instance109. The application server 6.0 instance can be bound to data sources, shared libraries, etc. The application server 7.0 instance will also be bound to those data sources and shared libraries. The application server 7.0 instance109will be instantiated with services and components in accordance with its installation files and the configuration data in. The obtained metadata may be used to further configure the application server 7.0 instance109. The application server 7.0 instance109will use the obtained metadata and binding information to bind to and/or establish additional components and/or services that may not be indicated in the installation files of the application server 7.0 installation files/script.FIG. 1depicts the application server 7.0 instance109as hosting the container component, service, and database connector as depicted for the application server 6.0 instance. A newer version of an application server will not necessarily be instantiated with the same components or services as a previous version of the application server.FIG. 1also depicts the database connector hosted by the application server 7.0 instance109as connecting to a database119. The database instance119is most likely another instance of the database107. If a database is involved in a software product installation, an implementation of smart rebinding install can either connect to a same database, in this example to database107, or create another copy of the database107. In some cases, all applications running on an instance of a previous version of an application server will migrate to the instance of the newer version of the application server. For those cases, the upgrade instance can use the artifacts (i.e., databases, components, services, etc.) of the previous version instance without creating replicas or redundancies. After stage C1completes, the application server 7.0 instance109is running and can accept requests/tasks.

At stage C2, At stage C1, the application B 3.0 instance115has been launched. The resulting application B 3.0 instance115obtains metadata and binding information from the B 2.3 instance105. The B 3.0 instance115creates data structures with the metadata and the binding information in execution space of the B 3.0 instance115. With the binding information, the application B 3.0 instance115discovers that it should bind to the container component, service, and database connector that is now hosted in the application server 7.0 instance. The application B 3.0 instance115binds to those hosted in the application server 7.0 instance instead of the application server 6.0 instance because the application B 3.0 instance115has been configured to run on the application server 7.0 instance109, and is unaware of the application server 6.0 instance. After stage C2completes, the application B 3.0 instance115is running and can accept requests/tasks. The application B 3.0 instance115notifies the application B 2.3 instance that the upgrade version is able to accept work/task requests.

At a stage D, the application B 2.3 instance105diverts in-process work to application B 3.0 instance115. Once it is determined that the upgrade instance of application B 3.0 can accept requests, the application B 2.3 instance105begins to queue received requests, and transfers the ownership of the queue or the queue itself to the application B 3.0 instance115. If processing a request involves multiple operations, some of which are independent on other operations, embodiments can allow a current instance to complete operations that have dependencies and pass the independent operations to the upgrade instance.

Although this example does not depict bindings between the instances of application A and application B, applications can be bound to each other or have dependencies between each other. For example, a user interface may present content from application A in a first panel and content from application B in a second panel. The content from application A may be dependent upon the content from application B. When the newer version of product B is installed, the binding information and metadata is updated to preserve the relationship between the instance of application A and the instance of the newer version of application B.

At stage E, the deployment engine119invalidates the in the component and service name registry117for the application B 2.3 instance105. The entry is marked for deletion after the shared environment100is stabilized. The shared environment100reaches stabilization, with respect to application B, when the following occurs: 1) application B 2.3 instance103no longer handles any requests; 2) references to application B 2.3 have been cleared (e.g., an application that is not running has a reference to application 2.3); and 3) any bindings to the application B 2.3 instance105have been transferred to the application B 3.0 instance115(e.g., another application or service may be bound to the application B 2.3 instance105).

Although the example depicts implementing the smart rebinding functionality (i.e., live transfer of metadata and binding information between versions of a software product) in the software products, embodiments are not so limited. Other embodiments implement smart rebinding in a centralized fashion. A separate executing piece of code (e.g., the deployment engine) tracks metadata and the binding information for each software product installed on a shared environment. Tracking can involve recording pointers to the metadata and the binding information, maintaining a copy of the location of the metadata and binding information, etc. This piece of code (“smart rebinding manager”) monitors the installation process, and communicates the metadata and binding information to a newly installed software product once it detects launch of the newly installed product. The smart rebinding manager can handles diversion of requests from a previous instance to an upgrade instance.

FIGS. 2-3depict a flowchart of example operations for installing an application upgrade with smart rebinding. At block201, a newer version of an application product is received to install. At block203, it is determined if the application product is an application server. For example, a deployment engine administrative module examines the product name or identifier. If the product is an application server, then control flows to block207. If the product is not an application server, then control flows to block209.

At block207, the application server product is installed to a new location and configured. For example, the application server product is installed into a new folder or directory. Implementations do not necessarily install the application server product to a newly created location. The “new” location is just different than the location of the currently installed version of the application server product. Control flows from block207to block211.

At block209, the application product is installed at a new location and configured to run on a specified application server. The application product may be installed along with an application server product. In that case, the application server product is installed first. After the application server product is up and running, the application product is installed to run on the newly installed application server product. Control flows from block209to block211.

At block211, an instance of the application is launched in accordance with the configuration. Any one or more of a user, default configuration, and previous version configuration data can be used to configure the application product.

At block213, an identifier of the newer version of the application product and an indication of the new location are recorded. For example, a deployment engine records a name and version of the application product along with the location of the application product in a data structure that tracks installed products.

At block215, an identifier and location of the currently installed version of the application product are determined. For example, the deployment engine looks up an entry with a similar name or identifier as the identifier of the product being installed.

At block217, metadata and binding information is requested from the instance of the currently installed version of the application product. For example, smart rebinding code of the upgrade instance calls a function/method using the location information looked up in a name service registry. The function can be defined with an application programming interface.

At block219, the metadata and the binding information are received.

At block221, data structures for the metadata and the binding information are created in the execution space of the upgrade instance. The data structures correspond to any one of a web page, a portlet, wires, preferences, etc. For example, data structures are instantiated for the wires that connect the current instance with other components in the shared environment. Those data structures are modified to indicate the upgrade instance instead of the current instance. If the current instance is a target of a wire, then a data structure will be instantiated to indicate the upgrade instance as the target of the wire. For a wire that indicates the current instance as a source, a data structure will be instantiated that indicates the upgrade instance as the source. Embodiments can copy the data structures that represent the wires, and modify the copied data structures for the upgrade instance. When the upgrade instance takes over for the current instance, the copied wires are activated. Other embodiments modify the data structures that represent the wires with invalid entries that indicate the upgrade instance. When the upgrade instance takes over, the entries for the upgrade instance are activated and the entries for the current instance are marked as invalid to eventually be removed from the wire data structures. To illustrate, an application A comprises a user interface that is wired to an application B. For this illustration, the application B operates as a source and the application B operates as a target of the wire. When application A is upgraded, the wire is modified (or a new wire is created) to logically connect the upgrade version of application A with the application B in accordance with the existing wire configuration of application B as a source and application A as a target. Content from the upgrade instance of application A and the application B are presented via the wire in the user interface of the upgrade instance of application A.

At block223, in-process work is diverted to the upgrade instance from the current instance. For example, a smart rebinding manager intercepts requests submitted to the current instance and passes those requests to the upgrade instance, while informing the requestor of the upgrade instance. For example, the wires for the upgrade instances are now used instead of the wires connected to the current instance, thus maintaining integration between the product being upgraded and other products.

FIG. 3depicts example operations that continue from block223ofFIG. 2. At block301, it is determined if the application product is an application server. Embodiments are not limited to making multiple determinations about the product being installed. An embodiment can follow different paths of operations after making an initial determination as to the type of product being installed. If the application product is an application server, then control flows to block304. If the application product is not an application server, then control flows to block303.

At block303, the entry for previous version of the application product is invalidated and marked for removal. The current instance is then terminated. Termination is delayed to allow for the environment to stabilize as described earlier. An application server product is not invalidated in this example because other application instances may be running on a current instance of an application server. An administrator can manually remove an entry for a server type of application when the administrator considers it safe. Control flows from block303to block315.

At block304, it is determined if application instances running on the current instance of the application server will migrate to the upgrade instance. For example, a smart rebinding manager examines configuration data, an administrator setting, etc. to determine whether application instances will migrate. If one or more application instances will migrate, then control flows to block305. If none of the application instances running on the current instance of the application server will migrate, then control flows to block315.

At block305, a set of operations begin for each of the applications instances to be migrated.

At block307, a location of code (e.g., binary) for the application instance is determined. For example, the deployment engine looks up location of binary for an application in a registry with an identifier corresponding to the application instance.

At block309, an indication of the location of the code is recorded in the execution space of the upgrade instance. For example, a deployment engine communicates, to the upgrade instance, a reference to binary of the migrating application. The upgrade instance then creates a data structure for the application instance.

At block311, configuration data of the application instance is modified to conform to the upgrade instance of the application server. For example, upgrade instance of the application server or an administrative module updates the configuration data to reflect that the application instance will be running on the upgrade instance of the application server.

At block313, it is determined whether there is another application instance to process. If not, then control flows to block315. If so, then control returns to block305.

At block315, a notification is generated that the upgrade instance is live. For example, the deployment engine writes to a log that the live install has completed.

The flowcharts depicted in the figures are intended to aid in understanding the inventive subject matter, and should not be used to limit embodiments of the inventive subject matter. Embodiments can perform additional operations, fewer operations, operations in parallel, in a different order, etc. For instance, an embodiment can perform configuration operations after launching an application product in contrast to the depicted operations at block207and209ofFIG. 2. An embodiment can extract the operations for migrating application instances as depicted inFIG. 3and perform the migration operations separately from the smart rebinding installation.

FIG. 4depicts an example computer system. A computer system includes a processor unit401(possibly including multiple processors, multiple cores, multiple nodes, and/or implementing multi-threading, etc.). The computer system includes memory407. The memory407may be system memory (e.g., one or more of cache, SRAM, DRAM, zero capacitor RAM, Twin Transistor RAM, eDRAM, EDO RAM, DDR RAM, EEPROM, NRAM, RRAM, SONOS, PRAM, etc.) or any one or more of the above already described possible realizations of machine-readable media. The computer system also includes a bus403(e.g., PCI, ISA, PCI-Express, HyperTransport®, InfiniBand®, NuBus, etc.), a network interface405(e.g., an ATM interface, an Ethernet interface, a Frame Relay interface, SONET interface, wireless interface, etc.), and a storage device(s)409(e.g., optical storage, magnetic storage, etc.). The system also includes a smart rebinding component425, depicted as coupled with the bus403. The smart rebinding component425installs a software product that is part of a multi-product solution without interrupting the solution. Bindings of a previous version of the software product already installed are obtained and utilized for the newer version of the software product being installed. Any one of these functionalities may be partially (or entirely) implemented in hardware and/or on the processing unit401. For example, the functionality may be implemented with an application specific integrated circuit, in logic implemented in the processing unit401, in a co-processor on a peripheral device or card, etc. Further, realizations may include fewer or additional components not illustrated inFIG. 4(e.g., video cards, audio cards, additional network interfaces, peripheral devices, etc.). The processor unit401, the storage device(s)409, and the network interface405are coupled to the bus403. Although illustrated as being coupled to the bus403, the memory407may be coupled to the processor unit401.