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.

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

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

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.

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.

Answer 5

我使用在使用Eclipse的3个步骤中创建Web服务客户端中描述的方法

Answer 6

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