| Lesson 2 || Prerequisites |
|Objective || Make sure you have the background and equipment required for this course.|
Basic COM Programming Prerequisites
COM Versus ActiveX Versus OLE
Question: What is the difference between COM, OLE, and ActiveX?
That is one of the most common (and reasonable) questions developers ask as they get into this technology. It is a reasonable
question because it seems that the purveyor of this technology, Microsoft, does little to clarify the matter.
You have already learned that COM is the API and binary standard that forms
the building blocks of the other technologies. In the old days (like 1995), OLE was the blanket term used to describe the entire suite of technologies built on the COM architecture.
These days, OLE refers only to those technologies associated specifically with linking and embedding, such as containers, servers, in-place activation, drag-and-drop, and menu merging.
In 1996, Microsoft embarked on an aggressive marketing campaign in an attempt to create brand recognition for the term ActiveX, which became the blanket term used to describe non-OLE technologies
built on top of COM. ActiveX technologies include Automation (formerly called OLE Automation) controls, documents, containers, scripting, and several Internet technologies.
Because of the confusion created by using the term ActiveX to describe everything short of the family pet, Microsoft has backed off a bit and now sometimes refers to non-OLE COM technologies simply as
Those with a more cynical view of the industry might say that the term OLE became associated with adjectives such as slow and bloated, and marketing-savvy Microsoft needed a new term for
those APIs on which it planned to base its future operating system and Internet technologies. Also amusing is the fact that Microsoft now claims OLE no longer stands for object linking and embedding.
The Solution: Component Software
Object-oriented programming has long been advanced as a solution to the problems at hand. However, while object-oriented programming is powerful,
it has yet to reach its full potential because no standard framework exists through which software objects created by different vendors can interact with one another within the same address space,
much less across address spaces, and across network and machine architecture boundaries.
The solution is a system in which application developers create reusable software components
For example, a component might be a spelling checker sold by one vendor that can be plugged into several different word processing applications from multiple vendors. It might be a math engine optimized for computing fractals.
Or it might be a specialized transaction monitor that can control the interaction of a number of other components (including service providers beyond traditional database servers). Software components must adhere to a binary external standard,
but their internal implementation is completely unconstrained.
They can be built using procedural languages as well as object-oriented languages and frameworks, although the latter provide many advantages in the component software world.
Software component objects are much like integrated circuit (IC) components, and component software is the integrated circuit of tomorrow.
The software industry today is very much where the hardware industry was 40 years ago. At that time, vendors learned how to shrink transistors and put them into a package so that no one ever had to figure out how to build a particular discrete function ever again.
Such functions were made into an integrated circuit, a package that designers could conveniently buy and design around.
As the hardware functions got more complex, the ICs were integrated to make a board of chips to provide more complex functionality and increased capability.
As integrated circuits got smaller yet provided more functionality, boards of chips became just bigger chips. So hardware technology now uses chips to build even bigger chips.
The software industry is at a point now where software developers have been busy building the software equivalent of discrete transistors for a long time.
The Component Object Model enables software suppliers to package their functions into reusable software components in a fashion similar to the integrated circuit.
What COM and its objects do is bring software into the world where an application developer no longer has to write a sorting algorithm.
A sorting algorithm can be packaged as a binary object and shipped into a marketplace of component objects. The developer who need a sorting algorithm just uses any sorting object of the required type without worrying about how the sort is implemented.
The developer of the sorting object can avoid the hassles and intellectual property concerns of source-code licensing, and devote total energy to providing the best possible binary version of the sorting algorithm.
Moreover, the developer can take advantage of COM’s ability to provide easy extensibility and innovation beyond standard services as well as robust support for versioning of components,
so that a new component works perfectly with software clients expecting to use a previous version.
As with hardware developers and the integrated circuit, applications developers now do not have to worry about how to build that function; they can simply purchase that function.
The situation is much the same as when you buy an integrated circuit today: You don’t buy the sources to the IC and rebuild the IC yourself. COM allows you to simply buy the software component, just as you would buy an integrated circuit.
A component is a reusable piece of software in binary form that can be plugged into other components from other vendors with relatively little effort.