webapp directories
What must be installed on a deployment machine?
To make a machine part of a deployment, it must have the following software installed (and running if necessary):
Depending on the runtime environment, and which nodes are running, additional software may also need to be installed:
Simple configuration management:
A configuration is a canonical structure of message instances describing
initial application data, application hosts, and node parameters. It is
saved in XML format as config.xml in the env
directory of a deployment project.
In the simplest possible scenario,
Any changes made post-deployment are ignored, unless the original
config.xml is updated, and the deployment build process repeated.
Change tracking configuration management:
To track changes to a configuration, the configuration updates (sourced
from the control interface, or other editing interface) are sent to a local
ConfigManager node, which broadcasts the updates to all ConfigManager nodes
on the hosts. Each ConfigManager updates the local config.xml file, so
changes persist and can be tracked.
Simultaneous updates are prevented through a "master" designation that
must be obtained synchronously by the local ConfigManager instance as a
prerequisite to accepting updates for broadcast. See the node for more
information.
By monitoring the statistics produced by the nodes, and applying
threshold rules, an automation node can produce configuration updates
within specified parameters in response to local host processing
conditions. For example when hosting a DataManager instance, and other
node instances, an automated configuration management node may choose to
move other node instances off the machine in response to heavier
DataManager traffic, or decreased throughput.
Other environments may provide load balancing through the declaration
of virtual hosts, which are in fact load distributing clusters.
Development typically utilizes a variation of
simple configuration management where the
development machine and the server host are the same. Presuming the
computer has been set up with all the required software for both, a
typical developer would simply change to the appropriate deployment
build area (for example c:\sand\deploy\TaskHeapDemo) and
run ant. Container deployment happens automatically.
As part of the build process, docs/index.html is updated
with a link to the web-based configuration editor. After modifying the
configuration, the build process is repeated for the changes to take
effect. If the changes are permanent, the updated
env/config.xml can be checked into the code version tracking
system.
How a config editor will be made available to a SAND environment user
will vary depending on the environment they are using. In the case of
SANDev, we have a straightforward webapp that is made part of every
deployment. The webapp is implemented through a webapp directory, which is
be packaged into a .war file for each deployment.
However it's important to note that webapps are specific to the SANDev
environment (or at least J2EE-based SAND environments). The same thing
would probably *not* make sense for a .NET environment, or a PDA
environment, or a flash/swing environment etc.
If you want to define a webapp directory as part of your deployment,
then that is automatically supported by the same build processes that
support creation of the config editor. However it's important to note that
this aspect of the overall system is not part of SAND, but rather part of
the SANDev network application compiler. A webapp is not supported
across every potential application environment.
SAND works at the level of information transfer between the UI and the
application deployment. This transfer is done through an adaptor node,
which is subject to change as the adapted technology changes. If part of
an application deployment uses code specific to the adapted technology,
that code is outside of the scope of SAND and is not insulated from
technology changes. This is appropriate for UI specific code, but not for
business logic related to the application.
The webapp directory is specified at the same level as the build, docs
and src directories. It follows the structure of the resulting .war file.