WSDL到Java还是Java到WSDL？

我最近接了一个项目，它的构建过程相当糟糕。JAXB读取手工编码的XSD模式，生成类和工厂的Java模型，用于手工编码的Java web服务类（带注释），然后将这些类部署到服务器上，它用作从中读取完整WSDL的源，以便生成第二个基于Java的模型，该模型包括用于客户端程序的完整WSDL的服务和工厂类

这听起来很可怕，我不认为我需要这么复杂，所以在某个阶段，我想把这些都扔掉

• 手工制作WSDL，生成完整模型并添加服务代码
• 或-编写服务和模型类，并在运行时根据需要在服务器上生成WSDL

无论哪种方式，我都希望最终为服务器和客户端都可以使用的模型提供一个源库，并为模型应该是什么提供一个“真相来源”，而目前我觉得我有几个

---

目前我倾向于第二种选择，但你会选择哪一种？您会使用哪种技术？

我认为可以使用简单的HTTP GET过程手动或通过简单的代码调用（ant任务等）而不是您描述的复杂过程来检索WSDL和模式。话虽如此，我通常处理具有发布周期的web服务，因此我通常手动获得wsdl和模式

---

如果您必须在每个构建中重新获取wsdl和模式，我倾向于将get过程作为一个初步步骤放在构建中（在maven中，这将是初始化阶段，我将考虑使用），然后是wsdl2java步骤（在maven中，我通常将wsdl2java ant任务挂接到生成源代码阶段）。

最干净的方法是手动或使用设计器生成WSDL，并从中生成代理和存根

这种方式背后的逻辑是，WSDL定义了服务契约，服务契约应该是实现无关的——Java类是实现特定的——并且这些实现细节通常被传递到WSDL

确切的问题取决于您使用的Java-to-WSDL转换器（或者更重要的是，Java-to-XSD转换器），但它们非常常见，特别是如果您计划在您的环境中添加非Java服务器或客户端

如果您喜欢用Java编写服务，那么应该遵循一些将实现锁定最小化的准则，如：

• 控制从类到XSD的转换（我相信这可以通过注释来实现）
• 仅使用简单类型和简单类型的聚合作为参数（不要将常规类作为参数传递）

---

最近，我采用了从wsdl自动生成Java类的方法。因此，我使用了Apache cxf项目中的wsdl2java.bat

---

我不得不做一些小改动（XmlElementWrapper）对于名称空间的集合和一些修复，但其他一切都很好。

在我正在进行的项目中，我们目前正在完全重新制作我们的web服务。这些服务通过SOAP向客户端提供服务器功能。从我所学的了解到，该协议的所有复杂之处都会对web服务的布局产生重大影响SDL，我不想自己编写WSDL。有太多的事情你可能会出错（特别是当涉及到参数样式之类的事情时）。一旦你的WSDL“存在”，并且从该WSDL生成的客户机愉快地与你的应用程序通信，你就不能再更改它了（或者你开始考虑一个版本控制策略，这可能会很痛苦）

因此，我强烈建议您使用Java编写服务代码，并让您的库为您生成WSDL。然后，您可以非常轻松地使用不同的绑定样式（这反过来会影响与其他客户端的互操作性）。这里有一篇非常详尽的文章，介绍了所有这些内容：

此外，WSDL对人类来说不是特别可读，因此（至少在我看来）人类更难维护。另一方面，Java代码相当容易阅读（或者至少可以这样编写），这是手工编写Java代码而不是WSDL的更好理由

---

希望这有助于您做出决定。

一旦您将web服务和Java完全视为两件不同的事情，这种方法将有一定的意义

鉴于此序言，手工编写XSD的原因是为了避免Java类型污染方法参数

问题有两个方面：类型定义、语言限制。JAX-RPC类型web服务生成的类型不适合许多非Java使用者使用。 Java小组一直在努力解决这个问题，我觉得JAX-WS基本上解决了这两个问题之一。在编程语言（XML是一种语言）的上下文之外定义web服务的尝试是手工编写数据定义的原因

---

正如许多人指出的那样，WSDL生成很困难，最好使用生成WSDL的工具或IDE来完成—这样，传输就不再是一个问题了。通过这种方式，XSD被包含到您的WSDL中，并且当您“手工编码”XSD时，您将可以控制您的内容。

一种方法是使用XML模式（XSD）定义一个模型。一旦定义了这个模型，您就可以定义服务接口（WSDL），它使用模型中的对象（XSD）作为服务的输入/输出

这定义了抽象服务和模型层

然后，您可以使用自己喜欢的工具和技术来开发