More convenient way to consume JAX-RPC services?

[dan.baumann]

Hi,

My spring app consumes many JAX-RPC services, and I'm wondering wether my setup could be improved.

Currently, for each new service to be consumed, I'm doing the following:
* Generate the portInterface (and required classes) from the service's WSDL using Axis' wsdl2java tool
* Hand-craft the serviceInterface (aka buisness interface) that mirrors the portInterface but does not declare RemoteExceptions
* Add JaxRpcPortProxyFactoryBean to my applicationContext

The first two steps of this routine are dumb and repetitive, so I have the gut feeling that someone smarter than I has already come up with a more convenient way to do this. Anyone?

On a sidenote, the services I'm consuming are generated using gsoap2 to interface with a C++ app and are out of my control. The code I'm generating with wsdl2java is butt-ugly, mostly because the C++ people prefix their variable names with characters indicating the type. This means I end up with accessors like getSName() or getIAmount() and so on. I really don't want to expose those ugly interfaces to my app, so I'm thinking about writing adapters for each service - which would be another repetitive step I'd rather spare myself. How does everyone else handle this?

Thanks in advance,
Dan

[ajit]

Hi ,
I have integrated apache axis in the Spring framework without using
JAXRpcProxyFactoryBean.I will thanlful to you if you kindly show some light on how to use JAXRpcProxyFactoryBean.A sample will be very helpful
With regards,
Ajit

[dan.baumann]

Sorry to disappoint you,

but I recently ran into problems with Axis ignoring my deserializers for custom types (see http://forum.springframework.org/viewtopic.php?t=3556 ), and now I'm also back to using plain Axis - and I'm quite unhappy with this.

For a sample, check out the latest beta of Spring from CVS, it contains additional documentation regarding JAX-RPC/Axis.

BTW, I ended up building adapters for most of the services I consume, just so I could clean up the interface and translate error codes into proper exceptions, and so on.

Regards,
dan

[jcej]

With respect to hand-crafting your wrapper I would suggest creating a custom XDoclet plugin to do that for you. You could even go so far as to give it a properties file (or similar) to map the ugly names to nicer ones.

If you haven't written an XDoclet plugin it can be a bit intimidating at first but once you're over the hurdle it has tremendous power.

[dan.baumann]

I guess that XDoclet could improve the situation, but it would also further complicate the build process.

Since I have to hand-craft those wrappers anyway, e.g. to map error codes to exceptions, I decided to do the clean-up manually, too.

Creating the new names programmatically seems like it's not an option (it would result in some different but still ugly names), so even if I used XDoclet, I would have to specify the name mapping explicitly.

But thanks for your suggestion!