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:
>>>
>>>
>>> Simon Nash <> 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
>
>
