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

Question

服务组合是SOA的基本组成部分。全部 预计服务库存提供的功能将被利用 必要时，该库存中的其他服务，以便 构建他们从较小的组件完成的任务 部分。这完全来自建筑层面：这是怎么回事 组成发生在实施层面？

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

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

你有没有遇到过这个？这是否有规范的“正确答案” 问题

Answer 1

您应该区分服务端点（在您的情况下，由各种服务公开的URL）和服务。服务基本上是组件，应该是，定义良好的边界，它们暴露一个或多个端点，它们交付合同（由消息组成）。

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

您的案例中的问题是process-request和PartsInventory同一服务的不同方面与否。我无法理解您服务中的细节，如果它们是否存在，但是如果它们真的有意义，那么您应该通过服务界面进行不同的服务。