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" <tuscany-dev@ws.apache.org>
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]
