ActiveX最初只不過是壹個商標名稱而已,它所涵蓋的技術並不是各自孤立的,其中多數都與Internet和Web有壹定的關聯。更重要的是,ActiveX的整體技術是由Microsoft的COM(Component Object Model,組件對象模型)構築的。但不要誤認為ActiveX是定義了所有包含基於COM的技術。COM與Microsoft Office和Windows以及Microsoft現在所做的壹切都有關聯,但顯然這些產品並不是ActiveX家族中的成員。
ActiveX是從Microsoft的復合文檔技術——OLE成長起來的。OLE最初發布的版本,只是瞄準復合文檔,但在後續版本OLE2中,導入了 COM。COM是應OLE設計者的需求而誕生的。其基本的出發點是想讓某個軟件通過壹個通用的機構為另壹個軟件提供服務。因而,COM的第壹個使用者是 OLE2。實際上,COM與復合文檔間,沒有多大關系。後來,COM就作為與復合文檔完全無關的技術,開始被廣泛使用。這樣壹來,Microsoft就開始"染指"通用平臺技術。但COM不是產品,它需要壹個商標名稱。不巧,市場專家們選用了"OLE"作為商標名稱。於是,使用COM的技術都開始貼上了 OLE的標簽。當然,這些技術中的絕大部分與復合文檔沒有關系。Microsoft要想向人們解釋:"OLE不單單是指復合文檔!",這要花費相當的精力和時間。
於是,在1996年春,Microsoft改變了主意,選擇了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王國
Active平臺是Microsoft的世界觀。其基本思想是:使用ActiveX控件,來構築包括從與用戶交互和適應COM的事務處理監視器到Web服務器、全部實現自動化的機構。Active平臺包括兩大部分:Active Server和Active Client。
Active Server實際上是中間層。使用組件或Active服務器頁面,來提供用於業務邏輯和主要應用處理的場所。ActiveServer的技術,其核心是NT Server、Microsoft事務處理服務器、數據管理服務、目錄服務、Web服務以及網絡服務。
事務處理服務器是把線程產生和數據庫多重化等傳統的TP監控功能與Microsoft的基於組件的編程模型結合起來。數據管理服務等Active平臺的其他組件是用OLE DB和ODBC,訪問DB2、Oracle、SQL Server等的數據源。目錄服務是在DCOM(Distributed COM,分布式COM)的周圍,提供目錄服務層,這樣使遠程對象在網絡上能相互搜索。Web服務以Internet信息服務器為中心進行構築,它為服務器上的Web應用開發,提供腳本生成(Scripting)機構。網絡服務以DCOM為中心進行構築,通過以同步MS-RPC為中介的網絡,使之能夠連接控件。
Active Client是壹種交叉平臺。Microsoft的技術縱然是獨家所有,但也希望將這種技術向多個OS開放。具體實施計劃是使用腳本引擎(Scripting Engine)。這種腳本引擎是由標準的HTML和帶有Microsoft特色的Java虛擬機(JVM)、Microsoft的VBScript與JScript所構成的。Active Client組裝進了Microsoft的IE 3.0和4.0,通過ActiveX,可以變成用戶的C/S應用的壹部分。
從清壹色采用Windows的企業用戶來看,Active平臺可以提供堅固的、具有可縮放性的服務器應用開發平臺。ActiveServer在TP監視器這類高端產品的場合,也利用常見的壹些工具和技術。因此,小型工作組和Intranet應用不會超越Active Server的能力。Active平臺的目標機雖是異種機環境,但由於過分依賴IE,所以不能驅動客戶端。盡管在壹些非Windows平臺上也推出了Explorer,但最好的支持、最新版本的Explorer還是在Windows上。
三、ActiveX的進展
1.向分布計算擴充
COM的最初版本假定COM對象及其客戶端是在同壹個機器上運行(可以在同壹個進程內,也可以在不同的進程內),DCOM是ActiveX家族中的重要成員。後來,它在Windows 95中也能使用。DCOM對於客戶端制作COM對象、進行交互的方法沒有做任何改變。
客戶端使用完全相同的代碼,可以訪問本地以及遠程對象。但許多場合下,客戶想使用少數的DCOM附件。DCOM備有分布式安全保密機制,提供認證和數據加密。在1998年要發布的Windows NT 5.0中,要將Kerberos等安全保密協議,追加到DCOM中。DCOM已能夠利用域名服務等簡潔的目錄服務,以用於搜尋在其他機器上的COM對象。NT 5.0要追加對Active Directory的支持。Active Directory是基於域名服務和輕型目錄訪問協議的。
DCOM的勁敵,此前壹直是OMG(Object Management Group)的CORBA(Common Object Request Broker Architecture)。它被組裝進了Iona的Orbix和Visigenic的VisiBroker等產品中。不久前,另壹種支持分散對象的技術 ——Java的遠程方法調用出臺了。無論是CORBA,還是DCOM,都能在多種語言寫的對象間進行通信。而RMI卻不同,它只限於在由Java實現的對象間進行通信。顯然,這是個制約。但RMI使用起來非常簡單。另外,RMI的開發者可以用Java來設計協議規範。因此,在語言的功能上,可以做得渾然壹體。若寫壹個只處理兩三個客戶端的DCOM服務器,還是比較簡單的。但是,要構築壹個高效處理幾百、幾千個客戶端的DCOM服務器,則相當之難。
為了便於編寫可縮放的DCOM服務器,Microsoft發布了事務處理服務器(MTS)。MTS在支持事務處理的同時,也提供自動生成線索和智能對象的重復使用等服務。MTS使可縮放服務器的制作變得相當簡單。即使是無需事務處理的應用,使用MTS也有好處。實際上,Microsoft鼓勵人們用VB來寫MTS應用。這與開發業務服務器的傳統手法不同,所有的MTS應用,都是作為壹個以上的COM對象來編寫,且必須以DLL來實現。壹般情況下,客戶端看不到MTS。客戶端只管壹如既往地制作、使用COM對象即可。
2.組件的標準化
基於組件的應用開發,其方法和組裝電子裝置壹樣,可以用已制作好的組件部件來構築應用。桌面用的、基於COM的組件叫做ActiveX控件。所謂ActiveX控件不過是遵從壹定的標準、與客戶端交互的COM對象而已。
例如,ActiveX控件必須通過Automation (即使用dispinterfaces)來公開方法。用這個被標準化的交互功能,可以在多個不同的上下文中,使用同壹個控件。在這個標準接口的"幕後", ActiveX控件幾乎是什麽都能執行。現在,許多軟件公司都能提供實現各種功能的控件。
ActiveX控件是作為DDL編寫的,為此,必須裝載到某個容器中。ActiveX控件的原型容器是VB,除此之外,還有多種容器可供選擇。目前,壹個非常重要的控件容器是Microsoft的Web瀏覽器Internet Explorer。
現在所謂ActiveX控件的那些內容,是實現許多方法所必須的。已經把它們從機器的本地硬盤移到了VB等容器中。幾百KB和幾MB的控件,似乎沒有什麽大區別。但要將控件裝載到Web瀏覽器時,很可能要通過速度很慢的電話線。現在,控件的大小已經是非常關鍵的問題。壹旦要執行超過了某個限度以上的控件,就會延長下載時間。因此,Microsoft規定:在ActiveX控件中,只能執行絕對必要的功能。
Apple和IBM推行的OpenDoc,曾是ActiveX控件的主要競爭對手。現在OpenDoc的贊助企業,已正式宣告中止資助。大部分與 Microsoft對抗的企業,轉而支持JavaBeans(基於Java的組件結構)。ActiveX控件,基本上都是和Windows捆綁在壹起、以二進制機器代碼發放的,而JavaBeans卻不同,它在哪兒都能執行。這當然是有代價的。顯而易見,只要不犧牲可移植性,就不可能完全、徹底地利用本地環境。要編寫從公***Internet上能下載的組件時,應優先選擇JavaBeans。
桌面組件市場在持續、急速增長。其中絕大部分是以ActiveX控件構築的(目前JavaBeans仍然是少數)。但服務器組件的標準化要落後壹些。在桌面上,Web瀏覽器、VB以及PowerBuilder這些編程環境,作為容器是強有力的。但服務器容器又該當如何呢?作為服務器上的組件容器, 事務處理服務器是壹個較好的選擇。
Microsoft的競爭對手,千方百計要阻止MTS和NT稱霸市場。他們正在快馬加鞭地制訂服務器上的組件標準,其中最有前途的是Enterprise JavaBeans。它是JavaBeans的擴充,並定義了事務處理服務器接口。Enterprise JavaBeans的支持者們,希望獨立軟件廠商不是將服務器組件作為COM組件來編寫,而是要作為Beans來編寫。
四、ActiveX的構築工具
隨著ActiveX控件的推廣,ActiveX控件的開發工具逐日增加。由於ActiveX不依賴於語言,所以傳統的開發工具基本上都能構築、配備ActiveX控件。最常用的有Delphi、PowerBuilder以及Visual Basic、Visual C++、Visual J++等。
1. 基本概況
用3GL開發ActiveX控件的方法有:①MFC (Microsoft Foundation Class,Microsoft基礎類),②ATL(ActiveX Template Library,ActiveX模板庫),③BaseCtrl Framework等。MFC最經典,采用MFC,可以使開發者不去關心接口,而是集中精力關註對象的動作。缺點是控件的規模較大且執行時DLL必須與容器同時存在。ATL可利用模板生成代碼。就是說,庫和DLL無需與控件壹起推出。在ATL中,需要從作為模板存在的幾個基本類派生類。ATL也有缺點,即接口的處理較難,應用中必要的接口,必須分別制作。另外,ATL不支持類向導(Class Wizard)。遺憾的是,沒有使對象描述語言(Object Description Language)和接口定義語言文件、與用戶代碼自動同步的向導。BaseCtrl是個簡便型庫。與ATL非常相似,但無模板。實際上,由於 BaseCtrl過於簡便,Microsoft並不支持它。在BaseCtrl中,帶有幾個萬能控件(Skeleton Control)。BaseCtrl提供容易理解的ActiveX開發模型,但與ATL相比並不簡單,且靈活性也不及ATL。目前看來,對於 ActiveX控件開發者來說,BaseCtrl是個"苦澀"的選擇。
2. 開發工具
可制作ActiveX控件的、最初的工具是Microsoft的Visual C++。它可為ActiveX開發者提供最多的控件。Visual J++也可以制作ActiveX控件。
Borland推出的兩個工具(JBuilder和IntraBuilder)也非常令人矚目。但是,用Borland的工具能制作ActiveX組件的, 只有Delphi 3.0和C++ Builder。Borland把Delphi的ActiveX開發功能,叫作Active Inside。它是將任意的Delphi Window做成ActiveX的形式。Active Inside備有配備在Web上的新控件。Delphi可以將控件鏈接到COM和DCOM。
PowerBuilder 5.0是改造成能用於ActiveX開發的、客戶機/服務器開發工具。 PowerBuilder可以將Data Window(PowerBuilder應用開發的核心部分)作為ActiveX控件來配備。以使現在的PowerBuilder開發者,能使用 PowerScript編程語言等某些熟悉的功能。具有制作ActivX控件最好工具的,當屬Microsoft。例如,若用Visual Basic 5.0,開發者就可使用可視化編程環境和本機的Visual Basic for Application語言,來開發控件。
五、ActiveX
的未來的確,Windows和Windows NT的世界,是ActiveX技術的最佳環境。但無論Microsoft如何賣力推進它的OS,也不能使所有的企業都變成清壹色的Windows。因此, Microsoft要設法使COM、DCOM以及ActiveX家族的壹部分,也能在其他OS上使用。現在,在Macintosh中,已經支持 ActiveX,其中也包含對ActiveX控件的支持。Software AG正在把這些技術移植到多個Unix和IBM的OS/390上。DEC和HP也打算將這些技術在自己的系統上使用,他們也是用移植Microsoft代碼的辦法來實現的。
COM已成為Windows 95和Windows NT環境下基礎軟件的重要部分,但它的未來還有許多不確定的因素。例如,Microsoft是否能將COM作為多平臺技術,讓其繼續存在發展下去?為了使 NT服務器能適合已有的企業,就必須要使DCOM等分布式服務也能在非Microsoft平臺上應用。要解決這些問題, 需花費相當長的壹段時間。另外, 基於CORBA的產品和Java的RMI,已成功地運行在多OS環境下。多平臺DCOM出臺得越晚,CORBA和RMI就領先越多。ActiveX控件和 JavaBeans的競爭前景如何?無論使軟件運行在Web瀏覽器上也好,還是在另外的地方運行也好,總之,組件式軟件(ComponentWare)將是下壹個軟件開發的熱點。