許 靜，牟 艷，秦江龍

(河海大學常州校區(qū)計算機與信息學院，常州 213022)

1 引言

綜合型運動會競賽信息系統(tǒng)結(jié)構(gòu)復雜，各子系統(tǒng)之間數(shù)據(jù)交流頻繁、數(shù)據(jù)交換需求量大且質(zhì)量要求高，如何及時將處于不同環(huán)境、不同系統(tǒng)平臺、格式各異的數(shù)據(jù)轉(zhuǎn)化為可透明訪問的共享信息，并將這些信息進行發(fā)布、交換、傳輸和共享，使“信息孤島”能夠互聯(lián)互通，是競賽信息系統(tǒng)開發(fā)中的重點和難點。

早期綜合型運動會普遍采用傳統(tǒng)交換方式(也稱專用方式)，針對每一個具體的系統(tǒng)，開發(fā)對方專用的交換接口，各系統(tǒng)采用網(wǎng)狀式的組網(wǎng)結(jié)構(gòu)。隨著綜合性運動會應用的增多，系統(tǒng)越來越復雜，這種交換方式的缺點越來越較明顯，主要表現(xiàn)在:接口太多，如果有N個系統(tǒng)，需要開發(fā)N*(N－1)個接口，工作量極大，耦合性太強，對數(shù)據(jù)交換的實現(xiàn)與維護困難［1］。

實現(xiàn)綜合型運動會競賽信息系統(tǒng)高效信息交換的一個行之有效的解決方案是建設競賽信息數(shù)據(jù)交換平臺，作為各子系統(tǒng)間信息交換的樞紐，提供信息交換服務。本文通過筆者參與設計開發(fā)的“第二十六屆世界大學生運動會賽事成績處理系統(tǒng)數(shù)據(jù)交換平臺(Data Exchange Manage，DXM，以下簡稱“DXM平臺”)”項目［2］，提出可管理、可配置的應用解決方案，剖析平臺系統(tǒng)的架構(gòu)、設計和實現(xiàn)。

2 系統(tǒng)概述

2.1 競賽信息系統(tǒng)與DXM平臺

綜合型運動會競賽信息系統(tǒng)以競賽信息服務為主要線索，其主要運作流程需要經(jīng)歷場館成績處理、綜合成績處理與競賽信息發(fā)布過程。其中場館成績處理作為競賽成績輸入系統(tǒng)，綜合成績系統(tǒng)作為競賽成績加工系統(tǒng)，信息發(fā)布作為競賽成績輸出系統(tǒng)，這些都分在競賽信息系統(tǒng)中分別對應于場館成績系統(tǒng)(Venue Result System，VRS)、中央成績系統(tǒng)(Central Result System，CRS)與信息發(fā)布系統(tǒng)(Information Distribution System，IDS)［3］。系統(tǒng)結(jié)構(gòu)負雜，系統(tǒng)間存在大量頻繁的數(shù)據(jù)交換。

作為各子系統(tǒng)之間信息交換的紐帶，DXM平臺通過競賽系統(tǒng)網(wǎng)絡，實現(xiàn)各子系統(tǒng)間的實時消息通信。VRS、CRS、IDS均作為消息通信終端(以下簡稱業(yè)務終端)，通過DXM平臺交換數(shù)據(jù)。DXM平臺接收到業(yè)務終端的消息后，根據(jù)預定義的消息分發(fā)策略，將消息分發(fā)到指定的業(yè)務終端。例如CRS向DXM平臺發(fā)送原始競賽信息，再由DXM平臺分發(fā)給VRS、IDS。VRS向 DXM平臺發(fā)送場館成績數(shù)據(jù)，由DXM平臺轉(zhuǎn)發(fā)給CRS進行綜合處理，轉(zhuǎn)發(fā)給IDS對外發(fā)布，系統(tǒng)間數(shù)據(jù)流如圖1所示。

圖1 競賽信息系統(tǒng)與DXM平臺關系圖

2.2 DXM平臺系統(tǒng)結(jié)構(gòu)

DXM平臺系統(tǒng)由分管理配置子系統(tǒng)、發(fā)中心子系統(tǒng)、業(yè)務終端接口系統(tǒng)、運行監(jiān)控子系統(tǒng)和DXM平臺數(shù)據(jù)庫組成，系統(tǒng)結(jié)構(gòu)如圖2所示。

圖2 DXM平臺系統(tǒng)結(jié)構(gòu)圖

DXM平臺數(shù)據(jù)庫用于存儲管理與系統(tǒng)通信交換相關的數(shù)據(jù)信息;管理配置子系統(tǒng)用于配置管理消息類別、業(yè)務終端類別、業(yè)務終端、分發(fā)路由、分發(fā)中心的相關信息以及分發(fā)中心子系統(tǒng)。

提供面向業(yè)務終端的主動連接和消息的自動重分發(fā)服務;業(yè)務終端接口系統(tǒng)提供消息發(fā)送、在線狀態(tài)變化和接收消息的接口服務，為各業(yè)務終端開發(fā)商提供透明的消息發(fā)送與接收服務;運行監(jiān)控子系統(tǒng)負責監(jiān)控各分發(fā)中心服務器的運行狀態(tài)及各業(yè)務終端的連接狀態(tài)，DXM平臺系統(tǒng)管理員可以通過運行監(jiān)控子系統(tǒng)實時地監(jiān)測、管理和控制各分發(fā)中心。

3 DXM平臺工作流程

在系統(tǒng)運行之前，由管理配置子系統(tǒng)完成對DXM平臺運行參數(shù)的初始化設置，主要是完成消息分發(fā)策略的配置，將配置保存于DXM平臺數(shù)據(jù)庫中，數(shù)據(jù)庫中還保存了各業(yè)務終端和分發(fā)中心的相關信息。當DXM平臺啟動后，分發(fā)中心讀取平臺數(shù)據(jù)庫中業(yè)務終端和分發(fā)路由表，通過各個業(yè)務終端的接口系統(tǒng)與各終端建立連接，此處的接口系統(tǒng)是利用在業(yè)務終端集成中間件的方式完成接入功能的。中間件對分發(fā)中心的建立請求作出響應，同時標識連接成功或者失敗，將事件記錄到消息日志中，存于平臺數(shù)據(jù)庫，若連接成功，則加載消息，啟動發(fā)送或接收流程，并判斷是否遍歷所有終端;若連接失敗，繼續(xù)連接業(yè)務終端，完成分發(fā)中心的啟動服務，分發(fā)中心繼續(xù)判斷業(yè)務終端在線，接收消息，收到數(shù)據(jù)包并且驗證后即解析消息類別，查找消息路由表確定消息接收終端列表，遍歷所有業(yè)務終端。若在線，即發(fā)送消息，否則緩存消息，遍歷完成后結(jié)束任務。同時將消息分發(fā)的時間記錄到日志文件中，保存在平臺數(shù)據(jù)庫中，而業(yè)務終端的消息收發(fā)事件保存在本地日志文件中。在DXM平臺運行過程中，運行監(jiān)控子系統(tǒng)與分發(fā)中心連接，負責監(jiān)控各分發(fā)中心服務器的運行狀態(tài)及各業(yè)務終端的連接狀態(tài)，控制分發(fā)中心與業(yè)務終端的連接，還可以讀取數(shù)據(jù)庫中的日志文件，查詢消息收發(fā)事件。

4 系統(tǒng)關鍵技術

為了保證系統(tǒng)的靈活性，采用靈活的參數(shù)配置，使DXM平臺適應于不同業(yè)務、不同需要、不同場合。由DXM平臺的技術支持人員使用平臺提供的路由配置功能完成，無須人工干預，無須進行任何額外開發(fā)工作，當分發(fā)策略改變時，只需要重新調(diào)整設置分發(fā)路由表，即可接入平臺進行數(shù)據(jù)交換，并且通過設置消息緩存隊列，實現(xiàn)消息的自動重發(fā)功能，保證了傳輸?shù)目煽啃浴?/p>

4.1 管理配置機制

管理配置子系統(tǒng)完成對DXM平臺運行參數(shù)的配置，關鍵是對比賽項目、消息類別、業(yè)務終端和分發(fā)策略的配置。

4.1.1 比賽的配置

通過對競賽項目信息的增加、刪除、修改等操作，負責體育競賽系統(tǒng)中比賽項目的維護。

4.1.2 消息類別的配置

消息類別是DXM平臺對消息進行分發(fā)策略的分類標準之一，它的合理設計，關系到DXM平臺和業(yè)務終端之間通信的效率問題。通過對消息類別進行增加、刪除、修改等操作，實時配置消息類別。

消息類別由類別編號和類別名稱區(qū)分，比如編號“M0011”代表“運動員及報項信息”，“M1011”代表賽事計劃。

4.1.3 業(yè)務終端的配置

通常將通信子系統(tǒng)進行分類，以方便進行分發(fā)策略的配置。通過對終端類別的增加、刪除、修改等操作，實時配置終端類別。業(yè)務終端類別也由類別編號和類別名稱區(qū)分，如分類CRS(中央成績)、VRS(場館成績)、INFO(信息發(fā)布)等類別。

4.1.4 分發(fā)策略的配置

管理配置最關鍵的就是實現(xiàn)消息分發(fā)路由的動態(tài)配置以滿足分發(fā)策略，使得系統(tǒng)有序的傳輸消息。DXM平臺根據(jù)消息類別與終端類別在不同的比賽項目中按照路由規(guī)則在各子系統(tǒng)中轉(zhuǎn)發(fā)消息。即比賽項目、消息類別、終端類別代碼共同決定消息分發(fā)的路由。當分發(fā)中心接收到業(yè)務終端發(fā)出的一條消息后，根據(jù)設定的消息類別、終端類別和比賽項目，計算出接收該條消息的合法業(yè)務終端隊列，即分發(fā)路由，其含義為哪些比賽項目的哪些消息會發(fā)送給哪些終端，然后將該消息發(fā)送到隊列中的各業(yè)務終端。

4.2 異步通信機制

DXM平臺為各子系統(tǒng)提供信息交換服務，要求其在數(shù)據(jù)通信中具有較高的可靠性，系統(tǒng)提供相應的保障機制，保障各子系統(tǒng)在數(shù)據(jù)交換中離線、網(wǎng)絡故障等情況下仍能保障數(shù)據(jù)信息不丟失，網(wǎng)絡通信恢復后仍能有效地傳輸數(shù)據(jù)。

基于這種可靠性要求，DXM平臺提供了異步通信服務。各業(yè)務終端離線時待發(fā)送的消息在本地緩存，待接收的消息在分發(fā)中心緩存，業(yè)務終端在線時DXM平臺自動完成消息的收發(fā)。業(yè)務終端與分發(fā)中心服務器均設置了本地緩存隊列，當網(wǎng)絡故障時，消息緩存在本地緩存隊列，待網(wǎng)絡恢復后，系統(tǒng)會自動載入緩存消息，向?qū)Ψ街鳈C發(fā)送。消息緩存隊列的工作分三個方面:

作為發(fā)送消息的業(yè)務終端，其消息緩存隊列接收用戶要發(fā)送的消息，放入發(fā)送隊列，由發(fā)送線程掃描隊列，隊列中有消息并且該發(fā)送終端與分發(fā)中心相連，則啟動發(fā)送該消息，發(fā)送成功則把消息從隊列中移除。

分發(fā)中心子系統(tǒng)，為與之相連的每個業(yè)務終端建立單獨的發(fā)送隊列，分發(fā)中心收到業(yè)務終端發(fā)送來的數(shù)據(jù)，檢查分發(fā)路由，將數(shù)據(jù)根據(jù)路由放入對應的接收終端隊列，再由各個終端的發(fā)送線程掃描各自的消息緩存隊列，發(fā)現(xiàn)有數(shù)據(jù)并且與對應的接收終端連接則發(fā)送數(shù)據(jù)，發(fā)送成功后從隊列中移除該數(shù)據(jù)。

作為接收消息的業(yè)務終端，只需要等待接收，作出響應。

緩存隊列的工作流程如圖3所示。

圖3 消息緩存隊列工作流程

如圖3所示，DXM平臺系統(tǒng)啟動服務后，不管是分發(fā)中心還是業(yè)務終端，作為發(fā)送方，都是將要發(fā)送的消息緩存在相應的緩存隊列中，由發(fā)送線程掃描隊列，請求連接合法后發(fā)送消息，如果連接失敗則繼續(xù)請求連接，同時遍歷緩存。若消息發(fā)送成功，則從緩存中清除該數(shù)據(jù)，當遍歷完成，即緩存中已無數(shù)據(jù)時，則結(jié)束線程，若消息發(fā)送失敗，則斷開連接，將發(fā)送失敗的消息存入緩存隊列，循環(huán)請求發(fā)送，直至緩存隊列清空。遍歷緩存延時30ms，這個時間既不影響系統(tǒng)的正常運行，還能保證緩存的消息及時處理掉。

5 DXM平臺設計與實現(xiàn)

5.1 分發(fā)中心子系統(tǒng)

分發(fā)中心子系統(tǒng)是整個DXM平臺的核心，它包括了以下功能:提供面向業(yè)務終端的主動連接和消息的自動化分發(fā)服務、根據(jù)業(yè)務終端信息自動加載業(yè)務終端、根據(jù)路由配置自動完成消息分發(fā)、消息接收方終端離線時提供本地緩存、在線時依次發(fā)送緩存消息。

分發(fā)中心啟動服務后，讀取DXM平臺數(shù)據(jù)庫，加載業(yè)務終端和消息路由，主動與業(yè)務終端集成的代理中間件連接，連接并且驗證成功后標識業(yè)務終端在線，若失敗，返回超時，標識業(yè)務終端離線，并重連。若業(yè)務終端在線，則加載消息，啟動發(fā)送消息流程，或者啟動接收消息流程，最后判斷是否遍歷所有業(yè)務終端，若沒有，繼續(xù)連接業(yè)務終端，完成啟動服務。啟動服務流程如圖4所示。

圖4 分發(fā)中心啟動服務流程圖

分發(fā)中心系統(tǒng)判斷業(yè)務終端在線，接收消息，收到數(shù)據(jù)包并且驗證后即解析消息類別，查找消息路由表確定消息接收終端列表，遍歷所有業(yè)務終端，若在線，即發(fā)送消息，否則緩存消息，遍歷完成后結(jié)束任務。分發(fā)中心接收消息及分發(fā)處理流程如圖5所示。

5.2 業(yè)務終端中間件

DXM平臺通過集成組件(即中間件)方式，封裝數(shù)據(jù)通信協(xié)議，這樣做提高了系統(tǒng)的可集成性，對外屏蔽了通信協(xié)議，提高了協(xié)議的安全性，同時還減少了各業(yè)務終端開發(fā)商的工作量。數(shù)據(jù)通信協(xié)議包含的事件有啟動、停止、服務狀態(tài)、發(fā)送、接收和服務狀態(tài)切換。各相關子系統(tǒng)通過中間件實現(xiàn)與DXM平臺的數(shù)據(jù)交換，協(xié)議給出數(shù)據(jù)包格式和命令格式及網(wǎng)絡中通信節(jié)點的信息，實現(xiàn)競賽信息的統(tǒng)一分發(fā)。協(xié)議結(jié)構(gòu)如表1所示。

圖5 接收消息及分發(fā)處理流程圖

表1 數(shù)據(jù)通信協(xié)議結(jié)構(gòu)

由表1所示，由標識碼判定是否是本系統(tǒng)需要處理的消息;命令碼確定對此條消息做何種操作，比如命令碼“101”表明是建立連接，若是“102”表明斷開連接;消息碼決定消息任務的類型，比如這條消息需要從VRS傳輸至CRS;唯一標識符記錄消息的事件，具有唯一性，可保存在日志中，以便查看;消息體長度決定數(shù)據(jù)參數(shù)的字符數(shù)組大小，比如消息體長度為1024B，數(shù)據(jù)參數(shù)的字符數(shù)組大小就是1KB，可見數(shù)據(jù)參數(shù)的大小是可變的。

消息發(fā)送模塊根據(jù)數(shù)據(jù)通信協(xié)議將消息打包成消息數(shù)據(jù)包，完成數(shù)據(jù)包的消息重組工作。消息包含消息頭和N個消息子包，消息頭定義內(nèi)容有消息開始標志、消息類型、壓縮標志、總包數(shù)、消息體長度(壓縮后)、數(shù)據(jù)消息類型、消息源類型、消息源關鍵字、大項代碼、消息標識號。消息子包定義內(nèi)容有子包開始標志、消息標識號、子包序號、子包大小、子包內(nèi)容。

業(yè)務終端中間件接收到分發(fā)中心的服務請求以后，啟動服務，連接成功后，發(fā)送/接收消息，通信完成后向宿主模塊拋出消息事件，服務始終記錄運行狀態(tài)和在線狀態(tài)變化報告，這些事件都保存在本地日志中，最后停止服務。

5.3 管理配置子系統(tǒng)

管理配置子系統(tǒng)由管理員完成對DXM平臺運行參數(shù)的配置，該子系統(tǒng)提供的功能有消息類別管理、業(yè)務終端類別管理、業(yè)務終端管理、消息分發(fā)路由管理和分發(fā)中心管理。

首先對比賽項目、消息類別、業(yè)務終端類別進行配置，組合三者計算出合理的消息分發(fā)路由，即哪些比賽項目的哪些消息會發(fā)送給哪些業(yè)務終端，還需要對分發(fā)負載(分發(fā)中心子系統(tǒng)正常運行時，連接的那些業(yè)務終端)進行相關通信參數(shù)的配置，以使分發(fā)中心與管理配置子系統(tǒng)協(xié)同運行。該子系統(tǒng)還設置了分發(fā)服務控制模塊，提供了對DXM平臺進行狀態(tài)監(jiān)控和消息分發(fā)的功能以及日志分析模塊，它對DXM平臺的各項指標進行分析監(jiān)控。

5.4 運行監(jiān)控子系統(tǒng)

運行監(jiān)控子系統(tǒng)負責監(jiān)控各分發(fā)中心服務器的運行狀態(tài)及各業(yè)務終端的連接狀態(tài)。DXM平臺系統(tǒng)管理員可以通過該子系統(tǒng)實時地監(jiān)測、管理和控制各分發(fā)中心。該子系統(tǒng)的客戶端與各分發(fā)中心通過中間件建立連接。

該子系統(tǒng)啟動后，讀取DXM平臺數(shù)據(jù)庫，查看DXM平臺有哪些分發(fā)中心及其詳細通信參數(shù)，以及分發(fā)負載的通信參數(shù)和狀態(tài)等，實時監(jiān)測各分發(fā)中心運行狀態(tài)和各業(yè)務終端連接狀態(tài)，控制分發(fā)中心與業(yè)務終端的連接，同時記錄監(jiān)控事件，保存于DXM平臺數(shù)據(jù)庫。

5.5 DXM平臺數(shù)據(jù)庫設計

DXM平臺數(shù)據(jù)庫用于存儲與管理系統(tǒng)通信交換相關的數(shù)據(jù)信息，系統(tǒng)采用集中式客戶機/服務器數(shù)據(jù)庫體系結(jié)構(gòu)。數(shù)所庫采用SQL Server 2005企業(yè)版數(shù)據(jù)庫系統(tǒng)，DXM平臺數(shù)據(jù)庫服務器使用Microsoft Windows 2003 Server(64)位操作系統(tǒng)。DXM平臺數(shù)據(jù)庫中存儲的數(shù)據(jù)表的內(nèi)容和作用如表2所示。

管理配置子系統(tǒng)的參數(shù)配置和各業(yè)務終端與分發(fā)中心的運行狀態(tài)和連接狀態(tài)變化事件都存儲在DXM平臺數(shù)據(jù)庫，而當各子系統(tǒng)啟動服務時，都需要從DXM平臺數(shù)據(jù)庫讀入相關數(shù)據(jù)。

5.6 系統(tǒng)物理架構(gòu)

VRS、CRS、IDS都通過集成中間件與分發(fā)中心通信，管理配置子系統(tǒng)管理消息類別、業(yè)務終端類別、業(yè)務終端、消息路由、分發(fā)中心的相關信息。運行監(jiān)控子系統(tǒng)實時監(jiān)測、管理和控制各分發(fā)中心。

表2 數(shù)據(jù)表簡介

業(yè)務終端應用軟件部署在場館端的服務器上，業(yè)務終端服務器每場館1臺。分發(fā)中心部署在中央成績系統(tǒng)的服務器上，分發(fā)中心服務器的數(shù)量需要根據(jù)實際運行負載、競賽計劃和各個項目的消息通信數(shù)據(jù)量進行合理、動態(tài)的設置。DXM平臺系統(tǒng)物理架構(gòu)如圖6所示。

圖6 DXM平臺系統(tǒng)物理架構(gòu)圖

6 DXM平臺系統(tǒng)運行測試及性能分析

6.1 壓力測試

2011年4月1日，在深圳龍崗26屆大運會集成測試實驗室舉行了壓力測試，共有大運會17個大項，203個小項參加，事前準備了這些小項的全部場館成績系統(tǒng)(VRS)數(shù)據(jù)。主要測試了DXM平臺與中央成績系統(tǒng)(CRS)和信息發(fā)布系統(tǒng)(IDS)之間的端到端數(shù)據(jù)聯(lián)通與交換情況，測試歷時1小時40分鐘，共交換XML消息24萬余條，無遺漏與錯發(fā)現(xiàn)象。

6.2 系統(tǒng)聯(lián)合演練

2011年7月，舉行了包括注冊報名系統(tǒng)(ACR)、場館成績系統(tǒng)(VRS)、中央成績系統(tǒng)(CRS)與信息發(fā)布系統(tǒng)(IDS)的全系統(tǒng)聯(lián)合演練，演練共進行3天，每天10小時，全部24個大項參加，每個大項均選擇了賽事最多的3個比賽日，每天通過DXM平臺交換XML消息4萬－7萬條，無遺漏與錯發(fā)現(xiàn)象。

6.3 正式比賽運行

2011年8月12日至23日，第26屆世界大學生夏季運動會在深圳舉行，賽事共設24個大項、306個小項，注冊國家和地區(qū)147個，注冊總?cè)藬?shù)11310人，其中運動員7587人，隨隊官員3723人。賽會歷時12天，每天通過DXM平臺交換XML消息2萬－4萬條，無遺漏與錯發(fā)現(xiàn)象，完成了大運會數(shù)據(jù)交換任務。

6.4 系統(tǒng)性能分析

根據(jù)上述測試結(jié)果的分析，通信平臺能夠支持交換的數(shù)據(jù)量遠大于實際比賽中的數(shù)據(jù)量，已能夠滿足綜合型運動會競賽數(shù)據(jù)交換平臺的性能要求，甚至可以應用于今后更大規(guī)模的運動會競賽系統(tǒng)中。

7 結(jié)束語

數(shù)據(jù)交換平臺的實現(xiàn)是獨立于各業(yè)務系統(tǒng)之外的，所以它并不影響各部門業(yè)務系統(tǒng)的運作，同時也能方便加入后續(xù)系統(tǒng)。數(shù)據(jù)交換平臺技術使業(yè)務系統(tǒng)具有較強的擴展性，可以支持數(shù)據(jù)導出系統(tǒng)以及決策支持系統(tǒng)等等的擴展。隨著XML技術的深入發(fā)展，必將使數(shù)據(jù)交換平臺功能更強大，更易于實現(xiàn)。

我們結(jié)合具體應用對數(shù)據(jù)交換平臺及數(shù)據(jù)交換的關鍵技術進行了分析和應用，目的是探討能夠有效支持數(shù)據(jù)共享，提高系統(tǒng)互操作性的數(shù)據(jù)模型設計。根據(jù)我們的工作，表明該DXM平臺的設計思路是成功有效的，能夠用于綜合型運動會競賽信息系統(tǒng)的數(shù)據(jù)模型設計。

隨著體育賽事信息化的深入，競賽信息系統(tǒng)之間的協(xié)作、業(yè)務往來以及參與合作的數(shù)量會越來越多，對通用數(shù)據(jù)交換平臺的要求會越來越高，因此，需要研究更多的理論和技術，來不斷地完善和發(fā)展它。

［1］陳向峰，陳東浩，方峻峰.面向服務的數(shù) 據(jù)交換平臺的研究與實現(xiàn)［J］.上海信息化，2006(8):69－71.

［2］2010深圳大運會通信平臺系統(tǒng)架構(gòu)［G］.國家體育總局體育信息中心，2010年9月8日.

［3］2010深圳大運會賽事成績系統(tǒng)技術方案［G］.國家體育總局體育信息中心，2009年12月18日.

［4］趙莉，杜思鋒.數(shù)據(jù)交換平臺中異構(gòu)數(shù)據(jù)轉(zhuǎn)換技術的研究［J］.電子設計工程，2011，19(5):91 －93.

［5］屠曉蕓.基于 Web Service數(shù)據(jù)交換的研究與實現(xiàn)［D］.北京:北京化工大學，2007.

［6］倪志剛，洪玫，劉佳.基于服務數(shù)據(jù)對象的異構(gòu)系統(tǒng)數(shù)據(jù)集成方案研究［J］.計算機應用，2007，27(6):21－23.

［7］BAKER F，F(xiàn)OSTER B，SHARP C.Cisco Systems，Cisco.Architecture for Lawful Intercept in IP Networks［S］.［S.l.］:Network Working Group，2004.

［8］David Campbell.Service Oriented Database Architecture;APP Service － Lite［J］.SIGMOD，2005:857－862.