<<Re-posted since the previous one is
missing the diagram>>
Hi,
I think I have an interesting picture for this topic.
1) 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).
a. Each databinding is mapped to a vertex.
b. If databinding A can be transformed to databinding B, then an edge will
be added from vertex A to vertex B.
c. The weight of the edge is the cost of the transformation from the source
to the sink.
2) In the data mediator/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.
Any thoughts?
Thanks,
Raymond
I think I have an interesting picture for this topic.
1) 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).
a. Each databinding is mapped to a vertex.
b. If databinding A can be transformed to databinding B, then an edge will
be added from vertex A to vertex B.
c. The weight of the edge is the cost of the transformation from the source
to the sink.
2) In the data mediator/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.
Any thoughts?
Thanks,
Raymond
----- Original Message -----
From: "Jeremy Boynes" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, March 15, 2006 3:37
PM
Subject: Data flow on a wire
> be exchanged on the wire during an interaction between a client and a
> provider. The spur for this was the JSON binding Ant was working on
> which has no obvious affinity to XML.
>
> Another issue related to this has been about supporting streaming types
> for interactions where data flows through a system rather than
> terminating there. This is related to Axiom and its use for precisely
> this purpose in Axis2.
>
> I wanted to capture thoughts whilst still current and open the discussion.
>
> As I see it there is no single answer to this, well apart from "it
> depends." :-) I think it is necessary for us 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.
>
> Given the flow issue descibed above and the XML nature of many our
> interactions I would suggest that a StAX XMLStreamReader may be the most
> apporpriate common format (at least for now). It's native to Axis2 and
> Raymond has posted patches already to support it in SDO.
>
> Alternatively, we don't need all of StAX for this to work so it may be
> simpler to provide a basic API that is essentially the same as an
> XMLStreamReader but without all the other stuff.
>
> Thanks for reading this far. The idea was to capture thinking and all
> input is welcome.
> --
> Jeremy
