Browse Prior Art Database

Dynamic selection of configuration file, with failsafe operation

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

Publishing Venue

IBM

Abstract

Where a system has a pluggable architecture, allowing the plugging in and removal of components (such as Nodes in a message flow system), the user interface (tooling) for the system needs to accurately reflect the set of components which are presently "plugged". One approach to this is to searching at startup of the interface, for which components are present and dynamically construct the displayable set. If the user interface relied purely on live data for the the dynamic creation of the set of components there would be a risk that the interface could not be constructed under certain circumstances, if for any reason the necessary data were not available or not accessible at startup. It is therefore sometimes desirable that a "default" configuration be assumed. Where a product assumes a default configuration, this may not always be appropriate for all possible types of installation. As an example, if such a product was shipped which did not include the nodes of type A, then on startup of the Control Center the workspace would (currently) display the nodes, even though they were not installed. The use of a single default is incompatible with the flexible installation of such a system by a solution install which may elect one of a number of possible combinations of functional content. It is therefore desirable to externalise the default workspace by providing it as a separate file. This, however, leads to a risk that if the file is deleted or corrupted that the Control Center cannot render a default workspace. The invention externalises the default workspace such that it can be loaded from file, but that if for any reason that load failed, then to revert to a hard coded default workspace. This allows the product to operate in such a way that, without modification to the product itself it could pick up a preferred configuration which suited the way that it has been installed, whilst still maintaining the ability to use its internally defined hard-coded configuration if necessary which is desirable for fail-safe operation. 1

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

Page 1 of 1

Dynamic selection of configuration file, with failsafe operation

Where a system has a pluggable architecture, allowing the plugging in and removal of components (such as Nodes in a message flow system), the user interface (tooling) for the system needs to accurately reflect the set of components which are presently "plugged". One approach to this is to searching at startup of the interface, for which components are present and dynamically construct the displayable set. If the user interface relied purely on live data for the the dynamic creation of the set of components there would be a risk that the interface could not be constructed under certain circumstances, if for any reason the necessary data were not available or not accessible at startup. It is therefore sometimes desirable that a "default" configuration be assumed.

    Where a product assumes a default configuration, this may not always be appropriate for all possible types of installation. As an example, if such a product was shipped which did not include the nodes of type A, then on startup of the Control Center the workspace would (currently) display the nodes, even though they were not installed. The use of a single default is incompatible with the flexible installation of such a system by a solution install which may elect one of a number of possible combinations of functional content. It is therefore desirable to externalise the default workspace by providing it as a separate file. This, however, lead...