基于JavaEE的IVDR-12580订票平台业务子系统的设计与实现*

陈晓冬，李炜，王晶

（1 北京邮电大学网络与交换技术国家重点实验室，北京 100876；2 东信北邮信息技术有限公司，北京 100191）

1 引言

IVDR（Interactive Voice and Data Response，交互式话音数据应答）面向TD-SCDMA网络，将传统电路域IVR（Interactive Voice Response，交互式话音应答）业务和数据域多媒体融合的一种业务。手机终端使用IVDR客户端软件，可以实现CS（Circuit Switching，电路交换）域与PS（Packet Switching，分组交换）域的并发。这种并发弥补了传统IVR业务[1]或者数据域业务通信方式单一的缺点，提升了客户使用体验与服务质量，降低了企业营运成本。话言和数据的结合也成为了移动增值市场的“亮点”业务[2]。本文提出的IVDR-12580订票系统，基于IVDR平台，与现有12580系统进行融合，针对TD-SCDMA用户提供IVDR形式的电影票预订业务。

JavaEE（Java Platform，Enterprise Edition）作为优秀的多层次分布式企业应用的解决方案，它以组件为基础的设计开发理念能够有效降低开发成本，提高开发速度。SSH（Spring、Struts and Hibernate）框架作为轻量级的JavaEE框架，具有高性能、可维护性以及可重用性的特点[3]。

本论文在提出基于IVDR的12580电影订票平台解决方案的基础上，对业务子系统进行了设计和实现。业务子系统作为一个JavaEE应用发布，基于SSH框架构建，并根据系统需要与外界不同实体的交互对业务逻辑层进行了扩展。最后，以数据推送为核心阐述了IVDR-12580订票业务的关键流程及实现技术。

2 解决方案

2.1 业务特点

12580是中国移动为用户提供的一个综合信息服务平台。12580主要基于话音通话（包括自助IVR语音以及人工语音）为用户服务，同时以短信和彩信服务作为辅助（通常是将用户的查询结果以短信或者彩信方式下发给用户）。

受话音通话的限制，12580业务存在服务流程僵硬、操作单一繁琐以及用户交互单向性等方面的瓶颈。通信媒介的扩充是解决这些瓶颈的思路之一：IVDR将通信媒介由单一的话音扩充到话音和数据并发，很好地解决了这个问题。从表1列出了订电影票业务在使用IVDR前后业务场景的对比。这种采用IVDR方式的12580业务，称为IVDR-12580业务。

2.2 系统结构

图1是IVDR-12580电影订票平台的系统总体结构，其中白色部分为原有功能实体，灰色部分为新增实体。可以看出IVDR-12580能在原有平台上进行较好的扩展而不影响原有的功能。下面简要说明新增实体的功能。

手机客户端软件：包含手机浏览器，可以通过HTTP（HyperText Transfer Protocol）消息进行页面访问；可以调用手机呼叫模块发起12580呼叫；支持TCP（Transmission Control Protocol）消息，建立与业务子系统直接的链接从而接收坐席侧的数据推送。

图1 IVDR-12580整体解决方案

IVDR插件：以插件形式安装在坐席侧浏览器（目前仅支持IE），可以接收12580呼叫插件的呼叫信息，从而建立用户话音和数据的对应；支持TCP消息，可以接受用户侧发起的数据推送。

IVDR-12580业务子系统：作为平台的核心子系统，支持手机侧和座席侧的页面访问；支持与手机侧、座席侧建立TCP数据链接进行数据推送；与12580原有数据服务器如FTP（File Transfer Protocol）服务器、Web服务器等进行数据交互。

表1 传统12580和IVDR-12580的订电影票业务场景比较

3 业务子系统的设计与实现

3.1 接口设计

根据图1的系统总体结构，业务子系统和外界实体主要有6个接口，各接口的数据交互设计如表2所示。

表2 业务子系统接口设计说明表

3.2 主要模块

基于以上数据交互接口，业务子系统应该具有以下主要模块：

Web服务器模块：提供一个Web容器，根据HTTP请求实例化Servlet或者JSP（Java Server Pages）并产生HTTP响应给浏览器。

逻辑处理模块：根据业务流程提供页面跳转的逻辑，调用不同的模块完成相应的功能。

DAO(Data Access Object)模块：封装数据源的访问操作，为逻辑处理模块等其他模块提供数据库访问API。

TCP模块：与手机客户端或者座席浏览器插件建立TCP链接，处理用户的登录、注销以及数据推送请求。

FTP模块：完成FTP客户端功能，可以远程登录FTP进行文件上传下载等操作。

SOAP（Simple Object Access Protocol）模块：完成SOAP客户端功能，根据SOAP协议请求Web服务器的数据。

3.3 基于SSH架构实现业务子系统

3.3.1 业务逻辑层的封装与扩展

如前文所述，业务子系统采用了JavaEE作为技术解决方案。JavaEE应用通常包含4个层次[4]：客户层、Web层、业务层以及EIS（Enterprise Information System，企业信息系统）层。传统的业务层是由EJB（Enterprise Java Bean）作为服务器组件，来实现企业应用的业务逻辑。然而正如Rod Johnson所说，EJB笨重、臃肿而且并不是真正意义上面向对象[5]。SSH框架整合了Spring、Struts以及Hibernate技术，提供了一个轻量级并真正实现了MVC（Modle-View-Controller）设计模式的JavaEE架构。与传统采用SSH框架的JavaEE应用通常只与数据库进行交互不同的是，IVDR-12580业务子系统需要与整个组网环境中的多种设备进行各种方式的消息交互。根据上文提供的解决方案，这些交互主要包括：

（1）通过JDBC对数据库进行访问；

（2）通过TCP协议与手机客户端、座席浏览器插件进行通信；

（3）通过SOAP协议与Web服务器进行通信;

（4）通过FTP协议与FTP服务器上传下载文件。

通过Spring和Hibernate对DAO组件的支持，可以轻易地实现子系统对数据库的逻辑访问，这也是SSH框架的优势功能之一。但是，SSH框架并未对如上所列的其他交互功能提供支持。因此，为实现这些多元化的交互功能，需要对业务逻辑层进行扩展。

图2所示的SSH架构中，对于每一个外界实体，业务逻辑层都提供一个组件进行交互，然后通过封装一个或者几个组件完成一个相对完整的业务逻辑Service；那么我们就可以得到一个功能完备的业务逻辑层。对Web层来说，只需要调用相应的Service方法，而无需担心组网结构和通信协议等细节。

图2 具备扩展业务逻辑层的软件架构

3.3.2 基于依赖注入思想的交互设计

依赖注入是Spring的一个核心思想。依赖注入解除了调用者与被调用者之间的深度耦合。借助依赖注入，Spring容器用来生成和管理对象[6]。对其他对象的依赖，由第三方的Spring容器“注入”；这样，与“面向接口编程”的思想结合，就可以构建一个松耦合、易扩展的多层次软件结构。

从图2可以看出，业务逻辑层与EIS层的交互基于DAO、TCP、FTP以及SOAP 4类组件。每个组件各有一个实现类来实现与外部实体的交互细节。这些实现类通过配置文件交给Spring容器处理。与业务逻辑层的“模型”Service类关联的是这些组件实现类的接口，通过“注入”这些组件实际实现的对象，完成自身的业务逻辑。得益于这种设计，无论组件的具体实现如何变化，只要遵守接口约束的“契约”，业务逻辑层就无需更改：依赖注入实现了调用与被调用之间依赖的倒置[7]。Web层与业务逻辑层的交互遵循同样的道理：Web层关联业务逻辑的Service接口，实现类封装具体实现并交由Spring容器控制。

4 关键技术及业务流程

4.1 用户登录流程

如前文所述，用户接入IVDR-12580业务是通过定制的手机客户端接入。手机客户端开启后，会发送一个登录消息给业务子系统，后者解析这个TCP消息得到用户的手机号、IP（Internet Protocol）、端口、手机操作系统以及手机分辨率等信息，并将这些信息保存在数据库的phoneuserlogin表中。作为登录消息的响应，业务子系统将IVDR-12580业务的首页URL（Uniform Resource Locator）回复给用户。用户通过这个URL并携带手机号发送HTTP访问业务首页，业务子系统根据手机号查询该用户手机系统和屏幕分辨率从而选择合适的首页回复给用户，最终显示在用户的手机客户端。图3表现了用户登录并获得首页的流程。

客服在打开IVDR-12580页面之后，浏览器的IVDR插件也会进行与手机客户端相同的登录模式：通过TCP将客服ID（IDentity）以及IP端口信息发送给业务子系统，后者将信息保存在servuserlogin表中。与手机侧不同的是，业务子系统无需在TCP响应消息中携带首页URL。

图3 用户登录流程（尖括号内标注消息协议和消息主要内容）

4.2 客服接听用户来电

用户在登录手机客户端后，用户可以浏览选择网页提供的影院影片等信息。在每一个页面都有一个“呼叫客服”的按钮。用户可以在浏览任何页面的时候呼叫客服，寻求查询、协助操作等服务。客服在接通用户呼叫之后，在自己的浏览器上可以看到用户呼叫时浏览的页面。这样，用户和客服之间就建立了话音和数据两种沟通媒介，这正是IVDR的业务形态。

图4详细描述了这个流程。可以看出，用户触发“呼叫客服”后，业务子系统通过向手机客服端发送TCP消息告知手机要拨打的电话号码。然后手机客户端直接调用手机的呼叫模块进行呼叫。另外，为了保证客服能得到用户呼叫时浏览的页面，业务子系统实时记录用户的访问记录。这样，客服的浏览器插件在收到呼叫请求后，会将用户手机号码和客服ID以HTTP请求发送给业务子系统。业务子系统一方面记录用户手机号与客服ID的对应关系（方便后续进行数据推送）；另一方面根据用户手机号查到用户当前访问页面，并将页面内容以HTTP响应回复给客服浏览器，保证了客服在接通用户电话的同时能够看到用户当前浏览页面。

图4 客服接通用户来电流程

4.3 数据推送技术

如同对话之于语音媒介，数据推送是用户和客服在数据媒介上的通信手段。用户可以将当前页面推送给客服请求协助处理，客服可以将处理结果页面推送给用户。利用这种方式完成数据域的请求和应答。图5表现了客服推送页面到用户手机客户端的处理流程。

从图5可以看出，完成数据推送主要由两个Action类执行：PushAction类和AcceptAction类。PushAction类是当座席侧客服点击页面上的“推送给用户”按钮触发；首先将客服浏览器的页面数据保存，然后在数据库中查询客服ID对应的用户手机号码，最后调用tcpService的方法发送TCP。tcpService通过用户手机号码可以得到用户手机的IP和端口，然后发送TCP消息。TCP消息的内容是手机客户端将要访问的URL。

无论客服推送何种类型的页面，业务子系统发给手机客户端的URL都是一样的。携带这个URL的HTTP请求（同时携带用户的手机号）都会触发AcceptAction类：根据手机号取出保存的页面数据；分析页面数据中的页面类型决定前转到相应的JSP。JSP根据AcceptAction对象提供的数据形成HTTP响应回复给手机客户端。最终用户在手机客户端上看到客服推送的页面。

4.4 用户订票流程

在手机用户和客服之间建立IVDR通信之后，IVDR-12580订票平台能够为用户提供丰富多样的服务方式。用户的每一步操作都可以由客服协助完成，然后查看操作结果。图6展现了用户请求客服协助完成订单确认的流程。坐席通过与用户的语音沟通以及页面的相互推送确认订单，业务子系统收到请求后触发相应Action，然后调用soapClient组件请求Web服务器处理订单，将处理结果前转到订票结果页面。最后客服将页面推送给用户。用户查看订票结果。

图5 客服向用户进行数据推送流程

5 结束语

IVDR业务相对于传统话音通信融合了话音和数据两种通信媒介，提供了丰富的应用场景。

图6 用户IVDR订票流程

进一步研究可以发现，IVDR业务不仅局限于订票业务，甚至不仅局限于电信运营系统。它可以为任何具有呼叫中心的客户服务系统提供解决方案。

[1] Wang J, Liao J X, Zhu X M, Shen Q W. The development and key technology of mobile intelligent peripheral in China[J]. Chinese Journal of Electronics, 2002,(4):238.

[2] 廖建新. 移动增值业务发展趋势[J]. 电信工程技术与标准化,2004,(05):3-5.

[3] 戚琦，廖建新，王纯. 基于敏捷方法的轻量级J2EE架构的应用[J]. 计算机系统应用，2007,(02):56.

[4] 孙卫琴. Tomcat与Java Web开发技术详解[M]. 北京：电子工业出版社，2009.

[5] Johnson R, hoeller J. Expert One-on-one J2EE Development without EJB[M], Wiley Publishing.Inc, 2004.

[6] Walls C, Breidenbach R著，毕庆红，王军译. Spring in Action(第二版）中文版[M]. 北京：人民邮电出版社，2008.

[7] 彭家恒，廖建新，王纯，阮友森. 基于MVC的WV网关系统的设计与实现[J]. 北京工商大学学报(自然科学版)，2007,(02):38.