概述
Jt 是一種用於快速實現 Java 應用程序的設計模式框架。Jt 在許多大的任務關鍵型系統中有應用。該框架實現以下目標：
框架架構基於一個消息傳送設計模式：框架組件能夠交互信息並通過發送、接收和處理消息執行計算。一個消息傳送 API 具有簡易性、強大的封裝性和松耦合特性；可以使用一個 “lego/messaging” 架構將框架組件交換地插入復雜的框架應用程序中。可對框架消息執行同步或異步處理。框架充分利用消息設計模式/API 的功能和簡易性。
設計模式框架使用消息傳送來實現和/或促進 Gang Of Four (GoF) 和 J2EE 等知名設計模式的實現。框架本身已基於設計模式被完全創建和實現。框架還基於設計模式促進和加速應用程序的實現。
框架 lego/messaging 架構提供對遠程組件的透明和安全訪問；可將遠程框架對象看作是本地對象。由框架（消息傳送、適配器、遠程代理和外觀）實現的設計模式隱藏與遠程 API 相關的復雜性，從而實現透明和安全訪問。用於消息加密和身份驗證的內置組件也會予以提供。
框架通過框架適配器、代理和相關設計模式的實現提供與其他技術的透明集成。這些技術包括 BPM、Data Access Object 實現（DAO）、Model View Controller 實現（MVC）、EJBs、JSP、AJAX、ESB、JMS、XML、REST 和 Web 服務。
該框架設計為輕量級和快速特性（開銷小/占用內存少）。
框架 messaging/lego 架構提高和簡化了設計/開發工作。UML 設計圖與實現所需的基於消息傳送的框架應用程序和組件之間有一個緊密的對應關系。框架提供生成框架應用程序所需的向導和自動化功能。可將框架組件輕松添加到 BPM/BPEL 流程圖。在未來版本的框架中，應該可以直接從 UML 設計圖生成應用程序模塊。該目標仍在發展中。
框架消息傳送架構促進測試和調試工作。框架可將組件分為獨立單元進行測試，方法是發送消息到組件並驗證回復消息。
消息傳送設計模式（MDP）
意向（Intent）：消息傳送設計模式支持組件與應用程序之間的信息交換（例如，消息）。
動機（動力）：該設計模式可用於在許多不同的場景中解決各種各樣的問題。一個消息傳送范式在模式和現實世界中被廣泛使用。我們周圍到處都有消息的交換。實體在不斷發送、接收和處理消息。例如：當我們看電視、聽音樂、接聽電話或通過互聯網通信時。現在，您在閱讀這個書面消息。由於計算機應用程序尋求建模現實世界，而使用消息傳送方法設計和編寫應用程序是最自然的。我們可以說這個方法提供一個對現實世界更復雜和准確的呈現（例如，模型）。結果，通過使用消息傳送設計模式，軟件工程設計流程得到顯著改進。
參與者：
消息發送方：發送消息的組件。
消息接收方（Reciever）：接收輸入消息的組件，它在處理消息之後可能會生成一個回復（輸出消息）。一般來講，輸入消息可能包含任何類型的信息。組件可能還要基於輸入消息執行計算。
信使（Messenger）：將信息從發送方傳輸到接收方的中介。發送方和接收方不需要關心信息的傳輸方式（通信協議、消息格式、加密/安全機制等）和沿途對消息執行的轉換。這是信使的用途和責任。類似於現實世界，經常不需要用到信使。可以將消息直接發送給接收方。通信模式包括：同步、異步和雙向消息傳送。
消息：需要在發送方與接收方之間交換的任何信息（例如，數據）。通常涉及兩種消息：輸入消息和輸出消息（或回復消息）。回復消息不是必需的。
圖 1. 消息傳送接口
圖 2. 消息傳送設計模式（同步模式）
圖 3. 消息傳送設計模式（沒有信使的同步模式）
結果：
封裝。消息傳送設計模式最大化封裝。每個組件是一個自包含/獨立單元。與其他組件和應用程序的惟一通信機制是通過消息傳送。
解耦。MDP 最小化耦合。同樣，每個組件是一個自包含單元，可獨立於系統其余部分執行。
可重用性。MDP 提高可重用性。這類似於 “Lego” 集中的構建塊。可以基於共享一種簡單互聯方式的簡單片段（例如，公共接口）構建復雜模型。該方法的功能來自於這些片段組裝的組合數。可將使用消息傳送設計模式的組件交換地插入復雜應用程序中。組件可隨意以任何配置進行組裝。一個組件的用戶需要知道組件處理的輸入/輸出消息。應用程序也能夠重用來自其他組件級應用程序的組件：如果使用消息傳送設計模式，就可從另一個應用程序中提取一個組件。
QA/測試流程。MDP 促進測試和調試工作。通過發送消息到組件並驗證回復消息（黑盒測試），可將組件作為獨立單元進行測試。一般而言，可以通過一個測試裝置執行單元測試。無需在組件代碼內包含測試代碼，因為這很耗時且容易引發意外的軟件問題。
設計流程。MDP 提供和簡化設計流程。多半設計工作就是，定義滿足系統需求所需的組件集和每個組件需要處理的輸入/輸出消息。UML 設計圖與實現所需的組件之間有一個緊密的對應關系。由於所有組件共享同一個消息傳送接口，可以將它們輕松添加到 BPM/BPEL 圖。如前所述，這類似於構建塊，可通過多種方式重用和連接。
開發流程。由於依賴於消息傳送的每個組件都是自包含的，一個團隊中的成員可以協作進行開發，無需介入其他人的代碼/工作。在理想情況下，一個組件/包可由一個人專門負責。團隊其余成員需要知道其他人要處理的輸入/輸出消息。無需更改其他人的代碼。而且不需要或很少需要創建、維護和合並多個版本的代碼。測試/QA 工程師可以通過一個測試裝置獨立執行其測試。總而言之，無需添加測試代碼。
日志記錄和調試。由於所有組件使用相同的消息傳送接口，消息會被自動記錄。這降低了在代碼中添加 print/logging 語句的需求，這個工作很耗時且容易出錯。看一下記錄的消息，用戶通常就能夠快速查出引起問題的消息/組件（只需少量工作或無需額外工作）。
開發速度和成本。基於上面概括的所有原因，消息傳送設計模式能夠極大地提高開發速度並降低成本。
質量和軟件維護。質量和軟件維護工作也由於上述原因得到改進。
為了充分利用這個設計模式，人們在建模、設計和構建軟件應用程序時需要考慮消息傳送方面：獨立的實體（例如，組件）相互交換消息。這可能需要學習和培訓。盡管一個消息傳送方法自然、直觀且與現實世界一致，傳統方法基於庫和方法/程序調用（包括本地和遠程）。
MDP 如同一個狀態機。因此可以通過復制組件並通過 consensus 算法協調其交互對其進行擴展，從而以一種更自然、直觀的方式提供容錯功能。一般來說，向一個不使用 MDP 的程序添加容錯特性是一項很困難的任務。
實現和代碼示例：
消息傳送設計模式是使用 Jt 消息傳送接口（JtInterface）實現的。該接口包括一個方法：
清單 1. 消息傳送接口
public interface JtInterface {
/**
* Jt messaging interface used for the implementation
* of the messaging design pattern.
* Process an input message and return a reply (output message).
*/
Object processMessage (Object message);
}
消息傳送接口（JtInterface）簡單而功能強大。該接口的簡易性具有欺騙性。所需要的只是一個方法。它充當一個通用消息傳送接口，適用於遠程和本地框架組件。該接口處理任何類型的消息（對象類）。盡管這裡提出了一個 Java 實現，不過 MDP 和相關框架可以使用任何計算機語言或技術予以實現。
設計模式實現
如前所述，MDP 用於實現和/或促進 Gang of Four (GoF)、DAO 和 J2EE 等知名設計模式的實現。為了解釋如何完成該實現，要用到幾個模式。同樣的概念適用於其他模式的實現。Jt 框架運用這些模式實現高級功能。
Proxy
消息傳送設計模式促進 Proxy 的實現。在消息傳送范式下，Proxy 主要負責將輸入消息轉發到真實主體。
圖 4. Proxy 的 MDP 實現
Adapter
消息傳送設計模式促進 Adapter 的實現。Adapter 的主要用途是實現接收方和發送方之間的消息轉換，從而使這些組件互相連接。
圖 5. Adapter 的 MDP 實現
Web 服務和透明訪問
注意，MDP 發送方和接收方不需要在同一個主機上運行。可以將消息發送到遠程組件上。MDP 在這方面不加以限制。使用一個現實類比法，您可以通過電話/互聯網對話與同屋內或千裡以外的朋友進行通信。MDP 能夠處理所有這些場景。您和您的朋友無需關心對話的傳輸方式（技術、通信協議、安全機制等）。當然，這些對您應該是透明的。
如圖 6 所示，消息傳送設計模式和前面討論的其他幾個設計模式可聯合使用，來實現對遠程組件的訪問。不管使用的協議和通信技術是什麼，MDP 都能夠提供對遠程組件/服務的透明和安全訪問：遠程組件被看作本地組件。消息可以通過 Web 服務、REST、EJBs、RMI、HTTP、Sockets、SSL 或任何類似的通信接口進行傳輸。上面討論的設計模式通過隱藏與遠程 API 相關的復雜性實現該透明和安全訪問。
圖 6. 對分布式組件/服務的 MDP 透明訪問
為清晰起見，將信使組件和內部 processMessage() 方法從下面的 UML 圖中刪除。盡管異步消息傳送受支持，這裡只顯示同步消息傳送。
代理：消息通過代理被發送到遠程組件。
遠程適配器：適配器負責通過轉化消息與遠程 API 連接。
外觀：將消息轉發到合適的遠程組件。它通常也提供安全功能。
再回到我們的現實類比法中，電話公司保留的框架需要某種注冊（電話薄）才能定位其他參與者。每個實體都有一個相關的電話號碼或 ID。所需要的是一個簡單的命名機制。在某些情況下，我們可能需要提供一個城市編碼和/或國家編碼。郵政服務和您的互聯網服務提供商也使用一個相對簡單的命名方案。
其他服務提供者利用框架並使用定制的身份驗證/授權 機制。例如，您的銀行機構利用電話系統且使用 Access Management 機制進行身份驗證和授權。我們在獲准訪問一個賬戶之前需要提供身份驗證信息。
所需的其他框架組件不同於上面概述的那些組件。Facade 組件通常負責安全性（消息傳送授權和身份驗證）。在將消息轉發給接收方之前，Facade 在其上執行解密、授權和身份驗證。
圖 7. 對分布式組件/服務的 MDP 安全訪問
下面是所涉及的組件：
MessageCipher：負責解密輸入消息並加密回復消息的組件。可配置該組件來使用一個特定加密方案。
Component Registry：允許系統注冊並根據 ID 查詢組件。
AccessManager：負責授權/拒絕對遠程組件的訪問。它對收到的每個消息授權並進行身份驗證。如果訪問管理器不能認證消息，消息就永遠不會到達接收方。
框架安全
MDP 可以自然、直觀的方式處理安全難題。它提供端到端、不可否認的消息層安全性（與傳輸層安全相反）。它還可用於選擇性加密，因此只有敏感消息被加密。知名的安全機制很適合於 MDP。另一方面，我們的模型不局限於某個消息格式（XML、SOAP 等）。它提供任何消息格式和 REST 式服務。這包括專用和自定義消息格式。
注意，在一個消息傳送范式下，大部分安全方面對於消息發送方和接收方都可以是透明的。例如，發送方和接收方不需要過於關心是否使用了安全性且如何實現安全性。框架提供必需的安全性組件和機制（“管道”）。一般來說，使用我們的現實類比法，您和您的朋友就無需擔心服務提供者是否出於隱私和安全原因對您的對話進行了加密。Jt 框架還使用聲明安全性來避免編寫易出錯的安全代碼。最後，可基於特定需求提供定制的安全機制。
異步消息傳送、雙向消息傳送和多線程
現在以您的電子郵件或郵政信箱為例。可將消息異步發送並放置在一個消息隊列或堆上，直至您准備 “處理” 它們。MDP 能夠處理與異步消息傳送和多線程相關的復雜性。框架組件能夠在一個獨立的線程中執行任務。這是對現實世界的一個自然表達：每個組件（實體）是一個自包含單元，能夠獨立於系統其余部分執行任務。使用組件自身的獨立線程，可以異步處理消息。這個功能通過一個消息傳送隊列在 Jt 框架的上下文中實現。組件不需要添加獨立邏輯來管理多線程，因為這很耗時、復雜且易於出錯。
您也可以決定異步發送回一個消息，建立一個雙向通信。MDP 能夠建立雙向異步消息傳送機制，其中組件和應用程序相互通信。也可以將同步和異步消息傳送結合起來。比如，在一個同事或主管來檢查進度的同時，您正在閱讀您的電子郵件消息。
性能、可伸縮性和容錯問題
MDP 模型簡單、通用、健壯。它能夠處理與分布式應用程序相關的復雜問題。MDP 與通用的可伸縮性和可用性機制（集群、負載平衡、故障轉移、緩存等）相兼容。例如，基於 MDP 的 SOA 和 ESB 應用程序能夠在計算機集群上運行，從而提高可靠性和可用性。您也可以使用 MDP 靈活地選擇和組合協議和技術。您不必局限於某一技術或協議。您的選擇取決於具體性能和可用性需求。
MDP 也可通過一種很自然的方式予以擴展，以提供容錯功能和技術。復制狀態機方法是實現容錯系統的一種通用方法，它復制組件並通過 consensus 算法協調其交互。框架組件的行為正好類似於狀態機：輸入消息、輸出消息和組件狀態是模型的組成部分。
企業服務總線（ESB）功能
Jt 設計模式框架也是一種消息傳送引擎，提供企業服務總線（ESB）功能。它提供對運行在遠程應用程序內部的組件的透明訪問。框架組件（本地和遠程）能夠安全地交換消息。Jt 框架還允許您連接異構應用程序，而不管使用什麼技術，這些技術包括 JMS、Web Services、EJB、REST, HTTP、EJBs 等。由框架（消息傳送、適配器、遠程代理、策略、外觀等）實現的設計模式可實現該功能。Jt 企業服務總線包括以下主要組件：
Enterprise Service Bus Adapter
JMS Adapters (point-to-point and publish-subscribe)
EJB Adapter
EJB Proxy
RESTful web services Adapter
Secure web services Adapter (Axis)
Axis Proxy
Message Cipher
Message Authenticator
Access Manager
Data Access Objects
Java Mail Adapter
XML/Component transformer
可使用 “lego/messaging” 架構將這些組件交換地插入復雜的框架應用程序中。可通過各種配置裝配它們來滿足特定業務需求。在這種情況下，這些構件塊被組合在一起來共同實現企業服務總線（ESB）功能。
框架 ESB 適配器將應用程序連接到 Jt 企業服務總線。可對 ESB 適配器進行配置，來使用任何交換消息策略：JMS、安全的 Axis Web 服務、EJBs、安全的 REST 式 web 服務、HTTP 等。定制/專用策略和協議可能也會用到。ESB 適配器和其他 ESB 組件也負責自動將消息轉化為適當的格式/協議。
