Answers inline where I think I know - hopefully Raymond can supply
more detail as needed.
On Jan 20, 2007, at 10:20 PM, Comain Chen wrote:
Thanks for your answer, it helps me a lot.
I have additional questions about databinding, hopfully any one can
give me
some hints.
1. "That makes the requirement on a binding that it be able to
support
transformation between a representation used in the runtime and the
representation the user is using. Representations used in the
runtime
include bytes from the transport layer, instances supplied by
other user
components, and instances used by the runtime
itself."
Can I say that, representation used by the user is a
databinding
the user typically prefer.Representation
the runtime is using, include XMLStreamReaders(interact
with the
transport stream), instances suppied by
other components --- databindings other component developers
prefer, and instances used by the runtime.
However what is instances used by the runtime itself, can
any one
give me an example?
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.
2. What are the 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. If I have 2 DataType objets,
that
have databinding and physical type in common but
have different logical type. They are different datatype
instances; therefore, they should be mediated using
some transformer. However, in the databidng graph in
transformer
registry, they are on the same vertex(Since
they have the databinding in common). This seems odd,
where am I
going wrong?
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.
3. Where is the data mediator interceptor? For a component A
with reference r references services s in
component B. Where is the data binding interceptor? A's
outbound
side before targetInvker or B's inbound
side? What is the relationship with binding? Typically if
reference r and service s both use ws binding, the
data transformation steps are: Data represented by data
binding A
--> Data represented by Axiom
(in Axis2TargetInvker)--->Stream on the transport--->Data
represented by Axiom--->Data represented by
data binding B. So, 5 steps involved, step 1 is in A's outbound
side, step 2, 3 are done by Axis runtime, Step 4
is in B's inbound side. Is it right?
Raymond can probably give more info but I view the interceptor as
being 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.
I'd describe the steps as:
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
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
