我已经在MULE上探索了网络并且了解到,为了让他们之间进行通信 - 即使它们部署在同一个Mule实例中 - 他们也必须使用TCP,HTTP或JMS传输。
不支持VM。
然而,我发现这与ESB原则有点矛盾。理想情况下,我们应该能够在ESB中定义EndPoints并使用任何传输连接到它吗?我可能错了。 此外,由于所有应用程序共享相同的JVM,人们希望能够通过内存中的VM队列进行通信,而不是依赖于无事务的HTTP协议或TCP,其中可以进行的连接数取决于服务器资源。即使对于JMS,我们也需要定义和管理另一个队列以及可能对性能产生影响的大量使用。虽然我同意如果我们有分布式和集群系统可能是HTTP或JMS将只是选项。
是否有计划将VM作为应用程序间通信协议进行合并,还是有其他方式可以让一个Flow与另一个Flow端点进行通信,但是在不同的应用程序中?
编辑: - 来自Mulesoft的回答
http://forum.mulesoft.org/mulesoft/topics/concept_of_endpoint_and_inter_app_communication
是的,我们正在考虑针对未来版本的应用内通信。
我们还要做什么时仍然不清楚,但我们对于我们希望这个功能如何表现有一些想法。我们可以创建一个服务器级配置,您可以在其中定义要在所有应用中使用的资源。在那里,您将能够定义VM连接器并使用它在同一服务器中的应用程序之间发送消息。
正如我所说,这只是一个想法。
答案 0 :(得分:2)
关于VM作为应用程序间通信的使用,只有MuleSoft可以回答VM是否具有未来功能。
我认为这与ESB原则并不矛盾。 “容器”功能在David A Chappell的“企业服务总线book”第6章中得到了很好的定义。容器应该尽量保持应用程序的隔离。
这将提供一些好处,例如“可独立部署的集成服务”(同一章节),更容易的集群化以及其他好处。
您应该像处理不同服务器中的应用程序一样处理相同的VM应用程序间通信。
答案 1 :(得分:0)
似乎Mule在3.5版本中添加了一项功能,可以在同一服务器中部署的应用程序之间进行通信。但共享VM连接器仅在企业版中可用。 信息: http://www.mulesoft.org/documentation/display/current/Shared+Resources#SharedResources-DefiningDomains
实施例: http://blogs.mulesoft.org/optimize-resource-utilization-mule-shared-resources/