- Objects, Components, and COM
- Abstraction and Class Modeling
- Encapsulation
- Polymorphism
- Inheritance
- Association Relationships
- One-to-One Relationships
- One-To-Many Relationships
- Class and Object Naming Conventions
- Component-Based Development
- Component-Based Development and COM
- COM-Definable Entities
- Component Coupling
- Summary
Component-Based Development and COM
Object-based CBD allows the packaging of class definitions into a deployable entity. Under the Microsoft Component Object Model (COM) architecture, these packages are special Dynamic Link Libraries (DLLs), a dynamic runtime technology that has been available since the earliest days of Microsoft Windows. Microsoft renamed these COM-style DLLs to ActiveX to indicate that there is a difference. An application gains access to classes in an ActiveX DLL by loading the library containing the class definitions into memory, followed by registration of the classes by the COM engine. Applications can then instantiate objects based on these classes using the COM engine.
The traditional DLL (non-ActiveX) meets the definition for CBD, but it is procedurally based (that is, non–object-based). ActiveX DLLs also meet this definition, being object-based in nature. Because an object-based approach is already rooted in the reusability of functionality, the ActiveX DLL implementation of CBD is widely considered the most powerful and flexible technology when working solely on the Win32 platform.
Although COM is both a component and object engine, it differs from other CBD technologies in that it represents binary reusability of components versus source-code level reusability. Because of its binary basis, we can write COM libraries in any language on the Win32 platform that adheres to the COM specification and its related API. The basic requirement to support the COM API is the capacity of a language to implement an array of function pointers that follow a C-style calling syntax. The COM engine uses this array as a jumping point into the public methods and properties defined on the object. Visual Basic is one of many languages with this capability.
COM actually has two modes of operation: local and remote invocation. The distinction between these two will become important as we discuss distribution in Chapter 6, "Understanding Development Fundamentals and Design Goals of an Enterprise Application."
In local invocation, a component is loaded into the memory space of a single computer. This component can load directly into an application's process space, or it can be loaded in a separate process space with an interprocess communication mechanism. In this latter approach, we must establish a communication channel between the process spaces. In the case of distributed computing, these processes reside on physically different machines, and the communication channel must occur over a network connection. We call the local invocation method an in-process invocation, and we call the remote invocation method out-of-process. We can actually make a local, out-of-process reference as well, which effectively removes the network portion of the communication channel. Microsoft developed a local, out-of-process mode of invocation for application automation, for example, when a Microsoft Word document activates an embedded Microsoft Excel worksheet.
With in-process servers, an application can reference an object, its methods, and its properties using memory pointers as it shares a memory space with the component. Figure 3.8 depicts the local, in-process invocation.
){kind=link}
Figure 3.8 The local, in-process invocation mode of COM.
In the out-of-process server mode, all data must be serialized (that is, made suitable for transport), sent over the interprocess boundary, and then deserialized. We call this serialization process marshalling, a topic that we will cover in detail in Chapter 6. Additionally, the out-of-process mode must set up a "proxy" structure on the application (or client) side, and a "stub" structure on the component (or server) side. Figure 3.9 depicts the local, out-of-process mode.
){kind=link}
Figure 3.9 The local, out-of-process invocation mode of COM.
The reason for this proxy/stub setup is to allow the client and server sides of the boundary to maintain their generic COM programming view, without having to be concerned about the details of crossing a process boundary. In this mode, neither side is aware that a process boundary is in place. The client thinks that it is invoking a local, in-process server. The server thinks that we have called it in an in-process manner. The in-process mode of COM is fast and efficient, whereas the out-of-process mode adds extra steps and overhead to accomplish the same tasks.
TIP
We should not use an out-of-process approach in speed-critical areas of an application. Examples of where not to use an out-of-process approach would include graphic rendering or genetic algorithm processing.
If the processes reside on different machines, we must add a pair of network interface cards (NICs) to the diagram. Additionally, we must use the remote procedure call (RPC) mechanism to allow the proxy/stub pair to communicate. We refer to the remote, out-of-process mode of COM as Distributed COM (DCOM). Figure 3.10 depicts DCOM. As we might imagine, DCOM is expensive from an overall performance standpoint relative to standard COM.
){kind=link}