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