您在何时，何地以及为何在PHP项目中使用ESB？
在哪里，何时以及为什么认为在PHP项目中使用ESB是有意义的？
ESB（以及像Mule这样的ESB辅导员）是否提供PHP和本机LAMP技术所缺乏的任何功能？
编辑
我对这个问题的动机源于我的假设你实际上从未真正需要骡子。骡子将促进与外部服务的沟通，您可以在没有骡子的情况下处理。在一天结束时，Mule也会产生成本和开销。所以我的问题是指导有人告诉我你真正受益于ESB和Mule这样的工具的场景，或者凭借扎实的知识来猜测。
编辑2
关于Houcem回复我对他的帖子的评论...什么是ESB / Mule的原生LAMP答案？
编辑3
似乎 燕尾服 可能是Mule / ESB的PHP本地替代品。有人有使用这个工具的经验吗？
ESB可以以不同的方式使用：
提供异步处理：示例：如果您的网站发送了大量电子邮件...并且发送电子邮件需要花费大量时间来阻止页面的执行：您可以使用ESB将电子邮件数据发送到Mule并将其路由到电子邮件出站通道，这样您就可以说已实现了邮件消息队列。另一种形式的异步处理：使用mule以非阻塞方式执行php脚本（使用命令行）。
与java应用程序集成：您可以使用php将消息发送到mule并使用java中的mule API实现一些Java业务，您的Java业务组件将接收php消息。这用于大型网站，它们进行大量复杂的处理，需要灵活而强大的语言，如java。
您需要了解的内容：ESB应该像Bus一样使用，这意味着以标准形式（Mule消息）从异构环境中收集数据。执行业务逻辑，然后将数据（路由后）输出到不同的环境
在PHP世界中没有与Mule的本机php集成。要做到这一点，你应该使用Web服务（SOAP）
ESB是可伸缩性问题的通用解决方案;管理大量应用程序接口的开销，成本和复杂性的问题。我写了一篇关于ESB / EAI解决方案基本原理的简短文章 http://psicom.com.au/solutions/eai
不可否认，大多数PHP站点都是小规模的，并且通常很难证明ESB的管理和技术开销是合理的。但现在用OSS PHP产品满足所有业务应用程序的需求是相当可行的，并且组织的成本压力也在增加，所以我预计会有越来越多的PHP商店开始感受到成长的痛苦我写的是关于。这可能会使他们重新评估他们的应用程序集成问题，而ESB是解决该问题的一个很好的解决方案。
据我所知，没有用PHP开发的ESB产品，我不希望在不久的将来看到这一点。但是FWIW，许多ESB产品都为PHP和其他OSS平台提供绑定，因此运行ESB的平台并不重要。
ESB（企业服务总线）是企业的多个异构应用程序集成的一种主干，可能源自不同的供应商，技术，甚至是冗余的。
它似乎与PHP世界相关的事实比PHP或任何其他语言更多 平时 大公司信息系统由以下部分组成：
PHP最常用于Web应用程序（即使对于大公司，但面向Web）。
ESB是一项巨大的成本，只有在互连应用程序数量增加时才有用/需要。 当您只有很少的连接（在Java，PHP或其他之间）时，您可以在网络级别使用DNS处理它，在应用程序级别使用配置键并为每个点对点连接执行协议交换和小型业务集成。
PHP应用程序的潜在用例将是旅行社的一个互联网网站，该网站查询多个航班/火车/酒店公司。即使在这种情况下，开发一个完整的交叉查询系统也不会发疯，因为它是这样一个网站/公司的业务核心。
我建议使用Windows Azure Service Bus，它在这里提供了一个PHP SDK https://github.com/WindowsAzure/azure-sdk-for-php
服务总线很棒，但保持一个不是。 Windows Azure Service Bus为您解决了所有维护开销，并且与PHP兼容。您甚至可以轻松地与PHP中使用Java，C＃，VS C ++编写的应用程序进行通信。