SOA 发布消息与调用过程
SOA Publishing Messages vs Calling Procedures
我正在从事的项目正在从 n 层架构转向 SOA 架构，因此我一直在阅读有关良好 SOA 实践的资料。我正在努力理解避免 RPC 样式服务以支持事件驱动服务与用户界面检索数据并快速执行的要求之间的动态关系。
因此，例如，理想情况下，SOA 体系结构将由可重复的业务流程组成，其中您可以简单地将消息发布到 ESB 上，ESB 将处理查找处理该消息的服务。因此，与其执行一个名为 "Setup New User" 的过程来执行与新用户设置相关的所有任务，不如将一条消息发布到 ESB 中，其中只包含新用户的详细信息并具有适当的文档类型 "New User" 然后 ESB 将找到处理该事件的服务，然后执行所需的任何域特定的新用户配置。
但是，有时您只需要数据。也许您有一个页面显示一些用户关联数据列表。您不能因为需要返回数据而立即向 ESB 发送消息。此外，您并没有真正触发任何业务流程；您只是从以前调用的业务流程（例如导致用户与数据相关联的流程）中检索数据。因此，举一个具体的例子，也许我只想查看用户最近观看的 10 部 Netflix 电影的列表。
如何在单个 SOA 系统中协调这些不同类型的服务？
在遵循事件驱动方法的 ESB 中，您拥有各种侦听器，它们可以检测事件并采取相应的行动。例如，这些听众可能会在某个端点通过某种协议等待直接消息的出现。无论触发器是什么——启动业务流程的纯业务事件或只需要检索一些数据的技术调用，它仍然是一个由 ESB 处理的事件。因此，您在技术上并没有破坏事件驱动的方法——它是由您的 ESB 解决方案强制执行的。此外请记住，SOA 不会强加这种限制 - 您不必以事件驱动的方式实现所有内容。
在您的情况下（前提是您没有合适的专用 BPM 解决方案），我将在 ESB 的两个纯概念层上识别并实施两种服务：
技术服务（事件是 retrieval/modification 数据的传入直接消息），可以由另一个系统（通过 ESB）直接调用或由其他流程服务调用.
以事件驱动方式触发的顶层（业务）层的流程服务（例如，使用主题队列，流程服务在其中侦听其触发事件）
但是，这可能不是最佳方法。在 this topic 中，我一直在讨论专用业务流程层中的业务流程与 ESB 中的流程服务。随意检查一下，因为它与您的问题有点相关。
我正在从事的项目正在从 n 层架构转向 SOA 架构，因此我一直在阅读有关良好 SOA 实践的资料。我正在努力理解避免 RPC 样式服务以支持事件驱动服务与用户界面检索数据并快速执行的要求之间的动态关系。
因此，例如，理想情况下，SOA 体系结构将由可重复的业务流程组成，其中您可以简单地将消息发布到 ESB 上，ESB 将处理查找处理该消息的服务。因此，与其执行一个名为 "Setup New User" 的过程来执行与新用户设置相关的所有任务，不如将一条消息发布到 ESB 中，其中只包含新用户的详细信息并具有适当的文档类型 "New User" 然后 ESB 将找到处理该事件的服务，然后执行所需的任何域特定的新用户配置。
但是，有时您只需要数据。也许您有一个页面显示一些用户关联数据列表。您不能因为需要返回数据而立即向 ESB 发送消息。此外，您并没有真正触发任何业务流程；您只是从以前调用的业务流程（例如导致用户与数据相关联的流程）中检索数据。因此，举一个具体的例子，也许我只想查看用户最近观看的 10 部 Netflix 电影的列表。
如何在单个 SOA 系统中协调这些不同类型的服务？
在遵循事件驱动方法的 ESB 中，您拥有各种侦听器，它们可以检测事件并采取相应的行动。例如，这些听众可能会在某个端点通过某种协议等待直接消息的出现。无论触发器是什么——启动业务流程的纯业务事件或只需要检索一些数据的技术调用，它仍然是一个由 ESB 处理的事件。因此，您在技术上并没有破坏事件驱动的方法——它是由您的 ESB 解决方案强制执行的。此外请记住，SOA 不会强加这种限制 - 您不必以事件驱动的方式实现所有内容。
在您的情况下（前提是您没有合适的专用 BPM 解决方案），我将在 ESB 的两个纯概念层上识别并实施两种服务：
技术服务（事件是 retrieval/modification 数据的传入直接消息），可以由另一个系统（通过 ESB）直接调用或由其他流程服务调用.
以事件驱动方式触发的顶层（业务）层的流程服务（例如，使用主题队列，流程服务在其中侦听其触发事件）
但是，这可能不是最佳方法。在 this topic 中，我一直在讨论专用业务流程层中的业务流程与 ESB 中的流程服务。随意检查一下，因为它与您的问题有点相关。