WAS v8.5 > Reference > Commands (wsadmin scripting)WSReliableMessaging policy and binding properties
Use the attributes parameter for the setPolicyType and setBinding commands to specify additional configuration information for the ReliableMessaging policy and policy set binding. The WSReliableMessaging quality of service (QoS) is only available for application policy sets.
WSReliableMessaging is an interoperability standard for the reliable transmission of messages between two endpoints. Use WSReliableMessaging to secure and verify transactions when using web services between businesses.
Use the following commands and parameters in the PolicySetManagement group of AdminTask to customize your policy set configuration.
- Use the -attributes parameter for the getPolicyType and getBinding commands to view the properties for the policy and binding configuration. To get an attribute, pass the property name to the getPolicyType or getBinding command.
- Use the -attributes parameter for the setPolicyType and setBinding commands to add, update, or remove properties from your policy and binding configurations. To add or update an attribute, specify the property name and value. The setPolicyType and setBinding commands update the value if the attribute exists, or adds the attribute and value if the attribute does not exist. To remove an attribute, specify the value as an empty string (""). The -attributes parameter accepts a properties object.
If a property name or value supplied with the -attributes parameter is not valid, then the setPolicyType and setBinding commands fail with an exception. The property not valid is logged as an error or warning in the SystemOut.log file. However, the command exception might not contain the detailed information for the property that caused the exception. When the setPolicyType and setBinding commands fail, examine the SystemOut.log file for any error and warning messages that indicate the input for the -attributes parameter contains one or multiple properties that are not valid.
IBM recommends using the HPEL log and trace infrastructure. With HPEL, one views logs using the LogViewer command-line tool in PROFILE/bin.
For transitioning users: In WAS v7.0 and later, the security model was enhanced to a domain-centric security model instead of a server-based security model. The configuration of the default global security (cell) level and default server level bindings has also changed in this version of the product. In the WAS v6.1 Feature Pack for Web Services, we can configure one set of default bindings for the cell and optionally configure one set of default bindings for each server. In v7.0 and later, we can configure one or more general service provider bindings and one or more general service client bindings. After we have configured general bindings, we can specify which of these bindings is the global default binding. We can also optionally specify general binding used as the default for an application server or a security domain. trns
To support a mixed-cell environment, WAS supports v7.0 and v6.1 bindings. General cell-level bindings are specific to v7.0 and later Application-specific bindings remain at the version the application requires. When the user creates an application-specific binding, the application server determines the required binding version to use for application.
WSReliableMessaging policy properties
Configure the WSReliableMessaging policy by specifying the following properties with the setPolicyType command:
- specLevel
- Choose the WS-ReliableMessaging standard to use for reliable transmission of your messages. The WS-ReliableMessaging specification v1.1 is the default value. Use the following information to choose a specification level:
- Specify 1.0 as the value for the specLevel attribute to use the WS-ReliableMessaging specification v1.0, February 2005 specification level.
- Specify 1.1 as the value for the specLevel attribute to use the OASIS WS-ReliableMessaging specification v1.1, August 2006 specification level.
The following example code sets the specLevel property to the OASIS WS-ReliableMessaging specification v1.1, August 2006:
AdminTask.setPolicyType('[-policySet "CustomWSReliableMessaging" -policyType WSReliableMessaging -attributes "[[specLevel 1.1]]"]')- inOrderDelivery
- Whether to process messages in the order they are received. If we use the inOrderDelivery property, then inbound messages might be queued while waiting for earlier messages.
The following example code enables the inOrderDelivery property:
AdminTask.setPolicyType('[-policySet "CustomWSReliableMessaging" -policyType WSReliableMessaging -attributes "[[inOrderDelivery true]]"]')
- qualityOfService
Specifies the quality of the WSReliableMessaging service to use. Define one of the following three values for the qualityOfService attribute:
- unmanagedNonPersistent
This setting tolerates network and remote system failures. The unmanagedNonPersistent quality of service is non-transactional. With this setting configured, messages are lost if a server fails. This quality of service is supported for all environments only if the environment is configured as a web service requester.
- managedNonPersistent
This setting tolerates system, network, and remote system failures. However, the message state is discarded when the messaging engine restarts. The managedNonPersistent quality of service is non-transactional. This setting prevents message loss if a server fails. However, messages are lost if the messaging engine fails. Managed and thin client applications cannot use this quality of service.
- managedPersistent
This setting tolerates system, network, and remote system failures. With this setting, messages are processed within transactions, persisted at the web service requester and provider. Messages can be recovered if a server fails. Messages that are not successfully transmitted at the time of failure continue when the messaging engine or application restarts. Managed and thin client applications cannot use this quality of service.
The following example sets the qualityOfService property as unmanaged nonpersistent:
AdminTask.setPolicyType('[-policySet "CustomWSReliableMessaging" -policyType WSReliableMessaging -attributes "[[qualityOfService unmanagedNonPersistent]]"]')The following example uses the setPolicyType command to set a value for each policy property:
AdminTask.setPolicyType('[-policySet "CustomWSReliableMessaging" -policyType WSReliableMessaging -attributes "[[specLevel 1.1][inOrderDelivery true][qualityOfService unmanagedNonPersistent]]"]')
WSReliableMessaging binding configuration attributes
If you set the qualityOfService policy property to managedNonPersistent or managedPersistent, configure the WSReliableMessaging binding by specifying values for the following properties with the setBinding command:
- busName
- The name of the service integration bus containing the messaging engine to use for the managedNonPersistent or managedPersistent Quality of Service options.
The following example sets the busName property as myBus:
AdminTask.setBinding('[-bindingLocation "" -bindingName cellWideBinding2 -policyType WSReliableMessaging -attributes "[[busName myBus]]"]')- messagingEngineName
- The name of the messaging engine to use for the managedNonPersistent or managedPersistent quality of service options.
The following example sets the messagingEngineName property as messagingEngine001:
AdminTask.setBinding('[-bindingLocation "" -bindingName cellWideBinding2 -policyType WSReliableMessaging -attributes "[[messageEngineName messageEngine001]]"]')The following code example demonstrates how to use the setBinding command to set values for each binding attribute:
AdminTask.setBinding('[-bindingLocation "" -bindingName cellWideBinding2 -policyType WSReliableMessaging -attributes "[[busName myBus][messageEngineName messageEngine001]]"]')
Related concepts:
WS-ReliableMessaging default policy sets
Related
Configure application and system policy sets for web services using wsadmin.sh
WS-ReliableMessaging
Troubleshoot applications with HPEL
Reference:
PolicySetManagement command group for AdminTask
Related information:
The WS-ReliableMessaging specification v1.0, February 2005
The OASIS WS-ReliableMessaging specification v1.1, August 2006.