GB2394570A

GB2394570A - Installing software components according to component characteristics

Info

Publication number: GB2394570A
Application number: GB0224445A
Authority: GB
Inventors: Grant Charles Paton; Gordon David Chisholm; Richard Andrew Han; Alexander Pearson Miller
Original assignee: NCR International Inc
Current assignee: NCR International Inc
Priority date: 2002-10-21
Filing date: 2002-10-21
Publication date: 2004-04-28
Also published as: GB0224445D0

Abstract

An aggregate installer 20 for initiating or managing the installation of a plurality of software components 11 in a target device 24. The installer 20 is configured to identify characteristics associated with the components 11 that are to be installed and/or existing software on the target device 24. This can be done using meta-data 12 that is tagged to the components and a component inventory 22 that is provided at the target device 24. Using this data, the aggregate installer 20 devises an installation strategy for the software components that minimises the installation time. Particularly, the installation process preferably satisfies dependencies either by ordering the installation of components appropriately or by installation of further software components. A further preferable feature is that the installation is performed so as to minimise the number of reboots required.

Description

Software Installation The present invention relates to a method for

installing software components and in particular to a method for optimising such installation.

5 An installable software component is a piece of software that can be installed on a target node e.g. MS Office, MS Exchange, MS Internet Explorer, Windows Service Pack, Security Hotfix. Conventional software installation technologies have concentrated on managing the installation 10 of such components as single packages of software. More recent technologies have helped create packages containing multiple components. However, these packages tend to have rigid, pre-configured installation scripts that define the order and management of components within the packages.

15 Problems with installation and configuration are of general concern in all software environments, but this is particularly so in distributed systems in which software may have to be installed on a large number of physically separate nodes or terminals. There are many issues.

20 However, the most significant is that of how to distribute and install the software components onto a target node in the shortest time possible. Installation time is a key issue for business critical systems, for example back office servers, or nodes that provide a valuable customer service,

such as self-service terminals, for example automated teller machines. An object of the invention is to provide an improved method for optimizing the installation of software.

5 According to one aspect of the present invention, there is provided a method of installing a package of software components in a target device, the method involving identifying characteristics associated with the components that are to be installed and/or existing software on the 10 target device; and devising an installation process that is dependent on the component characteristics and/or existing software identified.

By taking into account the characteristics of the software components that are to be installed and/or software 15 that is already provided on a device, the installation process can be optimised. For example, if it is determined that a component already exists on a device, then there is no need to re-install it, and so it is omitted from the installation process. Also, if it is determined from the 20 component characteristics that say three components require that the device or machine on which they are resident has to be rebooted at some time before they can be used, i.e. before they are fully installed, but not necessarily

immediately, then these can be grouped together and the device or machine rebooted once, rather than three times.

In practice, it has been found for complex systems that by optimizing the installation order, the time taken to 5 install new software can be reduced significantly.

Preferably, the step of identifying is carried out at the time of installation.

Preferably, the step of devising is carried out at the time of installation.

10 The step of identifying may involve comparing each of the software components that are to be installed with existing software components resident at the target device.

In the event that there is a match between a new and an existing component, the method further involves preventing 15 the new component from being installed. In the event that there is no match between a new and an existing component, the method may further involve installing the new component.

The step of comparing may involve comparing an identifier, for example the name, associated with a component that is to 20 be installed with the corresponding identifiers, for example the names, associated with the existing components.

Preferably, characteristics or identifiers associated with the existing components are listed in an inventory.

Preferably, the method further involves maintaining the

inventory of components installed on a target device. The method may further involve up-dating the inventory for the device after the new components are installed.

The characteristics may include a dependency on another 5 component. This means that the other component has to be installed first. In this case, the step of devising an installation process may involve arranging the order of installation of the components to ensure that any dependencies are satisfied.

10 The characteristics may include reboot information that is indicative of whether the target device has to be rebooted in order to complete installation of a component.

In this case, the step of devising an installation process involves arranging the order of installation of the 15 components to ensure that any reboot requirements are satisfied. Preferably, this is done in such a manner to minimise the number of reboots needed.

According to another aspect of the invention, there is provided an installer for installing a plurality of software 20 components in a target device, the installer being configured to identify characteristics associated with the components that are to be installed and/or existing software on the target device; and devise an installation process for

the software components that is dependent on the data and/or existing software identified.

Preferably, the installer is configured to identify the characteristics and/or existing software at the time of 5 installation.

Preferably, the installer is configured to devise the installation process at the time of installation.

The installer may be configured to identify existing software by comparing each of the software components that 10 are to be installed with existing software components resident at the device. In the event that there is a match between a new and an existing component, the installer is configured to prevent the new component from being installed. In the event that there is no match between a 15 new and an existing component, the installer is configured to install the new component. To identify matches between software that is to be installed and existing software, the installer may be configured to compare an identifier, for example the name, associated with a component that is to be 20 installed with corresponding identifiers, for example the names, associated with the existing components.

The existing components, and characteristics thereof may be listed in an inventory. Preferably, the installer is configured to maintain the inventory of components installed

on a device. The installer may be further configured to up-

date the inventory for the device after the new components are installed.

The characteristics may include a dependency on 5 another component. In this case, the installer may be configured to devise an installation process by arranging the order of installation of the components to ensure that any dependencies are satisfied.

The characteristics may include reboot information that 10 is indicative of whether the target device has to be rebooted in order to complete installation of a component.

In this case, the installer is configured to devise an installation process by arranging the order of installation of the components to ensure that any reboot requirements are 15 satisfied. Preferably, this is done in such a manner to minimise the number of reboots needed.

According to yet another aspect of the invention, there is provided a computer program, preferably on a data carrier or a computer readable medium, for installing a plurality of 20 software components on a target device, the computer program having code or instructions for identifying data associated with the components that are to be installed and/or existing software on the target device; and devising an order for

installing the software components that is dependent on the data and/or existing software identified.

Various aspects of the invention will now be described by way of example only, and with reference to the following 5 drawings, of which: Figure 1 is a simplified diagrammatic representation of a software component and its associated meta-data; Figure 2 is a schematic diagram of a system for grouping software components into packages and installing 10 these at remote locations; Figure 3 is a schematic view of a package that is exported from the system of Figure 2; Figure 4 is a schematic view of the package of Figure 3 being installed on a target device; 15 Figure 5 is a table setting out types of meta-data that could be associated with software components in the package of Figures 3 and 4 and used in the installation optimization process; Figure 6 is a representation of an algorithm that is 20 used to optimise the installation of the packages of software of Figures 3 and 4, and Figure 7 is a table of characteristics for a package of software components that has to be installed at a client terminal.

The present invention relates to a system and method for optimising the installation of software components. To achieve this, it is necessary to address particular problems that arise when trying to distribute a collection of 5 software components together. For example, which component should be installed first, what are the interdependencies, when does the system have to be rebooted, is a particular component already installed eta? For the purposes of this application a piece of 10 software that can be installed on its own is referred to as a component. A group of software components is referred to as an aggregate or package. An aggregate may a grouping of components and/or other aggregates. Because aggregates can contain other aggregates, an aggregate represents a tree 15 like structure identifying different groupings of components. In the present application, each component is associated with metadata that describes various component attributes, as shown in Figure l. The metadata may describe 20 many aspects of the software component including the following: component name; component description; windows

add/remove programs key that can be used to de-install the component; compatibility with previous version of the component, including which previous versions the new version

can directly upgrade from; the type of installation mechanism the component uses; special installation requirements, such as 'must be last in installation sequence'; windows administrative privileges required by 5 component; operating system dependencies, for example NT version, Service Pack requirements; installation time dependencies of the component, which are typically declared in the form of the names and versions of other components; run time dependencies of the component, declared in the form 10 of the names and versions of other components; target environments supported by the component, for example, self service terminal, development PC, simulation environment; command lines to install, upgrade and de-install the component for each specific environment supported; machine 15 reboot requirements of each component installation, for example whether no reboot is required or a reboot is required sometime in the future to complete installation or a reboot is required immediately to complete installation or a reboot may or may not be needed to complete installation; 20 and disk space requirements of each component installation, among others. Each of the software components to be installed on the target requires this metadata.

In order to form an aggregate of desired software components, once the appropriate metadata is created and

tagged to the components of interest, these components are selected by the system developer and imported into an aggregate builder tool 10, as shown in Figure 2. This builder tool 10 enables components 11, together with their 5 meta-data 12, to be grouped together into aggregates and allows aggregate installation parameters to be pre-set for those aggregates or components. To do this, the aggregate builder tool 10 imports the selected components 11 and aggregates them into an area called the aggregate 10 customization archive. Components 11 can be imported into the aggregate customization archive from any disk or storage location accessible to the aggregate builder tool 10. The aggregate builder tool 10 is adapted to allow aggregates 18 within the aggregate customization archive to be edited so 15 that they can be customised for particular applications.

Because of this, the aggregate builder tool 10 can help create and manage multiple software packages and also allow the content of those packages to be edited, quickly and easily. Using the aggregate builder tool, components 11 can 20 be reused easily and effectively with little or no additional effort on the part of the component developer.

Once an aggregate 18 is created, the aggregate builder tool 10 includes an extra piece of software 20 in the aggregate 18. This software will be referred to as the

aggregate installer 20, see Figure 3. Once this is done, the aggregate 18, together with its installer 20 is exported to the target terminal 24, as shown in Figure 4. This can be done manually or by downloading the software over a 5 communications network.

The function of the aggregate installer 20 is to install the software components in the aggregate 18; create and maintain a software component inventory 22 on the target node 24 and optimise the installation of the aggregate 18 10 based on the component metadata and the software component inventory 22 located at the target node 24. The software inventory 22 includes the metadata for all of the components installed on the target terminal. In order to ensure that this is kept up to date, the installer 20 is adapted to 15 enter the metadata associated with each of the components it installs once the installation process is completed.

It should be noted that the details of each component's installation are defined by the component's metadata. The aggregate installer 20 itself does not perform any actual 20 component installations, it only initiates and manages them.

Because of this any required installation method can be used as long as it conforms to the rules for component definition. For example, APTRA Advance NDC 2.3 uses Installshield to install. As long as the component

installation mechanism can be described using the component metadata, a component definition could be written to encapsulate the installation of the component. This component could then be used by the aggregate builder to 5 create an installable aggregate that contains the APTRA Advance NDC 2.3 component. Other valid installation methods are Windows Installer, Installshield, INF file etc. The aggregate installer 20 is adapted to optimise the installation routine and devise an installation process or 10 strategy. One of the most important features in doing this is determining the order in which components are to be installed in order to avoid unnecessarily repeating steps, such as rebooting, and installing components that are already available on the terminal. To this end, the 15 aggregate installer 20 includes an optimization algorithm that devises an installation script for setting the order of installation of the components.

The optimization algorithm is based on three factors: the state of the inventory of installed components on the 20 target system; the install time dependencies of the component meta-data and the reboot required flag of the component meta-data, which indicates whether installation requires the system to be re-booted. Hence, when the exported software package is to be installed, the installer

20 goes through all of the meta-data 12 for all of the components 11 at install time, as well as the inventory 22 for the target terminal 24 and uses this data to dynamically create an optimised installation script. Typically, this 5 involves identifying firstly whether any of the components that are to be installed actually exist on the terminal already and if they do prevent these from being installed; then identifying any dependencies and setting an initial installation order that guarantees these and finally 10 checking the rebooting status of the components and determining an installation order that ensures that all reboot requirements are met, whilst minimizing the number of such reboots needed. Once the optimal order of installation is determined, an installation script is dynamically created 15 to install the components in that order.

In order for the optimization algorithm to determine an optimal installation process or strategy, it has to have access to certain information relating to the components within the aggregate. As mentioned previously, this 20 information is included in the meta-data 12 associated with each component 11. Figure 5 shows a table of the particular types of information that can be used by the algorithm.

This includes component information, for example, the component name and version number; install time

dependencies, which indicate other software components that have to be installed before this component is installed; and reboot requirements, which indicate what action has to be taken in terms of rebooting the system in order to ensure 5 that the component is installed. Various reboot requirement values are provided including "NO"; "Yes"; "Automatic"; "ReturnCode" and "Immediate". These will be described in more detail with reference to Figure 6.

Figure 6 shows various combinations of component/system 10 characteristics that the optimization algorithm may come across, as well as the install action that is to be carried out in the event that the algorithm identifies a component having these specific combinations of features. From line one of the table of Figure 6, it can be seen that this 15 component is already installed in the target device, any reboot requirement can be used and there are no dependencies. In this case, the action for the algorithm is "do not install". This is because there is no need to include another version of the component if there is already 20 one in existence that can be shared. Hence, should the algorithm encounter a component having these characteristics, no action is taken.

In line two of the table of Figure 6, the component is not in the inventory, any reboot value can be used and the

dependency requirements have not been satisfied. In this case, the optimization algorithm is adapted to install the component, but only after the components in the installation order list are sorted so that the dependencies are 5 satisfied. Hence, in the event that the optimization algorithm encounters components that are not in the correct order to ensure that their dependencies are set-up, the first step that is taken by the algorithm is to order the components so that the dependencies can be guaranteed.

10 In line three of the table of Figure 6, the component illustrated is not in the inventory, the reboot requirement is "No", which means that no reboot is needed, and the dependency requirements have been satisfied. In this case, the optimization algorithm installs the component 15 immediately. Because of the lack of dependency on other components and the fact that there is no need for rebooting, this type of component can be installed before others.

In line four of the table of Figure 6, the component is not in the inventory, the reboot requirement is "Yes", which 20 means that a reboot is needed at some stage before installation of the component can be completed, and the dependency requirements have been satisfied. In this case, the optimization algorithm has to ensure that a reboot is effected at some stage in order to install the component.

This type of component is installed by the algorithm after those components that do not require a reboot to complete installation. In line five of the table of Figure 6, the component is 5 not in the inventory, the reboot requirement is "ReturnCode" and the dependency requirements are satisfied. The "ReturnCode" requirement is an install process exit code.

This is generated when the set up for the component terminates. It includes a code or identifier that is 10 indicative of whether a reboot is required. In this case, the optimization algorithm installs the component, but does not reboot unless the ReturnCode signifies that a reboot is needed to finalise the installation. The return code may indicate that a reboot is needed in the event that the 15 component that is being installed has become locked by another process and the machine must be rebooted to unlock the file. The algorithm is adapted to cause this type of component to be installed after those that need a reboot at some stage before the component is properly installed.

20 In line six of the table of Figure 6, the component is not in the inventory, the reboot requirement is Automatic and the dependency requirements have been satisfied. In this case, for the reboot requirement "Automatic", the component and may or may not reboot the terminal, rather

than this being controlled by the aggregate installer 20.

This particular reboot requirement is needed for components that are installed using earlier versions of installers, such as InstallShield, that may or may not reboot the 5 machine and do not support a process exit code to inform the aggregate installer 20 that a reboot is needed. By providing this code, it means that old components can be re-

used without alteration. Before allowing the installation of a component of this type, the aggregate installer 20 sets 10 up the system so that if a reboot occurs, the aggregate installer 20 restarts after the reboot and carries on where it left off. The algorithm is adapted to install components having the reboot requirement "Automatic" after those that have the reboot requirement "ReturnCode".

15 In line seven of the table of Figure 6, the component is not in the inventory, the reboot requirement is Immediate and the dependency requirements have been satisfied. In this case, the optimization algorithm installs the component and immediately reboots the system before anything else is 20 installed. The algorithm is adapted to install components having these characteristics last.

As an example, consider the simple aggregate shown in Figure 7. Based on the RebootRequirement information alone, and using conventional techniques, this installation should

take between four and six reboots to complete. However, applying the optimization algorithm to identify whether any of the new components are already installed shows that component D is included in the inventory for the target 5 device and so is already installed. This means that D does not have to be installed again. Identifying this reduces by one the number of reboots that have to be done.

Having identified existing components, the algorithm is adapted to investigate dependencies. To do this, it checks 10 the metadata for each of the components to determine whether its installation is dependent on the earlier installation of other components. From Figure 7, it can be seen that for components C, D, E, G and H there are no dependencies. In contrast, component A is dependent on component B. This 15 means that A has to be installed before B. In addition, component B is dependent on component H. This means that H has to be installed before component B. Finally, component F is dependent on D. In this case, however, since D is already installed on he target terminal, it does not need to 20 be reinstalled before F. Once the dependencies are checked and satisfied, the algorithm investigates the reboot flags for each component.

This shows that no reboot is needed to install C. Hence, C has all of the characteristics of the component of line

three of Figure 8 and so can be installed first. The same is true for component H. which can be installed directly after C. But A, B and E are only installed when the system is, at some time, rebooted. Since A is dependent on B and 5 the system has to be rebooted to ensure that B is installed, this means that B and E should be installed before A and additionally that the system has to be rebooted to install B before A can be installed. For F. the reboot requirement is "ReturnCode". In the present case, it is assumed that the 10 installer identifies that a reboot is necessary. Because of the status of the reboot requirement for F. this means that it has to be installed after C, H. E and B. For component G. the reboot requirement is Automatic, which means that the algorithm places it behind the other components in the 15 installation order list.

Taking into account its various checks, for the case of the aggregate of Figure 7, the optimsation algorithm gives the following installation sequence: 1. Don't install D; 20 2. Install C 3. Install H 4. Install E 5. Install B 6. Install F

7. Install G 8. Reboot 9. Install A lo. Reboot 5 This sequence requires only two reboots to perform the complete installation, rather than the 4 to 6 as would be required using conventional installation techniques. In practice, this represents a significant time saving.

Obviously more complex installations give greater potential 10 for savings.

Once the installation order is identified, the algorithm creates an installation script for initiating and controlling installation of each of the components in the specified order. This script causes each of the components 15 to be installed in the correct order and causes reboots to occur, when necessary in the overall installation sequence.

Once the components are installed, the installation script causes the software component inventory 24 to be up-dated.

By dynamically creating installation scripts at 20 installation time independently of the package itself, there is provided a simple and effective mechanism for ensuring that the installation process is optimized to suit the target environment as well as be tailor to take into account the multiple components that are to be installed, without

any prior knowledge of the specific installation environment. An advantage of this is that installations times can be significantly reduced. In addition, by moving away from the conventional idea of fixed, inflexible 5 installation scripts, it means that the installation script algorithm itself can be up-dated without altering the package. This means that the skill level and training required by application developers for software packaging and installation can be reduced, thereby saving time and 10 money. Using the aggregate builder, an organizations entire set of software solutions can be delivered and installed using one single installation technology even if the constituent software components use different installation technologies. 15 A skilled person will appreciate that variations of the disclosed arrangements are possible without departing from the invention. Accordingly, the above description of a

specific embodiment is made by way of example only and not for the purposes of limitation. It will be clear to the 20 skilled person that minor modifications may be made without significant changes to the operation described.

Claims

Claims

1. A method of installing a plurality of software components in a device, the method involving identifying 5 characteristics associated with the components that are to be installed and/or existing software on the target device; and devising an installation process that is dependent on the data and/or existing software identified.

10 2. A method as claimed in claim 1, wherein the step of identifying is carried out at the time of installation.

3. A method as claimed in claim 1 or claim 2, wherein the step of devising is carried out at the time of installation.

4. A method as claimed in any of the preceding claims, wherein the step of identifying involves comparing each of the software components that are to be installed with existing software components resident at the device and 20 preventing the new component from being installed if an identical component already exists at the device.

5. A method as claimed in claim 4, wherein the step of comparing involves comparing an identifier, for example the

name, associated with a component that is to be installed with corresponding identifiers, for example the names, associated with the existing components.

S 6. A method as claimed in claim 5 comprising storing identifiers associated with existing components in an inventory. 7. A method as claimed in claim 6 further involving 10 maintaining the inventory of components installed on a device. 8. A method as claimed in claim 7 further involving up-

dating the inventory for the device after the new components 15 are installed.

9. A method as claimed in any of the preceding claims, wherein the characteristics include a dependency on another component. 10. A method as claimed in claim 9, wherein the step of devising an installation process involves arranging the order of installation of the components to ensure that any dependencies are satisfied.

11. A method as claimed in any of the preceding claims, wherein the characteristics include reboot information that is indicative of whether the target device has to be 5 rebooted in order to complete installation of a component.

12. A method as claimed in claim 11, wherein the step of devising an installation process involves arranging the order of installation of the components to ensure that any lO reboot requirements are satisfied.

13. A method as claimed in claim 12, wherein the step of arranging is done in such a manner to minimise the number of reboots needed.

14. An aggregate installer for initiating or managing the installation of a plurality of software components in a target device, the installer being configured to identify characteristics associated with the components that are to 20 be installed and/or existing software on the target device; and devise an installation process for the software components that is dependent on the data and/or existing software identified.

15. An installer as claimed in claim 14 configured to identify the characteristics and/or existing software at the time of installation.

5 16. An installer as claimed in claim 14 or claim 15 configured to devise the installation process at the time of installation. 17. An installer as claimed in any of claims 14 to 16 lO configured to identify existing software and compare each of the software components that are to be installed with existing software components identified and prevent the new component from being installed if an identical component already exists at the device.

18. An installer as claimed in claim 17 configured to compare an identifier, for example the name, associated with a component that is to be installed with identifiers, for example the names, associated with the existing components.

19. An installer as claimed in claim 17 or claim 18 configured to maintain an inventory of components or characteristics of such components installed on a device.

20. An installer as claimed in claim 19 further configured to up-date the inventory for the device after the new components are installed.

5 21. An installer as claimed in any of claims 14 to 20, wherein the characteristics include a dependency on another component and the installer is configured to devise an installation process by arranging the order of installation of the components to ensure that any dependencies are 10 satisfied.

22. An installer as claimed in any of claims 14 to 21, wherein the characteristics include reboot information that is indicative of whether the target device has to be 15 rebooted in order to complete installation of a component and the installer is configured to devise an installation process by arranging the order of installation of the components to ensure that any reboot requirements are satisfied. 23. A system for installing a plurality of software components in a computer based system, the system comprising means for identifying characteristics associated with the components that are to be installed and/or existing software

on the target device; and means for devising an installation process that is dependent on the data and/or existing software identified.

S 24. A system as claimed in claim 23, wherein the means for identifying are operable to identify characteristics and/or existing software at the time of installation.

25. A system as claimed in claim 23 or claim 24, wherein the 10 means for devising are operable to devise the installation process at the time of installation.

26. A computer program, preferably on a data carrier or a computer readable medium, for installing a plurality of 15 software components on a target device, the computer program having code or instructions for identifying data associated with the components that are to be installed and/or existing software on the target device; and devising an order for installing the software components that is dependent on the 20 data and/or existing software identified.