[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-assembly] Issue 116: Interface compatibility refers to input/outputtypes 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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]