Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of eoghan.glynn@iona.com
 designates 62.221.12.33 as permitted sender)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Some quick thoughts on WSFeature and Policies
Date: Fri, 20 Apr 2007 17:25:09 +0100
Message-ID: <FA1787F64A095C4090E76EBAF8B183E071FD84@emea-ems1.IONAGLOBAL.COM>
In-reply-to: <7b774c950704200859t3d0c01f2x71540af5e3461ba2@mail.gmail.com>
Thread-Topic: Some quick thoughts on WSFeature and Policies
Thread-Index: AceDZPapxZByHkxiQkWRo20VwdghCAAAKymA
From: "Glynn, Eoghan" <eoghan.glynn@iona.com>
To: <cxf-dev@incubator.apache.org>

=20

> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com]=20
> Sent: 20 April 2007 16:59
> To: cxf-dev@incubator.apache.org
> Subject: Re: Some quick thoughts on WSFeature and Policies
>=20
> Re: #4 - do we have a way to do programmatic policy=20
> manipulation that isn't associated with transports?


I guess it would depend on how each configured object is (a) created and
managed and (b) whether it exposes an accessor for its policies.


> i.e. what=20
> would be the recommended way to assert a RMAssertion on my=20
> service via the API?


I'm not sure.=20

Maybe something like PolicyEngine.setEndpointPolicy() if the policy
engine were available as a Bus extension of some-such.=20

But I guess this is part of the point I'm making, that we've multiple
config-related mechanisms that sometimes intersect and sometimes
diverge.

So suppose a user want to configure two aspects of the runtime, call
them A and B. The choice of mechanisms available to configure A (e.g.
Spring or WS-Policy) may well be different to the choice available for B
(say Spring or programmatic).

Note this is not an objection to WSFeature per se, just a warning light
as to where we're headed in general with multiple config mechanisms.

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


Are these proposed WSFeatures the same thing as the JAX-WS 2.1
javax.xml.ws.WebServiceFeature idea (that can be passed programmatically
to Service.getPort() or specified via annotations)?

I guess we'll be required to support these eventually as part of JAX-WS
2.1 conformance.

Cheers,
Eoghan

=20
> - Dan
>=20
> 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=20
> > configuring things.
> >
> > Not that each individual mechanism isn't a good thing in=20
> itself, but=20
> > that the growing collection of different means to similar ends will=20
> > become difficult to test, document, demo, support tooling for etc.
> >
> > Off the top of my head, we've about six different current=20
> or proposed=20
> > config-related mechanisms:
> >
> > 1. Spring beans
> > 2. WS-Policy
> > 3. WSDL extensions
> > 4. Programmatic policy manipulation, e.g.
> >=20
> ((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=20
> > would find it all over-whelming and confusing. I'm not sure if=20
> > combining some of these (e.g. embedded policy assertions in=20
> WSFeature=20
> > as you suggest) would help or hinder here. Certainly its=20
> better than=20
> > inventing a new config syntax where there's already a preexisting=20
> > policy. But it also adds to the plethora of options as to where to=20
> > hang the policy assertion (i.e. a multitude of attachment points in=20
> > WSDL, external attachments applying policies to EPRs, and now=20
> > WSFeatures also). So that choosing the appropriate subject=20
> for the policy becomes non-trivial.
> >
> > In the case of say the WS-RM policy assertion, what would be the=20
> > advantage of embedding this in the <jaxws:client><features> Spring=20
> > config, as opposed to having an external policy attachment applying=20
> > the same assertion to an EPR corresponding to the target=20
> port of the=20
> > <jaxws:client> bean?
> >
> > Things are already getting confusing in terms of there some=20
> things can=20
> > only be configured via Spring, others via either Spring beans or=20
> > policy attachments, still others via WSFeature within Spring beans,=20
> > etc. So it mightn't be straight-forward for an individual=20
> user to just=20
> > pick one mechanism (say WS-Policy) and standardize all their config=20
> > activity on this.
> >
> > Note I'm not necessarily knocking WSFeature here, but I think we'd=20
> > have to be very clear about the delineation between all the=20
> above, and=20
> > the motivation for supporting them all (i.e. ask what extra=20
> expressive=20
> > 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=20
> wanted to see=20
> > > if I could quick finish off the wsfeature stuff. Its not=20
> necessarily=20
> > > that much code. And I think there was some consensus that this is=20
> > > generally a good thing, but I'd like to garner some more=20
> feedback if=20
> > > possible.
> > >
> > > Quickly the idea is that we can configure WS-* features=20
> via a bean=20
> > > like or xml interface:
> > >
> > > ServerFactoryBean sf =3D new ServerFactoryBean();
> > >
> > > feature =3D 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=20
> construct is=20
> > > needed in CXF because:
> > > a) Not everything is configurable via policy. WS-Security=20
> is a prime=20
> > > example
> > > - the ws-security policy doesn't encapsulate everything=20
> we need it=20
> > > to for configuration, like information about keystores. I noticed=20
> > > WS-Addressing has a feature as well which isn't encapsulated in=20
> > > policy - the allow duplicates flag on the MAPAggregator could be=20
> > > 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=20
> benchmarked=20
> > > this, so its hard for me to say at this point)
> > >
> > > (a) could possibly be addressed by writing new policies,=20
> but I'm not=20
> > > sure that is the answer. I don't know that Policy makes a stellar=20
> > > configuration language for everything. Going back to my=20
> ws-security=20
> > > example, lets say I need to load a KeyStore. This=20
> KeyStore could be=20
> > > from a file or even possibly a database. If it was a database I=20
> > > would have to configure it with lots of jdbc info. If we go 100%=20
> > > ws-policy, I would have to write a policy to configure=20
> it. Whereas=20
> > > if I'm using a bean based/spring approach I can just=20
> write <bean...>=20
> > > inside my <trustKeyStore> element.
> > >
> > > Now the question in my mind is: how do we merge this=20
> seamlessly with=20
> > > policy?
> > > I agree that there is some overlap. So I was thinking of=20
> introducing=20
> > > 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=20
> and applying=20
> > > 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=20
> > > that verbose in reality for users as
> > > a) the features would have sensible defaults so you would=20
> only need=20
> > > to specify a policy if you were overriding the defaults
> > > b) it would seem that chances are high that they might have their=20
> > > policy externally attached if they're writing policy (via=20
> > > ExternalAttachmentProvider or via the wsdl attachments)
> > >
> > > Another option would be to allow inline policies at the endpoint=20
> > > config:
> > >
> > > <client>
> > >   <policies>
> > >      <RMAssertion> ... </RMAssertion>
> > >   </policies>
> > > </client>
> > >
> > > Finally, I'm contemplating the name "Plugins" instead. I=20
> could see=20
> > > this also applying to things like JMX configuration.
> > >
> > > Thoughts? Better ideas?
> > >
> > > - Dan
> > >
> > > --
> > > Dan Diephouse
> > > Envoi Solutions
> > > http://envoisolutions.com | http://netzooid.com/blog
> > >
> >
>=20
>=20
>=20
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
>=20