Sergey Beryozkin wrote:
-----Original Message-----
From: Sergey Beryozkin [mailto:[EMAIL PROTECTED]
Sent: 24 September 2007 21:31
To: [email protected]
Subject: RE: WS-SX
I think we're over-blowing the problem a bit. Lets not get sidetracked into
hypothetical discussions on how dangerous it is to put a private stuff into
policies. Rather lets come up with a set of practical guidelines on when to
use policies and features.
Another thing I'd like to avoid is to have some religious debate leading
nowhere.
I really don't believe this is hypothetical or religious at all.
Dan, you said you wanted to support WS-SecurityPolicy because it was so
important for the enterprise. Now you're also saying that using features is
so much better from an API perspective.
I personally don't understand what is your position. I'm just confused. Can
you please clarify?
Imagine I'm writing a GUI for CXF which configures the security for my
services. As a CXF integrator, I don't want to have to generate policies
to be able to configure a service. Features are much nicer to use. "new
Feature().setFoo(bar);"
Do you want support WS-SecurityPolicy by using WS-Security feature ? I don't
think it makes any sense but I'd you to explain please.
I would like to be able to configure CXF specific configuration items
(like key info) via a feature. Policies can then be attached.
I see policies and configuration of the other bits as two seperate
processes. For instance, you may have a policy which you apply to all
your services. But the key information may differ on each one.
Can you explain please what you mean by saying it's so much harder to set up
a service using a policy ?
See above.
I'd also like to suggest you to think of the following :
* how can one satisfy a user's desire to attach capabilities to endpoints,
operations, and bindings using features
Yeah, thats what Policy is for. Are you suggesting that users are going
to have different key information for different operations? I can
certainly see bindings/endpoints - and you can apply features at that level.
* how can a client to avoid doing duplications like enabling MTOM on the
client side when using features
I don't understand this question - if the client encounters an MTOM
policy expression, it can just enable it. No feature needed.
* how can a client perform intersection of capabilities using features
Eh? I'm not suggesting we rip out policy all together.
Speaking of the client: are you suggesting the client has to take a
policy from a service, add in a bunch of extra expressions for key info
and the like, and then deploy? Thats a hell of a lot of work. Thats what
features are for: to supply configuration which is orthogonal to Policy.
Or yes, one more thing.
How can one express 'or' combination using features, that is how one can do
multiple alternatives, something one can easily do with policies :
<Policy>
<All>
</All>
<All>
</All>
</Policy>
Alternatives are targeted at a consumer. Multiple consumers can choose their
own alternatives and a provider will ensure it supports all the consumers.
Consumers may also have their policies on which case they'll do the
intersection.
This clearly shows that WS-Policy is not about configuration only. Looking
at a WS-Policy language as the configuration option only is not correct.
I don't want push the message that using policies is the only true way to
go. I'd just like us to agree on a policy (:-)) when polices should be
applied.
Who's looking at WS-Pol as a configuration option only here? I didn't
think anyone was.
So to summarize: we should use features for information which is not
useful for the client and for stuff which should not be public beyond
the local service. Because:
1. It makes API configuration of the service easier. No need to generate
policy documents by hand.
2. Security considerations - Policy files are not easily tracked and
will leak IMO
3. Configuration readability - WS-SecPol files are quite verbose/sticky.
As Fred said: "Im less inclined to use WS-SecurityPolicy as a
configuration mechanism, at least exclusively so. It's not really
designed to be human-readable, despite the fact that it's written in
XML, and XML is supposed to be human-readable, etc etc."
4. Separation of concerns: Policy and configuration are two separate
processes, often done at different stages. They also have different
levels of reusability.
I'm not saying we couldn't also support policy expressions for
configuration, but I think the use case for it is limited. Again, as
Fred said: "I agree that in some small percentage of cases, we need to
support configuration of WS-SecurityPolicy directly, and at a low level,
but these cases fall below the 20% bar, and can certainly be exposed
through low-level config."
Of the above items, I will admit that 3/4 are potentially overcomeable
but I would rank #1 & #2 as very important issues which kill the idea of
configuring everything in Policy for me. We could also potentially use a
feature to generate policy, but that would be a PITA IMO. It'd probably
just be easier to interact with the WS-SX engine directly.
- Dan
--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com/blog
