Page History

...

Summary of issues with the current arrangement

• Better separation of policy model from assembly model
  • implementation policy sets held by component due to reuse of implementation model objects
  • OASIS are talking about moving to an external attachment model so we need flexibility to follow that move if necessary
• "Applies to" happens right at the start of contribution and is not subject to later builder processing
• Consistency of model style between assembly and policy models
• Separate any policy processing from policy model
• Consistency of policy extension model
• definitions.xml processing should be domain wide and not restricted to a single contribution

Idealistic policy model

The make sure I understand the model I reproduced my version of it from the existing spec resources. It's slightly different from what we have at present as the code model is somewhat optimized but I want to use this as my baseline for reviewing what we have in the implementations

Image Added

Image AddedImage Removed

Policy model reading follows the assembly model in having read and resolve phases. The read phase will create dummy objects with "unresolved = true" set to represent any unresolved references. These dummy objects are replaced with the real thing at the resolve stage.

...

The assembly model starts life with manually configured intents and policy sets on individual assembly elements. The result of applying the intent and policySet inheritance rules and the intent and policySet matching rules leads to a final set of relationships between assembly artifacts and policySets. I started to draw these externalized from the assembly model but expect that they will resolve to placing the correct policySet QNames on appropriate assembly artifacts. These relationships drive the configuration of each binding and implementation and with wires in between.

Image RemovedImage Added

Policy touch points

...