论企业应用集成

摘要

2004年 10 月，我参加了XX车站综合信息平台项目的开发，承担项目的方案设计任务该项目力图通过对车站现有信息子系统的集成，以达到共享各子系统的数据，优化企业运输作业流程，提高企业经营管理水平之目的。

本文结合笔者的实践，以该综合信息平台建设项目为例，讨论了企业应用集成技术。在本着集成、开放标准、管理配套的原则下，提出了基于Java 技术的J2EE 应用服务器作为统一的应用集成平台，以集成适配器作为系统集成架构模式的总体设计思路，并着力介绍了该项目关键部件一一集成适配器的构建过程。还就项目的具体实施作了详细叙述。最后，提出了企业应用集成的持续性，并确定了下一步集成的目标。

正文

2004 年 10月，我单位承接了XX车站综合信息平台的建设任务。由于我具有多年的铁路行业软件项目开发经验，所以我有幸被单位指定为该项目的负责人，主要负责项目的方案设计工作。

该车站是一等客货运编组站，车站所在地是矿区，有规模不等的国有煤矿及个体煤矿数十个，车站主要以煤炭运输为主。近些年来，随着铁路 TMIS 系统(铁路运输管理信息系统)建设的逐步深入，该车站建立了若干相应的应用子系统，主要有列车确报系统、车站现在车系统、货票制票系统、车号红外线自动识别系统、货运计划系统、货运安全系统及货车轨道衡计重系统等。车站希望通过综合信息平台的建设达到以下几个目标:(1)实现各子系统间数据共享。(2)能够实时地向企业客户(货主)发布请车、承认车及货物运价调整等相关信息。(3)通过各子系统的应用集成，使车站运输作业流程得以优化

在设计综合信息平台建设总体方案时，我充分考虑了下面三个原则:

集成原则:综合信息平台最主要的目标是整合车站的信息资源，在考虑 最大化集成各个信息子系统时，应该避免产生新的“信息孤岛”

开放标准原则，在综合信息平台建设时，应该站在整个系统宏观的高度，采用开放的标准和统一的架构来集成各信息子系统，避免各子系统“点到点”的低效落后的集成方式，以利于将来其他新的系统能够便利、无缝的整合。

管理配套原则:建设综合信息平台的目的是通过信息共享，达到业务流程的优化，以提高车站各方面整体管理水平。

因此项目设计之时，应充分考虑企业管理方面的需求在遵循上述原则的基础上，经过对企业需求的认真分析，结合当今成熟的 EAI 技术，我提出了以基于Java技术的J2EE 应用服务器作为统一的应用集成平台，以集成适配器作为系统集成架构模式的总体设计方案。如下图所示:

本设计方案从集成的广度来说，既包括了数据的集成，也包括了应用的集成，在集成的方法论方面来讲，大部分系统采用可白盒集成方法，少数系统采用的是黑盒集成方法。

根据综合信息平台的总体设计方案，集成适配器是该信息平台的最关键部分，它负责不同子系统之间数据的采集、转换和交流。因此，集成适配器的选型或设计的合理与否，是项目成败的关键。由于车站各信息子系统存在操作系统平台和数据库的异构性，无法从现有的中间件中找到完全适合的产品，因此我们决定自行开发此中间件。由于铁路各车站的业务领域和业务流程存在高度相似性，所以，此中间件有较高的复用价值。

对于集成适配器的设计，我采用了一种“可插拔”的设计理念。即为每个需要集成的子系统单独设计一个插接件，该插接件负责为与之相连的子系统提供数据及应用接口。各插接件通过 XML格式的装配文件，自由组装到集成适配器这个容器中，集成适配器为所有插接件提供一个统一的调度模块，来协调和指挥所有插件，使之能够协同运作。

在集成适配器的开发中，我选用了开源的集成开发环境 Eclipse 作为开发平台对于集成适配器调度模块的开发，我们采用了 Eclipse 提供的 Jobs API，Jobs API封装了JDK(Java Development KitTools)的定时及同步方面底层API，降低了编程的复杂性，提高了开发效率在插接件的开发过程中，我们充分利用 Eclipse 的高度可扩展特性，在因特网上搜集该项目可用的插件，以这些插件为扩展点，来扩展我们自己的插接件，最后我们利用 Eclipse 提供的 RCP (Rich Client Platform) 技术，集成我们的功能插件，并生成独立于 Elipse 平台的可独立执行的集成适配器。

各信息子系统具体集成过程及效果如下所述:

(1)轨道衡计重系统

该车站的轨道衡设在矿区与车站之间，距车站站场大约 2 公里左右，从矿区到车站的重车要经过轨道衡检斤，对于超重货车，要通知车站相关部门处理，由于该系统是个独立的单机系统，计重软件采用的是 VFP 编制，数据库是单机的 DBF。因此，我们首先从网络方面进行了集成，利用一对网桥将该系统接入车站 TMIS 系统。重车通过轨道会产生结构为:(车辆顺位、车号、车种、铁重、计重)数据，与轨道衡相连的插件会通过 JDBC--ODBC 桥，将数据转换为两个不同格式的副本，一份写入中心数据库，一份作为矿区站发来的确报报文，写入确报系统的到确报库中

通过该系统的集成，轨道衡工作人员免去了每天去车站递送过衡报表的工作，车站相关部门可随时通过浏览器查询过衡数据，并能方便的生成各种统计数据，车站的车号员通过查收确报报文，即可学握过衡列车的组成内容，减去了每列车都要到现场抄车号，回去录入的工作流程，大大减轻了劳动强度，提高了工作效率

(2)货票制票系统

该系统的集成我们采用了批量文件传输(FTP)方式货票制机在制票完成后，会自动向分局传输货票数据。因此我们在货票传输地址表中增加一个条目，使货票数据在传送分局的同时也传送到集成适配器，与之相应的插件将到达的 80 列格式货票数据进行解析，形成结构为:(票号、车号、车种、计重、运价、发货人、收货人)的数据，利用JDBC，一份写入中心数据库，另一份通过车号与现车系统的车辆库匹配，写入相应信息。

通过该系统的集成，减轻了编制出发列车确报的工作量，因为输入车号后，与该车号相关的货票信息会自动生成，免去了去查阅货票步骤。另外，该系统的集成，使货主通过因特网查询货票信息成为了可能。

其他的信息子系统如确报、现车系统、货运计划系统、车号识别系统等等，也都通过各自的接口插件进行了数据或应用的集成，在此不再祥述。

(3)OA系统和企业信息发布平台

通过 TMIS 各子系统集成而建立的中心数据库，是办公自动化和企业信息发布平台的数据基础。通过设在货服大厅的大屏幕显示系统，能够实时动态地发布与货运业务相关的系统，方便了货主，提高了办公的透明度。

通过项目组成员努力工作，车站高层领导的高度重视，以及车站相关人员的通力合作，历时四个月，该车站的综合信息平台初步完成，达到了建设之初的需求目标，得到车站的一致好评，系统到目前为止运行稳定

我们应该知道，企业应用集成是一个持续集成过程，是一项长期、不断进行的工程，不能指望短时间内达到深度集成。随着铁路信息化建设的深入，还会有新的应用需要整合。我们下一步的目标是建立该企业的企业门户，使我们前期的后台整合成果，能够在 Internet 上得以展现。

论企业应用集成

摘要

本文讨论了某公司的应用系统集成项目。某公司为了应对市场变化的需要，决定把公司几个主要的应用系统 ERP 系统，PDM 系统，E-mail 系统集成在一起，系统集成完成后，ERF系统可以与 PDM系统交换数据，大大减少了重复工作。通过 ERP 系统与 E-mail 系统的集成可以把 ERP 出来的报表自动发送给相关人员。我作为该项目的主要负责人之一，担任了系统分析和设计的工作，通过分析需求，设计三层体系结构，选择合适的平台等措施使项目能顺利完成。在项目实施过程中，我发现 XML作为新的 WEB 开发语言，应是今后选择的一个方向，并且企业应用集成是一个不断发展的过程

企业的应用集成(EAI)是指在企业范围内将多个应用系统的过程，软件，标准和硬件集成起来，使其成为无缝运作的整体。目前企业应用集成正越来越受到人们的重视。我在 2004年 1月参加了公司应用系统集成项目，作为项目的主要负责人，我担任了系统分析和设计的工作。项目首先是和相关部门的用户一起讨论系统集成的内容，用户希望完成系统集成后能提供给什么样的功能和服务。确定了这些需求后，就进行软件开发平台的选择和集成方案的设计。最后进行开发测试。测试完成后上线正式使用。整个项目用了五个月的时间完成，在2004年6月交付使用

该企业的信息化程序比较高，主要的应用系统有：ERP 系统，实施了物流和财务模块，把公司的采购，财务集成到了一起，PDM 系统，产品的设计和开发在该系统上进行;E-mail 系统，主要是收发内部和外部的电子邮件。但是，随着企业的发展和市场竞争的激烈，问题也逐渐暴露出来。因为三个系统是独立的，没有数据的交换和共享，这样，大量相关的数据不得不重复输入。像 PD系统负责产品数据的的维护，当一个产品的 DOI(Bill of material物料清单)成熟后，要把该 BOM导入到 ERP 系统。因为两个系统没有关联，这样就需要安排人员专门负责数据的录入，往往要加班加点，且容易出错，很不利于产品快带地生产并推向市场，为此，要考试应用集成，把企业的这些“信息孤岛”联系起来实现信息的交流。我在分析了企业应用系统的现状后，分以下几个步骤来实现该企业应用集成。、仔细研究现有的系统之间的关系，确定要集成的内容并考虑实现的方法

首先是是 ERP 系统和 PDM系统的数据的交换，要求在 PDM系统开发出来的 BOM下达后要自动导入ERP 系统因为两者针对的是 BOM，结构是一致的，实现两者的数据集成，只需定义统一的数据接口和格式即可。其次是 E-mail 系统和 ERP 系统的集成n用户希望有 ERP 系统批准的采购订单能自动发送给供应商而不必手工要从 ERP 系统中下载下来整理后再发给供应商。驻外地的销售人员要求能每天收到关于成品库存的 E-mail。通过分析，发现公司用的E-mail系统是 Microsoft Exhange Server，而 Exchange 提供了与外界的API接口，只要照接口规定的格式填写，如发件人，收件人，信件标题，内容等，进行填写的文件，转送到了Exchange Server后，Exchange Server 就可以把将其发送到指定的收件人邮箱。利用这一功能，可以在 ERP 上开发接口程序，下载符合要求的文件到 Exchange Server 上实现 E-mail自动发送。

二、设计企业应用集成的体系结构

为了避免传统的点到点的系统集成的缺点，我提出了三层的系统集成体系结构，即把企业应用系统分成表示层，中间层和企业信息系统层(包括数据系统)，企业信息系统层由该企业的 ERP 系统，PDM 系统和 E-mail 系统组成，它们通过一个面向消息的中间件来实现数据的交换。中间层主要实现应用的业务逻辑和各种服务支持，它可以访问企业信息系统层运行且与应用相联系的数据和函数。比如前面说的 ERP 系统与 PDM的数据交换，ERP 系统与 E-mail系统的接口就在中间层实现。数据从底层进入中间层，在这一层完成数据交换和集成的功能。这样通过中间层就可以实现三个系统数据的共享。客户层则包括不同类型的客户端应用，之前三个系统都是c/s 结构，各自有自己的客户端程序运行在个人计算机上，集成后， 要开发出基于 WEB 的客户端程序，统一界面，方便访问，实现 B/S 与C/S 共享。这样，通过中间层实现不同系统的协调工作和对企业各种事务活动的支持，屏蔽了低层的接口和技术细节，使数据能方便地交流

三、选择合适的应用集成平台

目前，可作为开放式企业应用集成的规范和平台的主流技术有两种:一种是微软公司的COM++规范和 Windows .NET 平台，另一种是 SUN公司的EJB 规范和J2EE 平台。在平台的选择上我进行了反复的比较，最后选择了 J2EE 平台。因为J2EE 平台的开放性与支持异构性，可移植性，支持的广泛性。对企业现有遗产系统的继承性和技术优势等。更重要的是它具跨平台的功能。公司的 ERP 系统是运行在  Unix 服务上的，PDM 系统用的则是 Microsoft NT操作系统，E-mail是Microsoft的 Exchange Server，这些应用使用不同的操作系统和平台而微软的.NET 只能用在 Windows 的操作系统的所以基于公司的实际，J2EE 平台是合适的选择。选择J2EE 平台存在的间题在于，一是成本相对比较高。二是公司的IT 人员对 JAVA还不熟练。为此，我在确定选用该平台后，先了解该平台的软件构成，只购买了我们需要的开发软件，从而节省了成本。对 JAVA则安排了几次培训，使 IT 人员能很快地上手用 JAVA 开发程序

四、应用集成方案的实践

在J2EE 平台上，我通过JAVA在业务逻辑层的开发，实现了以下的业务流程首先，在PDM系统的产品结构成熟后将会有一个下达的动作，然后 BOM数据通过中间层的处理自动导入到ERP 系统，这能过之前已定义好的口规范和数据格式可以很空易地实现。ERP 接收到产品结构数据后，即可以运行 RP 产生采购订单和生产订单，投入产品的生产。此外，通过业务逻辑层，在 ERP 系统上下达 PO 后，采购订单的数据会自动传到 Exchange 服务器，然后通过E-mail自动发送给供应商产品库存的数据也可以从ERP 系统传到 E-mail 发给外地的销售人员。该应用系统集成后，用户不必再加班加点在地在 ERP 系统中维护产品数据，并且保证了ERP 的产品结构与 PDM 中的是一致的由于实现了 ERP 与 E-nail 系统的集成，用户也不用担心哪张 PO 没有发送给供应商了。

项目上线后，满足了用户的需求，运行半年多来，系统基本稳定，大大提高了工作效率,

得到用户和管理层的肯定，但也存在着一些问题。 在项目实施的后期，我们发现用 JAVA 编写代码效率比较低，运行速度慢，并且取数据还是不太方便。于是引入了 M 技术进行数据的抽取，组织和表现，结果大大增加了开发的效率。通过该项目我认识到 XML 将会是今后EB 开发和实现企业集的主要技术之一。此外，现在仅是实现了 PDI 系统和 ERP 系统的集成，之后随着企业的发展ERP 将运行在更开放的平台上。会从企业的内部应用转为一个连接到 WEB 上的分布式应用系统。即ERP II，这将是以后的发展方向。

财务数据仓库系统的设计与实现

[摘要]

近年来，数据仓库技术在信息系统的建设中得到了广泛应用，有效地为决策提供了支持。2004 年 6月，本人所在单位组织开发了财务管理决策系统，该系统主要是使高层领导学握企业的经营状况及进、销、存情况，分析市场趋势。

本文通过对财务数据的分析，结合数据仓库开发原理，完成对财务数据仓库的数据组织介绍了财务数据仓库的设计和实现方法方法。财务数据仓库的设计步骤主要是遵循数据库设计的过程，为分概念模型的设计、逻辑模型设计、物理模型设计和数据仓库生成等几个阶段目前，该项目已顺利上线，领导反映良好。在该项目中，本人担任系统分析师职务，主要负责系统架构设计和数据仓库的设计工作。

[正文]

2004 年6月，我所在的单位为了快速适应市场的变化，使高层领导及时学提企业的经营状况及进、销、存情况，分析市场趋势，决定开发财务数据仓库系统。在该项目中，本人担任系统分析师职务，主要负责系统架构设计和数据仓库的设计工作。在这个系统的设计过程中，我们遵循了数据库设计的过程，整个财务数据仓库的设计步骤如下:

(1)概念模型的设计

(2)模型设计

(3)物理模型设计

(4)数据仓库生成

1.概念模型的设计

进行概念设计所要完成的主要工作有:

(1)决策需求分析:对于数据仓库系统而言，决策者最为迫切的需求在于，更加准确的掌握企业的经营状况及进、销、存情况，包括分析进货趋势，分析销售市场波动趋势，分析企业存货情况，分析市场经营状况发展趋势。所要求的操作数据库的数据有商品进货数据、商品销售数据、商品库存数据、顾客信息和销售商信息。

(2)确定系统的主题域及内容在上述需求分析的基础之上，我们可以确定企业财务仓库系统的 3 个主题，分别是商品、顾客和销售商。如图 所示

2、逻辑模型设计

商品、顾客、销售商是财务数据仓库的 3 个主题，是其经营运作3 个框架。商品主题描述企业商品分类及销售情况，顾客主题描述了企业对顾客进行分类及有关顾客合同的管理情况，销售商主题描述了企业销售人员销售商品及销售地区情况。其中商品主题作为中心，将这3个主题联系起来。它们的内容列出如下:

(1)商品，商品固有信息(商品代码、商品名称、商品类别等)，商品库存信息(商品代码、库房号、库存量、日期等)，商品销售信息(商品代码、顾客代码、销售日期、销售单价销售数量等);

(2)顾客:顾客固有信息(顾客代码、顾客名称、地址号、电话等):顾客合同信息(顾客代码、合同代码、起始日期、终止日期、数量、价格等)，顾客购货信息(顾客代码、商品代码、单价、数量、日期等)

(3)销售商:销售商固有信息(销售商代码、销售商品、销售商品名、销售商地址等);销售商地区信息(销售商代码、销售地区名、电话等)。

以“商品”为主题可以看到，首先，在从面向应用到面向主题的转变过程中，丢弃了原来不必要、不适合分析的信息，如各类领料单、出库单、入库单等，棋次，在原有数据库模式中，有关商品的信息被分散在各个子系统中，如，商品销售信息存放于数据管理子系统，商品库存信息存放于商品库管理子系统中等，根本没有形成一个有关商品的完整一致的描述，而向主题的数据组织形式所实现的就是要形成商品一致的信息集合，以便在此基础上针对“商品”这一分析对象进行分析处理

3、物理模型设计

(1)确定数据的存储结构

通过定义功能/教据的交叉参照图，决定谁需要访问哪个范围的数据。每个数据仓库实施的最初阶段，必须标明最终用户的词汇表，定义恰当的商业术语，与底层数据联系起来。

• 由于数据仓库本身通常是面向主观意识的，基于最终用户的需求，创建数据仓库的第一步是识别和分析有关的内部数据和外部数据源。
• 数据模型在将内部和外部操作数据转换和集成到数据仓库里的过程中起着关键性的作用。在这个阶段，系统分析师必须收集信息，实施从数据源到数据模型的逻辑转换，确定数据按简要或详细的程度保存在数据仓库中。
• 创建词汇表、清除数据是产品数据与仓库数据之间的转化基础，词汇表是关于数据的数据。对于决策支持分析员来说，它是一个确定数据位置、理解计算法则的商业定位指导。清除数据和过滤数据包括转换数据、巩固数据和通过应用一致的命名法则协定解决在操作数据库中数据不一致的问题。
• 从长远的角度优化数据仓库，系统必须是灵活的，可扩充的，模块化的，以便有足够的能力去适应系统的不断增长。

(2)确定索引策略

由于数据仓库的数量比较大，因此在库结构设计时将每一个子库设计为树型索引结构，初始结点为所要决策的主题，其中间结点即为不同优先级的与该主题有关的查询角度与层次而最终结点为经过预处理的有定义的数据集合。

4、数据仓库的实现

(1)接口设计

在财务数据仓库中有几种方式:菜单式、问答式和图形式。接口设计涉及如下几个模式:输入响应模块、输出模块、人机对话管理模块和外围设备。由于时间和篇幅有限，这里就不详细介绍这些方式和模块了

(2)数据的采集

接口设计结束后，下一步工作就是将数据采集到数据仓库中。数据采集是将原始数据从多个传统事务处理数据库系统中提取出来进行清洗，集成等有关处理，使之符合数据仓库环境中对数据质量的要求后再装载入数据仓库中。数据采集的主要工作有确定数据源的次序、元数据的管理、粒度划分、数据分制和数据的定期维护，数据在装入数据仓库底层的目标数据库后，还要完成的任务包括数据的定期洁理、刷新、重建索引、初划分主题等工作

目前，该系统已经上线并顺利运行了一段时间，达到了开发的目标，为高层领导决策提供了可靠的数据来源和支持，得到了单位领导的一致好评。

数据仓库技术的发展包括数据抽取，存储管理，数据表现和方法论等方面。

在数据抽取方面，未来的技术发展将集中在系统集成化。它将互连、转换、复制、调度、监控纳入标准化的统一管理、以适应数据仓库本身或数据源可能的变化，使系统更便于管理和维护。

在数据管理方面，未来的发展将使数据库厂商明确推出数据仓库引擎，作为服务器产品与数据库服务器并驾齐驱。在这一方面，带有决策支持扩展的并行关系数据库将最具发展潜在数据表现方面，数理统计的算法和功能将普遍集成到联机分析产品中，同时与Internet/Web 技术紧密结合，推出适用于 Intranet 和终端免维护的数据仓库访问前端。

数据仓库实现过程的方法论将成为数据库设计的一个明确分支，并将成为管理信息系统设计的必备。

论软件需求分析方法和工具的选用

[摘要]

本文通过一个集成电路设计有关的软件项目，讨论了该项目的主要特点和本人所担任的工作，若重讨论了在项目需求分析过程中采用的具体方法和工具以及选用的理由。由于项目的专业领域的特殊性，分两类不同的需求讨论了需求分析中遇到的问题及解决方法，在这个过程中给出了对选用的具体工具和方法的效果的描述。接着本文讨论了对吏用方法的改进的一些想法以及具体的实现过程。最后提出了我对需求分析的某些看法，强调了与客户沟通的重要性

[正文]

近年，我一直从事某企业中有关IT 项目的开发，有一个系统是用于计算机辅助电路设计的，包括了从上流设计(注，日式说法)到下流设计(注日式说法)的所有流程，如用于可设计百万门数量级的逻辑门电路。有关方面把电路中路径的提取、过滤以及表示的某软件开发任务交给我公司，我有幸担任了该部分的需求分析以及设计

我所设计部分为一单独可启动的软件，主要是解析文件中的连线路径，以列表视图和用直方图等把它们显示出来，还可以执行诸如查找与过滤等功能。

委托方对此提供了很初步的需求说明，把一些基本功能及性能要求描述了一下。我在需求分析时的工作主要有两点:第一，对该软件的界面等详细需求要自己重新进行分析提取。第二，对于已提供的功能要求需要深化和细化，以形成真正完整的需求分析文档。

在接到需求分析任务后，我分析了一下所要完成的工作，发现由于是专用领域的软件，对专业领城要求相当高，所以准备把此项目分成两部分

(1)界面所受专业领域影响几乎没有，但由于全部没有任何要求，反而会感到风险和改动可能是最大的。

(2)功能方面由于委托方的许多功能都可以调用相应模块来得到，并且已有了相应的书面的简单需求，相应来说只是完成深化。对界面，我采用了部分 RUP 的思想迭代与渐进。而对功能需求采取了分层细化，每细化一层就要求委托方确认、修改和补充。

首先把风险较大的部分完成，这是现代软件开发的基本常识。我选择先进行界面的需求分析。第一步是根据功能描述抽取出逻辑模型，并使逻辑模型与界面元素及功能一一对应，大体上决定了界面应有的功能，然后根据该界面功能描述，确定具体的控件，这时，我参考了委托方已初步完成的主窗口的界面布局及控件的使用规律，然后根据需要完成的功能从Qt(由于要支持 Windos 和 Unix 双平台，所以控件采用 Qt)的类库中选择相应的控件，在提取和抽象逻辑模型时，我采用了 Rose 2000 中的用例图，即以USE-CASE 图来描述与外部的关系。之所以采用 Rose，我是基于以下的原因，第一，在已开发的部分中，委托方统一要求我们使用 Rose 进行类和顺序图等的设计和代码生成。第二，Ros 提供了标准的图来描系统与外部的关系，在全球范围已是一种标准结构，第三，使用上的方便性，我用 Rose 的USE-CASE 图，理清了我们的软件窗口(日式说法，即，沟通人员)与委托方主窗口(日式说法同上)以及外部角色《操作者)之间的相互关系

在确定了界面元素后，考虑到文档的可理解性不是很强，我采用 visio 2000 把界面的外观绘制出来，写上了基本的控件作用，随后送给委托方评审，幸运的是除了几个小功能的修改，委托方基本批准了我的方案

下面的需求是针对功能需求的。虽然委托方技术部门有初步的需求文档，但由于领域的专门化不对，我不清楚其中复杂的路径提取关系及较深入的专业术语，一直有一种举步维艰的感觉。只能采用分层细化的原则，从最初的几条深入一层变成十几条。这样的话，不会一下子碰到太深的专业问题，可以循序渐进从委托方与文献的解答中不断学习，深化自己对专业领域的了解，这样在设计中自己始终是层层推进的，不至于碰到无法逾越的专业障碍

在这一阶段的开发中，由于一直是与自己不熟悉的专业领域打交道，所以我觉得一些辅助设计工具似乎无法发挥应有的功能。在这期间，对我帮助最大的应是公司的 E-mail 系统所有不清楚的问题的提出，以及对问题的解答都通过它进行周转。换句话说，在需求分析阶段，它起到了一个与客户的交流沟通和客户需求的提取作用所以，我认为在这一阶段,E-Mail系统是对我帮助最大的工具，其次是 Excel，我用它建立了问题跟踪图表，对每一个提出的问题，均需要记录上去，把问题结果 (可分为已清楚、仍不太清楚、不清楚、尚未回答)均记录下来，根据这些表，我可以很好地了解自己工作中的核心问题，并有了解决它的方向，提高了工作效率。

每进行一层的细化，我都把结果交付委托方审核，由他们进行提出何时能终止细化，大约在八层细化后，对方认为已达到了效果，确认可以结束。至此，分析工作全部完成，项目的需求分析基本成功了

在这次需求分析中，我认为取得成功的原因主要是方法和工具选择得正确。在界面设计中采用了流行的辅助工具，对需求及逻辑模型的建立提供很大的帮助，可以更方便帮助自己理清思路。选用了选代法，把一些错误的影响在功能分析和界面分析的不断迭代过程中加以改正。在后期，以功能需求为主时，我主要依赖的是沟通工具和表格工具，这也说明辅助工具不是万能的，需求分析的关键之关键，应是与客户的交流与沟通。通过这次案例，我认为在软件的需求分析工作中，方法的重要性应远超过工具的使用，应当首先确定分析中的风险，把风险分类，用不同的方法去解决各类风险，而工具的选择不仅是要看影响力和名气，而是要真正为我所用，应把握其精髓，即是此工具到底可以对开发有什么帮助，而不是仅限于如何使用，我认为在需求分析中工具的作用不外予两个:一是实际系统与环境模型等的抽象工具，二是需求表达工具。第一类的代表是 Rose，第二类的代表是Word,WPS, Visio等,在这次项目中由于地理上的限制还用到了沟通工具,Web 浏览与E-mail服务系统。

最后我还是总结一下，在需求分析中工具方法都只是辅助项目成功的因素，真正的决定因素还是——“与客户的沟通”

企业应用集成的实践

摘要

为了向铁路各部门用户提供高可用、整合的信息，受铁道部科技司委托，我单位承担了“信息应用集成的研究”这一项目的研究和开发工作。本人作为该项目的负责人之一，担任了方案设计师的职务。该项目的目标是实现现有系统中的数据共享，有机的结合相关联的数据，搭建统一的使用平台，为今后铁路信息化更大规模应用集成建立可行、可靠的依据。本文主要从以下三个方面描述作者在该项目中的工作:确立企业应用集成的解决方案，选择应用集成规范和平台;在现有的铁路信息系统中选择二至三个，对应用集成的方案进行实践，分析并改进方案

正文

近年来，铁路信息化建设取得了突飞猛进的发展，特别是正在建设实施中的“铁路运输管理信息系统(以下简称TMIS)”工程。TMIS 是实现铁路运输管理现代化的一项重要工程覆盖了铁路运输组织管理的各个环节。从功能上来看，TMIS以货运管理为核心，分为列车预确报系统、货票系统、车号自动识别系统、货运营销和技术计划系统等多个子系统。从组织结构上看，TMIS 由铁道部、14 个铁路局、50个铁路分局和 2000 多个车站四级组成，目前TMIS 已经成为一个由多个子系统构成的、庞大的多级分布式应用系统。

在部、局、分局的数据库中，已经建立了能够实时接收数据的货票库、确报库和车号自动识别库，货票库主要用于货物运费清算、确报库主要用于实时掌提调度行车信息、车号自动识别库主要用于车辆位置查询管理。为了实现列车、机车、车辆的实时追踪管理，必须共享各子系统数据，同时为了实现各级子系统的应用集成，必须选择一个开放式的应用集成规范和平台，为此受铁道部科技司委托，我单位承担了“信息应用集成的研究”这一项目的研究和开发工作。由于在 TMIS 工程建设中的多年工作经验，特别是在货票子系统中担任系统设计师的工作经验，本人有幸成为“信息应用集成的研究”项目的负责人之一，担任了项目方案设计师的职务。

经过分析，我对该项目的目标总结如下:为实现现有各系统中的数据共享，有机的结合相关联的数据，应确立企业应用集成的解决方案，为实现各级子系统的集成，建立统一的应用平台，应选择一个开放式的应用集成规范和平台:为建立今后铁路信息化大规模企业应用集成可行可靠的依据，应在现有的铁路信息系统中选择二至三个，对应用集成的方案进行实

下面我就从三个方面对企业应用集成的实践进行描述

确立企业应用集成的解决方案

从集成的深度上来说，本方案包含了数据的集成，同时也包含了应用系统的集成。企业应用集成常用的方法有:基于客户端/服务器的方法、基于消息代理的方法、基于应用服务器的方法等。在这里我选择了基于应用服务器的方案，即通过建立独立的底层架构来连接企业的异构系统、应用数据等，如图所示:不同的子系统通过不同的适配器连接到应用集成服务器，应用集成服务器内部通过消息传递实现不同应用之间的交流。

二、选择应用集成规范和平台

从集成的广度上来说，本项目涉及部门之间的系统集成，同时也涉及了企业不同级(部局、分局、站段)的系统集成。为了保证各级系统的数据一致，加强各级之间的交流，应该从整体来考虑企业的集成方案。较好的方法是选择一个开放的集成平台，把不同级的应用纵向的结合起来，通过统一的门户信息网站向外发布信息。

目前，开放式企业应用集成规范和平台的主流技术有两种，微软公司的 COM+规范和Windows DNA平台，SUN公司的ETB 规范和J2E平台由于J2E架构的与操作系统无关的特性，为了更好的支持现有的不同级的系统，我选择了 EJB 和 J2EE 的组合如图所示，系统采用MVC 的设计模式Jsp 所在为表示层，提供数据的展示功能，Servlet 所在为控制层，处理表示层与业务层的关系;业务层由多种 Bean 组成，Session Bean 处理交互相关的信息，Transaction Bean处理具体的业务逻辑Entity Bean 与数据层交互。

三、应用集成方案的实践

为了实现列车、机车、车辆、货物的实时追踪管理，需要在现有的几个系统中提供近乎实时的系统集成和数据集成。这些系统包括:货票系统提供了货物的名称、重量、装货车辆、发送人、收货人等信息，车号自动识别系统提供了车辆的位置等信息，确报系统提供了列车的车次、机车号、车辆号等信息。应用服务器通过缩写各自适用的适配器连接这些系统。应用服务器上有一个匹配作业，当车号自动识别数据入库时启动的该作业，通过车号和通过时间，在确报库中匹配该车所在的列车、机车等信息，然后在货票库中匹配货物的名称、收发货人等信息，匹配后的信息写入动态追踪库，至此一次作业完成，同一时间段内，应用服务器上有可能有 n个等待匹配的作业，依次放在消息队列中，通过编码实现的应用集成程序统一调度，消息队列的实现选用 IBM的 MQ series。企业不同级《部、局、分局)的系统之间的数据更新不同步，造成各级之间的矛盾，通过数据同步服务器的加入，实现三级数据的有机整合，保证数据的一致性。数据同步后写入中央数据库，由三台集群的 web 服务器向外发布信息。同时满足铁道部路局、分局用户的使用，包括货票信息应用、确报信息应用、车号自动识别信息应用和动态追踪综合应用。编码工作量相对较少，系统响应时间快。

企业应用集成后，实际的效果证明本项目的系统方案设计到达了项目目标的要求，横向能够集成不同系统的相关数据，纵向能够提供统一的应用平台，并且扩展方便，通过编写新的适配器，可以集成新的应用系统，通过广城网和局城网的建设，能够加入更多的用户，同时，集成后的新增的动态追踪系统也成为越来越多用户的热点应用。应用系统集成后，信息通过相对统一的界面向外发布。由于用户的部门和级别不同，因此主要关心信息的角度各不相同，所关心信息的内容也有所不同，用户可能需要多次选择或点击才能得到想要的信息，引入 XML 技术，实现个性化的展示层，方便用户的使用，是我在该项目中的下一个工作目标。

论分布式数据库的设计与实现

摘要

本文通过XXX高速公路收费系统(以下简称收费系统)，来论述分布式数据库的设计与实现，收费系统是我公司近年来接的较为大型的项目，管理结构为三层结构:公司级、收费中心级、收费站级，各级之间即可独立的完成自身业务，又有自上而下的管理关系。收费中心、收费站均为三层 c/s 结构，公司级采取 B/s 结构。该系统的数据库也按照三层来设计，收费站存放本站的所有流水数据，收费中心存放所有数据，公司本部存放查询用汇总数据，收费站与收费中心使用事务复制来同步数据，而收费中心与公司本部使用快照复制来同步数据，并且使用分级的方法来测试收费站、收费中心与公司本部之间的数据同步

在本项目的开发过程中，我担任了数据库的设计工作

正文

2000 年 10 月一2001年12 月我司开发了高速公路收费系统以下简称(收费系统)，收费系统项目从管理层面分为三层结构:公司级、收费中心级和收费站级，公司本部:供领导、运营部、财务部等业务部门了解业务情况、检查工作，B/s 结构各部门通过 web 服务器查询数据库服务器，而公司数据库服器定时要求中心数据库服务器复制汇总数据。

收费中心:收费系统的管理中心·下达管理制度，管理数据到收费站，接收统计收费站的收费数据，上报汇总数据到公司，负责日常的管理工作。

收费站:具体进行收费的单位，收费车道的数据通过通信系统实时上传到收费站数据库保存、分类、汇总，并且实时传送收费中心下达的数据库管理，并通过通信子系统下载到车道收费机上具体实施，

系统采用三层 C/s 与B/S 的混合结构，收费中心与收费站为三层 cS 结构，而公司级头B/s 结构。我在项目中担任了数据库的设计工作，负责数据库的设计、测试及实施

数据库设计

此收费系统的结构较为复杂，分为公司级、收费中心、收费站三级管理结构，既可独立工作，又有管理的联系，数据实时传送到收费站数据库服务器，再实时传送到收费中心数据库服务器。 在数据库设计方面我们按物理的分布也分为三层结构。

在收费站，根据系统的需求分析的结果，一辆车通过收费站时产生的最基本的数据有:通过日期、时间、车型、收费类型及收费金额，因为收费标准不轻易改变，考虑到我们采用的是专用的车道收费机，存储量较小，所以收费金额项在此处不计入数据库，上传至收费站数据库服务器后，可以用车数乘以此类车型的收费标准而得到。当车道收费机上传数据到数据库时，还要加上工班、车道及收费员信息，保证数据的唯一性，所以我们把日期、时间、工班、车道、收费员、收费类型、车型设为组合主链，为车辆流水数据。收费员下班后还要上缴实收金额，因此还要保存实收金额，包括日期、工班、收费员及实际收费金额，为工班收费数据。在此基础上，分析、汇总数据，得到以下几类数据:业务类型数据，车辆流水数据、工班收费数据、车道开通情况、收费员上班情况，扩展的数据，为了查询、打印的方便、高效，流水表经过分类汇总，产生了以车道分类统计的车流量表《日、月)、以收费员来分类统计的收费金额表《日、月)及不收费车辆统计表;

管理类型数据，收费标准、收费员信息、收费站信息、车道信息、工班信息、收费类型信息，从全局应用的角度出发，各收费站存放本站的数据，收费中心的数据库则存放所有数据，开对数据进行完整性和一致性的检查，这种做法虽然有一定的数据冗余，但在不同场地存储同一数据的多个副本，能提高系统的可靠性、可用性，使系统易于扩充，也提高了局部应用的效率，减少了通讯代价，同时也使得各处理机之间的相互干扰降到最低。公司总部存放所有收费站的汇总数据，通过浏览器进行查询，

数据的分布

(1)在收费中心数据库服务器与收费站数据库服务器的数据关系中，由于收费站的数据是收费中心数据的子集，我们采用了水平分片的方式，通过并运算实现关系的重构。

(2)在收费中心数据库服务器与公司总部数据库服务器的数据关系中，数据是按照其应用功能来划分的，所以我们采用了垂直分片的方式

数据分布在多个地点，为了保证数据的一致性及完整性，我使用了事务复制和快照复制两种数据同步的方式，在收费中心与收费站之间使用事务复制，而在收费中心和公-司总部之间使用快照复制。

对于业务类型的数据，收费站在本地存放收费车辆的实时数据，而用户也要求收费中心也要实时的收费车辆数据，延迟不超过 2 秒，所以我采用事务复制进行业务数据的同步，收费站只需将更新的数据发送到收费中心的数据库即可。具体过程如下，把收费站的数据库作为出版者和分发者，收费中心的数据库作为订阅者，对收费站的数据建立快照代理，并在分发数据库中记录同步状态的信息，每一个使用事务复制的收费站数据库均有自己的日志读取代理，运行在分发者上并连接出版者。分发代理的任务是将分发数据库中保持的事务任务直接推动到订[阅者。当推订阅被创建时，每个为立即同步而建立的事务出版物通过自己的分布代理运行在分发者上并与订阅者相连。

而管理型的数据是在收费中心设置，虽然修改的频度不是很大，但在修改后即要发生作用，所以也采用事物型复制，收费中心为出版者，收费站为订阅者。将管理型的数据发布到各收费站。

由于公司总部不需要实时更新，所以收费中心数据库服务器与公司总部服务器之间的数据同步设置为快照复制，公司总部数据库中建立收费中心表的快照，对这些数据的修改在收费中心进行，把收费中心数据库服务器设置为出版者，出版物为汇总数据，公司总部数据库服务器设置为订阅者，快照代理将准备包含有被出版数据表的结构与数据的快照文件，在分发者上存储这些文件，并在分发者的分发数据库中记录同步任务。在收费中心数据库服务器上建立一个作业，设置为每天早上8 点更新一次(收费日的天为8 点到第二天8 点)，公司总部就能得到截止到前一天所有收费站的汇总数据

测试

数据库设计好了，就要对它进行测试。我们的测试策略为分步测试:首先测试收费站数据的正确性及完整性，在多台收费机上同时输入几组车型、收费类型的数据，查询数据库的流水数据是否正确，再看汇总数据是否正确，收费站正确后，再测试收费中心的数据的正确性、完整性及延时;再测试公司总部的数据正确性、完整性。

一开始我们把所有的表都建立在一个出版物中，但在测试中我们发现，由于收费站一个表的错误而造成的复制的中断，经常要重新配置复制，所有的表都要重新选择及设置一遍，非常繁琐，我们采取一个表建立一个出版物的方法来简化操作，只要恢复出错的复制，其他的复制仍然能正常执行，而且哪一个表的复制发生中断也很明确，不仅简化了操作，也加快了处理时间，就是日后用户维护起来也简单明了。

在设计过程中，基于查询及安全性的需要，我们大量的使用了视图，第一加快了查询速度，第二也防止了人为因素造成的数据的更改总结

按照以上的设计方案实施后，完全满足高速公路系统对数据实时性和完整性的要求，系统目前只在内部使用，而以后全省的高速公路收费系统实行联网，在外网上发布信息，那时数据的安全性及查询的响应速度将是我们考虑的重点。

论分布式数据库的设计和实现

摘要

本文论述《金蚕工程》的分布式数据库的设计和实现，该项目的设计目标是实现企业间茧、丝等的合同交易(交易规则和期货交易一样)、实时行情和成交数据的发布、茧丝历押和质押数据的发布，所有功能均要求既能在企业局域网交易大厅和 Internet 上进行，许多功能又要在苏州和成都分中心进行。系统从设计时就把基于分布式数据库应用的可用性和可靠性作为系统一个关键目标。为了达到系统的上述更求，系统分别从数据库设计、应用数据集成和测试以及分布式数据库部署等做了大量工作。针对上述各部分，本文论述了分布式数据库的设计和实现及遇到过的典型问题和措施，最后对系统改进，谈一些自己的体会，在项目开展期间，我担任了系统分析、系统设计与关键模块的编程等大量工作。该项目在2002 年通过了浙江省软件评测中心的评测

我于2000年底到 2002 年 6 月组织了中国市场由国家经贸部资助的《金蚕工程》。一、二期项目的开发，由于原有系统存在如下问题:(一)原有系统采用传统 c/S 结构，客户端运行在 DOS 平台，后台使用 Foxpro 数据库，系统处理慢，前后台数据一致性，并且Foxpro服务器在交易高峰经常莫名其妙的死锁和 Down 机(二)市场是中国最大的革经交易市场，由于会员单位不断增加，原有远程电话拨入设备严重不够用，系统又不能通过Internet 连接访问，进行合同交易和行情的及时查询，严重限制了市场的发展，(三)原有系统只部分实现了合同交易和资金清算，功能和企业发展不相适应。(四)由于会员在地区上分布不均匀，为了更好地服务于会员要求在满足一定条件下建立分中心交易系统。在这种情况下，市场决定开发基于 Internet B/s 结构和基于Xnetserver 通讯中间件(类似 IBM MQS eries 的通讯中间件)的4-Tier 结构的综合软件，分中心采用基于分布式数据库地应用系统。一期项目包括:基于 4-Tier 的合同交易系统和资金清系统，基于 Internet 的行情查询和信息发布的企业网站。二期项目包括:蚕丝质押、仓库管理系统、 Internet 蚕丝质押查询系统和分中心交易和资金结阵系统。

鉴于该项目业务比较复杂，流程比较多，系统要兼顾企业交易大厅会员、远程 Internet交易的会员和分交易中心会员，项目完成时间短等特点，为了既要项目的按期投产又要实现基于分布式数据库的分中心交易和资金结算系统，我从数据库选型、数据库设计、应用数据集成和测试以及分布式数据库部署如下工作。

(1)数据库选型现在的主流数据库一般都可以按分布式进行部署，例如:SQL Server、Oracle、Informix和 DB2 等由于一期项目的数据库平台是选择了 Oracle 7.0，经过了近一年的运行，其数据自动备份、多用户并发处理性能、磁盘表空间管理、Web 数据发布等表现良好，我公司又由于开发过基于该平台的分布式应用系统，公司对其分布式实施也有相当的经验，所以经我们开发部相关人员的讨论，我决定在各分交易中心继续采用 oracle 数据库来实现，其分布功能主要基于 SQL*NET来完成

(2)分布式数据库设计，由于各交易品种的每节交易价格由市场的交易大厅决定，所以各分中心必须在每节交易开始前取得相关的交易数据。各分交易中心必须保留其会员已经交易成功的买入和卖出交易数据，并根据会员需要进行资金结算。经对分交易中心充分业务需求分析后，我觉得分交易中心的主要功能还是和主市场交易中心(简称:主中心)功能是致的，只不过分交易中心的会员数比较少和无需保留各节的历史交易行情，所以，分中心的主要数据库中的各表还是照搬主市场数据库的各表，分中心只保留各自的会员其础数据和成交数据，保留会员历史交易数据，只保留当前的各节的交易行情，不保留历史行情。主中心必须保留各分中心的各项明细数据，主中心也必须及时计算分中心会员的汇总资金，所以主中心必须增加分中心汇总资金表

(3)数据集成。为了保证分中心及时下单，必须保证每节的交易行情要及时的传送到各交易分中心。节处理最后一步必须把下一节的交易行情传送送各交易分中心。同时下发给分中心的数据还有，分中心本节各会员的成交数据。由于主中心保留各分中心的各项数据，所以，分中心有新的会员加入必须同时更新分中心和主中心数据库，分中心会员资金有变动时也必须同时更新主数据库，由于各会员只能在当日交易结束后才能进行数据平仓，所以分中心平仓数据汇总后同意发送到主中心进行平仓。在上述设计的数据库到数据库操作的数据完整性和一致性由数据库的二阶段提交(2 Phase Conit )来保证由于Oracle 是一个比较成熟的数据库平台，又由于每次事务都不大，所以运行到现在也没有发现数据不一致现象，没有出现“单边帐”，数据处理也比较快。为了近一步保障各中心数据的一致性，我还做了一个同步程序，由主中心发起，对主中心和分中心数据进行比较，该程序可定期进行。(4)测试。由于一期项目已经运行了相当长的一段时间，系统已经相当稳定了。由鉴于2 Phase Conmit 出色表现，所以基于分布式的测试没有觉得和集中数据库有太大的区别。唯一的感觉是在第一次建立远程数据库连接时，连接速度比较慢(有时超过 20 秒)。为了提高测试速度，我在同一个局域阴中安装了三套 0racle，分别充当主中心和两个分中心进行测试(5)部署分布式数据库，和集中时式的数据库不同，采用分布式系统，必须配置SQL*N ET。其他的 oracle 组件和子系统安全同本地安装数据库一样。

分布式数据库在逻辑上属于同一系统，使得应用不必关心远程数据库的物理位置，就可以像访问本地数据库一样访问远程数据库，采用分布式数据库可充分提高系统的处理能力、均衡网络负载，所以该分布式数据库应用方案在银行代收、代付业务处理、保险代理点等单位和机构中大量采用。但由于近些年来通信基础建设比较迅速，特别是 2M、10M和 100M 光纤的推广(100M 电月租费仅为 800 元)，又为了节省下属网点的机房费用，各单位又不约而同的采用的集中方案

[缺点和需要改进的地方]

(1)分中心或主中心由于不明原因而 Dowm 机后，由于 racle 有自动恢复功能，可能造成对方数据库会收到过时的垃圾数据。该问题现在通过手工方式解决

(2)由于分中心没有收到下一节的交易行情，可能会造成分中心会延时交易，分中心的主控系统可通过主动拉取数据来解决

[结束语]

《金蚕工程》项目是成功的，年交易量已经有 100 多亿人民币。通过该项目的顺利投入运行，中国茧丝绸市场不仅牢牢把握住了中国的茧丝行情，随着我国进入 WTO，中国带丝绸市场在世界上也有举足轻重的分量!总之，中国的软件产业应该走自己的路，只有通过“已过程为核心，以度量为基础，已人为本”的管理政策，根据我国的国情、软件业和公司的现状，只有通过“干”，才能有实绩，才能实现“以信息化带动工业化的大思路”

论分布式数据库的设计和实现

摘要

分布式数据库系统把应用所需的数据存放在多个数据库服务器上，完成某个数据操作要涉及到访问多个服务器，这适用于某种特定需要的应用。我在主持设计开发的一个 MIS 系统中，为了达到了在低速网络通道下有效提高应用程序性能的目的，使用了 sybase 的分布式数据库技术。我设计的这个系统是采用典型的 c/s 结构，但许多客户端连接服务器的网络采用电话线拨号，速度有限，传统 windows 界面的客户端应用程序相应速度比较慢。考虑到 B/S结构也避免不了大量数据从服务器端传输到客户端，我认为 WEB 界面并不能有效解决这个间题，所以采用了优化数据库结构的方法，把数据分两部分存放，基础数据放客户机，会员资料主要采用键码放服务器，应用程序再现数据时从服务器取键码，到客户机取对应的解释，由于键码的数据量少，网络传输便快。在构建这个分布式数据库系统的过程中，我着重研究并解决了数据同步和事务协调的问题，取得了良好的应用效果。我认为，分布式数据库系统的技术在 Intenet 时代正当其道，大有发展前景。

正文

分布式数据库系统把数据存放在多个数据库服务器上，当应用提取所需数据时，要访问多个服务器，综合多点数据才能完成。

分布式数据库技术在很多场合得到了应用。譬如某企业随着业务量的扩大，原有数据库服务器已经达到了容量和性能极限，如果不希望丢弃原有投资，可以建立另外一套新的数据库，跟原有的系统组成一个分布式数据库系统，给应用提供透明统一的数据访问，还有，如果某企业分成多个业务部门，而且地域分散，可以在某个部门放置单独的数据库服务器，用于存放该部门最常用的数据，而部门和部门之间相互引用的数据可以通过分布式数据库技术来方便地完成。分布式数据库不是简单地把集中数据库分散实现，而是针对某种特定应用需要而诞生，它必然具有自己特有的性质和特征，需要在上面做许多的工作，来满足应用的要求。

我在设计、开发一个 MIS 系统时，针对应用的需要而引入分布式数据库技术，取得了良好的效果。

该系统针对会员资料的管理而设计，用于管理会员入会、缴纳会费、申请资助、办理资助审批、关系转移、退会和注销手续等等业务流程。分三个级别的应用权限一一基层单位级、总公司级和集团公司级，各个级别只能操作各自范围内的业务数据。该系统采用典型的 C/S结构，后台数据库采用 Sybase，前端应用采用 开发工具来设计标准的 windows 操作界面我在其中任系统分析和数据库设计的角色，担任了调查业务需求、业务建模和数据库建模

数据库设计以及指导应用程序测试、优化系统和应用的性能等等一系列工作。由于客户端地域的分散，遍及多个省境内，许多使用该系统的基层单位连接服务器数据库的网络采用电话线拨号方式，速度有限，在使用客户端应用程序时感觉界面速度很慢。经过分析，认识到许多操作都要从服务器中取数据，速度慢就慢在数据访问上。服务器是没有性能瓶颈的，问题出在网络速度上。不可能要求众多使用客户改善和升级他们的网络，只能充分挖掘软件的潜力，来适应这种低速网络的使用模式。

经探讨，结合关系数据库的知识，认识到，应用程序的每一次数据库操作，都要访问多个相关联的表，其中，有会员资科表和基础数据表，会员资料表中存放许多的键码值，在基础数据表中有键码相应的解释，键码值的数据量比较少，而基础数据是静态的，几乎不会更改。如果考虑把会员资料放在服务器上，基础数据放在客户端，当应用程序中访问数据时，总是从服务器上存取会员资料，从客户端提取会员资料中键码的相应解释。由于键码的数据量少，便减少了网络上传递的数据量，从而提高了界面的响应速度。同时考虑到基层单位总是操作自己所属的部分会员，增删转移操作少，会员列表比较固定，而每一项业务操作都涉及到要从会员列表中查找定位到某个会员，所以会员列表是最常访问的数据项。把会员列表从会员资料数据中抽取出来，也放置在客户端，这样，便进一步改善了性能。

同时考虑到基层单位总是操作自己所属的部分会员，增删转移操作少，会员列表比较固定，而每一项业务操作都涉及到要从会员列表中查找定位到某个会员，所以会员列表是最常访问的数据项。把会员列表从会员资料数据中抽取出来，也放置在客户端，这样，便进一步改善了性能。

把数据分散存放只是工作的第一步，接下来要考虑应用程序怎样访问这种分布式数据开发应用时，如果每一功能都针对两个数据库进行，就带来了很多麻烦。所以，我们研究了Sybase 的分布式数据库技术，决定采用了 CIS(组件集成服务)部件，来合并两个数据库成一个统一的分布式数据库。应用程序只要连接一个数据库，就可以透明统一访问到两个数据库中的数据。

该技术具体实施方法是，在客户端数据库中建立一个对服务器数据库的远程访问服务名包含访问地址、登录用户名、登录密码等等关键的连接信息，并且对服务器中会员资料数据表建立一个本地代理表，结构和服务器中远程表完全一样，它是访问服务器中会员资料的中转和代理。客户端应用程序访问本地代理会员资料表时，实际上是通过预定义的远程访问服务名中包含的连接信息到服务器中对应的实际会员资料表中访问数据。这种访问对于客户端完全透明，感觉不到是从物理上独立的两个服务器中存取数据。所以，这种数据库结构是典型的分布式数据库。

部署这种分布式数据库不是难事，只要在客户端和服务器上安装 120版以上的数据库服务器，在客户端服务器上建立远程服务名和代理表即可。由于 Sybase 数据库的安装支持脚本方式，在客户端应用程序的标准安装过程中，嵌入 Sybase 数据库的安装和配置脚本，就自动化地完成了所有工作。

在实际使用该分布式数据库系统的过程中，遇到了几个问题。第一，数据同步。客户端基础数据不是绝对静态的，也有变化，因此在服务器端要设置一个统一的基准，称为主点数据，客户端总是复制使用，称为复制点数据，如何及时感知到服务器端主点数据的变化，有效率地复制到客户端，是个难题。Sybase 针对这种应用场合，提供了复制服务器技术，但为了避免过于复杂，我们实际采用应用程序来管理同步。当服务器端主点数据有了更改时，保存一个相应的标识和时间戳，客户端应用在登录服务器时，检查这种标识，一检测到了数据有更新，就首先下载，然后再进入系统正常使用。这种方法实现起来，增加了额外的开发量且不能判别绕过应用程序对数据的直接修改，但是，是最简单和有效的方法。

第二个问题是事务协调问题。物理上独立的两个数据库，在协同操作时，如果服务器正好停机或者网络故障，完整的一个事务没能完成，就会“事务崩溃”虽然 Sybase CIS 内了两阶段提交技术，能够自动恢复，但是应用程序在这种情况下，敏感性不够，操作界面会无端凝固，影响了使用的方便性。我们针对 PB 对于连接的判断和感知，用了一个小小编程技巧，使应用程序能够及时感知到数据库连接故障，及时停止和恢复事务，使操作界面表现友好灵活。

以上遇到的这些问题，都找到了解决办法。分布式数据库技术的应用并不是非常复杂，它往往为解决特定问题、满足特定需要而被采纳，使用得当，会给应用带来了许多便捷。

在当今信息社会里，互联网络带来了相互连通的便捷，而且知识爆炸，数据的分布式访间是个必然趋势。潮流兴起的 DL 技术，提供了各种平台数据库之间的一个公共数据访间标准，可能会用来构建更加灵活、适应性更强的分布式数据库技术。

论信息系统的架构设计

摘要

本文讨论医保通零距离实时赔付系统项目的架构设计。该系统主要实现了中国人寿保险公司通过与医院合作，让中国人寿客户在出险住院并完成治疗后，即可获得实时的健康险理赔服务，从而在提升保险公司服务的同时减轻病人经济负担、减少客户理赔困难。在医保通实时赔付系统设计架构中，整个系统中分为B/S 结构的管理中心端与C/S结构的医疗机构前端两部份。在管理中心端采用J2EE 架构，使用了与传统 EJB 为核心的重量级架构有所不同的轻量级架构方式，其中主要使用 spring 框架作为系统的基础平台，充分体现了 sping 的高开发效率、易测试维护性及应用服务的可移植性等优点。同时，在架构设计中，充分考虑了系统的可扩展性、稳定性、安全性、可维护性、灵活性等因素。在本项目的开发过程中，我担任了系统架构设计与项目管理的工作。该项目从目前推广与应用情况看，达到了项目的预期目标，得到了各级公司的一致好评

“理赔难”一直以来都是各大商业保险公司与参保客户所关注的重要问题，为解决该问题，中国人寿保险公司提出了商业保险的实时赔付系统一中国人寿医保通零距离实时赔付系统，该系统是国内首个用于商业健康险的实时理赔服务系统。系统主要通过中国人寿保险公司与医院合作，将常规保险理赔工作从事后理赔调整为事中理赔，也就是将以往的串行工作方式“客户出险一>住院一>出院一>理赔开始一>理赔结束”，改为了并行方式即客户住院时也就开始了理陪工作，当客户出院时理赔工作同时结束，有效地缩短了理赔时间。医保通实时赔付系统的出现，提高了保险公司理赔服务时效、降低了保险公司调查难度，保证了理赔调查的准确性，加强了理赔风险管理，降低了暗付率，同时，为参保客户提供了方便的理赔服务方式，使客户在住院期间可少缴医疗保证金，减轻了客户住院的经济压力，让客户治疗出院时即可获得理赔，免去了客户理赔奔波等烦心事医保通系统第二版于 2006年底开始全新开发，并对系统功能及系统架构进行了全面改进，在通过公司近几 30 位员工的共同努力下，该版本于 2007 年6 月通过客户验收我在本项目的开发过程中，担任了系统架构设计与项目管理工作。

信息系统架构设计是软件需求分析与软件设计的桥梁，架构在软件开发中为不同人员提供了共同的交流语言，体现了系统早期的设计决策，为系统的开发提供了强有力的支持。好的架构将奠定优质的信息系统，同时好的架构需要源于对需求的充分了解。因此，在进行架构设计前，我们对软件需求进行了充分的了解与分析。

通过对需求的了解与分析，我们知道该项目主要干系人员是保险公司(包括管理人员与各岗位工作人员)、医院工作人员及客户，真正使用与操作的人员是保险公司与医院，他们分别有各自的职责，分别负责不同的工作内容。从系统功能上区分，保险公司主要负责各项管理工作及众多的统计分析，而医院则主要负责对客户住院信息与诊疗信息的采集及进行理赔金的垫付。系统的所有数据与信息都必须存储于保险公司。

在软件功能上，医院需要使用的功能相对简单，保险公司需要使用的功能则复杂很多在软件的使用环境上，由于保险公司多年来一直较重视信息技术的发展，已建立有良好的网络及信息技术平台，而医院则不同，由于国内医院众多，其各自对信息技术的开发与利用各不相同，甚至某些小型的卫生院目前都没有安装使用计算机。保险公司领导与医院领导对软件的关注点也存在差异，保险公司领导主要关心软件能否实现预定的各项功能，能否达到预期的管理目标，而开发与运维费用则能少则少，成为了他们次要关注内容，对于医院领导来说，医保通系统的实施给其带来的显式经济收益不多，反而会增加其成本的投入，因而他们会考虑更多的成本投入。最终，我们总结出以下几点:

1、软件在保险公司与医院都需要有操作界面，医院在本地准备与组织数据，需要进行数据通讯时再进行网络联接，不需要实时在线操作，以减少网络使用费用的支出:2、网络连接上需要提供多种连接方案，对于使用量小的医院，可选择拔号连接方式，对于使用量大的医院可使用ADSL或光纤进行VPN接入，

3、医院端需要提供多种与医院已有管理系统《HIS)的接口方式，便于医院重复利用已有信息数据，减少重复录入;

4、医院端必须提供简单的信息录入方式，包括入院信息、诊疗信息及出院信息，使没有HIS系统的医院能进行信息的录入工作;

5、保险公司端则需要在结合功能实现的基础上，更多的考虑系统的稳定性、安全性可扩展性、灵活性、可维护性等方面:

6、医保通系统将与保险公司核心系统及众多的 HIS 系统进行信息接口，所使用的信息编码应符合国际、国家及行业编码规范，

7、最大限度地降低系统开发及运维成本。

基于这些特点，我们将整个系统分为 B/S 结构的管理中心端与 c/s 结构的医疗机构前端两个部份。在管理中心端采用J2EE 架构，其中主要使用 pring 框架作为系统的基础平台。c/s 结构的医院端软件在整个系统的架构中被视为一个表现层，通过专用的通讯模块与管理端实现数据接口，而对于医院来说，他又是一套独立的应用软件。如下图所示:

从图中可以看出，本系统是一个典型的多层轻量级 J2EE 架构，主要分为表现层(管理端表现层与医院端表现层)、企业应用集成层、业务逻辑层、数据访问层。在表现层，医院端通过 TCP/IP 方式和中心端进行数据交互，可看作系统在医院端的表现层，通讯模块是医院端与管理端数据交互的主要途径，而管理端表现层则以JSP 及报表等多种方式将数据展示出来，供用户使用，管理端用户操作主要集中在这一层Webwork2作为轻量级的 MVC框架，能够较为容易的与 Spring 进行集成，同时，优雅的设计提供了良好的扩展接口，可以有多种的数据表现形式。企业应用集成层(EAI)，所涉及的数据较多，提供从多方进行数据采集，如保险公司已有的三套核心系统及社保系统等。此层的作用即是为与其它企业应用提供数据交互的接口。

业务逻辑层，是系统的核心，它负责处理系统中的各类业务逻辑。它是以 Spring 作为基础平台，借助它的强大功能，以轻量级的 POJO 作为基础，即可完成复杂的业务逻辑处理

数据访问层，因 Spring 提供了良好的数据访问支持，如JDBC及事务支持等，使得数据访问较为容易，

该架构中各层相互间以松耦合的方式进行联系并负责各自的工作。各层在应用部署时可合并部署也可分开部署，在工作负荷较小时，所有层可合并部署在同一服务器中，如果某层工作负荷增大，则可将其独立出来部署于其他服务器中，或以服务群集的方式进行部署，以提高系统的整体运行效率。

总的来说，该架构充分体现 sping 的高开发效率、易测试维护性及应用服务的可移植性等优点，同时也能体现出该系统的可扩展性与灵活性。从目前推广与应用情况看，达到了项目的预期目标，得到了各级公司的一致好评。但该架构仍存在其缺点，目前，保险公司已有三套信息相对独立的核心系统，虽然医保通系统通过 EAI 层很好地解决了与之分别相对的信息接口，但仍存在很多“信息孤岛”，该架构不利于解决信息系统的整合。在架构设计之初，医院端与管理端通讯并未使用专用通讯模块，是将两个软件看作是相对独立的软件，其通讯则是根据不同交易使用不同的处理过程，这样将导致开发与运维工作量的增加，甚至影响到系统的稳定性与安全性，同时也意味着相应成本的增加。在进行架构设计论证时，有员工对此提出了新的看法。其方法是将通讯处理过程进行统一，形成独立的数据通讯层，并负责网络通讯的安全管理，所有通讯工作都需要经过该层，但他不对通讯的具体内容进行处理，也就是说不管通讯内容或格式有什么变化，其通讯翅都不需要进行修改。从而降低了开发工作量，减少了对通讯的运维，也提升了系统安全性、稳定性与可维护性。通过这事，我们再次体会了在软件开发中需要大家的共同努力，集中大家的智慧，团结才能发出更大的力量。

论新技术的引进

摘要

根据国家税务总局对税务系统内所有系统进行集成与整合的需求，我所在的开发单位组织了全国金税工程防伪税控系统网络版的升级开发工作。该项目工程浩大，要求在具有严格的安全、可靠性能的基础上，将基于 DOS 操作系统、Foxpro 数据库的原单机版防伪税控子系统集成到基于网络的、大型数据库的“集中存储、分布操作”的分布式系统中来，并实现与基于AIX等操作系统和 oracle数据库的稽核协查等其他应用系统的数据共享和互操作在项目中，我担任项目主管，主要负责系统规划和组织实施工作。我在将近一年的可行性研究、需求分析、系统研发与试点工作中，通过引进面向对象设计方法、采用 B/s/s 三层体系结构、利用群集实现负载平衡等新技术，使该项目取得了圆满成功，受到了用户的一致好评。但是现在看来，由于新技术的使用，怎样实现软件开发公司对新技术的渗透、怎样开发自主产权的中间件等问题，需要我们在今后系统开发中做进一步探索

正文

2003年元月，我作为项目主管，有幸参与了全国税务系统金税工程防伪税控系统的升级开发工作。防伪税控系统主要由基于增值税发票的企业开票、企业发行、报税、认证、发票发售等五大子系统组成，系统组成模块如图 1 所示。具体流程是:企业在当地税务机关通过个业发行系统取得用于开县增值税发票的相关设备(金税卡与 IC 卡)和权限，再到发票发售系统领取增值税发票，通过企业开票系统开出发票后产生发票明细和申报纳税数据存入 IC卡中，然后、企业持 IC卡到税务机关由报税系统进行报税、并将取得的可抵扣的发票数据通过认证系统进行认证后，经过 Internet 上传到税务机关，所有数据经由税务机关处理后，传递到其它系统进行处理，系统要求具有严格的安全、可靠性能，必须建成基于网络的，分布式实时数据库处理系统，达到数据共享的目的。在此次开发过程中，我特别强调在认真细致的需求分析的基础上，最大限度地引进新技术新方法的思想。

一、采用面向对象分析方法

防伪税控系统网络的应用将极为广泛，涉及全国所的有税局和一般纳税人企业，具有基于增值税发票的开票、认证、报税、传递等业务操作，面对如此复杂的系统，怎样从中理出头绪来，最大限度满足用户要求要，实现整个开发流程的“无缝”连接，需求分析是最重要的环节。我在认真研究和分析旧单机版开发文档后，提出采用面向对象的开发方法。系统的主要业务范围是增值税专用发票的防伪与税控，通过对整个系统流程的分析，我抽象出“发票、操作员、安全卡”等类，从类出发，建立对象，再通过对象类之间的继承、聚合关系、消息和关联，分别建立开票、认证、开票、企业发行等子系统和共用的系统管理等模块，并通过操作员类中权限属性实现各子系统的权限控制。通过面向对象分析方法，不仅提高了系统的开发效率，而且提高了软件的复用性和可维护性。

在工具的选择过程中，我们选择了现在十分流行的系统 Rationa 系统系列工具，包括Rational RoseRup、Soda和 Requisite Pro等特别的，从防伪税控系统的对于增值税发票的防伪和税控功能可以看出，整个系统具有很长的生命周期，必须面对税务系统因为经济发展而出现的多变的需求变更，并且，又必须服务于税务系统其它的如征收管理、稽核协查等应用系统。所以，要求系统具有很好的可维护性、可扩展性，而公司在原有单机版的升级上，因为没有统一的、规范的开发文档而吃尽了苦头。所以，我决定采用 Requisite Pro作为我们现在和未来的系统需求管理工具。我们在对经过详细的用户调查后，按照我们的基本理解写成了某本需求，交给用户进行评审和补充，再形成正式的需求录入到 Requisite Pro中去，并记录需求的变化情况、需求之间的依赖关系，实现需求的全面管理。公司决策层在认真听我的汇报后，表示了很高的兴趣并给出支持，使我更加增强引入新技术进行开发的决

但是，新技术并不意味着是最好的或是最适合的。在引用新技术中，我特别注意它的负面。面向对象分析方法虽然有效地表达和描述了现实世界，但有时也会忽略外在的表层的需求，有些关键需求要等到用户使用后才会提出，然而等到用户使用后再维护是不现实的，作为原型开发模型中的原型也是收集用户需求，描述与解释需求的一类相当有效的方法工具。在分析过程中，为了更好让用户了解我们的系统，更完整提出需求，我沿用了公司熟用的原型开发方法。通过利用 Access 开发出系统原型，让用户试用，取得很好的效果。所以在新技术引进过程中，我们熟悉的优秀的开发思想与方法不能丢，这是我们要特别注意的地方。

二、用 B/S/S 层件体系统结构

瘦客户端设计表示层。进行系统设计时，采用客户/服务器(C/S)模式还是采用浏览器应用服务器/数据库服务器的(B/S/S)模式，成为我们开发小组成员争论的焦点。我认为，采用哪种系统体系结构相当重要，决策时，不但要考虑系统运行成本，还要考虑系统运行的稳定性、可靠性、可维护性以及业务需求变动时的可扩展性。新系统将所有数据集中到市级税务机关(参看图 1)，如果将业务处理逻辑分散到客户端或数据库服务器，虽然可以低成本运行，但是，我们分析得到，同一时刻，区县级税务机关和企业到服务器的连接可能达到30-1000，在发达地区可能更多，这显然击中了 C/S 模式的要害，并且，税务系统的需求经常变更，所以，我们决定采用应用服务器集中处理实现业务逻辑，事实证明，这个决策是正确的。新系统在沿海五省四市试运行时，不仅稳定、可靠，易维护，而且，客户端采用  浏览器，受到了维护人员和广大操作者的好评。

业务层引入 WEBLOGIC 应用服务器。众所周知，WEBLOGIC 是用于开发、集成、部署和管理大型分布式 WEB 应用、网络应用和数据库应用的 Java 应用服务器。可以说，采用 Weblogic的主要理由有:首先是税务现有应用系统的异构的数据库平台如用于(如用于 CTAIS 征管系统的 Sybase、稽核协查系统的 0racle、其它的 SQL Server);再有，对多种操作系统的支持包括 NT 系列、AIX、Sco 等；并且，税务的系统需求经常变化，比如在我们的开发过程中，因为国家税务总局推出“一窗式”管理，税局要求我们的报税系统有向征管系统传出某种格式数据的功能，我们利用 WEBLOGIC 对 XML的支持，很快地解决了这个需求。总之，这要求系统具有很好的可移植性和可伸缩性，应用服务器能使程序员从常规设计中脱离出来，集中精力组织和优化业务逻辑。我特别注意了服务器的选型，主要从开发效率、可复用性、可伸缩性和可扩展性等几个方面考虑。

三、利用工作站实现负载平衡

企业将取得的可抵扣的增值税发票经过认证系统认证后，形成加密的认证数据，经过与联网传到税局的外网 WEB 服务器，再由 WEB 服务器传到内网的应用服务器进行解密和税局再认证。对于一个市级税局，这种发票数据可能非常宠大，如果由应用服务器信中进行解密，很显然，时间上是不充许的，并且，可能造成应用服务器的死机。我提出采用解密工作站队列处理解密工作，让应用服务器统一分配各工作站的工作量。这样，大大地减少了应用服务器的工作量。

综上所述，由于采用了面向对象的系统分析方法，B/S/S 系统体系结构、解密工作站实现负载平衡等新技术，提高了整个系统的开发效率和质量，使新系统按计划完成，且具有很好的安全性、可靠性、可维护性、可扩展性和外部接口。但是，由于新技术的采用，也使我们产生了一些新的问题。

怎样让员工理解、支持和掌握新技术，引进新技术，将打破开发人员习惯的开发方法和程序设计方式，这种习惯的打破，往往要付出更多的精力和时间，如果靠权力或压力来解决只能是一种表面现象，我认为，关键是要营造一种引进新技术进行软件开发的文化氛围，让软件公司开发人员学习并引进新技术到我们的开发中来形成一种习惯，怎样营造这种围是我们管理领导层常思考的问题。

怎样开发自主产权的中间件，我们的应用服务器采用的是 BEA公司的 WEBLOGIC 中间件。虽然，它提高了我们新系统的开发效率和安全性和平台无关性，但是，也大大提高了我们的软件开发成本。中间件在我国具有很大的市场和利润空间，我想基于中间件的开发，首先要把握它的市场价值，然后在开发上注重它的通用性。