Data processing: software development – installation – and managem – Software program development tool – Translation of code
Reexamination Certificate
1998-07-21
2001-02-06
Chaki, Kakali (Department: 2762)
Data processing: software development, installation, and managem
Software program development tool
Translation of code
C707S793000
Reexamination Certificate
active
06185734
ABSTRACT:
BACKGROUND OF THE INVENTION
This invention relates generally to replacing software components in a computer system and more particularly to managing multiple versions of a software component.
Most software applications use software libraries, a group of software routines collected together, usually for a related purpose. The purpose of the library can be said to be the library's “service”. Software libraries are made available to a software application through the use of a linker. A linker has the task of combining a series of independently compiled or assembled program routines into a single module (the executable program). Libraries are incorporated into the executable program by one of two linking methods: a library can either be statically linked or dynamically linked to the application. When a library is statically linked, the library or library routine is made part of the executable program during the link. Therefore any modifications to a statically linked library would require a new executable program to be built by the linker.
A dynamically linked library exists, on the other band, outside of the executable program. At link time the linker must know all of the external references of a library, such as the names of the routines available, but does not need to know the actual contents of the library itself, or even its location. It is not until run-time that the program must be able to determine the location of the library. Determining the location of the library at runtime is known as “runtime binding”. Therefore a dynamically linked library is free to change everything except its interface definition up until the time it is executed.
However, dynamic linking does not, by itself, provide true dynamic updating. It does not allow for changing a reference to an external procedure during a run after the references have been established. The binding takes place at or before the first time a procedure is invoked. Subsequent references are not typically rebound. Even if the external reference is resolved every time the external procedure is called, dynamic linking is ineffective because it does not allow replacing a software component while that component is being executed. Also, changing libraries by dynamic linking does not keep track of the “state” of the library from the old version to the new version. When the new version is in place, it does not know the state of the library data structures or other state data that the old version had created. This will lead to an update that is unreliable to the user.
To be able to use more than one version of a software library, there must be a way to keep track of which application uses which software library. When a software library is available as a dynamically linked library, an application cannot distinguish between multiple versions of a software library. An application run-time binds to the first version of a software library that it identifies. Therefore, the only way to update to a new version of a dynamically linked library is to make a system-wide switch to the new version of the library, i.e., delete the old version. All applications then upgrade to the new version of the software library. This method involves halting all applications, installing the new version of the library, and restarting the applications, which will now bind to the new version. This method requires all applications on a system to use the same version of the library.
To overcome the problem of an application being unable to determine which version of a software library to runtime bind to, each application can be statically linked directly to its own version of a software library. This removes any ambiguity over which version of the library to use. However, changing a version of the software library used by the application requires the application to be re-linked to the new version of the software library. The application process running with the old version of the software library must be stopped or completed before a new application process with the new version of the software library can be started.
In addition to the inconvenience of halting the application so as to restart using the new version of the library, there are several other disadvantages with this method. Unlike dynamic linking, which involves updating to a new dynamically linked library, static linking to libraries requires linking to the unlinked objects that make up the library. Libraries are often provided by vendors, who generally do not provide the unlinked compiled objects of the library to the end-user for re-linking. Instead vendors usually provide a new dynamic library. Also, in a static link, the location of the library is fixed as of the time of the link. Lastly, this method can be difficult to manage, since it is difficult to tell which version of the library is being used by which application.
Therefore, there is a need for a system and a method for managing the update of a library in a system without requiring the halting of applications using the library.
Further, there is a need to manage such a system to allow for multiple applications to each potentially use its own version of a software library.
Further, there is a need to manage this system in an easy to use and flexible method.
SUMMARY OF THE INVENTION
The present invention provides a system and a method to manage changes in the versions of a software component and to allow for the use of different versions of a software component by different applications. A centralized hierarchical registry (the registry) is implemented to track which version of a software component each application currently uses.
The commonly assigned application Ser. No. 09/120,040 filed Jul. 21, 1998 and entitled SYSTEM AND METHOD FOR ON-LINE REPLACEMENT OF SOFTWARE describes a system and method of replacing libraries on-the-fly, where the application and a replaceable “implementation” library must not be linked or run-time bound to each other. The application, instead, is linked to an “interface library” that contains proxy interfaces for all routines found in the implementation library. The interface library can, at run-time, determine the location of the implementation library. The system and method of replacing libraries on-the-fly allows for replacing libraries without restarting the application. In the described embodiment of the invention, the registry is used to keep track of multiple versions of the implementation libraries. However, the techniques described herein may be used to keep track of multiple versions of any software component, other than a software library, such as a software procedure or an entire software program. Regardless of the software component type, all versions of a software component have a “service” that they provide. The user of the service, such as an application program, uses a particular version of that service, depending on the conditions of the application and the state of the version of the software service.
The invention allows for several versions of a software library to be used by several different applications within the same system. An application can be updated to a new version of the library without re-linking to the library or restarting. A hierarchical registry, according to the present invention, is easy to manage due to its centralized nature. The invention also allows for great flexibility in the management of multiple libraries by offering the freedom for libraries to be deleted and updated on the fly without impacting applications.
In the presently preferred embodiment, each version of a software library has a corresponding base entry in the registry. Generally, one base entry identifies a default software library to be used by an application calling the library's service, while one additional base entry exists for each additional version of a library service. Any base entry may have rules, each rule defining the conditions that must be met for an application to use the corresponding version of the software library. A base entry may have more than one rule or no rules at all. If t
Maag Andrew
McGowen Alan
Saboff Michael L.
Chaki Kakali
Hewlett--Packard Company
LandOfFree
Hierarchical registry structure for managing multiple... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Hierarchical registry structure for managing multiple..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Hierarchical registry structure for managing multiple... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2604620