Venkata Krishnan wrote:
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.
+1 but I think we could start with something simpler than a repository,
simply a model for definitions.xml, and a reader for this file.
2. There can be a PolicyRegistryService that can provide interfaces to
add,
retrieve and remove intents and policies to the Policy Registry /
Repository.
+1
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.
Policy administration is independent of SCA contributions. How about a
new policy-xml module for the code that will read definitions.xml,
independent of the ContributionProcessor?
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.
Intents need to be resolved to point to the intents defined in
definitions.xml in ArtifactProcessor.resolve(). I'd suggest to adopt to
the same approach as for all other objects that need to be resolved:
1. read creates an Intent / PolicySet with unresolved = true
2. resolve replaces it with the resolved Intent / PolicySet
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.
Yes, this sounds good to me. I'd suggest to start small with:
- reading of definitions.xml
- completing the Policy Intent and PolicySet models
- starting with a a real Policy implementation, like Security, to help
drive the design and implementation with a concrete use case.
Thanks
- Venkat
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
