有哪些方法可以从 WSDL 文件自动生成 java 客户端存根？答案

【问题标题】：What methods exist to auto-generate java client stubs from WSDL files?有哪些方法可以从 WSDL 文件自动生成 java 客户端存根？
【发布时间】：2010-07-23 09:06:50
【问题描述】：

我是 Web 服务的新手，并且已经阅读了一些关于 XML、SOAP 和 WSDL 的信息。这很有趣！我正在开发一个具有 Web 服务和客户端的现有项目。然而，客户“高层”对客户应用程序并不满意。它太复杂了，他们想要一个更用户友好、更简单、易于扩展的应用程序。

该项目使用 Apache Axis2。我找到了 WSDL 文件，并希望以此为基础构建一个客户端。但是，出于上述原因（他们的意见），我不想使用 Axis2。我想知道如果我必须使用已经存在的代码（wsdl 文件），我可以制作一个更简单的客户端有没有人知道我可以使用任何其他方法来根据现有的 WSDL 文件自动生成客户端存根？我听说过 wsimport，即使 wsdl 文件是使用 Axis2 创建的，这应该仍然有效？

非常感谢任何帮助或提示。

【问题讨论】：

标签： java wsdl axis2

【解决方案1】：

嗯，我们使用了 xfire，但不是以 wsdl 为中心的方法：wsdl 是从公开的远程接口动态创建的。客户端具有自动映射到生成的 wsdl 的相同接口。

AFAICS xfire 演变成 CXF，CXF home page 告诉我：

CXF 先支持两个合约使用 WSDL 和代码优先进行开发从Java开始开发。为了 REST，CXF 还支持一个 JAX-RS（TCK 兼容）前端。

据我了解，如果您选择基于 wsdl，您将需要 wsdl2java 工具从现有 WSDL 文件生成客户端存根。如果两个对等点都运行 java，那么以 java 为中心的方法是适用的并且更加透明（因为服务接口/POJO 可以在客户端/服务器之间共享，在运行时生成传输而无需任何存根/代理生成步骤）。

【讨论】：

不，不需要对涉及的接口或 POJO 进行额外注释。有点离题，但也许你会看看 RESTful Web 服务模型？这不是 XML 的数据类型/结构安全（因为它使用 JSON），但我们能够使用 Jackson JSON 映射库创建具有 400 行代码的自定义 RPC 协议。
非常感谢您的反馈，我这周会继续努力，我会告诉你我走的路线。

【解决方案2】：

见Step1: Generate Skeleton Code:

要生成骨架和所需的类，您可以使用 Axis2 中提供的 WSDL2Java 工具。该工具位于发行版的 bin 目录中，可以使用提供的脚本（.bat 或 .sh）执行。

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

【讨论】：

嗨，谢谢，我部分地尝试了这个方法（仅使用 -uri 标志）并且它有效！在对现有客户端代码进行进一步调查后，似乎最初的开发人员也使用 WSDL2Java 来生成他们的客户端存根。我想知道我是否可以使用另一种方法，也许仍然可以与现有的axis2自动生成的wsdl文件一起使用。否则，我将使用原始开发人员使用的相同方法。再次创建相同的“过于复杂”的客户端。（或者我应该只使用 WSDL2Java 并尽力编写更简单的代码？）

【解决方案3】：

试试wsimport。我以前用过。那时我决定反对 Axis2，因为它产生了更复杂和臃肿的存根来编写代码。

【讨论】：

谢谢，我尝试了 wsimport，它为我创建了一些 .class 文件。尽管在 .class 文件中是可读代码而不是字节代码。我想我只需将扩展名更改为 .java 并尝试使用它们来构建我的新客户端应用程序。
@ghostlines：哦！如果我没记错的话，如果你指定选项“-keep”，你会得到 .java 文件。
我通过使用 wsimport 从源中存在的本地 wsdl 文件创建我的 clientstub。我无法从 web 服务本身获取它，因为我在网上看到很多这种方法对我不起作用 --> wsimport http://
:/service?WSDL。我阅读了本教程的客户端部分jax-ws.dev.java.net/jax-ws-ea3/docs/… 但我不明白我必须在哪里指定 Web 服务的地址，以便我可以使用我的存根来调用请求。我是否必须制作单独的肥皂消息并指定端点和端口？帮助表示赞赏

【解决方案4】：

使用 SOAP 的优势之一是可用的大量客户端库。最好先询问您的客户他们首选的实施技术是什么。

能够支持 Java 或 C# 客户端的客户将立即宣布他们效忠于他们最喜欢的锤子 :-)

如果您的客户不在乎，这意味着他们只想要“有效”且“易于维护/维护成本低”的东西。如果是这种情况，那么我会推荐以下answer

中给出的解决方案之一

我是 Axis2 的忠实粉丝，但根据我的经验，CXF 从复杂的 WSDL 生成更具可读性的代码。即便如此，API 也很少可用...... WSDL 倾向于过度设计复杂和多层次的 XML 模式继承......客户端总是将“不可读”的客户端代码归咎于代码生成框架不考虑没有昂贵的 XML 设计工具就无法解释的接口规范 :-)

我的建议？如果您控制服务器端代码，则简化 WSDL 以便它验证相同的 SOAP 消息。您会注意到客户端代码也变得更加简单，并且您将更好地了解您的 Web 服务所提供的内容。

替代方案（如果您不控制 WSDL）使用像 SOAPUI 这样的工具来查看正在交换的实际 SOAP/XML，然后直接生成这些 XML 消息。

【讨论】：

【解决方案5】：

我使用Creating a Web Service Client in 3 Steps Using Eclipse 中描述的方法

【讨论】：

【解决方案6】：

Spring web services 可以提供帮助。我一般推荐 Spring。

【讨论】：