You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Scott Kurz <sc...@gmail.com> on 2007/07/03 13:40:39 UTC

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)
"/>
            <binding.ws wsdlElement="
http://w2j.sca.soa.ws/test/hw-ws-static-sdo-2parm#wsdl.port(HelloWorldService/HelloWorldSoapPort)
"/>
        </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

Re: Problems using WSDL interfaces together with DataBinding (DB) framework

Posted by Raymond Feng <en...@gmail.com>.
Hi,

Using the componentType.reference.interface as the source should be done by 
the databinding framework. The binding provider needs to set the expected 
interface contract (if different from the reference.interface) for the 
transport layer.

Thanks,
Raymond

----- Original Message ----- 
From: "Rashmi Hunt" <ra...@gmail.com>
To: <tu...@ws.apache.org>
Sent: Friday, July 06, 2007 9:24 AM
Subject: Re: Problems using WSDL interfaces together with DataBinding (DB) 
framework


> Raymond
>
> Referring back to the solution you suggested in your previous mail
>
> "So I think the solution is to use the interface for reference on the
> component type to perform the data transformation."
>
> How do we use interface for reference on the componentType
> to perform the data transformation?  Is this something each binding
> which needs to support WSDL interface needs to do or something
> Tuscany databinding framework needs to support?
>
> Regards
> Rashmi
>
> On 7/6/07, Scott Kurz <sc...@gmail.com> wrote:
>>
>> 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 <sc...@gmail.com> 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 <si...@googlemail.com> wrote:
>> > >
>> > > On 7/6/07, Scott Kurz <sc...@gmail.com> 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 < enjoyjava@gmail.com> 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" <sc...@gmail.com>
>> > > > > To: < tuscany-dev@ws.apache.org>
>> > > > > 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: tuscany-dev-unsubscribe@ws.apache.org
>> > > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> > > > >
>> > > > >
>> > > >
>> > > 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
>> > >
>> >
>> >
>>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Problems using WSDL interfaces together with DataBinding (DB) framework

Posted by Rashmi Hunt <ra...@gmail.com>.
Raymond

Referring back to the solution you suggested in your previous mail

"So I think the solution is to use the interface for reference on the
component type to perform the data transformation."

How do we use interface for reference on the componentType
to perform the data transformation?  Is this something each binding
which needs to support WSDL interface needs to do or something
Tuscany databinding framework needs to support?

Regards
Rashmi

On 7/6/07, Scott Kurz <sc...@gmail.com> wrote:
>
> 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 <sc...@gmail.com> 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 <si...@googlemail.com> wrote:
> > >
> > > On 7/6/07, Scott Kurz <sc...@gmail.com> 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 < enjoyjava@gmail.com> 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" <sc...@gmail.com>
> > > > > To: < tuscany-dev@ws.apache.org>
> > > > > 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: tuscany-dev-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > > >
> > > > >
> > > >
> > > 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
> > >
> >
> >
>

Re: Problems using WSDL interfaces together with DataBinding (DB) framework

Posted by Raymond Feng <en...@gmail.com>.
Hi, Scott.

JavaBeans Databinding is not really a superset of SDO Databinding. For 
example, we might a CustomerSDO (DataObject) and a CustomerBean (JavaBean). 
Transformation is required to convert CustomerSDO into CustomerBean.

There might be another way to tell the runtime that no transformation is 
required: Set the databinding to "null". And then change the code to treat 
null databinding as an indication of no transformation.

Thanks,
Raymond

----- Original Message ----- 
From: "Scott Kurz" <sc...@gmail.com>
To: <tu...@ws.apache.org>
Sent: Friday, July 06, 2007 8:51 AM
Subject: Re: Problems using WSDL interfaces together with DataBinding (DB) 
framework


> 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 <sc...@gmail.com> 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 <si...@googlemail.com> wrote:
>> >
>> > On 7/6/07, Scott Kurz <sc...@gmail.com> 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 < enjoyjava@gmail.com> 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" <sc...@gmail.com>
>> > > > To: < tuscany-dev@ws.apache.org>
>> > > > 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: tuscany-dev-unsubscribe@ws.apache.org
>> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> > > >
>> > > >
>> > >
>> > 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
>> >
>>
>>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Problems using WSDL interfaces together with DataBinding (DB) framework

Posted by Scott Kurz <sc...@gmail.com>.
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 <sc...@gmail.com> 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 <si...@googlemail.com> wrote:
> >
> > On 7/6/07, Scott Kurz <sc...@gmail.com> 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 < enjoyjava@gmail.com> 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" <sc...@gmail.com>
> > > > To: < tuscany-dev@ws.apache.org>
> > > > 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: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > > >
> > >
> > 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
> >
>
>

Re: Problems using WSDL interfaces together with DataBinding (DB) framework

Posted by Scott Kurz <sc...@gmail.com>.
No, it looks like the InterfaceImpl types no longer implement Cloneable
though I remember the old version of this function did support clone().
Scott.

On 7/6/07, Raymond Feng <en...@gmail.com> wrote:
>
> Hi,
>
> I think the clone() has already been supported.
>
> Thanks,
> Raymond
>
> ----- Original Message -----
> From: "Scott Kurz" <sc...@gmail.com>
> To: <tu...@ws.apache.org>
> Sent: Friday, July 06, 2007 8:41 AM
> Subject: Re: Problems using WSDL interfaces together with DataBinding (DB)
> framework
>
>
> > 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 <si...@googlemail.com> wrote:
> >>
> >> On 7/6/07, Scott Kurz <sc...@gmail.com> 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 <en...@gmail.com> 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" <sc...@gmail.com>
> >> > > To: <tu...@ws.apache.org>
> >> > > 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)
> >> > > > "/>
> >> > > >            <binding.ws wsdlElement="
> >> > > >
> >> > >
> >> >
> >>
> http://w2j.sca.soa.ws/test/hw-ws-static-sdo-2parm#wsdl.port(HelloWorldService/HelloWorldSoapPort)
> >> > > > "/>
> >> > > >        </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: tuscany-dev-unsubscribe@ws.apache.org
> >> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> > >
> >> > >
> >> >
> >> 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
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>

Re: Problems using WSDL interfaces together with DataBinding (DB) framework

Posted by Raymond Feng <en...@gmail.com>.
Hi,

I think the clone() has already been supported.

Thanks,
Raymond

----- Original Message ----- 
From: "Scott Kurz" <sc...@gmail.com>
To: <tu...@ws.apache.org>
Sent: Friday, July 06, 2007 8:41 AM
Subject: Re: Problems using WSDL interfaces together with DataBinding (DB) 
framework


> 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 <si...@googlemail.com> wrote:
>>
>> On 7/6/07, Scott Kurz <sc...@gmail.com> 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 <en...@gmail.com> 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" <sc...@gmail.com>
>> > > To: <tu...@ws.apache.org>
>> > > 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)
>> > > > "/>
>> > > >            <binding.ws wsdlElement="
>> > > >
>> > >
>> >
>> http://w2j.sca.soa.ws/test/hw-ws-static-sdo-2parm#wsdl.port(HelloWorldService/HelloWorldSoapPort)
>> > > > "/>
>> > > >        </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: tuscany-dev-unsubscribe@ws.apache.org
>> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> > >
>> > >
>> >
>> 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
>>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Problems using WSDL interfaces together with DataBinding (DB) framework

Posted by Scott Kurz <sc...@gmail.com>.
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 <si...@googlemail.com> wrote:
>
> On 7/6/07, Scott Kurz <sc...@gmail.com> 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 <en...@gmail.com> 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" <sc...@gmail.com>
> > > To: <tu...@ws.apache.org>
> > > 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)
> > > > "/>
> > > >            <binding.ws wsdlElement="
> > > >
> > >
> >
> http://w2j.sca.soa.ws/test/hw-ws-static-sdo-2parm#wsdl.port(HelloWorldService/HelloWorldSoapPort)
> > > > "/>
> > > >        </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: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> >
> 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
>

Re: Problems using WSDL interfaces together with DataBinding (DB) framework

Posted by Simon Laws <si...@googlemail.com>.
On 7/6/07, Scott Kurz <sc...@gmail.com> 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 <en...@gmail.com> 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" <sc...@gmail.com>
> > To: <tu...@ws.apache.org>
> > 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)
> > > "/>
> > >            <binding.ws wsdlElement="
> > >
> >
> http://w2j.sca.soa.ws/test/hw-ws-static-sdo-2parm#wsdl.port(HelloWorldService/HelloWorldSoapPort)
> > > "/>
> > >        </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: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
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

Re: Problems using WSDL interfaces together with DataBinding (DB) framework

Posted by Scott Kurz <sc...@gmail.com>.
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 <en...@gmail.com> 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" <sc...@gmail.com>
> To: <tu...@ws.apache.org>
> 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)
> > "/>
> >            <binding.ws wsdlElement="
> >
> http://w2j.sca.soa.ws/test/hw-ws-static-sdo-2parm#wsdl.port(HelloWorldService/HelloWorldSoapPort)
> > "/>
> >        </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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>

Re: Problems using WSDL interfaces together with DataBinding (DB) framework

Posted by Raymond Feng <en...@gmail.com>.
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" <sc...@gmail.com>
To: <tu...@ws.apache.org>
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)
> "/>
>            <binding.ws wsdlElement="
> http://w2j.sca.soa.ws/test/hw-ws-static-sdo-2parm#wsdl.port(HelloWorldService/HelloWorldSoapPort)
> "/>
>        </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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org