可擴展地實現非功能邏輯的方法和設備及其系統的制作方法

專利名稱：可擴展地實現非功能邏輯的方法和設備及其系統的制作方法
技術領域：
本發明涉及軟件開發平臺的實現，更具體地，涉及一種與功能邏 輯相分離地且可擴展地實現非功能邏輯的方法和設備及其系統。
背景技術：
當今商業應用不夠靈活的一個重要原因在于功能關注點與非功能 關注點的緊密且不可管理地糾纏在一起，其中功能關注點是指商業功 能和邏輯，而非功能關注點是指諸如性能、安全、監控、可擴展性等 方面。在程序代碼中功能關注點和非功能關注點的交叉極大地提高了
復雜度，從而使得很難理解、構造、擴展和重用，例如
— 理解方面商業邏輯代碼和NFR ( non國function requirement,非功能需求)相關代碼彼此編織，從而使 得難以從單一視角理解該代碼；
— 構造方面需要謹慎地開發代碼以考慮到功能和非功能方 面，從而需要更大的工作量和更多的技能；
一 可擴展方面當功能或非功能需求變化時改變代碼是相當 困難的；
— 重用方面單純地重用功能或非功能代碼很困難， 因此，如下面將更詳細地解釋的那樣，關注點的分離逐漸成為面
向方面編程(Aspect Oriented Programming, AOP ) 、 J2EE (JavaTM 2 Platform Enterprise Edition Specification ， JavaTM 2平臺企業編輯 規范)等現代軟件技術主要目標和途徑。然而，這些技術的利用仍然 面臨極大的約束。 一方面，AOP只能處理簡單的NFR任務，如日志。 另一方面，盡管將容器引入到J2EE使其能夠處理復雜的NFR問題 (如，事務)，添加這種NFR支持通常是一件耗時的工作，其需要對
容器的實現有很好地了解并具有相關的技能。在當今的J2EE容器中 支持定制和專門化NFR支持是相當困難的，使得在J2EE中僅僅支持 一些通用NFR，從而留下其它NFR仍與功能代碼混在一起。
AOP是由Xerox PARX公司于20世紀90年代提出的一種編程范 式。AOP使開發者能夠分離關注點。諸如日志、安全檢查、事務管 理等的很多非功能服務與功能服務分離開來。同時，這些非功能服務 可以由功能服務共享。 一旦非功能行為發生改變，不需要修改這些功 能服務，而僅需要改變非功能服務。
才艮據來自AOSD ( Aspect-Oriented Software Development,面向 對象的軟件開發，對其的相關介紹在因特網上的網址http:〃aosd.net 上可以得到)的調查，有近100種AOP實現。對于基于Java的AOP 實現，有超過20種實現。在此列出其中幾種比較成熟的AOP實現 1. Aspect J
AspectJ (商標)(對其的相關介紹在因特網上的網址 http:〃www.eclipse.org/aspecti上可以得到)是一種通用的對Java的 面向方面擴展。在部署之前，AspectJ在編譯時進行編織。AspectJ是 一種靜態編織，其借助預編譯器對源代碼進行增強。AspectJ是成熟 的AOP實現，但是它很復雜并且需要專用的Java編譯器。
L AspectWerkz
AspectWerkz (商標)(對其的相關介紹在因特網上的網址 http:〃aspectwerkz,codehaus.org上可以得到)是一種動態的AOP框 架。AspectWerkz修改Java字節碼以實現方面編織。編織發生在兩 個不同的階段中，其中一個階段是類加栽階段，另一個階段是激活階 段。
3. SpringFramework
SpringFramework (商標)(對其的相關介紹在因特網上的網址 httu:〃www.sDringframework.org/docs/wiki/Si)ring AOP Framework
jiimL上可以得到)是一種基于動態代理的aop框架，其中動態代理 來自于代理設計模式。動態代理不需要為每個活動的業務對象生成代
理。僅需要為將是活動的接口和代理實現代理生成，并且運行時將生
成代理對象。SpringFramework缺省使用由JDK提供的代理機制。 4. JBossAOP
JBoss AOP (商標)(對其的相關介紹在因特網上的網址 http:〃www.iboss.org/products/aoD上可以得到H吏用Javassist來改變 字節碼以在類加載期間實現動態編織。
對于已知的AOP實現，非功能部分(方面)仍然由代碼編寫而 成。在運行時或編譯時將各個方面與功能代碼編織在一起以形成混合 代碼。因而，每個方面都將與功能代碼一起加栽到內存中。如果有幾 個功能代碼使用同 一方面并且這些功能代碼都在內存中，則內存將有 該方面的幾個副本。此外，還沒有使用插件框架來為方面提供擴展機 制的AOP實現。
在例如J2EE ( JavaTM 2平臺企業編輯規范，v1.4 )容器(對其的 相關介紹在因特網上的網址h加:〃iava sun.com上可以得到)的一些 應用容器中， 一些經常被應用程序使用的非功能部分被分離出來由容 器提供。目前，J2EE容器支持的非功能包括認證、事務、日志等。 然而，目前的J2EE不提供擴展機制和框架以使第三方擴展這些非功 能服務實現和將其編織到應用中。
Mayer等人在其2002年發表的標題為 "Lightweight plug-in-based application development"的書中，提出了插件概念作為 設計模式(所述設計模式具有Gamma等人1995年發表的、標題為 "Design Patterns: Elements of Reusable Object-Oriented Software" 的書中提出的形式)，并且給出了在Java中的示例實現。其體系結構 包括加栽類和識別那些使用反射將已知的接口實現為主接口的類的插 件管理器，其相關內容在Green等人于1997-2001年在Sun Microsystems, Inc.中發表的、標題為"The Reflection API"的技術報 告中做了詳細介紹，所述文章在因特網上的網址 httD:〃iava.sun.com/docs/books/tutorial/reflect/上可k乂得至l] 。 Mayer等 人提出的示例實現允許使用多個插件，還可能用不同的接口，來擴展
一個應用，但是沒有提及將插件添加到其它插件中。
PluggableComponent是提供一種用于在運行時交換組件的基礎 架構或體系結構的模式，其相關內容在V"olter于1999年在In EuroPLoP ，99上發表的、標題為"Pluggable Component - A Pattern for Interactive System Configuration"的文章中做了詳細介紹。該體 系結構特征在于管理不同類型的PluggableComponent的注冊表。該 注冊表由配置工具用來提供管理員可以用來配置其應用的可用組件的列表。
Eclipse平臺是為構造集成開發環境而設計的，其相關內容在 Object Technology International, Inc.于2001年7月發表的、標題為 "Eclipse Platform Technical Overview"的技術報告中做了詳細介紹， 所述文章在因特網上的網址 h加:〃 www.ecliDse.org/whiteDapers/ecliDse-overview.pdf 上可以得到。 Eclipse平臺建立在用于發現、集成和運行被稱為插件的模塊的機制 上。任何插件自由定義新的擴展點(對其的描述也可以在上述網址得 到)以及提供新的API以供其它插件使用。插件可以擴展其它插件的 功能以及擴展內核。這提供了創建更復雜配置的靈活性。
然而，所有這些插件框架都作用在應用層上.來自用戶的請求給 出了應當包括哪些插件以滿足該請求的指示符。然而在應用容器中， 僅僅;f艮據用戶請求，不能直接得到有關應當調用哪些非功能插件的信 息。
在2007年5月31日公布的、公布號為US2007/0124797A1的、 Gupta等人的美國專利申請中提出了一種在網絡業務環境中創建、管 理、執行策略的方法以及使用該方法的系統，其意圖也是要將功能邏 輯與非功能邏輯分離開來。所述系統包括策略管理器、策略執行器、 客戶端和服務。客戶端包括請求服務的軟件。服務是網絡服務，例如， 諸如登錄過程的應用或可操作(或功能)過程和消息的接口和加密。 策略管理器用于指定功能，諸如日志、認證、加密、高速緩存等，這 些不是核心商業邏輯，但是確實提供了非功能貢獻。策略管理器用于
分離商業關注點和非商業關注點。策略執行器用于監視和執行經由策
略管理器配置的策略。在該系統中，在OSI (開放系統互連)7層模 型中的應用層中實現策略管理器，并且在低層執行所創建的策略。在 該系統中，沒有對網絡低層做任何改變。在該系統中，可以將策略實 現為消息的攔截器從而將策略無縫地引入消息流路徑中。或者，將策 略部署到網關和服務代理中。由網關和代理攔截消息以實現相應的策 略。由上述內容可知，該專利申請中公開的系統通過策略管理器來配 置和滿足非功能需求，然而它并沒有提供一個可擴展的方式來允許開 發者擴展和定制非功能需求的支持。此外，該專利申請中公開的方法 將策略管理器置于客戶端和后端服務之間，實際上只能對服務接口訪 問進行控制，對多個服務之間的訪問進行控制則需要相應添加多個策 略管理器，從而增加了網絡實現的復雜度并提高了實現成本和時間。
因此，現有技術中存在對方便快捷且可擴展地分離功能邏輯和非 功能邏輯的機制的需求。

發明內容
為了克服現有技術中存在的上述問題，本發明提出了一種與功能 邏輯相分離地且可擴展地實現非功能邏輯的方法和設備及其系統和計 算機程序產品。
為了實現上述目的，本發明提供了一種與功能邏輯相分離地且可 擴展地實現非功能邏輯的方法，包括步驟基于加載的策略需求配置 獲得策略與所需的插件之間的關聯關系；根據所獲得的關聯關系，產 生插件上下文定義，所述插件上下文定義是與該插件有關的插件上下 文的一部分，其中所述插件上下文定義了插件所提供的服務以及對與 其有聯系的其它插件的引用；以及基于插件上下文定義而產生插件上 下文對象，其中，所述插件上下文對象是實例化的插件上下文定義。
為了實現上述目的，本發明還提供了一種與功能邏輯相分離地衛 可擴展地實現非功能邏輯的設備，包括應用裝載器，用于將應用的 策略需求配置加載到內存；策略附加器，基于加載的策略需求配置森
得策略與所需的插件之間的關聯關系，以及根據所獲得的關聯關系， 產生插件上下文定義，所述插件上下文定義是與該插件有關的插件上 下文的一部分，其中所述插件上下文定義了插件所提供的服務以及對
與其有聯系的其它插件的引用；和應用構造器，基于插件上下文定義 而產生插件上下文對象，其中，所述插件上下文對象是實例化的插件 上下文定義。
為了實現上述目的，本發明還提供了一種分離功能邏輯與非功能
邏輯的系統，包括應用層實體，用于供用戶實現功能邏輯并利用基 礎架構服務插件層實體提供的插件；基礎架構服務插件層實體，用于 利用應用運行時層實體的服務，實現所述插件；以及應用運行時層實 體，用于實現上述方法以供所述基礎架構服務插件層實體調用。
為了實現上述目的，本發明還提供了一種計算機程序產品，該計 算機程序產品包括存儲在計算機可讀存儲介質中的程序代碼，該程序 代碼的執行實現了根據本發明的方法。
根據本發明的優選實施例，為基礎架構服務提供方提供了抽象層， 將應用的非功能邏輯與應用的功能邏輯分離開來，并且使得能夠靈活 地改變應用的非功能配置而不用重新編譯、再部署該應用。
根據本發明的優選實施例，對運行時構造子進行一些修改以添加 一些運行時擴展點，諸如創建組件實例之前或之后的擴展點 Before(After)CreateComponentlnstance、調用組件實例之前或之后的 擴展點Before(After)InvokeServiceMethod等。實際上，大多數基礎 架構服務，例如，日志、安全、事務等，在這些運行時擴展點的時間 段上活動。換言之，通過擴展這些擴展點，可以實現大多數基礎架構 服務。
根據本發明的優選實施例，引入了策略(非功能需求)注冊表和/ 或插件注冊表。策略注冊表存儲插件所支持的策略，而策略注冊表存 儲所有插件和維護插件之間的關系，例如，擴展關系和/或依賴關系。
根據本發明的優選實施例，改變應用裝栽過程以將應用的策略配 置映射到插件的依賴關系上。此外，所獲得的插件的依賴關系被存儲
在插件上下文實體中，其中所述插件上下文實體附接于應用的相應的 運行時對象上。這樣，可以直接定位所依賴的插件，而不需要在應用 的執行期間查詢策略注冊表和插件注冊表。
根據本發明的優選實施例，能夠方便快捷且可擴展地實現應用的 功能邏輯和非功能邏輯的分離。
此外，根據本發明的優選實施例，在應用執行期間相關的插件將 被直接調用無需查詢注冊表進行定位從而提高了運行性能。
與AOP技術相比，本發明可以保持對應用的全局綜覽，從而， 可以實現事務的復雜策略等。而且，可以以可擴展的方式開發服務于 策略的基礎架構服務。
與在當前應用容器(例如，Java)中的策略支持相比，本發明可 以以可擴展的方式開發基礎架構服務，同時可以僅由J2EE容器提供 商進行對當前應用容器中基礎架構服務的改變或擴展。
與傳統的擴展機制相比，本發明使得能夠根據應用配置對基礎架 構服務插件進行隱式調用。


從下面結合附圖的詳細描述中，本發明將會更易于理解，其中， 相同的附圖標記表示相同的結構元素，并且，附圖中
圖1示出了根據本發明的支持功能邏輯與非功能邏輯相分離的系 統體系結構圖2示出了基于圖l所示的系統體系結構實現期望的應用的流程
圖3是示出根據本發明的系統體系結構進行的應用引導過程的信 息流圖4是示出根據本發明的系統體系結構進行的應用引導過程的流 程圖5是示出運行時擴展點和運行時應用對象之間的關系的圖； 圖6是示例性地示出在插件上下文中插件之間的擴展關系的圖；圖7是示例性地示出在插件上下文中插件之間的依賴關系的和
圖8示意性地示出了其中可以實現本發明的實施方式的計算機系統。
具體實施例方式
下面，參考圖l描述根據本發明的支持功能邏輯與非功能邏輯的 分離并實現非功能邏輯的系統的系統體系結構。
如圖l所示，系統體系結構從下至上分為3層，即，應用運行時 層、基礎架構服務插件層和應用層。
應用運行時層包括兩個子層，即，應用運行時核心子層117和基 礎架構服務插件框架子層115。
在應用運行時核心子層117中，包括如下部分應用裝載器127、 應用構造器129、和應用構造子單元131。應用構造器129為應用的組 件生成運行時對象以及組件之間的鏈接。在應用的引導期間(即，準 備好運行期間)使用應用構造器129。應用構造子單元131用于創建 組件實例或建立組件實例之間的通信。在應用的運行期間使用應用構 造子單元131。上述各部分除了具有本領域技術人員所公知的功能之 外，為了實現本發明還對其進行了一些修改，其中，應用構造子單元 131 被修改以添加運行時擴展點，諸如 ， BeforeComponentlnstanceCreation 和 AfterComponentlnstanceCreation等，其中所述運行時擴展點是指供 應用運行時核心子層117調用的擴展點。從對于Eclipse的介紹中可 知，擴展點是指在應用中提供的某一個點，通過該點第三方可以在應 用中添加其自己的功能模塊來擴展原有的應用。應用裝載器127被修
改以調用下面將描述的策略附加器125,策略附加器125通過基于來 自應用裝載器127的策略需求配置查詢下面將描述的插件注冊表，將 應用的策略配置映射到支持的插件。應用構造器129被修改以不僅產 生應用運行時對象，而且根據來自策略附加器的輸入而產生相關的插
件上下文。所謂的插件上下文包括插件所提供的服務以及對與其有聯 系的其它插件的引用。
在基礎架構服務插件框架子層115中，包括如下部分插件注冊 表121和策略附加器125。可選地，還包括策略注冊表119和策略匹 配器123。策略注冊表119存儲了插件所支持的策略以及策略之間的 關系，例如，策略的包含關系，如個人身份認證包括口令認證、指紋 認證、虹膜認證等。實際上，策略注冊表119定義了系統所支持的策 略能力。而插件注冊表121存儲了有關插件的信息以及插件之間的關 系。該關系，例如，包括插件之間的擴展關系和/或依賴關系。根據本 發明，策略附加器125可以直接查詢插件注冊表121而將應用的策略 配置映射到支持的插件，并返回策略需求配置與支持的插件之間的關 聯關系。在這種情況下，對策略需求配置的定義必須具體到每個插件， 也就是說，對插件注冊表的入口定義更加具體，這相對復雜且比較耗 時。根據本發明的一個優選實施例，策略附加器125可以先將策略需 求配置的定義傳送給策略匹配器123，策略匹配器123從中分析出所 需的策略并據此查詢策略注冊表119以確定本系統架構是否支持所要 求的策略配置。如果支持的話，才相應地查詢插件注冊表121而獲得 策略和插件之間的關聯關系(即，句柄)，并將其發送給策略附加器
125。在這種情況下，能夠提高系統的運行效率并縮短引導所需的時間。 策略附加器125根據所獲得的關聯關系，產生應用的插件上下文
定義，其中包括與所述插件實例的關聯(即，句柄)，并將其發送到
應用構造器129。
基礎架構服務插件層包括由基礎架構服務開發者基于應用運行時
層提供的非功能邏輯而開發的向應用層提供的各種服務插件，例如，
事務107、安全109、日志lll，以及其它服務插件113。所述其它服
務插件113可以是在應用運行時層上可以實現的任何插件。通過擴展
運行時擴展點而實現這些服務插件。
應用層包括用戶(諸如，軟件開發者)期望實現的各種應用，這
些應用例如是航程及信用卡點數交換系統101、在線游戲103、以及其
它應用105。所述其它應用105可以是需要調用基礎架構服務插件層 提供的服務插件的任何應用。當用戶在基于本系統架構的平臺上實現 該應用時，功能邏輯在應用層內實現，并且根據策略需求配置通過在 應用構造子單元131中定義的運行時擴展點來調用基礎架構服務插件，從而實現非功能邏輯。通過功能邏輯與非功能邏輯的結合，最終 實現用戶期望的應用。
此外，在插件中可以進一步定義指向其它插件的擴展點，以實現進一步的功能。如前面所述的，插件之間的關系包括擴展關系和/或依 賴關系，且所述關系也存儲在插件注冊表121中。當然，根據需要，還可以定義插件之間的其他關系。在此，插件之間的擴展關系是指在一個插件中提供其它擴展點，并且在符合一定條件的情況下，才可以擴展該擴展點。依賴關系是指在運行時對一個插件的實例化依賴于另 一插件的實現結果。在下面將舉例說明插件之間的這兩種關系。
圖2示出了用戶基于根據本發明的系統架構實現所期望的應用的 過程。
在步驟202中，用戶在基于本發明的系統體系結構的平臺上定義功能邏輯以及策略需求配置，并將其加載到內存中。用戶可以在任意 編程平臺上使用任意編程語言來定義功能模塊，例如，用于可以在 WindowsTM開發平臺上使用Java語言來編寫功能模塊，其中，在需 要調用非功能模塊之處進行聲明，即，給出需求描述即可。
在步驟204中，在內存中執行應用引導過程。關于步驟204的具體執行過程，后面將進行詳細說明。
在步驟206中，在運行時應用構造子單元131擴展在步驟204中產生的擴展點，即，調用插件的注入點，并在運行時創建對應插件的 實例以執行相應功能。
圖3示出根據本發明的系統體系結構中的應用引導過程中的信息流的流向。其中在信息流l中，包括根據功能需求和非功能需求分別定義的應用 的組件功能和策略需求配置；
在信息流2中，包括根據功能需求定義的應用的組件功能；
在信息流3、 4、 5中，包括^f艮據非功能需求定義的策略需求配置 信息，其在應用裝載器127、策略附加器125、和策略匹配器123處可 能有相同或不同的形式，這根據需要而定；
在信息流6中，包括為所獲得的策略和支持的插件之間的關聯關
系，諸如，包括實現非功能需要所需插件的描述和句柄；
在信息流7中，包括插件上下文定義，它是與該插件有關的插件 上下文的一部分，其中所述插件上下文定義了插件所提供的服務以及 對與其有聯系的其它插件的引用；
在信息流8中，包括應用運行時對象、插件上下文對象及其關聯。 下面參照圖4，描述根據本發明的系統體系結構中的應用引導過程。
在步驟402中，應用裝載器127將應用的組件功能定義和策略需 求配置加載到內存中，即，將應用包部署到應用運行時。所謂的應用 運行時是指已經將應用包裝載到內存中，此時，該應用包已經處于"就 緒"狀態，隨時可以被調用。
在步驟404中，應用裝栽器127根據組件功能定義產生組件定義 (即，功能邏輯模塊)，并將策略需求配置傳遞給策略附加器125， 然后傳遞給策略匹配器123，在此過程中，所述策略需求配置可以根 據需要有不同的形式。
應用的組件功能定義的加栽和產生組件定義可以采用已有技術， 例如使用SCA (服務組件體系結構)的運行環境Tuscany作為基層的 應用運行就可以實現，因此省略對其的詳細描述。而且，對于實現本 發明目的而言，上述過程不是必需的。
在步驟406中，策略匹配器123基于策略需求配置查詢插件注冊 表121以獲得用于策略需求配置的支持的插件，并將策略和所需的插 件之間的關聯關系(包括該插件的描述和句柄)返回給策略附加器 125。可選地，在步驟406，策略匹配器123先查詢策略注冊表119, 以獲知本系統是否支持所需求的插件。如果支持的話，查詢插件注冊
表121，并返回策略和所需的插件之間的關聯關系，否則，返回異常 指示。
在步驟408中，策略附加器125根據所接收的該插件的描述和句 柄，為該插件產生插件上下文定義，所述插件上下文定義是與該插件 有關的插件上下文的一部分，其中所述插件上下文定義了插件所提供 的服務，其與該插件的句柄相關聯，以及對與其有聯系的其它插件的 引用；其中，可以將所述插件上下文形成為鏈表的形式或樹狀結構， 或者本領域技術人員所知的其它任何結構。
在步驟410中，應用構造器129基于組件定義而產生應用運行時 對象，并基于插件上下文定義而產生插件上下文對象，并將該插件上 下文對象與相應的應用運行時對象相關聯，其中，所述插件上下文對 象是實例化的插件上下文定義。
參照圖5，其中示出了運行時擴展點和運行時應用對象之間的關 系。如圖5所示，應用運行時對象與多個運行時擴展點相關聯，所述 運行時擴展點包括兩大類， 一類是與服務調用有關的擴展點，諸如調 用組件實例之前的擴展點BeforelnvokeServiceMethod和調用組件實 例之后的擴展點AfterlnvokeServiceMethod;另一類是與組件創建有 關的擴展點，諸如創建組件實例之前的擴展點 BeforeCreateComponentlnstance和創建組件實例之后的擴展點 AfterCreateComponentlnstance。當與用戶交互的過程中由構造子創 建運行時擴展點的實例時，系統插件上下文中所包含的與插件實例的 關聯關系而直接找到并調用對應插件。
下面，以在線支付系統為例，說明本發明的參考實現。在本參考 實現中，可使用SCA (服務組件體系結構)運行時環境Tuscany作為 基層的應用運行時環境。在此，使用簡化的偽代碼以便更好地圖解其 后的機制。在如圖1所示的基礎架構服務插件層中實現作為示例的基 礎架構服務插件"日志"。而且，作為示例的應用，在線支付系統， 用來展示如何使用"日志"插件。該應用使用Paypal來提供在線支付 服務，并且用戶使用"日志"來記錄Paypal服務的使用。
1.應用運行時核心子層117的修改
應用運行時核心子層117的#"改包括<務改應用構造子單元131、 應用裝載器127、和應用構造器129。下面給修改的偽代碼加了下劃線。
首先，為了使應用運行時知道Paypal組件對日志的需求并從而調 用"日志"，需要如下修改運行時應用裝載器127 ，ComponentLoader， 以創建插件上下文定義
〃用于加栽scdl文件的組件標簽信息的Tuscany裝栽器
public class ComponentLoader extends LoaderExtension<ComponentDefinition< { PluginContextDefinition pcd = null; 〃插件定義信息類型 public ComponentDefinition< > load(CompositeComponent parent,
XMLStreamReader reader, DeploymentContext deploymentContext)
throws XMLStreamException， LoaderException {
〃解析插件定義信息
String intents = reader.getAttributeValue("null,"requires"); pcd = processListoflntentfintents);
方法"ComponentLoader"將解析應用配置并識別一些關鍵詞， 如"需求"。關鍵詞"需求"用來指定期望的基礎架構服務(intent)。 方法"processListoflntent"將調用策略附加器125來產生對應的插件 上下文定義。
其次，需要如下#"改應用構造器129， JavaComponentBuilder， 來將插件上下文與對應的組件相關聯
〃用于根據組件定義建立組件的Tuscany核心API
public class JavaComponentBuilder extends
ComponentBuilderExtension<JavaImplementation> { public AtomicComponent build(CompositeCoinponent parent, ComponentDefinition<JavaImplementation> definition, DeploymentContext deployment) throws BuilderConfigException {
JavaAtomicComponent component = new JavaAtomicComponent(definition
.getName()， configuration); 〃創建插件上下文
comuonent.createPluginContext(definition.getPluginContextDefinition());
最后，為了使運行時可擴展，需要指明在運行時應用構造子單元 131中的運行時擴展點。為了實現在調用服務之前觸發的擴展點 "BeforelnvokeServiceMethod"，需要在獲得組件實例并調用其服務 之前對擴展點"BeforelnvokeServiceMethod"進行聲明，然后，在實 現應用構造子單元131時，在從應用構造器129獲得的插件上下文中 找出所有插件擴展的"System.BeforeInvokeServiceMethod"擴展點， 并且對于每個插件，向其釋放鏈接添加其子插件上下文并運行該插件。 下面示出了對服務調用類PojoTargetlnvoker的修改
〃用于調用組件服務的T^iscany核心API
public abstract class ProjoTargetlnvoker implements Targetlnvoker { public Object invokeTarget(final Object payload) throws InvocationTargetException { try{
〃觸發擴展點管理功能
processBeforelnvokeServiceMethodf payload, instance); Object retj
〃獲得組件實例并調用其服務
if (payload != null && !payload，getClass().isArrayO) {
ret = operation.invoke(instance， payload); } else {
ret = operation.invoke(instance， (Object[]) payload);
return ret; } catch (IllegalAccessException e) {
〃激活擴展其擴展點的所有插件
public void processBeforelnvokeServiceMethod (object uavload,
AtomicComponentExtension instance) { 〃從組件實例獲得插件上下文 PluginContext nc= instance.getPluginContextf);
〃從插件上下文中找出所有擴展了 "Svstem.BeforeInvokeServiceMethod"擴展點的 插件
List<Extension> elist = Dc.getExtension("Svstem.BeforeInvokeServiceMethod");
//執行所有插件
For(Extension e: elist)
i
e.runO;
通過4吏用方法"processBeforelnvokeServiceMethod"，可以獲得 當前組件實例的插件上下文。根據該上下文，可以獲得對插件"日志" 的引用"e"，其擴展了擴展點"BeforelnvokeServiceMethod",接 著調用"日志"。注意，對"日志"的調用發生在服務調用 operation.invoke()之前。
2.基礎架構服務插件框架子層115的實現
基礎架構服務插件框架子層115包括插件注冊表121、策略匹配 器123和策略附加器125。可選地，還包括策略注冊表119。
首先，插件注冊表121維護插件的信息(例如，所提供的策略) 和插件之間的關系(例如，擴展關系和/或依賴關系)。以下示出了按 照策略來索引插件以及按照擴展點來索引插件的插件注冊表121的實 現:
〃定義索引插件的注冊表
public class PluginRegistry {
public List<Plugin> getPluginsByPolicy(Policy policy);
public List<Plugin> getPluginsByExtensionPoint(ExtensionPoint ep);
插件類維護所提供的插件的擴展和擴展點。以下示出了在插件中 對擴展點的擴展以及提供與該插件有擴展關系和依賴關系的插件的擴
展點的實現
〃插件定義
public class Plugin(
public List<Extension> getExtensions();
public List<ExtensionPoint> getExtensionPoints();
public List<Plugin> getDependentPlugins();
其次，策略注冊表119維護基礎架構服務的需求和策略之間的映 射，其中策略描述了 一些可以應用于服務組件或服務組件之間的交互 的能力或約束。以下示出了根據需求獲得策略的實現
〃定義索引策略的注冊表
public class PolicyRegistry {
public Policy getPolicy(String intent);
再次，策略匹配器123負責找到用于需求的支持的插件。以下示 出了首先根據需求獲得策略其后+艮據策略獲得插件的實現
〃提供策略和插件之間的匹配器
public class PolicyMatcher {
public List<Plugin> getPlugins (String intent) {
Policy policy = PolicyRegistry. getPolicy(intent); return PluginRegistry. getPluginsByPolicy(policy);
最后，策略附加器125為需求產生支持的插件的上下文定義。方 法"generatePluginContextDefinition"為插件構造插件上下文定義， 而方法"buildPluginContextChain"根據插件的關系將插件上下文定 義組織為鏈表并返回該鏈表的首部。上述方法根據每個策略找出所有 插件，然后從插件注冊表121中找出相應的插件定義，并且建立插件 定義上下文。
〃提供根據策略獲得插件定義上下文的機制 public class PolicyAttacher{
public List<PluginContextDefinition> getPluginContextDefinition(String intents) { List<String> intentList=getIntents(requires，policySets); List<PluginContextDefinition> result = new List<PluginContextDefinition>; for(String intent: intentList)( 〃根據每個策略找出所有插件
List<Plugin> plugins- PolicyMatcher. getPlugins(intent);
〃找出相應的插件定義
List< PluginContextDefinition> pluginContextDefinitions =
generatePluginContextDefinition(pIugins)
〃建立插件定義上下文
PluginContextDefinition pluginContextDefinitionHeader =
buHdPluginContextChain(pluginContextDeflnitions，plugi
<formula>formula see original document page 22</formula>
方法"PluginContextDefintion"提供了一種為所需的插件層次結 構建立上下文樹的方式。
〃定義插件上下文定義
<formula>formula see original document page 22</formula>
3.日志插件實現
插件的配置指定了其擴展的擴展點以及其提供的擴展。在此，示 出了與"日志"插件有擴展關系的擴展點"過濾器"。下面，說明了 "日志"插件的配置。
<formula>formula see original document page 22</formula>擴展
<extension-point id-，，com.ibm.crl.plugin.log.FHter"
interface.class-，，com.ibm.crl.plugin.log.IFilter，， />〃擴展點 </component> </composite>
"日志"插件通過擴展擴展點"BeforelnvokeServiceMethod"， 日志服務調用相關的信息。下面示出了 "日志"插件的具體實現
public class LogProcessor implements BeforelnvokeServiceMethod {
private Logger log = Logger.getLogger(this.getClass()); 〃記錄器啟動
public void run() {
log.info(" componentname: "+ componentname + " operation: " + operation + " args: " + args + " Timestamp: " + System.currentTimeMillis()); 〃i已錄器i己錄
4.相關的代碼和在線支付系統的配置
下面示出了具有日志代碼的Paypal組件的偽代碼。
public class EPaypelServicelmpl implements EPaypelService {
private Logger log = Logger.getLogger(this.getClass());〃日志代碼
public List requestPayment(String companyName)
log.info("Classname: " + this.getClass() + " operation: requestPayment" + " args: "+ companyName+" timestamp: "+System.currentTimeMillis());〃日志代碼
doSomethingO;
使用"日志"插件，可以簡單地將日志需求添加到在線支付應用 的配置中，從而，從應用代碼中移除日志代碼。以下示出了在線支付 系統的配置，并且日志需求用下劃線指示。
<composite xmlns="http:〃www.osoa.org/xmlns/sca/1.0" name-"Online Payment">
〈component name="EPaypelService" reciuires='，log''> implementation, Java
class="conUbm.crLpaypel.EPaypelServiceImpl" /> -reference name=，,paymentManagementOagis">
PaymentManagementComponent </rcference> </componcnt>
</composite>
下面還以上述"日志"插件為例，說明插件之間的擴展關系。 假設"日志"插件提供日志組件實例創建和服務方法調用的能力。 而且，"日志"插件提供擴展點"過濾器"以添加過濾條件。
同時，"ABC過濾器"插件擴展"日志"插件的"過濾器"擴展 點，以便僅日志符合"ABC"條件的信息。
圖6示出了如何^^用插件上下文來定位插件的插件，而不用在應 用的執行期間額外查詢策略注冊表119和插件注冊表121。
插件上下文存儲插件的擴展點，在本示例中，為"過濾器"擴展 點。而且，該擴展點"過濾器"指向另一插件上下文，其存儲了所需 擴展點的擴展"ABC過濾器"，即，擴展了該擴展點"過濾器"并 在此需要插件"ABC過濾器"。
下面還以上述"日志"插件為例，說明插件之間的依賴關系。 假設存在"監視器"插件，其為每個身份提供監視組件實例創建 和方法調用的能力。此外，插件提供服務以獲得所選身份的當前組件 實例數目。
同時，"資源管理"插件提供限制每個身份的最大組件實例數目 的能力。該插件支持"監視器"插件以獲得在為每個身份創建組件實 例之前獲得當前組件實例數目。
圖7示出了如何將插件上下文用于插件的依賴插件，而不需要在 應用的執行期間額外查詢策略注冊表119和插件注冊表121。
插件上下文存儲了插件所提供且所需要的服務。而且，還存儲了 對依賴插件(即，提供所需服務的插件)的引用。在本示例中，插件 所提供的服務為限制最大組件實例數目，而其所需要的服務為"監視 器"擴展點來提供當前的實例數目。該擴展點"監視器"指向另一插 件上下文，其存儲了所需擴展點的擴展"監視器"，即，擴展了該擴 展點"監視器"并在此需要插件"監視器"。
圖8示意性地表示了其中可以實現本發明的實施方式的計算機系 統。圖8中所示的計算機系統包括CPU(中央處理單元)801、 RAM(隨 機存取存儲器)802、 ROM(只讀存儲器)803、系統總線804， HD(硬盤) 控制器805、鍵盤控制器806、串行接口控制器807、并行接口控制器 808、顯示器控制器809、硬盤810、鍵盤8U、串行外部設備812、并 行外部設備813和顯示器814。在這些部件中，與系統總線804相連 的有CPU 801、 RAM 802、 ROM 803、 HD控制器805、鍵盤控制器 806，串行接口控制器807，并行接口控制器808和顯示器控制器809。 硬盤810與HD控制器805相連，鍵盤811與鍵盤控制器806相連， 串行外部設備812與串行接口控制器807相連，并行外部設備813與 并行接口控制器808相連，以及顯示器814與顯示器控制器809相連。
圖8中每個部件的功能在本技術領域內都是眾所周知的，并且圖 8所示的結構也是常規的。這種結構不僅用于個人計算機，而且用于 任何支持用戶開發其所需要的應用的開發平臺。在不同的應用中，圖 8中所示的某些部件可以被省略。圖8中所示的整個系統由通常作為
軟件存儲在硬盤810中、或者存儲在EPROM或者其它非易失性存儲 器中的計算機可讀指令控制。軟件也可從網絡(圖中未示出)下載。 或者存儲在硬盤810中，或者從網絡下載的軟件可被加載到RAM 802 中，并由CPU801執行，以便完成由軟件確定的功能。
盡管圖8中描述的計算機系統能夠支持根據本發明的方法，但是 該計算機系統只是計算機系統的一個例子。本領域的熟練技術人員可 以理解，許多其它計算機系統設計也能實現本發明。
本發明還可以實現為一種例如由圖8所示計算機系統所使用的計 算機程序產品，其包含有用于本發明的方法的代碼。在使用之前，可 以把代碼存儲在其它計算機系統的存儲器中，例如，存儲在硬盤或諸 如光盤或軟盤的可移動的存儲器中，或者經由因特網或其它計算機網 絡進行下栽。
從以上描述中，本發明的很多特征和優點將清楚，并且，由此， 意圖由所附權利要求涵蓋本發明的所有這樣的特征、以及優點。此外， 由于對于本領域的技術人員來說、將容易出現大量修改和改變，所以，
不應將本發明限于如所示出并描述的確切的構造和操作。由此，可將 所有適用的修改和等價物視為落在本發明范圍內。
權利要求
1. 一種與功能邏輯相分離地且可擴展地實現非功能邏輯的方法，包括步驟基于加載的策略需求配置獲得策略與所需的插件之間的關聯關系；根據所獲得的關聯關系，產生插件上下文定義，所述插件上下文定義是與該插件有關的插件上下文的一部分，其中所述插件上下文定義了插件所提供的服務以及對與其有聯系的其它插件的引用；以及基于插件上下文定義而產生插件上下文對象，其中，所述插件上下文對象是實例化的插件上下文定義。
2. 如權利要求l所述的方法，其中，所述基于加栽的策略需求配 置獲得策略與所需的插件之間的關聯關系的步驟還包括基于策略需求配置查詢包含插件的描述和插件之間的關系的信息 的插件注冊表而獲得策略和所需的插件之間的關聯關系。
3. 如權利要求l所述的方法，其中，所述基于加栽的策略需求配 置獲得策略與所需的插件之間的關聯關系的步驟還包括基于策略需求配置查詢包含插件所支持的策略以及策略之間的關 系的信息的策略注冊表；以及基于所述策略注冊表的查詢結果，進一步通過查詢插件注冊表將 所述策略需求配置映射到相應的插件以獲得策略和所需的插件之間的 關聯關系，其中所述插件注冊表包含插件的描述和插件之間的關系的 信息。
4. 如權利要求l-3中任一項所述的方法，其中，還包括 定義應用的策略需求配置。
5. 如權利要求4所述的方法，其中，還包括 定義應用的組件功能；以及 根據加載的組件功能定義產生組件定義；
6. 如權利要求5所述的方法，其中，還包括 基于組件功能定義而產生應用運行時對象；以及 將該插件上下文對象與相應的應用運行時對象相關聯。
7. 如權利要求1或6所述的方法，其中，所述方法還包括步驟 在運行時根據該插件上下文對象而直接找到并調用該插件以實現該插件的功能。
8. 如權利要求1或6所述的方法，其中，所述插件上下文被形成 為鏈表的形式或樹狀結構。
9. 如權利要求2或6所述的方法，其中，所述插件注冊表還包括 對插件之間的擴展關系和/或依賴關系的定義，其中所述擴展關系是指 在一個插件中還包括對指向另 一插件的擴展點的定義，而所述依賴關 系是指 一 個插件的實例化依賴于另 一插件的實現。
10. —種與功能邏輯相分離地且可擴展地實現非功能邏輯的設備, 包括應用裝栽器，用于加栽應用的策略需求配置；策略附加器，基于加載的策略需求配置獲得策略與所需的插件之 間的關聯關系，以及根據所獲得的關聯關系，產生插件上下文定義， 所述插件上下文定義是與該插件有關的插件上下文的一部分，其中所 述插件上下文定義了插件所提供的服務以及對與其有聯系的其它插件 的引用；和應用構造器，基于插件上下文定義而產生插件上下文對象，其中， 所述插件上下文對象是實例化的插件上下文定義。
11. 如權利要求10所述的設備，其中，所述設備還包括 插件注冊表單元，用于存儲包含插件的描述和插件之間的關系的信息的插件注冊表；其中，所述策略附加器基于策略需求配置查詢所迷插件注冊表而 獲得策略和所需的插件之間的關聯關系。
12. 如權利要求10所述的設備，其中，所述設備還包括 策略注冊表單元，用于存儲包含插件所支持的策略以及策略之間的關系的信息的策略注冊表；其中，所述策略附加器基于策略需求配置查詢策略注冊表，并基 于所述策略注冊表的查詢結果，進一步通過查詢插件注冊表將所述策系，其中所述插件注冊表包含插件的描述和插件之間的關系的信息。
13. 如權利要求10至12中的任一個所述的設備，其中， 所述應用裝載器還加載應用的組件功能。
14. 如權利要求13所述的設備，其中，所述策略附加器還基于組件功能定義而產生應用運行時對象。
15. 如權利要求14所述的設備，其中，所述應用構造器將該插件上下文對象與相應的應用運行時對象相 關聯。
16. 如權利要求10或14所述的設備，其中，所述設備還包括 應用構造子單元，用于在運行時根據該插件上下文對象而直接找到并調用該插件以實現該插件的功能。
17. 如權利要求10或14所述的設備，其中，所述插件上下文被 形成為鏈表的形式或樹狀結構。
18. 如權利要求11所述的設備，其中，所述插件注冊表還包括對 插件之間的擴展關系和/或依賴關系的定義，其中所述擴展關系是指在 一個插件中還包括對指向另 一插件的擴展點的定義，而所述依賴關系 是指一個插件的實例化依賴于另一插件的實現。
19. 一種分離功能邏輯與非功能邏輯并實現非功能邏輯的系統， 包括應用層實體，用于供用戶實現功能邏輯并利用基礎架構服務插件 層實體提供的插件；基礎架構服務插件層實體，用于利用應用運行時層實體的服務， 實現所述插件；以及應用運行時層實體，用于實現權利要求1至9所述的方法以供所 述基礎架構服務插件層實體調用。
全文摘要
本發明提供了一種與功能邏輯相分離地且可擴展地實現非功能邏輯的方法和設備及其系統和計算機程序產品，所述方法包括步驟基于加載的策略需求配置獲得策略與所需的插件之間的關聯關系；根據所獲得的關聯關系，產生插件上下文定義，所述插件上下文定義是與該插件有關的插件上下文的一部分，其中所述插件上下文定義了插件所提供的服務以及對與其有聯系的其它插件的引用；以及基于插件上下文定義而產生插件上下文對象，其中，所述插件上下文對象是實例化的插件上下文定義。根據本發明的方法使得能夠根據應用配置對基礎架構服務插件進行隱式調用，避免了查詢插件注冊表并在插件調用期間獲得更好的性能。
文檔編號G06F9/44GK101387956SQ20071015369
公開日2009年3月18日 申請日期2007年9月14日 優先權日2007年9月14日
發明者劍 徐, 俊 朱, 談華芳, 黃鶴遠 申請人:國際商業機器公司