Re: [sca-assembly] Issue 116: Interface compatibility refers to input/outputtypes which is ambiguous when using WSDL 1.1

[David Booz <booz@us.ibm.com>]

Simon,

The non-round trippable cases you identified are in fact corner cases for SCA. XML schema as a means for describing data is one of the core design points in SCA's relationship to SOA patterns and how those patterns deal with data in service contracts. This core design point (as I see it) further centers on the exchange of data in document form. Therefore, the mapping of XML schema to some implementation technology is critical, as well as that technology's ability to retain XML fidelity even after the mapping. We see this in Java with SCA's "recommendation" to use JAXB and SDO as technologies for handling data. Bottom up Java interfaces being built in the traditional way, with individual parameter data items is not at the center of the SCA value proposition. In fact, Java is not even at the center of the SCA value proposition, IMHO. WSDL and XML Schema are at the center.


Dave Booz
STSM, BPM and SCA Architecture
Co-Chair OASIS SCA-Policy TC and SCA-J TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093 or 8-295-6093
e-mail:booz@us.ibm.com

Simon Nash ---03/03/2009 10:34:41 AM---See comments inline. Simon

From:	Simon Nash <oasis@cjnash.com>
To:	OASIS Assembly <sca-assembly@lists.oasis-open.org>
Date:	03/03/2009 10:34 AM
Subject:	Re: [sca-assembly] Issue 116: Interface compatibility refers to input/output types which is ambiguous when using WSDL 1.1

---

See comments inline.

   Simon

Anish Karmarkar wrote:
> Two comments inlined below.
> 
> -Anish
> -- 
> 
> Simon Nash wrote:
>> Mike Edwards wrote:
>>>
>>> Folks,
>>>
>>> Comments inline
>>>
>>> Yours,  Mike.
>>>
>>> Strategist - Emerging Technologies, SCA & SDO.
>>> Co Chair OASIS SCA Assembly TC.
>>> IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
>>> Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  Email:  
>>> mike_edwards@uk.ibm.com
>>>
>>> Simon Nash <oasis@cjnash.com> wrote on 02/03/2009 10:24:04:
>>>
>>>  > [image removed]
>>> <snip>
>>>  > > Outline --
>>>  > > 1) Use the WSDL 1.1 interface as the canonical interface 
>>> language and
>>>  > > require that "sameness" be determined after the interfaces are 
>>> mapped to
>>>  > > WSDL 1.1.
>>>  >  >
>>>  > I don't think this is the right solution.  We don't require (and 
>>> shouldn't
>>>  > require) that all SCA interfaces must be mappable to WSDL.  The 
>>> requirement
>>>  > should be that the SCA interface types of the source and target 
>>> interface
>>>  > define mappings that can be applied to the target interface to 
>>> produce
>>>  > a representation of the target interface in the source interface 
>>> language.
>>>  >
>>>
>>> I disagree.  I think that for remotable interfaces, it is right and 
>>> reasonable
>>> to require that all interface types map to WSDL.  If this is not 
>>> done, then you
>>> have a difficult n x n mapping table to construct - and worse, I 
>>> think it will
>>> be hard to know whether any particular binding can be used for that 
>>> remotable
>>> interface.
>>>
>>> The requirement for mapping to WSDL allows a much simpler approach 
>>> both to
>>> comparison of interfaces and also to the application of bindings.
>>>
>>> For local interfaces, WSDL mapping should not be a requirement, but 
>>> there,
>>> the restrictions on mapping of interfaces will need to be spelled out.
>>>
>> The proposed text is for the wiring section.  Wiring applies to local
>> interfaces as well as remotable interfaces.  Any rules for wiring need
>> to apply to both local and remotable interfaces.  The text proposed
>> by Anish does not meet this requirement.
>>
> 
> Although the proposed text is for the wiring section. It should not be. 
> I did not include that in my proposal as I knew that either you or I 
> would be filing a separate issue for that (and you already have).
> 
> Mixing of interfaces applies not just to wires but also to promotions, 
> overriding interfaces specified in componentTypes (but configuring 
> components).
> 
I agree, and this comment would apply for all these cases as well,
as there's no  guarantee that the interfaces in question would be
mappable to WSDL.

>> The question about whether all remotable interfaces are required to be
>> mappable to WSDL is a separate issue.  Currently, there is nothing in
>> the Assembly specification saying this and there is no open issue
>> concerning this.  A number of interface specifications are owned by
>> other TCs and IMO the Assembly specification should not impose this as
>> a requirement on all of those other TCs and the interface specifications
>> that they create.  Each interface specification should state whether or
>> not its remotable interfaces MUST be mappable to WSDL.  Having these
>> other specs require this and define the mapping to WSDL would be the
>> normal case.  For example, I think this mapping should be required and
>> defined for remotable Java interfaces.
>>
>> I believe the alternative text that I have proposed is sufficient to
>> define wiring rules without the need to mention WSDL.  I am not sure
>> what the difficulty is with the application of bindings.  Please can
>> you give more details of this.
>>
>> Requiring the compatibility test to be performed on mapped WSDL
>> doesn't work for some cases.  Consider the following examples:
>> 1. A service uses interface.wsdl and a reference uses interface.java.
>>    In this case the service interface needs to be mapped from
>>    WSDL to Java and the compatibility test needs to be applied to
>>    the reference's Java interface and the WSDL->Java mapping of the
>>    service's interface.  It would not be valid to map the reference's
>>    interface from Java to WSDL using the Java->WSDL mapping and apply
>>    the compatibility test to this mapped interface and the service's
>>    interface, because the WSDL that will be used on the wire is the
>>    service's WSDL and not the generated Java->WSDL mapping of the
>>    reference.
> 
> I'm not sure I understand this.
> If it is compatible, how does it matter whether it was generated or not?
> 
> Not an assembly issue, but does JAX-WS take care of around tripping?
> Also, since JAX-WS defines annotations for mapping, wouldn't it be 
> always better to go from Java->WSDL?
> 
These mappings are not round-trippable, and always going from Java->WSDL
could produce either false positives or false negatives.  I posted one
example in my other recent email.  This is a tricky area and requires
careful thought.

   Simon

> 
>> 2. A service uses interface.java and a reference uses interface.java.
>>    The compatibility test needs to be applied directly to these Java
>>    interfaces.  It would not be valid to to map them both to WSDL
>>    and apply the compatibility test to the generated WSDL, because
>>    of the false positives that could occur if different Java types
>>    map to the same WSDL type.
>>
>>   Simon
>>
>>> <snip>
>>>  >
>>>  >    Simon
>>>  >
>>>  > > -Anish
>>>  > > --
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> /
>>> /
>>>
>>> /Unless stated otherwise above:
>>> IBM United Kingdom Limited - Registered in England and Wales with 
>>> number 741598.
>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire 
>>> PO6 3AU/
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 
> 



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php