Charlie Kindel
Program Manager/OLE Evangelist, Microsoft Developer Relations Group
Created: March 10, 1994
Revised: October 18, 1994
Software development projects almost always begin life with the designers planning on implementing "modular systems" with "components" that can be used by other developers in other projects. However, in reality, these high hopes are rarely realized because either the modularity breaks down or performance problems make the end-result unusable. The Component Object Model provides a new way of approaching systems design that allows for the development of complex systems where the components are not only very usable, but reusable as well. This technical note describes several potential designs that can be considered when designing market data applications for Microsoft® Windows®.
The Component Object Model (COM) provides the following features to developers in the market data industry:
There are many opportunities for vendors to take advantage of COM and OLE 2.0. Many vendors' current Windows® offerings are second or third-generation applications whose code bases are becoming unmanageable and whose feature sets are not living up to customers' expectations. By redesigning these monolithic applications using COM, these vendors can provide even more value to customers because customers can use the resulting components in the way that best fits their business. Because COM is language-independent, these vendors do not have to completely throw away their existing code bases. Existing code can simply be repackaged into COM objects.
This article consists of four sections. The first part describes the terminology used. The remaining three parts provide descriptions of possible architectures or designs for a component-based market data application. This article does not attempt to describe all of the possible ways these systems could be designed. Its purpose is to illustrate several concepts that can be applied in many different ways, because they are based on the Component Object Model.
A Data Source object refers to an OLE object that provides access to raw real-time data through COM interfaces. Data Source objects typically have little need to provide user interface or advanced OLE features such as Visual Editing or Drag and Drop; they are service providers. The user interface elements a Data Source object may have are typically limited to facilities for controlling the data feed.
Figure 1. A Data Source object directly accesses a data feed and provides access to that feed through COM interfaces
Data Source objects, typically through some proprietary interface, can make requests of, and receive data from, some sort of data feed. The transport mechanism that is used by the data feed may be some network protocol, asynchronous serial I/O, and so on. The point is that the Data Source object is responsible for talking directly to the data feed and making the appropriate data available via OLE interfaces.
Data User object refers to software components that can access the OLE interfaces provided by Data Source objects and, in turn, access the real-time data those Data Source objects provide. Data User objects do not necessarily need to be OLE Document objects—they simply must be able to access the COM interfaces exposed by a Data Source object.
Typically, Data User objects will provide advanced user interface features and will be responsible for rendering the underlying real-time data in interesting ways. In many cases, Data User objects will be OLE Document objects, supporting Embedding, Visual Editing, Linking, and so on.
In the architecture illustrated in the figure below, the container application is literally just a container for any number of the service objects (which may support Visual Editing features and/or OLE Control interfaces). As indicated in the illustration, the service objects are Data User objects that make requests of, and receive data from, the Data Source objects. In this case, the Data Source objects are implemented in .EXE object servers. While the illustration does not indicate it, there may be multiple container applications with embedded service controller objects; the discussion in this section is applicable to that case as well.
Note The diagrams in this document show only a partial set of interfaces actually implemented on the depicted objects. I've attempted to achieve a balance between keeping the diagrams simple and making sure they convey the correct message.
Figure 2. Example architecture for an OLE 2.0-based trader's workstation
The Data Source objects are developed by a data feed vendor. Their primary purpose is to transfer data to and from the network or from some other external source of real-time data. In some cases, the Data Source may "add value" to the data by doing computations or applying analytics. The Data Source may also integrate data from multiple external data feeds (possibly adding value to the raw data as it does so). The Data Source is not necessarily an OLE Document object; that is, the Data Source may support COM interfaces, but does not necessarily support the linking and embedding interfaces. However, the Data Source does implement several interfaces that are useful for data transfer (that is, by following the WOSA/XRT Design Specification in the case of real-time market data—for a copy of the specification, see Backgrounders and White Papers, Operating System Extensions, in the MSDN Library Archive). The vendor can either design a set of custom interfaces or use some of the existing OLE 2.0 interfaces (such as IDataObject and IDispatch) that the Data Source exposes to service objects.
In many cases, the vendor who develops the Data Source will want to implement it as an .EXE. For example, many vendors currently have .EXE applications that are dynamic data exchange (DDE) servers, and they want to be able to reuse the existing code base and have one .EXE that provides their older DDE services as well as the new OLE 2.0 interfaces.
The container in this scenario is relatively "dumb" in that it has no inherent knowledge of the data; it simply serves as a "frame" for all of the service objects to live in. It may also act as a container for non-service OLE objects—such as Microsoft Excel sheet objects—that the user has chosen to embed. It is imagined that this container will support the activation of multiple objects in place at a time.
The service objects are relatively full-featured OLE Document objects that are visually intensive. Examples include objects that chart stock histories, objects that provide access to news stories, and objects that display market data in real time. They support features such as Visual Editing, Linking, and Drag and Drop. These objects support inside-out and outside-in activation and may support the OLE Control-related interfaces. Because these objects support the standard OLE 2.0 Embedding interfaces, they also can be embedded in off-the shelf container applications such as Microsoft Excel or Word for Windows. If the interactions between the service objects and the data source use some published set of interfaces (such as WOSA/XRT), the service objects that access a given data source may come from multiple vendors (or the user may have implemented his/her own).
Figure 3. Multiple data sources, service objects, and containers
It is likely that there could be multiple Data Sources available, each with its own set of service objects. There may also be multiple containers containing service objects that are getting data from different Data Sources. Figure 3 above illustrates this.
This example illustrates how objects that add value to data can make that data available to a container that is capable of more than just embedding objects in a standard, robust manner. Examples include a container that incorporates computational functionality (such as Microsoft Excel 5.0) or one that supports a powerful built-in programming language (such as Visual Basic® for Applications in Microsoft Excel 5.0 or Visual Basic 3.0).
Design 1 in the previous section (smart objects in a dumb container) is very applicable to situations where each service object is self-contained and self-sufficient. That is, the service objects do not require external programmatic control in order to be useful. In addition, the container in Design 1 has no capability for analyzing or otherwise manipulating the data itself; it just sees opaque objects embedded within its frame.
This section builds upon Design 1 by adding the ability for the container to access the value-added data in the service objects and act upon that data. Thus, in Design 2, the container becomes "smart."
If the container will not require high-performance access to the value-added data in the service objects, an OLE Automation-only scheme can be implemented. In this case, the service objects would simply expose an OLE Automation programmability interface via the IDispatch interface. Of course, the container must be an Automation controller (Visual Basic for Applications in Microsoft Excel 5.0).
Sometimes the same high-performance access mechanisms that are required between the service objects and Data Source objects described in Design 1 are required between the container and the service objects. In this case, it makes sense to design the service objects such that they expose interfaces that are very similar to, or the same as, those of the Data Source objects.
In terms of WOSA/XRT, this would mean that both the Data Source object and the service objects are WOSA/XRT data objects, as defined in the WOSA/XRT Design Specification. The service objects would also be WOSA/XRT data users in that they would be the "clients" of the Data Source objects.
This example illustrates that two or more service objects can be implemented such that they can communicate with one another (for synchronization and/or providing services to one another). Just as Design 2 built upon Design 1, this design simply extends Design 2 by providing facilities for the service objects to proactively communicate with the container when something interesting happens (which they want other service objects to know about). In turn, the container would call into the other service objects via OLE Automation.
The key piece of technology that is required to make this flexible and robust is an "event model" whereby service objects can "fire events" into the container, and the container can respond to these events programmatically.
The OLE Controls define such an event model. Thus, it is envisioned that service objects in this design would be OLE Controls.