Fabric3 support for SCA Policy uses a powerful interceptor-based infrastructure that can be used in a range of scenarios:

• Policies can enforce a number of behaviors such as transactions, security, or SLA alerts.

• Policies can be explicitly configured on components and remote communications

• Policies can be enforced on a domain level and "attached" to components and remote communications at deployment

• Policies can be dynamically enforced on a domain level and attached to existing components and remote communications

Writing Policy Extensions

Fabric3 support standard policies such as transactions and also provides a way to write custom policies. These custom policies may be bundled directly with user code (e.g. if it is only applicable to a service or set of services) or as a separate contribution.

Defining and Applying Policies

Policies are defined in an SCA definitions file. A definitions file can contain intents, policy sets, binding types, and implementation types. The specifics of SCA policy are beyond the scope of this reference. Briefly, though, intents are abstract requirements that can be declared by a component or on a reference or service. Intents are matched to policy sets, which provide concrete configuration for a behavior. For example, a the "message authentication" intent may be mapped to a policy set that specifies WS-Security. Intents are therefore a way to specify a requirement without tying a component to a specific underlying technology. In an environment that does not use WS-Security, the "message authentication" intent would be mapped to a different security technology.
Policy set configuration in Fabric3 varies by binding. For example, defining a policy set for use with the Web Services binding is done using Axis2's XML configuration dialect or WS-Policy if Metro is used.
Fabric3 also provides a general mechanism for defining policy sets that can be used across bindings and wires. This involves writing an interceptor that will be called to process a message invocation. The following XML definitions file demonstrates how to define an interceptor policy:
<?xml version="1.0" encoding="ASCII"?>
<definitions
xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200903"
xmlns:f3="urn:fabric3.org">
<policySet name="testImplementationPolicy"
f3:phase="INTERCEPTION"
attachTo="//component">
<f3:interceptor
class="org.fabric3.interceptor.TestInterceptor"/>
</policySet>
</definitions>
The "attachTo" attrbitute instructs Fabric3 to apply the interceptor to all components in the domain (note you would probably not want to do this in a real-world application). This is termed "SCA external policy attachment". Again, the details of these SCA mechanisms are beyond the scope of this reference. Briefly, though, the value of the attachTo attribute is an XPath expression that is applied to the domain infoset. This is an extremely powerful capability. Policies can be dynamically attached to any component, binding, or wire in the domain by specifying an XPath expression. This attachment can happen at deployment or be applied to already deployed components, bindings, and wires.
Note that in addition to external attachment, Fabric3 also supports a "pull" policy model where policies (or intents) are specified in the component configuration or via annotations.
The interceptor class for the previous policy set is shown below:
package org.fabric3.interceptor;
import org.fabric3.spi.invocation.Message;
import org.fabric3.spi.wire.Interceptor;
public class TestInterceptor implements Interceptor {
private Interceptor next;
public Message invoke(Message message) {
// perform some processing.
return next.invoke(message);
}
public void setNext(Interceptor interceptor) {
next = interceptor;
}
public Interceptor getNext() {
return next;
}
}
Note the interceptor class implements org.fabric3.spi.wire.Interceptor.

Including Policies in a Contribution

Policies (e.g. the definitions.xml file and supporting classes such as an interceptor) can be packaged and deployed as part of a contribution. This is useful if the policy only applies to a particular set of services. The only required step to do this is to ensure the contribution manifest (sca-contribution.xml) contains an import.java entry for the org.fabric3.spi package:
<contribution xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200903" xmlns:f3="urn:fabric3.org" f3:extension="true">
<import.java package="org.fabric3.spi.*"/>
</contribution>

Packaging Policies Separately

Policies can also be packaged and deployed as individual contributions. Again, the only specific requirement is that the contribution manifest import the org.fabric3.spi package. One important difference, however, with this approach is that the interceptor class will be loaded in a different classloader than the source and targets of a wire. In most cases, this will not matter as the component classloaders will not be needed. In cases where the source and target classloaders must be accessed, the policy contribution must use the lower level Fabric3 interceptor builder SPI.

Creating Custom Intent and PolicySet Annotations

TBD

The Interceptor Builder SPI

TBD