[Neethi][Status] Newly proposed architecture of Neethi

[Sanka Samaranayake <sa...@apache.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello Everyone,

Apache Neethi 1.0 didn't have an extensibility mechanism which will
allow the assertion authors to control the behavior of an assertion.
It passed all the assertions in its entirety and provided a uniform
way of getting the underlying attributes and values. This way of
processing raised few issues. First it consumes lot of memory and
processing power specially if the assertion is a complex one. Second
it doesn't provide the assertion authors a mechanism to control the
behavior of the any domain specific assertions. For instance to add
some specific methods to get values of some specific attributes etc.

To address these issues a new architecture was suggested.
see : https://issues.apache.org/jira/browse/WSCOMMONS-42

I've committed some code based on that newly proposed architecture
with some minor amendments. Following is a concise description of how
the new stuff work.

PolicyCompoent:
New Neethi architecture consists of two type of PolicyComponents
namely PolicyOperators and Assertions.

PolicyOperator:
There are three PolicyOperators namely Policy, ExactlyOne and All
which extends the AbstractPolicyOperator class. You can add one or
more PolicyComponents to a PolicyOperator. It also defines a
normalize(boolean) method which returns a PolicyComponent that is the
normalized format of that PolicyOperator. The boolean parameter
indicates where the Assertions that PolicyOperator contains should be
normalized. It is useful since partial normalization is sufficient for
high level Policy operations like merge and intersect and the cost of
normalization of a complex assertion can be high.

Assertion:
Assertion is an interface that any domain specific Assertion must
implement. This is the extension point for the domain specific
Assertion authors to write their own Assertions with desirable
behavior yet the general Neethi frame can understand. Here it is up to
domain specific Assertion authors to decide what additional methods to
implement, level of processing of the xml structure and how
normalization should behave of that particular Assertion.

AssertionBuilderFactory and AssertionBuilders:
AssertionBuilder is an interface which all domain specific
AssertionBuilders much implement. Any domain specific AssertionBuilder
has the knowledge to build an Assertion out of an OMElement with a
specific QName. For instance UsernameTokenAssertionBuilder can build a
UsernameToken Assertion out of a OMElement which must be the
UsernameToken Policy Assertion. Assertion builder factory maintains a
set of AssertionBuilders where each AssertionBuilder is capable of
producing an Assertion out of a OMElement. You can register any
AssertionBuilder in the AssertionBuilderFactory where that
AssertionBuilder becomes available for other registered
AssertionBuilders.

PolicyEngine:
PolicyEngine provides mechanisms to create a Policy object out of an
OMElement or an InputStream. It maintains a AssertionBuilderFactory
instance that is used process any Assertion other than PolicyOperators
when it constructs a Policy object.

Thoughts ?

Best,
- --Sanka

- --
Sanka Samaranayake
WSO2 Inc.
http://sankas.blogspot.com/ - http://www.wso2.net/
T:+94-77-3506382 F:+94-11-2424304

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (GNU/Linux)

iD8DBQFEw2P8/Hd0ETKdgNIRAnyvAJ9DzbdWQcFLBegovegjqiMbydBmtQCaAzZw
0m5ezurQGQyqB9NGya03h1c=
=k4b7
-----END PGP SIGNATURE-----


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org

Re: [Neethi][Status] Newly proposed architecture of Neethi

[Sanjiva Weerawarana <sa...@opensource.lk>]

Can u post build instructions please? We'll want build neeth1 (the "old"
neethi) and neethi2 (the "new" neethi) both of course.

Can we post snapshots as neethi2 somewhere?

Sanjiva.

On Sun, 2006-07-23 at 11:56 +0000, Sanka Samaranayake wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello Everyone,
> 
> Apache Neethi 1.0 didn't have an extensibility mechanism which will
> allow the assertion authors to control the behavior of an assertion.
> It passed all the assertions in its entirety and provided a uniform
> way of getting the underlying attributes and values. This way of
> processing raised few issues. First it consumes lot of memory and
> processing power specially if the assertion is a complex one. Second
> it doesn't provide the assertion authors a mechanism to control the
> behavior of the any domain specific assertions. For instance to add
> some specific methods to get values of some specific attributes etc.
> 
> To address these issues a new architecture was suggested.
> see : https://issues.apache.org/jira/browse/WSCOMMONS-42
> 
> I've committed some code based on that newly proposed architecture
> with some minor amendments. Following is a concise description of how
> the new stuff work.
> 
> PolicyCompoent:
> New Neethi architecture consists of two type of PolicyComponents
> namely PolicyOperators and Assertions.
> 
> PolicyOperator:
> There are three PolicyOperators namely Policy, ExactlyOne and All
> which extends the AbstractPolicyOperator class. You can add one or
> more PolicyComponents to a PolicyOperator. It also defines a
> normalize(boolean) method which returns a PolicyComponent that is the
> normalized format of that PolicyOperator. The boolean parameter
> indicates where the Assertions that PolicyOperator contains should be
> normalized. It is useful since partial normalization is sufficient for
> high level Policy operations like merge and intersect and the cost of
> normalization of a complex assertion can be high.
> 
> Assertion:
> Assertion is an interface that any domain specific Assertion must
> implement. This is the extension point for the domain specific
> Assertion authors to write their own Assertions with desirable
> behavior yet the general Neethi frame can understand. Here it is up to
> domain specific Assertion authors to decide what additional methods to
> implement, level of processing of the xml structure and how
> normalization should behave of that particular Assertion.
> 
> AssertionBuilderFactory and AssertionBuilders:
> AssertionBuilder is an interface which all domain specific
> AssertionBuilders much implement. Any domain specific AssertionBuilder
> has the knowledge to build an Assertion out of an OMElement with a
> specific QName. For instance UsernameTokenAssertionBuilder can build a
> UsernameToken Assertion out of a OMElement which must be the
> UsernameToken Policy Assertion. Assertion builder factory maintains a
> set of AssertionBuilders where each AssertionBuilder is capable of
> producing an Assertion out of a OMElement. You can register any
> AssertionBuilder in the AssertionBuilderFactory where that
> AssertionBuilder becomes available for other registered
> AssertionBuilders.
> 
> PolicyEngine:
> PolicyEngine provides mechanisms to create a Policy object out of an
> OMElement or an InputStream. It maintains a AssertionBuilderFactory
> instance that is used process any Assertion other than PolicyOperators
> when it constructs a Policy object.
> 
> Thoughts ?
> 
> Best,
> - --Sanka
> 
> - --
> Sanka Samaranayake
> WSO2 Inc.
> http://sankas.blogspot.com/ - http://www.wso2.net/
> T:+94-77-3506382 F:+94-11-2424304
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.1 (GNU/Linux)
> 
> iD8DBQFEw2P8/Hd0ETKdgNIRAnyvAJ9DzbdWQcFLBegovegjqiMbydBmtQCaAzZw
> 0m5ezurQGQyqB9NGya03h1c=
> =k4b7
> -----END PGP SIGNATURE-----
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: commons-dev-help@ws.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org