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 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. > > > > > > 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. >
