Microsoft’s Component Object Model is an emerging standard for PC-based and Windows-based component software. To find out more, investigate these links…
For more examples and information regarding Microsoft's COM, check out these additional links:
This site is best experienced with
Click here to start.
This site is in no way sanctioned by:
Please send questions and/or comments to: bdebusk@deroyal.com
For newsgroup information regarding COM and ActiveX, visit: microsoft.public.win32.programmer.ole
Overview Of The Component Software Concept
Component software is a term used to describe a programming technique in which software is written in a compartmentalized form to encourage its reuse. Instead of a single main program, the application is broken down into components that operate together. Each component exists as a "sub-program" that is designed to provide a specific set of functionality. Examples of software components include a spreadsheet grid, a data-graphing window, and a rotating marquee display. These components are not stand-alone applications; they are "pieces" of applications that can be tied together through a controlling program. In the future, applications will be developed by identifying the necessary elements of the program, procuring the required components, and binding the components together to provide application-specific behavior. The use of component software has the following benefits:
The principles of component software and code reusability have been long-time goals of the software industry yet no model has emerged as the complete solution. Source code reusability is offered through languages such as C++, Delphi, Ada, and Smalltalk, but the source code approach has received limited enthusiasm. Link-time reusability models include static and dynamic linked libraries, but these techniques also have severe limitations such as programming language restrictions. Current component software standards have accepted the principle of run-time compatibility. This concept states that the component can be programmed in any language as long as certain programming rules are obeyed. Therefore, a component-based application may use software elements that are written in two or more programming languages.
Although component software promises a wide array of benefits, it is not without cost. Several drawbacks associated with its development and use include:
While these limitations are significant, they should not completely discourage a developer from producing and/or using software components.
The Emergence Of A Component Software Standard
The benefits and drawbacks previously noted apply to all component software but until recently, component software had one much larger problem -- no widely-accepted standard existed. Microsoft’s Component Object Model (COM) specification is the emerging standard for Windows-based computers and possibly for Unix-based platforms in the future. In recent years, several standards have been developed such as Apple’s OpenDoc, IBM’s System Object Model (SOM), and the Object Management Group’s Common Object Request Broker Architecture (CORBA). All of these standards have their own strengths and weaknesses yet developers have been reluctant to program to these standards due to uncertainty regarding which standard will prevail.
Although the acceptance of COM for Windows-based platforms now seems certain, its application beyond the Windows platform is questionable. Virtually every specification claims to be developing its standard on a non-native operating system platform. Not to be outdone, Microsoft has announced plans to develop COM for Unix systems but no release dates have been established. Furthermore, independent third party vendors currently offer limited packages for COM integration on the Unix operating system. Platform invasion is not the only means in which a standard can cross operating systems. Apple has announced that it will incorporate COM compatibility into its OpenDoc specification such that COM objects can be used within OpenDoc components. This would allow an OpenDoc component to encapsulate a COM component thereby allowing it to function on Apple operating systems. The Object Management Group has announced plans to provide a similar encapsulation of COM components for its CORBA specification. This surround-and-conquer technique is not limited to OpenDoc and CORBA specifications: Microsoft has incorporated Java into COM components thus allowing Java applets to execute within COM objects. Incorporation of one standard within another can either strengthen or undermine the standard being incorporated. It can be argued that incorporation amounts to capitulation by the standard performing the incorporation. On the other hand, it can be argued that through incorporation, the incorporating standard obtains the ability to subjugate the foreign standard. The incorporating standard can treat foreign objects as second-class objects and offer its own native format with higher performance. Only time will tell if incorporation benefits the incorporator or the incorporatee.
The widespread use of COM objects may mark the end of large, bloated applications. In a component-driven application, the component does not necesarily load itself into memory unless it is needed. Since COM objects are fully encapsulated sub-programs, it is relatively simple to bring them into and out of memory. Some have speculated that application suites such as Microsoft’s Office Pro and Lotus’ SmartSuite will be undermined by component software. This group believes users will glue together scaled-down versions of their favorite desktop applications from components rather than deal with sluggish applications filled with unused features.
Due to the large installed base of Windows 3.x/95/NT systems, Microsoft’s development and promotion of COM virtually ensures its success. Many of the existing Windows-based applications such as Microsoft Excel, Microsoft Word, and Powerpoint use COM components. Furthermore, these applications make their own objects available for use by other programs. For example, a programmer can make use of Excel’s graphics functions by instancing its "Chart" component within their own application. Many of the functions provided by Windows 95 and Windows NT are also implemented as COM components. Considering the widespread use of COM combined with new tools designed to ease development, the emergence of COM as a standard now seems inevitable.
Overview Of The Component Object Model
COM is based on the concept of interfaces. An interface consists of a group of related functions that focus on a particular aspect of the component. Each interface represents a contract in that the complete set of interface functions must be supported if the component claims to have implemented the interface. When one COM component needs to communicate with a second COM component, a set of rules exists for the two components to negotiate their capabilities. Once the components know each other’s interfaces, they can exchange data and/or trigger each other to perform specific tasks. For example, a spreadsheet control may ask a graph control if it can accept data in a particular format. Once a common format is identified, the controlling application can ask the spreadsheet to provide its data to the graph control and then ask the graph control to display the data. Each component can implement a single interface or a variety of interfaces to provide specific sets of functionality. To be a valid COM object, the component needs to implement at least one interface referred to as "IUnknown." This is the most generic interface with only three functions. The IUnknown interface is not useful in itself; it merely guides the outside world to the more useful interfaces implemented by a component.
COM also relies on support from the operating system. The operating system must keep an inventory of valid COM components and be able to serve the components to applications as needed. Furthermore, some components may execute within different processes or even on different computers. A component’s visual representation may appear on the user’s desktop but the actual executable code for the component may reside on a separate machine. COM uses a technique known as marshaling to transport information between the two machines. This is done transparently to the user who does not realize the transport is taking place. Marshaling does reduce overall program execution speed since the operating system must pack-up data and transfer it from one point to another.
The COM architecture has many strengths:
There are several drawbacks associated with the COM standard:
It does, however, appear that COM's strengths clearly outweigh its drawbacks.
The widespread use of component software will benefit software producers and consumers alike. Producers will generate better applications with shorter development times and users will benefit from higher quality software at lower costs. Programs will be written as combinations of existing software components that are bound together to provide application-specific functionality. In the future, the development of applications from scratch will be as antiquated and impractical as programming applications in assembly language is today.
Historically, failure to agree on a component standard has prevented this important software concept from being fully realized. Different groups proposed varying standards that were not necessarily compatible. This resulted in many software developers being reluctant to write component software due to the fear that their efforts would be wasted on an obsolete standard. The emergence of Microsoft’s COM specification as a dominant component software standard for Windows-based platforms will assist in its widespread commercialization. Although COM is not without its shortcomings, it is the best choice available for PC-based and Windows-based platforms. Developers should both use and write COM-compatible components to ensure the ongoing value of their programming efforts.
Specific Benefits Of Component Software
Programming Time and Expense Is Reduced
Programmers no longer have to develop each application from scratch. Instead, key elements of program functionality are identified and the appropriate software components purchased. The programmer then glues the components together and provides any additional code necessary to complete the application.
The Value of Programming Efforts Is Increased
If a specific type of functionality is not available, a programmer can develop his or her own component and include it in their application. In future applications, any programmer may reuse the component thus the utility of the original programmer’s effort is being maximized. Code reuse has been a long-time goal of the developer community.
Programming typically involves three phases, compilation, linking, and executing. Previous models for software reuse focused on the compilation and linking steps but neither approach has achieved any degree of commercialization. Current component software models focus on the execution phase – the components exist as run-time objects with their own executable code. Therefore, components can be programmed in a variety of languages yet remain invisible to the component consumer.
Component Software Objects Can Easily Be Distributed, Upgraded, and Extended
These objects are distributed as executable sub-programs, not in source code form. Therefore, component developers are protected from others expropriating source code from the object for their own unauthorized use. Distribution and upgrades of COM objects can be done over traditional media such as disks and CDs or it can be done over newer media such as the Internet. Users can upgrade their existing controls and improve the performance and reliability of their existing applications without any other modifications. Some component software architectures incorporate licensing directly into their standards thus simplifying the task of protecting against unauthorized use.
Since components are reused, the code is not being tested in only one application under a limited number of conditions. Each component acts like a self-contained program that interacts with the controlling application. If a bug is detected, it is corrected within the object itself and the improved object is then redistributed to the benefit of all applications using the component.
Look and Feel Consistency Is Increased, and User Training Time Is Reduced
Each component has its own look and feel. If a given component (i.e. a spreadsheet grid) is reused across multiple applications, users can learn the control’s use in one application and transfer that knowledge to another application. Much like users can become familiar with the Microsoft Windows interface, users can become familiar with specific controls that appear across a broad variety of applications.
Specific Drawbacks Associated With Component Software
System Performance May Be Reduced
The additional code necessary to implement component software does reduce overall program execution speed. This code is typically necessary to package the component such that it can communicate with other objects. All of the interface code adds overhead to the component’s size and execution speed and contributes to the problem of large, inefficient applications commonly referred to as "code bloat." Programming of the component must also be modified. Typically, the component is written with little or no specific knowledge of how it will be used. This requires the programmer to include additional code to guarantee resiliency. For example, a graphics component would not know the scale of the data to be plotted, the number of points to be displayed, or the number of data series. Components should always be written with worst-case scenarios in mind.
Programming Skill Set Bifurcation Will Occur
As component software emerges, the programming community will be divided into two classes: component producers and component consumers. Component producers will develop the component software at the most basic level. These programmers will have expertise in programming at the lowest levels in languages such as C and C++. The increased complexity associated with component software will be borne almost exclusively by this group of programmers. Component consumers will use existing component software to generate applications. They will use higher-level languages such as Microsoft’s Visual Basic or Borland’s Delphi to instance components into applications and use the high-level language itself to bind the components together.
Operating System Platform Choices Are Limited
Most component software is platform-specific in one of three operating system camps: 1) Windows 95/NT platforms, 2) Unix and Unix-variant platforms, and 3) Macintosh platforms. Each platform has announced plans to incorporate rival platform standards, yet very little cross-platform object support exists. For now, cross-platform component software choices are limited.
Components Are Processor-Specific
Most forms of component software are compiled for a particular class of processor such as the Intel x86 series or the MIPS 4x000 series. This requires a user to have not only the appropriate component but the component must be compiled for the appropriate processor. Since components are still largely operating system platform-specific and operating systems are still largely processor-specific (including Unix variants), this issue has not yet presented a problem. As operating systems branch-out to cover additional processors (i.e. Windows NT running on Intel, Alpha, and MIPS platforms), the need to recompile a component for each platform becomes more important. The one exception to this is Java, which uses a platform-independent pseudocode capable of running under a variety of processors. In general, Java programs execute more slowly than their native counterparts. Most users are unwilling to sacrifice the component's execution speed in exchange for platform independence and a variety of solutions such as Java compilers are currently in use.
Specific Benefits Of COM Objects
COM Components Can Be Small and Fast
Fortunately for COM objects, a minimal implementation requires very little system overhead. In this minimal form, one component can make program calls directly into a second component and no data movement is necessary. Objects using direct interfaces that operate within a common process space are practically as efficient as direct coding. More complex COM objects can require substantial amounts of system overhead, particularly objects that are distributed among multiple computers. COM objects that implement a scripting interface for compatibility with Microsoft Visual Basic also suffer from reduced performance due to the process of late binding. Late binding is an interface technique that increases the component’s run-time flexibility but the host application must incur a performance penalty as a result.
A Variety of Tools Exist for Producing and Using COM Components
COM components can be produced through a variety of programming languages. The most common platforms include the C and C++ programming languages, Microsoft’s Visual Basic programming language, and Borland’s Delphi programming language. Microsoft has hinted that all major COM development should be done through its Visual C++ development platform. Other platforms such as Visual Basic produce valid COM components but their execution speed will most likely suffer.
A Large Number of COM Interfaces Are Defined
COM is merely an interface protocol standard. It does not define any specific interfaces other than the default interface, "IUnknown." Therefore, developers must agree upon common interfaces to allow components to interoperate efficiently. For example, moving large amounts of data between components is a common need. Microsoft has defined an interface to implement uniform data transfer (UDT) referred to as "IDataObject." This interface consists of a specific set of function calls necessary for data transfer. Therefore, a component that needs to exchange data with other objects would implement the "IDataObject" interface and advertise the interface to the outside world.
A large number of interfaces have been standardized by Microsoft. Examples of these interfaces include uniform data transfer (UDT), drag-and-drop, persistent (i.e. hard disk) storage, and in-place editing. These published interfaces enable programmers to selectively implement functionality that enables new components to communicate with a wide variety of existing objects. Many of the Windows 95 and Windows NT functions (i.e. the Recycle Bin) are implemented using standard component interfaces.
A Large Number of COM-Compatible Components Are Available
Developers are producing COM components. Components are currently available to provide data spreadsheets, graphic plots, telephony functions, database access, image processing, and much more. These components commonly range from free to $1,000 with some components requiring no per-seat licensing and others charging on a per-seat basis. COM objects commonly implement a licensing interface to allow developers to control their component’s distribution and use. Features such as common licensing control encourage developers to produce objects using the COM architecture.
COM Components Can Be Tailored for the Internet
The COM architecture can be extended to work with the protocol used by Internet to implement the World Wide Web (WWW). To be an Internet-capable control, developers must implement a series of interfaces within their COM-compliant object. A higher-level specification referred to as "ActiveX" has been defined by Microsoft that describes the necessary interfaces. Once these interfaces have been implemented and advertised, application developers and web surfers may use these components through their ActiveX-compatible browser. Currently, ActiveX is positioned to compete primarily with Sun Microsystem’s Java technology. Many believe that ActiveX is "flawed" yet also believe that it will survive through Microsoft’s ongoing efforts to participate in the Internet. Microsoft has announced an ActiveX control that can run Java applets and plug-ins.
Specific Drawbacks Of COM Objects
COM Is Tightly Coupled with Windows 95/NT
Currently, the full COM architecture is available only on Windows 95/NT platforms. Note that this does not limit its use to Intel architectures since Windows NT is available on DEC, MIPS, and PowerPC platforms. Microsoft has announced its intention to develop COM for Unix and Unix-variant platforms, but firm release dates have not been announced.
COM Component Development Can Be Difficult
COM components are often difficult for developers to implement. An extensive amount of code must be provided to implement a valid COM object. Several development platforms such as Visual C++ provide developers with "Wizards" that automatically generate the component’s code shell after asking a few questions of the programmer. The developer can then customize the code shell as necessary to implement the component’s specific functionality. Furthermore, the software debugging tools for COM objects are less developed than their non-component counterparts. Since COM objects can be active on multiple computers, it is often difficult to determine the source of an application’s malfunction.
Interface Standards May Diverge
The COM architecture only specifies how software components communicate – not the specific interfaces they should use. Microsoft has already defined many interfaces that provide standard features such as drag-and-drop, data transfer, and persistent storage. These are not the only valid interfaces; any developer can define and implement their own custom interface. Although this in one of the greatest strengths of COM, it is also one of its greatest weaknesses. With unchecked interface proliferation, developers will create their own closed set of interface standards that will be incompatible with the work of other developers. This problem has been partially averted through Microsoft’s use of a standard scripting interface referred to as "IDispatch." The coordinated development of interface standards will be necessary for the ongoing success of COM.
Additional Links Regarding COM
Microsoft Corporation Home Page
COM (OLE) Development Home Page
Reference Articles Of Interest
"Exploring IBM’s SOM," Part 1, Garbrielle Gagnon, PC Magazine, October 10, 1995
"Inside the ActiveX Platform," Thomas Mace and Neil J. Rubenking, PC Magazine, September 24,1996
"OLE Automation Collections," John Lam, PC Magazine, April 9, 1996
"Prepackaged Power: New OCX Controls," Stephen W. Plain, PC Magazine, January 23, 1996
"Custom Interfaces, Customizable Objects," Richard Hale Shaw, PC Magazine, February 6, 1996
"Understanding Objects," Richard V. Drangan, PC Magazine, November 7, 1995
"Reusable Binary Components," John Lam, PC Magazine, March 12, 1996
"ActiveX Gets New Owner," Internet Trends, PC Magazine Online, October 2, 1996
"Will an ORB Light Up Your Network?" Software Trends, PC Magazine Online, February 7, 1996
"In COM-vs.-CORBA Battle, Some Developers Stay Neutral," Norvin Leach and Michael Moeller, PCWeek Online, August 12, 1996
"OpenDoc Gains Fans: Cyberdog Goes Abroad," Clifford Colby, MacWeek, April 1, 1996
"OMG Blesses OpenDoc," Clifford Colby, MacWeek, March 21, 1996
"Microsoft’s ActiveX Technology Open To Industry Input," Karen Rodriguez, Inter@ctive Week, October 3, 1996
"Time To Take Part In OpenDoc Revolution," Clifford Colby, MacWeek, January 9, 1996
"OpenDoc Parts Coming Together," Clifford Colby, MacWeek, December 4, 1995
"Hot-wiring Software Distribution," Dave Kosiur, PCWeek Online, September 19, 1996
"OpenDoc: Live Objects Closer Than They Appear," Clifford Colby, MacWeek, August 9, 1996
"OpenDoc Enters Fray," Stephen Howard, MacWeek, May 29, 1995
"Outside Developers Chasing Cyberdog," Henry Norr, MacWeek, June 17, 1996
"Battle Brewing: ActiveX Vs. Java," Karen Rodriguez, Inter@ctive Week, July 22, 1996
"Building ActiveX Controls: The State of the Tools," Neil J. Rubenking, PC Magazine, September 24, 1996
"Sharing the Wealth: DCOM and DSOM," Larry Seltzer, PC Magazine, September 24, 1996
"Coming Soon: A New Kind of Application," Jeff Prosise, PC Magazine, April 11, 1995
"On-Line Componentware," Jon Udell, Byte Magazine, November 1996
"A Better Foundation," Rainer Mauth, Byte Magazine, September 1996
"OpenDoc Says OLE to Developers," Emily A. Vander Veer, Byte Magazine, July 1996
"OpenDoc: A Better OLE than OLE?" Robert L. Hummel, Byte Magazine, July 1996
"Tool Makers Take It to the Net," Steve Apiki, Byte Magazine, June 1996
"ActiveX Chases Java," Steven J. Vaughan-Nichols, Byte Magazine, June 1996
"OLE’s Missing Links," Keith Pleas, Byte Magazine, April 1996
"More Reusable Components from Smaller Libraries," Byte Virtual Press Release, February 2, 1996
"What is the Future of Reuse?" Byte Virtual Press Release, February 2, 1996
"OLE on Unix? You Bet!" Rainer Mauth, Byte Magazine, February 1996
"OpenDoc: Small Is Beautiful," Raymond GA Cote, Byte Magazine, February 1996
"Components Everywhere," Tom R. Halfhill and Salvatore Salamone, Byte Magazine, January 1996
"How to Walk to Standards Tightrope," Byte Magazine, January 1996
"Integration, Not Perspiration," David S. Linthicum, Byte Magazine, January 1996
"Killer Components," Alan Joch, Byte Magazine, January 1996
"The Components of Change – Companies Turn to Prewritten Software Rather than Code from Scratch," Jacques Surveyer, InformationWeek, May 6, 1996
"Building Compound Applications with OLE," Tom Hagan and Ed Harragan, InformationWeek, November 14, 1994
"Java Beans Shake Up Component Software World," Sun Microsystems White Paper, Computer Reseller News, October 28, 1996
"Microsoft Surrenders ActiveX Standards," Rich Levin, InformationWeek, July 29, 1996
"CORBA Gets Center Stage – IBM, Sun to Disclose Deal at Object World West," Rich Levin, InformationWeek, August 19, 1996
"Roll-Your-Own-Apps On-Line," R. Colin Johnson, EETimes, December 18, 1995
"Spec Wars: DCOM and OLEnterprise Battle for Distributed Windows Apps," Andy Feibus, InformationWeek, October 7, 1996
"OMG Agrees on Protocol That Promises Object Interoperabilty," Frank Hayes, Open Systems Today, November 28, 1994
"The Future of Object Systems," Lamont Wood, InformationWeek, November 21, 1994
"Knit 1 Pearl 0 – The Rise of Modular Software Components," Phillip J. Gill, OEM Magazine, May 1, 1995
"Object Spec Bridges CORBA, OLE," Martin Marshall, CommunicationsWeek, May 13, 1996
"Object Software Finally Comes to Life at Confab," Alexander Wolfe, EETimes, August 1, 1994
"Web Development Tools – Cooking From Scratch," Rich Levin, InformationWeek, May 20, 1996
"Middleware: Distributed Objects, Few Standards," Bruce Robertson, Network Computing, October 1, 1995
"Object Standard – OMG Interface Links OLE-COM with CORBA," Martin Marshall, CommunicationsWeek, April 29, 1996
"OMG Challenges Microsoft’s OLE with OpenDoc’s Compound Documents," Martin Marshall, CommunicationsWeek, March 25, 1996
"The OpenDoc Challenge – When It Comes, Could It Dethrone OLE as the Component Standard?" Ian G. Jacobs, VARBusiness, November 1, 1995
"Where to Buy Objects Over the Internet," Clinton Wilder, InformationWeek, December 11, 1995
"Distributed Applications – Choose Your Architecture," Herman Mehling, InformationWeek, July 29, 1996
"Microsoft Complies with DCE For Now," Herman Mehling, InformationWeek, July 29, 1996
"OpenDoc, OLE 2.0 May Be the Solutions to Problems Raised by Compound Documents," Sally Atkins, Open Systems Today, May 9, 1994
"Mastering Objects – Object Middleware Holds the Secrets to Distributed Computing," Phillip Gill, InformationWeek, October 21, 1996
"Application Suites: Just a Passing Fad?" Paul Krill, Open Systems Today, April 25, 1994
"Components Are Here Now," Stewart McKie, ComputerWorld, December 11, 1995
"Assuming the Lotus Position," Sharon Gaudin, ComputerWorld, August 26, 1996
"Industry Turning to Components," Ed Scannell and William Brandel, ComputerWorld, April 11, 1994
"Components May Sour Users on Software Suites," Lisa Picarille, ComputerWorld, February 26, 1996
"Who Needs Objects?" Cheryl Gerber, ComputerWorld, November 13, 1995
"Back to the Future?" Judith Hurtwitz, ComputerWorld, May 1, 1994
"Components Turn Up Web Wattage," Sharon Gaudin, ComputerWorld, July 22, 1996
"OpenDoc vs. OLE/COM," Cliff Reeves, ComputerWorld, January 30, 1995
"Adding Applets to Notes May Undercut SmartSuite," Tim Ouellette, ComputerWorld, January 29, 1996