...
Figure 1 depicts the Policy architecture.
*****
The function of Policy is to maintain, distribute and/or operate on the set of rules that underlie ECOMP’s control, orchestration, and management functions.
ECOMP 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<<Link X<<TODO: Link to PDP-X top page>> is based on XacML technology [1] and XACML technology and PDP-D<<Link D<<TODO: Link to PDP-D top page>> is based on Drools technology [2]. 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 , also, 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 this the initial release of ECOMP OpenECOMP Policy and will be turned on when testing is completed.
As illustrated in Figure 1, the Policy components are supported by a number of interfaces and subsystems. The ECOMP Portal <<Link to Policy User Guide top page>> 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.
The PAP provides interfaces and management of policy definitions. It utilizes the XACML DB database to store policy definitions, which are then distributed to the PDPs.
The XACML and Drools databases<<Link databases<<TODO: Link to database top page>> are hosted in a Maria DB clusterMariaDB cluster. The XACML DB database is used to persist policy definitions and provide a point for PDPs to retrieve policy definitions. The XACML DB database also has tables used for node state management<<Link management<<TODO: Link to state management top page>>, detection of node failure and failover<<Link failover <<TODO: Link to system integrity top page>>. As indicated above, the state management tables will only include entries for the PAP and PDP-X as the testing is not yet complete for the PDP-D.
The PDP-X receives deployed policies and has interfaces to handle XACML policy transactions<<Link transactions<<TODO: Link to XACML transaction interface top page>>. These transactions are stateless and once complete, they are removed from memory. If a policy that is deployed to the PDP-X is of an operational nature it will contain Drools rules and Java executables. These artifacts are processed into Maven artifacts and pushed to the Maven Repository<<Link to the Maven Repository top page>>. The PDP-D is then notified a new policy has been deployed.
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<<Link 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 , resulting in a change of internal session state and /or 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.
...