--------------------------------------------------
From: "ant elder" <[email protected]>
Sent: Saturday, June 06, 2009 12:00 AM
To: <[email protected]>
Subject: Re: Fwd: using webservices transparent
On Fri, Jun 5, 2009 at 7:20 PM, Raymond Feng<[email protected]>
wrote:
The problem users run in is not that POJOs don't work out-of-the-box
with
the binding.ws from Tuscany SCA.
Isn't that exaclty what this problem is in this case i've forwarded to
the dev list? They're trying to call the WeatherService web service
from a Tuscany Java client and the result is returned to the Tuscany
client as a null which is incorrect, and the service did actually
return a reponse just Tuscany didn't pass the response on to the
client, can't get much more _not_ working out-of the-box than that.
The WeatherService WS is implemented using .NET. Tuscany receives the
response in XML. The issue is how to map the XML into Java. There are
two
ways:
1) Use a non-typed in-memory Java representation of the XML, for
example,
OMElement, DOM, StAX. No type checking is performed and the XML is
unmarshaled as-is no matter whether it conforms to the XSD or not. In
such
cases, the client has to make sure the incoming data is valid.
2) Use a typed java class, for example, a POJO or JAXB, SDO generated
classes. For most databindings, it requires the XML to conform to the
XSDs
that are used to generate the java classes. In Tuscany, we use JAXB for
POJO
and JAXB mapping rules are used. Sure, you can invent something for
POJO
to
be more heuristic but it will lead to more inconsistencies too.
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.
Sure yes, I'm not questioning Tuscanys use of JAXB, I'm wondering if
there's anything else we could be doing as well to handle these other
cases better than we do today.
I agree that we need to document the best practice for POJO-based WS
though.
Documenting things is fine but working where possible would be even
better, just giving a helpful error message might be more useful than
returning null like is happening here.
To be precise, it's NOT returning null but an empty POJO.
IIUC currently we don't always work when the interface uses parameter
types that are unannotated pojos or interfaces. We regularly get posts
from users asking about these and assuming most users don't bother
emailing then this is likely a _lot_ of people who run into this issue
so if there's anything we could do it might make a big difference to
how they perceive Tuscany.
Using POJO for WS definitely imposes the Java-specific behavior. If the
POJO
cannot be accurately mapped to the XSD-compliant XML and vice versa,
there
will be interop issues.
In this example the user simply changes their interface to have the
reponse be an OMElement instead of a String and then they do get the
correct response so this _is_ a problem with Tuscany. We shouldn't be
returning null we should either throw an error saying there is a
problem with the client or much better would be to have the runtime
spot that there isn't the correct annotations and just handle the
response correctly automatically anyway. That must be possible mustn't
it as we have both the wsdl and the java interface and the impl class
so can see that its all not quite matching what JAXB needs?
As we have observed, the default behavior for JAXB unmarshaling is best
effort and to ignore the invalid XML pieces silently. We can try to see
if
there is any flag to control such thing.
