I'm sorry for yet another note... but I realize that what I had in mind
wouldn't happen without some additional logic in
DataBindingRuntimeWireProcessor.
What I had in mind (I didn't really) explain, was to use the presence of
the
default, JavaBeans DB at the binding level to disable data
transformation.
That is... instead of saying the SDO DB on (1) is different from the
JavaBeans DB (3), so a transform is needed......... we would instead say,
the JavaBeans DB is a superset (i.e. we can cast to from) the SDO DB...
so
no transform is needed.
Am I making sense? Is there already another way to do what I just
proposed?
Scott
On 7/6/07, Scott Kurz <[EMAIL PROTECTED]> wrote:
>
> After thinking on this a bit, I wonder if I was confusing things by
> wrongly coupling the question of Java vs. WSDL interface with the
> choice
of
> DataBinding.
>
> Say I wanted the java.lang.Object DB for my binding. I could still
set
> this up on the binding-level operation objects, whether I had a Java or
WSDL
> interface.
>
> It's not as if by using a WSDL interface I'm tied to using something
like
> an AXIOM DB.
>
> Right?
>
> So I guess this is still a simple pattern binding impls could use.
>
> A separate issue though is the question of whether we should be able to
> clone (2) at the level of (3) instead of writing to the same
object. I
> think these used
> to be clonable...
>
> Scott
>
>
> On 7/6/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> >
> > On 7/6/07, Scott Kurz <[EMAIL PROTECTED]> wrote:
> > >
> > > Raymond,
> > >
> > > Your proposal makes sense to me.
> > >
> > > It seems like a nice simplification to view the component-level
> > > intf
> > (2)
> > > as
> > > existing only for testing
> > > wire-mappability of interfaces and to view the "componentType
> > > intf",
> > (or
> > > impl-level intf) (1) and
> > > the binding intf (3) as the interfaces with databindings associated
> > with
> > > them.
> > >
> > > Would you agree one consequence of such a change, though, would be
> > that
> > > binding impl like the default binding impl whose method impl:
> > >
> > > RuntimeSCABindingProvider.getBindingInterfaceContract()
> > >
> > > merely delegates to the
> > >
> > > RuntimeComponentReference.getInterfaceContract ()
> > >
> > > would have to be reconsidered?
> > >
> > > This code setting up interface (3) on the binding might prefer to
copy
> > > interface (1) rather than (2), maybe for the specific purpose of
> > wanting
> > > to
> > > use a Java, not a WSDL interface.
> > >
> > > Actually the code as written today does not always do the job of
> > setting
> > > up
> > > a Java interface (if that is the goal), as the component could have
a
> > > Composite impl with WSDL interface on the Composite-level
ref/service.
> > > The
> > > code setting up the binding intf (3) might really want a Java
> > > atomic
> > > component impl's Java intf to percolate up to be set on the
> > > binding.
> > > (Maybe a WSDL->Java conversion is the right thing to do here then).
> > >
> > > Anyway, I'm expanding the discussion a bit ...
> > >
> > > I need to think a bit to articulate in more detail some questions I
> > still
> > > have ... so I'll stop here.
> > > Thanks,
> > > Scott
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > You've thought about this more than I have.. but
> > >
> > >
> > >
> > > On 7/5/07, Raymond Feng < [EMAIL PROTECTED]> wrote:
> > > >
> > > > Hi, Scott.
> > > >
> > > > Thank you for bringing up this issue. I have been thinking about
> > this
> > > for
> > > > a
> > > > while:-).
> > > >
> > > > There are three interfaces in the picture:
> > > >
> > > > 1) [componentType.reference.interface]: The java interface of the
> > > > reference
> > > > defined by the component type, which is introspected from the
> > @Reference
> > > > annotation on the java class
> > > > (GreetingComponentImpl). This is the effective interface what the
> > > outbound
> > > > call made. For example,
> > > >
> > > > Reference declaration:
> > > > @Reference
> > > > protected HelloWorld helloWorldService;
> > > >
> > > > Reference usage:
> > > > helloWorldService.hello(...);
> > > >
> > > > 2) [component.reference.interface ]: The wsdl interface that
> > overrides
> > > the
> > > > reference for "MyComponent". This interface is for purpose of
> > wiring. In
> > > > most cases, the interface for
> > > > the reference on the component is the same as the one for the
> > reference
> > > on
> > > > the component type.
> > > >
> > > > 3) [component.reference.binding.interface] The wsdl interface
> > > > that
> > the
> > > WS
> > > > binding uses, i.e., the portType for
> > > HelloWorldService/HelloWorldSoapPort.
> > > > This is the effective interface that binding layer expects to
> > receive
> > > > data.
> > > >
> > > > The data transformation should happen between the interface 1 and
> > > > interface
> > > > 3 (instead of 2 and 3).
> > > >
> > > > The same happens to the service side. If we have a java
> > > > component,
> > the
> > > > interface for the service on the component type is a java
> > > interface/class.
> > > > When the component service is further typed with interface.wsdl,
> > then
> > > the
> > > > interface for the service on the component is a WSDL interface.
But
> > the
> > > > one
> > > > for the component type should be used for data transformation
> > purposes.
> > > >
> > > > So I think the solution is to use the interface for reference on
the
> > > > component type to perform the data transformation.
> > > >
> > > > Do you agree?
> > > >
> > > > Thanks,
> > > > Raymond
> > > >
> > > > ----- Original Message -----
> > > > From: "Scott Kurz" <[EMAIL PROTECTED]>
> > > > To: < [email protected]>
> > > > Sent: Tuesday, July 03, 2007 4:40 AM
> > > > Subject: Problems using WSDL interfaces together with DataBinding
> > (DB)
> > > > framework
> > > >
> > > >
> > > > > Say I use SCDL like (for WS binding):
> > > > >
> > > > > <component name="MyComponent">
> > > > > <implementation.java class="
> > > > > test.sca.w2j.ws.static_sdo.helloworld.GreetingComponentImpl "/>
> > > > > <reference name="helloWorldService">
> > > > > <interface.wsdl interface="
> > > > >
> > > >
> > >
> >
http://w2j.sca.soa.ws/test/hw-ws-static-sdo-2parm#wsdl.interface(HelloWorld)
<
http://w2j.sca.soa.ws/test/hw-ws-static-sdo-2parm#wsdl.interface%28HelloWorld%29
>
> > > > > "/>
> > > > > <binding.ws wsdlElement="
> > > > >
> > > >
> > >
http://w2j.sca.soa.ws/test/hw-ws-static-sdo-2parm#wsdl.port(HelloWorldService/HelloWorldSoapPort)
> >
> > <
http://w2j.sca.soa.ws/test/hw-ws-static-sdo-2parm#wsdl.port%28HelloWorldService/HelloWorldSoapPort%29
>
> > > > > "/>
> > > > > </reference>
> > > > > </component>
> > > > >
> > > > > If I rely on the DefaultWSDLInterfaceIntrospector to build the
> > > Operation
> > > > > model objects for the Component-level Interface, they will be
> > created
> > > > with
> > > > > a
> > > > > null DB, because of the null in:
> > > > >
> > > > > WSDLOperation op = new WSDLOperation(wsdlFactory, wsdlOp,
> > > > > inlineSchemas,
> > > > > null, resolver);
> > > > >
> > > > > This leads to the following exception as I try to convert
between
> > the
> > > > null
> > > > > DB at the component level and the AXIOM DB set by the WS
> > > > > binding
> > at
> > > the
> > > > > binding level.
> > > > >
> > > > > org.apache.tuscany.sca.databinding.TransformationException: No
> > wrapper
> > > > > handler is provided for databinding: null
> > > > > at
> > > > >
> > > >
> > >
> >
org.apache.tuscany.core.databinding.transformers.Input2InputTransformer.getWrapperHandler
> > > > > (Input2InputTransformer.java:204)
> > > > > at
> > > > >
> > > >
> > >
> >
org.apache.tuscany.core.databinding.transformers.Input2InputTransformer.transform
> > > > > (Input2InputTransformer.java:112)
> > > > > at
> > > > >
> > > >
> > >
> >
org.apache.tuscany.core.databinding.transformers.Input2InputTransformer.transform
> > > > > (Input2InputTransformer.java:53)
> > > > > at
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate
> > (
> > > > > MediatorImpl.java:77)
> > > > > at
> > > > >
> > > >
> > >
> >
org.apache.tuscany.core.databinding.wire.DataTransformationInteceptor.transform
> > > > > (DataTransformationInteceptor.java:168)
> > > > >
> > > > >
> > > > > So I tried setting up the Axiom DB instead from
> > > > > DefaultWSDLInterfaceIntrospector on the
component-level-interface
> > > > > Operation
> > > > > objects loaded from <interface.wsdl> definitions. (Note I had
to
> > > > > workaround
> > > > > JIRA TUSCANY-1342 with the fix I suggested).
> > > > >
> > > > > This change has the side effect, however, of causing
> > > > > DataTransformationInteceptor to not get set up when I'm using
the
> > WS
> > > > > binding, since the WS binding uses the Axiom DB and since the
> > > > > DataBindingRuntimeWireProcessor won't create the interceptor in
> > the
> > > case
> > > > > the
> > > > > DBs match.
> > > > >
> > > > > Does someone have a better idea of how to make the DataBinding
> > > framework
> > > > > do
> > > > > what I want here?
> > > > >
> > > > > Looking at this I'm wondering... did we lose a DB "layer" in
> > > > > the
> > move
> > > to
> > > > > 1.0-spec code? Before we had component-level, composite-level
> > and
> > > > > binding-level. Now we have only component-level and
> > binding-level.
> > > > >
> > > > > Is a DB Interceptor needed to transform between the impl level
and
> > the
> > > > > component level in a case like this where you have a Java impl
w/
> > SDO
> > > DB
> > > > > but
> > > > > you put <interface.wsdl> on the component-level service/ref?
> > > > >
> > > > > (One might ask what is the point of using <interface.wsdl> at
all
> > in a
> > > > > case
> > > > > like this, since the WS binding can convert between different,
> > > > compatible
> > > > > Java interfaces on either side. Well, I'm looking ahead to
the
> > time
> > > > > when
> > > > > we have a wire between a ref w/ WS binding and a service w/ WS
> > binding
> > > > and
> > > > > <
> > > > > interface.wsdl> would allow us to easily determine interface
> > > > compatibility
> > > > > on the wire.)
> > > > >
> > > > > Scott
> > > > >
> > > >
> > > >
> > > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > > >
> > >
> > I'm not sure I have much to offer to this conversation just yet but
I'm
> > interested in the context of making the SCA Binding a first class
> > citizen in
> > order to support both local and remote invocation scenarios. As Scott
> > says
> > the way it sits as the moment is that it follows the original
implement
> > and
> > defers to interface [2] when asked for the interface contract.
> >
> > In the case where no binding has been specified the suggestion that
> > interface [1] should provide the interface contract fits well. Does
the
> > model already make this assumption?
> >
> > Simon
> >
>
>
