What methods exist to auto-generate java client stubs from WSDL files?

Question

I'm new to web-services and have read up some info about XML,SOAP,and WSDL. It's very interesting! I'm working on an existing project that has a web-service and client. However the client the 'higher ups' aren't pleased with the client application. It's too complex, they would like a more user friendly and simpler app that can be easily expanded.

The project uses Apache Axis2. I've found the WSDL files and would like to build a client based on that. However I don't want to use Axis2 for the above reasons( their opinion). I wonder how a simpler a client I can make given that I have to work with already existing code(wsdl files)Does anyone know any other methods I can use to auto generate client stubs based on the existing WSDL files? I've heard of wsimport, this should still work even if the wsdl files were created using Axis2?

Any help or tips are greatly appreciated.

Exhaustless

Answer 1

Well, we used xfire, but not the wsdl-centric approach: wsdl was created on the fly from the exposed remote interfaces. Client had the same interfaces which were mapped to the generated wsdl automagically.

AFAICS xfire evolved into CXF, and the CXF home page tells me this:

CXF supports both contract first development with WSDL and code first development starting from Java. For REST, CXF also supports a JAX-RS (TCK compliant) frontend.

As I understood you'll need wsdl2java tool to generate client-side stubs from existing WSDL file if you choose to base on wsdl. If both peers run java, then java-centric approach is applicable and quite more transparent (as service interfaces/POJOs may be shared across client/server with transport generated in runtime w/o any stub/proxy generation steps).

Airdrome

And no, there was no need for extra annotations on the interfaces or POJOs involved. A bit of offtopic, but maybe you'd take a look on RESTful web services model? This is not that datatype/structure-safe as XML (as it uses JSON) but we were able to create custom RPC protocols with 400 lines of code using Jackson JSON mapping library. – Airdrome

Thanks a lot for the feedback, I'll be working on it this week and I'll let you know what route I took. – Exhaustless

Answer 2

See Step1: Generate Skeleton Code:

To generate the skeleton and required classes, you can use the WSDL2Java tool provided in Axis2. This tool is located in the bin directory of the distribution and can be executed using the provided scripts (.bat or .sh).

$ wsdl2java.sh -uri ../samples/wsdl/Axis2SampleDocLit.wsdl -ss -sd -d xmlbeans 
    -o ../samples -p org.apache.axis2.userguide

Funk

Hi thanks, I tried this method out partially(only with the -uri flag) and it works! Upon further investigation of the existing client code it seems the original developers also used WSDL2Java to generate their client stubs. I was wondering if I can use another method perhaps that would still work with the existing axis2 auto-generated wsdl file. Otherwise I'll be using the same methods the original developers used. Creating once again the same 'too complexed' client. ( Or should I just use WSDL2Java and try my best to code it simpler?) – Exhaustless

Answer 3

One of the advantages of using SOAP is the wealth of client libraries that are available. It's best to ask your client what they preferred implementation technology is first.

Clients capable of supporting a Java or C# client will immediately declare their allegience to their favorite hammer :-)

If your client doesn't care it means they just want something that "works" and is "easy/cheap to maintain". If that is the case then I'd recommend one of the solutions given in the following answer

I'm a big fan of Axis2, but it has been my experience that CXF generates more readable code from complex WSDLs. Even so, the API is rarely useable...... WSDLs have a tendency to be over-engineered with complex and multiple levels of XML schema inheritance..... Clients always blame the code generation framework for "unreadable" client code without a thought for the interface specification that cannot be interpreted without the aid of an expensive XML design tool :-)

My advice? If you control the server-side code, then simplify the WSDL so that it validates the same SOAP message. You'll notice that the client-side code becomes a lot simpler too and you will gain a better understanding of what your web service is offering.

Alternative (if you don't control the WSDL) use a tool like SOAPUI to see the actual SOAP/XML being exchanged, and just generate those XML messages directly.

Ugo

Answer 4

Try wsimport. I have used it previously. At that time I decided against Axis2 for the very reason that it produced more complex and bloated stubs to code against.

Huge

Thanks, I tried wsimport and it created some .class files for me. Though in the .class files are readable code instead of byte code. Think I'll just change the extension to .java and try use them to build my new client application. – Exhaustless

@ghostlines: Oh! If I remember correctly you get .java files if you specify the option "-keep". – Huge

I got through to use wsimport to create my clientstub from a local wsdl file that was present in the source. I couldn't get it from the webservice itself cuz this method that I see a lot online doesn't work for me --> wsimport http://<address>:<port>/service?WSDL. And I read the client part of this tutorial jax-ws.dev.java.net/jax-ws-ea3/docs/… But I don't understand where I have to specify the address of the web service so I can use my stubs to invoke requests. Do I have to make separate soap messages and specify the endpoint and port? Help's appreciated – Exhaustless

Answer 5

I use the method described in Creating a Web Service Client in 3 Steps Using Eclipse

Corpuz

Answer 6

Spring web services could help. I recommend Spring in general.

Krum