[
https://issues.apache.org/jira/browse/TUSCANY-3894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13072148#comment-13072148
]
Scott Kurz commented on TUSCANY-3894:
-------------------------------------
I checked in some more changes here, so let me explain.
>From the runtime side, in r1151632, I refactored the local part of
>sca-binding-runtime so that the exact details of the data transform are
>extensible.
I'm creating a new interface, BindingSCATransformer which I'll implement to
handle the transform details.
My thought is that the base portion of the binding will do things like
calculate whether to do the pass-by-reference optimization and establish other
aspects of the invoker/interceptor chain. This will be handled in
DefaultLocalSCAReferenceBindingProvider, which will also compute the WSDL
contract, in case the transform needs it, as well as return the
ComponentTypeRefIC to disable the DataTransformationInterceptor. So we're
always initiating data transform from the binding, not via
DataTransformationInterceptor on the wire, just to reiterate.
In my scheme, the BindingProviderFactory impl will create a ref binding
provider which will potentially extend the base
DefaultLocalSCAReferenceBindingProvider by providing its own
BindingSCATransformer (and possibly a different databinding then the DOM
default one I'm using).
There are now two provider factories, each resulting in a different
BindingSCATransformer being used.
The first, the default, maintains the current behavior we're used to.
Notably, it:
- uses Mediator.copyXXX rather than Mediator.mediateXXX, which notably does
not use the JAX-WS wrappers
- has RMI-like referential integrity for parameters (see earlier comments)
- for POJOs, preferes Java serialization (if java.io.Serializable), then
JAXB/XML serialization
The second is an XML-centric databinding. Some notes:
- It's built via pointing to XMLWFLocalSCABindingProviderFactory in the
extension point, which builds the XMLWFBindingSCATransformer.
- relies on building a WSDL InterfaceContract to be used along with
Mediator.mediateXXX
- uses a DOM databinding (since there's been a move to avoid AXIOM if
possible), but this could easily be switched in another impl with little code
- The XMLWFLocalSCAReferenceBindingProvider actually extends the
DefaultLocalSCAReferenceBindingProvider, the provider in the first, default
impl.
I would like to add a weighting to the various binding provider factories, and
ideally polish things up a bit. However, there are a couple more JIRAs I need
to open after noticing some side effects, and it seemed easiest to have
something concrete in the trunk to refer to.
So by committing this code I have:
- enabled the use of separate databindings across client/service
- allowed extension with reuse of the PBR calculation.
Scott
> Binding.sca local behavior: copy vs. mediate, same-databinding assumption
> --------------------------------------------------------------------------
>
> Key: TUSCANY-3894
> URL: https://issues.apache.org/jira/browse/TUSCANY-3894
> Project: Tuscany
> Issue Type: Improvement
> Components: SCA Java Runtime
> Affects Versions: Java-SCA-2.x
> Reporter: Scott Kurz
> Assignee: Scott Kurz
> Priority: Minor
> Fix For: Java-SCA-2.0
>
> Attachments: 3894.patch, 3894.tests.patch
>
>
> As discussed in: https://issues.apache.org/jira/browse/TUSCANY-3884
> the binding-sca-runtime code seems to assume that the reference/service sides
> share a common databinding, which might not be a desirable limitation.
> Also the object reference graph of copy vs. mediate seems to be different,
> which might not be preferable either.
> Just working on some tests now before commenting further, however I wanted to
> open this up to move the discussion out of the 3884 JIRA, to avoid confusion
> as this is a separate issue from simply adding the ability to delegate.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
