Versions Compared

Old Version 2

changes.mady.by.user Zhaohui Feng

Saved on

compared with

New Version 3

changes.mady.by.user Zhaohui Feng

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Source Concrete Type

Source Declared Type

Target Concrete Type

Target Declared Type

Support

JAXBCustomer

java.lang.Object

SDOCustomer

java.lang.Object

Y

JAXBCustomer

customer.Customer

SDOCustomer

customer.Customer

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Note
Wiki Markup

...

> - 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 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.

...

Operation-level transformations
...
 Code Block
/**
 * DataBinding represents a data representation, for example, SDO, JAXB and AXIOM
 */
public interface DataBinding {
    /**
     * A special databinding for input message of an operation
     */
    String IDL_INPUT = "idl:input";
    /**
     * A special databinding for output message of an operation
     */
    String IDL_OUTPUT = "idl:output";
    /**
     * A special databinding for fault message of an operation
     */
    String IDL_FAULT = "idl:fault";
    /**
     * The name of a databinding should be case-insensitive and unique
     * 
     * @return The name of the databinding
     */
    String getName();
    
    /**
     * Get the aliases for the databinding
     * 
     * @return An array of aliases
     */
    String[] getAliases();

    /**
     * Introspect and populate information to a DataType model
     * 
     * @param javaType The java class or interface to be introspected
     * @param annotations The java annotations
     * @return true if the databinding has recognized the given data type
     */
    boolean introspect(DataType dataType, Annotation[] annotations);

    /**
     * Introspect the data to figure out the corresponding data type
     * 
     * @param value The object to be checked
     * @return The DataType or null if the java type is not supported by this databinding
     */
    DataType introspect(Object value);

    /**
     * Provide a WrapperHandler for this databinding
     * @return A wrapper handler which can handle wrapping/wrapping for this databinding
     */
    WrapperHandler getWrapperHandler();

    /**
     * Make a copy of the object for "pass-by-value" semantics
     * @param source object to copy 
     * @return copy of the object passed in as argument
     */
    Object copy(Object object);
    
    /**
     * Get the type mapper for simple types
     * @return The databinding-specific simple type mapper
     */
    SimpleTypeMapper getSimpleTypeMapper();
    
    /**
     * Get the handler that can handle exceptions/faults in the
     * databinding-specific way
     * 
     * @return An instance of the exception handler
     */
    ExceptionHandler getExceptionHandler();
}

...
 Code Block
/**
 * Module activator for AXIOM databinding
 * 
 * @version $Rev: 529327 $ $Date: 2007-04-16 10:10:43 -0700 (Mon, 16 Apr 2007) $
 */
public class AxiomDataBindingModuleActivator implements ModuleActivator {

    public Map<Class, Object> getExtensionPoints() {
        return null;
    }

    public void start(ExtensionPointRegistry registry) {
        DataBindingExtensionPoint dataBindingRegistry = registry.getExtensionPoint(DataBindingExtensionPoint.class);
        dataBindingRegistry.register(new AxiomDataBinding());

        TransformerExtensionPoint transformerRegistry = registry.getExtensionPoint(TransformerExtensionPoint.class);
        transformerRegistry.registerTransformer(new Object2OMElement());
        transformerRegistry.registerTransformer(new OMElement2Object());
        transformerRegistry.registerTransformer(new OMElement2String());
        transformerRegistry.registerTransformer(new OMElement2XMLStreamReader());
        transformerRegistry.registerTransformer(new String2OMElement());
        transformerRegistry.registerTransformer(new XMLStreamReader2OMElement());
    }

    public void stop(ExtensionPointRegistry registry) {
    }

}

TODO List
  • Support Collection or Array data types
  • Better support interface/operation level databinding mappings
  • Support databinding for java types which can be used for multiple datatypes, for example, InputStream or String can be used to represent various formats
  • Better support exception/fault
  • Support application data based introspection of operations