Templates Support

The Cougaar template property controls the standard set of infrastructure components that are loaded into the nodes and agents.

For example, setting the template to embedded tells the infrastructure to load a local-only (trivial) message transport and naming service. If the template is set to lan then the distributed message transport and naming service are loaded.

The System Property is:

    -Dorg.cougaar.society.xsl.param.template=$value

The supported values are:

    *embedded*      = loopback mts/wp, no servlets,
                    designed for applets and other embedded environments.

    *single_node*   = loopback mts/wp, no metrics,
                    adds standard plugins and servlets (e.g. "/tasks" servlet)

    *single_debug*  = full mts, loopback wp, full metrics and aspects

    *legacy*        = default backwards-compatible with prior Cougaar releases.
                    distributed mts/wp, adds planning and communities.

    *lan*           = distributed mts/wp, added metrics aspects,
                    adds standard plugins and servlets (e.g. "/wp" servlet)
                    adds servlet tunneling through mts (but will favor http-redirect)

    *wan*           = currently same as lan.
                    eventually we'll add mts sequence checking here, etc.

It is defined in:

    configs/common/SimpleAgent.xsl

This parameter simply enables/disables other parameters, and can be overwritten in the society XML file. For example, an ‘embedded’ configuration can add servlets by setting:

    -Dorg.cougaar.society.xsl.param.servlets=true

Matrix of enabled/disabled features

PARAMETER template value
embedded single_node single_debug legacy lan wan
threadService trivial full full full full full
pluginThreadPool note N/A 30 30 30 30 30
mts singlenode singlenode full full full full
wpserver singlenode singlenode singlenode true note full full
socketFactory required by full wp and mts false false true true true true
metrics trivial trivial full full full full
standard_aspects false false true false true true
sensors e.g. agent load false false true false true true
mobility false false false false true true
servlets engine false true true true true true
standard_node_servlets e.g. “/wp” false true true false true true
standard_agent_servlets e.g. “/tasks” false true true false true true
servlet_engine.tomcat false true true true true true
servlet_engine.micro false false false false false false
servlet_engine.mts false false false false true true
servlet_redirector.http_redirect false true true true true true
servlet_redirector.http_tunnel false false false false false false
servlet_redirector.mts_tunnel false false false false true true
communities false false false legacy note false true
assume planning domain should be loaded false false false true note false false
read domain_ini file false false false true note false false
link_protocol.loopback default default true note default default default
link_protocol.rmi default default default default default default
link_protocol.jms default default default default default default

Notes

The full threadService supports a plugin thread limit. The trivial thread service implementation has no limit. 
The wpserver supports a default “true” value, which tells the node to load the WPServer component into every node. This is for backwards compatibility. 
The communities option supports a default “false” value, a “legacy” value for the old lib/community.jar implementation, and a “true” value for the new core implementation in org/cougaar/core/agent/service/community. 
For backwards compatibility, the legacy configuration loads the planning domain. The preferred approach is to explicitly list domains in each agent, just like plugins. 
Similar to the above planning issue, the legacy configuration reads a “LDMDomains.ini” domain configuration file. 
By default, the RMI and Loopback link protocols are loaded. In the ‘single_debug’ configuration we only want loopback.