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