...
| 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\\
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 Removed
Parameter-level transformations
Logical Type vs. Physical Type
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?
Logical Type vs. Physical Type
The runtime's 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).
...
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
...
)
Data Transformations
How to transform data across databindings
...
- SimpleTypeMapper: convert data between XSD simple types (by the databinding, for example, OMElement with an OMText child) and java objects
Operation-level transformations
The signature of an operation is modeled as follows:
- InputType: The data type for the input. The logical type is a list of data types that represent the list of parameters
- OutputType: The data type for the output. The logical type is the data type that represents the return value
- FaultTypes: The list of data types for all the faults
Image Added
DataBindingRuntimeWireProcessor and DataTransformationInteceptor
...
Extend the databinding framework
What can be extended?
The Tuscany databinding framework can be extended in two ways:
...