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
