Simon Laws wrote:
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
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.
Simon
