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

服务组合是SOA的一个基本部分。所有的 服务清单提供的功能预计将得到利用 必要时，该库存中的其他服务，以便 从较小的组件构建他们正在完成的任务 部分。不过，这都是从体系结构的角度来看的：这是如何做到的 组合在实现级别发生

考虑一下这种情况。我有一个“任务服务”，包括 发布

/流程请求

资源，该资源将管理其他 异步处理要复制的大型文件所涉及的资源 生成“真实”资源。让我们称之为最终的“真正”资源 政党。因此，您需要为 向

/process request

服务提交零件，然后该服务创建 一个部件记录“占位符”并启动异步ETL 参与将URL上的海量csv文件转换为真实的csv文件 第七部分。如果此异步作业失败，它将删除 将显示占位符和对

/process request

服务的查询 反映失败。如果成功，它将删除占位符 对

/process request

服务的状态和查询将改为 将您重定向到PartsInventory资源

那么，如何实现两者之间的交互呢

/process request

和零件库存外观，从代码 立场？我是否将请求发布到已发布的

/parts inventory

服务，还是调用ORM对象来创建占位符？如果 前者，我遵守公布的合同，并作为 我自己的服务的消费者，这似乎符合可组合性 原则——但从一开始就以这种方式进行互动真的很尴尬 在同一个代码库中。另一方面，后者假定

/processrequest

处理程序将了解如何创建 一个PartsInventory占位符本身，在 它本身第三种选择是创建专门的静态 PartsInventory对象上的工厂方法，称为

零件库存的行。创建占位符（）

，以便

/processrequest

代码至少不知道构造函数 PartsInventory对象的依赖项。这仍然是分开的 但是，创建到两个位置

你遇到过这个吗？有没有一个规范的“正确答案”

---

问题？

您应该区分服务端点（在您的例子中，URL由各种服务公开）和服务。服务基本上是具有定义良好的边界的组件，这些边界公开了一个或多个端点，在这些端点上它们传递契约（由消息组成）

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

您案例中的问题是，流程请求和部件是否涉及同一服务的不同方面。我无法从您服务中的详细信息中理解它们是或不是，但如果它们作为不同的服务真正有意义，您应该通过服务接口来了解