cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrea Smyth <andrea.sm...@iona.com>
Subject Re: Some quick thoughts on WSFeature and Policies
Date Fri, 20 Apr 2007 16:38:44 GMT
Dan Diephouse wrote:

> Re: #4 - do we have a way to do programmatic policy manipulation that 
> isn't
> associated with transports? i.e. what would be the recommended way to 
> assert
> a RMAssertion on my service via the API?

1. all manually:

RMInInterceptor rmIn = new RMInInterceptor();
Bus.getInInterceptors().add(rmIn);
...
Bus.getExtension(RMManager.class).getRMAssertion().setBaseRetransmissionInterval(...) 
;

The latter applies of course to all services  - but it's possible to 
programatically change that by creating a service specific RMManager, 
and using service specific rm interceptors.

2. programatically attach a policyElement to wsdl:

org.apache.neethi.Policy p = new Policy();
org.apache.neethi.Assertion a = new 
org.apache.cxf.ws.policy.JaxbAsertion<RMAssertion>();
p.addPolicyComponent(a);
... getServiceInfo().addExtensor(new Policy);

3. programming an external attachment provider  (I won't go into details 
here, but that also can be done in a couple of lines).

Andrea.

>
> Also, I would classify WSFeatures as a part of the Spring bean
> configurations, since they're essentially part of the
> *ServerFactory/*ClientFactory classes IMO.
>
> - Dan


BTW why restrict this to WSFeatures -

>
> On 4/20/07, Glynn, Eoghan <eoghan.glynn@iona.com> wrote:
>
>>
>>
>> Hi Dan,
>>
>> I'm a bit concerned here that we're proliferating different ways of
>> configuring things.
>>
>> Not that each individual mechanism isn't a good thing in itself, but
>> that the growing collection of different means to similar ends will
>> become difficult to test, document, demo, support tooling for etc.
>>
>> Off the top of my head, we've about six different current or proposed
>> config-related mechanisms:
>>
>> 1. Spring beans
>> 2. WS-Policy
>> 3. WSDL extensions
>> 4. Programmatic policy manipulation, e.g.
>> ((HTTPCondiut)client.getConduit()).getClientPolicy().setAllowChunking(tr
>> ue)).
>> 5. WSFeature
>> 6. config embedded in URIs (as proposed by James Strachan)
>>
>> Can't fault any individual one of these, but I'd worry that users would
>> find it all over-whelming and confusing. I'm not sure if combining some
>> of these (e.g. embedded policy assertions in WSFeature as you suggest)
>> would help or hinder here. Certainly its better than inventing a new
>> config syntax where there's already a preexisting policy. But it also
>> adds to the plethora of options as to where to hang the policy assertion
>> (i.e. a multitude of attachment points in WSDL, external attachments
>> applying policies to EPRs, and now WSFeatures also). So that choosing
>> the appropriate subject for the policy becomes non-trivial.
>>
>> In the case of say the WS-RM policy assertion, what would be the
>> advantage of embedding this in the <jaxws:client><features> Spring
>> config, as opposed to having an external policy attachment applying the
>> same assertion to an EPR corresponding to the target port of the
>> <jaxws:client> bean?
>>
>> Things are already getting confusing in terms of there some things can
>> only be configured via Spring, others via either Spring beans or policy
>> attachments, still others via WSFeature within Spring beans, etc. So it
>> mightn't be straight-forward for an individual user to just pick one
>> mechanism (say WS-Policy) and standardize all their config activity on
>> this.
>>
>> Note I'm not necessarily knocking WSFeature here, but I think we'd have
>> to be very clear about the delineation between all the above, and the
>> motivation for supporting them all (i.e. ask what extra expressive power
>> does WSFeature would give us).
>>
>> Cheers,
>> Eoghan
>>
>> > -----Original Message-----
>> > From: Dan Diephouse [mailto:dan@envoisolutions.com]
>> > Sent: 20 April 2007 08:23
>> > To: cxf-dev@incubator.apache.org
>> > Subject: Some quick thoughts on WSFeature and Policies
>> >
>> > Hiya,
>> >
>> > I know we're very close to our 2.0-RC release, but I wanted
>> > to see if I could quick finish off the wsfeature stuff. Its
>> > not necessarily that much code. And I think there was some
>> > consensus that this is generally a good thing, but I'd like
>> > to garner some more feedback if possible.
>> >
>> > Quickly the idea is that we can configure WS-* features via a
>> > bean like or xml interface:
>> >
>> > ServerFactoryBean sf = new ServerFactoryBean();
>> >
>> > feature = new WSSecurityFeature();
>> > feature.setTrustKeyStore(...);
>> > ...
>> > sf.addWSFeature(feature);
>> >
>> > Or in XML:
>> >
>> > <jaxws:endpoint ...>
>> >   <features>
>> >      <wssec:security>
>> >          ....
>> >      </wssec:security>
>> >   </features>
>> > </jaxws:endpoint>
>> >
>> > As stated previously, my thinking is that a WSFeature
>> > construct is needed in CXF because:
>> > a) Not everything is configurable via policy. WS-Security is
>> > a prime example
>> > - the ws-security policy doesn't encapsulate everything we
>> > need it to for configuration, like information about
>> > keystores. I noticed WS-Addressing has a feature as well
>> > which isn't encapsulated in policy - the allow duplicates
>> > flag on the MAPAggregator could be configured via this as well.
>> > b) Policy requires some extra configuration to set up (i.e.
>> > policy engine
>> > enablement)
>> > c) A feature may want to customize a bus/server/client.
>> > d) policy may introduce unnecessary overhead? (I haven't
>> > benchmarked this, so its hard for me to say at this point)
>> >
>> > (a) could possibly be addressed by writing new policies, but
>> > I'm not sure that is the answer. I don't know that Policy
>> > makes a stellar configuration language for everything. Going
>> > back to my ws-security example, lets say I need to load a
>> > KeyStore. This KeyStore could be from a file or even possibly
>> > a database. If it was a database I would have to configure it
>> > with lots of jdbc info. If we go 100% ws-policy, I would have
>> > to write a policy to configure it. Whereas if I'm using a
>> > bean based/spring approach I can just write <bean...> inside
>> > my <trustKeyStore> element.
>> >
>> > Now the question in my mind is: how do we merge this
>> > seamlessly with policy?
>> > I agree that there is some overlap. So I was thinking of
>> > introducing a AbstractPolicyWSFeature class which would be
>> > roughly like so:
>> >
>> > public class AbstractPolicyWSFeature {
>> >   public void setPolicies(Collection<Object> policies) {... }
>> >   public Collection<Object> getPolicies() { .. }
>> >
>> >   public void initialize(...) {
>> >    ... logic for ensuring the policy engine is enabled and
>> > applying the policies to the server/client/bus would go here
>> >   }
>> > }
>> >
>> > Or in xml form:
>> >
>> > <client>
>> >   <features>
>> >     <reliablemessaging>
>> >       <policies>
>> >          <RMAssertion>...</RMAssertion>
>> >       </policies>
>> >     </reliablemessaging>
>> >   </features>
>> > </client>
>> >
>> > Now that all seems a little verbose, but it probably wouldn't
>> > be that verbose in reality for users as
>> > a) the features would have sensible defaults so you would
>> > only need to specify a policy if you were overriding the defaults
>> > b) it would seem that chances are high that they might have
>> > their policy externally attached if they're writing policy
>> > (via ExternalAttachmentProvider or via the wsdl attachments)
>> >
>> > Another option would be to allow inline policies at the
>> > endpoint config:
>> >
>> > <client>
>> >   <policies>
>> >      <RMAssertion> ... </RMAssertion>
>> >   </policies>
>> > </client>
>> >
>> > Finally, I'm contemplating the name "Plugins" instead. I
>> > could see this also applying to things like JMX configuration.
>> >
>> > Thoughts? Better ideas?
>> >
>> > - Dan
>> >
>> > --
>> > Dan Diephouse
>> > Envoi Solutions
>> > http://envoisolutions.com | http://netzooid.com/blog
>> >
>>
>
>
>


Mime
View raw message