SOA服務識別的關鍵方法
SOA團隊 2020-03-16
服務需求的主要工作是基于SOA的需求分析方法論，以流程和業務驅動IT的指導思想，對業務系統進行業務建模，用例建模和業務實體建模，形成企業級需求和業務功能清單，作為后續服務識別的輸入。
對于服務需求，以流程分析為基礎，通過流程的逐層分解，細化出關鍵的業務活動，將流程活動識別為業務用例，并對業務用例進行建模。用例建模本身可以作為業務系統功能開發的需求規格說明書，同時對用例分析和功能操作的識別形成業務域-》流程分解-》用例-》業務操作的分解過程，用于后續服務的識別。
在整個分析過程中，流程的關鍵活動或業務用例的操作都會涉及到業務實體對象，因此需要對業務實體對象進行單獨建模，分析實體對象的關鍵屬性和對象間關系，同時分析實體對象和業務操作間的U/C矩陣，作為后續公用服務提取的基礎。
服務識別開始于需求分析，終止于識別出的候選服務列表。為了有效的實施SOA工程，應用不能孤立于其他應用而獨立開發。SOA的應用應該可以共享服務，這些服務不單單屬于某個獨立的應用，并且有自己的生命周期，能夠被獨立的管理。在SOA工程中，為了有效的管理需求，各個項目必須知道其他已經存在的項目、正在開發的項目以及未來將要開發的項目需求。所以，與SOA服務相關的需求應該在企業級層面管理。
候選服務是被識別出用于系統重用的業務功能。一個候選服務不一定一對一的對應到實際交付的服務，比如，在分析階段，一個粗粒度的服務可能對應到需求中兩個或兩個以上的初始候選服務。另一方面，服務識別并不是簡單的識別出候選服務，也包括了一系列的校驗和評估。
1.數據服務識別
數據服務為以實現業務系統底層數據集成為目的，以業務實體為核心的數據對象傳輸為主的SOA服務。數據服務沒有明確的業務規則和含義。一般服務消費方在消費數據服務后都需要將數據同步到本地數據表，再根據業務系統自身需要對數據服務進行相關業務規則的封裝和實現。
a.業務實體確認
在業務建模和數據建模階段，已經對業務實體進行了分析，包括業務實體的類型，業務實體和業務功能的U/C矩陣分析等。業務實體是識別數據服務的基礎，因此需要對業務建模階段識別的業務實體進行確認。業務實體完全是業務視角的業務對象，而不是數據庫設計中的數據庫表，如采購訂單業務實體可能涉多層結構和多張數據庫表，但是在此處的分析只需要考慮采購訂單業務實體對象。
b.服務重用性分析
在業務建模構建的U/C矩陣的基礎上，可以從兩個層面分析服務的重用性。
一個是跨業務系統的服務重用性，一個是在一個業務應用內部業務模塊間的服務可重用性。當一個業務主數據或一個核心業務單據需要跨多個業務系統或業務模塊使用的時候，則該業務實體識別為數據服務是可重用的。
c.服務實現方法分析
在服務實現的時候，一方面是考慮服務的可重用性，一方面是考慮業務敏捷要求。對于數據類服務一般可以實現為查詢類數據服務，也可以實現為導入類數據服務。
當業務數據的業務敏捷性和時效性要求高時候，優先考慮實現為導入和分發類服務滿足業務敏捷性的要求。
d.服務大數據量傳輸分析
對于底層數據集成類服務，可能涉及到大數據量傳輸，這種數據對實時性要求不高，但是任何一個批次傳輸可能都在10萬級以上的數據量。對于這種情況要單獨進行分析，分析服務數據量，調用頻度，數據同步機制等。
對于大數據量傳輸在識別為數據服務的時候可以考慮ODI服務，JMS消息，數據分頁等多種方式來實現。
2.業務服務識別
業務服務是有明確業務含義的，含具體業務規則和邏輯的，實現一個有價值的業務活動的一系列業務操作的組合。業務服務具有明顯的高業務內聚性，粗粒度特征。
a.業務組件確認
業務組件是實現多個業務功能的，高內聚松耦合的業務功能模塊單元。業務組件是可以進行獨立需求分析，設計，開發，測試和部署的組件管理單元。對于一個完整的業務系統或業務流程是通過業務組件的交互和協同來完成。業務組件之間的交互則通過標準的SOA服務方式進行。即業務組件中包含了技術組件和服務組件，其中服務組件暴露業務服務。
b.業務服務識別
對于業務服務識別分為兩個層面的內容。其一是為了實現跨業務組件的業務流程分析出來的業務組件之間的業務交互。其二是在用例建模階段我們對業務操作進行了詳細分析，對于這些分析整理出業務操作清單，對于業務操作清單中的可重用的業務操作識別為關鍵的業務服務。具體識別步驟為：
1. 根據業務流程或業務用例，繪制相應的跨業務組件協作的業務交互圖。
2. 對所有的業務交互點識別為潛在的業務服務。
對業務操作活動列表進行分析，將可重用的業務操作識別為潛在的業務服務。
3.UI組件服務識別
UI組件是可以完成獨立的業務功能的小業務應用。UI組件可以獨立進行需求分析，設計，打包，部署和運行。UI組件是一種頁面內嵌的方式在多個業務系統中運行，因此在UI組件復用的情況下，基本不需要進行底層的數據集成和同步操作，可以更好的保證數據的一致性和時效性。
對于UI組件的識別主要分為兩個層面進行：
a.從頂向下識別
對于業務系統在構建中的業務系統和系統需求進行分析，在系統需求階段會進行詳細的功能需求描述和UI界面描述。可以針對這些需求文檔分析重復的業務功能界面，將其識別為潛在的UI組件服務。
b.從下向上識別
該方法是首先對業務系統中的平臺化功能模塊進行抽象，如工作流管理，系統管理，公共技術服務等都是可以進行平臺化的組件功能模塊。
對于平臺化的組件功能模塊需要和業務系統進行界面層的交互，因此對于這些界面層交互可以由平臺層提供UI組件服務內嵌到各個業務系統中使用。
4.技術服務識別
技術服務是和業務無關的，提供某種技術能力的服務。技術服務一般包括消息，安全，日志，會話，規則，異常，數據庫管理等多個方面的內容。對于技術服務的識別仍然是包括了兩個層面：
a.從頂向下識別
在業務建模和業務系統需求分析過程中，需要關注業務系統非功能性需求的描述，這些非功能需求包括了異常，日志，安全，性能，可靠性，高可用性，可擴展性，大數據量處理等多個方面的內容。對于這些非功能需求如果有多個業務系統或模塊提出，則可以考慮抽象識別為公有的技術服務。
b.從下向上識別
該方法是從平臺層面進行考慮，企業在業務系統建設過程中一般會分為產品層和平臺層，對于平臺層又包括了產品平臺和技術平臺。在進行平臺化功能構建的過程中，平臺層需要朝產品層提供能力，這些能力的提供都可以考慮以技術服務的方式統一提供。以實現產品層和平臺層的集成。
遠行科技
遠行云商
