體系結構實踐，第 4 部分: 場景 1：實際 SOA 場景中的服務創建選項

使用 IBM? 面向服務的體系結構（Service-Oriented Architecture，SOA）基礎生命周期在軟件開發上下文中討論 SOA。體系結構實踐 專欄的本部分將重點討論 SOA 場景中的第一個場景，服務創建場景。探究 SOA 中的三個主要服務來源，以及為恰當使用相關服務提供指導的體系結構模式。熟悉各個模式及 SOA 生命周期中的各種活動，并了解用于實現和實例化這些模式的 IBM 產品的常用建議。

引言

體系結構實踐 專欄文章的第 1 部分“理解面向服務的體系結構”討論了 IBM 的面向服務的體系結構 (SOA) 基礎生命周期（或 SOA 生命周期），以及其如何允許 IBM 客戶從軟件開發生命周期的角度來看待 SOA。其中詳細討論了 IBM SOA 生命周期的四個階段——建模、組裝、部署和管理。

本專欄討論各種廣泛的主題。有關 IBM SOA 場景的更多信息，請閱讀第 2 部分“SOA 解決方案場景介紹”，其中介紹了典型的基于 SOA 的 IT 項目中的八個最常見場景。第 2 部分對各個場景進行了說明，解釋了其背后的理念以及能夠對其加以應用的廣泛上下文。第 2 部分還討論了用于將特定 SOA 場景應用到啟用服務的典型遺留項目。

本文（第 4 部分）重點討論八個場景中的第一個場景：服務創建場景，可幫助您了解 SOA 如何幫助解決典型的業務挑戰。本文將討論不同的服務創建選項背后的基本原理，并將給出各個選項最相關和最適用的情況。 對于每個服務創建選項，文章中會將其與 SOA 生命周期中各個階段的高級活動對應起來。另外還將包括有關可用于實現生命周期每個階段的活動的一個或多個 IBM 產品和工具的建議。

處理業務挑戰

快速而有效地實現業務計劃是大部分組織都必須處理的一項主要業務挑戰。企業必須能夠認識各種市場情況并快速地調整其戰略，以反映變化。為了獲得這種靈活的業務模型，需要有同樣靈活的 IT 基礎設施作為支持。SOA 中的服務 定義為自包含的可重用軟件模塊，用于執行特定業務任務。現在將這些服務作為基礎軟件構建塊使用，以提供靈活的 IT 解決方案。服務具有定義良好的接口，獨立于其運行的應用程序和計算平臺。在現在的環境中，必須了解您的業務及流程（作為一組相互聯系的可重復業務任務執行，可以將這些業務任務方便地進行重新排列）。

您的組織需要一種機制來為增值投資（提供獨有功能的任務）分配資源。您需要將資源集中在能給業務帶來突出優勢和價值的投資上，而不用擔心經常出現的低價值瑣事級的任務。

您還會希望業務能夠穩定地增長。您需要確保自己了解和信任的業務系統具有良好的性能和可靠性，同時與值得信賴的業務合作伙伴和服務提供商合作，以便獲得您所需要的服務。而且，如果選擇收購某個企業，則必須能夠將其業務系統與您的系統集成，以確保快速形成統一體。

所建議工具或技術的詳細說明不在本文的討論范疇內。有關更多信息，請參見參考資料部分。

一個不錯的著手點是將業務已有的東西 與業務所需的東西 進行比較。建模現有業務流程和未來業務模型，并模擬其功能和效果，從而提供關于業務應該如何運行的參考框架。然后考慮組成業務流程的各個任務應該如何完成的問題。每個任務都需要由服務提供支持。通過 SOA 可以將這些服務連接為靈活的模塊化系統，從而為靈活業務模型提供支持。確定服務來自何處是實現優化業務流程遠景的第一步。

回頁首

服務創建場景的訪問模式

IBM 確定了 SOA 中服務的三個主要來源，如圖 1 中所示。

四個常用體系結構模式提供了相關指南，說明了關于如何恰當地使用三個主要來源提供的服務創建基于服務的 IT 解決方案。建議的方法是將需要的東西與已有的東西進行比較。可以自己從頭創建服務、購買服務或使用現有的支持服務的打包軟件或自定義軟件。可以通過以下方式利用所有三個類別的服務：

• 現有應用程序和資產中的現成高價值軟件應用程序和系統支持的服務啟用任務。
• 使用外部提供的服務支持瑣碎任務。
• 僅在需要填補剩余空白領域時創建新服務。

啟用服務的現有資產

SOA 并不是“拆除和替換”。最好的做法是在現有應用程序、系統和資產中確定可重用的高價值業務任務，并采用 SOA 的原則和技術來公開服務。重用已有的應用程序和系統是一項非常明智的業務決策。可以減少新技術方面的投資，而使用現有業務邏輯（這是公司擁有的最寶貴且經過驗證和時間考驗的資產）。當前應用程序的服務啟用工作可以大幅度加速 SOA 項目的采用進度，并能降低其風險。研究表明，這樣的開銷比從頭構建方法少五倍。由于常用功能的代碼已經過了嚴格的生產使用的檢驗，因此其維護開銷也會減少。

在此技術中，單個服務可以利用一個打包或自定義應用程序或者多個系統來提供其預期功能。例如，SAP 客戶關系管理系統中的地址記錄可以與基于大型機的遺留財務系統進行組合，以創建支持開設新客戶帳戶的服務。此組合服務可以為涉及配送和開單的訂單輸入業務流程提供部分支持。這樣減少了服務大幅度增加的風險，不會在不管粒度如何的情況下將任何現有 IT 功能都視為服務并加以公開。通過應用恰當的 SOA 方法，如 IBM 提供的面向服務的建模和體系結構（Service-Oriented Modeling and Architecture，SOMA）（請參見參考資料），可以解決服務粒度問題。

用于處理啟用服務的現有資產的兩個最流行的體系結構模式如下：

• 直接將現有應用程序功能作為服務公開。
• 將功能作為服務組件間接公開。

直接將現有應用程序功能作為服務公開

當必須將現有應用程序功能作為服務公開，以供其他系統和應用程序使用，或提供更多的訪問渠道時，則使用此方法。對于此模式（如圖 3 中所示），其中假定您采用非常簡單的場景，其中的現有功能并不復雜，只是使用 Web 服務技術將其作為服務提供者部署。這個簡單的拓撲并不需要任何新基礎設施，因為此服務使用支持服務的現有應用程序（通常為遺留應用程序）的工具和技術實現。

例如，可以使用 IBM CICS? Transaction Server V3.1 Web 服務技術將 COMMAREA 應用程序直接作為 Web 服務公開。最低要求是所公開的服務符合 WS-I Basic Profile 的要求。（有關技術模式以及現有遺留功能如何作為服務公開的更多信息，請參見參考資料。）

對于此方法，一個好處是服務接口由所公開的遺留資產定義，因此不需要進行分析來設計接口規范。而且，由于新服務可以在與包裝的現有資產相同的平臺上運行，因此沒有必要添加新基礎設施。能省略接口定義和分析，而且要處理的平臺更少，這樣部署周期就會更短。

采用此體系結構模式來提供服務器支持時，需要考慮以下主要體系結構注意事項：

• 服務使用者與遺留資產的定義建立聯系，而后者在很多情況下的最初設計都比較糟糕。
• 此模式假定現有應用程序平臺提供了對服務調用的最新技術的支持。
• 實現模式經常給系統帶來高服務消息處理負擔，而這些系統經常針對無內部互鎖管道級的微處理器（Microprocessor without Interlocked Pipeline Stages，MIPS）使用進行了優化。

 

將功能作為服務組件間接公開

此服務支持體系結構模式代表了在現有應用程序功能和服務之間引入中間軟件組件（稱為服務組件）的情況。下面的圖 4 顯示了一個示例。

服務組件也稱為企業組件（請參見參考資料），是提供服務和實際實現之間的抽象層的 IT 組件。服務組件可以通過以下方式之一發揮作用：

• 從頭創建業務邏輯和功能時，服務組件可以對內聚業務邏輯從邏輯和功能方面進行封裝。
• 當必須對一個或多個現有操作系統的業務邏輯集成和重用，從而為服務提供集成業務邏輯實現時，服務組件可以封裝對外圍操作系統（可能為異類系統）的訪問機制。

 

使用中間服務組件有一些好處：

• 可以在不影響服務使用者的情況下更改現有操作系統中的業務邏輯實現。服務組件可以方便地進行擴展，以封裝數據和信息，并為數據或信息服務提供外觀層。
• 可以在操作系統層進行系統和功能的 IT 合并或遷移，而對服務使用者的影響很小或者沒有影響。
• 可以將服務部署在與現有應用程序不同的基礎設施上，而現有應用程序的基礎設施通常針對服務的特定處理要求進行了硬編碼。

 

對于直接將應用程序功能作為服務公開的情況，此模式還有一些主要體系結構注意事項。首先，它允許與業務保持緊密一致但并不一定直接映射到現有應用程序接口的服務接口定義。可以使用 SOA 的原則和最佳實踐來以正確的粒度級別設計服務和接口。不過，這會增加恰當定義服務的設計時間，而且開發周期更長。其次，其設計經常比直接公開更為復雜，因為可能會涉及到使用適配器或連接器技術來與操作系統進行連接。

使用外部提供的服務

在此場景中，服務的來源為一個或多個第三方服務提供商。應用程序利用第三方服務來實現其所需的功能。圖 5 顯示了服務如何依賴第三方實現提供者進行實現。

此模式的主要優勢在于，并不需要花時間為服務定義開發實現構件，將由外部服務提供者提供這些構件。這可以大幅度減少開發時間。還有個值得注意的優勢是，客戶機能夠根據各種技術、財務和政策注意事項在服務提供者之間進行切換。

有一些主要體系結構注意事項需要加以處理：

• 必須恰當地定義服務的服務級別協議（Service-Level Agreement，SLA）。在尋找最佳的第三方提供商時，滿足 SLA 的能力是一項重要考慮事項。
• 由于服務實現位于企業防火墻之外，所以必須為服務及其調用配備恰當的安全性措施。
• 應該非常強調服務治理，以建立用于選擇最合適的服務提供者的標準。對行業及開放標準的遵從，以及作為服務提供者的第三方的成熟度之類的因素，應該由治理組織加以確定。

從頭構建服務

在此場景中，必須從頭設計、定義和開發服務。現有應用程序或任何第三方提供商都不能提供功能或服務來滿足您的需求。此場景依賴于 Java? 2 Platform Enterprise Edition (J2EE) 應用服務器支持服務實現。核心業務功能通常使用標準 J2EE 開發，而且通常采用 Enterprise JavaBeans (EJB) 或簡單的傳統 Java 對象（Plain Old Java Object，POJO）的形式。采用了標準 J2EE 集成開發環境（Integrated Development Environment，IDE）功能和技術來將 EJB 或 POJO 轉換為標準 Web 服務。

此方法的優勢在于，可通過其根據現有業務需求建模服務，并對其進行恰當的設計來滿足將來的業務需求。服務并不受現有操作系統或第三方提供商的約束。

體系結構方面的一個重要注意事項是，需要在整個服務開發流程中（從表示到規范再到實現）應用完整的 SOA 方法（例如 SOMA）。

回頁首

服務定義和實現“菜譜”

前一部分所討論的體系結構模式可幫助標識和設計服務，需要對其進行實例化，以實現端到端 SOA 解決方案。您需要將模式步驟應用到 SOA 生命周期中，并提供正確的工具和產品來創建特定的 SOA 構件。

IBM 使用和遵循 SOA 生命周期（建模、組裝、部署和管理）、治理和流程；我們確定了可應用于 SOA 生命周期的每個階段的每個體系結構的活動（請參見參考資料）。IBM 還提供了大量的相關產品，可幫助實現任何工業強度 SOA 解決方案。

此部分將以下體系結構模式及其較高級別的活動放入 SOA 生命周期的上下文中進行討論：

• 現有功能的直接公開
• 現有功能的間接公開
• 第三方提供的服務
• 從頭創建的服務

實現現有功能的公開

和所有 SOA 項目一樣，最好從生命周期的角度來看待現有功能的直接公開（也稱為現有 IT 資產的服務支持）。此處我們將利用得到廣泛認可的 IBM SOA Foundation 所定義的服務生命周期。圖 6 顯示了可以如何應用 SOA 生命周期來為現有資產啟用服務。

SOA 生命周期的每個階段都可以應用到服務支持工作中。建議的較高級別的活動包括：

建模

開始從當前 IT 應用程序和系統投資組合中形成候選資產目錄，以啟動建模階段。在此階段，最需要關注的是服務建模方法。IBM 的 SOMA 方法是用于面向服務的建模的可靠且經過嚴格驗證的方法。Rational? Unified Process (RUP) 也擴展為可處理面向服務的方法 (RUP for SOA)。RUP for SOA 基于 SOMA 方法。IBM 的 Rational Software Architect (RSA) 提供了建模框架對服務模型進行建模和設計。

組裝

使用各項技術在不更改其提供的基本功能的情況下將資產轉換為可重用服務。轉換流程實際上將涉及使用定義良好的接口包裝現有功能。

在此階段，通常為在 IBM System z? 系統（之前的 IBM eServer?zSeries? 系統）上運行的 CICS 應用程序提供服務支持的工具是名為 IBM WebSphere? Developer for zSeries (WDz) 的 IDE。將需要啟用服務支持的現有代碼庫導入到 WDz 的工作區中。可以利用工具功能來開發 Web 服務描述語言（Web Services Description Language，WSDL）定義。在此過程中，現有應用程序的數據和語言結構可能需要一些映射和轉換。可以從此 IDE 生成 WSDL 和特定應用程序綁定。

組裝階段也包括對所開發代碼的單元測試。WDz 提供了用于 CICS Transaction Server (TS) 的測試環境，提供了所有基本功能，以便測試在實際工業強度 CICS TS 上運行的 WSDL。可以在 CICS TS 測試環境中作為組裝階段的一部分對生成的 WSDL 進行測試。

部署

使用 SOA 基礎設施和中間件產品來部署服務，從而將訪問擴展到其他涉及到更多系統和用戶的功能。

在此階段，要將經過單元測試的 WSDL 和所生成的 COBOL 源代碼（進行了可能的數據和語言轉換后）部署到 CTS 上。隨 CTS 3.1 提供了很多 Web 服務功能（如 WS-Security），可以在部署過程中對其進行配置。

管理

以實時方式仔細管理和監視所部署的服務，以了解更新后的資產的性能和安全性。對于此階段，主要的焦點轉移到了管理和監視所部署的服務上。必須仔細地監視服務，以確保遵從已發布的功能和非功能需求。

IBM 的 Tivoli? 品牌產品針對一般系統管理和監視進行了優化，包含用于滿足監視和管理服務的大量產品。Tivoli Omegamon-XE for CICS 3.1 常用于在 IBM z/OS? 上管理和監視 CICS TS。Tivoli 還提供了一套產品，專門針對服務調用和安全性的特定領域，如：

• IBM Tivoli Federated Identity Manager (ITFIM)，提供松散耦合聯合標識模型來跨企業邊界管理標識。
• IBM Tivoli Identity Manager (ITIM)，提供企業內的集中標識管理系統。
• IBM Tivoli Access Manager (ITAM)，提供單點登錄和授權功能。

 

治理和流程

確保遵循服務生命周期及其有效控制和管理方面的策略、標準和最佳實踐。

對于此階段，WebSphere Service Registry and Repository (WSRR) 是支持整個 SOA 生命周期的 IBM 產品。WSRR 允許服務提供者安全地注冊業務服務，以供服務使用者進行查找和綁定。另外還提供了發布在 SOA 中管理服務的生命周期所需的元數據的功能。

總而言之，在實現直接訪問現有應用程序的模式時，可以遵循標準 IBM SOA 生命周期的階段，并在各個階段中使用以下產品：

• RSA，用于服務的建模和設計。
• WebSphere Developer for zSeries，用于將現有功能組合為服務，并從 CICS TS Test Environment 對其進行單元測試。
• 在 CICS TS 3.1 上部署服務定義以及所生成的遺留代碼。
• 使用一系列 Tivoli 管理與監視產品，如主要用于管理和監視服務 SLA 的 Tivoli Omegamon-XE、ITFIM、ITAM 等。
• WebSphere Service Registry and Repository，用于在 SOA 中在服務的整個生命周期中對其進行管理。

實現現有功能的間接公開

服務創建的每個機制都具有一組規程，即給定場景下最常遵循的步驟。前面所述的這些步驟可以與 SOA 生命周期的五個階段建立聯系。此場景的主要步驟與實現現有功能的公開非常相似，因此將不在此進行重復說明了。

正如服務創建場景的訪問模式中所述，間接公開和直接公開的區別在于其中包含了服務組件層。服務組件提供與業務保持一致的服務接口——自頂向下方法。通過分析現有資產，可以確定可以使用哪些系統中的哪些應用程序功能來實現服務組件定義的服務接口。服務組件充當業務中心視圖和現有應用程序之間的中間層。因此，這個新的外觀組件在組裝階段需要執行額外的步驟。

在建模階段，可以使用 SOMA 方法及其抽象規范進行服務定義。這與第一個訪問模式并沒有太大的區別。在這兩者中，都將執行 SOMA 的服務標識階段。不過，其區別在于階段中的活動重點。在直接公開期間，其重點在現有資產分析上。在非直接公開場景中，重點在使用自頂向下方法標識與業務一致的服務。此處建議使用的 IBM 產品是 Rational Software Architect。

在組裝階段，最常用的工具是 Rational Application Developer (RAD)。如果在此階段將 RAD 作為 IDE 使用，請遵循以下步驟：

• 在 RAD 工作區創建 Web 或 J2EE 項目——最好是新項目。從與業務一致的角度來認識服務及其接口操作，并據此定義 WSDL。使用 SOMA 標識階段的輸入來定義與業務一致的服務（業務服務）。如果已經定義了 WSDL 并且其可用，直接將其導入到 RAD 的項目工作區中即可。

   

• 從 WSDL 生成會話 EJB 框架。應該隨后實現所有操作的業務邏輯。對于遺留系統在其他環境中運行的情況，應該在實現期間使用適配器技術。例如，對于在獨立 System z (zSeries) 計算機上運行的 CICS 應用程序，需要使用 CICS ECI 資源適配器連接到 CICS 系統。

  資源適配器通常采用資源存檔 (.rar) 文件的形式，需導入到 RAD 工作區。資源適配器包包含應用程序編程接口（Application Program Interface，API），可用于幫助從會話 EJB 訪問 CICS 應用程序。還應該針對遺留系統中使用的特定語言使用相關的 Java 數據綁定。

• 將 WSDL 定義以及所實現的會話 EJB、Java 數據綁定以及可選資源適配器打包為企業存檔（Enterprise ARchive，EAR）文件，以供進行部署。

盡管在組裝階段使用 RAD 是一種很常見的做法，但很多 IT 企業僅在使用遺留系統方面非常專業。在這樣的客戶機環境中，建議使用 WebSphere Developer for z (WDz)。WDz V6.0.1 提供了內置的 CICS TS 測試環境，可與 CICS Transaction Gateway V6.0.2 組合使用，從而提供一個非常強大的用于從遺留系統公開服務的環境。

如前面所提到的，WebSphere Service Registry and Repository 是用于服務生命周期治理的標準 IBM 產品，同時我們也建議使用此產品。

實現第三方提供的服務

當現有遺留系統和應用程序過于晦澀難解而難以替換，或業務需求要求提供現有系統中沒有的功能時，則下一個選項就是第三方服務提供商。行業中經常出現第三方程序包提供的功能影響企業的業務需求的情況。很多企業都出現了這樣的情況，但后來卻發現由于所感興趣的第三方程序包的特性或功能影響，就開始改變自己的業務需求。這是 SOA 采用中的一個反模式，應該加以避免。

在此場景中，功能需求可由第三方服務提供商完全或幾乎完全滿足。在業務需求強制要求的可接受限制范圍內，必須滿足功能需求和 SLA 需求。

此場景的高級活動也可以映射到 SOA 生命周期的各個階段，如圖 7 中所示。

SOA 生命周期的每個階段都可以應用到服務支持工作中。建議的高級活動總結如下：

建模

首先運行轉換范圍內的業務流程的模擬，并決定哪些服務適合自己創建，哪些服務適合從外部獲取。

在建模階段，重點是分析使用第三方服務提供商而不自行構建服務的理由。將執行各種業務分析和模擬，并評估成本、時間、資源和 IT 可行性。

組裝

訪問外部服務，并將其與自有服務編排在一起，從而支持端到端業務流程。組裝將對第三方服務和企業自有服務進行編排。

在組裝階段，將執行主要工作。所建議的 IBM 產品為 RAD。相關步驟包括：

1. 從服務提供者獲取 WSDL。
2. 驗證 WSDL，并與提供者進行合作，以成功地通過完整的驗證。
3. 在 RAD 中創建新企業應用程序。
4. 將 WSDL 導入項目工作區。
5. 從 WSDL 生成客戶端存根。這時請仔細分析哪種 XML 綁定類型是恰當的（JAX-RPC、JAXB 等）。
6. 根據客戶端存根開發客戶機應用程序，以調用服務。
7. 將項目打包為可部署 EAR 文件。

 

部署

可以對經過編排的服務進行部署，而不用擔心每個服務的出處。

在此階段，可部署 EAR 文件安裝在 Web 服務兼容中間件服務器上。此處建議的 IBM 產品是 WebSphere Application Server。所安裝的 EAR 文件提供了客戶端 API，以使用第三方服務。

管理

如果第三方服務提供商進行實現工作，則務必監視服務，以確定是否符合和滿足業務強制要求的 SLA 和合同規定的關鍵性能指標（Key Performance Indicator，KPI）。IBM Tivoli Composite Application Management (ITCAM) for SOA 是用于監視運行時服務器來確定遵從性的最為全面的 Tivoli 產品。

 

治理和流程

在注冊中心創建和維護外部服務目錄，以方便訪問和管理。

在此階段，將提供外部服務的 WSDL 定義此階段建議的 IBM 產品是 WebSphere Service Registry and Repository (WSRR)。任何采用服務增強形式出現的更改都在管理服務的生命周期的 WSRR 中進行管理。

實現從頭創建的服務

此場景通常是最后的選擇。當沒有現有應用程序功能可以直接或間接地作為服務公開，而且沒有第三方服務提供商提供所需的業務功能時，就會采用此方法。服務定義和所有實現構件都需要從頭構建。這可能看起來很簡單，沒有需要作為基礎的現有遺留系統，沒有要集成的遺留代碼，沒有要掛接的第三方提供商服務，也沒有部署時要考慮的復雜拓撲。但要確定服務標識和深入規范，可能會有不少的工作要做。圖 8 顯示了 SOA 生命周期的不同階段的主要活動。

從 SOA 生命周期的角度而言，從頭創建服務所涉及的活動如下：

建模

其重點在于設計與服務一致的服務，同時涵蓋當前需求和將來的需求。建議的方法是應用 SOMA 的服務標識技術，并同時使用 Rational Software Architect 進行服務建模，以創建實際的建模構件。

 

組裝

用于服務開發的建議 IBM 產品是 Rational Application Developer (RAD)；RAD 是一個可靠且功能豐富的 J2EE 應用程序開發 IDE，它還提供了用于服務開發和實現的各種簡單功能和高級功能。它提供了基本服務實現的簡單功能，并將其作為 WSDL 文件公開。Rational Application Developer 還可以添加有關 Web 服務實現的高級功能，從 WS-I 遵從性開始，以增量方式逐漸添加 WS-Addressing、WS-Transactions 等實現。使用 Rational Application Developer 進行服務開發的一般步驟（與實現第三方提供的服務類似）如下：

1. 在 Rational Application Developer 中的新工作區創建 J2EE 企業應用程序項目。
2. 基于服務的設計規范創建 WSDL 定義。或者，如果存在 WSDL，則將其導入工作區。
3. 從 WSDL 生成會話 EJB 服務框架。
4. 為服務框架中的所有已定義操作完成業務邏輯實現。
5. 或者，創建用于調用服務的 Web 服務客戶機代碼。對于調用服務的 J2EE 應用程序客戶機，此客戶機代碼已經足夠了。對于非 J2EE 客戶機，需要提供技術特定的客戶機代碼來進行服務調用。
6. 將實現構件打包為部署時使用的 EAR 文件。

對于將企業業務流程作為服務編排實現的端到端解決方案，可以將此場景作為服務設計和開發工作進行構造；組裝是這些服務在業務流程上下文中的編排。

建議使用的 IBM 工具為 WebSphere Integration Developer (Integration Developer)，此工具提供了業務流程執行語言（Business Process Execution Language，BPEL）開發環境。除了其他功能外，還提供了將現有服務編排為業務流程流的功能。所得到的流程可以隨后部署到 BPEL 運行時引擎中，從而提供編排功能來執行企業級業務流程。

部署

經過打包的 EAR 部署模塊安裝到 WebSphere Application Server 運行時上。對于分布式環境，建議使用 WebSphere Application Server Network Deployment Edition V6 作為運行服務的中間件。要部署所提到的業務流程，建議使用的 IBM 產品是 WebSphere Process Server V6（屬于 IBM WebSphere Business Service Fabric 中間件）。

管理

需要對所部署的服務進行監視和管理。監視通常是保證遵從服務的 SLA 的典型強制要求，并在達到不遵從閾值時引發警報或事件。在企業范圍外公開服務時，最低要求是，要保證非授權訪問無法訪問服務。前面提到的 Tivoli 產品均適用于此場景。簡要總結如下：

• IBM Tivoli Composite Application Management (ITCAM) for SOA，用于監視服務以確保 SLA 遵從性。
• IBM Tivoli Federated Identity Manager (ITFIM)，用于在整個企業范圍內進行聯合標識管理。
• IBM Tivoli Identity Manager (ITIM)，用于跨企業系統提供集中標識。
• IBM Tivoli Access Manager (ITAM)，用于單點登錄和在服務調用前進行授權。

治理和流程

服務生命周期管理的建議 IBM 產品是 WebSphere Service Registry and Repository，此產品具有可靠的高級功能，能以模塊化的方式進行使用。

回頁首

總結

IBM 確定了典型的基于 SOA 的 IT 項目的八個不同的常見 SOA 場景。IBM 還提供了全面的指導信息，說明應該如何使用面向 SOA 的 IBM 工具、產品及方法對每個場景進行建模、設計和實現。

在本文中，我們討論了第一個 SOA 場景，服務創建。我們還對基于以下三個主要服務來源進行良好服務支持的四個最常用的體系結構模式進行了概述：現有應用程序、第三方服務提供商以及從頭創建服務。另外，我們還了解了如何將 SOA 生命周期應用到四個體系結構訪問模式，以及 IBM 產品套件可以如何處理服務支持的特定設計、開發和運行時需求。