All this sounds quite complicated and unlikely to get done in the near
future, so as an interim solution how about adding a parameter to specify
the data binding to use for WS messages and having something like an XML
data binding that puts a StAX XML stream for the SOAP body as the payload of
the Tuscany message. That way if you're wiring an WS entryPoint to an E4X or
XSLT component or directly to a WS externalService then you specify the XML
data binding so there's no conversion to the Java object types.
The data binding could be a parameter on the WS binding along the lines of:
<binding.ws dataBinding= "XML | SDO | JAXB | ..." port="..."/>
Or maybe it could go on the import.wsdl element.
...ant
On 3/23/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
>
> Raymond Feng wrote:
> > 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?
> >
>
> Nicely summarized.
> --
> Jeremy
>
