改进Web 服务器性能的有关技术

[摘要]

一个大中型的图书馆信息系统涉及到许多方面的技术与方案，本文着重讨论与 Web 服务器性能有关的一些内容。

本人有幸作为项目负责人之一参与了某大型图书馆数字化信息系统的设计和基于 web 应用软件的开发工作。由于在数字化图书馆信息系统中流通着的大多是数字化的索引、文摘、全文、图像或音频视频等多媒体信息，对 web 服务器性能有着较高的要求

结合实际工程经验，本文将从硬件实现手段(缓存服务器、均衡负载设备、Web 双机镜像CPU和网卡的提升、网络带宽扩充)和软件实现手段(三层c/S 软件结构设计、应用程序部署)等两个大方面论述如何提高 web 服务大路的性能，以便使用户能够更快捷、高效、安全地使用应用系统

[正文]

随着 Intranet 信息技术的发展，图书馆为了更好地发挥其图书流通、资料检索和学术交流的职能，图书馆的数字信息化工程也势在必行。某图书馆为了尽快地步入世界先进图书馆的行列，已经启动了一部分的数字图书馆工程

该数字图书馆工程主要包括对外信息 Web 发布系统，交互式检索网，后台馆藏信息管理系统、多媒体资料采集制作以及外 VOD 点播系统等。本人有幸作为项目负责人之一，参与了整个数字化信息系统的总体设计，并参与了基于 eb 的一些应用(如对外信息发布系统、图像/全文混合系统、VOD 点播系统的)开发

某图书馆数字化信息系统从网络环境上讲，主要划分为多个网段:(一)Intranet 接入部分，采用 2M 的 DDN专线，(二)公共段(非军事区)，主要包括前台发布数据库服务器、Web服务器、E-mai1/FTP/DNS 服务器、检索服务器及 SAN 网络区域存储设备，(三)是内部局域网，包括内网 we 服务器、后台馆藏数据库服务器、0A 服务器等。(四)是 VOD 点播专用网，包括音频视频点播服务器等。由于制定了严格的网络级和应用级访问权限，通过具有三层交换能力的高性能交换机和安全授权认证系统等，有效地控制了访问权限，确保了数据的安全性和完整性。考虑到经费和人员素质及今后的维护管理运营等方面，操作系统采用 windowsNT 平台，服务器选用 DELL 高端的系列，数据库采用 IB的 DB2主干网为千兆快速交换式以太网局域网百兆到桌面，VOD 点播网十兆到桌面。

在该网络环境下应用主要分为三大部分:(一)对外 web 发布系统、对外图书辅助检索系统，(二)后台馆藏信息管理系统和图像/全文混合检索系统，(三)VOD 点播系统。由于绝大部分应用采用 Browser/Server 方式结构，最终用户在本地只需安装 或者 Netscape Web 浏览器，在后台数据库服务器的支持下通过网页方式请求和访间各类应用服务。另外，由于在图书馆信息系统中流通的多为索引、摘要、全文或音频视频等多媒体信息，对 web 服务器性能与网络带宽等有更高的要求。

通过不断地试验和实践，我们发现从以下几个方面可以相对有效地提升 web 服务器性能

(1)缓存服务器和均衡负载设备使用可以缓解访问瓶颈，提高网络带宽、实现均衡负载缓存服务器也称为 cache 服务器，可以存储 cache 静态的内容如网页、多媒体点播资源和会议实况(已压缩的、有一定格式要求的)等。此外，目前美国 cashflow 缓存服务器，已经可以存储 cache 数据库、ASP 等动态内容cache 服务器通常放到防火墙之外，外网 Web 服务器之前，因此 Inrternet 用户点击网页不再直接访问网站 Web 服务器，而是访间 cache 服务器。

由于 cache 服务器具有多个 CPU 和高速大容量 I/O 通道，独立的 OS，因此能大大缓解Internet 访问瓶颈，而且也具有一定的抗黑客攻击的能力

目前某图书馆采用这种方式，把大数据量的静态图片、点播资源、虚拟三维应用等都事先置放在 cache 服务器中，即使现今只有 2M internet 的接入带宽，以上应用的播放速度和效果仍能让用户满意。

另外一种方式采用均衡负载设备或 web 双机镜像这种方式通过负载均衡的方法达到 web访问性能最优。web 双机镜像是较早以前流行的方式，虽能使系统可靠性提升，但由于双机总是在互相询问对方状态，将会影响一定的访问性能。均衡负载设备是独立于 we 服务器的硬件，它和 web 服务器及网站中其他服务器接在同一交换机上，通过负载调度程序为各个服务器分配工作量，从而，能达到充分利用资源，提高访问性能的目的。只是由于某图书馆目前对外发布资源相对仍较少，只有用了三台 web 服务器，因此目前的均衡负载设备作用还不显著。

(2)从 Web 服务器的配置来看，web 服务器自身 CPU 个数及速度、网卡数量、Web 服务器与防火墙的位置关系等，都会影响到 web 服务器的性能。

从 web 服务器硬件本身来讲，CPU 个数的增加、网卡个数的增加、I/O 信道的扩展无疑可以直接地提高 web 服务器性能。此外，由于千兆口的防火墙目前较少且费用较高，如果把 Web服务器放置防火墙之后，一定会大大影响 Internet 访问性能某图书馆采用 IDS(入侵侦测)+web 服务器(服务器防火墙，较低端，不会影响流量)+应用服务器+数据库服务器(防火墙,高端)，分层次的安全模式，既保证了系统的安全模式，既保证了系统的安全性，又提升了网络访问性能。

另外，某图书馆还采用了 SAN 网络区域存储来提高服务器访问速度。

(3)三层c/s 软件结构设计和应用程序的适当部署也会提高 Web 服务器的性能。将业务逻辑、通用访问接口与数据等相互分离、分别置放于 web 服务器、应用服务、数据库服务器上，通过过程序功能和逻辑的合理部署，也能大大改进 web 服务器性能一般的原则是，Web服务器只需接受 Internet 的http 访问请求，使Web 只有最少的任务把实际处理交给各个应用服务器处理，然后返回结果给 Browser。某图书馆采用这种方式专门开发了搜索引擎应用服务器和混合检索应用服务器等，达到了良好的应用效果。事实上，web 服务器的性能提升还存在很多手段和方法，比如 CPU 与存储之间关系，Web交换机等等，有待于我们进一步的实践、分析和讨论

论改进Web 服务器性能的有关技术

[摘要]

基于 web 技术的数据库应用是当前应用的一个热点，在用户数目与通信负荷很大的场合提高 web 服务器性能是一个迫切的课题。本文从笔者参与某个银行系统项目开发的经历出发阐述了提高 web 服务器的性能应渗入到项目论证、选型、开发、运行和管理的各个环节，只有各个环节都能充分考虑到性能与质量的需要，系统的性能才是真正可保证的和可扩充的。文章从系统的实际运行与相应的经验出发，阐述了性能改进方面的一些具体措施。比如:在本文中讨论了 web 服务器平台的选型考虑;Web 服务器的配置管理，应用系统本身的优化与预先设计系统时可扩性的性能保障等具体内容通过技术上的分析与改进，综合性地运用多类措施与手段，在实际系统中，web 服务器运行的性能得到了一定程序的保证。

[正文]

我所在的单位是把目标定位于金融领域开发 IT 应用的一家信息技术公司随着金融电子化建设的发展和商业银行之间市场竞争的加剧，各主要商业银行不断通过信息技术提供新的金融产品，并且希望整合市场渠道。比如主要的商业银行不断推出形形色色的网上银行服务在这种背景下，本人参与了开发新一代网上银行产品，涉及提供网上个人理财服务、网上外汇买卖服务、网上企业服务等具有市场竞争力的产品。作为项目开发的组织者之一和主要的技术骨干，在整个项目开发过程中始终要处于第一线，从而在改进 Web 服务器性能、提高整个网上平台系统性能方面收获良多，在本文中简要讨论如下，希望与读者们共享经验。在 Web服务器配置与优化方面，我有如下几方面主要的体会:

第一方面是 Web 服务器选型考虑

在 Web 服务器选型及网上平台搭建这初，我们就已充公考虑整个网上平台的性能及可扩展性问题，这一考虑为该系统的稳定性及扩展性能力方面打下了坚实的基础。某银行原有的一些网上产品由于开发较早，故而采用的是老式的 HTTP Server + CGI程序调用的方式。这时，每一客户请求需要对应于后端系统的系统进程来运行CGI程序来处理系统的开销相当大，系统的扩展能力也很差，性能已不能满足业务处理的需要，故而在为此

银行系统具体选型的时候，我们一开始就否决了这种方案。通过市场上同类产品的比较选择，我们选择了国际商业机器有限公司 IBM的 Web Sphere产品系列作为该行网上银行系统的建立平台。作出这样选择是因为 Web Sphere 基于使HTTPServer 和应用服务器相分离的整体架构，同时支持JSP、Servlet和企业级JavaBean等轻量级线程规范，所有的请求对应于应用服务器上的处理线程，系统的开销低，效率非常高，同时 Web Sphere 整个体系结构相当的灵活，为适应扩展需要可以作不同的横向和纵向扩展，从而可以满足各银行未来的扩展需要。

正是因为在一开始选型的时候我们就已考虑到未来的扩展需要，整个系统在接下来的几次性能改进方面，我们大体上都能相对顺利地达到了预期目标。

第二方面是 web 服务器的性能配置。

在一开始系统上线的时候，由于系统的负荷不是很大，为了节省系统总拥有成本 TCO 投资，我们在一台较低配置的 IBM RS6000 上投产了该系统。整个系统的 HTTP 服务器、应用服务器、通信服务器等均位于该台机器上，由于初始投产时用户不多，所以系统的性能基本上能令人接受但随着业务的发展和用户访问量的增大，我们发现该服务器的响应变慢，系统的 CPU 利用率和内外存交换显著增大。经过跟踪，我们发现关键原因之一是系统的内存不足的缘故。由于网上服务器把大量用户的会话信息保存在内存中供给应用系统使用，当内存不足时，大量Session信息被迫交换至硬盘，大量CPU时间消耗在等候内外存的交换上，系统效率迅速下降

鉴于这种情况，我们把该服务器的内存由 2GB 扩充为 4GB，同时相应调整用户会话信息的保存时间，这样整个系统的效率又回到较为理想的状况。

由于新应用的不断投产及数据库操作的日益增加，我们后来逐渐监控到系统的数据库处于繁忙状态，系统的错误日志也记录下了供应用服务器使用的数据库连接处出现资源不足的情况。在这种背景下，我们认为整个系统由于硬件配置所限，应该进行横向扩展，因此我们把数据库服务器分离出来，配置到另一较高性能的服务器上，相应定义的数据库资源也大幅增加，这样整个系统的性能又处于较为理想的状况。

第三方面是对应用系统进行相应的优化以提高性能。

web 服务器配置及相应的硬件扩展不失为解决系统性能问题的一条捷径,但应用系统的优化也是应该重点加以考虑的，毕竟它能够在投入较少的情况下提高系统的运用效率。在开发的初期，我们就已经十分注意系统的利用效率，比如提醒程序员尽量不要利用用户会话信息(Session)来传递大的对象，对于内存要注意回收等。同时，通过内部的交流会推广与介绍一些小的，有用的编程技巧来提高开发人员的水平，通过代码的抽查，希望能在早期就发现问题等。

在系统运行期间，我们通过监控发现，应用服务器所基于的 Java 虚拟机，其内存堆的空闲空间有不断下降的趋势，每隔若干天导致空间消耗殆尽，无法分配新对象空间，从而导致系统重启。在排除了系统本身问题的原因外，我们确定为应用系统的开发有问题。通过从网上下载IBM公司检测Java点拟机的相关工具对JV进行监控后终于发现系统内部存在着不能回收内存的对象，再通过查找相应的程序发现在该程序中有“环状”的对象引用，从而导致对象使用后不能被垃圾收集器所回收。这个问题的解决过程虽然十分艰苦，但由于该问题不能通过升级硬件或增加资源配置而得到根本解决，会给系统带来很大的隐患。所以，整个过程的分析与解决是完全值得的，更何况通过查找故障原因的过程，给整个项目组上了生动的一堂软件质量保证课，对项目组的质量意识起了很大的促进作用。

所以说改进 web 服务器的性能并不单纯是系统管理方面的工作，它渗透到开发以及系统运行第一系列环节中。

第四方面预先考虑未来的扩展与性能需要。

随着系统的发展及成熟，考虑到用户访问量的不断上升，为了预留系统的发展空间，我们最近又对整个系统作了一个系统性的升级通过引入多台 HTTP 服务器及应用服务器并行工作提高整个系统吞吐量及单点故障克服能力。由于在一开始选型的时候就已经充分考虑到动态负载均衡及横向扩展方面的需要，这一项的升级无需对整个系统的体系结构作根本的变革，对应用程序来说，更是没有造成任何影响。

整个项目历时近两年，从这两年的系统情况来看，整个系统是成功的。根据我亲身的经历，系统性能并不单纯是系统运行与管理阶段的问题，而是渗透在项目论证、开发以及运行的各个阶段。只有各个阶段都能充分考虑性能方面的需要，在实际运行时，整个系统的性能才可能真正有保障。在技术方面来看，可以综合利用选型评估、硬件扩展、应用优化和系统配置优化等一系列的手段，比如在硬件扩展方面，又可以分为主要部件扩容，纵向升级、横句升级等方面。在我们的项目实践中，曾综合地利用了上述的各种手段。比如某银行的整个系统日访问量不足1万至现在的每日超过 10 万次以上的点击的发展情况来看，整个系统的性能保障及提高方案是比较成功的。

论基于构件的软件开发

摘要

去年初，单位承担了新立的“测井资料处理与解释集成软件” 项目，目的是集成目前国内零散的测井解释方法，我有幸参加该项目，并负责软件系统平台设计和部分开发工作，在项目的实施过程中，我充分进行基于构件的软件开发，复用成熟的商业构件和本单位的构件资源库，同时考虑了本项目开发资源的进一步复用，形成了绘制组件包，数据交换组件和数值计算组件包等。基于构件开发，大大提高了软件的质量，缩短软件的开发周期。开发的软件目前在石油测井几个油田现场使用，并得到用户的好评。本文就在本项目中如何进行基于构件开发进行描述，并在复用构件的使用和丰富方面谈一些自己看法

正文

2004年3月，我有幸参加了单位软件开发项目一一“测井资料处理与解释集成软件”并负责系统平台设计和部分开发工作，本项目是由中国石油天然气集团公司科技部的测井软件类项目，在项目立项之前，国内测井行业为了提高石油解释的分析和决策能力，在解释方法方面广泛与各大高校进行合作，经过长时间的积累，形成的非常多而且实用的方法和处理模型，并开发了简单的使用系统，但这些应用非常零散，不统一，无法协调工作，处理效率低，多个解释系统之间没有必然联系，而且数据格式多种多样，不利于测井的精细解释和综合应用。本项目的目的是为了综合决策能力，提高石油解释的准确率，考察了解国内流行的测井资料处理解释方法，将成形和半成形的解释方法进行筛选和整理，集成到统一的系统平台上，增强一体化处理功能和商业化能力，并有偿反馈给石油测井现场用户使用。

在本项目立项前，单位承担了较多的软件开发项目，软件开发方法一直在改进更新。单位早期的软件以数值计算为主，主要采用面向过程开发方法，但随着软件的复杂度增加，可视化要求和开发效率，在面向过程方法不能满足要求的情况下，开发方法转为面向对象方法，实现界面编程，可视化操作交互，开发效率得到大幅度提升，但是这种方法也存在一些不足无法有效实现资源复用，多个项目之间的资源复用仅限于部分开发过程和偶尔可以复用的模块类，新项目很少能借鉴老项目，即使存在明显类似的项目也无法有效复用，出现了多个项目组软件界面不统一，操作习惯不一致等情况，因为新项目只注重眼前效率和操作适应性，根本没有考虑以后的复用，导致重复开发，浪费人力物力。因此，在面向对象开发方法的基础上进行改进，采用基于构件的开发方法，在每一次项目中，尽可能地考虑以后可重用的部分，以构件形式进行设计开发，虽然在单部分的开发工作可能增加，但是多项目综合考虑，大大提升软件的开发效率。而且，本单位大部分项目为测井类软件项目，在软件的设计思路和最终成品上看，很多部分非常相似甚至雷同，几个连续项目存在联系，基于构件开发的软件方法在本单位更能体现作用。

在“测井资料处理与解释集成软件”项目的设计和实施过程中，我使用了基于构件开发的方法，充分利用公认的构件技术-COM/DCOM 和ADO等，使用已有的商业构件-Xtreme 和Esstentials等，复用单位的构件资源-数据转换组件，并开发了新的构件，如绘制组件包，数据交换组件和数值计算组件包等。

本软件系统以测井解释分析为主，主要包括图件绘制、用户交互操作、数值处理和数据存储等几个部分，我将软件设计为C/ 四层体系架构客户端应用程序采用 Microsoft Visual C++开发，本单位已经购买了 Xtreme 的使用权，Xtreme 是基于的架的界面构件，它是微软的合作伙伴，能经过简单的几步向导就能产生美观的软件界面，它生成的界面具有一致性，对于测井解释集成应用，统一的界面可以降低软件的学习难度，增强软件的易用性，使用 Xtreme，我非常方便地实现了界面设计和开发工作。

图件绘制基于 GDI和 GDI开发，每个绘制对象采用单独的一个类进行封装，绘制的载体对象派生于 MFC 的窗口类，其他对象派生于同一个基类，基类设计足够的消息响应函数，对象采用重载虚函数或者操作自动定向，实现鼠标响应，属性修改和递归型子对象管理。绘制载体类和基类封装在一起，形成绘制核心库，其他对象单独以 MFC 扩展动态库实现，一个或者几个对象设计成一个扩展对象库，如果要增加和删除某个对象，只需修改相应的扩展动态库。这样，只需要绘制核心库与必要的绘制对象扩展库，就可以提供相应的绘制功能，而且绘制的对象可以定制并进行二次开发。在某些绘制图件的设计中，考虑到算法的难度，直接利用较为成熟的绘制构件-Gigasoft Pro Essentials，如等值线图，区块三维分布图和多井连通图等图件的绘制算法，核心绘制部分直接由 Essentials 完成，用户交互响应由对象封装

测井解释的核心部分是解释方法，每种测井项目有多种解释方法，而每种解释方法又有多个解释模块，因此解释方法的设计是相对复杂的。在考虑到测井解释的流程化处理和模块动态增减的要求，采用 COM 组件技术进行了模块设计。例如常规测井解释项目，包含 POR、CLASS、SAND和 CRA 等多种解释方法，而这些解释方法都包含几个解释过程，如 POR 包含泥质含量计算，渗透率计算、孔隙度计算和含水饱和度计算，将上面的每个过程设计为功能完整封装的 COM 组件，当用 POR 解释方法进行资料处理时，依次调用处理过程完成解释。由于采用组件方法设计，方法模块可以动态添加，如果在 POR 的基础上需要添加含油饱和度计算模块，只需要设计相应模块，动态添加到 POR 的管理队列中。在解释方法分解设计的同时，将多种相同的数值计算方法进行提取抽象，形成满足自己需求的数值计算组件包，方便多种解释方法的复用，并为新的解释方法研究提供强大的计算能力。

在软件设计开发中，数据的存储最为繁琐，由于测井解释面对多种数据格式，如国内Forward 软件使用wis(WellLogging Information Sysetn 测井信息系统)数据文件，国GeoFrame 使用的Lis(Log Information Standard)eXpress 使用的XIF(exchange Tape Format可交换带格式)格式和 DPP 使用的 clis 格式等，这些测井软件使用相当广泛，如果本项目软件能进入市场，这些格式都需要兼容，但是将这些格式都作为应用对象很难实现或者不可能实现。在数据储存方面，我直接采用 sql Server 数据库存储，存储结构设计采用国际标准结构，国际石油标准化组织 POSC制定了一套EPICENTRY石油数据存储标准，这种结构被石油系统广泛采用，可以存储石油系统多行业数据，如测井、录井、钻井和开发类数据等，直接采用已有标准可以满足复杂的存储要求，避免重新设计格式的存储能力限制。数据访问采用 D数据访问组件，实现数据通讯和交换。在数据库的数据录入方面，我充分利用了本单位其他项目开发的数据格式转换组件，用于支持多种测井数据的解码和编码，由于以往项目的数据操作是基于文件系统(CIF 格式)，内部封装了固定 CIF 文件格式转换功能，我将组件进行了适当修改，将基于 CIF文件格式的操作改为内存操作方法，实现向数据库录入。

在数据库和解释模块之间，我设计了数据交换组件，因为测井解释的特殊性，一次解释需要获得数据非常多，一次解释处理至少需要二三条曲线，测井采样间隔一般为 0.01 米左右，2000 米井段每条曲线传输数据量就有 100 多，如果需要处理成像数据，数据量更大，可能有几十兆，甚至上百兆，由解释模块或测井图件直接采用 ADO 进行数据库访问，每次解释会多次访问数据库，势必会降低软件的执行效率和处理的稳定与连续性。数据交换组件将一次解释数据全部读出，打成固定格式的数据包 GDS (Global Data Storage)，GDS 可以以文件形式存放和内存形式交换，应用模块只处理 GDS 数据包，完成各种应用后，按照同样的格式传回数据库，优化处理性能，而且基于 GDS 构件的应用还可以扩展开来，GD 不一定只与我们设计的数据库进行交换，如果需要增加其他存储方式数据库，只要知道详细的存储结果，开发访问组件，GDS 就能与其相联进行信息处理，新的数据格式也是一样，只要提供了访问组接口，也能够进行测井解释。

开发过程中，我充分利用已有的构件，也充分地考虑了本项目开发资源的进一步复用，开发了绘制组件包、数据交换组件和数值计算组件包等构件，完善单位的可供复用的构件库积累和固化知识财富。到目前为止，绘制组件包和数据交换组件已经在新项目测井数据采集平台使用，效果非常好。

基于构件的软件开发，可以缩短软件产品的开发周期，提高软件质量，但是如果构件选择不当或使用方法不当，也会带来一些麻烦，在构件的使用上，我也走了一些弯路，如在使用 xtreme 上，由于购买了它的源代码，曾将某些绘制模块建立在其源代码级别的紧密耦合，当 Xtreme 提供的新的版本后，这些紧密合的模块无法适应新版本，如果想继续应用，必须再进行同样的开发工作，最后我放弃了某些紧密耦合的功能，将绘制交互与 Xtreme 完全隔离开，后续的版本升级再没有带来任何问题，类似的教训还有很多，总结分析后，我认为在基于构件的开发中主要注意一些问题，如项目开发不要与已有构件紧密耦合，防止构件升级带来的影响，构件的使用一定要进行严格的测试与审核:不要勉强应用某些构件，如使用巨大构件的其中某个微小部分，虽然功能很适合应用，但可能影响软件效率，新项目必须注意构件库的积累，只有这样才能充分体现基于构件开发的便利，新构件功能一定要完整，文档及接口定义明晰，否则难以复用。

在本项目的开发工作完成后，相比以往的开发项目，开发周期明显缩短，软件的质量明显提高，用户软件维护要求也减少了，而且其扩展性非常强大，目前该解释软件已经在华北油田、长庆油田和土哈地质研究院进行了现场应用，得到了用户的一致认可。通过这次案例，我认为在软件系统的复杂性不断增长的情况下，基于构件的开发能有效提高软件质量、积累和固化知识财富，并有效地缩短软件产品的开发周期，提高了软件生产效率。

论基于构件的软件开发

摘要

基于构件的软件开发是提高软件生产效率和软件产品质量的有效途径，本文结合我们的实践，以“在线学习支持服务平台”项目为例，讨论了基于构件的软件开发的技术的应用。由于我校现有的各级软件系统都是基于微软 windows 系列平台因此我们确定使用微软的 COM组件技术来开发该平台，并介绍了该平台所使用的几种 COM组件，主要采用 VB6 语言编写通用模块并生成DLL文件及注册成为 COM程序，客户端用ASP 语言来实现并通过ADO技术来调用SQLSERVER 2000和 COM组件

在本项目中的开发过程中，我担任了系统设计工作

正文

“在线学习支持服务平台”是面向我校开放教育学生进行远程学习教学辅导，经过多年的远程教育模式的探索，确立了成熟完善的远程教育教学模式--利用先进的网络数字信息技术，为广大的学生提供开放的教育平台和最优秀的教育资源，突出个性、学生自主学习的教学。

“在线学习支持服务平台”是一个综合性的在线式基于 WEB 的远程教学平台，存储着核心信息数据，提供网上课程、信息发布、查询、BBS、VOD 视频点播等教学服务，该系统的开发技术主要集软件复用、企业级应用程序开发等技术于一体的“基于构件的软件开发”系统运行于WINDOWS SERVER 2000，用 SQL SERVER 2000 为后台数据库，用ASP+IIS 5.0 来架构网站。

由于 COM组件既可以被嵌入动态 Web 页面，还可以在 LAN 或桌面环境的 VB，VC等应用中使用。另外该组件之间是彼此独立的。当应用需求发生变更时，可能需要更换中间层的个别 COM 组件，但并不影响其他组件的继续使用。组件具有若干对外接口(属性和方法)，可以根据不同的应用需求，有选择地使用不同的接口。即使不再使用某些接口时，COM 组件本身仍然可继续使用。同一 COM 组件可以在不同的应用环境中重复使用。因此，结合我校的实际情况，我校现有的各级软件系统都是基于微软 Windows 系列平台，且开发人员对COM组件技术也较熟悉，对开发语言 VB6 也很熟悉，因此我们确定使用微软的 COM 组件技术来开发该平台:

该平台采用 B/S 结构进行设计，把整个系统分为三个层，数据库层，应用逻辑层，用户界面层。用户界面是浏览器(如IE，Firefox 等)，并通过ASP 语言来实现同应用逻辑层构件交互。应用逻辑层负责事务处理，应用逻辑层用主要通过使用 COM 组件方式来实现，数据库层用 SQL Server

我们依据平台的主要功能，在平台开发中，如果采用传统的方法来开发，则每实现一个功能都要编写同样的代码，为了节省开发时间和提高维护效率，我们把共用的代码模块都做成组件，例如我们把记录操作(如记录的删除、增加、修改等)、数据库操作、查询做成用户管理组件，把用户身份认证和用户类型识别做成用户管理组件，把所有实现与数据库的连接做成连接组件，把用户的错误操作、与系统的交互出错等做成错误处理组件。对于各组件我们采用VB6 语言进行编写并生成 DLL 文件，通过注册成为CO程序，供各个组件调用。在数据库连接方面，我们采用了 ADO 技术由于 ADO采用了 OLE-DB 技，使能访问各式各样的数据并提高了访问性能。

在该平台的开发过程中，主要设计和实现了以下一些COM 组件:

(1)用户管理组件，包括身份认证功能

我们主要定制COM组件用户管理组件 UserCheck.dll进行用户管理处理。该组件主要完成两个功能:一是身份认证功能，主要是提供用户登录时验明身份，保证应用的安全性。二是根据用户所输入的账户名确定该用户的类别。

因此，该组件具有三个接口，每个接口代表组件的某个属性或方法。对用户的登录请求做出相应的处理，如果是学生登陆则转入学生学习平台，如果是教师登陆则转入教师平台如果是管理员登陆则转入管理员平台

(2)查询和提交信息组件

我们主要定制COM组件QuerySys.dll进行查询和提交信息处理

该组件主要完成两个功一是供学生用于查询学生成绩和查询课程信息，二是提交学生注册信息。该组件具有两个接口，每个接口代表组件的某个属性或方法。如果学生的请求是查询功能(QueryInfo方法)，则将查询信息请求做出相应的处理，并将查询结果集返回给出学生。如果学生的请求是提交注册信息(Submitinfo方法)，则将提交信息请求做出相应处理并将信息提交提示返回给用户。

(3)连接组件

我们主要定制COM组件 Conector.dll，该组件主要完成与数据库的连接。该组件具有一个接口，那就是确定数据源，以便自动连接后台数据库。

(4)错误处理组件

我们主要定制 COM组件 CError.dll，该组件主要确定错误类集，该组件具有一个接口，

主要是输出错误信息，方便用户排错。我们把编译好的组件，将其在 MST 中注册，并将其分布在服务器上，这样就可以在设计平台过程中进行调用这些组件了，在本系统中，我们通过以下几种方式把组件集成到系统中

一是连接集成，即我们将组件直接入 ASP 页中即在SP 脚本中通过 SET 对象名=Server.Createobject("类名”)来引用使此二进制组件可以运行于服务器端。

二是容器集成，即如果一个组件需要调用另一个组件时，就在需调用的组件中引用另一个组件的方法。例如在使用查询和提交信息组件时就需要先调用连接组件。

我们结合连接集成和容器集成两种方式来组装系统，以登陆界面为例，在客户端我们只提供两个输入项和一个提交信息的功能按钮，主要通过ASP 来实现。在服务器端，主要根据用户输入的信息来进行相应的处理，这就要调用各种组件。如果学生以错误的学号和用户名登陆，则系统调用用户管理组件、错误处理组件和连接组件，返回非法用户的信息。如果学生以合法的身份登陆进入学生平台，这就要调用用户管理组件、连接组件。如果教师以合法的身分登陆进入教师平台，也要调用用户管理组件、连接组件

目前，该平台运行收到良好的效果，我们采用 COM 组件技术进行开发，减少了重复输入代码的工作，缩短软件的开发周期。同时，在进行系统维护时，我们只关心组件的接口参数，而不用再考虑组件内部的具体实现，提高了系统的可维护性。在以后的工作中，如果我们要扩展某些功能时，也可以重复利用这些组件，提高了系统的可复用性。目前该平台运行存在的缺点是:由于在 ASP 中运行的 COM组件是二进制代码，当 COM 组件工作出错时，ASP 不能指出COM 组件发生错误的具体位置，只能简单显示对象创建不成功。这样就给我们在调试该平台过程中增加了难度。

论软件产品线技术

摘要

本人在测井行业的一个国有企业软件开发部工作，从 2002 年初开始，我陆续参加了多个测井软件开发项目，这些项目都是测井行业资料处理解释软件，具有很强的行业特征，其开发方向和应用范围都非常相似，从“测井资料处理集成软件” 项目，开始我实施了软件产品线技术，虽然在开始阶段，由于经验不足和管理不善，遇到了一些问题，但是随着逐步实施，都得到的纠正和有效控制，目前这几个软件项目都非常顺利的完成，实施工期明显缩短，极大的提高了产品质量，本文就在这些项目中为什么实施软件产品线?在实施过程中遇到哪些问题?产品线开发支持工具选用情况和产品线实施带来的益处等进行论述，并分析总结在目前本单位产品线技术应用中存在的不足。

正文

本人在测井行业的一个国有企业软件开发部工作，在近几年来内，我陆续参加了几个的软件开发，2002 年初参加“测井资料处理集成软件” 项目，此项目的目的是集成本单位重点实验室研究成形的测井资料处理方法，提供一体化的应用，服务于各个测井公司，我负责底层平台设计和开发，2003 年初参加“阵列感应实时分析软件”项目，主要针对单位自行研制测井仪器-阵列感应仪器MIT 的现场资料实时处理，总体负责软件的设计和实现，2003 年中参加国家级项目“山地地震和矢量地 勘探研究”的“成像勘探开发处理软件”子项目，本项目的目的是实现国内勘探解释方法和仪器的大整合，“成像勘探开发处理软件”子项目完成成像勘探部分的软件开发，我负责成像勘探部分软件架构设计和分析实现，2004 年初，参与总公司科技局“测井综合应用平台”项目，性质与“测井资料处理集成软件”类似，但集成范围扩大到整个测井行业，我参与了总体架构组，并完全负责底层平台的设计。

这几个项目都是测井行业资料处理解释软件，具有很强的行业特征，其开发方向和应用范围都非常相似。几个项目表现了很多共性特征，如数据录入接口方面，都采用测井行业标准的数据格式CIF、LIS 和 XIF 等，数据表现方面，采用图件可视化方式，数据管理方面，除了第二个实时解释项目采用文件系统外，其他均采用数据库存储，使用测井国际化标准组织POSC 的 EPICentry 规范，不仅如此，处理流程也大致相似，首先获取数据、进行数据转换，按照用户指定的方法进行资料处理，然后以形象化的方式反馈给用户一些处理特征，进行处理结果输出，各种资料归档等。除了这些共性外，几个项目也表现了一些个性特征，如“阵列感应实时分析软件”要求的实时性比较高，性能要求较高，采用文件系统，“测井资料处理集成软件” 项目用于实验室方法集成，分析功能和研究性质略强于其他三个项目等，虽然存在个性，但是我认为几个项目更多地表现为一致性。

在这几个项目中我都实施了软件产品线技术。主要原因有以下几个:1、本部门长期承接测井行业软件开发，开发范围清晰，且容易界定，在多个连续的项目中，一直存在一些共性开发。在早期项目中，由于构架和开发接口不统一，造成重复开发的弊端，实施产品线可以有效节省人力、物力和财力。2、测井行业目前出现的软件都是层次架构，80%采用采用 c/S模式，主要应用在测井资料处理上，其余采用 B/S 模式或者两种组合方式进行简单数据查询和处理结果显示，有利于产品线架构设计。3、由于行业特点，开发的软件很难适合所有的测井公司，而多数情况是量身定做，因此同一个项目可能出现多种软件版本，如华北油田专版重点挂接生产测井解释功能，而长庆油田对斜井校正等方法较为重视，采用软件产品线可以方便解决这些问题。4、同时，测井行业中，方法的更新较快，但是一般的软件使用的方法都相同，如“测井资料处理集成软件” 项目和“测井综合应用平台”项目使用同样的软件处理方法和图件绘制方式(测井行业特征，方法永远采用最新的)，一旦解释方法和绘制方式改变所有的软件要求能统一改变。

我在接手“测井资料处理集成软件” 项目后，与其他开发人员向单位建议了软件产品线的开发技术，得到同意并开始实施。由于是新项目开始，而且软件规模不算很大，因此，我们直接采用了革命的方式，项目直接实施全新的软件产品线方式，我将团队分为两路，一路总结分析旧项目的软件，一路进行当前项目的分析界定，同时聘请行业专家和技术专家结合本项目从大局进行规划，首先进行行业分析，对行业分析结果与单位的规划进行整合，最后在形成的领域架构基础上进行当前系统的需求分析和设计界定，其中开发重点在核心资源库上，然后当前项目的软件直接复用资源库上的产品线构架和构件。这几个项目完成后，本单位的核心资源库得到了丰富和充实，由这几个项目直接构成的核心资源包括两套产品线架构，分别适用于测井资料处理和测井资料检索管理两种开发类型，数据格式转换构件组，能够进行十几种测井原始数据进行转换和录入，测井图件绘制构件组，数据按照四十多种图形方式显示在通用的桌面系统、浏览器，并能以位图、矢量元文件、SW和 CGI进行输出，还有文件系统和数据库操作标准和一些商业构件库和中间件等

几个项目完成的非常顺利，除了第一个项目的出现短暂延期外，其他项目大幅度缩短了开发周期，而且软件维护和版本升级非常方便，但在实施过程中我们也遇到了一些问题:1、在第一个项目实施期间，经验不足，人员分工与过程组织不合理，核心构件与应用系统开发混淆，导致了开发设计的反反复复，延迟工期。2、部分核心资源设计不合理，某些构件在老项目方便使用，但没有充分考虑新项目的特点，在新项目无法充分利用，如果直接修改冲突构件满足新项目，老项目的维护和更新又无法与新项目配套，在一段时间内存在同时维护多套多版本构件的情况。3、资源管理不利，因为产品线实施需要非常强大的构件管理和配置管理，我的四个项目针对不同油田的应用每个项目都生成了多个软件产品，维护还包括了核心

资源维护和应用系统维护，实施前期经常出现管理不善带来的负面影响。到目前，我们逐步解决了这些不利情况，主要是加强人才培训、资源管理和组织管理。在资源管理上，我们主要通过自动化工具来解决。目前支持产品线的工具不多，大多是构件的管理和组装工具，在系统分析设计和建模方面一直采用 Rational的 ROSE，软件配置管理采用CVS，核心资源管理方面从初始的利用 CVS 转变到北大青鸟的公共软件构件库管理系统，它是采用了 B/s 的多层体系结构，分布式的应用架构，基于EJB技术，具备较强的灵活性和扩充性，支持刻面分类等多种分类模式，并提供基于角色的用户管理机制，使系统具有灵活的权限分配和安全的控制方式。在选择这些工具的选择上最重要的是核心资源管理工具选择，因为其他工具相对成熟且熟悉，而核心资源库是产品线最重要的部分，并须能进行统一的管理和识别，如关键词分类、枚举分类和刻面分类方法等，因此我们选择了北大青鸟的公共软件构件库管理系统来进行核心资源库的维护，它不仅满足上述要求，而且完全支持 UDDIV2.0标准规范，而且支持构件统一、描述、发现和集成。

产品线技术在本单位不断扩充与发展，到目前为止，形成了采集、通讯、解释处理等多方面的产品线架构和构件库，利用这些资源，可以方便快速地“组装”一个测井实用软件系统。通过实施软件产品线，本单位测井软件的开发模式逐渐规范，不同项目复用同一个或多个产品线架构，做到组件复用的最大化，实施工期明显缩短，极大的提高了产品开发过程和产品质量。虽然有了几年的技术和资源积累，我认为在本单位的产品线开发上还存在一些不足，如在领域工程方面，缺乏具备深厚行业经验的领域分析人员，需要在不断的实践培养过程中，辅以本行业外部专家的咨询和辅导，在核心资源方面，缺乏高效的管理，虽然使用了较为方便的构件管理工具和其他辅助工具，但是其智能化欠缺，不是很成熟，同时构件的组装上，还是采用人工代码方式，缺少智能组装工具应用，还有就是管理和过程方面，传统单兵作战思想影响依然深远，国有企业开发人员或多或少有一定技术封闭性，不利于核心资源积累，而且向团队开发和多部门协同开发转变存在一个阶段，需要更好的管理和更多时间的磨合。

论软件产品线技术

摘要

本人作为某软件公司负责人之一，通过对位于几个省的国家甲级、乙级、丙级设计院的考查和了解，我决定采用软件产品线方式开发系列《设计院信息管理平台》产品

该产品线开发主要有如下功能:1)知识、资源管理平台; 2)内部管理平台 3)基于WEB 的办公平台软件产品线最难开发的是核心资产的分析与建模，如何从用户重多不同需求中抽象出共性的东西，如何使得核心资产通过继承、参数化等方式能够组装成用户实际需要的产品，我以及我们公司的系统分析员做了大量工作。概括起来我们用了如下三种方式:

(1)加强核心资产开发的灵活度，部分产品作成用户能够自定义的功能，彻底免除产品化时的问题，但这样做难度很大，实施周期长;

(2)说服客户微调管理模式，以使得管理适应我们的产品线功能。这样做无疑是“双赢的”，但是实际不见得会行得通，

(3)根据流程最长的需求开发所有需要的构件，构件间的接口做成松耦合。演化成产品时进行构件组装。

正文

本人所在软件公司于2003 年6 月承接了某《化工级计院管理平台》工作，主要功能包括:1)知识、资源管理平台: 2)内管理平台: 3)基于Web 的平台该项目于2004年2月成功投入运行，得到客户的肯定该项目的开发成功以及通过与该设计院员工的接触，对我触动很大。我作为公司主要负责人与其他负责人研究后，决定进入“设计院信息工程”这样的一个行业领域做深度软件产品开发。理由有如下几点:

1)设计院是一类知识技术密集型单位，员工素质较高，管理比较规范，有完善的硬件设施---性能良好的局域网平台，具备了实施信息化管理的基础，

2)设计院的图形工作站所用的二维、三维软件或其它工程计算软件都用正版软件且价格比较昂贵，高层领导他们有支付软件费用的观念;

3)设计院开发一个项目，从可行性分析到项目实施、项目交付、到项目后期支持往往需要几年的时间，这期间产生巨量的、非常重要的各类文档(比如可行性分析报告、进度计划项目条件、变更记录、会议纪要、计算书)和大量工程图，在整个项目开发期间这些资料要提供给项目开发人员查阅或使用、修改，这些资料的安全性、完整性都是至关重要的，这些资料既是知识、技术的承体、又是法律的承载体，这些资料保存年限是 30 年或更长。目前设计院大都设立专门的部门，但基本都是采用手工管理。

4)设计院的客户在项目开发期间以及项目上线以后一段时间都希望得到良好的技术服务。技术支持既包括现场技术服务，也包括远程服务。现在的远程技术支持是很被动的接听客户电话、传真或 EMAIL，没有建立专门的平台也没有进行规范管理

有了对设计院内部运作的一般了解后，我们将已经开发成功的某《化工级设计院管理平台》精简做成演示原型，我带着这个原型以及对《设计院信息管理平台》的设想来到本市各类设计院:省级建筑设计院、市级建筑设计院、省级电力设计院、省级化工设计院、大型企业内部设计院等大大小小 20 家，征求他们的意见和建议，了解他们对该管理平台的认可度我感到很欣慰的是 80%的设计院高层领导对我们的产品设想有兴趣,并提出了针对自己单位的需要扩充或压缩的功能。随后的一个多月我带着补充修改后的原型产品，来到另外几个省会的设计院征求意向，结果:1)大部分的设计院目前没有完善的管理平台;2)如果我们真能设计出满足他们需要的产品，他们有兴趣购买

通过持续2个月的调查我们公司于 2004 年5月决定投入这个行业的软件开发，因为要开发大量类同的软件产品，公司决定采用软件产品线开发。我们的对该系列产品的设想是:

这样划分的理由是:不同级别的设计院规模大小、管理模式、职能部门、待管理的资源区别非常大，国家甲级设计院除了设计以外，还能做技术咨询、工程总承包、建设监理、设备材料供货等工作，承接国际性工程。而丙级设计院一般隶属于相关厂矿企业，只能做本单位的项目开发，所以管理规模、管理资源相对较少，乙级设计院则界于两者之间。在同级别的设计院中，则因为设计院的性质不同，开发所采用的步骤和侧重点不同。该系列产品主要功能:

1)知识、资源管理平台:管理内容包括工程图纸、各类文档(可行性研究报告、项目计划、条件变更单、项目会议纪要、来往传真等)、标准图库、标准及规范、招投标书、合同等;2)内部管理平台:包括项目管理、人力资源管理、供应管理、客户关系管理、员工绩效管理等 3)基于EB的办公平台:用于对客户的远程技术支持、保持与关键设备供应商、国家级研究机构的快速联系、快速获取新技术新行业信息、推广公司形象。

确立了产品线开发的基本思路以后，我采用一种动态的组织结构进行开发，初始阶段将公司主要技术力量集中起来进行核心资产开发，计划当我们的核心资产开发已经有几个实际产品之后，逐步将重点放到产品开发上并不断演化我们的核心资产。我决定核心资产的开发先重点考虑“乙级设计院”级别，这样做的好处:将来开发丙级设计院产品，只需做适当的功能裁剪，另外避免了开发甲级设计院管理平台的技术风险和项目风险。

建模我们采用 ROSE 2003，对需求分析的评估则采用 Requisite Pro，软件开发平台选用J2EE，数据库选用 ORACLE，这样做主要考虑J2EE 的平台无关性。在开发平台的选择中我们曾经考虑选用 .NET，因为 .NET 开发相对简单和快捷，但NET 限制服务器在W INDOWS 平台上行，考虑我们今后客户中的“甲级设计院”，服务器一般都采用 UNIX 系统，为便于今后产品的移植，我们选择了J2EE。版本控制工具选用clearCase。

核心资产开发最主要的是如何从众多不

同需求中抽象出相同部分，并进行概括或分类。比如我们对员工绩效管理分析时就发现，相同的部分是:输入均为图纸量、其它文档、项目总利润、职工职称等，输出则为与项目相关的奖金。但是对奖金的算法，基本每个单位有自己的一套公式:有的对图纸量分专业计算复杂度系数，有的按本专业计算复杂度(比如关键技术、新技术或普通技术)，有的按复用度(该图纸与原有图纸的相似度)计算折扣，有的不分职称只计算单纯的图纸量，有的则考虑职称或工龄，有的将计算书折算为图纸进行考核有的专门对计算书或其他文挡考核、有的计算考虑加班有的不考虑

面对我们从 20 来个设计院收集不同的考核方法，我以及我们的系统分析员确实伤透了脑筋。如果全部采用抽象类或接口来实现，那么抽象的层次肯定比较多，产品开发人员今后很难理解核心构件的意图，而通过组装类构造的话，组装类的开发工作量比较大。而最大的问题则是如何适应用户考核方法的变更。我们最终的做法是，收集和整理 20 来个设计院的考核方案中所有考虑因素的全集，对这些全集进行分类，然后使用 MVC 设计模式设计成用户自己可以控制的控件，在控件间设定一定的逻辑表达，由用户自定义计算公式计算奖金。这种设计虽然核心资产的开发周期相对较长，但我觉得是值得的。因为大大缩短了今后产品的开发周期，并减少了产品定制时的错误。

本次核心资产开发中公用部分较多的是对“知识、资源管理平台“的开发，虽然最初我们也了解到不同设计院管理方法也有所不同，我们在研究几家管理比较好的设计院方案后，拿出了一套比较规范的管理流程方案，这几个设计院表示愿意改进他们的管理措施以适应我们的方案。这一点是我本次产品线开发最值得骄傲的地方，实现了“双赢”----客户改进了他们的管理，我们节约了开发成本。

我觉得最为困难的是在众多不同需求中如何抽象出相同部分，而对不同部分进行灵活的组装或构造比如本次设计的核心模块:“项目管理”的流程，项目开发一可行性研究报告一可行性评审一初步设计一初步设计评审一施工图设计一施工图交底一项目后期支持，但有的项目由生产厂家进行可行性研究，那么同样省略的就有可行性研究评审，还有的小型项目，不需要做初步设计，项目开工后直接进入施工图设计。这种情况下我根据流程最长的需求开发

所有需要的构件，构件间的接口做成松藕合。演化成产品时进行构件组装。因为目前我们通过核心资产演化的产品还不多，所以很难评价核心资产开发的整体质量这个问题的解决有赖于更多实际产品的开发以及更多的用户反馈。本次软件产品线开发，我觉得有如下一些收获:1)对我们公司员工的素质是一个大锻炼，2)在开发过程中我们也与设计院一些高层领导及部门领导结下了深厚的友谊，加深了对该类技术密集型单位的认识,非常便于我们今后推广最终产品:3)通过核心资产的更多开发，我们今后产品开发的工作量产品开发质量都会有数量级的改善。