Configuration via Policy
Configuration via policy follows the same hierarchy as most Axis2 configuration. That leads to the following (from the top down):
- Module policy (in the module.xml file for Sandesha)
- Axis policy (in the axis2.xml file)
- Service Group policy (in the services.xml file)
- Service policy (in the service.xml file)
Policy at the operation level (or lower) will be ignored by Sandesha.
The following policy information is understood by Sandesha:
TODO - demonstrate the syntax.
Core Policy Options
- StorageManager class name.
The name of the class to use as the storage manager. Each storage manager class name will only be instanciated once, and once it is set up it is stored on the Axis ConfigurationContext. This allows policies which use the same StorageManager class name to share the same storage manager instance.
When the Storage Manager is needed the name is looked up using the Axis Service Context, and the lowest setting that is found will be used to retrieve the instance from the ConfigurationContext.
- SecurityManager class name.
The name of the class to use as the security manager. Each security manager class name will only be instanciated once, and once it is set up it is stored on the Axis ConfigurationContext. This allows policies which use the same StorageManager class name to share the same storage manager instance.
When the security manager is needed the name is looked up using the Axis Service Context, and the lowest setting that is found will be used to retrieve the instance from the ConfigurationContext.
- UseMakeConnection
- UseMakeConnectionAnonURI
- InOrder
- EnforceReliability
Timing Policy
The following options all affect the operation of the WS-RM protocol. As such, it is important to have a coherent set of these options, so they are all captured at Sequence creation time, and stored. All of the runtime decisions are made by referring to the Sequence, not the policy.
- DefaultExpiryDuration
- ExponentialBackoff
- AcknowledgementInterval
- MaxRetransmissionCount
- InactivityTimeout
- AcknowledgementRequestInterval
This interval controls how long the RMS will wait for an acknowledgment before requesting one from the RMD. In practice, this is equivalent to a RetransmissionInterval, and we may support both names for a while.
Configuration via API properties
In addition to the configuration that can be done using policy, there are a collection of API properties that can be used to affect individual messages.