Patent Application
20060271924
1. Field of the Invention
The present invention generally relates configuration management of software components located on a computer, and more particularly to a manner of obtaining up-to-date lists of files and hardware necessary and prohibited for proper software installation and execution.
2. Description of the Related Art
Installing and updating new software to a computer system is a recurring task. Such installs may allow users to fix errors, for example, via a patch, improve performance, add features, and improve security among other things.
In a business environment, where an application may be shared out to many users simultaneously, it is particularly critical that the software installs occur routinely and with as few as possible errors or impediments. In the past, high data integrity of a generally-released code would rely on the vendor to record to CD or other media all code, data, and install programs. Subsequently, delivery occurred by mail. Users or information technology staff would spend time unpacking and loading the media into the target computer system.
More recently, software can be delivered as an electronic download over the Internet. Whether the software is provided on CD or as a download over the Internet, a delay may occur between when the software is made generally-available to when the software is actually installed, run, or updated. Occasionally, information technology staff would delay making the install or upgrade, while in other cases, a new customer would receive software after several generations of code releases. In any event, disparities in staff diligence and product introduction often resulted in system configurations of processors, storage, and supporting code modules, for example, operating systems, that vary widely.
Install programs generally have fairly routine tests to verify that a target system has sufficient memory, hard-disk storage, and other hardware and software prerequisites. However, the install programs could have very involved lists of dependency conditions to properly install and run the purported features of the new code-install. Dependency conditions are also known as dependencies.
One conundrum that vendor developers face is trying to anticipate interoperability between an application and later, but not-yet-released, versions of an operating system or other dependency. The vendor can either assume that later versions of the supporting code will change enough that the current application will not be supported, or the vendor can assume that the current application version will be supported by later versions.
If the former more conservative view is expressed in the install program, many false reports may be generated by the install program that the new operating system does not support the code install or upgrade. For example, the install dependency file may state that Windows XP Service Pack 2 (SP2) is a correct and supported level and nothing more. Then, when a later service pack, SP3, becomes available after the general availability of an application, the install program will report that the required SP2 is not there and suggest an error or some caveat, such as “proceed at your own risk”.
Clearly, such messages, when incorrect, do not create a good user experience. Such messages may ultimately impact a vendor's reputation and bottom line.
In the second case, the vendor assumes that the current application version will be supported by later versions. A later version of a dependency has the possibility of causing problems with the software being installed. For example, the newer operating system level conflicts with the software. This conflict could occur during installation or while running the software. The install program may not allow the user to continue with the software installation if a particular dependency version is not present and newer levels are not deemed acceptable. This situation would prevent the user from installing the software, leading to even more marked customer dissatisfaction.
Occasionally, users may seek to free up disk space by deleting old or seldom used files. A routine deleting effort, among other things, may result in the deleting of a file or other dependency of the installed software. Thus, a possibility lingers, even at runtime of the target software, that the target software's progress may be hampered by the loss of data or code upon which the software depends.
The present invention provides a method, apparatus, and computer usable program code for performing software operations for an application or target software on the computer. In response to an activation of an installation program, a determination is made as to whether an updated dependency file is present at a remote source for use in performing a software operation for the target software. If the updated dependency list is present, the updated dependency file is downloaded from the remote source. A determination is made as to an absence of a failed condition using the updated dependency file. The software operation is performed for the target software in response to the absence of the failed condition.
The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further objectives and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:
With reference now to the figures and in particular with reference to
With reference now to
In the depicted example, local area network (LAN) adapter 212, audio adapter 216, keyboard and mouse adapter 220, modem 222, read only memory (ROM) 224, hard disk drive (HDD) 226, CD-ROM driver 230, universal serial bus (USB) ports and other communications ports 232, and PCI/PCIe devices 234 may be connected to SB/ICH 210. PCI/PCIe devices may include, for example, Ethernet adapters, add-in cards, PC cards for notebook computers, etc. PCI uses a cardbus controller, while PCIe does not. ROM 224 may be, for example, a flash binary input/output system (BIOS). Hard disk drive 226 and CD-ROM drive 230 may use, for example, an integrated drive electronics (IDE) or serial advanced technology attachment (SATA) interface. A super I/O (SIO) device 236 may be connected to SB/ICH 210.
Docking interface 240 may also be connected to the SB/ICH. Data processing system of
An operating system runs on processor 202 and is used to coordinate and provide control of various components within data processing system in
Those of ordinary skill in the art will appreciate that the hardware in
For example, data processing system of
One or more illustrative embodiments of the invention may provide a mechanism by which a vendor's server may be consulted by an installer program. The installer program may be resident on the platform on which a user desires to install software. The platform may be, for example, data processing system 200 of
A pre-requisite list may include a listed program or data file or hardware, such as hard drive space and RAM, that should be installed and available for a feature or second program to work. A pre-requisite list may also be a correspondence between a feature and a set of program files or data files that must have at least one member of the set installed and available for the feature to work.
A co-requisite list is a list of one or more programs or data files that should be installed at substantially the same time as a target program in order for the target program to work.
A mutually exclusive list is a program or data file that should not be installed. The occurrence of a mutually exclusive condition could be either software that conflicts with the to-be-installed software or an assignment of hardware, both real and virtual, that conflicts. For example, the install could attempt to use a particular port that another program already uses. But the user may want to change the port of the original program. The user may choose to continue with the install, even after the warning. Thus, the occurrence of a mutually exclusive condition may permit the user to a) override; b) uninstall; or c) stop.
The nature of dependencies may be better understood with reference to
An initial set of extended markup language tagged identifiers define the product or software to which the extended markup language file of dependencies applies. Extended markup language tags “productID” may bound a serial number product identifier 301. Extended markup language tag “name” may bound a title or English name string for the product 303. Extended markup language tag “version” may bound version number 305, wherein versions may be numeric, with delimiting periods to signal the significance of the version. By convention, digits to the left of a period are treated as more significant than digits to the right of a period. Similarly, comparing a short version having fewer periods to a long version having more periods, the convention is that the short version is identical to one that has a trailing sequence of “.0.0.0” subversions. For example, when comparing a short version “9.0” to a long version “7.2.0.2”, version “9.0” may be treated as equivalent to the string that occurs when appending “.0.0” or the whole string “9.0.0.0”. As is typical in extended markup language hierarchical data description, the section relating to defining the specific product to which the file applies is bounded by the “<product name=”xxxx“>” 300 tag at the beginning and the “</product>” 307 tag at the conclusion.
One or more types of dependencies may be enclosed in the pair of extended markup language tags, “<dependencies>” 311 and “</dependencies>” 313 of
An expansive definition of a software or hardware may be enclosed within the option extended markup language tags, which may include a name and a product identifier, as defined earlier. In addition, a range of acceptable version numbers may be defined. The lowest acceptable version may be enclosed in the extended markup language tags “<minVersion>” 331 and “</minVersion>” 332. The highest acceptable version may be enclosed in the extended markup language tags “<maxVersion>” 333 and “</maxVersion>” 334. As may be appreciated, ranges may be defined that include low settings for memory and disk space. Low and high settings may be specified for internet protocol addresses. A lowest acceptable version, and a highest acceptable version, are examples of a range limitation. A range limitation has at least one limit specified.
The operating system prerequisites allow for either a “Windoze 2003” 337 or a “Windoze XP” 339 operating system. “Windoze XP” may be a mnemonic for “Windoze Extra Powerful”.
A corequisite section follows and is bounded by the extended markup language tags “<coreq name=”xxxx“>” 351 and “</coreq>” 355. Here the “WebSphere MQ” 353 is supplied for the “xxxx” of the tag just mentioned.
A mutually exclusive section follows and is bounded by the extended markup language tags “<xreq>” 361 and “</xreq>” 365. Recall that mutually exclusive items are forbidden if installation is desired. In the embodiments of the invention the presence of one or more mutually exclusive software or hardware causes the embodiments to stop installation of the product of software defined earlier in the file. Each dependency of the mutually exclusive section is bounded by the extended markup language tags “<option>” 367 and “</option>” 369. Each dependency has at least a name and a product identifier.
As may be appreciated, alternate embodiments may accept dependencies as several files, each file keeping a class of dependency inside itself. Various database formats may also be used as alternatives, and the embodiments of this invention are not limited to a specific form of defining the dependencies. Extended markup language is an easy-to-parse syntax for representing data. As such, the extended markup language may be well suited to distinguish the varying kinds of dependency conditions. It is appreciated that other markup language conventions may be used to identify the dependency conditions. In addition, dependency conditions may be stored in a database, or alternatively in a flat file. Thus, the embodiment of the present invention is not limited only to extended markup language representation of the dependency conditions.
The process begins with a user, perhaps at a command line prompt, commanding the installer to begin. The installer may be, for example, installer 401 of
The absence of network traffic results in the installer requesting that the user connect to the network (step 505). Such a request may be accomplished by dialog box or other methods known in the art. The installer may continuously test for network availability (step 507) or test only upon getting a positive input from the user, for example, by clicking on a “yes” dialog box button. The dependency list may also have been acquired and stored within the local computer network system, and the installer could ask the user where the newer dependency list is located. Two things, among others, may cause execution to divert, relying on the next best alternative to a remote-sourced dependency file: a fault in the interconnect to the vendor's server; or lack of an available remote-sourced dependency file. Execution diverts by using the dependency file available locally. The installer may ask the user where the newer dependency list is located. The installer may be, for example, installer 401 of
Preferably, the vendor has a file stored within a vendor's server or a site controlled by the vendor and the various network impediments do not occur. The vendor's server is also known as a remote source. Assuming that is the case, a positive result from the network connectivity test (step 507) causes further execution of checking if the remote-sourced dependency file is an updated dependency file (step 510). An updated dependency file exists when the creation or modification date associated with the remote-sourced dependency file is later than a creation or modification date associated with the local dependency file. A positive result from checking update (step 510) causes further execution of downloading the dependency file for the software (step 511). The step of downloading the dependency file may include reading the dependency file. It is appreciated that although there is shown a direct sequence of steps from first network step of attempting to download a dependency file (step 511), many things may happen during the interval from (step 503) to (step 511) that are beyond the control and scope of the invention. For example, the vendor's server could be subjected to a denial of service attack, or the vendor could have forgotten to place a dependency list file on remote source. Nevertheless, within the scope of attempting to download the dependency file is the act of actually downloading the dependency file.
In addition, the downloading of the dependency file may include downloads of several files. The collective file or files may contain one or more of a prerequisite list, a co-requisite list, and a mutually exclusive list.
Downloading may use any convenient protocol, for example, file transfer protocol, hypertext transfer protocol and the like. The format of the dependency file may be an extended markup language file or any convenient format.
Following any attempt to download an updated dependency file, the installer may check each dependency in a dependency list applicable to a selected feature or features for install, including one or more prerequisites (step 515). One point of novelty in this illustrative embodiment of the invention is that the step of checking for conditional dependencies is performed very close in time after the attempt to download the dependency file. In other words, there is a short delay between the conclusion of the downloading step (step 511) and the start of checking for conditional dependency (step 515), which may be shorter than a few seconds. The prerequisite list may show one or more conditions. Essentially, the installer checks for failed conditions. If all conditions are met, execution may continue to check the co-requisite list applicable to the selected feature or features for install (step 517). The co-requisite list may show one or more conditions. Essentially the installer checks for the absence of a failed condition. If all conditions are met, execution may continue to check the mutually exclusive list applicable to the selected feature or features for install (step 519). The mutually exclusive list may show one or more conditions. The installer checks for the absence of a failed condition. If, still, all conditions are met, the installer proceeds to perform a software operation, which may be, for example, installation of the target software (step 521). In addition, the software operation may be a removal of the target software, a maintenance operation for the target software, or an update of the target software. It is appreciated that steps 517, 519 and 521 may be performed in any order, since each of the steps involves checking a different kind of dependency.
Collectively, the steps of checking prerequisites (step 515), checking co-requisites (step 517), and checking for mutually exclusive conditions (step 519) are known as checking conditional dependencies. It is the absence of failed conditional dependencies that is the outcome of positive results from steps 515, 517 and 519.
In any event, a failure to download the vendor-server-sourced dependency file is not fatal to the continuing install and upgrade process. The default dependency file may be included among the software distribution files that comprise the software-to-be-installed, and it is that, less dynamic file, to be used for the various checks confirming available supporting programs, data, and hardware.
Optionally, the installer may ask the user to identify a preferred set of features and functions that the user desires installed as part of install command(step 501), as there may be various gradations of install that permit user preferences to be taken into account.
Operation continues by using the dependency file that is available from either the distribution media or the vendor's site. First, installer may confirm that the prerequisites are all met (step 615), if any. Next, installer may confirm that the co-requisites are all met (step 617), if any. Installer may next check to confirm that all mutually exclusive conditions are met (step 619), if any. Assuming that each of the conditions of the prerequisites, co-requisites, and mutually exclusive conditions are met (i.e. absence of failures), the installer may install the software (step 621). A negative outcome at any of steps 615, 617 and 619 may result in the installation being aborted, perhaps with installer issuing some warning message to the user.
Yet another embodiment could implement all the steps of
It is appreciated that “running the program” may be accomplished in several different ways: clicking on an icon, entering a program name on a command line or even triggering an event in a browser or other intermediate program, wherein the actual program is invoked as a plug-in.
By having an active network connection download the freshest dependency file for a proposed software install or upgrade, a user avoids many of the spurious caveat messages that occur when using an outdated dependency file that is shipped with the distribution media for the software intended for install. Fewer calls and complaints are made to the vendor, thus proactively avoiding problems. In addition, a better user experience improves the continued relationship between user and vendor.
Equally important is the fact that use of the runtime embodiment may prevent operating the software without necessary supporting software and/or hardware. The runtime embodiment makes the problem more apparent so that a remedy may be found without unknown results happening. Unknown results happen if the target software is run into a potentially more damaging error condition.
The different aspects of the present invention can take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment containing both hardware and software elements. In a preferred embodiment, the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc.
Furthermore, the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk—read only memory (CD-ROM), compact disk—read/write (CD-R/W) and DVD.
The description of the present invention has been presented for purposes of illustration and description, and is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art. The embodiment was chosen and described in order to best explain the principles of the invention, the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.
