Hi Sebastien,
First thanks to you and Dave for responding to my queries.
I always had this one point troubling my mind with this. Its about creating
those various proxy objects and abandoning them once they are resolved to
the original one. Since we do this right across our model I wonder if it
would do hurt to have so many objects dereferenced this way or am I
imagining too much and that this is actually quite affordable.
Thanks
- Venkat
On 6/21/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
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: <tuscany-dev@ws.apache.org>
> 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]
