什么是AtciveX？做什么？
一、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也将在这场市场竞争中抢占一席之地。