SOA 服务组合如何在代码级别工作？

Question

服务组合是 SOA 的基本组成部分。全部 服务清单提供的功能预计将利用 必要时，该清单中的其他服务，以便 从较小的组件构建他们正在完成的任务 部分。不过，这一切都来自架构层面：这是如何做到的？ 组合发生在实现级别？

考虑这种情况。我有一个“任务服务”，其中涉及 发布一个/process-request 资源，该资源将管理其他 异步处理大文件所涉及的资源 生成“真实”资源。让我们称最终的“真实”资源 零件库存。因此，您为 PartsInventory 到/process-request 服务，然后创建 PartsInventory “占位符”并启动异步 ETL 涉及将您 URL 上的大量 csv 文件转换为真实的 零件库存。如果此异步作业失败，它将删除 占位符和对/process-request 服务的查询将 反映失败。如果成功，它将删除占位符 /process-request 服务的状态和查询将改为 将您重定向到 PartsInventory 资源。

现在，如何实现之间的交互 /process-request 和 PartsInventory look，来自代码 立场？我是否将请求发布到已发布的/parts-inventory 服务，还是我调用 ORM 对象来创建占位符？如果 前者，我遵守已公布的合同，表现得像 我自己的服务的消费者，这似乎符合可组合性 原则——但以这种方式互动感觉真的很尴尬 在同一个代码库中。另一方面，后者假定 /process-request 处理程序将了解如何创建 单独的 PartsInventory 占位符，感觉很尴尬 本身。第三种选择是创建一个专门的静态 PartsInventory 对象上的工厂方法，一起调用 PartsInventory.create_placeholder() 的行，因此 /process-request 代码至少对构造函数一无所知 PartsInventory 对象的依赖关系。这仍然分开 但是，创建到两个位置。

你遇到过吗？对此是否有规范的“正确答案” 问题？

Answer 1

您应该区分服务端点（在您的情况下是由各种服务公开的 url）和服务。服务基本上是具有明确定义的边界的组件，这些边界暴露了一个或多个端点，它们在其中交付合同（由消息组成）。

在服务内进行的调用不必通过服务接口调用跨服务边界的调用必须通过服务接口。

您的问题是流程请求和 PartsInventory 是否是同一服务的不同方面。我无法从您的服务中的详细信息中了解它们是否存在，但如果它们作为不同的服务真的有意义，您应该通过服务接口。