Opengroup SOA本體服務，服務接口，服務合同

Question

我試圖理解本文檔中的定義。 http://www.opengroup.org/soa/source-book/ontologyv2/service.htm

他們對服務，服務接口和服務合同的定義不清楚，或者看起來與我通常遇到的不同。

服務：

“服務是具有指定結果的可重復活動的邏輯表示。 它是獨立的，對消費者來說是一個“黑匣子”。”

可以說我有一個WCF項目，它有兩個Operations StoreFront + GetPrice + AddToCart

該定義說“可重復的活動”。 服務StoreFront也是嗎？ 還是我有兩個服務（GetPrice和AddToCart）。

服務合同：具有“效果”等級。 是“返回價格”和“添加到購物車”的效果嗎？

Answer 1

在同一篇文章中：

“這種功能是一個實體或使用定義明確的‘條款與條件’和接口實體他人提供的。”（來源：OMG的SoaML規范-我的斜體字）

在我看來，這是比談論“可重復活動”的定義更好的定義。

定義中的關鍵詞是能力 。 能力是指業務能力 ，它是BPM行業的遺留物，但在SOA上下文中是指具有不同邊界的業務領域。

因此，根據此定義，我們可以推測服務應該公開或應該在業務能力/流程邊界內運行。 這就引出了我們的想法（從SOA的負責人或承租人出發），即服務應該在定義明確的邊界內是自治的。

在您的示例中，您正在詢問

服務StoreFront也是嗎？ 還是我有兩項服務（GetPrice和AddToCart）

一如既往的答案是“取決於”。 但是，通常，定價（GetPrice）與訂購（AddToCart）屬於不同的業務功能。 此外，操作在其他一些重要方面也有所不同：

• GetPrice是讀取操作，而AddToCart是寫入操作。
• GetPrice是一個同步操作，而AddToCart很可能是異步的

因此，從業務角度來看，我們可能應該假設它們是兩種不同的服務。

這個假設有一些根本的影響。 如果它們是兩項服務，那么根據SOA，它們應該是自治的。 這意味着我們應該尋求以各種可能的方式使服務之間的耦合最小化，以便盡可能將它們作為單獨的關注點進行計划，開發，測試，構建，部署，托管，支持和管理。

另一個影響是，當您在某種程度上將服務物理分開時，如何將這些內容一起顯示給用戶？ 它們可能具有不同的功能，但仍需要在屏幕上一起工作。

此外，從后端的角度來看，訂購需要了解定價數據，否則訂單如何履行？ 如果您將數據庫分為兩部分，那么Checkout服務如何知道多少物料成本，要應用哪些折扣等？

我已經發布這個東西之前 ，所以請隨時有一個讀。 我建議閱讀的優秀文章微服務由劉易斯和福勒也。