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 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 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 ? > > > > I overlooked the setup() method. It is what I had in mind. > > > > > > > > > > > 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 ? > > > > I may be wrong but I thought that intents and policy sets are propagated > down the XML hierarchy until you get to the implementation. They are not > propagated to operations. The operation-level attachments are supposed to > override the implementation-level, but only for the intents that are in > common. > My understanding has been that intents on implementation apply to all operations of the implementation's service in general in addition to what may be defined on the operation itself. When there is something defined on the operation and its of the same type as that in the parent then the one with the operation overrides. Isn't that what you also mean ? > > > > > > > > > > > 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. > > >
