我确实想构建一个从嵌套映射（从二进制数据流生成）到 SOAP 客户端的通用网关。
背景：需要调用 SOAP-Services 的非 java-application 无法生成 json 或 SOAP/XML，但可以轻松生成自定义协议（在我们的控制之下）。
所以需要代理。不应在每次更改 WSDL 或推出下一个 Web 服务时重写该代理。
我的计划是：
将 url、port 和 service-name (url:port/service-name) 作为该代理的“严格”定义参数，
将 SOAP 操作作为“严格”定义的参数
请求（可能缓存） url:port/service-name?wsdl 的 wsdl 并动态启动存根调用（缓存），
将嵌套映射中存在的值填充到该存根
调用 SOAP 服务
将答案转换回该二进制协议。
如果缺少一些必要的值，它应该发送等效的 SOAP-Error。
当然，所有这些都具有小（负担得起的）延迟、高稳定性、绝对最小的部署停机时间（用于更新）和相当大的负载。
我看到了几种可能性：
a) 使用像 WSO2ESB 这样的 ESB。在那里，我将流格式实现为特殊的输入格式适配器，将其转换为内部 XMLStream（至少 json-adapter 似乎是这样工作的）并将其发送给中介。该调解员会尝试类似 http://today.java.net/pub/a/today/2006/12/13/invoking-web-services-using-apache-axis2.html “创建动态客户端”并调用直接使用 SOAP 服务。
b) 使用像 ApacheMQ 这样的 MOM 中间件和 Camel，
c) 将其简化为 Apache Karaf 和 CXF
我有点迷失在所有这些可能性之间，而这些只是或多或少是各种任意样本。
对a）的想法：
减号：没有 ESB-Target 感觉有点奇怪，因为中介会直接调用给定的 SOAP-Requests
减：我想知道内部转换成 XML-Stream 是否不会花费额外的时间和资源
减号：据我所知，更改代码需要重新启动 WSO2ESB
另外：我可以定义使用 ESB 解析的符号名称，而不是 url、端口、服务名称——如果不需要额外的毫秒。
对于 b) 我还没有检查这些格式转换在 Camel 中的难易程度以及 SOAP-Service-Requests 是否适合消息发送和队列。
我已经对该主题进行了一些搜索，但是由于完全不同的产品的重叠范围，这确实令人困惑。我认为这是一个标准问题，但显然没有明显的解决方案 - 至少我没有找到它们。
我确实希望了解这些解决方案中的哪些可能会导致麻烦或大量工作（以及哪些容易成功），并且我希望我的方法中有一些原因。
感谢任何合格的评论！
马可