Existing Technologies to Solve Application-Related Problems

Existing Technologies to Solve Application- Related Problems

The problems associated with deploying different versions of an application have existed for a number of years , and various systems have been implemented to overcome these problems. These solutions include the use of "well-known" locations to store globally accessible code, the use of user -configurable search paths to modify the way in which the names of executables are resolved at runtime, and the use of symbolic names which add a level of indirection during name resolution.

Well-Known Locations

Most operating systems provide one or more "well-known" directories that may hold publicly accessible executable files. Administrators can install an application or components into one of these well-known directories to make them potentially available to all users on a system.

For example, UNIX operating systems often have directories named bin for just this purpose. Normally these directories hold many executable files that are fundamental to running different applications, including the operating system itself. A UNIX operating system may support a number of well-known directories, such as /bin , /usr/bin and /usr/local/bin . Individual users can also create a directory off their home directories, again often named bin , and insert programs that they wish to execute into this directory. In most cases, these programs remain private to individual users.

In the Windows operating systems, the System32 directory is another example of a well-known directory.

Search Paths

Many operating systems allow the user to define a PATH variable that contains a list of directories. The operating system uses this list of directories when searching for executables on behalf of a user, by sequentially looking in each directory in the PATH variable until it finds the named program. The search stops when the file name is first found, without taking any other context or any other installed versions into account. Thus the order of the directories in the PATH variable can be critical. For instance, the desired file may exist on the system but not be used if the directory is located later on the PATH variable's list than another file with the same name.

Recent versions of Microsoft Windows support a concept called "side-by-side component sharing" that uses a variation on search paths to implement multiple versions of the same component. This technique simply searches the application's directory for matching components before checking the well-known system location. Although this approach goes some way toward solving the problem, it relies on vendors to modify their applications to support this technique, and it does not cover every scenario where components need to be shared.

Symbolic Names

Most operating systems allow users to create symbolic names (or links) to files. A symbolic link is another name that refers to the same file. It may be located in any directory and may have any valid file name. For example, a meaningful symbolic name, such as MyEditor , might refer to a file such as ed_eng_12_3 .

This concept can also be extended to directories. For example, the X11 windowing system, also known as X Windows, which is commonly found on Linux installations, uses symbolic names to point to the specific installation version. In the following directory listing, the /usr/lib directory has a directory named X11 , which is actually a symbolic link to the /usr/X11R6 directory:

 [skip@localhost lib]$ ls -l X11  lrwxrwxrwx    1 root ...        16 Apr 19  2001 X11 -> ../X11R6/lib/X11 [skip@localhost lib]$ 

Applications can simply refer to /usr/lib/X11 without having any knowledge of the specific version installed on the machine.

Versioning-Related Technologies

A combination of the concepts of well-known directories, PATH variables , and symbolic links provides a solution to problems related to versioning. Suppose that version 1 of a program called Editor is installed on a system in a subdirectory called Editor1 . The system administrator may install a symbolic link called Editor in a well-known directory that points to the Editor executable in the directory Editor1 . Users then include the well-known directory in their individual PATH variables, so that when a user types Editor and presses the return key the Editor program executes.

What happens when the vendor releases the next version of Editor ? The system administrator might install the new Editor program in an Editor2 subdirectory. Changing the symbolic link so that it no longer points to the Editor executable in directory Editor1 but rather points to the version in Editor2 upgrades all users on the system without any intervention on their behalf. A limitation with this approach, however, is that it upgrades all users at the same time; users who wish to continue using version 1 of the Editor program must now take explicit actions to access the previous version (but at least they can do so).

Now if a user wishes to use the beta version of Editor3 , then he or she can install the beta version in one of the user's own directories, such as a local bin directory. If the user changes the PATH variable to look in the local directory before looking in the global directories, then the beta version will be loaded when the user types Editor at the prompt. A limitation here is that changing the PATH variable affects lookup of all executable programs.

Does the use of these schemes solve all versioning problems? While they do provide an amount of useful functionality, some problems persist. First, configuring a system involves a number of processes and people, from system administrators to users. Second, these strategies function well in a fairly static system; systems that incorporate the dynamic downloading of executable code do not fit well into this model.

Windows Registry

The Windows Registry provides some of the abilities described previously. It is a well-known location where the operating system and applications can go to resolve a call for executable code. One of the elements in the Registry that COM uses is program IDs; they provide some of the benefits of symbolic names, where each program ID can be translated into an executable file on disk. An example of a program ID is Excel.Application.10 , where 10 is the version number. Over a period of time, the location of the code referenced by a program ID can change without the need for clients to take any action.

Use of the Registry has a number of limitations. First, only one Registry exists; users cannot add their own private registry. Second, the Registry is fairly complicated when compared to a directory structure. Indeed, inserting an executable into a well-known directory is much simpler than adding entries to the Windows Registry.

The major limitation of the Registry, however, is that the information contained in it and the executable files to which it refers remain separate. Therefore, whenever an executable file that requires information to be inserted in the Registry is moved to a new machine, the installation scripts must update the Registry. Maintaining consistency between the Registry and the actual files on disk can be an arduous task. One goal of any deployment system should be improved simplicity in copying a file to a location and making it available for subsequent use without any additional overhead.