COM & .NET Component Services

Queued Components Pitfalls

Queued components is a great service, no doubt, but it does have a few quirks and pitfalls that I would like to point out.

MSMQ Setup

MSMQ can be installed in two configurations. The first relies on having a Windows 2000 domain server present on the network. The workstation onto which you wish to install MSMQ must be part of that domain. The second installation option is for a Windows Workgroup.

To call queued components across the network securely, queued components require the presence of a Message Queuing Primary Enterprise Controller (PEC) on the network. If you install MSMQ for Workgroup, you have to turn the security knob all the way down (set the authentication level for the queued components application to None and avoid using access control checks). Any cross-machine calls must be unauthenticated. This limitation is serious. For any Enterprise-level worthy application, you need the MSMQ domain server installation.

Queued Component Client

A client of a queued component can run only on a Windows 2000 machine. There is no apparent reason for this condition, as every Microsoft platform supports MSMQ. What makes it even more awkward is the fact that most portable devices that could benefit from disconnected sessions will not run Windows 2000.^[5]

Visual Basic Persistable Objects

As mentioned before, a queued component client can pass in as a method parameter an interface pointer to a COM object, provided that the object supports the IPersistStream (so ...