组件技术介绍
組件（component）技術(shù)是各種軟件重用方法中最重要的一種方法，也是分布式計(jì)算和Web服務(wù)的基礎(chǔ)。網(wǎng)絡(luò)應(yīng)用中的軟件組件，又被稱為中間件（middleware）。
組件技術(shù)的應(yīng)用現(xiàn)在已經(jīng)十分廣泛，從Windows編程中使用的各種控件和公用對(duì)話框，到ActiveX控件和DirectX的應(yīng)用；從微軟公司的COM，到Sun公司的JavaBean。其中最流行的組件技術(shù)的應(yīng)用是——客戶端的VBX（微軟/VB）和服務(wù)器端的EJB（Sun/Java）。
在網(wǎng)絡(luò)及其應(yīng)用都很發(fā)達(dá)的今天，對(duì)組件服務(wù)的需求十分強(qiáng)烈，因此組件技術(shù)近年來得到了飛速的發(fā)展和廣泛的應(yīng)用。
概述
面向過程的編程重用函數(shù)、面向?qū)ο蟮木幊讨赜妙?、范型編程重用的是算法的源代碼，而組件編程則重用特定功能完整的程序模塊。
每個(gè)組件會(huì)提供一些標(biāo)準(zhǔn)且簡(jiǎn)單的應(yīng)用接口，允許使用者設(shè)置和調(diào)整參數(shù)和屬性。用戶可以將不同來源的多個(gè)組件有機(jī)地結(jié)合在一起，快速構(gòu)成一個(gè)符合實(shí)際需要（而且價(jià)格相對(duì)低廉）的復(fù)雜（大型）應(yīng)用程序。
組件區(qū)別于一般軟件的主要特點(diǎn)，是其重用性（公用/通用）、可定制性（設(shè)置參數(shù)和屬性）、自包容性（模塊相對(duì)獨(dú)立，功能相對(duì)完整）和互操作性（多個(gè)組件可協(xié)同工作）。可以簡(jiǎn)單方便地利用可視化工具來實(shí)現(xiàn)組件的集成，也是組件技術(shù)一個(gè)重要優(yōu)點(diǎn)。
普通的面向過程和面向?qū)ο蟮木幊?#xff0c;一般會(huì)生成兩種類型的軟件——針對(duì)特定應(yīng)用的可執(zhí)行程序和面向通用編程的API庫。前者包含你需要的各種特殊的具體功能，但必須從頭到尾自己來創(chuàng)建，其中很多是低層次的重復(fù)勞動(dòng)；后者雖然通用，但是卻不能滿足你的具體應(yīng)用的特殊需要。
組件技術(shù)提供了第三種途徑，它將庫的可重用性與特定程序的可定制性結(jié)合起來，讓用戶可以用可重用的組件來定制自己特定的應(yīng)用程序。所以組件在某些方面類似于“可執(zhí)行程序”，在另一些方面又類似于“庫”。
采用MFC編程，可選的項(xiàng)目類型為：MFC應(yīng)用程序、MFC DLL和MFC ActiveX控件，剛好對(duì)應(yīng)于上面所討論的可執(zhí)行程序、庫和組件這三類軟件。
使用組件來構(gòu)造應(yīng)用程序的工作（組件集成）非常簡(jiǎn)單，不需要專業(yè)程序員，普通用戶就可以很快做到。但是設(shè)計(jì)和創(chuàng)建組件（組件編寫）的工作卻十分復(fù)雜，只有高水平的程序員才有可能完成。這也是為什么VB和Delphi會(huì)如此流行的真正理由（組件功能強(qiáng)大，編寫又非常簡(jiǎn)單），同樣也是ATL和EJB等（創(chuàng)建組件）編程少有人問津的原因。
1．組件模型
軟件組件的核心技術(shù)是組件模型，它定義了組件的體系結(jié)構(gòu)、及如何操作此結(jié)構(gòu)并與外部交互。
組件模型的兩個(gè)基本要素是——組件和容器。模型的組件部分，提供構(gòu)造組件的模版，是各種組件創(chuàng)建和使用的基礎(chǔ)；模型的容器部分，定義了將多個(gè)組件結(jié)合成有用結(jié)構(gòu)的方法，為組件的結(jié)合和交互提供環(huán)境支持。
2．中間件
中間件（middleware）是一種軟件，它能使處于應(yīng)用層的各種應(yīng)用組件之間實(shí)現(xiàn)異構(gòu)網(wǎng)絡(luò)平臺(tái)上的協(xié)同工作。它是組件技術(shù)的最重要方面，也是分布式計(jì)算和Web服務(wù)等網(wǎng)絡(luò)應(yīng)用技術(shù)的主要組成部分。
????
????中間件定義
中間件一般由執(zhí)行環(huán)境和應(yīng)用開發(fā)工具兩部分組成，可以分成事務(wù)處理中間件、消息中間件和分布式中間件等三種類型。?
組件標(biāo)準(zhǔn)
組件應(yīng)用的基礎(chǔ)是標(biāo)準(zhǔn)，沒有統(tǒng)一的接口描述、沒有規(guī)范的組件通信、沒有標(biāo)準(zhǔn)的對(duì)象請(qǐng)求和遠(yuǎn)程調(diào)用，就沒有組件應(yīng)用的可能。目前的主要標(biāo)準(zhǔn)有CORBA（國際通用）、EJB（Sun的Java）、COM和CLR（Microsoft的Windows和.NET）。
1．CORBA
最早而且最權(quán)威的組件標(biāo)準(zhǔn)是CORBA (Common Object Request Broker Architecture公共對(duì)象請(qǐng)求代理體系結(jié)構(gòu))，它由OMG所制定的，1991年10月推出1.0版、1996年8月推出2.0、2002年7月推出3.0，目前的最新標(biāo)準(zhǔn)為2004年3月12日推出的CORBA 3.0.3版。
OMG（Object Management Group對(duì)象管理組，http://www.omg.org/）是一個(gè)開放型非贏利組織，負(fù)責(zé)制定和維護(hù)協(xié)同企業(yè)應(yīng)用的計(jì)算機(jī)工業(yè)規(guī)范。OMG是1989年4月由3COM、Apple、美國航空、佳能、DG、HP、IBM、Philips、Unisys和Sun等11個(gè)公司所創(chuàng)建的，后來發(fā)展到800多個(gè)公司、大學(xué)和國際組織，包括Adobe、AT&T、Borland、CA、加州大學(xué)、富士通、HP、IBM、MIT、NEC、Oracle、Sun、東芝、東京大學(xué)、清華大學(xué)、W3C等。（注意，Intel和Microsoft并沒有參加）。OMG制定的其他標(biāo)準(zhǔn)還有：UML（Unified Modeling Language統(tǒng)一建模語言）和IDL（Interface Definition Language接口定義語言）等。
CORBA是一種獨(dú)立于語言的分布式對(duì)象模型，其核心是ORB（Object Request Broker對(duì)象請(qǐng)求代理），對(duì)象的接口用IDL描述，在各個(gè)對(duì)象之間采用IIOP（Internet Inter-ORB Protocal因特網(wǎng)ORB交互協(xié)議）進(jìn)行通信。
2．EJB
Sun公司于1997年在Java的JDK 1.1中引入了JavaBean組件技術(shù)，后來又于2000年隨J2EE（Java 2 Platform, Enterprise Edition，Java 2平臺(tái)企業(yè)版）引入服務(wù)器端的組件技術(shù)EJB（Enterprise JavaBeans企業(yè)爪哇豆）和網(wǎng)頁編程工具JSP（JavaServer Page, Java服務(wù)器網(wǎng)頁）。至此，Java成為了一種功能完備的分布式計(jì)算環(huán)境。這對(duì)（一心想進(jìn)入利潤豐厚的服務(wù)器端網(wǎng)絡(luò)應(yīng)用軟件領(lǐng)域的）微軟公司，造成了極大的威脅。
JavaBean是一種可復(fù)用的平臺(tái)獨(dú)立的軟件組件，開發(fā)者可以在軟件構(gòu)造器工具（如網(wǎng)頁構(gòu)造器、可視化應(yīng)用程序構(gòu)造器、GUI設(shè)計(jì)器、服務(wù)器應(yīng)用程序構(gòu)造器等）中對(duì)其直接進(jìn)行可視化操作。而EJB則是用于開發(fā)企業(yè)級(jí)的服務(wù)器端應(yīng)用程序的JavaBean組件，可以分為會(huì)話bean（維護(hù)會(huì)話）、實(shí)體bean（處理事務(wù)）和消息bean（提供異步消息機(jī)制）等三種類型。
JavaBean的接口采用標(biāo)準(zhǔn)的IDL定義，在各個(gè)EJB之間采用RMI（Remote Method Invocation遠(yuǎn)程方法調(diào)用）進(jìn)行通信，而且J2EE還為EJB與CORBA的集成提供了適配器和RMI的擴(kuò)展——RMI-IIOP，可以用于EJB與CORBA對(duì)象之間進(jìn)行通信。而對(duì)數(shù)據(jù)庫的訪問，采用的則是JDBC（Java DataBase Connection，Java數(shù)據(jù)庫連接）。
3．COM / .NET
COM（Component Object Model組件對(duì)象模型）是微軟公司于1993年提出的一種組件技術(shù)，是軟件對(duì)象組件之間相互通信的一種方式和規(guī)范，它是一種平臺(tái)無關(guān)、語言中立、位置透明、支持網(wǎng)絡(luò)的中間件技術(shù)。
COM是OLE（Object Linking and Embedding對(duì)象鏈接和嵌入）的發(fā)展（而OLE又是DLL [Dynamic Link Libraries動(dòng)態(tài)鏈接庫]的發(fā)展），DCOM（Distributed COM分布式COM，1996年）和COM+（DCOM+管理，1999年）則是COM的發(fā)展。ActiveX控件是COM的具體應(yīng)用（如VBX和DirectX都是基于ActiveX的）。ATL（Active Template Library活動(dòng)模板庫）是開發(fā)COM的主要工具，也可以用MFC來直接開發(fā)COM，但是非常復(fù)雜。
作為組件技術(shù)的進(jìn)一步發(fā)展，微軟公司又于2002年推出了.NET框架，其中的核心技術(shù)就是用來代替COM組件功能的CLR（Common Language Runtime公共語言運(yùn)行庫），可采用各種編程語言，利用托管代碼來訪問（例如C#、VB、MC++），使用的是.NET的框架類庫FCL（Framework Class Library）
微軟公司的各種組件技術(shù)之間的關(guān)系與發(fā)展可以參見下圖：
下面分別對(duì)這幾種組件技術(shù)加以簡(jiǎn)單的介紹：
1）DLL
DLL（Dynamic Link Libraries動(dòng)態(tài)鏈接庫）還不能算組件技術(shù)，但它是軟件重用的鼻祖。
普通的靜態(tài)鏈接庫，雖然也能做到代碼共享，但是只能是在編譯鏈接階段。在運(yùn)行時(shí)，程序調(diào)用的是已經(jīng)鏈接到自己程序內(nèi)的庫函數(shù)。如果每個(gè)程序都包含所有用到的公共庫函數(shù)，則這是很大的浪費(fèi)，即增加了鏈接器的負(fù)擔(dān)，也增大了可執(zhí)行程序的大小，還加大了內(nèi)存的消耗。
而DLL采用動(dòng)態(tài)鏈接，對(duì)公用的庫函數(shù)，系統(tǒng)只有一個(gè)拷貝（位于系統(tǒng)目錄的*.DLL文件），而且只有在應(yīng)用程序真正調(diào)用時(shí)，才加載到內(nèi)存。在內(nèi)存中的庫函數(shù)，也只有一個(gè)拷貝，可供所有運(yùn)行的程序調(diào)用。當(dāng)再也沒有程序需要調(diào)用它時(shí)，系統(tǒng)會(huì)自動(dòng)將其卸載，并釋放其所占用的內(nèi)存空間。
由于應(yīng)用程序是通過系統(tǒng)來調(diào)用動(dòng)態(tài)鏈接庫的，因此每個(gè)DLL都有一個(gè)類似于main的入口函數(shù)。在DLL中，供外部應(yīng)用程序調(diào)用的庫函數(shù)叫做導(dǎo)出函數(shù)，而只是被DLL內(nèi)部調(diào)用的庫函數(shù)則叫做內(nèi)部函數(shù)。導(dǎo)出函數(shù)在客戶端叫做導(dǎo)入函數(shù)。
2）OLE
OLE（Object Linking and Embedding對(duì)象鏈接和嵌入）是微軟公司于1991年推出的一種簡(jiǎn)單的組件技術(shù)，它允許Windows中的程序相互之間進(jìn)行合作——一個(gè)（客戶）程序調(diào)用另一個(gè)（服務(wù)器）程序，以完成特定的功能。而且客戶/主程序的界面不變，就似將服務(wù)器程序嵌入到客戶程序中一樣。
實(shí)際上，OLE是一套可擴(kuò)充的協(xié)議（OLECLI.DLL和OLESVR.DLL），能使客戶和服務(wù)器應(yīng)用程序通過一組DLL彼此進(jìn)行通信。1993年隨VC1.0又推出OLE2.0，對(duì)1.0版進(jìn)行了若干改進(jìn)，使客戶和服務(wù)器的結(jié)合更加緊密，還允許服務(wù)器繼承客戶的主菜單，使得用戶感覺不到在不同應(yīng)用之間的切換，并且提供了C++的開發(fā)接口（1.0版只支持C語言開發(fā)）。
OLE使用DDE（Dynamic Data Exchange動(dòng)態(tài)數(shù)據(jù)交換）作為客戶和服務(wù)器應(yīng)用程序間通信的傳輸機(jī)制。
3）COM
OLE 1.0實(shí)際上只是一種復(fù)合文檔，而OLE 2.0已經(jīng)具有標(biāo)準(zhǔn)組件的特性了，顯然它是受了CORBA的影響。所以從OLE 1.0到OLE 2.0，是微軟公司在組件技術(shù)上的一次飛躍。這時(shí)，OLE的名稱就有一些名不副實(shí)了，因此，在增加了一些功能和規(guī)范之后，微軟公司于1993年在OLE 2.0的基礎(chǔ)上又推出了COM，用來替代原有的OLE。這樣一來，OLE就不再是一種獨(dú)立的組件技術(shù)，而只是COM技術(shù)在鏈接和嵌入方面的一個(gè)具體應(yīng)用。而1996年3月推出的ActiveX控件，也只是COM的一個(gè)具體應(yīng)用，它是用來替代原有的VBX控件的。
COM（Component Object Model組件對(duì)象模型）的核心是一組組件對(duì)象間交互的規(guī)范，它定義了組件對(duì)象如何與其使用者通過二進(jìn)制接口標(biāo)準(zhǔn)進(jìn)行交互，COM的接口是組件的球類型紐帶。
除了規(guī)范之外，COM還是一個(gè)稱為COM庫的實(shí)現(xiàn)，它包括若干API函數(shù)，用于COM程序的創(chuàng)建。COM還提供定位服務(wù)的實(shí)現(xiàn)，可以根據(jù)系統(tǒng)注冊(cè)表，從一個(gè)類標(biāo)識(shí)（CLSID）來確定組件的位置。
COM采用自己的IDL來描述組件的接口（interface），支持多接口一解決版本兼容問題。COM為所有組件定義了一個(gè)共同的父接口IUnknown。GUID 是一個(gè) 128 位整數(shù)（16 字節(jié)），COM將其用于計(jì)算機(jī)和網(wǎng)絡(luò)的唯一標(biāo)識(shí)符。
除了基本規(guī)范和系統(tǒng)實(shí)現(xiàn)之外，COM的構(gòu)成還包括永久存儲(chǔ)、綽號(hào)（moniker智能命名/標(biāo)記）和統(tǒng)一數(shù)據(jù)轉(zhuǎn)移（UDT = Uniform Data Transfer）三個(gè)核心的操作系統(tǒng)部件。
在COM模型中，所有將CLSID傳遞給COM并獲得實(shí)例化的對(duì)象，都被稱為COM客戶（程序）。最簡(jiǎn)單的實(shí)例化方式，是調(diào)用COM函數(shù)CoCreateInstance。也可以通過調(diào)用CoGetClassObject函數(shù)來為CLSID獲得類工廠（Class Factory）對(duì)象的接口指針。
與COM客戶程序相比，COM服務(wù)器在于實(shí)現(xiàn)類工廠和其生產(chǎn)的對(duì)象類，并將工廠提供給COM使用。
4）DCOM
DCOM（Distributed COM，分布式COM）是COM的網(wǎng)絡(luò)化。COM具有進(jìn)程透明性，組件對(duì)象和客戶代碼不必考慮調(diào)用傳遞的細(xì)節(jié)，只須按照普通函數(shù)方式進(jìn)行調(diào)用即可。而DCOM將COM的進(jìn)程透明性擴(kuò)展為位置透明性，形成分布式的組件對(duì)象模型。
COM組件有兩種進(jìn)程模型：進(jìn)程內(nèi)組件和進(jìn)程外組件。由于本地進(jìn)程外組件與客戶運(yùn)行在不同的進(jìn)程空間，所以客戶程序?qū)M件對(duì)象的調(diào)用，并不是直接進(jìn)行的，而是用到了操作系統(tǒng)支持的一些跨進(jìn)程通信方法，主要有OSF（Open Software Foundation開放軟件基金會(huì)，現(xiàn)在改為Open Group[開放小組http://www.opengroup.org/]）開發(fā)的DCE RPC（Distributed Computing Environment 分布式計(jì)算環(huán)境Remote Procedure Call 遠(yuǎn)程過程調(diào)用）和LPC（Local Procedure Calls本地過程調(diào)用）。
為了將組件服務(wù)延伸到網(wǎng)絡(luò)，DCOM建立在自己的網(wǎng)絡(luò)協(xié)議上，并通過SCM（Service Control Manager服務(wù)控制管理器）來創(chuàng)建遠(yuǎn)程對(duì)象。
COM的"ORB"結(jié)構(gòu)
?
5）COM+
COM+是COM-based services and technologies（基于COM的服務(wù)與技術(shù)）的簡(jiǎn)稱，+表示將COM組件技術(shù)和MTS（Microsoft Transaction Server微軟事務(wù)服務(wù)器）應(yīng)用程序主機(jī)技術(shù)結(jié)合在一起。它是一個(gè)面向應(yīng)用的高級(jí)COM運(yùn)行環(huán)境，它在COM基礎(chǔ)上實(shí)現(xiàn)了許多面向企業(yè)應(yīng)用的分布式應(yīng)用程序所需要的服務(wù)。COM+是1999年隨Windows 2000推出的。
COM+是Windows DNA（Distributed interNet Application [Architecture]分布式網(wǎng)間應(yīng)用程序[體系結(jié)構(gòu)]）框架的重要組成部分。DNA為Windows環(huán)境下開發(fā)分布式應(yīng)用程序提供了工具和框架，而COM+則是DNA的中間件技術(shù)和粘結(jié)劑。COM+會(huì)自動(dòng)處理不同的編程任務(wù)，諸如資源集池、分離應(yīng)用程序、事件發(fā)布、預(yù)定和分布式事務(wù)。
??
其中：
IE = Internet Explorer因特網(wǎng)探索者（微軟的網(wǎng)頁瀏覽器）
HTTP = Hypertext Transfer Protocol超文本傳輸協(xié)議（W3C制定的萬維網(wǎng)的數(shù)據(jù)傳輸協(xié)議）
IIS = Internet Information Services因特網(wǎng)信息服務(wù)（微軟的因特網(wǎng)服務(wù)器平臺(tái)組件）
ASP = Active Server Page動(dòng)態(tài)服務(wù)器網(wǎng)頁（微軟的Web服務(wù)器端的動(dòng)態(tài)網(wǎng)頁腳本語言）
Visual InterDev = VS中針對(duì)因特網(wǎng)應(yīng)用程序的專用開發(fā)工具（使用ASP）
MTS = Microsoft Transaction Server微軟事務(wù)服務(wù)器（協(xié)調(diào)組件和數(shù)據(jù)庫、負(fù)責(zé)管理資源的緩存和共享、實(shí)現(xiàn)可伸縮性，通常被用作組件的容器，可以視為組件管理器或代理程序）
MSMQ = Microsoft Message Queue Server微軟信息隊(duì)列服務(wù)器（負(fù)責(zé)復(fù)雜的、涉及發(fā)送和接收、同步和異步之信息獲取的協(xié)調(diào)工作）
ADO = ActiveX Data Objects，ActiveX數(shù)據(jù)對(duì)象（微軟的關(guān)系數(shù)據(jù)庫訪問組件）
SQL = Structured Query Language結(jié)構(gòu)化查詢語言（關(guān)系數(shù)據(jù)庫的通用查詢語言，國際標(biāo)準(zhǔn)）
6）.NET / CLR
.NET的核心是CLR，它可以視為是COM技術(shù)的繼承和發(fā)展，它解決了COM組件模型中存在的主要問題。
?
Web服務(wù)
框架和庫
（ASP.NET、ADO.NET、Windows窗體）
交互標(biāo)準(zhǔn)
（SOAP、WSDL）
開發(fā)工具
（Visual Studio .NET/2005）
組件模型
對(duì)象模型和CLS
CLR
.NET框架的分層結(jié)構(gòu)
（1）COM的缺陷
COM（含DCOM和COM+）組件技術(shù)存在許多問題，其中有一些是關(guān)鍵的，有的甚至是致命的。
組件技術(shù)主要強(qiáng)調(diào)在獨(dú)立開發(fā)和部署的程序之間的一套約定（contract），COM則是微軟公司將這些約定規(guī)范化的首次嘗試。COM既能作為設(shè)計(jì)范例（paradigm）（它將組件的約定，表示為類型定義），也可用作支持平臺(tái)技術(shù)。作為前者，COM編程模型相當(dāng)成功；但是后者卻存在諸多問題，正是由于缺乏穩(wěn)固的平臺(tái)技術(shù)，COM時(shí)代面臨著終結(jié)。
組件間的約定，純粹是通過用戶與組件之間的語義保證和假設(shè)的形式來表示的。但是，仍需要定義某種形式來表示語義，專業(yè)的做法是——采用可編程的類型定義，以及描述這些類型定義的人工可讀文檔。
COM用類型的形式表示組件約定，但是該約定存在如下兩個(gè)關(guān)鍵問題，使得其對(duì)語義的表示并不是最優(yōu)的。
1．約定的描述：
COM沒有定義約定的交換格式，即COM規(guī)范所約定的類型定義，必須通過完全是COM之外的某種技術(shù)來進(jìn)行交互。微軟定義和支持的COM交換格式有兩個(gè)——IDL（Interface Definition Language接口語言定義）和TLB（Type LiBrary類型庫），但是這兩種格式并不是同構(gòu)的，其中也沒有哪種格式是權(quán)威的或標(biāo)準(zhǔn)的。
另外，COM的描述約定方式，至少還存在兩個(gè)其他的關(guān)鍵問題：
① COM缺乏對(duì)組件依賴性的描述。因此，沒有辦法來解析COM組件（或者其約定的定義），也不能確定它所需要的其他組件，從而無法保證它的正確運(yùn)行。由于缺少相關(guān)信息，使得部署基于COM的應(yīng)用程序，很難確定它需要哪些DLL，也不能靜態(tài)確定所需要的是哪個(gè)版本的組件，這讓對(duì)版本問題的診斷變得極其復(fù)雜；
② COM約定的描述格式缺乏擴(kuò)展性。IDL是基于文本的，極少隨組件部署，通常只有C++程序員才會(huì)使用。但是，在MTS下開發(fā)企業(yè)應(yīng)用的C++程序員很少，這使得IDL約定用處不大。TLB在擴(kuò)展性方面存在缺陷，而且VB與TLB/MTS之間被隔離開來，這最終導(dǎo)致了TLB的沒落。
2．約定的工作方式：
COM組件的約定是基于類型描述的，所采用的類型系統(tǒng)是C++的可移植子集。而且COM對(duì)組件的約定是物理的（二進(jìn)制約定）。它要求：每個(gè)方法都具有精確的虛函數(shù)表vtable偏移量、每個(gè)被傳遞的參數(shù)在堆棧規(guī)則中都有明確的偏移量、對(duì)象引用采用接口指針的明確格式、使用規(guī)定的分配器進(jìn)行被調(diào)用這內(nèi)存分配。
就底層技術(shù)而言，COM組件的約定，最終只是在內(nèi)存中形成堆棧結(jié)構(gòu)的協(xié)議，根本沒有（按組件所要求的那樣來）描述語義內(nèi)容。二進(jìn)制的物理約定，過度關(guān)心細(xì)節(jié)，使COM難于使用和開發(fā)。尤其在針對(duì)COM組件的版本控制問題上，物理性約定所產(chǎn)生的問題就更大了。這使得COM組件，難以進(jìn)行語義修改和版本升級(jí)。
COM組件的約定定義的精確性，產(chǎn)生了高效的代碼，但這卻是以難以接受的不可靠性和開發(fā)使用及擴(kuò)展升級(jí)的困難與復(fù)雜性為代價(jià)的。
（2）CLR與CLI
為了解決COM所存在的這些問題，微軟公司的COM和MTS小組，計(jì)劃開發(fā)一個(gè)新的組件平臺(tái)。開始時(shí)叫COM3或COM+ 2.0，后來又叫COR（Component Object Runtime組件對(duì)象運(yùn)行時(shí)）和URT（Universal Runtime通用運(yùn)行時(shí)），最后才被命名為CLR（Common Language Runtime公共語言運(yùn)行時(shí)[庫/層]）。它是現(xiàn)在（由微軟提交的）成為國際標(biāo)準(zhǔn)的CLI（Common Language Infrastructure公共語言基礎(chǔ)結(jié)構(gòu)）在Windows平臺(tái)上的一種具體實(shí)現(xiàn)。
CLI是針對(duì)可執(zhí)行代碼格式、以及能執(zhí)行該代碼的運(yùn)行時(shí)環(huán)境的一種規(guī)范。CLI標(biāo)準(zhǔn)包含如下幾個(gè)主要組成部分：
????CTS（Common Type System公共類型系統(tǒng)）——被編譯器、工具和CLI本身所共用的一種統(tǒng)一類型系統(tǒng)。 它是一個(gè)模型，定義了在聲明、使用和管理類型時(shí)，CLI應(yīng)遵循的規(guī)則。CTS建立了一個(gè)框架，使跨語言集成、類型安全和高性能的代碼執(zhí)行成為可能；
????CLS（Common Language Specification公共語言規(guī)范）——語言設(shè)計(jì)者和框架（類庫）設(shè)計(jì)者之間的一種協(xié)定（agreement）。它指定了CTS的一個(gè)子集和一個(gè)用法常規(guī)（usage conventions）集；
?????metadata（元數(shù)據(jù)）——描述和引用CTS所定義類型的數(shù)據(jù)。元數(shù)據(jù)被以一種獨(dú)立于任何特定的程序設(shè)計(jì)語言的方式存儲(chǔ)。從而，元數(shù)據(jù)為操作程序的工具（如編譯器和調(diào)試器）之間，以及這些工具和VES之間提供了一種公共交換機(jī)制。
????VES（Virtual Execution System虛擬執(zhí)行系統(tǒng)）——該系統(tǒng)實(shí)現(xiàn)和實(shí)施CTS模型。VES負(fù)責(zé)裝入和運(yùn)行為CLI編寫的程序。它在運(yùn)行時(shí)，利用元數(shù)據(jù)將分開產(chǎn)生的模型連接在一起，并為執(zhí)行托管代碼和數(shù)據(jù)提供所需要的服務(wù)。VES也被稱為執(zhí)行引擎；
?????CIL（Common Intermediate Language公共中間語言）——可被VES理解的指令集，也被稱為MSIL（微軟IL）。
?
程序集（Assembly，裝配/匯編）就是CLR中的組件，它是一種功能上不可分割的邏輯單元，由一個(gè)或多個(gè)模塊（module，DLL或EXE文件）組成。大多數(shù)程序集就是一個(gè)DLL，所以程序集也被稱為“托管DLL”。
每個(gè)程序集中有一個(gè)程序清單（manifest），它包含了程序集內(nèi)所有模塊和其他文件的信息（如程序集的名稱、版本號(hào)、文化和語言、程序集包含的所有文件列表、程序集所依賴的其他程序集等）。
程序集中自然包含了若干CLR類的（MSIL中間語言）代碼，同時(shí)還包含了這些類的元數(shù)據(jù)。元數(shù)據(jù)（metadata）描述模塊中類型的相關(guān)信息，如類型的名稱、類型的可見性（public或assembly）、基類、實(shí)現(xiàn)的接口和方法、暴露的屬性、提供的事件等。
（3）CLR與COM
與COM相比，CLR的組件技術(shù)有了質(zhì)的飛躍，前面提到的各種COM問題都迎刃而解、一掃而光。
相同點(diǎn)——約定（類型）
與COM平臺(tái)一樣，CLR也注意組件間的約定，而且這些約定也是基于類型的（注意，組件技術(shù)里的類型是廣義的，除了包括字符、布爾、整數(shù)和浮點(diǎn)數(shù)等基本數(shù)據(jù)類型之外，還包括類、結(jié)構(gòu)、接口、串、數(shù)組、枚舉、委托[delegate，指向方法和函數(shù)的安全指針，用于事件處理和回調(diào)]等高級(jí)結(jié)構(gòu)類型）。
?
???不同點(diǎn)1——約定的描述（元數(shù)據(jù)）
但是與COM（沒有標(biāo)準(zhǔn)格式來描述約定）不同的是，CLR有完全規(guī)范的格式來描述組件之間的約定——元數(shù)據(jù)（metadata）。CLR的元數(shù)據(jù)是機(jī)器可讀的，其格式是公開的、國際標(biāo)準(zhǔn)化的、完全規(guī)范的。CLR還提供了讀寫元數(shù)據(jù)的實(shí)用工具，使用者不需要了解元數(shù)據(jù)的底層文件格式。
不像COM的元數(shù)據(jù)（IDL和TLB）難以定制和擴(kuò)展；而且其元數(shù)據(jù)中又缺少依賴和版本信息，使得對(duì)組件的部署和版本的控制都十分困難；另外，COM元數(shù)據(jù)的存在是可選的，而且經(jīng)常會(huì)被忽略掉，這對(duì)組件應(yīng)用的構(gòu)建會(huì)造成很多問題。
CLR通過定制（本身就是強(qiáng)類型的）特性（attribute），使其元數(shù)據(jù)可以達(dá)到清晰容易的可擴(kuò)展性。CLR元數(shù)據(jù)中還包括組件的依賴關(guān)系和版本信息，從而允許使用新技術(shù)來處理版本控制問題。另外，CLR元數(shù)據(jù)的存在是強(qiáng)制性的，部署或加載組件都必須訪問元數(shù)據(jù)。因此，構(gòu)建基于CLR的基礎(chǔ)架構(gòu)和各種工具，顯然要比COM容易的多。
?
???不同點(diǎn)2——約定的類別（邏輯結(jié)構(gòu)）
CLR約定與COM約定的第二個(gè)主要差別，是約定本身的特性。
在COM中，組件的（二進(jìn)制物理）約定隱含了：堆棧約定、虛函數(shù)表和（作為方法參數(shù)傳遞的）數(shù)據(jù)結(jié)構(gòu)在內(nèi)存中的表示形式。
在CLR中，約定被描述為類型的邏輯結(jié)構(gòu)，而不是物理的二進(jìn)制格式。因此，在CLR的約定中，并沒有暗示訪問字段和方法的精確代碼順序。所以，在考慮虛方法布局、堆棧規(guī)則、對(duì)齊方式、以及參數(shù)傳遞方式時(shí)，CLR具有極大的靈活性。CLR是通過名字和簽名來引用字段與方法，而不是偏移量。這樣，CLR就避免了困擾COM的聲明順序問題，組件成員的實(shí)際地址/偏移量，需要等到運(yùn)行時(shí)在類型被加載及初始化時(shí)，才能夠確定。另外，CLR版本的改變（如從2002年1.0到2003年的1.1，再到2005年的2.0），也不會(huì)帶來組件的重新編譯。
?
???不同點(diǎn)3——CIL
實(shí)現(xiàn)數(shù)據(jù)表示形式和方法地址的虛擬化，需要延時(shí)對(duì)約定的物理方面（如方法表和字段偏移量等）的解析，這就要求組件中不含具體的機(jī)器代碼?；贑LR的組件，通過采用CIL（Common Intermediate Language公共中間語言）而實(shí)現(xiàn)了這一要求。
CIL是一組與處理器無關(guān)的指令集，它具有抽象能力——將與機(jī)器代碼密切關(guān)聯(lián)的物理數(shù)據(jù)的表示形式抽象出來。CIL使用的操作碼在訪問字段和調(diào)用方法時(shí)，不再使用絕對(duì)地址和偏移量，而是利用元數(shù)據(jù)進(jìn)行基于名字和簽名的引用。
CIL會(huì)在（第一次被）執(zhí)行前被翻譯成本地的機(jī)器語言，CLR執(zhí)行的是由CIL生成的本地代碼。而CLR在CIL杯翻譯成本機(jī)代碼之前，是不會(huì)解析其物理綁定的細(xì)節(jié)的。由于翻譯工作是在部署機(jī)器上進(jìn)行的，所以，組件所需的外部類型定義，將與部署機(jī)器上的某個(gè)類型匹配，而不是開發(fā)者的機(jī)器。這極大減少了跨組件約定的不可靠性，同時(shí)又不會(huì)降低代碼的運(yùn)行性能。
另外，由于CIL到機(jī)器代碼的翻譯，發(fā)生在部署的機(jī)器上。所以，任何用到的待定處理器布局或?qū)R規(guī)則，都將與（代碼將在其上面運(yùn)行的）目標(biāo)處理器架構(gòu)相匹配?，F(xiàn)在，軟件正面臨著一次重大的處理器遷移，即從IA-32/Pentium和AMD32架構(gòu)向IA-64/Itanium和AMD64架構(gòu)的發(fā)展。對(duì)于這次升級(jí)，CLR顯得尤為重要。
?
??COM向CLR過渡
鑒于COM技術(shù)已經(jīng)被使用多年，有許多現(xiàn)存的資源，程序員和用戶也不可能一下子就全部完全轉(zhuǎn)換到.NET環(huán)境。因此，微軟公司也允許在CLR環(huán)境中繼續(xù)使用COM/DCOM/ COM+和DNA，這可以通過.NET框架的 System.EnterpriseServices 命名空間來進(jìn)行。
但是鑒于與COM相比，CLR組件所具有的無比優(yōu)越性。COM技術(shù)必然會(huì)走向滅亡，而.NET的CLR終將取而代之。
作者：touzani?
來源：CSDN?
原文：https://blog.csdn.net/touzani/article/details/1619472?
版權(quán)聲明：本文為博主原創(chuàng)文章，轉(zhuǎn)載請(qǐng)附上博文鏈接！
總結(jié)
- 上一篇： react学习(28)---react挂
- 下一篇： 使用Flash air操作本地文件