Versions Compared

Key

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

...

  • Axis1 uses DOM
  • Axis2 uses AXIOM
  • JAX-WS uses JAXB

Implementation technologies may impose requirements on the data too. For example, the Apache ODE BPEL engine only consumes/produces data using DOM. And SAXON XQuery engine uses NodeInfo.

Application developers should have the freedom to choose their preferred data representation and components with compatible data should be able to interoperate without the intervention of the business logic. With the ability to attach data transformation mediations to wires, this actually becomes a requirement to support any data type that can be mapped from client to provider and back again.

...

  • <interface.xxx> defines the inbound service contract (SC2) which can be wired from a source component, reference or service (SC1).
  • <binding.xxx> can optionally hint a service contract (SC3) for the outbound data to the binding protocol layer.

Image Removed

Data transformation for property values

  • Property values are loaded from SCDLs as DOM documents
  • The DOM Document can be transformed into a java object under a databinding, such as SDO, JAXB so that the component implementation code can work with the databinding directly instead of DOM.

Image Removed

The data model

Code Block

<schema targetNamespace="http://www.example.com/Customer" xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:cust="http://www.example.com/Customer">
<element name="customer" type="cust:Customer" />
<complexType name="Customer">
<sequence>
<element name="customerId" type="string" />
<element name="name" type="string" />
<element name="billingAddress" type="cust:Address" />
<element name="mailingAddress" type="cust:Address" />
</sequence>
</complexType>
<complexType name="Address">
<sequence>
<element name="street" type="string" />
<element name="city" type="string" />
<element name="state" type="string" />
<element name="zipCode" type="string" />
</sequence>
</complexType>
</schema>

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

 

 

 

 

 

 

  • the binding protocol layer.

Image Added

Data transformation for property values

  • Property values are loaded from SCDLs as DOM documents
  • The DOM Document can be transformed into a java object under a databinding, such as SDO, JAXB so that the component implementation code can work with the databinding directly instead of DOM.

Image Added

Note
Wiki Markup
> - Databinding technology is not reflected in the service contract but&nbsp; in\\
 > the implementation contract. For example, different component\\
 > implementations may choose different databinding technologies.&nbsp; Currently,\\
 > we pass this information as part of Operation, which is&nbsp; part of the\\
 > ServiceContract.\\
I can see the following paths below with potentially different data\\
 contracts that require transformations:\\
1. component1.ref1 \--> component2.svc1\\
&nbsp;&nbsp;&nbsp; a) component1's implementation contract \--> component1.ref1's\\
 ServiceContract\\
 &nbsp;&nbsp;&nbsp; b) component1.ref1's ServiceContract \--> component2.svc1's\\
 ServiceContract\\
 &nbsp;&nbsp;&nbsp; c) component2.svc1's ServiceContract \--> component2's implementation\\
 contract\\
2. composite.service1 w/ binding1\\
&nbsp;&nbsp;&nbsp; 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.

...

Code Block
/**
 * A transformer provides the data transformation from source type to target type. The cost of the transformation is
 * modeled as weight.
 */
public interface Transformer {
    /**
     * Get the source type that this transformer transforms data from. The type is used as the key when the transformer
     * is registered with TransformerRegistry.
     *
     * @return A key indentifying the source type
     */
    String getSourceDataBinding();

    /**
     * Get the target type that this transformer transforms data into. The type is used as the key when the transformer
     * is registered with TransformerRegistry.
     *
     * @return A key indentifying the target type
     */
    String getTargetDataBinding();

    /**
     * Get the cost of the transformation. The weight can be used to choose the most efficient path if there are more
     * than one available from the source to the target.
     *
     * @return An integer representing the cost of the transformation
     */
    int getWeight();
}


/**
 * PullTransformer transforms data from one binding format to the other one which can be directly consumed
 * 
 * @param <S> The source data type
 * @param <R> the target data type
 */
public interface PullTransformer<S, R> extends Transformer {
    /**
     * Transform source data into the result type.
     * 
     * @param source The source data
     * @param context The context for the transformation
     * @return The transformed result
     */
    R transform(S source, TransformationContext context);
}

...