Tuscany SCA - DataBinding

+

General

+

Home
+License
+Downloads
+Found a Bug?

+

Community

+

Events
+Get Involved
+Mailing Lists
+Blog

+

Tuscany SCA

+

SCA Overview
+SCA Java
+SCA Native
+PHP SCA
+SCA Releases

+

+ + +

Tuscany SDO

+

SDO Overview
+SDO Java
+SDO C++

+

Tuscany DAS

+

DAS Overview
+DAS types

+

+ +

SCA DataBinding FAQs

+ +

What is he difference between Logical Type and Physical Type? From the comments in DataType.java, logical type is used by the assembly, physical type is used by the runtime, and for Tuscany Java the physical type is always a Java Type
+ 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.
What is the role of a data mediator interceptor? Can you cite an example of how mediation works say for a component A with reference R that references a service S in component B.?
+ The interceptor gets added by the connector. A's outbound wire and B's inbound wire describe the datatypes their implementations can support. When the wire ends are connected the connector adds the interceptor if mediation is needed.
+ One job of a transport binding is to convert an in-memory physical representation to a suitable set of bits on the network (aka serialization and deserialization). Rather than reinvent the different transports we reuse existing implementations such as Axis2 or RMI. As such we need to convert the physical representation on our internal wire with that used by the transport. So, for example, Axis2 only understands AXIOM so in a reference we need to convert the user's physical representation to AXIOM and in a service we need to convert the AXIOM generated by the transport into the form the user's implementation requires. The steps could be described as follows: +
1. A calls reference R with physical Java object X(java)
2. X is placed on R's outbound wire
3. data mediation converts X(java) to AXIOM object X(axiom)
4. X(axiom) is placed on inbound wire for the Axis2 binding
5. Axis2 binding serializes X(axiom) onto the network as XML
6. Axis2 binding on the target deserializes the XML from the network to X(axiom)
7. X(axiom) is placed on the outbound wire from the Axis2 binding
8. data mediation converts X(axiom) to X(java) as needed by the target component
9. X(java) is placed on B's inbound wire
10. the target instance for B is invoked passing in X(java)
  +. An important thing to note here is that from the fabric's perspective we are dealing with two physical wires: the wire on the client connecting the source component A to the outbound Axis2 transport and the wire on the server connecting the inbound Axis2 transport to the target component B.
  +From a global perspective there is one logical wire from A to B but because A and B are located on two different runtimes that logical wire gets split into two physical wires A->net and net->B.
+

+ +

+