《BREW進階與精通——3G移動增值業務的運營、定製與開發》連載之13—BREW精要之COM 模型

 

COM是Component Object Model （元件物件模型）的縮寫。BREW基本上遵從COM這一組件構架的。組件架構的一個優點就是應用可以隨時間的流逝而發展進化，除此之外，使用組件還有一些可以使對以有應用的升級更加方便和靈活的優點，如應用的定製，組件庫以及分布式組件等。

BREW的COM屬性

COM原本是微軟公司為了電腦工業的軟體生產更加符合人類的行為方式開發的一種軟體開發技術。在COM構架下，人們可以開發出各種各樣的功能專一的組件，然後將它們按照需要組合起來，構成複雜的應用系統。由此帶來的好處是多方面的：可以將系統中的組件用新的替換掉，以便隨時進行系統的升級和定製；可以在多個應用系統中重複利用同一個組件；可以方便的將應用系統擴充到網路環境下；COM與語言，平台無關的特性使所有的程式員均可充分發揮自己的才智與專長編寫組件模組等等。

BREW
SDK中所提供的服務實際上是一些小的二進位可執行程式形成的組件，它們可以給應用程式、作業系統以及其他組件提供服務。開發自訂的BREW組件（例如，BREW 擴充類）就好像是開發動態、物件導向的API。多個BREW對象可以串連起來形成應用程式或組件系統。並且組件可以在運行時刻，在不被重新連結或編譯應用程式的情況下被卸下或替換掉。

COM實際上象結構化編程及物件導向編程方法那樣，也是一種編程方法。使用組件的種種優點直接來源於可以將它們動態插入或卸出應用。為了實現這種功能，所有的組件必須滿足兩個條件：第一，組件必須動態連結；第二，它們必須隱藏（或封裝）其內部實現細節。動態連結對於組件而言是一個至關重要的要求，而訊息隱藏則是動態連結的一個必要條件。

總的來說，BREW可以在運行時刻同其他元件連線起來構成某個應用程式，可以動態插入或卸出應用，是動態連結的。BREW隱藏（封裝）其內部實現細節，基於BREW的應用以二進位的形式發布，可以在不妨礙已有使用者的情況下被升級。BREW的自訂擴充按照一種標準的方式來宣布它們的存在。

BREW中的介面

COM的對象之間通過介面進行互動。介面是包含了一組函數的資料結構，通過這組資料結構，代碼可以調用組件對象的功能。介面定義了一群組成員函數，這群組成員函數是組件對象暴露給使用者的所有可用資訊，客戶可以利用這些資訊取得組件提供的服務。與COM使用GUID作為介面的唯一標識類似，BREW使用稱之為ClassID的一個4位元組不帶正負號的整數作為唯一標識。

BREW提供了一組固定的介面，哪怕以後實現的方式出現了變化，只要應用程式和組件程式之間的介面不變，就不需要任何改變。從技術上講，介面是包含了一組函數的資料結構，通過這組資料結構，使用者可以調用組件的功能。同樣與COM類似，BREW使用基於介面對象的引用計數來控制介面的生存期，並且為多個程式之間共用統一介面對象提供了有效控制手段。一般來說，引用計數技術包括三種實現方式:一是使用全域引用計數，這樣可以精確的控制整個應用程式模組的生存期；二是使用針對每個介面一個引用計數跟蹤介面的使用方式，但是對於實現了多個介面的對象，這樣做的效果就是解析度太細這將導致無法精確跟蹤每個介面的使用方式，造成管理困難，唯一的好處就是能夠減少資源的消耗;三是使用每個對象一個引用計數這樣可以精確控制對象的生存期，並且在複雜度和資源消耗上能夠達到較好的平衡。BREW介面的引用計數使用方式三，是針對每個介面類或者是應用程式採用引用計數。

應用程式用一個指向介面資料結構的指標來調用介面成員函數，4-5所示。

       圖 4-5： BREW應用程式的介面指標示意

實際上，應用所使用的介面指標也指向一個指標，這個指標則指向一組函數的定義（即介面函數表，又稱為虛函數表，vtable）。每一個介面成員函數的第一個參數必須為指向這個定義這個介面的組件類型的指標（可以參考一下用C類比C++的過程，在C++的類定義中，每一個成員函數的第一個參數都是隱含的，即編譯系統自動添加的this指標），這是因為介面本身不能獨立存在，它必須依附於某個COM組件而存在。因此這個指標可以提供對象執行個體的屬性資訊，在調用過程中可以知道是在對那個COM對象進行操作。 圖中到圓邊方框之前，定義的都是指標，真正的實現要依賴於COM組件給出的實現，對於客戶來說，只需要知道應該調用什麼就足夠了，但是對於組件來說就必須考慮這樣的功能應該怎樣實現。介面是客戶程式和組件程式之間的橋樑，介面應該具有不變性，並且一個COM對象也應該支援多個介面。

對於同一個類的所有對象，它們分別擁有不同的資料成員儲存區，但是共用同一份成員函數的拷貝，在不同的對象調用成員函數的時候根據對象隱式傳遞的this指標判別是哪個對象調用了成員函數。對於介面的實現也類似，類似於C++中的資料成員，對於指向虛函數表的指標，每個介面指標都有屬於自己的一份拷貝，而對於提供功能實現的虛函數表，則共用同一份拷貝（圖4-6）。

圖 4-6： BREW中的虛函數表

 

BREW中的ISHELL_createlnstance方法使用了對象建立型設計模式的抽象原廠模式，它提供了建立一系列相關或者是相互依賴對象的介面，而無須指定他們具體的類，這樣可以只提供BREW
的介面，而在需要的時候根據具體的ClassID建立具體的實現，一般來說抽象原廠模式有以下的幾個優點:

(1)分離了具體的實現和介面：只需指定不同的介面和classlD，既可成功建立介面對象，而無須關心是何種實現;

(2)有利於更新產品模組:當有新的模組更新的時候，無須更改程式，只需替換相應的模組實現，這樣就可以使用新的模組;

(3) 有利於產品的一致性;由於classID的唯一性，可以建立指定的對象實現，而不會在有眾多實現的應用中出現混亂。

對於抽象原廠模式難以支援新種類產品的缺點，在BREW 的設計架構中給予消除了，由於重新啟動BREW環境的時候，會對系統範圍內的ClassID 予以重新註冊，因此當新種類加入的時候，只需要提供確定的ClassID
既可成功建立應用。