[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-assembly] NEW ISSUE: Interface compatibility refers to input/outputtypes which is ambiguous when using WSDL 1.1
Anish Karmarkar wrote: > Four comments inlined below. > > -Anish > -- > > Simon Nash wrote: >> See comments inline. >> >> Simon >> >> Mike Edwards wrote: >>> >>> Logged as Issue 166: _http://www.osoa.org/jira/browse/ASSEMBLY-116_ >>> >>> 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 >>> >>> >>> From: Anish Karmarkar <Anish.Karmarkar@oracle.com> >>> To: OASIS Assembly <sca-assembly@lists.oasis-open.org> >>> Date: 26/02/2009 07:46 >>> Subject: [sca-assembly] NEW ISSUE: Interface compatibility refers >>> to input/output types which is ambiguous when using WSDL 1.1 >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> >>> Title: Interface compatibility refers to input/output types which is >>> ambiguous when using WSDL 1.1 >>> >>> Description: >>> In ASM60017 it states: >>> "compatibility between the source interface and the target interface for >>> a wire for the individual operations is defined as compatibility of the >>> signature, that is operation name, input types, and output types MUST be >>> the same." >>> >>> There are two problems with this: >>> 1) We allow different interface languages to be used in SCA, so it is >>> not clear how the operation name and type comparison would be made to >>> determine if they are the "same". >>> 2) When using WSDL 1.1 interface, there are two "types" allowed: XML >>> Schema element decl or XML Schema type. How is "sameness" determined in >>> a case where the reference uses XML Schema element decl and the service >>> uses a XML Schema type. >>> >>> Proposal: >>> >>> 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. >> > > Thanks for pointing this out. I had forgotten that we don't require > mapping to WSDL. > I'm curious why the mapping must be source->target ? > Won't it be right to allow either source->target or target->source ? > What happens if mapping between interface type A and type B is defined, > but mapping from B to A is not defined? > I originally thought the mapping could go either way, as you are suggesting. On further thought, I convinced myself that the mapping has to be applied to the target and not the source. I'll take you through my thought process to see if I can convince you too :-) To illustrate this, let's consider Java and WSDL interfaces. The mapping from WSDL to Java would be used when I have an existing Web service with a WSDL definition and I want to create a Java client that can call that Web service, without changing the Web service. The mapping from Java to WSDL would be used when I have an existing Java implementation and I want to create a Web service that exposes this Java implementation, without changing the Java implementation. The WSDL resulting from this mapping would be used by clients (in any language) calling my Web service. In both of these cases the mappings were applied in the same direction: from the service contract to the client contract. This is why I have said that the target's interface needs to be mapped into the source interface language and compared with the source interface. Let's examine what would go wrong if the mapping is done the other way round. Suppose I have a service S defined using a WSDL interface with an operation A taking an xsd:unsignedInt parameter. The WSDL to Java mapping of xsd:unsignedInt is long, so if I have a Java client interface with a method A taking a long (let's say this was generated from the service WSDL by wsdl2java), this should be compatible with service S. However, the Java to WSDL mapping of long is xsd:long. So if I map from the client's Java interface to a WSDL interface using the Java to WSDL mapping, the result is a WSDL containing xsd:long, not xsd:unsignedInt. If the compatibility test is applied to this generated WSDL and the service's WSDL, these types are not the same and the compatibility test would fail. I don't think we want this. The counter-argument is that the Java client might actually be putting a long value in the long parameter rather than an unsigned int. This wouldn't work very well if sent to the service. Despite this, I think a service to client mapping and compatibility comparison will produce better results than a client to service mapping and compatibility comparison. Simon >>> 2) Two interfaces A and B, where A uses XML Schema element decl and B >>> uses XML Schema type are considered incompatible. >>> >> I'm OK with this. >> >>> Text change -- >>> replace ASM60017 with: >>> "compatibility between the source interface and the target interface for >>> a wire for the individual operations is defined as compatibility of the >>> signature, that is operation name, input types, and output types MUST be >>> the same, ***after the interfaces are mapped to WSDL 1.1 portTypes***." >>> >> Alternative proposal: >> 1. Do not make the above change to ASM60017. >> 2. Remove the following later paragraph that talks about interface types >> being equivalent: >> "A Wire can connect between different interface languages (eg. Java >> interfaces and WSDL portTypes) in either direction, as long as the >> operations defined by the two interface types are equivalent. They >> are equivalent if the operation(s), parameter(s), return value(s) >> and faults/exceptions map to each other." > > I'm fine with this. > >> 3. Add a new normative paragraph number 6 after ASM60019 as follows: >> "6. If the source and target interfaces have different SCA interface >> types representing different interface languages (e.g., Java >> interfaces >> and WSDL portTypes), the target interface MUST be mappable into the >> source interface language using mapping rules defined by the >> SCA interface type of the target interface and/or the SCA interface >> type of the source interface. [ASM600xx] In addition, the criteria >> specified in numbered points 1 through 5 above MUST be satisfied >> when applied to the source interface and the mapped target interface. >> [ASM600xx]" > > Not sure why target->source is important. > >> >>> add addition text as follows: >>> WSDL 1.1 message parts can point to XML Schema element declaration or >>> XML Schema types. When determining compatibility between two WSDL >>> operations, a message part that points to an XML Schema element >>> declaration is considered to be incompatible with a message part that >>> points to an XML Schema type. >>> >> Should this go in section 7.5 (WSDL interface type)? > > That would make sense. > >> >> Simon >> >>> -Anish >>> -- >>> >>> --------------------------------------------------------------------- >>> 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]