Re: Data flow on a wire

[ant elder <an...@gmail.com>]

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 <jb...@apache.org> 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
>

Re: Data flow on a wire

[Jeremy Boynes <jb...@apache.org>]

ant elder wrote:
> 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.
> 

I don't think it belongs there - I think the primary reasons that you
would want to import a WSDL are to get its portType/interface
declarations or to be able to map service references to endpoints. I
don't see how that relates to the format on a local wire.

We ran into the question a few days ago of how to import SDO types into
the system. I think this is fairly similar in that you are referring to
a type of data binding (SDO) and want to add a new instance (the Type
you are importing).

We can address a new type of data binding through the use of a namespace
URI - this would be the target namespace in which the <import> element
would be defined. It would be good to reuse that concept to specify the
data binding to be used. Something like ...

<module xmlns:sdo="the sdo data binding ns">
   <sdo:import schemaLocation="path to a schema"/>

   <entryPoint name="...">
      <interface.java ...>
      <binding.ws port="portURI" dataBinding="sdo"/>
      <reference>target...

where dataBinding="sdo" refers to the namespace prefix declared at the
to and tells the ws transport binding which data binding to use. The
user could also use the data binding's namespace URI instead of the prefix.

Each data binding implementation would need to declare a namespace in
order to specify an import so I don't think we're adding a lot of
complexity here (from the user's perspective :-) ) but we don't end up
being restricted to a hard-coded set of data bindings. We will need to
define an SPI that lets the transport binding talk to the data binding
to deserialize the data.


Another alternative is to let the user specify data conversion
interceptors that should be engaged. For example, something like:

   <binding.ws port="portURI"/>
   <reference>
     <target>component
     <dataBinding in="axiom" out="sdo"/>

where the dataBinding element is handled by the wire builders and
ensures the appropriate interceptor is engaged.

--
Jeremy