Queued Components vs MSMQ Triggers vs Custom Listeners

Hello everybody,

here are some notes comparing "Queued components", "Message Queuing Triggers", "Custom Receivers" options for developing an MSMQ based asynchronous architecture.

Due to the limitation of "Message Queuing Triggers" in handling concurrent receival of transactional messages, in a recent experience we chose for developing an architecture based on "Custom Receivers".

hth

Dario

Enterprise Services Queued Components

Advantages:

1.      Queued Components provide a "built-in" retry mechanism for request failures; this behaviour may be a useful default for exception handling.
Generally this is adequate whenever the target request is idempotent.

2.      Queued Components "built-in" retry mechanism protects also against "Poisoned Messages".

3.      Queued Components allow the configuration of "Exception classes" to intercept exceptions from outside of the queued component and manage appropriate compensating transactions.

4.      Receive operations can be processed concurrently; concurrency can be administered with the package property "Maximum concurrent players" on the Queuing Tab.

5.      Queued Components support distributed transactions by means of COM+.

6.      Queued Components can be used in a clustered environment.
This is generally documented for Microsoft Cluster Server environment only; QC configuration for clustered environment is fairly complicated.

7.      Queued Components support role based authorization.

Disadvantages:

1.      Queued Components need COM+ and use of the "Serviced Component" model.

2.      Queued Components are hosted in the COM+ host process (dllhost).

3.      Queued Components cannot interact with the queue; the message format is opaque (RPC NDR binary format).

4.      Queued Components are designed for use of transactional queues (which is the default).

5.      Client and server application are strictly bound to each other. 

Additional Considerations:

Queued Components provide good scalability and reliability.

"Serviced Component" model may add complexity to deployment procedures.

Inability to interact with the message and the queue doesn't allow exploiting some features from the MSMQ transport (eg. Using the response queue).

Message Queuing Triggers

Advantages:

1.      Message Queuing Triggers support distributed transactions by means of COM+

2.      Message Queuing Triggers can be used in a clustered environment.
This is generally documented for Microsoft Cluster Server environment only.

3.      Message Queuing Triggers allow interaction with the message queue; the message format is defined by the application.

4.      Message Queuing Triggers can be used with transactional and non transactional queues. 

Disadvantages:

1.      Message Queuing Triggers don't support automatic administration.

Some administration features are provided by trigadm utility which is not part of the operating system; trigadm utility can be downloaded from the internet and it has limited supportability.

2.      Transactional receive() operations are always processed sequentially.

3.      Message Queuing Triggers cannot be hosted in a process other than mqtgsvc.exe.

4.      Concurrency for receive operations is difficult to administer and with machine scope only.

5.      Message Queuing Triggers require use of COM interoperability (do not require use of Serviced Components)

6.      Message Queuing Triggers use ActiveX message format. 

Additional considerations

Serialization of transactional receive() operations may be a too severe limit for scalability.

Requirement of COM interoperability may add complexity to deployment procedures.  

Custom Receivers (developed in .Net)

Advantages:

1.      Custom Receivers allow native use of distributed transactions; CR do not require COM interoperability nor use of "enterprise services" model.

2.      Custom Receivers allow support for clustered environments.
MSMQ cluster support is documented for both Microsoft and Veritas clusters.

3.      Custom Receivers support concurrent transactional (and non transactional) receive operations.

4.      Custom Receivers can be administered with xcopy deployment.

5.      Custom Receivers allow interaction with the queue; the message format is not opaque.

6.      Custom Receivers allow control of concurrency in receive operations.

7.      Custom Receivers can be implemented as stand alone services or as components to be hosted in existing processes. 

Disadvantages:

1.      Custom Receivers require accurate design for managing transactions, concurrency on receive operations etc..

2.      Custom Receivers require accurate test, especially for handling exceptional conditions, cluster failover etc.
For example, receivers behaviour should be verified carefully with failures on target components, failures msmq operations, handling of poisoned messages etc. 

Additional considerations:

Custom Receivers can provide ease of administration and good scalability depending on the chosen implementation.

They generally involve a higher development risk.

Comments

• Anonymous
  January 03, 2007
  Ottimo articolo su enterprise .NET