|
王迪明 朱晓民 廖建新
（1．北京邮电大学网络与交换技术国家重点实验室 北京 100876，2．东信北邮信息技术有限公司 北京 100083）
摘要：WWW（World Wide Web）接入方式是目前彩铃业务最主要的接入方式之一。本文针对原有彩铃业务WWW接入系统中的不足，采用Struts2 MVC(Model-View-Controller)框架，使用Spring容器作为系统的IoC(Inversion of Control)容器，并结合现有的web新技术，重新设计和实现了彩铃业务WWW接入系统，提高了该系统的灵活性、可扩展性、可维护性、安全性等。最后采用测试工具对原有系统和改进后的系统进行了性能比较，并对本文提出的改进方案进行了讨论。
关键字：彩铃业务，WWW接入，Struts2，Spring IoC
Improvement of WWW Access System for CRBT Service
Wang Diming1,2 Zhu Xiaomin1,2 Liao Jianxin1,2
(1. State Key Laboratory of Networking and Switching Technology, Beijing University of Posts and Telecommunications, Beijing, 100876; 2. EB Information Technology Co. Ltd., Beijing, 100083)
Abstract: WWW-based access way is one of the main access way for CRBT service. In this paper, the access system based on WWW of CRBT service is resigned and realized, aimed at overcoming the existing system’s shortcomings. In order to improve the flexibility, scalability, maintainability, security, the new access system will use the latest technology of web layer, with the adoption of the Struts2 MVC framework and the Spring container as the IoC container. Finally, the paper will compare the performance of the original system and the new one by testing tools, and discuss the improved plan.
Key words: CRBT service, WWW access, Struts2, Spring IoC
1 引言
彩铃业务是一种当主叫用户发起呼叫并等待被叫应答时，以个性化、差异化的音乐替代传统的、由被叫端局提供的、单调的回铃音为目的的业务，是一种根据客户的价值取向和消费心理而提出的增值业务[1]。该业务是通过在原有的通信网上叠加智能网，通过智能网中的独立智能外设（本文称为彩铃平台）来实现。
随着彩铃业务的逐渐发展，彩铃业务的接入方式也从单一的IVR （Interactive Voice Response）接入发展到IVR、web、WAP（Wireless Application Protocol）、SMS（Short Message Service）等多种接入方式，并提供第三方的SOAP（Simple Object Access Protocol）接入方式[2]。
彩铃业务WWW接入系统是一种基于WWW的分布式计算企业应用模式[3]，给彩铃用户和管理者提供通过Internet访问彩铃网站的服务。由于WWW接入系统具有操作方便简单、能够减轻营业厅的工作量、易于推广新业务、易于维护、提高接入能力和贴近用户等优点，从而成为目前电信业务中最主要的接入方式之一。
彩铃业务WWW接入系统主要为以下三类客户提供铃音管理服务[4]：
1. 普通用户：该类铃音管理服务面向大众用户，提供如彩铃开销户、铃音试听、定制、个人铃音库管理、主叫分组管理等多种多样的彩铃管理功能。
2. 铃音提供商：该类铃音管理服务面向如新浪、龙腾阳光等SP（Service Provider），WWW接入系统为获得权限的SP提供相应的登陆帐号，以便它们方便地上传铃音供普通用户下载。
3. 网络运营商：该类铃音管理服务面向运营商，彩铃业务相关负责人员可以方便地登陆操作员网站，对彩铃业务的各种业务属性进行管理，如铃音审核、设定权限、费率修改等操作。
本文针对原有彩铃业务WWW接入系统的不足，采用清晰的分层架构对系统进行重构，提出了具体的改进方案，并对原有彩铃业务WWW接入系统和改进后的彩铃业务WWW接入系统进行性能上的比较，最后对改进方案进行了讨论。
2 彩铃业务WWW接入系统的现状
2.1 原有的彩铃业务WWW接入系统
彩铃平台的内部模块及相关外部实体的组织结构如图1所示。其中彩铃管理平台框中的web&WAP框内的部分就是本文所描述的原有彩铃业务WWW接入系统。图1清晰地描述了原有的彩铃业务WWW接入系统在彩铃平台中的位置。
图1 彩铃平台的内部模块及相关外部实体的组织图
图1所示的彩铃业务WWW接入系统包含客户终端管理模块、Java Bean模块和前置进程。客户终端管理通过网站的形式给用户提供最直观的感受，Java Bean主要处理业务逻辑和数据操作，WWW接入系统通过前置进程与彩铃平台中的CN（Control Node）进行交互。
目前彩铃业务WWW接入系统采用的是简易的MVC架构，业务逻辑和数据访问集中在Action类中实现，而Action类由Controller调用。这种架构简化了业务逻辑层和数据访问层的设计，将业务逻辑层和数据访问层融合在一起，同时这两层又与Web表现层紧密耦合。彩铃业务WWW接入系统的模块关系如图2所示。
图2 彩铃业务WWW接入系统的模块关系图
从图2可以分析出原有彩铃业务WWW接入系统的MVC架构：
Model：即图2所示的Module。用于保存Action处理的结果（主要是查询结果），以及在一次登录过程中需要保存的其他用户信息，通过JSP(Java Server Page)页面显示给用户。
View：即图2所示的JSP页面部分。呈现给用户的JSP页面是从HttpSession中提取Model，将用户上一操作的操作结果显示给用户，并提供可以执行的其他操作。
Controller：即图2所示的ControlerServlet部分。该部分接受请求并处理请求。ControlerServlet处理请求时获得HttpSession的引用，获得Model的引用，实例化处理请求的Action类，并将数据库连接池、SOCKET连接池和Model的引用交给Action，同时将Action保存在HttpSession的ActionMap中。
图2的Action是整个系统中实现具体业务逻辑的主要部分之一，也可以称为业务控制器。通过引用保存在ControlerServlet中的SOCKET连接池和数据库连接池获得与前置机和数据库的连接，实现事务处理的操作；处理完成后，将请求前转到相应的显示页面。
实际上，原有系统中的Module部分并不进行数据访问，只是保存数据访问的结果，真正的数据访问是在Action部分中实现的。这样的设计容易理解，简单易学，但是也存在很多问题，将在2.2节中对其进行分析。
2.2 存在的问题
在2.1中所述的这种模式将业务逻辑层和数据访问层集中在Action中实现，虽然结构简单、易学、上手容易，但是还是存在以下不足：
1、耦合度高。
Action类与web表现层耦合很紧密，存在着逆向调用关系，体现在：Action类保存对Session的引用（引用Session中的Model），而Session是web层的概念；Action类处理完业务逻辑后要将请求前转到相应的JSP页面。这种逆向调用使得业务逻辑层和数据持久层与web表现层紧密耦合，不够独立，也违反了三层结构的设计原则。
2、可维护性和可扩展性差。
Action类中的业务逻辑处理和数据访问掺杂在一起，业务逻辑代码中混杂着SQL语句，两者之间的界限很不清晰。基于这种模式开发系统的优点在于开发的迅速便捷，这对于小型应用而言别具意义，但其维护性和扩展性较差，对象属性、数据库结构的变动都将直接导致业务逻辑代码的修改。例如，当数据库表某个字段的名称改变，进行数据访问的SQL语句要重写，从而导致整个Action重新编译。而且视图部分的JSP页面多采用java script进行编程，也给维护带来了很大困难。
3、 配置性和灵活性差。
页面之间的跳转需要在Action里硬编码，不能通过配置实现，灵活性差。
可以看出，现有的彩铃业务WWW接入系统采用的架构不是一种清晰的分层结构，给代码复用、开发效率以及代码维护等方面带来不良影响。
另外，从原有的系统描述中可以看出原有系统除了进行WWW接入管理，还对彩铃业务进行逻辑处理。这个系统是一个相对独立的系统，可以直接对通过WWW接入发起的彩铃业务请求进行处理，可以直接和彩铃平台的CN进行交互。目前在彩铃平台上不同的接入方式都有自己的业务逻辑处理模块，这些接入方式仅基于数据库共享[5]。但是事实上这些业务的功能都是一致的，因此造成了业务开发维护人员为相同的业务功能开发、维护多份代码的情况，严重制约了新业务的开发进度，加大了业务维护的成本。随着彩铃业务的发展、表现层的多样化、业务逻辑的多样化，原有系统在代码复用、提高开发效率和维护等方面显得力不从心，因此对它进行改进是必须的。
3 改进方案
3.1 设计原则
针对以上的问题，提出以下五个设计原则：
1. 明确WWW接入系统的职能，力求简单化，减少重复工作。
2. 采用清晰的分层结构对彩铃业务WWW接入系统的架构进行重新设计，以提高代码的复用性和灵活性，提高业务逻辑的结构性。
3. 采用web层的安全性技术，以提高彩铃业务WWW接入系统的安全性。
4. 采用定时生成静态内容页面的技术，减少对数据库的访问次数，以此提高系统的性能。
5. 由于彩铃铃音的信息繁多，需要采用一定的搜索策略，提高效率。
3.2 具体实现
为了提高彩铃业务的统一性，将彩铃平台的各个模块的业务逻辑和业务流程统一起来，形成一个统一的业务逻辑处理模块。因此可以将彩铃平台清晰地分为三层结构：接入层、业务层和数据持久层。WWW接入系统属于彩铃平台的接入层，其主要功能是负责处理HTTP协议和用户交互界面的设计。
在彩铃业务WWW接入系统中采用目前流行的中间层设计，使用成熟的Struts2 MVC框架结构，与Spring容器相结合，融合Acegi安全认证框架，OS Cache缓存模块和Compass智能搜索模块等。
Struts2的处理流程采用传统的请求——响应模型，用户通过“提交”按钮来提交请求，请求被系统的控制器处理。Struts2使用拦截器作为处理（Advice），以用户的业务逻辑控制器为目标，创建一个控制器代理[6]。控制器代理负责处理用户请求并处理用户请求时回调业务控制器的execute方法，该方法的返回值决定了Struts2将怎样的视图资源呈现给用户。
采用Struts2架构web应用，需要用户自己开发的是Action模块和一些辅助的模块，以及一些其它Web应用常用的Servlet、Filter等等。
改进后的彩铃业务WWW接入系统的模块结构如图3所示。
图3 彩铃业务WWW接入系统的模块结构图
图3清楚表示了改进后WWW接入系统的处理流程，具体如下：
用户的请求发送至服务器会首先经过Acegi安全认证框架的过滤，认证鉴权用户的身份。然后将请求传递Struts2框架进行处理，Struts2框架的业务核心就是Actions中的业务逻辑处理部分，该部分会对用户的请求做处理，如开户、下载铃音等。然后Struts2将请求递交给其它Filter，其它Filter处理完毕之后返回给客户端。在改进后的WWW接入系统中还使用了CacheFilter针对部分页面进行缓存。对于铃音的搜索则采用了Compass开源软件进行开发，主要是开发搜索模型（对象），搜索方法以及对Compass的配置。
在改进后的系统中，使用Spring容器作为系统的IoC容器，将系统中所有组件都放在Spring容器中进行管理，并且充分利用Spring IoC容器的功能，采用依赖注入来管理系统中个组件的依赖关系，避免了各组件之间的硬编码耦合，提高了系统的可扩展性。
4 性能比较
为了提高复用性，可维护性和灵活性，改进后的彩铃业务WWW接入系统采用了成熟的轻量级Web框架——Struts2，并且利用了Spring容器中的IoC思想，对彩铃业务WWW接入系统进行了架构上的调整。Struts2框架提供了很多拦截器机制，使得诸如日志记录、性能监控、参数验证等模块可以与Action解藕，作为单独的模块提供。这给代码的复用和灵活性带来了极大的便利。当然在获得高复用性、可维护性和灵活性的同时，不可避免的会增加web服务器和整个彩铃平台的内存与CPU资源的占用。正因为考虑到这些因素，所以在改进的WWW接入系统中采用了很多提高性能的页面技术，比如页面缓存技术、定时生成静态页面技术等。总的来说，改进的WWW接入系统除了以实现所有功能为目标以外，还以提升性能为目标，以提高复用性、可维护性、灵活性和高性能为目标。
本文在实验室环境下，使用微软的WAS（Web Application Stress）工具，分别对改进前和改进后的彩铃业务WWW接入系统的首页、搜索和显示铃音信息等web页面进行性能比较。
网站首页：
改进前的彩铃业务WWW接入系统 改进后的彩铃业务WWW接入系统
Number of Users 30 30
Requests per second 15.06 22.84
TTFB(Time To First Byte）Avg 798.03 348.24
TTLB(Time To Last Byte)Avg 1988.52 1309.34
表1首页性能比较
从表1看出，在用户数都为30的时候，改进后的系统每秒的请求数比改进前的系统多（22.84-15.06）/22.84=34%左右，但是TTFB（第一个请求发出到收到服务器应答的第一个字节的平均时间）改进后的系统比改进前的系统快了449.79s，提高了56%左右。同理，TTLB（第一个请求发出到受到服务器应答的最后一个字节的平均时间）改进后的系统比改进前的系统快了679.18，提高了34%左右。
搜索页面：
改进前的彩铃业务WWW接入系统 改进后的彩铃业务WWW接入系统
Number of Users 30 30
Request per second 49.35 96.38
TTFB(Time To First Byte）Avg 53.43 114.98
TTLB(Time To Last Byte)Avg 117.67 307.83
表2搜索性能比较
表2显示的是网站搜索功能的性能比较。改进后的系统中搜索采用了Compass框架，该框架是通过拦截器的方式和Struts2结合，拦截器带来了可配置灵活性的好处，但是不可避免的牺牲了处理时间。由表2可见，改进后的系统的TTFB比改进前的系统慢61.55s，慢了53.5%左右，同理，改进后系统的TTLB比改进前的系统慢190.16s。
铃音信息页面：
改进前的彩铃业务WWW接入系统 改进后的彩铃业务WWW接入系统
Number of Users 30 30
Request per second 87.80 134.87
TTFB(Time To First Byte）Avg 27.93 19.60
TTLB(Time To Last Byte)Avg 64.59 41.85
表3 铃音信息页面性能比较
表3显示的是网站显示铃音信息页面的性能比较数据。当用户数都为30的时候，改进后的系统的TTFB比改进前的系统快8.33s，快了30%左右，同理，改进后系统的TTLB比改进前的系统慢22.74s。
5 结束语
改进后的系统针对旧系统的问题进行了集中改造，尤其是针对旧系统可维护性、灵活性、可扩展性和安全性等方面问题进行集中改造。改造后的系统经实践验证，上述各方面都比旧系统有了较大的提高。但是，这些方面的提高也会不可避免的带来性能上的一些损失，比如搜索功能返回结果的时间变长等。相对于新系统带来的便利，这些损失是可以接受的。同时，本文的设计方案为单元测试提供了便利（Struts2框架支持单元测试），带来了一定程度上的质量保证。由于使用了优秀的框架，因此可以使开发人员从繁重的代码中脱离出来，极大地提高开发效率。在对其他移动增值业务或者电信业务进行WWW接入系统设计时，可以借鉴本文的改进方案。
参考文献
[1] 中国移动通信集团公司，彩铃业务规范QB-D-003-2006 v_3.0.0，2006年3月
[2] 徐磊，廖建新，王纯，彩铃统一管理业务生成平台的设计与实现，计算机系统应用，2007年第10期，2007年10月，pp2-6
[3] 张雅特，武家春，张铁鹰，廖建新，基于WWW的移动智能网业务管理接入系统的研究与设计，现代电信科技，2005年第02期，2005年2月，pp14-17
[4] 田甜，IIP中基于轻量级J2EE的彩铃业务集成平台的设计与实现，北京邮电大学硕士学位论文，2007年3月，pp7-14
[5] 王娜，王纯，张铁鹰，廖建新，基于Web服务的彩铃业务管理接入系统，计算机工程与应用，2005年41卷23期，pp142-144
[6] 李刚，Struts2权威指南——基于WebWork核心的MVC开发，电子工业出版社，2007年9月
|
搜索
关注微信
