0

我的环境的前提：我在 Spring 3 上运行，使用 spring-ws 来处理所有 SOAP 需求。我已经与不同的供应商进行了多次集成，没有这方面的问题。

问题：这个最近的集成有一个供应商运行非常古老的东西，他们的 WSDL 使用 rpc 绑定样式。不用说，JAXWS 并不完全支持 rpc（这是正确的，因为它是互操作的对立面）。

可能的解决方案 #1：我仍然可以尝试使用 Axis 1 在他们的 WSDL 上生成存根。事实上我已经这样做了，但是我非常不愿意将 Axis 依赖项引入我的 pom.xml 中。我很确定会有大量的库冲突，可能会破坏目前非常稳定的环境。

可能的解决方案#2：我可以尝试将他们的 WSDL 重写为 JAXWS 能够解析的文档/文字。遇到一些实际重写 WSDL 的问题（Getting "Schema descriptor {xxx}xxx in message part "xxx" is not defined and could not be bound to Java"）。此外，如果他们的端点专门检查 rpc，无论如何我都搞砸了。

可能的解决方案#3：我可以部署一个全新的盒子，专门运行 Axis 和这个服务客户端。即主项目对该框进行 REST 调用，该框发出 SOAP 请求并解析响应。这样做似乎是一种非常非常愚蠢的方式（并且对于应该很简单的事情进行了大量的工作）。

我错过了任何解决方案吗？此外，我一直在为此搜索谷歌，虽然有些人在#1 方面取得了成功，但没有人真正谈论过之后的后果。（即处理 Axis 的遗留依赖项，尝试让 Axis 在 Spring 3 中发挥出色，等等）

4

1 回答 1

0

#1

使#1 更稳定的一种方法是让自己获得 Axis 源的本地副本，您将使用它来构建自己的 Axis jar 副本。但是你改变了整个东西的包装。例如，而不是 org.apache.axis，它变成了 com.mycompany.org.apache.axis，翻译变得非常机械。

然后，Axis1 的任何依赖项（可能像旧版本的 commons-beanutils）都会得到相同的处理。加载他们的罐子。用您自己的定制包装构建他们的罐子。（如果他们使用 Maven 构建，确定依赖关系会更容易一些。）

这样做确实牺牲了将更新和修复合并到原始 Axis 代码的能力。任何已发布的更新都会变成一组更改，您必须弄清楚如何将其合并到本地副本中，其中每个 .java 文件都对packageandimports行进行了更改。

#2

不知道#2。它是掷骰子，不是吗。

#3

您在#3 中所做的是 ESB 真正擅长的。3 号是您编写自己的迷你翻译器的地方。我已经做到了，它工作得很好。

但是您实际上可以在同一个盒子上构建第 3 步。你不需要另一个盒子。您将小翻译应用程序部署为在主端口上运行的单独应用程序。您将应用程序部署在不同的端口或作为不同的 URL/路径。翻译器应用程序使用 Axis1 并翻译传入的消息，将其传递并翻译回响应。

这个解决方案的一个好处是它处理负载平衡就像你有一个应用程序一样。翻译器应用程序和主应用程序的负载一起上升，耗尽了它们共享的 CPU 周期桶。如果您需要更多，请添加更多设置完全相同的服务器。

于 2013-04-04T18:17:46.433 回答