1

我正在尝试理解本文档中的定义。 http://www.opengroup.org/soa/source-book/ontologyv2/service.htm

他们对服务、服务接口和服务契约的定义要么不清楚，要么看起来与我通常遇到的不同。

服务：

“服务是具有特定结果的可重复活动的逻辑表示。它是独立的，对消费者来说是一个“黑匣子”。”</p>

假设我有一个 WCF 项目，它有两个 Operations StoreFront +GetPrice +AddToCart

定义说“可重复的活动”。服务 StoreFront 也是如此吗？或者我有两个服务（GetPrice 和 AddToCart）。

服务契约：有一个“效果”类。效果是“退货”和“加入购物车”吗？

4

1 回答 1

1

来自同一篇文章：

“一个或多个实体使用明确定义的‘条款和条件’和接口向其他实体提供的能力。” （来源：OMG SoaML 规范 - 我的斜体）

在我看来，这比谈论“可重复活动”的定义更可取。

定义中的关键词是能力。能力是指业务能力，它是从 BPM 行业继承而来的，但在 SOA 上下文中是指具有不同边界的业务领域。

因此，根据这个定义，我们可以推测服务应该公开或应该在业务能力/流程边界内运行。这导致我们（来自 SOA 的负责人或租户）的想法是，服务应该在明确定义的边界内是自治的。

在您的示例中，您在问

服务 StoreFront 也是如此吗？或者我有两个服务（GetPrice 和 AddToCart）

与往常一样，答案是“视情况而定”。但是，通常定价 (GetPrice) 与订购 (AddToCart) 属于不同的业务能力。此外，这些操作在其他一些重要方面有所不同：

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

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

这个假设有一些激进的影响。如果它们是两个服务，那么根据 SOA，它们应该是自治的。这意味着我们应该寻求以各种可能的方式最小化服务之间的耦合，以便尽可能地将它们作为单独的关注点进行规划、开发、测试、构建、部署、托管、支持和管理。

另一个影响是，当你在物理上分离服务到这种程度时，你怎么能把这些东西一起展示给你的用户呢？它们可能是不同的能力，但它们仍然需要在屏幕上协同工作。

此外，从后端的角度来看，订购需要了解定价数据，否则如何执行订单？如果您已将数据库一分为二，结帐服务如何知道材料的成本、要应用的折扣等？

我之前已经发布过有关这些内容的内容，因此请随时阅读。我也推荐阅读Lewis 和 Fowler撰写的关于微服务的优秀文章。

于 2014-05-02T09:14:12.803 回答