Browse Prior Art Database

Use of replaceable parameters in deployment of an e-business solution

IP.com Disclosure Number: IPCOM000013938D
Original Publication Date: 2001-Mar-01
Included in the Prior Art Database: 2003-Jun-19
Document File: 1 page(s) / 38K

Publishing Venue

IBM

Abstract

In a multi-tier solution topology, resources may exist on a number of physically separate machines. These resources can include business objects, configuration files, command files, programs, classes, text files, message queues, message flows and database tables (with data). The resources are configured and controlled by a number of control files and scripts, which are installed at the same time as the rest of the solution. A post-installation demonstration, tutorial, or installation verification test of the solution may be provided in the form of one or more examples, which will be comprised of such resources. It is desirable that these should be able to run without requiring the user to perform additional setup tasks. In addition to the desirability from the user's point of view of avoiding needing to ask the user to perform additional setup tasks, the avoidance of such intervention is likely to make the system less error prone. Furthermore, if the examples can be run without such intervention this provides the ability to run automated installation verification tests on completion of installation. The configuration files and scripts needed to deploy and run examples in a multi-machine solution topology are dependent on various aspects of the choices (such as install paths, user names and passwords) made by the user during installation. What is needed is a means of making the user's selections available to the configuration files. The solution topology is most lilkely to be a distributed system in which the configuration scripts will not (initially) have access to any of the other machines, and in which the machines may be installed using different settings. The files installed onto each machine must be aware of the local settings. Some of the files have fixed formats, such as XML DTDs and cannot be simply parameterised. The problem must be solved in a non-platform specific manner, in order to support solution topologies which are heterogeneous. To address this problem, the solution installation program may be augmented to modify the content of the configuration files and scripts based on a number of replaceable parameters. The advantages of this approach are that the configuration files are complete there are no additional parameters to be retrieved from a solution repository, which is thus rendered unnecessary and the use of which would make the configuration files harder to understand. This would be a particular disadvantage where the files relate to an example which is supposed to provide educational value. Furthermore, such an approach is portable across platforms, whereas all alternatives considered would have been subject to platform inconsistencies. On completion of install, the whole solution is completely defined by the configuration files.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 1

Use of replaceable parameters in deployment of an e-business solution

In a multi-tier solution topology, resources may exist on a number of physically separate machines. These resources can include business objects, configuration files, command files, programs, classes, text files, message queues, message flows and database tables (with data). The resources are configured and controlled by a number of control files and scripts, which are installed at the same time as the rest of the solution.

    A post-installation demonstration, tutorial, or installation verification test of the solution may be provided in the form of one or more examples, which will be comprised of such resources. It is desirable that these should be able to run without requiring the user to perform additional setup tasks. In addition to the desirability from the user's point of view of avoiding needing to ask the user to perform additional setup tasks, the avoidance of such intervention is likely to make the system less error prone. Furthermore, if the examples can be run without such intervention this provides the ability to run automated installation verification tests on completion of installation.

    The configuration files and scripts needed to deploy and run examples in a multi-machine solution topology are dependent on various aspects of the choices (such as install paths, user names and passwords) made by the user during installation. What is needed is a means of making the user's selections...