[
https://issues.apache.org/jira/browse/WSCOMMONS-299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12719096#action_12719096
]
Konrad K edited comment on WSCOMMONS-299 at 6/13/09 1:22 AM:
-------------------------------------------------------------
Indeed ... But let me explain my motivation first...
In my project, we need to generate policies based on parameters given at a
frontend. Therefore I tried out Metro's policy library but it has the following
disadvantages:
- PolicyAssertion subclasses aren't easy to reuse. For instance i need an
"Issuer" assertion with an wsa:EndpointReferenceType inside. But the class is
missing a convenient constructor or a setter to do so.
- Something which is also quite annoying are the two object models for
policies, namely a source and a normal one. Thus serializing includes lots of
transformation code.
- In the normal model most classes are immutable. Thus I had to package all my
assertions into collections before passing them to an operator. Afterwards I
had to package all my operators before creating a policy. As a result, I have
to generate my policy backwards.
- Its object model doesn't reflect the policy specification as good as Neethi
does.
Neethi adopts the composite pattern and generating a policy looks naturally in
the code. Also CXF's assertions seem to be cool initially, but they have some
mistakes (see http://issues.apache.org/jira/browse/CXF-2282). Another problem
is that they don't implement WS-SecurityPolicy to the letter. I wasn't able to
pass my whole EndpointReference to this setter:
setIssuerEpr(org.w3c.dom.Element issuerEpr), because I might have a wsa:Address
and but also a Metadata element, which need to be direct childs of the Issuer
Assertion. In the end I implemented most Assertions again.
Summarizing my experience i came to the following conclusions:
- CXF's Assertions have too much duplicate code ... also because of the
Assertion interface design
- The implementation of standardized assertions should be a part of Neethi and
the enforcement of them should be a part of CXF. That would enable people like
me to reuse assertions, as they are specified.
- It would also be nice to support WS-Policy 1.5 ... but currently we can't
switch the policy version consistently, because the serialize methods have
opaque nested policies.
I'm thinking of an Assertion interface like the following:
getName() : QName
getNestedPolicy() : Policy
isOptional()
isIgnorable()
serializeParameters() ... getParameters ... ?_?
serializeAttributes() ... getAttributes ... ?_?
// because most specified assertions have extension points
addParameter()
addAttribute()
Things that can be realized with such an interface ...
- consistent WS-Policy 1.2 or WS-Policy 1.5 serialization
- implementation of normalize and intersect by Neethi
- getParameters() would also enable cloning of a policy and hence e.g. the
normalization can't be undone accidentally.
- reduces common code like serializing an assertion's QName
Whilst such an interface enables the above points it is difficult to implement
... Also we loosed e.g. the possibility that implementors take a JAXB binding
and pass the XMLStreamWriter to the Marshaller ...
maybe we can add a policy version parameter to the serialize method ...
So I'm not sure what's the best solution ...
was (Author: creme-fresh):
Indeed ... but I think the Assertion interface of CXF isn't sufficient,
too. But let me explain my motivation first...
In my project, we need to generate policies based on parameters given at a
frontend. Therefore I tried out Metro's policy library but it has the following
disadvantages:
- PolicyAssertion subclasses aren't easy to reuse. For instance i need an
"Issuer" assertion with an wsa:EndpointReferenceType inside. But the class is
missing a convenient constructor or a setter to do so.
- Something which is also quite annoying are the two object models for
policies, namely a source and a normal one. Thus serializing includes lots of
transformation code.
- In the normal model most classes are immutable. Thus I had to package all my
assertions into collections before passing them to an operator. Afterwards I
had to package all my operators before creating a policy. As a result, I have
to generate my policy backwards.
- Its object model doesn't reflect the policy specification as good as Neethi
does.
Neethi adopts the composite pattern and generating a policy looks naturally in
the code. Also CXF's assertions seem to be cool initially, but they have some
mistakes (see http://issues.apache.org/jira/browse/CXF-2282). Another problem
is that they don't implement WS-SecurityPolicy to the letter. I wasn't able to
pass my whole EndpointReference to this setter:
setIssuerEpr(org.w3c.dom.Element issuerEpr), because I might have a wsa:Address
and but also a Metadata element, which need to be direct childs of the Issuer
Assertion. In the end I implemented most Assertions again.
Summarizing my experience i came to the following conclusions:
- CXF's Assertions have too much duplicate code ... also because of the
Assertion interface design
- The implementation of standardized assertions should be a part of Neethi and
the enforcement of them should be a part of CXF. That would enable people like
me to reuse assertions, as they are specified.
- It would also be nice to support WS-Policy 1.5 ... but currently we can't
switch the policy version consistently, because the serialize methods have
opaque nested policies.
I'm thinking of an Assertion interface like the following:
getName() : QName
getNestedPolicy() : Policy
isOptional()
isIgnorable()
serializeParameters() ... getParameters ... ?_?
serializeAttributes() ... getAttributes ... ?_?
// because most specified assertions have extension points
addParameter()
addAttribute()
Things that can be realized with such an interface ...
- consistent WS-Policy 1.2 or WS-Policy 1.5 serialization
- implementation of normalize and intersect by Neethi
- getParameters() would also enable cloning of a policy and hence e.g. the
normalization can't be undone accidentally.
- reduces common code like serializing an assertion's QName
Whilst such an interface enables the above points it is difficult to implement
... Also we loosed e.g. the possibility that implementors take a JAXB binding
and pass the XMLStreamWriter to the Marshaller ...
maybe we can add a policy version parameter to the serialize method ...
So I'm not sure what's the best solution ...
> Policy intersection is not yet implemented
> ------------------------------------------
>
> Key: WSCOMMONS-299
> URL: https://issues.apache.org/jira/browse/WSCOMMONS-299
> Project: WS-Commons
> Issue Type: Bug
> Components: Policy
> Reporter: Tammo van Lessen
> Attachments: patch.txt, patch2.txt
>
>
> Intersection is crucial for testing compatibility. It was already implemented
> it one of the earlier versions but got somehow lost...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
