Policies

A policy is a capability or constraint of a service component that you can manage separately from an application's core business logic to affect runtime or deployment behavior, such as security, reliability, threading, and quality of service. You can specify a policy during development or at runtime.

For TIBCO ActiveMatrix, a policy includes the configuration that specifies the details that the TIBCO ActiveMatrix platform needs to enforce that policy. TIBCO ActiveMatrix Policy Director uses policies that are specified for runtime use. Other TIBCO ActiveMatrix policies are specified during design and may use intents.

Declaring policies at runtime yields several advantages over hard-coding policies into functional components:

Division of Effort - Separation of functionality and policy lets engineering teams focus on implementing functionality, while management, administrative and operations teams focus on formulating and implementing policy decisions.
Leverage - Declarative policies generalize frequently used solutions into conventions (called policy templates). You gain leverage by reusing them many times.
Concise Specification - A declarative policy combines a policy template with a small number of parameters, which adjust its behavior to a specific business situation.
Comprehension - Because declarative policies are concise and based on standardized conventions, they are easier to understand and to verify than procedural code. The declarative language of policies specifies the desired result, and the distribution engine delivers operational details of policies.
Flexibility - Declarative policies are easier to change than procedural code. Management decisions must respond quickly to changing business conditions. Declarative policies can change quickly to bring the enterprise into compliance. Instead of waiting for coding changes, the distribution engine immediately applies and enforces new or modified policies.

Consider these example uses of policy:

Authentication - Validate username and password credentials from request messages.
Authorization - Screen service request messages by checking that the requestor has valid credentials and appropriate access permissions for the request.
Encryption - Enforce encryption on all messages between two applications, encrypting messages as they exit one application, and decrypting them as they enter the other application.
Credential Mapping - Automatically attach appropriate credentials to request messages before they arrive at services.
Log Faults- When a request results in a fault message, log the details for later analysis by an administrator.