An Asynchronous Messaging Architecture ASP

Durability and reliability are the main concerns of the architecture presented in Figure 1-8.
MSMQ and COM+ Queued Components are used to accomplish this. Clustering was not an
option considering the budget on this example project, and so to provide for “availability” of
the data access layer, MSMQ and database triggers are leveraged to programmatically syn-
chronize the data in these redundant servers.
This architecture is based entirely on XML. All of the controls in the user interface repre-
sent their state as XML documents, and it’s XML that gets packed into the body of the MSMQ
messages.
Users of this application don’t have a very fast connection, so page sizes are kept to a min-
imum. This means page developers will likely favor caching data on the web server to rebind a
control like a grid across postbacks, rather than rely on ViewState to maintain this information
on the client (see Chapter 4).
The data access layer on the web server needs to support asynchronous operations.
Commands that modify the data are sent to the data access abstraction layer, which doesn’t
actually execute the command, but packs the XML representing the request into the body
of an MSMQ message. This message is then placed in a queue, and execution continues in the call stack on the web server. This means that the web server responses don’t wait for the database work to be done before sending a result to the user. Users see a message that their
requests were sent and to check back later for results. See Chapter 8 for MSMQ examples.

Of course, sometimes synchronous access to the database is critical. When users want to
see data, you cannot tell them that a request for the data they want to see has been submitted,
and to come back later to see it. For synchronous requests for data, you use a simple timeout
listener loop within the data access abstraction layer. This monitors an incoming MSMQ for a correlated result message, sent back from the queue listener when the work has been
completed. This architecture makes it very easy to put in a timeout should the request take
too long. This timeout period can (and should) be controlled by a configuration file. With a
10-second timeout specified in the configuration file, users get an error or warning message
if they wait any longer for a message to appear in the response queue.