[#HERASAFXACMLCORE-99] PolicyRepository should be split into two interfaces

HERAS-AF XACML Core

PolicyRepository should be split into two interfaces

Created: 08/Jan/10 02:45 PM Updated: Friday 01:40 PM

Component/s:

Policy Repository

Affects Version/s:

None

Fix Version/s:

1.0.0-M2

Time Tracking:

Original Estimate:

4 hours

Remaining Estimate:

0 minutes

Time Spent:

3 hours, 16 minutes

File Attachments:

mylyn-context.zip (9 kB)
2.

mylyn-context.zip (9 kB)
3.

mylyn-context.zip (16 kB)

Issue Links:

Relate

This issue is related to:

~~HERASAFXACMLCORE-144~~ Split usage of evaluation and deployment policy repositories

~~HERASAFXACMLCORE-120~~ Improve SimplePDPFactory API

~~HERASAFXACMLCORE-131~~ Adaption of the SimplePDP factory methods

Issue Links:

Description

« Hide

When I want to write an Implementation of PolicyRepository to pass to a PDP Implementation, I have to implement both PDP-facing and deployment-specific methods. That means that I cannot write a Deployment endpoint without having to implement the internal methods as throwing NotSupportedOperationExceptions. A repository apparently has two (inter) faces looking in different directions.

All

Comments

Work Log

Change History

Sort Order:

[ Permalink | « Hide ]

Stefan Oberholzer added a comment - 14/May/10 12:55 PM - edited

I think it should be at least three interfaces.
One interface to get the policies (during evaluation), one Interface to deploy undeploy root policies and another one to deploy deltas to an existing policy tree. I don't think that everyone who wants to implement a repository wants be able to implement the possibility to change an existing policy tree.

[ Permalink | « Hide ]

Wolfgang Giersche added a comment - 17/May/10 07:06 AM

I do not understand why there need be an interface for the delta deployments. Well, it may be beneficial to have such a method somewhere, but:

what benefit is in the interface for a PAP developer? She's going to use her own implementation of a repo anyway, with her own interfaces on the deployment side.
what do we know about the actual deployment process and all the info it requires? It's going to be very specific for any implementation, anyway.
The interface can only be a marker anyway and forces PAP deployment to use HERAS-AF specific code. This is unlikely to be appreciated.

I suggest we spare the effort.

[ Permalink | « Hide ]

Florian Huonder added a comment - 17/May/10 09:28 AM

I understand Stefan's idea.
I think it would be an effort worth it because:

As I understand Stefan the delta-deployment-interface is intended to be an extension to the (I say) root-deployment-interface.
This issue is not about having custom interfaces on the deployment side. It is about having a set of interfaces if someone wants to use them. In my opinion the case where someone is going to use his own interfaces is a different case.
In the case a PAP/PolicyRepository developer decides to use our interfaces he has, currently, only one interface. This interface requires to developer to implement root-deployment methods and delta-deployment methods. If he does not want delta-deployments he is forced to do an unlovely thing like "OperationNotSupportedException". I think this is much worse than giving him the choice of implementing an interface that only supports root-deployment or an extended version that supports delta-deployment as well.

With these methods we provide a somewhat generic way for deployment: The root-deployment methods support deploying and undeploying on the root level and the delta-deployment methods support any kind of change to an existing policy tree. The latter is also implemented very generic due to the fact that the delta-objects are of type DeploymentModification that is only a marker interface. In my opinion this approach suffices a lot of "standard" cases and if not the user is still open to use his own, custom, interfaces.

[ Permalink | « Hide ]

René Eggenschwiler added a comment - 17/May/10 03:35 PM - edited

I agree with Stefan with respect to Wolfgangs input (they both are right).
My opinion is that we should merge both ideas:

Make 3 Interfaces:
- getEvaluatables Aspects for Evaluation
- simpleDeploy Aspects for "root" deployment
- deltaDeploy Aspects for "delta" deployment

Interpretation:

Users implementing a PolicyRepository on their own will be sufficient by implementing "getEvaluatables" to work properly with HERAS-AF XACML Core.
That's the only interface they really MUST implement. Also HERAS-AF implementations have to implement that interface.

The "simpleDeploy" interface will be implemented by the default PolicyRepository in HERAS-AF XACML Core (e.g. MapBasedSimplePolicyRepository).
That's needed to provide a simple PolicyRepository which can deploy policies for testing and very basic standalone usage.
Meaning that it is optional for implementation by the user, but a MUST for default implementations in HERAS-AF XACML Core

The "deltaDeploy" interface can be defined now as a default variant for delta deployments.
It will not yet be implemented by any HERAS-AF implementation and most probably not be used by any user (at least not yet).
The interface will for the moment only be defined as a preview draft interface to mention that a delta deployment is foreseen anyhow.
No effort should be spent on implementing that interface yet.

[ Permalink | « Hide ]

Ylli Sylejmani added a comment - 16/Jul/10 01:57 PM

Additionally implemented some small corrections from the Review HERAS-AF-XACML-14.

[ Permalink | « Hide ]

Ylli Sylejmani added a comment - 16/Jul/10 02:01 PM

And also renamed the policy repository interfaces to the names, which I discussed with Wolfgang.
PolicyRepositoryDeployment --> PolicyRepository -~~> Ordered~~/UnorderedPolicyRepository
PolicyRepositoryEvaluation --> PolicyRetrievalPoint