Environments

An Environment is a logical grouping of Applications and Nodes. An Administrator server can have multiple Environments. For example, you can define Environments distinguished by product life cycle function such as development and production, by geographical area, or by business unit.

Environments provide a way to isolate one group of Applications and Nodes from another. This is useful for security, optimizing network traffic (each Environment has its own Enterprise Message Service server for service bus communication) and visual organization in the ActiveMatrix Administrator UI. Hosts can also be isolated and associated with one or more Environments.

Environments contain the following types of objects:

  • Applications The Services and References defined by an Application can be promoted to the Application's Environment. Services and References promoted to the Environment level can be wired to each other. The following figure illustrates a Service and Reference exposed by a component, promoted to the composite level, promoted again to the Environment level, and wired between the promoted Reference and Service.
    Cross Environment Wires


  • Nodes Nodes are runtime sandboxes that run application logic. Node names must be unique within an Environment and within a Host.
  • Messaging Bus configuration

Administrator Environment

The Environment containing the Node on which the ActiveMatrix Administrator server runs, SystemNode, is named SystemEnvironment. In a high-availability enterprise, the SystemEnvironment contains the SystemNodeReplica as well.

Note: SystemEnvironment is solely for ActiveMatrix platform Applications. Do not deploy any user application to SystemEnvironment.

Development Environment

When you create an ActiveMatrix Administrator server you have the option to create a development Environment and Node. By default, the Environment is named DevEnvironment and the node is named DevNode.