深圳互联网信息平台业务保障毕业设计毕业论文模板

HUNAN毕业设计(论文)设计论文题目：深圳互联网信息平台业务保障模块设计和实现TheDesignandRealizationofTheBusinessSupportDomainofShenzhenInternetInformationPlatform深圳互联网信息平台业务保障模块设计和实现摘要伴随计算机网络飞速发展，Internet技术越来越广泛应用，网络覆盖区域不停扩大，多种多样网络应用快速蔓延，很多企业和企业开始为实现其内部各大平台、各项应用、各类资源和用户群整合而感到烦恼而又势在必行。即使现在中国部分企业提出了很多策略和方法，如采取三层架构和多层架构、使用EJB实现企业分布式应用问题。不过这些策略只能说是处理了部分问题，在我们系统中统一认证、web服务标准化、外系统对接等问题全部还期待一个很好处理方案。另外，已经有处理方案难以满足大型企业庞大而复杂业务逻辑。所以有必需采取新技术和更为合理架构来适应这一需求。本文以深圳电信“互联网信息服务平台”项目业务保障模块设计和实现为例，给出了为建立一个统一互联网信息服务支撑平台时所采取架构和策略一个缩影。论文研究内容关键为业务逻辑和功效点实现。并牵涉系统两大关键技术关键点：统一认证和单点登陆实现，外系统交互实现。在体系架构方面，系统采取通用三层架构，各层独立设计，确保了系统可扩展性、可伸缩性和可用性。在数据库设计方面，采取对象/关系映射技术，将分析建模阶段实体对象映射成关系型数据表，并经过关系约束、事务处理来确保数据完整性。在业务逻辑上采取EJBSessionBean技术。在外系统交互方面，系统采取IBM消息驱动技术JMS和队列NQ技术，拥有良好扩展性。文体结构遵照从需求分析到总体设计到数据库设计，再到具体设计总体路线对系统设计和实现进行了具体描述。关键词：深圳互联网信息平台，业务保障域，三层架构，EJB

TheDesignandRealizationofTheBusinessSupportDomainofShenzhenInternetInformationPlatformAbstractAsthedevelopmentandspreadingofkindsofwebapplications,manycorporationsandenterprisesbegintoworryabouthowtointegratetheirplatforms、applications、resourcesandusergroupstogether,whichistrulyimperative.Therehavebeenmanysolutionsandstrategiesbroughtforwardbysomeenterprises,suchasadoptingtheThree-tierstructureorMulti-tierstructure,usingEJBtoaccomplishdistributedenterpriseapplications.However,theycannotbesuitableineverycircumstances,forexample,howtoachievethegoalofsingle-sign-on,standardizationofwebservicesandinteractionwithout-systemsandsub-systems.NottomentionthosesolutionsobviouslyhavedifficultiestosatisfyvariousdemandsofthecomplexbusinesslogisticsofLargeenterprises.Sowehavetofindaway,anewtechnology,amoreconsciousstructuretomeetthesedemands.WiththecaseofShenzhenTelecom’s“InternetInformationServicePlatform”(IISP)project,thisthesistrytodescribehowtofoundaglobalinternetinformationplatform,whatstructureandstrategydidweadopttofinishthistask.Thecontentofresearchincludestheconceptofunifiedauthenticationandsingle-sign-on,therealizationdetailsofbacksupportmoduleandtheinteractionwithoutersystems.Inarchitecture,weusethethree-tierstructurecommonly,eachtierindependentlydesignedtoensurethatthesystemexpansibility,scalabilityandavailability.Inthedatabasedesigns,weadopttheobject/relational-mapping(ORM)technology,whichmaptheentitiesgotfromanalysisandmodelingstagetoobject-relationaldatasheets,andboundedbyrelations,transactionprocessingtoensuredataintegrity.Inbusinesslogic,wetakeEJBtechnologytosatisfydemandsofbothremoteinvocationandlocalinvocation.Ininteractionwithoutersystem,weimplementJMSandNQtechnologyprovidedbyIBMtoensurecommunicationbesafeandsteady.Moreover,thisthesis,inthesequenceofrequirementanalysis,systemdesign,databasedesign,detailsystemdesign,havedetaileddescribedthedesignimplementationofthissystem,whichhavealsogiventhespecificsolutionofautomaticreplenishmentplatformandautomaticreplenishmentaccreditationprocessmodule.Keywords：IISP，BusinessSupportDomain，Three-tierArchitecture，EJB

目录1绪论 11.1课题研究背景和现实状况 11.2项目建设必需性 11.3建设目标 21.4系统概述 21.5论文组织结构 41.6本章小结 52技术和框架概述 62.1什么是JSP 62.2Struts介绍 72.3Hibernate介绍 92.4EJB介绍 92.5网站框架搭建 102.6开发环境和运行环境 122.7本章小结 133系统分析 143.1需求分析 143.1.1账务上传功效需求 143.1.2投诉管理功效需求 153.1.3停机/复机功效需求 153.2步骤分析 153.2.1账务上传步骤分析 163.2.2投诉管理步骤分析 163.2.3停机/复机步骤分析 183.3本章小结 194具体设计 204.1数据库具体设计 204.2投诉管理模块 204.3账务上传模块 224.4停机复机模块 234.5关键步骤设计 234.5.1怎样提供Web服务和调用Web服务 234.5.2脏数据问题处理 244.5.3事务回滚采取方法 254.5.4字典表设计 274.6本章小结 285系统实现和展示 295.1投诉管理模块实现 295.2账务上传模块实现 295.3停机模块实现 315.4复机模块实现 325.5本章小结 326总结和展望 33致谢 34参考文件 351绪论因为深圳电信对业务整合迫切需求，深圳互联网信息平台才应运而生。论文叙述了该项目标一个经典功效域开发和实现过程，以此反应出整个系统概貌。1.1课题研究背景和现实状况现在深圳拥有500万网民、400万家庭用户、60万宽带用户、30万企业用户，含有了庞大用户资源和得天独厚互联网资源。深圳电信响应“共享和世界同时信息文明”企业使命，在深圳这个庞大互联网平台上已经做了很多努力，也获取了不少结果，比如中国游戏中心、深圳之窗、互联星空、蓝色通道、网上营业厅、VVGOO商务领航购物网站、号码百事通、VBC精英俱乐部等，为企业用户和个人用户带来了不少方便和便利。在给用户带来便利同时怎样让这些门户和频道在统一计划下运转，在原有技术平台上挖掘新增值点，快速响应市场需求，又成了迫在眉睫事情。现在深圳电信信息运行渠道相对独立，品牌推广分散。各门户全部有各自用户，用户资源优势没有充足发挥，缺乏对用户深度经营手段；缺乏多渠道、多平台宣传模式，分散了用户注意力，收效单一；个人用户关心和拓展，和商业用户关心和拓展，均消耗大量成本，充足整合各门户资源，重用已经有功效应用，将是互联网信息服务平台需要处理难题。1.2项目建设必需性面对迫在眉睫增值业务和门户平台整合任务，和怎样快速应对巨大互联网商机，深圳电信需要将现在门户、频道业务和现有资源进行整合，尽可能地将各项目纳入统一计划管理中，将原有成熟技术组件进行提取，将各门户用户和商家进行融合，达成共享目标。同时还需要将现在应用进行多方位扩展展现，比如E家服务、三信支撑、蓝色通道、信息内容管理展现在不一样门户、频道等。深圳电信需要结合电信传统业务特点推出新业务新功效新应用时能够在各门户、频道配置出来，降低反复开发资源浪费。1.3建设目标本项目建设总体目标是为了愈加好地支撑深圳电信互联网增值业务发展，理顺互联网信息服务平台展现、应用、资源和能力架构，处理现在平台分离、运行支撑能力和门户展现能力不足问题，实现运行中急需用户统一认证、互联网产品管理、订购管理、合作伙伴管理和业务数据和部分基础服务能力共享功效，从而支撑三信门户、我e家信息服务、蓝色通道等互联网应用平台建设，提升深圳电信互联网信息服务运行能力[1]。111.4系统概述项目关键目标是建立一个统一互联网信息服务支撑平台，提供互联网产品运行支撑能力，覆盖电信业务用户及互联网注册用户。平台需求分为以下多个功效域：供给商/合作伙伴管理域,服务管理域,产品/套餐管理域,用户管理域,业务开通功效域,业务保障功效域。图1-1所表示。图1-1互联网信息服务平台功效域供给商/合作伙伴管理域经过互联网信息服务平台向外提供产品起源系统，统称为供给商/合作伙伴，供给商/合作伙伴管理域关键管理和这些提供服务能力组织实体相关业务和操作。向AP/CP/ASP业务人员和电信管理人员提供管理入口，实现供给商在线注册登记，电信管理人员对其进行开通确定，和供给商业务人员维护供给系统基础信息，电信管理人员对分帐规则及结算业务进行管理。服务管理域由供给商/合作伙伴管理域所管理服务/内容供给系统所提供全部基础服务能力纳入这个功效域中管理。服务管理域关键对AP/CP/ASP业务人员提供注册登记，内容变更等功效，对电信管理人员提供管理审核，基础信息展示等功效。产品/套餐管理域以服务管理域所管理基础服务/内容，电信管理人员能够组装成多种产品及套餐，制订资费规则和业务使用规则，正式对外开放为可订购产品/套餐。用户管理域互联网信息服务平台在对深圳电信各类用户提供服务，开放产品/套餐订购/使用权限同时，要处理两个关键矛盾，第一，各类用户基础信息由各个已经运行业务系统管理这种形式不会改变，互联网信息服务平台不能替换这些系统对已经有用户管理；第二，同一个自然人或法人实体（用户）在深圳电信各类系统中开通了多个登录入口账号（用户），各个用户实体怎样关联到同一个用户实体之下，既关系到用户使用体验满意度，也影响以后整合营销能力建设。关键功效有三个：A依靠已经建成统一认证平台，或各相关业务系统认证功效入口，实现和产品订购/使用相关用户认证和授权。B提供自助绑定（由用户自行指定用户关联关系）和自动绑定（在订购/使用业务时自动生成用户关联关系）两种方法，逐步理清用户关联关系，整合到用户实体下。C依靠统一认证功效和绑定信息，实现跨平台单点登陆/统一访问功效。业务开通功效域用户管理域所管理用户，全部能够使用业务开通功效域中功效，选择、订购、使用产品/套餐管理域所管理产品及套餐。对外部用户，业务开通功效域关键提供产品展示、订购、受理入口，对电信业务人员，业务开通功效域关键提供审核、开通业务、施工管理等功效。对于已经存在订购关系，如电信业务用户使用E家套餐内产品，业务开通功效域依靠服务总线取得相关信息，统一对外部用户展现。以上是系统整体介绍。论文所围绕是系统一个经典功效模块——业务保障域实现。其中包含关键功效点有：账务上传、用户投诉管理、停机/复机/拆机业务。账务上传是指对业务开通功效域中确立订购/使用关系，每当发生使用行为，计费功效域依据产品/套餐管理域所定义资费规则，实施对应计价处理。依据订购时所确立SLA及相关约定，可能需要产生对应帐单，交由统一支付平台，以网银、V卡等方法支持。对于不需要实时付费托收账户，在结算期产生总帐单，交由帐务系统处理。投诉管理支持用户对其已订购产品使用，统计相关使用行为，作为以后整合营销基础信息。提供投诉处理/查询功效，对正在处理开通业务进行查询，对已经开通业务使用过程中发生问题进行跟踪处理。停机和复机功效关键是依据订购产品/套餐时所确定SLA及资费规则，对未能立即付清费用业务进行停机，对停机后付清费用业务使用进行复机。1.5论文组织结构全文共分为六章，其中：第一章是绪论部分，在这一章节中，首先简单介绍了课题起源和背景，然后叙述了中国外研究现实状况，最终依据起源和背景提出了系统建设标准，并叙述了系统建设意义和论文组织结构。第二章关键叙述了系统总体框架搭建和运行环境。首先讨论了系统所包含各项框架技术，然后在比较传统框架和对业务需求简单分析基础上提出了本系统框架合理性。最终叙述了系统开发环境和运行环境。第三章关键对本系统模块进行了全方面分析。首先简单叙述了模块需求，然后分析了个模块步骤。经过二者反应了系统具体要求和具体情况，为后文叙述打下基础。第四章关键对系统设计进行具体叙述。首先具体叙述了系统数据库设计，然后叙述了系统各模块具体实现细节设计，最终对设计上牵涉到关键技术做出着重分析和叙述。第五章对系统实现进行了细致叙述。第六章为总结和展望。对整个系统进行了全方面总结和叙述。提出了系统不足之处和对未来发展展望。1.6本章小结本章从整体上介绍了深圳电信互联网信息服务平台项目建设背景和项目标建设目标。然后介绍了整个项目标概况和关键模块。在此背景和基础上着重叙述了论文所围绕经典模块——业务保障域功效关键点和牵涉内容。最终对论文整体结构组成和各章节内容进行了简述。2技术和框架概述在深入讨论系统需求、设计和实现之前，我们需要先了解对应基础知识和关键技术。同时，对于系统开发环境和开发工具也要有所了解。因为，不一样项目环境决定着实现上很多细节。2.1什么是JSPJSP(JavaServerPages)是由SunMicrosystems企业提倡、很多企业参与一起建立一个动态网页技术标准。JSP技术有点类似ASP技术，它是在传统网页HTML文件(*.htm,*.html)中插入Java程序段(Scriptlet)和JSP标识(tag)，从而形成JSP文件(*.jsp)。JSP和JavaServlet一样，是在服务器端实施，通常返回该用户端就是一个HTML文本，所以用户端只要有浏览器就能浏览。Web服务器在碰到访问JSP网页请求时，首先实施其中程序段，然后将实施结果连同JSP文件中HTML代码一起返回给用户。插入Java程序段能够操作数据库、重新定向网页等，以实现建立动态网页所需要功效。JSP页面由HTML代码和嵌入其中Java代码所组成。服务器在页面被用户端请求以后对这些Java代码进行处理，然后将生成HTML页面返回给用户端浏览器。JavaServlet是JSP技术基础，而且大型Web应用程序开发需要JavaServlet和JSP配合才能完成。JSP含有了Java技术简单易用，完全面向对象，含有平台无关性且安全可靠，关键面向因特网全部特点。用JSP开发Web应用是跨平台，即能在Linux下运行，也能在其它操作系统上运行。JSP技术使用Java编程语言编写类XMLtags和scriptlets，来封装产生动态网页处理逻辑。网页还能经过tags和scriptlets访问存在于服务端资源应用逻辑。JSP将网页逻辑和网页设计和显示分离，支持可重用基于组件设计，使基于Web应用程序开发变得快速和轻易。自JSP推出后，众多大企业全部支持JSP技术服务器，如IBM、Oracle、Bea企业等，所以JSP快速成为商业应用服务器端语言。JSP1.0规范最终版本是1999年9月推出，12月又推出了1.1规范。现在较新是JSP1.2规范，JSP2.0规范征求意见稿也已出台。新JSP规范版本包含新用于提升程序职员作效率功效，关键有：AnExpressionLanguage(EL)许可开发者创建Velocity-样式templates(amongotherthings).愈加快更简单创建新标签方法。Hello,${param.visitor}<%--sameas:Hello,<%=request.getParameter("visitor")%>--%>什么是MVC模式呢？为了把表现层presentation从请求处理requestprocessing和数据存放datastorage中分离开来，SUN企业推荐在JSP文件中使用一个模-视图-控件Model-view-controller模式。规范SERVLET或分离JSP文件用于处理请求。当请求处理完后，控制权交给一个只作为创建输出作用JSP页。有多个平台全部基于服务于网络层模-视图-控件模式(比如Struts和Springframework)[2]。2.2Struts介绍Struts是一个基于SunJ2EE平台MVC框架，关键是采取Servlet和JSP技术来实现。其最初萌芽于CraigMcClanahan构思。现在，Struts是Apache软件基金会旗下Jakarta项目组一部分，其官方网站是。因为Struts能充足满足应用开发需求，简单易用，灵敏快速，故而颇受关注。Struts把Servlet、JSP、自定义标签和信息资源(messageresources)整合到一个统一框架中，开发人员利用其进行开发时不用再自己编码实现全套MVC模式，极大节省了时间，所以说Struts是一个很不错应用框架[3]。Struts框架版本已从最初1.x发展到现在2.x。Struts2是以Webwork设计思想为关键，吸收了Struts1优点，所以，能够认为Struts2是Struts1和Webwork结合产物。系统模块采取了较新Sruts-2.1.4版本Struts2并不是简单版本升级。它号称是一个全新框架，当然但这仅仅是相对Struts1而言。Struts2和Struts1相比，确实有很多革命性改善，但它并不是新公布新框架，而是在另一个赫赫有名框架：WebWork基础上发展起来。从某种程度上来讲，Struts2没有继承Struts1血统，而是继承WebWork血统。或说，WebWork衍生出了Struts2，而不是Struts1衍生了Struts2。因为Struts2是WebWork升级，而不是一个全新框架，所以稳定性、性能等各方面全部有很好确保：而且吸收了Struts1和WebWork二者优势，所以，是一个很值得期待框架。图2-1Struts框架图Struts2大致工作步骤图2-1所表示。当接收到一个浏览器请求httprequest时，由框架内置拦截器Interceptor做部分拦截或初始工作。当外部httpservletrequest到来时初始到了servlet容器，传输给一个标准过滤器链。ActionContextCleanUp这个在集成插件方面很有用。Otherfilters(SitMesh,etc)调用FilterDispatecher会去查找对应ActionMapper。假如找到了对应ActionMapper它将会将控制权限交给ActionProxy。ActionProxy将会经过ConfigurationManager来查找配置struts.xml。下一步将会经过ActionInvocation来负责命令模式实现（包含调用部分拦截Interceptor框架在调用action之前）。一旦action返回，会查找对应Result。Result类型能够是jsp或freeMark等。这些组件和ActionMapper一起返回给请求url（注意拦截器实施次序）。响应返回是经过我们在web.xml中配置过滤器。假如ActionContextCleanUp是目前使用，则FilterDispatecher将不会清理sreadlocalActionContext。假如ActionContextCleanUp不使用，则将会去清理sreadlocals。2.3Hibernate介绍在介绍Hibernate之前，首先需要了解是什么是持久化，什么是ORM[4]。持久化（Persistence），即把数据（如内存中对象）保留到可永久保留存放设备中（如磁盘）。持久化关键应用是将内存中数据存放在关系型数据库中，当然也能够存放在磁盘文件中、XML数据文件中等等。数据库读写是一个很花费时间和资源操作，当大量用户同时直接访问数据库时候，效率将很低，假如将数据持久化就不需要每次从数据库读取数据，直接在内存中对数据进行操作，这么就节省了数据库资源，而且加紧了系统反应速度。ORM（ObjectRelationalMapping），即对象关系映射，是持久化一个实现方案。以O/R原理设计持久化框架（Framework），包含O/R机制、SQL自生成、事务处理和Cache管理等。ORM实现思想就是将关系数据库中表数据映射成为对象，以对象形式展现，这么开发人员就能够把对数据库操作转化为对这些对象操作。所以它目标是为了方便开发人员以面向对象思想来实现对数据库操作[5]。Hibernate是一个Java语言下对象关系映射处理方案。它是一个自由、开源软件。它用来把对象模型表示对象映射到基于SQL关系模型结构中去，为面向对象领域模型到传统关系型数据库映射，提供了一个使用方便框架[6]。Hibernate不仅管理Java类到数据库表映射（包含从Java数据类型到SQL数据类型映射），还提供数据查询和获取数据方法，能够大幅度降低开发时人工使用SQL和JDBC处理数据时间。它设计目标是将软件开发人员从大量相同数据持久层相关编程工作中解放出来。不管是从设计草案还是从一个遗留数据库开始，开发人员全部能够采取Hibernate。Hibernate对JDBC进行了很轻量级对象封装，使得Java程序员能够随心所欲使用对象编程思维来操纵数据库。Hibernate能够应用在任何使用JDBC场所，它既能够在Java用户端程序使用，也能够在Servlet/JSPWeb应用中使用。最具革命意义是，Hibernate能够在应用EJB（EnterpriseJavaBeans是Java应用于企业计算框架）J2EE架构中替换CMP，完成数据持久化重担[7]。2.4EJB介绍EJB是sun服务器端组件模型，最大用处是布署分布式应用程序，类似微软.net技术。凭借java跨平台优势，用EJB技术布署分布式系统能够不限于特定平台。它定义了一个用于开发基于组件企业多重应用程序标准。其特点包含网络服务支持和关键开发工具(SDK)。在J2EE里，EnterpriseJavaBeans(EJB)称为Java企业Bean，是Java关键代码，分别是会话Bean（SessionBean），实体Bean（EntityBean）和消息驱动Bean（MessageDrivenBean）。在系统模块中关键用到是比较简单会话Bean（SessionBean）[8]。2.5网站框架搭建传统J2EE架构方法采取纯Servlet+JavaBean或Jsp+Servlet+JavaBean。其业务代码，逻辑代码和业务展示代码均无可避免在同一servlet中出现，此种架构直接造成代码结构混乱。其维护代价高．可拓展性差等缺点展露无疑。JSP技术得出现一定程度上填补了Servlet尴尬局面，使得传统得架构开始走向MVC三层架构模式。在参考文件[9]中余腊生、任炬OJ系统对三层架构有很好叙述。我们熟知MVC架构模型图2-2所表示：图2-2传统J2EE架构模型传统架构技术表现层用Jsp+Servlet技术来处理，业务层使用JavaBean，访问层是JavaBean(即常说Dao)，和资源层连接采取JDBC控制。此种构架方法带来弊端有代码编写量大，开发效率低，JDBC连接安全性没有得到确保，业务代码无法高程度脱离。资源管理需手动编写代码控制等等。SSH三层架构出现，极大程度上处理了传统架构所带来问题。其架构模型和传统J2EE架构相同，关键差异在于各层内部怎样实现。SSH三层架构体系中，表现层使用了Struts框架，实现了视图控制分离。Hibernate是JDBC轻量级对象封装，它是一个独立对象持久层框架。Hibernate强大缓存机制能一定程度上缓解服务器端频繁读取数据库压力，这也是Hibernate被广泛使用得关键原因之一。而且Hibernate高效权衡了运行效率、内存消耗和开发效率，并自动封装了事务控制。安全性代码等关键功效。鉴于以上原因，系统采取了struts框架技术和hibernate框架技术。但在架构上稍有区分于传统和普遍架构。那就是以ejb来作为业务逻辑控制层。首先需要说明是Struts+hibernate+ejb框架仅仅是网站代码框架技术实现方案。必需强调这里说代码框架并不是整个系统架构，它反应是J2EE网站开发环境，还不能完全反应网站和外系统交互情况和对外接口提供和外部接口使用情况。系统整体架构图2-3所表示。它是面向服务，即基于SOA思想[10]。整个架构中贯通着一条服务管理总线，全部系统功效以服务形式公布到总线上。图2-3系统整体框架图代码框架则图2-4所表示。其中表述层或称表现层采取了Struts2框架，业务逻辑层经过封装EJB远程或当地SessionBean实现，持久化层则使用了Hibernate框架技术。系统采取了Websphere应用服务器，在持久层并非直接访问数据库，而是经过JNDI来访问，这关键也是出于系统整体架构考虑。图2-4模块框架2.6开发环境和运行环境系统开发环境关键包含IBMRationalApplicationDeveloper（简称RAD[11],见图2-5）7.00版本集成开发工具和Oracle10g数据库。因为RAD工具中已经集成了Websphere6.1服务器。这里并不再需要其它应用服务器来支持布署和测试。因为模块会调用外部服务和其它模块接口，而全部服务均经过总线来管理。所以在RAD项目中应该包含JMS调用项目包（由项目组其它组员开发和提供）。图2-5RAD版本信息图2.7本章小结本章关键介绍了项目包含相关框架和技术。然后讨论了系统怎样利用这些技术搭建系统框架。同时接收了系统开发环境和运行环境。3系统分析系统分析建立在系统需求基础之上。在系统分析过程中，我们全方面考虑在业务逻辑上和具体实现上所可能碰到问题，着力于建立良好代码框架，和初步提出一些特殊问题处理方案。系统分析包含了需求分析、步骤分析等。3.1需求分析在对系统需求充足调研后，整理出以下需求文档。经过具体阅读系统需求和结合自己对需求想法和实际考虑，我将自己所做模块需求总结以下。3.1.1账务上传功效需求深圳电信用户群体大致能够分为托收用户和非托收用户。非托收用户关键针正确是通常注册用户。而托收用户针正确是电信职员。其本质区分就是托收用户能够延期付款和分期付款，且用户账号信息在电信账务系统中有数据统计。正因为如此，该需求仅仅针对仅针对非实时托收付费类型。对业务开通功效域中确立订购/使用关系，每当发生使用行为，计费功效域依据产品管理域所定义资费规则，实施对应计价处理。依据订购时所确立SLA及相关约定，可能需要产生对应帐单，交由统一支付平台，以网银、V卡等方法支持。对于不需要实时付费托收账户，在结算期产生总帐单，交由帐务系统处理。账务上传采取定时上传至指定FTP站点方法。通常为天天上传一次，而账务每十天进行一次统一划账扣款。这些时间上区分在系统设计时需要着重考虑。3.1.2投诉管理功效需求投诉管理模块是一个用户反馈产品使用信息平台。也是系统管理人员，电信施工人员处理和处理用户问题渠道和平台。关键需求包含以下多个方面。投诉信息查询。提供给用户查看投诉信息页面。用户可查看到自己所产生全部投诉。同时能够查看到该投诉工单处理情况。用户发出投诉在失效之前不能撤销和删除。用户投诉信息录入。提供一个统一页面供用户填写投诉单。投诉类别是限制。系统将依据类别将投诉投递到对应部门。投诉信息处理。提供页面供系统管理人员操作。管理人员可查看全部用户投诉。可对投诉进行回复和转交和处理等操作。能够追踪投诉工单实施情况。投诉信息投递。投递功效包含了由用户投递到系统。用统一平台投递到相关系统。投递过程应该是可配置。能够自动投递也可手动投递。3.1.3停机/复机功效需求停机/复机关键针正确是各合作伙伴所提供给用户使用各项产品和服务。停机分为两方面情况。一是用户在欠费情况下将被迫停机。二是用户主动发出停机请求。复机则由用户主动触发，假如复机条件满足，再进行复机操作。停机和复机针对不一样用户群体采取策略和步骤不一样。对于托收用户是采取分期付款方法，那么在停机时将考虑费用免去。而复机时又要恢复收费。非托收用户费用只能是一次性付清情况，停复机将不受其它原因牵连。3.2步骤分析这里步骤描述是系统用例和大致过程。它反应了系统在运作时所经历部分步骤和它运作时同包含外系统相互关系。3.2.1账务上传步骤分析账务上传步骤大致图3-1所表示。各个步骤具体过程叙述以下。提取数据：从帐单库中将需要生成总帐单费用数据提取出来；生成总帐单：将取到费用数据自动组成总帐单；批量上传：将生成好总帐单批量上传至营销帐务库；数据归档：将步骤相关数据和上传是否成功等信息归档，备份到帐单库中保留，如上传不成功，将在下次结算周期时再次重新处理帐单库：互联网平台集中保留帐单、支付等相关数据。图中所表示账单库是互联网信息平台内部数据库。而营销账务系统是互联网信息平台外部系统，即电信账务系统。故而需要采取FTP上传方法传输信息。数据归档则是指互联网信息平台数据统计和修改等操作。图3-1账务上传步骤图3.2.2投诉管理步骤分析投诉管理步骤图3-2所表示。关键步骤分为两条线。第一条线，管理员经过系统对投诉进行查询和处理；第二条线，产品用户进行投诉提交和投诉查询操作。查询为共有功效项。查询时，用户首先在查询页面输入查询关键字，然后点击查询按钮，页面将跳转到结果页面并将符合条件信息显示在此结果页面上。提交投诉是用户特有。用户在投诉页面填写投诉相关信息，点击按钮提交后，系统跳转到结果提醒页面。处理投诉页面建立在投诉查询结果页面基础之上。在查询结果页面上，提供了丰富功效按钮方便实现对投诉多种处理。图3-2投诉管理步骤图下面，我结合了用例图对提交投诉，查询投诉和处理投诉这三个用例进行了一个概括描述。提交投诉。图3-3，互联网信息服务平台产品用户，提交投诉信息。平台用户包含个人注册用户、企业管理员、企业职员三类。她们投诉信息将统计到互联网信息平台数据库。图3-3提交投诉步骤图处理投诉：图3-4，管理员对用户投诉进行处理。操作是经过页面功效按钮来完成。修改数据任然是互联网信息平台当地数据。图3-4处理投诉步骤图投诉查询：图3-5，管理员查询系统投诉，产品用户查询本身投诉处理状态。管理员指是企业管理员。用户包含企业职员和注册用户两类。她们查询信息范围将有所区分。图3-5查询投诉步骤图3.2.3停机/复机步骤分析停机/复机步骤图3-6所表示。结合该图，我将从IB提议、平台施工、AP施工三个阶段来描述。其中IB是广州电信IBSS系统简称，该系统负责电话、宽带等电信业务实际停复操作和费用结算。平台施工指是本系统所实施操作。AP是指在本系统平台上提供服务供给商。图3-6停机/复机步骤图IB提议：IB提议停机/复机指令。实际操作为IB系统调用本系统接口。平台施工：互联网信息服务平台实施操作，并向牵涉AP发出对应指令。实际操作为平台调用服务供给商接口。AP施工：AP完成停复机具体操作。具体操作为服务供给商内部操作，本系统并不关心。3.3本章小结第三章关键对本系统模块进行了全方面分析。首先简单叙述了模块需求，然后分析了个模块步骤。经过二者反应了系统具体要求和具体情况，为后文叙述打下基础。4具体设计具体设计建立在对需求充足考虑、充足了解基础上。经过具体设计，我将所需实现功效转变为了具体可参考实施方案。4.1数据库具体设计互联网信息服务平台全部信息全部存放在关系型数据库中。关系数据库含有数据结构化、最低冗余度、较高程序和数据独立性、易于扩充和编制应用程序等优点，尤其在分析方面含有优势。互联网信息服务平台使用关系型数据库来进行数据存放，在进行了需求调研和功效分析后，进行了数据库设计，整个系统包含数据库表张有二十八张，关系映射三十个。其概念模型图4-1所表示。图4-1数据库具体设计图4.2投诉管理模块投诉管理模块是个相对简单模块。在设计上，经过借用Struts框架和Hibernate框架帮助，能够实现页面功效关键部分。整体设计图4-2。图4-2投诉模块设计图首先设计是用户端投诉信息查询和展示页面。当用户进入投诉管理模块时，她（她）首先应该看到是一个整体概况。在页面中她能够看到自己已经投递了哪些投诉。投诉处理情况怎样。而且用户能够经过方便连接进入和查阅相关单项投诉愈加详尽信息。这么设计是普遍使用方法。譬如通常使用邮箱，譬如论坛全部是采取这么布局。管理员端处理投诉页面能够和该页面类似。但必需考虑到管理员在处理投诉时，她所面正确可能是成千上万投诉信息，而用户所产生应该只有少数几条。故而在管理员投诉查询和展示页面是必需配置查询功效。这里考虑查询方法关键包含了投诉标题或内容模糊查询，按日期范围查询，按投诉类别查询，按投诉人ID查询等。这么设计基础涵盖了全部比较合理查询条件。同时管理员还拥有特权。因为管理员能够批量或独个去处理投诉信息。处理关键包含直接处理和回复和派发。设计时我将管理员特权表现在所能操作按钮上。用户端页面和管理端页面做成不一样页面。它们可能拥有类似内容和布局。但它们所展现功效按钮将是不一样。然后设计是一个投诉信息录入页面。在这里安放了投诉各项信息简单输入框。同时还有多个特殊字段。首先用户ID是不能随便输入，因为用户是必需能够实时联络到。在系统登录时，用户信息会保留在系统Session中。故而这里考虑将用户信息从Session中取出。然后设置为只读形式。投诉类别是不能够随意指定。这里经过查询字典表（KIND=COMP_TYPE）获取。最终设计是一个投诉具体信息查看页面。这里单独展示单条投诉信息内容，而且包对该条投诉信息进行处理相关功效按钮。依据需求投诉信息必需在无效状态下才能够删除。在查阅界面可能有投诉时能够删除而则不能。这里采取设计方案是依据投诉信息状态自动控制删除按钮显示和隐藏。这么无疑降低了冗余页面开发。带来缺点是不利于新功效添入。针对目前需求却是能够。4.3账务上传模块针对账务上传功效需求，在代码实现上采取多步骤设计。经过步骤来控制整个步骤。能够将该部分分成以下多个步骤。账单信息提取。这是账单信息获取步骤。账单信息是经过查询用户订购产品表和产品关联各项服务计价规则表计算得出。设计时多建立了一张表。它和订单表相关联，以方便查询订单信息。同时它留有字段保留价格信息。在订购和修改产品时将价格信息录入此表。以后在账单信息提取步骤以此表为依据生成数据。当地保留将提取后账单信息从内存写入当地硬盘。FTP上传将当地保留账单信息上传账务FTP系统。之所以采取先当地保留后FTP上传设计是出于可靠性、稳定性、事务可回滚来考虑。因为直接从内存写入异地磁盘，其中存在可变原因是很多。因为网络有可能是不稳定。一旦在从内存上传异地FTP过程中出了差错，事务回滚含有相当大难度。故而采取先写到当地，再网络传输方法来保障系统稳定可靠，同时也方便事务控制。文件上传所需考虑网络安全和网络异常问题，我从文件[12]中取得很多有益提议。数据回填对已处理数据作对应标识，以避免二次操作。4.4停机复机模块在需求描述中，停机步骤和复机步骤是有区分。但功效实现方案是大同小异。停机模块采取了节点和判别器组成类似于步骤控制软件一个比很好整体设计。节点负责是功效实施，而判别器负责是对步骤走向控制。采取这么设计好处是将各模块独立出来，便于扩展。同时能直接反应出系统业务步骤。再者因为依据业务需要，即使节点仍然是那么多个，但不一样业务走不一样步骤线路。 复机模块设计方案类似于停机模块设计方案。4.5关键步骤设计此步骤讨论是在处理部分关键性问题上所采取特殊设计策略。这些包含了在动态网站开发过程中所常见问题处理方案，也有部分独特创新见解。4.5.1怎样提供Web服务和调用Web服务这本身不是一个复杂问题，做一个WebService和调用一个WebService并不是一件困难事情。Web服务，它是一类能够从Internet上获取服务总称，它使用标准XML消息接发系统，而且不受任何操作系统和编程语言约束。在过去三年中，出现了三种作为全球标准关键技术：SOAP[13]，WSDL和UDDI。它们组成了今天Web服务技术关键。然而全部Web服务协议和新技术全部是以XML作为其数据表示层，XML消除了协议特有网络，操作系统和平台绑定限制，所以XML是全部Web服务基础[14]。不过需要考虑是在互联网信息平台接入企业将越来越多。每个企业提供不一样接口，也会需要不一样接口。A企业可能是用C做接口，B企业可能是用JAVA做接口。A企业可能需要是平台Web服务1，Web服务2，Web服务3集合，B企业可能仅仅需要Web服务1。这么平台兼容性受到很大考验。假如因为一个新接入了一个企业而又重新开发专门针对于该企业已经有服务，或又要重新封装服务，不言而喻，二者全部是无法想象。所以在设计上，系统设计提出了企业服务总线概念。本系统和全部外系统提供接口全部统一放在企业总线上。图4-3所表示。图4-3企业总线图这么，系统把全部接口全部经过标准化封装后放到企业总线上。企业需要哪个全部能够从出队列去取。4.5.2脏数据问题处理当多个事务同时对数据库表中同一条数据操作时，假如没有加锁机制话，就会产生脏数据（dutydata）。即当事务读取还未被提交数据时，就会发生这种事件。举例来说：Transaction1修改了一行数据，然后Transaction2在Transaction1还未提交修改操作之前读取了被修改行。假如Transaction1回滚了修改操作，那么Transaction2读取数据就能够看作是从未存在过。为了处理这一问题，具体实现时我们引入了乐观锁机制。经过使用Hibernate乐观锁[15]自动检测多个事务对同一条数据进行操作，并依据先胜标准，提交第一个事务，其它事务提交时则抛出org.hibernate.StaleObjectStateException异常。 其实现原理是比较简单。首先每个实体全部有一个版本信息version.她在每次修改后全部将进行自加操作。以下面伪代码(图4-4所表示)为例。图4-4账务上传伪代码示例图在事务2提交时，因为它提交数据比事务1提交后数据旧，在乐观锁机制中将不许可该操作变更数据。怎么知道事务2提交数据比事务1提交后数据旧呢？因为MyEntity有个version版本控制字段。回头看看上面源代码中：MyEntityet1=session1.load(MyEntity.class,id);MyEntityet2=session2.load(MyEntity.class,id);这里，et1.version==et2.version，比如此时version=1，当事务1提交后，该数据版本控制字段version=version+1=2，而事务2提交时version=1<2所以Hibernate认为事务2提交数据为过时数据。4.5.3事务回滚采取方法在系统整体设计上采取了Hibernate框架。故而事务回滚关键是借助框架来完成。Hibernate是对JDBC轻量级对象封装，Hibernate本身是不含有Transaction处理功效，HibernateTransaction实际上是底层JDBCTransaction封装，或是JTATransaction封装.Hibernate能够配置为JDBCTransaction或是JTATransaction，Hibernate事务回滚其实就取决于它在实施增、删、改时不会进行真正提交。数据库本身有回滚机制。假如没有提交，全部对数据库操作全部不会生效。也就是说屏蔽了底层自动提交默认实现功效而改成由程序来控制。它在每个会话Session打开时候自动实施conn.setAutoCommit(false)，并不是像通常JDBC一样将默认AutoCommit属性设置为真。真正意义上回滚是并不足以经过这种简单方法来实现。为了应对多种多样业务逻辑，单纯事务显得不够灵活[16]。事实上，在这个问题上，我认为是不会有“以不变应万变方法”。在系统设计时，我考虑了采取以下方法：包含事务处理时，我一直尽可能在数据库中用专门表，或经过数据库表专门字段来统计事务实施情况。对可能发生异常，需要回滚情形做预先准备。将回滚所需要各项数据做预先保留。图4-5所表示，我以账务上传事务回滚为例说明了以上两点是怎样具体应用。图4-5账务上传模块回滚示例图当系统在步骤1抛出异常，则步骤2实施前发觉数据库标志是默认0而不是1。从而采取对应回滚。这里因为还未包含数据库操作，无需做什么事情。假如步骤2抛出异常，那么当地保留文件是有问题。这时候我们在步骤3实施前因为判定到数据库标志非2，所以去去校验文件，依据校验文件统计文件名将当地文件删除。再重新操作。步骤3抛出异常时，依据校验文件统计文件名将远程FTP文件删除，再从当地重新上传。最终数据回填后，甄别FTP目录文件名统计和校验文件，二者统计文件名列表一致，且数据库操作无异常抛出则顺利结束。假如数据库操作失败，数据库事务回滚。然后重新回填数据一次。4.5.4字典表设计 这是一个不起眼问题，以前历来没有引发过我注意。但就是这么一个简单设计技巧在代码后续维护中起到了至关关键作用[17]。字典表关键是存放部分固定名词和变量。譬如电信业务支撑系统IBSS业务编码，譬如订单状态（待AP施工状态、AP施工状态、待IB施工状态、IB施工状态、停机状态、正常状态）。 字典表设计时有多个字段基础是固定。它们是词条ID、名称和类别（名称是随意定义）。词条ID是绝正确固定字段，在系统编码中使用，且不应该变更。任何包含字典表数据库表应该引入字典信息全部应该是词条ID，不应该出现名称。名称是词条含有实际意义描述。类别是对词条所属类别描述以使字典表中繁多词条分门别类。它也会在代码中出现，应是固定不变。在通常使用中，用户需要看到是词条含有实际意义名称。用户需要变动较大也是这个名称。而在代码开发中，程序员应该使用则必需是词条ID和类别字段。名称能够经过对词条ID和类别限定进行查找。下面举例说明以上问题。比如在系统登录时用户类别有电信管理员、企业管理员、施工员、一般用户等几类供选择。这是在页面显示情况。在后台数据库中则有图所表示统计。图4-6字典表数据统计图在编码时登录类别获取将经过查询字典表获取。譬如一个编写一个形式以下函数：ListqueryUserTypeList(Stringtype)这么好处是在以后添加或删减了用户类别时，我们不再需要去变更代码，只需更改数据库中统计便能够做到。4.6本章小结本章对系统设计进行具体叙述。首先具体叙述了系统数据库设计，然后叙述了系统各模块具体实现细节设计，最终对设计上牵涉到关键技术做出着重分析和叙述。5系统实现和展示系统实现理应遵照具体设计。可是，在实际开发过程中，却常常碰到很多细枝末节，甚至在具体设计中也未能考虑到问题。另外，设计方案在具体实现过程中也有很多实现路径。在这个章节叙述了我是怎样实现这个模块。5.1投诉管理模块实现页面上使用了少许AJAX技术，用于在用户字数超出数据库字段长度时给提醒信息。经过这么达成很好效果。相关AJAX技术均参考于参考文件[18][19]所述著作。在此不赘述。实现完全根据设计实现，并无太多细节。实现页面如附录B所表示。5.2账务上传模块实现根据设计中所提及五个步骤，在实现时，针对各个步骤所面临问题作了细致考虑。具体以下。账单信息提取。如设计中所述，账单信息是经过查询用户订购产品表和产品关联各项服务计价规则表计算得出。计价并不是一件轻松事情。在计价步骤关联表有十来张之巨。包含了订单表、产品表、产品实例表、产品关联表、服务表、服务实例表、计价规则表等。这么计算一次价格所开销系统成本是很大。而账单信息提取，每次处理订单数目可能有数万之巨，故而除了在订购产品和修改产品属性情况下是不提议进行计价操作。另外产品订购或修改后，价格信息是相对平稳，不会再有太大变动。针对以上分析，设计时多建立了一张表。它和订单表相关联，以方便查询订单信息。同时它留有字段保留价格信息。在订购和修改产品时将价格信息录入此表。以后在账单信息提取步骤以此表为依据生成数据。当地保留将提取后账单信息从内存写入当地硬盘。FTP上传因为是批量处理，针对成千上万数据统计，不可能通通保留在一个文件中，不然“一荣俱荣，一损俱损”了。经过和账务系统协商。这里将采取文件分割设计方案。所谓文件分割是指能够依据配置文件对上传账务系统单个文件统计数加以限制。这么账单信息将散列在多个文件中。当信息分散了，怎样确定数据完整性能。很简单设计是添加一个校验文件。文件将列举一个文件名集合，并和所包含文件一齐上传。图5-1校验文件示例图数据回填对已处理数据作对应标识，以避免二次操作。 步骤设计好了。各个步骤全部独立成节。这么单个步骤犯错则对单个步骤进行恢复，不影响其它步骤实施。各个步骤实施全部有一定判定条件以得悉步骤是否应该实施。这么整个步骤就能够得到很好控制。这借鉴了现在企业广泛使用步骤管理思绪。以规范化结构端到端卓越业务步骤为中心，以连续提升组织业务绩效为目标操作性定位描述，因为步骤管理是为了用户需求而设计，所以这种步骤会伴随内外环境改变而需要被优化。 同时账务上传是一个时间调度任务。它将在天天实施一次。在设计时开始考虑是采取类库Timer实现，最终使用是quartz框架作为实现方案。采取该框架最直接原因是它采取成熟框架将避免自己在编写任务调度时出现问题。另外，Quartz是一个完全由java编写开源作业调度框架。它易用得简直让人受不了！简单地创建一个实现org.quartz.Job接口java类。Job接口包含唯一方法：publicvoidexecute(JobExecutionContextcontext)throwsJobExecutionException;在你Job接口实现类里面，添加部分逻辑到execute()方法。一旦你配置好Job实现类并设定好调度时间表，Quartz将亲密注意剩下时间。当调度程序确定该是通知你作业时候，Quartz框架将调用你Job实现类（作业类）上execute()方法并许可做它该做事情。无需汇报任何东西给调度器或调用任何特定东西。仅仅实施任务和结束任务即可。假如配置你作业在随即再次被调用，Quartz框架将在合适时间再次调用它。再者，该框架实现调度方法多个多样，很灵活。而且可配置。5.3停机模块实现依据设计，在实现时，我将停机模块划分成多个节点。NA节点是起始节点，它指示用户开始了停机操作。这时在施工表中生成停机工单。这是后续步骤关键判定原因。以后判定和节点实施全部将根据施工单信息来。然后需要判定器JA判定用户类型。假如是电信职员实施节点NB，假如是一般用户实施节点NC。节点NB通告电信业务支撑系统(简称IBSS)。电信用户停机需要通知IBSS，以停止收费。通知后IBSS在处理时将再度通知我们系统。而我们在此段算是结束步骤。节点NC则开始通知AP进行施工。AP可能有多个，AP接口调用可能是立即也可能是非立即。假如施工完成将在施工单信息中有统计。这是由判定器JB做判定。假如全部AP施工完成则进入节点ND，假如施工未完成则进入终止状态等AP施工完成后再进入JB判定步骤。 在类设计上节点类均实现统一接口，调用统一execute(WorkFormworkform)方法实现功效。而接收参数将是施工单类。施工单类是父类，停机施工单，复机施工单全部继承该父类。从而实现可扩展性。判定器类也将实现统一接口，调用统一validate()方法和jumpTo()方法。判定器实际上也起到了导航器作用。它控制了步骤走向。最终节点类和判定器类均继承于Cell类。整个步骤是一个List<Cell>为主体工作流。它有两个特殊子类：BeginCell和EndCell.顾名思义，工作流由BeginCell开始实施，在EndCell处结束运行。在其实施过程中默认将根据LIST前后次序实施，而经过判定器类能够进行跳转，从而