Hi, Thanks for sending out the note.
In addition to the concern that I raised against your commit log, can you explain why we need to do transformation for local sca binding? I assume that's for distributed sca binding. Raymond Feng Sent from my iPhone On Jul 27, 2011, at 7:51 PM, "Scott Kurz (JIRA)" <dev@tuscany.apache.org> wrote: > > [ > 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 > >
