Re: Problems with SOAP encoding

From: Paulo Jose Pinto <paulo.pinto_at_ALTITUDE.COM>
Date: Mon, 08 Jul 2002 18:53:27 +0100

> -----Original Message-----
> From: Public discussion on JAX-RPC
> [mailto:JAXRPC-INTEREST_at_JAVA.SUN.COM]On Behalf Of John Keyes
> Sent: segunda-feira, 8 de Julho de 2002 17:22
> Subject: Re: Problems with SOAP encoding
> Hi Paulo,
> On Mon, 2002-07-08 at 17:06, Paulo Jose Pinto wrote:
> > Hello everyone,
> >
> > I have a problem similar to the thread
> > entitled "SOAP encoding related problem".
> >
> > I need to be able to generate client stubs
> > from RMI interfaces or from WSDL.
> >
> > I've discovered that when the stubs are generated
> > from the RMI interface, they expect the response
> > in SOAP encoded format.
> >
> > But not all the web services that may application
> > might use, reply using SOAP encoded messages.
> >
> > Is there any way to say which encoding format I
> > want to use ?
> It is the responsibility of the tool that generates
> the stub code for you to handle this. The stubs
> will be generated in a binding specific manner i.e.
> you will need different stubs for a HTTP binding
> and a SOAP binding.

Well, I will be using xrpcc. As our requirements are
to use the JWSDP pack.

> Most toolkits provide the functionality to set the
> style and use for SOAP; where style can be
> 'document' or 'rpc' and the use can be 'encoded'
> or 'literal'.
> Remember, the stubs are generated from the WSDL,
> and the WSDL is the API contract. So the correct
> way to set the encoding format ('use') that you want
> is by editing the WSDL.
> -John K

My team will develop a tool that will generate stubs by
generating all the files that are required to serve as
input to xrpcc.

So our idea is:

  - Only code is available -> Generate RMI interfaces
   and the config.xml for xrpcc.

  - Only the WSDL is available -> Generate config.xml
   for xrpcc.

The problem is that xrpcc is generating stubs that
expect 'SOAP envelops' as answers, when using RMI interfaces.

The tool that I am refering to, will be used to generate Java
stubs for web-services that aren't done in Java.

The idea is to be able to read a bunch of files and generate a
single jar with all the information about the webservices exported
by those files.

Paulo Pinto