Deciding Between MSMQ, QC, and COM Events

[Previous] [Next]

Now that I've covered the fundamentals of MSMQ, QC, and COM+ Events, I'd like to take a step back and describe a few important design issues. Let's say that you need to establish asynchronous, disconnected communication between two applications. As you've seen, QC eliminates the need for programming directly with MSMQ at the expense of some flexibility. If QC provides the functionality you're looking for, it can offer a savings in time and effort. However, you should keep in mind that many things are possible with MSMQ programming that aren't available with QC.

Communicating with computers running Windows NT, Windows 95, and Windows 98 is often a major concern. If this is a requirement, you must work with MSMQ directly. Many companies have determined that QC is best used for server-to-server communication. For example, QC makes it simple to send one-way asynchronous requests from a Web server to an application server. For an application that requires more sophisticated asynchronous communication, it's often better to spend the extra time and money to write your code using MSMQ.

You've seen that the COM+ Events service provides a value-added framework for dispatching event notifications. However, it's important that you understand its strengths and limitations. Many developers overestimate the capabilities of this service and then, after spending time working on prototypes and running stress tests, they decide that programming directly with MSMQ results in more adaptable and performance-oriented solutions.

Microsoft has aggressively pushed QC and COM+ Events as valuable new features and has had little to say about MSMQ. After all, MSMQ was already part of the platform and wasn't a hot new selling point.

Since I'm not a marketer, I've tried my best to convince you that MSMQ is one of the biggest selling points of the Windows 2000 platform. I'm not suggesting that QC and COM+ Events are never useful. I'm fond of QC because it gives Visual Basic developers a multithread listener service and a valuable exception-handling framework. But I urge you to use MSMQ when your design calls for it.

Let's conclude this chapter with an example that uses MSMQ and QC together. Let's say that you have to supply hundreds of client applications with event notifications when a stock price falls below a certain threshold. You start by designing a queued component to run on a Windows 2000 server computer. An application running on a different Windows 2000 computer might raise an event notification asynchronously using the queued component.

When the QC listening service processes the resulting message, it creates an instance of your queued component and lets you notify registered clients. If your queued component programs against MSMQ, you can send notifications to client applications running on Windows NT, Windows 95, and Windows 98. This type of solution promotes scalability because events are raised and dispatched asynchronously.

In a solution such as this, you must find a way to register clients who want to receive notifications. One approach is to create a private queue on each desktop and track the format name of each queue in a database or an XML file on the computer with the queued component that's going to be dispatching event notifications. When the queued component receives an event notification, it can iterate through all the format names and prepare and send a message to each client. Unfortunately, MSMQ doesn't currently support the broadcasting of messages, so you must prepare and send a separate message to each individual client-side queue.

Summary

In this chapter, you've seen quite a few techniques for using Visual Basic to integrate messaging and asynchronous communication into a distributed application. What I hope you take away from this chapter is the why and how of moving data around the network using MSMQ messages.

Messaging can succeed in scenarios where RPC and HTTP fail. Asynchronous communication can significantly increase response times and system throughput. Messaging also improves availability because it provides reliable communication between computers that might become disconnected for any number of reasons.

Transactional programming takes messaging to another level. As you've seen, MSMQ can provide a level of reliability that you can't achieve using RPC or HTTP. Request messages can be submitted with exactly-once delivery semantics. However, you've also seen that transactional messaging involves a good deal of complexity. Someone has to deal with the poison message problem and exception handling.

Finally, you should be familiar with the strengths and weaknesses of each COM+ service so that when you need asynchronous or disconnected communication, you can make an informed decision about whether to use MSMQ or QC. In some applications, QC will meet your needs and can save you a good deal of time and money. Other applications will require MSMQ programming to implement specific functionality or to reach clients running on older versions of Windows. As you've seen, sometimes you can get creative and integrate these two services in a single solution.



Programming Distributed Applications with COM+ and Microsoft Visual Basic 6.0
Programming Distributed Applications with Com and Microsoft Visual Basic 6.0 (Programming/Visual Basic)
ISBN: 1572319615
EAN: 2147483647
Year: 2000
Pages: 70
Authors: Ted Pattison

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net