Raymond Feng wrote:
The problem users run in is not that POJOs don't work out-of-the-box
with the binding.ws from Tuscany SCA. If you use the POJOs at both
server and client side, it will work. The issue arises when the client
uses hand-craft POJOs to talk to WSDL based WS (for example, those from
.NET) or another WS implementation (such as pure Axis2).
Different WS stacks have different mapping rules to deal with POJO
to/from XML conversions. It's only guaranteed that you the POJO would
work with the same runtime and tool or you start with the same POJO at
both server and client sides.
JAXB is the only industry standard that defines the default Java/XML
mapping rules for unannotated POJOs. It also provides the capability to
enrich the POJOs with more accurate XML mappings so that it will
produces the XML payment conforming to the XSD on the server side.
I don't think moving away from JAXB will solve the problem at all. It
might get one framework happier but it probably screws the others.
I agree that we need to document the best practice for POJO-based WS
though.
Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <[email protected]>
Sent: Friday, June 05, 2009 9:30 AM
To: <[email protected]>
Subject: Fwd: using webservices transparent
This comes up from users over and over again, i've not looked into the
details of whats going on but wonder isn't there something we could do
so that Tuscany works out-of-the-box when using parameters that are
interfaces or unannotated POJOs? There must be some way we can
recognize those cases and either configure the databinding to just
work or even use cglib to generate classes that workwith the
databinding framework couldn't we?
...ant
---------- Forwarded message ----------
From: Raymond Feng <[email protected]>
Date: Fri, Jun 5, 2009 at 4:40 PM
Subject: Re: using webservices transparent
To: [email protected]
We use JAXB internally to support POJO for WS/XML. The POJOs are
mapped to/from XML following the JAXB rules. If you have an external
WSDL/XSD, you are recommended to use wsimport tool to generate the
Java interface which accurately represents the WSDL/XSD. Please see an
example at:
https://svn.apache.org/repos/asf/tuscany/branches/sca-java-1.x/samples/zipcode-jaxws/
(We actually use the same WS as you do :-).
Of course you can still handcraft the POJOs, but you might have to add
a few JAXB annotations to map the namespaces. To unmarshal the XML
into JAXB/POJO, if a property is not found, it is ignored. That's why
you see the empty data.
In general this seems like the correct behavior. Web services are
intended to support loose coupling and this should mean that types
on the client and server ends don't need to match exactly. If a
type returned by the server has extra properties that the client
doesn't understand, as could happen when the type version at the
server end is newer than the type version at the client end, it
seems better to make an attempt to give the client something it
can deal with, instead of raising an error and stopping. The same
issue would occur in reverse when the client passes a type to the
server with more properties than the server understands.
Perhaps there are some cases where Tuscany could infer that the
above situation doesn't apply, and an error should be raised.
Some possible examples:
1) a Java type with no properties at all
2) a Java type that doesn't have properties corresponding to
all mandatory elements in the schema
Simon
