「服務封裝業務功能」與「服務可以被組合成業務流程」

最近，我讀2本書，我用下面的語句「服務封裝業務功能」與「服務可以被組合成業務流程」

學習WCF由米歇爾·勒魯碰到：

服務封裝業務功能

Service orientented architecture in real world：

個

服務可被組裝（或-composed‖）到業務流程

鬆耦合系統導致鬆散耦合的業務流程，[...]。服務及其相關的接口必須保持穩定，使他們能夠被重新配置或重新聚合到滿足業務內容

閱讀SOA在現實世界中，我明白，我是假設的不斷變化的需求讓我的獨立（最初無用的）服務從業務環境中抽象出來，然後編寫和編排，然後做一些有用的事情，創建業務層並制定業務需求。

然後，閱讀學習WCF讓我覺得，我應該（在非平臺特定的格式，當然）讓我的業務層，以滿足特定的需求，然後將其暴露爲服務

目前，我正在做我的業務層，然後通過定義良好的接口公開一些公共方法，但我喜歡創建更多獨立服務的想法，然後構建業務層。

我想聽聽有經驗的SOA開發人員，這些方法對於獲得SOA的好處以及爲什麼是理想的，爲什麼？

我很困惑這個話題。示例和開源項目將會非常有幫助。

來源

2012-01-20 Davi Fiamenghi

在Thomas Erl的着作中，他將服務分類爲「實體服務」，這是細粒度的，與一個實體相關的業務過程不可知的服務，經常用於合成/編排，以及「任務服務」通常涉及多個實體，包含更多的業務邏輯，對業務流程有一定的瞭解，並不適用於重用/組合。

因此，業務流程既可以在一個大型的任務服務中實現，也可以通過將多個實體服務組合到一個組合中來實現。

'任務服務'聽起來像Michelle Leroux的服務願景，而真實世界中的SOA有更多的'實體服務'願景。

在Erl的SOA願景中，兩種服務都可以並肩生活。實體服務是首選目標 - 這些可以更容易地重用和組合，並提高業務敏捷性。但在某些情況下，這可能不合適，任務服務將是更好的解決方案 - 性能需求和封裝遺留代碼就是兩個例子。

來源

2012-01-20 17:23:53

謝謝，你的回答很明確。爲了做得更好，請確認這是否屬實：「銷售服務」是一個很好的候選人，因爲它涉及（產品，服務，運輸，佣金等）。 ProductService，ServicesService，ShippingService和ComissionService將是實體服務。我是如何實現它的？一個IProductService和ProductService類（等）以及SalesBusiness中的業務規則公開爲ISalesServices？我仍在尋找示例 –

銷售服務可以是任務服務（用C＃或Java開發並作爲Web服務公開），或者它可以是在BPEL/SCA引擎中實現的組合服務，並且使用產品，服務，航運和佣金實體服務。實體服務很可能被開發爲c＃或Java中的Web服務。沒有太多的例子，因爲它會非常複雜 - 幾個項目和對BPEL/SCA引擎，企業服務總線，發現註冊表等的依賴。 –

@DaviFiamenghi以及上面，我推薦這些書：SOA實踐：Nicolai M. Josuttis的「分佈式系統設計的藝術」和Jeff Davis的「開源SOA」 –

對我來說，服務的想法是封裝業務相關的功能。但是，這不同於業務流程。通常單獨的業務功能部件需要組成更大的單元來代表整個業務流程。例如，進行銷售需要付款，運輸產品，計算銷售佣金。所有這些都是離散的業務功能塊，可以作爲服務建模，但它們必須組成以代表整個業務流程

但是，業務流程往往運行時間相對較長（超過一個網絡的超時時間單一請求），所以不知何故業務流程的狀態需要保持 - 這是Workflow和Biztalk可以帶給參與者的一件事情。

來源

2012-01-20 07:37:09

很好的描述。您能否就我們如何識別服務給我們任何建議？是否有助於跨多個業務流程查找並找到它們的共同點？還是有更好的方法？您如何知道服務的粒度太細或粒度不夠？ – ahoffer

@Richard Blewett，在談論工作流時，服務應作爲活動庫和每個服務操作公開一項活動。那是對的嗎？ –

「服務封裝業務功能」與「服務可以被組合成業務流程」

回答

相關問題