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 'setup' call is there as part of the PolicyHandler interface for this purpose. I am open to evolving the PolicyHanlder model as we come across more usecases. Could you please share some if you have in this regard ? > > 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)." Isn't this taken care of as part of the PolicySet computations that we do on implementation and bindings ? Some that gets defined at the component level gets to be inherited by the implementation i.e. the implementation's list of PolicySets will include the one that is defined at the Component level. Or, am I not getting your point ? > > 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. > We are dealing with this more generally on another thread that Raymond has started related to the capability of ordering interceptors.
