Hi, Jim.
Thank you for the quick response. Please see my comments inline.
Raymond
----- Original Message -----
From: "Jim Marino" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Saturday, August 19, 2006 10:29 AM
Subject: Re: adding an interceptor
On Aug 19, 2006, at 9:52 AM, Raymond Feng wrote:
Hi,
I gave a try and got an interceptor added to the invocation using the
policy registry strategy. I reached a step (with some hacks/ workarounds)
that the interceptors are able to be invoked with the Echo binding
sample.
Here are a list of questions (some of them have been mentioned in Jim's
note) which will help me move forward.
1) We have a basic PolicyRegistry but it's not triggered to invoke the
policy builders by the core. I hacked JDKWireService to activate it
since I'm seeing some TODOs related to policy handling in the code. I
don't think it's the right place. Maybe it should be in the connector?
It only needs to be added as a system service in the SCDL and autowired
to the wire service. Did you try that?
Well, my builders (which in turn add interceptors/handlers) can be added to
the policy registry which is created as a system service. The problem I had
is that even though the builders were registered with the registry, they
were not invoked since there's no code asked the policy registry to do so.
2) I had to change the InvocationChain SPI so that I can added the
interceptor before the InvokerInterceptor. Please see my post
(http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/
200608.mbox/[EMAIL PROTECTED]).
This is a hack related to not having the policy builder. If you fix 1, I
believe this is not necessary.
Based on the my comment above, we still need to fix it. Or are you saying
the InvokerInterceptor should be handled as part of the policy?
3) How does a policy builder receive the context (for example, the
CompositeComponent and other policy-related stuff) and make them
available to the interceptors/handlers it contributes? I agree with Jim
that the SPI needs more work.
That would be off reference definition and service definition. I can't
remember if policy has a concept of a component-wide policy that affects
policy decorations on things like references. If so, we may need to pass
the component definition as well. Do you know offhand?
It seems that the SCA spec (the policy appendix has not been updated to 0.96
level) always talk about interaction policies for bindings and implmentation
policies for impls. I assume policy can apply to
service/reference/implementation.
I'm having second thoughts about moving the policy building into the
connector phase. I think that would mean we loose the separation of
runtime artifacts from the model as composite components would have
knowledge of the former, leading to something that is probably very
messy. Also, thinking about it more, what I think you are trying to do is
an analysis of a wire which is tightly coupled to source and target,
while policy is more "loosely" coupled in that it just prescribes
statements about the nature of a source or target without specific
knowledge of both. As a preliminary thought, what if we added the ability
to decorate InvocationChain with extensibility elements that were added
by a policy builder. Then, in the connect phase, we have "optimizers"
which come along and can insert or subtract additional interceptors
before the connect is made? I'm not sure this is the right approach but
do you agree on the problem propagating the model would cause?
I'm not promoting to pass the model down to the interceptor. Instead, just
to want to make sure the interceptor will have enough context to decide to
how to enforce the policy. For example, the DataBinding interceptor will
require the source DataType (as well as some databinding-speficic info) and
the target DataType to transform the data.
4) How do we decide that a policy interceptor/handler should be
activated for an invocation chain? I guess it's the policy builder's
repsonsibility and the decision will be made based on some metadata (for
example, the presence of SCDL for a given policy).
This would be done by the particular policy builder. An interceptor or
handler would never be introduced if it was not activated.
5) What's the ordering strategy for policy interceptors/handlers? Axis2
has the phase concept which we may steal.
There was a preliminary phase concept in the policy builder registry
which we should reconcile against Axis' concepts. Also, I'd be interested
in understanding Celtix in this respect as they have done a lot with
multiple transports. Dan, Jervis?
Also, in terms of ordering, we should have a system service that does a
sort called at the end. The default would be to do nothing an simply
return. This will allow people to plug in a programmatic sorter if
required since the phase approach doesn't always work.
Sounds good to me.
6) It seems now the policy can only apply to bound services and
references. Is it possible that we apply it for local wiring as well?
Sure we just need to plug in the policy builder.
Thanks,
Raymond
----- Original Message ----- From: "Jim Marino"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, August 08, 2006 7:18 PM
Subject: Re: adding an interceptor
Hi Matthew,
Sorry for the delay in answer, I've been swamped at work. This would
be great if you could jump in. Generally we have a pattern of using a
registry for various extensions (e.g. loaders, builders) that handle a
particular task in the runtime. An extension would be contributed as a
system service (implementation.system), and as it was initialized,
would register itself with the registry (the extension gains a pointer
to the registry by declaring an "autowire" to it - you may not be
familiar with this mechanism so I'm happy to explain if so). The
registry would then dispatch to the correct extension based on some
key. For example, with the SCDL loaders, the loader registry uses the
XML element name.
I was thinking the policy registry would function the same way. There
would be a registry that would track all of the policy extension
points, source and target policy "builders". These extension points
would be called to decorate either an inbound or outbound wire with
interceptors or handlers. We may also want to have the concept of
phases to help with ordering as well as a way for an extension
developer to plug in a class that can order interceptors/handlers
after all have been contributed to a wire.
Currently, there is a very primitive cut at the policy registry
(PolicyBuilderRegistryImpl) and policy builders (SourcePolicyBuilder
and TargetPolicyBuilder). As a start, perhaps you could start looking
at the current registry implementation and seeing what parts need
refactoring? I believe the API needs some work. For example, related
to the following methods on PolicyBuilderRegistry:
void buildSource(ReferenceDefinition referenceDefinition, OutboundWire
wire) throws BuilderException;
void buildTarget(ServiceDefinition serviceDefinition, InboundWire
wire) throws BuilderException;
we currently use a Java class and java.lang.Method to represent the
service interface and a service operation respectively. We need a
generic way to represent Services and associated metadata such as
asynchronicity and policy. There's an ongoing thread on that so we
should pick up the details there, I just wanted to call your attention
to it.
I imagine as you start to look at this, you will have questions on how
invocations flow, the relationship between inbound and outbound
chains, and how interceptors and handlers work. Can you start to have
a look at the registry and post questions as they arise?
Thanks,
Jim
On Aug 7, 2006, at 6:23 AM, Matthew Sykes wrote:
Jim,
I'd be interested in contributing to this but I'm not sure I know
exactly where to begin. If you're willing to spend a bit of time on
the Q&A necessary to describe the intended flow through the bindings,
wires invocation handlers, and policy handlers (using some of
Jeremy's presentation as a starting point), I'm in.
Thanks.
Jim Marino wrote:
Greg,
We don't have this finished yet but it would be a nice project for
someone to work on, particularly since it would involve figuring out
how we are going to support SCA policy. If you or someone else is
interested in tackling this (or part of it) let me know and I'll
help out.
Jim
On Aug 4, 2006, at 11:49 AM, Greg Dritschler wrote:
I am trying to understand how to add an interceptor to an
invocation chain.
It looks like at one point this was accomplished by a implementing a
TargetPolicyBuilder and registering it with the
PolicyBuilderRegistry.
However in the current code base it looks to me like the
PolicyBuilderRegistry is no longer instantiated. Is this broken or
has
this been replaced by some other mechanism?
Greg Dritschler
------------------------------------------------------------------
-- -
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-------------------------------------------------------------------
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
