A subsystem can be considered as a server embedded within the main server. A subsystem can be started, stopped, and configured independently, and it has its own isolated Spring application context and configuration.
The application context is a child of the main context. This means that it can reference all the beans in the main application context. However, the subsystem beans cannot be seen by the main application context and communication with the subsystem must be through explicitly imported interfaces. The main features of subsystems are:
- Multiple ‘instances’ of the same type
- The same template spring configuration can be used with different parameters in different instances. For example, this allows you to chain, or combine functions of more than one subsystem, through property file edits.
- Dynamic existence
- The subsystem has JMX-based server configuration capabilities.
- Own bean namespace
- You do not need unique bean names if you use multiple instances of the same subsystem. This simplifies the problem of building an authentication chain as there is no need to edit a template Spring configuration.
- Clearly defined interfaces with the rest of the system
- The subsystem interfaces must be imported to be used anywhere else in the system. This is done by mounting them as dynamic proxies.
- Hidden implementation specifics
- Implementation specifics are not visible because beans are hidden in a private container.
- Swapping of alternative implementations
- To switch from native Alfresco Content Services authentication to Kerberos PAC Validation, you switch to a Kerberos authentication subsystem and the correct components are swapped in.
- Separate product from configuration
- A subsystem binds its configuration settings to properties. There is no need to edit or extend a prepackaged Spring configuration to configure a subsystem for your own needs.