In an effort to make SST useful in a broad range of situations with a minimum of end-user modification, SST has been made highly configurable. This capability is embodied in configuration objects which manage a collection of options. These options go together to define the desired behavior of some related object. Most of the major SST components (such as spaces, invocation handlers) have corresponding specialized configuration objects. It is assumed that for each option there are corresponding accessor methods for getting and setting the value. Configurations conform to the IuSstConfiguration interface.

While the use of configurations provides great flexibility, they can also overwhelm you with innumerable options and combinations only some of which are relevant. The SstExamples application, particularly the ping-pong examples, contain a number of example configurations for various common interaction situations. Once you capture the desired behavior in a configuration, you can use the configuration as a template for instantiating the corresponding SST component.

Transport and invocation configurations can be managed by the system. Configurations developed by programmers are registered with the configuration managers using the transport identifier or invocation scheme. These configurations are then specified using URLs and automatically looked up and used when building communications and method invocation components based on these URLs.

In addition to this management, components such as marshalers or dispatchers offer class methods which return configurations describing well-known behavior. For example, byReferenceConfiguration on some message marshalers.