微軟倡導的ActiveX網絡化多媒體對象技術
壹、ActiveX的起源
ActiveX起初只是壹個商標名，它所涵蓋的技術並不是孤立的，大部分都與Internet和Web有關。更重要的是，ActiveX的整個技術是由微軟的COM(組件對象模型)構建的。但是不要誤認為ActiveX定義了所有基於com的技術。COM與微軟Office和Windows以及微軟現在所做的壹切都有關系，但顯然這些產品並不是ActiveX家族的成員。
ActiveX是從Microsoft-OLE的復合文檔技術發展而來的。OLE的最初版本只針對復合文檔，但在後來的OLE2版本中，引入了COM。COM是在OLE設計師的需求下誕生的。它的基本出發點是通過壹個總的組織，讓壹個軟件為另壹個軟件提供服務。所以COM的第壹個用戶是OLE2。其實COM和復合文檔沒有太大的關系。後來，COM作為壹種與復合文檔完全無關的技術，開始被廣泛使用。這樣，微軟開始“染指”通用平臺技術。但COM不是產品，它需要壹個品牌名稱。不幸的是，市場專家選擇了“OLE”作為商標名稱。因此，使用COM的技術開始被貼上OLE的標簽。當然，這些技術大多與復合文檔無關。微軟想向人們解釋:“OLE不僅僅是復合文檔！”這需要相當多的精力和時間。
於是，在1996的春天，微軟改變了主意，選擇ActiveX作為新的品牌名稱。ActiveX指的是基於COM的松散定義的技術集合，而OLE仍然僅指復合文檔。當然最重要的核心還是COM。
讓對象模型完全獨立於編程語言是壹個非常新穎的想法。從C++和Java的對象中，我們可以得到壹些了解。但是所謂的COM對象是什麽呢？為了便於理解，COM可以看作是壹種封裝技術，即可以看作是將軟件的不同部分按照某種面向對象的形式組合成壹個交互過程和壹組支持庫。COM對象可以用C++、Java、VB等任何語言編寫，可以用DLL的形式實現，也可以作為不同進程的執行文件實現。使用COM對象的客戶端不需要關心對象是用什麽語言編寫的，或者它是由DLL還是另壹個進程執行的。從客戶端來說，沒有區別。
這種通用的處理技術非常有用。比如用戶協同運行的兩個應用，可以把它們的* * *和作業部分實現為COM對象之間的交互(當然現在OLE復合文檔也可以做到)。從Web服務器下載並在瀏覽器中執行的代碼可以被瀏覽器視為COM對象。也就是說，COM技術也是封裝可下載代碼的標準方式(ActiveX控件執行這個功能)。
甚至應用程序與原生OS交互的方法都可以由COM指定(Windows和Windows NT使用的新API大部分都定義為COM對象)。雖然COM起源於復合文檔，但它可以有效地應用於許多軟件問題。
二、ActiveX王國
活躍的平臺是微軟的世界觀。它的基本思想是使用ActiveX控件建立壹個自動機制，包括與用戶交互並適應COM和Web服務器的事務處理監視器。主動平臺包括兩部分:主動服務器和主動客戶端。
主動服務器實際上是中間層。使用組件或Active server pages為業務邏輯和主要應用程序處理提供場所。ActiveServer技術的核心是NT服務器、Microsoft事務服務器、數據管理服務、目錄服務、Web服務和網絡服務。
Transaction server將線程生成、數據庫倍增等傳統的TP監控功能與微軟基於組件的編程模型相結合。活動平臺的其他組件，如數據管理服務，使用OLE DB和ODBC來訪問數據源，如DB2、Oracle和SQL Server。目錄服務圍繞DCOM(分布式COM)提供了壹個目錄服務層，以便遠程對象可以在網絡上相互搜索。Web服務是圍繞互聯網信息服務器建立的，它為服務器上的Web應用程序開發提供腳本機制。網絡服務是圍繞DCOM構建的，它可以通過以同步MS-RPC為中介的網絡與控件連接。
主動客戶端是跨平臺的。雖然微軟的技術是獨占的，但是也想把這個技術開放給多個OS。具體的實現方案是使用腳本引擎。這個腳本引擎由標準的HTML、具有微軟特色的Java虛擬機(JVM)、微軟的VBScript和JSc ript組成。主動客戶端被組裝到微軟IE 3.0和4.0中，可以通過ActiveX成為用戶C/S應用的壹部分。
從全部采用Windows的企業用戶來看，Active platform可以提供壹個堅實的、可擴展的服務器應用開發平臺。ActiveServer在TP monitor等高端產品的場合也使用了壹些常用的工具和技術。因此，小型工作組和內部網應用程序不會超過活動服務器的能力。雖然Acti ve platform的目標機是異構機環境，但由於過於依賴IE，無法驅動客戶端。雖然在壹些非Windows S平臺上已經推出了Explorer，但是最好支持的最新版本的Explorer還是在Windows s上。
第三，ActiveX的進展
1.分布式計算的擴展
COM的最初版本假設COM對象和它們的客戶端運行在同壹臺機器上(要麽在同壹個進程中，要麽在不同的進程中)，DCOM是ActiveX家族的重要成員。後來也可以在Windows 95中使用。DCOM並沒有改變客戶制作COM對象和相互交流的方式。
客戶端使用完全相同的代碼，並且可以訪問本地和遠程對象。但在許多情況下，客戶希望使用壹些DCOM配件。DCOM配備了分布式安全和保密機制，提供認證和數據加密。在將於1998發布的Windows NT 5.0中，Kerberos和其他安全協議應被添加到DCOM中。DCOM已經能夠使用簡單的目錄服務(如域名服務)在其他機器上搜索COM對象。NT 5.0需要增加對活動目錄的支持。活動目錄基於域名服務和輕量級目錄訪問協議。
DCOM的勁敵壹直是OMG(對象管理集團)的CORBA(公共對象查詢代理架構)。它已被組裝成產品，如愛奧那島的Orbix和Visigenic的VisiBroker。不久前，另壹種支持分布式對象的技術——Java遠程方法調用問世。ORBA和DCOM都可以在用多種語言編寫的對象之間進行通信。另壹方面，RMI僅限於Java實現的對象之間的通信。顯然，這是壹種約束。但是RMI使用起來非常簡單。此外，RMI開發人員可以使用Java來設計協議規範。所以在語言的功能上，可以做到天衣無縫。
編寫壹個只處理兩三個客戶端的DCOM服務器相對簡單。然而，構建壹個能夠高效處理成百上千個客戶端的DCOM服務器是相當困難的。
為了編寫可伸縮的DCOM服務器，微軟發布了事務處理服務器(MTS)。在支持事務處理的同時，MTS還提供自動生成線索、重用智能對象等服務。MTS使得制作可伸縮的服務器變得非常簡單。即使對於不需要事務處理的應用程序，使用MTS也是有益的。事實上，微軟鼓勵人們用VB編寫MTS應用程序。這不同於傳統的開發業務服務器的方法。所有的MTS應用程序都被寫成壹個以上的COM對象，必須用DLL實現。壹般來說，MTS對客戶端是不可見的。客戶端只需要像往常壹樣制作和使用COM對象。
2.組件的標準化
基於組件的應用程序開發方法與組裝電子設備的方法相同，可以使用制造的組件構建應用程序。桌面上使用的基於COM的組件稱為ActiveX控件。所謂的ActiveX控件，無非就是壹個符合壹定標準的COM對象，與客戶端進行交互。
例如，ActiveX控件必須通過自動化(即使用調度接口)來公開方法。通過這種標準化的交互功能，您可以在許多不同的環境中使用相同的控件。在這個標準接口的背後，ActiveX控件幾乎可以執行任何事情。現在很多軟件公司都可以提供實現各種功能的控件。
ActiveX控件是作為DDL編寫的，所以它們必須加載到容器中。ActiveX控件的原型容器是VB，此外還有很多容器可供選擇。目前壹個非常重要的控件容器就是微軟的網頁瀏覽器。
現在很多方法都需要所謂的ActiveX控件來實現。它們已經從機器的本地硬盤移動到VB等容器中。幾百KB和幾MB的控件之間似乎沒有太大區別。但是，當將控件加載到Web瀏覽器中時，它很可能會通過慢速電話線。現在，控制規模已經成為壹個非常關鍵的問題。壹旦要執行超過壹定限制的控件，就會延長下載時間。所以微軟規定只有絕對必要的功能才能在ActiveX控件中執行。
蘋果和IBM推廣的OpenDoc曾經是ActiveX控件的主要競爭對手。現在OpenDoc的贊助商已經正式宣布停止資助。大多數與微軟對抗的企業都轉向J avaBeans(基於Java的組件結構)。ActiveX控件基本上和Windows捆綁在壹起，以二進制機器碼分發，但是JavaBeans不壹樣，它可以在任何地方執行。當然，這是有代價的。顯然，只要不犧牲便攜性，就不可能充分徹底地利用本地環境。當編寫可以從公共* * *互聯網下載的組件時，應該首選JavaBeans。
臺式機組件市場正在持續快速增長。大部分都是用ActiveX控件構建的(Java Beans還是少數)。然而，服務器組件的標準化卻相對滯後。在桌面上，Web瀏覽器、VB和PowerBuilder作為容器都是功能強大的編程環境。但是服務器容器呢？作為服務器上的組件容器，事務處理服務器是更好的選擇。
微軟的競爭對手千方百計阻止MTS和nt主宰市場。他們正在加速服務器上組件標準的開發，其中最有前途的是Enterprise JavaBeans。它是JavaBeans的擴展，定義了事務服務器接口。Enterprise JavaBeans的支持者希望獨立軟件供應商不要把服務器組件寫成COM組件，而是寫成Beans。
第四，ActiveX構造工具
隨著ActiveX控件的普及，ActiveX控件的開發工具日益增多。因為ActiveX是獨立於語言的，傳統的開發工具基本上可以構建和裝備ActiveX控件。最常用的有Delphi，Po werBuilder，Visual Basic，Visual C++，Visual J++等。
1.基本概述
用3GL開發ActiveX控件的方法有:①MFC(微軟基礎類)，②ATL(ActiveX模板庫)，③BaseCtrl框架等。MFC最經典。使用MFC，開發人員可以不關心界面，而是專註於對象的動作。缺點是控件的規模很大，並且在執行時DLL必須與容器壹起存在。ATL可以使用模板來生成代碼。也就是說，庫和dll不需要與控件壹起推出。在ATL中，您需要從作為模板存在的幾個基本類中派生。AT L也有壹些缺點，就是接口不好處理，應用中必要的接口必須單獨做。此外，ATL不支持類向導。不幸的是，沒有向導可以自動將對象描述語言和接口定義語言文件與用戶代碼同步。BaseCtrl是壹個簡單的庫。非常類似於ATL，但是沒有模板。事實上，由於BaseCtrl過於簡單，微軟並不支持。在BaseCtrl中，有幾個骨架控件。BaseCtrl提供了壹個易於理解的ActiveX開發模型，但它並不簡單，靈活性也不如ATL。目前對於ActiveX控件開發者來說，BaseCt rl是壹個“苦”的選擇。
2.開發工具
制作ActiveX控件的原始工具是微軟的Visual C++。它可以為ActiveX開發人員提供最多的控件。Visual J++也可以制作ActiveX控件。
Borland的兩個工具(JBuilder和IntraBuilder)也非常搶眼。但是只有Delphi 3.0和C++ Builder可以用Borl和的工具制作ActiveX組件。Borland稱Delphi的壹個A ctiveX開發函數在內部是活躍的。它以ActiveX的形式制作任何Delphi窗口。Active Inside在網絡上配備了新的控件。Delphi可以鏈接控件到COM和DCOM。
PowerBuilder 5.0是壹個客戶端/服務器開發工具，可以轉化為ActiveX開發。Powe rBuilder可以將數據窗口(power Builder應用程序開發核心部分)作為ActiveX控件來配備。以便現在的PowerBuilder開發者可以使用壹些熟悉的功能，比如PowerScript編程語言。
微軟是制作ActivX控件的最佳工具。例如，如果使用Visual Basic 5.0，開發人員可以使用可視化編程環境和本機Visual Basic for Application語言來開發控件。
動詞 （verb的縮寫）微軟倡導的ActiveX網絡化多媒體對象技術
的確，Windows和Windows NT的世界是ActiveX技術的最佳環境。但是不管Micr osoft怎麽推它的OS，也不能讓所有的企業都變成清壹色的Windows。因此，微軟應該努力使COM、DCOM和ActiveX家族的壹部分在其他操作系統上可用。現在，在Macin tosh中，已經支持ActiveX，這也包括對ActiveX控件的支持。軟件公司正在將這些技術移植到多種Unix和IBM OS/390上。DEC和惠普也打算在自己的系統上使用這些技術，也是通過移植微軟代碼來實現的。
COM已成為Windows 95和Windows NT中基礎軟件的重要組成部分，但其未來仍有許多不確定因素。比如微軟能不能把COM作為多平臺技術，讓它繼續存在和發展？為了使NT服務器適用於現有的企業，諸如DCOM這樣的分布式服務也必須在非微軟平臺上應用。解決這些問題需要很長時間。此外，基於Jav a的CORBA和RMI的產品已經成功地在多操作系統環境下運行。多平臺DCOM出來的越晚，CORBA和RMI就越領先。
ActiveX控件和JavaBeans的競爭前景如何？不管軟件是在網絡瀏覽器上運行還是在別的地方運行，簡而言之，組件軟件將是軟件開發的下壹個熱點。目前雖然ActiveX控件暫時領先，但由於OpenDoc自生自滅，與微軟競爭的企業會聯合起來與之競爭。用戶永遠不想看到“獨霸天下”。僅在這方面，JavaBeans也將在這場市場競爭中搶占壹席之地。