GPS部標監控平臺的架構設計(八)-基於WCF的平臺數據通訊設計

整體來說，GPS部標平臺的軟件開發是一個對網絡通訊和應用程序之間通訊的技術應用密集型的開發工做，也是有必定設計技術含量的工做。

1.設計通訊接口

在設計的時候，根據職責劃分，拆分紅不一樣的應用子系統，對各個子系統進行功能隔離，並經過設計接口規定子系統直接的調用規約。

首先咱們根據部標平臺的要求，設計和開發出各個主要的服務器子系統，這是平臺中最核心的子系統，在實際的應用中，因爲車輛規模的大小和行業需求，還會擴展出各類業務子系統。核心子系統以下：

1)808GPS服務器，採用交通部的部標808協議，負責與終端的數據接收、指令下發; 參見：基於部標JT/T 808協議及數據格式的GPS服務器

2)809轉發服務器，採用交通部的部標809協議，做爲企業下級平臺，負責轉發GPS數據到政府平臺的服務器;參見:基於JT/T809-2011的(已過檢)GPS平臺數據交換及轉發服務器

3)809政府服務器，採用交通部的部標809協議，做爲政府上級平臺，負責與下級平臺進行全雙工通訊。

4)GPS監控客戶端，採用自定義的數據通訊協議與服務器進行數據通訊，爲用戶提供監控UI，各類監控功能都直接反映在此客戶端上。交通部的部標檢測和認證的全部工做，雖然涉及了平臺的各個部分，可是檢測的發起都是從客戶端發起的，其餘的子系統，咱們統稱爲後臺。須要購買部標平臺源碼的能夠聯繫(2379423771@qq.com)

2.接下來，咱們須要肯定子系統直接的通訊框架。

不少老牌的GPS程序員，對於Socekt特別熟悉，只要是通訊，就設計協議，而後使用Socket框架，裏面侵入了大量的業務邏輯。時間長了，代碼很是難以維護。

如今開發技術的發展彷佛與他們絕緣。連WebService都少用。更不用說瑞士軍刀WCF框架了。這種面向字節的設計和開發，經常要重複編寫大量的二進制字節轉換，而如今咱們更喜歡的是面向接口的設計和開發，底層的東西咱們已經不須要考慮，經過簡單的配置就能夠快速的構建出兩個應用程序之間的數據通訊。採用WCF，可讓咱們基本擺脫掉那些使人厭惡的Socket套路。

好比咱們再808中，設計一個實時數據服務，RealDataService和接口IRealDataService，  編寫一個獲取實時數據的方法，經過WCF框架的配置，就能夠快速的爲其餘子系統提供實時數據的推送和轉發服務了。

並且，咱們也能夠經過配置，將WCF轉換成JSON格式，這樣手機查車等手機客戶端引用也能夠和服務器進行數據通訊，獲取數據。

3.全雙工通訊

  實際上子系統的通訊基本全是全雙工的通訊，好比拍照的通訊：809下級平臺服務器收到上級平臺的拍照指令後，將指令下發808服務器，808服務器再下發給終端，終端拍照應答給808服務器，808服務器再將拍照數據轉發給809下級平臺，809下級平臺再將拍照數據轉發給809上級平臺。雖然咱們描述流程的時候，彷彿是同步的，實際上網絡通訊是異步的全雙工通訊。能夠看出部標要求的通訊需求決定了子系統之間的通訊的複雜性，而WCF的通訊框架較好的隱藏掉底部通訊的複雜性，知足頂層業務開發的需求。

 

4）部標流程檢測和運行檢測

部標平臺開發的複雜性就在於，咱們能夠快速開發出一個大面上過得去的東西，可是卻沒法開發出一個嚴格符合要求的部標平臺，從上圖中能夠看出一個拍照指令，須要貫穿四個子系統，而且是異步的。如何跟蹤各類指令在橫跨各個子系統或平臺時的發送狀態、執行狀態和應答狀態，不只僅是一個須要在用戶體驗上面下功夫的功能，在交通部的部標認證的檢測中，最最麻煩的就是運行檢測，由於要跨兩個平臺，政府平臺和企業平臺，企業平臺內部要跨越終端、808服務器、809下級平臺服務器等多個子系統。檢測失敗，可能出如今各個環節當中，檢測人員只是平靜的告訴你沒有經過，而咱們剩下就是猜了。因此每一個系統必需要有較好的指令監控的功能，以便於較好的應對實際的部標檢測中出現的意外狀況。如下是對809轉發服務器的指令的數據包監控。