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