杨柳1,2，王晶1,2，王纯1,2
（1.北京邮电大学网络与交换技术国家重点实验室 北京 100876
2.东信北邮信息技术有限公司 北京 100191）
摘要 本文讨论了SIP应用服务器的业务开发框架的发展趋势，针对NGN业务开发现状，提出了业务层框架的解决方案，并给出了关键模型的设计。
关键词 应用服务器 业务开发 SIP NGN
Improvement of Service Framework of Application Server
Yang Liu1,2，Wang Jing1,2，Wang Chun1,2
(1.State Key Laboratory of Networking and Switching Technology, Beijing University of Posts and Telecommunications, Beijing 100876,China;2.EBUPT Information Technology Co., Ltd., Beijing 100191,China)
Abstract: This article discusses the prospects of service framework of SIP(Session Initiation Protocol)application server. There are some problems in NGN(Next Generation Network) service development. In this paper, the corresponding solution is presented, and the key design of the model is given.
Key words: Application Server Service Development SIP NGN
1引言
随着用户业务需求的不断提高和各电信运营商之间竞争的加剧，增值业务的提供能力已经成为当今运营商竞争发展的重点。NGN(Next Generation Network)是一种业务驱动型网络，通过业务和呼叫控制分离与呼叫控制和承载分离实现相对独立的业务体系，使业务独立于网络，这种开放式业务架构，能不断满足用户的业务需求，增强运营网络的竞争力，因此，从现有的PSTN(Public Switched Telephone Network)网向NGN网络发展是电信网发展的必然方向。
NGN的业务开发、业务应用与传统业务有所不同。首先是业务的开放性，不像传统网络的封闭，NGN允许第三方来控制应用平台和提供业务，把NGN网络资源与IT业结合，可以在网络域外创建、测试以及运行。NGN有明显的多媒体特性，能提供个性化、差异化的业务。NGN中业务运营和网络运营分离，由网络运营商提供可靠高校的承载平台，由业务运营商提供各种应用[1]。
因此，NGN具有丰富的应用前景，满足用户多样化和个性化的业务需求，NGN能融合通信、信息、电子商务等业务，实现新型语音、数据和图像业务。在构建下一代网络时，运营商对业务发展提出了更高的要求，针对新客户提供多业务能力，对老客户进行业务升级，特别是能够利用原网络资源快速引入新业务，降低业务部署和维护成本[2]。
因此，作为NGN业务支撑环境主体的应用服务器在NGN网络中格外重要。应用服务器提供增值业务的业务驻留和执行环境，同时提供开放的API，为第三方业务开发提供开发环境。在NGN中，根据应用服务器与软交换的网络接口的不同，应用服务器可分为SIP应用服务器和Parlay应用服务器。本文的应用服务器指SIP应用服务器。
2应用服务器业务开发方式现状
SIP应用服务器提供的业务开发接口有API和脚本两类。
API开发方式主要有JAIN(Java API for Integrated Network) SIP API和SIP Servlet API。
JAIN的基本思想是定义一系列标准API，通过API对网络和协议的实现细节进行抽象，允许利用这些API开发可移植的应用。JAIN中的业务开发是基于Java部件（Java Beans），这些部件可以在一个动态运行系统上增加、删除、扩展、联合、分享和重新分布。JAIN技术使得业务开发更加快捷、更加简单、开销更小，业务开发者能方便得根据需求使用应用的Java业务控件生成所需的业务。
SIP Servlet1.1是对HTTP Servlet API和容器模型的扩展，也是一容器标准，专用于SIP协议，特定于Java语言。SIP Servlet是用Java语言实现的，类似WEB服务器常用的Java Servlet。Java Servlet已经被广大的软件开发人员所熟悉，这些人员很容易就可以基于SIP Servlet开发应用。这些灵活、开放的机制使业务提供者使用通用的编程语言方便开发各种智能业务，而不必考虑服务器的实现。
基于脚本的开发主要采用CPL(Call Processing Language)语言，CPL是一种基于XML，用于描述和控制呼叫类业务的脚本语言，可以支持呼叫策略路由、呼叫筛选、呼叫日志等业务。CPL脚本最初的设计目的是Internet环境中提供给使用IP电话的用户创造个性化业务的能力，它允许终端用户或者第三方，来设计、操作、升级、修改这些服务。
基于API的开发模式，虽然功能强大，可以实现各种电信业务，但是对开发人员要求高，需要手工编写全部的业务逻辑，调试和测试复杂，开发周期长。基于脚本的开发模式，只需要告诉应用服务器“做什么”，而无须告诉应用服务器“怎么做”，使业务的开发变得便捷。但是，脚本语言本身的能力限制了业务开发者的手脚，脚本的不可扩展性使得基于脚本的开发模式无法适用于全部电信业务。
3应用服务器业务层框架
3.1什么是业务层框架
首先，框架不是容器，不是一个能够提供某种能力的功能实体，业务层框架是一个半成品，通过抽象和复用业务中的相似特性，从而达到简化业务开发的目的。其次，框架不是SLEE和业务逻辑必须的中间件，它本身是业务的一部分，如图1所示。
业务层框架的作用有以下几点：
1. 定义业务逻辑的开发方式，即使没有业务层框架，开发人员也可以直接基于应用服务器进行业务开发（对于开发人员来说，这样的开发方式当然是一种折磨），但通过增加业务层框架，可以明确业务开发是利用API还是利用脚本，或者两者结合，更可以确定业务开发采用何种编程语言，是Java，是C或者是某种动态语言。
2. 可以降低业务开发成本，业务层框架可以屏蔽底层协议。根据关注点分离的原则，业务开发者并不需要花费巨大的成本去学习和掌握他们并不了解也不愿关注的底层协议细节，他们只需了解业务层框架提供的API和开发规则即可进行开发，而通常情况下，框架提供的开发方式远远比直接开发简单。
3. 促进代码复用，不同的业务开发过程中可能会遇到相同的情境，特别是对协议的处理，将这一部分内容抽象出来并整合到框架中，实现代码复用，因此减少业务的开发工作量。
业务层框架可以有多种实现，之前的Xjoin以及本文中的新型业务层框架都不是唯一的业务层框架，都只是框架的一种实现。
图1 业务层框架在AS中的位置
3.2应用服务器业务层框架Xjoin
北京邮电大学网络与交换技术国家重点实验室网络智能研究中心借鉴WEB领域成熟的以事件为驱动的的WEB应用框架模式，自主研发并实现了SIP应用服务器的电信应用业务层框架Xjoin为业务快速开发和代码重复利用提供了支持。
Xjoin介于应用服务器和业务逻辑之间，应用服务器将事件上报给Xjoin，框架负责执行业务逻辑。Xjoin框架采用了基于构件的软件架构，将各个模块做成构件的形式，通过构件的接口来相互调用[3]。Xjoin的基本结构如图2所示：
图2：Xjoin基本结构图
图中左侧的EBAS SLEE(EB Application Server Service Logic execute environment)即为应用服务器的核心部件业务逻辑执行环境，与Xjoin通过接口SleeService互连，SLEE将属于同一业务的事件路由到SleeService。
Xjoin的核心是EventHandler(事件接收者/事件处理器)
public interface EventHandler {
String handle(Event event);
}
整个Xjoin以及基于Xjoin之上的业务都是由大大小小的EventHandler连接起来构成的，他们通过对接收到事件的不同处理组合起来构成了完整业务。
图中的Application、Application Session、Session以及命名、日志等蓝色小块都是EventHandler。
Session是一个EventHandler、它表示一组有关联的事件的组合。Session接收一组有关联的事件，并按照配置将事件路由到实际的事件处理器上。
Application Session也是Session，它接收一个应用级会话的所有事件，并把事件路由到不同的子Session（比如一个sip session）中。
Application还是一个Session，它接收一个业务的所有事件，并将事件路由到不同的Application Session中。
业务行为依靠编写一个个不同的EventHandler来实现，业务逻辑本质就是将Event按照一定的顺序通过不同EventHandler。所有EventHandler利用Spring框架对于XML文件的解析能力组织在一起。因此，基于Xjoin的业务开发就是实现一系列EventHandler，并编写XML配置文件，将这些EventHandler组织在一起。
3.3新型应用服务器业务层框架
Xjoin的结构是极度灵活和可扩展的，这种灵活性是由于Xjoin的基础架构是职责链/拦截器、代理/装饰模式的组合。但是，基础架构灵活性、可扩展并不代表框架就好用。虽然可扩展性对于框架来说是必要的特性，但是开发者不会直接基于基础框架来扩展能力，通常还是基于Xjoin高层的Application->Application Session->Session这样的基于拦截器的运行时树形模型来开发。Application树形结构通过对事件的命名和路由，一定程度上简化了业务的事件路由和会话管理的功能但是这种结构也存在很多的问题需要解决，Xjoin目前通过扩展Spring，采用XML的方式配置业务的控制流程，由于目前业务层直接处理底层协议，需要在XML中处理各类协议自动机状态变化，导致出现很多的内部消息跳转，使得复杂业务的配置文件很大，不易进行业务流程测试。另外，Xjoin过分依赖Spring，在框架和业务层之间没有很清晰的接口。因此，需要研究和开发新型的业务层框架，在保持灵活的基础上，解决上述问题。
3.3.1新型业务层框架的运行时模型
图3 新型业务层框架的运行时模型
正如上文中提到的，Xjoin是基于拦截器和树形运行时模型，通过对原始事件的层层过滤和路由，实现应用、应用示例、协议会话的层次结构。这样的模型对事件有较强的控制，但是事件的层层递进和路由会一定程度上影响性能；同样，这种模型限制了同一应用会话的子会话间只能通过内部事件来交互，增加了复杂度；不利用做一些并发控制。
而图3展示的运行时模型就像一棵倒置的树，可以比较容易的对应用层做并发控制；传入事件不用层层推进，路由方式更加简单有效；这种模式下，在应用会话的开发中，可以通过API来进行子会话间的交互；业务层能有更多的自由来处理会话。
3.3.2高层事件
所谓高层事件是相对于协议层提交的原始事件来说的，目前Xjoin中需要对协议层的原始事件进行处理，需要知道原始协议细节；同时，由于目前的业务逻辑的流程控制都是在基于XML的配置文件里配置，因此协议层自动机的状态变化等都要通过配置文件显性配置，进一步增加了业务配置文件的复杂度。而业务开发者无需知道具体协议层的细节，针对此，提出相应的高层事件的概念，用来对原始事件进行自动化处理，将协议层事件与业务事件分离。
每个生成高层事件的实体，都是一个eventHandler，与普通eventHandler的区别是，高层事件实体是有状态的，我们把这样的eventHandler称为高层事件组件，高层事件组件的首要功能是能对底层协议进行自动化处理。
图4高层事件组件的基本模型
高层事件组件的基本模型如图4所示，每个组件都是一个提供某种高层事件的状态机，原子组件可以理解为最基础的协议层自动机，通过对组件的组合构成相对复杂的解决方案。重要的是，这些组件都是可以复用的。
每个高层事件组件一般都应该是内含状态机的，既然有状态机，就需要有触发状态机变化的外部因素。高层事件组件可以有两种方式触发自身状态变化：通过组件接收的事件对象；通过组件提供的API。而高层事件组件可以通过内部路由的方式向上层提供高层事件。
3.3.3会话状态自动机设计
下文将以SIP协议为例，说明业务层框架中逻辑实体的状态转移。框架中的关键实体有Transaction、Session、ApplicationSession。
ApplicationSession为应用级会话，和业务实例相对应，ApplicationSession对象保存所有会话参与方共用的内容。Session为协议会话，和会话参与方相对应，Session对象中保存的是某参与方自己的内容。一组完整的相关的SIP信令交互称为一个Transaction，也称为一个SIP状态机。
根据会话参与角色的不同，参考SIP协议栈的设计可以将会话分为四个状态：
Ø ICT (invite client Transaction)以发出invite为初始的会话
Ø IST (invite server Transaction)以收到invite为初始的会话
Ø NICT(non-invite client Transaction)以发出非invite信令为初始的会话
Ø NIST(non-invite server Transaction)以收到非invite信令为初始的会话
3.3.3.1 Transaction自动机的设计
Transaction对象是对一组完整SIP信令交互的抽象，根据当前正在处理信令的不同共有5种状态：
Ø PRE_CALLING Transaction对象创建后的初始状态
Ø CALLING 对象接收到invite消息后的状态
Ø PROCEEDING 对象接收到1xx临时响应后的状态
Ø COMPLETED 对象收到或发送invite请求对应的ack消息或Nxx消息后的状态
Ø TERMINATED 对象收到或发送invite请求对应的2xx成功响应后的状态
图5是ICT Transaction状态转移图，状态的转移由时间触发或者回调函数来触发。
图5 ICT Transaction状态转移图
3.3.3.2 Session自动机的设计
Session对象是对每个会话参与方的抽象，只需记录参与方在SIP协议层上的状态。Session中至少要包含一个Transaction对象，同时必须有一个Transaction作为Session的关键Transaction，此Transaction的状态决定了Session的状态转移。因此，Session自动机与关键Transaction自动机状态一致。
3.3.3.3 ApplicationSession自动机的设计
ApplicationSession自动机的设计要考虑的方面较多，其状态与呼叫所处的工作模式（UA还是B2BUA）有关，在UA模式下，每个ApplicationSession只包含一个Session，因此状态与Sessiond的状态一致，而在B2BUA工作模式下的自动机包含七个状态PRE_CALLING、CALLING、PROCEEDING 、TRYING、CONFIRMED、COMPLETED 、TERMINATED，其状态转移如图6：
图6 ApplicationSession状态转移图
1. 主叫Session（IST）的初始状态为IST_PRE_CALLING，被叫Session（ICT）的初始状态为ICT_PRE_CALLING,ApplicationSession的初始状态为PRE_CALLING。
2. 主叫Session在收到invite事件后，状态变为IST_CALLING，再触发ApplicationSession的状态由PRE_CALLING变为CALLING。
3. 被叫Session在发出invite后，状态变为ICT_CALLING，再触发ApplicationSession的状态由CALLING变为PRECEEDING。
4. （1）若被叫Session收到Nxx消息，则状态变为ICT_COMPLETED,回复ACK的同时，再将ApplicationSession的状态由PRECEEDING或TRYING变为COMPLETED。
（2）若被叫Session收到1xx消息，则状态变为ICT_PROCEEDING,主叫发出1xx消息后，状态变为IST_PROCEEDING，再将ApplicationSession的状态由PRECEEDING变为TRYING。
（3）若被叫Session收到2xx消息(特指invite200)，则状态变为ICT_TERMINATED，主叫Session发出2xx消息以后，状态变为IST_TERMINATED，再将ApplicationSession的状态变为CONFIRMED。
4 结束语
本文结合当前电信应用服务器中业务开发现状，指出现有框架的瓶颈，讨论了业务层框架的演进方向；主要对下一阶段业务层框架中的关键模型进行设计，其中运行时模型的设计着重点在于降低事件路由的消耗和增强业务对会话交互的控制；高层事件的设计着重点在于把业务开发与底层协议解耦，降低业务开发人员的技术要求，使开发人员更加关注业务逻辑的设计；会话状态自动机的设计着重点在于对高层事件的支持，同时规范会话的创建与销毁，明确会话结束的终点。限于篇幅，文中没有给出详细的高层事件模式与类图，以及具体的实现过程和回调方法。
参考文献：
[1] 万晓榆，张洪，樊自甫．下一代网络的业务生成技术．北京邮电大学出版社，2005.3
[2] 廖建新，李彤红，陈俊亮，移动智能网和宽带智能网的研究现状及其展望，电子学报，<
搜索
关注微信
