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
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: sca-assembly@lists.oasis-open.org
- Date: Tue, 31 Mar 2009 13:29:41 +0100
Simon,
This is indeed a truly treacherous area.
Part of the problem is that the WSDL
-> Java mapping rules are dangerously simplistic.
So, to take the example that you gave
of an unsignedInt in the WSDL. Really, in no way should
this be mapped to a Java long. A
Java long allows for negative values, which cannot be the
case for the XML unsignedInt. A
"proper" mapping would be to some "new" specific class
- let me call it "xmlUnsignedInt"
- which has the correct serialization annotations attached and
which validates that its value is in
the allowed range for unsignedInt.
The JAX-WS & JAXB folks have led
everyone up the garden path by defining the default
mappings in the way that they have.
Apparently simple but in reality anything but.
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:
| Simon Nash <oasis@cjnash.com>
|
To:
| sca-assembly@lists.oasis-open.org
|
Date:
| 31/03/2009 12:37
|
Subject:
| Re: [sca-assembly] Issue 116: Interface
compatibility refers to input/output types which is ambiguous when using
WSDL 1.1 |
Mike,
Thanks for digging deeper into this. This will help as a workaround
for some of the problem cases. It's unfortunate that these annotations
and extra classes aren't generated by the WSDL to Java mapping and
need to be manually added by hand editing of the generated Java code.
Simon
Mike Edwards wrote:
>
> Folks,
>
> Well, I dug a bit more and I believe that there is a solution to the
> corner cases that Simon describes, although it is
> about as ugly as it gets.
>
> For parameters with a default mapping that is not the one required,
such
> as a Java long needing to map to an XSD
> unsignedInt, there is the possibility to use the @XmlJavaTypeAdapter
> annotation on the parameter(s) concerned
> and map them to a type that is itself mapped to an xsd:unsignedInt
using
> the @XmlSchemaType annotation.
> You will note that this not only requires the annotations but also
> requires a couple of trivial "shim" classes.
>
> I believe that this approach works, although I have not had time to
try
> it out.
>
> Why JAXB makes the remapping of parameters this hard, I have no idea.
>
>
> 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:
David Booz <booz@us.ibm.com>
> To:
sca-assembly@lists.oasis-open.org
> Date:
11/03/2009 20:03
> Subject:
Re: [sca-assembly] Issue 116: Interface compatibility
refers
> to input/output types which is ambiguous when using WSDL 1.1
>
>
> ------------------------------------------------------------------------
>
>
>
> 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_
> >
>
>
>
>
> ------------------------------------------------------------------------
>
> /
> /
>
> /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
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]