软考高级-系统架构设计师 论文范文参考（一）

论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方式进行通信，实现各应用的松耦合，提高灵活性和扩展性，以支撑不断变化的企业业务需求。