Level: Introductory Charlie Halloran, Jr. (cwh@us.ibm.com), Senior Software Engineer, IBM
10 May 2005 Solution installation technology in the IBM® Autonomic Computing Toolkit is best understood in terms of the Solution Installation descriptor. With examples included here, learn how to use the Solution Installation descriptor to reap the benefits of self-configuring technology from the Autonomic Computing Toolkit. By eliminating tasks normally required of the software packager and the user who's installing it, solution installation technology saves time and eliminates errors.
Introduction
The promise of autonomic computing technology is to enable computer systems and products to manage themselves. One aspect of self-managing software is its ability to configure itself. The solution installation technology in the Autonomic Computing Toolkit enables applications to be self-configuring, making it easier for customers to start using the software without investing a lot of time and skills installing and configuring.
To bring an application on board, three things need to be done:
- Check for a proper installation environment.
- Copy all required files and objects from install media.
- Make any modifications to the default configuration to reflect the proper operating environment.
The solution installation technology in the Autonomic Computing Toolkit contains an architected data format and a run-time library that lets these three steps be completely described and implemented, resulting in a much
simpler and smoother installation experience, and yields an application that is ready to be used.
The solution installation samples in the Autonomic Computing Toolkit illustrate important concepts and
provide insight into how solution installation technology can be used in a typical fashion. Download and install two packages from the Autonomic Computing Toolkit:
Specifically, the Family Lifecycle sample is referred to throughout this article. When referring to directories, standard Windows™ directory naming applies. Note, there also is an InstallShield scenario as well, with similar capabilities and files. That scenario can also be examined after you understand the concepts explained in this article.
Managing dependencies
The first step, as mentioned above, is to check for a proper installation environment. A particular solution might have a number of technical requirements. The traditional approach is to document the requirements in an installation guide and leave it to the user to figure out if their environment meets system requirements. This strategy requires that the user know how to check for the requirements in the first place. What?s the command on Linux to check for total disk space left in a filesystem? What about on AIX®? How can you tell if a particular release of a software prerequisite exists on the system? These typical questions are left for the user to answer when the only directions given in an installation guide are a list of dependencies.
Managing dependencies the autonomic way
Because the software developers already know what the dependencies are, the better approach is
to have the software check the system on behalf of the user. The ability to define and execute dependency checks is one of the main advantages of solution installation technology. To see an example of how this is done, open the NeptuneMoonsPackage.zip file from the Solution Installation and Deployment Scenario using InstallAnywhere, which you downloaded from the Autonomic Computing Toolkit. The file is in the Program Files\IBM\AutonomicComputingToolkit\Neptune Moons Zero G\readme-toolkit directory.
Within this zip file is a file called packaged_IU.xml. This file is the main Solution Installation descriptor file that describes the entire solution, including its dependencies. The other files that make up the entity being installed are called the artifacts. Each part of the solution that can be thought of as a separate component or stand-alone entity is called an Installable Unit (IU). The XML file is called an SDD, short for Solution Deployment Descriptor. The format of this XML file is defined by the Solution Installation schema, which is a set of specifications that provides a framework for describing a solution, all its attributes and dependencies, and the actions to be performed when deploying it.
Figure 1.Sample Solution Deployment Descriptor
You can find the entire Solution Installation specification on the W3C standards organization Web site (see Resources for more information). The schema is complex and inclusive, so not all of it will be used for every solution, and certainly not for these samples. It is not necessary to understand it all to follow the samples contained in the Autonomic Computing Toolkit.
To continue the examination of the dependencies contained within the packaged_IU.xml file, edit the file using an Internet browser or a specialized XML editor. At the beginning of the XML code are schema elements that define the name of the particular IU. In this case, the name is "Neptune Moons Common Component" and is Version 1.0.0. These values are associated with the attributes <name> and <version> under the <identity> tag. It is a straightforward way to describe what the solution is or represents. Likewise, dependencies are also associated with XML tags.
Defining dependencies
The dependencies are located in a section of the XML labeled <checks>.
Searching the XML for this string of characters reveals the list of checks defined for the Neptune Moons package. Solution Installation checks are strictly defined:
- Property checks for attributes such as operating system type
- Capacity checks for defining upper bounds of resources used, such as memory
- Consumption checks for defining the amount of resources used, such as disk space
- Installable unit checks for a dependency on a specific, named installable unit
- Software checks for a dependency on a software package that might not be an installable unit
- Custom checks for anything not covered by the above
Dependency checks are specified in the installable unit as requirements, hierarchically shown in
Figure 2.
Figure 2. Checks within an installable unit
In the Neptune Moons scenario, the following information is contained in the checks:
- The solution requires a Windows or Linux operating system (property check).
- It requires at least a 400-MHz processor (capacity check).
- It requires at least 50 MB of disk space (consumption check).
- It checks for a specific IU version 1.0.0.0 (iu check).
- It checks for a software program with files named "Bogoware." (software check).
These definitions merely define the dependency checks. To actually implement checks within the file requires them to appear in a <validationRequirements> tag. Within this tag, every check to be enforced must be called out with a <checkitem> tag. In this scenario's packagedIU.xml file, the only two checks explicitly called out are:
- The Jupiter IU check (checking that the IU is not installed using a false result)
- The software check (checking that the fictional "Bogoware" is not installed using a false result)
Note that the other checks, even though defined in the XML, are not actually implemented in this example. When the scenario is installed, the processor speed, memory, and disk space do not matter because there is no <checkitem> present for those checks.
Looking at how the dependencies are recorded, you can define in the XML file the same kind of information that would be in an installation guide. The difference is, when the dependencies are in a standard format they can be interpreted by the Solution Installation run time. The Solution Installation run time is called during the deployment process, reads the XML, and executes the checks and requirements contained in it. It is the Solution Installation run time that knows how to do all the checking. The user does not have to read the requirements and then figure out if the target environment satisfies them. It is all done automatically by the Solution Installation. No user errors and no time spent researching. One burden has been lifted.
Packaging considerations
After it has been confirmed that the target environment satisfies all requirements, the actual physical installation can begin. While copying files is necessary, it is not very exciting; this will be brought up again later in this article. What is exciting is the way Solution Installation allows applications to be structured and deployed. Applications can be packaged as a single executable (wrapping a descriptor around a setup.exe or RPM, for example), or as an aggregation, or combination, of files, programs, or other packages. Before discussing the mechanics of the installation process, it is useful to understand how applications can be assembled using Solution Installation. They can be simple, single-installable solutions, or complex solutions made up of many components or other solutions. Both types are described below.
A simple deployment package
The simplest way to use Solution Installation is to wrap the XML statements around a self-installing executable. Most small, commercial, Windows-based applications are packaged in a file called setup.exe or something equivalent. This executable is called an MSI, short for Microsoft Installer. The Solution Installation architecture (XML) can be used to describe the MSI package and its dependencies. The XML can then specify
that the MSI is executed, which performs the physical installation. Other operating system platforms have similar native packages that can be deployed in the same way.
The Autonomic Computing Toolkit has an example of a simple IU called Daughter 1.2.0 Fix. The package in the Solution Installation and Deployment Samples Scenario (which you downloaded earlier), is in the Daughter_1.2.0_Fix.zip file in the Program Files\IBM\AutonomicComputingToolkit\SolutionInstallSamples\samples\family directory.
Open this file using a zip file viewer. Inside the zip file is a packagedIU.xml file that describes the application. In this case, it is a fix to a base product, but it is still a simple IU that happens to require a base product first. Everything in the packagedIU.xml file is a wrapper that describes, in this sample, a single file to be copied. The file is included in the zip file (Daughter_1.2.0_Fix.txt) and referenced in the SDD inside a file called DaughterFixInstallArtifact.xml. Inside this file is an action that adds a file named Daughter_1.2.0_Fix.txt. The actual tag is <addFile>, which causes the file to be copied to the target system (see Figure 3).
Figure 3. Simple package descriptor
A wrappered MSI can be created in exactly the same manner, with a couple of exceptions. The packagedIU.xml file is remarkably the same. The difference comes in the action tag in the artifact xml file. Instead of the <addFile> tag, an action tag of <installMSIProduct> would be used, which would refer to the MSI package file (such as setup.exe). In this case, instead of simply getting copied, Solution Installation knows that the file referred to by <installMSIProduct> should be executed because it is a self-installing product file.
An aggregated deployment package
Up to now, you have learned how to describe an application, its dependencies, and then start the installation of the application using Solution Installation. But the real power of Solution Installation is in the aggregation of packages, such as native installables (MSI on Windows, or RPM on Linux, or installp on AIX, or those of
other platforms) or other Solution Installation packages. An example of aggregation can be found in the Family_2.0.0_Base.zip file in the same family directory, Program Files\IBM\AutonomicComputingToolkit\SolutionInstallSamples\samples\family.
Open this file in a zip viewer and look at the packagedIU.xml file. This solution is composed of six separate IUs. They are called SIUs, which is short for Smallest Installable Unit. In this example, all six IUs are included inline in the packagedIU.xml file. So, the definitions of Daughter, Son, Mom, Dad, Cat, and Dog are all listed in the one packagedIU.xml file. This is one way to aggregate components or simple applications in a single package.
This aggregation is a basic example, where each SIU is of the same type. In practice, all of the SIUs in any package do not have to be targeted for the same kind of system. They could be an MSI, or even a couple of MSIs and an RPM. As long as the proper checks and requirements match their target topology, you can mix SIU types within an aggregated package.
The other way to organize an aggregated package is to include the individual packages themselves. Instead of including all the SIU definitions inline in a single packagedIU.xml file, each SIU can be composed of a self-contained package. The root packagedIU.xml file would merely consist of pointers to separate packages contained within the zip file itself. For example, the Son SIU would not be defined in the root packagedIU.xml file; it would be termed a ReferencedIU and point to a zip file that is contained inside the whole solution zip file. Inside this type of Son package would be its files and its own packagedIU.xml file that describes the Son solution. The power of this organization is that tested packages can be combined together to form a complex solution without disturbing or opening the SIU packages. This strategy saves an incredible amount of test time because the individual SIU packages are exactly the same as had been tested during their development process. The concept of an aggregated package is shown in Figure 4.
Figure 4. Aggregated package using a referenced IU
Action!
Now that the solution is properly organized and the target environment is set, it is time to see what happens during the actual installation. Solution Installation is composed of not only the XML architecture as has been discussed, but also run-time code that interprets that XML. It is the run-time code that does the dependency checking and also performs the actions that result in the successful deployment of the solution. The actions are defined in an XML file within the package, separate from the packagedIU.xml file. These files are called action artifacts. There can be one artifact XML file for every action to be performed on the IU. The currently supported actions are:
- Install
- Uninstall
- InitConfig (initial configuration of an IU)
- Migrate (used during an update of the base IU)
Because InitConfig (used during an initial install) and Migrate (used during an upgrade) are mutually exclusive, an IU can have at most three action artifacts: Install/InitConfig/Uninstall, or Install/Migrate/Uninstall.
Again, turn to the sample Family_2.0.0_Base.zip file. The action artifacts are referenced in this solution?s packagedIU.xml file as seen in Figure 5. The packagedIU.xml file defines the file name of the artifact file, in this case, MomInstallArtifact. This is the XML file used to define the actions to be performed for the Install action for the Mom IU. Within the Family_2.0.0_Base.zip file is a MomInstallArtifact.xml file. The Solution Installation run time uses that XML file to determine what to do when performing the install operation.
Figure 5. Action artifacts, as referenced by the packagedIU.xml file
Types of actions
Before looking at the artifact sample, it is worthwhile to know what types of actions are allowed within the XML schema. The actions that are possible depend on the target of the deployment. The target is also called a hosting environment because it hosts the solution. This means that different things can be done to different hosting environments. While adding a file is pretty much the same on Windows and AIX, adding a registry key
or installing an MSI are commands only Windows understands. Therefore, some actions apply only to an appropriate list of hosting environments; for example, a Web application server. Actions such as creating a directory do not apply because the application server cannot create a directory; only the operating system can do that.
Because there are many different hosting environments, there are many different actions. Each hosting environment has its own list. Each is different, so there must be a program that executes the action for each hosting environment. This program is called a touchpoint. The touchpoint that handles operating system actions is called an OS touchpoint. There can be other touchpoints as well, such as a Web application server touchpoint or a database server touchpoint. The Autonomic Computing Toolkit uses only the OS touchpoint, and this is the only touchpoint that is part of the Solution Installation run time. The complete list of actions supported by the OS touchpoint can be found in the Operating System Touchpoint Guide and Reference manual, found in the Autonomic Computing Toolkit documentation bundle (see Resources).
The following common actions are a subset of this list:
addFileaddDirectoryaddWinRegistryValueinstallMSIProductinstallRPMPackageinstallAIXPackageupdateTextFileexecuteExternalCommandexecuteJavaClass
The last two actions in the list, executeExternalCommand and executeJavaClass, are catch-alls that allow any other command to be executed. There is no way for Solution Installation to architect every possible action that a developer may want to take when
installing a solution. So, customized actions can be taken by invoking these two special actions. They both allow a file to be specified that is either a native command (executeExternalCommand) or a Java program (executeJavaClass). These actions provide a high degree of customization capability within Solution Installation and make it possible for just about anything to be done as part of the installation process.
Examples of actions
In the Family 2.0.0 sample, only a simple addFile action is defined. The Mom IU install artifact, conveniently named MomInstallArtifact.xml, is shown in Figure 6. It is very simple. The main XML tag is the <addFile> action, which indicates that a file is to be
copied to the place specified by <name> from a place specified by <source>. After this action is completed, the file Mom_2.0.0.txt will exist on the filesystem.
Figure 6. Install artifact for the Mom installable unit
The two other Mom IU artifacts in the Family_2.0.0_Base.zip file are similarly constructed. The MomInitConfigArtifact.xml updates the Mom_2.0.0.txt file by appending the line "Initial Config Complete." The MomUninstallArtifact.xml removes the text file and all relevant directories. For completeness, MomMigrateArtifact.xml is included, which adds the line "Migrate Complete" to Mom_2.0.0.txt. However, as noted earlier, both the Migrate and InitConfig artifacts would not be executed during the same installation.
If other actions, taken from the list in the OS Touchpoint Guide and Reference, are needed, they are specified in the same manner. Each action is an XML tag in the artifact file and has its own associated information.
The ability to make actions happen by specifying XML, without knowing how to perform them on multiple platforms, is a huge time saver when putting together a solution. Common actions are basically predefined, with the ability to extend into executing other customized operations. In this way, solutions can be configured after they are deployed, ensuring they are configured properly, and saving the end user time.
Next steps
The advantages of Solution Installation are numerous. Software can be packaged to list dependencies, check them, and allow or disallow the installation depending on the results. Individual packages can be combined into one large aggregation by wrapping them together, thus preserving the testing done on each component package. Finally, actions to be performed can be included so that all the steps needed to be ready to run can be executed automatically.
These concepts are demonstrated by the samples included in the Autonomic Computing Toolkit. The
samples can be modified with any XML editor to try out other actions or test for other dependencies. For more comprehensive changes, a sophisticated tool will make it easier to create and edit SI packages. Two partners have announced support for the Solution Installation framework. Both Macrovision and Zero G Software have products in beta that make it easier to author SI descriptors and packages.
You may also contact IBM at actool@us.ibm.com, visit the
Autonomic Computing Web site for high-level information, or visit the developerWorks Autonomic Computing zone for articles and tutorials geared to developers.
Resources
About the author  | 
| | Charlie Halloran, Jr. has worked in the Autonomic Computing group at IBM Research Triangle Park, NC, for the past two years, focusing primarily on Solution Installation (SI) technology. He participated in the original workgroup defining the SI scope and schema, and has assisted with the implementation of the SI technology by business partners and customers. His responsibilities also include the SI bundles in the Autonomic Computing Toolkit. Charlie has a Computer Science degree from North Carolina State University and has worked for IBM for 24 years. He has spent his entire career in software, including support, services development, and product development positions. He can be reached at cwh@us.ibm.com. |
Rate this page
| 
