【正文】 多協議，只需支持一種特定的協議就可以了，此外，它必需知道到消息中心的通信方式（可在應用初始化時以參數形式引入），并在應用上線時向消息中心發(fā)送上線注冊消息；應用離線時，則需向消息中心發(fā)送離線注冊消息。消息定閱時，由潛在接收者將其“感興趣”的消息清單發(fā)給消息中心，該消息數據結構如下：Data MsgType?/MsgType/Data其中：l MsgType――被定閱的消息類型值。一個消息可以有多個定閱者。消息定閱存在這樣一種情況：發(fā)消息的不確切知道究竟誰對該消息“感興趣”。當服務申請者在申請一個特定服務時不用關心其由誰提供，只需將Receiver屬性填成保留字（如：SERVICE_PROVIDER），消息中心在收到這樣的消息后，取出其消息類型并查找服務列表，找到，則將該消息轉么給相應的服務提供者，否則，按上述消息轉發(fā)過程處理。服務提供者在上線時向消息中心發(fā)送服務注冊消息，該消息數據結構如下：Data MsgType?/MsgType Address?/Address/Data其中：l MsgType――消息類型。雖然服務申請者不知道應該向誰申請，但服務提供者顯然知道自己可以提供什么服務。服務注冊對于大量的服務申請，申請者并不知道該服務具體由誰提供（例如：一個社區(qū)健康檔案登記模塊欲將一個新記錄保存到數據庫中，但它并不確切地知道該記錄應該保存到獨立的社區(qū)數據庫中呢？還是直接保存到數據中心里，這時要求其填寫準確的Receiver地址是困難的。值得注意的是，該機制支持“群發(fā)”功能（若Receiver屬性值只填了分系統編號而沒填功能模塊編號，則發(fā)給整個分系統所有接收者。隨后有發(fā)往該應用的消息，若共Persistable屬性為1，則該消息被存儲到消息中心的永久消息隊列中，等待該應用下次上線時轉發(fā)過去；否則，將消息丟棄。離線注冊當應用離線時需向消息中心發(fā)送一個離線注冊消息，該消息數據結構如下：Data Protocol?/Protocol ProtocolAddress?/ProtocolAddress/Data各段含義同上。這樣消息中心在進行消息應答或轉發(fā)時，就知道應該選擇哪個消息發(fā)送模塊完成發(fā)送。如：采用SOAP協議，其樣子可能是這樣的：；而采用TCP/IP協義，其樣子可能是這樣的：，5001，等等。如SOAP、TCP/IP、MSMQ等等。l Protocol――通信協議，標識本應用所采用的通信協議。注冊消息的數據段（參前面的應用層消息定義）結構如下：Data Address?/Address Protocol?/Protocol ProtocolAddress?/ProtocolAddress/Data其中：l Address――應用層地址。其中ReceiverProtocolAddress為接收者協議地址。}。原則上，消息中心只需實現一個消息處理器，用于提供消息中心的標準服務，詳細描述見下文。}。消息處理器是實現了IMsgHandler 接口的組件對象，其作用是完成一至多個消息的處理。這種可定制的消息派發(fā)機制是實現可擴展消息服務的重要手段。}。該組件實現了接口IReceiver，該接口定義如下：interface IReceiver { HRESULT RegMsgHandler([in] long MsgType，[in] IMsgHandler *pMsgHandler)。}。如下圖所示：SOAP消息偵聽TCP/IP消息偵聽MQ消息偵聽SOAP消息發(fā)送TCP/IP消息發(fā)送MQ消息發(fā)送消息中心服務WANN消息中心多協議支持原理示意圖上圖中每種協議的消息偵聽組件都對應一個該協議特有的通信地址描述符（如：SOAP是一個指向WSDL的URL，而TCP/IP則是一個IP地址加端口號），根據“基于消息中心的系統架構示意圖”可知，每個應用都必需知道如何與消息中心通信，而具體的應用場景只支持一種通信協議，因此，它只需記住該協議在消息中心所對應的通信地址描述符即可。分別詳述如下：多協議支持如上所述，本架構有必要支持多種通信協議，但對于特定的應用場景，多協議支持是不必要的，因此，除消息中心外的其它應用都將只支持一種特定的通信協議，彼此間的消息往來都通過消息中心，由后者在轉發(fā)時完成協議轉換。消息中心是本架構設計的核心，其提供的服務主要有：上線注冊、離線注冊、消息轉發(fā)、服務注冊、永久消息隊列和消息定閱等。因此，在消息層面上，數據中心與其它業(yè)務數據庫并沒有什么不同，這意味著該架構可很好地支持數據的分布存儲。例如：功能模塊1申請一個服務，但它并不知道該服務該由誰提供，于是它將請求消息發(fā)給消息中心，消息中心則查找其中登記的服務提供者，比如發(fā)現該服務應用數據中心提供，于是消息中心將該消息轉發(fā)給數據中心，數據中心收到消息并完成處理后，同樣不知該如何將應答消息（如果有）直接發(fā)給申請者，于時它將應答消息發(fā)給消息中心，消息中心再將該消息轉發(fā)給功能模塊1，至此，完成一次基于消息的服務請求過程。從上圖可見，各功能模塊、和業(yè)務數據庫以及數據中心彼此并不知道對方的存在，但它們都知道如何與消息中心通信，反之亦然。 消息中心在上述消息及應用層地址的定義中都不曾涉及底層通信協議，但實際的消息收、發(fā)總是通過適當的通信協議完成，考慮到在整個系統虛擬網范圍內，各級各類醫(yī)療機構接入條件的差異，可支持多種通信協議是本架構需要具備的特性，此外，如前述基于信息的服務和支持分布數據存儲等特性都將在消息中心的設計中得到體現?？捎靡韵陆Y構化字串描述一個應用層地址： 分系統編號 ：[ 功能模塊編號 ]通過上述應用層地址定義，邏輯上可在某數據中心的覆蓋范圍內建立兩個功能模塊之間的直接會話通道。這里結合本架構的設計目標，給出應用層地址的統一定義。 應用層地址一次消息收、發(fā)涉及四個要素：發(fā)送者、消息、傳輸路徑和接收者。若取值為0，則要求發(fā)消息時，接收者同時在線，否則，發(fā)送行為將失敗返回，消息也將被丟棄；若取值為1，當消息發(fā)送時，若接收者離線，消息將被保存在數據中心的相關數據庫中，由目標接收者下次上線時自行到數據中心檢索。可選項?？蛇x項。取值為0，則，接收者在收到該消息后無需回執(zhí)；否則，接收者在收到消息后需再給相應的發(fā)送者發(fā)一個回執(zhí)消息，以確認收到，用于基于消息的同步調用。對于特定的Type，上述Data將具有明確的結構定義。l Type――消息類型。l Sender――發(fā)送者地址，用于在應用層唯一標識一個消息發(fā)送主體，稍后將給出具體定義。消息結構又可分作兩部分：控制結構和數據結構，其中數據結構因具體消息的不同而異，因而也不屬于本設計范疇，這里只定義統一的消息控制結構。 接口設計 消息定義標準在消息驅動的系統設計中，首要的任務當然是完成消息定義，我們并不是要定義IP包之類，這里的消息定義工作落在ISO OSI七層模型的第七層（應用層），這方面有很好的案例可供參考，即HL7，但HL7與本架構的設計目標并不完全一致，因而不宜生搬硬套，但可學習其基本原理，而根據我們的目標定義我們的消息?？蓪Ω鹘巧珯嘞捱M行更改。 行為審核、日志管理記錄系統及用戶操作行為，可按類型進行查詢。 功能結構 詳細功能說明 基礎數據管理（1）采集指標管理：可以添加，刪除，修改指標等，在定制表格時可以拖拽已有的指標；（2）信息分類管理：可以添加，刪除，修改信息的分類，信息添加時可以選擇已有的分類；（3）機構、部門、人員分類管理：提供樹型結構管理部、省、市、縣以及內部部門人員信息的管理。 接口管理靈活的二次開發(fā)接口，便于系統未來的擴展。 預警管理對各種異常數據及情況進行預警（預警條件可自定義），將分析預警結果通過各種圖形直觀顯示，并可與地圖結合直觀顯示。最高級別授權可對各種數據進行分析匯總，其他用戶需授權訪問不同級別狀態(tài)的數據。 綜合分析系統 概述信息綜合分析系統支持靈活的數據自定義查詢、統計分析功能及選擇本地的數據進行各種分析，并可定制各種統計報表，繪制形象直觀的統計圖表，能夠清晰的顯示瀏覽各種統計數據和查詢數據，導出為指定數據格式。 后臺設置通過后臺對系統用戶進行權限的靈活分級設置，設置用戶的數據采集、訪問權限?？蓪崿F電子文檔傳輸功能，并對填報單位上報的材料進行考核評分。 報表數據修正提供對匯總數據的修改功能，根據權限設定可對統計報表的匯總結果進行調整； 報表歸檔管理對各類報表提供歸檔管理功能?？梢耘繉徍藞蟊怼?報表審核上報數據采用自動和人工審核相結合的方式，并進行逐級審核，最終由國家畜牧業(yè)管理部門審核通過后方可提交查詢統計系統進行分析。上報事件將會記錄到行為審核日志中?？伸`活制定新報表的樣式、指標，提供指標關系定制，報表驗證等功能； 報表模板發(fā)布業(yè)務統計報表定制后，通過系統送消息，提供信息點的采集人員下載填報； 報表模板導入導出提供模板的導入導出功能，在系統部署到新的采集點、數據導入導出或系統受損恢復時使用；可提供多種文件格式的無失真導入導出。 功能結構 詳細功能說明 采集流程管理通過可視化的定義工具，能夠簡便快捷的定義從縣到地到省到部的報表采集流程。LDAP目錄服務提供的是一種統一的目錄訪問的服務，其與對外所提供的服務功能是沒有直接關系的，其所提供的是一種目錄服務的統一機制。廣義的意義講，安全證書管理、DNS、NIS、UDDI等都可以納入到目錄服務的范疇。目錄服務與數據庫服務的不同之處在于，它們一般缺少數據庫提供的事務功能和大規(guī)模數據的數據庫支持。目錄服務樹中的一個目錄對象可以通過它的名字檢索，或者通過使用一組搜索標準（表示目錄對象的名字和屬性）檢索。它可以記載網絡的所有文件以及所有在網絡上運行的資源，以及使用者帳號、身份口令、密碼、卷、文檔，應用程序以至于域名服務器DHCP、IP地址以及認證的公鑰等。目錄服務的核心是一個樹狀結構的信息目錄，將網絡中的數據資源、數據處理資源和用戶信息按有次序的結構進行組織，并且專門針對海量查詢的使用情況進行了優(yōu)化，極大地提高了數據讀取和查詢性能。政府部門為了實現各個分立的“信息孤島”走向連通和融合，一方面政務系統需要將自身的職能和業(yè)務協作要求公布出去；另一方面，也希望能夠檢索并獲取其他政務系統的信息和公共的信息資源。將來，Web services將取代應用程序成為Web上的基本開發(fā)和應用實體。利用Web services，公司和個人能夠迅速且廉價地通過互聯網向全球用戶提供服務，建立全球范圍的聯系，在廣泛的范圍內尋找可能的合作伙伴。 web servicesWeb services是為了讓地理上分布在不同區(qū)域的計算機和設備一起工作，以便為用戶提供各種各樣的服務。能夠按照制訂好的業(yè)務規(guī)則目標，保證具體畜牧業(yè)的順利實施，進而通過優(yōu)化，降低成本，提高效率。BPMS為管理整個自動化的畜牧業(yè)流程和業(yè)務活動的提供如下幫助：能夠迅速使業(yè)務調整通過業(yè)務概念和業(yè)務目標等形式付諸實施，并且這些實施幾乎可以是實時進行。BPMS技術能夠為管理者和審批業(yè)務人員提供定義、變更、實施業(yè)務流程的方法，并保證業(yè)務系統的靈活性和一致性，而不必考慮更多的細節(jié)問題。在業(yè)務流程設計過程中，需要業(yè)務經理與負責業(yè)務流程管理的管理人員之間經常進行交流，以保證業(yè)務流程管理的順利實施。應用集成聯接組件是整個應用集成系統的關鍵部分，它的作用是連接系統中已有的部件，構成一個新的整體，強化整個應用系統的特性。開發(fā)套間通過其中的工具分別對聯接組件的輸入、輸出端、對應關系和處理要求進行描述，開發(fā)組件根據這些描述，運用已有的基本模板，生成專用的應用集成聯接組件，并通過部署工具將應用聯接組件部署到運行平臺。應用集成系統由以下幾部分組成：開發(fā)套件、運行平臺和應用集成聯接組件。如何達到信息交換與共享，提高政府部門協同能力，應用集成技術成為當今信息化建設的一種重要手段與技術基礎。從中間件的定義可以看出，中間件是一類軟件，而非一種軟件；中間件不僅僅實現互連，還要實現應用之間的互操作；中間件是基于分布式處理的軟件，定義中特別強調了其網絡通訊功能。比較流行中間件的定義是：中間件是一種獨立的系統軟件或服務程序，分布式應用軟件借助這種軟件在不同的技術之間共享資源。 中間件技術隨著計算機技術的飛速發(fā)展，各種各樣的應用軟件需要在各種平臺之間進行移植，或者一個平臺需要支持多種應用軟件和管理多種應用系統，軟、硬件平臺和應用系統之間需要可靠和高效的數據傳遞或轉換，使系統的協同性得以保證。J2EE技術的基礎是JAVA語言，JAVA語言的與平臺無關性，保證了基于J2EE平臺開發(fā)的應用系統和支撐環(huán)境可以跨平臺運行。，軟件件均應是正版軟件且獲得法定授權許可。10. 高安全性：保障系統資源、數據的高度安全性，防止數據被外界破壞、竊取、篡改，防止系統被技術攻擊，具備合理的數據備份。8. 規(guī)范性：系統開發(fā)應嚴格遵照國家軟件工程規(guī)范進行，根據開發(fā)進度及時提供有關開發(fā)文檔，包括軟件需求說明書、數據要求說明書、系統設計說明書、數據庫設計說明書、測試計劃、用戶手冊、模塊開發(fā)卷宗、測試分析報告、系統維護手冊、操作手冊、系統安裝手冊等。6. 穩(wěn)定性：系統采用流行、成熟、穩(wěn)定、先進的操作系統、數據庫、網絡協議等，保證系統的穩(wěn)定性。4. 標準性：系統的開發(fā)符合國際標準、國家標準及行業(yè)標準，要求制定開放標準及接口，保證與相關系統的連接。2. 易操作性：系統設計過程還應考慮到易于操作、易于使用、界面友好等問題。中間件3l 支持主流廠商的硬件平臺，支持Windows、Unix、Linux等操作系統l 數據庫系統具有良好的伸縮性l 滿足雙（多）機熱備系統 l 支持主流的網絡協議l 支持數據庫的動態(tài)調優(yōu)和自我管理l 具有豐富的管理、調試、監(jiān)控與審計工具l 支持網絡上同構或異構數據庫之間的數據的有效傳輸和冗余性復制，具有多種復制功能模塊l 同一產品中支持聯機分析處理（OLAP），提供數據抽取、轉換、裝