Your (Method) Call is Important to Us
Both of my home computers suffered fatal and near-fatal failures over the holidays, so I spent a good chunk of time in telephone limbo, also known as on hold. The only advantage of spending time on hold is you get to find out how many different renditions of Having My Baby have been recorded. Even worse than waiting on hold is waiting and then being disconnected, or worse yet, waiting, getting through, explaining your problem, and then getting disconnected.
A similar type of aggravating scenario can occur with Distributed Component Object Model (DCOM) components. In spite of their spiffy high-tech sheen, DCOM components are synchronous objects that are bound by many of the same rules as a telephone call. COM+ Queued Components, which will be introduced with Windows 2000, will enable a more genteel solution.
Message queues are all about availability and reliability, two areas where synchronous protocols like DCOM are weak. Queues also provide a single programming model that supports stationary users and mobile users who are often disconnected from a network. The problem with queuing is that you typically have to develop your own message format and you have to develop a way to translate a desired action into that format -- a process know as marshaling. COM+ Queued Components, however, combine DCOM and Microsoft Message Queue (MSMQ) so COM users can take advantage of queuing immediately, without worrying about complexities like marshaling.
When you call a DCOM method today, you are at the mercy of the server machine. If the machine is under load, you will simply be placed on hold until your request can be finished. The server machine and client machine must both wait -- it's as if the network operator is saying, "your method call is important to use, please continue to hold." Remember, changing a property on a DCOM component is the equivalent of a method call. With a Queued Component, the client calls a method and immediately continues on its way. All the DCOM calls are recorded into a queue that’s guaranteed to be replayed on the server. The difference is that the client doesn’t spend any time on hold.
From a reliability standpoint, consider a program loop that updates DCOM server components. If the network plug was pulled in the middle of the loop, it would be a little nasty figuring out where to restart the process. In the queued example, because the transport layer is separate from the application, the only thing that fails is transmission of the playback queue to the server. In this scenario, MSMQ would automatically finish the queue transmission when the network is restored. From the perspective of the Queued Component application, the temporary loss of the network is meaningless.
Now before you run off and propose Queued Components as the solution for every DCOM ailment, Microsoft has some cold water to throw on your face. If you’ve been wondering how to get results back from a Queued Component, the answer is you can’t. Queued Components only contain call-by-value parameters. This limitation makes sense, considering the server machine doesn't necessarily have to be turned on when a Queued Component is used. This limitation, however, will usually cause an architectural shift in software designed around queues. Asynchronous software needs to handle requests and replies separately. That’s the bad news. The good news is that asynchronous designs tend to scale much better than synchronous designs.
Other than the input-only limitation, Queued Components appear in your Visual Basic, Delphi, C++, or other COM-aware environment like other remote components. In beta 3 of Windows 2000, the only difference between creating an instance of a Queued Component versus a traditional distributed component is the addition of a special prefix -- known as a moniker -- to the component’s ID.
Fewer and fewer people like to have their computer chained to their desk, and nobody likes to wait on hold. Queued Components will give you both the tools to leverage your existing COM expertise and the power of MSMQ to reach remote sites without bringing the telephone’s problems along with you. If you’ve had some interesting experiences converting from synchronous to asynchronous solutions, be sure to drop me a line. --Eric Binary Anderson is a development manager at PeopleSoft's PeopleTools division (Pleasanton, Calif.) and has his own consulting business, Binary Solutions. Contact him at ebinary@yahoo.com.