Hi, I am keen on adding further to the Policy support thats in Tuscany today. I recently run thro the Policy Framework specs and was looking into Tuscany on how far we had gone on this. Here's my understanding of all that. I request people's perspective on my understanding before I go ahead and implement things.
1. Policy intents and PolicySets are things that can be defined at the domain level. I propose we have Policy Registry or Repository that hosts the set of all intents and policy sets that pertain to a domain. 2. There can be a PolicyRegistryService that can provide interfaces to add, retrieve and remove intents and policies to the Policy Registry / Repository. 3. The set of intents and policy sets for a domain could be defined in the definitions.xml file which could be picked up by the ContributionsProcessor (see line 2490 of Assembly Model Spec). Infact there is more - such as the intents that are supported by binding and implementation types in the domain and so on. We could have a processor for the sca definitions that will read among other artifacts the policy intents and policy sets and add them to the registry. The model objects to represent policy intents and policy sets and the factory to create them are already in place under the policy module. 4. SCA artifacts will have intents and policy sets attached to them. Presently the artifact processors create the Intents and PolicySet objects. I propose that the artifact processor that read these SCA Artifacts will just about read the QNames and resolve them in the resolution phase with the help of the PolicyRegistryService. This way we can also check if the intent or policy set specified for an artifact is really applicable to the artifact or not. 5. Loading of PolicySet could get a bit deeper since there is extensibility that is allowed on the policy language that could be used. But I guess WS-Policy will need to be supported for by Tuscany as that is view to be a common thing that could be used So thats a summary the loading part. In the building phase there are algorithms that the Policy Framework Specs has specified to validate the wiring between components in the context of policies (including each end of the wire could inherit from ancestor artifacts and what is the binding or implementation type being used and what that supports inherently). Finally during runtime we have to make sure that the policy statements are handed out to the appropriate QoS infrastructures i.e Security or Transaction support modules so that they may be enforced. I am a bit unclear on the options related to this at the present moment. Before I get to a discussion on the wiring and runtime aspects related to policy I wish to know if my thoughts are in the right direction this far. Thanks - Venkat
