整合 WebSphere Process Server 與 SCA 功能包，第 1 部分

簡介： WebSphere® SCA Feature Pack 實現 OSOA SCA V1.0 規範，提供靈活且輕量級的程式設計模型來實現面向服務架構（SOA）服務。WebSphere Process Server 是一個行業領先的流程整合伺服器，在 IT 行業被廣泛應用。Process Server V7 和 SCA Feature Pack V1.0.1 的最新版本已得到增強，可以在這兩種執行時環境中進行事務和安全 SOA 服務的無縫互操作。本系列文章將幫助您配置並使用 SCA 繫結、Web 服務繫結和 JMS 繫結來連線這兩種型別的服務。

簡介

通過 WebSphere Process Server V7.0 和 WebSphere Application Server V7.0 Feature Pack for Service Component Architecture (SCA) V1.0.1，我們可以在使用 WebSphere Integration Developer V7.0（以下簡稱 Integration Developer）構造的 SOA 服務與使用 SCA 的 Rational Application Developer V7.5.5 之間進行互操作。本文是一個系列文章的第一篇，通過一個包含這兩種元件的示例應用程式來說明如何利用 Classic SCA 與 Open SCA 之間的互操作性。在本篇文章中，我們將介紹 Classic SCA 和 Open SCA 的歷史，並闡述如何組合、部署和測試由 Classic SCA 和 Open SCA 元件組成的應用程式。在後面的文章中，我們將應用程式更改為使用 JMS 和 Web Services 繫結。本文中講述的互操作能力也適用於 WebSphere Enterprise Service Bus (ESB) V7.0。

先決條件

本系列文章假設您熟悉 SCA 概念並且具有開發 SCA 應用程式的經驗。要檢視並試用 示例應用程式，需要安裝下列軟體：

• WebSphere Integration Developer V7.0
• 支援 SCA 的 Rational Application Developer V7.5.5

動機

雖然支援 SCA 的 IBM 產品在繼續改進和增強構造及支援 SOA 服務的能力，每個產品集都提供了獨特的功能，可以聯合起來提供一個全面的解決方案。WebSphere 業務流程管理（BPM）平臺為構建業務流程、業務規則、ESB 中介以及自定義的基於傳統 Java™ 物件（POJO）的業務邏輯提供 SCA 支援。WebSphere Application Server（以下簡稱 Application Server）為各種基於 Java 的程式設計提供 SCA 支援，例如 Java POJO、JEE 和 Spring。需要 SOA 方法和異構實現技術的應用程式方案可以受益於本系列文章中提到的技術。

在探究示例應用程式之前，需要確立一些術語來支援本系列文章中設定的上下文。詞語 “互操作”（及其派生形式）只表示交換和正確解釋在兩種服務之間傳送的訊息的能力。需要注意的是，此定義明確略去了 “可移植性”，其定義為在一個平臺上開發 SCA 元件而在另一個平臺上部署該元件的能力。因為 SCA 是一個元件模型，其定義包含一個程式設計模型，所以可能會使人認為互操作也包括可移植性，但事實並非如此。

SCA 是在 2005 年發行 WebSphere Process Server 時由 IBM 首次開發的。至此以後它被併入到 IBM BPM 產品系列中，提供健壯且可伸縮的 SOA 基礎設施，該基礎設施在 BPM 平臺中非常重要。在本系列文章中，我們將由在 WebSphere Process Server 上執行的 BPM 平臺承載的 SCA 元件稱為 “Classic SCA” 元件。WebSphere Process Server V7.0 就是這樣一個平臺。

同時，SCA 被引入一個稱為 Open SOA Collaboration (OSOA) 的開放的行業協會。該團體是由 IBM 和行業合作伙伴聯合建立的，作為一個開放的論壇，SOA 技術在被引入正式的標準團體作為官方標準之前將在該論壇中得到開發和優化。IBM 將 Classic SCA 作為 SOA 元件模型的基礎貢獻出去。OSOA Collaboration 在 2007 年完成了它的工作並將所得到的 SCA V1.0 規範貢獻給 OASIS 作為標準。今天，OASIS 幾乎完成 SCA V1.1 規範系列。在本系列文章中，術語 “Open SCA” 用於指示 SCA V1.x 平臺承載的元件。WebSphere Application Server V7.0 Feature Pack for Service Component Architecture (SCA) V1.0.1 是本系列文章中將使用的 Open SCA 平臺。

那麼 Classic SCA 和 Open SCA 之間的區別是什麼？正如技術委員會工作中經常發生的那樣，反映用例、優先順序甚至成員組織偏好的輸入概念有改動。但是，重要的 Classic SCA 概念在 Open SCA 規範中仍保持不變。提供服務（服務介面）和使用其他服務（引用）的諸如元件的概念存在於這兩種元件模型中。

元件具有一個通過其屬性配置的實現。元件服務和引用都具有繫結，這些繫結配置為通過標準有線傳輸和協議（比如 Web 服務或 JMS）來進行通訊。還有一個稱為 “SCA（預設）繫結” 的非標準繫結，它提供一種簡單的方式來連線遠端服務。所有這些概念都同時存在於 Classic SCA 和 Open SCA 中。

本系列文章中使用的 示例應用程式 將闡釋所有這些概念。下面是仍存在的主要區別列表以及一些簡要說明區別性質的註釋。本文不提供全面完整的比較。表 1 中列出了您在本系列文章中將遇到的概念。

表 1. Classic SCA 和 Open SCA 概念比較

示例概述

本系列文章中使用的 示例應用程式 是一個虛構的糖果店應用程式，該應用程式是從 WebSphere Application Server V7 SCA Feature Pack V1.0.1 中的糖果店示例衍生而來的。糖果店的客戶訪問商店 Web 站點，從顯示的線上目錄訂購糖果。該糖果店具有一項業務政策，線上訂單必須超過 10 美元。當購物者選擇完糖果後，他或她將通過結算流程來購買選擇的糖果。結算過程將進入一個業務流程，該流程記錄採購請求、檢查業務規則以便確保滿足訂單下限，如果滿足，將對客戶的信用卡收費存檔。最後，該業務流程記錄處理採購請求的結果，然後返回。

該功能細分如下：

• Web UI 互動：終端使用者 Web UI 通過三個協作 JSP 來實現，這些 JSP 顯示目錄和購物者的購物車中的東西、收集購物者的客戶編號，並提供成功採購的確認號碼。
• Open SCA 服務：有三種 Open SCA 服務。第一，糖果店提供目錄和購物車功能。第二，對客戶的信用卡收費的信用卡服務。第三，記錄採購請求和結果的記錄服務。
• Classic SCA 服務：這是該示例的核心。它是一個 BPEL 微流程，在購物者結算時糖果店 Open SCA 服務將呼叫該微流程。它使用業務規則、Open SCA 信用卡服務和 Open SCA 記錄服務。

客戶端

終端使用者互動由 Web 瀏覽器驅動。圖 1 中顯示了圖形螢幕流程。

圖 1. UI 檢視

主購物螢幕從圖 1 的左上角開始。它包含線上糖果目錄和購物者的虛擬購物車中的東西。購物者已經完成購物時，單擊 Checkout 按鈕將使 UI 導航到第二個螢幕，在那裡將詢問購物者的客戶編號。輸入客戶編號後，購物者單擊 Buy it 按鈕啟動採購。此互動將導致執行付款業務流程。付款完成後，將返回確認號碼。

服務

糖果店服務包含在 Open SCA 商店組合中，由三個 Java 元件組成，這些元件相互作用來提供購物車、產品目錄以及商店自身的主要功能。這些元件如圖 2 所示。

圖 2. Open SCA 商店組合檢視

StoreComponent 提供了一個 Web UI 層的服務介面，使用 StoreCatalog 元件來提供線上糖果目錄，並使用 StoreShoppingCart 元件來存放購物者的當前訂單。StoreShoppingCart 包含引用，但是請注意它不連線到此組合中的任何服務。引用將連線到 BPEL 付款業務流程，因此這是本文的要點。

Classic SCA 付款服務包含在 Classic SCA 模組內。圖 3 顯示了組合圖表，說明提供線上訂單付款的所有元件。

圖 3. Classic SCA 付款組合圖表

• PaymentService 匯出公開了一個供 Open SCA 商店服務使用的 SOA 介面。
• PaymentProcess 元件存放 BPEL 流程實現。
• ChargeLimit 規則集提供業務規則，強制線上商店 10 美元的下限。
• CreditCardCharge 匯入表示對信用卡收費服務的依賴，該服務不是此模組的一部分。
• 最後，AuditLogger 匯入表示對稽核記錄服務的依賴，該服務也不是此模組的一部分。

CreditCardCharge 和 AuditLogger 匯入都連線到 Open SCA 服務，本文後面將介紹這些服務。

圖 4 中顯示了 BPEL 付款業務流程。

圖 4. 付款業務流程

根據採購金額是否滿足 10 美元的下限，業務流程有兩條通路。如果訂單的金額太低，則向呼叫者返回錯誤。如果金額超過下限，則向客戶的信用卡收費。流程的所有通路都將呼叫稽核記錄程式來記錄流程的始末。

示例中的最後兩個服務是簡單的 Open SCA 服務，每個服務通過一個元件來實現。CreditCard 元件提供信用卡收費功能，Logger 元件跟蹤採購（以及採購嘗試）。每個元件都包含在其自己的 Open SCA 組合中。

SCA 繫結

Classic SCA 和 Open SCA 都可以通過 SCA 繫結將遠端服務連線在一起。SCA 繫結優於行業標準繫結（比如 Web 服務或 JMS）之處在於，SCA 繫結幾乎不需要任何配置。SCA 執行時平臺負責動態確定如何進行或接收服務呼叫。圖 5 中完整呈現了示例中的所有 SCA 元件。

圖 5. 示例中所有 SCA 元件的檢視

圖表中的紅線表示跨不同 SCA 執行時的連線。通過修改 SCA 繫結屬性可以輕鬆配置這些連線。如果您希望直接跳到講述如何配置這些紅線的部分，則請繼續閱讀 將 Classic SCA 連線到 Open SCA 和 將 Open SCA 連線到 Classic SCA。

SCA 繫結限制

SCA 繫結具有一些限制，當設計包含來自 Classic SCA 和 Open SCA 的元件的應用程式時，這些限制非常重要。當限制不合適時，存在解決方案來減輕每種限制的影響。這些限制是：

• WebSphere 單元約束：無法配置 Classic SCA 或 Open SCA 繫結來連線位於 WebSphere 單元之外的服務。通過使用 Web 服務、JMS 等行業標準繫結可以減輕此限制的影響。
• WSDL 介面：Classic SCA 和 Open SCA 繫結之間的互操作性受限於 WSDL 介面。無法使用或公開具有 Java 介面的服務來進行 Open SCA 和 Classic SCA 之間的互操作。可以使用 Java 介面實現 Open SCA 到 Open SCA 或 Classic SCA 到 Classic SCA 的連線。WSDL 介面提供更多抽象，通常更適用於整合方案。僅對 WSDL 介面支援互操作性，該介面滿足下列標準：
  • Web Services Description Language (WSDL) V1.1
  • WS-I Basic Profile V1.1
  • Simple SOAP Binding Profile V1.0 標準
  • 文件文字樣式
• Application Server V7 SCA Feature Pack 中的 Open SCA Java 程式設計模型沒有用於非同步呼叫請求響應服務的 API。即，當前沒有程式設計模型 API 來傳送此類請求、繼續處理以及稍後在有響應時接受響應。在 Process Server 整合方案中，這意味著 Open SCA 元件不能通過需要響應的 SCA 繫結從 Open SCA 客戶端呼叫長時間執行的業務流程（有時稱為巨集流程）。如果互動是單向的，則沒有問題。OASIS SCA V1.1 規範中對此不足進行了說明。在解決該不足之前，Open SCA 元件必須使用一對單向介面來與長時間執行的請求-響應操作進行通訊。

付款模組（Classic SCA）

本文結尾的 示例工件 包括您可以匯入到 Integration Developer 的專案交換檔案。將 Payment.zip 和 PaymentLib.zip 檔案匯入 Integration Developer V7.0。這樣，將建立兩個專案，一個名為 “Payment”，另一個名為 “PaymentLib”。下面的步驟顯示瞭如何為相同的互操作性方案配置 Classic SCA 匯入和匯出。

將 Classic SCA 連線到 Open SCA

通過 SCA 匯入繫結，Classic SCA 服務可以呼叫任何 Open SCA 域級別服務。不需要進行任何配置來公開該服務。

在我們的示例中，Payment 服務（一個 Classic SCA 服務）需要呼叫 AuditLogging（一個 Open SCA 服務）和 CreditCardCharge（一個 Open SCA 服務）。要檢視如何進行該連線，您將專案匯入 Integration Developer 後，在組合編輯器中單擊名為 CreditCardCharge 的匯入來顯示其配置，如圖 6 所示。

圖 6. Classic SCA CreditCardCharge 匯入配置

請注意 Module name 欄位如何包含 Open SCA 元件的名稱，該元件提供目標服務。Export name 欄位包含 Open SCA 元件服務的名稱。

檢查 AuditLogging 匯入來觀察相似的配置。

匯出 Classic SCA 服務

對於要呼叫 Classic SCA 服務的 Open SCA 元件，Classic SCA 服務應該具有 SCA 匯出。請注意 Payment 服務的模組名稱和匯出名稱，稍後當從 Open 連線到 Classic 時我們將需要該資訊。在此應用程式中，模組名稱為 “Payment”，匯出名稱為 “PaymentService”。

介面

CreditCardCharge 和 AuditLogger 匯入都是通過匯入直接從相應 Open SCA 服務獲取的 WSDL 介面而建立的。不需要任何修改。

商店組合 (Open SCA)

現在我們將檢視 Rational Application Developer 中的商店組合，來檢視如何對其進行配置來連線到 Classic SCA Payment 服務。

將 CandyStore.zip 和 CommonArtifacts.zip 匯入安裝了 SCA 支援的 Rational Application Developer V7.5.5。

如果使用 Rational Application Developer 時需要重新整理程式，請參考本文末尾的 附錄，來了解有關如何建立 Open SCA 組合的分步指南。本部分將重點講述與 Classic SCA 服務整合所需的特定步驟。

準備付款介面

雖然人們更願意將 Java 介面直接從 Classic SCA 元件移植到 Open SCA 元件，如我們上面所述，但是這是不受支援的。相反，將使用 WSDL 檔案（該檔案必須包含服務和移植定義）來生成 Java 介面以及任何 Open SCA 元件將使用的相關型別。Rational Application Developer Open SCA 工具需要同時擁有 WSDL 繫結和 WSDL 服務的 WSDL。

Integration Developer 引入的付款介面具有 WSDL portType，但是沒有 WSDL 繫結和 WSDL 服務。這種情況的一個簡單解決方法是將付款 WSDL 的副本放入 Rational Application Developer SCA 專案，然後使用 Rational Application Developer WSDL 編輯器來新增 WSDL 繫結和服務。

要完成此操作：

1. 在編輯器中開啟 WSDL 檔案。右鍵單擊畫布並選擇 Add Binding。
2. 右鍵單擊新的繫結並選擇 Generate Binding Content。
3. 選擇 Payment 作為 portType，然後選擇協議，此時選擇哪個協議都沒關係。選擇 Overwrite existing binding information 並單擊 Finish。
4. 如果希望更改繫結的名稱，可以通過單擊 Property 選項卡並輸入新的名稱來實現。右鍵單擊 WSDL 編輯器畫布並選擇 Add Service。輸入 PaymentService 作為新服務的名稱並按 Enter。
5. 右鍵單擊新的埠並選擇 Set Binding > Existing Binding。單擊您剛剛建立的繫結，然後單擊 OK。現在 Rational Application Developer Open SCA 工具將可以使用 Payment WSDL。圖 7 顯示了完成上述步驟後 WSDL 編輯器的樣子。
   
   圖 7. 匯入到 Rational Application Developer 的 Payment WSDL
   
   
   

將 Open SCA 連線到 Classic SCA

1. 在商店組合圖表中，向下到達如圖 8 中所示的付款參考。
2. 在 CandyStore 專案下，導航到 SCA Content > Composites > http://soa.sca.samples.candystore/ > Store，並使用 SCA 組合編輯器開啟 Store。然後選擇付款參考。這是對 Classic SCA 付款元件的引用。
   
   圖 8. Rational Application Developer 中的商店組合
   
   
   
3. 通過選擇 Bindings 選項卡、展開 Bindings 並單擊 SCA，向下導航到 SCA 繫結資訊。構造對 Classic SCA 元件的引用非常簡單，因為不需要任何特殊配置。
4. Open SCA 通過根據 Classic 模組名稱和匯出名稱，比如 module_name/export_name，構造的 URI 來定位來自 Classic SCA 的服務。
5. 因為 Classic SCA 模組名稱為 “Payment”，匯出名稱為 “PaymentService”，所以示例的目標 URI 為 “Payment/PaymentService”。該 URI 將新增到 SCA 繫結配置。在 Rational Application Developer 中底部皮膚的 Properties 選項卡中指定該 URI，如圖 9 中所示。
   
   圖 9. Payment 服務的引用目標 URI
   
   
   

部署示例

隨示例提供了一個 指令碼 來將服務部署到伺服器上。

執行示例

部署 Classic SCA 元件和 Open SCA 元件，並測試示例應用程式。

1. 啟動 InteropCandyStore BLA 和 Payment 企業應用程式。
2. 使用 Web 瀏覽器訪問位於以下 URL 的應用程式：

   http://localhost:9080/CandyStoreClient.war/CandyStore.jsp

   
   

請注意需要根據您的配置更新主機名稱和埠。

安全性和事務傳播

雖然上面的方案中沒有介紹，Open SCA 和 Classic SCA 之間的呼叫還可以處理安全性和事務上下文傳播。當在源和目標服務中啟用相應的服務品質時將自動進行此操作。不需要在繫結級別進行任何其他配置。

結束語

WebSphere Process Server V7.0 和 WebSphere Application Server V7.0 Feature Pack for Service Component Architecture (SCA) V1.0.1 允許 Classic SCA 和 Open SCA 繫結之間的互操作性，從而為構造使用 Classic SCA 和 Open SCA 應用程式元件的 SOA 服務提供支援。本系列文章的第 1 部分簡要介紹了 SCA 程式設計模型及其標準化演化。本文還說明了如何組合、部署和測試使用 Classic SCA 和 Open SCA 元件的示例應用程式，其中這些元件通過 SCA 繫結進行互動。本系列文章的第 2 部分和第 3 部分將進一步展開該示例，說明在需要標準互操作性時，如何使用行業標準 Web 服務和 JMS 繫結輕鬆替換 SCA 繫結。

附錄

本部分提供了有關如何為本文正文中使用的示例應用程式建立 Open SCA AuditLogging 組合和 Logger 元件的詳細說明。所有這些步驟都是使用支援 SCA 的 Rational Application Developer V7.5.5 來執行的。

建立 Open SCA 元件

建立組合

1. 第一步是使用 Rational Application Developer 建立 SCA 組合檔案。單擊 File > New > Other。新的視窗開啟時，向下滾動到 Service Component Architecture 並展開該資料夾，如圖 10 所示。
   
   圖 10. 建立新的 SCA 組合
   
   
   
2. 選擇 Composite 並單擊 Next。您將看到如圖 11 所示的視窗。輸入下列資訊：
   • Composite Kind： Conventional Composite
   • Project：Log
   • Composite Name： AuditLogging
   • Target namespace： http://soa.sca.samples.log/
   • Composite path： /Log/AuditLogging.composite
3. 單擊 Finish。
   
   圖 11. 提供新 SCA 組合的詳細資訊
   
   
   
4. 使用 SCA 組合編輯器配置完組合。雙擊 AuditLogging.composite 檔案。您將看到一個空視窗。右鍵單擊空皮膚並選擇 Create component，如圖 12 所示。
   
   圖 12. 建立新 SCA 元件
   
   
   
5. 將出現一個如圖 13 所示的新元件。雙擊詞語 component 並輸入新的元件名稱 Logger。
   
   圖 13. SCA 元件圖示
   
   
   
6. 現在，返回組合編輯器，右鍵單擊元件並選擇 Creat Service。Logger 元件中將出現一個新的服務。單擊如圖 14 中所列的服務圖示。
   
   圖 14. 建立 SCA 服務
   
   
   
7. 在 Properties 皮膚中，單擊 Core 選項卡並輸入 Logging 作為服務名稱，如圖 15 所示。
   
   圖 15. 提供 SCA 服務的詳細資訊
   
   
   
8. 接下來，單擊 Interface 選項卡（位於 Core 選項卡下面），然後選擇 WSDL 作為介面型別。單擊 Interface 欄位的 Browse 按鈕。從介面的可用列表中選擇 Logging，然後單擊 OK。現在 Interface 選項卡如圖 16 所示。儲存更改。
   
   圖 16. 為 SCA 服務指定介面
   
   
   

建立元件實現

現在您可以為 Logging 元件建立 Java 實現：

1. 在 Rational Application Developer 中，右鍵單擊 Logger 元件並選擇 Regenerate Implementation，如圖 17 所示。
   
   圖 17. 建立 SCA 元件實現
   
   
   
2. 此時將顯示一個新的嚮導。選擇 Java 作為 Implementation Type，如圖 18 所示。單擊 Next。
   
   圖 18. 選擇實現型別
   
   
   
3. 圖 19 顯示了嚮導中的第二個皮膚。接受預設值並單擊 Finish。Rational Application Developer 會自動將新生成的類設定為元件實現。
   
   圖 19. 配置 Java 實現
   
   
   
4. 除了生成概要實現外，Rational Application Developer 還生成符合 JAX-WS 的 Java 介面和 JAXB 類，以便處理介面型別。如果您在此步驟中收到錯誤訊息，則可能因為 WSDL 中存在錯誤。一個常見錯誤就是在 WSDL 定義中遺漏了 WSDL 繫結和 WSDL 服務。

   注意：

   • 您還可以通過命令列執行 wsimport 工具。有關詳細資訊，請參閱 WebSphere Feature Pack for SCA 1.0.1 資訊中心。
   • 使用 Dynamic SDO V2.1.1 作為資料繫結也是受支援的，但是生成的介面將需要手動進行一些更新，如 WebSphere Feature Pack for SCA 1.0.1 資訊中心 中所述。
5. 要完成該實現，請向方法架構新增簡單的 System.out.println() 呼叫。開啟 Log\src\soa.sca.samples.logging 下的 LoggingImpl.java 檔案。通過新增 System.out.println 呼叫來更新該檔案，從而與下面的程式碼匹配：

   package soa.sca.samples.log.logging; import log.samples.sca.soa.logging.*; import org.osoa.sca.annotations.Service; @Service (Logging.class) public class LoggingImpl implements Logging{ @Override public void logOrderStart(String customerNo, double amount) { System.out.println("Log record: customer:"+customerNo+" Amount: "+amount); } @Override public void logOrderComplete(String customerNo, String confirmationNumber) { System.out.println("Log record: customer:"+customerNo+" ConfirmationNumber: "+confirmationNumber); } @Override public void logOrderError(String customerNo, String error) { System.out.println("Log record: customer:"+customerNo+" Error: "+error); } }

   
   
6. 儲存對 LoggingImpl 檔案的更新。

建立 SCA 貢獻

接下來，建立 sca-contribution.xml 檔案，以便 Open SCA 定位您的組合檔案：

1. 在 Rational Application Developer 中，轉至 File > New > Other。出現新的視窗時，向下滾動到 SCA，展開該資料夾，然後選擇 SCA Contribution，如圖 20 中所示，單擊 Next。
   
   圖 20. 建立新 SCA 貢獻
   
   
   
2. 在接下來的皮膚中，選擇 Log 作為 Project，然後在 Deployable composites 下選擇 Log，如圖 21 中所示。單擊 Finish。
   
   圖 21. 配置新 SCA 貢獻
   
   
   
3. 新的貢獻將由貢獻編輯器顯示在一個新的視窗中，如圖 22 所示。
   
   圖 22. 向貢獻新增可部署組合
   
   
   
4. 選擇 Add for Exports。如圖 23 所示，將出現一個新視窗。選擇 Export，然後選擇 OK。
   
   圖 23. 向貢獻新增匯出
   
   
   
5. 最後，將出現另一個新視窗，如圖 24 所示。輸入名稱空間 http://soa.sca.samples.log/Logging，然後單擊 OK。儲存所做的更改。
   
   圖 24. 配置要匯出的名稱空間
   
   
   

客戶端

將 CandyStoreClient.zip 匯入到 Rational Application Developer。

在 Web 客戶端中獲取 Open SCA 服務

該專案將用作一個客戶端來訪問和呼叫 SCA 元件。因為這是一個 Web 應用程式，它將不在 SCA 環境中執行，將無法通過引用注入來訪問 SCA 服務。相反，可以使用 CompositeContext API 來獲取 Open SCA 服務。可以通過呼叫靜態方法 CurrentCompositeContext.getContext() 從 SCA 環境外部獲取 CompositeContext。

使用指向 CompositeContext 的指標，可以呼叫下面的方法來獲取指向服務的指標：

 B getService(Class businessInterface, String referenceName)

在新專案中，導航到 WebContent > WEB-INF，然後開啟 CandyStore.jsp。

請注意，JSP 通過呼叫 compositeContext.getService 來獲取指向 CandyStore 服務的指標，如下所示：

private static Store storeService = null;
private CompositeContext compositeContext = null;

public void jspInit() {

    if ( storeService == null) {      
        compositeContext = CurrentCompositeContext.getContext();
        storeService = (Store)compositeContext.getService(Store.class, 
        "StoreComponent");
    }
    
}

getService 引數 Store.class 是指在 CommonArtifacts 專案中定義的商店介面，StoreComponent 引數是指在 CandyStore 專案中定義的 Store.composite 中定義的元件。

包含該客戶端的其他兩個 JPS 使用相同的方法來獲取 Open SCA 服務。

原文連結:http://www.ibm.com/developerworks/cn/websphere/library/techarticles/1005_fong/1005_fong.html

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14789789/viewspace-671149/，如需轉載，請註明出處，否則將追究法律責任。