徐州网站简介,做网站彩票网站,湖南中核建设工程公司官方网站,前端静态网站开发文章目录 论SOA技术的应用论SOA在企业信息化中的应用论UP#xff08;统一过程方法#xff09;的应用论分布式数据库的设计与实现论改进Web服务器性能的有关技术论基于UML的需求分析论基于构件的软件开发论基于构件的软件开发(二) 论SOA技术的应用
摘要#xff1a; 本人于… 文章目录 论SOA技术的应用论SOA在企业信息化中的应用论UP统一过程方法的应用论分布式数据库的设计与实现论改进Web服务器性能的有关技术论基于UML的需求分析论基于构件的软件开发论基于构件的软件开发(二) 论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月我参加了某市供电公司《电力营销管理信息系统》的开发工作并担任系统架构师一职主要负责系统分析和架构设计。该系统包括业扩管理、计量管理、电量电费核算管理、收费与账户管理、线损管理等五个模块。系统采用了StrutsSpringHibernate的主流Web应用框架降低了开发的难度和成本降低了组件的耦合度增强了软件的可维护、可扩展性。 项目的成功很大程度的归功于项目开发采用了RUP模型对整个的开发过程进行规范和改进。本文以该项目为例结合作者的实践讨论了UP统一过程方法在软件开发中的应用。从初始阶段建立业务模型并确定项目边界细化阶段分析领域、选择构件构建阶段把构件组合成产品最后把软件移交给用户四个阶段说明了UP的具体应用。重点介绍了分析领域、选择构件。 正文 2011年3月我参加了某市供电公司《电力营销管理信息系统》的开发工作并担任系统架构师一职主要负责系统分析和架构设计。该供电公司年供电量在10亿度以上计量点915个大客户209个。以前的业务流程是电话报装、手工派单、自主开发的VFP系统算费、财务系统收费开票等。随着供电量业务的扩展原业务流程暴露出各环节分散无法进行统一的管理客户的满意度低。为了解决上述问题该供电公司决定建设一套电力营销系统。以系统的建设促进用电管理水平的提高以电力信息化推动电力企业现代化。杜绝重复投资整体规划实现用电管理信息的高速交互和决策提升客户的满意度降低管理成本。 系统采用了StrutsSpringHibernate的主流Web应用框架开发工具采用MyEclipse10.0硬件配置两台IBM X3650安装Oracle10g做数据库服务器在两台服务器上搭建了高级复制功能保证数据库中数据同步。两台IBM X3650以双机热备的方式做营销应用服务器两台服务器上运行着集群软件通过“心跳”来检测对方的状态发现故障能自动切换。一台IBM X3650做算费服务器。 RUP统一软件开发过程是一个面向对象且基于网络的软件开发方法论。可以应付种类广泛的软件系统不同的应用领域不同的组织类型不同的性能水平和不同的项目规模。UP是基于构件的与其他软件过程相比有三个显著的特点用例驱动、基本架构为中心、迭代和增量。正是由于UP具备上述特点使采用UP模型的开发过程能提高团队成产力简洁清晰的过程结构为开发过程提供了较大的通用性。 根据RUP模型我们把整个的开发过程分为初始阶段、细化阶段、构建阶段和交付阶段。每个阶段结束的时候都要安排一次技术评审如果评审结果令人满意就可进入下一阶段。 1. 初始阶段 初始阶段的任务是建立业务模型、确定系统边界。首先我们采用用户访谈、用户调查和联合讨论会的方式捕获用户需求详细了解用户对系统的预期目标捕获在系统招标书中没有明确的性能指标。其次我们专门召开了一次联合讨论会会上参与的各方代表经过讨论就需求的优先等级达成一致意见。最后对需求进行分析确定了项目的目标、特性和用例模型完成了《需求规格说明书》的初稿并通过了用户的评审。 2. 细化阶段 细化阶段的任务是分析问题领域、建立体系结构、选择构件。通过对问题领域的分析我们把系统划分为5个主要模块业扩管理、计量管理、电费电量核算管理、收费与账户管理和线损管理。确立了软件的整体架构部件之间的交互接口构件的设计与选择。 基于构件的开发可以减少开发中重复的工作降低开发成本缩短开发周期提高软件的质量和灵活性。获取构件有多种途径第一种是在现有构件库中直接提取符合要求的构件或对已有构件做适当的修改。第二是采购第三方构件现在市场上有很多成熟的产品比如开发平台、数据库平台、各种通用构件等。第三是自己开发符合需要的构件当构件库和第三方构件没有满足需求时必须自己开发满足需要的构件。 该项目中上述的三种方法我们全部都用到了。在以前的项目开发中我们提取了很多的可重用构件加入自己的构件库。比如权限管理对于任何管理系统都很重要我们提取符合RABC基于角色的访问控制模型的独立授权构件将权限与角色相关联通过成为适当角色的成员来获得该角色的权限简化了授权的管理。该系统的流程要求根据业务需要可以配置我们提取了工作流引擎可以满足流程的调度、图形化的定义和管理。 市场上有很多成熟的构件包括开源的和商业的是不需要自己开发的。直接使用可以缩短开发周期降低开发成本。我们采用的StrutsSpringHibernate框架就是典型的开源框架可以让我们把主要的精力放在业务的实现上而不用去关心数据如何从数据库中读出和写入请求如何在各层之间传递等。报表是管理信息系统必不可少的功能我们采用明宇公司的如意报表满足报表在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年底验收满足客户方提出设计、生产、经营、管理的需求。 信息平台包含有企业门户、综合办公、设计生产、经营计划、技术质量、人力资源、档案管理、信息中心、公司决策、后台管理等十个子系统。为利用好以前各种硬件平台的投资选择信息平台运行于windowssqlserver2005 平台上采用.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技术的要求也特别高这就要求构件开发人员的选拔和培训成了一件紧迫的工作在以后的项目中会更加重视这一工作培养合格的构件开发人员让更多合格的构件加入到产品构件库提高公司的整体开发效率。 目前主流的构件技术标准有三种CorbaEJB和COM/Dcom/ComCorba是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运行于windowssqlserver2005平台上采用.net开发技术。采用四层B/S架构这四层分别为界面层外观层业务逻辑层及数据访问层项目的各种功能基本具有这四层架构。系统的主要功能有通过一次登录后可以任意跳转到其它各系统的单点登录用于统一管理各应用系统用户信息为各系统提供收发短信/彩信的消息服务还有日志管理和告警管理还有为其它功能提供短信、监控、同步用户、同步工作流待办待阅信息等的定时服务。这些功能都以webservice接口的方式公开给各应用系统调用有了这些基础功能应用系统就可以省去单点登录用户管理收发短信等功能的开发和维护缩短开发周期和降低开发成本。 因为UNMP是个平台系统接入的各种应用系统繁多影响面广开发周期短所以复用性稳定性和扩展性要求比较高团队最终采用了基于构件的开发方式基于构件的软件开发是一种自底向上的基于包装好的构件来构造应用系统的方法它主要包含构件的检索与获取理解与评价构件修改构件组装构件应用与布署等工作。基于构件的开发涉及到构件的获取问题目前构件的获取目前主要有三种方式自身企业库第三方构件和自主开发因为考虑到需求变化时构件的修改问题我们只采用了从企业库获取和自主全新开发两种方式。 鉴于公司在电信行业多年的项目积累我们整理了以往成功实施的项目形成企业构件库针对性的选择合适的构件对于与需求类似的构件进行修改后做好构件的版本记录。企业构件库构建采用从成功实施过的项目中抽取共用的底层的一些模块封装其内部逻辑为外部提供一致的调用接口形成可复用的构件。经过我们的分析、筛选和比对发现以往项目中经常用到的单点登录模块只需要改进一下验证方式就可以复用到新系统中接着从共用的底层模块中发现了数据库访问和日志管理模块只要在灵活性和可替换性方面加强一下也达到我们复用的标准最后发现的定时服务和短信组件这两个模块几乎是最成熟的除了界面外其它不用修改可以直接复用。 接下来详述一下组成系统的主要构件 1、首先介绍一下单点登录构件SSOSSO可以让用户登录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技术的要求也特别高这就要求构件开发人员的选拔和培训成了一件紧迫的工作在以后的项目中会更加重视这一工作培养合格的构件开发人员让更多合格的构件加入到企业构件库提高企业的整体开发效率。 目前主流的构件技术标准有三种CorbaEJB和Com/Dcom/ComCorba是OMG组织制订的一种标准这种标准易于扩充和修改具有较高的通用性和适应性EJB是java体系的凭借java跨平台的优势用EJB技术部署的分布式系统可以不限于特定的平台Com/Dcom/Com是微软公司研发的主要用于windows平台对windows支持度高。 最后展望一下构件技术的发展趋势随着企业业务的开展信息技术的不断应用企业集成的问题越来越突出构件将向soa架构靠拢服务也是一种构件构件间通过ESB方式进行通信实现各应用的松耦合提高灵活性和扩展性以支撑不断变化的企业业务需求。
