OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

[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


Dave,
Sorry, I only just saw this response.  See comments inline.

   Simon

David Booz wrote:
> See below
> 
> 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 <oasis@cjnash.com> wrote on 03/04/2009 06:57:43 AM:
> 
>  > [image removed]
>  >
>  > Re: [sca-assembly] Issue 116: Interface compatibility refers to
>  > input/output types which is ambiguous when using WSDL 1.1
>  >
>  > Simon Nash
>  >
>  > to:
>  >
>  > sca-assembly
>  >
>  > 03/04/2009 07:04 AM
>  >
>  > David Booz wrote:
>  > > 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,
>  > Apologies for not explaining my concerns more clearly.  I completely
>  > agree that WSDL and Schema should be central.  The use cases that
>  > I have identified as causing a problem are completely consistent
>  > with that perspective.
>  >
>  > Using the approach that you and I both agree on, a service would be
>  > designed around WSDL and schema, implemented in Java, and used by
>  > Java clients.  Let's say this service has a single method with a
>  > single parameter of schema type xsd:unsignedInt.
>  >
>  > The Java implementation of this service would use the WSDL to Java
>  > mapping to generate a Java interface for the service.  This interface
>  > would have a method whose parameter type is long.  The Java service
>  > implementation of the method would also have a parameter type of long.
>  > This service implementation would be published using interface.wsdl
>  > with a WSDL portType defining the parameter type as xsd:unsignedInt.
>  > So far, so good.
>  >
>  > Now I would like to create a Java client to call this service.
>  > I would use the WSDL to Java mapping from the service's WSDL to create
>  > a Java client interface.  The Java interface would have a method whose
>  > parameter type is long, and my Java client would call this method
>  > passing a long value, taking care to stay within the constraint that
>  > the long value must contain an unsigned int.  My Java client reference
>  > would have an introspected interface type of interface.java, with a
>  > single method taking a long parameter.
>  >
>  > Unfortunately, the rules that Mike has proposed would not allow this
>  > reference to be wired to this service.  Mike's rule would be to convert
>  > the reference's Java interface into WSDL using the Java to WSDL mapping,
>  > and compare the resulting WSDL with the service's WSDL.  This comparison
>  > would fail as incompatible, because the Java to WSDL mapping would
>  > produce a type of xsd:long in the generated WSDL, which is not the same
>  > as the xsd:unsignedInt type in the service's WSDL interface.
>  >
> 
> Why does the reference have a Java interface?  Surely the source
> controlled interface is WSDL, not Java, and that's what will appear in
> the SCA composite.  The wire matching will work fine.  The client
> component is certainly free to use the Java mapping if it wants to
> when implementing the client.
> 
The interface in the component type will always have a Java interface
because it's introspected from the Java implementation.  It would be
possible to configure the component with a WSDL interface for the
reference, but this brings the compatibility rules into play just as
if wiring were being done.  So the scenario that I have outlined
would apply in this case also.

> It is also possible that the client chose to use a Java interface in the
> SCA composite (either derived from WSDL or by some other means), in which
> case the situation you describe below could occur.  As I said, I think
> that's a corner case.
> 
By default the interface in the composite would be the Java interface
introspected from the implementation.  If this was mapped from WSDL
using the JAX-WS WSDL to Java mapping, I think it should be OK to leave
it in place and not override it.  I believe the proposal that I made
allows for this case.

>  > I have tried the above case using the JAX-WS wsimport and wsgen tools
>  > from Java 6.  I started with WSDL and schema, and used wsimport to
>  > generate Java.  The generated Java interface and wrapper classes contain
>  > various annotations like @RequestWrapper, @WebParam and @XMLSchemaType.
>  > Despite the presence of these annotations, the Java to WSDL mapping
>  > performed by wsgen fails to recognize that the long type in the Java
>  > interface is intended to be an xsd:unsignedInt rather than an xsd:long,
>  > and it generates a schema definition that uses xsd:long.
>  >
>  > I have read the JAX-WS and JAXB specs to try to find a solution or
>  > workaround to this, and I have experimented with various edits to
>  > the generated Java code, but I have not been able to come up with a
>  > solution.
>  >
> 
> I'll have to take a look at the specs. I thought there was a side file
> containing metadata to describe/record what mapping was done so that
> a round trip mapping would be possible.
> 
For some cases I think the mapping is round-trippable by virtue
of the annotations inserted in the generated Java code.  It appears
that this doesn't work for all cases.

Also, other languages may have mappings to and from WSDL that are not
defined as round-trippable.  The assembly rules should cater for this
situation and should not depend on round-trippability.

>  > Now consider how my alternative proposal would solve this problem.
>  > Instead of mapping the reference's Java interface to WSDL and doing
>  > the comparison based on WSDL, I am proposing to map the service's
>  > WSDL interface to Java and compare the Java interfaces.  This works,
>  > because the parameter type is long in both cases.
>  >
> 
> So what about the reverse case, where the WSDL is used on the client
> but the service uses a Java interface?  In order to make your idea
> work, we'd have to say that when Java is involved, the non-Java IDL
> must be mapped to Java and then compared Java to Java.  Is this
> going to work for all languages?
> 
This is definitely against the principle that interoperable services
should be exposed using WSDL interfaces.  Any service exposed using
a non-WSDL interface is likely to only be interoperable with a
client that uses the same interface type.

   Simon

>  > The key difference in my approach is that it uses the WSDL to Java
>  > mapping and not the Java to WSDL mapping.  This is what we want,
>  > because it's consistent with the schema-centric top-down approach
>  > which also uses the WSDL to Java mapping.  In contrast, the Java to
>  > WSDL mapping is used for the bottom up case that you and I agree is
>  > a corner case, and it is not desirable to use it as part of the
>  > reference/service compatibility checking.
>  >
>  >    Simon
>  >
>  > >
>  > > 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
>  > >
>  > > Inactive hide details for Simon Nash ---03/03/2009 10:34:41 AM---See
>  > > comments inline. SimonSimon 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
>  > >
>  > >
>  > >
>  >
>  >
>  >
>  > ---------------------------------------------------------------------
>  > 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]