基于SAI(业务能力注入模式)构建新的ParlayX业务能力集为向第三方开放业务接口提供了方法和架构上的可靠保证。

　　下一代网络是“业务驱动型网络”，这一特点所体现出来的网络融合、业务融合、业务开放的思想，在最大限度上扭转了传统电信网网络封闭业务单一的状况，是电信网络价值最大化的体现。

　　作为下一代网络技术的热点，IMS技术为业务开放提供了良好的基础。IMS技术的HOMEDomain提供服务模式解决了移动业务的业务可携带性问题，其MPC(MultiplePointofCon-trol)模型在一定程度上满足了多业务触发与控制问题；同时，IMS所勾勒出的由SIP应用服务器、SIPParlay/ParlayX网关、SIPIN-SSM网关组成的业务层，使基于IMS技术提供增值业务的手段更加丰富。

　　这一切似乎都预示着基于IMS技术提供增值业务已经成熟，但是为什么仍然没有出现大规模的部署SIP应用服务器的状况呢？问题的核心仍然在于业务接口与业务提供方式。

　　单纯依靠运营商自己提供的封闭业务(如基于智能网)已经被证明是效费比很低的模式，而通过将业务接口开放给第三方增值业务开发商和运营商，通过社会力量来扩展新的业务形式和业务领域(如短信平台)则证明是非常有效的增值业务模式。

　　为了能够适应第三方增值业务运营商的业务开发与运营，开放业务接口需要足够简单、灵活和安全。

　　开放业务接口技术的比较

　　回头看IMS技术提供的开放业务接口：SIP协议接口，Parlay接口和ParlayX接口。在实践中，这三类接口并不能完全满足运营商的业务运营需求。

　　SIP协议具有丰富的控制能力和业务支持能力，但也同样缺少接纳控制、业务能力注册与发现等框架支持，缺少对SIP协议网络控制能力的限制与监管，SIP协议的强大的网络控制能力在缺乏监管的情况下极容易被滥用，从而可能危害网络的安全。

　　Parlay技术具有抽象程度适中的接口能力，具有完善的业务能力发布与发现、业务能力接纳管理的Frame-work，能够保证业务能力安全可靠的接入网络。不过，Parlay接口仍然是一种以网络能力为基础的接口。虽然ParlayAPI在设计的过程中，其目标用户是没有电信经验的传统IT开发人员，但是在实际使用中，开发人员首先必须理解业务触发与检测的概念与规则，理解详细的呼叫过程与过程中资源控制。同时，基于Parlay技术所依赖的CORBA分布式计算环境技术对于中小第三方增值业务开发商与运营商来讲也是一个不小的技术障碍。

　　与SIP和Parlay技术相比，ParlayX技术则从用户需求和业务提供角度对接口进行了进一步封装。ParlayX技术与SIP和Parlay技术的最大不同在于，前者是针对业务能力进行的封装，而后两者是对网络能力进行的封装。ParlayX接口的优点主要有以下三点：

　　首先，在使用基于业务能力进行封装的ParlayX接口的时候，开发人员不需要关心网络的呼叫过程与资源管理过程，而只需要将关注点集中在具体的业务逻辑实现，因此ParlayX接口能够有效降低业务开发人员开发电信业务的技术门槛。

　　其次，承载ParlayX接口的WebService技术是Internet行业被广泛应用的技术，出发点是实现Internet上分布的异构应用的共享，其客户和服务器之间是简单的“请求-响应”模式的面向服务交互过程，控制粒度在“服务”级别上，适合于普通的IT应用开发者。

　　最后，由于ParlayX是针对业务能力的封装，业务开发人员并不能直接访问到网络控制能力，因此具有很好的网络安全性，使运营商能够将这一接口开放给位于不可信任域的第三方增值业务开发与运营商使用。

　　由此可见，ParlayX技术将是未来第三方增值业务接口的核心技术。

　　ParlayX技术存在的问题

　　虽然ParlayX能够满足作为第三方增值业务接口的需要，但是ParlayX技术及现有的ParlayX能力集仍然有其不足：

　　首先，WebService技术通常用于完成持久性无状态的服务，持久性和无状态意味着WebService服务并不会区分客户，不会记录客户的一系列相关操作。其认为每一个客户的每一次请求都是相对独立的一次服务过程。因此需要通过应用扩展来支持服务的状态。

　　其次，现有的ParlayX规范定义的业务能力过为简单，如不支持预付费、IVR等业务类型，也不能满足业务中对复杂需求(如可变语音、复合语音)的支持。

　　最后，基于WebService的无状态特性，现有呼叫控制类API没有对呼叫状态的维持，因此无法对呼叫的进展保持监控，也不能根据呼叫的具体进展情况做进一步的处理，同时应用也无法利用网络专有资源向用户提供服务。

　　为了克服ParlayX封装层次过高，业务能力相对固定的缺陷，一些新的业务能力集被提出来，其中最典型的是中国电信研究院SAG项目所提出来的ECC能力集。

　　ECC能力集针对结束呼叫、语音交互、彩铃、基本呼叫、顺序呼叫和同振呼叫等业务形式进行了封装，能够在一个呼叫过程中持续进行控制，监测呼叫过程中的多种事件并进行处理，从而增强了业务开发的灵活性，支持了更多的业务能力。

　　ECC能力集虽然在一定程度上提高了接口的控制能力，但是并没有真正的解决ParlayX接口的缺点：

　　ECC接口虽然提供了一个增强呼叫控制能力的业务能力集，但是这个接口仍然是针对某几个特定业务类型的抽象，如应用发起两方、呼叫转接等，对于其他的业务类型则无能为力。

　　ECC接口仍然继承了ParlayX的基本特点，即接口消息语义与业务能力绑定。如enhandleUIEvent表达出的语义是应用控制的用户交互，其只能用于承载ECC业务能力。当需要扩展业务能力的时候，则要全部更换接口语义，这不利于新业务的提供。

　　ParlayX业务接口为每一种业务能力提供一种独立的能力集的做法，需要业务能力提供侧准确的解析每一种能力集的语义，不利于提供一个统一的业务接入网关。

　　能力注入模式出炉

　　为了向第三方提供合适的业务能力集，开放业务能力的一方需要改变传统的增值业务逻辑直接使用业务能力集或网络能力集的开发模式。

　　这一模式带来的直接问题就是：细粒度的网络能力集虽然能够满足灵活业务开发的需要，但不能向第三方开放；粗粒度的业务能力集虽然能够满足开放的需要，但不能解决业务能力集灵活性的欠缺。

　　新的业务能力集设计模式被称为“业务能力注入模式”(ServiceAbilityInjection)。在这一模式下，业务能力集将被抽象为业务模板框架(ServiceTem-plateSchema)，这一框架包含两部分内容：业务逻辑框架和业务数据框架。

　　业务模板框架将业务逻辑的执行过程描述为数据结构，将业务逻辑执行过程中需要用到的数据结构抽取成为数据约束。

　　实际的增值业务逻辑并不是使用业务能力集的消息语义完成业务的控制，而是通过控制业务模板框架所约束的数据，并将该数据注入到提供业务模板框架解析的业务模板逻辑中，从而驱动业务的执行。

　　基于业务能力注入模式，各种业务能力集将有统一业务能力注入方法，从而使增值业务的开发不必关心不同业务能力集语义的差异，有利于构建统一的增值业务开发环境；同时不同的业务能力集将有统一的业务模板运行环境和对外接口环境，从而有利于ParlayX网关通过动态加载业务模板的方式扩展对业务能力集，有利于构建统一的ParlayX业务接入网关。基于业务能力注入模式构建新的ParlayX业务能力集为向第三方开放业务接口提供了方法和架构上的可靠保证。

*博客内容为网友个人发布，仅代表博主个人观点，如有侵权请联系工作人员删除。