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 Thu, 08 Jul 2010 21:21:22 GMT
Simon Laws wrote:
> On Wed, Jul 7, 2010 at 7:31 PM, Simon Nash <nash@apache.org> 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
>>> 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
> 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
I don't see how we could justify allowing an implementation that returns
OMElement (the equivalent of xsd:anyType) to be exposed as a component
service with a WSDL that declares the return type as xsd:string.


View raw message