開發一個基于消息的解決方案是不容易的事情，在生產中操作這樣一個產品同樣也是一個挑戰：一個基于消息的集成解決方案一天可以產生、路由和轉換成千上萬的消息。我們不得不處理異常、效率瓶頸或改變合作系統。而為了使事情變得更加有挑戰性，組件經常被分布在不同的平臺和機器上，甚至位于不同的地理位置。
System Management包含以下幾種模式
l Control Bus
l Detour
l Wire Tap
l Message History
l Message Store
l Smart Proxy
l Test Message
l Channel Purger
除了與生據來的復雜性、分布式集成的規模以及個性化的應用之外，低耦合的架構使得測試和debug變得更加困難。Martin Fowler將這個癥狀稱為“架構師的夢想，開發者的夢魘”。低耦合的架構原則以及間接的依賴于外部系統提供了靈活性。然而，測試一個消息生產者不了解消息消費者的系統可能會是一個挑戰。另外異步的和時間相關的消息使得事情變的更加復雜。舉例來說，消息方案可能被設計沒有被成消息生產者者必須從接受者那里得到一個回應。同樣的消息基礎設施通常保證傳輸消息，但不能保證傳輸時間。這是的開發基于消息傳送結果的測試用例變得困難。
當監控一個消息解決方案，我們可以在兩個抽象層面上跟蹤消息流。一個典型的系統管理方案監控多少消息被發送或者它多長時間得到一個被處理的消息。這些監控方案不檢查消息數據，除了可能會檢查消息頭中的幾個字段（比如消息標識或者消息歷史）。與之相對的，BAM（business activity monitoring）方案聚焦于包含在消息中的有效數據，舉例來說，發生在過去一小時的所有訂單的金額。System Management中的很多模式都足夠通用并可以用在以上兩個目的中（監控消息頭或者消息內容）。然而，由于BAM本身就是一個新領域，并且需要從數據倉庫中獲得很多數據（有些我們根本就沒有涉及到），我們決定在系統管理的內容中討論這些模式。
系統管理模式被設計用于為保持一個基于消息的復雜系統的運轉所提出的需求并提供工具。System Management的模式涉及三個種類：監控和控制，觀察和分析消息流量，測試和調試。
監控和控制
一個Control Bus提供一個單獨的控制點來對一個分布式方案進行監控和管理。它將多個組件連接到一個中心管理控制臺，這里可以顯示每個組件的狀態并且監控通過每個組件的消息流量。控制臺同時也可以用于發送控制命令給組件，比如，轉變消息流。
我們可能想要在路由消息時添加附加的步驟，比如驗證或者日志。由于這些步驟可能使效率降低，所以我們可以通過Control Bus來控制他們開關。一個Detour為我們提供這種能力。
觀察和分析消息流量
有時我們想要在不影響主要消息流的情況下觀察消息的內容。一個Wire Tap允許我們接入到消息流中。
當我們調試一個基于消息的系統，知道一個特定的消息在哪使很有幫助的。Message History保留一個消息訪問過的所有組件的日志，而不需要增加組件間的依賴。
然而Message History依賴于單獨的消息，一個中心的Message Store可以提供一個穿越系統的每個消息的完整記錄。結合Message History，Message Store可以分析所有消息穿過系統的可能路徑。
Wire Tap, Message History, 和Message Store幫助我們分析異步的消息流。為了跟蹤發送到請求-應答service的消息，我們需要在消息流中插入一個Smart Proxy。
測試和調試
在部署前測試一個消息系統是一個非常好的注意。但是測試不應該停止在部署前。你應該有能力驗證正在運行的消息系統運行持續的運行正常。你可以周期性的發送一個Test Message到系統中并驗證結果。
當一個組件失敗或者運行不正常，它可以簡單的終止，并放棄一個channel中的剩余消息。在測試期間這是很有用的。一個Channel Purger可以為我們做這些。