引言
在智能交通行業(yè)中,傳統(tǒng)的短信平臺是以短信貓(GSM MODEM)技術實現(xiàn)對手機的短信發(fā)送達與接收,從而實現(xiàn)智能交通業(yè)務中的氣象預警信息、防污防臺信息、路網運行路政設施情況、突發(fā)事件信息等及時通知相關管理人員和維護人員。隨著網絡技術的不斷發(fā)展,移動、聯(lián)通、電信三大運營商已推出各自的短信網關接口用于企業(yè)級的短信平臺接入。智能交通行業(yè)的短信平臺需要在此基礎上根據各運營商的接口進行功能的升級和完善,以適應行業(yè)的發(fā)展需求。
關鍵技術介紹
短信網關
短信網關主要是解決各運營商之間短信互通和服務提供商(SP)的接入問題,同時完成計費采集、業(yè)務管理、網絡管理等功能。通過短信接口,可以將短信平臺與各種應用系統(tǒng)進行無縫高效對接,將應用系統(tǒng)產生的動態(tài)信息轉變成手機短信。傳統(tǒng)的短信貓技術(GSM MODEM)技術實現(xiàn)PC對手機收發(fā)信息,適合小項目的開發(fā)。直接接入運營商短信網關的方法實現(xiàn)不需要附加新的硬件,但是需要到運營商申請網關,適合于企業(yè)級的大型通信開發(fā),如向移動、聯(lián)通、電信等公司申請,使用起來比較方便。
Web Service
介紹 Web Service是一種輕量級的、獨立的、低耦合的通訊技術,它可以接收從其它系統(tǒng)中傳遞過來的各種請求。對于Web Service技術來說Web服務就是一個URL 資源,調用方可以通過編程方式請求得到它的服務,并且不需要知道所請求的服務內部機制是如何實現(xiàn)的。(Web Service體系結構如圖1所示)
▲圖1:Web Service的體系結構
通過SOAP在Web上提供的軟件服務,使用WSDL文件進行說明,并通過UDDI進行注冊。 SSH框架 SSH框架采用面向對象的分析方式將一些模型實現(xiàn)為java對象,然后編寫基本的DAO接口,并給出Hibernate的DAO實現(xiàn),采用Hibernate框架實現(xiàn)的DAO 類來實現(xiàn)java類與數(shù)據據之間的轉換和訪問,最后由 Spring管理Struts和Hibernate。
SSH框架
自上而下可以分為表示層、業(yè)務邏輯層、數(shù)據持久層和域模塊層四個層次。采用上述開發(fā)模型,不僅實現(xiàn)了視圖、控制器與模型的徹底分離,而且還實現(xiàn)了業(yè)務邏輯層與持久層的分離,大大提高了系統(tǒng)的可服務注冊中服務請求者服務提供者發(fā)布發(fā)現(xiàn)綁定復用性,提高了開發(fā)效率。
短信平臺總體設計
功能設計
通知短信提醒功能短信平臺可以與智能交通的交通監(jiān)控系統(tǒng)、設施設備運維系統(tǒng)等外部系統(tǒng)進行關聯(lián),當系統(tǒng)出現(xiàn)異常情況可通過用戶登記的手機號送相應的短信提示,及時通知監(jiān)控人員、運維人員,以便及時查看,大大提高了工作效率。短信發(fā)送功能 用戶可以通過相應帳號向在系統(tǒng)中已登記的手機 號發(fā)送短信。子功能包括:從組織結構樹選擇接收短信 的人員,定義接收短信子組。如根據監(jiān)控、運維、應急 等業(yè)務定義需要接收短信的短信子組。在短信發(fā)送時 可以選定后一次發(fā)送,同時可以查看短信發(fā)送內容和 條數(shù)等情況。短信自動分發(fā)功能 短信平臺對應移動、聯(lián)通和電信三個發(fā)送通道,可 根據接收手機號不同,自動將信息分發(fā)到相應的短信網 關。同時保留短信貓接口,當短信網關通訊出現(xiàn)異常時 可以使用短信貓接口作為備用接口。
總體架構設計
▲圖2:短信平臺的整體架構
短信平臺的整體設計決定了系統(tǒng)的健壯性和易用性。本架構采用基于java語言的SSH框架架構技術,自上而下可以分為應用層、接口層、協(xié)議層、數(shù)據層和接入層五個層次: 應用層:監(jiān)控系統(tǒng)、運維系統(tǒng)、日常管理以及其它 在信息化建設過程中上線的各種應用都可以實現(xiàn)信息發(fā) 送通知和短信提醒的功能。雖然系統(tǒng)架構和所采用編程 語言可能有所不同,但是采用Web Service接口技術可以很好的實現(xiàn)這些異構系統(tǒng)與短信平臺的無縫對接。接口層:短信平臺采用B/S架構,用戶可以統(tǒng)一登錄到短信平臺。第三方的應用程序則通過Web Service接口接入至短信平臺。協(xié)議層:SMS(短信服務)協(xié)議主要用來處理文本、數(shù)字或二進制非文本數(shù)據為主,對于長度超過140 字節(jié)的短信自動拆分,然后分別發(fā)送,接收端接收后拼接還原為長短信。MMS(多媒體信息服務)協(xié)議主要用來處理多媒體短信的發(fā)送,包括視頻、圖片、聲音和文字等。數(shù)據層:數(shù)據層是整個短信平臺的核心模塊,為其他層次提供數(shù)據庫支持。數(shù)據主要包括用戶數(shù)據、短信數(shù)據和匯總統(tǒng)計數(shù)據,同時還可以用來存儲短信發(fā)送、接收和定制情況等。接入層:目前國內各大電信運營商在短信網關的通信上分別制定了不同的協(xié)議,例如:EMPP協(xié)議(移動)、SGIP協(xié)議(聯(lián)通)、SMGP協(xié)議(電信)。不同運營商用戶分別連接不同的運營商網關,接入層主要的工作是實現(xiàn)各短信運營商短信網關的對接,由于每一家短信運營商的短信接入協(xié)議并不相同,因此在接入層按照短信運營商劃分為移動、聯(lián)通、電信接入模塊。同時保留短信貓模塊,當與運營商網關通訊出現(xiàn)異常時,可通過短信貓進行信息發(fā)送。
關鍵模塊的實現(xiàn)
短信平臺整體功能強大,具體多個功能模塊。平臺采用J2EE技術開發(fā),整體架構采用SSH框架和Oracle數(shù)據庫技術。開發(fā)環(huán)境使用Myeclipse實現(xiàn)部署。關鍵模 短信管理監(jiān)控系統(tǒng)運維系統(tǒng) 日常管理應用層HTTP接口Web Service接口接口層其它應用短信中心通訊錄通訊記錄管理用戶管理SMS協(xié)議MMS協(xié)議協(xié)議層數(shù)據庫接口數(shù)據層移動接入模塊接入層 移動接入模塊 移動接入模塊 短信貓接入模塊主要包括移動、聯(lián)通、電信三家主流運營商的接口實 現(xiàn)。
基于EMPP協(xié)議實現(xiàn)移動運營商短信的發(fā)送 EMPP是上海移動制定的企業(yè)短信通平臺接口協(xié)議,版本為V2.0。它規(guī)定了上海移動企業(yè)短信通業(yè)務客戶接入的消息類型和定義,規(guī)定了EP(使用短信平臺發(fā)送短信的企業(yè)客戶端)與ESMP(企業(yè)短信平臺)之間短信收發(fā)接口協(xié)議的內容,適用于各EP的開發(fā)廠商。EMPP協(xié)議主要提供以下兩類業(yè)務操作:短信接收和短信發(fā)送。協(xié)議以TCP/IP作為底層通信承載。企業(yè)端可以在一個TCP連接上可以連續(xù)發(fā)送多個數(shù)據包,在TCP連接保持期間,如果沒有數(shù)據包發(fā)送,需要雙方發(fā)鏈路檢測包以維持此連接。通信雙方以客戶-服務器方式建立TCP連接,用于雙方信息的相互提交。當信道上沒有數(shù)據傳輸時,通信雙方應每隔時間C發(fā)送鏈路檢測包以維持此連接,當鏈路檢測包發(fā)出超過時間T后未收到響應,應立即再發(fā)送鏈路檢測包,再連續(xù)發(fā)送N-1次后仍未得到響應則斷開此連接。在EP與ESMP之間發(fā)送短信時采用異步方式,即客戶端在發(fā)送一條短信后不必等待服務器端的響應即可再次發(fā)送短信。
▲圖3:EP與ESMP交互過程中的應答方式
基于SGIP協(xié)議實現(xiàn)聯(lián)通運營商短信的發(fā)送 SGIP是中國聯(lián)通制定的短消息網關系統(tǒng)接口協(xié)議(,版本為V1.2。協(xié)議所描述的短消息網關接口協(xié)議,用于完成在SMG(聯(lián)通公司的短消息網關)和SP(服務提供商)之間、SMG和SMG之間短消息的發(fā)送、接收和轉發(fā)功能,以及SMG和GNS之間路由表的同步功能。 SMG是具有短消息轉發(fā)功能的短消息網關。全國可以有多個SMG網關,SMG網關之間通過互聯(lián)網等方式實現(xiàn)網絡互聯(lián)。每一個SMG同時與多個SMSC以及多個SP連接。全網具有唯一有效的GNS,GNS負責全局路由表的維護與更新;為了確保路由表存儲的安全性,網絡中設置主備用GNS,兩個GNS要保持一致性。每一個 SMG都和GNS連接。SMG與SP、SMG與GNS以及SMG與 SMG之間的通信協(xié)議為SGIP協(xié)議。SMG與SMSC之間的通信統(tǒng)一采用SMPP3.3協(xié)議。
▲圖4:SMG的體系結構
SGIP有兩種具體實現(xiàn)方式,一種是采用專用SGIP方式,另一種是采用通用HTTP方式。SMG和GNS、以及SMG和SMG之間采用專用SGIP方式作為承載協(xié)議;而SP和SMG的通信同時支持專用SGIP方式和通用 HTTP方式兩種承載協(xié)議。 SP和SMG之間的通信由客戶端向服務器端發(fā)起連接。連接建立以后,由客戶端向服務器端發(fā)送命令,服務器端必須對接收到的每一條命令返回一條應答消息。SP和SMG互為客戶端和服務器端。SP與SMG之間發(fā)送的任何一條命令都帶有一個序列號,序列號由命令源產生??蛻舳伺c服務器端通信開始以后,客戶端可以向服務器端發(fā)送相應的命令,服務器端對收到的命令返回應答。
▲圖5:SP和SMG的通信業(yè)務實現(xiàn)
▲圖6:SP和SMG的通信業(yè)務實現(xiàn) (SP為客戶端) (SMG為客戶端)
命令在SP和SMSC之間的傳輸是采用類似接力的方式,每條命令和對應的應答僅僅表示該次命令發(fā)送的結果是否正確。比如,SP向某一個手機發(fā)送一條短消息,是通過向本地SMG發(fā)送一條Submit命令實現(xiàn)的,隨后,SP會從SMG接收到一條Submit_ Resp應答。但是,即使應答表示Submit命令已正確接收,也不表示Submit命令內的短消息已經發(fā)送到手機上了,而僅僅表示該短消息已經傳送到SMG,SMG將會作下一步處理,或者發(fā)送給 SMSC,或者路由到另外的SMG,最終由目的SMSC發(fā)送到手機上。這中間任何一個環(huán)節(jié)出現(xiàn)錯誤,系統(tǒng)會終止信息的繼續(xù)發(fā)送,并且通過向原SP發(fā)送Report命令告訴發(fā)送出錯的原因(如果 SP指定要求反饋的話)。
基于SMGP協(xié)議實現(xiàn)電信運營商短信的發(fā)送 SMGP是中國電信制定的短消息網關協(xié)議(短消息網關協(xié)議),版本為V3.0.3。協(xié)議適用于適用于短消息網絡上(固定網、移動網)短消息網關與其它網元之間進行短消息的傳輸,適用于短消息網關、相關網元設備開發(fā)商及內容提供商。 SMGW(短消息網關)與ESME(外部短消息實體)之間共有兩種連接方式:長連接和短連接。本系統(tǒng)采用短連接方式。通信雙方以客戶-服務器方式建立TCP連接,應答與請求在同一個連接中完成。系統(tǒng)采用客戶/服務器模式,操作以客戶端驅動方式發(fā)起連接請求,完成一次操作后關閉此連接。通信雙方之間的消息發(fā)送后等待T秒后未收到響應,應立即重發(fā),再連續(xù)發(fā)送N-1次后仍未得到響應則停發(fā)。
▲圖7:業(yè)務實現(xiàn)流程圖
結束語
隨著信息技術的不斷發(fā)展,短信群發(fā)平臺作為獲取信息、發(fā)布通知公告的一種重要方式越發(fā)顯得重要。文章提出的基于SSH的短信平臺,實現(xiàn)了移動、聯(lián)通、電信三大運營商短信網關接口的接入,并在此基礎上實現(xiàn)了通知短信提醒功能、短信發(fā)送功能以及短信自動分發(fā)功能,有效地延伸了有效延伸了其他應用系統(tǒng)的信息流,提高了信息發(fā)送的便捷性和針對性,具有一定的推廣性和研究價值。目前系統(tǒng)已經上海市交通委指揮中心監(jiān)控系統(tǒng)正式使用,在今后的信息化發(fā)展中如何能夠更加充分有效地利用短信平臺還需要進一步研究和探索。