SOA学习笔记
1?????????? SOA簡介：
1.1????????? SOA 是一種 IT 體系結構樣式，支持將業務作為鏈接服務或可重復業務任務進行集成，可在需要時通過網絡訪問這些服務和任務。這個網絡可能完全包含在公司總部內，也可能分散于各地且采用不同的技術，通過對來自紐約、倫敦和香港的服務進行組合，可讓最終用戶感覺似乎這些服務就安裝在本地桌面上一樣。需要時，這些服務可以將自己組裝為按需應用程序——即相互連接的服務提供者和使用者集合，彼此結合以完成特定業務任務，使業務能夠適應不斷變化的情況和需求（在有些情況下，甚至不需要人工干預）。
1.2????????? 當前架構所面臨的問題：
1.2.1???? 復雜性：如一個“銀行”可能擁有數套針對不同領域用戶服務的“軟件”，每一個運行正常，但同時帶來了巨大的冗余
1.2.2???? 接口多樣性：各個軟件之間必須要考慮接口，可能形成網狀的接口環境
1.3????????? Java 技術促成了平臺中立的編程，而 XML 促成了自描述，因而也促成了平臺中立的數據。現在，Web 服務通過允許應用程序以對象模型中立的方式實現互連，它具有以下特點：
1.3.1???? 無處不在的、開放標準的、低成本的網絡基礎架構和技術。它有助于一個分布式環境的形成，這個環境更有利于采用 Web 服務，而不是 CORBA 和 DCE
1.3.2???? 在一個以網絡為中心的領域內達到的接受程度的技術成熟水平。它要求互操作性以實現關鍵的業務目標（比如，分布式協作）
1.3.3???? 基于 Internet 的開放標準和相關技術是實現低成本互操作性的最好方法。
1.3.4???? 基于網絡的技術（比如 TCP/IP）、工具集（IDE、UML等等）、平臺（比如 J2EE 平臺）和相關的方法（比如 OO、服務等等）的成熟水平。它們提供了簡化松散耦合的、可互操作的、機器到機器的交互（一種比 CORBA 用戶體驗到的高級得多的狀態）所需的基礎架構
1.4????????? 更重要的機會剛剛出現，其中第一個就是網格計算，網格計算不僅是使用擁有大量 MIPS 的應用程序來進行計算的解決方案，而且還將提供一個框架，通過此框架可以動態地定位、重定位、平衡和管理大量的服務，這樣，無論系統上的負載如何，總可以保證安全地獲取所需的應用程序。而這又明顯地需要按需計算的概念（on-demand computing），按需計算可能是在任何配置下實現的，從簡單的服務器集群到有1024個節點的 SP2 網絡。用戶需要解決問題和適當的用于解決問題的計算資源——不多也不少——并且為實際使用的資源付費
1.5????????? Web 服務是包括 XML，SOAP，WSDL 和 UDDI 在內的技術的集合，它使您能夠針對特定的消息傳遞和應用程序集成問題構建編程解決方案。
1.6????????? 其一，服務是真正獨立的；其二，它們是可以管理的。管理包括許多功能，其中有：
1.6.1???? 安全性——請求的授權、加密和解密（在需要時）、確認等等
1.6.2???? 部署——出于性能、可用性冗余或其他方面的原因，允許服務在網絡內重新部署（移動）
1.6.3???? 日志——用于審核、測量等等
1.6.4???? 動態重新路由——用于故障排除（fail over）或負載平衡
1.6.5???? 維護——管理服務的新版本
1.7????????? 體系結構中的集成需求：
1.7.1???? 應用程序集成：
1.7.2???? 終端用戶界面集成：終端用戶界面集成涉及如何集成特定用戶訪問的全部應用程序和服務來提供可用、高效、一致的界面
1.7.3???? 應用程序連接：應用程序連接是一種集成方式，它涉及體系結構必須支持的所有類型的連接。在一個層次上，這意味著數據的同步和異步通信、路由、轉換和高速分布、以及網關和協議轉換器等等。而在另一個層次上，它還與輸入和輸出或源（sources）和匯（sinks）的虛擬化有關
1.7.4???? 流程集成：流程集成涉及開發映射到業務流程和為業務流程提供解決方案的計算流程、將應用程序集成到流程以及集成一些流程與其他一些流程。
1.7.5???? 信息集成：信息集成是一個流程，其作用在于為所有需要它的應用程序提供對企業中全部數據的一致訪問，而不管這些應用程序是以什么形式需要它，也不受數據的格式、來源或位置的限制。在實現時，這項需求可能包括 適配器和轉換引擎，不過它通常要比這復雜
1.7.6???? 構建集成開發模型：
1.8????????? 部署面向服務的體系結構的好處：
1.8.1???? 利用現有資產 —— 這是首要的需求。通過使用適當的 SOA 框架并使其可用于整個企業，可以將業務服務構造成現有組件的集合。使用這種新的服務只需要知道它的接口和名稱。服務的內部細節以及在組成服務的組件之間傳送的數據的復雜性都對外界隱藏了。這種組件的匿名性使組織能夠利用現有的投資，從而可以通過合并構建在不同的機器上、運行在不同的操作系統中、用不同的編程語言開發的組件來創建服務。遺留系統可以通過 Web 服務接口來封裝和訪問。
1.8.2???? 商品化基礎架構 —— 在所有不同的企業應用程序之間，基礎架構的開發和部署將變得更加一致。現有的組件、新開發的組件和從廠商購買的組件可以合并在一個定義良好的 SOA 框架內。這樣的組件集合將被作為服務部署在現有的基礎構架中，從而使得可以更多地將基礎架構作為一種商品化元素來加以考慮
1.8.3???? 更快的產品上市速度 —— 組織的 Web 服務庫將成為采用 SOA 框架的組織的核心資產。使用這些 Web 服務庫來構建和部署服務將顯著地加快產品的上市速度，因為對現有服務和組件的新的創造性重用縮短了設計、開發、測試和部署產品的時間。
1.8.4???? 減少成本 —— 隨著業務需求的發展和新的需求的引入，通過采用 SOA 框架和服務庫，為現有的和新的應用程序增強和創建新的服務的成本大大地減少了。同樣，開發團隊的學習難讀也降低了，因為他們可能已經熟悉了現有的組件。
1.8.5???? 降低風險 —— 重用現有的組件降低了在增強或創建新的業務服務的過程中帶來的風險。如前所述，這也減少了維護和管理支持服務的基礎架構的風險。
1.8.6???? 持續改進業務過程 —— SOA 允許清晰地表示流程流，這些流程流通過在特定業務服務中使用的組件的順序來標識。這給商業用戶提供了監視業務操作的理想環境。業務建模反映在業務服務中。流程操縱是以一定的模式重組部件（構成業務服務的組件）來實現的。這將進一步允許更改流程流，而同時監視產生的結果，因此促進了持續改進。
1.8.7???? 以流程為中心的體系結構—— 現有的體系結構模型和實踐往往是以程序為中心的。應用程序是為了程序員的便利而開發的。通常，流程信息在組件之間傳播。應用程序很像一個黑匣子，沒有粒度可用于外部。重用需要復制代碼、合并共享庫或繼承對象。在以流程為中心的體系結構中，應用程序是為過程開發的。流程可以分解成一系列的步驟，每一個步驟表示一個業務服務。實際上，每個過程服務或組件功能都相當于一個子應用程序。將這些子應用程序鏈接在一起可以創建能夠滿足業務需求的流程流。這種粒度允許利用和重用整個組織中的子應用程序。
2?????????? SOA生命周期：
2.1????????? 建模：面向服務的體系結構項目的第一步幾乎和技術沒有任何關系，所有事項都與業務相關。面向服務的方法將業務所執行的活動視為服務，因此第一步是要確定這些業務活動或流程實際是什么。對業務體系結構進行記錄，這些記錄不僅可以用于規劃 SOA，還可以用于對實際業務流程進行優化。通過在編寫代碼前模擬或建模業務流程，可以更深入地了解這些流程，從而有利于構建幫助執行這些流程的軟件。建模業務流程的程度將依賴于預期實現的深度。另外，這個程度還依賴于開發團隊中擔任的角色。如果是企業架構師，將會對實際的業務服務進行建模。如果是軟件開發人員，將可能對單個服務進行建模。
2.2????????? 組裝：對業務流程進行了建模和優化后，開發人員可以開始構建新的服務和/或重用現有的服務，然后對其進行組裝以形成組合應用程序，從而實現這些流程。在“建模”步驟中，已經確定了需要何種類型的服務以及它們將訪問何種類型的數據。已經存在某種形式的實現這些服務或訪問該類數據所需的一些軟件。“組裝”步驟將要找到已經存在的功能，并為其添加服務支持。另外，還涉及到創建提供功能和訪問數據源所需的新服務，以便滿足 SOA 涉及的業務流程范圍內的需求。
2.3????????? 部署：進行了建模和組裝后，要將組成 SOA 的資產部署到安全的集成環境中。此環境本身提供專門化的服務，用于集成業務中涉及的人員、流程和信息。這種級別的集成可幫助確保將公司的所有主要元素連接到一起協同工作。此外，部署工作還需要滿足業務的性能和可用性需求，并提供足夠的靈活性，以便吸納新服務（并使舊服務退役），而不會對整個系統造成大的影響。
2.4????????? 管理：系統就位，一切都正常運行。部署后，需要從 IT 和業務兩個角度對系統進行管理和監視。在“管理”步驟中收集的信息用于幫助實時地了解業務流程，從而能更好地進行業務決策，并將信息反饋回生命周期，以進行持續的流程改進工作。需要處理服務質量、安全、一般系統管理之類的問題。 在本步驟中，將監視和優化系統，發現和糾正效率低下的情況和存在的問題。由于 SOA 是一個迭代過程，因此，在此步驟中，不僅要找出技術體系結構中有待改進之處，而且還要找出業務體系結構中有待改進之處。完成此步驟后就要開始新的“建模”步驟了。在“管理”步驟中收集的數據將用于重復整個 SOA 生命周期，再次進行整個過程。
2.5????????? 控制：SOA 是一種集中系統；其中可以包含來自組織的不同部門的服務，甚至還能包含來自組織外的服務。如果沒有恰當的控制，這種系統很容易失控。控制對所有生命周期階段起到鞏固支撐作用，為整個 SOA 系統提供指導，并有助于了解系統全貌。它提供指導和控制，幫助服務提供者和使用者避免遇到意外情況。
3?????????? SOA的采用
3.1????????? 構建服務：具有特殊連接的根據需要提供的服務
3.1.1???? 在 SOA 采用第一個階段，通常會很偶然地著手構建 SOA 服務。也就是說，由于需要解決特定的問題，他們選擇了面向服務的方法，而不使用傳統方法。在此階段，服務構建將更多地關注解決特定的問題，而不是對企業現有系統進行轉換。IT 部門將構建一些新服務，或許會將一些現有應用程序轉換為一組基于 Web 的服務。它們之間的鏈接將根據需要提供，而不是源自整個體系結構的要求
3.2????????? 集成：具有可靠連接的系統標準化服務接口
3.2.1???? 發現了松散耦合體系結構的優勢、方便性和易維護性后，下一步就是利用這種靈活性通過組合服務來創建新的組合應用程序。例如，員工狀態服務可以與經理審批服務組合，以形成請假服務。這個過程可以采用自頂向下的方法，將重點放在最終結果和查找組件組成部分上。或者，可以采用自底向上的方法，將重點放在各個組成部分上，看看可以基于這些組成部分構建何種服務。他們之間的鏈接是預先計劃的且定義良好。
3.3????????? 轉換 IT：組合可重用服務，利用多個來源的功能
3.3.1???? 這個階段涉及到對信息技術基礎設施進行轉換，以便充分利用 SOA 的優勢。在此階段，所有系統將轉換為基于服務的應用程序，松散耦合是其中的規范做法，而不是例外。系統的所有組件都將根據 SOA 進行集成和連接，IT 系統的所有部分都在 SOA 內工作。
3.4????????? 轉換業務：對服務進行動態的事件驅動的重新配置
3.4.1???? 在 SOA 成熟的最后一個階段，業務與 SOA 完全集成，達到了這樣一個程度：所有合適的業務活動都被視為服務，可以最終在技術體系結構中對其進行建模、分析和實例化。達到此階段需要業務部門進行大量的工作和投入；不過，達到此階段后，業務將從面向服務的體系結構獲得最大的回報。
4?????????? 采用SOUP：
4.1????????? SOUP （Service-Oriented Unified Process）是一種使用 RUP(Rational Unified Process，這里可使用Rose2003) 和 XP(極限編程，采用jUnit單元測試等方式) 中的最佳部分來構建和管理 SOA 項目的軟件方法。它的目標是任何組織中正在進行的 SOA 項目。
4.1.1???? 典型的軟件開發項目包含應用程序開發過程、項目管理以及所使用的技術。此外，軟件開發項目通常具有四個變量：時間、預算、范圍 和質量。任何一個變量的變化對整個項目都有影響。不斷變化的業務需求使得范圍和質量成為兩個最難管理的因素。技術復雜性可能導致時間和預算管理方面出現問題。 SOA 項目比通常的軟件項目復雜得多，因為它們要求配備更大的跨功能的團隊，并且還有因此而帶來更復雜的團隊間溝通和日常管理工作。 雖然 SOA 可以為組織帶來許多好處，但同時也可能帶來很大的成本支出和時間消耗。如果項目沒有經過良好定義，并且在項目啟動時沒有關于最終結果的遠景，則失敗的可能性就非常大。
4.1.2???? 可以幫助 SOA 成功完成的關鍵因素有：
4.1.2.1??? 明確定義的開發過程
4.1.2.2??? 與業務相關的項目團隊之間增強的溝通渠道
4.1.2.3??? 明確的支持和控制策略?
4.1.3???? 在初始開發過程中，采用正式軟件方法是盡可能地減少已確定的風險的最好辦法。成功建立了 SOA 項目后，可利用正式的維護和增量開發方法來增加項目的 ROI。然而，XP 之類的靈活方法可能不夠正式，不適合在初始階段使用。SOUP 方法可幫助減少 SOA 推出階段的風險，并能讓您隨后進行持續 SOA 優化工作
4.2????????? SOUP 是一個由六個階段組成的軟件開發方法。每個階段代表對于 SOA 成功推出非常關鍵的一組特有的活動
4.2.1???? 初始：
4.2.1.1??? 確定組織對 SOA 項目的需求。您可以通過應用 SOA 成熟度模型來確定組織的體系結構成熟度水平并確定 SOA 的驅動因素。此時，您將需要向為業務服務的所有項目團隊說明 SOA 的基本概念，并擬訂與反饋和建議流程有關的策略計劃
4.2.1.1.1?? SOA 遠景和范圍：給出項目的整體遠景。它還提供了確定項目范圍的邊界，該范圍至少應包含兩個業務線或項目。
4.2.1.1.2?? SOA 策略：說明項目將如何執行的概略計劃。
4.2.1.1.3?? ROI 分析：給出此項目將帶來的成本支出和節省情況。
4.2.1.1.4?? 溝通計劃：說明 SOA 團隊將如何與其他項目團隊和業務用戶進行溝通。
4.2.1.2??? 跨功能分析人員和項目管理人員將對客戶的業務進行分析，以確定基于 SOA 的解決方案的優勢。分析人員將對客戶的內部操作進行研究，此外還要分析其與合作伙伴、供應商以及他們的客戶的交互情況，而且也會研究其總體業務模型。這些因素有助于分析人員制定 SOA 策略并向客戶推薦。在此階段，您還需要對推薦的 SOA 策略進行全面的 ROI 分析。此分析應當清楚地表明短期、中期和長期的成本優勢
4.2.2???? 定義：
4.2.2.1??? 是 SOA 項目中最為關鍵的階段。此階段業務和項目團隊的參與將最終決定項目的成功
4.2.2.2??? 項目生命周期的此階段的活動包括：
4.2.2.2.1?? 收集需求
4.2.2.2.2?? 分析需求
4.2.2.2.3?? 定義非功能需求
4.2.2.2.4?? 制定項目計劃，其中包含時間安排和項目估算
4.2.2.2.5?? 定義技術基礎設施
4.2.2.2.6?? 定義和實現用例
4.2.2.2.7?? 定義和記錄總的體系結構
4.2.2.3??? 此階段的主要交付內容有：
4.2.2.3.1?? 功能需求文檔：詳細描述 SOA 將作為業務服務提供的所有業務流程。
4.2.2.3.2?? 非功能需求文檔：包括性能注意事項、服務水平協議 (SLA) 和基礎設施要求。
4.2.2.3.3?? 用例和用例實現：詳細說明將構建的所有業務服務的用例。
4.2.2.3.4?? SOA 體系結構文檔：描述項目總的體系結構，包括硬件和軟件組件。
4.2.2.3.5?? SOA 適用性文檔：說明哪些項目將在 SOA 項目的范圍內以及如何在 SOA 的基礎上構建后續項目。
4.2.2.3.6?? 基礎設施定義文檔：包括詳細的基礎設施部署圖，其中列出相關服務器以及實現 SOA 所需的服務器的連接和連接位置。
4.2.2.3.7?? 項目計劃：整個項目的詳細計劃，包括里程碑和依賴關系。
4.2.2.3.8?? 支持和控制模型：描述將如何支持和控制 SOA。其中包括各種注意事項，如 SLA 監視和管理。
4.2.3???? 設計：
4.2.3.1??? 對定義階段確定的設計構件進行細化。用例實現和軟件體系結構文檔將轉化為詳細的設計文檔
4.2.3.1.1?? 此階段的主要交付內容有：
4.2.3.1.1.1?????? 詳細設計文檔：描述如何設計和構建服務。
4.2.3.1.1.2?????? 應用程序編程模型：提供有關設計開發項目的結構的指南。涉及的主題包括使用的流程和技術、編碼標準以及部署過程。
4.2.3.1.1.3?????? 數據庫模型：包括 SOA 使用的數據庫的實體關系圖。
4.2.3.1.1.4?????? 測試和 QA 計劃：詳細說明測試和 QA 計劃，并在其中包括測試用例。
4.2.4???? 構造：
4.2.4.1??? 使用選擇的迭代構建方法來構建 SOA。此階段中包括新的開發和集成活動。活動不僅限于軟件方面，還涉及到與基礎設施相關的子項目，如硬件整合項目或服務器承載集中化工作。雖然整個工作是在單個 SOA 項目中進行管理的，但仍然很有可能將由各種小型子團隊進行不同的構造活動
4.2.4.2??? 項目生命周期的此階段將涉及到各種活動：
4.2.4.2.1?? 迭代開發
4.2.4.2.2?? 迭代 QA 和測試
4.2.4.2.3?? 用戶文檔
4.2.4.3??? 此階段的主要交付內容：
4.2.4.3.1?? 基本代碼：該代碼應存儲在某類源代碼管理存儲庫中。
4.2.4.3.2?? 測試結果：執行測試用例和 QA 計劃的結果應可供進行檢查分析。
4.2.4.3.3?? 文檔：文檔中應包含關于代碼以及對設計文檔的任何更新的詳細信息
4.2.5???? 部署：
4.2.5.1??? 在部署階段，將向各個項目團隊推出 SOA，這些項目團隊將開始在其生產環境中的項目上使用此 SOA。此階段最明顯的主要交付內容或許就是投入生產環境中使用的應用程序。然而，SOA 試驗項目的計劃卻是更為重要的交付內容。這將導致進入 SOUP 方法的下一個步驟，該步驟將確定后續項目如何使用新體系結構。
4.2.5.2??? 此階段的其他主要交付內容有：
4.2.5.2.1?? 部署模型：給出總的 SOA 部署結構。
4.2.5.2.2?? 用況模型：提供有關如何使用 SOA 的指南。隨著各個項目團隊和業務線開始使用新體系結構，此模型會變得非常重要。
4.2.5.2.3?? 后續支持級別模型：將對定義階段開發的支持和控制模型的任何更新進行系統化。
4.2.6???? 支持：
4.2.6.1??? 軟件開發周期的這最后一個步驟非常重要。在支持階段，您將確保提供后續 SOA 支持、錯誤修正和進行新功能開發。項目生命周期的此階段將涉及到各種活動：
4.2.6.1.1?? 維護
4.2.6.1.2?? 錯誤修正
4.2.6.1.3?? 培訓
4.2.6.1.4?? 持續項目投入
總結
- 上一篇： 建行分期通被拒还可以申请吗
- 下一篇： 程序员的灯下黑：能认识自己吗？