> - Databinding technology is not reflected in the service contract but  in\\
 > the implementation contract. For example, different component\\
 > implementations may choose different databinding technologies.  Currently,\\
 > we pass this information as part of Operation, which is  part of the\\
 > ServiceContract.
\\
I can see the following paths below with potentially different data\\
 contracts that require transformations:\\

1. component1.ref1 \--> component2.svc1
\\
    a) component1's implementation contract \--> component1.ref1's\\
 ServiceContract\\
     b) component1.ref1's ServiceContract \--> component2.svc1's\\
 ServiceContract\\
     c) component2.svc1's ServiceContract \--> component2's implementation\\
 contract\\

2. composite.service1 w/ binding1\\

    a) binding1's contract (mandated by the transport/protocol stack, for\\
 example, AXIOM for Axis2) \--> composite.service1 ServiceContract (by the\\
 interface definition under <service>)
\\
3. composite.reference1 w/ binding1\\

&nbsp;&nbsp;&nbsp; a) composite.reference1's ServiceContract (by the interface definition\\
 under the <reference>) \--> Composite reference's binding contract (mandated\\
 by the transport/protocol stack)\\

There are different cases:\\

1) Case 1: A "weak" interface implemented by a method expecting a\\
 databinding-specific data. The implementation has a contract which is not\\
 the same as the ServiceContract for the service.\\

public interface GenericInterface
{        Address getAddress(Customer customer); }

Both Address and Customer are plain interfaces.
\\
Then if the implementation code only work off the common interfaces, then no\\
 transformation is required. If it happens that impl code will cast the\\
 interface to some hidden contract such as commonj.sdo.DataObject, then we\\
 need to have the method in the impl class to express such requirements.\\

Another case is that we provide a componentType file for a POJO component to\\
 indicate that it exposes service using WSDL. Then the ServiceContract for\\
 the POJO component now is a WSDL service contract.\\

A similar case would be that a JavaScript component using interface.java, so\\
 the incoming data should be conforming to the java interface. But the\\
 JavaScript code might want to deal with all the data as XMLBeans.\\

For references and services with bindings, it becomes more obvious to see\\
 the databinding requirement from the binding contracts. For example, the\\
 binding.axis2 would only consume and provide data in AXIOM. The databinding\\
 information will be provided by binding extensions and set to the binding\\
 metadata.\\

2) Case 2: Two remotable interfaces with different databindings for the\\
 reference and target service\\

Let's assume there are two remotable interfaces generated from the same WSDL\\
 under two different databindings (SDO vs. JAXB):\\

public interface JAXBInterface
{        JAXBAddress getAddress(JAXBCustomer customer); }

public interface SDOInterface
{     SDOAddress   SDOAddress getAddress(SDOCustomer customer); }

We now have two components: Component1 is implemented using SDO while\\
 Component2 is implemented using JAXB. Component1 has a reference "ref1"\\
 typed by SDOInterface (because component1 will use SDO data for the outbound\\
 service call) while Component2 has a service "svc1" typed by JAXBInterface\\
 (because component2 only accepts JAXB data).\\

Should we support the wiring from Component1.ref1-->Component2.svc1? (I\\
 think it's resonable as the two interfaces can be mapped against each other\\
 because both are representation of the same WSDL portType using different\\
 databindings.