Versions Compared

Old Version 7

changes.mady.by.user Zhaohui Feng

Saved on

compared with

New Version 8

changes.mady.by.user Zhaohui Feng

Saved on

Key

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

...

The limitation here is whether a transformation can be constructed to match the formats on either end. If one exists then great, but as the number increases then developing n-squared transforms becomes impractical. A better approach would be to pick the most common formats and require bindings and containers to support those at a minimum, with other point-to-point transforms being added as warranted. (Source: http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200603.mbox/%3c4418A53D.2080606@apache.org%3e)

Usage Scenarios

The data model

Let's look at a scenario with various databindings involved. We need to retrieve all the orders for a given customer. The source side uses SDO to represent the Customer and Orders. The target side uses JAXB to represent customer and Orders. The order retrival function is exposed as a web service.

Data transformation between SCA components

  • Data transformation can be performed on wire for mappable and remotable interfaces
  • Data transformation can happen between interfaces defined using different IDLs such as Java or WSDL.

Image Added

Data transformation for composite services

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

Data transformation for composite references

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Note
unmigrated-wiki-markup-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> - 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) binding1component1's implementation contract (mandated by the transport/protocol stack, for\\
 example, AXIOM for Axis2) \--> composite.service1 ServiceContract (by the\\
 interface definition under <service>)component1.ref1's\\
3. composite.reference1 w/ binding1 ServiceContract\\
 &nbsp;&nbsp;&nbsp; ab) compositecomponent1.reference1ref1's ServiceContract (by the interface definition\\
 under the <reference>)\--> component2.svc1's\\
 ServiceContract\\
 &nbsp;&nbsp;&nbsp; c) component2.svc1's ServiceContract \--> Composite reference's binding contract (mandated\\
 by the transport/protocol stack)component2's implementation\\
There are different cases: contract\\
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

Operation:

InputType

OutputType

FaultTypes

Image Removed

Parameter-level transformations

Logical Type vs. Physical Type

The runtime's main job is to connect user components together so typically the actual type used would be determined by the user code that implements the source or target. The databinding framework's role here is to convert from the type used by the source to the type used by the target. The internal types used by the runtime should not influence this - which is an essential separation to maintain given the components and the wire connecting them need to work on different runtimes (implemented in different languages).

Where runtime types do matter is in the conversion between some serialized form and an in-memory representation and the two places where that occurs are in the configuration properties and in the binding implementations. To handle configuration properties (with the XPath requirement) we use DOM in the Java runtime; I believe the C++ runtime uses SDO. Each transport binding also tends to deserialize using a specific technology - for example, AXIOM for Axis2, JAXB for JAX-WS, Serializable for RMI and so the databinding framework is used to convert between the form generated by the binding and the form used by the component.

The logical type represents the data type the user thinks is flowing across a wire. This could be a Java type, a XML type, a CORBA type, whatever depending on the /logical/ service contract defined in the assembly.

The physical type is the actual representation of that type that is flowed by the runtime. In the Java runtime this will always be a Java type (i.e. some subclass of Object). In some cases it will be the same as the logical type - e.g. when a Java component calls another Java component over a local wire using a Java interface then both logical and physical types will be the same. In many cases though they will be different - for example, if the service contract was WSDL then the logical type would be the XML type used by the WSDL.

Within the runtime the same logical type may have different physical forms. For example, the same XML document could be represented physically as a DOM, a StAX stream, an SDO, a JAXB object, or an AXIOM stream. The framework supports conversion between these different physical forms.

1. A component (A) consumes a service provided by another component (B). The implementation of A prefers SDO while the implementation of B prefers JAXB.

In the SCA term, A is wired to B using a reference.

  • Data is represented by an interface which is independent of the databinding
  • Data is represented by an interface or class which is databinding-specific (either generated or dynamic)

2. A component (A) consumes a web service using axis2. Axis2 engine expects to handle AXIOM objects.

3. A component is exposed as a service over a transport/protocol.

Where runtime types do matter is in the conversion between some serialized form and an in-memory representation and the two places where that occurs are in the configuration properties and in the binding implementations. To handle configuration properties (with the XPath requirement) we use DOM in the Java runtime; I believe the C++ runtime uses SDO. Each transport binding also tends to deserialize using a specific technology - for example, AXIOM for Axis2, JAXB for JAX-WS, Serializable for RMI and so the databinding framework is used to convert between the form generated by the binding and the form used by the component.

interfaces for services and references are the contracts for SCA assembly.

1. Incoming data for component implementation

2. Interace mapping

  • interface.java <--> interface.java
  • interface.wsdl <--> interface.java
  • interface.wsdl <--> interface.wsdl
  • interface.* <--> other

Mapping from interface.wsdl to interface.java

JaxbAddress getAddress(JaxbCustomer customer)

SdoAddress getAddress(SdoCustomer customer)

What's a databinding?

A databinding represents a specific data format in the Tuscany runtime. Each databinding has a unique name which identifies the data format.

Typical databindings

  • XML/Java databinding frameworks
    • SDO
    • JAXB
    • XMLBeans
    • Castor
    • Axiom
    • JavaBeans
  • XML Parsing Technologies
    • SAX (InputSource, ContentHandler)
    • DOM (Node)
    • StAX (XMLStreamReader/XMLStreamWriter/XMLEventReader/XMLEventWriter)
  • I/O
    • InputStream/OutputStream
    • Reader/Writer

What's a transformer?

Usage Scenarios

Data transformation between SCA components

  • Data transformation can be performed on wire for mappable and remotable interfaces
  • Data transformation can happen between interfaces defined using different IDLs such as Java or WSDL.

Image Removed

Data transformation for composite services

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

Data transformation for composite references

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

...

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.

Operation-level transformations

Operation:

InputType

OutputType

FaultTypes

Image Added

Parameter-level transformations

Logical Type vs. Physical Type

The runtime's main job is to connect user components together so typically the actual type used would be determined by the user code that implements the source or target. The databinding framework's role here is to convert from the type used by the source to the type used by the target. The internal types used by the runtime should not influence this - which is an essential separation to maintain given the components and the wire connecting them need to work on different runtimes (implemented in different languages).

Where runtime types do matter is in the conversion between some serialized form and an in-memory representation and the two places where that occurs are in the configuration properties and in the binding implementations. To handle configuration properties (with the XPath requirement) we use DOM in the Java runtime; I believe the C++ runtime uses SDO. Each transport binding also tends to deserialize using a specific technology - for example, AXIOM for Axis2, JAXB for JAX-WS, Serializable for RMI and so the databinding framework is used to convert between the form generated by the binding and the form used by the component.

The logical type represents the data type the user thinks is flowing across a wire. This could be a Java type, a XML type, a CORBA type, whatever depending on the /logical/ service contract defined in the assembly.

The physical type is the actual representation of that type that is flowed by the runtime. In the Java runtime this will always be a Java type (i.e. some subclass of Object). In some cases it will be the same as the logical type - e.g. when a Java component calls another Java component over a local wire using a Java interface then both logical and physical types will be the same. In many cases though they will be different - for example, if the service contract was WSDL then the logical type would be the XML type used by the WSDL.

Within the runtime the same logical type may have different physical forms. For example, the same XML document could be represented physically as a DOM, a StAX stream, an SDO, a JAXB object, or an AXIOM stream. The framework supports conversion between these different physical forms.

1. A component (A) consumes a service provided by another component (B). The implementation of A prefers SDO while the implementation of B prefers JAXB.

In the SCA term, A is wired to B using a reference.

  • Data is represented by an interface which is independent of the databinding
  • Data is represented by an interface or class which is databinding-specific (either generated or dynamic)

2. A component (A) consumes a web service using axis2. Axis2 engine expects to handle AXIOM objects.

3. A component is exposed as a service over a transport/protocol.

Where runtime types do matter is in the conversion between some serialized form and an in-memory representation and the two places where that occurs are in the configuration properties and in the binding implementations. To handle configuration properties (with the XPath requirement) we use DOM in the Java runtime; I believe the C++ runtime uses SDO. Each transport binding also tends to deserialize using a specific technology - for example, AXIOM for Axis2, JAXB for JAX-WS, Serializable for RMI and so the databinding framework is used to convert between the form generated by the binding and the form used by the component.

interfaces for services and references are the contracts for SCA assembly.

1. Incoming data for component implementation

2. Interace mapping

  • interface.java <--> interface.java
  • interface.wsdl <--> interface.java
  • interface.wsdl <--> interface.wsdl
  • interface.* <--> other

Mapping from interface.wsdl to interface.java

JaxbAddress getAddress(JaxbCustomer customer)

SdoAddress getAddress(SdoCustomer customer)

What's a databinding?

A databinding represents a specific data format in the Tuscany runtime. Each databinding has a unique name which identifies the data format.

Typical databindings

  • XML/Java databinding frameworks
    • SDO
    • JAXB
    • XMLBeans
    • Castor
    • Axiom
    • JavaBeans
  • XML Parsing Technologies
    • SAX (InputSource, ContentHandler)
    • DOM (Node)
    • StAX (XMLStreamReader/XMLStreamWriter/XMLEventReader/XMLEventWriter)
  • I/O
    • InputStream/OutputStream
    • Reader/Writer

What's a transformer?

Data Transformations

How to transform data across databindings

...