Java：Soap的快速通用网关数据

我确实希望构建一个从嵌套映射（从二进制数据流生成）到SOAP客户端的通用网关

背景：需要调用SOAP服务的非java应用程序不能生成json或SOAP/XML，但可以轻松生成自定义协议（由我们控制）

因此需要一个代理。该代理不应该在WSDL的每次更改或下一个Web服务的每次推出时都被重写

我的计划是：

• 要将url、端口和服务名称（url:端口/服务名称）作为该代理的“严格”定义参数

• 将SOAP操作作为“严格”定义的参数

• 要请求（可能缓存）url:port/service name？wsdl的wsdl，并动态（缓存）启动存根调用

• 将嵌套映射中的值填充到该存根

• 调用SOAP服务

• 将答案转换回该二进制协议

如果缺少一些必要的值，则应发送相当于SOAP错误的消息

当然，所有这些都具有较小（价格合理）的延迟、高稳定性、绝对最小的部署停机时间（用于更新）和相当大的负载

我认为有几种可能性：

a） 使用像WSO2ESB这样的ESB。在那里，我将把流格式实现为一个特殊的输入格式适配器，将其转换为内部XMLStream（至少json适配器似乎是这样工作的）并将其发送给mediator。那个调解人会尝试类似于 “创建动态客户机”并直接调用SOAP服务

b） 使用MOM中间件，比如ApacheMQ和Camel

c） 将其简化为ApacheKaraf和CXF

我有点迷失在所有这些可能性之间，而这些只是或多或少的任意样本

对未来的思考：

• 负：没有ESB目标感觉有点奇怪，因为中介将直接调用给定的SOAP请求

• 负：我想知道内部转换为XML流是否不会花费额外的时间和资源

• 减：更改代码需要重新启动WSO2ESB（据我所知）

• 另外：我可以不用url、端口、服务名称，而是定义符号名称，这些名称使用ESB-iff解析，不需要额外的毫秒

对于b）我还没有检查Camel中的格式转换有多容易，以及SOAP服务请求是否适合消息发送和排队

我已经对该主题进行了一些搜索，但由于不同产品的范围重叠，这确实令人困惑。我认为这是一个标准问题，但显然没有明显的解决办法——至少我没有找到

我真的希望得到一个线索，这些解决方案中的哪些可能导致麻烦或大量工作（哪些容易成功），我希望我的方法中有一些原因

谢谢你的评论

马可