...
Figure 1 depicts the Policy architecture.
...
Figure 1. Policy high-level architecture
System Architecture
OpenECOMP Policy is composed of several subcomponents: the Policy Administration Point (PAP)<<Link to PAP top page>>, which offers interfaces for policy creation, and two types of Policy Decision Point (PDP), each based on a specific rules technology. PDP-X<<TODO: Link to PDP-X top page>> is based on XACML technology and PDP-D<<TODO: Link to PDP-D top page>> is based on Drools technology. PDP-X is stateless and can be implemented using a resource pool of PDP-X servers. The number of servers can be grown to increase both capacity (horizontal scalability) and to increase availability. The PDP-D is stateful, as it utilizes Drools in its native, stateful way and transactions persist so long as the PDP-D is active. Persistent Drools sessions, state management, local and geo-redundancy have been deactivated for the initial release of OpenECOMP Policy and will be turned on when testing is completed.
As illustrated in Figure 12, the Policy components are supported by a number of interfaces and subsystems. The OpenECOMP Portal provides a human interface for the creation, management and deployment of policies. It is a web-based system that utilizes internal APIs in the PAP.
Figure 2. Policy subsystem system architecture
The PAP provides interfaces and management of policy definitions. It utilizes the XACML database to store policy definitions, which are then distributed to the PDPs.
...
When the PDP-D is notified a new policy has been deployed, it downloads it from the Maven repository and assigns it to an internal controller. This controller provides the external Closed Loop<<TODO: Link to Closed Loop transactions top page>> interfaces to the UEB/DMaaP message bus over which events and messages are exchanged with external systems. As events or messages arrive at the PDP-D, they are assigned to the appropriate controller and a Drools session is either created or retrieved from memory. The events, messages or facts are passed to the Drools session and the rule engine is fired, resulting in a change of internal session state and possibly actions taken in response to the rule processing. Response messages and requests are passed by the controller back over the UEB/DMaaP message bus to the appropriate system. The Drools session can also have timers and autonomous events. In a future release the PDP-D will enable the node state management and session persistence in the Drools DB. *************
Policy Creation
The Policy Creation component of the Policy subsystem enables creation of new policies and modification of existing polices, both online and offline.
...