...
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.).
...
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
...