[發明專利]一種構件反向調用平臺及構件間類組播通信的方法

無效

• 申請號: 200910241377.5
• 申請日: 2009-11-30
• 公開（公告）號: CN101739255A
• 公開（公告）日: 2010-06-16
• 發明（設計）人: 馬亞平;李元;王永剛;馬豐文;葉東;陳小青
• 申請（專利權）人: 馬亞平;李元
• 主分類號: G06F9/44
• 分類號: G06F9/44;G06F9/54
• 代理公司: 北京路浩知識產權代理有限公司 11002
• 代理人: 胡小永

技術領域

本發明涉及基于“平臺+構件”軟件架構技術領域，特別涉及一種構件可以反向調用平臺，以及構件間進行“類組播”通信的方法。

背景技術

“平臺+構件”的軟件架構是基于“平臺”的開發和基于“構件”的開發CBD二者的有機結合。在這種系統架構中，“平臺”通常將系統的通用基礎功能進行集成，并提供統一的集成框架；而“構件”提供某方面特定的或專業性功能。“構件”通過“平臺”提供的統一集成框架集成到“平臺”上，與“平臺”一起構成一個整體的應用系統。這種傳統意義上的“平臺+構件”系統架構可以用圖1來說明。

在這種傳統意義上的系統架構中，構件和平臺之間功能和數據交互一般存在兩種方式：

一種是，領域平臺調用構件的功能函數來完成某些特定的任務或計算，而構件一般是不能反向調用平臺的計算服務的，即平臺的計算功能是很難暴露給構件使用的，如圖2所示。這種情形下，平臺是一個可執行程序且不具有二次開發功能和接口，而構件是集成到平臺上運行的動態鏈接庫。

另一種是，平臺具有二次開發功能，即除了上述平臺調用構件功能之外，平臺還提供一系列開發包(一般為動態鏈接庫DLL)，第三方(即開發用戶)可以使用平臺開發包提供的基礎功能來開發應用系統。此時，雖然調用平臺開發包功能的可以是構件也可以是某種程序片段，但用戶開發的應用系統最終是一個與平臺獨立的可執行程序EXE，而不是集成到平臺上執行的動態鏈接庫。“平臺+構件”的這種模式，是目前最為流行的軟件開發方式，如科學計算領域的MATLAB。這種具有二次開發能力的“平臺+構件”架構模式的系統結構如圖3所示。

上述兩種系統結構是“平臺+構件”架構模式系統一般的表現形式，即傳統意義上的基于平臺的開發和基于構件的開發模式。第一種模式中，開發的構件和平臺集成在一起構成一個完整的應用系統；而第二種模式中，基于平臺開發的應用系統獨立于平臺運行。

第一種模式中，平臺其實不具有二次開發能力，因此只能平臺調用構件的功能。這種模式帶來的優點是系統具有統一的集成框架、操作界面和使用風格，集成也相對簡單。但其缺點是由于平臺不提供二次能力，因此構件不能調用平臺上的基礎功能，對于那些需要類似于平臺的基礎和通用功能的構件來說，這是很大的缺陷。這種缺陷帶來的不僅僅是構件對基礎功能和某些算法的重復開發，如果構件對平臺的基礎功能存在依賴關系(即構件功能的執行需要平臺提供上下文環境)，那么此時構件與平臺的互動將變得很困難。這種情況下，如果由于依賴關系而構件需要調用或啟動平臺的某項功能(或服務)，一般是通過數據庫、文件或消息機制來完成。如，構件向數據庫寫一個“平臺調用地圖”的要求，而平臺需要通過某種輪詢機制來訪問數據庫以獲得“調用地圖”的要求。但這種機制的前提是構件和平臺之間必須事先存在某種“契約”，即平臺如何解析數據庫記錄的約定。文件方式和消息機制也同樣需要這種“契約”。這種“契約”方式雖然能解決一定的問題，但“契約”的約定往往很難，且效率很低(如數據庫訪問、文件讀取效率都比較低，輪詢機制有時對系統資源開銷較大)。因此，總體而言，由于平臺不提供二次開發功能接口，而帶來系統的可擴展性比較差。

第二種模式中，平臺提供二次開發功能接口，從某種程度上克服了第一種模式的不足，但帶來的問題是由于沒有統一的集成框架和系統操作方式，因此開發出來的系統在集成性、可互操作性、可擴展性、使用風格和界面的規范性以及維護性等方面存在嚴重不足。另外，如果一旦平臺開發包依賴于平臺的某種服務(即開發包動態庫中某些服務其實是由平臺來提供的，而不是在開發包來完成的，那些包含許多計算量比較大而相互依賴的基礎功能的平臺往往會將這些基礎功能以服務的形式提供，而不是將其放入開發包中，這樣開發包就會“瘦”許多，否則開發包過大就會造成開發困難或運行時開銷過大。如系統動力學計算平臺Adams就是這樣一種開發模式)，那么在運行應用系統的同時也必須運行平臺，這樣就可能存在不必要的系統開銷(因為許多情況下，平臺的服務是不需要的。雖然可以通過人工的方式來啟動和關閉平臺，但由于我們難以確定系統需要平臺服務的時機，因此最好將平臺一直處于運行狀態)。