Michael, Thanks for your comments and suggestions. Yes, I agreed. Typically policy would be enabled through PolicySet. My assumption is some intents may be enabled by binding and implementation because the intent may heavily depend on binding/impl underlying API or be supported by the nature of the binding/impl. And others may be enabled by system (in Tuscany, this may be done by registering interceptor. PolicySet will be enabled by corresponding interceptor), so the code to enable these PolicySet could be shared for multiple bindings/impls. Is this reasonable?
If so, does policy framework spec have any consideration for indicate "who" will enable the intent on a binding/impl type, system or the binding/impl? For example,"directly support" means it doesn't need PolicySet for concrete policy configuration. Does it also imply the intent should"be enabled" by binding and implementation itself? Felix On 11/4/06, Michael Rowley <[EMAIL PROTECTED]> wrote:
<MR> Sounds good. Although you should make sure to allow for cases where bindings or implementation types provide intents directly, without using policy sets. I suspect this is what you mean by the paragraph below.</MR> <MR> I expect that the typical way that policy would be enabled (I hesitate to say "enforced", since most policies are more like configuration than like assertions) would be through policySets. I expect that different child elements of the <policySet> element would trigger creation of different kinds of configuration artifacts to be created. Some policies would be expressed as wsp:PolicyAttachments, and others could be references to fragments of J2EE deployment descriptors.</MR>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
