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>]

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.

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.

> 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.

> 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?

> 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
>