首頁 > 由于消費興趣不斷推陳出新，運營商不得不考慮提高自身的提供豐富個性化業(yè)務的能力，而不是在某項具體業(yè)務過多投資。因此，高效的新業(yè)務開發(fā)成為實現(xiàn)個性化通信消費產(chǎn)品的系統(tǒng)集成項目的關鍵要素。而新業(yè)務的上市時間（TTM）的重要性也日益突出。
作為下一代融合網(wǎng)絡的核心，IMS標準和IMS技術一直廣受業(yè)界關注。關于IMS技術的優(yōu)點有很多，其中對應用層開放而靈活的標準接口一直是其中的亮點之一。下面，我們一起來看一下，基于IMS 機制和開放接口，如何靈活地組合出各種多媒體新業(yè)務，愛立信研究人員又做過哪些技術開發(fā)。
IMS中的SIP Servlet容器
讓我們先假想一個實際的應用例子，把基于IMS的IPTV與呈現(xiàn)（Presence）驅(qū)動的聊天應用組合在一起。一個名叫Shelley的用戶在家中想讓她的朋友通過呈現(xiàn)業(yè)務（Presence）知道自己正在看一檔選秀節(jié)目，從而可以一邊看節(jié)目，一邊跟同時在看此節(jié)目的朋友聊天評論這些選秀明星。
實現(xiàn)此功能的傳統(tǒng)方法必須修改IPTV設備（例如：機頂盒），使其能夠向呈現(xiàn)服務器發(fā)送SIP PUBLISH消息，然后由該服務器通知Shelley的朋友。修改IPTV設備所需要的工作會嚴重影響該業(yè)務的上市時間，從而影響對消費興趣的吸引，最終影響到商業(yè)機遇。不僅僅如此，更改接收選臺信息的IPTV控制器還會提高實體的復雜性。
那么，有沒有一種辦法，能夠僅僅通過修改IMS 網(wǎng)絡端的配置來將這兩種已有業(yè)務組合起來呢？
JSR 289草案中定義的SIP Servlet容器可以容納和管理SIP應用程序，同時通過Java API提供對會話發(fā)起協(xié)議（SIP）機制的訪問。
Java EE是電信業(yè)使用的可擴展中間件平臺。Java EE應用服務器（AS）是用于部署SIP Servlet容器的平臺。AS提供收發(fā)SIP請求與響應的網(wǎng)絡服務。
IMS中的AS通過IMS服務器控件接口（ISC）連接到提供服務的呼叫會話控制功能模塊（CSCF）。CSCF發(fā)起的SIP請求被轉(zhuǎn)發(fā)到容器，容器通過查詢稱為應用路由器（AR）的實體來識別相關SIP應用，然后把請求分配到所選擇的SIP應用服務器。只要SIP應用不終止請求，則容器會再次向AR查詢下一個調(diào)用的SIP應用。
通過在SIP路由報頭加入路由信息（與到IMS應用服務器的CSCF路由大同小異），應用路由器也可以指示容器把請求路由到部署在另一臺服務器上的SIP應用。
IMS業(yè)務組合引擎
愛立信的研究人員定義并且實現(xiàn)了一種業(yè)務組合引擎，其采用AR接口在運行時間為容器提供SIP路由決策——動態(tài)SIP路由。該引擎根據(jù)以下幾方面的數(shù)據(jù)來算出路由決策：
- 組合引擎的狀態(tài)；
所實現(xiàn)的算法是基于事件，并且由數(shù)據(jù)驅(qū)動的，而并非采用WS-BPEL中面向進程的方法。在WS-BPEL中，進程活動是其核心關注點，而并不明確對事件的支持。支持會話、基于事件的模式與呼叫控制中的信令能方便進行直接關聯(lián)，在組合實時通信方面更加自然、更加靈活。因此，現(xiàn)有面向進程、與Web服務相關的技術（如：WS-BPEL）不適用于組合SIP業(yè)務。
該算法以業(yè)務屬性以及控制業(yè)務屬性的約束條件為中心，根據(jù)事件和執(zhí)行環(huán)境的狀態(tài)，動態(tài)建立和路由SIP會話。上面提到的約束條件，一般是指業(yè)務交互方式和它們的相關性。
對組成業(yè)務的描述都保存在業(yè)務數(shù)據(jù)庫中，業(yè)務數(shù)據(jù)庫將其提供給SIP業(yè)務組合引擎。利用組合模板和約束條件，組合算法可以在數(shù)據(jù)庫中搜索需要添加到組合業(yè)務中的下一個組成業(yè)務。這種在運行中動態(tài)選擇具體組成業(yè)務的方法稱為后期綁定。此方法支持松散耦合，從而大大提高組合業(yè)務里各種組成業(yè)務構建的靈活性。
該算法能夠通過在建立的會話中逐個添加組成業(yè)務（每個業(yè)務都滿足全部約束條件）而構建組合業(yè)務。只要在業(yè)務模型中預先定義了它們的相關性，這種方式還可以實現(xiàn)對互動業(yè)務的管理。
核心組合邏輯適用于多種技術和協(xié)議。因此，組合引擎并不僅限于SIP業(yè)務。例如，Web服務調(diào)用就可以用于查詢外部實體，以便做出路由決策或者執(zhí)行SDP（Service Delivery Platform）業(yè)務流程，如：計費或用戶統(tǒng)計信息收集。
此外，提供SIP業(yè)務的SIP應用也可以部署在不同的應用服務器上。此情況下，組合引嬋梢圓捎肁R接口添加指向另一臺應用服務器的SIP路由。如果組合引擎需要在另一臺應用服務器完成處理之后把SIP請求返回到當前應用服務器，則可以添加指向自身的SIP消息。當然，另一臺應用服務器也可以保留在標準SIP路由路徑中。
在該SIP業(yè)務組合引擎中，用于業(yè)務組合的業(yè)務創(chuàng)建環(huán)境是基于Eclipse的圖形化業(yè)務創(chuàng)建環(huán)境。此環(huán)境通過提供用于定義業(yè)務描述與約束條件的視圖來支持業(yè)務組合，同時支持把組成業(yè)務組合到組合模板上的圖形化編輯器。在圖形化編輯器上完成相應組合后，組合引擎就開始部署和執(zhí)行了。
該圖形化界面還允許用戶監(jiān)控正在運行的組合業(yè)務以及檢查保存在組合引擎中的所有狀態(tài)信息。此外，用戶也可以通過設置斷點以及在調(diào)試模式下執(zhí)行自定義的組合業(yè)務，來驗證和糾錯。
這種圖形化表現(xiàn)形式和模塊化方法，能夠大大縮短組合業(yè)務的定制時間，讓用戶把精力集中在應用邏輯上，而非源代碼的細節(jié)上。另一方面，功能的模塊化整潔封裝，還可以簡化開發(fā)組成業(yè)務的應用設計人員的工作，實現(xiàn)任務與能力的分離（設計SIP應用是一項任務，而組合SIP業(yè)務是另一項任務）。
部署示例
讓我們接著前面提到過的應用實例，看看通過該業(yè)務組合引擎，如何把IMS IPTV和呈現(xiàn)業(yè)務（Presence）驅(qū)動的聊天應用組合起來。
通過正確匹配iFC，CSCF將把部署業(yè)務組合引擎的AS連接到IPTV SIP會話中。隨后，CSCF再連接到IPTV控制器。在Shelley選臺時，組合引擎會截取攜帶選臺信息的SIP消息。組合引擎（根據(jù)相應策略）決定是否在IPTV SIP會話中包含狀態(tài)呈現(xiàn)網(wǎng)絡代理（PNA）。如果包含PNA，則組合引擎執(zhí)行該PNA，后者把含有選臺信息的SIP PUBLISH消息發(fā)送到呈現(xiàn)服務器。
組合引擎能夠以逐個會話為基礎，做出有關組成業(yè)務的、詳細的、與上下文相關的決策。示例表明，我們可以根據(jù)業(yè)務組合，定制和擴展IMS應用的業(yè)務邏輯，而無需實際更改產(chǎn)品及其源代碼。
針對狀態(tài)呈現(xiàn)信息的發(fā)布這個例子，其實是可以定義不同類型的策略（如：基于位置的策略）。這些策略并非硬編碼，而是在IPTV會話建立過程中由組合引擎動態(tài)評估的，每個用戶都可以有不同的配置組合策略。更新現(xiàn)有策略或者定義新策略，也無需修改呈現(xiàn)擴展組合模板。用戶（Shelley）甚至可以通過訪問web門戶，來修改自己的業(yè)務組合策略，在建立下一個會話時，這些策略修改將會自動被組合引擎執(zhí)行。
只有當用戶位于家中時，該策略才會被選中執(zhí)行。在成功評估相關策略之后，呈現(xiàn)擴展組合模板即把PNAHandler成分添加到SIP業(yè)務鏈中。
總結(jié)
愛立信是JSR 289標準組織中的重要成員，該組織一直在致力于應用路由器（AR）與Java EE SIP Servlet容器間接口的標準化，而此Java EE SIP Servlet容器正是負責控制SIP實體按順序加入SIP會話的應用服務器。
愛立信研究人員通過實際的開發(fā)已經(jīng)證明，可擴展的組合引擎能夠為IMS提供靈活的定制業(yè)務實現(xiàn)方式。
組合引擎利用數(shù)據(jù)驅(qū)動的算法，根據(jù)事件動態(tài)控制SIP會話建立。除了SIP信令中包含的信息，組合引擎還可以通過狀態(tài)、約束、外部數(shù)據(jù)（如：Web服務）以及SIP業(yè)務的形式化描述來做出有關SIP請求路由的上下文相關的決策。文中所介紹的機制支持松耦合，從而使組合業(yè)務具有比傳統(tǒng)方法開發(fā)的業(yè)務更高的適應性。
該業(yè)務組合機理，實現(xiàn)了任務與角色的分離：設計IMS應用是一項任務，而組合IMS業(yè)務又是另一項任務。通過讓用戶使用業(yè)務組合引擎的圖形化業(yè)務創(chuàng)建環(huán)境，將顯著縮短組合業(yè)務的開發(fā)時間，推動新業(yè)務盡快進入市場。
要想在此領域取得商業(yè)上的成功，業(yè)界在通用IMS應用框架（例如：API、SIP消息擴展、SIP業(yè)務形式化描述）的持續(xù)合作和共同遵守，是至關重要的因素。
