论SOA技术的应用
摘要：
本人于2010年7月参加国内某某知名港口供电业务系统的开发工作，在该项目中主要担任系统架构师，主要负责该系统架构和网络安全体系架构设计。经过近20年的港口信息化建设，港口供电系统已经建立了一些应用系统，但是，随着港口供电业务的发展，有些系统已经无法满足目前供电业务需求，同时存在已经开发的系统之间信息共享能力弱，系统集成度较低，系统扩展难的现象。 为了解决供电系统中复杂、分散、异构的数据信息之间交换，实现数据的高可复用性，同时适应新的业务需求，开发新的应用系统以适应日益增长的港口供电线系统信息化需求，实现系统平台的易扩张性，易集成的特性，在供电业务系统中，我们采用WCF开发技术，建立了SOA架构。目前该项目已于2011年7月完工，从运行效果来看，达到了预期的目的，得到了同行和用户一直好评，也说明SOA技术对实现企业信息系统的开发有着非常重要的意义。
正文：
本人于2010年7月参加了国内某某知名港口供电业务系统的开发工作，在该项目中担任系统架构师，主要负责系统架构和网络安全体系架构的设计。经过近20年的港口信息化建设，港口供电系统信息化建设已经取得一些成绩，建立了多个应用系统，如劳资系统、调度派工系统、财务管理系统、电费管理系统等。但是由于不同的系统在不同的时期开发，运行在不同的平台上，采用不同的开发技术和规范标准，导致"信息孤岛"现象存在，系统之间数据共享和交换较为困难。按照合同规定，该项目必须在1年内完成。为了在有限的时间内，开发出高效的应用系统，我们必须采用科学的开发方法，经过分析，我们采用WCF开发技术，运用SOA 架构来实现系统的功能需求。 经过需求分析，我们将该系统分为电费管理、财务业务一体化管理、安全护品管理、机电设备管理、物资管理、生产调度管理、流程申报管理、网上办公管理、工程项目管理、报表及领导查询管理模块。在该系统中，我们前端程序采用微软的.NET平台中的C#进行开发，数据库采用oracle进行数据存储。通过对系统需求分析，我们采用以下方法实现： （1）电费管理模块虽然已经有该应用系统，但是目前的电费管理计算方法已经发生很大变化，在新的系统中必须按照最新的电费计算方法开发，但是很多基础资料，我们应该导入到后台数据库中。因此该部分应该采用淘汰老系统，复用有价值的数据方法开发。 （2）财务业务一体化管理、工程管理、流程申报管理、报表及查询过管理是在新系统提出的新业务需求，需要全新开发。 （3）安全护品管理是我公司以前帮供电业务系统开发，而且也是基于WCF开放技术实现的，在新系统中，可以将此系统直接集成到新的供电业务管理系统平台下。 （4）机电设备管理、物资管理、生产调度管理虽然已有的应用系统基本能满足目前的业务需求，但是由于开发技术比较落后，系统维护困难，此外数据共享能力差，我们决定采用将数据集成到新的业务系统中，前端应用重新开发。 在该系统中，我们采用以下开发技术实现供电业务系统功能，系统采用层次架构设计风格来实现所有系统功能，在该系统是通过四层架构（client/contract/service/Host）的方式实现的。 首先，我们通过需求分析，将用户需求分解为一个个服务。由于该系统涉及港口供电业务系统方方面面，在该系统中需要编写很多服务。我们在前端编写的客户端界面以插件（plugin）的形式进行注册，各个客户端界面调用的服务通过统一的端口，以申请访问服务器上的服务，在该系统中具体是通过显示指定服务，同时依赖契约层方法实现和服务器上服务关联的。安全护品模块是我公司开发的，所以可以直接将该部分界面注册到开发平台下。 其次，中间契约层实现提供服务接口功能。中间层既要被服务层所用，也要为客户端所用。我们通过契约层将所有的服务操作暴露给用户，同时实现将所有的接口转换为服务契约，客户端所有需要的服务也在契约层上进行查找，客户端无须知道每一个服务（service）是如何实现。中间契约层实际上就是定义了在该层有哪些可用的操作，以及每个操作的方法签名。再次，服务实现层具体实现如何完成每一个服务，所有的服务层要和契约层相关联，在该系统中服务层通过注册表以访问数据库，实现和数据库相关的所有操作。Host层的本质就是把一个Service置于一个运行中的进程中，并以Endpoint的形式暴露出来，并开始监听来自Client端的请求。Host层通过XML语言描述实现和服务实现层以及契约层相关联。等所有的系统功能完成后，将所有的服务注册部署到相关的应用服务器，以提客户端申请服务成功查找，进而实现系统的通信功能。 通过采用这种面向服务的架构给系统带来了很大益处，实现了系统的高可复用性。如安全信息管理模块、物资管理，港口其他单位的信息化需求较为相似，以后在为其他企业开发项目的系统的时候，只需要为该企业开通权限，允许调用此服务即可实现系统功能。对于以后新出现客户需求，只要添加新的服务接口就可以，不需要搭建新的系统架构。同时通过此层次架构的开发，增强了系统网络安全性，由于各个层次的功能明确，客户端将无法直接访问数据库层，取而代之的是专门的应用服务器去访问访问服务，而其通过对服务器的访问安全设置，提高了对数据库的访问安全性。此外，大大提供企业应用的集成度，在该系统中，港口供电系统的所有应用被集成到一个统一的平台下，如财务部门、劳资人事部门、生成管理部分都需要调用人员信息，在统一的系统平台下，该信息只要一次完成，多次调用即可，打破了传统的同一个界面在不同的应用系统中要重复开发的现象。 该系统已经于2011年7月，成功通过了供电业务部门的验收，大大提高了港口供电系统信息化管理水平，提高了港口供电系统生产效率，得到了用户的肯定。但是目前该系统由于开发时间有限，该系统仍存在一些需要改进之处。由于港口供电业务系统平台注册的服务很多，系统用户也很多，有些服务调用响应时间较长，如电费收取模块本身计算较为复杂，在加上服务查找时间，导致客户端获取数据较慢。在今后，我们对采用层次架构风格系统要采用将应用服务器进行分类，将服务按功能发布到不同服务器上，同时要提供备份应用服务器，当其中一台服务器无法工作时候，备用服务器要立刻启动去工作。以较少服务的响应时间和保证系统通信正常。由于在该体统中数据共享程度高，在不同系统间进行数据读取时候，要注意对输入数据的校验，如我们发现在人力资源管理系统中输入的数据有些格式错误，数据不正确，这就要求系统提供智能化识别功能。同时对系统出错的时候，要能够有一定的容错功能，要提供回滚功能，如在此系统中的流程申报出错，要提示与此相关联的所有操作都要撤销。 在该系统中，由于使用了SOA技术，大大提高了系统开发效率，节省系统开发和维护成本，使系统具有更好的开放性、易扩展性，以及可移植性。从该项目完工后使用效果看，到达了预期目的，得到了用户的好评。在今后的日子里，本人一定会更加努力钻研专业基础知识，提高自身水平，为国家信息化建设尽自己绵薄之力。
论SOA在企业信息化中的应用
摘要：
2010年8月，我参与了某市级机关的电子政务系统建设项目，该项目的主要目的是开发一个通用性的框架平台，其主要功能是提供一个统一、高效、具有强大的扩展能力的电子政务平台，包括政府门户、政务信息系统、业务办公系统等系统均以服务的形式集成到该平台中，并将接口暴露给用户，同时将该市级机关原有的政务信息系统遗产进行通用化包装，并集成至该电子政务平台中，形成一个统一的、完整的系统。 笔者在该项目中担任项目经理和系统分析师，主要负责项目的管理工作和系统框架的设计工作。在项目中，考虑到对高扩展能力、高集成能力和重用信息系统遗产的需要，我们最终采用了基于SOA架构的Web Service技术来实现该系统。该系统从2011年4月完工至今，运行情况良好，已经基本实现了预期的目的，充分证明了SOA技术对企业信息系统开发的重要意义，然而在实际使用当中，也有一些问题尚待解决。
正文：
进入二十一世纪以来，我国电子政务建设有了长足的进展，各地政府纷纷建立了以县、市、省三级结构的电子政务系统。在建设的过程中，有两个问题很突出：一是系统的集成性和扩展性的问题，二是各单位原有的政务信息系统遗产的处理问题。 笔者于2010年8月，参与了某市级机关的电子政务系统建设项目，并在该项目中担任项目经理和系统分析师一职。该项目的主要目的有两点：一是开发一个通用性的电子政务框架平台，提供一个统一、高效、具有强大的扩展能力和集成能力的电子政务平台，包括政府门户、政务信息系统、业务办公系统等系统均以服务的形式集成到该平台中，并将接口暴露给用户；二是将该市级机关原有的政务信息系统遗产进行通用化包装，并集成到政务平台中，形成一个统一、完整的系统。 笔者在前期的需求分析调研当中，发现由于该市级机关的信息化政务建设工作起步较早，因而存在着信息孤岛的问题，具体表现在该市级机关的信息化建设工作起步较早，各部门根据自己部门的实际需要，在不同的时间段，选择了不同的厂商，采用了不同的开发平台和后台数据库建设了自己部门级的政务信息系统，如财务处的财务处理系统、人事处的人事管理系统、以及各个业务部门的业务信息系统等，这些信息系统采用不同的开发平台和数据库系统，彼此之间的运行环境、数据格式互不兼容，并且由于各部门进行信息系统建设的时候采用各自为政的策略，没有一个统一的规划，造成了各部门的信息系统之间的业务流沟通不畅，信息无法共享，系统与系统之间缺乏通信接口，从而造成了信息孤岛的现象，最终阻碍了该机关电子政务系统的发展。 经过上述的分析后，我们为此专门召开了项目会议，由于用户提出要求保留和盘活该机关的政务信息系统遗产，并且在新系统建设当中，重点建设系统的集成能力和扩展性，经过会议的讨论，最终我们决定采用SOA框架技术来进行该电子政务系统的建设。 SOA框架技术是一种将企业的现有的软件系统进行重新包装，并通过某种管理机制进行统一的管理，以构成一个统一的、集成的系统，在这个系统中，新开发的系统和旧有的系统之间通过异步消息机制进行数据通信和业务流协作，以达到新旧系统能够无缝（最大限度地）协作，SOA最大的特点之一就是将所有的应用都看作服务，通过服务注册中心进行统一的管理，因此SOA框架技术适用于对扩展性和集成性要求较高的场合。 SOA仅仅是一个面向服务的架构，还需通过具体的技术来实现。经过对该机关的基础设施的调研，从现有软硬件环境、该单位自有的技术人员的经验和知识范围等方面考虑，最终我们决定采用基于微软的.net framework环境的Web Service技术来进行开发。 在具体的开发过程中，我们采用了.NET中的C#来开发客户端应用，利用微软的MS SQL SERVER开发后台数据库，应用以组件的形式在服务器上的服务管理中心进行统一的注册，并暴露统一的接口给客户端以供调用。服务管理中心是整个系统开发的重点，它在客户端应用和后台数据库之间起到承上启下的作用，整个服务管理中心实际上就是一个Web Service，负责管理服务器上所有的组件服务，我们利用.NET技术来实现服务管理中心。我们将新开发的服务模块在服务管理中心中注册，服务模块采用基于XML的WSDL语言来进行模块功能的描述，以便让服务管理中心自动识别，并将功能接口暴露给客户端以供调用，服务的功能接口采用SOAP协议以便客户端进行服务的识别和数据交换。服务管理中心实际上是处于客户端和后台数据库中间的一个结构层次，所有的服务都被包含在这个服务管理中心中，对于客户端而言，在进行服务调用时，不必关心服务的具体位置和具体的实现方法，仅需向服务管理中心发送异步消息，该消息是基于SOAP和XML的，包含了例如客户端提出的功能请求类型、数据格式等相关信息，该消息在服务管理中心的消息总线机制上进行发布和传递，当在服务管理中心中查找到所需要的服务后，就可以同该服务进行通信，并完成整个业务。 我们所采用的客户端-组件管理中心-数据库三层式开发方法，是基于SOA框架的典型应用，它具有扩展性和集成性好、利于功能扩充等优点，很好地满足了用户对扩展性和集成性的要求。然而至此，整个开发工作只能说是完成了一半，接下来我们还需要进行政务信息系统遗产的包装和集成的工作。 由于SOA框架本身就支持对旧有系统的无缝集成，因此在对历史遗产系统进行包装和集成的时候，我们不需要修改旧有系统的任何代码，只需要进行一些配置，将其在服务管理中心注册并暴露统一的接口给用户即可。在具体的工作中，我们为每个旧有系统编写了关于系统配置、数据格式的WSDL文档，该WSDL文档是用XML语言编写的，可以被服务管理中心自动识别，通过该WSDL文档，可以将旧有系统在服务管理中心进行注册，并将接口暴露给服务管理中心的消息总线机制，以便当客户端发送服务请求时，能够被旧有系统的接口识别，从而同客户应用建立连接并进行数据操作和业务流操作。 综上所述，我们将整个系统建设的重点放在两方面：一方面是以集成性和扩展性为中心，采用基于SOA框架技术的Web Service技术进行开发，另一方面是利用SOA技术规范中的WSDL文档规范，对旧有系统进行包装和描述，使其能同新系统无缝集成，达到建立一个统一的、完整的、无缝的系统的效果，以发掘旧有系统的商业和技术价值，充分保护该机关的现有投资。 该市级机关的电子政务系统成功上线运行至今，运行情况出色，经用户反映，政务办公的效率大大提高，并且有效地减轻了有关工作人员的工作负担。事实证明，在进行电子政务系统的建设时，采用SOA框架和基于SOA框架的实现技术可以有效地提高系统的集成性和可扩展性，并且充分地盘活实施单位的历史信息系统遗产，保护实施单位的已有投资。 然而新版电子政务也非十全十美，经过一段时间的实际运行，发现了两个问题：一是系统运行一段时间之后，其运行速度呈线型下降，据分析，应是由于所新加的服务应用的增多，导致服务管理中心的运行速度变慢，为此我们制定了一个定期重启服务器的计划，经测试，运行速度变慢的现象有所缓解；二是经客户反映，包装集成的旧有系统在实际运行中，有时会报错，据分析，应是该系统服务的WSDL文档编写不规范所导致，因此我们为其重新编写了WSDL文档，经测试，故障排除。 结束语： 在二十一世纪的信息大潮的带动下，我国电子政务的建设如火似荼，然而电子政务的建设对于我国而言，是一个长期的、艰巨的任务，绝非一蹴而就的一次性工作，笔者愿意以一己微薄之力，投入到这场信息化建设大潮当中，为我国的信息化建设贡献一份微薄之力。
论UP（统一过程方法）的应用
摘要：
2011年3月，我参加了某市供电公司《电力营销管理信息系统》的开发工作，并担任系统架构师一职，主要负责系统分析和架构设计。该系统包括业扩管理、计量管理、电量电费核算管理、收费与账户管理、线损管理等五个模块。系统采用了Struts+Spring+Hibernate的主流Web应用框架，降低了开发的难度和成本，降低了组件的耦合度，增强了软件的可维护、可扩展性。 项目的成功很大程度的归功于项目开发采用了RUP模型，对整个的开发过程进行规范和改进。本文以该项目为例，结合作者的实践，讨论了UP（统一过程方法）在软件开发中的应用。从初始阶段建立业务模型并确定项目边界，细化阶段分析领域、选择构件，构建阶段把构件组合成产品，最后把软件移交给用户四个阶段说明了UP的具体应用。重点介绍了分析领域、选择构件。
正文：
2011年3月，我参加了某市供电公司《电力营销管理信息系统》的开发工作，并担任系统架构师一职，主要负责系统分析和架构设计。该供电公司年供电量在10亿度以上，计量点915个，大客户209个。以前的业务流程是电话报装、手工派单、自主开发的VFP系统算费、财务系统收费开票等。随着供电量业务的扩展，原业务流程暴露出各环节分散，无法进行统一的管理，客户的满意度低。为了解决上述问题，该供电公司决定建设一套电力营销系统。以系统的建设促进用电管理水平的提高，以电力信息化推动电力企业现代化。杜绝重复投资，整体规划，实现用电管理信息的高速交互和决策，提升客户的满意度，降低管理成本。 系统采用了Struts+Spring+Hibernate的主流Web应用框架，开发工具采用MyEclipse10.0，硬件配置：两台IBM X3650安装Oracle10g做数据库服务器，在两台服务器上搭建了高级复制功能，保证数据库中数据同步。两台IBM X3650以双机热备的方式做营销应用服务器，两台服务器上运行着集群软件，通过"心跳"来检测对方的状态，发现故障能自动切换。一台IBM X3650做算费服务器。 RUP统一软件开发过程是一个面向对象且基于网络的软件开发方法论。可以应付种类广泛的软件系统，不同的应用领域，不同的组织类型，不同的性能水平和不同的项目规模。UP是基于构件的，与其他软件过程相比有三个显著的特点：用例驱动、基本架构为中心、迭代和增量。正是由于UP具备上述特点，使采用UP模型的开发过程能提高团队成产力，简洁清晰的过程结构，为开发过程提供了较大的通用性。 根据RUP模型，我们把整个的开发过程分为：初始阶段、细化阶段、构建阶段和交付阶段。每个阶段结束的时候都要安排一次技术评审，如果评审结果令人满意就可进入下一阶段。 1. 初始阶段 初始阶段的任务是建立业务模型、确定系统边界。首先，我们采用用户访谈、用户调查和联合讨论会的方式捕获用户需求，详细了解用户对系统的预期目标，捕获在系统招标书中没有明确的性能指标。其次，我们专门召开了一次联合讨论会，会上参与的各方代表经过讨论，就需求的优先等级达成一致意见。最后，对需求进行分析，确定了项目的目标、特性和用例模型，完成了《需求规格说明书》的初稿，并通过了用户的评审。 2. 细化阶段 细化阶段的任务是分析问题领域、建立体系结构、选择构件。通过对问题领域的分析，我们把系统划分为5个主要模块：业扩管理、计量管理、电费电量核算管理、收费与账户管理和线损管理。确立了软件的整体架构，部件之间的交互接口，构件的设计与选择。 基于构件的开发可以减少开发中重复的工作，降低开发成本，缩短开发周期，提高软件的质量和灵活性。获取构件有多种途径，第一种是在现有构件库中直接提取符合要求的构件，或对已有构件做适当的修改。第二是采购第三方构件，现在市场上有很多成熟的产品，比如开发平台、数据库平台、各种通用构件等。第三是自己开发符合需要的构件，当构件库和第三方构件没有满足需求时，必须自己开发满足需要的构件。 该项目中上述的三种方法我们全部都用到了。在以前的项目开发中，我们提取了很多的可重用构件加入自己的构件库。比如：权限管理对于任何管理系统都很重要，我们提取符合RABC（基于角色的访问控制）模型的独立授权构件，将权限与角色相关联，通过成为适当角色的成员来获得该角色的权限，简化了授权的管理。该系统的流程要求根据业务需要可以配置，我们提取了工作流引擎，可以满足流程的调度、图形化的定义和管理。 市场上有很多成熟的构件，包括开源的和商业的，是不需要自己开发的。直接使用可以缩短开发周期，降低开发成本。我们采用的Struts+Spring+Hibernate框架就是典型的开源框架，可以让我们把主要的精力放在业务的实现上，而不用去关心数据如何从数据库中读出和写入，请求如何在各层之间传递等。报表是管理信息系统必不可少的功能，我们采用明宇公司的如意报表，满足报表在Web下的设计、浏览、打印等功能。 有一部分构件是本系统独有的，没有现成的产品，必须自己开发。该系统对电费的计算有很多灵活的要求，变压器容量的固定冲减、月度结算中变压器容量的退补、特殊单位执行特殊电价、子表电量追加自动冲减母表等。根据这些要求，我们不能把算法写死在程序中，而是自主开发了一个电费计算引擎，通过计算规则和电费计算相分离，实现了算法的方便配置修改，提高了电费计算的灵活性。 在细化阶段我们更新了需求规格说明书和软件体系文档，选择了适合的构件，并完成了用户对其的评审。 3. 构建阶段 构建阶段的任务是把各种构件组装成产品。我们采用基于功能和面向对象的组装技术相结合，根据系统的需求，把各种渠道获取的构件组装成产品，并完成系统的集成测试和系统测试。每次迭代的成果都展示给用户，让用户详细了解进度，并提出反馈和改进意见，我们及时调整开发。该阶段结束时，向用户交付了系统的Beta版本。 4. 交付阶段 交付阶段的任务是把产品成功的分发给用户。由于用户要求是新的业务应用该系统，不存在新老系统的业务移交问题，所以交付阶段比较简单。首先，在用户提供的环境下部署Beta版本，进行系统的Beta测试。其次，对各种错误和缺陷做出修改，增加文档和培训资料，并对用户进行培训。最后，配合用户完成了验收测试。 结束语： 该系统于2011年11月成功的通过了用户的验收，大大提高供电公司的用电管理水平，提高了客户的满意度，降低了管理的成本。项目的成功很大程度归功于采用了RUP的开发模型，对整个开发过程进行规范和改进。在迭代的开发过程、需求管理、可视化建模、验证软件质量控制变更等方面，为每个开发成员提供了各阶段必要的准则、模板和工具指导。 RUP虽然具备很多优点，但也存在一些不足，如：RUP仅仅是开发过程，没有覆盖软件的维护和技术支持着两个重要的过程。不支持组织内的多项目开发，导致组织内的大范围重用无法实现。在度量管理、重用管理、人员管理等方面存在不足。在实际的应用中可以根据需求对其改进，可用OPEN、OOSP等其他软件过程的相关内容对RUP进行补充和完善，使整个开发过程更加适合自己的项目。
论分布式数据库的设计与实现
摘要：
分布式数据库系统把应用所需的数据存放在多个数据库服务器上，完成某个数据操作要涉及到访问多个服务器，这适用于某种特定需要的应用。 本文描述了我在主持设计开发的一个MIS系统中，为了达到了在低速网络通道下有效提高应用程序性能的目的，使用Sybase分布式数据库技术的过程。系统采用典型的C/S结构，但许多客户端连接服务器的网络采用电话线拨号，速度有限，传统Windows界面的客户端应用程序相应速度比较慢。考虑到B/S结构也避免不了大量数据从服务器端传输到客户端，我认为WEB界面并不能有效解决这个问题，所以采用了优化数据库结构的方法，把数据分两部分存放，基础数据放客户机，会员资料主要采用键码放服务器，应用程序再现数据时从服务器取键码，到客户机取对应的解释，由于键码的数据量少，网络传输便快。在构建这个分布式数据库系统的过程中，我着重研究并解决了数据同步和事务协调的问题，取得了良好的应用效果。我认为，分布式数据库系统的技术在Intenet时代正当其道，大有发展前景。
正文：
分布式数据库系统把数据存放在多个数据库服务器上，当应用提取所需数据时，要访问多个服务器，综合多点数据才能完成。 分布式数据库技术在很多场合得到了应用。譬如某企业随着业务量的扩大，原有数据库服务器已经达到了容量和性能极限，如果不希望丢弃原有投资，可以建立另外一套新的数据库，跟原有的系统组成一个分布式数据库系统，给应用提供透明统一的数据访问。还有，如果某企业分成多个业务部门，而且地域分散，可以在某个部门放置单独的数据库服务器，用于存放该部门最常用的数据，而部门和部门之间相互引用的数据可以通过分布式数据库技术来方便地完成。分布式数据库不是简单地把集中数据库分散实现，而是针对某种特定应用需要而诞生，它必然具有自己特有的性质和特征，需要在上面做许多的工作，来满足应用的要求。 我在设计、开发一个MIS系统时，针对应用的需要而引入分布式数据库技术，取得了良好的效果。 该系统针对会员资料的管理而设计，用于管理会员入会、缴纳会费、申请资助、办理资助审批、关系转移、退会和注销手续等等业务流程。分三个级别的应用权限------基层单位级、总公司级和集团公司级，各个级别只能操作各自范围内的业务数据。该系统采用典型的C/S结构，后台数据库采用Sybase，前端应用采用PB开发工具来设计标准的Windows操作界面。我在其中任系统分析和数据库设计的角色，担任了调查业务需求、业务建模和数据库建模、数据库设计以及指导应用程序测试、优化系统和应用的性能等等一系列工作。 由于客户端地域的分散，遍及多个省境内，许多使用该系统的基层单位连接服务器数据库的网络采用电话线拨号方式，速度有限，在使用客户端应用程序时感觉界面速度很慢。经过分析，认识到许多操作都要从服务器中取数据，速度慢就慢在数据访问上。服务器是没有性能瓶颈的，问题出在网络速度上。不可能要求众多使用客户改善和升级他们的网络，只能充分挖掘软件的潜力，来适应这种低速网络的使用模式。 经探讨，结合关系数据库的知识，认识到，应用程序的每一次数据库操作，都要访问多个相关联的表，其中，有会员资料表和基础数据表，会员资料表中存放许多的键码值，在基础数据表中有键码相应的解释。键码值的数据量比较少，而基础数据是静态的，几乎不会更改。如果考虑把会员资料放在服务器上，基础数据放在客户端，当应用程序中访问数据时，总是从服务器上存取会员资料，从客户端提取会员资料中键码的相应解释。由于键码的数据量少，便减少了网络上传递的数据量，从而提高了界面的响应速度。 同时考虑到基层单位总是操作自己所属的部分会员，增删转移操作少，会员列表比较固定，而每一项业务操作都涉及到要从会员列表中查找定位到某个会员，所以会员列表是最常访问的数据项。把会员列表从会员资料数据中抽取出来，也放置在客户端，这样，便进一步改善了性能。 把数据分散存放只是工作的第一步，接下来要考虑应用程序怎样访问这种分布式数据。开发应用时，如果每一功能都针对两个数据库进行，就带来了很多麻烦。所以，我们研究了Sybase的分布式数据库技术，决定采用了CIS（组件集成服务）部件，来合并两个数据库成一个统一的分布式数据库。应用程序只要连接一个数据库，就可以透明统一访问到两个数据库中的数据。 该技术具体实施方法是，在客户端数据库中建立一个对服务器数据库的远程访问服务名，包含访问地址、登录用户名、登录密码等等关键的连接信息；并且对服务器中会员资料数据表建立一个本地代理表，结构和服务器中远程表完全一样，它是访问服务器中会员资料的中转和代理。客户端应用程序访问本地代理会员资料表时，实际上是通过预定义的远程访问服务名中包含的连接信息到服务器中对应的实际会员资料表中访问数据。这种访问对于客户端完全透明，感觉不到是从物理上独立的两个服务器中存取数据。所以，这种数据库结构是典型的分布式数据库。 部署这种分布式数据库不是难事，只要在客户端和服务器上安装12.0版以上的数据库服务器，在客户端服务器上建立远程服务名和代理表即可。由于Sybase数据库的安装支持脚本方式，在客户端应用程序的标准安装过程中，嵌入Sybase数据库的安装和配置脚本，就自动化地完成了所有工作。 在实际使用该分布式数据库系统的过程中，遇到了几个问题。第一，数据同步。客户端基础数据不是绝对静态的，也有变化，因此在服务器端要设置一个统一的基准，称为主点数据。客户端总是复制使用，称为复制点数据。如何及时感知到服务器端主点数据的变化，有效率地复制到客户端，是个难题。Sybase针对这种应用场合，提供了复制服务器技术，但为了避免过于复杂，我们实际采用应用程序来管理同步。当服务器端主点数据有了更改时，保存一个相应的标识和时间戳，客户端应用在登录服务器时，检查这种标识，一检测到了数据有更新，就首先下载，然后再进入系统正常使用。这种方法实现起来，增加了额外的开发量，且不能判别绕过应用程序对数据的直接修改，但是，是最简单和有效的方法。 第二个问题是事务协调问题。物理上独立的两个数据库，在协同操作时，如果服务器正好停机或者网络故障，完整的一个事务没能完成，就会"事务崩溃"。虽然Sybase CIS内嵌了两阶段提交技术，能够自动恢复。但是应用程序在这种情况下，敏感性不够，操作界面会无端凝固，影响了使用的方便性。我们针对PB对于连接的判断和感知，用了一个小小编程技巧，使应用程序能够及时感知到数据库连接故障，及时停止和恢复事务，使操作界面表现友好灵活。 以上遇到的这些问题，都找到了解决办法。分布式数据库技术的应用并不是非常复杂，它往往为解决特定问题、满足特定需要而被采纳，使用得当，会给应用带来了许多便捷。 在当今信息社会里，互联网络带来了相互连通的便捷，而且知识爆炸，数据的分布式访问是个必然趋势。潮流兴起的XML技术，提供了各种平台数据库之间的一个公共数据访问标准，可能会用来构建更加灵活、适应性更强的分布式数据库技术。
论改进Web服务器性能的有关技术
摘要：
基于Web技术的数据库应用是当前应用的一个热点，在用户数目与通信负荷很大的场合，提高Web服务器性能是一个迫切的课题。本文从笔者参与某个银行系统项目开发的经历出发，阐述了提高Web服务器的性能应渗入到项目论证、选型、开发、运行和管理的各个环节，只有各个环节都能充分考虑到性能与质量的需要，系统的性能才是真正可保证的和可扩充的。 文章从系统的实际运行与相应的经验出发，阐述了性能改进方面的一些具体措施。 比如：在本文中讨论了Web服务器平台的选型考虑；Web服务器的配置管理；应用系统本身的优化与预先设计系统时可扩性的性能保障等具体内容。 通过技术上的分析与改进，综合性地运用多类措施与手段，在实际系统中，Web服务器运行的性能得到了一定程序的保证。
正文：
我所在的单位是把目标定位于金融领域开发IT应用的一家信息技术公司。随着金融电子化建设的发展和商业银行之间市场竞争的加剧，各主要商业银行不断通过信息技术提供新的金融产品，并且希望整合市场渠道。比如主要的商业银行不断推出形形色色的网上银行服务。在这种背景下，本人参与了开发新一代风上银行产品，涉及提供网上个人理财服务、网上外汇买卖服务、网上企业服务等具有市场竞争力的产品。作为项目开发的组织者之一和主要的技术骨干，在整个项目开发过程中始终要处于第一线，从而在改进Web服务器性能、提高整个网上平台系统性能方面收获良多，在本文中简要讨论如下，希望与读者们共享经验。在Web服务器配置与优化方面，我有如下几方面主要的体会： 第一方面是Web服务器选型考虑。 在Web服务器选型及网上平台搭建这初，我们就已充公考虑整个网上平台的性能及可扩展性问题，这一考虑为该系统的稳定性及扩展性能力方面打下了坚实的基础。 某银行原有的一些网上产品由于开发较早，故而采用的是老式的HTTP Server + CGI程序调用的方式。这时，每一客户请求需要对应于后端系统的系统进程来运行CGI程序来处理，系统的开销相当大，系统的扩展能力也很差，性能已不能满足业务处理的需要，故而在为此银行系统具体选型的时候，我们一开始就否决了这种方案。 通过市场上同类产品的比较选择，我们选择了国际商业机器有限公司IBM的Web Sphere产品系列作为该行网上银行系统的建立平台。作出这样选择是因为Web Sphere基于使HTTP Server和应用服务器相分离的整体架构，同时支持JSP、Servlet和企业级Java Bean等轻量级线程规范，所有的请求对应于应用服务器上的处理线程，系统的开销低，效率非常高，同时Web Sphere整个体系结构相当的灵活，为适应扩展需要可以作不同的横向和纵向扩展，从而可以满足各银行未来的扩展需要。 正是因为在一开始选型的时候我们就已考虑到未来的扩展需要，整个系统在接下来的几次性能改进方面，我们大体上都能相对顺利地达到了预期目标。 第二方面是Web服务器的性能配置。 在一开始系统上线的时候，由于系统的负荷不是很大，为了节省系统总拥有成本TCO投资，我们在一台较低配置的IBM RS6000上投产了该系统。整个系统的HTTP服务器、应用服务器、通信服务器等均位于该台机器上，由于初始投产时用户不多，所以系统的性能基本上能令人接受。 但随着业务的发展和用户访问量的增大，我们发现该服务器的响应变慢，系统的CPU利用率和内外存交换显著增大。经过跟踪，我们发现关键原因之一是系统的内存不足的缘故。由于网上服务器把大量用户的会话信息保存在内存中供给应用系统使用，当内存不足时，大量Session信息被迫交换至硬盘，大量CPU时间消耗在等候内外存的交换上，系统效率迅速下降。 鉴于这种情况，我们把该服务器的内存由2GB扩充为4GB，同时相应调整用户会话信息的保存时间，这样整个系统的效率又回到较为理想的状况。 由于新应用的不断投产及数据库操作的日益增加，我们后来逐渐监控到系统的数据库处于繁忙状态，系统的错误日志也记录下了供应用服务器使用的数据库连接处出现资源不足的情况。在这种背景下，我们认为整个系统由于硬件配置所限，应该进行横向扩展，因此我们把数据库服务器分离出来，配置到另一较高性能的服务器上，相应定义的数据库资源也大幅增加，这样整个系统的性能又处于较为理想的状况。 第三方面是对应用系统进行相应的优化以提高性能。 Web服务器配置及相应的硬件扩展不失为解决系统性能问题的一条捷径，但应用系统的优化也是应该重点加以考虑的，毕竟它能够在投入较少的情况下提高系统的运用效率。 在开发的初期，我们就已经十分注意系统的利用效率，比如提醒程序员尽量不要利用用户会话信息（Session）来传递大的对象，对于内存要注意回收等。同时，通过内部的交流会推广与介绍一些小的，有用的编程技巧来提高开发人员的水平，通过代码的抽查，希望能在早期就发现问题等。 在系统运行期间，我们通过监控发现，应用服务器所基于的Java虚拟机，其内存堆的空闲空间有不断下降的趋势，每隔若干天导致空间消耗殆尽，无法分配新对象空间，从而导致系统重启。在排除了系统本身问题的原因外，我们确定为应用系统的开发有问题。通过从网上下载IBM公司检测Java虚拟机的相关工具对JVM进行监控后终于发现系统内部存在着不能回收内存的对象，再通过查找相应的程序发现在该程序中有"环状"的对象引用，从而导致对象使用后不能被垃圾收集器所回收。这个问题的解决过程虽然十分艰苦，但由于该问题不能通过升级硬件或增加资源配置而得到根本解决，会给系统带来很大的隐患。所以，整个过程的分析与解决是完全值得的，更何况通过查找故障原因的过程，给整个项目组上了生动的一堂软件质量保证课，对项目组的质量意识起了很大的促进作用。 所以说改进Web服务器的性能并不单纯是系统管理方面的工作，它渗透到开发以及系统运行第一系列环节中。 第四方面预先考虑未来的扩展与性能需要。 随着系统的发展及成熟，考虑到用户访问量的不断上升，为了预留系统的发展空间，我们最近又对整个系统作了一个系统性的升级。通过引入多台HTTP服务器及应用服务器并行工作提高整个系统吞吐量及单点故障克服能力。由于在一开始选型的时候就已经充分考虑到动态负载均衡及横向扩展方面的需要，这一项的升级无需对整个系统的体系结构作根本的变革，对应用程序来说，更是没有造成任何影响。 整个项目历时近两年，从这两年的系统情况来看，整个系统是成功的。根据我亲身的经历，系统性能并不单纯是系统运行与管理阶段的问题，而是渗透在项目论证、开发以及运行的各个阶段。只有各个阶段都能充分考虑性能方面的需要，在实际运行时，整个系统的性能才可能真正有保障。在技术方面来看，可以综合利用选型评估、硬件扩展、应用优化和系统配置优化等一系列的手段；比如在硬件扩展方面，又可以分为主要部件扩容，纵向升级、横向升级等方面。在我们的项目实践中，曾综合地利用了上述的各种手段。比如某银行的整个系统日访问量不足1万至现在的每日超过10万次以上的点击的发展情况来看，整个系统的性能保障及提高方案是比较成功的。
论基于UML的需求分析
摘要：
2008年3月1日至12月20日，我参加了"数据安全访问平台"项目的开发，担任系统分析员的工作。该项目是某行业用户"数据中心二期"建设的主要内容，目标是：建立数据统一访问接口及其使用标准，规范、约束和审计数据应用访问数据库的行为，对数据应用提供强制审计的技术手段。由于该系统是所有应用的基础平台，对系统的可靠性与性能有较高要求，同时由于没有成熟的现有系统作为参照，该项目存在较高的风险。 本文结合作者实践，讨论了在项目中基于UML的需求分析。我们使用用例图描述用户与系统的交互；使用类图描述系统的核心概念；使用部署图描述系统的网络部署；使用活动图描述系统的应用流程。由于采用了UML中的多种技术，使得我们能从多个方面完整的把握需求，有效的保证到了需求工作的质量。最后，分析了需求工作中存在的问题和改进的方法。
正文：
一、项目概述 2008年3月1日至2008年12月20日，我参加了"数据安全访问平台"项目的开发，担任系统分析员的工作。"数据安全访问平台"是某行业用户"数据中心二期"建设的主要内容。在一期建设中已建成数据的统一存储和统一分发框架。但主要存在以下问题：无法获得应用用户对数据库的操作日志；开发人员对数据库的使用不规范，查询的结果集过大，导致数据库的性能大幅下降；应用直接使用数据库的登录数据库，存在着一定的安全隐患。"数据安全访问平台"的目标是：建立数据统一访问接口及其使用标准，规范、约束和审计数据应用访问数据库的行为，对数据应用提供强制审计的技术手段。 该项目具有较高的业务需求风险和技术风险。由于没有成熟系统做为参照，该项目需求不是很明确，而且系统涉及甲方多个利益相关方，各方对系统的安全和审计功能、运行维护、可靠性、性能和易用性有者不同的观点，某些观点之间还存在冲突。同时系统作为"数据中心"的基础设施之一，所有的应用系统都要通过本系统完成数据库访问。系统的可靠性和性能直接影响到应用系统的正常运行。整个系统分为6个子系统，包括JDBC驱动封装子系统、ADO.Net驱动封装子系统、WebService接口子系统、管理配置网站、存储子系统（SQL Server2005数据库，存储配置信息）和监控子系统（数据库网络协议分析与连接控制）。 二、UML在需求工作中的应用 项目组采用一个精简RUP开发模型指导项目的整个开发流程。在初始阶段主要采用用户访谈、用户调查和联合讨论会捕获用户需求，进行初步分析，完成《需求规格说明书》初稿，通过用户评审；在细化阶段，对需求进行了细化，并在采用原型法验证用户需求，完成《需求规则说明书》更新稿，通过用户评审，作为项目验收的依据。 项目开发中，我们采用了统一建模语言（UML），并使用了Rational Rose工具。在需求工作中，我们主要使用了UML中的用例图、类图、活动图和部署图。 1、用例技术的应用 整个需求开发都是围绕着用例技术开展的。首先，我们明确了系统的利益（查书）相关方、确定了系统边界和建设目标，以及主要功能特性。由于系统涉及甲方多个利益相关方，包括：应用科、维护科、网络科、信息中心领导和应用开发方，他们对系统的安全和审计功能、运行维护、可靠性、性能和易用性有者不同的观点，同时本系统与已建成的网管系统和单点登录系统存在着交互关系，这给确定系统的目标和边界带来一定的难度。项目初始阶段开始，我们先通过用户访谈、用户调查了解了各个用户对系统的观点；随后，我们召开了联合讨论会，会上我们描述了各个用户的观点，以及之间可能的冲突，供各方进行充分的讨论，会议最后，信息中心的领导统一了各方的意见，对系统达成一致的目标，并明确了系统主要的功能特性，确定本系统了与网关系统和单点登录系统的关系。 其次，我们建立用例模型，并细化关键用例。明确了系统的目标和主要功能特性后，我们采用用例模型对需求进行分析。整个系统包括六个用例包：访问接口包用例包、审计信息管理用例包、用户认证信息管理用例包、数据库连接资源管理用例包、访问控制信息管理用例包、数据库连接监控管理用例包和审计日志管理用例包，共包含55个用例。对大部分用例我们只描述了一个基本正确流程，只对5个关键高风险用例进行了细化描述，包括：前置条件、后置条件、基本流、扩展流和相关约束。这项工作完成后，我们编写了《需求规格说明书》初稿，提交用户进行了审核。经过修改后，通过用户评审，作为初始化阶段的主要成果。 最后，细化用例模型。在细化阶段，我们细化描述了所有的用例，完成《需求规则说明书》更新稿，通过用户评审后，作为项目验收的依据。 2、类图的应用 用例技术描述了系统需求的动态结构，但对于需求特性和用例中出现的概念，并没有统一的分析。我们使用类图描述系统的核心概念。本项目中涉及的核心概念主要包括：逻辑连接、用户、应用、受限角色、认证SQL语句、参数取值范围的约束和查询结果集的限制。在分析核心概念时，我们主要关注：概念之间的关联关系，是否具有相同的生命周期，和具体的对应关系（一对多、多对多和多对一）。 3、部署图与活动图的应用 由于整个系统包含多个子系统，各个子系统部署在不同的节点，需要考虑用户的网络结构是否能支持。在需求阶段，我们也描述了整个系统的部署。其中监控子系统比较特殊，由于其是通过分析Oracle数据库的网络数据包进行工作的，因此监控子系统必须接入核心交换机的镜像端口。我们将部署图与网络科进行了确认。 我们使用活动图描述系统的应用场景。由于本系统对应用系统的开发增加了一层管理，因此应用系统的开发方与信息中心存在一个交互流程：应用开发方首先使用本系统的开发版进行本地开发，并填写基本配置数据；然后，在用户的生产环境中部署应用，并提交基本配置数据；最后，信息中心的管理员对配置数据进行修改后，应用在生产环境中才能运行。我们使用流程图描述了整个过程。用通道表示应用开发方和信息中心，并描述了各个通道内的流程以及通道之间的交互。 三、总结 由于没有成熟系统做为参照，该项目具有较高的需求风险。由于在整个开发过程中使用了UML的用例图、类图、部署图和活动图，这使得我们能从多个方面完整的把握需求，有效的保证到了需求工作的质量。 本项目的需求工作中，我们也遇到的一些问题，主要是维护Word文档与模型的一致性。我们使用RationalRose建模，使用Word写文档，通过截图的方式将模型插入文档，因此需要手工维护两者的一致性。这种方式较繁琐，容易出错。今后的工作中，我们准备使用Rational公司的Soda工具，自动将Rose中的模型插入到Word文档中。
论基于构件的软件开发
摘要：
2011年3月，我有幸参加了沈铁设计院综合管理信息平台(简称：信息平台)项目的开发工作，并担任系统架构师一职，负责系统的架构设计及核心构件的开发工作。该系统是沈阳铁道勘察设计院有限公司委托开发的，项目于2011年底验收，满足客户方提出设计、生产、经营、管理的需求。 本文以信息平台为例，讨论基于构件的软件开发，简单说明为什么要用构件开发及获取构件的方式，接着详细介绍了通过一次登录后可以任意跳转到其它各子系统的单点登录构件、数据库访问构件、展现信息的层次结构的目录树构件、方便设置文档格式的活动表单构件等系统主要的构件以及开发过程，开发策略，加强构件复用程度，提高软件的开发效率，缩短软件的开发时间。文章最后简略说明几种构件技术的发展趋势。
正文：
2011年3月，我有幸参加了沈铁设计院综合管理信息平台(简称：信息平台)项目的开发工作，并担任系统架构师一职，负责系统的架构设计及核心构件的开发工作。该系统是沈阳铁道勘察设计院有限公司委托开发的，项目于2011年底验收，满足客户方提出设计、生产、经营、管理的需求。 信息平台包含有企业门户、综合办公、设计生产、经营计划、技术质量、人力资源、档案管理、信息中心、公司决策、后台管理等十个子系统。为利用好以前各种硬件平台的投资，选择信息平台运行于windows+sqlserver2005 平台上，采用.net开发技术。采用四层B/S架构，这四层分别为界面层、外观层、业务逻辑层及数据访问层，信息平台的各种功能基本具有这四层架构。系统的主要功能有：通过一次登录后可以任意跳转到其它各子系统的单点登录；采用目录树构件来展现数据的层次结构；活动表单构件方便用户编辑格式化的文档数据等服务。这些功能都以Web service接口的方式公开给各应用系统调用，有了这些基础功能，应用系统就可以省去单点登录，用户格式化的信息编辑，信息的层次展现等功能的开发和维护，缩短开发周期和降低开发成本。 信息平台采用了基于构件的开发方式，基于构件的软件开发是一种自底向上的，基于包装好的构件来构造应用系统的方法，它主要包含构件的检索与获取，理解与评价构件，修改构件，组装构件，应用与布署等工作。基于构件的开发涉及到构件的获取问题，目前构件的获取主要有三种方式：公司产品库，第三方构件和自主开发，因为考虑到需求变化时构件的修改问题，我们只采用了从产品库获取和自主全新开发两种方式。 鉴于我们公司具有多年的项目积累，我们从公司的产品库中选择合适的构件，对于与需求类似的构件，进行修改后，做好构件的版本记录。经过我们的分析、筛选和比对，发现以往项目中经常用到的单点登录模块，只需要改进一下验证方式就可以复用到新系统中；接着从共用的底层模块中，发现了数据库访问模块，只要在灵活性和可替换性方面加强一下，也达到我们复用的标准；最后发现目录树和活动表单这两个模块，几乎是最成熟的，除了界面外其它不用修改，可以直接复用。 接下来详述一下组成系统的主要构件： 1.首先介绍一下，单点登录构件(SSO)，SSO可以让用户登录信息平台后，可以跳转到任意其它应用系统，进入其它系统时无需再次登录，免除用户每使用一个应用系统就得再次登录的重复操作，需要接入的应用系统只要到信息平台注册，按照规范配置即可实现这一功能。当用户进行页面请求时，就会被SSO捕获(采用.net 的 httpmodule机制)，SSO首先判断是当前客户端是否存在在该用户的Cookie，如果不存在则跳转到信息平台的登录页面，要求通过后会跳转到用户所请求的页面，完成一次SSO过程。验证用户的合法性，有几种情况：第一种是对用户的密码进行MD5加密后与数据库进行比对，同时还要对用户登录的计算机与数据库进行比对；第二种是判断用户是否插入登录钥匙盘。只要有一种验证通过即视为验证成功，不再进行下一步验证，对于这种需求，由于项目初期还不知以后会有多少种验证方式，所以从构件库获取之后，在设计上增加职责链的设计模式，以适应增加新的验证方式提高扩展性。 2.数据库访问构件，从构件库获取后，抽象出一套规范的数据访问接口，以后构件的修改不会影响到其它调用的程序。为了解决以后还可以替换成其它类型的数据库平台，采用了"倚赖注入"的理念，即抽象工厂模式，通过配置文件配置数据库操作的具体实现构件(类)，来生成实例，这样就可以实现以下场景：比如数据库从 sqlserver2005替换成oracle，只要使用oracle数据库访问构件，然后配置在配置文件中，即可以完成不同数据库平台的切换，其他程序无须改动，做到平滑过渡，提高系统稳定性。 3.活动表单构件，这个构件是直接从产品构件库提取出来的，只做了界面调整，为信息平台的企业门户内的通知公告、院内新闻、重要精神等等栏目使用，用户在创建发布的信息时，可以对发布的内容在活动表单编辑器内设置字体、格式、段落等排版信息。同时支持附件上传功能。 4.目录树构件，这个构件也是直接从产品构件库提取出来，为信息平台的设计生产的单项设计项目的信息进行构件复用，项目树结构由六级节点组成。Root根节点为零级节点由项目名称表示，一级节点由设计阶段表示，二级节点由单项工程名称表示，三级节点由专业表示，四级节点由功能区(工作区、输入区、提资区、收资区、成品区等)表示，五级节点即叶节点由功能属性名(图纸、文字、图片、其他等)表示；还有人力资源子系统的组织机构树等。 5.在界面层的设计中，因为构件库中没有相应的控件，只好采取自主全新开发，如时间段选择控件，文本框智能提示控件，基于flash的多文件上传控件，以及用户/部门选择控件。这些控件还提供了日常的数据验证功能，开发时跟.net服务器控件一样，拖拉到开发页面即可，让开发人员把精力集中在系统的业务功能实现上，而非技术细节，缩短了界面层的开发周期，也为后续项目积累了基础控件。 该系统采用基于构件的开发方法，从构件库中获取构件，并采用了"依赖注入"，抽象工厂，后期绑定等技术，提高扩展性、灵活性和稳定性。对于构件库没有的进行了自主全新开发，开发完成后加构件库，为后续项目开发提供构件。这种开发方法保证了系统质量并按期通过验收。 虽然从产品构件库中获取到大部分的构件，但构件本身的修改不是件容易的事情，如上述所提的单点登录(SSO)构件，数据访问构件都需要资深的开发人员采用一些如"依赖注入"，抽象工厂，后期绑定等技术，提高扩展性、灵活性和稳定性；而构件库没有用自主全新开发的，比如flash批量上传文件控件还涉及flash,Ajax等技术，用户/部门选择控件对javascript技术的要求也特别高，这就要求构件开发人员的选拔和培训成了一件紧迫的工作，在以后的项目中会更加重视这一工作，培养合格的构件开发人员，让更多合格的构件加入到产品构件库，提高公司的整体开发效率。 目前主流的构件技术标准有三种：Corba，EJB和COM/Dcom/Com+，Corba是OMG组织制定的一种标准，这种标准易于扩充和修改，具有较高的通用性和适应性；EJB是JAVA体系的，凭借JAVA跨平台的优势，用EJB技术部署的分布式系统可以不限于特定的平台Com/Dcom/Com+是微软公司研发的，主要用于windows平台，对windows支持度高。 最后展望一下构件技术的发展趋势，随着企业业务的开展，信息技术的不断应用，企业集成的问题越来越突出，构件将向SOA架构靠拢(服务也是一种构件)，构件间通过ESB方式进行通信，实现各应用的松耦合，提高灵活性和扩展性，以支撑不断变化的企业业务需求。
论基于构件的软件开发(二)
摘要：
2011年3月，我有幸参加了统一网管应用平台（UNMP）项目的开发工作，并担任系统架构师一职，负责系统的架构设计及核心构件的开发工作。该系统是省移动分公司网络维护中心委托我们开发的，在该项目立项前，该部门存在大量的第三方应用系统，这些系统之间存在大量重复的功能，所以提出了建设UNMP作为各应用系统的支撑平台。UNMP主要功能有：单点登录、用户管理、集中授权、消息通知、日志管理、告警管理、系统监控、定时服务等。该项目于2011年底通过验收，满足客户方提出的作为各应用系统支撑平台的需求。 本文以UNMP为例，讨论基于构件的软件开发，简单说明为什么要用构件开发及获取构件的方式，接着详细介绍系统主要的构件以及开发过程，开发策略。文章最后简略说明几种构件技术及展望构件技术的发展趋势。
正文：
2011年3月，我有幸参加了统一网管应用平台（UNMP）项目的开发工作，并担任系统架构师一职，负责系统的架构设计及核心构件的开发工作。该系统是**省移动分公司网络维护中心委托开发的，项目于2011年底验收，满足客户方提出的作为各应用系统支撑平台的需求。 以前该部门存在大量各种各样的应用系统，这些应用系统的开发平台、架构、语言截然不同，硬件也不尽相同，部门系统维护人员维护的难度很大，各应用系统重复采集数据给网络带来额外负担，也浪费了采集带宽和资源，系统之间存在大量的重复功能。为解决上述问题，需要建立统一网管应用平台（UNMP）来有效整合各种应用系统，规范各类开发和维护。同时这个平台也可以为新增的应用系统提供规范约束和指导，提高开发效率和降低开发成本。 为利用好以前各硬件平台的投资，选择UNMP运行于windows+sqlserver2005平台上，采用.net开发技术。采用四层B/S架构，这四层分别为界面层，外观层，业务逻辑层及数据访问层，项目的各种功能基本具有这四层架构。系统的主要功能有：通过一次登录后可以任意跳转到其它各系统的单点登录；用于统一管理各应用系统用户信息；为各系统提供收发短信/彩信的消息服务；还有日志管理和告警管理；还有为其它功能提供短信、监控、同步用户、同步工作流待办待阅信息等的定时服务。这些功能都以webservice接口的方式公开给各应用系统调用，有了这些基础功能，应用系统就可以省去单点登录，用户管理，收发短信等功能的开发和维护，缩短开发周期和降低开发成本。 因为UNMP是个平台系统，接入的各种应用系统繁多，影响面广，开发周期短，所以复用性，稳定性和扩展性要求比较高，团队最终采用了基于构件的开发方式，基于构件的软件开发是一种自底向上的，基于包装好的构件来构造应用系统的方法，它主要包含构件的检索与获取，理解与评价构件，修改构件，组装构件，应用与布署等工作。基于构件的开发涉及到构件的获取问题，目前构件的获取目前主要有三种方式：自身企业库，第三方构件和自主开发，因为考虑到需求变化时构件的修改问题，我们只采用了从企业库获取和自主全新开发两种方式。 鉴于公司在电信行业多年的项目积累，我们整理了以往成功实施的项目，形成企业构件库，针对性的选择合适的构件，对于与需求类似的构件，进行修改后，做好构件的版本记录。企业构件库构建，采用从成功实施过的项目中，抽取共用的，底层的一些模块，封装其内部逻辑，为外部提供一致的调用接口，形成可复用的构件。经过我们的分析、筛选和比对，发现以往项目中经常用到的单点登录模块，只需要改进一下验证方式就可以复用到新系统中；接着从共用的底层模块中，发现了数据库访问和日志管理模块，只要在灵活性和可替换性方面加强一下，也达到我们复用的标准；最后发现的定时服务和短信组件这两个模块，几乎是最成熟的，除了界面外其它不用修改，可以直接复用。 接下来详述一下组成系统的主要构件： 1、首先介绍一下，单点登录构件（SSO），SSO可以让用户登录UNMP后，可以跳转到任意其它应用系统，进入其它系统时无需再次登录，免除用户每使用一个应用系统就得再次登录的重复操作，需要接入的应用系统只要到UNMP注册，按照规范配置即可实现这一功能。当用户进行页面请求时，就会被SSO捕捉（采用.net的httpmodule机制），SSO首先判断是当前客户端是否存在该用户的cookie，如果不存在则跳转到UNMP的登录页面，要求用户进行登录，如果存在则传递到业务层进行解密，验证解密后的用户信息是否合法，用户类型是否合法，验证通过后会跳转到用户所请求的页面，完成一次SSO过程。验证用户的合法性，有几种情况：第一种是临时用户只跟本地数据库进行比对；第二种是AD（活动目录）用户，则需要调用AD的接口进行验证；还有一种是省portal类型的用户，需要调用portal提供的验证接口。只要有一种验证通过即视为验证成功，不再进行下一步验证，对于这种需求，由于项目初期还不知以后会有多少种验证方式，所以从构件库获取之后，在设计上增加职责链的设计模式，以适应增加新的验证方式提高扩展性。 2、数据库访问构件，从构件库获取后，抽象出一套规范的数据访问接口，以后构件的修改不会影响到其它调用的程序。为了解决以后还可以替换成其它类型的数据库平台，采用了"依赖注入"的理念，即用抽象工厂模式，通过配置文件配置数据库操作的具体实现构件（类），来生成实例，这样就可以实现以下场景：比如数据库从sqlserver2005替换成oracle，只要实现oracle数据库访问构件，然后配置在配置文件中，即可以完成不同数据库平台的切换，其它程序无须改动，做到平滑过渡，提高系统稳定性。 3、日志构件和数据库访问构件一样，也规范了一套日志接口，采用"依赖注入"等理念。因为UNMP作业平台系统，对日志功能要求比较高，如果现有的日志构件表现不佳，需要随时能替代成其它的日志构件，而不影响现有的程序。 4、定时服务构件和短信构件，这两个构件是直接从企业构件库提取出来的，只做了界面调整，定时服务采用windows服务的方式，为注册的程序提供按时间段，时间点，某月某日，每星期某天等方式执行。利用该构件可以为同步用户、告警、系统监控、及工作流待办待阅信息等提供定时执行的机制。短信构件是调用华为iod（短信网关）接口，实现短信的接收和发送，具有多线程，短信队列，同步控制等功能，第三方应用系统通过调用webservice接口，把短信信息写入UNMP数据库，然后由短信构件进行短信的发送和接收。 5、在界面层的设计中，因为构件库中没有相应的控件，只好采取自主全新开发，如时间段选择控件，文本框智能提示控件，基于flash的多文件上传控件，以及用户/部门选择控件。这些控件还提供了日常的数据验证功能，开发时跟.net服务器控件一样，拖拉到开发页面即可，让开发人员把精力集中在系统的业务功能实现上，而非技术细节，缩短了界面层的开发周期，也为后续项目积累了基础控件。 该系统采用基于构件的开发方法，从构件库中获取构件，并采用了"依赖注入"，抽象工厂，后期绑定等技术，提高扩展性、灵活性和稳定性。对于构件库没有的进行了自主全新开发，开发完成后加构件库，为后续项目开发提供构件。这种开发方法保证了系统质量并按期通过验收。 虽然从企业构件库中获取到大部分的构件，但构件本身的修改不是件容易的事情，如上述所提的单点登录（SSO）构件，数据访问构件都需要资深的开发人员采用一些如"依赖注入"，抽象工厂，后期绑定等技术，来提高扩展性、灵活性和稳定性；而构件库没有采用自主全新开发的，比如flash批量上传文件控件还涉及flash、Ajax等技术，用户/部门选择控件对javascript技术的要求也特别高，这就要求构件开发人员的选拔和培训成了一件紧迫的工作，在以后的项目中会更加重视这一工作，培养合格的构件开发人员，让更多合格的构件加入到企业构件库，提高企业的整体开发效率。 目前主流的构件技术标准有三种：Corba，EJB和Com/Dcom/Com+，Corba是OMG组织制订的一种标准，这种标准易于扩充和修改，具有较高的通用性和适应性；EJB是java体系的，凭借java跨平台的优势，用EJB技术部署的分布式系统可以不限于特定的平台Com/Dcom/Com+是微软公司研发的，主要用于windows平台，对windows支持度高。 最后展望一下构件技术的发展趋势，随着企业业务的开展，信息技术的不断应用，企业集成的问题越来越突出，构件将向soa架构靠拢（服务也是一种构件），构件间通过ESB方式进行通信，实现各应用的松耦合，提高灵活性和扩展性，以支撑不断变化的企业业务需求。
论企业应用集成
摘要: 2016年9月，我国某省移动通信有限公司决定启动VerisBilling6.0项目，该项目实现了在线计费、离线计费、内容计费、账务处理、信控管理等子系统的整合，我作为系统分析师全程参与了项目的建设。本文以VerisBilling6.0项目为例，论述企业应用集成中界面集成、数据集成、应用集成在软件集成过程中的实际应用及效果。通过界面集成，实现了账务前台、产品前台、信控前台界面的整合，把几个独立系统经过集成也一个整体展现给用户。通过数据集成，将各之前各系统产生的"信息孤岛"进行了整合，数据的一致性得到有效保障。通过应用集成，从业务逻辑上为各功能系统提供统一的数据接口，使业务逻辑更规范。通过以上集成技术的应用，项目于2017年4月成功上线，各项性能指标达到客户要求，获得省移动通信公司各级领导的好评。
近几年来某省移动用户增长至3000多万，随着移动数据流量资费的新一轮下调，导致GPRS数据流量成爆发式增长，OpenBillingNG版系统在话单处理上瓶颈显现。16年春节期间，GPRS日话单达到30亿条，话单处理处于积压状态，直到节后两周才将积压话单追完，大量跨月的话单引发了大批用户投诉，给移动业务支撑中心带来的压力非常大；该省移动通信公司相关领导联合系统运营商遂展开会议讨论解决方案，最终决定将该省OpenBillingNG版升级至VerisBilling6.0版本，以解决OpenBillingNG版本遇到的瓶颈问题。作为移动通信BOSS业务支撑的核心，VerisBilling6.0需支持24x7连续运行，满足话单的实时处理，还需要把在线计费、离线计费、内容计费、账务处理、产品管理等在OpenBillingNG版时独立的系统进行整合。我作为系统分析师全程参与了VerisBilling6.0项目的建设，VerisBilling 6.0项目由产品管理组、研发组、测试组、对账组、运维组、数据组、专家组共120人组成的项目团队，耗时8个月完成，项目从2016年9月初启动，至2017年4月30日上线。
作为系统分析师，我深知在VerisBilling6.0项目中系统集成方法对该项目的重要性。通常情况下，企业应用集成中常用的集成有界面集成、数据集成、应用集成等方法。其中界面集成通过将各系统界面进行整合，从而实现了为用户提供一个统一的系统界面的效果，增强了各系统间的交互性能。数据集成的集成点在数据访问层，通过中间件更新数据库的方式，保持数据一致；通过对数据库中通常需要同步的数据表的集成，实现各系统的数据高效同步，保证了系统数据的一致性。应用集成的集成点都在程序的内部结构中，需要根据业务的实际情况，重组结构，重新开发；是基于业务逻辑层面的集成方法，通过对系统业务逻辑进行集成，为各系统提供统一的业务接口，属于较高层次是集成方式，也是难度较大的集成。三种集成方法相辅相成，互为补充。
如何为VerisBilling6.0项目选择合适的集成方法呢？首先，作为BOSS系统的核心，Veris Billing6.0项目是一个庞大、复杂的项目，涉及账务系统前台、产品管理系统前台、信控管理系统前台的界面集成。其次，VerisBilling6.0项目还涉及计费产品库、账务产品库、信控系统数据库等数据库的整合。最后，项目还涉及在线计费、离线计费、内容计费等几个系统业务逻辑方面的集成。接下来我将从界面集成、数据集成、应用集成三个方面来具体阐述，在VerisBilling6.0项目中，我的团队是如何使用这些方式实现企业应用集成的。
界面集成的应用。在VerisBilling6.0项目中，我们实现了账务系统前台、产品管理前台、信控管理系统前台进行整合。首先，我们对信控系统页面重新做了布局，将账务系统前台、产品管理前台的功能页合并到信控管理系统的主界面上，并增加了相应的链接功能菜单。其次，在做界面集成时，我们充分的考虑了系统界面的用户友好性，对几个界面做了扁平化设计，并将几个系统的界面样式风格调整一致，使得集成后的系统看上去更像一个整体。最后，我们增加了系统导航功能菜单，完善了系统间的交互性能。经过界面集成，三个系统界面被集成到一个系统页面上，形成了一个整体。当用户登录信控管理系统后台就可以对账务管理系统、产品管理系统、信控管理系统进行操作。由于三个系统都存在独立的系统表，且都实现了自身的权限管理等功能，要想实现单点登录后进行各系统功能的操作，还需要对用户数据进行集成。
数据集成的应用。在OpenBillingNG版本中，存在账务产品库、计费产品库、局数据产品库、信控数据库等，在以往的生产过程中，经常会因数据变动后同步不及时而产生错误引发用户投诉。VerisBilling6.0项目要求将所有产品库进行整合，合并到一个中心数据库，首先，我们对各功能系统的数据库进行分析，将各库中的数据表进行梳理比对，并将平时需要做同步处理的表提取出来分析。接下来，将提取出来的数据表合并到公共数据库，实现了将分散的数据信息进整理合并。最后，将那些系统间无直接关系的表直接割接到公共数据库，经过梳理加工后，完成了对数据的集成，实现了数据的统一管理，数据的一致性得到了保障。经过数据集成，可以有效避免"信息孤岛"的产生，由于系统之间直接调用公共数据表的数据，使得系统数据在任何时候都是完整的、一致的，有效避免数据同步不及时的问题。
应用集成的应用。VerisBilling6.0项目中，大量的外围系统需要通过接口访问计费MDB和账务MDB。由于这个版本中，MDB数据表的变动非常大，为了保障CRM等外围系统对MDB的访问不受影响，首先，我们对所有的MDB接口进行了梳理并同外围系统研发人员进行了确认。接下来，针对每个接口，我们进行了重新定义，并将设计文档发与给外围系统研发负责人，然后按设计文档要求开发出相应的接口。最后，在系统测试过程中，要求各外围系统参与联调测试。由于接口的修改涉及到系统业务逻辑的调整，应用集成难度极大，对外围系统的影响面较广，在该集成方法的使用过程中，参与的人员最多，联调周期最长。应用集成对于各方参与研发的人员综合素质要求也比较高，需要充分考虑逻辑业务的变化对系统的性能的影响，对任何一个接口的疏忽都会产生较为严重的后果。
通过以上集成技术的应用，VerisBilling6.0项目于2017年4月底上线，经过半年的运行，系统各项性能指标达到可以要求，并通过客户验收，获得省移动通信公司各级领导好评。在项目结束后的讨论会上，大家也指出了项目中存在一些不足。在项目中由于MDB发生了变动，所以需要做业务逻辑的调整，我们在项目中要求所有外围系统都需要参与联调测试，但有几个接口CRM没有按要求进行相应的调整，导致系统上线当天出现CRM访问MDB出现异常。
通过VerisBilling6.0项目，使我深刻的认识到在项目实施过程中，每一个细节都需要把控好。首先，在项目中需让专家团队及时对风险进行评估，并针对每个风险点需要提供相应的应对措施，这些措施在项目出现问题时能得到有效的处置。其次，需要制定好实施计划，并严格安计划进行实施，特别是一些需要做联调测试的内容上，必须严格按要求完成，避免出现联调测试不完整这类似问题。最后，在项目中一定要严格把控好每个细节，并实现将系统每个细节的把控落实到个人。
论软件三层结构的设计
摘要：
我所在的单位是国内主要的商业银行之一，作为单位的主要技术骨干，2009年1月，我主持了远期结售汇系统的开发，该系统是我行综合业务系统的一个子系统，由于银行系统对安全性，可靠性，可用性和响应速度要求很高，我选择了三层C/S结构作为该系统的软件体系结构，在详细的设计三层结构的过程中，我采用了字符终端为表示层，CICS TRANSATION SERVER为中间层，DB2 UDB 7.1为数据库层，并采用了CICS SWITCH组，并行批量的办法来解决设计中遇到的问题，保证了远期结售汇系统按计划完成并顺利投产，我设计的软件三层结构得到了同事和领导的一致认同和称赞。但是，我也看到在三层结构设计中存在一些不足之处：比如中间层的负载均衡算法过于简单，容易造成系统负荷不均衡，并行批量设计不够严谨，容易造成资源冲突等。
正文：
我所在的单位是国内主要的商业银行之一。众所周知，银行的业务存在一个"二八定理"：即银行的百分之八十的利润是由百分之二十的客户所创造。为了更好地服务大客户，适应我国对外贸易的蓬勃发展态势，促进我国对外贸易的发展，2009年1月，我行开展了远期结售汇业务。 所谓的远期结售汇就是企业在取得中国外汇管理局的批准后，根据对外贸易的合同等凭证与银行制定合约，银行根据制定合约当天的外汇汇率，通过远期汇率公式，计算出交割当天的外汇汇率，并在那天以该汇率进行成交的外汇买卖业务。远期结售汇系统是我行综合业务系统的一个子系统，它主要包括了联机部分﹑批量部分﹑清算部分和通兑部分，具有协议管理﹑合约管理﹑报价管理﹑外汇敞口管理﹑帐务管理﹑数据拆分管理﹑报表管理﹑业务缩微和事后监督等功能。 我作为单位的主要技术骨干之一，主持并参与了远期结售汇系统的项目计划﹑需求分析﹑设计﹑编码和测试阶段的工作。由于银行系统对安全性，可靠性，可用性和响应速度要求很高，我选择了三层C/S结构作为该系统的软件体系结构，下面，我将分层次详细介绍三层C/S软件体系结构的设计过程。： 1﹑表示层为字符终端。我行以前一直使用IBM的VISUALGEN 2.0附带的图形用户终端来开发终端程序，但在使用的过程中，分行的业务人员反映响应速度比较慢，特别是业务量比较大的时候，速度更是难以忍受。为此，我行最近自行开发了一套字符终端CITE，它采用VISUAL BASIC作为开发语言，具有响应速度快，交互能力强，易学，编码快和功能强大的特点，在权衡了两者的优点和缺点之后，我决定选择字符终端CITE作为表示层。 2﹑中间层为CICS TRANSATION SERVER(CTS)。首先，我行与IBM公司一直保持着良好的合作关系，而我行的大部分技术和设备都采用了IBM公司的产品，其中包括了大型机，由于CICS在IBM的大型机上得到了广泛的应用，并在我行取得了很大的成功，为了保证与原来系统的兼容和互用性，我采用了IBM的CTS作为中间层，连接表示层和数据库层，简化系统的设计，使开发人员可以专注于表示逻辑和业务逻辑的开发工作，缩短了开发周期，减少开发费用和维护费用，提高了开发的成功率；其次，对于中间层的业务逻辑，我采用了我行一直使用的VISUALAGE FOR JAVA作为开发平台，它具有简单易用的特点，特别适合开发业务逻辑，可以使开发人员快速而准确地开发出业务逻辑，确保了远期结售汇系统的顺利完成； 最后，由于采用了CTS，确保了系统的开放性和互操作性，保证了与我行原来的联机系统和其他系统的兼容，保护了我行的原有投资。 3﹑数据层为DB2 UDB7.1.由于DB2在大型事务处理系统中表现出色，我行一直使用DB2作为事务处理的数据库，并取得了很大的成功，在DB2数据库的使用方面积累了自己独到的经验和大量的人才，为了延续技术的连续性和保护原有投资，我选择了DB2 UDB7.1作为数据层。 但是，在设计的过程中我也遇到了一些困难，我主要采取了以下的办法来解决： 1﹑CICS SWITCH组。众所周知，银行系统对于安全性，可靠性，可用性和响应速度要求很高，特别是我行最近进行了数据集中，全国只设两个数据中心，分别在XX和YY 两个地方，这样对以上的要求就更高了，为了保障我行的安全生产，我采用了CTS SWITCH组技术，所谓的CICS SWITCH组，就是一组相同的CTS，每个CTS上都有相同的业务逻辑，共同作为中间层，消除了单点故障，确保了系统的高度可用性。为了简化系统的设计和缩短通讯时间，我采用了简单的负载均衡算法，比如这次分配给第N个CTS，下次则分配给第N+1个CTS,当到了最后一个，就从第一个开始；为了更好地实现容错，我采用了当第N个CTS失效的时候，把它正在处理的业务转到第N+1个上面继续处理，这样大大增加了系统的可用性，可以为客户提供更好的服务；此外，我还采用了数据库连接池的技术，大大缩短了数据库处理速度，提高了系统运行速度。 2﹑并行批量。银行系统每天都要处理大量的数据，为了确保白天的业务能顺利进行，有一部分的帐务处理，比如一部分内部户帐务处理，或者代理收费业务和总帐与分户帐核对等功能就要到晚上批量地去处理，但是，这部分数据在数据集中之后就显得更加庞大，我行以前采用串行提交批量作业的办法，远远不能适应数据中心亿万级的数据处理要求，在与其他技术骨干讨论之后，并经过充分的论证和试验，我决定采用了并行批量的技术，所谓的并行批量，就是在利用IBM的OPC（Tivoli Operations, Planning and Control）技术，把批量作业按时间和业务处理先后顺序由操作员统一提交的基础上，再利用DB2的PARTITION技术，把几个地区分到一个PATITON里面分别处理，大大提高了银行系统的数据处理速度，确保了远期结售汇系统三层结构的先进性。在并行批量的设计过程中，我考虑到批量作业有可能因为网络错误或者资源冲突等原因而中断，这样在编写批量程序和作业的时候必须支持断点重提，以确保生产的顺利进行。 由于我软件三层结构设计得当，并采取了有效的措施去解决设计中遇到的问题，远期结售汇系统最后按照计划完成并顺利投产，不但保证了系统的开发性开放性﹑可用性和互用性，取得了良好的社会效益和经济效益，而且我的软件三层结构设计得到了同事和领导的一致认同与称赞，为我行以后系统的开发打下了良好的基础。 在总结经验的同时，我也看到了我在软件三层结构设计中的不足之处： 首先，负载算法过于简单，容易造成系统的负荷不均衡：由于每个业务的处理时间不一样，有的可能差距很远，简单的顺序加一负载分配算法就容易造成负载不均衡，但是如果专门设置一个分配器，则增加了一次网络通讯，使得系统的速度变慢，这样对响应速度要求很高的银行系统来说也是不可行的，于是我决定采用基于统计的分配算法，即在收到请求的时候，根据预先设定的权值，按概率，直接分配给CTS。 其次，由于批量作业顺序设计得不过够严谨等各种原因，容易造成资源冲突：在远期结售汇系统运行了一段时间之后，数据中心的维护人员发现了，系统有的时候会出现资源冲突现象，在经过仔细的分析之后，我发现，由于每天各个业务的业务量大小不一样，顺序的两个作业之间访问同一个表的时候便会产生资源冲突，另外，在OPC作业运行的过程中，操作员提交的其他作业与这个时间的OPC作业产生也有可能产生资源冲突。对于第一种情况，可以在不影响业务的情况下调整作业顺序或者对于查询作业运用DB2的共享锁的技术，而第二种情况则要制定规范，规定在某时间断内不允许提交某些作业来解决。为了更好地开展系统分析工作，我将在以后的工作实践中不断地学习，提高自身素质和能力，为我国的软件事业贡献自己的微薄力量。
论软件设计模式的应用
摘要：
本人2009年有幸参加了中国石油集团的高性能数控测井系统项目的开发研制工作。该系统是在当前测井成套测井装备的基础上，为了满足高精度，高性能，高效率的要求开发的测井系统。该系统由井下成套仪器，测井遥测系统，测井地面系统，测井软件系统，测井解释评价系统等子系统组成。本人在其中主要是负责测井软件系统的分析、设计以及部分开发任务。设计模式是前人设计面向对象软件的经验和总结，在软件设计中灵活的使用设计模式可以极大的提高系统的稳定性，可扩展性，以及良好的可维护性。本文描述了在测井软件系统开发过程中，如何分析和发现相关模式，以及如何选择和应用设计模式，特别是介绍了MVC模式在软件框架和相关系统模块中的应用和使用效果。在文章的最后，讨论了在实际项目开发中，设计模式应用的有关想法和教训。
正文：
随着当前石油测井技术的发展，为了能更快，更好的得到储层地层信息，解决目前国内测井系统不统一，测井精度不高，效率低下的缺点，2009年1月中国石油集团公司科技局成立了高性能数控测井系统项目，目的是为国内测井行业提供一个从井下到地面以及解释评价的整套测井系统。系统的设计目标是一次测井，取得所有合格资料，并且能保证60井次的免维修率。整个系统由井下成套仪器，测井遥测系统，测井地面系统，测井软件系统，测井解释评价系统等子系统组成。我主要是负责测井软件系统的分析，设计和部分开发工作。整个测井软件系统完成三个主要任务： 测井数据的采集、 测井数据的工程值计算、测井过程的监控。测井数据采集主要是采集井下仪器通过测井遥测系统传输的测井数据，并保证数据的完整性，正确性。测井数据工程值计算主要是把采集的数据根据不同仪器刻度计算方法进行工程值的计算。测井过程监控主要是把计算的测井数据用曲线和图像的方式实时的显示在屏幕和打印成图，由测井操作员进行实时监控。 设计模式是前人设计面向对象软件的经验和总结，在软件设计中灵活的使用设计模式可以极大的提高系统的稳定性，可扩展性，以及良好的可维护性。在测井软件系统框架进行分析和设计时，考虑如何提高系统的稳定性、可扩展性和可维护性时，我们采用了MVC设计模式。 MVC模式构架包括三个部分：模型（Model）、视图（View）、控制（Control）。模型主要是对系统的数据和逻辑运算的封装。它独立与系统的界面和I/O。视图把表示模型的数据和逻辑关系用特定的形式展示给用户。控制处理用户和软件之间的交互操作，当模型的数据有所变化时，控制负责通知视图做出相应的更新。模型、视图、控制的相互分离有利于模块之间内聚性的提高，耦合更加松散。一个模型可以对应多个视图，由控制来传播模型的变化从而更新视图。 MVC模式如何在测井软件系统实现，我们主要是从如下四个方面进行： 一、分析系统功能，分离功能模型 首先根据系统的主要任务进行系统的模块分解。根据测井软件系统数据采集、数据转换和测井监控三个主要任务，把系统分为三个模块对应于MVC模式的三个部分。其中模型（Model）对应于数据的采集和工程值的计算。测井视图（View）对应于测井监控功能。测井模型所要实现的功能包括：测井数据的采集、数据的刻度计算、数据的存储、数据的操作。测井数据的采集负责硬件平台的初始化，下井仪器的初始化， 井下仪器数据的中断相应，数据帧的采集，数据帧的重组等。数据的刻度计算主要是根据不同的仪器实现数据的刻度计算，包括刻度系数表的获取、刻度计算、深度延迟计算等。数据存储主要是原始数据的存储和测井数据的存储。这里我们采用的是测井公用的XTF格式做为数据存储格式。数据的操作是视图和模型之间数据交互的接口。它主要是提供数据输入和输出功能。 二、视图的设计与实现 视图主要是提供测井数据的图形显示。通过调用模型中的数据操作方法，提取测井数据，根据不同的测井数据提供曲线、波列、图像等多种表现形式。在本系统的实现中，为了提高数据采集的稳定性和程序的健壮性，采用进程间通讯的方式。就是说视图的实现本身一个独立的程序。它与模型之间的通过TCP/IP网络进行通讯。视图主要包括数据源、数据表象对象、绘图打印模块等部分组成。数据源负责得到模型（Model）的数据，然后把数据分配给每个数据表象对象。数据表象对象是个有层次的类家族，其基类是绘图类（CDrawObj），所有的数据表象包括道（CDrawTrack）、曲线（CDrawCurve）、波列（CDrawWave）、图像（CDrawImage），数值对象（CDrawData）等都是从其派生的。最后有绘图打印模块提供管理，负责视图的区域更新，数据表象的绘制和打印等功能。 三、控制的设计与实现 控制主要功能是提供用户的输入输出反馈，同时监控模型的数据变化，通知视图进行更新。由于控制和视图的耦合非常的紧密，在架构实现中，控制和视图是在一个应用程序中实现的。控制主要分为井下仪器控制和视图控制两个部分。其中井下仪器控制主要是由操作人员根据视图中的曲线和图像信息，对仪器发出的状态控制命令，以保证测井过程中数据和仪器的安全。视图控制则是操作人员对视图显示参数的调整，包括鼠标的响应和键盘的响应以及用户对测井原始图的特殊要求如道大小，曲线位置的摆放，颜色的调整等。 四、使用可动态添加算法模型 由于每次测井作业中下井仪器串的仪器种类和仪器的数量都是变化的，为了能更好的抽象出实际的测井模型，提高系统的灵活性，在模型中数据刻度计算部分，我们采用的动态添加的方式。我们把不同测井仪器的刻度算法封装到动态连接库，然后根据测井作业的不同，调用用不同的仪器动态库中的刻度算法。由于视图和控制与模型之间的松耦合，当用户添加算法模块，视图与控制基本不要修改。 在采用MVC模式的软件框架后，整个系统分为两个部分，数据采集管理器和数据实时浏览器。数据采集管理器对应于模型（Model）的实现，数据实时浏览器对应于视图（View）和控制（Control）的实现。我们采用的是Visual C++.net 基于Window2003平台来进行系统开发。采用MVC模式给我们带来了如下好处： 1、由于模型（Model）与视图（View）和控制（Control）之间的松耦合，使得我们非常容易就实现了一个模型运行同时建立多个视图。这在调试仪器时非常有用，当硬件人员调试仪器时直接连接网线就可以一边看仪器一边看数据。不再需要象以前必须到地面系统控制室查看数据了。 2、适合多硬件平台的跨接。由于不同的硬件平台上采集数据的方式都不同，有的系统采用的是PCI总线，有的是USB接入，有的是ISA卡接入。由于模型（Model）和视图（View）的松耦合，当要移植到不同的硬件平台上是我们只有修改相应的模型（Model），有可以实现对不同硬件平台的支持。 3、良好的可维护性和扩展性。由于采用MVC模式，系统模块功能划分明确，代码实现也相对容易。代码的错误不会在系统中扩散，同时由于可以动态添加仪器算法模块，当用户添加新仪器时，不需要更改系统程序，只有添加仪器动态库DLL就可以了。 在整个系统的开发中，我们还应用了一些别的模式， 有些模式是在进行系统设计时，就考虑到而特意实现的， 有些模式是在采用别的方法实现后，效果不太理想，在代码重构时引进的。在应用设计模式进行系统设计和开发后，整个系统各个模块之间逻辑变的相对独立，耦合也很松散，结构的扩展性良好。而且使得代码的重用的程度变好，减少了错误的发生和错误在代码中的扩散。但是在实际应用模式的过程中，我还发现模式应用的经验越丰富，模式应用的就越好。有时在采用何种模式时，有几种模式方案可以采用，但是具体采用那个模式就需要不断的尝试，看看模式是否满足实际的需要。特别要注意的是不能为了设计模式进行设计，也就是过分设计的问题。这样会导致设计过于复杂，偏离程序设计简约够用的基本原则。 目前设计模式在软件开发中的应用正引起广大开发人员的注意，各大软件开发商也在软件开发工具中提供了有关设计模式的自动应用的工具，相信设计模式会越来越多应用于软件的设计和开发中。
论软件维护及软件可维护性
摘要：
本人2010年有幸主持并参与了国内某银行小额信贷综合系统的开发研制工作，作为技术经理主要负责需求分析、概要设计及核心模块的设计实现等工作。该系统主要面向中小企业及个人客户，为其提供融资贷款服务。由于银行项目软件通常有较长的维护周期，并且要求有效地控制维护成本和维护风险，因此需要采用多种措施来提高软件的可维护性。本文结合作者实践，讨论了软件维护的三种类型，改正性维护、预防性维护和完善性维护的特点，阐明了影响软件可维护性的三个主要因素，即分析阶段要尽可能地模块化设计，高内聚低耦合；缺陷预防需要新技术新工具的支撑；变更控制要通过UCM方式来进行闭环管理。本文结合该项目的开发过程，详细介绍了在项目中所进行的软件维护活动，为提高软件可维护性所采取的措施，并基于这些评价了实施过程中的效果。最后总结了项目在软件维护及可维护性方面取得的成绩和需要改进的地方。
正文：
众所周知，当前以中小、小微企业及个人为主的小额借款人"融资难，融资贵"的问题仍然比较突出，为解决这个问题国家出台了一系列政策措施鼓励和支持银行业开展小额信贷等创新型金融服务。 2010年5月，我所在单位受国内某银行委托开发研制该行小额信贷综合业务系统。 该系统主要为中小企业及个人客户提供无担保无抵押的信贷资金。借款人可以通过网上银行、电子邮件、手机短信、电话及邮寄等多种途径申请贷款。系统收到贷款申请后，先通过外部征信系统获取到借款人的信用信息，并基于信用信息对其进行风险评级，给出参考额度和贷款利率，再由客户经理通过系统进行复审及放款。贷款发放后，风险经理可以通过系统对借款人的还款情况进行实时监控和跟踪。与此同时，该系统还可以针对不同情况给出相应的催收建议及催收措施，从而帮助银行回收贷款，降低不良率。该系统主要包括网上银行、风险评级、授信审批和贷后监控部分，具有客户管理、账务管理、合约管理、催收管理和报表管理等功能。 我作为单位的技术骨干，担任该项目技术经理一职，主持并参与了该项目，主要工作有：需求分析，概要设计，核心模块的设计实现，协助项目经理制订项目计划。由于银行软件系统通常生命周期较长，尤其是软件的维护周期较长，往往还需要一个小型团队专职进行项目的维护工作。为了能够有效控制维护成本，提高软件的可维护性，我们团队在开发工程中采取了一系列方法措施。下面我将详细论述这些方法措施在软件维护方面的作用和意义。 通常比较常见的软件维护类型有：改正性维护、预防性维护和完善性维护。通俗来讲，改正性维护即修改软件交付后发现的缺陷，主要通过提供修复后的新版本、修复脚本或者修复补丁等方式。预防性维护是指在软件开发过程中预防缺陷的产生，是一种防患于未然的措施，正确地进行缺陷预防能够很好地降低软件的开发机维护成本。完善性维护是指由于用户在使用软件的过程中，业务需求发生了变化，因而需要对软件系统的功能进行变更的一种维护，这种维护手段不仅要求软件自身有较好的扩展性，同时也要求从管理的角度做好变更的跟踪和控制。 我认为影响软件可维护性的主要因素有三点，首先，系统在分析设计阶段是否很好地遵循了规范，有没有使用成熟可靠的通用构件，系统构架是否扩展性强，模块设计是否高内聚松耦合。其次，缺陷预防的投入是否足够，有没有使用新技术、新工具来提高效率和质量。再次，变更控制管理是否到位，有没有做到问题闭环管理，对于代码的修改是否有评审监控，对于修改后的版本是否有效管理。我们在实际开发中使用了多种技术手段、管理手段来落实以上三点。 1. 尽可能多地使用成熟、稳定的通用构件来增强系统的可靠性、可维护性和可扩展性。 在本项目开发过程中，我们考虑到银行会根据国家政策的调整来调整风险评级的规则，会根据央行的基准利率和计算方法来调整利息的计算方法。如果每一次调整都需要修改源代码，重新编译、打包、回归测试、部署，势必会影响到维护效率，缩短系统的在线时间。我们引入了Drools业务规则引擎和Groovy脚本引擎来解决这一问题。Drools引擎可以把一系列风险评级的推理判断规则封装在一个规则文件中，该文件是一个文本文件，可以方便地对其进行修改编辑。值得一提的是，Drools规则文件的语法使用自然语言风格，即领域定义语言（DSL），这样业务人员也可以轻松地阅读、编写、评审规则文件。Groovy脚本引擎可以动态地执行数学公式，将计算结果返回给主程序。公式中所用到的参数变量可以由业务人员通过Web页面在系统中自行设置，而无需开发人员修改程序或者修改数据。Groovy脚本引擎在计算时，会将业务人员定义的参数以键值对的方式代入公式，从而达到灵活计算的效果，正是由于采用了Drools业务规则引擎和Groovy脚本引擎，我的团队才能有效地提高了系统的可维护性，即当业务规则和利率计算公式发生变化时，业务人员可以不依赖于开发人员和系统管理员的参与，也无需修改程序，重新部署新版本等繁琐步骤就能完成系统的修改升级，大大地提高了系统的在线时间。 2. 使用新技术、新工具进行缺陷预防。 我们认为在软件开发过程中有效的缺陷预防胜于疲于奔命的缺陷修复，因此我们引入了一系列新技术、新工具来进行缺陷预防。首先推行持续集成技术，即采用Jenkins持续集成引擎，每隔15分钟对项目代码进行一次构建，并自动执行单元测试用例，每隔2小时执行一次集成测试用例、代码静结构分析和代码覆盖率分析，并将结果通过邮件发送给项目成员。其次，优化开发人员的集成开发工具，1）使用JUnit做单元测试；2）使用Emma做代码覆盖率测试；3）使用Findbugs和PMD做代码静结构分析；4）使用Checkstyle做代码规范检查。与此同时，测试人员使用EasyB和Selenium来开发自动化回归测试用例，并将其与Jenkins引擎集成。质量控制人员使用Sonar对代码质量、规模和设计进行度量。这样就可以使团队成员从多种角度对项目质量把关，进而使整个系统的设计、开发、集成、测试过程透明可见，真正地做到了让项目在"阳光"下进行，从而有效地达到了进行缺陷预防的目的，大大地降低了缺陷逃逸率。但是另一方面，有项目成员抱怨，太多的检查预防措施耽误了开发进度，连项目经理也会有相同的顾虑。我通过和公司另一项目A做了对比来说服他们，A项目基本不做预防检查，表面上看似很快的进度却在系统测试阶段搁浅了，反反复复地"回归"，以至于模块、代码千疮百孔、缝缝又补补、补丁摞补丁，甚至在上线后发现了严重缺陷，造成了公司和客户的损失。项目组成员听取了我的建议，不但没有了抱怨，更是从严、从深地积极做好缺陷防范工作，正是由于我们的项目在开发过程中就夯实了基础，才在验收测试及试运行是无任何故障，受到客户的好评。 3. 使用UCM变更控制 我们在项目开发过程中使用IBM Rational ClearCase和ClearQuest对变更和缺陷实施UCM管理。在项目维护期，闭环的变更和缺陷管理显得尤为重要。所谓UCM，是指客户提出的变更申请和缺陷进行统一管理，包括分类，优先级评定和状态跟踪等。在我们项目中，客户通过ClearQuest提出变更请求，待项目经理及变更委员会批准后，新需求会分配给相应的开发人员。开发人员只可以根据ClearQuest的任务签出相应模块的程序代码进行修改，而对于其它不相关的代码，他们则无权限访问。开发人员完成代码修改和提交后，变更请求流转至测试人员处进行复测和回归测试，最后经用户确认后，才由发版经理发布部署。整个流程可管理、可追踪、有记录并与版本控制系统无缝集成。 4. 结束语 综上所述，我们在项目开发过程中采用成熟文档的通用构件，并引入新技术、新工具进行缺陷预防，同时结合UCM变更控制管理等一系列手段来提高系统的可维护性，有效地降低了软件的维护难度和维护成本。自系统上线至今未发现任何严重缺陷，系统稳定可靠，得到了客户和公司领导的肯定。同时，我也发现了一些不足之处，例如，如何平衡缺陷预防、质量控制和项目进度的关系。我相信我和我的团队可以再不断地尝试、摸索和总结中解决好这一问题。我在日后的工作中会更努力地提高专业技术水平，为我国的软件事业贡献出自己的力量。
论信息系统安全性设计
摘要：
随着国内航空业的高速发展，机场空中交通日趋繁忙，机场空管有必要提前掌握空中态势，做好空中交通管制的准备工作。现阶段各个机场空管系统的信息获取手段单一，依赖本机场雷达提供的信息已不能满足场内空中交通管制的需要。为了改变这种现状，我单位对民航部分系统实施改造，开发了一个空管综合数据定制系统，使得机场空管能够根据业务需要自主定制所需信息，实现资源共享。 在整个项目中，我担任空管综合数据定制系统的主任设计师，负责空管综合数据定制系统分析、设计和开发工作。空管综合数据定制系统是B/S结构的WEB应用系统，用户登录系统后可以在有限的范围内自主定制飞行情报、气象情报等信息。 在项目开发过程中，我们注重系统的安全性。在系统安全方面，我们采用登录控制、授权管理等方法保证用户访问安全；用日志记录加数据备份保障系统数据安全；用双机热备系统保障服务器系统运行安全。
正文：
国内民航空中交通管制按地理区域划分，由各大地区空中交通管理机构通过区域中心管制系统实现对各个机场空管系统的管理工作。机场空管的信息数据通过内部网络或专线等方式汇集到区管中心，运用数据融合等情报处理技术形成多种信息的统一态势，以便于对管制区内的飞行统一实施空中交通管制。 现阶段各个机场空管系统的信息获取手段较为单一，管制所需的数据来源处于一个"被动"状态。为改变这种现状，实现空管信息资源共享，我单位对地区空中交通管制系统进行初步改造，以实现机场对飞行情报、气象情报、飞行计划等信息的按需定制。 在该项目中，我参与项目的需求分析，并担任用户按需定制功能的主任设计师，负责设计和开发"空管综合信息数据定制系统"。该项目于2010年8月开始启动，历时7个月完成项目的开发工作，并于2011年3月投入试运行。目前系统已交付，运行至今相当稳定。 根据系统的功能需求，空管综合信息数据定制系统按功能分为用户管理，信息定制、数据查询与维护等部分。用户管理分为用户帐户管理、用户基本信息维护、用户定制权限管理。根据用户的类型，系统设置了两种用户的角色，分别是管理员用户和定制用户。信息定制功能根据信息的类型分为飞行情报定制、飞行计划定制、气象情报定制和飞行流量定制等。定制用户根据其定制类型权限可以分别不同类型的信息。数据查询与维护功能包括定制状态查询、日志数据查询、基础数据查询与维护等。 在系统开发初期，我们对系统的层次架构和系统环境进行仔细分析。定制并不限于在用户系统的哪一个席位上进行操作，并考虑到实现用户定制应对用户的客户端影响最小化，所以我们决定采用B/S架构，以WEB方式实现用户定制功能。这样也使得应用程序都存放在WEB服务器上，方便了系统的部署与维护，实现了零客户端。考虑到空管系统中UNIX操作系统的HP服务器，我们以JAVA为主要开发语言。为使系统有更好的可扩充性、灵活性与逻辑性，并实现系统的业务处理与显示相分离，系统采用MVC模式，结构分为表示层、业务层（控制层、业务逻辑层、数据访问层和消息发送层）、数据层。在系统中采用Tomcat作为Web服务器，数据库服务器则使用原来在空中交通管制系统中作为数据库服务器的Oracle9i。 空管行业是一个比较特殊的行业，他们的系统有一个独立的网络，在物理上与互联网隔离。空管综合信息数据定制系统也是运行在他们内部网络上的WEB应用系统，所以在安全问题上，我们重点保证用户访问安全、数据安全以及系统的运行安全。 （一）保障用户的访问安全的措施 虽然系统运行在空管内部网络上，但是也必须保证只有合法用户才能访问系统。我们采用登录页面作为用户访问系统的首页，这也是WEB应用系统的通用模式。在这个页面上需要输入用户名与口令，系统验证正确后，用户才能进行下一步操作。用户名与密码需要从用户使用的客户端传输到WEB服务器上进行验证。如果是定制用户，则用户使用的计算机很可能与WEB服务器不在一个网段中，那么必须考虑对用户名与密码信息进行保护，防止数据的机密性的破坏。我们查找相关的HTTP安全技术，决定使用HTTPS安全技术保护用户名和密码信息在网络中的传输。TOMCAT对HTTPS提供了直接的支持，实现起来也不复杂，但由于HTTPS连接过程比一般的HTTP连接要慢，所以我们也只在登录页面使用了HTTPS连接。 用户名和密码被保存在服务器端的数据库相关的用户信息表中，所以具有相应权限的数据库用户可以通过oracle客户端或者Sql Plus工具直接查看用户信息表的内容。为了防止用户密码的泄露，我们对密码字段的内容进行加密，然后再存储到数据库的表格中。我们编写了一个中间转换类实现对密码字段的转换，方便了系统对密码的读写操作。 在开发需求中，系统用户分为管理员用户和定制用户，这两种用户对系统有不同的访问范围和操作方式，而定制用户对定制情报数据也有不同的地理范围权限。因此，对用户进行操作权限控制也是我们必须考虑的安全性问题。 我们在用户登录时就根据用户名对用户的身份进行判断，针对不同类型的用户设计不同的访问界面和菜单，这也就使管理员和定制用户对应不同的功能。对于定制用户不同的定制地理范围权限，我们设计了一个类似定制界面中的ActiveX地图控件，管理员用户在授权管理时，在这个地图控件中绘制出一个地理区域，并将结果保存到定制用户的权限表中。这样在定制用户实施定制操作时，系统将他的地理范围权限显示在定制界面中的地图控件上，他所绘制的定制区域不能超出其地理范围权限，否则告警并要求他重新输入。 （二）数据安全的保护措施 对于系统的数据安全问题，我们通过两个方面的措施，一个是记录用户操作的日志；二是定时备份系统数据。 我们对定制用户的每一个定制操作及取消定制操作都进行了日志记录，以便于查找定制用户是否正常使用系统，和检查用户的定制范围是否在授权范围内。管理员需要对用户信息进行维护，对用户权限进行管理，以及对系统基础数据维护。我们对管理员的每一个操作也进行了日志记录。日志记录不但可以用于查询管理员和定制用户的操作历史记录，还有助于分析系统其它的功能问题，防止用户的误操作。 我们在UNIX服务器设置了一个定时任务，每天对系统的关键数据进行了备份；每周自动进行一次数据全备份。定时任务是个服务器上的SHELL脚本，执行数据库表格数据的备份，和一些运行数据文件的备份。对于系统自动产生的备份文件，我们采用人工的方式按期拷贝出来，转存到备份盘上，以释放服务器上的磁盘空间。 （三）系统运行安全机制 为保证系统的运行安全，我们采用了双机热备的方式。在服务器端运行着一主一备的服务器。服务器上运行着集群软件，主备服务器用"心跳"来检测对方的状态。这些状态包括数据库状态、WEB服务器状态以及其它子进程的状态。备机一旦发现主机的某个子进程的状态失效，立即自动切换。这两台服务器上oracle数据库搭建了高级复制，以保证数据库中表格数据的同步。 从系统的实际运行效果上看，系统在安全性方面很好地符合了用户的需求。安全性是一个WEB应用系统必须重视的问题，不管系统运行在内网还是互联网。用户登录、用户权限、数据安全，以及系统运行安全等方面是WEB系统重要安全问题。我们在系统运行安全方面还有个异地备份需要考虑。现在状况是只在一个区域中心的系统运行综合数据定制系统，如果本地的系统出现故障，还需要一个异地和备中心来接替运行。但在主备中心的数据同步和状态通信上还存在不少需要解决的问题。
论信息系统的安全性设计(二)
摘要：
2011年我有幸参加了某单位遥感卫星测控系统项目的研制，我在系统中担任软件分系统负责人，主要负责软件开发的管理工作、软件需求分析，软件设计方面的工作。遥感卫星测控系统主要完成对遥感成像卫星的遥测，遥控和数传任务，软件分系统作为整个系统的分系统之一，主要完成系统硬件设备工作参数设置，系统运行状态监视和遥感图像数据的管理功能。由于卫星测控系统的操作牵涉到卫星资源的控制和遥感影像产品的管理，系统的安全性设计变得十分重要。在项目的需求分析阶段，项目组对系统的安全性进行了分析，得出的结论是系统可能存在物理安全隐患，网络通信安全隐患，和系统安全隐患，在项目的设计阶段项目组针对系统安全风险分析报告中提到的系统安全隐患做了相应的设计方案。主要采用异地备份来解决可能发生的自然灾害对系统造成的不可恢复的损坏。采用防火墙技术和入侵检测系统对网络访问加以控制，采用非对称加密技术和数字签名技术保证重要数据的安全性和可靠性。本文对系统的安全性设计进行了详细介绍，最后总结了系统运行的效果和不足之处，以及针对不知之处采取的补救措施。
正文：
2011年我参加了某单位遥感卫星测控系统项目的开发工作，我在系统任命中担任软件分系统负责人，主要负责软件开发小组的管理和对系统进行软件需求分析和设计。遥感卫星测控系统由发射分系统，接收分系统，测试标校分系统，天伺馈分系统和软件分系统组成，系统的五个分系统各施其职，协调工作，完成对遥感卫星的跟踪，遥测，遥控和数传任务。软件分系统在系统中扮演指挥者的角色，主要负责对系统工作状态的监视，工作参数的设置，执行卫星跟踪任务计划和管理遥感影像数据。软件系统也是整个系统的人机接口，工作人员在执行任务时对设备的大部分操作都要通过软件分系统完成，系统对防误操作方面的要求比较高，软件分系统承担了卫星遥控计划的执行和卫星遥感数据的管理，因此，系统对安全保密性要求比较高。 软件分系统采用C/A/S三层体系结构，数据库服务器主要完成对系统的任务计划，遥感数据和系统日志信息进行存储管理；业务服务器主要完成系统的业务处理，主要包括与上级指挥中心的网络通信功能，与其他硬件分系统的嵌入式软件之间的串口通信功能，对系统工作参数的设置和工作状态的监视功能，执行上级指挥中心下发的任务计划，对遥感影像数据进行管理等功能。系统包括多个客户端软件，主要完成人机接口功能。系统的数据库服务器，业务服务器，多个嵌入式监控软件和部分客户端处于同一个局域网内，部分客户端部署在指挥中心，通过光纤网络与业务服务器通信。系统与指挥中心的网络接口是系统与外界的唯一一个外部接口。 项目组在分析了系统的网络结构和组成后，我们发现系统在物理方面，网络通信方面，系统安全性方面都存在安全隐患。物理方面，由于系统由多个服务器和大量磁盘阵列组成，系统保存了大量的中药数据，尽管系统本地也采取的备份措施，但是如果发生火灾，洪灾，地震等不可抗击的自然灾害，将可能永久性损坏系统服务器和存储设备，导致大量的宝贵数据丢失；在网络传输方面系统对外有一个网络接口与指挥中心进行通信，这个非法访问者提供了机会，可能存在外部的非法入侵行为。在网络上传输的数据会被非法获取，导致重要信息的泄密，或者外部非法入侵者冒出指挥中心给系统发送错误的任务计划，导致系统执行错误的遥控指令，这将会导致严重的后果。在系统内部，应用服务器和其他硬件设备的嵌入式软件通过串口传输控制命令和设备状态，有少部分设备由于设备位置离系统机房比较远，并且要经常移动位置，所以不得不采用无线通信的方式，这也给非法入侵者提供了机会。可能通过截获无线信号获取设备控制命令，或者伪造设备命令导致设置执行错误的指令。所以网络通信将是系统实施安全防护的重点部分。在系统访问控制方面，系统的服务器采用windows server2008操作系统，客户端采用windows xp操作系统，虽然操作系统提供了比较安全的用户身份认证和访问控制权限控制，基本上满足了系统安全性要求，但是也有可能因为系统的漏洞或者系统感染病毒或木马程序导致非法入侵者可以访问系统资源。在应用系统层面，主要存在工作人员误操作的隐患。 经过需求阶段的系统安全分析，项目组得出了系统安全风险报告，项目组根据报告中提到的问题进行了系统安全性方案设计，物理方面的安全问题主要是自然灾害导致的，并且一旦发生也是不可抗拒的，我们采取将系统重要数据定时进行异地备份，在指挥中心建立一个重要数据备份库。予解决系统物理方面的安全问题。 在网络通信方面，我们采取了两方面的解决措施，一方面是在系统外网入口处安装应用防火墙，控制外部用户对系统内的资源访问，通过设置访问ip端口号限制，已经通信服务方面的限制，阻止非法用户通过网络进入系统，同时安装入侵检测系统，达到及时发现网络访问异常告警的目的，根据入侵检测系统报告的网络情况，及时修改防火墙设置。另一方面是对系统与中心传输的数据进行加密和合法性验证，主要采用了非对称加密技术RSA和数字签名技术。有效防止数据被窃取，也保证了数据源的合法性，同时也防止双方的抵赖性。对于系统内部的无线传输，我们采用具有加密功能的无线数传模块，发送方在发送数据之前进行数据加密，接收方接收到数据后先进行解密即可得到正确的命令。防止了无线通信可能造成的数据泄密。 在操作系统级，我们关闭了很多没用的网络通信服务，设置了用户访问权限、策略。对用户的访问权限进行控制，同时安装杀毒软件定期进行病毒扫描，防止系统被病毒感染或者木马程序入侵。及时安装系统补丁，定期更新病毒库。定期更新用户密码。对重要的数据采用加密软件进行加密存储。在应用软件方面，我们主要采取用户身份认真和访问权限控制，将用户等级分为管理员，操作用户和监视用户；管理员可以创建用户和执行一切操作，操作用户可以控制设备，执行任务计划，监视用户只能对系统工作状态进行监视。这样可以防止卫星测控系统软件被不相干人员随意操作。 系统经过一年多的运行，目前运行稳定，没有发现非法访问和泄密事件发生，说明我们的系统安全性设计方案是成功的，但是在系统运行中也发现一些考虑不周全的地方，用户可以通过PE光盘启动系统，绕过已经安装的操作系统直接访问系统硬盘，这相当于操作系统设置的用户名和密码，用户访问权限没有用了。我们发现这个问题后，封闭了所有设备的光驱和USB接口，并加强了安全管理方面的工作，对系统机房实行二十四小时监控，防止非法人员接近系统主机，经过这个项目，我们总结出信息系统的安全工作必须从技术上和安全管理制度以及工作人员的思想上全面考虑。单从技术上无法保证系统绝对的安全性，系统安全任重道远，我们时刻准备对系统不足之处进行改进。
论信息系统的架构设计
摘要：
本文结合作者所参与研发的前台业务报表系统升级改造项目对如何设计信息系统的架构进行了论述。前台业务报表系统是国内某大型商业银行全行的通用报表平台，每日通过从各业务系统采集的数据进行报表展现，为该银行的决策者和经营管理人员提供各类系统交易的日报表信息平台。项目的主要内容是将原有的前台业务报表系统进行报表展现产品升级，对技术架构进行重构，对业务功能进行扩充，全面满足海内外的管理部门、业务部门对查看日趋复杂的大量的报表需求。 本文首先说明了作者在需求分析之后，软件设计之前为何重视架构设计的原因，并描述了通过分析本项目的规模、复杂程度、变化的因素等进行的新系统的架构设计。在此基础上依据具体的数据论述了作者采用的架构对于项目质量的效果。最后作者对本项目在架构设计的不足之处也做了简要分析，并提出了改进建议。
正文：
我在国内一家较大的商业银行的软件开发中心工作。由于我行前台业务报表从99年试点投产以来已经运行多年，其使用的报表产品版本对新操作系统的兼容等已经存在问题需要升级；原系统的技术架构及业务功能也已无法满足现今的业务报表要求。2010年2月，总行规划并立项于10月前完成对业务报表进行改造，对使用的报表展现产品升级，对技术架构进行重构；根据日趋复杂的报表需求，对业务功能进行扩充。我有幸参与了该项目并担任系统架构设计和项目管理工作。 本项目的主要任务是将国内前台业务报表和海外业务报表应用已有功能进行重构，实现境内外框架一体化，支持多语言与多时区，境内外分行均使用统一应用体系架构实现各业务类报表的处理、展现及打印功能；将国内版数据处理和存储集中在各个一级分行，海外版数据统一集中存放在海外数据中心；对使用的报表产品进行升级，采用SAP公司提供的CRYSTAL报表工具，完成报表体系架构的调整及报表程序的移行升级。 架构是信息系统的基石，对于信息系统项目的开发来说，一个清晰的架构是首要的，架构在软件需求与软件设计之间架起一座桥梁，着重解决软件系统的机构和需求向实现平坦地过渡的问题。架构在软件开发中为不同的人员提供了共同交流的语言，体现并尝试了系统早期的设计决策，并作为系统设计的抽象，为实现框架和构建的共享和重用、基于架构的软件开发提供了有力的支持。本系统是一个系统改造项目，涉及国内37家分行，16家境外机构，规模庞大而复杂，开发周期长，为保证项目质量，我们在需求分析之后，明确了本项目的开发任务，软件设计之前进行了详细的软件架构设计。 考虑到以下几点： 1、我行各分行及海外机构分布较散，另外随着INTERNET的迅速发展，部分报表信息需要通过网络向总行领导汇报展现； 2、各分行对数据查询速度要求高，每日各网点产生的数据量很大，要求每日报表在10秒内展现，并能进行批量打印； 3、银行内对数据的保密性要求高； 4、增强系统的可扩展性，并能访问若干年前的报表数据。 典型的软件架构风格有很多。例如，设计图形用户界面常用的事件驱动风格、设计操作系统常用的层次化设计风格，设计编译程序厂用电管道与过滤风格、设计分布式应用程序常用的客户机/服务器风格等。一个实用的软件系统通常是几种典型架构风格的组合。 经过分析，发现之前的前台业务报表系统C/S模式体系结构已显示出了他在异构的、分布式的网络环境中的不足，可维护性和发布性等较差，并不利于系统扩展，难以满足新系统的要求，基于B/S体系的WEB应用有利于系统的扩展性、维护性。C/S 一般建立在专用的网络上，小范围里的网络环境，局域网之间再通过专门服务器提供连接和数据交换服务。B/S 建立在广域网之上的， 不必是专门的网络硬件环境，有比C/S更强的适应范围， 一般只要有操作系统和浏览器就行；C/S一般面向相对固定的用户群，对信息安全的控制能力很强。一般高度机密的信息系统采用C/S 结构适宜. 可以通过B/S发布部分可公开信息。B/S 建立在广域网之上， 对安全的控制能力相对弱。结合CS和BS架构的优缺点，我们最终采用C/S和B/S混合的架构设计。 一、系统支持分布式部署和集中式部署两种方式。 国内采用分布式部署方式，应用环境部署在各一级分行，数据库部署两个Oracle实例。 海外采用集中式部署方式，应用环境部署在海外数据中心，数据库部署两个Oracle实例，两实例间通过DBLINK进行参数表的同步。 客户端程序国内部署于各二级分行、支行和网点；海外部署于海外分行。 二、报表文件的生成： （1） 为减少传输的数据量，批量打印及离线归档采用文本方式，并且文本可以进行压缩传输，可有效减少网络传输流量。 （2） 所有报表数据文件都预生成，生成文本文件的批量服务器端进行自行开发，不依赖于报表工具产品，以根据数据本身的特色进行开发提高批量处理效率。例如采用SQL嵌入到C编程语言中，利用C语言提高对文件处理的效率。 （3） 在批量服务器输出文件的同时，把相关的结果也写入到数据库的B/S查询表中供B/S客户端查询展现，B/S查询表的数据库表的结构与批量打印使用的文本文件结构一致。 三、报表查看、批量打印部分： （1） B/S架构：报表查看结果的HTML页面由服务器生成，客户端本地不处理任何数据。对于B/S客户端方式，是一个纯集中式系统，数据的逻辑处理以及显示处理都是集中式的。对于B/S的报本查询需设立缓存机制。 （2） C/S架构：是一个服务器与分布式结合的报表处理系统。服务器端主要工作是数据的逻辑处理，例如报表的汇总、统计、字典转换、币种折算、数据表关联等各类数据的逻辑处理。 四、版本在线自动更新功能： C/S客户端提供版本在线自动更新功能。打开客户端程序后，客户端会根据临时文件夹及更新日志记录自行检查是否与服务器版本号相符，若发现不符合，则客户端自行下载最新的版本，并自行安装新版本，解决网点的由于报表频繁升级的安装管理维护问题。 前台业务报表升级改造项目最终在2010年底投产并取得了较大的成功。完全符合海内外各分行及总行管理部门的需求，得到了大家一致好评。 当然，本项目的是存在一些不足之处的。我们在设计时将大部分的精力都放在了整体功能测试上，对于性能的设计上只考虑整体情况，较少考虑具体的数据库性能优化，例如表的索引设计以及锁事务处理机制我们有所忽略。导致投产后仍有少量交易因SQL访问效率问题出现了响应时间过长的情况。这一点也是我们今后的项目设计中需要注意改进的地方。
论信息系统架构设计(二)
摘要：
本人于2010年7月参加国内某某知名港口供电业务系统的开发工作，在该项目中主要担任系统架构师工作，主要负责该系统架构和网络安全体系架构设计。近年来随着港口吞吐量的增加，港口供电业务信息化需求越来越强，而传统的管理方式已经无法满足业务需求，因此我们开发此系统。通过需求分析，我们将该系统分解为港口供电系统电费管理、生产调度管理、安全管理、机电设备管理、物资管理、申报流程管理、网上办公管理、报表及查询分析管理。 本文以某某港口的供电业务系统为例，分析了管道/过滤器体系架构风格、事件驱动风格、层次架构风格以及客户端浏览器风格，以及以上三种架构风格是如何在该系统中应用的，充分说明了体系架构风格对系统开发的重要性。实践证明，采用良好的软件体系架构风格，不仅可以节省开发和维护成本，提高系统开发的效率，而且可以使系统具有很好的开放性、易扩展性，便于移植性。
正文：
本人于2010年7月参加了国内某某知名港口供电业务系统的开发工作，在该项目中担任系统架构师工作，主要负责系统架构和网络安全体系架构的设计。随着港口生产业务的发展，港口供电线系统越来越繁忙，而传统的管理方式越来越无法满足港口供电系统信息化管理需求。原来存在一的些信息系统"信息孤岛"现在较为明显。因此，开发新的系统满足日系增长的港口供电业务系统信息化要求日益强烈，为了消除"信息孤岛"现象，同时使新开发的系统能够适应港口未来业务的发展，新的系统架构必须设计良好，具备兼容性、可扩充性。 通过需求分析我们将该系统分为电费管理、生产调度管理、安全管理、机电设备管理、物资管理、申报流程管理、网上办公管理、报表及查询分析管理模块。为了适应港口供电系统信息化不断发展的需求以及对整个系统架构的分析。我们采用面向服务（SOA）的架构，运用WCF技术进行设计。数据库采用oracle10g，系统通过微软的.net平台C#进行开发。为了高效的开发出此系统，我们采用以下方法来实现此系统功能。 首先，系统整体采用层次架构设计模式。我们将这个系统架构分为四层。首先，我们通过需求分析，将客户端用户需求分解为一个个服务。由于该系统涉及港口供电业务系统方方面面，在该系统中需要编写很多服务。我们在前端编写的服务以插件（plugin）的形式进行注册，通过统一的端口以申请访问服务器上的服务。中间契约层作为提供服务的接口，通过契约层将所有的服务操作暴露给用户，所有的服务都需要在契约层上通过ServiceContract进行发布，客户端所有需要的服务也在契约层上进行查找，客户端无须知道每一个服务（service）是如何实现。服务实现层具体实现如何完成每一个服务，所有的服务层要和契约层相关联，通过注册表以访问数据库， 实现和数据库相关的所有操作。服务发布层和服务实现层相关联，通过XML语言实现和服务实现层相关联。将所有的服务注册到相关的应用服务器，以提供契约层成功查找服务。进而实现系统的通信功能。通过采用这种层次架构风格给系统带来了很大益处，实现了系统的高可复用性。如安全信息管理模块、物资管理，港口其他单位的信息化需求较为相似，等在为其他企业开发项目的系统的时候，只需要为该企业开通权限，允许调用此服务即可。同时通过此层次架构的开发，增强了系统网络安全性，由于跟个层次的功能明确，客户端将无法直接访问数据库层，取而代之的是专门的应用服务器去访问访问服务，而其通过对服务器的访问安全设置，提高了对数据库的访问安全性。此外，大大提供企业应用的集成度，在该系统中，港口供电系统的所有应用被集成到一个统一的平台下，如财务部门、劳资人事部门、生成管理部分都需要调用人员信息，在统一的系统平台下，该信息只要一次完成，多次调用即可，打破了传统的同一个界面在不同的应用系统中要重复开发的现象。 其次，在该系统中通过采用管道/过滤器架构风格，实现从人力资源管理系统到供电业务系统的对接。目前港口的人力资源管理系统有专门的系统。我们从该系统中找到需要的数据输出报表接口。供电业务系统开发相应的接口对应获取并分析处理数据，将数据转化为供电业务所需要的数据类型。通过这种方式实现了数据共享功能，避免了数据重复录入，以及和最新的人事信息保持同步问题。 再次，通过采用事件调用架构风格，实现了流程申报管理和生产调度模块和物资管理的对接。在本供电业务管理系统中，申报的流程管理需要关联于此相关联的生产调度信息以及物资相关内容。当在申报流程中填写申请单审批通过后，将自动关联生产派工单以及物资申请单据。 生产调度部门在完成相关任务，物资仓管人员完成物资的派送后，申报流程界面将自动出现此信息，然后根据具体工作审批内容，走公司管理的各种流程化管理步骤。通过此模式成功实现了与申报流程相关内容的自动管理，无需其他手工操作，当以后改进系统时候，可以很方便操作。 第四，通过采用客户端/浏览器（B/S）风格，实现了网上办公模块的管理。对于供电系统宣传模块，以及公司考勤管理、部门工作计划、公司通讯录等内容放到供电系统网站上，这样供电系统的员工不论在公司，还是在外出差，都能方便的使用这些功能。在该部分的设计中，由于考虑到系统涉及很多公司内部管理数据，所以对安全方面做了比较严格的控制，引入了PKI/CA体系的安全认证。系统与用户之间的信息交互都是加密进行的，如此设计，既能满足用户的"随时随地"使用办公模块，又保障了系统的安全性，同时增强了系统的可维护性。 该系统已经于2011年8月，成功通过了供电业务部门的验收，大大提高了港口供电系统信息化管理水平，提高了港口供电系统生产效率，得到了用户的肯定。但是目前该系统由于开发时间有限，系统架构仍存在一些需要改进之处。由于港口供电业务系统平台注册的服务很多，系统用户也很多，有些服务调用响应时间较长，如电费收取模块本身计算较为复杂，在加上服务查找时间，导致客户端获取数据较慢。今后，我们将对层次架构风格系统进行应用服务器分类，将服务按功能发布到不同服务器上，同时提供备份应用服务器，当主服务器无法工作时，备用服务器可以接替主服务器进行工作。这样将提升服务性能，确保系统正常运作。在采用管道/过滤风格的系统将加强对输入数据的校验，如我们发现在人力资源管理系统中输入的数据有些格式错误，数据不正确，这就要求系统提供智能化识别功能。在采用事件架构风格进行系统设计时候，将提供回滚机制，如在此系统中的流程申报出错，系统会提示与此相关联的所有操作撤销，以确保系统的一致性状态。 对于一个成功系统，往往融入好几种体系架构，在该系统中，我们通过共同使用这几种架构，大大提高了系统开发效率，节省系统开发和维护成本，使系统具有更好的开放性、易扩展性，以及可移植性。在今后的日子里，本人一定会更加努力钻研专业基础知识，提高自身水平，为国家信息化建设尽自己绵薄之力。