You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@tuscany.apache.org by Martin Thoma <m....@b2m-software.de> on 2009/06/05 13:42:36 UTC

using webservices transparent

Hello,

I am trying to integrate an external web service(represented by WSDL) in a SCA component within the Tuscany platform (Version 1.3.1). The web services is specified as reference in the component composite, as well as annotated in implementation code(see below). The example that I implemented was similar to the xml-bigbank example in the tuscany 1.3.1 version. With the examples (see code below), I got different results. But I want to use a transplant solution provided by the tuscany framework, where I don't have to use generated stub code(e.g. from axis2 wsdl2java) in the implementation(client) code.    

As a first step  I developed a external test webservice operated on axis2 server(outside the tuscany framework).

To use this web service in the tuscany platform, I declared this interface, which represents external web service(inside tuscany framework):

 
	@Remotable
	public interface TestService{
		Result foo(Request r);
	}



with Result and Request as normal POJO classes.

The binding in client.composite:
	<reference name="testService">
		<binding.ws wsdlElement="http://targetnamespace/#wsdl.port(TestService/TestServiceSoap)" />
	</reference>

the corresponding wsdl
	<?xml version="1.0" encoding="utf-8"?>
		<wsdl:definitions targetNamespace="http://targetnamespace/"
			xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
		<wsdl:import namespace="http://targetnamespace/"
			location="http://localhost/testservice?wsdl" />
		</wsdl:definitions>

		
the TestClient (implementation of remotable interface):

	@Reference 
	protected TestService testService;
	...
	Request r = new Request();
	Result rs = testService.foo(r);

	
and everything works fine (no axis,axis2, etc. stuff in client code) ;-)


Now I tried to integrate a foreign external webservice 

(URI: http://www.webservicex.net/WeatherForecast.asmx?wsdl):

The interface:
	@Remotable
	public interface WeatherService  {
    	GetWeatherByPlaceNameResult GetWeatherByPlaceName(String placeName) throws java.rmi.RemoteException;
	}

and again with GetWeatherByPlaceNameResult as POJO class.

The binding 
      <reference name="weather">
    	    <binding.ws wsdlElement="http://www.webservicex.net#wsdl.port(WeatherForecast/WeatherForecastSoap)" />
	    </reference>

the corresponding wsdl
	<?xml version="1.0" encoding="utf-8"?>

		<wsdl:definitions targetNamespace="http://www.webservicex.net"
			xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
		<wsdl:import namespace="http://www.webservicex.net"
			location="http://www.webservicex.net/WeatherForecast.asmx?wsdl" />
		</wsdl:definitions>
		
and the TestClient:

	@Reference
	protected WeatherService weather;
	...
	GetWeatherByPlaceNameResult result = weather.GetWeatherByPlaceName("New York");
	System.out.println(result.getPlaceName());

but this time the POJO is always empty !

If I changed the interface WeatherService to

	@Remotable
	public interface WeatherService  {
	     OMElement GetWeatherByPlaceName(String placeName) throws java.rmi.RemoteException;
	}
	
I got the data but this is not transparent anymore!

Any ideas why the GetWeatherByPlaceNameResult object is always empty ?


Mit freundlichem Gruß / Kind regards

Martin Thoma


Re: Fwd: using webservices transparent

Posted by Simon Nash <na...@apache.org>.
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" <an...@gmail.com>
> Sent: Friday, June 05, 2009 9:30 AM
> To: <de...@tuscany.apache.org>
> 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 <en...@gmail.com>
>> Date: Fri, Jun 5, 2009 at 4:40 PM
>> Subject: Re: using webservices transparent
>> To: user@tuscany.apache.org
>>
>>
>> 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



Re: Fwd: using webservices transparent

Posted by Raymond Feng <en...@gmail.com>.
+1 to create a bunch of itests for various POJO styles. We can then look 
into them case by case to discuss if the scenario is reasonable. This will 
help us build up the best practices.

Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <an...@apache.org>
Sent: Monday, June 15, 2009 12:54 AM
To: <de...@tuscany.apache.org>
Subject: Re: Fwd: using webservices transparent

> On Fri, Jun 12, 2009 at 4:40 PM, Raymond Feng<en...@gmail.com> wrote:
>
>> There are two ways, either enhance our JAXB support (such as smarter
>> mapping, better documents, better messages) or reinvent a new POJO/XML
>> mapping. I'm inclining to the first approach.
>>
>
> If we can get some "smarter mapping" that makes some of the cases work
> that currently fail that would be wonderful. How shall we we get that
> done? Should we create some itests that show what we'd like and then
> get the code changed so the tests work?
>
>   ...ant 


Re: Fwd: using webservices transparent

Posted by ant elder <an...@apache.org>.
On Fri, Jun 12, 2009 at 4:40 PM, Raymond Feng<en...@gmail.com> wrote:

> There are two ways, either enhance our JAXB support (such as smarter
> mapping, better documents, better messages) or reinvent a new POJO/XML
> mapping. I'm inclining to the first approach.
>

If we can get some "smarter mapping" that makes some of the cases work
that currently fail that would be wonderful. How shall we we get that
done? Should we create some itests that show what we'd like and then
get the code changed so the tests work?

   ...ant

Re: Fwd: using webservices transparent

Posted by Raymond Feng <en...@gmail.com>.
If you can come up a better story than what JAXB can do for POJOs, go ahead. 
There are two ways, either enhance our JAXB support (such as smarter 
mapping, better documents, better messages) or reinvent a new POJO/XML 
mapping. I'm inclining to the first approach.

Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <an...@apache.org>
Sent: Friday, June 12, 2009 4:34 AM
To: <de...@tuscany.apache.org>
Subject: Re: Fwd: using webservices transparent

> Ok? Are you saying those links are the solutions and we shouldn't do
> anything over what jaxb supports?
>
>  ...ant
>
> On Tue, Jun 9, 2009 at 5:04 PM, Raymond Feng<en...@gmail.com> wrote:
>> Let's step back and get all the issues on the table first:
>>
>> 1) JAXB default rules for POJO to XML namespace mapping is not
>> straightforward
>>
>> 2) JAXB silently ignores the XML elements/attributes that are not 
>> conforming
>> to the XSD. As a result, some of the POJO propeties are left unpopulated.
>> https://jaxb.dev.java.net/guide/Unmarshalling_is_not_working__Help_.html
>>
>> 3) JAXB cannot handle POJO interfaces
>> https://jaxb.dev.java.net/guide/Mapping_interfaces.html
>>
>> 4) JAXB cannot handle non JavaBeans
>> https://jaxb.dev.java.net/guide/XML_layout_and_in_memory_data_layout.html
>>
>> Thanks,
>> Raymond
>> --------------------------------------------------
>> From: "ant elder" <an...@apache.org>
>> Sent: Tuesday, June 09, 2009 2:58 AM
>> To: <de...@tuscany.apache.org>
>> Subject: Re: Fwd: using webservices transparent
>>
>>> On Sat, Jun 6, 2009 at 7:31 PM, Raymond Feng<en...@gmail.com> wrote:
>>>>
>>>>
>>>> --------------------------------------------------
>>>> From: "ant elder" <an...@apache.org>
>>>> Sent: Saturday, June 06, 2009 12:00 AM
>>>> To: <de...@tuscany.apache.org>
>>>> Subject: Re: Fwd: using webservices transparent
>>>>
>>>>> On Fri, Jun 5, 2009 at 7:20 PM, Raymond Feng<en...@gmail.com> 
>>>>> 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.
>>>>
>>>
>>> I'm not questioning the use of JAXB, I'm questioning if there are
>>> other things we could be doing as well as or along side of JAXB to
>>> make this easier and work more seemlessly for some of the cases that
>>> today just fail. These questions come up a lot, for example there are
>>> three going on currently - this thread and [1] and [2], and for every
>>> user that does send an email to the user list there's likely lots more
>>> users who hit these problems but don't bother emailing.
>>>
>>> So for example with using interfaces as parameter types is there
>>> really nothing we can do? What about if the service interface uses
>>> interfaces but the implementation uses concrete implementations
>>> couldn't we get it to work by finding those impl classes, or even
>>> using cglib to generate mock classes for the interfaces?
>>>
>>> And for the unannotated pojo cases what about ways for "smoothing over
>>> differences" as suggested in TUSCANY-2992. Or could the runtime try
>>> alternative datatbindings when JAXB doesn't work?
>>>
>>>  ...ant
>>>
>>> [1] http://apache.markmail.org/message/eelvu7onmpyfxb5x
>>> [2] https://issues.apache.org/jira/browse/TUSCANY-2992
>>>
>> 

Re: Fwd: using webservices transparent

Posted by ant elder <an...@apache.org>.
Ok? Are you saying those links are the solutions and we shouldn't do
anything over what jaxb supports?

  ...ant

On Tue, Jun 9, 2009 at 5:04 PM, Raymond Feng<en...@gmail.com> wrote:
> Let's step back and get all the issues on the table first:
>
> 1) JAXB default rules for POJO to XML namespace mapping is not
> straightforward
>
> 2) JAXB silently ignores the XML elements/attributes that are not conforming
> to the XSD. As a result, some of the POJO propeties are left unpopulated.
> https://jaxb.dev.java.net/guide/Unmarshalling_is_not_working__Help_.html
>
> 3) JAXB cannot handle POJO interfaces
> https://jaxb.dev.java.net/guide/Mapping_interfaces.html
>
> 4) JAXB cannot handle non JavaBeans
> https://jaxb.dev.java.net/guide/XML_layout_and_in_memory_data_layout.html
>
> Thanks,
> Raymond
> --------------------------------------------------
> From: "ant elder" <an...@apache.org>
> Sent: Tuesday, June 09, 2009 2:58 AM
> To: <de...@tuscany.apache.org>
> Subject: Re: Fwd: using webservices transparent
>
>> On Sat, Jun 6, 2009 at 7:31 PM, Raymond Feng<en...@gmail.com> wrote:
>>>
>>>
>>> --------------------------------------------------
>>> From: "ant elder" <an...@apache.org>
>>> Sent: Saturday, June 06, 2009 12:00 AM
>>> To: <de...@tuscany.apache.org>
>>> Subject: Re: Fwd: using webservices transparent
>>>
>>>> On Fri, Jun 5, 2009 at 7:20 PM, Raymond Feng<en...@gmail.com> 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.
>>>
>>
>> I'm not questioning the use of JAXB, I'm questioning if there are
>> other things we could be doing as well as or along side of JAXB to
>> make this easier and work more seemlessly for some of the cases that
>> today just fail. These questions come up a lot, for example there are
>> three going on currently - this thread and [1] and [2], and for every
>> user that does send an email to the user list there's likely lots more
>> users who hit these problems but don't bother emailing.
>>
>> So for example with using interfaces as parameter types is there
>> really nothing we can do? What about if the service interface uses
>> interfaces but the implementation uses concrete implementations
>> couldn't we get it to work by finding those impl classes, or even
>> using cglib to generate mock classes for the interfaces?
>>
>> And for the unannotated pojo cases what about ways for "smoothing over
>> differences" as suggested in TUSCANY-2992. Or could the runtime try
>> alternative datatbindings when JAXB doesn't work?
>>
>>  ...ant
>>
>> [1] http://apache.markmail.org/message/eelvu7onmpyfxb5x
>> [2] https://issues.apache.org/jira/browse/TUSCANY-2992
>>
>

Re: Fwd: using webservices transparent

Posted by Raymond Feng <en...@gmail.com>.
Let's step back and get all the issues on the table first:

1) JAXB default rules for POJO to XML namespace mapping is not 
straightforward

2) JAXB silently ignores the XML elements/attributes that are not conforming 
to the XSD. As a result, some of the POJO propeties are left unpopulated.
https://jaxb.dev.java.net/guide/Unmarshalling_is_not_working__Help_.html

3) JAXB cannot handle POJO interfaces
https://jaxb.dev.java.net/guide/Mapping_interfaces.html

4) JAXB cannot handle non JavaBeans
https://jaxb.dev.java.net/guide/XML_layout_and_in_memory_data_layout.html

Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <an...@apache.org>
Sent: Tuesday, June 09, 2009 2:58 AM
To: <de...@tuscany.apache.org>
Subject: Re: Fwd: using webservices transparent

> On Sat, Jun 6, 2009 at 7:31 PM, Raymond Feng<en...@gmail.com> wrote:
>>
>>
>> --------------------------------------------------
>> From: "ant elder" <an...@apache.org>
>> Sent: Saturday, June 06, 2009 12:00 AM
>> To: <de...@tuscany.apache.org>
>> Subject: Re: Fwd: using webservices transparent
>>
>>> On Fri, Jun 5, 2009 at 7:20 PM, Raymond Feng<en...@gmail.com> 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.
>>
>
> I'm not questioning the use of JAXB, I'm questioning if there are
> other things we could be doing as well as or along side of JAXB to
> make this easier and work more seemlessly for some of the cases that
> today just fail. These questions come up a lot, for example there are
> three going on currently - this thread and [1] and [2], and for every
> user that does send an email to the user list there's likely lots more
> users who hit these problems but don't bother emailing.
>
> So for example with using interfaces as parameter types is there
> really nothing we can do? What about if the service interface uses
> interfaces but the implementation uses concrete implementations
> couldn't we get it to work by finding those impl classes, or even
> using cglib to generate mock classes for the interfaces?
>
> And for the unannotated pojo cases what about ways for "smoothing over
> differences" as suggested in TUSCANY-2992. Or could the runtime try
> alternative datatbindings when JAXB doesn't work?
>
>   ...ant
>
> [1] http://apache.markmail.org/message/eelvu7onmpyfxb5x
> [2] https://issues.apache.org/jira/browse/TUSCANY-2992
> 

Re: Fwd: using webservices transparent

Posted by ant elder <an...@apache.org>.
On Sat, Jun 6, 2009 at 7:31 PM, Raymond Feng<en...@gmail.com> wrote:
>
>
> --------------------------------------------------
> From: "ant elder" <an...@apache.org>
> Sent: Saturday, June 06, 2009 12:00 AM
> To: <de...@tuscany.apache.org>
> Subject: Re: Fwd: using webservices transparent
>
>> On Fri, Jun 5, 2009 at 7:20 PM, Raymond Feng<en...@gmail.com> 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.
>

I'm not questioning the use of JAXB, I'm questioning if there are
other things we could be doing as well as or along side of JAXB to
make this easier and work more seemlessly for some of the cases that
today just fail. These questions come up a lot, for example there are
three going on currently - this thread and [1] and [2], and for every
user that does send an email to the user list there's likely lots more
users who hit these problems but don't bother emailing.

So for example with using interfaces as parameter types is there
really nothing we can do? What about if the service interface uses
interfaces but the implementation uses concrete implementations
couldn't we get it to work by finding those impl classes, or even
using cglib to generate mock classes for the interfaces?

And for the unannotated pojo cases what about ways for "smoothing over
differences" as suggested in TUSCANY-2992. Or could the runtime try
alternative datatbindings when JAXB doesn't work?

   ...ant

[1] http://apache.markmail.org/message/eelvu7onmpyfxb5x
[2] https://issues.apache.org/jira/browse/TUSCANY-2992

Re: Fwd: using webservices transparent

Posted by Raymond Feng <en...@gmail.com>.

--------------------------------------------------
From: "ant elder" <an...@apache.org>
Sent: Saturday, June 06, 2009 12:00 AM
To: <de...@tuscany.apache.org>
Subject: Re: Fwd: using webservices transparent

> On Fri, Jun 5, 2009 at 7:20 PM, Raymond Feng<en...@gmail.com> 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.

>
>  ...ant 


Re: Fwd: using webservices transparent

Posted by ant elder <an...@apache.org>.
On Fri, Jun 5, 2009 at 7:20 PM, Raymond Feng<en...@gmail.com> 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.

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

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.

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?

  ...ant

Re: Fwd: using webservices transparent

Posted by Raymond Feng <en...@gmail.com>.
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" <an...@gmail.com>
Sent: Friday, June 05, 2009 9:30 AM
To: <de...@tuscany.apache.org>
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 <en...@gmail.com>
> Date: Fri, Jun 5, 2009 at 4:40 PM
> Subject: Re: using webservices transparent
> To: user@tuscany.apache.org
>
>
> 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. 


Fwd: using webservices transparent

Posted by ant elder <an...@gmail.com>.
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 <en...@gmail.com>
Date: Fri, Jun 5, 2009 at 4:40 PM
Subject: Re: using webservices transparent
To: user@tuscany.apache.org


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.

Re: using webservices transparent

Posted by Raymond Feng <en...@gmail.com>.
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.

Thanks,
Raymond
--------------------------------------------------
From: "Martin Thoma" <m....@b2m-software.de>
Sent: Friday, June 05, 2009 4:42 AM
To: <us...@tuscany.apache.org>
Subject: using webservices transparent

> Hello,
>
> I am trying to integrate an external web service(represented by WSDL) in a 
> SCA component within the Tuscany platform (Version 1.3.1). The web 
> services is specified as reference in the component composite, as well as 
> annotated in implementation code(see below). The example that I 
> implemented was similar to the xml-bigbank example in the tuscany 1.3.1 
> version. With the examples (see code below), I got different results. But 
> I want to use a transplant solution provided by the tuscany framework, 
> where I don't have to use generated stub code(e.g. from axis2 wsdl2java) 
> in the implementation(client) code.
>
> As a first step  I developed a external test webservice operated on axis2 
> server(outside the tuscany framework).
>
> To use this web service in the tuscany platform, I declared this 
> interface, which represents external web service(inside tuscany 
> framework):
>
>
> @Remotable
> public interface TestService{
> Result foo(Request r);
> }
>
>
>
> with Result and Request as normal POJO classes.
>
> The binding in client.composite:
> <reference name="testService">
> <binding.ws 
> wsdlElement="http://targetnamespace/#wsdl.port(TestService/TestServiceSoap)" 
> />
> </reference>
>
> the corresponding wsdl
> <?xml version="1.0" encoding="utf-8"?>
> <wsdl:definitions targetNamespace="http://targetnamespace/"
> xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
> <wsdl:import namespace="http://targetnamespace/"
> location="http://localhost/testservice?wsdl" />
> </wsdl:definitions>
>
>
> the TestClient (implementation of remotable interface):
>
> @Reference
> protected TestService testService;
> ...
> Request r = new Request();
> Result rs = testService.foo(r);
>
>
> and everything works fine (no axis,axis2, etc. stuff in client code) ;-)
>
>
> Now I tried to integrate a foreign external webservice
>
> (URI: http://www.webservicex.net/WeatherForecast.asmx?wsdl):
>
> The interface:
> @Remotable
> public interface WeatherService  {
>    GetWeatherByPlaceNameResult GetWeatherByPlaceName(String placeName) 
> throws java.rmi.RemoteException;
> }
>
> and again with GetWeatherByPlaceNameResult as POJO class.
>
> The binding
>      <reference name="weather">
>        <binding.ws 
> wsdlElement="http://www.webservicex.net#wsdl.port(WeatherForecast/WeatherForecastSoap)" 
> />
>     </reference>
>
> the corresponding wsdl
> <?xml version="1.0" encoding="utf-8"?>
>
> <wsdl:definitions targetNamespace="http://www.webservicex.net"
> xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
> <wsdl:import namespace="http://www.webservicex.net"
> location="http://www.webservicex.net/WeatherForecast.asmx?wsdl" />
> </wsdl:definitions>
>
> and the TestClient:
>
> @Reference
> protected WeatherService weather;
> ...
> GetWeatherByPlaceNameResult result = weather.GetWeatherByPlaceName("New 
> York");
> System.out.println(result.getPlaceName());
>
> but this time the POJO is always empty !
>
> If I changed the interface WeatherService to
>
> @Remotable
> public interface WeatherService  {
>      OMElement GetWeatherByPlaceName(String placeName) throws 
> java.rmi.RemoteException;
> }
>
> I got the data but this is not transparent anymore!
>
> Any ideas why the GetWeatherByPlaceNameResult object is always empty ?
>
>
> Mit freundlichem Gruß / Kind regards
>
> Martin Thoma
>