> -----Original Message-----
> From: Dan Diephouse [mailto:[EMAIL PROTECTED]
> Sent: 20 April 2007 17:40
> To: [email protected]
> Subject: Re: Some quick thoughts on WSFeature and Policies
>
> > 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.
>
>
> Totally agreed. I'm just trying to figure out how to best
> support the various use cases.
>
> At the very least I think I'd like a way to embed a policy
> inside an <endpoint>/<client> without resorting to an attachment.
Just so I understand, would embedding a policy in this way be:
(a) a straight *alternative* to attaching the policy externally, so that
the attachement is no longer required to cause the corresponding
capability to be enabled
or
(b) more of a "complete the picture" sort of idea ... e.g. a feature
that refers to a policy asserted elsewhere, and additionally provides
some extra detail not expressed in the policy itself (such as the
keystore location & password in the case of a security policy)?
> > Also, I would classify WSFeatures as a part of the Spring
> > > bean configurations, since they're essentially part of the
> > > *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.
>
>
> They're similar - which is why I'm thinking of renaming them
> plugins.
+1 for renaming to avoid confusion with JAX-WS 2.1 WebServiceFeatures.
However I'm not sure about "plugin", which to me has connotations of "a
coarse-grain blob of functionality which may be optionally loaded into
the container/Bus/whatever". For example a "security plugin" or "routing
plugin".
Sounds like these features are more fine-grained and concerned with
detailed settings, as opposed to the life-cycle issues around
dynamically loading a plugin. Anyway, just my two cents.
Cheers,
Eoghan
> With JAX-WS you can do something like this
>
> @WebService
> @WebServiceFeatures( features = { AddressingFeature.ID,
> MTOMFeature.ID, HTTPSessionFeature.ID, FastInfosetFeature.ID
> } ) public class MyWebServiceImpl { .... }
>
> The JAX-WS 2.1 RI comes with those features and several more.
> I think the first two are the only standard ones. We could
> map these back to our own WSFeature/WSPlugin representation
> pretty easily. It could probably be mapped back to policy too.
>
> BTW, one technical hurdle we have with writing policies right
> which reference the policy xsd outside the policy module is
> not possible. For instance, if I put the security policy xsd
> in the security policy module, it regenerates the core policy
> beans. To support reuse of the existing beans we have to
> migrate to JAXB 2.1. This could make a bit difficult in the
> meantime for outside people to write more advanced policies.
> Hopefully we can fix this in the 2.1 timeframe though.
>
> - Dan
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
>
