[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ]

At this point, we are pretty much ready to execute our Queued Component. The actual instantiation of the component uses a slightly different syntax than other components. Here's the line of code that instantiates the queued component and executes one of the methods:

    oOrder = GetObject("queue:/new:Hospital.OrderMedicine") oOrder.PlaceOrder("Markus","Cough Syrup")

GetObject() instantiates the component. The extra parameters before the component name make use of a technique called "Monikers". Basically, monikers are pointer to interfaces. In this case, we specify that we want to create a new instance of the Hospital.OrderMedicine object (or the interface that goes along with that class) and we want to do that through the queue. If we used a plain CreateObject() we would have been able to instantiate the same object, but it wouldn't have been executed queued.

The second line actually places an order, but this is done in an asynchronous fashion. This means that this will not actually result in an order, but it will result in a message in the queue (see below). At this point, we have set up the application to be listening for new incoming messages. However, the application has never actually been started. Normally, COM+ Applications are started automatically whenever one of its components gets instantiated. But since we didn't really instantiate the component but just the queue, the application never started. For this reason, the listening process didn't take place and we will not find the file C:\MedOrder.txt on our harddrive. However, we can start the application manually. Just open up the Component Services tool, right-click the COM+ Application and select "Start":

As soon as we do this (there might be a slight delay that is caused by the component instantiation time), the listener sees the incoming message and the text file will appear on the harddrive.

You may now play with some of the settings. You can turn of the listener setting, and you will see that the message remains queued until you turn that setting back on, no matter how often the application is launched and shut down.

Programmatic Application Start and Shut Down

In the above example, we manually started the application. This isn't very useful in real life applications. Typically, applications are started programmatically either to trigger delivery from another application, or to attempt delivery as soon as possible.

Starting and shutting down applications is a relatively simple task that can be performed through a COM interface. The object that is required to perform this task is named COMAdmin.COMAdminCatalog. Here is some sample code that launches our sample application programmatically:

    loCat = CreateObject("COMAdmin.COMAdminCatalog") 
    loCat.Connect("") 
    loCat.StartApplication("Hospital")

Basically, we create an instance of the COM+ catalog, connect to a certain machine (in our example everything is executed on the current machine, but this could be different…) and launch an application of a certain name.

Sub sequentially, an application can also be shut down using the ShutdownApplication() method like so:


    loCat.ShutdownApplication("Hospital")

Typically, these method calls would be found right before a queued component is instantiated, and right after communications with a queued component are complete.

The "Deadqueue"

Messages that can't be delivered will eventually end up in the deadqueue. The deadqueue is a final resting place for messages that cannot be delivered. This queue is not monitored by any listeners. For that reason, messages have to be removed manually (either by hand using the administrator tool, or using a deadqueue handler application).

[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ]