電信業務能力開放技術標準

楊　勇　賈　霞　董振江

摘要：電信業務能力的開放是電信技術發展過程中長期研究的熱門課題之一，電信業務能力的開放技術在不斷的發展，相應的標準也在不斷的提出或更新。在這些標準規范之中，JCP和Parlay系列規范是兩大主流的國際規范，分別提供了不同層次的、面向不同用戶對象的業務能力開放技術標準。其中，JCP針對JAVA應用開發人員制定了JSR21、JSR32、JSR116和JSR289等系列規范，而Parlay則提出了Parlay和Parlay X等規范，規范的版本也在不斷地更新之中。各種不同的能力開發技術實現方法不同，各有各的優勢和生命力。隨著業務開發的群體不斷壯大和融合業務開發的要求越來越明顯，提供一種快速、高效和簡易的業務能力開放技術就成為業務能力開放技術研究的重點。

關鍵詞：電信業務能力；開放技術；JCP

Abstract: The open technique of telecommunication service capability is one of the most interesting subjects in the research of telecommunication technique, and the correspondent standards are also proposed or updated continuously. Among the standard group, JCP and Parlay are the two active international standards groups, which propose different kinds of technique standards for different users in different levels, such as JSR21, JSR32, JSR116 and JSR289 in JCP, and Parlay/Parlay X with different version in Parlay group. Each of these standards is realized in different technique, and each one has its own advantage and lifecycle. With the application developer and the need for the convergent applications becoming more and more obvious, it is more important to provide a kind of fast, efficient and easy service capability open technique.

Key words:telecommunication service capability; open technique; JCP

電信業務能力的開放是電信技術發展過程中長期研究的熱門課題之一[1-7]，其主要目的就在于將電信能力開放出來，使得電信業務開發變得更為容易和高效，豐富電信增值業務，促進電信行業的發展和繁榮。

最早的電信業務能力開放技術要追溯到傳統的智能網和基于用戶交換機(PBX)的計算機電話集成(CTI)技術[8]，它為第三方監控和控制電話呼叫提供了技術支持。智能網[9]技術實現了業務和呼叫控制的分離，它將業務控制從交換機中分離出來，同時，提供了一種高效的、圖形化的業務生成環境(SCE)；隨著業務能力開放的日益增長的需要和Java技術的發展，業務能力開放技術規范也在以更快的速度在不斷地發展和完善。

關于業務能力開放技術的標準規范主要包括了兩大組織，JCP和Parlay/OSA，其中，JCP是由SUN公司于1995年發起成立的一個開放的國際組織，主要由Java開發者以及被授權者組成，職能是發展和更新Java技術規范、參考實現和技術兼容包。目前JCP有1 200多個成員加入，由數百名來自世界各地Java代表成員一同監督Java發展的正式程序。Parlay/OSA組織成立于1999年，它是一個由65家通信和IT領域的公司共同參與的非盈利性組織，致力于定義一個讓IT開發人員快速創建電信業務的應用程序接口(API)。這些接口覆蓋了各種電信網的功能如呼叫控制、短消息服務/多媒體短消息服務(SMS/MMS)、定位、計費、在席和可用性管理以及策略管理等等。

下面，首先從傳統的智能網技術入手，來分析并介紹一下業務開發和業務能力開放的不同模式以及標準規范。

1 CTI技術

最早的CTI技術有兩大技術規范，其一是電話應用程序接口(TAPI)，它是微軟和英特爾推出的產品，其1.0版本最初在1993年發布，提供一組用于編程的應用程序接口(API)函數，支持Windows平臺上的CTI應用。它的優點是能在基于Windows的應用系統和電話系統之間建立連接；其二是電話服務應用程序接口(TSAPI)，它是由Novell和AT＆T共同創造的。正因為有AT＆T的參與，TSAPI可以與現有的電話交換機很好地兼容。基于CTI技術的呼叫中心業務，作為PBX交換機的功能補充，也得到了廣泛的發展和應用，特別地，伴隨著VoIP技術的發展，集成CTI技術的下一代呼叫中心業務目前得到了大規模的應用。

2 智能網技術

智能網的目標不僅在于今天能向用戶提出諸多的業務，而且著眼于今后也能方便、快速、經濟地向用戶提供新的業務。因此，智能網為了向用戶提供新的業務而采用了一種新的方法，即建立集中的業務控制點和數據庫，進而進一步建立起集中的業務管理系統和業務生成環境來達到上述目的。

智能網定義了一個完整的業務總體架構，包括業務交換點(SSP)、業務控制點(SCP)、業務管理點(SMP)、業務數據點(SDP)和SCE等，它是一個用于產生和提供電信業務的體系結構，能快速、方便、靈活、經濟、有效地生成和實現各種新業務的體系。這個體系的目標是為所有的網絡服務，即它不僅可以為現有的公共交換電話網絡(PSTN)、分組交換公共數據網(PSPDN)以及窄帶綜合業務數字網(N-ISDN)服務，還可以為寬帶綜合業務數字網(B-ISDN)、公共陸地移動電話網(PLMN)和Internet服務。

作為一個生成和提供新業務的體系，它的特征是：

●有效地使用網絡資源；

●網絡功能的模塊化；

●重復使用標準的網路功能生成和實施新的業務；

●網路功能靈活地分配在不同的物理實體中；

●通過獨立于業務的接口，網路功能之間實現標準通信；

●有效的使用信息處理技術；

●業務用戶可以控制由用戶所規定的業務屬性；

●業務使用者可以控制由使用者所規定的業務屬性；

●標準化的業務邏輯管理。

智能網的目標，是利用獨立于業務的功能塊、功能實體的標準通信，有效地利用已有的資源，快速、簡便、靈活地提供各種新的補充業務。智能網的目標是逐步完成的，目前正在建設的智能網是能力級1(CS-1)，CS-1主要限于向PSTN、N-ISDN和在一個網的網內提供各種智能網業務。但是隨著網路發展以及實際網路運行的復雜性，用戶還有業務管理和業務生成等方面的要求，因此在CS-2增加了網間互通業務、呼叫方處理業務(如呼叫轉移、呼叫等待等等)、終端移動性業務、業務管理業務、業務生成業務等。

目前CS-1和CS-2方面的建議已經標準化，國際電信聯盟遠程通信標準化組(ITU-T)現正著手CS-3方面的研究。除了對CS-3進行研究外，還在研究智能網長期架構(LTA)。LTA的研究是為適應當前技術的快速進步，用戶對業務需求的快速增長，各種業務間的互連以及由于通信市場引入競爭機制而提出的，目的在于提出一種靈活地、適應新技術發展的、又能滿足各種可能的業務需求的新型通信網控制和管理機制。

因此，智能網的發展是以業務發展為前提，并且將逐步擴展到移動通信和寬帶通信領域，還要與電信管理網結合起來，提供一種更靈活、適應最新技術發展的通信系統。

智能網近期的發展是使用綜合智能網系統，同一個智能網可以接入GSM、CDMA、PSTN、Parlay、HTTP等不同的協議，業務邏輯處理與網絡類型無關。

早在1994年，鑒于對國際智能網業務的迫切需求，我國首先建設了國際智能網，提供300、800及VPN三種電話業務。從1995年起，開始建設國內智能網，它與國際智能網是分別進行建設和使用的，各自提供不同的業務，擁有各自的用戶。兩個智能網間是不互通的。

智能網技術的出現，使得呼叫控制與業務相分離，極大促進了業務的發展。然而，在傳統的智能網體系中，SCE是與業務執行點SCP緊密捆綁在一起的，沒有形成統一的標準，也不具備開放性。通常情況下，只有電信設備商自己的開發人員利用自己的SCE來開發智能業務。

3 JCP相關規范

隨著Java技術的迅速發展，Java開發人員和許多組織都投入研究基于Java技術的電信業務能力開放技術，相關的技術規范也在快速的制定或更新之中。

JCP是一個基于Java的開發組織，專門制定一些Java的技術規范。最早基于Java的CTI技術標準是Java電話應用程序接口(JTAPI)是由Intel、Lucent、Nortel Networks、Novell以及Sun微系統等公司組成的工作組在1996年共同開發出來的。JTAPI是一種為電腦電話應用程序而設的基于Java的應用編程接口，它由一組語言包組成，核心包為簡單的電話過程提供了一個基本的框架，例如：打電話、接電話、還有掛電話等，而其它的擴展包提供了附加的電話特性。JTAPI在不同的電腦平臺下可以共同使用，它與TAPI相類似，二者之間的關系就類似于開放數據庫連接(ODBC)和Jave數據庫連接(JDBC)的關系。

JCP組織在發展過程中，不斷完善了基于Java的技術規范并定義為JCP的標準，陸續發布了多個電信業務能力開放的Java規范[10-11]。下面，我們對這些Java規范做一個較為詳細的介紹。

3.1 JSR21規范

JSR21規范[12]全稱是“JAIN Java Call Control Application Programming

Interface”，它是一組用于在融合的PSTN、分組交換和無線環境下創建、監控、控制、操作和拆除通訊會話的Java接口。它為第三方應用提供了使用包括核心網和外圍設備在內的網絡元素的能力。Java呼叫控制(JCC)允許應用在會話建立過程中被觸發或調用，本質上類似于智能網(IN)或高級智能網(AIN)中業務被調用的模式。因而JCC允許編程人員開發應用，同時這些應用可以在支持這些API的任意平臺上運行。這就使得業務提供商可以通過自己開發或購買第三方開發的業務的方式來快速高效的提供業務給終端用戶。JCC規范中所定義的API是從JTAPI繼承下來的。

JCC API并不是用于將電信網絡信令架構開放給公眾，它只是將網絡能力進行封裝，使得電信能力采用可見對象技術以一種安全、可管理和可計費的方式被表述和使用。這種方式允許獨立的業務開發者來開發電信業務，不會對網絡安全和可靠性帶來不利影響。JCC API由一些相關的互相交互的對象的集合所定義，這些對象模化了一個會話中所涉及的不同的物理和邏輯元素或相關功能。應用通過面向對象的過程圖與各個對象交互。JCC API不僅僅可以控制語音呼叫，而且還可以控制數據和多媒體會話。

JCC API從結構上可以分為3類：

●基本的呼叫控制，這個Java軟件包包括了發起和應答呼叫的基本工具。

●核心的呼叫控制，這個Java軟件包包括監視、發起、應答、處理和操縱呼叫的工具，同時還提供了在呼叫過程中調用其它應用并返回結果的一些工具，可以滿足絕大部分基本呼叫和增值業務實現的需要。

●擴展的呼叫控制，該Java軟件包還提供了一些擴展的細粒度的呼叫控制功能。特別地，與JCC不同，JCAT能夠支持所有通用的AIN應用以及與其它的語音/數據和下一代業務的集成。

基于以上的軟件包開發的應用可以執行在交換機平臺自身上，也可以以協作式、分布式的方式橫跨多個平臺。

JCC API只提供Java API接口定義，接口的實現需要設備商自已去做。這組API屏蔽了網絡傳輸層，適用于PSTN、IP網或無線網等任何網絡類型，同時也不關心底層的通訊協議或信令，可以是媒體網關控制協議(MGCP) [13]、會話初始協議(SIP) [14]、或七號信令等任意信令方式。對于應用開發人員來講，這些網絡基礎知識他都無需關心。

從以上的簡要介紹可以看到，JSR21規范的主要目的是，滿足第三方Java開發人員開發呼叫業務。但是，該規范中定義的API接口是一種面向底層的呼叫控制信令的操作接口，對于應用的開發人員而言，需要具備通訊的基礎知識。此外，由于SIP協議的擴展性非常強，利用JCC API開發基于SIP協議的應用時，應用的功能往往會受到API的擴展性的限制。

3.2 JSR32

JSR32規范[15]的全稱是“JAIN SIP API Specification”，它是JCP組織定義并開發的一套用于開發SIP應用的接口規范，為開發人員提供了一個與RFC3261規范兼容的基于Java語言的標準的SIP服務接口。

JSR32規范支持SIP基本規范RFC3261以及下述擴展規范：

●RFC2976：INFO方法

●RFC3262：可靠的SIP響應；

●RFC3265：事件通知框架；

●RFC3311：UPDATE方法；

●RFC3326：Reason頭部；

●RFC3428：Message方法；

●RFC3515：REFER方法和即時消息的定義；

●RFC3581：通過共享的多播地址分發可靠的命名服務器；

●RFC3903：PUBLISH方法；

JSR32規范標準化了SIP協議定義的普通交易模型，提供從交易接口接入對話的功能。該架構用于J2SE環境下的應用開發，是一個基于事件的偵聽/提供模型，定義了很多工廠類，用于創建請求消息和響應消息的SIP頭。它為每個支持的頭定義了通用接口，可添加到Request消息和Response消息中。SIP消息通過一個事務被傳到偵聽/提供模塊用于監聽到來的事件，包括請求的響應或者新的請求。此外，JAIN SIP被設計為可擴展的，定義了通用的擴展頭接口，以便應用處理規范中不支持的SIP頭域。

需要注意的是，對SIP消息重發的缺省處理是取決于應用類型，所有的重發都是由用戶代理(UA)中的協議棧來處理的。

由于JAIN SIP API是對SIP標準的完整定義，任何基于SIP的程序可將JAIN SIP API用作Java標準接口，成為經JAIN SIP認證的棧。這意味著應用服務器、SIP電話、網關及網關控制器、SIP服務器、基于SIP的業務、SIP計費解決方案、開發者工具包、SIP測試工具、SIP用戶代理以及SIP網絡管理，均可利用JAIN SIP API實現在SIP棧實施中的通用性。典型的SIP網絡中，JAIN SIP接口應用于代理服務器、媒體網關和客戶端。JAIN SIP API涵蓋了比用戶代理或客戶端軟件所需更多的內容。

JAIN SIP API提供的基本類可以分為4個軟件包，分別是：

●javax.sip：該程序包包含的是，從應用開發人員和協議棧提供商的角度所提供的基礎架構的主要接口。

●javax.sip.address：該程序包包含用以表示SIP協議中的地址組件的接口。

●javax.sip.header：該程序包包含本規范所支持的SIP頭域表示和獲取接口。

●javax.sip.message：該程序包包含用以表示SIP消息體的接口。

JSR32規范同JSR21規范相比，它是一種專門針對下一代網絡(NGN)或IP多媒體子系統(IMS)等SIP協議網絡，同時，它為應用開發人員提供了一個Java的SIP協議棧及相應接口，這個接口是協議層的接口；而JSR21規范它是一種功能操作級別的接口，比JSR32規范的層次要高得多。JSR32提供的接口，允許開發人員獲取或操作包括SIP頭域中的各個字段和SIP消息體在內的所有的SIP消息內容，應用開發人員必須具備專業性的SIP協議知識，才能開發SIP應用。

3.3 JSR116

JSR116規范的全稱是[16]“SIP Servlet Specification v1.0”，它是JCP組織定義并開發的一套基于SIP容器的SIP應用開發規范。

SIP Servlet是一個基于Java的應用組件，它由SIP容器管理，同時實現SIP信令的處理。和其它的基于Java的組件一樣，Servlet是與平臺無關的Java類，可以動態加載在基于Java的SIP應用服務器中來運行。容器是提供Servlet功能的服務器擴展，借助于Servlet容器，Servlet通過請求和響應消息之間的交換來實現與客戶端的交互。SIP Servlet容器是應用服務器的一部分，它為網絡層業務提供請求和響應消息的接收和發送，它決定了接收到的SIP消息觸發哪個應用，同時，以什么順序來觸發。SIP Servlet容器同時包含Servlet的生命周期管理功能，它還負責網絡偵聽點的管理，SIP規范要求所有的SIP網元應該支持用戶數據報協議(UDP)和傳輸控制協議(TCP)，可選支持安全傳輸層(TLS)和流控制傳輸協議(SCTP)等。SIP Servlet主要用于開發基于SIP協議的應用，目前，基于SIP的應用主要包括呼叫類的應用、即時消息、在線和由SIP Message方法衍生出來的SIP短消息等。用于開發SIP應用的接口規范，為開發人員提供了一個與RFC3261規范兼容的基于Java語言的標準的SIP服務接口。

在JSR116規范中，SIP Servlet容器的作用主要包括：

●應用管理

一個SIP應用的Servlet上下文可以包含多個SIP Servlets一旦部署之后，Servlet上下文的生命周期由Servlet 來維護。盡管Servlet 上下文可以隨著服務器的起停而起停，但是系統管理員也可以顯式地啟動/停止/重載Servlet 上下文。

●SIP消息處理

SIP Servlet容器提供的SIP消息功能包括：分析接收到的SIP消息、將分析后的SIP消息轉發給相應的SIP Servlet、發送SIP Servlet產生的消息給相應的UA、自動生成SIP響應，如 "100 Trying"、自動管理SIP頭部字段。SIP Servlet 處理的SIP消息都被表示為SipServletRequest 或SipServletResponse對象，接收到的SIP消息首先分析器分析之后，再翻譯成這些對象，然后發送給SIP Servlet 容器。

●工具功能

SIP Servlet 定義了下述的工具：SIP會話和應用會話、SIP工場和代理。

JSR116規范是一種針對SIP協議，并提供容器式SIP應用管理的SIP應用開發工具。從接口的封裝程度上講，它是一種介于JSR21和JSR32之間的接口規范，不僅提供了方法級的操作接口，而且提供了協議層的數據操作接口。從應用開發的角度講，靈活性和易用性都不錯。JSR116是SIP容器產品的1.0規范版本，目前1.1版本規范JSR289也已經發布，同JSR116相比，大的框架上沒有變化，僅僅對部分接口定義做了改進。最新的SIP Servlet規范是1.1版本，參見JSR289[17]。

此外，由于SIP Servlet規范僅僅定義了基于SIP Servlet所提供的接口來開發SIP應用，但是，我們知道，大多數電信應用都會涉及到放音、收號和會議等基本電信功能，而包括JSR116和JSR289在內的SIP Servlet規范，都沒有定義與此相關的功能接口，因而2007年JCP組織發布了JSR309規范[18]——“Java MediaServer Control”，該規范定義了與媒體服務器控制相關的功能接口來配合基于Java的SIP應用開發。除以上規范之外，JCP還定義了一個關于業務執行環境的JAVA規范，JAIN SLEE V1.0。JAIN SLEE是JAIN API集合中的一個組成部分，它處于JAIN的核心地位，是應用的邏輯執行環境，具體參見JSR22[19]，在此不在贅述。

4 Parlay相關規范

Parlay組織成立于1999年，它是一個由65家通信和IT領域的公司共同參與的非盈利性組織，致力于定義Parlay APIs為一組開放的、獨立于技術的、可擴展的API，以便于第三方業務開發商、獨立軟件提供商能通過Parlay API來開發業務。到目前為止已經發布了多個版本的Parlay規范。Parlay組織的公司成員包括阿爾卡特、英國電信、愛立信、富士通、惠普、IBM、Incomit、朗訊、NTT、西門子、SUN、Telcordia科技、意大利電信、Teltier和其他50個北美、歐洲及亞洲的公司。OSA在3GPP和3GPP2的移動業務體協結構中被引用，而Parlay就是OSA中的API部分。

Parlay API[20]的定義采用接口描述語言(IDL)來描述，API的實現采用分布式的Corba中間件技術。

Parlay組織研究開放的接口部分，并不關心任何基礎電信網絡結構和技術，該接口介于業務提供網絡部分和核心網絡部分之間。當Parlay組織正著手研究Parlay2標準時，3GPP和ETSI也開始研究基于第三代網絡的應用服務開發API接口。由于在研究領域上有很大的重疊性，3GPP和ETSI很快就發現Parlay可以應用在他們關于第三代網絡的API接口上。因而，Parlay被引入了3GPP/ETSI標準框架中并命名為OSA，3GPP/ETSI對Parlay標準進行了進一步的補充。

現在3GPP已經發布了Release 5版本的API標準，ETSI和Parlay Group也發布了相應的版本，最高版本已經發展到Parlay6.0。

在Parlay API的版本發展到Parlay 4.0時，Parlay組織發現，Parlay規范在IT研發人員看來，還是相當的龐雜，對于IT研發人員而言，采用Parlay協議規范研發基于電信網絡的應用還是有相當的難度。基于此，3GPP提出了Parlay X規范[21]。Parlay X協議在原有Parlay API協議的基礎上，對API進行了進一步的抽象，并使用基于Web業務的WSDL語言對API進行描述，從而提供了IT研發人員一個更為清楚、簡潔、抽象、易于理解的電信業務研發接口。這樣IT研發人員無需掌控電信網絡專業知識，即能夠根據Parlay X協議接口研發、應用下一代網絡業務。從而促進下一代網絡業務的發展。

在Parlay4.1規范發展為ParlayX規范之后，后來逐漸出現了兩個分支，原來的Parlay規范急需發展下去，直到現在的6.0規范，而ParlayX規范也不斷發展，逐漸推出了2.0、2.1、2.2等，直到現在的ParlayX3.0規范。

下面，我們對Parlay組織定義的相關規范分別做一簡單介紹。

4.1 Parlay規范

Parlay規范定義了多組業務能力特征(SCF)，每組SCF對應有一組業務能力開放的接口API。

Parlay/OSA的邏輯結構中主要包括以下幾個部分，如圖1所示。Parlay 應用、Parlay/OSA框架、業務能力特征服務器(SCS)和核心網。其中，框架和業務能力服務器合稱為Parlay網關。各部分的功能如下：

框架：負責應用的鑒權計入、業務能力的注冊和發現以及完整性管理等功能；

SCS：負責業務能力開放接口API的實現；

Parlay 應用：它是基于Parlay GW開發的電信應用。

以Parlay4.0規范為例，共定義了11個SCF：呼叫控制、用戶交互、移動管理、終端能力、數據會話控制、普通消息、連通性管理、賬戶管理、計費、策略管理和呈現和可用性管理。

3G網絡的開放結構為Parlay GW控制網絡資源提供了必要條件。在3G IMS網絡中，CSCF設備是網絡的中心。它獨立于底層承載協議，完成呼叫控制、媒體網關接入控制、資源分配、協議處理、路由等，可以向用戶提供現有網絡能夠提供的業務。基于Parlay GW開發的應用提供業務邏輯的駐留和執行環境；由Parlay GW提供的API為第三方的業務開發提供開發平臺。Parlay GW是業務提供面中的主體，也是業務提供和開發的核心，它幫助業務平面利用下層網絡的各種資源提供豐富的業務。這種架構將業務與呼叫控制分離、呼叫控制與承載分離來實現相對獨立的業務功能，使得上層業務與底層網絡無關，從而可以靈活、有效地實現業務提供。

4.2 Parlay X規范

Parlay X規范是在Parlay規范基礎之上發展起來的。盡管Parlay規范定義了多組API將電信業務能力開放給第三方，但是，對于IT開發人員而言，這些API的使用仍然過于復雜，而且，由于采用了Corba中間件產品，使得API的開放性受到了一定的影響。基于以上原因，Parlay組織對Parlay API進行了進一步的簡化，將API以Web服務的方式開放給第三方，形成了Parlay X規范。第一個規范Parlay X1.0于2003年4月正式發布，最新的規范版本是Parlay X3.0。

以Parlay X2.0規范為例，其中定義了多組業務能力，包括：第三方呼叫、呼叫通知、短消息、多媒體短消息、語音呼叫、終端狀態、終端位置、賬戶管理、呼叫處理、支付、多媒體會議、地址列表管理和呈現。

Parlay X對原來的Parlay API經過高度的抽象和封裝，定義了一組功能強大，但又簡單、抽象和極富想象力的電信能力API，以便于通信開發人員和IT開發人員都能快速地理解和掌握，并在此基礎上開發出具有創新意義的電信應用軟件。

Parlay X采用Web業務的方式，Web業務技術的開放性使得Parlay X的開放性更為IT開發人員所接受和認可。基于Parlay X API開發的應用與實現Parlay X Web業務的服務器(也稱做Parlay X網關)之間的交互方式采用基于可擴展標記語言(XML)的消息交換來實現；消息交換由應用發起，并且遵循同步的“請求/響應”模型。

當然，Parlay X Web業務服務器到應用的“響應”是可選的，根據實際的應用需求而定。然而，對于應用服務器作為被動方的消息通知類型的業務，就需要定義異步消息，這樣才能實現消息從Parlay X網關到應用的消息傳遞。

Parlay X API的封裝程度遠遠比Parlay API高，例如，在Parlay API中，應用側發起一個呼叫至少需要3次API調用(不包括接入和業務能力的獲取等前期大量的API調用)，createCall→routeReq(A)→routeReq(B)；而在ParlayX中，僅需要“makeACall”這一次API調用即可。這種較高的封裝程度大大簡化了開發人員的開發難度。然而從另一方面講，業務開發的靈活性也受到了一定限制，所以，對呼叫的持續控制不足，用戶交互能力的薄弱、缺少用戶鑒權手段等成為Parlay X被人所詬病的一些缺點，目前，相關組織正在對它不斷地改進。

5 各種業務能力開放技術的比較

綜合前面的介紹，我們可以把業務能力開放技術或者業務開發模式做一個比較全面的比較和分析。

首先，我們來看JCP系列規范。JSR21和JSR32規范用于開發單獨的應用，而JSR116規范引入了容器的概念，可以承載多個應用的運行，如圖2所示。

同時，JSR116所提出的容器的概念可以和HTTP容器想結合，開發一些基于Web的融合SIP應用。此外，JSR32規范和JSR116規范相比的另一個差別是，JSR32所定義的JAIN SIP規范是面向J2SE應用的，而JSR116所定義的SIP Servlet規范則是面向J2EE應用的。

其次，我們來看基于JCP系列規范開發的應用與基于Parlay規范開發的應用的運行模式。從應用的部署和運行模式的角度來看，Parlay/Parlay X是基于分布式技術來實現的，所以應用的運行也是一種分布式的模式。而基于JCC、JAIN SIP和SIP Servlet規范開發的應用，API的實現和應用由同一個Java虛擬機來執行，物理上是捆綁在一起的。

二者的差別如圖3所示。

從圖3也可以看出，基于JSR系列規范的應用在部署時，是直接和核心網網元對接的，二者之間的接口是標準的SS7或SIP；而基于Parlay/Parlay X規范開發的應用，在部署的時候，是以IIOP/SOAP協議與Parlay/Parlay X網關對接，再由Parlay/Parlay X網關轉換為標準的SS7或SIP協議。

相比而言，分布式的部署方式肯定要優于集成的應用模式。但是，分布式部署方式的缺點在于，開發人員除了熟悉基本的呼叫信令知識之外，還需要掌握Corba或Web服務等技術，在一定程度上提高了對開發人員的要求。

同時，JCP系列規范(JCC、JAIN SIP和SIP Servlet)僅僅定義的只是應用功能開發的接口，不涉及應用的鑒權接入和訪問控制等功能，所以它只能適用于一些可信域內的應用開發，而Parlay規范，不僅提供基本的呼叫能力，而且還提供了從應用鑒權接入、訪問控制、生命周期管理等一個完整的應用開發、運行和管理的體系。特別地，Parlay X通過SOAP頭的擴展，也具備了業務接入和控制方面的一些基本功能。當然，任何事物都是具有兩面性的，簡單易用與靈活性之間通常是一種互斥的關系。

再次，從技術實現的角度講，JSR系列標準定義的是Java語言的API實現，它繼承了Java語言跨平臺的特征；而Parlay API的實現是基于Corba中間件技術的，它是一種跨平臺的技術，與操作系統和編程語言無關，即應用和服務可以運行不同的操作系統上，還可以以不同的編程語言來實現API的功能和調用。

Parlay X基于Web服務技術實現，具有更為優秀的開放性，可以用不同的編程語言來實現。對應用開發人員而言，跨平臺的、與語言無關的接口技術肯定更受人歡迎。

當然，對于各種不同的業務能力開放技術，不能簡單的說孰優孰劣，每一種技術都有自己的優勢，對于不同層次的業務開發人員，面對不同的業務需求，可以選用適合自己的技術來開發電信應用。

此外，我們再從API的封裝程度的角度對各個規范進行比較，如圖4所示。從較高的層次上講，可以將接口封裝分為兩類：操作級的API封裝和協議層的API封裝。其中，JCC和Parlay/Parlay X提供的是操作級的API，API的封裝程度比較高，API的實現與具體的協議無關；而JAIN SIP和SIP Servlet提供的是協議層的API，它們提供了針對SIP協議的API封裝，從某種程度上講，相當于提供了一個Java版本的SIP協議棧，相比之下，SIP Servlet提供的API比JAIN SIP規范中的API更為高級一些。對應用開發人員而言，封裝程度較高的接口技術更容易用來開發應用。

最后，從生命力的角度對各個規范做一比較，如圖5所示。JCP和Parlay兩個不同的組織所制定的規范一直還在發展之中，從目前的情況看，JCC和JAIN SIP規范，目前支持或積極響應的設備商并不多；而SIP Servlet產品，目前已經有多個廠商明確支持；支持Parlay/Parlay X的廠商比較多，其中，愛立信的Parlay GW產品應用最為廣泛。各個廠商對Parlay X的支持就更為普遍了。

所以，從總體上講，各個廠商對Parlay/Parlay X的支持要好于對JCP規范的支持。當然，JCP組織不僅在業務能力開放方面進行了研究，在業務執行環境方面也做了深入的研究工作，制定了JAIN SLEE等規范，該規范的制定，從另一方面又極大地促進了JCC、JAIN SIP等規范的發展和推廣，后面我們會對JAIN SLEE規范做專門的介紹。

6 結束語

從電信領域的發展趨勢來看，總的趨勢可以歸納為：從封閉走向開放，從開放走向融合。最初的電信網作為一個封閉的體系，到不斷地開放業務能力，不斷地融入并開放新的業務能力，到現在電信域和IT域開始走向融合，整個過程將使得電信網成為一個開放的、可聚合的和可持續擴展的基礎網絡體系。

從電信的業務能力開放技術，特別是接口技術的實現上，不同的接口提供了不同的實現技術，前面已經說過，從接口的封裝程度上講，封裝程度越高，基于接口的應用實現越容易；封裝程度越低，接口功能越靈活，基于接口的應用實現也越復雜。因而，對于不同的技術，我們并不能簡單地說孰優孰劣，而是要針對不同的需求和不同層次的應用開發人員，提供適合他們需要的業務接口開放，實現不同層次不同粒度的能力開放。

隨著業務能力的逐步開放，業務開發的周期不斷縮短，業務開發的群體不斷壯大，業務之間的耦合關系和交互作用越來越復雜，如何實現業務和業務、業務能力和業務能力、業務和業務能力之間的有序監控和管理就成為下一代基于分布式開放ICT融合環境的業務生成環境和執行環境的研究重點。

7 參考文獻

[1] 張云勇,劉韻潔,張智江,等. 下一代網絡業務開放的相關問題[J]. 電信科學，2004,20(1)：41-46 .

[2] 強磊,陳卉. NGN的統一業務開放平臺與增值業務的創新[J]. 中國數據通信,2004,6(5):71-74.

[3] 劉韻潔.下一代網絡的發展趨勢—融合與開放[J].電信科學,2005,21(2):5-10.

[4] FALCARIN P, LICCIARDI C A. Analysis of NGN service creation technologies[J]. IEC Annual Review of Communications, 2003,56(6):100-110.

[5] LICCIARDI C A, FALCARIN P. Next generation networks: The services offering standpoint[R].Eurescom Project P1109. 2002.

[6] LAGO P, LICCIARDI C A, CANAL G, et al. An architecture for IN-Internet hybrid services[J]. Computer Networks Journal, 2001, 35(5):537-549.

[7] BOETSELAARS L, et al. CD-ROM: Enabling technologies for IN-Internet integration[R]. Eurescom Project P909 Deliverable 4. 2001.

[8] 葉飛,傅海陽. CTI技術及其在現代通信中的應用[J].電子工程師, 2001,27(6): 36-38, 41.

[9] 張雪麗. 智能網標準概況[J].電信工程技術與標準化, 2004(1):34-38.

[10] JAIN. A set of JavaTM APIs for integrated networks[R]. Telcordia Technologies Inc. 1999.

[11] The JAIN APIs: Integrated network APIs for the Java platform[R/OL]. White Paper. 2000.[2008-12-11]. http://java.sun.com/products/jain.

[12] JSR21-JAIN Java call control (JCC) applicaiton programming interafce (API), Version 1.0[S]. JCP. 2001.

[13] ARANGO M, DUGAN A, HUITEMA C, et al. Media gateway control protocol (MGCP), Version 1.0[R]. RFC 2705.1999.

[14] ROSENBERG J, SCHULZRINNE H, CAMARILLO G, et al. SIP: Session initiation protocol[S]. RFC 3261. 2002.

[15] JSR32-JSIP API specification v1.2, Final release [S]. JCP. 2006.

[16] JSR116- SIP servlet API, Version 1.0 [S]. JCP. 2003.

[17] JSR289-SIP servlet specification v1.1, Final release [S]. JCP. 2008.

[18] JSR309-Java media server control [S]. JCP. 2008.

[19] JSR22-JAIN SLEE 1.0 specification, Final release [S]. JCP. 2004.

[20] ETSI ES 201 915-1 V1.1.1. Open service access; Application programming interface. Part 1-Part 12[S]. 2001.

[21] Parlay APIs 4.0: ParlayX Webservices[R]. White Paper. Parlay Group, 2002.

收稿日期：2008-12-11

楊勇，畢業于東南大學，現工作于入中興通訊股份有限公司。研究方向包括多媒體圖像、視頻處理技術、增值業務平臺等，先后從事智能網以及Parlay/ParlayX網關的研發工作。已發表論文多篇。學。現任中興通訊股份有限公司高級工程師，主要從事UMTS、LTE等無線通信系統的前沿技術研究工作。已發表論文5篇，提交專利2篇。

賈霞，碩士畢業于大連理工大學，現工作于中興通訊股份有限公司，負責下一代業務網絡預研。先后從事固定智能網業務、寬帶業務、IMS業務等開發和設計工作，研究方向為業務網絡，SDP、SOA、業務引擎、移動互聯網。已發表過業務網絡演進相關文章多篇。

董振江，碩士畢業于哈爾濱工業大學，現工作于中興通訊股份有限公司。先后從事交換機和智能網等開發、設計和規劃等工作，研究方向為SDP、P2P、業務引擎、3G業務和ICT等。參與和負責過多項國家發改委的技術課題，已發表過多篇增值業務相關文章。