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 18:31:22 GMT
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
> rfeng@apache.org <mailto:rfeng@apache.org>
> /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
>>
> 


Mime
View raw message