ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Ws Wiki] Update of "Tuscany/TuscanyJava/DataMediation" by Venkatakrishnan
Date Wed, 23 Aug 2006 11:13:41 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Ws Wiki" for change notification.

The following page has been changed by Venkatakrishnan:
http://wiki.apache.org/ws/Tuscany/TuscanyJava/DataMediation

------------------------------------------------------------------------------
  ## page was renamed from Tuscany/DataMediation
+ 
+ = Objective =
+ It is necessary to support the flow of any data type that is supported by both the client
and the provider. 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 (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 about 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 container and transport binding 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 wire 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. ''(Source: http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200603.mbox/%3c4418A53D.2080606@apache.org%3e)''
+ 
+ == Implementation Updates ==
+ 
  Hi,
  
  I created a prototype to demonstrate how we can support multiple databindings and transform
data accross them. The initial drop contains some basic transformer implementations for the
following databindings:

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@ws.apache.org
For additional commands, e-mail: general-help@ws.apache.org


Mime
View raw message