專利名稱：一種交通管理數(shù)據(jù)交互方法及消息服務系統(tǒng)的制作方法
技術領域：
本發(fā)明涉及一種交通管理數(shù)據(jù)交互方法，特別涉及一種交通管理數(shù)據(jù)交互方法及 消息服務系統(tǒng)。
背景技術：
隨著時代的進步以及社會的發(fā)展，各城市的機動車保有量迅速增長，從而導致城 市、城際之間的交通矛盾日益突出。而城市交通是否通暢直接影響到城市的經(jīng)濟和發(fā)展，從 而解決交通問題迫在眉睫。要想快速有效的解決城市交通中的問題，就必須準確了解城市交通中涉及到的各 種交通元素，以及整個城市的交通狀況。而城市控制中的各數(shù)據(jù)源從空間上來說，分布在不 同的位置；從時間上來說，有歷史數(shù)據(jù)以及實時數(shù)據(jù)；從采集方式上，對各項數(shù)據(jù)的采集， 是分布在不同的系統(tǒng)中。要想把如此紛繁復雜的交通管理數(shù)據(jù)整合起來，進行快速分析定 位，就必須有一個性能良好的數(shù)據(jù)交互服務。目前在交通領域通常會利用設備對交通狀態(tài)做數(shù)據(jù)采集，這些交通狀態(tài)的數(shù)據(jù)包 括交通流數(shù)據(jù)，然后對這些數(shù)據(jù)進行分析，并將分析結(jié)果通過信息系統(tǒng)傳遞給用戶，這些信 息系統(tǒng)均采用Web Service訪問機制(見圖1)，ftp機制(圖2)，或消息隊列來實現(xiàn)各系 統(tǒng)之間的數(shù)據(jù)交互。數(shù)據(jù)的交互效率以及實時性、準確性受到了極大的限制。對于使用web Service進行數(shù)據(jù)交互的方式，數(shù)據(jù)的提供方將數(shù)據(jù)存儲到數(shù)據(jù)庫 或者其他存儲介質(zhì)后，數(shù)據(jù)的使用方并不能及時了解到這種情況，即時使用定期巡檢，也會 有一定的時延。對于利用ftp技術，進行數(shù)據(jù)交互的系統(tǒng)，也存在著實時性的局限性。采集端將數(shù) 據(jù)存儲到ftp文件夾下，使用端利用簡單的二次開發(fā)，可以獲取到ftp服務器的數(shù)據(jù)。這種 交互方式的優(yōu)勢是，不管使用方是否存在，提供方都可以將采集結(jié)果，存儲到相應的位置； 缺點就是，使用方無法第一時間了解所需的數(shù)據(jù)是否已經(jīng)到位，并得到所需的消息，因此， 實時性無法保證。對于現(xiàn)有的另外一種交互方式就是消息隊列(MQ)。消息交互方之間，利用消息 隊列提供的接口方法，向消息隊列存放數(shù)據(jù)或者將消息隊列中的消息發(fā)送給接收端，由于 消息隊列在發(fā)送消息時需要被指定接收端，當消息隊列中的消息被發(fā)送給接收端后，此消 息會被從消息隊列中刪除，因此對于一些未被指定的接收端而言，無法在第一時間接收到 服務器向外發(fā)出的消息，因此，消息隊列的實時性也仍然不夠。智能交通領域的優(yōu)化控制和預測，不僅僅需要在對現(xiàn)場的交通流數(shù)據(jù)進行及時的 采集和分析，而且需要將分析出的結(jié)果以最快速度傳遞給用戶，其消息傳遞的實時性顯得 尤為重要，而上述技術的應用會帶來一定的局限性，消息的實時性難以保證。
發(fā)明內(nèi)容
為此，本發(fā)明在于提出一種具有高實時性的一種交通管理數(shù)據(jù)交互方法及消息服
4務系統(tǒng)。因此，一種交通管理數(shù)據(jù)交互方法，包括以下步驟a)數(shù)據(jù)的采集數(shù)據(jù)采集子系統(tǒng)將實時采集到的交通流數(shù)據(jù)進行分析，并根據(jù)分析結(jié)果及時形成 交通消息發(fā)送給消息服務器；b)消息的接收消息服務器接收來自數(shù)據(jù)采集子系統(tǒng)的消息，所述消息包括交通消息和用于訂閱 所述交通消息的消息訂閱請求；c)消息的解析所述消息服務器對接收到的所述消息進行解析，將其中的所述消息訂閱請求進行 保存；d)消息的發(fā)送所述消息服務器根據(jù)所保存的所述消息訂閱請求，將隨后接收到的相應的被訂閱 的所述交通消息發(fā)送給訂閱該消息的客戶端。上述的交通管理數(shù)據(jù)交互方法，所述消息服務器對消息的處理為多線程處理。上述的交通管理數(shù)據(jù)交互方法，所述消息還包括用于取消訂閱所述交通消息的消 息取消訂閱請求，所述消息的解析包括如下處理方式i.判斷所述交通消息或所述客戶端消息的數(shù)據(jù)格式的合法性對為不合法數(shù)據(jù)格式的所述消息進行過濾，對為合法數(shù)據(jù)格式的所述消息進行進 一步的類型判別；ii.判別合法消息的類型如果被判別的消息類型為訂閱類型時，則加入消息訂閱列表；如果被判別的所述消息為取消訂閱類型時，則從所述消息訂閱列表中刪除相應的 消息訂閱請求。上述的交通管理數(shù)據(jù)交互方法，所述消息的發(fā)送是利用線程池的函數(shù)來創(chuàng)建發(fā)送 線程，將解析后的數(shù)據(jù)發(fā)送給相應的訂閱者。發(fā)送結(jié)束后，退出該線程。上述的交通管理數(shù)據(jù)交互方法，所述消息服務器對接收到的所述消息進行解析后 識別為必達性質(zhì)的必達信息時，將所述必達消息保存于所述消息服務器中；并將所述必達 消息發(fā)送給訂閱了所述必達消息的必達消息接收端；當所述服務器接收到了所述必達消息接收端的確認接收反饋時，所述服務器將被 保存的所述必達消息刪除；當所述服務器未接收到所述必達消息接收端的確認接收反饋時，所述服務器此后 將定期向所述必達消息接收端發(fā)送所述必達消息。一種采用上述任一交通管理數(shù)據(jù)交互方法的消息服務系統(tǒng)，包括至少一個數(shù)據(jù)采集子系統(tǒng)，每個所述數(shù)據(jù)采集子系統(tǒng)將采集到的交通流數(shù)據(jù)進行 分析，并根據(jù)分析結(jié)果及時形成消息進行轉(zhuǎn)發(fā)；消息服務器，與各所述數(shù)據(jù)采集子系統(tǒng)連接，通過消息訂閱的方式實時地將從所 述數(shù)據(jù)采集子系統(tǒng)處接收到的所述交通消息轉(zhuǎn)發(fā)給訂閱了此交通消息的客戶端。
5
上述的消息服務系統(tǒng)，所述消息服務器包括a.消息接收模塊所述消息接收模塊接收來自所述數(shù)據(jù)采集子系統(tǒng)的交通消息和來自客戶端的客 戶端消息；b.消息解析模塊所述消息解析模塊與所述消息接收模塊連接，對接收到的所述交通消息和來自客 戶端的客戶端消息進行解析，并將客戶端消息中的消息訂閱請求進行保存；c.消息發(fā)送模塊所述消息發(fā)送模塊與所述消息解析模塊連接，根據(jù)所保存的所述消息訂閱請求， 將隨后接收到的相應的被訂閱的所述交通消息發(fā)送給訂閱該消息的客戶端。上述的消息服務系統(tǒng)，所述數(shù)據(jù)采集子系統(tǒng)包括用于采集交通流數(shù)據(jù)的信號機， 和與所述信號機連接的用于對接收的所述交通流數(shù)據(jù)進行分析并形成交通消息進行轉(zhuǎn)發(fā) 的數(shù)據(jù)處理裝置。上述的消息服務系統(tǒng)，還包括一個所述消息發(fā)送模塊連接的消息必達模塊，所述 消息必達模塊接收和保存來自所述消息發(fā)送模塊的具有必達性質(zhì)的必達消息，并將所述必 達消息發(fā)送給訂閱了所述必達消息的必達消息接收端當所述服務器接收到了所述必達消息接收端的確認接收反饋時，所述消息必達模 塊將被保存的所述必達消息刪除；當所述服務器未接收到所述必達消息接收端的確認接收反饋時，所述消息必達模 塊此后將定期向所述必達消息接收端發(fā)送所述必達消息。上述的消息服務系統(tǒng)，又包括一個與所述消息發(fā)送模塊連接的消息日志模塊，所 述消息日志模塊用于對接收以及發(fā)送過程中的異常數(shù)據(jù)進行記錄，以便后期查詢。本發(fā)明具有以下優(yōu)點1.本消息服務系統(tǒng)通過數(shù)據(jù)采集子系統(tǒng)將采集到的交通流數(shù)據(jù)進行分析，并根據(jù) 分析結(jié)果及時形成消息轉(zhuǎn)發(fā)給消息服務器；消息服務器采用消息訂閱的方式對消息進行訂 閱，可以確保消息服務器在接收到由數(shù)據(jù)采集子系統(tǒng)發(fā)送來的所述交通消息后，立即將所 述交通消息發(fā)送給訂閱了該消息的接收客戶端，大大地提高了消息傳輸?shù)膶崟r性。2、采用多線程的消息處理方式可以確保同時發(fā)送和接收多條消息，提高了消息傳 輸?shù)膶崟r性。3、采用消息必達模塊可以確?？梢栽诒剡_消息沒有達到消息接收端時，可以定期 向所述消息接收端發(fā)送消息，直至服務器接到所述消息接收端發(fā)來的確認接收反饋。
為了使本發(fā)明的內(nèi)容更容易被清楚的理解，下面根據(jù)本發(fā)明的具體實施例并結(jié)合 附圖，對本發(fā)明作進一步詳細的說明。圖1是用于描述現(xiàn)有技術中，利用web service技術進行數(shù)據(jù)交互的框2是利用ftp技術進行數(shù)據(jù)交互的框圖；圖3是消息服務器架構(gòu)圖；圖4是具有消息必達模塊消息日志模塊的消息服務器架構(gòu)圖中箭頭代表和模塊的連接關系以及消息流向。
具體實施例方式實施例1如圖3所示，交通管理數(shù)據(jù)交互方法的消息服務系統(tǒng)，包括數(shù)據(jù)采集子系統(tǒng)Si，每個所述數(shù)據(jù)采集子系統(tǒng)將采集到的交通流數(shù)據(jù)進行分析， 并根據(jù)分析結(jié)果及時形成交通消息進行轉(zhuǎn)發(fā)；其中，所述數(shù)據(jù)采集子系統(tǒng)由采集交通流數(shù) 據(jù)的信號機，和與所述信號機連接對采集到的所述交通流數(shù)據(jù)進行分析，并根據(jù)分析結(jié)果 形成消息進行轉(zhuǎn)發(fā)的數(shù)據(jù)處理裝置(此處未標出)。消息服務器，所述消息服務器分別與所述數(shù)據(jù)采集子系統(tǒng)Sl連接，并接收由所述 數(shù)據(jù)采集子系統(tǒng)Sl發(fā)送來的所述交通消息消息和由客戶端Rl發(fā)送來的客戶端消息，所述 客戶端消息包括訂閱所述交通消息的消息訂閱請求和消息訂閱所述交通消息的消息取消 訂閱請求；所述消息服務器具體包括消息接收模塊，所述消息接收模塊接收來自數(shù)據(jù)采集 子系統(tǒng)Si的交通消息，用于訂閱所述交通消息的消息訂閱請求，以及用于取消訂閱所述交 通消息的消息取消訂閱請求；消息解析模塊，所述消息解析模塊與所述消息接收模塊連接，對接收到的所述交 通消息或所述客戶端消息進行解析i.判斷消息的數(shù)據(jù)格式的合法性對為不合法數(shù)據(jù)格式(數(shù)據(jù)格式不為XML)的所述消息進行過濾，對為合法數(shù)據(jù)格 式(格式為XML)的所述消息進行進一步的類型判別；ii.判別合法消息的類型當消息格式為XML格式時，如果被判別的所述消息的元素名為“subscription” 時，如下所示< ？ xml version = 1·0\〃 encoding = \〃 GB2312\〃 ？ >〈subscription System = \〃 ATMS\〃 Ver = \" 1·0\〃 >則視為消息訂閱請求，并將其加入消息訂閱列表；如果被判別的所述消息的元素名為“unsubscription”時，如下所示< ？ xml version = 1·0\〃 encoding = \〃 GB2312\〃 ？ >〈unsubscription System = \"ATMS\〃 Ver = \" 1·0\〃 >
<messagetype> 路況信息 </messagetype> <sourceIP>106. 108. 1. 20</sourceIP> <user>Rl</user> </subscription)
<systemtype> 子系統(tǒng)類型 </systemtype> <messagetype> 路況信息 </messagetype> <sourceIP>106. 108. 1. 21</sourceIP>
<user>R2</user> </unsubscription>
7
則從所述消息訂閱列表中刪除相應的消息訂閱請求。如果被判別的所述消息的元素名為“message”時，則如下所示< ？ xml version = 1·0\〃 encoding = \"GB2312\〃 ？ >〈message System = \"ATMS\〃 Ver = \" 1·0\〃 ><messagetype> 路況信息 </messagetype><sourceIP>106. 108. 1. 23</sourceIP><messagecontent> 前方路況良好 </messagecontent></message>則送往發(fā)送模塊。本實施例中假設首先由客戶端Rl發(fā)送了元素名為‘‘subscription”的消息給消息 服務器，此后，由數(shù)據(jù)采集子系統(tǒng)Sl發(fā)送了元素名為“message”的交通消息給消息服務器。a)消息發(fā)送模塊所述消息發(fā)送模塊與所述消息解析模塊連接，所述消息發(fā)送模塊根據(jù)接收到的所 述交通消息“messagetype”屬性下的消息類型，本實施例為“路況信息”，從已保存的消息訂 閱請求中找出其“messagetype”屬性也為“路況信息”的消息訂閱請求(本實施例以Rl發(fā) 送的消息訂閱請求為例)，然后，根據(jù)該消息訂閱請求中“sourcelP”的IP地址(本實施例 Rl的IP地址為“106. 108. 1. 20”)作為消息接收端的IP地址，將該交通消息發(fā)送給該交通 消息的接收端Rl。本實施例中，消息服務器對消息的處理為多線程處理方式，每個與所述消息服務 器連接的所述客戶端，有一個獨立的消息處理線程，用于發(fā)送和接收消息。所述消息的發(fā)送 是利用線程池的函數(shù)來創(chuàng)建發(fā)送線程，將解析后的數(shù)據(jù)發(fā)送給相應的訂閱者，發(fā)送結(jié)束后， 退出該線程。實施例2本實施例與實施例1的區(qū)別在于客戶端Rl與消息服務器建立連接后，消息服務 器為其分配句柄hi ；客戶端Rl發(fā)送了一條消息訂閱請求給消息服務器，訂閱路況信息，消 息服務器將客戶端Rl的所述消息訂閱請求和客戶端Rl的句柄hi加入訂閱列表中。此后，采數(shù)據(jù)采集子系統(tǒng)Sl與消息服務器建立連接，消息服務器為其分配句柄 h2 ；采數(shù)據(jù)采集子系統(tǒng)Sl向消息服務器發(fā)送了一條“messagetype”屬性為“路況信息”的 交通消息后，消息服務器對該消息進行解析，并與訂閱列表比對，找到了訂閱此消息的句柄 hi，之后通過發(fā)送模塊，使用hl，發(fā)送給了客戶端R1。完成一次消息流轉(zhuǎn)。實施例3如圖4所示，本實施例與實施例1的區(qū)別在于所述消息服務器還包括一個與所述 消息發(fā)送模塊連接的消息必達模塊，所述消息解釋模塊對接收到的消息進行解釋，當識別 消息為合法的XML格式的消息后，對其消息的類型進行判別。當接收到的消息的元素名為 “message”時，判斷為交通消息，當該交通消息中具有“forcemission”屬性時，則判斷為具 有必達性質(zhì)的必達消息，如下所示< ？ xml version = 1·0\〃 encoding = \〃 GB2312\〃 ？ >〈message System = \〃 ATMS\〃 Ver = \" 1·0\〃 ><messagetype> 報警信息 </messagetype>
<sourceIP>106. 108. 1. 23</sourceIP> <targetIP>106. 108. 1. 21</targetIP> <forcemission>10</forcemission>
<user>Sl</user> <messagecontent> 路況報警 </messagecontent> </message>并將所述必達消息通過消息發(fā)送模塊傳送給所述消息必達模塊進行保存。所述消息發(fā)送模塊根據(jù)其“targetIP”屬性中的IP地址“ 106. 108. 1. 21 ”，將該必 達消息發(fā)送給IP地址為“106. 108. 1. 21”的接收客戶端，(本實施例以R2為必達消息的接 收客戶端為例)，當所述客戶端R2接收到該必達消息后，給于消息服務器一個確認接收反 饋，所述消息服務器通過所述消息發(fā)送模塊將所述確認接收反饋送至所述消息必達模塊， 所述消息必達模塊接到到所述確認接收反饋后將被保存的所述必達消息刪除。如果所述消 息服務器未接收到所述確認接收反饋時，所述消息必達模塊將自動根據(jù)地“forcemission” 屬性中的次數(shù)定期向客戶端R2發(fā)送所述必達消息，直至接收到所述確認接收反饋為止。 (本實施例的重發(fā)次數(shù)為10次)所述消息服務器又包括一個分別與所述消息接收模塊，所述消息解釋模塊，所述 消息發(fā)送模塊連接的消息日志模塊，所述消息日志模塊用于對接收以及發(fā)送過程中的異常 數(shù)據(jù)進行記錄，以便后期查詢。顯然，上述實施例僅僅是為清楚地說明所作的舉例，而并非對實施方式的限定。對 于所屬領域的普通技術人員來說，在上述說明的基礎上還可以根據(jù)設備的大小不同做出其 它不同形式的變化或變動。這里無需也無法對所有的實施方式予以窮舉。而由此所引伸出 的顯而易見的變化或變動仍處于本發(fā)明創(chuàng)造的保護范圍之中。
9
權(quán)利要求
一種交通管理數(shù)據(jù)交互方法，其特征在于包括以下步驟a)數(shù)據(jù)的采集數(shù)據(jù)采集子系統(tǒng)將采集到的交通流數(shù)據(jù)進行分析，并根據(jù)分析結(jié)果及時形成交通消息發(fā)送給消息服務器；b)消息的接收消息服務器接收來自所述數(shù)據(jù)采集子系統(tǒng)的交通消息和來自客戶端的客戶端消息，其中所述客戶端消息包括訂閱所述交通消息的消息訂閱請求；c)消息的解析所述消息服務器對接收到的所述交通消息或所述消息訂閱請求進行解析，將其中的所述消息訂閱請求進行保存；d)消息的發(fā)送所述消息服務器根據(jù)所保存的所述消息訂閱請求，將隨后接收到的相應的被訂閱的所述交通消息發(fā)送給訂閱該消息的客戶端。
2.根據(jù)權(quán)利要求1所述的交通管理數(shù)據(jù)交互方法，其特征在于 所述消息服務器對消息的處理為多線程處理。
3.根據(jù)權(quán)利要求2所述的交通管理數(shù)據(jù)交互方法，其特征在于所述客戶端消息還包括用于取消訂閱所述交通消息的消息取消訂閱請求，所述消息的解析包括如下處理方式i.判斷所述交通消息或所述客戶端消息數(shù)據(jù)格式的合法性對為不合法數(shù)據(jù)格式的所述交通消息和所述客戶端消息進行過濾，對為合法數(shù)據(jù)格式 的所述交通消息和所述客戶端消息進行進一步的類型判別； .判別合法消息的類型如果被判別的消息類型為訂閱類型時，則加入消息訂閱列表； 如果被判別的所述消息為取消訂閱類型時，則從所述消息訂閱列表中刪除相應的消息 訂閱請求。
4.根據(jù)權(quán)利要求1-3任一所述的交通管理數(shù)據(jù)交互方法，其特征在于所述消息服務器對接收到的所述交通消息進行解析后識別為必達性質(zhì)的必達信息時， 將所述必達消息保存于所述消息服務器中；并將所述必達消息發(fā)送給訂閱了所述必達消息 的必達消息接收端；當所述服務器接收到了所述必達消息接收端的確認接收反饋時，所述服務器將被保存 的所述必達消息刪除；當所述服務器未接收到所述必達消息接收端的確認接收反饋時，所述服務器此后將定 期向所述必達消息接收端發(fā)送所述必達消息。
5.一種采用權(quán)利要求1-4中任一交通管理數(shù)據(jù)交互方法的消息服務系統(tǒng)，其特征在 于包括至少一個數(shù)據(jù)采集子系統(tǒng)，每個所述數(shù)據(jù)采集子系統(tǒng)將采集到的交通流數(shù)據(jù)進行分 析，并根據(jù)分析結(jié)果及時形成交通消息進行轉(zhuǎn)發(fā)；消息服務器，與各所述數(shù)據(jù)采集子系統(tǒng)連接，通過消息訂閱的方式實時地將從所述數(shù) 據(jù)采集子系統(tǒng)處接收到的所述交通消息轉(zhuǎn)發(fā)給訂閱了此交通消息的客戶端。
6.根據(jù)權(quán)利要求5所述的消息服務系統(tǒng)，其特征在于所述消息服務器包括a.消息接收模塊所述消息接收模塊接收來自所述數(shù)據(jù)采集子系統(tǒng)的交通消息和來自客戶端的客戶端 消息；b.消息解析模塊所述消息解析模塊與所述消息接收模塊連接，對接收到的所述交通消息和來自客戶端 的客戶端消息進行解析，并將客戶端消息中的消息訂閱請求進行保存；c.消息發(fā)送模塊所述消息發(fā)送模塊與所述消息解析模塊連接，根據(jù)所保存的所述消息訂閱請求，將隨 后接收到的相應的被訂閱的所述交通消息發(fā)送給訂閱該消息的客戶端。
7.根據(jù)權(quán)利要求6所述的消息服務系統(tǒng)，其特征在于所述數(shù)據(jù)采集子系統(tǒng)包括用于 采集交通流數(shù)據(jù)的信號機，和與所述信號機連接的用于對接收的所述交通流數(shù)據(jù)進行分析 并形成交通消息進行轉(zhuǎn)發(fā)的數(shù)據(jù)處理裝置。
8.根據(jù)權(quán)利要求7所述的消息服務系統(tǒng)，其特征在于還包括一個所述消息發(fā)送模塊 連接的消息必達模塊，所述消息必達模塊接收和保存來自所述消息發(fā)送模塊的具有必達性 質(zhì)的必達消息，并將所述必達消息發(fā)送給訂閱了所述必達消息的必達消息接收端當所述服務器接收到了所述必達消息接收端的確認接收反饋時，所述消息必達模塊將 被保存的所述必達消息刪除；當所述服務器未接收到所述必達消息接收端的確認接收反饋時，所述消息必達模塊此 后將定期向所述必達消息接收端發(fā)送所述必達消息。
9.根據(jù)權(quán)利要求8所述的消息服務系統(tǒng)，其特征在于又包括一個與所述消息發(fā)送模 塊連接的消息日志模塊，所述消息日志模塊用于對接收以及發(fā)送過程中的異常數(shù)據(jù)進行記 錄，以便后期查詢。
全文摘要
一種交通管理數(shù)據(jù)交互方法及消息服務系統(tǒng)，包括以下步驟a)數(shù)據(jù)采集子系統(tǒng)將實時采集到的交通流數(shù)據(jù)進行分析，并根據(jù)分析結(jié)果及時形成交通消息發(fā)送給消息服務器；b)消息服務器接收來自數(shù)據(jù)采集子系統(tǒng)的消息，所述消息包括交通消息和用于訂閱所述交通消息的消息訂閱請求；c)所述消息服務器對接收到的所述消息進行解析，將其中的所述消息訂閱請求進行保存；d)所述消息服務器根據(jù)所保存的所述消息訂閱請求，將隨后接收到的相應的被訂閱的所述交通消息發(fā)送給訂閱該消息的客戶端。
文檔編號H04L12/58GK101902412SQ20101021978
公開日2010年12月1日 申請日期2010年6月28日 優(yōu)先權(quán)日2010年6月28日
發(fā)明者宋波, 張秀梅, 林擁軍, 甄愛武 申請人:北京易華錄信息技術股份有限公司