Re: PolicyHanders
Hi, Thanks for sharing your thoughts further. My comments inline. - Venkat On Feb 12, 2008 9:51 PM, Greg Dritschler <[EMAIL PROTECTED]> wrote: > Comments below. > > On Feb 11, 2008 7:36 AM, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > > > Hi Greg, > > > > Thanks for your observations / suggestions. Please see my comments > > inline. > > I apologize for making them lengthy in the hope that it would trigger > more > > discussions. > > > > - Venkat > > > > On Feb 7, 2008 1:33 AM, Greg Dritschler <[EMAIL PROTECTED]> > wrote: > > > > > I have been looking at the PolicyHandler support for Java > > implementations > > > and overall I like the direction this is going. I have some comments > > > about > > > it. > > > > > > 1. If a given component/operation has multiple policy sets that are > > > handled > > > by the same PolicyHandler, it appears that one PolicyHandler is > created > > > for > > > each such policy set. I wonder if it wouldn't be better to call a > given > > > PolicyHandler only once per invocation and give it the full list of > > policy > > > sets it handles. This may be more efficient depending on the policy > > (the > > > handler may be able to optimize/combine policies, and it may be able > to > > > find > > > conflicts that are beyond the powers of the policy framework). > > > > > > Just to clarify, I did start with PolicyHanlder types classified against > > the > > PolicySet name, but later discovered that this is not scalable. Today, > > the > > PolicyHandler types are classified against the PolicyModel that they can > > understand (i.e. WS-Policy or some customer model) and the Intent that > > they > > can deal with (i.e authentication or transaction). I feel we might also > > have to add one more classifier that denotes the QoS infrastructure that > > the > > PolicyHandler is capable of working with. While the policy model and > > intent > > can be extracted for a PolicySet to find the appropriate PolicyHandler, > I > > am > > not sure where we can encapsulate this 'specific infrastructure' > > information. > > > > I wasn't suggesting any changes along these lines. I think using model > objects and intents is sufficient. > Yes, I understood. :) ..but wanted to see if I could trigger some thoughts / ideas. > > > > So, if it does happen that we have mutliple PolicySets on a wire that > > point > > to the same PolicyHandler type, yes it makes sense to do what you > suggest. > > Infact, this turns out to be a necessity for example when we want to > > configure the Axis2 Config Parameters for binding.ws to say enable > > authentication AND integrity where each of these could have their own > > PolicySets. > > > > 2. Some intents can be provided without requiring a policy set (these > are > > > the intents in the implementation's mayProvides list). Although the > > > PolicyHandler gets registered for an intent, it appears it is only > > driven > > > if > > > the intent is satisfied by a policy set. It would be nice if it could > > be > > > driven if the intent appears in the mayProvides list too. > > > > > > +1. At the present moment this is left to how implementation and > binding > > extensions would choose to deal with. I'd prefer that the binding / > > implementation providers parse the list of required intents and if there > > are > > the ones that they 'mayProvide' then suitable PolicySets should be added > > to > > the list of PolicySets. Ofcourse the corresponding PolicyHandlers > should > > also be defined and registered. This I feel provide uniformity and > > extensibility to how policy handling plugs into extensions. > > > > Intents in the 'mayProvides' list don't require policy sets. True and will remain so for users. Amongst the choices of various mechanisms that a binding or implementation extension might use to handle mayProvides intents, I am just about suggesting why not use the PolicySet mechanism itself. The fact that the extension uses PolicySets for this is going to be opaque to users. Or am I missing a perspective here ? > > > > > > > > > > 3. I'm also wondering whether it should be possible to register a > > > PolicyHandler that always gets control regardless of what intents or > > > policy > > > sets are specified. This might be to implement some default behavior. > > > I'm > > > thinking of transactions here. The transaction spec says that the > > runtime > > > can provide one of the intents by default, but the choice of default > is > > > implementation-specific. There's no way to declare the default intent > > to > > > the policy framework today, so there's no choice but to give control > to > > > the > > > transaction handler and let it figure it out. > > > > > > > This sounds like something that is left for bindings / implementations > to > > deal with, in the way they might choose to. As I had mentioned in the > > previous point a cleaner way would be for binding /implementation > > providers > > to verify if a default intent need
Re: PolicyHanders
Comments below. On Feb 11, 2008 7:36 AM, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > Hi Greg, > > Thanks for your observations / suggestions. Please see my comments > inline. > I apologize for making them lengthy in the hope that it would trigger more > discussions. > > - Venkat > > On Feb 7, 2008 1:33 AM, Greg Dritschler <[EMAIL PROTECTED]> wrote: > > > I have been looking at the PolicyHandler support for Java > implementations > > and overall I like the direction this is going. I have some comments > > about > > it. > > > > 1. If a given component/operation has multiple policy sets that are > > handled > > by the same PolicyHandler, it appears that one PolicyHandler is created > > for > > each such policy set. I wonder if it wouldn't be better to call a given > > PolicyHandler only once per invocation and give it the full list of > policy > > sets it handles. This may be more efficient depending on the policy > (the > > handler may be able to optimize/combine policies, and it may be able to > > find > > conflicts that are beyond the powers of the policy framework). > > > Just to clarify, I did start with PolicyHanlder types classified against > the > PolicySet name, but later discovered that this is not scalable. Today, > the > PolicyHandler types are classified against the PolicyModel that they can > understand (i.e. WS-Policy or some customer model) and the Intent that > they > can deal with (i.e authentication or transaction). I feel we might also > have to add one more classifier that denotes the QoS infrastructure that > the > PolicyHandler is capable of working with. While the policy model and > intent > can be extracted for a PolicySet to find the appropriate PolicyHandler, I > am > not sure where we can encapsulate this 'specific infrastructure' > information. > I wasn't suggesting any changes along these lines. I think using model objects and intents is sufficient. > So, if it does happen that we have mutliple PolicySets on a wire that > point > to the same PolicyHandler type, yes it makes sense to do what you suggest. > Infact, this turns out to be a necessity for example when we want to > configure the Axis2 Config Parameters for binding.ws to say enable > authentication AND integrity where each of these could have their own > PolicySets. > > 2. Some intents can be provided without requiring a policy set (these are > > the intents in the implementation's mayProvides list). Although the > > PolicyHandler gets registered for an intent, it appears it is only > driven > > if > > the intent is satisfied by a policy set. It would be nice if it could > be > > driven if the intent appears in the mayProvides list too. > > > +1. At the present moment this is left to how implementation and binding > extensions would choose to deal with. I'd prefer that the binding / > implementation providers parse the list of required intents and if there > are > the ones that they 'mayProvide' then suitable PolicySets should be added > to > the list of PolicySets. Ofcourse the corresponding PolicyHandlers should > also be defined and registered. This I feel provide uniformity and > extensibility to how policy handling plugs into extensions. > Intents in the 'mayProvides' list don't require policy sets. > > > > > 3. I'm also wondering whether it should be possible to register a > > PolicyHandler that always gets control regardless of what intents or > > policy > > sets are specified. This might be to implement some default behavior. > > I'm > > thinking of transactions here. The transaction spec says that the > runtime > > can provide one of the intents by default, but the choice of default is > > implementation-specific. There's no way to declare the default intent > to > > the policy framework today, so there's no choice but to give control to > > the > > transaction handler and let it figure it out. > > > > This sounds like something that is left for bindings / implementations to > deal with, in the way they might choose to. As I had mentioned in the > previous point a cleaner way would be for binding /implementation > providers > to verify if a default intent needs to be in force and add the > corresponding > PolicySet to the list of policysets. For example, if an implementation > provider parses the requiredIntents and discovers nothing in there related > to transaction intent type, then it could add the default transaction > PolicySet to the list of policysets. Makes sense or am I missing your > point? > Intents in the 'mayProvides' list don't require policy sets. > > > > 4. The PolicyHandler is provided the target Operation and Message. I > > wonder if that's enough context. Can the handler works its way "up" the > > model (component, etc) if it needs to? > > > > I suppose what is 'provided' to the handler depends on the implementation > or binding extension and from where it decides to call the handlers. If > the > handlers are called from the interceptors they can provide
Re: PolicyHanders
Hi Greg, Thanks for your observations / suggestions. Please see my comments inline. I apologize for making them lengthy in the hope that it would trigger more discussions. - Venkat On Feb 7, 2008 1:33 AM, Greg Dritschler <[EMAIL PROTECTED]> wrote: > I have been looking at the PolicyHandler support for Java implementations > and overall I like the direction this is going. I have some comments > about > it. > > 1. If a given component/operation has multiple policy sets that are > handled > by the same PolicyHandler, it appears that one PolicyHandler is created > for > each such policy set. I wonder if it wouldn't be better to call a given > PolicyHandler only once per invocation and give it the full list of policy > sets it handles. This may be more efficient depending on the policy (the > handler may be able to optimize/combine policies, and it may be able to > find > conflicts that are beyond the powers of the policy framework). Just to clarify, I did start with PolicyHanlder types classified against the PolicySet name, but later discovered that this is not scalable. Today, the PolicyHandler types are classified against the PolicyModel that they can understand (i.e. WS-Policy or some customer model) and the Intent that they can deal with (i.e authentication or transaction). I feel we might also have to add one more classifier that denotes the QoS infrastructure that the PolicyHandler is capable of working with. While the policy model and intent can be extracted for a PolicySet to find the appropriate PolicyHandler, I am not sure where we can encapsulate this 'specific infrastructure' information. So, if it does happen that we have mutliple PolicySets on a wire that point to the same PolicyHandler type, yes it makes sense to do what you suggest. Infact, this turns out to be a necessity for example when we want to configure the Axis2 Config Parameters for binding.ws to say enable authentication AND integrity where each of these could have their own PolicySets. 2. Some intents can be provided without requiring a policy set (these are > the intents in the implementation's mayProvides list). Although the > PolicyHandler gets registered for an intent, it appears it is only driven > if > the intent is satisfied by a policy set. It would be nice if it could be > driven if the intent appears in the mayProvides list too. +1. At the present moment this is left to how implementation and binding extensions would choose to deal with. I'd prefer that the binding / implementation providers parse the list of required intents and if there are the ones that they 'mayProvide' then suitable PolicySets should be added to the list of PolicySets. Ofcourse the corresponding PolicyHandlers should also be defined and registered. This I feel provide uniformity and extensibility to how policy handling plugs into extensions. > > 3. I'm also wondering whether it should be possible to register a > PolicyHandler that always gets control regardless of what intents or > policy > sets are specified. This might be to implement some default behavior. > I'm > thinking of transactions here. The transaction spec says that the runtime > can provide one of the intents by default, but the choice of default is > implementation-specific. There's no way to declare the default intent to > the policy framework today, so there's no choice but to give control to > the > transaction handler and let it figure it out. > This sounds like something that is left for bindings / implementations to deal with, in the way they might choose to. As I had mentioned in the previous point a cleaner way would be for binding /implementation providers to verify if a default intent needs to be in force and add the corresponding PolicySet to the list of policysets. For example, if an implementation provider parses the requiredIntents and discovers nothing in there related to transaction intent type, then it could add the default transaction PolicySet to the list of policysets. Makes sense or am I missing your point? > 4. The PolicyHandler is provided the target Operation and Message. I > wonder if that's enough context. Can the handler works its way "up" the > model (component, etc) if it needs to? > I suppose what is 'provided' to the handler depends on the implementation or binding extension and from where it decides to call the handlers. If the handlers are called from the interceptors they can provide any state that is available to them. Or if there is context information that is not going to change across service calls then such information could be initialized into PolicyHandlers as part of the 'setup' call. > 5. It might be nice for the PolicyHandlingInterceptor constructor to make > an initialization call to the handler so it can do some setup. > For the JavaImplementation extension this is done in the JavaPolicyHandlingRuntimeWireProcessor that creates these PolicyHandlers and injects them into the interceptor. The 'setu
Re: PolicyHanders
Hi, I don't enough knowledge to cover all of your points, but let me give a try. See my comments inline. Thanks, Raymond - Original Message - From: "Greg Dritschler" <[EMAIL PROTECTED]> To: "tuscany-dev" Sent: Wednesday, February 06, 2008 12:03 PM Subject: PolicyHanders I have been looking at the PolicyHandler support for Java implementations and overall I like the direction this is going. I have some comments about it. I think we should converge PolicyHandler into the Interceptor framework. The current PolicyHandler interface is not well-typed. The interceptor pattern can deal with the pre/post-invoke already. Maybe the PolicyInterceptor can extend from the Interceptor interface so that it can receive the policy-related metadata. 1. If a given component/operation has multiple policy sets that are handled by the same PolicyHandler, it appears that one PolicyHandler is created for each such policy set. I wonder if it wouldn't be better to call a given PolicyHandler only once per invocation and give it the full list of policy sets it handles. This may be more efficient depending on the policy (the handler may be able to optimize/combine policies, and it may be able to find conflicts that are beyond the powers of the policy framework). +1. 2. Some intents can be provided without requiring a policy set (these are the intents in the implementation's mayProvides list). Although the PolicyHandler gets registered for an intent, it appears it is only driven if the intent is satisfied by a policy set. It would be nice if it could be driven if the intent appears in the mayProvides list too. If the intent matches one of the mayProvides, it hints that the implementation/binding provider can honor it without adding explicit interceptors. 3. I'm also wondering whether it should be possible to register a PolicyHandler that always gets control regardless of what intents or policy sets are specified. This might be to implement some default behavior. I'm thinking of transactions here. The transaction spec says that the runtime can provide one of the intents by default, but the choice of default is implementation-specific. There's no way to declare the default intent to the policy framework today, so there's no choice but to give control to the transaction handler and let it figure it out. Should the runtime populate the default intents in the model so that policy handlers can be triggered in these cases? Another way is to use the RuntimeWireProcessor to add an interceptor for the defaults. 4. The PolicyHandler is provided the target Operation and Message. I wonder if that's enough context. Can the handler works its way "up" the model (component, etc) if it needs to? The Message already has the to/from EndpointReference. It should provide enough context you need. 5. It might be nice for the PolicyHandlingInterceptor constructor to make an initialization call to the handler so it can do some setup. Maybe init/destory methods instead of constructor. 6. If policy sets are attached to the operation, JavaPolicyHandlingRuntimeWireProcessor uses the handlers associated with those policy sets instead of the handlers associated with the component level. I don't think this is completely right. It should be possible to use a policy from one domain (say security) for a given operation while using a policy for another domain (say transactions) at the component level. The section of the Policy spec dealing with operation-level attachment for implementations does not address this point specifically. However the section on operation-level attachment for bindings does offer this: "...operation-level policySets override corresponding policySets specified for the binding (where a 'corresponding' policySet @provides at least one common intent)." As I said, we should not tie the policy handing to the java component impl. 7. JavaPolicyHandlingRuntimeWireProcessor adds the interceptor to the end of the invocation chain. In the case of chains for oneway operations, this places the interceptor after the NonBlockingInterceptor. This may present problems for policy handlers such as transactions that are sensitive to running on the thread of execution. It's a bit tricky. For wires into a service, the handler would want to be called after the NonBlockingInterceptor has switched threads. For wires into a reference, the handler would want to be before the NonBlockingInterceptor switches off to another thread. Please chime in the "Adding phase-based ordering support for invokers/interceptors in the InvocationChain" Thread I started to see if the phase-based ordering can help. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
PolicyHanders
I have been looking at the PolicyHandler support for Java implementations and overall I like the direction this is going. I have some comments about it. 1. If a given component/operation has multiple policy sets that are handled by the same PolicyHandler, it appears that one PolicyHandler is created for each such policy set. I wonder if it wouldn't be better to call a given PolicyHandler only once per invocation and give it the full list of policy sets it handles. This may be more efficient depending on the policy (the handler may be able to optimize/combine policies, and it may be able to find conflicts that are beyond the powers of the policy framework). 2. Some intents can be provided without requiring a policy set (these are the intents in the implementation's mayProvides list). Although the PolicyHandler gets registered for an intent, it appears it is only driven if the intent is satisfied by a policy set. It would be nice if it could be driven if the intent appears in the mayProvides list too. 3. I'm also wondering whether it should be possible to register a PolicyHandler that always gets control regardless of what intents or policy sets are specified. This might be to implement some default behavior. I'm thinking of transactions here. The transaction spec says that the runtime can provide one of the intents by default, but the choice of default is implementation-specific. There's no way to declare the default intent to the policy framework today, so there's no choice but to give control to the transaction handler and let it figure it out. 4. The PolicyHandler is provided the target Operation and Message. I wonder if that's enough context. Can the handler works its way "up" the model (component, etc) if it needs to? 5. It might be nice for the PolicyHandlingInterceptor constructor to make an initialization call to the handler so it can do some setup. 6. If policy sets are attached to the operation, JavaPolicyHandlingRuntimeWireProcessor uses the handlers associated with those policy sets instead of the handlers associated with the component level. I don't think this is completely right. It should be possible to use a policy from one domain (say security) for a given operation while using a policy for another domain (say transactions) at the component level. The section of the Policy spec dealing with operation-level attachment for implementations does not address this point specifically. However the section on operation-level attachment for bindings does offer this: "...operation-level policySets override corresponding policySets specified for the binding (where a 'corresponding' policySet @provides at least one common intent)." 7. JavaPolicyHandlingRuntimeWireProcessor adds the interceptor to the end of the invocation chain. In the case of chains for oneway operations, this places the interceptor after the NonBlockingInterceptor. This may present problems for policy handlers such as transactions that are sensitive to running on the thread of execution. It's a bit tricky. For wires into a service, the handler would want to be called after the NonBlockingInterceptor has switched threads. For wires into a reference, the handler would want to be before the NonBlockingInterceptor switches off to another thread.
