Page History

...

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

Policy type, type implementation and policy creation

Policy type, policy type implementation and policy are organized as hierarchical resources in RESTful path. Policy type implementation payload should include which policy type this implementation is associated with. Likewise, policy payload should include which policy type and which type implementation this policy is created off. If policy type implementation is not present in endpoint path, it means to use default type implementation for associated policy type. Basically, the RESTful resource hierarchy can be expressed as

...

Note that the preceding policy type implementation list contains two elements. One is for sample use case1 rules whereas the other is for sample use case2 rules. Here, sample use case 1 and 2 are two example use cases which use drools rules for decision making. Let's assume sample use case1 rules do not have configurable properties while sample use case 2 rules contain configurable properties (e.g. ${ClosedLoopControlName}), which justifies that in the corresponding policies created off, we can see "properties: null" for use case 1 and "properties: ClosedLoopControlName: xxx" for use case 2 as shown above.

Policy deployment

With policy type, type implementation and policy are all stored in policy DB. As a follow-up after POST policy type impl and policy API calls, native created, next step is that policy author needs to call PAP deploy this policy to make it run in appropriate PDP. Deploying this policy is as easy as calling policy deployment API exposed by PAP. In this design option, the payload of deployment API will include only policy ID and version (the same as current). If version is not present, the latest version will be used. Content-type would be either application/json or application/yaml. For example,

Content-type: application/json

{
  "policies" : [
    {
      "policy-id": "operational.sampleusecase1",
      "policy-version": 1
    },
    {
      "policy-id": "operational.sampleusecase2"
    }
  ]
}

Flow explanation

Policy type, type implementation and policy are all stored in policy DB. As a follow-up after POST policy type impl and policy API calls, native policy author needs to call PAP policy deployment API to deploy native policies to PDP engine (e. deployment API to deploy native policies to PDP engine (e.g. drools). PAP will pull the policy and corresponding type implementation from DB then send them to appropriate PDP engine. Taking drools as one example, after PDP-D receives native policy and its type implementation from PAP, it will first pull necessary dependency artifact JARs from internal nexus based on what specified in "properties.dependencies" then copy them to local m2 repo. Next, PDP-D will package native rules into a new JAR and copy to local m2 as well. At last, PDP-D will instantiate a new drools controller instance based on what provided in "properties.controller" then invoke telemetry API to spin up the new drools controller. 

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

In this design option, only native policy rules are being provided in POST policy type implementation payload via custom content-type (e.g. application/drl, application/xacml, application/apex). Other dependencies and configuration are being provided in PAP policy deployment API call. The basic idea of this design option is, in policy design phrase, native policy author just needs to focus on composing native policy rules to realize predefined decision making logic, without worrying about how to setup/configure peripheral stuffs like dmaap server/topics and new drools controller instance. After finishing up policy rule handcrafting and later in policy deployment phrase, policy author can start considering about how to setup/configure other things to make sure native rules can be running correctly in appropriate PDP engine. It implies that when PAP policy deployment API is invoked, necessary configurations required by PDP engine to correctly execute native rules need to be provided in the payload of this policy deployment POST call. Along with native policy and its type implementation, they will all be sent to PDP engine for execution.

Policy type, type implementation and policy creation

Endpoint paths will remain the same in this option except that content-type will be customized to PDP engine specific one.

...

Policy payload will remain the same as that in option 1. 

Policy deployment

xxx

Flow explanation

TBA

Sequence diagram