EEPW论坛

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上。

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控件。最常用的有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语言,来开发控件。

的未来的确,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)将是下一个软件开发的热点。