1、 web服务器多框架解决方案 【摘要】在intranet上设计基于web的mis时，大批量数据录入弄成了操作上的困局，并给web server与database造极大的负担。为解决这个问题，我们设计了多框架结构，将应用的功能进行细分，然后交给各框架分别完成，这种分工协作方法可以使操作界面上的数据实现受控的部份刷新，有效地降低了网路的数据传输量，缩短了各部份的处理时间，同时了也大大减少了web server与database的系统负担。多框架解决方案采用asp（activex server pages）及ado(activex data objects)完成与数据库的交互工作。采用dom技术解决
2、和框架之间的协作问题。关键词：多框架*注：本文中讨论的方案中web服务器为iis4.0、客户端浏览器为ie4.0以上版本。一、问题的提出最初，我们采用asp及ado技术在intranet上设计基于web的mis（下文简称mis）时，沿用了往年设计web站点时的设计习惯。但随着设计的深入，我们发觉，现有的系统结构难以承当大批量的数据录入工作，因此，必须重新构造系统的总体设计结构。mis与普通的web站点之间最大的区别在于处理信息的方法。普通web站点的主要功能是发布信息，采集信息只是它极小的一部分功能，而且这种信息采集功能也都是比较简单的。但对于mis系统来说，信息的采集及维护工作占有比较高的比
3、例，在这种信息采集功能中还存在一些较为复杂及大批量的数据录入功能，这些功能成为了系统中的设计难点。二、问题的剖析当一个系统涉及到复杂及大批量的数据录入功能时，同时也就涉及到了响应速率及界面的问题。在往年的c/s形式中，客户端的录入速率由录入员来控制，一般情况下，当录入员熟悉了操作方法以后，录入速率是不受系统限制的。但在web方法下，页面采用完全刷新方法，每次的交互操作起码要引起一个页面的刷新。这种刷新的工作除了更新了数据，也将界面上的一些固定内容重新加载了一遍。对于普通用户来说，这种短时间的刷新并不会导致影响；但对于长时间进行操作的录入员来说，录入一条数据就要等待一段时间（这一段时间可能是2-
4、3秒，也可能是十几秒甚至几分钟），是绝对不能接受的。即使，网络有足够的带宽，页面的重载也会导致一种闪烁的疗效，这种一闪一闪的刷新导致录入员必须重新辨识页面上的各类元素，不仅也会拖慢了她们的录入速率，还导致右眼的快速疲劳。三、解决方案假如才能“不”刷新页面而“快速更新”页面中的数据，问题应当才能解决了。而且页面因为没有刷新，一些必须由服务器保存的状态信息也才能在客户端保存出来了，从而减少服务器的负担。那么怎样达到这个目标呢？下面将详尽讨论。1设计思路首先，我们确立采用多框架构建页面。框架(frames)其实不是哪些新东西，许多站点上都用它来完成显示固定标题及菜单的功能。采用框架才能防止一些页面的
5、重复访问。但是假如结合使用dom（document objects model)，框架可以完成许多细致的工作。按照dom的定义，框架可以被当成一个对象。假设我们构建了一个框架，并给它起名为a，则对于构建框架的页面来说，a是frames集合中的一个成员，而对于a中的页面来说，a相当于window对象。因些，虽然框架之间不存在从属关系，但可以通过它们的父页面（对象）建立各框架之间的关系。如右图所示：框架之间才能进行互相控制与数据传送。1）在框架a中用的是最常用的框架控制方法，利用a target“b” href=”url” 控制b框架中的页面重载。2）在框架b中，通过按键的点击风波对框架c进行控制
6、，这里的控制是通过dom来实现的。(假设b中按键name值为“b1”)控制c中的url，在按键的onclick风波中加入以下代码：(vbscript)sub b1_onclickset bframe = parent.bbframe.location.href = “url”end sub控制c中的文本框内容，在按键的onclick风波中加入以下代码：(vbscript)sub b1_onclickset bframe = parent.bbrame.document.all.txt1.value = “刘念”txt1是c框架中文本框的value值end sub2新的框架结构如上图，我们定义了
7、一个新的框架结构。在新的框架结构中，除了拿来放置一、二级菜单的menu1、menu2和拿来放置五级菜单及具体应用功能的aapp之外，还降低了三个专门拿来处理数据的框架（在上图中用实线表示）。这三个框架不需要界面，在应用执行的时侯是看不见的。12三个数据处理框架的与aapp框架分工合作，完成具体的功能。aapp 针对具体功能的界面和专用控制脚本bfun 客户端公用函数和全局变量cbuf 数据集合储存缓冲区dcom 服务器端命令执行结果储存缓区在系统中，根据生存周期按bfunaappcbufdcom的次序从大到小储存变量和数据对象。具体约定如下：bfun 系统级全局变量。如：用户的登入信息和操作记
8、录。aapp 功能级全局变量。如：步骤状态参数、功能常数。cbuf 如果一个功能在操作上存在多个步骤，在其中不确定的连续几个步骤中会用到的公共数据就保存在这个框架中，如一个缓冲表。dcom 针对cbuf，此框架只保存在多个步骤中的一步里须要用到的数据。如：函数估算结果。cbuf及dcom框架中保存的数据主要从服务器上取得。3程序流程说明在一个具体的功能中，aapp对整个程序流程进行控制。aapp通过对象关系取得bfun中的变量值或调用bfun中的函数。而cbuf及dcom中会包含一个完整的服务器端处理流程，aapp在适当的时侯将业务流程控制权交给cbuf或dcom，cbuf或dcom在流程执行
9、完成以后必须将流程控制权还给aapp。由于利用了dom中对象的方式与触发风波,aapp中可以实现部份数据更新,就象一个c/s中的客户端程序。如上图，cbuf与dcom负担了与web server及database的数据交换工作，使aapp在第一次被放入后就只须要在客户端浏览器中运行。这样，aapp中的主要界面就不需要进行刷新，避免了页面刷新时导致的延后和闪动问题。而cbuf与dcom中可以只按照约定格式返回数据和一个风波触发脚本，数据传输量可以按照须要降到最小，又由于cbuf与dcom没有可视界，因此在浏览器中的加载速率也是最快的。另外，bfun中保存了大部分的函数和变量，即使aapp的页面需
10、要重载，也只须要重载该页面专用的一部分内容。4数据储存格式约定将数据写入aapp界面中的形式有两种：一种是在cbuf与dcom订制脚本将数据讲到aapp中；另一种则是由aapp中的脚本读取cbuf与dcom中的数据再写到自已的界面上。两种方式最终都要保证aapp取得程序流程控制权。当从服务器上取到的数据比较少时（比如出错提出示信息），前一种方式是可行的。但当从服务器拿回的是一个数据集合（比如多行的记录集）时，前一种方式会导致控制脚本太长的问题，而且灵活性也不如后一种方式。而且依照各框架的分工，数据的控制功能应当由aapp去完成。因此后一种方式是数据控制的主要方式，但采用后一种方式必须在cbuf
11、与dcom中定义一个数据格式。在数据量少的时侯，可以用变量保存数据，变量名可以在递交url时定义，也可以使用默认变量名。两种定义方法性能差距不大，具体采用那一种可以按照个人喜好而定。在数据量比较大时，最常见的情况是在服务器上拿回了一个若干行的记录集。这时可以采用表格保存数据。具体格式如下：假设在递交asp文件的url时定义的表格对象名为rstest，则会返回两个表格对象rstest和rsteststru。rsteststru拿来储存记录集的列属性数据。这个表由固定的五列组成：1id 列顺序号2name 名称3type 数据类型4length 长度5prec 小数位rstest拿来储存记录集的各
12、行数据。在dom中，表格对象的行和列都有属于相应的对象集合。通过指定行和列的序号就能很确切的定位到任何一个数据元素，再结合innertext属性便可以取出想要的数据。但dom并没有给出对表格元素进行排序及查找的方式，因此我们必须自己编撰这方面的函数脚本。对于实际的web-mis，还要考虑asp及数据库方面的程序优化问题；一些额外的功能，如复印控制等，仍须要利用activex或java applet来实现，这里不作讨论。四、应用实例本方案在“深圳市自来水公司管理信息系统（sw-mis）”的“抄表收费分系统”中获得了应用，“抄表数据录入”功能在采用本方案进行优化后，在50个并发用户的测试中达到了不多于10条/（用户*分钟）的录入速率。而且web server与sql server的cpu占用率就能一直保持在10%左右。12-全文完-
