deployment configuration and control

Table of Contents:

• deployment definition
• configuration at startup
• runtime configuration changes

deployment definition:

An application is a project defined off the apps subdirectory of SAND_HOME. Applications are platform and technology neutral implementations of business logic, typically implemented using only standard Java.

A deployment is a project defined off the deploy subdirectory of SAND_HOME. A deployment typically requires one or more applications, which provide the message and node definitions to be instantiated as a working system.

The node instances (and other parameters necessary for deployment) are defined in the Configuration, which is saved to config.xml in the project env directory. The configuration is usually managed as source code, and accessed via the config editor (provided by the SAND environment). For access to the config editor, refer to the documentation for the deployment project.

TOC

configuration at startup:

At startup, the SandRoot on each server loads the node instances configured to run on it, according to the parameters specified in config.xml. Exactly how this occurs depends on the platform and supporting technology, but it is the responsibility of the SAND environment to ensure the deployment configuration is properly loaded.

While the SAND environment (eg sandev) is responsible for loading the configuration, each node is individually responsible for verifying its own environment and reacting appropriately. So while a node can assume that its configuration data members will set as configured (and that things like messaging and logging work) it cannot assume anything with respect to other nodes. Node instances are expected to stabilize themselves via communication and robust error recovery.

Once a configuration is loaded, changes to config.xml are typically ignored. Structs And Nodes Development is generally used for applications with stable deployments, where configuration changes undergo the same test/release process as source code changes. Runtime changes are instead handled through the control panel, provided by the SAND environment. For access to the control panel, refer to the documentation for the deployment project.

TOC

runtime configuration changes:

In a multi-server environment, it is possible to dynamically change the overall deployment configuration at runtime using temporary servers and carefully managing configuration changes. This process is actually helped by the fact that changes to config.xml are ignored until the server restarts, however some applications may still need to change their system configurations dynamically without server restart.

To implement runtime configuration updates:

1. Write an updateConfiguration method in the platform SandRoot implementing class which will shutdown the config and load the new. Expose this method in the SandRoot interface.
2. Create a ConfigManagerNode which can receive a ConfigurationUpdate, negotiate (eg 2 phase commit) with other ConfigManagers, and call the SandRoot updateConfiguration method.
3. Modify the deployment configuration to include one ConfigManager node instance on each server
4. Modify the config editor to send a ConfigurationUpdate to the ConfigManagerNode on save.

TOC