DCS控制软件的新结构
关键字:DCS控制软件的新结构
随着计算机的普及发展,企业网(Intranet)和国际互联网(Internet)的商业化,Microsoft Windows受欢迎的程度与日俱增,这大大增加了工业控制领域对Windows开发的普遍要求。
当今的集散控制系统(DCS)环境下的控制系统软件(或应用程序)与一般环境下的应用程序相比:一方面其功能已经发生了质的变化。比如,DCS网络下的控制系统软件能够调用、执行DCS网络中其它计算机上的一个程序,并与之交互,这是其它环境下的应用程序无法实现的;另一方面,DCS网络系统将整个系统的任务分散进行,然后集中监视、操作、管理,这些应用程序由于工作于网络环境下,因而分布极广,已被配置在网络中10台、100台、1000台甚至更多台的机器上运行,如果这些应用程序不够健壮、没有灵活的可伸缩性,将给日后的维护、升级、重新配置带来极大的困难,至少要消耗大量人力、财力和物力。而这种维护、升级、重新配置随着市场的发展,用户需求的扩大是不可避免的。为了解决这一问题,微软在对Windows系统本身进行改进、升级的同时,对Windows应用程序的标准、结构等也进行了重新定义,这就是:遵循组件对象模型(COM)/分布式组件对象模型(DCOM)标准、通过ActiveX实现的客户机/服务器结构。
客户机/服务器结构的主要思想是:根据COM/DCOM标准,将应用程序分割成若干个相互独立的逻辑单元,每个逻辑单元为应用程序提供一定的服务(以后就会明白这些逻辑单元被称为ActiveX组件),通过ActiveX把这些逻辑单元有机地结合起来,使它们协同工作,完成特定的任务。应用程序是ActiveX组件对象的集合,这些ActiveX组件对象知道怎样相互通信、相互调用,以实现应用程序要求的功能。
针对Intranet下控制系统的特殊情况,微软给出了一个三层的服务系统模型:用户逻辑(或用户服务)、商业逻辑(或商业服务)和数据逻辑(或数据服务)。用户服务提供用户可交互的或显示对数据进行查询、处理结果的屏幕界面等,由于Windows应用程序的屏幕界面已经标准化,所以用户服务相对来说变化不会太大,将它作为一个独立的逻辑单元,可被多个应用程序使用,从而实现了代码的重用;商业服务提供用户处理数据的各种规则,这些规则根据不同的用户有所不同,即使同一用户不同时期也可能不同。将它作为一个独立的逻辑单元并统一放在网络服务器中,有利于应用程序的日后维护。如果以后这些规则需要改变,只须重新配置网络服务器中的商业服务,而不需要重新编译客户机的应用程序;数据服务为用户提供各种数据,它是用户的数据源。实际中,这些数据源可能是Oracle、SQL Server、FoxPro、Access以及其它集散控制系统中的数据库(如:Fix系统)等等。
1、组件对象模型(COM)与分布式组件对象模型(DCOM)
多年来,软件工程师们一直在尝试编写可迅速嵌入各程序开发项目的可重用代码--软件组件(或简称为组件)。就像硬件工程师们先设计和制造出可用于各种电子设备的元件,然后利用它们组装成设备一样,控制系统软件开发者可以利用软件组件去组装自己的程序块,且很放心地知道这些组件是无故障的。这些组件不使用全局变量,并且独立于任何应用程序。
组件对象模型(Component Object Model---COM)就是软件组件采用的一种常规结构。它根据面向对象编程(Object Oriented Programming---OOP)的思想,将组件对象化,给出了面向对象软件组件(或简称为对象组件)的标准。
COM首次是在对象链接与嵌入(Object Linking and Embedding---OLE)2.0版中引入的,它是一种标准,而非一种实现。COM解释了组件之间该如何通信,但为了具体实现它,还需要用到另一个东西,即ActiveX。
在设计COM的过程中,微软解决了下列问题:
(1)交互操作能力。开发者怎样才能创建出独立的组件,使其能与其它组件充分地协作,而不用考虑它们是由谁创建的?(2)版本控制。一旦某个组件正由其他组件或应用程序使用,怎样才能改变或升级这个组件,而不影响正在使用它的组件或应用程序?(3)与语言无关。怎样才能确保用不同语言编写的组件能协同工作?(4)透明的跨进程交互操作。开发者怎样才能编写组件,使其能在进程内或进程外工作?
然而,OLE2中的COM只解决了同一网络中对象之间的交互问题,而没有解决对象在不同网络中的其它机器上生存或执行的问题,对这一问题的解决将打开通向在Windows环境下的分布对象结构之路。为了适应这一需要,微软开发出了分布式组件对象模型。
分布式组件对象模型(Distributed Component Object Model---DCOM),即通常所说的"网络OLE"。DCOM是一种特殊的协议,允许应用程序在分布式计算环境(Distributed Calculating Environment---DCE)里进行面向对象的远程过程调用(Remote Procedure Call---RPC)。DCOM扩展了COM的性能,使得COM对象能够通过相关网络与远程机中的另一个对象交互并使用此对象,这些网络可以是局部网、企业的Intranet或现今的Internet。用户可以在Windows NT4.0版中得到DCOM,它特别适用于开发企业的信息管理系统、专用的Web等。基于网络方面的不安全性考虑,DCOM自身包含有较高的安全处理功能。
所有软件组件都遵循COM或DCOM标准。
2、ActiveX
根据微软的定义:支持组件对象模型(COM)的对象总称为"组件对象"。而现在流行的术语OLE--即OLE2,支持COM,所以OLE对象也称为"组件对象"。一个组件对象不仅支持"对象链接与嵌入",而且还可以远程调用或运行其它机器或网络中的组件对象等等,它的功能已远远超过了OLE字面所能表达的功能。为了适合未来更加复杂的应用,微软决定重新命名它,将所有这些组件对象统称为ActiveX。
随着OOP逐渐成为公认的编程主流,面向对象软件组件已成为事实上的标准。面向对象软件组件统称为ActiveX组件。经过一番扩展以后,ActiveX组件现在可提供对DCOM的支持。
ActiveX是组件对象模型的一种物理实现方式,它为ActiveX组件的创建提供了基础。
ActiveX组件将程序逻辑封装起来,并可以进程内、本地进程外、远程进程外三种形式之一在网络中运行,为其它应用程序(客户机应用程序)提供服务。因此可以将ActiveX组件理解成"服务器"。它要么在"进程内"工作,即代码在与客户机应用程序相同的进程空间内执行(亦即一个DLL--ActiveX DLL);要么在"进程外"工作,即代码在同一机器的另一个进程内运行,或在远程电脑的另一个进程内执行(亦即一个EXE文件--ActiveX EXE)。
利用Visual Basic 5.0,Visual C++5.0或Visual J++等OOP语言,可以很方便地创建ActiveX DLL(进程内服务器)和ActiveX EXE(本地或远程进程外服务器)。
控制系统软件开发者可以将自己的应用程序逻辑编写成进程内ActiveX DLL或本地进程外ActiveX EXE或远程进程外ActiveX EXE,以向其他ActiveX组件或外部应用程序开放它们的部分或全部对象。
建立和使用ActiveX EXE实例的客户应用程序,可开放它们的对象,并在进程外使用它们。这意味着,ActiveX EXE中的代码运行在它自己的进程中,并且是在它自己的空间中,这可把它与客户应用程序的代码空间分离开来。
ActiveX DLL不能作为一个应用程序单独运行,但可以为应用程序提供对象的动态链接库。由于DLL中的代码与调用它的应用程序运行于同一进程中,所以能使程序执行得更快、更高效。
控制系统软件开发者可以利用ActiveX组件组装自己的应用程序。使用ActiveX组件的方法与在OOP中使用其它对象类似:
(1)创建一个你欲使用的ActiveX组件对象的实例;(2)利用该对象的方法、属性和事件编写代码;(3)使用完毕释放该对象;(4)必要时进行错误处理。
下面是Visual Basic 5.0中一个说明怎样在程序中利用ActiveX组件的VB程序片段。假设已建立了一个窗体,该窗体包含三个文本框(Text1、Text2和Text3)和一个命令按钮(Command1),并且在进程中增加了对微软Excel 8.0对象库的引用。当单击命令按钮(Command1)时,在Command1_Click事件过程中按照Microsoft Excel公式计算Text1与Text2的和,并将相加的结果显示在Text3中。程序如下:
Private Sub Command1_Click()
’说明对象变量
Dim xlApp As Excel. Application
Dim xlBook As Excel. Workbook
Dim xlSheet As Excel. Worksheet
’用Add方法创建对象的实例
Set xlApp = New Excel. Application
Set xlBook = xlApp. Workbooks.Add
Set xlSheet = xlBook. Worksheets.Add
’将文本框中的数据赋给Excel单元
xlSheet. Cells(1,1).Value = Text1. Text
xlSheet. Cells(2,1).Value = Text2. Text
’在Excel中,用Excel公式计算其和
xlSheet. Cells(3,1). Formula = " = R1C1 + R2C1"
’在Text3文本框中显示结果
Text3. Text = xlSheet. Cells(3,1)
’保存工作表单
xlSheet. SaveAs" c:\Test.xls"
’关闭Excel
xlApp. Quit
’释放对象
Set xlApp = Nothing
Set xlBook = Nothing
Set xlSheet = Nothing
End Sub
为简单起见,程序中没有进行错误检查。用户在编程时应养成检查错误、处理错误的习惯。
由以上程序可以看出,其编程方法完全是OOP的方法。这并不奇怪,因为ActiveX组件本身就意味着对象之间的共享,ActiveX组件是一种客户机/服务器关系,在这种关系中客户机请求对象,服务器提供对象。然而,具体一个ActiveX组件是客户机还是服务器并没有一个明显的界限。前面我们说可以把ActiveX组件理解成是一个服务器,因为它为用户程序(客户应用程序)提供服务;然而在其它场合,ActiveX组件本身往往还要向其它ActiveX组件请求服务,这时它又担当客户机的角色。
不管怎样,利用ActiveX组件组装成的应用程序,其结构必然是客户机/服务器结构,客户机/服务结构是网络发展的必然结果。
3、客户机/服务器结构
综观计算机网络系统结构的发展,大致可分为三个阶段:集中式结构、文件服务器结构以及客户机/服务器结构。这三个阶段代表了计算机网络系统结构发展的里程和趋势。
在六、七十年代,如果一家公司需要真正的计算能务(比如,天气预报、地震预报数据处理等等)便会考虑使用大型机,大型机代表一种集中式系统结构。
在集中式结构中,只有两种关键组件:服务器和客户机终端。客户机与服务器之间传输的唯一数据是用户的按键调度信息以及由服务器返回的终端字符。集中式结构伯优点包括出色的安全性以及可实现集中管理,这是因为无论应用程序逻辑还是数据都驻留于同一台机器--服务器上;同时也意昧着服务器的费用太高,因为它要完成网络中所有的计算。由于应用程序逻辑和数据都驻留于服务器上,集中式结构没有办法真正划分应用程序逻辑。
在本世纪80年代,PC机进入了商业舞台并逐渐走入千家万户。不久,局域网问世,同时引入了文件服务器的崭新概念。
文件服务器结构以DOS局域网和Windows3.X为代表。它使得廉价的PC机联成网络,共享资源。这对于那些根本没有实力实现大型机方案的公司来说,PC机无疑是他们的救星。但是,在这种结构中,应用程序逻辑总是在客户工作站上执行,使用的是客户机的CPU,而不是像集中式结构那样在服务器上执行。这意味着,客户机要有足够的计算能力,以便执行需要的任何应用程序,或能完成任何必要的任务。这无形中增加了客户机的负担,从而抵消了PC机价格低廉的优点。
为了折中考虑费用与性能问题,引入了客户机/服务器结构。在这种结构中,允许应用程序逻辑在用户工作站、服务器(不再称为"文件服务器")或者两者上运行。SQL Server、Oracle等是客户机/服务器结构的代表。
在客户机/服务器结构中,同时至少有两个独立的应用程序在运行:一个是客户应用程序(简称为客户);另一个是服务器应用程序(简称为服务器)。客户提出请求,服务器响应请求并为其服务。为了完成一项特定的任务,客户和服务器协同工作,以提高运行速度和效率。例如,在网络环境中,用户在客户端发出SQL命令查询服务器上某数据库中的数据,在文件服务器和客户机/服务器这两种结构中,该命令的执行情况是不一样的。如果读者不能区分它们之间的差别,就不可能充分利用客户机/服务器结构为我们提供的强大功能。
事实上,在基于文件服务器的结构中,查询是在客户端赋值并执行的。这就意味着,如果查询涉及的表中有10000条记录,那么查询逻辑会请求服务器通过网络将包含这10000条记录的表全部传送到自己这儿(客户端),在客户端进行查询处理。而在基于客户机/服务器原结构里,SQL语句本身将通过网络传送并在服务器内执行,服务器使用自己的CPU处理完SQL语句后,只把处理结果(成功或失败)通过网络反馈回客户端。显然,这大大减轻了网络的负载,同时也缩短了执行时间。这是对基于文件服务器结构性能的一个重要改进。
综上所述,大型机和基于文件服务器的系统由于应用程序逻辑必须在大型机内运行(针对集中式结构)或必须在客户机内执行(针对文件服务器结构),所以不能提供一个真正可伸缩的系统框架。而客户机/服务器系统至少由两部分组成:一台发出请求的客户机,一台为请求服务的服务器。这两个部分协同工作,应用程序逻辑则分布于客户和服务器之间。这样一来,就为开发运行更快、更高效的应用程序提供了基础。
Intranet和Internet为客户机/服务器结构提供了极好的机遇。当今的Web技术就是一个典型的客户机/服务器结构:浏览器是客户机,Web站点是服务器。
4、结束语
在DCS网络环境下运行的应用程序,应该是遵循COM/DCOM标准、通过ActiveX实现的客户机/服务器结构的应用程序。因为这样的应用程序是由ActiveX组件组装而成的,与其它应用程序结构相比更加健壮、可伸缩性强且容易维护。
另外,读者应注意:由于微软的重新命名,OLE文档已成为ActiveX文档;OLE控件已成为ActiveX控件;等等。从而OLE这一术语才真正像它早期缩写的含义那样,代表"对象链接与嵌入",而OLE中一些关键技术和组件则成为重新命名后的ActiveX技术和组件。
当今的集散控制系统(DCS)环境下的控制系统软件(或应用程序)与一般环境下的应用程序相比:一方面其功能已经发生了质的变化。比如,DCS网络下的控制系统软件能够调用、执行DCS网络中其它计算机上的一个程序,并与之交互,这是其它环境下的应用程序无法实现的;另一方面,DCS网络系统将整个系统的任务分散进行,然后集中监视、操作、管理,这些应用程序由于工作于网络环境下,因而分布极广,已被配置在网络中10台、100台、1000台甚至更多台的机器上运行,如果这些应用程序不够健壮、没有灵活的可伸缩性,将给日后的维护、升级、重新配置带来极大的困难,至少要消耗大量人力、财力和物力。而这种维护、升级、重新配置随着市场的发展,用户需求的扩大是不可避免的。为了解决这一问题,微软在对Windows系统本身进行改进、升级的同时,对Windows应用程序的标准、结构等也进行了重新定义,这就是:遵循组件对象模型(COM)/分布式组件对象模型(DCOM)标准、通过ActiveX实现的客户机/服务器结构。
客户机/服务器结构的主要思想是:根据COM/DCOM标准,将应用程序分割成若干个相互独立的逻辑单元,每个逻辑单元为应用程序提供一定的服务(以后就会明白这些逻辑单元被称为ActiveX组件),通过ActiveX把这些逻辑单元有机地结合起来,使它们协同工作,完成特定的任务。应用程序是ActiveX组件对象的集合,这些ActiveX组件对象知道怎样相互通信、相互调用,以实现应用程序要求的功能。
针对Intranet下控制系统的特殊情况,微软给出了一个三层的服务系统模型:用户逻辑(或用户服务)、商业逻辑(或商业服务)和数据逻辑(或数据服务)。用户服务提供用户可交互的或显示对数据进行查询、处理结果的屏幕界面等,由于Windows应用程序的屏幕界面已经标准化,所以用户服务相对来说变化不会太大,将它作为一个独立的逻辑单元,可被多个应用程序使用,从而实现了代码的重用;商业服务提供用户处理数据的各种规则,这些规则根据不同的用户有所不同,即使同一用户不同时期也可能不同。将它作为一个独立的逻辑单元并统一放在网络服务器中,有利于应用程序的日后维护。如果以后这些规则需要改变,只须重新配置网络服务器中的商业服务,而不需要重新编译客户机的应用程序;数据服务为用户提供各种数据,它是用户的数据源。实际中,这些数据源可能是Oracle、SQL Server、FoxPro、Access以及其它集散控制系统中的数据库(如:Fix系统)等等。
1、组件对象模型(COM)与分布式组件对象模型(DCOM)
多年来,软件工程师们一直在尝试编写可迅速嵌入各程序开发项目的可重用代码--软件组件(或简称为组件)。就像硬件工程师们先设计和制造出可用于各种电子设备的元件,然后利用它们组装成设备一样,控制系统软件开发者可以利用软件组件去组装自己的程序块,且很放心地知道这些组件是无故障的。这些组件不使用全局变量,并且独立于任何应用程序。
组件对象模型(Component Object Model---COM)就是软件组件采用的一种常规结构。它根据面向对象编程(Object Oriented Programming---OOP)的思想,将组件对象化,给出了面向对象软件组件(或简称为对象组件)的标准。
COM首次是在对象链接与嵌入(Object Linking and Embedding---OLE)2.0版中引入的,它是一种标准,而非一种实现。COM解释了组件之间该如何通信,但为了具体实现它,还需要用到另一个东西,即ActiveX。
在设计COM的过程中,微软解决了下列问题:
(1)交互操作能力。开发者怎样才能创建出独立的组件,使其能与其它组件充分地协作,而不用考虑它们是由谁创建的?(2)版本控制。一旦某个组件正由其他组件或应用程序使用,怎样才能改变或升级这个组件,而不影响正在使用它的组件或应用程序?(3)与语言无关。怎样才能确保用不同语言编写的组件能协同工作?(4)透明的跨进程交互操作。开发者怎样才能编写组件,使其能在进程内或进程外工作?
然而,OLE2中的COM只解决了同一网络中对象之间的交互问题,而没有解决对象在不同网络中的其它机器上生存或执行的问题,对这一问题的解决将打开通向在Windows环境下的分布对象结构之路。为了适应这一需要,微软开发出了分布式组件对象模型。
分布式组件对象模型(Distributed Component Object Model---DCOM),即通常所说的"网络OLE"。DCOM是一种特殊的协议,允许应用程序在分布式计算环境(Distributed Calculating Environment---DCE)里进行面向对象的远程过程调用(Remote Procedure Call---RPC)。DCOM扩展了COM的性能,使得COM对象能够通过相关网络与远程机中的另一个对象交互并使用此对象,这些网络可以是局部网、企业的Intranet或现今的Internet。用户可以在Windows NT4.0版中得到DCOM,它特别适用于开发企业的信息管理系统、专用的Web等。基于网络方面的不安全性考虑,DCOM自身包含有较高的安全处理功能。
所有软件组件都遵循COM或DCOM标准。
2、ActiveX
根据微软的定义:支持组件对象模型(COM)的对象总称为"组件对象"。而现在流行的术语OLE--即OLE2,支持COM,所以OLE对象也称为"组件对象"。一个组件对象不仅支持"对象链接与嵌入",而且还可以远程调用或运行其它机器或网络中的组件对象等等,它的功能已远远超过了OLE字面所能表达的功能。为了适合未来更加复杂的应用,微软决定重新命名它,将所有这些组件对象统称为ActiveX。
随着OOP逐渐成为公认的编程主流,面向对象软件组件已成为事实上的标准。面向对象软件组件统称为ActiveX组件。经过一番扩展以后,ActiveX组件现在可提供对DCOM的支持。
ActiveX是组件对象模型的一种物理实现方式,它为ActiveX组件的创建提供了基础。
ActiveX组件将程序逻辑封装起来,并可以进程内、本地进程外、远程进程外三种形式之一在网络中运行,为其它应用程序(客户机应用程序)提供服务。因此可以将ActiveX组件理解成"服务器"。它要么在"进程内"工作,即代码在与客户机应用程序相同的进程空间内执行(亦即一个DLL--ActiveX DLL);要么在"进程外"工作,即代码在同一机器的另一个进程内运行,或在远程电脑的另一个进程内执行(亦即一个EXE文件--ActiveX EXE)。
利用Visual Basic 5.0,Visual C++5.0或Visual J++等OOP语言,可以很方便地创建ActiveX DLL(进程内服务器)和ActiveX EXE(本地或远程进程外服务器)。
控制系统软件开发者可以将自己的应用程序逻辑编写成进程内ActiveX DLL或本地进程外ActiveX EXE或远程进程外ActiveX EXE,以向其他ActiveX组件或外部应用程序开放它们的部分或全部对象。
建立和使用ActiveX EXE实例的客户应用程序,可开放它们的对象,并在进程外使用它们。这意味着,ActiveX EXE中的代码运行在它自己的进程中,并且是在它自己的空间中,这可把它与客户应用程序的代码空间分离开来。
ActiveX DLL不能作为一个应用程序单独运行,但可以为应用程序提供对象的动态链接库。由于DLL中的代码与调用它的应用程序运行于同一进程中,所以能使程序执行得更快、更高效。
控制系统软件开发者可以利用ActiveX组件组装自己的应用程序。使用ActiveX组件的方法与在OOP中使用其它对象类似:
(1)创建一个你欲使用的ActiveX组件对象的实例;(2)利用该对象的方法、属性和事件编写代码;(3)使用完毕释放该对象;(4)必要时进行错误处理。
下面是Visual Basic 5.0中一个说明怎样在程序中利用ActiveX组件的VB程序片段。假设已建立了一个窗体,该窗体包含三个文本框(Text1、Text2和Text3)和一个命令按钮(Command1),并且在进程中增加了对微软Excel 8.0对象库的引用。当单击命令按钮(Command1)时,在Command1_Click事件过程中按照Microsoft Excel公式计算Text1与Text2的和,并将相加的结果显示在Text3中。程序如下:
Private Sub Command1_Click()
’说明对象变量
Dim xlApp As Excel. Application
Dim xlBook As Excel. Workbook
Dim xlSheet As Excel. Worksheet
’用Add方法创建对象的实例
Set xlApp = New Excel. Application
Set xlBook = xlApp. Workbooks.Add
Set xlSheet = xlBook. Worksheets.Add
’将文本框中的数据赋给Excel单元
xlSheet. Cells(1,1).Value = Text1. Text
xlSheet. Cells(2,1).Value = Text2. Text
’在Excel中,用Excel公式计算其和
xlSheet. Cells(3,1). Formula = " = R1C1 + R2C1"
’在Text3文本框中显示结果
Text3. Text = xlSheet. Cells(3,1)
’保存工作表单
xlSheet. SaveAs" c:\Test.xls"
’关闭Excel
xlApp. Quit
’释放对象
Set xlApp = Nothing
Set xlBook = Nothing
Set xlSheet = Nothing
End Sub
为简单起见,程序中没有进行错误检查。用户在编程时应养成检查错误、处理错误的习惯。
由以上程序可以看出,其编程方法完全是OOP的方法。这并不奇怪,因为ActiveX组件本身就意味着对象之间的共享,ActiveX组件是一种客户机/服务器关系,在这种关系中客户机请求对象,服务器提供对象。然而,具体一个ActiveX组件是客户机还是服务器并没有一个明显的界限。前面我们说可以把ActiveX组件理解成是一个服务器,因为它为用户程序(客户应用程序)提供服务;然而在其它场合,ActiveX组件本身往往还要向其它ActiveX组件请求服务,这时它又担当客户机的角色。
不管怎样,利用ActiveX组件组装成的应用程序,其结构必然是客户机/服务器结构,客户机/服务结构是网络发展的必然结果。
3、客户机/服务器结构
综观计算机网络系统结构的发展,大致可分为三个阶段:集中式结构、文件服务器结构以及客户机/服务器结构。这三个阶段代表了计算机网络系统结构发展的里程和趋势。
在六、七十年代,如果一家公司需要真正的计算能务(比如,天气预报、地震预报数据处理等等)便会考虑使用大型机,大型机代表一种集中式系统结构。
在集中式结构中,只有两种关键组件:服务器和客户机终端。客户机与服务器之间传输的唯一数据是用户的按键调度信息以及由服务器返回的终端字符。集中式结构伯优点包括出色的安全性以及可实现集中管理,这是因为无论应用程序逻辑还是数据都驻留于同一台机器--服务器上;同时也意昧着服务器的费用太高,因为它要完成网络中所有的计算。由于应用程序逻辑和数据都驻留于服务器上,集中式结构没有办法真正划分应用程序逻辑。
在本世纪80年代,PC机进入了商业舞台并逐渐走入千家万户。不久,局域网问世,同时引入了文件服务器的崭新概念。
文件服务器结构以DOS局域网和Windows3.X为代表。它使得廉价的PC机联成网络,共享资源。这对于那些根本没有实力实现大型机方案的公司来说,PC机无疑是他们的救星。但是,在这种结构中,应用程序逻辑总是在客户工作站上执行,使用的是客户机的CPU,而不是像集中式结构那样在服务器上执行。这意味着,客户机要有足够的计算能力,以便执行需要的任何应用程序,或能完成任何必要的任务。这无形中增加了客户机的负担,从而抵消了PC机价格低廉的优点。
为了折中考虑费用与性能问题,引入了客户机/服务器结构。在这种结构中,允许应用程序逻辑在用户工作站、服务器(不再称为"文件服务器")或者两者上运行。SQL Server、Oracle等是客户机/服务器结构的代表。
在客户机/服务器结构中,同时至少有两个独立的应用程序在运行:一个是客户应用程序(简称为客户);另一个是服务器应用程序(简称为服务器)。客户提出请求,服务器响应请求并为其服务。为了完成一项特定的任务,客户和服务器协同工作,以提高运行速度和效率。例如,在网络环境中,用户在客户端发出SQL命令查询服务器上某数据库中的数据,在文件服务器和客户机/服务器这两种结构中,该命令的执行情况是不一样的。如果读者不能区分它们之间的差别,就不可能充分利用客户机/服务器结构为我们提供的强大功能。
事实上,在基于文件服务器的结构中,查询是在客户端赋值并执行的。这就意味着,如果查询涉及的表中有10000条记录,那么查询逻辑会请求服务器通过网络将包含这10000条记录的表全部传送到自己这儿(客户端),在客户端进行查询处理。而在基于客户机/服务器原结构里,SQL语句本身将通过网络传送并在服务器内执行,服务器使用自己的CPU处理完SQL语句后,只把处理结果(成功或失败)通过网络反馈回客户端。显然,这大大减轻了网络的负载,同时也缩短了执行时间。这是对基于文件服务器结构性能的一个重要改进。
综上所述,大型机和基于文件服务器的系统由于应用程序逻辑必须在大型机内运行(针对集中式结构)或必须在客户机内执行(针对文件服务器结构),所以不能提供一个真正可伸缩的系统框架。而客户机/服务器系统至少由两部分组成:一台发出请求的客户机,一台为请求服务的服务器。这两个部分协同工作,应用程序逻辑则分布于客户和服务器之间。这样一来,就为开发运行更快、更高效的应用程序提供了基础。
Intranet和Internet为客户机/服务器结构提供了极好的机遇。当今的Web技术就是一个典型的客户机/服务器结构:浏览器是客户机,Web站点是服务器。
4、结束语
在DCS网络环境下运行的应用程序,应该是遵循COM/DCOM标准、通过ActiveX实现的客户机/服务器结构的应用程序。因为这样的应用程序是由ActiveX组件组装而成的,与其它应用程序结构相比更加健壮、可伸缩性强且容易维护。
另外,读者应注意:由于微软的重新命名,OLE文档已成为ActiveX文档;OLE控件已成为ActiveX控件;等等。从而OLE这一术语才真正像它早期缩写的含义那样,代表"对象链接与嵌入",而OLE中一些关键技术和组件则成为重新命名后的ActiveX技术和组件。
责任编辑:
[青岛机电网版权申明:除部分特别声明不要转载,或者授权我站独家播发的文章外,大家可以自由转载我站点的原创文章,但原作者和来自我站的链接必须保留(非我站原创的,按照原来自一节,自行链接)。文章版权归我站和作者共有。 转载要求:转载之图片、文件,链接请不要盗链到本站,且不准打上各自站点的水印,亦不能抹去我站点水印。 特别注意:本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有,文章若有侵犯作者版权,请与我们联系,我们将立即删除修改。]
