融合通信业务门户系统中业务逻辑层的扩展与实现

赵京华，　李　炜

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

融合通信业务(unified communications service,UC service)是以IP通信为基础，提供语音、视频、数据和信息服务的综合业务. 用户可以采用多样化的终端接入到网络享有融合通信的各种服务，以IP为核心的统一控制以及融合的业务平台能够实现各类通信的统一和用户体验的统一[1].

融合通信业务提供门户系统，通过登录业务门户，集团客户管理员和个人用户能够实现对业务的统一管理，因此该门户系统亦称作自助服务门户系统(portal system). 融合通信业务的部分组网结构如图1，自助服务门户系统部署在Web服务器上. 由于研究主要关注的是自助服务门户系统，因此，与Web服务器没有直接连接的组网设备在图1中未详细给出.

融合通信业务自助服务门户系统采用SSH(Spring、Struts和Hibernate)框架搭建系统架构. 基于Struts+Spring+Hibernate的轻量级J2EE架构，在系统运行性能、可扩展性，可维护性等多方面具有优势[2]. 在一般的SSH框架的应用中，业务逻辑层通过对DAO(data access object，数据访问接口)组件进行封装，来对数据库进行操作. 但是，从图1中可以看出，自助服务门户系统与诸多网络设备之间都存在信息的交互，且交互方式不同. 基于这种复杂的组网结构，研究分析本系统对业务逻辑层的特殊需求，并介绍如何通过对业务逻辑层的扩展，来满足本系统的业务需求.

图1　融合通信业务组网结构中的自助服务门户系统Fig.1　Portal system in the network infrastructure of UC service

1　业务组网环境

对于一般的Web应用程序，与之进行信息交互的网络实体包括客户端(浏览器)和数据库等. 而在融合通信业务中，丰富的业务特性和复杂的组网结构，让自助服务门户系统除了具有一般Web应用程序的特点之外，还需要具备与电信运营商核心网、PC桌面程序、移动电话等进行直接或间接信息交互的能力. 下面介绍融合通信业务中与自助服务门户系统建立了直接物理连接的网络实体的功能，同时介绍自助服务门户系统如何通过以下网元，与电信运营商核心网、PC桌面程序、移动电话建立通信.

1.1　数据库

同大多数企业级Web应用程序一样，数据库服务器是自助服务门户系统组网环境的重要组成部分. 数据库中存储着诸如系统参数，用户的个人信息，以及用户的好友、通讯录、群组等大量数据.

自助服务门户系统通过JDBC(java database connectivity，Java数据库连接)对数据库进行访问.

1.2　XDMS

在融合通信业务中，XDMS(XML document management server，XML文档管理服务器)为PC客户端和其它服务器提供好友管理、群组管理、企业通讯录管理等功能. 另一方面，在XDMS上运行的Sync进程可以与电信运营商的SMP(service management point，业务管理点)之间建立通信，通过SMP对SCP(service control point，业务控制点)的管理功能，实现全网SCP的数据同步[3]. 同步的信息包括用户的业务办理状态、用户的停开机状态、用户振铃策略等. XDMS是PC客户端和SMP访问融合通信业务平台的唯一接入点，因此，自助服务门户系统也可以通过XDMS的中转，建立与PC客户端和SMP之间的通信.

自助服务门户系统与XDMS之间通过XCAP(XML configuration access protocol，XML配置访问协议)协议进行通信.

1.3　SM-Proxy

SM-Proxy(short message proxy, 短信代理服务器)是融合通信业务平台与电信运营商短信行业网关之间的唯一接口. 融合通信业务平台的所有用户短信和系统短信都通过SM-Proxy发送给行业网关，并通过电信运营商的网络将短信下发至用户手机.

自助服务门户系统与SM-Proxy之间通过自定义接口的HTTP(hypertext transfer protocol，超文本传输协议)协议进行通信.

1.4　话单接口机

话单接口机主要负责生成融合通信业务产生的计费话单文件，并将其通过FTP协议传送至电信运营商BOSS(business & operation support system，电信业务运营支撑系统). 由于话单接口机建立了一条融合通信业务平台与BOSS之间的FTP通道，因此，自助服务门户系统也借助这条通道与BOSS进行信息的同步，同步的信息包括短信白名单、用户停开机状态等.

2　业务逻辑层的扩展

2.1　SSH框架分层结构

SSH框架具有清晰的层次结构. 根据立场的不同，SSH框架也具有多种分层的方式. 一般来说，一个基于SSH框架的系统可以分为五层：客户层、Web层、业务逻辑层、持久化层和数据库层. 通常，业务逻辑组件会对持久化组件进行封装，那么持久化层就完全被封装在业务逻辑层中，因此可以得到一种SSH框架的四层结构：客户层、Web层、业务逻辑层和数据库层.

2.2　自助服务门户系统对业务逻辑层的需求

自助服务门户系统区别于其它Web应用程序的特点在于，它需要与组网环境中的多种设备进行多种方式的信息交互. 这些交互包括：

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

2) 通过XCAP协议与XDMS进行通信；

3) 通过HTTP协议与SM-Proxy进行通信；

4) 通过FTP协议向BOSS传送信息同步文件.

通过Spring和Hibernate对DAO组件的支持，我们可以轻易地实现数据库访问逻辑[4]，这也是SSH框架最具优势的功能之一. 但是，SSH框架并未对上面所列出的其它几种交互能力提供支持，因此，为实现系统多元化的交互功能，需要对业务逻辑层进行扩展.

2.3　具体扩展方案

业务逻辑层通过DAO组件来实现数据库访问. 我们可以根据这种思路来提出一个业务逻辑层的扩展方案：如果对其它的每一种实体，分别提供一个组件来实现与它的交互，那么就可以得到一个功能完备的业务逻辑层，且对Web层的组件来说，也无需关心组网结构和协议等细节.

扩展后的业务逻辑层如图2. 由于原分层结构中的数据库层中增加了多种网络设备，所以我们将原来的数据库层改称作外部设备层.

图2　扩展的业务逻辑层Fig.2　Extended service logic layer

3　扩展的业务逻辑层的实现

3.1　配置DAO组件

DAO组件用来连接业务逻辑和数据源，实现两者的解耦. 一般来说，应当为每一个持久化类创建一个DAO. DAO模式要求为每个DAO组件编写DAO接口和至少一个实现类. 这种接口和实现分开的做法，可以使业务逻辑组件只与DAO接口耦合，而无需关心DAO的具体实现. 当底层数据库变更或持久化机制变更时，只需修改DAO实现即可.

下面以企业通讯录为例，介绍DAO组件的创建方法. 其它持久化类的DAO的创建方法与此类似，不再列举.

企业通讯录DAO封装了对企业通讯录持久化类的CRUD操作，DAO的实现类继承自Spring对Hibernate的支持类HibernateDaoSupport.

编写完成DAO组件的代码后，需要将DAO组件配置在Spring容器中，由Spring的ApplicationContext负责管理DAO组件的创建. 借助于Spring提供的IoC(inverse of control，控制反转)实现依赖注入，便可以得到DAO实例. 与传统程序设计中创建一个对象的实例的方式不同，IoC的含义是：由Spring容器来创建被调用对象的实例，然后将其注入调用者，因此IoC也称为DI(dependency injection，依赖注入). Spring通过接口松耦合的JavaBean模型提供了基于IoC容器的BeanFactory[5].

在Spring的配置文件applicationContext.xml中添加如下的配置代码，即可完成对企业通讯录DAO组件的配置.

〈bean id=“ComPhonebookDAO”class=“com.bupt.uc.hibernate.dao.ComPhonebookDAOImpl”〉

〈property name=“sessionFactory”ref=“sessionFactory”/〉

〈/bean〉

在上面配置的property子元素里，引用了Hibernate的SessionFactory. 其中，SessionFactory负责产生Hibernate Session. Session接口是Hibernate向应用程序提供的操纵数据库的最主要的接口，它提供了基本的保存、更新、删除和查询方法[6]. ComPhonebookDaoImpl实现类并没有提供 setSessionFactory()方法，该方法由其父类HibernateDaoSupport提供，用于为DAO组件依赖注入SessionFactory.

依次类推，可以完成所有持久化类的DAO组件的配置.

3.2　配置XCAP组件

XCAP组件用于实现业务逻辑与XDMS服务器的解耦. 同样地，XCAP组件也通过接口为业务逻辑组件提供服务，再通过实现类编写具体的实现. XCAP组件应当提供的功能包括构造XCAP请求、构造XCAP消息等.

由于XCAP是基于HTTP的协议，我们可以借助HTTP开源包来实现XCAP中基本的通信功能. HttpClient是开源组织Apache提供的一个使用Java语言实现的HTTP开源包，使用其中的HttpClient类可以模拟各种HTTP客户端所需的功能，使用其中的GetMethod，PutMethod，DeleteMethod类可以创建不同类型的连接，以对应XML文档的获取、创建、修改和删除操作.

XCAP接口和实现类的类图如图3.

图3　XCAP组件接口和实现类的类图Fig.3　The class diagram of XCAP component

在Spring中进行如下配置，将XCAP组件添加到IoC容器.

〈bean id=“XcapComponent”class=“com.bupt.uc.components.XcapComponent”〉

〈/bean〉

3.3　配置HTTP组件

HTTP组件用于连接业务逻辑与SM-Proxy. 由于与SM-Proxy之间的交互比较简单，因此HTTP组件只需完成HTTP消息的发送和接收即可. 在XCAP组件的实现中介绍了HttpClient类，它具备了所有HTTP组件需要具备的功能，因此，直接使用HttpClient类作为业务逻辑层的HTTP组件. 为在业务逻辑中使用该组件，只需要在Spring的配置文件中进行配置.

3.4　配置FTP组件

FTP组件用于与话单接口机之间建立FTP连接，发送和接受信息同步文件. 同时，还应具有移动、删除等功能，以便完成文件的转移和备份. 另外，还应支持批量上传和下载文件的操作.

FTP组件类FtpComponent依赖于FtpClient类，FtpClient是开源软件edtftpj提供的开源包中的FTP客户端组件，可以完成基本的FTP操作. 在FtpComponent类中对其进行封装，并将它配置到Spring容器中.

3.5　配置业务逻辑组件

业务逻辑层为Web层提供完成各类业务逻辑的服务，这些服务通过业务逻辑接口暴露给Web层，供Web层的控制器进行调用，而服务的实现在相应的实现类中进行定义. 通过面向接口编程，控制器无须与具体的业务逻辑组件耦合. 假如需要改变业务逻辑的实现时，可以只提供新的实现类，而不需要改变其控制器代码[4].

在自助服务门户系统中，业务逻辑层提供的服务放在UCService接口中进行定义，并在UCServiceImpl类中实现它们. UCServiceImpl的实现依赖于前面各节介绍的四类组件. UCService接口与其实现类UCServiceImpl，以及实现类依赖的四类组件类的类图如图4.

图4　业务逻辑组件的类图Fig.4　The class diagram of service logic components

从类图中可以看出，UCService接口提供了四个业务逻辑的功能，而这四个功能的实现则分别依赖于四个不同的组件. 由于Web层仅仅与UCService提供的接口耦合，因此通过这一扩展的业务逻辑层，系统底层的组网细节和交互方式都被隐藏了. 对于Web层的使用者来说，调用addComPhonebook()方法与调用addGroup()方法并无区别，但在实际场景中，前者将一个ComPhoneBook(企业通讯录)实例持久化到数据库中，后者则将一个Group(群组)节点添加到XDMS上的XML文档中.

在3.1节中，介绍了如何借助Spring的IoC容器获取DAO组件的实例. 为在业务逻辑组件的实现中获得其它三个不同组件的实例，可以使用同样的办法.

为了实现Spring的依赖注入，需要在UCServiceImpl实现类中添加四类组件的setter方法，然后在Spring配置文件中配置业务逻辑组件时，将它依赖的四类组件作为property子元素，这些子元素分别引用3.1至3.4节中配置的4类bean.

〈bean id=“ucService”class=“com.bupt.uc.service.UCServiceImpl”〉

〈!--省略了部分property子元素的定义--〉

〈propery name=“comPhonebookDAO”ref=“ComPhonebookDAO”/〉

〈property name=“xcapComponent”ref=“XcapComponent”/〉

〈property name=“httpComponent”ref=“HttpComponent”/〉

〈property name=“ftpComponent”ref=“FtpComponent”/〉

〈/bean〉

至此，研究实现了自助服务门户系统的业务逻辑层，它对传统的基于SSH框架的Web应用系统的业务逻辑层进行了扩展，使之具备了与多种组网设备进行信息交互的能力. 另一方面，业务逻辑层的扩展并未破坏它与Web层之间松散的耦合性，自助服务门户系统的业务逻辑层可以以传统的方式供Web层调用.

4　结束语

介绍了融合通信业务门户系统区别于其它Web应用程序的显著特征，并提出了一种通过扩展系统架构中的业务逻辑层来实现系统功能的实现方案. 这种方案体现了SSH框架在可扩展性等方面的优势，更大限度地发挥了SSH框架的能力. 对其它基于SSH框架的轻量级J2EE应用在系统扩展和优化方面具有一定的参考价值.

目前在软件开发领域存在着众多优秀的开发框架，它们有着各自的特点和优势，任何一种开发框架都不可能适应所有的应用场景. 因此，一方面应当根据具体应用场景选择适当的开发框架，另一方面，也应当打破惯性的思维，通过扩展和改造，充分发掘开发框架的能力，以便在不破坏系统架构的基础上，实现更加丰富的功能.