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

混江龙づ霸主 提交于 2019-11-29 02:24:07

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

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

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.

Mark O'Connor

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.

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

标签
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!