基于XML的北京軌道交通信息交換平臺研究

杜軒軒，劉 云

（北京交通大學 通信與信息系統北京市重點實驗室，北京 100044）

經過多年的建設，北京軌道交通信息化建設基本覆蓋了各專業業務，形成了網絡化運營的格局，但也存在不足，主要表現在以下3個方面：

（1）信息共享程度低

盡管各業務系統間存在著大量的信息交互，但由于缺乏統一、規范的信息交互機制，各信息系統之間無法實現數據資源的共享，導致業務信息難以實現高效的綜合處理，各信息系統之間難以聯系協調、共同發揮作用，使得數據處理、分析及報表管理分散，造成重復和缺失。

（2）各系統之間聯動性差

軌道交通運輸系統本身就是一個“車、機、工、電、輛”組成的聯動機，各業務系統間存在著業務聯動關系。例如，在火災情況下，防災報警信號會傳到各系統，觸發各系統的聯動模式，FAS (防災報警) 系統、ATC (信號與通信) 系統、BAS (環境與設備監控) 系統、AFC (自動售檢票) 系統、PIS（乘客信息顯示）系統等多個系統應協調工作。但現有的信息系統彼此孤立、異域異構、缺乏統一接口規范，它們之間的連通比較困難且成本較高，各系統操作員只能了解本專業所關心的系統狀態，難以及時獲知其它專業的狀態。目前，為實現運營的協調統一管理，不得不加入人工干預，這極大降低了可靠性、實時響應性和運營效率。

（3）各子系統缺乏統一的標準

各業務信息系統都采用不同的軟硬件平臺，人機交互界面多種多樣，信息交互接口也不統一。給系統間信息交互和共享帶來極大困難，嚴重影響了信息的充分利用以及綜合決策水平。

（4）缺少與外部相關系統的接口

城市軌道交通作為綜合交通系統的一個重要組成部分，與道路公共交通、鐵路、航空等存在著大量的數據交換需求，但現有的信息系統未考慮到對外接口需求，這對城市軌道交通系統的長遠發展十分不利。

以上的問題與北京作為首都的地位和建設現代國際城市的要求是不匹配的，所以基于以上的考慮，很有必要建立一個北京城市軌道交通的數據交換平臺，整合各個信息系統的數據資源，為北京城市軌道交通的發展提供有力的保障，從而推動整個北京的城市建設。

1 本平臺涉及到的關鍵技術

1.1 數據交換的理想中間格式XML

XML表示可擴展標記語言，是一種高度結構性的、具有自我數據描述功能以及可驗證性的語言。XML有一套規則使用戶可以自己定義標記和屬性，這些標記和屬性可以構成一些標準，用戶可以按照這些標準來開發應用程序，因而具有很好的擴展性。

由于可以借助驗證規則來規范一個XML文件的內容與結構，保證XML文檔的有效性，同時XML是非專有的并易于閱讀和編寫，就使得它成為在不同的應用間交換數據的理想格式。更重要的是，現在的系統多半使用關系型數據庫，如Oracle，SQLServer等，XML以上的特點以及其本身突出表現數據結構和語義的特點，使其自然地與數據庫結合在一起。一旦將XML數據文件與數據庫表關聯起來，不但可以保留關系數據庫表的結構信息，還可以利用XML文檔的優勢在網絡及數據庫間交換數據，并解決不同數據庫系統及數據關系、語義定義等數據表達方面的差異，如對應關系中字段內容不同、字段命名不同、數據類型不同等。這將較好地解決企業應用系統間信息源集成的分布和異構等問題，使得數據交換的手段更為高效。

1.2 XML文檔查詢語言Xquery

Xquery即XML Query，是W3C所制定的一套標準，用來從類XML文檔中提取信息，類XML文檔可以理解成一切符合XML數據模型和接口的實體，他們可能是文件或RDBMS。Xquery是查詢XML的語言，類似于RDBMS的SQL，目前主流的RDBMS如Oracle, DB2, SQLServer都支持Xquery。本平臺即利用Xquery在已注冊的系統中查詢用戶所請求的數據。

1.3 JMS

JMS是消息隊列服務（Java Message Service）的簡稱，用來在2個應用系統之間或是分布式系統之間發送消息。不同于傳統的面向消息的中間件（MOM）。JMS定義了統一的API，所以它的實現與具體的廠商無關，更有利于產品移植。通常情況下，JMS包括3部分內容：2個JMS客戶端和1個JMS服務器。

JMS客戶端是使用JMSAPI發送和接受消息的應用程序，JMS服務器是任何實現JMS規范的應用程序或者應用程序的一部分。JMS客戶端通過JMS服務器發送消息以進行通信。主要有2種通信方式：

（1）點對點模式（Point-to-Point）

消息生產客戶端向一個特定的隊列發送消息，然后消息消費客戶端從該隊列獲取信息，如果消費客戶端沒有從該隊列獲取信息，該信息將一直保留在隊列中，直至消費客戶端取走信息或該信息過期，所以在該模式下，通信以消息被取走而結束，客戶端和消費端不需要同時處于運行狀態，只有一個消費者能獲取信息。本平臺使用的就是第一種模式。

（2）發布者/訂閱者模型（Pub/Sub模式）

發布者向一個特定的消息主體發布消息，所有對該主題感興趣的訂閱者都可接收該消息，所以這種模式類似于匿名公告板，多個消費者可獲得消息。發布者與訂閱者存在時間差上的依賴性，發布者必須首先建立一個訂閱，以便訂閱者訂閱，除非訂閱者建立了持久的訂閱，否則訂閱者必須保持持續的活動狀態以接受消息。

2 本平臺功能模塊及整體設計

本系統可分為4個模塊，接入模塊，交換模塊，基礎服務管理模塊，消息路由模塊，如圖1。

2.1 接入模塊

處理應用信息系統的接入，主要功能是實現系統和平臺之間的數據讀寫。對于新建的系統比較簡單，利用java語言跨平臺的優勢，只需要按照規定實現一個可實現數據讀寫功能的接口即可接入平臺；對于已有系統，改寫系統代碼的代價比較大，解決的辦法是采用接入新系統的方法搭建一個適配器，由適配器來代替已有系統與平臺交互。

圖1 北京軌道交通數據交換平臺框架結構

2.2 基礎服務管理模塊

基礎服務管理模塊包括系統注冊模塊，事務管理模塊，日志管理模塊。系統注冊模塊負責整個系統的安全和授權部分，每個系統必須在平臺注冊并且得到平臺的同意響應后才能通過平臺和其它系統進行數據交換；事務管理模塊保證信息交互過程中的事務安全機制；日志管理模塊通過控制臺、文件和數據庫3種方式記錄平臺信息交互的日志，以備日后查詢分析。

2.3 交換模塊

交換模塊是整個平臺的核心部分，是異構數據交換的處理部分，以層次化的結構來組織。主要包括服務層、協議支持層和數據格式轉換引擎。

（1）服務層完成信息系統的接入服務，提供平臺自身的數據庫服務，該數據庫主要存放系統日志、消息隊列相關持久化信息，保證交換平臺運行過程中需要持久化的信息能夠正常存儲，與各個接入信息系統不發生關系。本層還可以部署其它服務，這個視系統的復雜性可進行后期擴展。

（2）數據協議層提供軌道交通信息交換平臺上需要交換的各種數據協議支持服務。服務層完成系統的接入后，將各個信息系統發送的JMS消息傳送到本層，本層通過解析消息的相關記錄，可得到該消息交換的數據所采用協議。通過判定協議后，即調用對應數據協議的交換處理模塊處理該信息交換任務。

（3）數據格式轉換引擎的功能主要是為了實現不同數據格式的轉換。轉換是基于數據內容的，也就是保持了原有的數據內容不變，只是將其外在的表現形勢做了轉換。各種數據格式之間轉換的中間格式為XML，即平臺先將待轉換格式轉化為XML格式，然后再將XML格式轉化為目的格式。

2.4 消息路由模塊

消息路由模塊位于平臺框架結構的最底層，負責處理各個系統的互達路由，保證系統信息正常到達指定系統。整個交換中使用的信息格式需要進一步研究符合要求的統一的數據交換規范。該層提供信息系統數據流的路由配置和實現。比如一個數據流由系統A發出（文本格式），經過系統B（XML格式），最終到達系統C（Html）。就可以在系統配置文件里添加一條路由，表示整條數據路徑。平臺路由模塊啟動時，就能加載這些配置好的路由信息，在系統運行時，只要有符合條件的數據流，系統就會按照配置的路由來傳送數據到目的系統。

3 系統消息分類和信息交換流程

3.1 消息分類

本平臺的數據交換需要系統平臺之間發送各種消息，這些消息的傳遞是通過中間件Jms規范的一種實現OpenJMS來完成的，目前主要發送的消息有：

（1）注冊消息（Registration Request）；

（2）注冊相應消息（Registration Response）；

（3）請求消息（Data Request）；

（4）請求響應消息（Data Response）。

以上消息的消息體均為XML格式，并且滿足各自的標準規范。

3.2 交換信息流程

（1）注冊流程

A系統要加入平臺進行數據交換，必須先進行注冊，獲得平臺的授權。A系統向平臺的Registration Buffer隊列發送注冊請求（Registration Request），平臺從RegistrationBuffer獲得注冊請求并進行解析，若經驗證A系統合法，則向Registration Response Buffer隊列發送成功的注冊響應，包括A系統的注冊有效，目前平臺中已注冊的系統列表。否則發送失敗的注冊請求響應，包含注冊失敗的原因。A系統從Registration Response Buffer獲得注冊請求響應，若注冊成功，則可開始進行數據交換。

（2）數據交換流程

現在A系統需要西直門地鐵站的涵洞數據，A系統將其請求封裝在請求消息（Data Request）中，發送到平臺的Request Buffer隊列，平臺從該隊列獲得請求消息并進行解析，然后在已注冊的系統中進行查詢，發現B和C系統含A系統所請求的數據。平臺分別向B和C的接收隊列（Receiver- BuffrFor X）轉發A的數據請求，B和C從各自的接受隊列獲得數據請求后，查詢各自系統，將查詢到的數據封裝在各自的請求響應消息中，發送到各自的發送隊列（Sender BuffrForX）。平臺從B和C的發送隊列中獲取數據，封裝成數據請求響應，并轉化為A系統的數據格式，發送到A系統的接受隊列（Receiver Buffer ForA），A系統從該隊列中獲取請求的數據。

4 結束語

本平臺數據交換的實現基于XML這一網絡“通用語言”，充分利用了XML可拓展，易組織，自描述性的特點；利用Jms作為系統之間傳遞消息的中間件，由于Jms定義了統一的接口，所以它的具體實現與應用程序是沒有關系的。所以使用該平臺對應用系統的侵入性很小，系統只需按照規定實現一個可實現數據讀寫功能的接口就可以使用該交換平臺。該平臺目前正在開發中，不過前期的測試表明該平臺能夠很好的完成異構數據的交換功能，而且具備上述與應用系統之間的松耦合的特點。相信隨著本平臺的開發完成，一定能夠克服現在北京軌道交通決策分析信息單一，各系統無法共享信息的問題，很好的服務北京市軌道交通的發展。

[1]張麗華. 基于XML的異構數據交換技術研究[J]．蘇州科技學院學報（工程技術版），2010，23（2）：77-80．

[2]金 廣. 校園異構數據集成平臺研究[J]. 湖南科技學院學報，2009，30（12）.

[3]時貴英，呂洪濤. 可擴展異構數據交換系統的研究及實現[J]. 長江大學學報（理工卷），2009（2）：217-218.

[4]張曉玲，劉洪基. 分布式異構數據交換和共享系統的設計和實現[J]. 楚雄師范學院學學報，2009，24（6）：1-5．

[5]魏曉東. 城市軌道交通自動化系統與技術[M]. 北京：電子工業出版社，2004.

[6]張振江，劉 云. 北京城軌交通信息交換平臺的研究[J]. 交通運輸系統工程與信息，2006，6（5）：129-132.

[7]羅玉玲. J2EE應用開發詳解[M]. 北京：電子工業出版社，2009.