VEX去中心化交易平台

Ⅰ AtciveX是什麼做什麼用

ActiveX
一、ActiveX的由來
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服務以Inter net信息伺服器為中心進行構築，它為伺服器上的Web應用開發，提供腳本生成(Scripting )機構。網路服務以DCOM為中心進行構築，通過以同步MS-RPC為中介的網路，使之能夠連接控制項。
Active Client是一種交叉平台。Microsoft的技術縱然是獨家所有，但也希望將這種技術向多個OS開放。具體實施計劃是使用腳本引擎(Scripting Engine)。這種腳本引擎是由標準的HTML和帶有Microsoft特色的Java虛擬機(JVM)、Microsoft的VBScript與JSc ript所構成的。Active Client組裝進了Microsoft的IE 3.0和4.0，通過ActiveX，可以變成用戶的C/S應用的一部分。
從清一色採用Windows的企業用戶來看，Active平台可以提供堅固的、具有可縮放性的伺服器應用開發平台。ActiveServer在TP監視器這類高端產品的場合，也利用常見的一些工具和技術。因此，小型工作組和Intranet應用不會超越Active Server的能力。Acti ve平台的目標機雖是異種機環境，但由於過分依賴IE，所以不能驅動客戶端。盡管在一些非Windows平台上也推出了Explorer，但最好的支持、最新版本的Explorer還是在Window 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要追加對Acti ve Directory的支持。Active Directory是基於域名服務和輕型目錄訪問協議的。
DCOM的勁敵，此前一直是OMG(Object Management Group)的CORBA(Common Object R equest Broker Architecture)。它被組裝進了Iona的Orbix和Visigenic的VisiBroker等產品中。不久前，另一種支持分散對象的技術——Java的遠程方法調用出台了。無論是C ORBA，還是DCOM，都能在多種語言寫的對象間進行通信。而RMI卻不同，它只限於在由Java 實現的對象間進行通信。顯然，這是個制約。但RMI使用起來非常簡單。另外，RMI的開發者可以用Java來設計協議規范。因此，在語言的功能上，可以做得渾然一體。
若寫一個只處理兩三個客戶端的DCOM伺服器，還是比較簡單的。但是，要構築一個高效處理幾百、幾千個客戶端的DCOM伺服器，則相當之難。
為了便於編寫可縮放的DCOM伺服器，Microsoft發布了事務處理伺服器(MTS)。MTS在支持事務處理的同時，也提供自動生成線索和智能對象的重復使用等服務。MTS使可縮放伺服器的製作變得相當簡單。即使是無需事務處理的應用，使用MTS也有好處。實際上，M icrosoft鼓勵人們用VB來寫MTS應用。這與開發業務伺服器的傳統手法不同，所有的MTS應用，都是作為一個以上的COM對象來編寫，且必須以DLL來實現。一般情況下，客戶端看不到 MTS。客戶端只管一如既往地製作、使用COM對象即可。
2.組件的標准化
基於組件的應用開發，其方法和組裝電子裝置一樣，可以用已製作好的組件部件來構築應用。桌面用的、基於COM的組件叫做ActiveX控制項。所謂ActiveX控制項不過是遵從一定的標准、與客戶端交互的COM對象而已。
例如，ActiveX控制項必須通過Automation (即使用dispinterfaces)來公開方法。用這個被標准化的交互功能，可以在多個不同的上下文中，使用同一個控制項。在這個標准介面的"幕後"，ActiveX控制項幾乎是什麼都能執行。現在，許多軟體公司都能提供實現各種功能的控制項。
ActiveX控制項是作為DDL編寫的，為此，必須裝載到某個容器中。ActiveX控制項的原型容器是VB，除此之外，還有多種容器可供選擇。目前，一個非常重要的控制項容器是Microsoft 的Web瀏覽器
現在所謂ActiveX控制項的那些內容，是實現許多方法所必須的。已經把它們從機器的本地硬碟移到了VB等容器中。幾百KB和幾MB的控制項，似乎沒有什麼大區別。但要將控制項裝載到Web瀏覽器時，很可能要通過速度很慢的電話線。現在，控制項的大小已經是非常關鍵的問題。一旦要執行超過了某個限度以上的控制項，就會延長下載時間。因此，Microsoft規定 :在ActiveX控制項中，只能執行絕對必要的功能。
Apple和IBM推行的OpenDoc，曾是ActiveX控制項的主要競爭對手。現在OpenDoc的贊助企業，已正式宣告中止資助。大部分與Microsoft對抗的企業，轉而支持JavaBeans(基於J ava的組件結構)。ActiveX控制項，基本上都是和Windows捆綁在一起、以二進制機器代碼發放的，而JavaBeans卻不同，它在哪兒都能執行。這當然是有代價的。顯而易見，只要不犧牲可移植性，就不可能完全、徹底地利用本地環境。要編寫從公共Internet上能下載的組件時，應優先選擇JavaBeans。
桌面組件市場在持續、急速增長。其中絕大部分是以ActiveX控制項構築的(目前Java Beans仍然是少數)。但伺服器組件的標准化要落後一些。在桌面上，Web瀏覽器、VB以及 PowerBuilder這些編程環境，作為容器是強有力的。但伺服器容器又該當如何呢?作為伺服器上的組件容器，事務處理伺服器是一個較好的選擇。
Microsoft的競爭對手，千方百計要阻止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 (Microsoft Foundation Class，Microsoft 基礎類)，②ATL(ActiveX Template Library，ActiveX模板庫)，③BaseCtrl Framework等。MFC最經典，採用MFC，可以使開發者不去關心介面，而是集中精力關注對象的動作。缺點是控制項的規模較大且執行時DLL必須與容器同時存在。ATL可利用模板生成代碼。就是說 ，庫和DLL無需與控制項一起推出。在ATL中，需要從作為模板存在的幾個基本類派生類。AT L也有缺點，即介面的處理較難，應用中必要的介面，必須分別製作。另外，ATL不支持類向導(Class Wizard)。遺憾的是，沒有使對象描述語言(Object Description Language)和介面定義語言文件、與用戶代碼自動同步的向導。BaseCtrl是個簡便型庫。與ATL非常相似，但無模板。實際上，由於BaseCtrl過於簡便，Microsoft並不支持它。在BaseCtrl中，帶有幾個萬能控制項(Skeleton Control)。BaseCtrl提供容易理解的ActiveX開發模型，但與 ATL相比並不簡單，且靈活性也不及ATL。目前看來，對於ActiveX控制項開發者來說，BaseCt rl是個"苦澀"的選擇。
2. 開發工具
可製作ActiveX控制項的、最初的工具是Microsoft的Visual C++。它可為ActiveX開發者提供最多的控制項。Visual J++也可以製作ActiveX控制項。
Borland推出的兩個工具(JBuilder和IntraBuilder)也非常令人矚目。但是，用Borl and的工具能製作ActiveX組件的，只有Delphi 3.0和C++ Builder。Borland把Delphi的A ctiveX開發功能，叫作Active Inside。它是將任意的Delphi Window做成ActiveX的形式。Active Inside備有配備在Web上的新控制項。Delphi可以將控制項鏈接到COM和DCOM。
PowerBuilder 5.0是改造成能用於ActiveX開發的、客戶機/伺服器開發工具。Powe rBuilder可以將Data Window(PowerBuilder應用開發的核心部分)作為ActiveX控制項來配備。以使現在的PowerBuilder開發者，能使用PowerScript編程語言等某些熟悉的功能。
具有製作ActivX控制項最好工具的，當屬Microsoft。例如，若用Visual Basic 5.0，開發者就可使用可視化編程環境和本機的Visual Basic for Application語言，來開發控制項。
五、ActiveX
的未來的確，Windows和Windows NT的世界，是ActiveX技術的最佳環境。但無論Micr osoft如何賣力推進它的OS，也不能使所有的企業都變成清一色的Windows。因此，Micros oft要設法使COM、DCOM以及ActiveX家族的一部分，也能在其他OS上使用。現在，在Macin tosh中，已經支持ActiveX，其中也包含對ActiveX控制項的支持。Software AG正在把這些技術移植到多個Unix和IBM的OS/390上。DEC和HP也打算將這些技術在自己的系統上使用，他們也是用移植Microsoft代碼的辦法來實現的。
COM已成為Windows 95和Windows NT環境下基礎軟體的重要部分，但它的未來還有許多不確定的因素。例如，Microsoft是否能將COM作為多平台技術，讓其繼續存在發展下去 ?為了使NT伺服器能適合已有的企業，就必須要使DCOM等分布式服務也能在非Microsoft平台上應用。要解決這些問題， 需花費相當長的一段時間。另外， 基於CORBA的產品和Jav a的RMI，已成功地運行在多OS環境下。多平台DCOM出台得越晚，CORBA和RMI就領先越多。
ActiveX控制項和JavaBeans的競爭前景如何?無論使軟體運行在Web瀏覽器上也好，還是在另外的地方運行也好，總之，組件式軟體(ComponentWare)將是下一個軟體開發的熱點。目前，ActiveX控制項雖然暫居領先，但由於OpenDoc的自生自滅，與Microsoft競爭的企業會結為一體與之抗衡。用戶決不希望看到"一統天下"，僅就這點而言，JavaBeans也會在這一市場競爭中搶佔一席之地。