On 4/20/07, Glynn, Eoghan <[EMAIL PROTECTED]> wrote:
> i.e. what
> would be the recommended way to assert a RMAssertion on my
> service via the API?
I'm not sure.
Maybe something like PolicyEngine.setEndpointPolicy() if the policy
engine were available as a Bus extension of some-such.
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.
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.
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. 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
