組件（component）技術是各種軟件重用方法中最重要的一種方法，也是分布式計算和Web服務的基礎。網絡應用中的軟件組件，又被稱為中間件（middleware）。 組件技術的應用現在已經十分廣泛，從Windows編程中使用的各種控件和公用對話框，到ActiveX控件和DirectX的應用；從微軟公司的COM，到Sun公司的JavaBean。其中最流行的組件技術的應用是——客戶端的VBX（微軟/VB）和服務器端的EJB（Sun/Java）。 在網絡及其應用都很發達的今天，對組件服務的需求十分強烈，因此組件技術近年來得到了飛速的發展和廣泛的應用。

概述

面向過程的編程重用函數、面向對象的編程重用類、范型編程重用的是算法的源代碼，而組件編程則重用特定功能完整的程序模塊。 每個組件會提供一些標準且簡單的應用接口，允許使用者設置和調整參數和屬性。用戶可以將不同來源的多個組件有機地結合在一起，快速構成一個符合實際需要（而且價格相對低廉）的復雜（大型）應用程序。 組件區別于一般軟件的主要特點，是其重用性（公用/通用）、可定制性（設置參數和屬性）、自包容性（模塊相對獨立，功能相對完整）和互操作性（多個組件可協同工作）。可以簡單方便地利用可視化工具來實現組件的集成，也是組件技術一個重要優點。 普通的面向過程和面向對象的編程，一般會生成兩種類型的軟件——針對特定應用的可執行程序和面向通用編程的API庫。前者包含你需要的各種特殊的具體功能，但必須從頭到尾自己來創建，其中很多是低層次的重復勞動；后者雖然通用，但是卻不能滿足你的具體應用的特殊需要。 組件技術提供了第三種途徑，它將庫的可重用性與特定程序的可定制性結合起來，讓用戶可以用可重用的組件來定制自己特定的應用程序。所以組件在某些方面類似于“可執行程序”，在另一些方面又類似于“庫”。 采用MFC編程，可選的項目類型為：MFC應用程序、MFC DLL和MFC ActiveX控件，剛好對應于上面所討論的可執行程序、庫和組件這三類軟件。 使用組件來構造應用程序的工作（組件集成）非常簡單，不需要專業程序員，普通用戶就可以很快做到。但是設計和創建組件（組件編寫）的工作卻十分復雜，只有高水平的程序員才有可能完成。這也是為什么VB和Delphi會如此流行的真正理由（組件功能強大，編寫又非常簡單），同樣也是ATL和EJB等（創建組件）編程少有人問津的原因。 1．組件模型 軟件組件的核心技術是組件模型，它定義了組件的體系結構、及如何操作此結構并與外部交互。 組件模型的兩個基本要素是——組件和容器。模型的組件部分，提供構造組件的模版，是各種組件創建和使用的基礎；模型的容器部分，定義了將多個組件結合成有用結構的方法，為組件的結合和交互提供環境支持。

2．中間件 中間件（middleware）是一種軟件，它能使處于應用層的各種應用組件之間實現異構網絡平臺上的協同工作。它是組件技術的最重要方面，也是分布式計算和Web服務等網絡應用技術的主要組成部分。

??? 中間件定義

中間件一般由執行環境和應用開發工具兩部分組成，可以分成事務處理中間件、消息中間件和分布式中間件等三種類型。

組件標準

組件應用的基礎是標準，沒有統一的接口描述、沒有規范的組件通信、沒有標準的對象請求和遠程調用，就沒有組件應用的可能。目前的主要標準有CORBA（國際通用）、EJB（Sun的Java）、COM和CLR（Microsoft的Windows和.NET）。 1．CORBA 最早而且最權威的組件標準是CORBA (Common Object Request Broker Architecture公共對象請求代理體系結構)，它由OMG所制定的，1991年10月推出1.0版、1996年8月推出2.0、2002年7月推出3.0，目前的最新標準為2004年3月12日推出的CORBA 3.0.3版。 OMG（Object Management Group對象管理組，http://www.omg.org/）是一個開放型非贏利組織，負責制定和維護協同企業應用的計算機工業規范。OMG是1989年4月由3COM、Apple、美國航空、佳能、DG、HP、IBM、Philips、Unisys和Sun等11個公司所創建的，后來發展到800多個公司、大學和國際組織，包括Adobe、AT&T、Borland、CA、加州大學、富士通、HP、IBM、MIT、NEC、Oracle、Sun、東芝、東京大學、清華大學、W3C等。（注意，Intel和Microsoft并沒有參加）。OMG制定的其他標準還有：UML（Unified Modeling Language統一建模語言）和IDL（Interface Definition Language接口定義語言）等。 CORBA是一種獨立于語言的分布式對象模型，其核心是ORB（Object Request Broker對象請求代理），對象的接口用IDL描述，在各個對象之間采用IIOP（Internet Inter-ORB Protocal因特網ORB交互協議）進行通信。
2．EJB

Sun公司于1997年在Java的JDK 1.1中引入了JavaBean組件技術，后來又于2000年隨J2EE（Java 2 Platform, Enterprise Edition，Java 2平臺企業版）引入服務器端的組件技術EJB（Enterprise JavaBeans企業爪哇豆）和網頁編程工具JSP（JavaServer Page, Java服務器網頁）。至此，Java成為了一種功能完備的分布式計算環境。這對（一心想進入利潤豐厚的服務器端網絡應用軟件領域的）微軟公司，造成了極大的威脅。

JavaBean是一種可復用的平臺獨立的軟件組件，開發者可以在軟件構造器工具（如網頁構造器、可視化應用程序構造器、GUI設計器、服務器應用程序構造器等）中對其直接進行可視化操作。而EJB則是用于開發企業級的服務器端應用程序的JavaBean組件，可以分為會話bean（維護會話）、實體bean（處理事務）和消息bean（提供異步消息機制）等三種類型。 JavaBean的接口采用標準的IDL定義，在各個EJB之間采用RMI（Remote Method Invocation遠程方法調用）進行通信，而且J2EE還為EJB與CORBA的集成提供了適配器和RMI的擴展——RMI-IIOP，可以用于EJB與CORBA對象之間進行通信。而對數據庫的訪問，采用的則是JDBC（Java DataBase Connection，Java數據庫連接）。
3．COM / .NET

COM（Component Object Model組件對象模型）是微軟公司于1993年提出的一種組件技術，是軟件對象組件之間相互通信的一種方式和規范，它是一種平臺無關、語言中立、位置透明、支持網絡的中間件技術。

COM是OLE（Object Linking and Embedding對象鏈接和嵌入）的發展（而OLE又是DLL [Dynamic Link Libraries動態鏈接庫]的發展），DCOM（Distributed COM分布式COM，1996年）和COM+（DCOM+管理，1999年）則是COM的發展。ActiveX控件是COM的具體應用（如VBX和DirectX都是基于ActiveX的）。ATL（Active Template Library活動模板庫）是開發COM的主要工具，也可以用MFC來直接開發COM，但是非常復雜。

作為組件技術的進一步發展，微軟公司又于2002年推出了.NET框架，其中的核心技術就是用來代替COM組件功能的CLR（Common Language Runtime公共語言運行庫），可采用各種編程語言，利用托管代碼來訪問（例如C#、VB、MC++），使用的是.NET的框架類庫FCL（Framework Class Library）
微軟公司的各種組件技術之間的關系與發展可以參見下圖：

下面分別對這幾種組件技術加以簡單的介紹： 1）DLL

DLL（Dynamic Link Libraries動態鏈接庫）還不能算組件技術，但它是軟件重用的鼻祖。

普通的靜態鏈接庫，雖然也能做到代碼共享，但是只能是在編譯鏈接階段。在運行時，程序調用的是已經鏈接到自己程序內的庫函數。如果每個程序都包含所有用到的公共庫函數，則這是很大的浪費，即增加了鏈接器的負擔，也增大了可執行程序的大小，還加大了內存的消耗。 而DLL采用動態鏈接，對公用的庫函數，系統只有一個拷貝（位于系統目錄的*.DLL文件），而且只有在應用程序真正調用時，才加載到內存。在內存中的庫函數，也只有一個拷貝，可供所有運行的程序調用。當再也沒有程序需要調用它時，系統會自動將其卸載，并釋放其所占用的內存空間。
由于應用程序是通過系統來調用動態鏈接庫的，因此每個DLL都有一個類似于main的入口函數。在DLL中，供外部應用程序調用的庫函數叫做導出函數，而只是被DLL內部調用的庫函數則叫做內部函數。導出函數在客戶端叫做導入函數。

2）OLE

OLE（Object Linking and Embedding對象鏈接和嵌入）是微軟公司于1991年推出的一種簡單的組件技術，它允許Windows中的程序相互之間進行合作——一個（客戶）程序調用另一個（服務器）程序，以完成特定的功能。而且客戶/主程序的界面不變，就似將服務器程序嵌入到客戶程序中一樣。

實際上，OLE是一套可擴充的協議（OLECLI.DLL和OLESVR.DLL），能使客戶和服務器應用程序通過一組DLL彼此進行通信。1993年隨VC1.0又推出OLE2.0，對1.0版進行了若干改進，使客戶和服務器的結合更加緊密，還允許服務器繼承客戶的主菜單，使得用戶感覺不到在不同應用之間的切換，并且提供了C++的開發接口（1.0版只支持C語言開發）。

OLE使用DDE（Dynamic Data Exchange動態數據交換）作為客戶和服務器應用程序間通信的傳輸機制。

3）COM

OLE 1.0實際上只是一種復合文檔，而OLE 2.0已經具有標準組件的特性了，顯然它是受了CORBA的影響。所以從OLE 1.0到OLE 2.0，是微軟公司在組件技術上的一次飛躍。這時，OLE的名稱就有一些名不副實了，因此，在增加了一些功能和規范之后，微軟公司于1993年在OLE 2.0的基礎上又推出了COM，用來替代原有的OLE。這樣一來，OLE就不再是一種獨立的組件技術，而只是COM技術在鏈接和嵌入方面的一個具體應用。而1996年3月推出的ActiveX控件，也只是COM的一個具體應用，它是用來替代原有的VBX控件的。

COM（Component Object Model組件對象模型）的核心是一組組件對象間交互的規范，它定義了組件對象如何與其使用者通過二進制接口標準進行交互，COM的接口是組件的球類型紐帶。

除了規范之外，COM還是一個稱為COM庫的實現，它包括若干API函數，用于COM程序的創建。COM還提供定位服務的實現，可以根據系統注冊表，從一個類標識（CLSID）來確定組件的位置。

COM采用自己的IDL來描述組件的接口（interface），支持多接口一解決版本兼容問題。COM為所有組件定義了一個共同的父接口IUnknown。GUID 是一個 128 位整數（16 字節），COM將其用于計算機和網絡的唯一標識符。

除了基本規范和系統實現之外，COM的構成還包括永久存儲、綽號（moniker智能命名/標記）和統一數據轉移（UDT = Uniform Data Transfer）三個核心的操作系統部件。

在COM模型中，所有將CLSID傳遞給COM并獲得實例化的對象，都被稱為COM客戶（程序）。最簡單的實例化方式，是調用COM函數CoCreateInstance。也可以通過調用CoGetClassObject函數來為CLSID獲得類工廠（Class Factory）對象的接口指針。

與COM客戶程序相比，COM服務器在于實現類工廠和其生產的對象類，并將工廠提供給COM使用。

4）DCOM

DCOM（Distributed COM，分布式COM）是COM的網絡化。COM具有進程透明性，組件對象和客戶代碼不必考慮調用傳遞的細節，只須按照普通函數方式進行調用即可。而DCOM將COM的進程透明性擴展為位置透明性，形成分布式的組件對象模型。

COM組件有兩種進程模型：進程內組件和進程外組件。由于本地進程外組件與客戶運行在不同的進程空間，所以客戶程序對組件對象的調用，并不是直接進行的，而是用到了操作系統支持的一些跨進程通信方法，主要有OSF（Open Software Foundation開放軟件基金會，現在改為Open Group[開放小組http://www.opengroup.org/]）開發的DCE RPC（Distributed Computing Environment 分布式計算環境Remote Procedure Call 遠程過程調用）和LPC（Local Procedure Calls本地過程調用）。

為了將組件服務延伸到網絡，DCOM建立在自己的網絡協議上，并通過SCM（Service Control Manager服務控制管理器）來創建遠程對象。

COM的"ORB"結構

5）COM+

COM+是COM-based services and technologies（基于COM的服務與技術）的簡稱，+表示將COM組件技術和MTS（Microsoft Transaction Server微軟事務服務器）應用程序主機技術結合在一起。它是一個面向應用的高級COM運行環境，它在COM基礎上實現了許多面向企業應用的分布式應用程序所需要的服務。COM+是1999年隨Windows 2000推出的。

COM+是Windows DNA（Distributed interNet Application [Architecture]分布式網間應用程序[體系結構]）框架的重要組成部分。DNA為Windows環境下開發分布式應用程序提供了工具和框架，而COM+則是DNA的中間件技術和粘結劑。COM+會自動處理不同的編程任務，諸如資源集池、分離應用程序、事件發布、預定和分布式事務。

其中：

IE = Internet Explorer因特網探索者（微軟的網頁瀏覽器）

HTTP = Hypertext Transfer Protocol超文本傳輸協議（W3C制定的萬維網的數據傳輸協議）

IIS = Internet Information Services因特網信息服務（微軟的因特網服務器平臺組件）

ASP = Active Server Page動態服務器網頁（微軟的Web服務器端的動態網頁腳本語言）

Visual InterDev = VS中針對因特網應用程序的專用開發工具（使用ASP）

MTS = Microsoft Transaction Server微軟事務服務器（協調組件和數據庫、負責管理資源的緩存和共享、實現可伸縮性，通常被用作組件的容器，可以視為組件管理器或代理程序）

MSMQ = Microsoft Message Queue Server微軟信息隊列服務器（負責復雜的、涉及發送和接收、同步和異步之信息獲取的協調工作）

ADO = ActiveX Data Objects，ActiveX數據對象（微軟的關系數據庫訪問組件）

SQL = Structured Query Language結構化查詢語言（關系數據庫的通用查詢語言，國際標準）

6）.NET / CLR .NET的核心是CLR，它可以視為是COM技術的繼承和發展，它解決了COM組件模型中存在的主要問題。

Web服務
框架和庫 （ASP.NET、ADO.NET、Windows窗體）
交互標準 （SOAP、WSDL）	開發工具 （Visual Studio .NET/2005）
組件模型
對象模型和CLS
CLR

.NET框架的分層結構 （1）COM的缺陷 COM（含DCOM和COM+）組件技術存在許多問題，其中有一些是關鍵的，有的甚至是致命的。 組件技術主要強調在獨立開發和部署的程序之間的一套約定（contract），COM則是微軟公司將這些約定規范化的首次嘗試。COM既能作為設計范例（paradigm）（它將組件的約定，表示為類型定義），也可用作支持平臺技術。作為前者，COM編程模型相當成功；但是后者卻存在諸多問題，正是由于缺乏穩固的平臺技術，COM時代面臨著終結。 組件間的約定，純粹是通過用戶與組件之間的語義保證和假設的形式來表示的。但是，仍需要定義某種形式來表示語義，專業的做法是——采用可編程的類型定義，以及描述這些類型定義的人工可讀文檔。 COM用類型的形式表示組件約定，但是該約定存在如下兩個關鍵問題，使得其對語義的表示并不是最優的。 1．約定的描述： COM沒有定義約定的交換格式，即COM規范所約定的類型定義，必須通過完全是COM之外的某種技術來進行交互。微軟定義和支持的COM交換格式有兩個——IDL（Interface Definition Language接口語言定義）和TLB（Type LiBrary類型庫），但是這兩種格式并不是同構的，其中也沒有哪種格式是權威的或標準的。 另外，COM的描述約定方式，至少還存在兩個其他的關鍵問題：

① COM缺乏對組件依賴性的描述。因此，沒有辦法來解析COM組件（或者其約定的定義），也不能確定它所需要的其他組件，從而無法保證它的正確運行。由于缺少相關信息，使得部署基于COM的應用程序，很難確定它需要哪些DLL，也不能靜態確定所需要的是哪個版本的組件，這讓對版本問題的診斷變得極其復雜；

② COM約定的描述格式缺乏擴展性。IDL是基于文本的，極少隨組件部署，通常只有C++程序員才會使用。但是，在MTS下開發企業應用的C++程序員很少，這使得IDL約定用處不大。TLB在擴展性方面存在缺陷，而且VB與TLB/MTS之間被隔離開來，這最終導致了TLB的沒落。 2．約定的工作方式： COM組件的約定是基于類型描述的，所采用的類型系統是C++的可移植子集。而且COM對組件的約定是物理的（二進制約定）。它要求：每個方法都具有精確的虛函數表vtable偏移量、每個被傳遞的參數在堆棧規則中都有明確的偏移量、對象引用采用接口指針的明確格式、使用規定的分配器進行被調用這內存分配。 就底層技術而言，COM組件的約定，最終只是在內存中形成堆棧結構的協議，根本沒有（按組件所要求的那樣來）描述語義內容。二進制的物理約定，過度關心細節，使COM難于使用和開發。尤其在針對COM組件的版本控制問題上，物理性約定所產生的問題就更大了。這使得COM組件，難以進行語義修改和版本升級。 COM組件的約定定義的精確性，產生了高效的代碼，但這卻是以難以接受的不可靠性和開發使用及擴展升級的困難與復雜性為代價的。 （2）CLR與CLI

為了解決COM所存在的這些問題，微軟公司的COM和MTS小組，計劃開發一個新的組件平臺。開始時叫COM3或COM+ 2.0，后來又叫COR（Component Object Runtime組件對象運行時）和URT（Universal Runtime通用運行時），最后才被命名為CLR（Common Language Runtime公共語言運行時[庫/層]）。它是現在（由微軟提交的）成為國際標準的CLI（Common Language Infrastructure公共語言基礎結構）在Windows平臺上的一種具體實現。

CLI是針對可執行代碼格式、以及能執行該代碼的運行時環境的一種規范。CLI標準包含如下幾個主要組成部分：

??? CTS（Common Type System公共類型系統）——被編譯器、工具和CLI本身所共用的一種統一類型系統。 它是一個模型，定義了在聲明、使用和管理類型時，CLI應遵循的規則。CTS建立了一個框架，使跨語言集成、類型安全和高性能的代碼執行成為可能；

??? CLS（Common Language Specification公共語言規范）——語言設計者和框架（類庫）設計者之間的一種協定（agreement）。它指定了CTS的一個子集和一個用法常規（usage conventions）集；

???? metadata（元數據）——描述和引用CTS所定義類型的數據。元數據被以一種獨立于任何特定的程序設計語言的方式存儲。從而，元數據為操作程序的工具（如編譯器和調試器）之間，以及這些工具和VES之間提供了一種公共交換機制。

??? VES（Virtual Execution System虛擬執行系統）——該系統實現和實施CTS模型。VES負責裝入和運行為CLI編寫的程序。它在運行時，利用元數據將分開產生的模型連接在一起，并為執行托管代碼和數據提供所需要的服務。VES也被稱為執行引擎；

???? CIL（Common Intermediate Language公共中間語言）——可被VES理解的指令集，也被稱為MSIL（微軟IL）。

程序集（Assembly，裝配/匯編）就是CLR中的組件，它是一種功能上不可分割的邏輯單元，由一個或多個模塊（module，DLL或EXE文件）組成。大多數程序集就是一個DLL，所以程序集也被稱為“托管DLL”。 每個程序集中有一個程序清單（manifest），它包含了程序集內所有模塊和其他文件的信息（如程序集的名稱、版本號、文化和語言、程序集包含的所有文件列表、程序集所依賴的其他程序集等）。 程序集中自然包含了若干CLR類的（MSIL中間語言）代碼，同時還包含了這些類的元數據。元數據（metadata）描述模塊中類型的相關信息，如類型的名稱、類型的可見性（public或assembly）、基類、實現的接口和方法、暴露的屬性、提供的事件等。

（3）CLR與COM

與COM相比，CLR的組件技術有了質的飛躍，前面提到的各種COM問題都迎刃而解、一掃而光。

相同點——約定（類型）

與COM平臺一樣，CLR也注意組件間的約定，而且這些約定也是基于類型的（注意，組件技術里的類型是廣義的，除了包括字符、布爾、整數和浮點數等基本數據類型之外，還包括類、結構、接口、串、數組、枚舉、委托[delegate，指向方法和函數的安全指針，用于事件處理和回調]等高級結構類型）。

?? 不同點1——約定的描述（元數據）

但是與COM（沒有標準格式來描述約定）不同的是，CLR有完全規范的格式來描述組件之間的約定——元數據（metadata）。CLR的元數據是機器可讀的，其格式是公開的、國際標準化的、完全規范的。CLR還提供了讀寫元數據的實用工具，使用者不需要了解元數據的底層文件格式。 不像COM的元數據（IDL和TLB）難以定制和擴展；而且其元數據中又缺少依賴和版本信息，使得對組件的部署和版本的控制都十分困難；另外，COM元數據的存在是可選的，而且經常會被忽略掉，這對組件應用的構建會造成很多問題。 CLR通過定制（本身就是強類型的）特性（attribute），使其元數據可以達到清晰容易的可擴展性。CLR元數據中還包括組件的依賴關系和版本信息，從而允許使用新技術來處理版本控制問題。另外，CLR元數據的存在是強制性的，部署或加載組件都必須訪問元數據。因此，構建基于CLR的基礎架構和各種工具，顯然要比COM容易的多。

?? 不同點2——約定的類別（邏輯結構）

CLR約定與COM約定的第二個主要差別，是約定本身的特性。 在COM中，組件的（二進制物理）約定隱含了：堆棧約定、虛函數表和（作為方法參數傳遞的）數據結構在內存中的表示形式。 在CLR中，約定被描述為類型的邏輯結構，而不是物理的二進制格式。因此，在CLR的約定中，并沒有暗示訪問字段和方法的精確代碼順序。所以，在考慮虛方法布局、堆棧規則、對齊方式、以及參數傳遞方式時，CLR具有極大的靈活性。CLR是通過名字和簽名來引用字段與方法，而不是偏移量。這樣，CLR就避免了困擾COM的聲明順序問題，組件成員的實際地址/偏移量，需要等到運行時在類型被加載及初始化時，才能夠確定。另外，CLR版本的改變（如從2002年1.0到2003年的1.1，再到2005年的2.0），也不會帶來組件的重新編譯。

?? 不同點3——CIL

實現數據表示形式和方法地址的虛擬化，需要延時對約定的物理方面（如方法表和字段偏移量等）的解析，這就要求組件中不含具體的機器代碼。基于CLR的組件，通過采用CIL（Common Intermediate Language公共中間語言）而實現了這一要求。 CIL是一組與處理器無關的指令集，它具有抽象能力——將與機器代碼密切關聯的物理數據的表示形式抽象出來。CIL使用的操作碼在訪問字段和調用方法時，不再使用絕對地址和偏移量，而是利用元數據進行基于名字和簽名的引用。 CIL會在（第一次被）執行前被翻譯成本地的機器語言，CLR執行的是由CIL生成的本地代碼。而CLR在CIL杯翻譯成本機代碼之前，是不會解析其物理綁定的細節的。由于翻譯工作是在部署機器上進行的，所以，組件所需的外部類型定義，將與部署機器上的某個類型匹配，而不是開發者的機器。這極大減少了跨組件約定的不可靠性，同時又不會降低代碼的運行性能。 另外，由于CIL到機器代碼的翻譯，發生在部署的機器上。所以，任何用到的待定處理器布局或對齊規則，都將與（代碼將在其上面運行的）目標處理器架構相匹配。現在，軟件正面臨著一次重大的處理器遷移，即從IA-32/Pentium和AMD32架構向IA-64/Itanium和AMD64架構的發展。對于這次升級，CLR顯得尤為重要。

? COM向CLR過渡

鑒于COM技術已經被使用多年，有許多現存的資源，程序員和用戶也不可能一下子就全部完全轉換到.NET環境。因此，微軟公司也允許在CLR環境中繼續使用COM/DCOM/ COM+和DNA，這可以通過.NET框架的 System.EnterpriseServices 命名空間來進行。 但是鑒于與COM相比，CLR組件所具有的無比優越性。COM技術必然會走向滅亡，而.NET的CLR終將取而代之。

width="728" scrolling="no" height="90" frameborder="0" align="middle" src="http://download1.csdn.net/down3/20070601/01184120111.htm" marginheight="0" marginwidth="0">

總結

以上是生活随笔為你收集整理的组件(component)技术介绍的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。