Pattern - Automatic Configuration

In Automatic Configuration, the application determines the state of the world (somehow) and sets itself up automatically. This could be done at install time, startup time, or dynamically. The latter is best, as it adapts to a changing world.

Features

• Application queries the host and network for the state of the environment in which the program is running.
• Application uses this information to control its own behaviour
• The Application may poll for changes (or register for state changes), and reconfigure itself as the environment around it changes.

A classic example of this is programs that adapt to network settings. Computers themselves use DHCP and DNS to dynamically find their assigned network information, and to locate other machines on the network. Http proxy configuration scripts enable web browsers and other programs to choose proxy settings based on the perceived state of the network.

Advantages

• No need for configuration options, dialogs, or the documentation to go with them.
• Eliminates errors due to incorrect information being manually entered.

Disadvantages

• Needs 100% accuracy. If the configuration is misinterpreted then the application will not work. In the absence of any way to manually control the settings, a broken automatically configured application is unusable.
• If you offer a manual configuration backup, you have increased your costs -you need to maintain the automatic and the manual options.
• Can be hard to test. You need to emulate the different environments and verify that the application adapts.
• Failure modes/testing can be harmful in its own right. For example, Skype generates large amounts of network traffic trying to get through firewalls.
• Not all programming platforms offer full access to system state.

Java is surprisingly limited in its ability to determine the state of the local machine. There are no API calls to discover a computer's battery/power source status; no APIs to determine if a program is running on a LAN or over a WiFi link, and if so, what the name of that WiFi link is. Without such information, it is impossible to write applications that work well on laptops. This runs through the system; DNS addresses get cached for the life of a process unless declared otherwise; Java RMI does not like to be running on a machine whose networks come and go, and whose IP addresses change in the process.

SmartFrog support

1. We are very limited by what the Java API itself offers SmartFrog in terms of network awareness.
2. Deployment descriptors use system properties (PROPERTY and environment variables ENV to build a configuration from the local system. If you use LAZY values, those of remote system will be used, and not the local client.
3. In default.ini we deliberately do not enable automatic proxy configuration, as it has been found to be unreliable, at least on Java 5 systems.