基于SOA的新聞文稿管理系統的應用研究

張 敏，趙 英，關俊玲，蘭建龍

（1.四川大學 公共管理學院，四川 成都 610064；2.四川農業大學 商學院，四川 成都 611830）

信息時代的廣播電視媒體對計算機技術應用提出越來越高的要求，處于核心業務支持地位的新聞制作、播出等管理系統必須能夠對新業務和新技術提供支持，不斷地擴展其業務服務形式，從業務上支持需求的多樣性，更多地滿足人們個性化的需求。新聞綜合業務管理系統主要是立足于新聞網絡制播的業務管理，涵蓋了新聞前期的信息采集和通稿制作管理、業務管理和數據存儲、流程監控等，簡單來講，它就是把新聞采集和通稿制作、新聞編播、新聞內容管理和新聞網絡制播監控四大系統中需要交互的業務以及相關的公共的業務流程來進行統一的管理和調度，形成一個核心業務管理平臺，同時其還要向各個系統提供相應的接口服務，從而來完成整個新聞節目從最初的資料收集到最終形成新聞播出的業務流程一體化管理。

當前的新聞業務管理系統，技術上沿用原有的J2EE架構的B/S模式，并在ESB總線的基礎上，基于面向服務架構建立相互協作的工作平臺相關核心組件，能夠協助電視臺用戶全方位管理生產資源，并通過辦公協同來提升業務便捷性，進而達到提高生產效率的目的。

1 新聞綜合業務管理系統

現階段的新聞業務管理系統基本上都是計算機服務商來提供，研究發現，目前面向服務的體系架構至少在60%的企業中被作為了其IT系統基本架構的方法[1-3]。而將面向服務體系架構（簡稱為SOA）的核心思想應用于新聞業務管理系統的系統構建過程的研究將具有十分重要的現實意義[4-5]。SOA在本質上支持將業務構件和技術構件轉換成一組服務組合或可重用的業務任務，而不管是什么樣的系統平臺和編程語言來完成的，在需要時只須訪問這些服務和任務并對來自各個地方的服務進行組合。

新聞業務管理系統作為一個以新聞生產管理為主體的業務管理平臺，涵蓋了新聞策劃、人員組織、資源調度、流程監控、考核統計以及信息、安全等方面的管理業務[6-8]。基于面向服務的架構實現步驟和應該遵循的原則，新聞綜合業務管理系統的基于面向服務架構的系統功能結構如圖1所示。

2 新聞文稿管理業務

文稿管理是新聞綜合業務管理系統眾多功能模塊之一，對于基于面向服務架構（SOA）的系統，它對架構思想的體現是十分全面的。新聞文稿的制作一般是從線索的匯聚開始，到信息挖掘、選題產生，然后再根據具體的內容生成文稿，最后進入編播的串聯單這樣一個流程。因為各個臺新聞文稿的應用差異并不是很大，所以它的通用性比較強。文稿管理依照SOA服務的劃分原則以及服務的低耦合、完整性等的要求，本身也可以被看作是一個組合服務，也可以被其他服務調用、組合來共同完成更復雜的業務功能。

2.1 文稿管理中的業務流程

中文稿創建、文稿編輯、文稿查詢、文稿審批、文稿刪除和查看處理記錄構成了文稿管理主要的業務功能。其大致的業務流程如下：首先新建文稿（這里要進行新建權限的判斷），如果有新建權限，則創建文稿并保存文稿，進行文稿提交；對于已提交的文稿，可以對其進行編輯、修改保存，重新提交，如果是編稿本人，則可以對自己保存提交的文稿進行修改編輯；對于已經確定的文稿，編稿本人可以查看自己的文稿或者是對其他有權限的文稿，同時可以將已經確定的文稿送審，等待審批；審批人擁有審批權限，可以根據不同級別的審批權限來進行多次審查；最后通過審批的文稿就被送入到串聯單管理模塊，審批不通過的則被打回，重新執行上述整個業務操作。至此，文稿管理的業務操作就完成了。

文稿管理業務流程圖如圖2所示。

2.2 文稿管理模塊的服務分析

依照對文稿管理的業務分析，按照面向服務架構服務劃分原則，對文稿管理模塊進行服務劃分。

首先，把該模塊的業務功能封裝成1-新建文稿、2-編輯文稿、3-查詢文稿、4-刪除文稿、5-審批文稿、6查看文稿處理記錄等6個獨立的粗粒度服務。

其次，進一步分析抽象，把新建、查詢、編輯、刪除和審批進行更細粒度的服務劃分，把前4個封裝為4個基本服務，而審批本身是個組合功能，所以繼續細分為11-審批流程創建、12-審批流程數據定義、13-審批流程。這樣以來，就可以實現多級審批的自定義配置。同時，由于還需要對整個文稿管理的操作進行監控，所以還應該有一個存儲業務操作處理情況的服務。

至此，在進行整體系統開發時，不同的系統業務模塊就可以采取傳入不同的配置參數來動態組裝基本服務的形式，完成其具體的業務流程功能；特別需要指出的是，為了適應業務個性化需求，在審批業務模塊中，把審批流程單獨分離出來，使其具體的實現細節和執行內容相分離，達到了靈活配置的效果。在調用審批服務時，不同的業務模塊只需要傳入自己的業務類型標識即可啟動相應的審批服務，整個審批過程對用戶來說都是透明的。

圖3顯示了文稿管理模塊的服務關系網絡。

在圖3中，每個結點都代表一個服務，每條線表示當一個服務執行完以后要轉向下一個服務所應該滿足的條件和下一個服務需要的參數來源，同一個結點出來的射線所表示的條件是不會相交的。

完成了服務粗細粒度的劃分，弄清了服務之間的關系，接下來就將這些服務進行發布和注冊，使其成為可復用的SOA服務，以方便在需要的時候調用。當然，在發布服務之前，還應該進行一系列的檢查來確保分析沒有錯誤，發布的服務合乎服務標準。

2.3 文稿管理模塊的服務發布與注冊

這里選用Xfire進行相關服務的發布工作。因為它可以將服務首先描述為POJO接口，然后進行適當的配置，實現發布服務。以審批服務為例，主要作用是輸入一個編輯完成的文稿進行多級審批，并將審批結果返回供其他的服務模塊使用。

在Eclipse galio中創建一個Web服務項目，此時，在根目錄下就會有一個名為WEB SERVICE的文件夾，在實現服務接口以及服務類后，還需要在這個文件夾的services.xml文件中進行配置，從而加入新發布的服務。

先用Java語言來描述這個服務接口，代碼如下：

在進行參數處理時，采用的是使每個模塊需要傳遞的參數以在后臺管理中單獨配置的形式存在，封裝在相應的一個類文件中，例如文稿模塊的參數信息封裝在public class docMsgService extends AbstractMessagePipe-Adapter中，方便對其進行統一管理。

接下來，為這些服務接口創建實現類，并實現接口中定義的方法。現在服務的實現部分已經完成，接著就是在上文中提到的services.xml文件中進行相關信息配置，使發布的服務生效：

該配置文件中描述了服務的名稱、命名空間、實現接口類等信息。到此，審批服務就發布成功了，通過網絡即可訪問到該服務，對其進行組合調用。對服務進行發布后，服務請求者就可以對服務進行訪問了，并進行服務注冊，把已經發布的服務在公共的或者私有的UDDI注冊中心注冊，從而供不同的使用者方便查詢和發現服務。通過把服務注冊到服務數據庫中，服務請求者能方便地對現存的服務進行查找，并獲得其相應的描述信息（WSDL），將服務進行注冊也有利于服務的管理和編排。考慮到系統良好的擴展性以及高效性，引入了企業服務總線對服務的注冊進行統一管理，加快了服務之間交互訪問的速度，提高了工作效率。至此，服務發布和注冊都已完畢，接下來在實際的操作過程中進行服務組合的測試。

2.4 文稿管理模塊的服務測試

模塊服務發布和注冊完成后，還需要對整個模塊的功能進行測試，以保證在實際的生產環境中各種業務需求得到滿足，并把因為開發因素導致的故障可能性降到最低。圖4為系統功能模塊測試的基本流程。

以下為針對文稿管理模塊服務接口進行的壓力測試，包括新建、查詢、提交、審批等業務接口，詳細設計了測試方案與用例，并按用例逐個完成測試，而且在重要的業務接口中多次重復執行測試，以保存測試結果的準確性。本文中選用成熟的性能測試工具loadrunner9.0英文版作為壓力機，通過并發進行接口數據傳遞，同時調整傳遞數據大小形成不同的壓力，觀察并記錄響應時間和模擬用戶數，同時監控服務接口服務器系統資源變化。

部分測試用例如下：

1）創建文稿用例。模擬100個用戶，每5 s加載20個用戶，通過集合點控制所有用戶到達后并發執行接口數據傳遞，迭代3次，超時設置為300 s。

2）查詢文稿用例。（1）模擬100個用戶，每5 s加載20個用戶，通過集合點控制所有用戶到達后并發執行接口數據傳遞，迭代3次，超時設置為300 s，每個用戶傳遞參數ScriptID不一樣，共需300個docid號；（2）模擬100個用戶，每5 s加載20個用戶，通過集合點控制所有用戶到達后并發執行接口數據傳遞，迭代3次，超時設置為300 s，傳遞參數PageSize設為200。

3）文稿合成提交用例。模擬100個用戶，每5 s加載20個用戶，通過集合點控制所有用戶到達后并發執行接口數據傳遞，迭代3次，超時設置為300 s，每個用戶傳遞參數ScriptID不一樣，共需300個docid號。

從以上結果記錄中可知，創建、提交業務模擬用戶與成功用戶之比100%，所有請求都成功，同時事務（發送參數與接收返回結果）平均響應時間也較低，100個并發用戶執行都小于2.5 s，并接口服務器資源消耗較小，該部分的接口性能符合設計要求，完全滿足用戶需求。

查詢業務接口中，業務接口模擬的用戶成功執行，各種性能指標穩定、正常，按預定的結果返回，從目前測試的結果可知，該部分的接口也正確、穩定。但由于返回結果條數較少，沒有更多的被測試數據，所以無法測試接口的極限值（最大返回條數）。但在測試查詢文稿接口時，當接口服務器返回條數（用戶數×返回條數）超過35 000條時就會報錯，也就是說該接口的最大返回極限條數為35 000條。

2.5 文稿管理模塊前端設計

基于面向服務架構的思想，業務功能的實現被劃分成了幾個部分：前端應用程序、服務總線、業務服務和后臺服務。當后臺服務和業務服務設計完畢之后，作為SOA架構中比較活躍的元素應用程序前端，則因為服務總線和統一接口定義語言的存在對進行非常靈活的設計，而且采用多種方式實現。

文稿管理模塊GUI的實現界面可以分為前臺管理界面和后臺服務界面兩部分。在前臺管理服務中，通過將一些基本服務進行組合形成文稿編輯、查詢等一系列工作，然后通過前臺管理調用后臺管理中的“審批”服務來完成文稿管理中的審批服務。具體的審批信息配置都是通過后臺服務來完成的。發送請求時不必關心流程具體實現細節，而只需要關注是否返回審批結果即可。在本模塊的開發中，采用面向服務的方式，很好的實現了執行內容和

4）文稿送審提交。模擬100個用戶，每5 s加載20個用戶，通過集合點控制所有用戶到達后并發執行接口數據傳遞，迭代3次，超時設置為300 s，每個用戶傳遞參數ScriptID不一樣，共需300個docid號。

測試結果部分記錄如表1所示。執行流程的分離，提高了系統對業務靈活性等的支持。

3 總結

表1 測試結果表

新聞業務管理系統作為一個綜合管理平臺，其系統的業務功能主要是依據這些相關的所要管理的子業務來確定。新聞文稿管理作為新聞業務重要的一環，在實現過程中充分體現了新聞業務管理系統的特點。本文采用面向服務架構（SOA）的思想實現新聞文稿管理功能，在對業務需求流程進行詳細分析的基礎上，對服務進行劃分，發布和注冊，并完成了模塊功能的測試。通過制定統一的接口，實現各個業務之間的松散耦合、規范開放的互聯互通，以提高新聞業務管理水平，對于整個新聞綜合業務管理系統的實現具有積極的作用。

：

[1]王斌，田野，章云.廣電企業業務流程的分析與優化[J].電視技術，2007，31（7）：59-61.

[2]馮細光，劉建勛.WEB服務測試技術綜述[J].微計算機應用，2010，31（1）：21-26.

[3]郎大為.基于語義Web服務的服務組合與匹配算法研究[D].大連：大連理工大學，2006.

[4]李軍.采用SOA的廣電臺內網應用集成技術設計與實踐[J].現代電子技術，2008（2）：41-43.

[5]DANG G，CHENG Z，JIN S，et al.A service-oriented architecture for tele-immersion[C]//Proc.2005 IEEE International Conference on e-Technology，e-Commerce and e-Service.Hong Kong，China：IEEE Press，2005：646-649.

[6]劉大軍.廣播電視臺綜合業務網的功能與實現[J].廣播與電視技術，2002，29（10）：119-121.

[7]孫林記，張潔霞，冒衛.全臺網系統中的業務流程設計[J].廣播電視信息，2009（1）：94-97.

[8]李友.基于Internet網的新聞交換和新聞異地采訪[J].電視技術，2011，35（4）：26-27.