Base content: Service Bus buffers

In my October 2009 column, "Routers in the service Bus" (msdn.microsoft.com/magazine/ee335696), I proposed Windows Azure AppFabric Possible future directions for the service bus: become the final listener. I proposed the router feature and promised to write the queue next.

Since then, routers and queues have been deferred to the second version of the service bus, temporarily providing buffers by the service bus. Future versions may increase logging, diagnostics, and various detection options. I will cover these aspects in a future article. In this article, I'll explain the buffer and show you some advanced Windows communication Foundation (WCF) programming techniques.

Service Bus Buffers

In the service bus, each URI of the service namespace is actually an addressable messaging system junction point. The client can send the message to this junction point, which can be forwarded to the service by the junction point. However, each junction point can also be used as a buffer (see Figure 1).

Figure 1 Buffers in the service bus

Even if no service is monitoring the buffer, the message stores the configured time period within the buffer. Note that there are a number of services that can monitor the buffer, but unless you explicitly view and lock the message, only one of the services can retrieve the message.

The client is separated from the service after the buffer, and the client and the service do not have to run at the same time. Because the client interacts with the buffer and does not interact with the actual service endpoint, all messages are one-way and there is no ready-made way to get the result of a message call or any errors.

The service bus buffer should not be equivalent to a queue or WCF queuing service such as Microsoft Message Queuing (MSMQ), which has a series of critical differences:

The service bus buffer is not persistent and the message is stored in memory. That is, if the service bus itself has a catastrophic failure (albeit somewhat unlikely), the message is at risk of loss.

The service bus buffer is not transactional and cannot be sent or retrieved as part of the transaction processing.

The buffer cannot handle persistent messages. The service must retrieve the message from the buffer within 10 minutes or the message will be discarded. Although messages based on WCF MSMQ also have a lifetime, this time period is much longer and defaults to one day. This greatly increases the range of truly disjointed operations and disconnected applications.

The buffer size is limited and the message reserved cannot exceed 50.

The size of the buffered message is also capped, each 64KB. Although MSMQ also sets the maximum size for the message, its upper limit is much larger (each message 4MB).

As a result, the buffer does not provide true queued calls through the cloud, but if the connection loses calls somewhere between the queued call and the "on-and-go" asynchronous call, the buffer can recover the connections to some extent.

A buffer can be useful in both cases. One is that the connection between the client and service of the application is unstable, and as long as the message is buffered during a short offline period, the drop and reconnection of the connection can be tolerated. The second (and more common) scenario is that the client makes an asynchronous one-way call and processes the result of the call using the response buffer, as described in the following section, "Responding to services." This interaction is more about the network connection as a flexible rope, rather than a rigid network cable without storage capacity.