Queued Components

When most people think of Wall Street traders, they imagine a frenetic trading floor, countless arms outstretched, waving tickets under a green-dotted, scrolling marquee. But not all trading is like that. Take bond trading, for example. Bonds and bond trading are commonly referred to as Fixed Income (FI) trading on Wall Street. The FI trading environment is more reserved than you might expect. In many firms, FI traders sit quite closely to each other at long desks laden with electronic news feeds, telecommunications consoles, and something called a Hoot and Holler (used for hollering announcements throughout the office).

These days, proprietary monitors and news feeds are giving way to Windows desktops, and there is growing acceptance of Windows-based, message-oriented information systems. But at one investment bank I worked with, a major problem occurred regarding an inherent limitation of COM when it applies to messages. With this problem I introduce the concept of asynchronous messaging with Microsoft Message Queue (MSMQ), and ultimately, our discussion works its way up the evolutionary timeline to COM+ Queued Components.

In this chapter, we take a look at how to call methods asynchronously using Queued Components. As you'll see, Queued Components rely on MSMQ, and this chapter also includes as a detailed discussion of this their inter-relationship.

The Mystery of the Hanging News Feeder

As you can imagine, the prompt receipt and processing of a high volume of messages is critical for a trading system. Price corrections, small and large, need to be packaged, processed, and presented to the trader immediately through some sort of user interface.

One firm I consulted for developed a proprietary, centralized system to deliver messages to a number of clients. The system was based on traditional COM (not COM+; this was a couple years ago) and used a mechanism called connection points. Connection points are discussed in greater detail in Chapter 11, "Events," but in the simplest terms, connection points give rise to a scenario where a server COM object holds an interface to its client. This enables the server to call methods on the client's interface (a client can be or create a COM object for the purpose of receiving notification) or, to use other terminology, trigger events on the client.

My client's notification server was found to hang indefinitely on occasion and required someone to kill the process. The client asked me to troubleshoot the system, but I had a pretty good guess as to what was going on without looking at the code. I asked if any kind of modal dialog box was popping up in the event routine of their client application. A modal dialog box, I further explained, is one that suspends any further code execution until it is dismissed. I received a blank look, which was in itself revealing.

Basically, any COM method call is synchronous. This is because COM is based on traditional Distributed Computing Environment (DCE), an industry standard style Remote Procedure Calls (RPC) where a client application blocks until the server-side implementation of a function completes. In more specific terms, an RPC client thread always blocks—that is, freezes—while it is waiting for the server-side RPC thread to run the function implementation and return. If the server takes an arbitrarily long time to complete the function, the client waits just as long. If you turn the tables, you find that the same holds true for connection point clients. If the client-side event hangs somewhere in its implementation code after being called by the server, the server thread that called the event hangs as well. If the server is single threaded, the server is now blocked on the method call to the client, giving the impression that it is hung.

This, in fact, is exactly what was happening with my client's news feed server. The author of the VB client application had implemented a certain event such that it popped up a modal dialog box in response to certain messages. If, however, the trader did not dismiss the form, the server blocked on the call and ceased to deliver any further messages to this or any other client. So, by replacing the modal dialog box with a modeless one, the immediate problem was resolved.

Clearly, an architecture that can be held hostage by one rogue (or badly-written) client is not going to cut it in the enterprise. If, however, your remote method calls are synchronous, there is no convenient way of avoiding the hanging client problem. But what if your method calls could somehow be asynchronous? In other words, what if the client did not need to block on a method call, but could return the moment after it called it? Microsoft offers two COM-based mechanisms toward this end:

• Queued Components (QC)

• Asynchronous COM

QC by far the easier of the two to use, is a COM+ core service, and does not suffer significant limitations of Asynchronous COM (mainly, COM+-configured components cannot use it!). This chapter, therefore, focuses on QC, but I discuss Asynchronous COM at the end.

For an asynchronous architecture to work, you need to forego the use of return values and output parameters in methods you want to call asynchronously. After all, if the client returns from a method call before the method executes, there is certainly no way output parameters can contain valid values.

Assuming you are willing to give up any output or return parameters, there remains the problem of delivery. Often, the return value of a function is used to indicate its success or failure, but if a client returns immediately after invoking a remote method and cannot rely on any kind of return values, it cannot be certain that the server even received the client's invocation. It is awkward to force the developer to write his own acknowledgement scheme, but it is just as awkward for the system to notify the client of a failed method call—how and when should it do so? Many different schemes have arisen to address failed asynchronous calls. Some schemes demand that the server-side implementation of the method be idempotent such that the system can call it multiple times without harm if needed. (We discuss idempotence in Chapter 9, "Compensating Resource Managers," in the section "Handling Recovery.") Other schemes simply ignore the problem altogether and say, "Call at your own risk—no guarantees of delivery."

Providing asynchronous method invocation services that also guarantee delivery is a tricky business, and Microsoft has taken up the challenge in small steps over the years, which has culminated in COM+ Queued Components. The first step, on which others are built, was introduced in November 1997 (as part of the NT 4 Option Pack), and it was called Microsoft Message Queue (MSMQ).

NEXT : Introducing Microsoft Message Queue