Hi,
For the data transformation to be handled by a databinding interceptor,
let's assume we have the following case:
* The source side uses SDO.
<import.sdo location="xsd/customer.xsd"/>
int getCreditScore(@databinding.sdo(namespace="http://customer";
name="Customer")Customer customer);
* The target side uses JAXB.
int getCreditScore(@databinding.jaxb Customer customer);
Then the interceptor will require the following information:
1) DataType on the source side (SDO Customer)
2) A "commonj.sdo.TypeHelper" associated with the current composite that
will provide the SDO type system
3) DataType on the target side (JAXB Customer)
4) (some JAXB context for the JAXB Customer?)
Thanks,
Raymond
----- Original Message -----
From: "Jim Marino" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Saturday, August 19, 2006 5:24 PM
Subject: Re: adding an interceptor
On Aug 19, 2006, at 3:44 PM, Raymond Feng wrote:
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.
Right. I'm doing some changes there so I will add the invoke.
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?
The invoker interceptor should be done as the last thing by the builder
registry.
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.
That's why I think we need to decorate the invocation chain. Since you
need knowledge of *both* target and source, and policy requires knowledge
of one or the other, I don't think this should be done as part of policy.
I need to look into this more but I think there should be an optimization
step where data binding interceptors are introduced. This would come
after all policy is in place.
Can you tell me the information you need to propagate from source and
target?
so, 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.
O.K. I'll add that in.
---------------------------------------------------------------------
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]
