It looks like we're on the same page, I added some clarifications where
you had a question inline.
scabooz wrote:
Venkat,
comments embedded...
----- Original Message ----- From: "Jean-Sebastien Delfino"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, June 18, 2007 10:33 AM
Subject: Re: Policy Framework Impl. in Tuscany
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.
In addition, you could consider PolicySets packaged with a contribution,
such that it's not possible (a temporary restriction) to reference a
policySet from another contribution. Start simple.
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?
Right. A long term solution would include a seperation of policy from
contributions. The "policy registry" could even be separate from
the Domain as an entity, but a Domain will have a reference to a
policy registry.
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
I didn't quite follow this. Is this different from canonicalizing
intent and policySet attachments as described in the lengthy algorithm in
section 1.4.10 of the spec?
I was describing the general pattern currently used in Tuscany to
represent and resolve relationships between models. Our models need to
be able to represent relationships with objects that are resolved later
or in some cases never resolved at all.
Let's say you have two model classes:
AssemblyThing
Intent
Instead of having:
(a)
interface AssemblyThing {
QName getIntentName();
void setIntentName(QName qname);
}
interface Intent {
QName getName();
void setName(QName name);
}
or
(b)
interface AssemblyThing {
QName getIntentName();
void setIntentName(QName qname);
Intent getIntent();
void setIntent(Intent intent);
}
interface Intent {
QName getName();
void setName(QName name);
}
We're using the following pattern in our models:
(c)
interface AssemblyThing {
Intent getIntent();
void setIntent(Intent intent);
}
interface Intent {
QName getName();
void setName(QName name);
boolean isUnresolved();
void setUnresolved(boolean unresolved);
}
Pattern (a) doesn't look like a model at all. Pattern (b) is confusing.
So we're using pattern (c), which can use an instance of intent marked
unresolved to represent the relationship to a "proxy" Intent just
holding its name, then later change it to point to the actual intent
object after it's resolved. With pattern (c) models look like real
models with real relationships instead of beans with names and strings
or QNames all over the place shadowing model relationships.
That was my point. This doesn't replace, compete with, or get in the way
of the algorithm described in 1.4.10, it just helps model the
relationships between the various things that we need to model.
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.
+1
Thanks
- Venkat
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
