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)
> "/>
> <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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
