开发一个基于消息的解决方案是不容易的事情，在生产中操作这样一个产品同样也是一个挑战：一个基于消息的集成解决方案一天可以产生、路由和转换成千上万的消息。我们不得不处理异常、效率瓶颈或改变合作系统。而为了使事情变得更加有挑战性，组件经常被分布在不同的平台和机器上，甚至位于不同的地理位置。
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可以为我们做这些。