Enterprise Services (.NET 1.1) Performance Guidelines - Queued Components

From Guidance Share
Jump to navigationJump to search

- J.D. Meier, Srinath Vasireddy, Ashish Babbar, and Alex Mackman


Use Queued Component to Decouple Client and Server Lifetimes

Queued Components enable you to decouple your application's front end from back-end systems. This has a number of key benefits:

  • Improves performance. Clients become more responsive because they are not awaiting back-end system processing. Synchronous communications force the client to wait for a server response whether or not one is required. This can cause significant delays on slow networks.
  • Improves availability. In a synchronous system, no part of a business transaction can complete successfully unless all components are available. In a queued message-based system, the user interaction portion of the transaction can be separated from the availability of the back-end system. Later, when the back-end system becomes available, messages are moved for processing and subsequent transactions complete the business process.

Facilitates server scheduling. An application using asynchronous messaging is well-suited to deferring noncritical work to an off-peak period. Messages can be queued and processed in batch mode during off-peak periods to reduce demands on servers and CPUs.


Do Not Wait for a Response from a Queued Component

Method calls made to a queued component return immediately. QC is a "fire and forget" model and COM+ does not allow you to return values from a queued component. One of the ways to address this issue is to send a response back from the server using a separate message to a queued component that resides in the client process. However, the client should not wait for a response before proceeding because it cannot guarantee when the server will read and process the call from its queue. The target server may be offline or unreachable due to network issues, or the client might be disconnected.

If you need to ensure that a dispatched message is processed in a particular amount of time, include an expiration time in the message. The target component can check this before processing the message. If the message expires, it can log the message details. Even with this solution, synchronizing time between disparate systems is challenging. If the client absolutely has to have a response from the server before moving on to its next operation, do not use Queued Components.