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) > > > "/> > > > <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] > > > > > 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
