1 引言
在互聯網支持的大數據應用系統中，實體行為通常通過消息交流產生相互影響，實體行為之間是并發的、獨立的、自演化的。所有實體的行為決定了系統的行為，在系統的穩定態下個別實體的變異不會影響整個系統的功能，雖然每個實體的行為具有確定性，但它們所作用的系統演化結果具有不確定性。也就是說，互聯網中的所有個體構成了巨大的并發計算機，每一個個體通過與其他個體進行信息交互實現各自的計算，并且得出整個系統的運行結果。如果將這種在互聯網世界表現出來的行為方式運用到程序架構設計中，由個體的消息來驅動程序，降低個體變異對整個系統的影響，形成一種新的開發框架，將會是程序設計的一種新思路，可以看作在程序層面模擬自然系統的行為。比如，很多大數據應用系統由于個體行為與整個系統性能有著強關聯性，其編程方法和開發模式就需要解決實體的動態性、不確定性、并發性，通過模擬自然系統的行為和演化模式，實現程序的靈活性、頑健性等問題。
在大數據應用系統中，已出現很多實際問題需要采用新的程序架構來完成特定的功能要求。比如在智慧城市中，許多用戶之間共用一套消息管理系統，消息管理系統可將消息主動推送給相應的用戶，而用戶之間很少進行聯系。在傳統的面向對象的程序設計方法中，對象之間是相互通信且彼此聯系的，任何一個對象的加入或者退出都需要告知其他對象，簡單來說就是每個對象內部都有一套自己的消息管理系統。但是在大數據應用中，多元數據的融合卻成為重要的問題，這就給程序設計帶來新的問題，即動態融合的數據如何更好地應用于系統，以實現“融合、跨界、基礎、突破”。
針對這類大數據應用，一種新的程序開發架構正在形成，這就是面向實體、基于消息驅動的開發架構——消息驅動架構（massage drivenframework，MDF）。MDF在結構上沒有傳統的主程序，而是分為3個模塊，即實體模塊、消息模塊和數據及顯示模塊。實體類似于對象，封裝了數據和操作，形成獨立的運行單元。但是實體之間沒有直接聯系，所有的實體都是基于消息控制的。MDF提供了一種在網絡環境下，共同開發系統的機制，遵守事先規定好的規范，開發人員不需要有溝通聯系，根據規范自行開發應用模塊（實體），然后加入系統中運行，并且還可以隨時退出，這些操作都無需與系統其他用戶和管理人員打招呼。所有這些實體（用戶）行為決定了系統的行為，個別實體的消亡或變化不影響整個系統的功能。MDF是一種在互聯網環境下的編程框架，支持眾多實體參與的共同開發模式，它建立一種直接模擬自然和社會系統復雜行為運行的編程方法，排除個別變異實體對整個系統功能的影響；探索一種新的應對大數據問題高并發、大流量、用戶獨立的解決方案，滿足新的應用需求。
消息管理是MDF重要的組成部分，可以說是整個系統的中樞，所有實體的運行要靠消息管理進行協同，因此消息管理模塊的設計與開發是整個系統的關鍵內容。這里面主要有三大挑戰：一是在MDF中，所有的通信方式都被嚴格定義為消息，不同類型的消息有著不同的處理方式，消息管理器如何在消息數量龐大的情況下識別消息類型，盡可能提高消息的處理準確率；二是在消息維護過程中，如何通過調度策略，以優化各種不同類型消息的處理和管理，使得在消息交互過程中盡量減少資源開銷和成本；三是在消息接收和發送過程中，尤其在消息數量龐大的情況下，消息必然出現排隊情況，如何設計合理算法，保證不同優先級的消息能夠及時得到發送，又避免出現消息長期等待不被處理的情況。
本文中指的消息，相對于已有的事件驅動（event-driven）中的事件有所不同，事件的定義更加廣泛，可以是程序本身發出的信息，也可以是終端設備發出的請求。事件的管理和處理需要有一套復雜的硬軟件設備來完成。消息只是用戶程序（終端應用程序）發出的一些文字序列，因此比起事件來說，在類型和內容上要簡單的多。理論上說，事件驅動的技術可以用來產生消息驅動程序，但是不如另外為消息驅動重新定制一種架構，在應用系統開發中會更加有效和簡單。
消息管理模塊在MDF中起到了中心的作用。本文設計并實現了MDF的消息管理模塊，包括以下3個方面：
● 定義了消息的基本格式，制定了消息池的語言規范，通過消息表單的配置，實現不同類型消息的區別管理；
● 利用現有的編程語言Java開發了消息維護中間件，根據消息規范的表單配置自動生成消息類型管理，實現消息的接收、維護、存儲和發送等核心功能；
● 開發了中間件，接受實體對于消息管理模塊的操作，包括查詢、檢索以及對于各種類型消息的定義變更，滿足了MDF中實體運行和變化的需要。
在MDF中，實體的數量是可變的，實體的類型是多樣的。所有實體發送的消息和接收的消息將遵循統一的格式，實體需要向系統聲明的是它的URL地址、消息類型、消息發送要求等。URL 地址提供了該實體消息發送和接收的接口。消息類型和消息發送要求提供了消息的處理方式，這種要求被消息管理模塊響應，并被正確維護。一個系統中的實體類型是多種的，每一種實體類型被定義了消息格式，同一類型的實體必須按照相同的消息格式發送消息，系統的消息管理模塊在邏輯上是唯一的。所以消息管理模塊的設計為實現MDF的并發性、動態性、頑健性、不確定性和跨平臺性等重要特性奠定了基礎。
2 相關工作
隨著計算機經驗和軟件技術的發展，計算機編程語言經歷了機器語言、匯編語言、面向過程的程序設計語言以及面向對象的程序設計語言階段[6]。具體的語言不勝枚舉，見表1。
表1 編程語言的發展
隨著編程語言的發展，計算機程序設計的方法也主要經歷了3個階段的發展：面向機器的程序設計、面向過程的程序設計和面向對象的程序設計。
人類和計算機進行交流最開始的語言是由計算機可以直接識別的二進制指令組成的機器語言，在這個時期，計算機的程序架構就是直接描述機器操作，因此這時的程序稱為面向機器的程序架構。隨著高級程序語言的出現，面向過程的程序架構被提出，這種結構化的程序設計采用了“自頂向下，逐步求精”的思想，將計算問題模塊分化，功能分解，大的問題化解為若干個小問題，大大提高了工作效率，也利于程序的維護。當然，面向過程的設計方法也存在一定缺點，最主要的是該方法編寫的程序是一系列的線性步驟，這種編程方式必須按照線性步驟從頭到尾編寫代碼，過程枯燥且不易修改，代碼的靈活性和可移植性都較差。為了克服這一困難，面向對象的程序架構應運而生，其主要思想是“注重對象，抽象成類”，不再強調過程，更側重于對對象的操作。對象是數據和操作的封裝體，與客觀實體直接對應。通過封裝使對象變得獨立，只能通過預先設定的方法與對象交談，在構建代碼的過程中通過繼承，減少冗余代碼的同時又可擴展現有代碼；封裝可減少外界對程序的干擾；且面向對象的系統很容易切分成很多獨立的部分，將系統化繁為簡，同時這種方法可以使系統從小到大逐步升級。但傳統的面向對象架構仍存在不足，對象之間需要建立自己的通信通道，所有對象都需要了解一定的環境參數。但是在互聯網環境中某些由眾多用戶動態參與的應用系統中，例如購物、游戲、社區等，它們的特點是用戶眾多且不確定，并且在大多數情況下，用戶不需要了解過多的運行要求和參數，而且用戶之間是透明的，也就是用戶之間可能不知道對方的存在，因此也不能有直接的溝通，對于這類程序的開發就需要提供一種更為自由和開放的編程模式。從目前主要是個人和小團隊開發的模式，逐步過渡到可以由彼此互不認識的眾多用戶共同開發的模式，讓眾多的用戶包括非計算機專業的用戶也可以參與到系統的開發和運行中，使得每一個用戶既是程序的應用者也是程序的開發者，將更加能夠體現大數據應用的特點。
本文提出的MDF的程序設計方法的主要思想是“實體獨立，消息驅動”，各個實體之間遵循相同的消息通信協議，參與設計和開發的人員只需輸入框架指定的幾個參數就可參與開發，因此開發人員不需要相互溝通，大家只需要根據協議和規范就可以進行各自的應用開發，最終組成一個龐大的應用系統，讓更多的用戶根據個性化的要求方便地使用。
3 MDF架構與消息管理模塊
3.1 MDF架構
MDF沒有傳統意義上的主體程序，而是由實體、消息和數據顯示3個部分組成。總體來說，MDF是模擬自然和社會系統的運行模式，MDF所有運行都是通過消息驅動的。任何用戶都可以成為系統的組成部分，稱之為實體，或者系統對象。程序開發者只發布系統規范，系統規范指明實體的類型、實體的動作定義、實體的消息構成、實體消息的內容格式與解釋以及實體的登錄方法、實體生命周期等。一般地，規范提供實體樣式。系統規范還會提供實體與數據顯示部分的數據交換方式、運行結果顯示的方式以及相應的顯示控制軟件，由數據顯示部分具體執行。規范是開放的，用戶可以根據系統規范開發實體，或者實體樣式填好參數進行注冊，進入系統運行；也可以根據規范自行開發顯示模塊，獲取個性化的顯示方式。實體的地位是平等的，實體的加入和退出完全是自由的，雖然會影響系統的運行結果，但是一般不會影響系統的功能。消息部分是實體之間進行信息交互的中介，實體之間并不直接通信，而是借助消息部分進行轉發。實體的動作由消息定義，實體通過發送和接收消息來實行具體動作。實體的功能以及如何由消息定義動作在系統規范中予以說明。數據顯示部分提供運行結果和過程的顯示。MDF通過3個模塊實現這些功能，分別是實體管理模塊、消息管理模塊和由數據庫和輸出控制組成的數據顯示模塊。其具體架構如圖1所示。
圖1 MDF架構
●實體管理模塊：是整個軟件開發的主要部分。開發者編制、發布實體規范，規范提供實體描述定義、實體動作定義以及消息內容格式與解釋，用戶根據規范自行開發實體程序，或者根據開發者提供的實體樣板注冊登錄。實體管理模塊根據實體規范協議管理所有的實體，包括實體的登錄和退出以及生存期間的運行管理。
●消息管理模塊：管理實體之間用于交互的消息。消息管理模塊發布一個消息格式協議，其中定義了消息格式的內容與解釋。消息管理模塊根據消息格式協議管理消息的接收、發行、維護以及存儲等。
●數據顯示模塊：提供系統運行數據的顯示，包括結果顯示和過程顯示，數據顯示模塊與實體進行通信，接收實體提供的數據，通過輸出控制器執行數據顯示的功能。同時該模塊還提供公共性數據和永久性數據的存儲和查詢，這些功能同樣通過與實體消息交互來驅動和實現。
本文主要介紹消息管理模塊的設計原理和實現，其他兩個模塊將另文撰寫。
3.2 消息格式協議
消息管理模塊最重要的是消息格式協議（message format propotol，MFP）。M FP定義消息為一個文本信息，分為4種類型，分別為：發送消息、查詢消息、測試消息和名單消息，所有消息都用表示消息類型的代碼開頭，后面跟隨消息本體。其中，A表示發送消息，即實體之間傳遞的消息；B表示查詢消息，即實體發出的查詢某個消息的請求；C表示測試消息，即實體用于測試通信鏈路狀態的消息；D表示名單消息，即實體發出的名單，這個名單提供當前實體的變動，或者在多播狀態下提供接收實體的列表。
MFP定義消息head部分有7個屬性（見表2）。各部分內容如下。
●name：符號串類型，表示消息的名稱。字長限制為128 byte。
●from：URL類型+時間類型，消息發送方的URL地址，后跟發送時間，中間用“+”號隔開。
●to：消息接收方地址，使用“X+P”形式表示，其中，X表示發送形式，分別是U（單播）、M（多播）和B（廣播）。P表示發送對象，在單播時為URL地址，多播時為接收方的URL地址，最多為16個地址，或者是分組文件名稱，這個分組文件事先存放在消息管理模塊中。廣播時，P為空，此時由消息管理模塊根據內部存放的實體名單向各實體發送消息。X和P之間用“+”隔開。
●type：消息發送類型，使用單個字符表示，其中A表示主動發送，即該消息根據設定的時間自動發送到接收方；P表示消息只在接收方查詢時發送。
●life：消息生存時間，使用“單個字符+時間類型”形式表示，單個字符表示消息銷毀時間，后面是具體的時間，中間用“+”隔開。其中，單個字符L表示該消息發送后即銷毀；L+time表示該消息在time這個時間點銷毀；K+time表示消息在保存time時間后銷毀。
●time：時間類型，表示消息發送的時間，這個參數只在主動發送時有效，在查詢發送的消息中，該欄目可以為空。
●priority：整數類型，取值為1~3，表示該消息的優先等級，消息的優先等級由系統規范定義。
表2 消息的基本格式
表2列出了發送消息name、from、to、type、life、time、priority的全部7種屬性。消息管理模塊會針對消息的屬性描述進行不同的處理。
發送消息（以A開頭）的消息內容由head和body兩段組成。head定義了消息的聲明部分，用以描述消息的屬性；body定義了消息的內容部分，用以描述消息的正文。MFP僅對消息的head部分進行了格式要求，其屬性值對消息的傳輸、保留、銷毀、發送以及與實體之間的交互起著重要的作用。MFP對body未做要求，只是限定了body的長度。body的內容語義解釋由程序開發者定義，所有實體必須按照這個定義來編排消息內容。在MFP和消息管理模塊中，不涉及對于消息內容的任何讀寫，只是根據消息head部分的要求進行消息管理，而消息body部分的內容理解是由實體完成的。
查詢消息（以B開頭）由消息名稱（name）（必有）、查詢方的URL地址（to）以及查詢內容（body）組成。查詢內容是消息的屬性，該模塊支持屬性匹配查詢，消息管理模塊在匹配檢查完成后，將符合條件的消息根據URL地址發送給查詢方。查詢內容部分可以是空，表示這部分不用匹配。在本文的版本中，暫不支持模糊查詢和通配符查詢，也暫不支持多條件查詢。
測試消息（以C開頭）是由發送方的URL地址加上任意的64byte的文本，中間用“+”隔開。消息管理模塊在收到該消息后，向發送方返回該64 byte的文本。測試消息是為了檢查當前通信線路是否可用，當實體發送測試消息并正確回收發送的文本后，就可以執行正常的消息傳送了。
名單消息（以D開頭）有兩種格式：名單定義與名單刪除。名單定義用于表示實體定義的多播名單，一般情況下，實體可以隨時發送多播名單，多播名單有多個，編號加以區別，該多播名單聲明實體名稱和多播對象URL地址。當實體提交一個多播消息時，應在屬性to中指明多播名單的編號，以便于消息管理模塊生成發送消息對象。名單刪除表示需要刪除的名單，所有名單通過名單名稱進行識別。
3.3 消息管理模塊
消息由實體產生，并以消息格式協議規定的形式由消息管理模塊處理，其中消息名稱name是消息的唯一標識。
每一個實體在登錄系統時，會向消息管理模塊發送一個身份登錄信息，從而在消息管理模塊中產生一個動態的實體名單，該名單維護當前登錄實體名稱。同時每一個實體需要發送多播消息時，會向消息管理模塊提交多播名單編號。如果未提交多播名單，協議允許發送方在消息屬性to部分臨時指定不超過16個發送對象的URL地址。實體名單和多播名單都由消息管理模塊維護。
圖2演示了消息從接收到發送的完整流程。實體1發送控制指令與通信線程1建立消息傳輸通道1，發送消息msg2。消息管理模塊接收到msg2，經過合法性和完整性的驗證，將消息存放在消息池中。如果消息屬于主動發送類型，則將該消息加入發送隊列，根據指定的優先級發送消息。如果是被動發送消息，則在接收到查詢消息后，將該消息加入發送消息隊列，根據該消息的優先級發送到實體2。
由圖2可以看出，消息管理模塊主要分為2個部分：消息池和消息數據庫。
圖2 消息的流向
消息池是3個消息隊列，分別對應MFP中的3個優先級。需要發送的消息根據優先級放入相應的消息隊列進行排隊。消息隊列的管理算法在下面單獨說明。
消息數據庫是一個數據庫，消息被接收后，經過消息管理模塊的解析，如果不是即時發送，則存入相應的數據庫。消息數據庫隨時檢查消息，當某條消息達到發送條件時，即將該消息送入消息池排隊。如果接收到的消息是查詢消息，則進行相應的查詢，并將查詢的信息返回發送方。如果某條消息需要銷毀，則消息數據庫進行相應的操作。
除了這兩部分外，消息管理模塊還負責消息池和消息數據庫的維護，保證其正常運行和通信暢通。當實體發送測試消息時，該模塊負責響應該測試消息。當實體發送名單消息時，該模塊負責讀取并存入相應的存儲器管理，或從存儲器中刪除名單。
（1） 消息管理
消息與實體之間的聯系采取socket通信協議。socket為消息管理模塊和實體模塊之間的通信提供了進程通信的端點，每個socket都用一個半相關的描述（協議、本地IP地址、本地端口）。系統會根據實體的URL地址和端口號為其生成一個socket號；消息管理模塊向所有實體公布唯一的socket號，任何知道該socket號的實體都可以向消息管理器發出連接請求。
消息管理模塊與實體之間的連接過程分為3個步驟：通信線程的監聽、實體端請求和消息管理模塊的連接確認。由于消息在網絡中進行傳輸會有較大的時延，為了提高系統的實時性和吞吐量，每個實體與消息管理器之間都有一個消息傳輸通道。對于每一個消息傳輸通道，消息管理器中有一個用來收發消息的通信線程與其對應。
通信線程接收到用戶實體發送的消息后，首先對消息進行完整性、合法性檢驗，然后再對檢驗合格的消息進行處理。
● 如果是發送消息，則解析消息head中的各個屬性，對于滿足發送條件的，則根據屬性中的指示，將消息加上需送達的實體URL地址以及其他一些輔助信息，根據其優先級，加入相應的發送隊列等待發送。
● 如果是查詢消息，根據查詢消息中的查詢內容在消息庫中進行查詢；將查詢到的消息加上送達實體的UR L地址以及其他一些輔助信息，并根據其優先級，加入相應的發送隊列等待發送。
● 如果是測試消息，則根據協議規定，返回測試實體64 byte的文本。
● 如果是名單消息，則將名單加上發送實體的URL地址與編號作為文件名稱，存入相應的存儲器，以備使用。
同時，消息管理模塊也支持一些控制指令，以保證系統通信的正常和完好。
（2） 消息池
消息池負責管理消息的發送，主要包括多個發送隊列（本文中是3個）、發送隊列維護線程、消息的發送線程。消息管理模塊與實體連接后，就會進行消息的傳遞，在消息的傳送過程中，將根據優先隊列進行消息發送。
消息池經常處于并發工作狀態，為此在消息池中對每條消息都標記了優先級，同優先級的消息位于同一發送隊列，如圖3所示。具體算法如下。采用優先隊列發送（priority queuesent，PQS）算法。
圖3 發送隊列設計
①讀取最高優先級（priority=3）的隊列消息，如果該消息信道空閑，則發送該消息；如果信道繁忙，則轉向同隊列的下一條消息；如果下一條消息不存在，則將下一優先級的第1個消息移入該隊列，并發送該消息。
②消息發出后，等待時間間隔γ，如果收到消息發送成功信息，則在隊列中刪去此消息。將次高優先級（priority=2）和最低優先級（priority=1）的隊列中的最前消息優先級加1，并排到前一優先級的隊尾；返回第①步。
③如果時間間隔γ后，未收到消息發送成功信息，則再次發送該消息。
④如果再次時間間隔γ后，仍未收到消息發送成功信息，將該消息移到同一優先級的隊尾，返回第①步。
該算法可以設立通信進程而支持消息的并行發送，在前一個消息發出而未收到確認信息時，后一條消息仍可以發送，而且確認信息回復的次序可以與發送次序不同，后發的消息回復可能先收到。
消息池在消息隊列的內部采用FIFO（first in first out，先進先出）算法；在隊列間，采用動態優先權調度算法，即將消息加入發送隊列時，按其優先級加入相應的發送隊列，消息發送總是在最高優先級隊列中進行，每處理一條消息后，就將其余隊列中的第1條消息的優先級加1，并按更新后的優先級將消息轉至相應的發送隊列隊尾。梯度發送隊列之間用鏈表實現。發送隊列維護線程用于動態（按時間片）更新消息的優先級。消息的發送線程用于從優先級最高的發送隊列中取出消息，并根據消息head中的to字段調用相應的通信線程發送消息。由于系統中有多個消息傳輸通道，等待一個消息被接收后再發送另一個消息會導致傳輸通道的空閑時間過長，為了提高系統的吞吐量，本文采用了多線程的消息發送模式，只要待發消息的信道空閑，就發送該消息，這樣的方法可以提高信道的利用率。
（1） 消息庫
消息庫是一個關系數據庫，本文使用的是MySQL。消息庫存放所有未被刪除的消息以及名單消息中提供的名單，并實現以下的操作。
● 接收消息后，經過解析，如果需要立即發送，則按照優先級送到相應的發送隊列排隊，并存入信息庫；若不需要發送，則送入消息庫，消息的各屬性作為消息庫的字段，以便于按屬性查詢。
● 檢查消息庫：如果某條消息符合發送條件，則取出該消息，送入發送隊列；如果某條消息需要銷毀，則銷毀該消息。
● 收到查詢消息后，進行按屬性查詢，并將查詢結果返回查詢實體。如果被查詢消息需要發送，則送入發送隊列。
● 收到名單消息后，如果是名單定義，則將名單追加到消息庫；如果是名單刪除，則從消息庫中刪除指示名稱的名單
4 實驗設計
本文提供一個基于M D F 開發的實例——天文大數據模擬系統。天文科學是一個產生大數據的學科，例如在太陽與小行星的運行系統中，就有數以萬計的小行星，計算這些小行星的軌跡是一個典型的大數據應用。這些小行星還會不斷增加和消失，如果把小行星看作用戶，這是非常有代表性的多用戶動態運行系統。因此通過MDF開發一個系統，隨時模擬小行星的運行，該系統支持小行星的隨時更新。在本文中，筆者做了一個簡化的實驗性版本，用以說明原理，以太陽、地球、火星、金星4個星體為例，模擬星體的運行軌跡。星體之間由于受到引力作用，以太陽為中心做橢圓軌跡的運動。太陽系的運行是包括太陽在內的所有星體共同作用的結果，由于每個星體都是不停運動的，對其他星體引力的大小和方向在時刻變動。消息驅動框架正適宜去描述這類問題。在該模型中，每個星體都是一個實體，它們都具備相同的功能，而一個星體對另一個星體的引力影響可以認為是該星體發出了一個消息給另一個星體，星體根據消息內容做出自己的運行。在MDF方式下，每個星體只要給出自己的物理參數（質量、位置、速度），整個太陽系的運行就可以自動建立起來，而且可以隨時添加新發現的星體（小行星），也可以隨時刪去星體。
圖4顯示了金星在太陽、地球和火星作用下的引力模型。金星有一個質量和初速度V0使其能在引力作用下圍繞太陽轉動。
圖4 三行星的運行模型
在該引力模型中，實體管理模塊有兩種實體類型：太陽和行星。地球、火星、金星為行星類型。實體管理模塊定義太陽的位置固定不動，行星在引力的牽引下圍繞太陽作公轉運動。太陽實體具有質量（weight）和位置（position）兩種屬性，以（weight， position）的消息格式發送并存放在消息管理模塊。每個行星實體都有質量（weight）、位置（position）、速度（velocity）、時間（time）4種屬性，并將這4種屬性以（weight ，position， velocity， time）的形式加以封裝，作為消息相互傳遞通信。太陽的消息是被動查詢類型，而每個行星實體的消息都是主動廣播類型。以火星為例，火星實體向消息管理器發送一條查詢消息，消息管理器解析火星實體發送來的查詢消息的head部分，將查詢到太陽的消息發送給火星，火星實體解析出太陽的位置和質量，又得到其他行星推送的消息，就可以計算出自己在當前位置受到的來自太陽和其他行星的引力，并計算下一步的位移。
為了觀察實驗結果，將太陽、地球、金星和火星的運動軌跡以圖像的形式展現出來，本次實例使用的質量、位置、速度數據均以目前太陽系運行模型為基準，參數設置在表3中，而圖5則將表3的參數圖形化，顯示了各個星體的初始位置。
表3 行星參數
圖6顯示了太陽在靜止不動的情況下，地球、金星和火星圍繞太陽的運行軌跡。
圖5 星體的初始位置
圖6 星體的運行軌跡
在該天體模型中，可以隨時加入或撤銷星體。當發現新的星體時，只要在實體管理模塊輸入星體正確的質量、速度和初始位置，就可以加入該天體模型中。新星體的加入或撤銷會影響其他星體的運行軌跡，但不會導致整個模型的崩潰。
5 結束語：
在大數據應用背景下，編程語言顯示出與機器的相關性越來越小，與客觀世界越來越貼近，程序的開發架構也越來越與計算機執行的過程脫離，而趨向于和問題結構越來越靠近，“描述就是編程”已經成為當前編程架構的關注點。編程語言已經逐漸從專業高端走向普通大眾。本文研究的消息驅動框架的開發模式是一種典型的聲明式編程，其中，消息管理模塊是消息驅動框架的交通樞紐、神經中樞，它控制著通信唯一媒介——消息的接收、存儲、發送以及維護等相關工作。這種編程框架模擬了許多自然和社會系統的行為方式，改變了人們的解決問題的方式，也將處理邏輯的重點從內部轉移到外部，簡化了問題求解的復雜度。
在消息驅動的開發框架中，消息管理模塊的定義與設計是重點，目前也只是完成初步的描述，還有很多細節和功能方面需要改進，以下幾點是需要完善和考量的。
● 程序的頑健性：在消息管理模塊中有大量的中間件，要保證每個中間件必須是頑健的。因此建立錯誤恢復機制、為開發人員提供測試和調試的接口以及提供較為明確的錯誤報告對消息驅動框架的發展是相當必要的。
● 消息管理：本文雖然對消息管理做了初步的約定和設計，但是在實際系統運行中，消息管理的要求是多樣的，如何適應不同需求的消息管理模式，仍有待于繼續探討。
● 消息管理模塊與實體模塊和顯示模塊的對接：本文的工作主要是針對MDF的消息管理模塊，實體模塊以及數據管理和顯示模塊仍需要進一步完成和完善。
核心關注：拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理，全面涵蓋了企業關注ERP管理系統的核心領域，是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網http://m.lukmueng.com/
本文標題：大數據應用系統的消息驅動架構
相關文章
