Scenario

[Previous] [Next]

You have developed an electronic financial trading system that executes orders on the New York Stock Exchange. Because the system has proven to be stable and reliable, your manager has laid out a plan to add a list of new destinations (such as London and Tokyo) for trade execution over the next few months. As the number of destinations increases to include exchanges around the world, the application evolves to a 24-hour trading system. No downtime is tolerable because, as we all know, time is money. If traders can't place orders on a given exchange because the system has to be shut down to bring new destinations on line, the company could lose a great deal of money.

Implementing the Object Factory design pattern (Chapter 8) in this situation might seem ideal because it uses an ActiveX DLL in which you can define the destination interface, various classes that implement the destination interface, and a factory class that creates a specific class instance of the destination interface expected by the client application. To add a new destination you would first define a new class within the ActiveX DLL and update the factory class implementation so that the factory class would know how to create an instance of the new class. Next you would rebuild the DLL (select Make DLL from the File menu in the Microsoft Visual Basic IDE) and redeploy the DLL to all desktop machines running your electronic trading system.

Unfortunately, there is a catch: If the trading system is running on a machine you're trying to copy the DLL to, the operating system will not allow you to replace the DLL because it is in use. You could copy the DLL, along with a copy of the trading system executable, to a different directory and run the trading system from this new location. However, you'll notice that the new destination is still not available, even to the new instance of the trading system, because Microsoft Windows defines the behavior of DLL usage such that when a client process attempts to load a DLL it looks first in memory. Because the original instance of the trading system application loaded the old DLL, the new instance of the application will grab that version of the DLL from memory. So you're still left with no choice but to restart the trading system application.

Figure 9-1. The Prototypical Object Factory design pattern is implemented through primary and auxiliary server processes.

An alternative you might be thinking of at this point is to create the destination component as an out-of-process ActiveX EXE project rather than as an ActiveX DLL. This implementation leaves you with one central destination component being shared by several trading system clients, which makes deployment easier because you need to update only one file instead of a potentially unwieldy number. Also, because the destination component resides in its own process, you could restart it without affecting the trading system clients. You're now on the right track, but even this method won't work if a reference to the factory is being maintained by a running instance of the trading system and the destination component is registered as MultiUse. (Refer to Chapter 3 for an in-depth explanation of the various registration options.) Restarting the destination component will result in an invalid factory object reference, making the trading system on the client inoperable.

The best way to avoid these showstoppers is to implement the Prototypical Object Factory design pattern. As illustrated in Figure 9-1, you can define the prototypical object factory, which I'll refer to as the destination manager (DM), and an initial list of destinations in a single ActiveX EXE (primary destination server process). The trading system client would obtain references to destinations via the DM. Subsequent destinations can be defined in separate ActiveX EXE components, either one destination per component or multiple destinations grouped together in a single component (auxiliary destination server process), whichever is appropriate. Upon startup, these components must register their Destination objects with the DM. The DM then clones the Destination objects and returns references to them on demand to the trading system client. The trading system never has to be shut down, and new destinations can be brought on line at any point in time, even during the busiest trading hours.