Queued Components

Queued components provide an asynchronous client model for invoking methods on COM+ Serviced Components. Sometimes the client wants to make a method call on a COM+ component but then wants to go on about its business without worrying about how long it takes for the method to complete. This is where queued components help. If a serviced component is queued, the method calls to that component are stored in a Microsoft Message Queuing (MSMQ) queue. When the component has time, it will then process the messages in the queue. This gives your component the ability to perform long-running operations without halting the client application or without using multithreaded programming. The use of MSMQ grants the transmission of messages a measure of reliability and durability. If the power on a server fails with messages still in the queue, they will be processed when the server starts up again.

To implement a component that receives method calls via a queue, you need to define an interface, mark that interface with the InterfaceQueueing attribute, and then define a class that inherits from ServicedComponent as well as implements the interface, as shown in the following code:

using System; using System.IO; using System.Collections.Generic; using System.Text; using System.EnterpriseServices; using System.Windows.Forms; namespace QueuedLibrary { [InterfaceQueuing] public interface IQueuedComponent { void ProcessData(int numData); } public class SampleQueuedComponent : ServicedComponent, IQueuedComponent { public void ProcessData(int numData) {     MessageBox.Show("Data received from queue " + numData.ToString(), "Data Received"); } } } 

Obviously, in a production environment you won't want to be using the MessageBox method because there will rarely be a case where a queued method call will have any meaningful user interface.

Queued components must reside in server-side assemblies that have enabled queuing. The attributes used to accomplish this are as follows:

[assembly: ApplicationName("Queued Component Demo")] [assembly: ApplicationQueuing(Enabled=true,   QueueListenerEnabled=true, MaxListenerThreads=100)] [assembly: ApplicationActivation(ActivationOption.Server)] 

Again, you must provide any COM+ assembly with a strong name for it to be able to be imported into COM+. Because the queued components assembly must run as a server-activated object, it cannot take part in automatic registration; you must use the regsvcs.exe tool to register the COM+ application before a client can communicate with it.

To create a client that consumes a queued component, you need to make use of the System.Runtime.InteropServices.Marshal class. You use Marshal.BindToMoniker instead of new to create an instance of the object:

IQueuedComponent iqc = null; try {      iqc =         (IQueuedComponent)         Marshal.BindToMoniker("queue:/new:QueuedLibrary.SampleQueuedComponent"); } catch (Exception ex) {     MessageBox.Show(ex.ToString()); } iqc.ProcessData(42); // this needs to be done to release properly Marshal.ReleaseComObject(iqc); 

After invoking a method on a queued component, you should see a new message appear in a private queue, as shown in Figure 40.2.

Figure 40.2. MSMQ containing a queued component message.

Either the message will be processed on its own, or you can force the message to be processed immediately by starting and stopping the COM+ application. After the message has been processed, it disappears and the method is invoked, as evidenced by the dialog box shown in Figure 40.3.

Figure 40.3. Dialog box displayed as a result of a queued component method call.