You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Raymond Feng <en...@gmail.com> on 2009/02/23 20:28:04 UTC
[2.x] Update on the OASIS OpenCSA SCA policy framework
Hi,
I have started to implement the OASIS OpenCSA SCA policy framework. The
first set of the changes were checked in under r746356 [1]. It contains the
model interfaces/implementations as well as the processors that load the
policy related configuration from composite and definitions files. The UML
model is available at [2]. I also added a diagram to show the relationship
between the policy and assembly [3]. Feedbacks are welcome.
For next steps, I'm looking into the following directions:
a. Build the definitions from the built-in intents/policies as well as the
META-INF/definitions.xml from SCA contributions. The list of definitions
become the definitions of Intents, PolicySets and ExtensionTypes in the SCA
domain.
b. Build the policy configuration for the endpoints (service binding)
/endpoint-references (reference binding) /implementations following the
inheritances from the implementation and structure hierarchies. The result
will be a list of PolicySubjects which represent the SCA
endpoints/endpoint-references/implementations.
c. Attach the policySets to the SCA domain composite using the @attachTo
XPath and resolve to a list of
endpoints/endpoint-references/implementations. The result will be
consolidated with the result from b to become the effective policies for a
given policy subject.
Please note step b & c is based on some of the thoughts on the endpoint
side. At this moment, the current code try to patch/update the assembly
models to resolve the configurations by implementation or structure
inheritances. It leads to messy models and complex logic in the builders.
Having a separate endpoint to group a set of assembly objects (such as
[composite, component, service, binding] for a service endpoint and it will
be used to hold the calculated configurations such as the interface,
policySets and intents).
After that, we will revisit the PolicyProvider SPIs to allow policy handlers
to be added to the SCA invocation chains or
endpoint/endpoint-reference/implementation to enforce the policies.
[1] http://svn.apache.org/viewvc?rev=746356&view=rev
[2]
http://cwiki.apache.org/confluence/download/attachments/85246/policy-uml-model.jpg
[3]
http://cwiki.apache.org/confluence/download/attachments/85246/policy-assembly.jpg
Thanks,
Raymond
Re: [2.x] Update on the OASIS OpenCSA SCA policy framework
Posted by Raymond Feng <en...@gmail.com>.
A quick update for the class diagram: http://cwiki.apache.org/confluence/download/attachments/85246/policy-classdiagram.jpg.
I'll add more later for the rest of your comments.
Thanks,
Raymond
From: Simon Laws
Sent: Wednesday, February 25, 2009 4:03 AM
To: dev@tuscany.apache.org
Subject: Re: [2.x] Update on the OASIS OpenCSA SCA policy framework
<rfeng>I intentionally produced a raw UML model that only captures the classes/interfaces. I have another version that is generated from the java code which acurrately reflects what we have in the java code. Once the model is agreed, we can publish that too.</rfeng>
If you have it can you post the full model? Much easier than trying to reverse engineer the code.
<rfeng>The current code tries to reconcile and resolve all the configurations following the composite/component/service|referenece/binding chain as well as the component/componentType inheritance. And we push the result at every single levels, for example, copy all settings from the enclosing composite to the component, then to the service. This makes the builders very complicated and the model very messy. From both assembly and policy perspective, what we are interested in at runtime is the following:
* The reference to an endpoint (It captures all the related metadata for the SCA reference on a given binding, such as composite, component, reference, binding, interface. All of them as policy subjects that can have intents or policySets attached)
* The an endpoint for a service (similar to the above)
* The component implementation
b is for direct attachment. We collect all the relevant policy subjects for one of the above items and then do the calculation. The result will be captured on the group to calculate the effective policies.
c is for external attachment. We need to apply the "attachTo" xpath against the SCA domain composite. It resolves a list of elements which are the policy subjects. Merging the result of b and c gets the ultimate policy attachments and it can be used to calculate the effective policies.
OK I agree that threading all of the policy stuff through the assembly model as it's built is complex and therefore the separation of the two models has advantages. I'd like us to get into more detail about the sequence of events as I don't want us to be painted into a corner re. future flexibility.
In what follows I realize I'm not saying anything particularly new but am marshalling my own thoughts;-) We have the three main things from the above list.
Implementation
Endpoint (the service/binding piece)
Endpoint Reference (I think that's what we are calling the reference/binding piece these days)
Endpoint Reference for resolved target
Endpoint Reference for explicit binding
Endpoint Reference determined by autowire
The initial active policy set can be determined for all of these things with suitable processing in the domain. I've used the term "initial policy set" as I'm ducking here the question about what happens when someone adds a new contribution to the domain that contains a definitions.xml file.
Clearly we need to start by reading both the assembly model and the policy model. The result of this at the moment is the domain level composite and the system contribution. I believe you are saying that following there is an "outside looking in" process where the intent/policy information is applied to the assembly model to determine what is applicable and what is actually active for each policy subject (implementation, endpoint and endpoint reference). NWe'll have to extend this to support operations and messages as policy subjects.
There is one case that is problematic. Endpoint Reference for unresolved target. We may say that in this case the composite can't be started until the target is resolved and hence policy processing can be completed when the target becomes resolved. I.e. from a deployment point of view we may configure nodes with unresolved references (what will naturally happen if you add contributions one at a time) but that they will only be started when all endpoints are resolved. I should say this is different in my mind from the situation where someone chooses to build an infrastructure to do registry look up for service endpoint information for targets that are known to be resolved.
So this makes me agree that the process of calculating applicable policies should at least be easily repeatable and independent of the main build processing. Which I think is what you are saying. Given that we have said the word Endpoint here a few time and I'm looking at that at the moment I think we need to put some context models together that documents how the policy processing will apply.
None of this discussion precludes having a purely static model in the first instance but I would like to bear this in mind to at least allow for the possibility of future dynamic behaviour.
Regards
Simon
Re: [2.x] Update on the OASIS OpenCSA SCA policy framework
Posted by Simon Laws <si...@googlemail.com>.
>
> <rfeng>I intentionally produced a raw UML model that only captures
> the classes/interfaces. I have another version that is generated from the
> java code which acurrately reflects what we have in the java code. Once the
> model is agreed, we can publish that too.</rfeng>
>
If you have it can you post the full model? Much easier than trying to
reverse engineer the code.
> <rfeng>The current code tries to reconcile and resolve all the
> configurations following the composite/component/service|referenece/binding
> chain as well as the component/componentType inheritance. And we push the
> result at every single levels, for example, copy all settings from the
> enclosing composite to the component, then to the service. This makes the
> builders very complicated and the model very messy. From both assembly and
> policy perspective, what we are interested in at runtime is the following:
>
> * The reference to an endpoint (It captures all the related metadata for
> the SCA reference on a given binding, such as composite, component,
> reference, binding, interface. All of them as policy subjects that can have
> intents or policySets attached)
> * The an endpoint for a service (similar to the above)
> * The component implementation
>
> b is for direct attachment. We collect all the relevant policy subjects for
> one of the above items and then do the calculation. The result will be
> captured on the group to calculate the effective policies.
> c is for external attachment. We need to apply the "attachTo" xpath against
> the SCA domain composite. It resolves a list of elements which are the
> policy subjects. Merging the result of b and c gets the ultimate policy
> attachments and it can be used to calculate the effective policies.
>
OK I agree that threading all of the policy stuff through the assembly model
as it's built is complex and therefore the separation of the two models has
advantages. I'd like us to get into more detail about the sequence of events
as I don't want us to be painted into a corner re. future flexibility.
In what follows I realize I'm not saying anything particularly new but am
marshalling my own thoughts;-) We have the three main things from the above
list.
Implementation
Endpoint (the service/binding piece)
Endpoint Reference (I think that's what we are calling the reference/binding
piece these days)
Endpoint Reference for resolved target
Endpoint Reference for explicit binding
Endpoint Reference determined by autowire
The initial active policy set can be determined for all of these things with
suitable processing in the domain. I've used the term "initial policy set"
as I'm ducking here the question about what happens when someone adds a new
contribution to the domain that contains a definitions.xml file.
Clearly we need to start by reading both the assembly model and the policy
model. The result of this at the moment is the domain level composite and
the system contribution. I believe you are saying that following there is an
"outside looking in" process where the intent/policy information is applied
to the assembly model to determine what is applicable and what is actually
active for each policy subject (implementation, endpoint and endpoint
reference). NWe'll have to extend this to support operations and messages as
policy subjects.
There is one case that is problematic. Endpoint Reference for unresolved
target. We may say that in this case the composite can't be started until
the target is resolved and hence policy processing can be completed when the
target becomes resolved. I.e. from a deployment point of view we may
configure nodes with unresolved references (what will naturally happen if
you add contributions one at a time) but that they will only be started when
all endpoints are resolved. I should say this is different in my mind from
the situation where someone chooses to build an infrastructure to do
registry look up for service endpoint information for targets that are known
to be resolved.
So this makes me agree that the process of calculating applicable policies
should at least be easily repeatable and independent of the main build
processing. Which I think is what you are saying. Given that we have said
the word Endpoint here a few time and I'm looking at that at the moment I
think we need to put some context models together that documents how the
policy processing will apply.
None of this discussion precludes having a purely static model in the first
instance but I would like to bear this in mind to at least allow for the
possibility of future dynamic behaviour.
Regards
Simon
Re: [2.x] Update on the OASIS OpenCSA SCA policy framework
Posted by Raymond Feng <en...@gmail.com>.
Thanks for the feedback. Please see my comments below.
Raymond
From: Simon Laws
Sent: Tuesday, February 24, 2009 5:26 AM
To: dev@tuscany.apache.org
Subject: Re: [2.x] Update on the OASIS OpenCSA SCA policy framework
Hi Raymond
Looks like good progress! Some initial comments.....
I have started to implement the OASIS OpenCSA SCA policy framework. The first set of the changes were checked in under r746356 [1]. It contains the model interfaces/implementations as well as the processors that load the policy related configuration from composite and definitions files. The UML model is available at [2]. I also added a diagram to show the relationship between the policy and assembly [3]. Feedbacks are welcome.
Some detailed comments on the UML model (this of course assumes that I understand the semantics you imply by the names of the relationships in the diagram)
An qualified intent can only qualify a single intent
An intent can require zero or more intents (the 0..1 multiplicity refers to the attribute itself and not its contents)
An intent can exclude zero or more intents
An intent can be marked as mutallyExclusive
An intent can have an intentType
An intent can have a description
An intent can constrain an extension type
<rfeng>An intent can constrain one or more extension types</rfeng>
A qualifier has a description
<rfeng>The intent/qualifier element is now modeled as a "qualified" intent.</rfeng>
The qualifier is shown as being shared with the intent map. This may not be correct as they are defined as separate structures. I think we (I) need to understand this area better
<rfeng>You are confused here. The Qualifier model is for the intentMap/qualifier element. It contains the provided intent and a list of policy expressions.</rfeng>
A profile intent cannot be a qualified intent. Is this restriction just applied in the processors. Would we worth noting these kind of explicit restrictions as they will catch us out.
<rfeng>
When I look at the different types of intents, I don't see a strong need to have separate models. All the constraints can be enforced as we validate the model against the conformance items.
Here is my view:
profile intent = an intent with a non-empty required intents list
qualified intent = an intent with a non-null qualifiable intent and its local name contains a '.' (the spec only allows one level of qualifications)
</rfeng>
PolicySet has a name
PolictSet appliesTo zero to many ExtensionTypes
PolicySet may provide and intent without an intentMap (or are you always going to use and intent map regardless of whether a qualified intent is involved.If so then the intent map should be able to provide and intent directly and not via a qualifier.
<rfeng>We have PolicySet.getPolicies() to catch that. It's probably missing in the UML diagram.</rfeng>
Does PolicyExpression represent the actiualy policy? I think "expression" is missleading. Why not just call this "polcy"?
<rfeng>I align some of the terms with the WS-Policy spec from which the SCA policy spec generalizes some of the ideas. In the WS-Policy term, PolicyExpression is the XML info set for the policy. </rfeng>
Multiple policySets can provide the same intent. Differentiated by where they are applied
Multiple policySets can applyTo an ExtensionType.
Multiple policySets can attachTo a PolicySubject
Generally it would be useful to get the attributes and methods on the UML diagram (I only mentioned a few) as there is an amount of interpretation required in reading the diagram and the extra information will help.
<rfeng>I intentionally produced a raw UML model that only captures the classes/interfaces. I have another version that is generated from the java code which acurrately reflects what we have in the java code. Once the model is agreed, we can publish that too.</rfeng>
For next steps, I'm looking into the following directions:
Is it safe to assume that we are going to support both direct and external attachment?
<rfeng>Yes</rfeng>
a. Build the definitions from the built-in intents/policies as well as the META-INF/definitions.xml from SCA contributions. The list of definitions become the definitions of Intents, PolicySets and ExtensionTypes in the SCA domain.
Can you take a look at the SystemContribution formation in the NodeImpl. This should help you out here.
<rfeng>I did. It's good that the NodeImpl is already on that direction</rfeng>
b. Build the policy configuration for the endpoints (service binding) /endpoint-references (reference binding) /implementations following the inheritances from the implementation and structure hierarchies. The result will be a list of PolicySubjects which represent the SCA endpoints/endpoint-references/implementations.
I'm interested in how the xpath expression is applied. I would like us to get rid of this initial stage we have at them moment that creates hidden applicable policy set attributes.
<rfeng>I removed all that. It was pretty fun to get rid of complex code. </rfeng>
c. Attach the policySets to the SCA domain composite using the @attachTo XPath and resolve to a list of endpoints/endpoint-references/implementations. The result will be consolidated with the result from b to become the effective policies for a given policy subject.
I don't understand your thinking on b and c here. I guess we need to discuss more detail.
<rfeng>The current code tries to reconcile and resolve all the configurations following the composite/component/service|referenece/binding chain as well as the component/componentType inheritance. And we push the result at every single levels, for example, copy all settings from the enclosing composite to the component, then to the service. This makes the builders very complicated and the model very messy. From both assembly and policy perspective, what we are interested in at runtime is the following:
* The reference to an endpoint (It captures all the related metadata for the SCA reference on a given binding, such as composite, component, reference, binding, interface. All of them as policy subjects that can have intents or policySets attached)
* The an endpoint for a service (similar to the above)
* The component implementation
b is for direct attachment. We collect all the relevant policy subjects for one of the above items and then do the calculation. The result will be captured on the group to calculate the effective policies.
c is for external attachment. We need to apply the "attachTo" xpath against the SCA domain composite. It resolves a list of elements which are the policy subjects. Merging the result of b and c gets the ultimate policy attachments and it can be used to calculate the effective policies.
Please note step b & c is based on some of the thoughts on the endpoint side. At this moment, the current code try to patch/update the assembly models to resolve the configurations by implementation or structure inheritances. It leads to messy models and complex logic in the builders. Having a separate endpoint to group a set of assembly objects (such as [composite, component, service, binding] for a service endpoint and it will be used to hold the calculated configurations such as the interface, policySets and intents).
+1
After that, we will revisit the PolicyProvider SPIs to allow policy handlers to be added to the SCA invocation chains or endpoint/endpoint-reference/implementation to enforce the policies.
[1] http://svn.apache.org/viewvc?rev=746356&view=rev
[2] http://cwiki.apache.org/confluence/download/attachments/85246/policy-uml-model.jpg
[3] http://cwiki.apache.org/confluence/download/attachments/85246/policy-assembly.jpg
Thanks,
Raymond
Re: [2.x] Update on the OASIS OpenCSA SCA policy framework
Posted by Simon Laws <si...@googlemail.com>.
Hi Raymond
Looks like good progress! Some initial comments.....
> I have started to implement the OASIS OpenCSA SCA policy framework. The
> first set of the changes were checked in under r746356 [1]. It contains the
> model interfaces/implementations as well as the processors that load the
> policy related configuration from composite and definitions files. The UML
> model is available at [2]. I also added a diagram to show the relationship
> between the policy and assembly [3]. Feedbacks are welcome.
Some detailed comments on the UML model (this of course assumes that I
understand the semantics you imply by the names of the relationships in the
diagram)
An qualified intent can only qualify a single intent
An intent can require zero or more intents (the 0..1 multiplicity refers to
the attribute itself and not its contents)
An intent can exclude zero or more intents
An intent can be marked as mutallyExclusive
An intent can have an intentType
An intent can have a description
An intent can constrain an extension type
A qualifier has a description
The qualifier is shown as being shared with the intent map. This may not be
correct as they are defined as separate structures. I think we (I) need to
understand this area better
A profile intent cannot be a qualified intent. Is this restriction just
applied in the processors. Would we worth noting these kind of explicit
restrictions as they will catch us out.
PolicySet has a name
PolictSet appliesTo zero to many ExtensionTypes
PolicySet may provide and intent without an intentMap (or are you always
going to use and intent map regardless of whether a qualified intent is
involved.If so then the intent map should be able to provide and intent
directly and not via a qualifier.
Does PolicyExpression represent the actiualy policy? I think "expression" is
missleading. Why not just call this "polcy"?
Multiple policySets can provide the same intent. Differentiated by where
they are applied
Multiple policySets can applyTo an ExtensionType.
Multiple policySets can attachTo a PolicySubject
Generally it would be useful to get the attributes and methods on the UML
diagram (I only mentioned a few) as there is an amount of interpretation
required in reading the diagram and the extra information will help.
>
> For next steps, I'm looking into the following directions:
Is it safe to assume that we are going to support both direct and external
attachment?
>
>
> a. Build the definitions from the built-in intents/policies as well as the
> META-INF/definitions.xml from SCA contributions. The list of definitions
> become the definitions of Intents, PolicySets and ExtensionTypes in the SCA
> domain.
Can you take a look at the SystemContribution formation in the NodeImpl.
This should help you out here.
>
>
> b. Build the policy configuration for the endpoints (service binding)
> /endpoint-references (reference binding) /implementations following the
> inheritances from the implementation and structure hierarchies. The result
> will be a list of PolicySubjects which represent the SCA
> endpoints/endpoint-references/implementations.
I'm interested in how the xpath expression is applied. I would like us to
get rid of this initial stage we have at them moment that creates hidden
applicable policy set attributes.
>
>
> c. Attach the policySets to the SCA domain composite using the @attachTo
> XPath and resolve to a list of
> endpoints/endpoint-references/implementations. The result will be
> consolidated with the result from b to become the effective policies for a
> given policy subject.
I don't understand your thinking on b and c here. I guess we need to discuss
more detail.
>
>
> Please note step b & c is based on some of the thoughts on the endpoint
> side. At this moment, the current code try to patch/update the assembly
> models to resolve the configurations by implementation or structure
> inheritances. It leads to messy models and complex logic in the builders.
> Having a separate endpoint to group a set of assembly objects (such as
> [composite, component, service, binding] for a service endpoint and it will
> be used to hold the calculated configurations such as the interface,
> policySets and intents).
+1
>
>
> After that, we will revisit the PolicyProvider SPIs to allow policy
> handlers to be added to the SCA invocation chains or
> endpoint/endpoint-reference/implementation to enforce the policies.
>
> [1] http://svn.apache.org/viewvc?rev=746356&view=rev
> [2]
> http://cwiki.apache.org/confluence/download/attachments/85246/policy-uml-model.jpg
> [3]
> http://cwiki.apache.org/confluence/download/attachments/85246/policy-assembly.jpg
>
> Thanks,
> Raymond
>