I raised similar issues before with OASIS to discuss if we should take type inheritance into consideration when we check the interface compatibility. Both Java and XML support type inheritance. In fact, xsd:anyType is the base type for all XSD types. We didn't reach any conclusions.
Thanks, Raymond ________________________________________________________________ Raymond Feng [email protected] Apache Tuscany PMC member and committer: tuscany.apache.org Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com Personal Web Site: www.enjoyjava.com ________________________________________________________________ On Jul 7, 2010, at 9:41 AM, Simon Nash wrote: > 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. > > Simon >
