In essence, native/raw policy is custom policy type implementation which can be native policy rules (e.g. drools rules, xacml rules or apex rules) with or without configurable property values. If a set of native policy rules does not contain any configurable property, it becomes policy implementation which is directly executable in PDP engines. If it contains one or more configurable properties (e.g. marked as ${xxx}), it becomes a rule template. Its corresponding policy type defines those configurable properties and their values can be provided by particular TOSCA policy created off this policy type. In this scenario, executable policy implementation will be generated by combining TOSCA policy and this corresponding policy type implementation. The relationship among policy type, policy type implementation, TOSCA policy and policy implementation can be illustrated as below:
Taking drools rules as one example, current usecases.drl used in PDP-D is a default policy type implementation for operational policy. It is both a policy type implementation and policy implementation since it is a set of rules without any configurable property values to be populated and it can be directly run in PDP-D. However, some policy authors might prefer to compose their own drools rules in a different way even if they aim to implement the same or different use cases. Current policy framework does not provide an interface for such policy authors to bring in their own native rules. Hence, we need to come up with a solution in Frankfurt to bridge the gap.
Regarding this solution, I have two design options in my mind which will be explained in the following. In both options, we want to use PAP to deploy such native policies to appropriate PDP engines. Given drools rules will import some java classes and use them in action part to perform particular operations as well as in condition part to indicate the java models for I/O message events, we want to separate java class implementation and rule authoring. Java classes being used in drl rules need to be implemented separately and packaged into JARs which are deployed to internal nexus repo before implementing/deploying native policies.
Option 1: Everything being provided through policy design API (i.e. drl rules, java dependencies, drools controller configuration)
In this design option, native policy author needs to provide all necessaries in the payload of POST custom policy type impl call. The payload will use application/json or application/yaml as content-type. All the necessaries include native policy rules with or without configurable properties (e.g. drl with ${xxx}), java dependency descriptors (i.e. groupId, artifactId, version) and other configuration required by corresponding PDP engine to load/execute these new rules (e.g. drools controller configuration which includes controller-name, dmaap server, dmaap topics, java classes for serialization/deserialization, filter, custom serializer, etc.).
endpoint,
payload schema,
flow explanation, role of PAP and PDP-D,
sequence diagram
Option 2: Native policy rules being provided through policy design API whereas peripheral configuration (i.e. java dependencies, drools controller configuration) being provided through PAP policy deployment API
xxx