在我 2009 年 10 月的专栏文章“服务总线中的路由器”(msdn.microsoft.com/magazine/ee335696) 中，我提出 Windows Azure AppFabric 服务总线未来可能的发展方向：成为最终的侦听器。我提出了路由器功能，并承诺下一步将写写队列。
自那之后，路由器和队列已被推迟到服务总线的第二个版本，暂时代之以由服务总线提供缓冲区。未来版本可能会增加日志记录、诊断和各种检测选项。我会在以后的文章中讲述这些方面。在本文中，我将对缓冲区加以说明，也会向您展示一些先进的 Windows Communication Foundation (WCF) 编程技术。
服务总线缓冲区
在服务总线中，服务命名空间的每一个 URI 实际上都是一个可寻址的消息系统交接点。客户端可以将消息发送到这个交接点，交接点可以将其转发到服务。不过，每个交接点也可以作为一个缓冲区（请参见图 1）。
图 1 服务总线中的缓冲区
即使没有服务正在监控缓冲区，该消息也会在缓冲区内存储配置的时间段。请注意，有多种服务可以监控缓冲区，但除非您明确查看并锁定消息，否则只有其中一种服务可以检索消息。
客户端会在缓冲区后面与服务分离，并且客户端和服务可不必在同一时间运行。由于客户端与缓冲区交互，并没有与实际的服务端点交互，因此所有的消息都是单向的，也没有现成的办法获取消息调用的结果或任何错误。
该服务总线缓冲区不应等同于 Microsoft 消息队列 (MSMQ) 等队列或 WCF 排队服务，它们之间有一系列关键性差异：
该服务总线缓冲区不持久，而且消息存储在内存中。也就是说，如果服务总线本身发生灾难性故障（虽然有点不太可能），消息会有丢失的风险。
该服务总线缓冲区不是事务性的，不可以作为事务处理的一部分来完成对消息的发送或检索。
缓冲区无法处理持久消息。服务必须在 10 分钟内从缓冲区检索消息，否则消息会被丢弃。尽管基于 WCF MSMQ 的消息也有生存时间，不过这个时间段要长得多，默认为一天。这极大地增加了真正脱节的操作和断开的应用程序的范围。
缓冲区的大小有限，所保留的消息不能超过 50 条。
所缓冲消息的大小也有上限，每个 64KB。虽然 MSMQ 也对消息规定了最大尺寸，它的上限却要大得多（每条消息 4MB）。
因此，缓冲区无法通过云系统提供真正的排队调用，不过，如果连接会在排队调用和“即发即弃”的异步调用之间的某处丢失调用，在某种程度上缓冲区可以恢复这些连接。
缓冲区在两种情况下会有用。一种是应用程序的客户端和服务之间进行交互的连接不稳固，而只要消息在短期离线期间得到缓冲，连接的丢弃和重新连接是可以容忍的。第二个（和更常见）的情况是客户端发出异步单向调用，并利用响应缓冲区（如后面的“响应服务”一节所述）来处理该调用的结果。这样的互动更多地是将网络连接视为有弹性的绳索，而不是没有存储容量的刚性网络连接线。