我已经使用过SOAP，但我从未使用过SOA，ESB和其他企业应用程序集成模式。我发现有关ESB的文档非常令人困惑。
我不太了解ESB的内容。我知道这是一个概念，描述了企业作为公交车的网络，而不是真正具体的东西，但仍然。
我可以理解，ESB提供与旧服务的协议和消息转换，允许编排，并且消息目标的逻辑由ESB完成。但我也认为ESB是不同ESB服务器之间的中间件（而不仅仅是Web服务接口）。
如果我以ServiceMix为例，我认为在不同服务器上安装多个ServiceMix平台是很自然的，这些平台通过公共总线/协议（NMR？JMS？）进行交互。因此，我在ServiceMix（a）上使用CAMEL创建的服务（例如，通过使用一些Web服务）可以使用ServiceMix上的服务（b）也使用CAMEL创建。
因此，如果我的服务需要其他服务，我只会提及其标识符，ESB会将我的请求路由到正确的ServiceMix平台。
但是，当我读到ServiceMix的示例时，在我看来，ServiceMix最初被用作独立的应用程序服务器。不是服务器集群。
ESB只是一个提升的应用服务器吗？ （让它提供的集成功能分开）
SOA中是否存在多个ESB？它们是否与ESB内部的协议相关联？或者，在ESB（a）上实现的服务是否必须提供像SOAP这样的外部接口，以便ESB（b）可以使用其服务？
答案 0 :(得分：2)
ESB经常被用作营销概念，您可以将其绘制为中间的条形图，其中所有内容都可以简单地插入。这极大地过度简化了企业集成，因为在ESB内部，您可能会遇到以前在外面发生的混乱。 / p>
通常，ESB实现为具有适配器和路由核心的应用程序服务器。我个人认为，与一个应用服务器集成并不是一个好的架构选择。原因是您从系统泄漏了太多信息以便以这种方式集成。中央平台将了解其集成的应用程序的内部细节，如数据库结构或专有连接协议。
另一方面，可以关心路由和转换的平台的想法是一个很好的概念，如果正确完成可以帮助很多。
我认为更好的架构是在SOA中使用通用传输和格式并使用依赖于业务语言和思维的模型创建服务的概念。要实现这一点，您需要在您集成的系统附近安装适配器。这导致了分散的ESB，看起来更像您描述的内容。请记住，以使公共传输和数据格式非常标准化。
我使用消息传递系统作为中央传输，使用纯XML或SOAP作为数据格式。另一个好的选择是REST。也可以将两者结合起来。
Servicemix或Karaf + Camel + CXF可以为应用程序托管适配器以及路由和转换逻辑。此外，您可以使用camel和CXF将适配器嵌入到您的应用程序中。 JMS或REST将允许连接容器和外部适配器。
答案 1 :(得分：2)
简单地说，企业服务总线更像是一种架构概念。我们的想法是实现业务服务的集成。 ESB实际上可以实现为一组策略和指南，其中应用程序就给定的一组格式和给定的通信协议（SOAP / WS，消息传递等）达成一致，这是一种描述服务等的方式。
ESB服务器（Service Mix，IBM WebSphere Message Broker，JBoss ESB，Mule ESB，MS BizTalk Server，您的名字）本质上提供了一个工具箱来实现这一点。通常需要针对每种情况和企业环境确定服务器的数量，拓扑，要使用的协议/数据格式等。由批量控制的传统/主框架系统构建的应用程序环境需要非常不同的集成设置，例如事件驱动的Java EE或.NET应用程序堆栈。
答案 2 :(得分：0)
旧主题 - 但我认为您需要围绕Message Bus系统构建ESB。
ESB可以提供其他访问方式，例如HTTP，FTP等.ESB本身可以托管应用程序，或者让您无缝连接到另一个外部应用程序，与协议无关，因为它在内部进行调解。您可以根据需要进行缩放。例如您可以在3个ESB实例中部署相同的应用程序并在面向消息的中间件上进行负载平衡 - 即您在队列上发送消息并且所有ESB实例都在监听它并且只有一个在点对点模型上进行拾取。然后，您可以通过拥有MoM集群进一步扩展，并将消息发送到任何实例 - 两者都托管相同的队列。