Tuscany Databinding Guide (TUSCANY) edited by Raymond Feng
Page:
http://cwiki.apache.org/confluence/display/TUSCANY/Tuscany+Databinding+Guide
Changes:
http://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=52118&originalVersion=27&revisedVersion=28
Content:
---------------------------------------------------------------------
h1. Tuscany Databinding Framework
h2. Overview
In an SOA environment, business functions can be implemented in various
technologies such as Java, C++, Scripting, BPEL, Spring, OSGi and XQuery. The
business data can also be represented in different formats such as DOM, JAXB,
SDO, AXIOM or POJO. Business services often communicate with each other on the
network using various protocols such as RMI, RMI/IIOP, SOAP/HTTP, JMS, JCA,
FEED and JSON-RPC. The service collaborations are achieved by data exchanges
between service components. The SCA programming model defines an extension
model for interface, implementation and binding types. The extensibility is
essential to SOA as we need to be able to leverage and integrate all kinds of
technologies. On the data side, we also need the extensibility for different
formats so that we can flow any data type that is supported by both the client
and the provider.
Business data are represented in different ways even they are for the same
infoset. For example, we can model a Customer business object as:
* SDO
* JAXB
* JavaBeans
* DOM
And different protocol implementation stacks support different data
representations. For example, in the Web Service domain, we have:
* 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.
In any interchange there are just two things that are defined: the format of
data that will be supplied by the client and the format of data that will be
consumed by (delivered to) the provider. Neither client or provider needs to be
aware of the format of data on the other end or of what gyrations the fabric
went though in order to make the connection. As part of making the connection,
it is the fabric's job to make the connection as efficient as possible,
factoring in the semantic meaning of the data, the policies that need to be
applied, and what the different containers support.
All this flexibility just requires we use the most generic type possible to
hold the data being exchanged: a java.lang.Object or a (void*) depending on the
runtime. The actual instance used would depend on the actual wire, some
examples from Java land being:
* POJO (for local pass by reference)
* SDO (when supplied by the application)
* Axiom OMElement (for the Axis2 binding)
* StAX XMLStreamReader (for streamed access to a XML infoset)
* ObjectInputStream (for cross-classloader serialization) and so forth.
Each SCA implementation and binding type just needs to declare which data
formats it can support for each endpoint it manages. The wiring framework need
to know about these formats and about what transformations can be engaged in
the invocation pipeline.
For example, the Axis2 transport may declare that it can support Axiom and StAX
for a certain port and the Java container may declare that it can only handle
SDOs for an implementation that expects to be passed a DataObject. The wiring
framework can resolve this by adding a StAX->SDO transform into the pipeline.
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.
h2. Usage Scenarios
Let's look at a sample scenario. The business function is to retrieve all the
orders for a given customer. The data exchanged between the client and server
side will be Customer(s) and Order(s). Let's assume that the business objects
are modeled using XML schema and the client side will talk to the server side
over Web Service using Axis2. The client program decides to use SDO to
represent the business data while the server side prefers to use JAXB.
In this case, there are three data formats involved: SDO, JAXB and AXIOM (The
AXIS2 XML Infoset).
h3. 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.
!databinding_components.jpg|align=center!
h3. 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. !databinding_service.jpg|align=center!
h3. 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.
!databinding_reference.jpg|align=center!
h3. 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.
!databinding_property.jpg|align=center!
h2. 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
** FastInfoset
* XML Parsing Technologies
** SAX (InputSource, ContentHandler)
** DOM (Node)
** StAX (XMLStreamReader/XMLStreamWriter/XMLEventReader/XMLEventWriter)
* I/O
** InputStream/OutputStream
** Reader/Writer
** byte[] or String
* Other
** JavaBeans
** Simple Java Types
** JSON
{note:title=Overloaded data fomats}
Please note the I/O kind of databindings are further defined by the type of the
content. For example, the InputStream can feed XML stream, fastinfoset, or
something else. The context of a String can be a XML document, a JSON string or
a CSV.
{note}
h2. What's a transformer?
A transformer is the data conversation logic that transforms data from one
format to another format. For example, a transformer can convert the DOM Node
into a SDO dataobject. A transformer will be registered as an edge connecting
the source databinding to the target databinding. The weight of a transformer
represents the cost
of the transformation.
The following is an incomplete list of transformers that we ship in
1.0-incubating release.
{code}
org.apache.tuscany.sca.databinding.sdo.DataObject2String;source=commonj.sdo.DataObject,target=java.lang.String,weight=40
org.apache.tuscany.sca.databinding.sdo.DataObject2XMLStreamReader;source=commonj.sdo.DataObject,target=javax.xml.stream.XMLStreamReader,weight=10
org.apache.tuscany.sca.databinding.sdo.XMLDocument2String;source=commonj.sdo.helper.XMLDocument,target=java.lang.String,weight=40
org.apache.tuscany.sca.databinding.sdo.String2DataObject;source=java.lang.String,target=commonj.sdo.DataObject,weight=50
org.apache.tuscany.sca.databinding.sdo.XMLDocument2XMLStreamReader;source=commonj.sdo.helper.XMLDocument,target=javax.xml.stream.XMLStreamReader,weight=10
org.apache.tuscany.sca.databinding.sdo.XMLStreamReader2DataObject;source=javax.xml.stream.XMLStreamReader,target=commonj.sdo.DataObject,weight=15
org.apache.tuscany.sca.databinding.sdo.XMLStreamReader2XMLDocument;source=javax.xml.stream.XMLStreamReader,target=commonj.sdo.helper.XMLDocument,weight=15
org.apache.tuscany.sca.databinding.sdo.DataObject2Node;source=commonj.sdo.DataObject,target=org.w3c.dom.Node,weight=40
org.apache.tuscany.sca.databinding.sdo.Node2DataObject;source=org.w3c.dom.Node,target=commonj.sdo.DataObject,weight=40
org.apache.tuscany.sca.databinding.xml.InputSource2Node;source=org.xml.sax.InputSource,target=org.w3c.dom.Node,weight=40
org.apache.tuscany.sca.databinding.xml.InputStream2Node;source=java.io.InputStream,target=org.w3c.dom.Node,weight=40
org.apache.tuscany.sca.databinding.javabeans.DOMNode2JavaBeanTransformer;source=org.w3c.dom.Node,target=java.lang.Object,weight=10000
org.apache.tuscany.sca.databinding.xml.Node2String;source=org.w3c.dom.Node,target=java.lang.String,weight=40
org.apache.tuscany.sca.databinding.xml.Node2XMLStreamReader;source=org.w3c.dom.Node,target=javax.xml.stream.XMLStreamReader,weight=40
org.apache.tuscany.sca.databinding.javabeans.JavaBean2DOMNodeTransformer;source=java.lang.Object,target=org.w3c.dom.Node,weight=10000
org.apache.tuscany.sca.databinding.xml.Reader2Node;source=java.io.Reader,target=org.w3c.dom.Node,weight=40
org.apache.tuscany.sca.databinding.xml.SAX2DOMPipe;source=org.xml.sax.ContentHandler,target=org.w3c.dom.Node,weight=30
org.apache.tuscany.sca.databinding.xml.StreamDataPipe;source=java.io.OutputStream,target=java.io.InputStream,weight=50
org.apache.tuscany.sca.databinding.xml.String2Node;source=java.lang.String,target=org.w3c.dom.Node,weight=50
org.apache.tuscany.sca.databinding.xml.String2XMLStreamReader;source=java.lang.String,target=javax.xml.stream.XMLStreamReader,weight=50
org.apache.tuscany.sca.databinding.xml.Writer2ReaderDataPipe;source=java.io.Writer,target=java.io.Reader,weight=50
org.apache.tuscany.sca.databinding.xml.XMLStreamReader2Node;source=javax.xml.stream.XMLStreamReader,target=org.w3c.dom.Node,weight=40
org.apache.tuscany.sca.databinding.xml.XMLStreamReader2String;source=javax.xml.stream.XMLStreamReader,target=java.lang.String,weight=40
org.apache.tuscany.sca.databinding.xml.Node2SimpleJavaType;source=org.w3c.dom.Node,target=java:simpleType,weight=10000
org.apache.tuscany.sca.databinding.xml.SimpleJavaType2Node;source=java:simpleType,target=org.w3c.dom.Node,weight=10000
org.apache.tuscany.sca.databinding.axiom.Object2OMElement;source=java:simpleType,target=org.apache.axiom.om.OMElement,weight=10000
org.apache.tuscany.sca.databinding.axiom.OMElement2Object;source=org.apache.axiom.om.OMElement,target=java:simpleType,weight=10000
org.apache.tuscany.sca.databinding.axiom.OMElement2String;source=org.apache.axiom.om.OMElement,target=java.lang.String,weight=40
org.apache.tuscany.sca.databinding.axiom.OMElement2XMLStreamReader;source=org.apache.axiom.om.OMElement,target=javax.xml.stream.XMLStreamReader,weight=10
org.apache.tuscany.sca.databinding.axiom.String2OMElement;source=java.lang.String,target=org.apache.axiom.om.OMElement,weight=40
org.apache.tuscany.sca.databinding.axiom.XMLStreamReader2OMElement;source=javax.xml.stream.XMLStreamReader,target=org.apache.axiom.om.OMElement,weight=10
org.apache.tuscany.sca.databinding.jaxb.JAXB2Node;source=javax.xml.bind.JAXBElement,target=org.w3c.dom.Node,weight=30
org.apache.tuscany.sca.databinding.jaxb.Node2JAXB;source=org.w3c.dom.Node,target=javax.xml.bind.JAXBElement,weight=30
org.apache.tuscany.sca.databinding.jaxb.Reader2JAXB;source=java.io.Reader,target=javax.xml.bind.JAXBElement,weight=30
org.apache.tuscany.sca.databinding.jaxb.XMLStreamReader2JAXB;source=javax.xml.stream.XMLStreamReader,target=javax.xml.bind.JAXBElement,weight=10
org.apache.tuscany.sca.databinding.saxon.Node2NodeInfoTransformer;source=org.w3c.dom.Node,target=net.sf.saxon.om.NodeInfo,weight=10
org.apache.tuscany.sca.databinding.saxon.NodeInfo2NodeTransformer;source=net.sf.saxon.om.NodeInfo,target=org.w3c.dom.Node,weight=10
org.apache.tuscany.sca.databinding.saxon.Object2ValueTransformer;source=java.lang.Object,target=net.sf.saxon.value.Value,weight=10000
org.apache.tuscany.sca.databinding.saxon.Value2ObjectTransformer;source=net.sf.saxon.value.Value,target=java.lang.Object,weight=10000
org.apache.tuscany.sca.databinding.saxon.SimpleType2ValueTransformer;source=java:simpleType,target=net.sf.saxon.value.Value,weight=10000
org.apache.tuscany.sca.databinding.saxon.Value2SimpleTypeTransformer;source=net.sf.saxon.value.Value,target=java:simpleType,weight=10000
org.apache.tuscany.sca.databinding.saxon.NodeInfo2DataObjectTransformer;source=net.sf.saxon.om.NodeInfo,target=commonj.sdo.DataObject,weight=20
org.apache.tuscany.sca.databinding.saxon.DataObject2NodeInfoTransformer;source=commonj.sdo.DataObject,target=net.sf.saxon.om.NodeInfo,weight=10
org.apache.tuscany.sca.databinding.sdo2om.DataObject2OMElement;source=commonj.sdo.DataObject,target=org.apache.axiom.om.OMElement,weight=1000
org.apache.tuscany.sca.databinding.sdo2om.XMLDocument2OMElement;source=commonj.sdo.helper.XMLDocument,target=org.apache.axiom.om.OMElement,weight=1000
{code}
h2. The data transformation graph
Databinding transformer graph
!databinding_graph.jpg|align=center!
The algorithm to calculate the transformation path
* The transformers are registered and selected using the following algorithm.
** The data transformation capabilities for various databindings can be nicely
modeled as a weighted, directed graph with the following rules. (Illustrated in
the attached diagram).
** Each databinding is mapped to a vertex.
** If databinding A can be transformed to databinding B, then an edge will be
added from vertex A to vertex B.
** The weight of the edge is the cost of the transformation from the source to
the sink.
* In the data interceptor on the wire, if we find out that the data needs to be
transformed from databinding A to databinding E. Then we can apply Dijkstra's
Shortest Path Algorithm to the graph and figure the most performed path. It can
be A\-->E, or A{-}->C-\->E depending on the weights. If no path can be found,
then the data cannot be mediated.
Transform data
* Direct transformation
* Multi-hop transformation
h2. What' a data type?
h3. 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.
h2. Data Transformations
h3. How to transform data across databindings
* A databinding is a terminal for the data transformation
* Three types of databindings depending on how the data is represented by the
databinding
** Some databindings can feed the data for consumption
** Some databindings serve a sink to receive data
** Some databindings can bridge the sink so that data coming into the sink can
be consumed by others
Scenario 1: Source \--> Source
Scenario 2: Source \--> Sink
Scenario 3: Sink \--> Source (Pipe)
How to use databindings?
Declare the data binding for the interfaces
* Data Binding requirement can be expressed as:
** SCDL extension
{code}
@Remotable
public interface MyInterface {
Node call(Node msg);
XMLStreamReader call1(XMLStreamReader msg);
}
{code}
h3. Fine-grained databinding control
Java annotations for a remotable interface
h2. DataBindingRuntimeWireProcessor and DataTransformationInteceptor
DataBindingRuntimeWireProcessor is responsible to insert a
DataTransformationInteceptor into the invovcation chains if the data
transformation is required between the source and target operations. Depending
on the invocation patterns, it uses the effective interface contracts to
determine if transformation should be applied.
Typically, there are three cases:
|*Interaction*|*Effective Source Interface contract*|*Effective Target
Interface Contract*|
|A SCA component talks to another SCA component over a remotable interface
using binding.sca|The interface contract of the reference defined by the source
component type|The interface contract of the service defined by the target
component type|
|A SCA component talks to an external service using binding.x|The interface
contract of the reference defined by the source component type|The interface
contract imposed by the binding protocol|
|The request from binding.y is routed to a component service|The interface
contract imposed by binding.y|The interface contract of the service defined by
the target component type|
h2. DataBindingJavaInterfaceProcessor
The DataBindingJavaInterfaceProcessor is responsible to introspect the java
interfaces to figure out the databindings of the parameters and return types.
It delegates to all of the databinding implementations which will set the
databinding and logical type if such data type is recognized by the
databinding. This introspection process can handle most of the cases as the
java types usually have some patterns, for example, implementing a know
interface.
h2. Special databindings and transformers to deal with operation-level
transformations
* Input2InputTransformer
* Output2OutputTransformer
* Exception2ExceptionTransformer
Deal with different IDLs
Dealing with WSDL/XSD based IDLs
* SCA allows the interfaces to be defined using various IDLs, for example, java
interface or WSDL portType
* IDLs may have different ways to represent the input/output/fault data
* The databinding framework is designed to support the transformation across
IDLs
* Some special databindings are internally used for this purpose:
** idl:input
** idl:ouput
Dealing with WSDL/XSD based IDLs
* WrapperHandler
** Provide WrapperStyle WSDL wrapping/unwrapping support
!wrapper_transformation.jpg|align=center!
* SimpleTypeMapper: convert data between XSD simple types (by the databinding,
for example, OMElement with an OMText child) and java objects
h3. 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
!databinding_operation.jpg|align=center!
h3. Wrapper style WSDL operation
The WrapperHandler provides wrapper style WSDL wrapping/unwrapping support
!wrapper_transformation.jpg|align=center!
h2. Extend the databinding framework
h3. What can be extended?
The Tuscany databinding framework can be extended in two ways:
1. Add more databinding providers to support new formats to represent
business data
2. Add more transformers to facilitate the data exchange accross
databindings
h3. How to contribute a new databinding or transformer?
Databindings and transformers can be plugged into Tuscany runtime following the
Tuscany extensibility story. It can be achieved in the following steps:
Add a new databinding:
1. Provide a java class which implements the DataBinding interface. You can
subclass the BaseDataBinding.
2. Register your databindings against the DataBindingExtensionPoint.
Add a new transformer:
1. Provide a java class which implements the Transformer interface. You can
subclass the BasePullTransformer or BasePushTransformer.
2. Register your transformers against the TransformerExtensionPoint.
h4. The DataBinding SPI:
{code}
/**
* 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 dataType The data type 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}
* Support introspection of java types
* Support data copying for pass-by-value
* Support warpping/unwrapping for WSDL wrapper style
* Support exception handling
h4. Transformer SPI
{code}
/**
* 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);
}
{code}
h4. Register databindings and transformers
To regsiter one or more databindings, you need to add entries to a plain text
file named as META-INF/services/org.apache.tuscany.sca.databinding.DataBinding.
This service provider file needs to be on the classpath when Tuscany is
bootstrapped.
{code}
# implementation classes for the databindings
org.apache.tuscany.sca.databinding.axiom.AxiomDataBinding;type=org.apache.axiom.om.OMElement,name=axiom
{code}
The syntax is:
<implementation_class_name>;type=<databinding_id>,name=<databinding_alias>
To register one or more transformers, you need to add entries to a plain text
file named as
META-INF/services/org.apache.tuscany.sca.databinding.PullTransformer. This
service provider file needs to be on the classpath when Tuscany is bootstrapped.
{code}
# Implementation classes for the transformers
org.apache.tuscany.sca.databinding.axiom.Object2OMElement;source=java:simpleType,target=org.apache.axiom.om.OMElement,weight=10000
org.apache.tuscany.sca.databinding.axiom.OMElement2Object;source=org.apache.axiom.om.OMElement,target=java:simpleType,weight=10000
org.apache.tuscany.sca.databinding.axiom.OMElement2String;source=org.apache.axiom.om.OMElement,target=java.lang.String,weight=40
org.apache.tuscany.sca.databinding.axiom.OMElement2XMLStreamReader;source=org.apache.axiom.om.OMElement,target=javax.xml.stream.XMLStreamReader,weight=10
org.apache.tuscany.sca.databinding.axiom.String2OMElement;source=java.lang.String,target=org.apache.axiom.om.OMElement,weight=40
org.apache.tuscany.sca.databinding.axiom.XMLStreamReader2OMElement;source=javax.xml.stream.XMLStreamReader,target=org.apache.axiom.om.OMElement,weight=10
{code}
The syntax is:
<implementation_class_name>;source=<source_databinding_id>,target=<target_databinding_id>,weight=<cost_of_the_transformation>
h1. 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
---------------------------------------------------------------------
CONFLUENCE INFORMATION
This message is automatically generated by Confluence
Unsubscribe or edit your notifications preferences
http://cwiki.apache.org/confluence/users/viewnotifications.action
If you think it was sent incorrectly contact one of the administrators
http://cwiki.apache.org/confluence/administrators.action
If you want more information on Confluence, or have a bug to report see
http://www.atlassian.com/software/confluence
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
