You can define default bindings at the cell-level or the application server level, and for one or multiple policy sets in a cell.
Policy set bindings contain platform specific information, like keystore, authentication information or persistent information, required by a policy set attachment. Each policy set attachment to a service provider or service client must have exactly one binding. When you create a policy set attachment, the default bindings are used initially. When default bindings are used in association with a policy set attachment, the cell-level default bindings are applied at runtime. If application server level bindings exist, the server-level default bindings override the cell-level definition. Default bindings specify configuration for both service client and service provider attachments and the default bindings are not tailored to a specific policy set or application. When you define server-level default bindings, the binding begins in a completely unconfigured state. You must add each policy, such as WS-Security or HTTP Transport, that you want to override the default binding and you must fully configure the bindings for each policy that you have added.
A custom binding is a named binding that you create. Custom bindings enable you to provide platform specific configuration information for specific policy set attachments. When you create a custom binding, the available binding configuration options are tailored to the definitions in the attached policy set. You can reuse custom bindings for multiple service resources within an application. When you create a custom binding for a policy set attachment, the binding begins in a completely unconfigured state. You must add each policy, such as WS-Security or HTTP Transport, that you want to override the default binding and you must fully configure the bindings for each policy that you have added.
In this information ...Subtopics
Related tasks
Managing policy sets using the administrative console | IBM Redbooks, demos, education, and more |