...
Business data are represented in different ways even they are for the same infoset. For example, we can model a Customer business object as:
- JavaBeans
- SDO
- JAXB
- JavaBeansXMLBeans
- DOM
And different protocol implementation stacks support different data representations. For example, in the Web Service domain, we have:
...
Implementation technologies may impose requirements on the data too. For example, the
- Apache ODE BPEL engine only consumes/produces data using DOM
...
- SAXON XQuery engine
...
- consumes/produces data using NodeInfo
- DAS implementation requires SDO
- Script Implementation uses AXIOM
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.
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 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.
Usage Scenarios
Let's look at a sample simple scenario. The business function is to retrieve report all the orders accounts for a given customer. The data exchanged between the client and server side will be Customer (s) and Order(s)and AccountReport. 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) .
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.
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.
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.
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.
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 | ||
---|---|---|
| ||
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. |
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.
and all of them come from the same model in the following XSD type definitions:
Code Block |
---|
<xsd:complexType name="Customer">
<xsd:sequence>
<xsd:element name="id" type="xsd:string"></xsd:element>
<xsd:element name="firstName" type="xsd:string"></xsd:element>
<xsd:element name="lastName" type="xsd:string"></xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="AccountReport">
<xsd:sequence>
<xsd:element name="id" type="xsd:string"></xsd:element>
<xsd:element name="type" type="xsd:string"></xsd:element>
<xsd:element name="balance" type="xsd:double"></xsd:element>
</xsd:sequence>
</xsd:complexType>
|
Client java component:
Code Block |
---|
SDO_AccountReport getAccountReport(SDO_Customer customer); // SDO_Customer and SDO_AccountReport are generated SDO interfaces
|
AXIS2 Web Service Stack:
Code Block |
---|
OMElement getAccountReport(OMElement customer); // pseudo method, the operation is defined in WSDL
|
Service java component:
Code Block |
---|
JAXB_AccountReport getAccountReport(JAXB_Customer customer); // JAXB_Customer and JAXB_AccountReport are generated JAXB classes
|
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 | ||
---|---|---|
| ||
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. |
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 Block |
---|
org. |
Code Block |
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.XMLDocument2XMLStreamReaderDataObject2String;source=commonj.sdo.helper.XMLDocumentDataObject,target=javaxjava.xmllang.stream.XMLStreamReaderString,weight=1040 org.apache.tuscany.sca.databinding.sdo.XMLStreamReader2DataObjectDataObject2XMLStreamReader;source=commonj.sdo.DataObject,target=javax.xml.stream.XMLStreamReader,target=commonj.sdo.DataObject,weight=1510 org.apache.tuscany.sca.databinding.sdo.XMLStreamReader2XMLDocumentXMLDocument2String;source=javaxcommonj.xmlsdo.streamhelper.XMLStreamReaderXMLDocument,target=commonjjava.sdolang.helper.XMLDocumentString,weight=1540 org.apache.tuscany.sca.databinding.sdo.DataObject2NodeString2DataObject;source=commonjjava.sdolang.DataObjectString,target=orgcommonj.w3csdo.dom.NodeDataObject,weight=4050 org.apache.tuscany.sca.databinding.sdo.Node2DataObjectXMLDocument2XMLStreamReader;source=orgcommonj.w3csdo.domhelper.NodeXMLDocument,target=commonjjavax.xml.sdostream.DataObjectXMLStreamReader,weight=40 10 org.apache.tuscany.sca.databinding.xmlsdo.InputSource2NodeXMLStreamReader2DataObject;source=orgjavax.xml.saxstream.InputSourceXMLStreamReader,target=orgcommonj.w3csdo.dom.NodeDataObject,weight=4015 org.apache.tuscany.sca.databinding.xmlsdo.InputStream2NodeXMLStreamReader2XMLDocument;source=javajavax.xml.iostream.InputStreamXMLStreamReader,target=orgcommonj.w3csdo.domhelper.NodeXMLDocument,weight=4015 org.apache.tuscany.sca.databinding.javabeanssdo.DOMNode2JavaBeanTransformerDataObject2Node;source=commonj.sdo.DataObject,target=org.w3c.dom.Node,target=java.lang.Object,weight=10000weight=40 org.apache.tuscany.sca.databinding.xmlsdo.Node2StringNode2DataObject;source=org.w3c.dom.Node,target=javacommonj.langsdo.StringDataObject,weight=40 org.apache.tuscany.sca.databinding.xml.Node2XMLStreamReaderInputSource2Node;source=org.w3cxml.domsax.NodeInputSource,target=javaxorg.xmlw3c.streamdom.XMLStreamReaderNode,weight=40 org.apache.tuscany.sca.databinding.javabeansxml.JavaBean2DOMNodeTransformerInputStream2Node;source=java.langio.ObjectInputStream,target=org.w3c.dom.Node,weight=1000040 org.apache.tuscany.sca.databinding.xmljavabeans.Reader2NodeDOMNode2JavaBeanTransformer;source=javaorg.w3c.iodom.ReaderNode,target=orgjava.w3clang.dom.NodeObject,weight=4010000 org.apache.tuscany.sca.databinding.xml.SAX2DOMPipeNode2String;source=org.xmlw3c.saxdom.ContentHandlerNode,target=orgjava.w3clang.dom.NodeString,weight=3040 org.apache.tuscany.sca.databinding.xml.StreamDataPipeNode2XMLStreamReader;source=javaorg.w3c.iodom.OutputStreamNode,target=javajavax.xml.iostream.InputStreamXMLStreamReader,weight=5040 org.apache.tuscany.sca.databinding.xmljavabeans.String2NodeJavaBean2DOMNodeTransformer;source=java.lang.StringObject,target=org.w3c.dom.Node,weight=5010000 org.apache.tuscany.sca.databinding.xml.String2XMLStreamReaderReader2Node;source=java.langio.StringReader,target=javaxorg.xmlw3c.streamdom.XMLStreamReaderNode,weight=5040 org.apache.tuscany.sca.databinding.xml.Writer2ReaderDataPipeSAX2DOMPipe;source=javaorg.xml.iosax.WriterContentHandler,target=javaorg.w3c.iodom.ReaderNode,weight=5030 org.apache.tuscany.sca.databinding.xml.XMLStreamReader2NodeStreamDataPipe;source=javaxjava.xmlio.stream.XMLStreamReaderOutputStream,target=orgjava.w3cio.dom.NodeInputStream,weight=4050 org.apache.tuscany.sca.databinding.xml.XMLStreamReader2StringString2Node;source=javaxjava.xmllang.stream.XMLStreamReaderString,target=javaorg.w3c.langdom.StringNode,weight=4050 org.apache.tuscany.sca.databinding.xml.Node2SimpleJavaTypeString2XMLStreamReader;source=orgjava.w3clang.dom.NodeString,target=java:simpleTypejavax.xml.stream.XMLStreamReader,weight=1000050 org.apache.tuscany.sca.databinding.xml.SimpleJavaType2NodeWriter2ReaderDataPipe;source=java:simpleType.io.Writer,target=orgjava.w3cio.dom.NodeReader,weight=1000050 org.apache.tuscany.sca.databinding.axiomxml.Object2OMElementXMLStreamReader2Node;source=java:simpleTypejavax.xml.stream.XMLStreamReader,target=org.apachew3c.axiomdom.om.OMElementNode,weight=1000040 org.apache.tuscany.sca.databinding.axiomxml.OMElement2ObjectXMLStreamReader2String;source=orgjavax.apachexml.axiomstream.om.OMElementXMLStreamReader,target=java:simpleType.lang.String,weight=1000040 org.apache.tuscany.sca.databinding.axiomxml.OMElement2StringNode2SimpleJavaType;source=org.apachew3c.axiomdom.om.OMElementNode,target=java.lang.String:simpleType,weight=4010000 org.apache.tuscany.sca.databinding.axiomxml.OMElement2XMLStreamReaderSimpleJavaType2Node;source=org.apache.axiom.om.OMElementjava:simpleType,target=javaxorg.xmlw3c.streamdom.XMLStreamReaderNode,weight=1010000 org.apache.tuscany.sca.databinding.axiom.String2OMElementObject2OMElement;source=java.lang.String:simpleType,target=org.apache.axiom.om.OMElement,weight=4010000 org.apache.tuscany.sca.databinding.axiom.XMLStreamReader2OMElementOMElement2Object;source=javax.xml.stream.XMLStreamReader,target=org.apache.axiom.om.OMElement,weight=10 target=java:simpleType,weight=10000 org.apache.tuscany.sca.databinding.jaxbaxiom.JAXB2NodeOMElement2String;source=javaxorg.apache.xmlaxiom.bindom.JAXBElementOMElement,target=orgjava.w3clang.dom.NodeString,weight=3040 org.apache.tuscany.sca.databinding.jaxbaxiom.Node2JAXBOMElement2XMLStreamReader;source=org.apache.w3caxiom.domom.NodeOMElement,target=javax.xml.bindstream.JAXBElementXMLStreamReader,weight=3010 org.apache.tuscany.sca.databinding.jaxbaxiom.Reader2JAXBString2OMElement;source=java.iolang.ReaderString,target=javaxorg.apache.xmlaxiom.bindom.JAXBElementOMElement,weight=3040 org.apache.tuscany.sca.databinding.jaxbaxiom.XMLStreamReader2JAXBXMLStreamReader2OMElement;source=javax.xml.stream.XMLStreamReader,target=javaxorg.apache.xmlaxiom.bindom.JAXBElementOMElement,weight=10 org.apache.tuscany.sca.databinding.saxonjaxb.Node2NodeInfoTransformerJAXB2Node;source=orgjavax.w3cxml.dombind.NodeJAXBElement,target=netorg.sfw3c.saxondom.om.NodeInfoNode,weight=1030 org.apache.tuscany.sca.databinding.saxonjaxb.NodeInfo2NodeTransformerNode2JAXB;source=netorg.sfw3c.saxondom.om.NodeInfoNode,target=orgjavax.w3cxml.dombind.NodeJAXBElement,weight=1030 org.apache.tuscany.sca.databinding.saxonjaxb.Object2ValueTransformerReader2JAXB;source=java.langio.ObjectReader,target=netjavax.sfxml.saxonbind.value.ValueJAXBElement,weight=1000030 org.apache.tuscany.sca.databinding.saxonjaxb.Value2ObjectTransformerXMLStreamReader2JAXB;source=netjavax.sfxml.saxonstream.value.ValueXMLStreamReader,target=javajavax.xml.langbind.ObjectJAXBElement,weight=1000010 org.apache.tuscany.sca.databinding.saxon.SimpleType2ValueTransformerNode2NodeInfoTransformer;source=java:simpleTypeorg.w3c.dom.Node,target=net.sf.saxon.valueom.ValueNodeInfo,weight=1000010 org.apache.tuscany.sca.databinding.saxon.Value2SimpleTypeTransformerNodeInfo2NodeTransformer;source=net.sf.saxon.valueom.ValueNodeInfo,target=java:simpleTypeorg.w3c.dom.Node,weight=1000010 org.apache.tuscany.sca.databinding.saxon.NodeInfo2DataObjectTransformerObject2ValueTransformer;source=java.lang.Object,target=net.sf.saxon.om.NodeInfo,target=commonj.sdo.DataObjectvalue.Value,weight=2010000 org.apache.tuscany.sca.databinding.saxon.DataObject2NodeInfoTransformerValue2ObjectTransformer;source=commonj.sdo.DataObjectnet.sf.saxon.value.Value,target=netjava.sf.saxon.om.NodeInfolang.Object,weight=1010000 org.apache.tuscany.sca.databinding.sdo2omsaxon.DataObject2OMElementSimpleType2ValueTransformer;source=commonj.sdo.DataObjectjava:simpleType,target=orgnet.apachesf.axiomsaxon.omvalue.OMElementValue,weight=100010000 org.apache.tuscany.sca.databinding.sdo2omsaxon.XMLDocument2OMElementValue2SimpleTypeTransformer;source=commonjnet.sf.sdosaxon.helpervalue.XMLDocumentValue,target=java:simpleType,weight=10000 org.apache.axiom.om.OMElement.tuscany.sca.databinding.saxon.NodeInfo2DataObjectTransformer;source=net.sf.saxon.om.NodeInfo,target=commonj.sdo.DataObject,weight=1000 |
The data transformation graph
Databinding transformer graph
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
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.
Data Transformations
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 Block |
---|
@Remotable
public interface MyInterface {
Node call(Node msg);
XMLStreamReader call1(XMLStreamReader msg);
}
|
Fine-grained databinding control
Java annotations for a remotable interface
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:
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
|
The data transformation graph
In Tuscany, we register transformers to form a graph as folllows:
- 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.
With the transformer graph, we support not only point-to-point transformations but also multiple-hop transformations. This approach greatly reduces the number of transformers required and makes it possible to transform data without a direct transformation logic. It's very common that some databindings will be supported as the intermediaries, for example, the XML Sting, DOM Node and StAX XMLStreamReader are very populate in the XML world.
The algorithm to calculate the transformation path
- 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.
What' a data type?
DataType is the decription of the data. It contains three pieces: the data binding, the physical type and the logical 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. 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.
Introspection of java interfaces for data types
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.
Data mediation in the SCA assembly
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 | |
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 |
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.
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
- 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
...
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 |
Data transformation between SCA components
- Data transformation can be performed on wire for remotable interfaces
- Data transformation can handle interfaces defined using different IDLs such as Java or WSDL.
Data transformation for service bindings
- <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.
Data transformation for reference bindings
- <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.
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.
Special databindings and transformers to deal with operation-level transformations
- Input2InputTransformer: Transform the input data from the source operation to the input data expected by the target operation
- Output2OutputTransformer: Transform the output data from the target operation to the output data expected by the source operation
- Exception2ExceptionTransformer: Transform the fault data from the target operation to the fault data expected by the source operaion
Deal with interfaces defined using different 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 The input data format for an operation
- idl:output: The output data format for an operation
- idl:fault: The fault data format for an operation
- 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
Wrapper style WSDL operation
Code Block |
---|
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions name="AccountService" targetNamespace="http://www.example.org/AccountService/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:tns="http://www.example.org/AccountService/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<wsdl:types>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.example.org/AccountService/">
<xsd:complexType name="Customer">
<xsd:sequence>
<xsd:element name="id" type="xsd:string"></xsd:element>
<xsd:element name="firstName" type="xsd:string"></xsd:element>
<xsd:element name="lastName" type="xsd:string"></xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="AccountReport">
<xsd:sequence>
<xsd:element name="id" type="xsd:string"></xsd:element>
<xsd:element name="type" type="xsd:string"></xsd:element>
<xsd:element name="balance" type="xsd:double"></xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="getAccountReport">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="customer" type="tns:Customer"></xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="getAccountReportResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="report" type="tns:AccountReport"></xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
</wsdl:types>
<wsdl:message name="getAccountReportRequest">
<wsdl:part name="parameters" element="tns:getAccountReport"></wsdl:part>
</wsdl:message>
<wsdl:message name="getAccountReportResponse">
<wsdl:part name="return" element="tns:getAccountReportResponse"></wsdl:part>
</wsdl:message>
<wsdl:portType name="AccountService">
<wsdl:operation name="getAccountReport">
<wsdl:input message="tns:getAccountReportRequest"></wsdl:input>
<wsdl:output message="tns:getAccountReportResponse"></wsdl:output>
</wsdl:operation>
</wsdl:portType>
</wsdl:definition
|
The WrapperHandler provides wrapper style WSDL wrapping/unwrapping support
...