tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Nash <n...@apache.org>
Subject Re: Interface contract mapping and remote interfaces
Date Wed, 07 Jul 2010 16:41:33 GMT
Simon Laws wrote:
> I have some more comprehensive local changes for TUSCANY-3616 now and
> needless to say this causes many of our tests to fail. Some of this is
> legitimate where we just have the WSDL for the test wrong. Other cases
> are different. There first one I've found is here [1]. The component.
> HelloWorldComponent
> Defines a Java operation as follows.
> public OMElement getGreetings(OMElement om)
> Which is described by a provided WSDL where the input and return types
> of this operation are of type
> xsd:string
> The response from ?wsdl will therefore be sensible from the external
> user point of view. However the WSDL generated from the Java for
> matching purposes will describe the input and output values as
> xsd:anyType.
> This would seem to be a special binding.ws case that Tuscany supports.
> I.e. the ability to have a service process the raw message structure
> while having the real service interface described through a provided
> WSDL. It feels similar to the specified JMS binding behaviour where,
> using the default wire format, a component can implement onMessage().
> Assuming that this is true then I'll need to add a special case in the
> matching logic.
> [1] http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/itest/ws/endpoints/src/main/resources/org/apache/tuscany/sca/binding/ws/axis2/WSDLExplicitURI.composite
> Simon
This seems like an issue with the spec that should be raised in OASIS.

If an implementation's introspected Java interface has a parameter type
that maps to xsd:anyType then the service can presumably handle any type
for the parameter value.  So if the WSDL used in a component definition
specifies a more restrictive parameter type such as string, int, etc.,
this should always be acceptable to the implementation.  This shouldn't
just be true for Tuscany but for all SCA implementations.

There could be other similar cases, e.g., if the implementation parameter
type is long and the WSDL parameter type in the component definition is int.
As a int parameter can always be converted to a long, this could be
considered as a valid match.

For return types, the opposite applies.  So if the implementation return
type is xsd:anyType (as in the HelloWorldComponent example) it wouldn't be
valid to expose this implementation in a component definition using a WSDL
with a return type of xsd:string.  This is because the implementation could
return data of some other type that isn't valid to represent as a string.

This is a tricky area and I don't think it's advisable for Tuscany to use
different compatibility rules than what the spec says, except as a
temporary expedient until the spec can be revised.


View raw message