On Wed, Jul 7, 2010 at 7:31 PM, Simon Nash <[email protected]> wrote: > Raymond Feng wrote: >> >> 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. > > Was this an informal discussion, or a formal OASIS spec issue that was > closed with no action? > > Simon > >> Thanks, >> Raymond >> /________________________________________________________________ Raymond >> Feng >> [email protected] <mailto:[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 >>> >> > >
I think we should try and keep this as simple as possible. At least for now. Saying interfaces have to be the same is pretty clear. I'm trying to identify those cases where we deviate from this and raised the OMElement case as we have explicit tests for it so it must be important to someone. I don't want to disable features if I can avoid it and there is a good reason for them (and we can justify them in the context of the spec or a Tuscany specific extension to the spec). On the other hand I don't want to go in and support a lot more flexibility that people are not asking us for and seem tricky to implement. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
