Architecture Opengroup SOA本体服务vs服务接口vs服务契约

我试图理解本文件中的定义。

他们对服务、服务接口和服务合同的定义要么不清楚，要么似乎与我通常遇到的不同

服务：

“服务是可重复活动的逻辑表示，该活动 具有指定的结果。它是自包含的，是一个用于 它的消费者。”

假设我有一个WCF项目，它有两个操作 店面 +GetPrice +AddToCart

定义是“可重复的活动”。那么服务店面呢？或者我有两个服务（GetPrice和AddToCart）

服务合同：

---

有一个“效果”类。效果是否为“退货价格”和“添加到购物车”

来自同一篇文章：

“一个或多个实体使用 定义良好的“条款和条件”和接口。”（来源：OMG SoaML规范-我的斜体）

在我看来，这是一个比谈论“可重复活动”更好的定义

定义中的关键词是能力。能力指的是BPM行业的遗留产品，但在SOA上下文中指的是具有不同边界的业务领域

因此，根据这个定义，我们可以推测服务应该公开，或者应该在业务能力/流程边界内运行。这使我们（从SOA的角度）想到服务应该在定义良好的边界内自治

在你的例子中，你是在问

那么服务店面呢？或者我有两种服务（GetPrice和 AddToCart）

答案总是“视情况而定”。然而，一般来说，定价（GetPrice）与订购（AddToCart）属于不同的业务能力。此外，操作在其他一些重要方面有所不同：

• GetPrice是一个读操作，而AddToCart是一个写操作
• GetPrice是一个同步操作，而AddToCart很可能是异步的

因此，从业务角度来看，我们可能应该假设它们是两种不同的服务

这一假设产生了一些根本性的影响。如果它们是两个服务，那么根据SOA，它们应该是自治的。这意味着我们应该尽可能减少服务之间的耦合，以便尽可能多地将它们作为单独的关注点进行规划、开发、测试、构建、部署、托管、支持和管理

另一个影响是，当您将服务物理分离到这种程度时，如何将这些内容一起显示给您的用户？它们可能具有不同的功能，但仍需要在屏幕上协同工作

此外，从后端的角度来看，订购需要了解定价数据，否则如何实现订单？如果您已经将数据库分成两部分，那么结帐服务如何知道材料的价格、应用的折扣等

---

我已经发布了这篇文章，请随意阅读。我建议你也读一下刘易斯和福勒写的一篇优秀的文章

+1个好问题。不知道你为什么会被否决。。。