Tuscany SCA Java - FAQ (TUSCANY) edited by haleh mahbod
Page:
http://cwiki.apache.org/confluence/display/TUSCANY/Tuscany+SCA+Java+-+FAQ
Changes:
http://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=35040&originalVersion=12&revisedVersion=13
Content:
---------------------------------------------------------------------
{section:border=true}
{column:width=15%}
{include: SCA Java Subproject Menu}
{column}
{column:width=85%}
Welcome to the Apache Tuscany Java SCA FAQ page. Please help to keep the
information on this page current.
\\
{panel:title=Apache Tuscany SCA User
Guide|borderStyle=solid|borderColor=#C3CDA1|titleBGColor=#C3CDA1|bgColor=#ECF4D1}
* [Biding Questions|#Binding Questions]
** [Can I use the EJB binding to publish an SCA services as an SLSB?
|#BindingA]
* [DataBinding Questions|#DataBinding Questions]
** [What is the difference between Logical Type and Physical
Type?|#DataBindingA]
\\
{panel}
h2. {anchor:Binding Questions}{bgcolor:#C3CDA1}Binding Questions{bgcolor}
h3. {anchor:BindingA}{bgcolor:#C3CDA1}Can I use the EJB binding to publish an
SCA services as an SLSB?
{bgcolor}
Unfortunately, we only have the reference binding support for SLSB (call
SLSB from SCA) in Tuscany at this moment. Any contribution to support SLSB
service binding is welcome. :-)
h2. {anchor:DataBinding Questions}{bgcolor:#C3CDA1}DataBinding
Questions{bgcolor}
h3. {anchor:DataBindingA}{bgcolor:#C3CDA1}What is he difference between Logical
Type and Physical Type? {bgcolor}
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. {quote}
# *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:
## A calls reference R with physical Java object X(java)
## X is placed on R's outbound wire
## data mediation converts X(java) to AXIOM object X(axiom)
## X(axiom) is placed on inbound wire for the Axis2 binding
## Axis2 binding serializes X(axiom) onto the network as XML
## Axis2 binding on the target deserializes the XML from the network to X(axiom)
## X(axiom) is placed on the outbound wire from the Axis2 binding
## data mediation converts X(axiom) to X(java) as needed by the target component
## X(java) is placed on B's inbound wire
## 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.
{column}
{section}
---------------------------------------------------------------------
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]
