On 4/23/07, Glynn, Eoghan <[EMAIL PROTECTED]> wrote:
> -----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)?
So the way I ended up implementing it is like (b) I think. The Feature can supply stuff thats not in the policy. Then the PolicyFeature will supply an inline policy so an attachment is no longer needed. This allows us to use straight-up Policy whenever possible. But if someone needs to supply more details or customize the Client/Server/Bus, as in the WS-Security case, then they can write their own feature class instead of just a PolicyInterceptorProvider. To take a more concrete example, right now WSRM can be completely configured via Policy. But say we add a database store at somepoint. I would see that being configured via a RMFeature. One advantage of this is that it allows you to seperate your configuration from policy if necessary. For instance, I could configure one WS-Security feature with the various keystores and then have different policies for each service.
> 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.
Yeah, I agree. I don't have any better names though - "Options"? I settled on AbstractFeature for the moment. Cheers, - Dan -- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
