用于处理异步HTTP请求/响应的体系结构：ESB与Async Http客户端库

Question

我们正在开发一个应用程序集成器，它同时向各种Web服务发送请求，聚合每个Web服务返回的数据并将其格式化以显示在UI上。每个Web服务都可能具有专有的xml格式。此外，我们不会妥协用户体验。

我们为此要求确定了ESB（Servicemix / Mule）和Async Http Client。

有谁能建议哪个更好？ Async Http Client看起来很合适，因为它比servicemix更轻巧。

谢谢， 阿米特帕特尔

Answer 1

你也可以只使用Apache Came l ......

它支持各种components和messaging patterns，是轻量级的，并且具有灵活的部署模型（独立，弹簧，专家，webapp，OSGi等）。

Answer 2

你已经回答了自己的问题。是的，ESB是不错的选择。您可以使用Mule。

第二个选项是异步消息，但它很复杂，因为你必须正确地协调服务。

Answer 3

根据您的要求，我建议您使用WSO2 ESB。它和100％免费和开源的ESB（Apache License 2）和其他ESB不同，wso2你没有商业和社区版本。因此，来自WSO2的download for free包含其他ESB供应商的“商业版本”中提供的所有功能。此外，WSO2不仅提供ESB，还提供满足您SOA需求的完整SOA平台。

对于您上面提到的要求，您可以试用simple sample。

Answer 4

呃，我们在编写纯java与ESB（mule和spring集成）的编码时进行了生产力测试。我们有3个开发人员在所有3个版本中都做同样的事情（mule，SI，只有纯Java，没有ESB）。当他们不使用ESB时，他们的速度提高了6倍，我们在问题中提供了很多可以利用ESB的东西，但最终它没有帮助......所有的xml编码和api用法的混乱导致了真正的非生产性开发团队。不仅如此，在市场上也很难找到ESB开发人员。

注意：我们甚至采用了一个先进的弹簧集成工具，而且他在纯java中也更快完成代码。他喜欢春季融合，在参加考试后，他改变了主意。

即。请注意使用错误框架可能导致的巨大生产力损失。 6次是一个巨大的惩罚。我的意思是1个月对6个月是一个很大的区别。

生产力损失6倍，值得花一周时间进行自己的开发人员生产力测试。有些人和我争辩说他们还不知道框架，这就是为什么我们有一个先进的弹簧集成人来参加测试。

另外，请确保您的测试至少花费一个小时左右....只需从您要编写的应用程序中开发一些虚假但实际的要求，以便在运行研究时在应用程序上取得进展。我很想看到更多的结果发布。